Microsoft Foundry、Hosted エージェントで長期業務ワークフローを状態管理する設計を解説

Microsoft Foundry Blog は 2026年6月8日、Foundry Hosted エージェントを使って、数日から数週間にまたがる業務プロセスをAIエージェントに継続処理させる設計を解説しました。単発のチャット応答ではなく、途中で人の承認や確認を挟みながら、状態を保持して次の作業へ進むエージェント設計が主題です。

要点

• Foundry Hosted エージェントのサンドボックスVMを、プロジェクト単位の状態保持に使う考え方が示された
• 提案書対応のような長期ワークフローで、タスク一覧、作業ログ、チャネルの読み取り位置、次に実行すべき処理を保持する設計が紹介された
• デスクトップアプリ側はセッションIDを保持する薄いクライアントとし、実データや作業状態はAzure側の管理された環境に寄せる構成が説明された
• Microsoft 365連携、OAuth identity passthrough、OpenTelemetryベースのトレースなど、実運用で確認したい統制面も含まれている

今回のブログ記事で語られていること

今回の記事の中心は、「AIエージェントに業務を任せる」と言うときに避けられない状態管理の問題です。通常のエージェント実行は、入力を受け取り、モデルを呼び出し、必要なツールを使い、応答を返すという1回限りの処理として設計されがちです。しかし、実際の業務では、提案依頼への対応、契約レビュー、顧客対応、社内承認のように、数日から数週間のあいだに複数の担当者、メール、チャット、ドキュメント、承認ステップが絡みます。こうしたワークフローでは、「前回どこまで進んだか」「誰に何を依頼したか」「まだ返ってきていないものは何か」「次にどの条件で再開するか」を忘れない仕組みが必要になります。

Microsoft Foundry Blog は、この課題に対して Foundry Hosted エージェントのサンドボックスVMを使う構成を示しています。プロジェクトごとに分離された実行環境を作り、その環境内のホームディレクトリに、プロジェクト憲章、タスク一覧、ステータス、作業履歴、チャネルのカーソルなどをファイルとして保持します。エージェントは再開時にそれらの状態を読み直し、現在の状況をコンテキストに戻してから次のアクションを判断します。これにより、単なるチャット履歴だけに頼らず、業務の進捗を構造化された状態として扱えるようになります。

記事では、提案依頼に対応するSOWワークフローが例として使われています。エージェントはMicrosoft 365上のメールや会議情報、ドキュメントを参照し、RFPを見つけ、プロジェクトの概要を作成し、会議内容から担当者とタスクを抽出し、作業依頼やリマインドの下書きを作ります。重要なのは、これらを一度に終わらせるのではなく、人の承認や担当者からの返信を待ちながら、何度も再開して進める前提で設計している点です。AIエージェントを業務プロセスに組み込む場合、モデル性能そのものよりも、再開性、状態の一貫性、監査可能性が実務上のボトルネックになりやすいことを示す内容です。

実務で確認したい設計ポイント

まず確認したいのは、状態をどこに置くかです。今回の記事では、ローカルPCに作業状態を置くのではなく、Azure側の管理されたサンドボックスに寄せる構成が推奨されています。これにより、エンドポイント側にはセッションIDなど最小限の情報だけを残し、業務データや作業履歴を企業の管理下に置きやすくなります。複数プロジェクトや複数担当者で運用する場合、ローカルに状態を持たせる設計はシンプルに見えても、情報漏えい、バックアップ、監査、引き継ぎの面で課題が増えます。

次に、セッションの扱いです。記事では、セッション作成、既存セッションへの再接続、過去レスポンスとの接続、状態差分の反映といった考え方が紹介されています。これは、エージェントを「その場の会話相手」ではなく「プロジェクトを進める作業主体」として扱うための基礎になります。特に、複数のスキルやサブエージェントが同じ状態を更新する場合は、上書き事故を避けるために、状態全体を雑に保存するのではなく、差分更新や所有範囲の分離を設計する必要があります。

統制面では、Foundry、Microsoft エージェント Framework、アプリケーション Insights を使ったトレースも重要です。モデル呼び出し、MCPツール呼び出し、サブエージェントの実行、状態更新を追跡できれば、後から「なぜこの依頼が送られたのか」「どのデータを参照したのか」「どのプロジェクトの処理だったのか」を確認しやすくなります。AIエージェントを本番業務に入れるチームにとって、これは便利機能というより、承認フロー、監査、障害調査、責任分界を成立させるための前提です。

今回のブログ記事が関係する人

この内容は、Azure AI Foundryでエージェントを試している開発者だけでなく、社内業務の自動化を検討するIT部門、提案書作成や契約レビューのようなナレッジワークを標準化したい業務部門、そしてAI利用の統制を担うセキュリティ・ガバナンス担当者にも関係します。特に、単発の要約や検索ではなく、複数日かかる業務をAIに持たせたい場合、状態管理、アクセス権、監査ログ、承認タイミング、失敗時の復旧方法を最初から設計に入れる必要があります。

また、今回の構成は「ローカルで動くエージェント」と「クラウド上でホストされるエージェント」の判断材料にもなります。個人の試作や限定的なローカル作業では、手元で状態を保持する構成のほうが始めやすい場合があります。一方で、企業内の業務プロセス、Microsoft 365連携、複数担当者による進行、監査証跡が必要な場面では、ホストされた環境に状態と実行を寄せるほうが運用しやすくなります。

結局、今回のブログ記事をどう読むべきか

導入を検討する場合は、まず対象業務を「一度で完了するタスク」と「途中で止まり、再開し、承認を待つタスク」に分けると読みやすくなります。後者に該当する業務では、エージェントのプロンプトやツールだけでなく、状態ファイルの形式、セッションの寿命、プロジェクトIDの設計、権限委譲、監査ログ、ユーザーへの通知方法を合わせて決める必要があります。

今回の記事は、Foundry Hosted エージェントを単なる実行基盤としてではなく、長期の業務プロセスを保持する作業環境として見るための設計メモとして有用です。AIエージェントを本番業務へ進めるチームは、モデルの応答品質だけでなく、状態が壊れたときの復旧、誤ったリマインドや承認依頼を防ぐガードレール、ユーザーが最終判断を行うポイントまで含めて検証したいところです。