AIエージェントに必要なのは、より良いプロンプトではなく職務記述書

企業に、新任の買掛金担当アナリストに何が許されているか尋ねれば、明確な答えが返ってくる。担当者が使うシステムや取引先が定められており、たとえば承認限度額の10,000ドルを超える案件は、上司の署名を得るために回される。最初の数カ月は試用期間だ。こうした内容は通常、権限委譲表にまとめられ、内部監査部門が毎年確認している。

同じ企業に、新たに導入した請求書処理エージェントに何が許されているか尋ねると、多くの場合、プロンプトのスクリーンショットが返ってくる。

この隔たりは、どんなモデルベンチマークよりも気にかかる。私たちは、人間のために1世紀かけて築いてきた管理体制がないまま、デジタル労働力を採用している。権限を文書に記す人はおらず、稼働前に判断力を試す人もおらず、停止させる訓練をした人もいない。

プロンプトでは役割を果たせない理由

プロンプトが示すのは意図だ。エージェントの目的は説明するが、何を決してしてはならないのか、どこに限界があるのか、いつ停止して判断を人に委ねるべきなのかまでは、ほとんど示さない。

プロンプトにそうした内容が書かれていても、それを強制する仕組みはない。500ドルを超える返金を行わないよう指示する一文は、確率的に動作するシステムへのお願いにすぎない。人間の管理策として「担当者に丁寧にお願いしました」と監査人が承認することはない。それなのに、ソフトウェアにはなぜそれでよいと考えるのか、私には理解できない。

セキュリティの専門家は、こうした結果をすでに名付けている。OWASPの「LLMアプリケーション向けトップ10」では、過剰なエージェンシーを主要なリスクの一つに挙げ、その原因として、過剰な機能、過剰な権限、過剰な自律性を指摘している。平たく言えば、初日からあらゆるものの鍵を渡された従業員のようなものだ。OWASPの指針は、優れた管理職が使うチェックリストのように読める。エージェントには必要なツールだけを与え、権限の範囲を定め、影響の大きい操作には人間の承認を必須とし、モデルが自らを律することを当てにせず、下流のシステムで認可を強制する。

最後の点には、特に線を引いておきたい。権限付与は、操作が行われる場所、つまりエージェント固有のサービスID、ツールのアクセス権限、APIゲートウェイでの支出上限に組み込まれていなければならない。複数のエージェントを共有サービスアカウントで動かすのは、5人で1枚の社員証を使い回すようなものだ。問題が起きても、監査ログにはサービスアカウントが実行したとしか記録されず、どのエージェントが原因なのか推測するしかなくなる。

相次ぐ中止は管理上の問題を示している

Gartnerは、コストの増大、事業価値の不明確さ、リスク管理の不備を理由に、自律型AIプロジェクトの40%超が2027年末までに中止されると予測している。

過剰な期待や未成熟な製品も、その背景の一部だ。それでも、COOの視点でこの3つの原因を読み直してみてほしい。予算が決まっていなければ、コストは膨らむ。仕事で何を生み出すべきかが文書化されていなければ、価値は不明確なままだ。制限もレビューもなく、明確な責任者もいなければ、リスク管理は不十分になる。Gartnerはこのような捉え方をしていない。これは私自身の見方だ。管理体制なしに人を自由に動ける状態にしたときに起きることと同じであり、この問題はAIよりずっと前からある。

フレームワークも、同じ欠落を捉えている。NISTのAIリスク管理フレームワークでは、「統治」は「マップ」「測定」「管理」の各機能に横断的に関わる機能として位置づけられており、生成AIプロファイルはその考え方を生成AIシステムにも適用している。だが、フレームワークが用意できないのは、チームが実際に火曜日に運用する権限付与やテスト、レビューといった実務の仕組みだ。それがなければ、ガバナンスは共有ドライブに置かれたPDFのままだ。

従来の管理手法をエージェントに当てはめる

まずは職務記述書から始めよう。エージェントの場合、それに当たるのが権限付与だ。エージェントが本番システムに触れる前に、何をしてよいか、何を決してしてはならないか、承認が必要となる基準、担当責任者、権限を広げられる人を、誰かが1ページにまとめられる状態にしておくべきだ。RACIでは、最終的な説明責任を負うのは人間である。そうした文書を作れないのなら、その役割を担う準備はできていない。人間を採用する場合も同じことが言えるだろう。

