AIエージェントが誰でも作れる時代に、IT部門は何を管理するのか

Microsoftの講演から読み解く、モデル競争の先にある「データ・評価・統制」の設計

生成AIが企業へ広がり始めた当初、IT部門が受ける相談は比較的単純だった。

• どの生成AIサービスを使えばよいか
• 社内データを入力してよいか
• ChatGPTとCopilotは何が違うか
• RAGをどのように構築すればよいか

AIエージェントが普及すると、問題の性質が変わる。AIは質問に答えるだけでなく、計画を作り、情報を探し、ツールを呼び出し、業務システムへ処理を依頼するようになる。さらに、自然言語やMarkdownの指示書を用意するだけで、専門的なプログラミングをほとんどせずにエージェントを作れる環境も増えている。

現場部門にとっては大きな機会である。一方、IT部門には新しい管理対象が生まれる。

• 誰が何の目的で作ったのか
• どのデータとツールへ接続しているのか
• どのモデルを、どの地域・条件で使うのか
• 誰の権限で読み取り・更新・外部送信を行うのか
• 品質低下や権限逸脱をどう検知するのか
• 作成者の異動・退職後に、誰が所有・廃止を判断するのか

Microsoftの講演資料が示したのは、AIエージェント時代にIT部門が単なるシステム提供者から、データ、権限、評価、実行経路を設計する統制者へ役割を広げるという方向性である。

Microsoft Foundryの資料では、これを次の四つに整理している。

Ground    : AIと業務データを結び付ける
Integrate : 既存業務とシステムへ組み込む
Operate   : 評価・観測・改善を続ける
Govern    : ID・権限・セキュリティ・監査を統制する

本稿では、製品紹介にとどめず、IT部門が何を共通化し、何を現場へ委ね、何を止められるようにすべきかを整理する。

生成AIは「使うかどうか」ではなく「どこまで任せるか」の段階に入った

生成AIは、文章作成や要約だけでなく、長い文脈の処理、画像理解、音声対話、コード生成、ツール利用、長時間の処理へ能力を広げている。日本語での業務文書や自然言語指示の扱いも改善し、AIを業務フローへ組み込む選択肢は増えた。

ただし、能力が上がったことと、任せてよい範囲が広がったことは同義ではない。

企業が最初に決めるべきなのは、「AIを導入するか」ではなく、次の境界である。

段階	AIの役割	人間の役割	主なリスク
情報支援	検索・要約・候補提示	判断・実行	誤情報、根拠不足
下書き支援	回答・申請・分析案の作成	修正・承認	誤記、判断漏れ
条件付き実行	定型処理の更新・通知	例外判断・事後確認	権限逸脱、二重実行
継続監視	イベント検知・調査・起票	是正・優先順位判断	見逃し、通知疲れ
権限付き自律実行	範囲内での実行	方針・上限・監査	金銭、安全、法的影響

資料を要約するAIと、顧客データを更新するAIを、同じ管理方法で扱ってはいけない。自律性は便利さではなく、業務リスクに応じて設計する対象である。

モデル競争は「最も賢い一つ」を選ぶ競争ではない

Microsoft Foundry Modelsは、Microsoft、OpenAI、DeepSeek、Hugging Face、Metaなどを含むモデルを探索、評価、展開するためのカタログとして提供されている。Microsoft Foundry Modelsの公式説明 も、モデルの比較、独自データでの評価、微調整、可観測性、責任あるAIの機能を一体で扱うとしている。

多くのモデルを利用できることは、最も性能が高い一つのモデルへ全業務を集約すべき、という意味ではない。

たとえば、問い合わせメールの分類、社内文書の要約、契約条件の比較、コード修正、事業計画の検討、顧客への正式回答では、求める品質、コスト、応答時間、説明可能性が異なる。

モデル選択は、性能ランキングではなく、次の要素を含むアーキテクチャ判断である。

• 業務ごとの品質・根拠性・構造化出力の要件
• 一件当たりのコストと、ピーク時の処理量
• 応答時間と、待ち時間を許容できるか
• データ所在地、利用可能リージョン、保持条件
• 安全制御、可用性、障害時の代替手段
• 特定モデル・特定ベンダーへの依存度

重要なのは「モデルを所有すること」ではない。自社の評価データ、業務知識、ツール定義、モデルを切り替える能力を持つことである。

Model Routerは便利だが、モデル選択の責任をなくさない

Microsoft FoundryのModel Router は、プロンプトの複雑さ、推論の必要性、タスク種別などを分析し、適切な基盤モデルへリアルタイムに振り分ける。品質、コスト、レイテンシーを重視するルーティングモードや、採用候補を限定するモデルサブセットも提供されている。

