Insynergy

AIエージェントが実行を担う組織で、最後の判断は誰が引き受けるのか

AIエージェントがコードを書き、テストし、本番投入の準備まで担うときも、最終的なリリース判断は説明責任を持つサービスオーナーが引き受けなければならない。委任範囲、停止条件、エスカレーション、記録を設計しなければ、人間の承認クリックは儀式を残して責任を失わせる。

AIがコードを書いたあと、誰がリリースを決めるのか

金曜日の17時40分。 AIコーディングエージェントが変更を仕上げ、テスト結果とプルリクエストを提示している。 画面には、本番環境へ進めるための緑色のボタンが表示されている。

コードを書いたのはAIであり、テストを回したのもAIである。 しかし、その変更が顧客の要求を正しく解釈しているか、想定外の影響を許容できるか、この時刻に公開してよいか。 それを誰が決めるのかは、画面のどこにも表示されていない。

これは実在の事件ではなく、説明のための想定場面である。 ただ、AIコーディングエージェントを導入した開発の現場なら、似た瞬間に心当たりがあるだろう。

本稿が追いかける問いはこうだ。 AIが実行を担うようになった組織で、最後の判断は誰が引き受けるのか。

先に答えの骨格を示しておく。 「判断は人間に残る」と単純に言えるわけではない。 判断の一部はAIへ委任できるし、委任したほうが速く安全になる場合もある。 問題は、委任の範囲、受け入れの条件、停止の基準、最終責任を、誰も決めないまま運用が始まってしまうことにある。 AI時代に人間へ残る仕事は、AIにできない作業の残余として自然に決まるのではない。 目的設定、受容条件、停止、例外処理、最終承認、説明責任のうち、誰が何を引き受けるかを組織が設計した結果として決まる。

AIの能力向上と、組織の変化は同じ速度では進まない

この問いを考える出発点として、一つの講演を紹介したい。 プリンストン大学のArvind Narayananが2026年7月9日、ソウルで開かれた機械学習の国際会議ICMLで行った基調講演「What will be left for us to work on?（私たちに残る仕事は何か）」である。 編集済みのトランスクリプトが著者のニュースレターAI as Normal Technologyと注釈付きスライドとして公開されている。 査読論文ではなく、著者自身の研究、仮説、予測を含む講演録である。 その性質を踏まえて読んでも、経営者への示唆は多い。

Narayananは、共著者のSayash Kapoorとの論考「AI as Normal Technology」（Knight First Amendment Institute）で、AIを過去の汎用技術と同じ経路で普及していく「普通の技術」として捉える見方を示してきた。 AIが社会と経済に及ぼす影響は、モデルの能力だけでは決まらない。 手法の進歩、製品化、初期導入、そして業務、組織、制度、人材の再設計を伴う組織的適応という段階を経て現れる。 このうち最も遅いのが適応である。

同論考は電化の例を挙げている。 工場に電動機が入ってからも、生産性の向上が統計に現れるまでに約40年を要した。 動力源を置き換えるだけでは足りず、工場の設計と作業の組み立てそのものを組み替える必要があったからである。

であれば、経営者が問うべきことも変わる。 「AIはどこまで賢くなるか」だけを追っても、自社への影響は読めない。 自社の業務と判断の仕組みをどう組み替えるかが、影響の速度と深さを決める。

AIが圧縮するのは仕事全体ではなく、実行の層である

講演でNarayananは、ソフトウェア開発の仕事を三つの層で捉えてみせる（著者はこれを「decide-execute-deliverのサンドイッチ」と呼ぶ）。

decide：顧客の要求を理解し、何を作るか、どの優先順位で作るかを決める層。 execute：コードを書き、デバッグし、テストする、実装の層。 deliver：結果を検証し、既存のシステムへ統合し、顧客へ届け、その結果を引き受ける層。

AIコーディングエージェントが圧縮しやすいのは、このうちexecuteである。 一方、decideとdeliverは自動的には縮まない。 むしろ実行が安く速くなるほど、作れる候補が増え、どれを作るかの選別と、出来上がったものの検証や統合に回る仕事が増える場合がある。