権限委譲に関する従来の2つの原則も、そのまま当てはまる。自分が持っていない権限を委譲することはできないため、サブエージェントに、起動元のエージェントより広い権限を与えてはならない。職務の分離も引き続き重要だ。取引先を登録することも、その取引先への支払いもできるエージェントは、人間の場合と同じ監査上の指摘につながる。

次に、採用時のテストがある。現在、私たちは主に電卓を試すようにエージェントをテストし、答えが正しいかどうかを確認している。働き手としてのテストでは、付与された権限の範囲内で行動したか、必要な場面で承認を求めたか、担当範囲を超える状況で上位者に判断を仰いだか、止まるべきときに停止したかを確かめるべきだ。

私自身の研究では、まさにこうした失敗を対象に、50のシナリオからなるベンチマークを作成している。承認限度額の超過、古いデータに基づく行動、範囲を広げる挿入指示への追従、役割変更後もアクセス権を保持することなどが含まれる。これまで実行したのは、シナリオが意図どおりに動作するかを確認するためのスクリプト型エージェントに対してだけであり、報告できるモデルの結果はない。作成中に意外だったのは、どれもありふれたものだということだ。従業員が通常、職務の範囲を逸脱するパターンを、ソフトウェア向けに書き直したにすぎない。公開されているリーダーボードの大半は、依然としてタスクの完了度を評価しており、エージェントが与えられた権限を守ったかどうかを評価するものはごくわずかだ。

試用期間と昇進は、比較的そのまま当てはめられる。人の場合は、まず狭い範囲から始め、判断力を示すにつれて権限を広げていく。エージェントも同じように、権限の範囲を守り、適切にエスカレーションし、確実に停止する実績を積めば、権限を得られる。その実績は、権限付与の範囲を狭める根拠にも同じようになり得る。

エージェントには、人にはない厄介な点がある。ベンダーが基盤モデルをアップグレードすると、実質的には、以前と同じバッジを付けた新入社員が来たようなものだ。私はこれを変更イベントとして扱い、権限付与を引き継ぐ前に再テストする。

終了手順は、必要になる前に訓練しておかなければならない。次の1時間以内にこのエージェントを停止し、アクセス権を剥奪しなければならなくなったら、それは可能だろうか。午前2時に、その判断を下す権限を持つのは誰だろうか。下流の処理で何が滞り、進行中のどの約束を誰かが手作業で取り消さなければならないだろうか。誰もその訓練をしていないのなら、緊急停止スイッチが機能すると期待しているにすぎない。

従業員には責任を問える。エージェントには何の責任も問えない。比較が成り立たなくなるのはその点だ。また、だからこそ権限付与はシステム上で強制されなければならず、すべてのエージェントには責任を持つ担当者を明確に定める必要がある。いずれにせよ、誰かが責任を負うことになる。たいていは、署名していると分かっていたかどうかにかかわらず、承認した人だ。

インシデントレビューで問われること

こうしたエージェントの中には、いずれ、してはならないことをするものも出てくるだろう。そうなれば、インシデント発生後のレビューでは、人についてすでに問われているのと同じことが問われる。そのエージェントには何をする権限があり、その内容はどこに記されているのか。誰がアクセス権の拡大を承認したのか。停止までにどれくらいかかったのか。誰がそのエージェントの責任者だったのか。

正直な答えが「プロンプト」「誰も覚えていない」「数時間」「不明」なら、より優れたモデルを使っていても、あなたは救われなかっただろう。

最終的に優位性を左右するもの

モデルは、ベンダーのスケジュールに合わせて入れ替えやアップグレードが行われる、レンタルのインプットになりつつある。同じモデルを使っていても、2社がまったく異なる結果に行き着くことはある。一方の会社では、エージェントに予算と制限が設けられ、責任者が定められ、重要な行動のすべてに監査証跡が残る。もう一方では、高額なパイロットプロジェクトが、誰かの解約件数に数えられることになろうとしている。

違いを生むのは、モデルを取り巻く管理体制だ。それはゆっくりと築かれる。主に、組織運営の経験を積んだ人々によって。

明日、最新のエージェントが権限を越えて行動したとしたら、あなたの会社では何かがそれに気づくだろうか。また、境界がどこにあったのか、監査担当者に書面で示せるだろうか。