この仕組みの価値は、各アプリケーションに分散しがちなモデル切替ロジックを、共通のプラットフォームへ寄せられる点にある。単純な分類は軽量なモデルへ、複雑な推論は高性能なモデルへ振り分けることで、過剰な費用や待ち時間を抑えやすくなる。

ただし、Model Routerは「常に最適なモデルを選ぶ魔法の機能」ではない。公式ドキュメントには、次の制約も明記されている。

• ルーターの実効コンテキスト長は、対象モデル群の最小値に制約される
• 選択できるモデル、地域、デプロイ種別には条件がある
• モデルサブセットやルーティングモードによって出力傾向が変わる
• 音声入力など、対象外となるモダリティがある

したがって、モデル選択をプラットフォームへ寄せても、IT部門の責任が消えるわけではない。むしろ、次を共通ルールとして管理する必要がある。

• どの業務でどのモデル群を利用してよいか
• 重要業務で品質モード・コストモードをどう使い分けるか
• 新しいモデルを本番ルーティングへ追加する前の評価方法
• モデル変更後に、どの回帰テストを通すか
• 障害時のフォールバックと、代替時に許容する品質差

モデルルーティングは、モデル選択を自動化する機能ではあるが、調達・品質・事業継続の判断を自動化する機能ではない。

コスト最適化は、安いモデルを使うことではない

生成AIのコストは、一回のAPI料金だけでは決まらない。

• 入出力トークン数
• 検索・再ランキングの回数
• エージェントが呼び出すツール数
• 失敗時の再試行
• 長い実行時間と状態保持
• 人間の確認・修正コスト
• 誤処理後の再処理・復旧コスト

たとえば社内規程への質問に答えるため、全規程、全マニュアル、全議事録を毎回モデルへ渡せば、長いコンテキストを扱えるモデルでも費用と応答時間は増える。

必要なのは、モデルの前段を含む設計である。

質問の分類
  ↓
情報源の選択
  ↓
権限を反映した検索
  ↓
重複除去・再ランキング・必要部分の抽出
  ↓
用途に合うモデルへ渡す
  ↓
出力の検証と必要時の人間確認

コスト最適化の対象は、モデル単価ではなく、情報をモデルへ渡し、結果を業務へ戻すまでの経路全体である。

プロンプトだけでは直せない。改善ループを三層に分ける

講演では、AIシステムの改善を、システム全体、エージェント、モデルの三層として捉えていた。これは実務で有効な分け方である。

システム全体の改善

業務成果を確認する。処理時間は短くなったか。人の作業は減ったか。品質は維持できたか。利用者は使い続けているか。コストに見合うかを評価する。

エージェントの改善

エージェントが、正しいツールを選んだか、不要な検索や再試行をしていないか、遠回りな計画になっていないか、適切な時点で人へ引き継いだかを評価する。ここは、プロンプト、ツール定義、ワークフロー、ガードレール、停止条件を直すことで比較的速く改善できる。

モデルの改善

モデルが指示や業務用語を正しく理解したか、出力形式を守ったか、より適したモデルがあるか、微調整が必要かを評価する。モデル変更やファインチューニングは重要だが、もっとも時間と検証を要する改善手段でもある。

回答が遅い原因は、モデル推論、検索範囲、API遅延、ツールの再呼び出し、計画の失敗などに分かれる。回答が不正確な原因も、データ、チャンク分割、検索、プロンプト、モデル、ツール結果の解釈に分かれる。問題を層ごとに分けずにモデルだけを交換しても、改善しないことが多い。

Microsoft AIが自社モデル開発を「hill-climbing machine」、すなわち計算資源、データ、評価を繰り返し改善する仕組みとして説明していることも参考になる。Microsoft AIの7つのMAIモデルに関する発表 は、モデルそのものだけでなく、継続的に評価・改善する組織能力を重視している。

一般企業が基盤モデルを一から開発する必要はない。ただし、自社業務の評価データと改善ループを持つ必要はある。

評価できないエージェントは、改善も統制もできない

AIエージェントを運用するなら、利用者の入力と最終回答だけを保存しても足りない。途中の経路を追跡できなければ、なぜ失敗したのかを特定できないからである。

最低限、次を追跡できるようにする。

• 利用者・実行主体・セッション
• 選択されたモデルとバージョン
• エージェントの計画と状態遷移
• 検索クエリ、参照文書、根拠の版
• 呼び出したツール、入力値、戻り値
• 再試行、失敗、所要時間、トークン量、費用
• 最終出力、人間の修正、承認・却下の結果
• 利用者評価、業務上の結果、インシデント