ここからNarayananは、人の仕事の比重が、構築そのものから、評価、方向づけ、制御、説明責任へ移っていくと予測する。 エンジンの出力を上げる仕事よりも、どちらへ進むかを決める舵の側に労力が移る、という見立てである。

「評価が人に残る」だけでは、組織は制御できない

この予測には、著者自身の研究にもとづく観測が添えられている。 Narayananらプリンストン大学の研究チームが公開するHAL AI Agent Reliability Trackerは、複数のAIエージェントについて、タスクを解ける能力とは別に、同じタスクを安定して解けるか、入力の揺らぎに耐えられるか、自らの確信度を正しく見積もれるかを測っている。 その結果、能力の改善に比べて、こうした信頼性の改善は小幅にとどまると報告されている。 対象は特定のベンチマークとエージェント群に限られるため、すべてのAIに一般化はできない。 それでも、能力の数字が上がることと、業務を任せられることが別の問いである点は、この範囲だけでも読み取れる。

ただし、評価は、AIの出力や挙動を測るところまでしか進まない。 どのスコアなら受け入れるのか、どんな失敗なら許容するのか、どの兆候が出たら止めるのか、最終決定者は誰か。 これらは測定の結果からは出てこない。 組織が決めるほかない事柄である。

人間を承認の輪に置くだけでも足りない。 何を確認し、どの権限で承認し、何を根拠に止めるのかが定義されていなければ、人間は実質的な判断者ではなく、形式的な承認者になり得る。 緑色のボタンの前に人が座っていることと、その人が判断できる状態にあることは、別のことである。

人間に残る仕事は、能力差ではなく境界の選択で決まる

「AIにできないことは何か」を探し続けるだけでは、この状態から抜け出せない。 能力の境界は動き続けるため、そこに仕事の定義を置くと、定義のほうが際限なく動いてしまうからである。

組織が立てるべき問いは、能力の問いではなく権限の問いである。

「AIにできるか」は観測すれば分かる。 「AIに決めさせるか」は、観測からは決して出てこない。 この二つを分けることが、AI時代の組織設計の出発点になる。

既存領域の役割と、その間に残る不足

こうした問いを扱う枠組みが、すでにあるように見えるかもしれない。 それぞれの役割を確認しておく。

Governance：どのルールで監督し、誰に権限を与え、何を説明責任とするかを扱う。日本では経済産業省などがまとめたAI事業者ガイドライン（第1.2版）が代表例である（法的な義務ではなく、実務の指針である）。 DX：業務や価値提供のかたちをどう変えるかを扱う。 Automation：どの処理を機械に任せるかを扱う。 AI Ethics：守るべき価値や原則を扱う。

どれも必要であり、いずれかを否定して済む話ではない。 しかし、これらを整えても、個々の業務について、誰が目的を定め、どこまでAIへ判断を委ね、どの条件で止め、誰が結果を引き受けるかは、自動的には決まらない。 規程は判断の枠を与えるが、金曜17時40分のボタンを誰が押すかまでは指定しないからである。

欠けているのは、AIが担う実行と評価を、組織が担う目的設定、受容、停止、説明責任と、「誰が何を決めるか」という単位で結び直す設計である。

ここから先では、この欠けた設計を、AIコーディングエージェントによる本番リリースという具体例へ落とし込む。 AIに委ねる判断、人間が引き受ける判断、利用できるデータ、承認と停止の条件、例外時のエスカレーション、記録と見直しの契機を一つずつ設計し、冒頭の緑色のボタンを、誰が、どの条件で押せるのかを明らかにする。

こうして判断ごとに境界を引き直す営みが、先に述べた不足を埋める。 この営みを、Decision Design™︎と呼ぶ。 Decision Designは、判断という行為そのものを設計対象とする思想だ。 その中心にあるのが、Decision Boundary™︎という概念である。 誰が決めるのか。 どこまでを任せ、どこからを引き受けるのか。 その線を無自覚のまま放置せず、意図的に設計すること。 それがDecision Designである。

