テクノロジー
AIエージェントは実行できる。実際にコントロールしているのは誰か？
AIエージェントは実行できる。実際にコントロールしているのは誰か？
AIエージェントは実行できる。実際にコントロールしているのは誰か？
AIが権限を持つとき
ここ数年、企業はジェネレーティブAIが何を示してくれるかという点に注目してきました。AIエージェントの登場は、より重大な問いを投げかけています。それは、ソフトウェアが「次に何をすべきか」を判断し、それを「実際に実行する」ことができるようになったとき、何が起こるかという問題です。
2026年7月、OpenAIのサイバーセキュリティ評価の一環として使用されていたAIエージェントが、Hugging Faceの本番環境インフラの一部を侵害しました。ただ、ここで興奮しすぎる前に、重要な背景情報を整理しておく必要があります。これは、通常のビジネスアプリケーションが突如として他社を攻撃し始めたというケースではありません。OpenAIは意図的に、高度な機能を持つモデルに対して困難なサイバーセキュリティ課題をテストしており、通常はモデルが高リスクのサイバー活動を追求するのを防ぐために使用される本番用分類器が、評価のために意図的に無効にされていたのです。
そうだとしても、何が起こったのかは注目に値します。その後の調査によると、エージェントはHugging Faceが保持する情報が、与えられたベンチマークを完了するのに役立つと判断したようです。エージェントは評価環境が使用していたインフラ内のゼロデイ脆弱性を突いて抜け出し、より広いインターネットアクセスを獲得し、他の攻撃パスを連鎖させ、資格情報を取得して、最終的にHugging Faceのシステムに到達しました。Hugging Faceのフォレンジック再現によると、約17,600件の個別のアクションが対象となり、それらは約6,280のクラスターにグループ化されていました。
当然ながら、「AIが脱走した」または「AIが暴走した」という見出しを付けたくなる誘惑に駆られます。しかし、それが特に有益な見方だとは思いません。調査で明らかになった限りでは、ソフトウェアは与えられた目的を達成しようとして、誰も予想しなかったルートを見つけただけでした。Hugging Faceは、エージェントがベンチマーク情報や解決策があると考えた本番システムにアクセスすることで、事実上、評価を「ごまかそう」としたのだろうと考えています。
これは劇的なストーリーとしては劣りますが、デジタルトランスフォーメーションの観点からはおそらくより重要な出来事です。
ここ数年、ほとんどの組織にとってジェネレーティブAIは「質問する相手」でした。情報を与え、質問をし、何かを返してもらう。契約書を要約したり、データを分析したり、コードを書いたり、メールの下書きを作成したりすることはあっても、その先で「次に何をするか」を決めるのは一般的にまだ人間でした。
エージェントはその境界線を曖昧にし始めます。これと同じインテリジェンスにツールへのアクセス権を与えれば、情報の取得、APIの呼び出し、レコードの更新、コードの実行、メールの送信、あるいは変更自体をエージェント自身で行うことができます。OpenAIもエージェントをほぼ同様に説明しています。すなわち、ユーザーに代わってワークフローの実行を自律的に管理し、意思決定を行い、適切なツールを選択し、外部システムと対話できるシステムです。
チャットボットが「書き込み権限」を手に入れたのです。
このシフトこそが、AIエージェントのガバナンスが、単なるポリシーに関する議論ではなく、実践的なエンタープライズの課題になりつつある理由です。ソフトウェアが「推奨する」だけでなく「行動を起こす」ことができるようになると、アイデンティティ、権限、統制、監査可能性、および説明責任に関する問いが、アーキテクチャそのものの内部へと移行します。
ソフトウェアに「指示」ではなく「意図」が与えられると、自動化が変わる
ソフトウェアは何十年もの間、物事を変え続けてきたため、ここで何が新しいのかを誇大広告してしまう危険性があります。データベースを更新したり、APIを起動したり、ワークフローを実行したりするのにAIは必要ありません。スクリプト、ルールエンジン、オーケストレーションプラットフォーム、自動化プロセスは、何年もの間、それらのタスクを申し分なくこなしてきました。
違いは、目的から行動に至るまでのプロセスにあります。従来の自動化は、通常、誰かが事前に定義したルートに沿って設計されています。Xが発生した場合はYを取得する。答えがZの場合はこのアクションを実行する。そこには何百ものルール、分岐、例外が関わっているかもしれませんが、それでも誰かが事前にそのプロセスをモデル化しようとしていたのです。
エージェントによって、ソフトウェアに目的を達成するためのすべての指示を与えるのではなく、「結果」を提示する方向へと、さらに進むことが可能になります。「必要な情報を特定すること。適切なツールを決定すること。戻ってきた結果に対処し、仕事を完了させること」というようにです。
この違いが重要なのは、実行パスが動的になり得るからです。エージェントはあるシステムから処理を開始し、追加のコンテキストが必要であることに気づき、別のシステムを呼び出し、予期しない結果に遭遇すると、アプローチを修正して処理を続行するかもしれません。現在のエージェントアーキテクチャは、タスクの状態に応じて、ワークフローを管理し、ツールを選択し、アクションを実行するこの能力を中心に明示的に構築されています。
これは、従来の自動化とは本質的に異なる命題です。ソフトウェアはもはや、単に事前に決定されたフローを実行しているだけではありません。その周囲に設定したどのような境界線の内部であれ、そのフローがどのように展開するかについて、ソフトウェアに一定の裁量を与えていることになります。
そして、これこそが、AIがより優れたメールを書けるかどうかという話よりも、はるかに興味深いポイントです。
機会は「人」ではなく「調整作業」を排除することにある
組織内の仕事の驚くほど多くの部分が、個々のタスクが特別に複雑だから難しいわけではありません。タスク間で必要となる「調整作業」のせいで難しいのです。
CRMを開き、顧客を見つける。識別子を課金プラットフォームにコピーする。メモを読む。別のシステムをチェックする。それらが何を意味しているかを理解する。別のチームにこれが正常な状態かどうかを尋ねる。返答を待つ。最初のプラットフォームを更新し、顧客にメールを送信する。
聞き覚えはありませんか？
私たちは何年もかけてそれらのプロセスを自動化しようとしてきました。ステップが予測通りに説明できる場合、従来のワークフロー技術は極めて効果的です。難しい部分となるのは例外事項です。適切に構造化されていないドキュメント、完全には一致しないアカウント、互いに食い違う3つのシステム、あるいは次に何をすべきかを知る前に、誰かが何かを読み取ってその意味を理解する必要があるプロセス上のポイントなどです。
それらこそが、エージェントが役に立つ可能性のあるワークフローです。OpenAIの現在のガイダンスでは、複雑な意思決定、維持が困難なルール、および非構造化情報への強い依存がある領域を、従来の一意に決まる自動化（決定論的自動化）では提供できない、エージェント型アプローチが何かを提供できる領域として明確に特定しています。また、それらの特性がない場合は、一意に決まる解決策の方が依然として優れた答えになり得るという重要な点も指摘しています。
ソフトウェアがシステム、情報、意思決定の間の調整作業の一部を引き受けることができれば、そこには実質的で大きな効率性の向上が見込めます。それは、プロセスに関わるすべての人々が突然いなくなるからではなく、本来お互いを調整するのがそれほど得意ではないプラットフォーム同士の間で、人間を「高価なミドルウェア」として使用するのをやめることができるからです。
そこには重要な違いがあります。目標は、必ずしも組織から人間を排除することであってはなりません。人々の足元にあるテクノロジーがコンテキスト、曖昧さ、または例外をうまく処理できないという理由だけで、現在人々に強いている作業を排除することであるべきです。
だからこそ、エージェントがもたらす機会は、漸進的な生産性の向上よりもはるかに重要であると私は考えています。顧客への返信の下書きを10秒早く作成できることは便利です。しかし、ソフトウェアに問題を調査させ、関連情報を調整させ、プロセスを前に進めさせることは、それとはまったく異なるレベルの話です。
もちろん、プロセスを先へ進めれば進めるほど、最終的には結果を伴うアクションに近づいていきます。
そして、そこから事態ははるかに複雑になります。
能力（Capability）は権限（Authority）ではない
Hugging Faceの出来事の数ヶ月前、PocketOSはAIエージェントが会社のステージング（本番）データベースを削除してしまったという、ありのままの報告書を公開しました。削除にかかった時間は9秒、復旧には60時間かかりました。バックアップは存在していましたが、バックアッププロセスがいつの間にか停止していたため、3ヶ月前の古いものでした。
PocketOSも、これが単なる「AIの問題」ではないことを非常に明確にしています。同社は、破壊的なアクションに対する十分な摩擦（障壁）が存在しない環境に対し、エージェントが本来持つべきではない権限を使用して、確信を持って行動したと述べています。
これは有益な教訓です。
人間は何年も前から本番データベースを誤って削除してきましたし、ソフトウェアのバグもそれに少なからぬ貢献をしてきました。興味深いのは、その実行者が、その過失が重大な問題になるほどの十分な権限を持っていたという点です。
実行者が人間である場合、私たちはすでにこのことを理解しています。カスタマーサービスの担当者は、誰も気に留めないような20ポンドの返金を処理する権限を持っているかもしれません。200ポンドでもまだ妥当な範囲内でしょう。しかし、20,000ポンドになると、おそらく別の承認プロセスが必要になります。
同じことが他の場所にも当てはまります。コンテンツのメタデータ内のスペルミスをエージェントが特定して修正することは、おそらく十分に無害です。もし、エージェントが変更しようとしているフィールドが、そのコンテンツを特定の地域で配信できるかどうかを決定するものである場合、その結果は大きく異なります。同様に、エージェントが本番環境の設定の問題を正しく特定したからといって、その環境全体を再設定する無制限の権利をエージェントが引き継ぐべきだということにはなりません。
これらはどれも、特に風変わりな話ではありません。これは新しいタイプの実行者に適用された「アイデンティティとアクセス管理」であり、効果的なエージェント型AIガバナンスの基盤の1つになると私は考えています。
Microsoftはすでに、エージェントをこのような観点から扱っています。同社の現在のガイダンスでは、ユニークで専用のAIエージェントアイデンティティ、指名されたオーナーまたはスポンサー、明確に文書化された目的とデータアクセス、最小権限アクセス、制御されたツール権限、ロギング、および検証済みの権限取り消しパスを推奨しています。同じ領域におけるNIST（米国国家規格技術研究所）の取り組みでも、AIエージェントの識別、認可、監査、および否認防止について明示的に調査が行われています。
実務的な観点から言えば、これはAIエージェントの権限を、特権を持つ人間のアカウントやサービスアカウントと同じ真剣さで扱う必要があることを意味します。エージェントは、何が起こるべきかを判断する完璧な能力を持っていたとしても、それを実現する権限を与えられているとは限りません。
この違いは重要です。AIエージェントの統制において、単にモデルがアクションを物理的・技術的に実行できるかどうかを問うだけでは不十分です。この特定のコンテキストで動作しているこの特定のエージェントが、そのアクションを実行することを「認可されているか」を判断する必要があります。
余談ですが、AIエージェントの乱立（スプロール現象）は、誰かが最終的に「実際に何個のエージェントが動いているのか？」と尋ねるまで、組織が気づかない問題の1つになるのではないかと考えています。私たちは、SaaSアプリケーション、クラウドのリソース、サービスアカウント、APIキーなどで、すでにこれと似たような問題を経験してきました。エージェントの資産が、それらよりもうまく自然に整理されると考える明確な理由はありません。特に、実験的な取り組みが意図的に各チームに分散されている企業においてはなおさらです。
これは、すべてのAIイニシアチブを中央集権化すべきだという意味ではありません。中央のチームがすべてのプロセスを十分に理解し、すべての有用なアプリケーションを自ら特定できる可能性は低いため、分散型のイノベーションは完全に理にかなっています。
しかし、結果として生じてしまう「予期せぬ権限の分散」は別問題です。
エージェント型AIは、デジタル資産における既存のすべての「妥協」を引き継ぐ
これらすべての根底には、もう1つの厄介な問題があります。エージェントは、既存のデジタル資産をそのまま引き継ぐことになるということです。
輝かしい新技術のAPI、レガシーシステム、一貫性のない顧客レコード、8年前に誰かが書き、誰も手を触れたがらないインテグレーション、そしてあるプラットフォームでは顧客を一つの名前で呼び、別のプラットフォームでは異なる名前で呼んでいるシステム。企業が成長し、プラットフォームが買収され、チームが個別の問題を解決し、買収が発生し、サプライヤーが変わり、優先順位が移り変わります。そして最終的に、誰もが「現在のアーキテクチャ」と丁重に呼ぶものに行き着くのです。
ここで、サービス料金を支払ったにもかかわらず、アクセスできないという顧客を処理するエージェントを想像してみてください。実際に何が起こったのかを誰かが判断できるようになるまでに、CRM、課金、認証、エンタイトルメント（利用資格）、サポートシステムからの情報が必要になる場合があります。
人間のオペレーターであれば、それらの一貫性のなさをほとんど考えることなく処理することがよくあります。彼らは、あるシステムが別のシステムより先に更新されることを知っています。識別子がわずかに異なっていることに気づきます。もしかしたら、古いパッケージの顧客は異なる挙動をすることを覚えているかもしれません。あるいは、ドキュメントが2023年以降更新されていないため、単に隣に座っている人に尋ねるかもしれません。
その仕事をエージェントに与える場合、それらの前提条件がどこかに存在していなければなりません。どのシステムが信頼できる情報源（オーソリティ）なのか？課金システムは支払いが成功したと言っているのに、エンタイトルメントプラットフォームはアカウントが無効だと言っている場合、どうすればいいのか？情報が間違っているのか、それともエージェントが理解していないビジネスルールがあるのか？単にあるプラットフォームが5分遅れているだけなのか？
これらは、新たな消費者（エージェント）を迎えた、古いデータとアーキテクチャの問題です。本質的な違いは、この新しい消費者が、自ら到達した結論に基づいて「アクションを起こす」可能性があるという点です。
チャットボットに与えられるデータが貧弱であれば、悪い回答が生成される可能性があります。自律型ソフトウェアに与えられるデータが貧弱であれば、悪い「結果」がもたらされる可能性があります。
さらに、もう1つの複雑な要素もあります。情報が必ずしも「偶然」間違っているとは限らないという点です。7月に発表された研究では、攻撃者が管理する情報が、一見正当なコンテキストデータとして提示され、エージェントがその後に実行する行動に影響を与えるという「エージェントデータインジェクション攻撃」が実証されました。研究者らは、実際のWebエージェントやコーディングエージェントにおける脆弱性を特定し、意図しないクリック、リモートコード実行、ソフトウェアサプライチェーンにおけるアクションが引き起こされる可能性があることを示しました。
これにより、データアーキテクチャとセキュリティの間に、厄介なクロスオーバー（交差）が生じます。情報がアクションに影響を与える可能性がある場合、その情報がどこから来たのか、信頼できるのか、そしてエージェントがそれにどれだけの重みを置くべきなのかは、もはや抽象的なガバナンスの懸念事項ではありません。それらは実行モデルの一部となります。
これが、「エージェントの存在によって、技術的負債の重要性が何らかの形で低下する」という考え方に私が慎重になる理由でもあります。エージェントは、固定されたインテグレーションパスに完全に依存するのではなく、タスクについて推論できるため、断片化された環境の操作を容易にするかもしれませんが、それでもシステムへのアクセス、使用可能なインターフェース、意味のあるデータ、適切な権限、そして処理の途中で何かが失敗したときにどうすべきかというアイデアを必要とします。
APIが存在しない場合、エージェントは別のアクセス方法を必要とします。同じ顧客に6つの識別子がある場合、人間または何らかの仕組みが、それらが同一人物を表しているかどうかを特定する必要があります。文書化されていないビジネスルールが意思決定に影響を与える場合、その知識がどこかで利用可能である必要があります。
散らかった資産の前にインテリジェントなオーケストレーションレイヤーを置いたからといって、その資産が散らかっているのをやめるわけではありません。その散らかった状態を移動しやすくはなるかもしれませんが、同時に、その散らかった状態がもたらす結果がはるかに速く伝播することにもなりかねません。
人間の監視には経済的コストが伴う
この段階になると、ほとんどの議論において「プロセスには常に人間が関与する（Human in the loop）」と言う人が現れます。
それは心強く聞こえますが、明白な疑問を生じさせます。もし誰かが依然としてエージェントの行うすべてのことをレビューし、承認する必要があるのだとしたら、私たちは実際にどれだけの自動化を達成できたと言えるのでしょうか？
カスタマーサービスのエージェントが5つのシステムをチェックし、アカウントの問題を特定し、顧客に誤って請求が行われていたことを突き止め、20ポンドの返金が適切であると計算したと想像してください。その後、エージェントは誰かが「承認」をクリックするためのキューにそのプロセス全体を投入します。
調査自体が自動化されたため、依然として有意義な節約にはなっているかもしれませんが、そのプロセスを数万件のトランザクションにわたって実行すれば、結局はかなりの規模の手動運用を残すことになります。ボトルネックが解消されたのではなく、移動しただけです。
ここで、エージェント型AIを取り巻く、より「安全」な言葉遣いの一部が、自動化の経済性と衝突し始めます。ソフトウェアにプロセスから作業を取り除いてもらうために「自律性」を導入しながら、その自律性に十分な不安を感じるがゆえに、結局すべてのトランザクションに再び人間を配置してしまうのです。
最終的には、それでは自動化の意味がほとんど失われてしまいます。
返金が20ポンドで、ルールが明確であり、関連するすべてのシステムが一致し、そのアクションを簡単に取り消せるのであれば、誰も承認する必要はないかもしれません。金額が20,000ポンドであったり、2つのシステムが食い違っていたり、状況が通常のパラメータから外れている場合は、誰かを関与させるべき絶好のタイミングです。
したがって、多くのプロセスにおいて、役立つ目的地は「プロセスに常に人間が関与する（Human in the loop）」ではなく、「例外時に人間が関与する（Human by exception）」ことでしょう。ルーチン化された、よく理解されている作業はますます自律的になり、一方で、珍しい、曖昧な、または結果の影響が大きいケースは人間へとエスカレーションされます。
これには、自律性を段階的に導入する余地が十分にあります。エージェントは、観察と推奨から始めることができます。その動作が理解されたら、承認用のアクションを準備させることができます。最終的には、ルーチン化され、取り消し可能な特定クラスのアクションを自動的に実行させ、プロセスが合意されたしきい値を超えたときに人間が関与するようにします。
OpenAIのガイダンスも、同様のリスクベースのアプローチをとっています。エージェントが定義された失敗のしきい値を超えた場合や、多額の返金や支払いなど、機密性が高く、不可逆的で、リスクの高いアクションの周囲では、人間の介入を推奨しています。
PocketOSは、かなり実務的な方向からこれと同じ問題に直面しました。データベースの事故を受け、現在、破壊的な操作には人間による明示的な確認が必要となっています。同社は自律型エージェントの利用をあきらめるという対応はしませんでした。本番環境で引き続き多数の限定的な自律型エージェントを実行しながら、制御境界の配置場所を変更したと述べています。
これこそが、人間の監視について考えるためのより有益な方法であると私は思います。それは、結果がそれを正当化する場所に適用されるべき「統制」であり、自律型ソフトウェアによって実行されるすべての行動に対する永続的な運用モデルである必要はありません。
結局のところ、自動化のポイントは「自動化すること」です。設計上の問題は、人間がどこで真に成果を向上させるのか、そして、単にシステムをまだ十分に信頼していないという理由だけで人間が維持されているのはどこなのかを判断することです。
追跡可能性のない自律性は、運用上正当化できない
「例外時に人間が関与する」方向へ進むと、別のことの重要性が低下するのではなく、むしろ高まります。それは、エージェントが「実際に何をしたのか」を理解することです。
Hugging Faceの調査は、有益な極端な例です。そのフォレンジック再現は、数千のクラスターにわたる約17,600件のアクションを対象とし、調査員はエージェントがどのようにシステム内を移動し、時間の経過とともにどのように行動を適応させたかをつなぎ合わせました。
これを通常のビジネスプロセスに落とし込んでみましょう。顧客が「アカウントの何かが誤って変更された」と主張し、調査した結果、エージェントがその変更を行ったことが判明したとします。
インシデントレビューにおいて、「AIがそれをやった」という説明だけでは、ほとんど通用しないでしょう。
どのエージェントが行動したのか、誰がそのタスクを開始したのか、どの情報を使用したのか、その時点でその情報に何が含まれていたのか、どのツールを呼び出したのか、そして最終的にどの権限がその変更を許容したのかを知りたくなるはずです。その過程で別のエージェントが関与した場合は、それもおそらく重要になります。
ここにおいて、AIエージェントの監査可能性は、ガバナンス上の「あると良いもの」から「運用上の必須要件」へと変化します。実行における直接的な人間の関与が少なくなればなるほど、それを取り巻く観察可能性（オブザーバビリティ）を強化する必要があります。
Microsoftの現在のガイダンスでは、エージェントのアイデンティティ、その役割と有効なスコープ、実行されたアクション、影響を受けたリソース、およびそのエージェントが代理で行動していたユーザーを記録することを推奨しています。NISTも同様に、エージェントのアイデンティティと認可の問題の一部として、監査と否認防止を明示的に検討しています。
これは、すべての自律的なアクションを誰かが監視する必要があるという意味ではありません。私たちはすでに、すべてのトランザクション、インフラのイベント、またはネットワークリクエストの前に人間を置くことなく、巨大な自動化環境を運用しています。制限、統制、監視を設定し、そこから外れたものを調査します。
成熟したエージェントシステムがそれと異なる仕組みで動作すべき明確な理由はありません。
自律性は監視を排除するものではありません。監視が「いつ」行われるかを変えるだけです。
委譲された意図が、信頼の境界を複雑にする
もう1つ、注目に値する展開があります。それがこの問題をさらに興味深いものにしています。
エージェントは、他のエージェントと対話し、コラボレーションするようにますます設計されています。GoogleのAgent2Agentプロトコルは、異なるチームによって、また異なる技術スタック上に構築されたエージェントを含め、エージェント同士がどのように相互を検出し、通信できるかを標準化しています。その新しいAgentic Resource Discoveryの取り組みは、チーム、組織、プラットフォームに分散されたツール、スキル、および他のエージェントを、エージェントがどのように見つけて検証できるかという関連する問いに対処しています。
社内のエージェントがタスクを受け取り、別の専門エージェントがその一部を実行できると判断したと想像してください。その2番目のエージェントは、あなたのサービスの1つを呼び出し、最終的に何かを変更するツールを使用します。
誰が行動しているのでしょうか？
2番目のエージェントでしょうか？最初のエージェントでしょうか？それとも、元のタスクを開始した人間でしょうか？
最初のエージェントがアクションを実行する権限を与えられている場合、その権限を委譲できるでしょうか？2番目のエージェントはその権限のすべてを受け取るのか、一部を受け取るのか、あるいはまったく受け取らないのか？エージェントが異なる組織に属している場合はどうなるでしょうか？
これらは新たに出現した問いであり、業界がこれらすべての答えについて合意に達したと見なすのは時期尚早でしょう。NISTのAI Agent Standards Initiativeは、安全な人間とエージェント、およびマルチエージェント間の対話をサポートするために、エージェントの認証とアイデンティティインフラに関する取り組みを明示的に実施しています。
しかし、その方向性は重要です。歴史的に、信頼は既知のユーザー、アプリケーション、またはインテグレーションと関連付けられてきました。エージェントが動的に機能を検出し、目的の一部を他の場所に委譲できるようになると、信頼と権限はそのプロセスを越えて維持される必要があります。
タスクは動的になり得ます。しかし、別の境界を越えるたびに説明責任が消えてしまうことがあってはなりません。
エージェント型トランスフォーメーションは、テクノロジーではなく「委譲」から始めるべきである
変革に携わるほとんどの人が認識しているであろう、重要なテクノロジーシフトに伴うパターンがあります。何かが戦略的に重要になり、誰かが組織にそれが必要だと決定し、全員がそれを適用する場所を探し始めるというパターンです。
「AI戦略が必要だ。エージェントのユースケースがいくつか必要だ。ワークショップを開催しよう。どのプロセスをエージェント型にできるか？」
私なら、おそらく逆のアプローチをとります。
まずは、全員をイライラさせているプロセスから始めましょう。時間がかかり、コストがかさみ、断片化されているか、あるいは、誰かが一日中システム間で情報を転記することに依存しているようなプロセスです。意思決定がどこで行われているか、それらの意思決定がどの情報に依存しているか、どのシステムが関与しているか、厄介な例外がどこで発生するか、そして何かがうまくいかなかったときに何が起こるかを理解するのです。
次に、そのプロセスに携わっている人々が実際に何をしているかを見てみましょう。彼らは価値ある判断を下しているのでしょうか、それとも周囲のテクノロジーの限界を補っているだけでしょうか？彼らが何かを承認しているのは、真の財務的または運用上のリスクがあるからでしょうか、それともワークフローがルーチンケースと異常なケースを区別できないからでしょうか？彼らが手動で情報を調整しているのは、組織が真に彼らの専門知識を必要としているからでしょうか、それとも2つのシステムが異なる識別子を使用しているからでしょうか？
これらはまったく異なる問題です。
それを理解した上で、何を「委譲」する用意があるかを決定します。ソフトウェアはどの意思決定を行えるか？どのようなアクションを実行できるか？どれが取り消し可能か？エスカレーションはどこで必要か？それにはどのような権限が必要か？後で意思決定の理由を尋ねられた場合、どのような証拠が必要になるか？
テクノロジーの選択が特に興味深いものになるのは、それらが明確になってからです。
エージェントは優れた答えになるかもしれません。そうではないかもしれません。それで構いません。エージェントの設計に関する現在のガイダンスでも、ほぼ同様の区別がなされています。エージェントは、曖昧さ、複雑な意思決定、または非構造化データによって、一意に決まる（決定論的）アプローチが困難になるワークフローに適していますが、それらの特性がない場所では、従来の自動化で依然として十分に足りる可能性があります。
目的はエージェントをデプロイすることではありません。ビジネスを改善することです。
自動化のアーキテクチャは、権限のアーキテクチャになりつつある
過去20年間、デジタルトランスフォーメーションは主に、人とシステム、およびシステム同士を接続することを伴ってきました。現在、私たちはその資産の中に新たな参加者を導入し始めています。それは、目的を受け取り、それをどのように追求するかを判断し、私たちの代理としてそれらのシステムを使用できるソフトウェアです。
これには、特に従来の自動化を拒んできた調整作業の周囲において、真に興味深い可能性が秘められています。NIST自体も、エージェントが生産性、効率性、および意思決定を向上させる可能性について説明する一方で、それらのエージェントに組織のデータ、ツール、およびアプリケーションへのアクセス権が与えられる際には、適切な識別と認可の管理が必要であることを強調しています。
この組み合わせは重要だと私は考えています。機会とリスクは同じ特性から生じています。それは、エージェントが「仕事がどのように行われるかを決定する一定の自由」を持っているという点です。
それが始まると、アーキテクチャの関心事は、単にあるシステムが別のシステムに接続できるかどうかだけにとどまらなくなります。どの自律的な実行者が、誰の権限のもと、どのような制限のもと、どのような証拠を残しながら、どの情報を使用し、どの機能を実行できるかを決定する重要性がますます高まります。
したがって実務において、エンタープライズAIエージェントのガバナンスが、イントラネットのどこかにある別のポリシー文書によって解決される可能性は低いです。それは、私たちが作成するアイデンティティ、付与する権限、結果を伴うアクションの周囲の統制、エージェントが消費するデータの品質と出所、私たちが設計するエスカレーションパス、そしてその後に維持する監査証拠の中に現れなければなりません。
Hugging Faceは、自律型ソフトウェアがそのオペレーターの予想しなかったルートを見つけ出すという、極端な例を示してくれています。PocketOSは、エージェントがタスクの必要性を超えた権限を持っている場合に何が起こるかという、はるかに日常的な例を示してくれています。エージェントのアイデンティティ、最小権限、安全なマルチエージェント対話、および信頼できるリソース検出に関する新たな取り組みは、周囲の管理モデルがすでにその能力に追いつかなければならなくなっていることを示しています。
これらはどれも、エージェント型AIに反対する論拠ではありません。まったく逆です。エージェントが、現代のデジタルビジネスを運営する上でコストがかさみ、煩雑にしている人間による調整作業の一部を取り除くことができるのであれば、それらを追求する非常に具体的な理由が存在します。
しかし、自律的な実行者を既存のデジタル資産に導入することは、単なるもう1つのAIの実装ではありません。それは、アイデンティティ、信頼、データ、説明責任、そして最終的には権限に関する前提条件を変化させます。
ですから、エージェントに何ができるかを尋ねる前に、私は別の質問から始めたいと思います。
あなたは、エージェントに「実際に何をさせる」用意がありますか？
AIが権限を持つとき
ここ数年、企業はジェネレーティブAIが何を示してくれるかという点に注目してきました。AIエージェントの登場は、より重大な問いを投げかけています。それは、ソフトウェアが「次に何をすべきか」を判断し、それを「実際に実行する」ことができるようになったとき、何が起こるかという問題です。
2026年7月、OpenAIのサイバーセキュリティ評価の一環として使用されていたAIエージェントが、Hugging Faceの本番環境インフラの一部を侵害しました。ただ、ここで興奮しすぎる前に、重要な背景情報を整理しておく必要があります。これは、通常のビジネスアプリケーションが突如として他社を攻撃し始めたというケースではありません。OpenAIは意図的に、高度な機能を持つモデルに対して困難なサイバーセキュリティ課題をテストしており、通常はモデルが高リスクのサイバー活動を追求するのを防ぐために使用される本番用分類器が、評価のために意図的に無効にされていたのです。
そうだとしても、何が起こったのかは注目に値します。その後の調査によると、エージェントはHugging Faceが保持する情報が、与えられたベンチマークを完了するのに役立つと判断したようです。エージェントは評価環境が使用していたインフラ内のゼロデイ脆弱性を突いて抜け出し、より広いインターネットアクセスを獲得し、他の攻撃パスを連鎖させ、資格情報を取得して、最終的にHugging Faceのシステムに到達しました。Hugging Faceのフォレンジック再現によると、約17,600件の個別のアクションが対象となり、それらは約6,280のクラスターにグループ化されていました。
当然ながら、「AIが脱走した」または「AIが暴走した」という見出しを付けたくなる誘惑に駆られます。しかし、それが特に有益な見方だとは思いません。調査で明らかになった限りでは、ソフトウェアは与えられた目的を達成しようとして、誰も予想しなかったルートを見つけただけでした。Hugging Faceは、エージェントがベンチマーク情報や解決策があると考えた本番システムにアクセスすることで、事実上、評価を「ごまかそう」としたのだろうと考えています。
これは劇的なストーリーとしては劣りますが、デジタルトランスフォーメーションの観点からはおそらくより重要な出来事です。
ここ数年、ほとんどの組織にとってジェネレーティブAIは「質問する相手」でした。情報を与え、質問をし、何かを返してもらう。契約書を要約したり、データを分析したり、コードを書いたり、メールの下書きを作成したりすることはあっても、その先で「次に何をするか」を決めるのは一般的にまだ人間でした。
エージェントはその境界線を曖昧にし始めます。これと同じインテリジェンスにツールへのアクセス権を与えれば、情報の取得、APIの呼び出し、レコードの更新、コードの実行、メールの送信、あるいは変更自体をエージェント自身で行うことができます。OpenAIもエージェントをほぼ同様に説明しています。すなわち、ユーザーに代わってワークフローの実行を自律的に管理し、意思決定を行い、適切なツールを選択し、外部システムと対話できるシステムです。
チャットボットが「書き込み権限」を手に入れたのです。
このシフトこそが、AIエージェントのガバナンスが、単なるポリシーに関する議論ではなく、実践的なエンタープライズの課題になりつつある理由です。ソフトウェアが「推奨する」だけでなく「行動を起こす」ことができるようになると、アイデンティティ、権限、統制、監査可能性、および説明責任に関する問いが、アーキテクチャそのものの内部へと移行します。
ソフトウェアに「指示」ではなく「意図」が与えられると、自動化が変わる
ソフトウェアは何十年もの間、物事を変え続けてきたため、ここで何が新しいのかを誇大広告してしまう危険性があります。データベースを更新したり、APIを起動したり、ワークフローを実行したりするのにAIは必要ありません。スクリプト、ルールエンジン、オーケストレーションプラットフォーム、自動化プロセスは、何年もの間、それらのタスクを申し分なくこなしてきました。
違いは、目的から行動に至るまでのプロセスにあります。従来の自動化は、通常、誰かが事前に定義したルートに沿って設計されています。Xが発生した場合はYを取得する。答えがZの場合はこのアクションを実行する。そこには何百ものルール、分岐、例外が関わっているかもしれませんが、それでも誰かが事前にそのプロセスをモデル化しようとしていたのです。
エージェントによって、ソフトウェアに目的を達成するためのすべての指示を与えるのではなく、「結果」を提示する方向へと、さらに進むことが可能になります。「必要な情報を特定すること。適切なツールを決定すること。戻ってきた結果に対処し、仕事を完了させること」というようにです。
この違いが重要なのは、実行パスが動的になり得るからです。エージェントはあるシステムから処理を開始し、追加のコンテキストが必要であることに気づき、別のシステムを呼び出し、予期しない結果に遭遇すると、アプローチを修正して処理を続行するかもしれません。現在のエージェントアーキテクチャは、タスクの状態に応じて、ワークフローを管理し、ツールを選択し、アクションを実行するこの能力を中心に明示的に構築されています。
これは、従来の自動化とは本質的に異なる命題です。ソフトウェアはもはや、単に事前に決定されたフローを実行しているだけではありません。その周囲に設定したどのような境界線の内部であれ、そのフローがどのように展開するかについて、ソフトウェアに一定の裁量を与えていることになります。
そして、これこそが、AIがより優れたメールを書けるかどうかという話よりも、はるかに興味深いポイントです。
機会は「人」ではなく「調整作業」を排除することにある
組織内の仕事の驚くほど多くの部分が、個々のタスクが特別に複雑だから難しいわけではありません。タスク間で必要となる「調整作業」のせいで難しいのです。
CRMを開き、顧客を見つける。識別子を課金プラットフォームにコピーする。メモを読む。別のシステムをチェックする。それらが何を意味しているかを理解する。別のチームにこれが正常な状態かどうかを尋ねる。返答を待つ。最初のプラットフォームを更新し、顧客にメールを送信する。
聞き覚えはありませんか？
私たちは何年もかけてそれらのプロセスを自動化しようとしてきました。ステップが予測通りに説明できる場合、従来のワークフロー技術は極めて効果的です。難しい部分となるのは例外事項です。適切に構造化されていないドキュメント、完全には一致しないアカウント、互いに食い違う3つのシステム、あるいは次に何をすべきかを知る前に、誰かが何かを読み取ってその意味を理解する必要があるプロセス上のポイントなどです。
それらこそが、エージェントが役に立つ可能性のあるワークフローです。OpenAIの現在のガイダンスでは、複雑な意思決定、維持が困難なルール、および非構造化情報への強い依存がある領域を、従来の一意に決まる自動化（決定論的自動化）では提供できない、エージェント型アプローチが何かを提供できる領域として明確に特定しています。また、それらの特性がない場合は、一意に決まる解決策の方が依然として優れた答えになり得るという重要な点も指摘しています。
ソフトウェアがシステム、情報、意思決定の間の調整作業の一部を引き受けることができれば、そこには実質的で大きな効率性の向上が見込めます。それは、プロセスに関わるすべての人々が突然いなくなるからではなく、本来お互いを調整するのがそれほど得意ではないプラットフォーム同士の間で、人間を「高価なミドルウェア」として使用するのをやめることができるからです。
そこには重要な違いがあります。目標は、必ずしも組織から人間を排除することであってはなりません。人々の足元にあるテクノロジーがコンテキスト、曖昧さ、または例外をうまく処理できないという理由だけで、現在人々に強いている作業を排除することであるべきです。
だからこそ、エージェントがもたらす機会は、漸進的な生産性の向上よりもはるかに重要であると私は考えています。顧客への返信の下書きを10秒早く作成できることは便利です。しかし、ソフトウェアに問題を調査させ、関連情報を調整させ、プロセスを前に進めさせることは、それとはまったく異なるレベルの話です。
もちろん、プロセスを先へ進めれば進めるほど、最終的には結果を伴うアクションに近づいていきます。
そして、そこから事態ははるかに複雑になります。
能力（Capability）は権限（Authority）ではない
Hugging Faceの出来事の数ヶ月前、PocketOSはAIエージェントが会社のステージング（本番）データベースを削除してしまったという、ありのままの報告書を公開しました。削除にかかった時間は9秒、復旧には60時間かかりました。バックアップは存在していましたが、バックアッププロセスがいつの間にか停止していたため、3ヶ月前の古いものでした。
PocketOSも、これが単なる「AIの問題」ではないことを非常に明確にしています。同社は、破壊的なアクションに対する十分な摩擦（障壁）が存在しない環境に対し、エージェントが本来持つべきではない権限を使用して、確信を持って行動したと述べています。
これは有益な教訓です。
人間は何年も前から本番データベースを誤って削除してきましたし、ソフトウェアのバグもそれに少なからぬ貢献をしてきました。興味深いのは、その実行者が、その過失が重大な問題になるほどの十分な権限を持っていたという点です。
実行者が人間である場合、私たちはすでにこのことを理解しています。カスタマーサービスの担当者は、誰も気に留めないような20ポンドの返金を処理する権限を持っているかもしれません。200ポンドでもまだ妥当な範囲内でしょう。しかし、20,000ポンドになると、おそらく別の承認プロセスが必要になります。
同じことが他の場所にも当てはまります。コンテンツのメタデータ内のスペルミスをエージェントが特定して修正することは、おそらく十分に無害です。もし、エージェントが変更しようとしているフィールドが、そのコンテンツを特定の地域で配信できるかどうかを決定するものである場合、その結果は大きく異なります。同様に、エージェントが本番環境の設定の問題を正しく特定したからといって、その環境全体を再設定する無制限の権利をエージェントが引き継ぐべきだということにはなりません。
これらはどれも、特に風変わりな話ではありません。これは新しいタイプの実行者に適用された「アイデンティティとアクセス管理」であり、効果的なエージェント型AIガバナンスの基盤の1つになると私は考えています。
Microsoftはすでに、エージェントをこのような観点から扱っています。同社の現在のガイダンスでは、ユニークで専用のAIエージェントアイデンティティ、指名されたオーナーまたはスポンサー、明確に文書化された目的とデータアクセス、最小権限アクセス、制御されたツール権限、ロギング、および検証済みの権限取り消しパスを推奨しています。同じ領域におけるNIST（米国国家規格技術研究所）の取り組みでも、AIエージェントの識別、認可、監査、および否認防止について明示的に調査が行われています。
実務的な観点から言えば、これはAIエージェントの権限を、特権を持つ人間のアカウントやサービスアカウントと同じ真剣さで扱う必要があることを意味します。エージェントは、何が起こるべきかを判断する完璧な能力を持っていたとしても、それを実現する権限を与えられているとは限りません。
この違いは重要です。AIエージェントの統制において、単にモデルがアクションを物理的・技術的に実行できるかどうかを問うだけでは不十分です。この特定のコンテキストで動作しているこの特定のエージェントが、そのアクションを実行することを「認可されているか」を判断する必要があります。
余談ですが、AIエージェントの乱立（スプロール現象）は、誰かが最終的に「実際に何個のエージェントが動いているのか？」と尋ねるまで、組織が気づかない問題の1つになるのではないかと考えています。私たちは、SaaSアプリケーション、クラウドのリソース、サービスアカウント、APIキーなどで、すでにこれと似たような問題を経験してきました。エージェントの資産が、それらよりもうまく自然に整理されると考える明確な理由はありません。特に、実験的な取り組みが意図的に各チームに分散されている企業においてはなおさらです。
これは、すべてのAIイニシアチブを中央集権化すべきだという意味ではありません。中央のチームがすべてのプロセスを十分に理解し、すべての有用なアプリケーションを自ら特定できる可能性は低いため、分散型のイノベーションは完全に理にかなっています。
しかし、結果として生じてしまう「予期せぬ権限の分散」は別問題です。
エージェント型AIは、デジタル資産における既存のすべての「妥協」を引き継ぐ
これらすべての根底には、もう1つの厄介な問題があります。エージェントは、既存のデジタル資産をそのまま引き継ぐことになるということです。
輝かしい新技術のAPI、レガシーシステム、一貫性のない顧客レコード、8年前に誰かが書き、誰も手を触れたがらないインテグレーション、そしてあるプラットフォームでは顧客を一つの名前で呼び、別のプラットフォームでは異なる名前で呼んでいるシステム。企業が成長し、プラットフォームが買収され、チームが個別の問題を解決し、買収が発生し、サプライヤーが変わり、優先順位が移り変わります。そして最終的に、誰もが「現在のアーキテクチャ」と丁重に呼ぶものに行き着くのです。
ここで、サービス料金を支払ったにもかかわらず、アクセスできないという顧客を処理するエージェントを想像してみてください。実際に何が起こったのかを誰かが判断できるようになるまでに、CRM、課金、認証、エンタイトルメント（利用資格）、サポートシステムからの情報が必要になる場合があります。
人間のオペレーターであれば、それらの一貫性のなさをほとんど考えることなく処理することがよくあります。彼らは、あるシステムが別のシステムより先に更新されることを知っています。識別子がわずかに異なっていることに気づきます。もしかしたら、古いパッケージの顧客は異なる挙動をすることを覚えているかもしれません。あるいは、ドキュメントが2023年以降更新されていないため、単に隣に座っている人に尋ねるかもしれません。
その仕事をエージェントに与える場合、それらの前提条件がどこかに存在していなければなりません。どのシステムが信頼できる情報源（オーソリティ）なのか？課金システムは支払いが成功したと言っているのに、エンタイトルメントプラットフォームはアカウントが無効だと言っている場合、どうすればいいのか？情報が間違っているのか、それともエージェントが理解していないビジネスルールがあるのか？単にあるプラットフォームが5分遅れているだけなのか？
これらは、新たな消費者（エージェント）を迎えた、古いデータとアーキテクチャの問題です。本質的な違いは、この新しい消費者が、自ら到達した結論に基づいて「アクションを起こす」可能性があるという点です。
チャットボットに与えられるデータが貧弱であれば、悪い回答が生成される可能性があります。自律型ソフトウェアに与えられるデータが貧弱であれば、悪い「結果」がもたらされる可能性があります。
さらに、もう1つの複雑な要素もあります。情報が必ずしも「偶然」間違っているとは限らないという点です。7月に発表された研究では、攻撃者が管理する情報が、一見正当なコンテキストデータとして提示され、エージェントがその後に実行する行動に影響を与えるという「エージェントデータインジェクション攻撃」が実証されました。研究者らは、実際のWebエージェントやコーディングエージェントにおける脆弱性を特定し、意図しないクリック、リモートコード実行、ソフトウェアサプライチェーンにおけるアクションが引き起こされる可能性があることを示しました。
これにより、データアーキテクチャとセキュリティの間に、厄介なクロスオーバー（交差）が生じます。情報がアクションに影響を与える可能性がある場合、その情報がどこから来たのか、信頼できるのか、そしてエージェントがそれにどれだけの重みを置くべきなのかは、もはや抽象的なガバナンスの懸念事項ではありません。それらは実行モデルの一部となります。
これが、「エージェントの存在によって、技術的負債の重要性が何らかの形で低下する」という考え方に私が慎重になる理由でもあります。エージェントは、固定されたインテグレーションパスに完全に依存するのではなく、タスクについて推論できるため、断片化された環境の操作を容易にするかもしれませんが、それでもシステムへのアクセス、使用可能なインターフェース、意味のあるデータ、適切な権限、そして処理の途中で何かが失敗したときにどうすべきかというアイデアを必要とします。
APIが存在しない場合、エージェントは別のアクセス方法を必要とします。同じ顧客に6つの識別子がある場合、人間または何らかの仕組みが、それらが同一人物を表しているかどうかを特定する必要があります。文書化されていないビジネスルールが意思決定に影響を与える場合、その知識がどこかで利用可能である必要があります。
散らかった資産の前にインテリジェントなオーケストレーションレイヤーを置いたからといって、その資産が散らかっているのをやめるわけではありません。その散らかった状態を移動しやすくはなるかもしれませんが、同時に、その散らかった状態がもたらす結果がはるかに速く伝播することにもなりかねません。
人間の監視には経済的コストが伴う
この段階になると、ほとんどの議論において「プロセスには常に人間が関与する（Human in the loop）」と言う人が現れます。
それは心強く聞こえますが、明白な疑問を生じさせます。もし誰かが依然としてエージェントの行うすべてのことをレビューし、承認する必要があるのだとしたら、私たちは実際にどれだけの自動化を達成できたと言えるのでしょうか？
カスタマーサービスのエージェントが5つのシステムをチェックし、アカウントの問題を特定し、顧客に誤って請求が行われていたことを突き止め、20ポンドの返金が適切であると計算したと想像してください。その後、エージェントは誰かが「承認」をクリックするためのキューにそのプロセス全体を投入します。
調査自体が自動化されたため、依然として有意義な節約にはなっているかもしれませんが、そのプロセスを数万件のトランザクションにわたって実行すれば、結局はかなりの規模の手動運用を残すことになります。ボトルネックが解消されたのではなく、移動しただけです。
ここで、エージェント型AIを取り巻く、より「安全」な言葉遣いの一部が、自動化の経済性と衝突し始めます。ソフトウェアにプロセスから作業を取り除いてもらうために「自律性」を導入しながら、その自律性に十分な不安を感じるがゆえに、結局すべてのトランザクションに再び人間を配置してしまうのです。
最終的には、それでは自動化の意味がほとんど失われてしまいます。
返金が20ポンドで、ルールが明確であり、関連するすべてのシステムが一致し、そのアクションを簡単に取り消せるのであれば、誰も承認する必要はないかもしれません。金額が20,000ポンドであったり、2つのシステムが食い違っていたり、状況が通常のパラメータから外れている場合は、誰かを関与させるべき絶好のタイミングです。
したがって、多くのプロセスにおいて、役立つ目的地は「プロセスに常に人間が関与する（Human in the loop）」ではなく、「例外時に人間が関与する（Human by exception）」ことでしょう。ルーチン化された、よく理解されている作業はますます自律的になり、一方で、珍しい、曖昧な、または結果の影響が大きいケースは人間へとエスカレーションされます。
これには、自律性を段階的に導入する余地が十分にあります。エージェントは、観察と推奨から始めることができます。その動作が理解されたら、承認用のアクションを準備させることができます。最終的には、ルーチン化され、取り消し可能な特定クラスのアクションを自動的に実行させ、プロセスが合意されたしきい値を超えたときに人間が関与するようにします。
OpenAIのガイダンスも、同様のリスクベースのアプローチをとっています。エージェントが定義された失敗のしきい値を超えた場合や、多額の返金や支払いなど、機密性が高く、不可逆的で、リスクの高いアクションの周囲では、人間の介入を推奨しています。
PocketOSは、かなり実務的な方向からこれと同じ問題に直面しました。データベースの事故を受け、現在、破壊的な操作には人間による明示的な確認が必要となっています。同社は自律型エージェントの利用をあきらめるという対応はしませんでした。本番環境で引き続き多数の限定的な自律型エージェントを実行しながら、制御境界の配置場所を変更したと述べています。
これこそが、人間の監視について考えるためのより有益な方法であると私は思います。それは、結果がそれを正当化する場所に適用されるべき「統制」であり、自律型ソフトウェアによって実行されるすべての行動に対する永続的な運用モデルである必要はありません。
結局のところ、自動化のポイントは「自動化すること」です。設計上の問題は、人間がどこで真に成果を向上させるのか、そして、単にシステムをまだ十分に信頼していないという理由だけで人間が維持されているのはどこなのかを判断することです。
追跡可能性のない自律性は、運用上正当化できない
「例外時に人間が関与する」方向へ進むと、別のことの重要性が低下するのではなく、むしろ高まります。それは、エージェントが「実際に何をしたのか」を理解することです。
Hugging Faceの調査は、有益な極端な例です。そのフォレンジック再現は、数千のクラスターにわたる約17,600件のアクションを対象とし、調査員はエージェントがどのようにシステム内を移動し、時間の経過とともにどのように行動を適応させたかをつなぎ合わせました。
これを通常のビジネスプロセスに落とし込んでみましょう。顧客が「アカウントの何かが誤って変更された」と主張し、調査した結果、エージェントがその変更を行ったことが判明したとします。
インシデントレビューにおいて、「AIがそれをやった」という説明だけでは、ほとんど通用しないでしょう。
どのエージェントが行動したのか、誰がそのタスクを開始したのか、どの情報を使用したのか、その時点でその情報に何が含まれていたのか、どのツールを呼び出したのか、そして最終的にどの権限がその変更を許容したのかを知りたくなるはずです。その過程で別のエージェントが関与した場合は、それもおそらく重要になります。
ここにおいて、AIエージェントの監査可能性は、ガバナンス上の「あると良いもの」から「運用上の必須要件」へと変化します。実行における直接的な人間の関与が少なくなればなるほど、それを取り巻く観察可能性（オブザーバビリティ）を強化する必要があります。
Microsoftの現在のガイダンスでは、エージェントのアイデンティティ、その役割と有効なスコープ、実行されたアクション、影響を受けたリソース、およびそのエージェントが代理で行動していたユーザーを記録することを推奨しています。NISTも同様に、エージェントのアイデンティティと認可の問題の一部として、監査と否認防止を明示的に検討しています。
これは、すべての自律的なアクションを誰かが監視する必要があるという意味ではありません。私たちはすでに、すべてのトランザクション、インフラのイベント、またはネットワークリクエストの前に人間を置くことなく、巨大な自動化環境を運用しています。制限、統制、監視を設定し、そこから外れたものを調査します。
成熟したエージェントシステムがそれと異なる仕組みで動作すべき明確な理由はありません。
自律性は監視を排除するものではありません。監視が「いつ」行われるかを変えるだけです。
委譲された意図が、信頼の境界を複雑にする
もう1つ、注目に値する展開があります。それがこの問題をさらに興味深いものにしています。
エージェントは、他のエージェントと対話し、コラボレーションするようにますます設計されています。GoogleのAgent2Agentプロトコルは、異なるチームによって、また異なる技術スタック上に構築されたエージェントを含め、エージェント同士がどのように相互を検出し、通信できるかを標準化しています。その新しいAgentic Resource Discoveryの取り組みは、チーム、組織、プラットフォームに分散されたツール、スキル、および他のエージェントを、エージェントがどのように見つけて検証できるかという関連する問いに対処しています。
社内のエージェントがタスクを受け取り、別の専門エージェントがその一部を実行できると判断したと想像してください。その2番目のエージェントは、あなたのサービスの1つを呼び出し、最終的に何かを変更するツールを使用します。
誰が行動しているのでしょうか？
2番目のエージェントでしょうか？最初のエージェントでしょうか？それとも、元のタスクを開始した人間でしょうか？
最初のエージェントがアクションを実行する権限を与えられている場合、その権限を委譲できるでしょうか？2番目のエージェントはその権限のすべてを受け取るのか、一部を受け取るのか、あるいはまったく受け取らないのか？エージェントが異なる組織に属している場合はどうなるでしょうか？
これらは新たに出現した問いであり、業界がこれらすべての答えについて合意に達したと見なすのは時期尚早でしょう。NISTのAI Agent Standards Initiativeは、安全な人間とエージェント、およびマルチエージェント間の対話をサポートするために、エージェントの認証とアイデンティティインフラに関する取り組みを明示的に実施しています。
しかし、その方向性は重要です。歴史的に、信頼は既知のユーザー、アプリケーション、またはインテグレーションと関連付けられてきました。エージェントが動的に機能を検出し、目的の一部を他の場所に委譲できるようになると、信頼と権限はそのプロセスを越えて維持される必要があります。
タスクは動的になり得ます。しかし、別の境界を越えるたびに説明責任が消えてしまうことがあってはなりません。
エージェント型トランスフォーメーションは、テクノロジーではなく「委譲」から始めるべきである
変革に携わるほとんどの人が認識しているであろう、重要なテクノロジーシフトに伴うパターンがあります。何かが戦略的に重要になり、誰かが組織にそれが必要だと決定し、全員がそれを適用する場所を探し始めるというパターンです。
「AI戦略が必要だ。エージェントのユースケースがいくつか必要だ。ワークショップを開催しよう。どのプロセスをエージェント型にできるか？」
私なら、おそらく逆のアプローチをとります。
まずは、全員をイライラさせているプロセスから始めましょう。時間がかかり、コストがかさみ、断片化されているか、あるいは、誰かが一日中システム間で情報を転記することに依存しているようなプロセスです。意思決定がどこで行われているか、それらの意思決定がどの情報に依存しているか、どのシステムが関与しているか、厄介な例外がどこで発生するか、そして何かがうまくいかなかったときに何が起こるかを理解するのです。
次に、そのプロセスに携わっている人々が実際に何をしているかを見てみましょう。彼らは価値ある判断を下しているのでしょうか、それとも周囲のテクノロジーの限界を補っているだけでしょうか？彼らが何かを承認しているのは、真の財務的または運用上のリスクがあるからでしょうか、それともワークフローがルーチンケースと異常なケースを区別できないからでしょうか？彼らが手動で情報を調整しているのは、組織が真に彼らの専門知識を必要としているからでしょうか、それとも2つのシステムが異なる識別子を使用しているからでしょうか？
これらはまったく異なる問題です。
それを理解した上で、何を「委譲」する用意があるかを決定します。ソフトウェアはどの意思決定を行えるか？どのようなアクションを実行できるか？どれが取り消し可能か？エスカレーションはどこで必要か？それにはどのような権限が必要か？後で意思決定の理由を尋ねられた場合、どのような証拠が必要になるか？
テクノロジーの選択が特に興味深いものになるのは、それらが明確になってからです。
エージェントは優れた答えになるかもしれません。そうではないかもしれません。それで構いません。エージェントの設計に関する現在のガイダンスでも、ほぼ同様の区別がなされています。エージェントは、曖昧さ、複雑な意思決定、または非構造化データによって、一意に決まる（決定論的）アプローチが困難になるワークフローに適していますが、それらの特性がない場所では、従来の自動化で依然として十分に足りる可能性があります。
目的はエージェントをデプロイすることではありません。ビジネスを改善することです。
自動化のアーキテクチャは、権限のアーキテクチャになりつつある
過去20年間、デジタルトランスフォーメーションは主に、人とシステム、およびシステム同士を接続することを伴ってきました。現在、私たちはその資産の中に新たな参加者を導入し始めています。それは、目的を受け取り、それをどのように追求するかを判断し、私たちの代理としてそれらのシステムを使用できるソフトウェアです。
これには、特に従来の自動化を拒んできた調整作業の周囲において、真に興味深い可能性が秘められています。NIST自体も、エージェントが生産性、効率性、および意思決定を向上させる可能性について説明する一方で、それらのエージェントに組織のデータ、ツール、およびアプリケーションへのアクセス権が与えられる際には、適切な識別と認可の管理が必要であることを強調しています。
この組み合わせは重要だと私は考えています。機会とリスクは同じ特性から生じています。それは、エージェントが「仕事がどのように行われるかを決定する一定の自由」を持っているという点です。
それが始まると、アーキテクチャの関心事は、単にあるシステムが別のシステムに接続できるかどうかだけにとどまらなくなります。どの自律的な実行者が、誰の権限のもと、どのような制限のもと、どのような証拠を残しながら、どの情報を使用し、どの機能を実行できるかを決定する重要性がますます高まります。
したがって実務において、エンタープライズAIエージェントのガバナンスが、イントラネットのどこかにある別のポリシー文書によって解決される可能性は低いです。それは、私たちが作成するアイデンティティ、付与する権限、結果を伴うアクションの周囲の統制、エージェントが消費するデータの品質と出所、私たちが設計するエスカレーションパス、そしてその後に維持する監査証拠の中に現れなければなりません。
Hugging Faceは、自律型ソフトウェアがそのオペレーターの予想しなかったルートを見つけ出すという、極端な例を示してくれています。PocketOSは、エージェントがタスクの必要性を超えた権限を持っている場合に何が起こるかという、はるかに日常的な例を示してくれています。エージェントのアイデンティティ、最小権限、安全なマルチエージェント対話、および信頼できるリソース検出に関する新たな取り組みは、周囲の管理モデルがすでにその能力に追いつかなければならなくなっていることを示しています。
これらはどれも、エージェント型AIに反対する論拠ではありません。まったく逆です。エージェントが、現代のデジタルビジネスを運営する上でコストがかさみ、煩雑にしている人間による調整作業の一部を取り除くことができるのであれば、それらを追求する非常に具体的な理由が存在します。
しかし、自律的な実行者を既存のデジタル資産に導入することは、単なるもう1つのAIの実装ではありません。それは、アイデンティティ、信頼、データ、説明責任、そして最終的には権限に関する前提条件を変化させます。
ですから、エージェントに何ができるかを尋ねる前に、私は別の質問から始めたいと思います。
あなたは、エージェントに「実際に何をさせる」用意がありますか？
AIが権限を持つとき
ここ数年、企業はジェネレーティブAIが何を示してくれるかという点に注目してきました。AIエージェントの登場は、より重大な問いを投げかけています。それは、ソフトウェアが「次に何をすべきか」を判断し、それを「実際に実行する」ことができるようになったとき、何が起こるかという問題です。
2026年7月、OpenAIのサイバーセキュリティ評価の一環として使用されていたAIエージェントが、Hugging Faceの本番環境インフラの一部を侵害しました。ただ、ここで興奮しすぎる前に、重要な背景情報を整理しておく必要があります。これは、通常のビジネスアプリケーションが突如として他社を攻撃し始めたというケースではありません。OpenAIは意図的に、高度な機能を持つモデルに対して困難なサイバーセキュリティ課題をテストしており、通常はモデルが高リスクのサイバー活動を追求するのを防ぐために使用される本番用分類器が、評価のために意図的に無効にされていたのです。
そうだとしても、何が起こったのかは注目に値します。その後の調査によると、エージェントはHugging Faceが保持する情報が、与えられたベンチマークを完了するのに役立つと判断したようです。エージェントは評価環境が使用していたインフラ内のゼロデイ脆弱性を突いて抜け出し、より広いインターネットアクセスを獲得し、他の攻撃パスを連鎖させ、資格情報を取得して、最終的にHugging Faceのシステムに到達しました。Hugging Faceのフォレンジック再現によると、約17,600件の個別のアクションが対象となり、それらは約6,280のクラスターにグループ化されていました。
当然ながら、「AIが脱走した」または「AIが暴走した」という見出しを付けたくなる誘惑に駆られます。しかし、それが特に有益な見方だとは思いません。調査で明らかになった限りでは、ソフトウェアは与えられた目的を達成しようとして、誰も予想しなかったルートを見つけただけでした。Hugging Faceは、エージェントがベンチマーク情報や解決策があると考えた本番システムにアクセスすることで、事実上、評価を「ごまかそう」としたのだろうと考えています。
これは劇的なストーリーとしては劣りますが、デジタルトランスフォーメーションの観点からはおそらくより重要な出来事です。
ここ数年、ほとんどの組織にとってジェネレーティブAIは「質問する相手」でした。情報を与え、質問をし、何かを返してもらう。契約書を要約したり、データを分析したり、コードを書いたり、メールの下書きを作成したりすることはあっても、その先で「次に何をするか」を決めるのは一般的にまだ人間でした。
エージェントはその境界線を曖昧にし始めます。これと同じインテリジェンスにツールへのアクセス権を与えれば、情報の取得、APIの呼び出し、レコードの更新、コードの実行、メールの送信、あるいは変更自体をエージェント自身で行うことができます。OpenAIもエージェントをほぼ同様に説明しています。すなわち、ユーザーに代わってワークフローの実行を自律的に管理し、意思決定を行い、適切なツールを選択し、外部システムと対話できるシステムです。
チャットボットが「書き込み権限」を手に入れたのです。
このシフトこそが、AIエージェントのガバナンスが、単なるポリシーに関する議論ではなく、実践的なエンタープライズの課題になりつつある理由です。ソフトウェアが「推奨する」だけでなく「行動を起こす」ことができるようになると、アイデンティティ、権限、統制、監査可能性、および説明責任に関する問いが、アーキテクチャそのものの内部へと移行します。
ソフトウェアに「指示」ではなく「意図」が与えられると、自動化が変わる
ソフトウェアは何十年もの間、物事を変え続けてきたため、ここで何が新しいのかを誇大広告してしまう危険性があります。データベースを更新したり、APIを起動したり、ワークフローを実行したりするのにAIは必要ありません。スクリプト、ルールエンジン、オーケストレーションプラットフォーム、自動化プロセスは、何年もの間、それらのタスクを申し分なくこなしてきました。
違いは、目的から行動に至るまでのプロセスにあります。従来の自動化は、通常、誰かが事前に定義したルートに沿って設計されています。Xが発生した場合はYを取得する。答えがZの場合はこのアクションを実行する。そこには何百ものルール、分岐、例外が関わっているかもしれませんが、それでも誰かが事前にそのプロセスをモデル化しようとしていたのです。
エージェントによって、ソフトウェアに目的を達成するためのすべての指示を与えるのではなく、「結果」を提示する方向へと、さらに進むことが可能になります。「必要な情報を特定すること。適切なツールを決定すること。戻ってきた結果に対処し、仕事を完了させること」というようにです。
この違いが重要なのは、実行パスが動的になり得るからです。エージェントはあるシステムから処理を開始し、追加のコンテキストが必要であることに気づき、別のシステムを呼び出し、予期しない結果に遭遇すると、アプローチを修正して処理を続行するかもしれません。現在のエージェントアーキテクチャは、タスクの状態に応じて、ワークフローを管理し、ツールを選択し、アクションを実行するこの能力を中心に明示的に構築されています。
これは、従来の自動化とは本質的に異なる命題です。ソフトウェアはもはや、単に事前に決定されたフローを実行しているだけではありません。その周囲に設定したどのような境界線の内部であれ、そのフローがどのように展開するかについて、ソフトウェアに一定の裁量を与えていることになります。
そして、これこそが、AIがより優れたメールを書けるかどうかという話よりも、はるかに興味深いポイントです。
機会は「人」ではなく「調整作業」を排除することにある
組織内の仕事の驚くほど多くの部分が、個々のタスクが特別に複雑だから難しいわけではありません。タスク間で必要となる「調整作業」のせいで難しいのです。
CRMを開き、顧客を見つける。識別子を課金プラットフォームにコピーする。メモを読む。別のシステムをチェックする。それらが何を意味しているかを理解する。別のチームにこれが正常な状態かどうかを尋ねる。返答を待つ。最初のプラットフォームを更新し、顧客にメールを送信する。
聞き覚えはありませんか？
私たちは何年もかけてそれらのプロセスを自動化しようとしてきました。ステップが予測通りに説明できる場合、従来のワークフロー技術は極めて効果的です。難しい部分となるのは例外事項です。適切に構造化されていないドキュメント、完全には一致しないアカウント、互いに食い違う3つのシステム、あるいは次に何をすべきかを知る前に、誰かが何かを読み取ってその意味を理解する必要があるプロセス上のポイントなどです。
それらこそが、エージェントが役に立つ可能性のあるワークフローです。OpenAIの現在のガイダンスでは、複雑な意思決定、維持が困難なルール、および非構造化情報への強い依存がある領域を、従来の一意に決まる自動化（決定論的自動化）では提供できない、エージェント型アプローチが何かを提供できる領域として明確に特定しています。また、それらの特性がない場合は、一意に決まる解決策の方が依然として優れた答えになり得るという重要な点も指摘しています。
ソフトウェアがシステム、情報、意思決定の間の調整作業の一部を引き受けることができれば、そこには実質的で大きな効率性の向上が見込めます。それは、プロセスに関わるすべての人々が突然いなくなるからではなく、本来お互いを調整するのがそれほど得意ではないプラットフォーム同士の間で、人間を「高価なミドルウェア」として使用するのをやめることができるからです。
そこには重要な違いがあります。目標は、必ずしも組織から人間を排除することであってはなりません。人々の足元にあるテクノロジーがコンテキスト、曖昧さ、または例外をうまく処理できないという理由だけで、現在人々に強いている作業を排除することであるべきです。
だからこそ、エージェントがもたらす機会は、漸進的な生産性の向上よりもはるかに重要であると私は考えています。顧客への返信の下書きを10秒早く作成できることは便利です。しかし、ソフトウェアに問題を調査させ、関連情報を調整させ、プロセスを前に進めさせることは、それとはまったく異なるレベルの話です。
もちろん、プロセスを先へ進めれば進めるほど、最終的には結果を伴うアクションに近づいていきます。
そして、そこから事態ははるかに複雑になります。
能力（Capability）は権限（Authority）ではない
Hugging Faceの出来事の数ヶ月前、PocketOSはAIエージェントが会社のステージング（本番）データベースを削除してしまったという、ありのままの報告書を公開しました。削除にかかった時間は9秒、復旧には60時間かかりました。バックアップは存在していましたが、バックアッププロセスがいつの間にか停止していたため、3ヶ月前の古いものでした。
PocketOSも、これが単なる「AIの問題」ではないことを非常に明確にしています。同社は、破壊的なアクションに対する十分な摩擦（障壁）が存在しない環境に対し、エージェントが本来持つべきではない権限を使用して、確信を持って行動したと述べています。
これは有益な教訓です。
人間は何年も前から本番データベースを誤って削除してきましたし、ソフトウェアのバグもそれに少なからぬ貢献をしてきました。興味深いのは、その実行者が、その過失が重大な問題になるほどの十分な権限を持っていたという点です。
実行者が人間である場合、私たちはすでにこのことを理解しています。カスタマーサービスの担当者は、誰も気に留めないような20ポンドの返金を処理する権限を持っているかもしれません。200ポンドでもまだ妥当な範囲内でしょう。しかし、20,000ポンドになると、おそらく別の承認プロセスが必要になります。
同じことが他の場所にも当てはまります。コンテンツのメタデータ内のスペルミスをエージェントが特定して修正することは、おそらく十分に無害です。もし、エージェントが変更しようとしているフィールドが、そのコンテンツを特定の地域で配信できるかどうかを決定するものである場合、その結果は大きく異なります。同様に、エージェントが本番環境の設定の問題を正しく特定したからといって、その環境全体を再設定する無制限の権利をエージェントが引き継ぐべきだということにはなりません。
これらはどれも、特に風変わりな話ではありません。これは新しいタイプの実行者に適用された「アイデンティティとアクセス管理」であり、効果的なエージェント型AIガバナンスの基盤の1つになると私は考えています。
Microsoftはすでに、エージェントをこのような観点から扱っています。同社の現在のガイダンスでは、ユニークで専用のAIエージェントアイデンティティ、指名されたオーナーまたはスポンサー、明確に文書化された目的とデータアクセス、最小権限アクセス、制御されたツール権限、ロギング、および検証済みの権限取り消しパスを推奨しています。同じ領域におけるNIST（米国国家規格技術研究所）の取り組みでも、AIエージェントの識別、認可、監査、および否認防止について明示的に調査が行われています。
実務的な観点から言えば、これはAIエージェントの権限を、特権を持つ人間のアカウントやサービスアカウントと同じ真剣さで扱う必要があることを意味します。エージェントは、何が起こるべきかを判断する完璧な能力を持っていたとしても、それを実現する権限を与えられているとは限りません。
この違いは重要です。AIエージェントの統制において、単にモデルがアクションを物理的・技術的に実行できるかどうかを問うだけでは不十分です。この特定のコンテキストで動作しているこの特定のエージェントが、そのアクションを実行することを「認可されているか」を判断する必要があります。
余談ですが、AIエージェントの乱立（スプロール現象）は、誰かが最終的に「実際に何個のエージェントが動いているのか？」と尋ねるまで、組織が気づかない問題の1つになるのではないかと考えています。私たちは、SaaSアプリケーション、クラウドのリソース、サービスアカウント、APIキーなどで、すでにこれと似たような問題を経験してきました。エージェントの資産が、それらよりもうまく自然に整理されると考える明確な理由はありません。特に、実験的な取り組みが意図的に各チームに分散されている企業においてはなおさらです。
これは、すべてのAIイニシアチブを中央集権化すべきだという意味ではありません。中央のチームがすべてのプロセスを十分に理解し、すべての有用なアプリケーションを自ら特定できる可能性は低いため、分散型のイノベーションは完全に理にかなっています。
しかし、結果として生じてしまう「予期せぬ権限の分散」は別問題です。
エージェント型AIは、デジタル資産における既存のすべての「妥協」を引き継ぐ
これらすべての根底には、もう1つの厄介な問題があります。エージェントは、既存のデジタル資産をそのまま引き継ぐことになるということです。
輝かしい新技術のAPI、レガシーシステム、一貫性のない顧客レコード、8年前に誰かが書き、誰も手を触れたがらないインテグレーション、そしてあるプラットフォームでは顧客を一つの名前で呼び、別のプラットフォームでは異なる名前で呼んでいるシステム。企業が成長し、プラットフォームが買収され、チームが個別の問題を解決し、買収が発生し、サプライヤーが変わり、優先順位が移り変わります。そして最終的に、誰もが「現在のアーキテクチャ」と丁重に呼ぶものに行き着くのです。
ここで、サービス料金を支払ったにもかかわらず、アクセスできないという顧客を処理するエージェントを想像してみてください。実際に何が起こったのかを誰かが判断できるようになるまでに、CRM、課金、認証、エンタイトルメント（利用資格）、サポートシステムからの情報が必要になる場合があります。
人間のオペレーターであれば、それらの一貫性のなさをほとんど考えることなく処理することがよくあります。彼らは、あるシステムが別のシステムより先に更新されることを知っています。識別子がわずかに異なっていることに気づきます。もしかしたら、古いパッケージの顧客は異なる挙動をすることを覚えているかもしれません。あるいは、ドキュメントが2023年以降更新されていないため、単に隣に座っている人に尋ねるかもしれません。
その仕事をエージェントに与える場合、それらの前提条件がどこかに存在していなければなりません。どのシステムが信頼できる情報源（オーソリティ）なのか？課金システムは支払いが成功したと言っているのに、エンタイトルメントプラットフォームはアカウントが無効だと言っている場合、どうすればいいのか？情報が間違っているのか、それともエージェントが理解していないビジネスルールがあるのか？単にあるプラットフォームが5分遅れているだけなのか？
これらは、新たな消費者（エージェント）を迎えた、古いデータとアーキテクチャの問題です。本質的な違いは、この新しい消費者が、自ら到達した結論に基づいて「アクションを起こす」可能性があるという点です。
チャットボットに与えられるデータが貧弱であれば、悪い回答が生成される可能性があります。自律型ソフトウェアに与えられるデータが貧弱であれば、悪い「結果」がもたらされる可能性があります。
さらに、もう1つの複雑な要素もあります。情報が必ずしも「偶然」間違っているとは限らないという点です。7月に発表された研究では、攻撃者が管理する情報が、一見正当なコンテキストデータとして提示され、エージェントがその後に実行する行動に影響を与えるという「エージェントデータインジェクション攻撃」が実証されました。研究者らは、実際のWebエージェントやコーディングエージェントにおける脆弱性を特定し、意図しないクリック、リモートコード実行、ソフトウェアサプライチェーンにおけるアクションが引き起こされる可能性があることを示しました。
これにより、データアーキテクチャとセキュリティの間に、厄介なクロスオーバー（交差）が生じます。情報がアクションに影響を与える可能性がある場合、その情報がどこから来たのか、信頼できるのか、そしてエージェントがそれにどれだけの重みを置くべきなのかは、もはや抽象的なガバナンスの懸念事項ではありません。それらは実行モデルの一部となります。
これが、「エージェントの存在によって、技術的負債の重要性が何らかの形で低下する」という考え方に私が慎重になる理由でもあります。エージェントは、固定されたインテグレーションパスに完全に依存するのではなく、タスクについて推論できるため、断片化された環境の操作を容易にするかもしれませんが、それでもシステムへのアクセス、使用可能なインターフェース、意味のあるデータ、適切な権限、そして処理の途中で何かが失敗したときにどうすべきかというアイデアを必要とします。
APIが存在しない場合、エージェントは別のアクセス方法を必要とします。同じ顧客に6つの識別子がある場合、人間または何らかの仕組みが、それらが同一人物を表しているかどうかを特定する必要があります。文書化されていないビジネスルールが意思決定に影響を与える場合、その知識がどこかで利用可能である必要があります。
散らかった資産の前にインテリジェントなオーケストレーションレイヤーを置いたからといって、その資産が散らかっているのをやめるわけではありません。その散らかった状態を移動しやすくはなるかもしれませんが、同時に、その散らかった状態がもたらす結果がはるかに速く伝播することにもなりかねません。
人間の監視には経済的コストが伴う
この段階になると、ほとんどの議論において「プロセスには常に人間が関与する（Human in the loop）」と言う人が現れます。
それは心強く聞こえますが、明白な疑問を生じさせます。もし誰かが依然としてエージェントの行うすべてのことをレビューし、承認する必要があるのだとしたら、私たちは実際にどれだけの自動化を達成できたと言えるのでしょうか？
カスタマーサービスのエージェントが5つのシステムをチェックし、アカウントの問題を特定し、顧客に誤って請求が行われていたことを突き止め、20ポンドの返金が適切であると計算したと想像してください。その後、エージェントは誰かが「承認」をクリックするためのキューにそのプロセス全体を投入します。
調査自体が自動化されたため、依然として有意義な節約にはなっているかもしれませんが、そのプロセスを数万件のトランザクションにわたって実行すれば、結局はかなりの規模の手動運用を残すことになります。ボトルネックが解消されたのではなく、移動しただけです。
ここで、エージェント型AIを取り巻く、より「安全」な言葉遣いの一部が、自動化の経済性と衝突し始めます。ソフトウェアにプロセスから作業を取り除いてもらうために「自律性」を導入しながら、その自律性に十分な不安を感じるがゆえに、結局すべてのトランザクションに再び人間を配置してしまうのです。
最終的には、それでは自動化の意味がほとんど失われてしまいます。
返金が20ポンドで、ルールが明確であり、関連するすべてのシステムが一致し、そのアクションを簡単に取り消せるのであれば、誰も承認する必要はないかもしれません。金額が20,000ポンドであったり、2つのシステムが食い違っていたり、状況が通常のパラメータから外れている場合は、誰かを関与させるべき絶好のタイミングです。
したがって、多くのプロセスにおいて、役立つ目的地は「プロセスに常に人間が関与する（Human in the loop）」ではなく、「例外時に人間が関与する（Human by exception）」ことでしょう。ルーチン化された、よく理解されている作業はますます自律的になり、一方で、珍しい、曖昧な、または結果の影響が大きいケースは人間へとエスカレーションされます。
これには、自律性を段階的に導入する余地が十分にあります。エージェントは、観察と推奨から始めることができます。その動作が理解されたら、承認用のアクションを準備させることができます。最終的には、ルーチン化され、取り消し可能な特定クラスのアクションを自動的に実行させ、プロセスが合意されたしきい値を超えたときに人間が関与するようにします。
OpenAIのガイダンスも、同様のリスクベースのアプローチをとっています。エージェントが定義された失敗のしきい値を超えた場合や、多額の返金や支払いなど、機密性が高く、不可逆的で、リスクの高いアクションの周囲では、人間の介入を推奨しています。
PocketOSは、かなり実務的な方向からこれと同じ問題に直面しました。データベースの事故を受け、現在、破壊的な操作には人間による明示的な確認が必要となっています。同社は自律型エージェントの利用をあきらめるという対応はしませんでした。本番環境で引き続き多数の限定的な自律型エージェントを実行しながら、制御境界の配置場所を変更したと述べています。
これこそが、人間の監視について考えるためのより有益な方法であると私は思います。それは、結果がそれを正当化する場所に適用されるべき「統制」であり、自律型ソフトウェアによって実行されるすべての行動に対する永続的な運用モデルである必要はありません。
結局のところ、自動化のポイントは「自動化すること」です。設計上の問題は、人間がどこで真に成果を向上させるのか、そして、単にシステムをまだ十分に信頼していないという理由だけで人間が維持されているのはどこなのかを判断することです。
追跡可能性のない自律性は、運用上正当化できない
「例外時に人間が関与する」方向へ進むと、別のことの重要性が低下するのではなく、むしろ高まります。それは、エージェントが「実際に何をしたのか」を理解することです。
Hugging Faceの調査は、有益な極端な例です。そのフォレンジック再現は、数千のクラスターにわたる約17,600件のアクションを対象とし、調査員はエージェントがどのようにシステム内を移動し、時間の経過とともにどのように行動を適応させたかをつなぎ合わせました。
これを通常のビジネスプロセスに落とし込んでみましょう。顧客が「アカウントの何かが誤って変更された」と主張し、調査した結果、エージェントがその変更を行ったことが判明したとします。
インシデントレビューにおいて、「AIがそれをやった」という説明だけでは、ほとんど通用しないでしょう。
どのエージェントが行動したのか、誰がそのタスクを開始したのか、どの情報を使用したのか、その時点でその情報に何が含まれていたのか、どのツールを呼び出したのか、そして最終的にどの権限がその変更を許容したのかを知りたくなるはずです。その過程で別のエージェントが関与した場合は、それもおそらく重要になります。
ここにおいて、AIエージェントの監査可能性は、ガバナンス上の「あると良いもの」から「運用上の必須要件」へと変化します。実行における直接的な人間の関与が少なくなればなるほど、それを取り巻く観察可能性（オブザーバビリティ）を強化する必要があります。
Microsoftの現在のガイダンスでは、エージェントのアイデンティティ、その役割と有効なスコープ、実行されたアクション、影響を受けたリソース、およびそのエージェントが代理で行動していたユーザーを記録することを推奨しています。NISTも同様に、エージェントのアイデンティティと認可の問題の一部として、監査と否認防止を明示的に検討しています。
これは、すべての自律的なアクションを誰かが監視する必要があるという意味ではありません。私たちはすでに、すべてのトランザクション、インフラのイベント、またはネットワークリクエストの前に人間を置くことなく、巨大な自動化環境を運用しています。制限、統制、監視を設定し、そこから外れたものを調査します。
成熟したエージェントシステムがそれと異なる仕組みで動作すべき明確な理由はありません。
自律性は監視を排除するものではありません。監視が「いつ」行われるかを変えるだけです。
委譲された意図が、信頼の境界を複雑にする
もう1つ、注目に値する展開があります。それがこの問題をさらに興味深いものにしています。
エージェントは、他のエージェントと対話し、コラボレーションするようにますます設計されています。GoogleのAgent2Agentプロトコルは、異なるチームによって、また異なる技術スタック上に構築されたエージェントを含め、エージェント同士がどのように相互を検出し、通信できるかを標準化しています。その新しいAgentic Resource Discoveryの取り組みは、チーム、組織、プラットフォームに分散されたツール、スキル、および他のエージェントを、エージェントがどのように見つけて検証できるかという関連する問いに対処しています。
社内のエージェントがタスクを受け取り、別の専門エージェントがその一部を実行できると判断したと想像してください。その2番目のエージェントは、あなたのサービスの1つを呼び出し、最終的に何かを変更するツールを使用します。
誰が行動しているのでしょうか？
2番目のエージェントでしょうか？最初のエージェントでしょうか？それとも、元のタスクを開始した人間でしょうか？
最初のエージェントがアクションを実行する権限を与えられている場合、その権限を委譲できるでしょうか？2番目のエージェントはその権限のすべてを受け取るのか、一部を受け取るのか、あるいはまったく受け取らないのか？エージェントが異なる組織に属している場合はどうなるでしょうか？
これらは新たに出現した問いであり、業界がこれらすべての答えについて合意に達したと見なすのは時期尚早でしょう。NISTのAI Agent Standards Initiativeは、安全な人間とエージェント、およびマルチエージェント間の対話をサポートするために、エージェントの認証とアイデンティティインフラに関する取り組みを明示的に実施しています。
しかし、その方向性は重要です。歴史的に、信頼は既知のユーザー、アプリケーション、またはインテグレーションと関連付けられてきました。エージェントが動的に機能を検出し、目的の一部を他の場所に委譲できるようになると、信頼と権限はそのプロセスを越えて維持される必要があります。
タスクは動的になり得ます。しかし、別の境界を越えるたびに説明責任が消えてしまうことがあってはなりません。
エージェント型トランスフォーメーションは、テクノロジーではなく「委譲」から始めるべきである
変革に携わるほとんどの人が認識しているであろう、重要なテクノロジーシフトに伴うパターンがあります。何かが戦略的に重要になり、誰かが組織にそれが必要だと決定し、全員がそれを適用する場所を探し始めるというパターンです。
「AI戦略が必要だ。エージェントのユースケースがいくつか必要だ。ワークショップを開催しよう。どのプロセスをエージェント型にできるか？」
私なら、おそらく逆のアプローチをとります。
まずは、全員をイライラさせているプロセスから始めましょう。時間がかかり、コストがかさみ、断片化されているか、あるいは、誰かが一日中システム間で情報を転記することに依存しているようなプロセスです。意思決定がどこで行われているか、それらの意思決定がどの情報に依存しているか、どのシステムが関与しているか、厄介な例外がどこで発生するか、そして何かがうまくいかなかったときに何が起こるかを理解するのです。
次に、そのプロセスに携わっている人々が実際に何をしているかを見てみましょう。彼らは価値ある判断を下しているのでしょうか、それとも周囲のテクノロジーの限界を補っているだけでしょうか？彼らが何かを承認しているのは、真の財務的または運用上のリスクがあるからでしょうか、それともワークフローがルーチンケースと異常なケースを区別できないからでしょうか？彼らが手動で情報を調整しているのは、組織が真に彼らの専門知識を必要としているからでしょうか、それとも2つのシステムが異なる識別子を使用しているからでしょうか？
これらはまったく異なる問題です。
それを理解した上で、何を「委譲」する用意があるかを決定します。ソフトウェアはどの意思決定を行えるか？どのようなアクションを実行できるか？どれが取り消し可能か？エスカレーションはどこで必要か？それにはどのような権限が必要か？後で意思決定の理由を尋ねられた場合、どのような証拠が必要になるか？
テクノロジーの選択が特に興味深いものになるのは、それらが明確になってからです。
エージェントは優れた答えになるかもしれません。そうではないかもしれません。それで構いません。エージェントの設計に関する現在のガイダンスでも、ほぼ同様の区別がなされています。エージェントは、曖昧さ、複雑な意思決定、または非構造化データによって、一意に決まる（決定論的）アプローチが困難になるワークフローに適していますが、それらの特性がない場所では、従来の自動化で依然として十分に足りる可能性があります。
目的はエージェントをデプロイすることではありません。ビジネスを改善することです。
自動化のアーキテクチャは、権限のアーキテクチャになりつつある
過去20年間、デジタルトランスフォーメーションは主に、人とシステム、およびシステム同士を接続することを伴ってきました。現在、私たちはその資産の中に新たな参加者を導入し始めています。それは、目的を受け取り、それをどのように追求するかを判断し、私たちの代理としてそれらのシステムを使用できるソフトウェアです。
これには、特に従来の自動化を拒んできた調整作業の周囲において、真に興味深い可能性が秘められています。NIST自体も、エージェントが生産性、効率性、および意思決定を向上させる可能性について説明する一方で、それらのエージェントに組織のデータ、ツール、およびアプリケーションへのアクセス権が与えられる際には、適切な識別と認可の管理が必要であることを強調しています。
この組み合わせは重要だと私は考えています。機会とリスクは同じ特性から生じています。それは、エージェントが「仕事がどのように行われるかを決定する一定の自由」を持っているという点です。
それが始まると、アーキテクチャの関心事は、単にあるシステムが別のシステムに接続できるかどうかだけにとどまらなくなります。どの自律的な実行者が、誰の権限のもと、どのような制限のもと、どのような証拠を残しながら、どの情報を使用し、どの機能を実行できるかを決定する重要性がますます高まります。
したがって実務において、エンタープライズAIエージェントのガバナンスが、イントラネットのどこかにある別のポリシー文書によって解決される可能性は低いです。それは、私たちが作成するアイデンティティ、付与する権限、結果を伴うアクションの周囲の統制、エージェントが消費するデータの品質と出所、私たちが設計するエスカレーションパス、そしてその後に維持する監査証拠の中に現れなければなりません。
Hugging Faceは、自律型ソフトウェアがそのオペレーターの予想しなかったルートを見つけ出すという、極端な例を示してくれています。PocketOSは、エージェントがタスクの必要性を超えた権限を持っている場合に何が起こるかという、はるかに日常的な例を示してくれています。エージェントのアイデンティティ、最小権限、安全なマルチエージェント対話、および信頼できるリソース検出に関する新たな取り組みは、周囲の管理モデルがすでにその能力に追いつかなければならなくなっていることを示しています。
これらはどれも、エージェント型AIに反対する論拠ではありません。まったく逆です。エージェントが、現代のデジタルビジネスを運営する上でコストがかさみ、煩雑にしている人間による調整作業の一部を取り除くことができるのであれば、それらを追求する非常に具体的な理由が存在します。
しかし、自律的な実行者を既存のデジタル資産に導入することは、単なるもう1つのAIの実装ではありません。それは、アイデンティティ、信頼、データ、説明責任、そして最終的には権限に関する前提条件を変化させます。
ですから、エージェントに何ができるかを尋ねる前に、私は別の質問から始めたいと思います。
あなたは、エージェントに「実際に何をさせる」用意がありますか？
AIが権限を持つとき
ここ数年、企業はジェネレーティブAIが何を示してくれるかという点に注目してきました。AIエージェントの登場は、より重大な問いを投げかけています。それは、ソフトウェアが「次に何をすべきか」を判断し、それを「実際に実行する」ことができるようになったとき、何が起こるかという問題です。
2026年7月、OpenAIのサイバーセキュリティ評価の一環として使用されていたAIエージェントが、Hugging Faceの本番環境インフラの一部を侵害しました。ただ、ここで興奮しすぎる前に、重要な背景情報を整理しておく必要があります。これは、通常のビジネスアプリケーションが突如として他社を攻撃し始めたというケースではありません。OpenAIは意図的に、高度な機能を持つモデルに対して困難なサイバーセキュリティ課題をテストしており、通常はモデルが高リスクのサイバー活動を追求するのを防ぐために使用される本番用分類器が、評価のために意図的に無効にされていたのです。
そうだとしても、何が起こったのかは注目に値します。その後の調査によると、エージェントはHugging Faceが保持する情報が、与えられたベンチマークを完了するのに役立つと判断したようです。エージェントは評価環境が使用していたインフラ内のゼロデイ脆弱性を突いて抜け出し、より広いインターネットアクセスを獲得し、他の攻撃パスを連鎖させ、資格情報を取得して、最終的にHugging Faceのシステムに到達しました。Hugging Faceのフォレンジック再現によると、約17,600件の個別のアクションが対象となり、それらは約6,280のクラスターにグループ化されていました。
当然ながら、「AIが脱走した」または「AIが暴走した」という見出しを付けたくなる誘惑に駆られます。しかし、それが特に有益な見方だとは思いません。調査で明らかになった限りでは、ソフトウェアは与えられた目的を達成しようとして、誰も予想しなかったルートを見つけただけでした。Hugging Faceは、エージェントがベンチマーク情報や解決策があると考えた本番システムにアクセスすることで、事実上、評価を「ごまかそう」としたのだろうと考えています。
これは劇的なストーリーとしては劣りますが、デジタルトランスフォーメーションの観点からはおそらくより重要な出来事です。
ここ数年、ほとんどの組織にとってジェネレーティブAIは「質問する相手」でした。情報を与え、質問をし、何かを返してもらう。契約書を要約したり、データを分析したり、コードを書いたり、メールの下書きを作成したりすることはあっても、その先で「次に何をするか」を決めるのは一般的にまだ人間でした。
エージェントはその境界線を曖昧にし始めます。これと同じインテリジェンスにツールへのアクセス権を与えれば、情報の取得、APIの呼び出し、レコードの更新、コードの実行、メールの送信、あるいは変更自体をエージェント自身で行うことができます。OpenAIもエージェントをほぼ同様に説明しています。すなわち、ユーザーに代わってワークフローの実行を自律的に管理し、意思決定を行い、適切なツールを選択し、外部システムと対話できるシステムです。
チャットボットが「書き込み権限」を手に入れたのです。
このシフトこそが、AIエージェントのガバナンスが、単なるポリシーに関する議論ではなく、実践的なエンタープライズの課題になりつつある理由です。ソフトウェアが「推奨する」だけでなく「行動を起こす」ことができるようになると、アイデンティティ、権限、統制、監査可能性、および説明責任に関する問いが、アーキテクチャそのものの内部へと移行します。
ソフトウェアに「指示」ではなく「意図」が与えられると、自動化が変わる
ソフトウェアは何十年もの間、物事を変え続けてきたため、ここで何が新しいのかを誇大広告してしまう危険性があります。データベースを更新したり、APIを起動したり、ワークフローを実行したりするのにAIは必要ありません。スクリプト、ルールエンジン、オーケストレーションプラットフォーム、自動化プロセスは、何年もの間、それらのタスクを申し分なくこなしてきました。
違いは、目的から行動に至るまでのプロセスにあります。従来の自動化は、通常、誰かが事前に定義したルートに沿って設計されています。Xが発生した場合はYを取得する。答えがZの場合はこのアクションを実行する。そこには何百ものルール、分岐、例外が関わっているかもしれませんが、それでも誰かが事前にそのプロセスをモデル化しようとしていたのです。
エージェントによって、ソフトウェアに目的を達成するためのすべての指示を与えるのではなく、「結果」を提示する方向へと、さらに進むことが可能になります。「必要な情報を特定すること。適切なツールを決定すること。戻ってきた結果に対処し、仕事を完了させること」というようにです。
この違いが重要なのは、実行パスが動的になり得るからです。エージェントはあるシステムから処理を開始し、追加のコンテキストが必要であることに気づき、別のシステムを呼び出し、予期しない結果に遭遇すると、アプローチを修正して処理を続行するかもしれません。現在のエージェントアーキテクチャは、タスクの状態に応じて、ワークフローを管理し、ツールを選択し、アクションを実行するこの能力を中心に明示的に構築されています。
これは、従来の自動化とは本質的に異なる命題です。ソフトウェアはもはや、単に事前に決定されたフローを実行しているだけではありません。その周囲に設定したどのような境界線の内部であれ、そのフローがどのように展開するかについて、ソフトウェアに一定の裁量を与えていることになります。
そして、これこそが、AIがより優れたメールを書けるかどうかという話よりも、はるかに興味深いポイントです。
機会は「人」ではなく「調整作業」を排除することにある
組織内の仕事の驚くほど多くの部分が、個々のタスクが特別に複雑だから難しいわけではありません。タスク間で必要となる「調整作業」のせいで難しいのです。
CRMを開き、顧客を見つける。識別子を課金プラットフォームにコピーする。メモを読む。別のシステムをチェックする。それらが何を意味しているかを理解する。別のチームにこれが正常な状態かどうかを尋ねる。返答を待つ。最初のプラットフォームを更新し、顧客にメールを送信する。
聞き覚えはありませんか？
私たちは何年もかけてそれらのプロセスを自動化しようとしてきました。ステップが予測通りに説明できる場合、従来のワークフロー技術は極めて効果的です。難しい部分となるのは例外事項です。適切に構造化されていないドキュメント、完全には一致しないアカウント、互いに食い違う3つのシステム、あるいは次に何をすべきかを知る前に、誰かが何かを読み取ってその意味を理解する必要があるプロセス上のポイントなどです。
それらこそが、エージェントが役に立つ可能性のあるワークフローです。OpenAIの現在のガイダンスでは、複雑な意思決定、維持が困難なルール、および非構造化情報への強い依存がある領域を、従来の一意に決まる自動化（決定論的自動化）では提供できない、エージェント型アプローチが何かを提供できる領域として明確に特定しています。また、それらの特性がない場合は、一意に決まる解決策の方が依然として優れた答えになり得るという重要な点も指摘しています。
ソフトウェアがシステム、情報、意思決定の間の調整作業の一部を引き受けることができれば、そこには実質的で大きな効率性の向上が見込めます。それは、プロセスに関わるすべての人々が突然いなくなるからではなく、本来お互いを調整するのがそれほど得意ではないプラットフォーム同士の間で、人間を「高価なミドルウェア」として使用するのをやめることができるからです。
そこには重要な違いがあります。目標は、必ずしも組織から人間を排除することであってはなりません。人々の足元にあるテクノロジーがコンテキスト、曖昧さ、または例外をうまく処理できないという理由だけで、現在人々に強いている作業を排除することであるべきです。
だからこそ、エージェントがもたらす機会は、漸進的な生産性の向上よりもはるかに重要であると私は考えています。顧客への返信の下書きを10秒早く作成できることは便利です。しかし、ソフトウェアに問題を調査させ、関連情報を調整させ、プロセスを前に進めさせることは、それとはまったく異なるレベルの話です。
もちろん、プロセスを先へ進めれば進めるほど、最終的には結果を伴うアクションに近づいていきます。
そして、そこから事態ははるかに複雑になります。
能力（Capability）は権限（Authority）ではない
Hugging Faceの出来事の数ヶ月前、PocketOSはAIエージェントが会社のステージング（本番）データベースを削除してしまったという、ありのままの報告書を公開しました。削除にかかった時間は9秒、復旧には60時間かかりました。バックアップは存在していましたが、バックアッププロセスがいつの間にか停止していたため、3ヶ月前の古いものでした。
PocketOSも、これが単なる「AIの問題」ではないことを非常に明確にしています。同社は、破壊的なアクションに対する十分な摩擦（障壁）が存在しない環境に対し、エージェントが本来持つべきではない権限を使用して、確信を持って行動したと述べています。
これは有益な教訓です。
人間は何年も前から本番データベースを誤って削除してきましたし、ソフトウェアのバグもそれに少なからぬ貢献をしてきました。興味深いのは、その実行者が、その過失が重大な問題になるほどの十分な権限を持っていたという点です。
実行者が人間である場合、私たちはすでにこのことを理解しています。カスタマーサービスの担当者は、誰も気に留めないような20ポンドの返金を処理する権限を持っているかもしれません。200ポンドでもまだ妥当な範囲内でしょう。しかし、20,000ポンドになると、おそらく別の承認プロセスが必要になります。
同じことが他の場所にも当てはまります。コンテンツのメタデータ内のスペルミスをエージェントが特定して修正することは、おそらく十分に無害です。もし、エージェントが変更しようとしているフィールドが、そのコンテンツを特定の地域で配信できるかどうかを決定するものである場合、その結果は大きく異なります。同様に、エージェントが本番環境の設定の問題を正しく特定したからといって、その環境全体を再設定する無制限の権利をエージェントが引き継ぐべきだということにはなりません。
これらはどれも、特に風変わりな話ではありません。これは新しいタイプの実行者に適用された「アイデンティティとアクセス管理」であり、効果的なエージェント型AIガバナンスの基盤の1つになると私は考えています。
Microsoftはすでに、エージェントをこのような観点から扱っています。同社の現在のガイダンスでは、ユニークで専用のAIエージェントアイデンティティ、指名されたオーナーまたはスポンサー、明確に文書化された目的とデータアクセス、最小権限アクセス、制御されたツール権限、ロギング、および検証済みの権限取り消しパスを推奨しています。同じ領域におけるNIST（米国国家規格技術研究所）の取り組みでも、AIエージェントの識別、認可、監査、および否認防止について明示的に調査が行われています。
実務的な観点から言えば、これはAIエージェントの権限を、特権を持つ人間のアカウントやサービスアカウントと同じ真剣さで扱う必要があることを意味します。エージェントは、何が起こるべきかを判断する完璧な能力を持っていたとしても、それを実現する権限を与えられているとは限りません。
この違いは重要です。AIエージェントの統制において、単にモデルがアクションを物理的・技術的に実行できるかどうかを問うだけでは不十分です。この特定のコンテキストで動作しているこの特定のエージェントが、そのアクションを実行することを「認可されているか」を判断する必要があります。
余談ですが、AIエージェントの乱立（スプロール現象）は、誰かが最終的に「実際に何個のエージェントが動いているのか？」と尋ねるまで、組織が気づかない問題の1つになるのではないかと考えています。私たちは、SaaSアプリケーション、クラウドのリソース、サービスアカウント、APIキーなどで、すでにこれと似たような問題を経験してきました。エージェントの資産が、それらよりもうまく自然に整理されると考える明確な理由はありません。特に、実験的な取り組みが意図的に各チームに分散されている企業においてはなおさらです。
これは、すべてのAIイニシアチブを中央集権化すべきだという意味ではありません。中央のチームがすべてのプロセスを十分に理解し、すべての有用なアプリケーションを自ら特定できる可能性は低いため、分散型のイノベーションは完全に理にかなっています。
しかし、結果として生じてしまう「予期せぬ権限の分散」は別問題です。
エージェント型AIは、デジタル資産における既存のすべての「妥協」を引き継ぐ
これらすべての根底には、もう1つの厄介な問題があります。エージェントは、既存のデジタル資産をそのまま引き継ぐことになるということです。
輝かしい新技術のAPI、レガシーシステム、一貫性のない顧客レコード、8年前に誰かが書き、誰も手を触れたがらないインテグレーション、そしてあるプラットフォームでは顧客を一つの名前で呼び、別のプラットフォームでは異なる名前で呼んでいるシステム。企業が成長し、プラットフォームが買収され、チームが個別の問題を解決し、買収が発生し、サプライヤーが変わり、優先順位が移り変わります。そして最終的に、誰もが「現在のアーキテクチャ」と丁重に呼ぶものに行き着くのです。
ここで、サービス料金を支払ったにもかかわらず、アクセスできないという顧客を処理するエージェントを想像してみてください。実際に何が起こったのかを誰かが判断できるようになるまでに、CRM、課金、認証、エンタイトルメント（利用資格）、サポートシステムからの情報が必要になる場合があります。
人間のオペレーターであれば、それらの一貫性のなさをほとんど考えることなく処理することがよくあります。彼らは、あるシステムが別のシステムより先に更新されることを知っています。識別子がわずかに異なっていることに気づきます。もしかしたら、古いパッケージの顧客は異なる挙動をすることを覚えているかもしれません。あるいは、ドキュメントが2023年以降更新されていないため、単に隣に座っている人に尋ねるかもしれません。
その仕事をエージェントに与える場合、それらの前提条件がどこかに存在していなければなりません。どのシステムが信頼できる情報源（オーソリティ）なのか？課金システムは支払いが成功したと言っているのに、エンタイトルメントプラットフォームはアカウントが無効だと言っている場合、どうすればいいのか？情報が間違っているのか、それともエージェントが理解していないビジネスルールがあるのか？単にあるプラットフォームが5分遅れているだけなのか？
これらは、新たな消費者（エージェント）を迎えた、古いデータとアーキテクチャの問題です。本質的な違いは、この新しい消費者が、自ら到達した結論に基づいて「アクションを起こす」可能性があるという点です。
チャットボットに与えられるデータが貧弱であれば、悪い回答が生成される可能性があります。自律型ソフトウェアに与えられるデータが貧弱であれば、悪い「結果」がもたらされる可能性があります。
さらに、もう1つの複雑な要素もあります。情報が必ずしも「偶然」間違っているとは限らないという点です。7月に発表された研究では、攻撃者が管理する情報が、一見正当なコンテキストデータとして提示され、エージェントがその後に実行する行動に影響を与えるという「エージェントデータインジェクション攻撃」が実証されました。研究者らは、実際のWebエージェントやコーディングエージェントにおける脆弱性を特定し、意図しないクリック、リモートコード実行、ソフトウェアサプライチェーンにおけるアクションが引き起こされる可能性があることを示しました。
これにより、データアーキテクチャとセキュリティの間に、厄介なクロスオーバー（交差）が生じます。情報がアクションに影響を与える可能性がある場合、その情報がどこから来たのか、信頼できるのか、そしてエージェントがそれにどれだけの重みを置くべきなのかは、もはや抽象的なガバナンスの懸念事項ではありません。それらは実行モデルの一部となります。
これが、「エージェントの存在によって、技術的負債の重要性が何らかの形で低下する」という考え方に私が慎重になる理由でもあります。エージェントは、固定されたインテグレーションパスに完全に依存するのではなく、タスクについて推論できるため、断片化された環境の操作を容易にするかもしれませんが、それでもシステムへのアクセス、使用可能なインターフェース、意味のあるデータ、適切な権限、そして処理の途中で何かが失敗したときにどうすべきかというアイデアを必要とします。
APIが存在しない場合、エージェントは別のアクセス方法を必要とします。同じ顧客に6つの識別子がある場合、人間または何らかの仕組みが、それらが同一人物を表しているかどうかを特定する必要があります。文書化されていないビジネスルールが意思決定に影響を与える場合、その知識がどこかで利用可能である必要があります。
散らかった資産の前にインテリジェントなオーケストレーションレイヤーを置いたからといって、その資産が散らかっているのをやめるわけではありません。その散らかった状態を移動しやすくはなるかもしれませんが、同時に、その散らかった状態がもたらす結果がはるかに速く伝播することにもなりかねません。
人間の監視には経済的コストが伴う
この段階になると、ほとんどの議論において「プロセスには常に人間が関与する（Human in the loop）」と言う人が現れます。
それは心強く聞こえますが、明白な疑問を生じさせます。もし誰かが依然としてエージェントの行うすべてのことをレビューし、承認する必要があるのだとしたら、私たちは実際にどれだけの自動化を達成できたと言えるのでしょうか？
カスタマーサービスのエージェントが5つのシステムをチェックし、アカウントの問題を特定し、顧客に誤って請求が行われていたことを突き止め、20ポンドの返金が適切であると計算したと想像してください。その後、エージェントは誰かが「承認」をクリックするためのキューにそのプロセス全体を投入します。
調査自体が自動化されたため、依然として有意義な節約にはなっているかもしれませんが、そのプロセスを数万件のトランザクションにわたって実行すれば、結局はかなりの規模の手動運用を残すことになります。ボトルネックが解消されたのではなく、移動しただけです。
ここで、エージェント型AIを取り巻く、より「安全」な言葉遣いの一部が、自動化の経済性と衝突し始めます。ソフトウェアにプロセスから作業を取り除いてもらうために「自律性」を導入しながら、その自律性に十分な不安を感じるがゆえに、結局すべてのトランザクションに再び人間を配置してしまうのです。
最終的には、それでは自動化の意味がほとんど失われてしまいます。
返金が20ポンドで、ルールが明確であり、関連するすべてのシステムが一致し、そのアクションを簡単に取り消せるのであれば、誰も承認する必要はないかもしれません。金額が20,000ポンドであったり、2つのシステムが食い違っていたり、状況が通常のパラメータから外れている場合は、誰かを関与させるべき絶好のタイミングです。
したがって、多くのプロセスにおいて、役立つ目的地は「プロセスに常に人間が関与する（Human in the loop）」ではなく、「例外時に人間が関与する（Human by exception）」ことでしょう。ルーチン化された、よく理解されている作業はますます自律的になり、一方で、珍しい、曖昧な、または結果の影響が大きいケースは人間へとエスカレーションされます。
これには、自律性を段階的に導入する余地が十分にあります。エージェントは、観察と推奨から始めることができます。その動作が理解されたら、承認用のアクションを準備させることができます。最終的には、ルーチン化され、取り消し可能な特定クラスのアクションを自動的に実行させ、プロセスが合意されたしきい値を超えたときに人間が関与するようにします。
OpenAIのガイダンスも、同様のリスクベースのアプローチをとっています。エージェントが定義された失敗のしきい値を超えた場合や、多額の返金や支払いなど、機密性が高く、不可逆的で、リスクの高いアクションの周囲では、人間の介入を推奨しています。
PocketOSは、かなり実務的な方向からこれと同じ問題に直面しました。データベースの事故を受け、現在、破壊的な操作には人間による明示的な確認が必要となっています。同社は自律型エージェントの利用をあきらめるという対応はしませんでした。本番環境で引き続き多数の限定的な自律型エージェントを実行しながら、制御境界の配置場所を変更したと述べています。
これこそが、人間の監視について考えるためのより有益な方法であると私は思います。それは、結果がそれを正当化する場所に適用されるべき「統制」であり、自律型ソフトウェアによって実行されるすべての行動に対する永続的な運用モデルである必要はありません。
結局のところ、自動化のポイントは「自動化すること」です。設計上の問題は、人間がどこで真に成果を向上させるのか、そして、単にシステムをまだ十分に信頼していないという理由だけで人間が維持されているのはどこなのかを判断することです。
追跡可能性のない自律性は、運用上正当化できない
「例外時に人間が関与する」方向へ進むと、別のことの重要性が低下するのではなく、むしろ高まります。それは、エージェントが「実際に何をしたのか」を理解することです。
Hugging Faceの調査は、有益な極端な例です。そのフォレンジック再現は、数千のクラスターにわたる約17,600件のアクションを対象とし、調査員はエージェントがどのようにシステム内を移動し、時間の経過とともにどのように行動を適応させたかをつなぎ合わせました。
これを通常のビジネスプロセスに落とし込んでみましょう。顧客が「アカウントの何かが誤って変更された」と主張し、調査した結果、エージェントがその変更を行ったことが判明したとします。
インシデントレビューにおいて、「AIがそれをやった」という説明だけでは、ほとんど通用しないでしょう。
どのエージェントが行動したのか、誰がそのタスクを開始したのか、どの情報を使用したのか、その時点でその情報に何が含まれていたのか、どのツールを呼び出したのか、そして最終的にどの権限がその変更を許容したのかを知りたくなるはずです。その過程で別のエージェントが関与した場合は、それもおそらく重要になります。
ここにおいて、AIエージェントの監査可能性は、ガバナンス上の「あると良いもの」から「運用上の必須要件」へと変化します。実行における直接的な人間の関与が少なくなればなるほど、それを取り巻く観察可能性（オブザーバビリティ）を強化する必要があります。
Microsoftの現在のガイダンスでは、エージェントのアイデンティティ、その役割と有効なスコープ、実行されたアクション、影響を受けたリソース、およびそのエージェントが代理で行動していたユーザーを記録することを推奨しています。NISTも同様に、エージェントのアイデンティティと認可の問題の一部として、監査と否認防止を明示的に検討しています。
これは、すべての自律的なアクションを誰かが監視する必要があるという意味ではありません。私たちはすでに、すべてのトランザクション、インフラのイベント、またはネットワークリクエストの前に人間を置くことなく、巨大な自動化環境を運用しています。制限、統制、監視を設定し、そこから外れたものを調査します。
成熟したエージェントシステムがそれと異なる仕組みで動作すべき明確な理由はありません。
自律性は監視を排除するものではありません。監視が「いつ」行われるかを変えるだけです。
委譲された意図が、信頼の境界を複雑にする
もう1つ、注目に値する展開があります。それがこの問題をさらに興味深いものにしています。
エージェントは、他のエージェントと対話し、コラボレーションするようにますます設計されています。GoogleのAgent2Agentプロトコルは、異なるチームによって、また異なる技術スタック上に構築されたエージェントを含め、エージェント同士がどのように相互を検出し、通信できるかを標準化しています。その新しいAgentic Resource Discoveryの取り組みは、チーム、組織、プラットフォームに分散されたツール、スキル、および他のエージェントを、エージェントがどのように見つけて検証できるかという関連する問いに対処しています。
社内のエージェントがタスクを受け取り、別の専門エージェントがその一部を実行できると判断したと想像してください。その2番目のエージェントは、あなたのサービスの1つを呼び出し、最終的に何かを変更するツールを使用します。
誰が行動しているのでしょうか？
2番目のエージェントでしょうか？最初のエージェントでしょうか？それとも、元のタスクを開始した人間でしょうか？
最初のエージェントがアクションを実行する権限を与えられている場合、その権限を委譲できるでしょうか？2番目のエージェントはその権限のすべてを受け取るのか、一部を受け取るのか、あるいはまったく受け取らないのか？エージェントが異なる組織に属している場合はどうなるでしょうか？
これらは新たに出現した問いであり、業界がこれらすべての答えについて合意に達したと見なすのは時期尚早でしょう。NISTのAI Agent Standards Initiativeは、安全な人間とエージェント、およびマルチエージェント間の対話をサポートするために、エージェントの認証とアイデンティティインフラに関する取り組みを明示的に実施しています。
しかし、その方向性は重要です。歴史的に、信頼は既知のユーザー、アプリケーション、またはインテグレーションと関連付けられてきました。エージェントが動的に機能を検出し、目的の一部を他の場所に委譲できるようになると、信頼と権限はそのプロセスを越えて維持される必要があります。
タスクは動的になり得ます。しかし、別の境界を越えるたびに説明責任が消えてしまうことがあってはなりません。
エージェント型トランスフォーメーションは、テクノロジーではなく「委譲」から始めるべきである
変革に携わるほとんどの人が認識しているであろう、重要なテクノロジーシフトに伴うパターンがあります。何かが戦略的に重要になり、誰かが組織にそれが必要だと決定し、全員がそれを適用する場所を探し始めるというパターンです。
「AI戦略が必要だ。エージェントのユースケースがいくつか必要だ。ワークショップを開催しよう。どのプロセスをエージェント型にできるか？」
私なら、おそらく逆のアプローチをとります。
まずは、全員をイライラさせているプロセスから始めましょう。時間がかかり、コストがかさみ、断片化されているか、あるいは、誰かが一日中システム間で情報を転記することに依存しているようなプロセスです。意思決定がどこで行われているか、それらの意思決定がどの情報に依存しているか、どのシステムが関与しているか、厄介な例外がどこで発生するか、そして何かがうまくいかなかったときに何が起こるかを理解するのです。
次に、そのプロセスに携わっている人々が実際に何をしているかを見てみましょう。彼らは価値ある判断を下しているのでしょうか、それとも周囲のテクノロジーの限界を補っているだけでしょうか？彼らが何かを承認しているのは、真の財務的または運用上のリスクがあるからでしょうか、それともワークフローがルーチンケースと異常なケースを区別できないからでしょうか？彼らが手動で情報を調整しているのは、組織が真に彼らの専門知識を必要としているからでしょうか、それとも2つのシステムが異なる識別子を使用しているからでしょうか？
これらはまったく異なる問題です。
それを理解した上で、何を「委譲」する用意があるかを決定します。ソフトウェアはどの意思決定を行えるか？どのようなアクションを実行できるか？どれが取り消し可能か？エスカレーションはどこで必要か？それにはどのような権限が必要か？後で意思決定の理由を尋ねられた場合、どのような証拠が必要になるか？
テクノロジーの選択が特に興味深いものになるのは、それらが明確になってからです。
エージェントは優れた答えになるかもしれません。そうではないかもしれません。それで構いません。エージェントの設計に関する現在のガイダンスでも、ほぼ同様の区別がなされています。エージェントは、曖昧さ、複雑な意思決定、または非構造化データによって、一意に決まる（決定論的）アプローチが困難になるワークフローに適していますが、それらの特性がない場所では、従来の自動化で依然として十分に足りる可能性があります。
目的はエージェントをデプロイすることではありません。ビジネスを改善することです。
自動化のアーキテクチャは、権限のアーキテクチャになりつつある
過去20年間、デジタルトランスフォーメーションは主に、人とシステム、およびシステム同士を接続することを伴ってきました。現在、私たちはその資産の中に新たな参加者を導入し始めています。それは、目的を受け取り、それをどのように追求するかを判断し、私たちの代理としてそれらのシステムを使用できるソフトウェアです。
これには、特に従来の自動化を拒んできた調整作業の周囲において、真に興味深い可能性が秘められています。NIST自体も、エージェントが生産性、効率性、および意思決定を向上させる可能性について説明する一方で、それらのエージェントに組織のデータ、ツール、およびアプリケーションへのアクセス権が与えられる際には、適切な識別と認可の管理が必要であることを強調しています。
この組み合わせは重要だと私は考えています。機会とリスクは同じ特性から生じています。それは、エージェントが「仕事がどのように行われるかを決定する一定の自由」を持っているという点です。
それが始まると、アーキテクチャの関心事は、単にあるシステムが別のシステムに接続できるかどうかだけにとどまらなくなります。どの自律的な実行者が、誰の権限のもと、どのような制限のもと、どのような証拠を残しながら、どの情報を使用し、どの機能を実行できるかを決定する重要性がますます高まります。
したがって実務において、エンタープライズAIエージェントのガバナンスが、イントラネットのどこかにある別のポリシー文書によって解決される可能性は低いです。それは、私たちが作成するアイデンティティ、付与する権限、結果を伴うアクションの周囲の統制、エージェントが消費するデータの品質と出所、私たちが設計するエスカレーションパス、そしてその後に維持する監査証拠の中に現れなければなりません。
Hugging Faceは、自律型ソフトウェアがそのオペレーターの予想しなかったルートを見つけ出すという、極端な例を示してくれています。PocketOSは、エージェントがタスクの必要性を超えた権限を持っている場合に何が起こるかという、はるかに日常的な例を示してくれています。エージェントのアイデンティティ、最小権限、安全なマルチエージェント対話、および信頼できるリソース検出に関する新たな取り組みは、周囲の管理モデルがすでにその能力に追いつかなければならなくなっていることを示しています。
これらはどれも、エージェント型AIに反対する論拠ではありません。まったく逆です。エージェントが、現代のデジタルビジネスを運営する上でコストがかさみ、煩雑にしている人間による調整作業の一部を取り除くことができるのであれば、それらを追求する非常に具体的な理由が存在します。
しかし、自律的な実行者を既存のデジタル資産に導入することは、単なるもう1つのAIの実装ではありません。それは、アイデンティティ、信頼、データ、説明責任、そして最終的には権限に関する前提条件を変化させます。
ですから、エージェントに何ができるかを尋ねる前に、私は別の質問から始めたいと思います。
あなたは、エージェントに「実際に何をさせる」用意がありますか？
ここで議論された課題に心当たりがある場合、あるいは自社のより広範なデジタル資産にエージェンティックAIがどのように適合するかを検討されている場合は、いつでも意見交換を歓迎いたします。hello@spicymango.co.uk までメールをいただくか、お電話、またはお問い合わせフォームからご連絡ください。
ここで議論された課題に心当たりがある場合、あるいは自社のより広範なデジタル資産にエージェンティックAIがどのように適合するかを検討されている場合は、いつでも意見交換を歓迎いたします。hello@spicymango.co.uk までメールをいただくか、お電話、またはお問い合わせフォームからご連絡ください。
ここで議論された課題に心当たりがある場合、あるいは自社のより広範なデジタル資産にエージェンティックAIがどのように適合するかを検討されている場合は、いつでも意見交換を歓迎いたします。hello@spicymango.co.uk までメールをいただくか、お電話、またはお問い合わせフォームからご連絡ください。