Microsoft Foundryのトレース機能 は、入力・出力、ツール利用、再試行、レイテンシー、コストなどを記録し、エージェントの経路を確認するためのものとして説明されている。さらに、クラウド評価の説明 では、テストデータによる事前評価だけでなく、本番トレースを使った継続評価も扱う。

ただし、トレースには利用者入力、ツール引数、検索結果などの顧客データが入り得る。トレースのデータ処理に関する公式説明 も、個人情報、秘密情報、資格情報をトレースから削除またはマスキングする必要性を示している。

つまり、可観測性はログを増やすことではない。原因分析に必要な情報を残しながら、保存してはいけない情報を制御することである。

音声AIは、デモではなく業務インターフェースになった

講演では、音声を直接扱うリアルタイムAI、画像理解、音声認識・音声合成を組み合わせたマルチモーダルな業務インターフェースも扱われた。視覚障害者支援サービスのBe My Eyesのように、カメラ映像を理解し、利用者の質問に音声で答えるサービスは、画像認識だけでなく、音声、画像、文脈をつないだ対話の例である。OpenAIが紹介するBe My Eyesの事例 も、視覚的な情報を対話で利用する方向を示している。

コールセンターでは、次のような役割分担が現実的である。

• 会話の文字起こし、要約、FAQ検索、CRM記録を支援する
• 営業時間案内、配送確認、予約変更など定型手続きを自動化する
• 用件を整理して、必要な情報とともに人間へ引き継ぐ

重要なのは、全面自動化ではない。感情的な相談、複雑な例外、高額契約、苦情、法的問題、関係修復は、人が担うべき場面が多い。AIか人間かの二者択一ではなく、どの状態で、どの情報を添えて、人間へ渡すかを設計する必要がある。

音声AIは、新しい本人確認リスクも生む。本人に近い声を生成できる以上、声が本人に聞こえることだけで、本人性を確認してはいけない。重要操作では、登録端末、多要素認証、コールバック、デジタル署名、取引内容の再確認を組み合わせるべきである。

また、ソフトバンクが提供するSoftVoiceは、発話内容を変えずに攻撃的な声の調子を和らげ、カスタマーハラスメントによる従業員の心理的負担を減らすことを目的とする。SoftVoiceの公式説明 が示すように、AIは顧客へ回答するだけでなく、対応者を守る補助策にもなり得る。ただし、脅迫や不当要求を解決するものではないため、通話終了基準、エスカレーション、管理者・法務との連携は別途必要である。

Microsoft IQは、データ接続の前に「企業の文脈」を扱う

Microsoft IQの公式ドキュメント は、組織に関する共有・継続的な理解を、AIエージェントとCopilotに渡すためのインテリジェンス層として、四つの機能群を示している。

機能群	扱う文脈	IT部門が確認すべきこと
Work IQ	人、共同作業、ワークフロー	共有範囲、会議・チャットの扱い、退職者データ
Fabric IQ	業務エンティティ、関係、指標、ルール	データモデル、マスター、定義、鮮度
Foundry IQ	規程、正式文書、再利用可能なナレッジ	正本、版管理、根拠表示、検索権限
Web IQ	Web上の最新情報	情報源、取得条件、引用、信頼性評価

これは、AIへファイル群やデータベースをそのまま渡すのではなく、情報源の意味、鮮度、関係、正式性、業務用語を扱う層を置く考え方である。

たとえば、Foundry IQは、複数の情報源を持つナレッジベースを構成し、検索時に利用者の権限を反映し、根拠付きで回答を返す機能として説明されている。Foundry IQの公式説明 によれば、Azure Blob Storage、SharePoint、OneLake、Webなどの情報源を扱い、クエリ時にアクセス制御を適用できる。

ここで重要なのは、検索APIを増やせばエージェントが賢くなるわけではない点だ。社内検索、SharePoint、CRM、データウェアハウス、Web検索が並ぶほど、エージェントは「どれを使うか」「どれが最新か」「どれを正本とするか」を判断しなければならない。

IT部門は、接続数ではなく、情報源の優先順位、権限、鮮度、版、業務用語を設計する必要がある。

「利用者の権限」と「エージェントの権限」は分ける

エージェントが利用者の権限を引き継いで検索することは、基本設計として妥当である。しかし、それだけでは不十分だ。

利用者が顧客データを閲覧できても、エージェントが全件を一括取得して外部へ送信してよいとは限らない。利用者が商品情報を更新できても、エージェントが発注や価格変更を実行してよいとは限らない。

