The Okura Tokyoのラウンジで、私はインドのAI企業EMB Globalのチームと向かい合っていた。
Honda、Rakuten、グローバル製造業の名前が次々と出てくる。2,500人規模のAIエンジニアネットワーク、AI-first delivery、Custom AI、AI Agent。資料の構成は洗練されていて、デリバリーの実績にも穴がない。日本市場に本格参入したいという話で、その温度感は静かだが本気だった。
会話は最初の30分、極めて滑らかに進んだ。
PoCの話、ワークフロー再設計の話、custom AIの優位性、low-code化のトレンド、vibe codingという最近の用語、Honda案件で得られた知見。彼らの口から出てくる単語は、世界中のAIカンファレンスで毎週聞かれているものとほぼ同じだった。私もそれに合わせて、こちらの観測を返していった。
ところが、ある瞬間に、空気が少しだけズレた。
私が「日本のエンタープライズではPoCの後で止まるケースが多い」と言ったときだ。
相手のリードは、ほんの一瞬だけ反応を遅らせてから、概ねこういう趣旨のことを答えた。本番運用に入る前に、人間が最後に確認する仕組みを入れる、と。言葉の選び方は丁寧で、本番運用では人間の確認を必ず挟む、そういう説明だった。
完璧な答えだった。教科書的に正しく、コンプライアンス的にも問題がない。総務省・経済産業省のAI事業者ガイドライン1.2版でも、自律性を持つAIエージェントやPhysical AIを念頭に、リスクに応じた人間の介入、説明責任、トレーサビリティの確保が重視されている。彼の答えは、その方向性にも整合していた。
でも私は、その「正しさ」が、実装の現場ではほとんど機能しないことを知っている。
そしてそれを、目の前の彼らが本気で信じているのか、それとも営業上の安全弁として置いているだけなのか、その境目がよく見えなかった。
PoCで止まる、という現象の中身
日本のエンタープライズがPoCで止まる、という話は、もはや業界の決まり文句になっている。原因として挙げられるのは、稟議文化、リスク回避、現場との合意形成、ROIの説明責任、いずれももっともらしい。
しかし、ここ数年、財務、製造、官公庁、複数の現場で本番化の手前まで併走してきた中で、私が観測してきた本当の停止要因は、もう少し別のところにある。
PoCは成功する。デモも動く。精度も合格ラインを超える。役員レビューも通る。
そこで止まる。
止まる場所は、技術検証ではなく、責任の引き取り方が言語化できなくなった瞬間である。
「これを本番に入れたとして、AIが間違えたときに、誰が、どの権限で、どのタイミングで止めるのか」
この問いに対して、誰も明確に答えられない。情シスは「業務オーナーが決めることだ」と言い、業務オーナーは「AIの挙動はベンダーが保証するはずだ」と言い、ベンダーは「最終判断はお客様にあります」と言う。リーガルは「ガイドラインに従ってください」と言う。
ガイドラインには、人間が最終確認をすることになっている。だから、その「人間」を一人決めればよい、ということになる。
現場で起きるのは、その「人間」が、AIの出力を承認ボタンで通すだけの存在になることだ。判断していない承認者が、判断の責任を負う構造だけが残る。
これがPoCの先で起きていることの、私が見てきた範囲での実像である。
low-codeが静かに変えている地形
EMB Globalとの会話の中で、もうひとつ気になった話題があった。
Vibe Codingと呼ばれる流れである。エンジニアでなくても、自然言語に近い指示でAIを呼び出し、業務を組み立てられる。Custom AI、ノーコードのAIエージェント構築、業務部門による自走。これらは確かに、生成AI以前と比べて圧倒的に容易になった。
問題は、容易になったがゆえに、誰がそれを作ったのか、どんなロジックで動いているのか、何を入力として受け取って何を出力しているのか、それを把握している人間が組織内に存在しなくなりつつあることだ。
業務部門の中堅社員が、月曜の朝に自分の業務効率化のために組んだAIエージェントが、半年後には部門全体の判断フローに組み込まれ、一年後には他部門の業務にまで影響を及ぼしている。そして作った本人はもう異動している。
これは技術的なブラックボックス化とは少し違う。技術的には、ログを取れば追える。プロンプトも残っている。
追えなくなっているのは、「この処理は、組織として、誰の判断のもとで動いているのか」という意味での責任の連鎖である。
エンジニアの世界には、コードレビュー、デプロイ承認、変更管理といった仕組みが、何十年もかけて整備されてきた。ローコードは、その積み重ねを、業務部門の領域で一気に飛び越えた。
そして、その飛び越えに対応する組織的な枠組みは、まだ存在していない。
「Human-in-the-loop」では足りない、という感覚
EMB Globalのリードは、Hiroshima AI Processにも触れた。広島で日本がホストした国際枠組み、生成AI事業者の責任と透明性に関する原則。彼はそれを知っていた。AI Guidelines for Businessの内容にも目を通していた。
その上で、Human-in-the-loopは前提として組み込みます、と言った。
私はそこで、少しだけ言葉を選んだ。
Human-in-the-loopは、概念としては正しい。AIの判断系の中に、人間の介入点を必ず設けるという考え方。問題は、その「人間」が、介入できる構造に置かれているかどうかだ。
AIが秒単位で1000件の処理を回している中で、人間が「最終確認」として承認画面に座っているとする。一件あたり3秒の確認時間しかない。差し戻したら全体のスループットが落ち、業務部門からクレームが来る。差し戻したケースが後日「正しかった」ことが証明されても、評価されるわけではない。差し戻さなかったケースで問題が起きたら、責任は問われる。
このとき、その人間は本当にloopの中にいるのか。
形式上はいる。承認権限を持っている。ログにも名前が残る。
しかし、判断する余地も、判断するインセンティブも、判断するための情報も、ほとんど与えられていない。
これを私は、構造的に空洞化したHITLと呼んでいる。リーガルとコンプライアンスの観点では、Human-in-the-loopは設置されている。実態としては、人間は判断していない。AIの出力が、人間の承認印を経由して、組織の決定として外に出ていく。
その決定が後で問題になったとき、組織は「人間が最終確認していました」と説明することになる。その人間は、何を確認していたのか、自分でも説明できない。
ガバナンスでは届かない場所
会話の終盤、私たちはガバナンスの話に入った。
EMB Globalは、日本のエンタープライズが求めるtrustとgovernanceの水準が高いことをよく理解していた。データ主権、監査要件、リスク評価、ベンダー責任の範囲、契約上の保証。それらは彼らの提案資料の中に、きちんと織り込まれていた。
ガバナンスのチェックリストには、ほぼ全て答えがある。
私が引っかかっていたのは、そのチェックリストの外側にある領域だった。
ガバナンスは、ルールを定め、ルールを守らせ、ルール違反を検知する仕組みだ。AI ethicsは、何をしてはいけないかを定める。DXは、業務をデジタル化して効率化する。Automationは、人間の作業を機械に置き換える。
これらは全て必要であり、どれも単独では十分ではない。
そして、これらが全て揃った先に、まだ名前のついていない領域が残っている。
それは、「AIが業務の参加者になった瞬間に、誰が、何を、どの境界で決めるのか」を、組織として設計するという領域である。
ガバナンスはルールを与える。しかしルールは、判断そのものを設計するわけではない。
判断は、ルールとルールの隙間、ルールが想定しなかった事態、ルールが複数同時に適用される瞬間に発生する。
そこで誰が決めるのか、その決定はどこに記録され、どう引き継がれるのか、その設計は、ガバナンスの語彙の外にある。
静かな予告
会食が終わって、ホテルの正面玄関で彼らを見送ったあと、私はしばらく霊南坂を下って虎ノ門の夜の通りを歩いた。
EMB Globalの提案には穴がなかった。彼らは優秀だったし、誠実だった。Honda、Rakutenの実績も本物だろう。日本市場で成功する可能性は十分にある。
それでも、私が会話の中で感じていた違和感は、彼らに固有のものではなかった。
ここ2年間、海外のAI企業、国内のAIベンダー、生成AIを導入しようとするエンタープライズの担当者、そのほぼ全ての会話で、私は同じ感覚に出会ってきた。
技術の話は通じる。導入の話も通じる。ガバナンスの話も、HITLの話も、ガイドラインの話も、全て通じる。
通じないのは、その全部が揃った後に残る、判断そのものの構造の問題である。
これは技術の問題ではない。ガバナンスの問題でもない。
おそらく、もっと手前の、組織が「決める」という行為そのものを、いつの間にか言語化できなくなっている問題なのではないか。
そう考え始めた頃から、私は自分の仕事の中で、ひとつの概念を使い始めるようになった。
それが Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのがDecision Boundary（判断の境界） という概念である。誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
ここから先では、Decision DesignとDecision Boundaryについて、定義、構造、そして具体的な実装の輪郭を書いていく。
Enterprise AIの本番運用で露出する責任構造問題に対して、ガバナンスでもHITLでもないレイヤーから、何をどう設計するのか。Escalation Matrix、Authority Map、AI Decision Logging、Override Triggerといった具体論にまで踏み込む。
PoCで止まるのではなく、本番運用の中で組織が説明能力を失う、その手前に何を置くのか。それを書く。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。