AIエージェントを導入したのに、数か月後には誰も使わなくなった。詳しい担当者しか成果を出せない。部門ごとに似たエージェントが増え、データや権限の管理が追いつかない。
これはモデルの性能不足だけで起きる問題ではない。むしろ、業務・データ・権限・組織をどう設計したかという、企業側の運用設計の問題である。
2026年7月23日から開催された AI Agent Day 2026 Summer は、この状況を「形骸化」「プロンプト依存」「野良エージェント」「汚いプロセスの自動化」「組織抵抗」という5つの壁に整理している。Salesforceのセッション「5つの壁を超える、AIエージェント運用の核心」も、この問題を扱う予定だ。本記事は公開済みのイベント・セッション概要を起点に、特定製品の紹介ではなく、IT技術者が設計すべき運用基盤として読み解く。
転換点は「AIを使う」から「AIが業務の一部として動く」へ
チャット画面でメールの下書きを作る利用では、人がAIを呼び出す。エージェントでは、業務フローの中でAIが状態を読み、情報を参照し、ツールを呼び出し、次の処理を提案または実行する。
たとえば契約更新の支援なら、単に「更新メールを書いて」と指示するだけではない。
- CRMから対象顧客と契約期限を取得する
- 利用状況、過去の対応、未解決の問い合わせを確認する
- 社内の価格・割引・承認ルールに照らして案を作る
- 担当者に根拠付きで提示し、承認を受ける
- 承認済みの内容だけを送信し、実行記録を残す
ここで人間の役割はなくならない。顧客との関係、例外判断、承認、結果の責任を担う。重要なのは「人が最終判断する」という標語ではなく、どの状態遷移で、誰が、どの根拠を見て止められるかを実装することである。
SalesforceもSummer '26リリースで、複数エージェントのオーケストレーションと共有コンテキストを製品上のテーマとして掲げている。これはSalesforce固有の話というより、AIを個人用の補助機能から業務基盤へ移す際に共通して現れる変化だ。同社の発表 は、複数エージェントとデータ、ワークフローを一体で扱う必要性を示している。
壁1: 使われなくなる──利用率ではなく「業務完了率」を見る
AIツールを配布しただけでは、利用は定着しない。仕事が従来の手順だけで完結するなら、忙しい現場にとってAIは「追加で開く画面」になってしまうからだ。
解決策は、AIを必ず使わせることではない。AIが価値を出せる一連の業務に組み込み、使わないほうが安全かつ合理的な状態を作ることだ。
たとえば問い合わせ対応では、次のように設計する。
受付 → 分類 → 根拠文書の取得 → 回答案の生成
→ 担当者レビュー → 送信 → 評価・訂正の記録
測定対象も「ログイン人数」や「生成回数」だけでは弱い。少なくとも、業務完了率、再作業率、エスカレーション率、顧客への初回回答時間、誤回答の訂正時間を、導入前後と人間のみの経路で比較する。AIを使ったことではなく、業務品質が改善したことを証明するためだ。
壁2: プロンプト職人に依存する──コンテキストを組織資産にする
個人が優れたプロンプトを持っていても、その人が異動すれば品質が落ちる。業務エージェントの品質を決めるのは、質問の言い回しよりも、どの情報を正規の根拠として渡し、どう更新し、どの条件で回答を控えさせるかである。
イベント側も、前提知識・指示・記憶・検索情報という「コンテキストの4層」を、個人技ではなく組織で整備する論点として提示している。Day 1の公式説明 にあるこの視点は、RAGを単にベクトル検索の導入として終わらせないために重要だ。
技術者が整えるべき最小単位は、文書の置き場ではなく「根拠を追跡できる知識」である。
| 設計対象 | 実装で確認すること |
|---|---|
| 正本 | 規程・商品情報・手順書のどれが正しいか。版と有効日を持つか |
| 検索 | 文書、版、節、チャンクを特定できるか。回答に根拠を付けられるか |
| 権限 | 利用者とエージェントの双方について、見せてよい情報だけを返せるか |
| 不確実性 | 根拠が不足・矛盾する際に、推測せず人へエスカレーションできるか |
| 改訂 | 誤回答を、どの知識・指示・ツール設定の問題として直すか追跡できるか |
MCP（Model Context Protocol）は、AIアプリケーションと外部ツール・データ源を結ぶ共通の接続方式として広がっている。ただし、MCPを導入してもデータの正しさや認可は自動では解決しない。2026年のMCPロードマップが「エンタープライズ対応」と「ガバナンス成熟」を優先項目に置くことは、接続できることと安全に運用できることが別問題であることを示している。MCPの2026年ロードマップ を、コネクタの流行ではなく運用要件として読むべきだ。
壁3: 野良エージェントが増える──禁止ではなく、発見・登録・昇格を設計する
現場がローコード製品やSaaSの機能でエージェントを作ること自体は、必ずしも悪いことではない。業務を最も理解する人が改善案を試せるからだ。問題は、それが見えないまま本番データ、外部送信、共有ナレッジに接続されることである。
必要なのは一律禁止ではなく、エージェントのライフサイクル管理だ。
| 段階 | 許可する範囲 | 必須の統制 |
|---|---|---|
| 個人実験 | ダミーまたは公開データ、読み取り中心 | 登録、利用規約、シークレット禁止 |
| 部門試行 | 部門データ、提案・下書きまで | 所有者、データ分類、評価ケース、ログ |
| 共有運用 | 複数部門、限定した書き込み | 個別ID、最小権限、承認、変更管理 |
| 本番実行 | 顧客・基幹業務に影響する操作 | 強い認証、監査、停止手順、ロールバック |
この台帳には、エージェント名だけでなく、所有部門、目的、モデル、参照データ、MCPサーバーやAPI、付与権限、承認者、評価結果、廃止予定日を記録する。エージェントを「便利なプロンプト集」ではなく、権限を持つソフトウェア資産として扱うためである。
NISTも2026年に、AIエージェントの識別・管理・認可を、企業で安全に導入するための課題として扱い始めている。NCCoEのAIエージェントID・認可プロジェクト が示す通り、エージェントに「誰として」「何を」「どの条件で」実行させるかは、導入後に付け足すセキュリティ機能ではない。
壁4: 汚い業務を高速化する──自動化前に例外と責任を可視化する
AIは複雑で曖昧な業務を、勝手に良い業務へ変えてくれるわけではない。古い手順、重複入力、曖昧な承認、散在したデータをそのまま渡せば、AIはそれを速く再現するだけである。
エージェント化の候補を選ぶ前に、次の問いに答えられるか確認したい。
- 開始条件と完了条件は明確か
- 正常系だけでなく、例外・差し戻し・緊急停止の経路が定義されているか
- 判断に必要なデータの正本と更新責任者は決まっているか
- 誤実行したとき、何を取り消し、誰に連絡し、どのログで調査するか
- 人間の承認は、形式的なクリックではなく判断に必要な情報を見られる設計か
最初の対象は、手順と成果指標が明確で、誤りが可逆であり、人間レビューを入れやすい業務がよい。たとえば、問い合わせの分類、チケットの要約、障害情報の相関候補、テスト観点の下書きである。いきなり本番環境の変更や対外送信を自律実行させる必要はない。
壁5: 組織が変わらない──余った時間と責任分界を先に決める
AIで処理時間が半分になっても、現場が「より多く処理するだけ」なら、品質改善や顧客価値にはつながらない。削減できた時間を、例外対応、顧客との対話、知識の更新、改善実験、教育のどれへ再配分するかを、導入前に決める必要がある。
Salesforceは人とAIエージェントの協働を前提に、業務・役割・プロセスの再設計、リスキリング、人材の再配置、仕事配分の再均衡を4Rとして整理している。Salesforceの4R解説 は、技術導入と組織設計を切り離せないことを端的に示す。
IT部門は「AI基盤を提供する部門」にとどまらず、業務部門と次を合意する役割を持つ。
- AIが提案する範囲、実行する範囲、必ず人が判断する範囲
- 誤りを発見した人が停止・訂正を要求できる経路
- AIの成果物をレビューする責任者と、その判断根拠
- AI利用によって変わる評価指標とスキル要件
- 現場が改善要求を出し、モデル・知識・ワークフローを更新する周期
2026年7月時点の最新動向: 接続・協調・観測・統制が同時に必要になった
2026年の変化は、単一の高性能モデルを選べば終わるという話ではない。以下の4つが同時に進んでいる。
MCP: ツール接続は標準化へ向かうが、認可設計は重くなる
MCPによって、モデルやエージェントが多様なツール・データ源へ接続しやすくなった。一方で、接続先が増えるほど、トークン、委任、ツールスコープ、サプライチェーンの管理が重要になる。MCPの次期仕様候補も、OAuth/OpenID Connectに近い認可の強化を含む。2026年7月のMCP仕様候補 を採用するかどうかにかかわらず、接続先ごとの最小権限と失効可能な資格情報は設計の必須項目である。
A2A: 複数エージェントは「分業」ではなく、責任の境界を増やす
A2A（Agent-to-Agent）は、異なるチーム・フレームワーク・サービスで動くエージェント同士が、能力を発見して協調するためのプロトコルだ。Googleの開発者向け解説 が説明するように、MCPが主にツールやデータへの接続を担うのに対し、A2Aはエージェント間の協調を扱う。
ただし、マルチエージェント化は「賢くなる魔法」ではない。各エージェントの入力・出力契約、権限、失敗時の責任、再試行上限、最終承認者を増やす。最初は一つのエージェントと明確なツール呼び出しで評価し、専門分業による品質・保守性の利点が測定できる場合だけ分割するのが堅実だ。
オブザーバビリティ: 応答だけでなく、実行経路と業務成果を追う
AIエージェントは非決定的で、ツール呼び出しや再試行によって処理経路も変わる。そのため「回答が返った」だけでは品質を判断できない。OpenTelemetryでは、モデル呼び出し、トークン数、遅延、ツール呼び出しを追うGenAIのセマンティック規約が整備されている。OpenTelemetryの2026年解説 は、プロンプトやツール引数には機密情報が含まれ得るため、内容の収集を既定で避ける設計も説明している。
運用では、次の二層を分けて観測する。
| 層 | 代表指標 |
|---|---|
| 技術運用 | 成功率、停止率、承認待ち、再試行、モデル・ツール遅延、トークン・コスト、権限拒否 |
| 業務成果 | 解決率、再作業率、エスカレーション率、訂正までの時間、顧客満足、売上・継続率への寄与 |
両方が必要である。技術指標が良くても、誤った顧客対応を高速化していれば失敗であり、業務KPIだけでは原因箇所を直せない。
ガバナンス: エージェント単位のID、権限、評価、監査が前提になる
AIの出力だけを審査する段階から、AIが実行した操作を制御・説明する段階へ移っている。NISTがエージェントのIDと認可を重点テーマにしていること、OWASPが2026年版で自律的・エージェント型アプリケーションのリスクを整理していることは、この変化の表れだ。OWASP Top 10 for Agentic Applications 2026 も確認し、プロンプトインジェクションだけでなく、過剰な自律性、ツールの誤用、データ・IDの取り扱いを脅威モデルに入れたい。
IT技術者が最初の90日で作るべきもの
大規模な「全社AI戦略」から始める必要はない。1業務を選び、次の成果物を残す。
- 業務境界図: 入力、状態、例外、出力、担当者、承認点を図示する
- データ・ツール台帳: 正本、データ分類、API/MCP、シークレット、保持期間を記録する
- 権限マトリクス: エージェント固有のIDで、read/write/delete/外部送信を分離する
- 評価セット: 正常系だけでなく、根拠不足、古い文書、権限外情報、悪意ある入力、失敗時停止を含める
- 監査・復旧手順: 依頼、参照根拠、ツール実行、承認、差分、実行結果を関連付け、止める・戻す手順を試験する
- 成果レビュー: 技術指標と業務指標を同じ定例で見て、知識、プロンプト、ツール、業務ルールのどこを直すか決める
AIエージェントの競争力は、モデル名そのものでは決まらない。根拠あるコンテキストを渡せるか、権限を絞れるか、失敗を止めて調査・復旧できるか、人間の判断を価値の高い仕事へ再配分できるかで決まる。
「導入したAI」を増やすことではなく、「安全に働き、測定でき、改善できるAI」を業務の中に作ること。それが、5つの壁を越えるためのITアーキテクチャである。
作成日: 2026年7月23日