AIエージェントは「ソフトウェア」ではなく「新しい労働力」である。したがって、従来のシステム導入のように「インストールして運用開始」という考え方では失敗する。企業はAIエージェントを人間の従業員と同様に、役割・権限・監督・監査の仕組みの中で管理しなければならない。特に従来の生成AIが抱える「誤った回答をするリスク（コンテンツリスク）」に対し、AIエージェントは「誤った行動を実行するリスク（実行リスク）」を持つ点が本質的に異なる。そのため、企業がAIエージェントを安全かつ大規模に導入するには、以下の4つの摩擦（課題）を克服する必要がある。
1. アイデンティティ（Identity）
「誰が行動しているのか」を明確にする
多くの企業はAIエージェントに共有サービスアカウントを与えているが、これは極めて危険である。
例えば、
- 人間の担当者は500ドルまで返金可能
- AIエージェントは共有管理者権限を持つ
という状況では、
- 人間にはできない5000ドル返金
- 本番データ削除
- システム改ざん
が発生し得る。
対策
AIエージェントを
- 社員番号を持つ従業員
として扱う。具体的には
- 固有ID付与
- 個別認証
- 最小権限原則
- ロールベースアクセス制御（RBAC）
- 完全な操作ログ
を適用する。
2. コンテキスト（Context）
間違った情報は間違った行動を生む
デモ環境では綺麗なデータが使われるが、実際の企業は違う。
現実には
- 古い規程
- 重複データ
- 矛盾するマスタ
- 更新漏れ
が大量に存在する。例えば
- 2022年の人事規程を参照
- 現在の制度と異なる解雇手続きを案内
といったことが起こる。さらに深刻なのがPrompt Injectionである。
メールやフォームに埋め込まれた悪意ある指示をAIが信じてしまい、
- CRM情報漏洩
- 顧客情報送信
- 権限逸脱
につながる。
対策
企業は
- 信頼できる情報源（Single Source of Truth）
- データ来歴管理（Provenance）
- 外部入力検証
を整備しなければならない。
3. 制御（Control）
AIは確率論的に動く
従来システムは、入力A → 出力Bが保証される。しかしLLMは
入力A → 出力B1
入力A → 出力B2
となる。つまり、毎回少しずつ違う。メール作成なら問題ないが、
- 送金
- 契約変更
- 顧客情報更新
では重大事故につながる。さらにマルチエージェント化すると
- Agent Aの誤判断
↓ - Agent Bへ伝播
↓ - Agent Cが実行
という連鎖事故が起こり得る。
対策
AIが直接実行しない。AIは提案のみ行う。実行前に
- ルールエンジン
- ワークフロー
- ポリシーチェック
による検証を行う。つまり、AIと実行権限の間にガードレール層を置く。
4. 説明責任（Accountability）
なぜその判断をしたのか説明できるか
人間なら「なぜそうした？」と聞ける。従来システムならログを見ればよい。しかしAIエージェントは
- プロンプト
- 検索結果
- 推論
- ツール呼び出し
が複雑に絡み合う。例えば、調達エージェントが契約書の機密情報をSlackへ投稿した場合、企業は
- どの文書を見たか
- どんな指示だったか
- なぜ公開可能と判断したか
を説明しなければならない。
対策
完全な監査証跡を保持する。記録すべき項目は
- プロンプト
- 参照データ
- 推論経路
- 実行アクション
- 利用ツール
である。また、
- 誰が責任者か
を明確に定義する。AIが原因でも責任は企業にある。
推奨される導入アプローチ
「自律性のはしご（Autonomy Ladder）」
著者は、いきなり完全自律型を目指すべきではないと主張する。
レベル1
情報生成
- 要約
- 下書き
- 提案
人間確認必須
レベル2
ガードレール付き検索
- 社内ナレッジ検索
- FAQ回答
レベル3
監督付き実行
- データ更新提案
- 承認フロー提案
- 返金提案
最終承認は人間
レベル4
限定的自律実行
- 金額上限付き返金
- 定型データ更新
など狭い範囲のみ自律化
経営者への示唆
この論文の本質は、「AI導入プロジェクト」ではなく「AIマネジメントの仕組みづくり」が成功要因であるという点にある。
AIエージェント時代に必要なのは、
- AIを増やすことではない
- AIを信頼できるよう統治すること
である。
詳細は下記参照。定期購読登録が必要です。
“To Scale AI Agents Successfully, Think of Them Like Team Members,” HBR.org, March 23, 2026.