利用者が閲覧できる
  ≠ エージェントが大量取得してよい
  ≠ エージェントが外部へ送信してよい
  ≠ エージェントが更新・実行してよい

特にバックグラウンドで動くエージェントでは、次を分ける。

• 依頼した利用者の閲覧権限
• エージェント自身の実行IDと最小権限
• 読み取り、更新、外部送信、金銭処理ごとの操作権限
• 実行対象、金額、回数、時間帯、リージョンなどのポリシー
• 例外時に人へ引き継ぐ条件

Microsoft Agent 365は、組織内のエージェントを可視化し、ライフサイクル、アクセス制御、コンプライアンスを管理する基盤として提供されている。Microsoft Agent 365の概要 では、Microsoft Entra、Purview、Defenderを通じて、ID、データ保護、脅威検知をエージェントへ適用する構成が説明されている。

シャドーAIの次は、シャドーエージェントである

承認されていない外部AIサービスを従業員が使う「シャドーAI」は、入力情報の漏えいが主な問題だった。シャドーエージェントでは、問題が一段深くなる。

個人が作ったエージェントが、メールを読み、社内文書にアクセスし、顧客情報を取得し、会議を設定し、業務システムを更新できる可能性があるからだ。情報を外部へ送るだけでなく、企業システムを操作する。

Agent 365のセキュリティ説明でも、利用者作成・SaaSエージェントの増加による攻撃面の拡大、過剰権限、ツールの誤用、認証不備、プロンプトインジェクション、データ漏えいが、エージェント固有のリスクとして挙げられている。Agent 365のセキュリティ機能 を踏まえ、全面禁止ではなく、見える化と安全な利用経路を用意することが必要になる。

現場が安全に試せる領域と、審査が必要な領域を分ける。

区分	例	管理方法
自由に試せる	公開情報による調査、個人の下書き	承認済みツール、データ持ち出し禁止
届出が必要	部門文書の検索、社内向け試作品	所有者、利用データ、保存期間を登録
審査が必要	顧客情報、個人情報、外部SaaS連携	セキュリティ、権限、評価、ログを審査
人の承認が必要	送信、更新、発注、契約・金額判断	影響・根拠・取消方法を表示して承認
原則禁止	不可逆な高リスク処理、法令上人の判断が必要な処理	個別の権限委譲なしには実行させない

所有者のいないエージェントを残さない

エージェントは、作成者が異動・退職した後も残り得る。目的を知る人がいない。接続先だけが生きている。古い規程やモデルを使い続ける。誰も停止を判断できない。これは、所有者不明のスクリプトやRPAより危険になり得る。

Microsoft Entra Agent IDのドキュメントは、技術運用を担うOwnerと、目的・ライフサイクル・アクセスレビューに責任を持つ事業側のSponsorを分けている。Agent IDにおける所有者とスポンサーの管理 は、エージェントに技術面と業務面の責任者が必要であることを示す。

また、Microsoft 365管理センターのAgent Registryでは、エージェントの可視性、アクセス、配布、廃止を管理し、停止、削除、所有者再割り当てなどの操作を扱える。エージェントのガバナンスとライフサイクル管理 を参照しつつ、製品固有の機能にかかわらず、社内では最低限次を台帳化すべきである。

• エージェント名、目的、対象業務、利用者
• 業務所有者、技術所有者、リスク・承認責任者
• 使用モデル、ツール、MCPサーバー、データソース
• 参照・更新・外部送信の権限
• 評価結果、更新日、次回レビュー日
• 有効期限、廃止条件、停止・復旧手順

エージェントの台帳は、管理のための書類ではない。問題が起きたときに、止める人、直す人、説明する人を特定するための運用基盤である。

Human in the Loopは、最後の承認ボタンではない

Human in the Loopを「最後に人が見ること」とだけ理解すると、承認者が判断材料を持てず、誤った前提をそのまま通す恐れがある。

たとえば、AIが在庫不足を予測し、過去の互換性情報をもとに代替部品の発注案を作る場合、「この処理を承認しますか」だけでは不十分だ。少なくとも次を示す必要がある。

• AIが実行しようとしている操作
• 対象、件数、金額、期限、取り消し可否
• 参照した在庫、需要、互換性、契約条件
• 根拠文書と、その版・更新日時
• 不確実な部分と、適用していない例外条件
• 実行後の影響と、失敗時の復旧方法

処理の影響度に応じて、事前承認、例外承認、事後監査を使い分ける。

