作成日: 2026-08-19
AIエージェントの議論は、しばらく「どのモデルを選ぶか」「どうツールを呼び出すか」「どうプロンプトを書くか」が中心だった。いずれも必要な技術である。しかし、エージェントが社内データを参照し、複数のシステムをまたいで仕事を進め、Teamsなどの普段の仕事場へ配布されるようになると、難所は構築後に移る。
本当に問うべきなのは、エージェントを作れるかではない。誰の権限で、どのデータを根拠に、どの行為まで任せ、失敗時に誰が止めて戻せるかである。
Microsoft Foundry Agent Serviceは、エージェントを構築、デプロイ、運用するマネージド基盤として提供されている。Hosted Agentsでは、独自コードや対応フレームワークをコンテナ化して実行し、プラットフォームがスケーリング、セッション状態、ID、可観測性、ライフサイクル管理を担う。Hosted agents in Foundry Agent Service
製品を採用するかどうかにかかわらず、この方向性は重要だ。AIエージェントは「会話画面の機能」から、仕事を委任される業務システムへ移りつつある。
図: 本記事の説明用に作成した概念図。Microsoftの公式アーキテクチャ図ではない。機能の提供状況や利用可否は、本文中の公式ドキュメントで確認してください。
変わるのは「出力リスク」から「行動リスク」へ
要約や下書きだけをするチャットAIでは、主な失敗は誤った回答や不適切な表現である。しかし、エージェントがCRMを読み、ファイルを更新し、チケットを起票し、メールを送信し、発注案を作るなら、誤りは実際の業務操作になる。
たとえば購買支援では、同じ「発注を支援する」でも危険度が異なる。
| 操作 | 典型的な扱い | 必要な統制 |
|---|---|---|
| 過去の購買履歴を検索する | 読み取り | 利用者ごとの閲覧権限、出典表示 |
| 見積もり候補を作る | 下書き | 価格・取引先の根拠、鮮度確認 |
| 発注データを作成する | 条件付き書き込み | 上限金額、重複検出、差分確認 |
| サプライヤーへ発注する | 対外実行 | 承認、送信先制御、取り消し・連絡手順 |
「人が最終確認する」と書くだけでは統制にならない。どの状態で止めるか、承認者は何を見て判断するか、拒否・期限切れ・再試行時にどう処理するかまで、ワークフローとして実装する必要がある。
エージェントをチームメイトとして扱うと、設計対象が見える
エージェントを新しい担当者として考えると、必要な設計が明確になる。
| 人に対して決めること | エージェントで実装すること |
|---|---|
| 担当業務 | 目的、開始条件、完了条件、禁止事項 |
| 社員IDと権限 | エージェント固有のID、RBAC、最小権限 |
| 利用する業務ツール | API、MCP接続、ツールごとのスコープと上限 |
| 参照するマニュアル | 正本データ、版、有効日、アクセス制御、出典 |
| 上司と決裁 | 人への引き継ぎ、承認者、エスカレーションSLA |
| 業務評価 | 正確性、ポリシー遵守、完了率、手戻り、顧客影響 |
| 退職手続き | ID・シークレット・接続・定期実行の失効と記録保存 |
特にIDは共有サービスアカウントで済ませない。FoundryのHosted Agentsでは、デプロイ時にエージェントごとのMicrosoft Entra IDが作成され、外部リソースへのアクセスはそのIDへRBACを割り当てる設計になっている。エージェントIDとRBACの説明 これは、エージェント単位で「誰として何をしたか」を追えるようにする考え方である。
Build: 会話AIでなく、根拠と境界を持つ業務システムとして作る
契約書レビューエージェントを例にする。「契約書を要約する」だけなら、モデルへの入力と出力で足りることがある。しかし、実務で任せるなら次の問いに答えなければならない。
- どの標準条項・社内規程を正本として検索するのか
- 改訂前の文書や下書きを、どう区別して除外するのか
- 契約書の閲覧権限を、依頼者とエージェントの双方でどう確認するのか
- 条項の差異をどの形式で根拠付き提示し、誰が法的判断をするのか
- 根拠不足、文書破損、権限拒否なら、何を出力せず誰へ渡すのか
モデルの賢さだけで正しい回答を保証することはできない。必要なのは、正本・版・有効日・所有者・アクセス権を持つ知識基盤である。Foundry IQは企業知識用のワークロードとして提供され、Foundry Agent ServiceやMicrosoft Agent Frameworkなどから知識ベースを呼び出せる。Foundry IQ FAQ
また、ツールを無制限に接続するのではなく、用途別に許可した道具だけをまとめる。FoundryのToolboxは、意図に応じたツール群をキュレーションする機能であり、現時点ではプレビューである。Toolboxのドキュメント ここでの本質は機能名ではなく、「契約審査なら契約検索・規程検索・リスク照会だけ」「支払い実行は別の強い承認経路」と、業務単位で権限を分けることだ。
Deploy: API公開ではなく、状態・隔離・配布を設計する
エージェントは、短いリクエストを返して終わるとは限らない。人の承認を待ち、ファイルを保持し、非同期に処理し、業務の途中から再開することがある。そのため、デプロイ時には実行環境の境界が重要になる。
Foundry Hosted Agentsは、セッションごとにVM分離されたサンドボックスを使い、セッション間の状態を隔離しつつ、アイドル後の再開に必要な状態を保持できるとしている。Hosted Agentsの隔離モデル これは単なる実装詳細ではない。一人の利用者のファイルや処理途中の状態が、他の利用者や別案件に混ざらないための業務上の境界である。
TeamsやMicrosoft 365のような日常の作業場所へエージェントを配布する場合も、利用しやすくなるほど統制を強める必要がある。利用者が「同僚に頼む」ように依頼できても、エージェントがどのデータに触れ、どの操作を実行できるかは、画面の手軽さとは別に管理しなければならない。
Operate: 本番公開は完成ではなく、評価の開始である
エージェントの実行経路は、モデル、指示、検索結果、ツール、外部データ、再試行によって変わる。誤った価格のメールが作られた場合、エラーコードだけを見ても原因は分からない。
- どの依頼と利用者コンテキストから開始したか
- どの文書・データを根拠として参照したか
- どのツールを、どの引数と権限で呼んだか
- どのポリシー確認と人の承認を通ったか
- どの版のモデル、指示、ツール設定で実行されたか
- 実行結果を訂正・停止・復旧したか
この関連を追えるようにして初めて、改善と説明責任が可能になる。FoundryではトレースをポータルとApplication Insightsで調査でき、Hosted AgentsはOpenTelemetry形式のトレース・ログ・メトリクスを出力できる。Foundryのエージェントトレース Hosted AgentsのOpenTelemetry
ただし、観測データそのものにプロンプト、個人情報、取引情報が含まれ得る。ログを「全部保存する」のではなく、目的、保持期間、閲覧権限、マスキング、インシデント調査時の開示手順を決める必要がある。
評価は正答率だけで終わらせない
エージェントの評価は、業務のリスクに合わせて多軸にする。カスタマーサポートなら、答えの正しさだけでなく、根拠の有無、ポリシー遵守、個人情報の扱い、適切な引き継ぎ、顧客に与える影響を測る。
| 評価軸 | 例 | 失敗時の扱い |
|---|---|---|
| 正確性・根拠性 | 正本を根拠に回答し、引用を示す | 下書きに戻し、知識・検索設定を見直す |
| 権限・安全性 | 権限外データや禁止操作を拒否する | 即時停止、影響確認、権限・ツール設定を修正 |
| 業務品質 | 完了率、手戻り、処理時間、承認滞留 | ワークフロー・役割分担を再設計 |
| 人への引き継ぎ | 高リスク、低信頼、例外を適切に渡す | 閾値・判断材料・担当者を見直す |
| コストと性能 | 遅延、再試行、ツール失敗、利用コスト | 上限、タイムアウト、フォールバックを調整 |
本番で起きた失敗、訂正、手動介入は、次の評価ケースに変える。これはモデルの再学習だけを意味しない。指示、知識、ツール、承認条件、業務ルールのどこを改めるべきかを、再現可能なテストにするということである。
最初の90日で残すべき成果物
エージェントを全社展開する前に、一業務を対象にして次を作るとよい。
- 業務境界図：開始条件、状態、例外、完了条件、担当者、承認点を描く。
- データ・ツール台帳：正本、データ分類、API/MCP、資格情報、更新者、保持期間を記録する。
- 権限マトリクス：エージェント固有IDで、読み取り、下書き、更新、外部送信、削除を分ける。
- 評価セット：正常系に加え、古い文書、根拠不足、権限外、悪意ある入力、停止・復旧を含める。
- 監査・復旧手順：依頼、根拠、ツール実行、承認、変更差分、結果をつなげ、止める・戻す訓練をする。
- 運用レビュー：技術指標と業務指標を同じ場で見て、知識・権限・ツール・業務ルールの改善を決める。
結論：競争力は「任せられる範囲」を増やす運用力にある
AIエージェント時代の技術力は、エージェントを一度作って動かす力だけでは足りない。正しい根拠へ安全に到達させ、権限を絞り、人の判断を適切な地点に残し、実行を追跡し、失敗を止めて改善する力が必要になる。
Microsoft Foundryの新しい機能群は、このライフサイクルを支援する選択肢の一つである。導入時に先に決めるべきなのは製品名ではない。どの仕事なら、どの条件下で、誰の責任のもとにAIへ任せられるかである。