Azure CAFで考えるAIエージェント導入の進め方

Azure CAFで考えるAIエージェント導入の進め方
.NETラボ 勉強会 2026年8月]
https://dotnetlab.connpass.com/event/396232/

Transcript

1. Azure CAFで考える AIエージェント導入の進め方 .NETラボ 勉強会 2026年8月 FutureOne株式会社 草場 友光
2. • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2716時間 2キャラ目：919時間 3キャラ目：801時間 4キャラ目：190時間(配信用) 自己紹介 • 2022/08-2027 Microsoft MVP (Microsoft Azure, Developer Technologies) • tomo_kusaba 第001462号
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • Azure Cloud Adoption Frameworkはクラウド導入のため のフレームワークですがAIエージェント導入に関してもドキュメン トが存在します。 • 組織にエージェント導入するにあたりどのようなことを考えてど のようなことを準備して行くべきなのか。そもそも何のためにAI エージェントを導入するのかそのあたりを紹介していきます。
5. Azure CAFとは • Azure導入を進めるためのフレームワーク 戦略 計画 準備 導入 運用 ガバナンス セキュリティ 管理
6. Azure CAFの流れ • 戦略に基づいて！ • 計画して！ • 準備して！ • 導入する！！
7. エージェント導入の特殊性 • Azure CAFはAzure導入が前提となって書かれている →必ずしもAzureがすべての組織に必要とも思わないけども建 前 • エージェント導入のドキュメントはAIエージェントが本当に必要な のかという分析フェイズがある。
8. はじめの問い！ • 誰の • どの業務を • 何のために • どのように • 改善するのか？ • 結論としてAIエージェントが必要なのか？
9. ありがちなパターン • 競合各社・または世の中がAIエージェントを導入している • よくわからないけどもAIエージェントを導入しないと出遅れる • 何でもいいのでAIエージェントを導入しよう！！ • 目的と手段が入れ替わっているパターン
10. 改善したい業務は何か？ • 誰が何に時間をとられているのか？ • 利用者は何を速く行いたいのか？ • どの経営・事業目標につながるのか？ • 現在の状況をなにで測るのか？ • どのような状況で継続・変更・中止するのか？
11. どのように改善するのか？ • コスト削減 • ワークフローの高速化 • 意思決定の改善 • 顧客体験の向上
12. ビジネス目標からエージェントの役割を決定 目標 業務上のボトルネック 任せない部分 エージェントを使う例 コスト削減 問い合わせの一次調査、同 じ内容への回答、転記や差し 戻しに時間がかかり、需要の 波に応じた振り分けが難し い 料金、返金、契約条件、優先度の最終決定は決 定的ルールと担当者確認に残す。品質低下や 「削減のための誤クローズ」を防ぐため、根拠な しの回答・自動クローズを禁止する 問い合わせを分類・要約し、承認済みナレッジを検 索して回答の下書きを作る。重複案件や手戻りの 兆候を見つけ、混雑度や専門性に応じて人へ振り 分ける ワークフローの高 速化 依頼文から必要事項を抜き 出す、複数システムを横断し て調べる、承認資料を作る 工程で待機と再確認 承認、レコード更新、規程外判断は自動実行し ない。必須項目、承認経路、期限判定は決定的 なワークフローで検証し、取得不能・矛盾・低信 頼のケースは人へエスカレーションする 依頼内容を抽出し、不足情報を確認するための質 問を作る。許可済みシステムから情報を集めてケー スを要約し、次の手順と承認用下書きを提示する。 例外は担当者へ渡す 意思決定の改善 根拠が複数ソースに散在し、 比較・会議資料・決定理由の 記録に時間がかかる。未確 定事項が埋もれやすい 意思決定を自律化しない。最終判断と権限行使 は人間に残し、出典、鮮度、偏り、アクセス権を 確認する。根拠が不足・競合する場合は結論を 断定せず、追加調査へ戻す 権限内の複数ソースから根拠を収集・要約し、選択 肢とトレードオフ、未確定事項を明示する。会議資 料の下書きと、意思決定後の根拠・判断理由の記録 を支援する 顧客体験の向上 顧客の意図や前回の経緯を 把握しにくく、担当者への引 き継ぎで同じ説明を求める。 案内のタイミングや言語・利 用状況にもばらつきがある 過度なパーソナライズ、誤案内、同意のないデー タ利用を避ける。センシティブな推定、補償判断、 苦情の最終対応は人間が担い、公開前の案内に は承認済み知識と確認を必須にする 問い合わせ意図を把握し、文脈に応じた案内とケー ス要約を作る。担当者への引き継ぎ、必要に応じた プロアクティブ通知の下書き、多言語・アクセシビリ ティに配慮した表現を支援する
13. 本当にエージェントが必要か？ 選択肢 向いている課題 強み 注意点 決定的コード ルール、計算、判定条件が明 確 再現性が高く、速く、テ ストしやすい 曖昧な依頼や未知の分 岐には弱い 検索 利用者が候補から正しい情 報を選べる 原文を直接確認でき、構 検索語を工夫し、検索結 成が単純 果を読み解く作業は利 用者に残る RAG 管理された知識から回答・要 約したい 根拠を与えやすく、知識 利用に集中できる 検索品質、根拠性、生成 品質の評価が必要 ワークフロー自動化 手順と分岐が既知で、処理を 承認、再試行、監査を設 確実に進めたい 計しやすい 想定外の入力への適応 には追加設計が要る AI エージェント 曖昧な入力を解釈し、状況に 応じて手順やツールを選ぶ 動的な複数ステップ処理 非決定性、権限、コスト、 に対応できる 監視、評価の負担が増え る 必ずしもAIエージェントを使うという判断に至らなくてもよい
14. 種類・自立性・人間の関与を課題に合わせる 種類 主な役割 人間との分担例 生産性エージェント 情報の取得・統合、意思決定支援 根拠付きの候補を提示し、人間が 判断する アクションエージェント 定義された業務でレコード更新や処理を 実行 下書き後の承認、または実行直前 の確認を設ける 自動化エージェント 雑な複数ステップを少ない監視で進める 境界内は自動実行し、例外や高リ スク時にエスカレーションする
15. 生産性エージェント • 様々な情報ソースが散逸かつ冗長である • 意思決定を促進するためにこれらの情報を取得し合成する • ナレッジツールを使用する • カスタマーサポートや内部ナレッジなどのシナリオで情報を検索す る時間の短縮が目的
16. アクションエージェント • レコードの更新やプロセスの実行など定義されたタスクを実行す る • 何らかの実行更新が伴うエージェント • ナレッジツールとアクションツールを組み合わせて実行
17. 自動化エージェント • 最小限の監視で複雑なマルチステッププロセスを監理する • ナレッジツールとアクションツールに加えて問題を実行、停止、エ スカレーションするタイミングを決定するトリガーを使用する • この自律性によってスケーラブルな自動化が可能になるが厳格な ガバナンスが必要になる。
18. どこにデプロイするかを決める • どこにデプロイするか？はAIエージェントの設計にも影響してく る話。 • Microsoft Foundryを使うのか、Copilot Studioを使うの かでは構築方法が変わってきます。 • ビジネス目標から導いた機能要件を満たし、運用要件が最小にな るものを選ぶ。
19. AIエージェントの検討フロー • 既製SaaS • Microsoft Copilot Studio • Microsoft Foundry Agent Service • Azure Container Apps/App ServiceなどのPaaS • Azure VM
20. 既存アプリケーションにエージェントを追加す る場合 • 既存アプリからAIエージェントの呼び出し方によって考える • コード：SDK・ライブラリを共有するか、WebAPI・MCPなどを介した独 立か • デプロイ：同時リリースが必要か、互換性を保って独立に変更できるか？ • 実行：同期・非同期、タイムアウト時の扱い障害がどこまで伝播するか？ • データと認可：誰がコンテキストを生成し、どこで権限を再検証するか？ • 運用：監視、スケール、変更、障害対応を誰が担うか？
21. API境界をデプロイ境界の候補にする • AIエージェントとアプリケーションとの必要最小限の契約を含め 実装します。 • エージェント側の実装・アプリケーション側の実装がそれぞれ影響 し合わないように実装します。 • AIエージェント側の障害をアプリケーションに持ち込まないように 設計します。
22. 密結合させるなら • Foundry Agent ServiceではなくWebアプリケーションと同 じ実行基盤にホストする。 • 既存アプリと同じチームライフサイクルであること • 低遅延が重要であること
23. 標準化を構築プロセスに入れる 標準化するもの 成果物の例 エージェント憲章 目的、対象ユーザー、責任者、許可／禁止事項、自律性、終了条件 テンプレート デプロイ、ネットワーク、ログ、安全制御、既定のタグを含む構成 評価ゲート 共通評価セット、ユースケース固有テスト、合格条件、例外承認 テレメトリ 会話／実行 ID、ツール、根拠、所要時間、トークン、コスト、結果 ID／権限 エージェント ID の発行、最小権限ロール、定期レビュー、失効 ツール接続 承認済み API／コネクター、入力検証、タイムアウト、冪等性、監査 変更管理 モデル、プロンプト、知識、ツールのバージョン管理、レビュー、段階展開、 ロールバック
24. 成功基準を評価ライフサイクルで検証する • どのような回答・行動なら正解かを実装前に定義して関係者で合 意すること • 内容：含めるべき事実、手順、最終結果 • 行動：使用すべき・使用すべきでないツールや操作、引数、実行回数 • 根拠と統制：参照すべき情報源、引用との整合、業務ルールやポリシーへ の準拠 • 不確実時の振る舞い：回答拒否、確認質問、人間へのエスカレーションを 選ぶ条件 • 品質：形式、簡潔さ、明瞭さ • 即失格条件：安全上の条件、権限外アクセス、未承認の外部送信など
25. 成功基準を評価軸へ分解する 評価軸 問い 評価例 ビジネス評価 導入目的を達成したか？ 処理時間、再作業率、完了単価、顧客／従業員満 足度 タスク達成 最終結果まで正しく完了したか？ 完了率、手順遵守率、失敗後の回復率 根拠性 信頼できる情報に支えられているか？ 根拠あり回答率、引用整合率、裏付けのない主張 率 ツール利用 正しいツールと引数を選んだか？ ツール選択精度、実行成功率、誤更新／重複実行 件数 安全性 ポリシー違反や情報漏洩を防げたか？ 違反率、攻撃テスト通過率、権限外アクセス件数 エスカレーション エージェントに任せてはいけない場面で人に 引き継いだか？ 見逃し率、不要な引き継ぎ率、人間の修正率 性能・信頼性 実務で許容できる時間内に応答し、障害時 に復旧できるか？ p95（95 パーセンタイル）レイテンシ、タイムアウ ト率、可用性 コスト 投入した資源が価値に見合っているか？ 完了タスク単価、トークン／API 使用量、人間の 確認時間
26. 宣伝
27. C# Kaigi 2026(9/19)
28. おしまい