方式	適する処理	重要な設計
事前承認	高額発注、正式回答、契約判断	根拠・影響・取消可否を承認者へ示す
例外承認	大量の定型処理	信頼度、ルール外、データ欠損の閾値を定義する
事後監査	可逆で影響が限定的な処理	サンプリング、異常検知、取消・復旧を用意する

人間が毎回すべてを承認すれば、エージェントは人間待ちの自動化になる。すべてを自動化すれば、誤りの影響が拡大する。人の関与は量ではなく、リスクに応じた配置が重要である。

IT部門は「作らせない部門」ではなく、共通能力を提供する部門になる

自然言語でエージェントを作れるようになると、IT部門がすべてを個別開発することは現実的ではない。一方で、各部門が独自に認証、検索、MCP接続、ログ、評価を実装すれば、品質と安全性を保てない。

IT部門が提供すべきなのは、現場を止めるための壁ではなく、ガードレール付きの共通基盤である。

利用者・業務イベント
        ↓
認証・アイデンティティ
        ↓
エージェント登録・公開承認・所有者管理
        ↓
モデルルーティング・ポリシー・ガードレール
        ↓
企業の文脈層（Work / Fabric / Foundry / Web）
        ↓
ツール・API・MCP・既存業務システム
        ↓
Human in the Loop / 条件付き実行 / 停止
        ↓
ログ・トレース・評価・コスト・監査
        ↓
改善・再認定・廃止

現場部門は、業務課題、例外、評価観点、利用者体験を担う。IT部門は、認証、権限、データ接続、評価、監視、障害対応、ライフサイクルを共通化する。経営層は、任せる範囲とリスク許容度、投資判断を担う。

この分担があれば、現場の創意工夫を生かしながら、シャドーエージェントを減らせる。

導入前に確認する実装チェックリスト

目的と業務

• 解決したい業務課題と、現行の比較指標は明確か
• チャット支援ではなく、エージェントとして実行する価値があるか
• AIに任せる判断と、人に残す判断を分けたか
• 例外、停止、エスカレーションを定義したか

データと文脈

• 正本、最新版、責任者、有効期限を判別できるか
• 検索時点で利用者の権限を反映できるか
• 参照、更新、外部送信を別の権限として管理したか
• 回答の根拠と元文書を提示できるか

モデルと評価

• モデル選定・ルーティングの理由を説明できるか
• 共通の業務評価セットを持っているか
• モデル・プロンプト・ツール変更後に回帰評価できるか
• コスト、待ち時間、品質、可用性を継続監視できるか

ツールと実行

• MCP・API・SaaS接続を許可制にしているか
• 入力値、実行回数、金額、対象件数、時間帯を制限できるか
• 二重実行、誤送信、タイムアウトを防げるか
• 操作を停止、取消、復旧する手順があるか

ガバナンス

• 業務所有者、技術所有者、リスク責任者を定めたか
• 所有者不明のエージェントを検知・再割り当てできるか
• トレースに含める情報と、マスキング・保持期間を決めたか
• 公開、定期レビュー、再認定、廃止の手順があるか

まとめ: IT部門の仕事は、エージェントを安全に増やせる仕組みを作ること

AIエージェントを作ること自体は、急速に簡単になっている。自然言語で指示し、データとツールを接続すれば、現場部門でも業務エージェントを作れる。

このときIT部門が「すべての開発をIT部門へ申請してください」とだけ求めれば、現場は待たずに外部サービスや個人アカウントでエージェントを作り始める。その結果、企業データへアクセスし、業務処理まで行うシャドーエージェントが増える。

一方、統制を緩めすぎれば、機密情報の漏えい、誤処理、権限逸脱、コスト増大、所有者不明、監査不能が起きる。

必要なのは、全面禁止でも全面自由化でもない。

• 承認済みモデルとモデルルーティング
• 安全なデータアクセスと根拠提示
• 共通ツールと最小権限
• 評価、トレース、コスト監視
• Human in the Loopと停止・復旧
• 所有者、公開、再認定、廃止のライフサイクル

を、組織の共通能力として提供することである。

AIエージェント時代に差が付くのは、最も多くのエージェントを作った企業でも、最も賢いモデルを契約した企業でもない。必要なデータへ安全に到達し、用途に応じてモデルを選び、失敗を観測し、改善し、不要になったエージェントを止められる企業である。

生成AIの時代、IT部門の役割は小さくならない。個々のシステムを管理する役割から、人間とAIエージェントが共同で働く企業全体の運用モデルを設計する役割へ広がっていく。

作成日: 2026年7月23日