Decision Designは、何を設計するのか

Decision Designは、判断という行為そのものを設計対象とする。

設計する項目を挙げる。 何についての判断か。 判断の主体は誰か。 AIへ委ねる範囲はどこまでで、人間または組織が引き受ける範囲はどこからか。 根拠に使ってよいデータと、判断の基準。 実行へ移してよい条件と、止める条件。 例外時のエスカレーション先。 そして記録、説明責任、境界を見直す契機である。

Decision Designは、何ではないのか

Decision Designは、AI利用規程の別名ではない。 守るべき項目を並べたチェックリストでもない。 すべての判断を人間の手に戻すための思想でもなければ、AIを信用しないための概念でもない。 むしろ、安心して委ねられる範囲を広げるために、委ねない範囲を明確にする考え方である。

Decision Designは、どの問題に対する概念なのか

Decision Designが向き合うのは、次の問題である。 AIによって判断の能力が拡張され、代替され、複数の主体へ分散される一方で、判断の主体と責任の所在が曖昧になっていく。

AIが実行を速くするほど、すべての判断に人間を挟む設計は機能しにくくなる。 かといって人間を外すだけでは、結果を引き受ける主体が消える。 だから、判断の種類ごとに線を引き直す作業が要る。

Decision Boundaryは、AIと人間の能力差ではない

Decision Boundaryとは、AIに委ねる判断と、人間または組織が引き受ける判断の境界である。

この境界は、「AIにできるか」だけでは決めない。 影響の大きさ、失敗からの回復可能性、不確実性の度合い、求められる説明責任、法的および契約上の役割、利用するデータ、あとから監査できるかどうか。 これらを組み合わせて決める。

AIの能力が向上すれば、境界は動かせる。 ただし、自動的に動かすわけにはいかない。 境界を動かすことは、リスクの引き受け先を変えることであり、能力の観測だけでは、誰が新しいリスクを受容したのかが決まらないからである。 誰が境界を変更できるのか、どんな出来事があれば見直すのかも、Decision Boundaryの設計対象に含まれる。

金曜17時40分のリリース判断を設計する

冒頭の場面に、この考え方を当てはめてみる。

何を判断し、誰に影響するのか

まず、判断の対象を正確に定める。 問われているのは「AIが生成したコードが正しいか」だけではない。 「この変更を本番環境へ公開し、顧客や社内利用者へ影響を及ぼしてよいか」である。 前者はコードの性質の問いであり、後者は組織の行為の問いである。 影響が及ぶのは開発チームだけではなく、顧客、業務部門、サポートまで含まれる。

AIの役割、人間の役割、最終判断者

AIには、承認済みの仕様の範囲内でのコード生成、テストの実行、変更差分の説明、既知のリスクの検出、判断材料の整理を委ねられる。 低リスクと事前に定義された変更であれば、ステージング環境までの反映をAIに任せる設計もあり得る。

本番リリースの最終判断者は、そのサービスに対する説明責任を持つ人間のサービスオーナーとする。 ただし、これは「毎回人間がボタンを押す」ことを意味しない。 一定の低リスク変更について、サービスオーナーが事前に承認した条件の範囲内で自動リリースを認める設計も可能である。 このとき判断しているのは、その条件を承認したサービスオーナーである。 誰がどの条件で自動実行を許可したのかが残っていれば、自動化は責任の消失ではなく、責任の事前配置になる。

使えるデータ、採用の条件、止める条件

AIが根拠に使える情報は、承認済みのリポジトリ、仕様書、テスト環境、脆弱性情報などに限定する。

変更を採用する条件には、要求との対応関係を追跡できること、テストの結果、変更範囲の狭さ、ロールバックできること、必要なセキュリティ確認を通過していることを含める。

