この記事はAIエージェントの意味を整理する解説です。特定製品の性能比較や、将来の自律性を約束するものではありません。
「AIエージェント」という言葉を聞くと、AIが人間の代わりに仕事を終わらせる場面を想像しやすい。けれど、生成AIを使っていることと、AIエージェントであることは同じではない。違いは、どれだけ賢く答えるかよりも、目標に向けた手順を誰が進め、どこで外部へ作用するかにある。
01 「生成するAI」と「進めるシステム」は別の層にある
生成AIは、文章や画像などを生成するモデルやサービスを指す広い言葉だ。一方、OpenAIの公式ガイドは、エージェントをユーザーに代わってタスクを独立して完了するシステムとして説明し、ワークフローの実行をLLMが制御しない単純なチャットボットや一問一答の利用はエージェントに含めていない。
Anthropicの説明にも、固定スクリプトではなく、目的を達成するために自分のプロセスとツール利用を指揮するモデル、という軸がある。両社の表現は同一ではないが、共通しているのは「回答を返す能力」だけでなく、状況を見て次の行動を選ぶ構成だ。
だから、同じモデルでも、文章を一度生成するだけなら生成AIの利用であり、ツールを選び、結果を確認し、必要なら人へ戻す仕組みまで組み込めばエージェント的なシステムになる。名前はモデルに貼るラベルではなく、行動の設計を読むための手がかりになる。
02 AIエージェントは四つの層でできている
「AIが自分で考えている」と一言でまとめると、どこに責任があるのか見えなくなる。Anthropicが示す整理を手がかりにすると、少なくとも次の四つを分けて考えられる。
モデル : 入力を解釈し、候補をつくる
ハーネス : 指示、状態、ガードレールを与える
ツール : 検索、ファイル、業務システムなどへ接続する
環境 : どのデータと権限の中で動くかを決めるモデルの性能だけを上げても、ツールの権限が広すぎれば別のリスクが生まれる。MCP（Model Context Protocol）を整理した記事で見るように、エージェントと外部ツールの接続が標準化されても、接続先ごとの権限設計は残る。逆に、モデルが同じでも、参照できるデータを絞り、送信前に確認を置き、実行履歴を残せば、委任できる範囲は変わる。エージェントの性格や安全性を、モデル一つの性質として扱わないことが重要だ。
03 自律性はオンとオフではなく、段階として設計する
ここでいう自律性は、編集部の設計上の整理として、次のような段階に分けられる。
- 閲覧だけを許可し、候補を返す
- 下書きや手順をつくり、人が内容を確認する
- 影響範囲が限定され、元に戻せる操作を実行する
- 外部へ送信する、公開する、削除するといった不可逆に近い操作は人が承認する
大切なのは、4へ進むほど「AIを信頼する」ことではない。何を見たか、何を判断したか、どんな影響があるかを人が追えるようにすることだ。NISTの生成AIプロファイルが示すリスク管理の考え方も、モデルの能力だけでなく、利用・評価・運用の文脈を含むシステム全体を扱う。
この段階性は、人間が常に細かく操作するという意味でもない。低リスクで繰り返し可能な部分は任せ、境界に近づいたら確認へ戻す。委任は信頼の宣言ではなく、戻れる道を含んだ設計である。
04 「人をループに入れる」だけでは監督にならない
重要な操作の前に承認ボタンを置けば、人が管理できているように見える。しかし、人が何を確認すべきか分からないまま承認を求められれば、確認は形式だけになりやすい。
2026年にAI and Ethicsで公開された研究は、AIが作業を進める「実行の主体性」と、人が結果を検証し、方向を変え、必要なら置き換える「評価の主体性」を分けて考える枠組みを提案している。ここで重要なのは、すべての内部推論を人が読むことではなく、目的、基準、影響、結果を人が確かめられる形にすることだ。
IBM ResearchがACM CAIS 2026で示した実装研究でも、統制は最後の承認画面だけに置かれていない。計画前、ツール利用の境界、高リスク操作の承認、最終出力といった複数の地点にポリシーを置く構成が示されている。
つまり、人の監督は「毎回クリックすること」ではない。何を自動で進めてよいかを先に限定し、重要な境界では判断材料を見せ、止める・戻す・差し替える余地を残すことだ。承認回数を増やすより、どこで人の判断が本当に必要かを設計する方が、委任の境界を理解しやすい。
05 任せられる仕事は、名前より失敗の戻しやすさで決まる
「経理なら危険」「文章なら安全」のように、仕事の名前だけで線を引くことは難しい。同じ文章作成でも、個人用の下書きと、外部へ自動公開する処理では影響が違う。同じ検索でも、候補を並べるだけなのか、結果をもとに発注するのかで必要な確認が変わる。
委任の前に見るべきなのは、少なくとも次の問いだ。
- 目的と完了条件を短く説明できるか
- 参照してよいデータの範囲が決まっているか
- 失敗したときに停止できるか、元に戻せるか
- 何を参照し、どの道筋で結果へ至ったかを確認できるか
- 最後に人が意味と影響を承認できるか
これらが曖昧なまま「全部任せる」と、AIの自律性ではなく、人間の見落としが自動的に拡大される。
エージェントを評価するときは、答えの採点に加え、必要な根拠へ到達できたかを分けて記録すると、失敗の場所を見つけやすい。HuaとLianのWorkWorlds研究（2026年プレプリント）は、架空の製薬会社を模した8業務で、3つのエージェントに社員ロール別の全資料、または依頼ごとに事前選定した資料を渡し、計192回を比較した。選定資料を渡した条件では、十分な根拠に到達した割合が72.8%から90.4%へ、評価基準を満たした割合が68.0%から76.7%へ上がった。一方、根拠に到達したケースに限った通過率は84.2%と82.7%で大きくは変わらず、差の多くは資料を探して到達する段階に現れた。試験導入では、手選び資料での成績と、実際の役割で見られる資料から探す成績を分け、検索負担と基準通過を記録したい。これは一つの合成職場、8課題、一時点の評価であり、別の組織や業務の成果を予測する数字ではない。
小さな観測や下書きから始めるという考え方は、業務自動化を扱ったフィールドノートとも接続する。
また、組織としてこの境界を継続的に見直すなら、AIガバナンスを方針ではなく運用ループとして捉える記事と同じく、利用、評価、停止、更新を一つの循環として扱う必要がある。
06 AIエージェントは、新しい人格というより権限の設計問題だ
エージェントという名前が付くと、AIが一人の担当者のように振る舞う未来を想像しやすい。しかし、システムとして見るなら、まず確認すべきなのは人格ではなく境界である。何を知るのか。何を決めるのか。何を実行できるのか。どこで人へ戻るのか。
画面の中で完結していた操作が、提案、確認、実行、報告という時間の流れへ変わるとき、インターフェースはボタンの配置だけでは足りなくなる。AIエージェントを理解する入口は、未来の同僚を想像することではない。行動の連鎖に、誰が許可を与え、どこに記録を残し、どう撤回できるかを観測することだ。
07 読み込む文章にも、信頼と権限の境界を置く
エージェントがWebページ、メール、PDF、リポジトリ内の文書を読むとき、その内容には情報だけでなく、モデルの振る舞いを変えようとする指示が含まれる場合がある。利用者が直接入力していない外部データを経由するこの攻撃は、間接プロンプトインジェクションと呼ばれる。NISTは、直接の利用者入力ではなく参照リソースの制御を通じて実行されるプロンプトインジェクションとして定義している。
これは単なる誤回答とは違う。読んだ内容が、メール送信、ファイル操作、コード実行のような権限つきの行動へつながると、影響が広がる。IPAの「情報セキュリティ10大脅威 2026」解説書も、開発用リポジトリのREADMEなどに埋め込まれた指示が、開発者権限でコードを実行させた事例を紹介している。検索やRAGを足すだけで、この境界が消えるわけではない。
そこで、設計では少なくとも三つを分けて考える。
| 境界 | 設計で確認すること |
|---|---|
| 外部データ | Webページや添付文書を、実行命令ではなく未信頼の参照情報として区別する |
| 権限 | 読み取りや下書きに必要な最小限の権限だけを与え、資格情報はモデルから分離する |
| 実行 | 送信・公開・削除など影響の大きい操作は、人が内容と影響を確認してから許可する |
OWASPは、外部コンテンツの分離、最小権限、高リスク操作の人による承認、攻撃シナリオを使った検証を組み合わせるよう勧めている。AIセーフティ・インスティテュートの2026年版評価ガイドも、エージェント固有の観点として自律的な挙動と外部環境との相互作用を評価項目へ加えた。見るべきものは出力の正しさだけではない。何を読み、どのツールを呼び、どこで人へ戻ったかという行動の経路も、監督の対象になる。
IPAが2026年7月に公開したセキュリティ担当者のための生成AIセキュリティの手引書は、情報漏えい、付与権限外の操作、内部データの改ざん、サービス停止、低品質な出力の利用・誤用、第三者への加害、過剰課金という七つの発生被害を整理し、業務や扱う情報に応じてリスクを評価する流れを示している。対策を技術・運用・人の統制に分け、実施後に残るリスクも確認する。エージェントの導入時はツール権限だけでなく、起こりうる被害を特定してから自律性と対策を決めると、委任範囲の評価が具体的になる。
防御策の比較でも、攻撃成功率だけでは通常業務への影響を判断できない。Khanらの2026年のAgentDojo銀行業務ベンチマーク評価では、GPT-5.4-miniのPrompt Injection DetectorとTool Filterは未防御条件より低い攻撃成功率と関連した一方、通常タスクの有用性も低かった。Tool Filterは利用できる操作を制限する仕組みで、実行2の対応比較では4防御策のいずれもHolm補正後の統計的有意差が残らなかった。未防御時のモデル間の成功率も、攻撃目標の達成可能性が揃っていないため、モデルの耐性順位とは読めない。この評価は銀行業務、単一の攻撃シナリオ、選定されたモデルと対策、各構成2回の実行に限られ、ばらつきについて強い結論を出すには足りない。実運用で対策を評価するときは、攻撃成功に加え、正当なタスクと攻撃下の有用性、必要な操作が使えるか、攻撃目標を実行できるか、実行間の差も合わせて測る必要がある。
この境界をRAGの仕組みと合わせて読む場合は、検索結果を回答の根拠へ渡す流れを整理した記事が手がかりになる。参照できる情報と、実行を許可された操作は別々に設計する必要がある。