同じくらい大切なのが、止める条件である。 認証、権限、決済、個人データ、データベース構造、公開API、セキュリティ制御に関わる変更が含まれるとき。 要求の解釈に曖昧さが残るとき。 指示していないファイルへの変更が現れたとき。 これらに該当したら、AIは処理を先へ進めない。 変更行数などの数値の閾値を置く場合、それは各社がリスクに応じて定める例であって、普遍的な基準ではない。

例外時のエスカレーション

停止条件に該当したとき、AIは変更内容と不確実な点を整理して、あらかじめ定めた主体へ引き渡す。 仕様の解釈に関わる例外はサービスオーナーへ、セキュリティに関わる例外はセキュリティ責任者へ、業務影響に関わる例外は業務責任者へ、という対応づけまで決めておく。 「分からないときは人に聞く」という指示だけでは、金曜の夕方に誰も捕まらず、例外が月曜まで放置されるか、誰かが根拠なく承認するかのどちらかに流れやすい。

記録と説明責任、境界を見直す契機

記録には、使用したモデルとバージョン、参照したデータ、与えた指示、ツールの操作、生成された差分、テスト結果、AIが示した不確実性、人間の承認理由、実行時刻を含める。 この記録は、障害が起きたときに「なぜこの変更が本番に出たのか」を組織として説明するための土台になる。

そして、境界は一度引いて終わりではない。 インシデント、新しい失敗パターンの発見、モデルの変更、業務の変更、法令や契約の変更、評価結果の悪化。 これらをDecision Boundaryを見直す契機として、あらかじめ定めておく。

評価は境界を支えるが、境界そのものではない

AIエージェントの評価は、どこまでを委ねられるかを判断するための最も具体的な材料である。 信頼性の測定が進むほど、境界は根拠を持って引けるようになる。

しかし、評価スコアは、誰がリスクを受容し、誰が最終決定を下すかを決めてくれない。 スコアが示すのは過去の挙動の統計であり、リスクの引き受けは将来に対する組織の約束だからである。 能力、信頼性、判断権限、説明責任。 この四つを混同させないことが、Decision Designの役割である。

緑色のボタンの問いに戻る

金曜日の17時40分に戻ろう。

緑色のボタンを押すのが人間だから、この組織は制御できているのではない。 何を確認し、どの条件なら実行し、どの条件なら止め、結果を誰が引き受けるか。 それがボタンを押す前に設計されているとき、はじめて制御できていると言える。 設計があれば、ボタンの一部をAIに委ねても制御は失われないし、設計がなければ、人間が毎回押していても制御は成立しない。

AI時代に人間へ残る仕事は、AIが苦手な仕事の一覧ではない。 どの判断をAIへ委ね、どの判断を自らの責任として引き受けるかを、組織が選び続けることで形づくられる。

Narayananの講演のタイトル「What will be left for us to work on?（私たちに残る仕事は何か）」への、本稿の答えはこうだ。 人間に何が残るかは、AI企業の研究室だけで決まるのではない。 何をAIへ渡し、何を自分たちの判断として引き受けるかを設計する、組織の側でも決まる。

FAQ

AIコーディングエージェントを導入すると、結局すべてのリリースに人間の承認が必要になるのですか。 そうとは限りません。サービスオーナーが事前に承認した条件の範囲内なら、自動リリースも設計できます。要点は、誰がどの条件で自動実行を許可したのかが明確で、記録に残っていることです。

Decision Boundaryは、AIの性能が上がったら広げてよいのですか。 広げられますが、性能の観測だけを理由に自動では広げません。境界の変更はリスクの引き受け先の変更なので、誰が変更を承認し、何があれば見直すのかまで設計しておく必要があります。

評価ベンチマークで高いスコアのエージェントなら、任せてよいのですか。 スコアは委任の範囲を決める材料ですが、それだけでは決まりません。公開されている信頼性評価でも、能力の改善に比べて安定性の改善は小幅と報告されており、評価の対象範囲も限られます。自社の業務での影響の大きさと回復可能性を踏まえ、リスクを受容する主体を決めることが先です。

参考資料

Read the original English analysis (English) →note版を開く →