Microsoft が2026年6月29日に公開した「Agent Harness: Working with your data, safely」は、Microsoft Agent Framework の Agent Harness に、ファイルアクセス、承認フロー、永続メモリを安全に組み込むための実装パターンを解説した公式ブログです。結論から言うと、既存の Microsoft 365 や Azure テナントにすぐ強制適用される管理変更ではなく、.NET / Python で AI エージェントを開発しているチームが、実データを扱う前に確認すべきセキュリティ設計の更新と捉えるのが適切です。(Microsoft for Developers)
今回のポイントは、「エージェントにデータを読ませる」だけでなく、「危険な操作は人間が承認する」「記憶する情報を用途別に分ける」「読み取りと書き込みの権限を同じ扱いにしない」という実務的な設計にあります。特に、社内ファイル、顧客データ、財務データ、業務レポートを AI エージェントに扱わせる予定がある場合は、今回の内容をそのまま実装チェックリストとして使えます。
Microsoft の「Agent Harness: Working with your data, safely」とは
「Agent Harness: Working with your data, safely」は、Microsoft Agent Framework の連載「Build your own claw and agent harness with Microsoft Agent Framework」の Part 2 にあたる記事です。Part 1 では、個人向け財務アシスタントにカスタムツール、Web 検索、計画機能を与えるところまでが扱われました。Part 2 では、そこから一歩進み、エージェントが実データを読み書きし、リスクのある操作を実行し、セッションをまたいで情報を記憶する方法が紹介されています。(Microsoft for Developers)
Microsoft Agent Framework は、.NET と Python で AI エージェントやマルチエージェント ワークフローを構築するためのフレームワークです。Microsoft Learn では、エージェント、ワークフロー、ツール、MCP クライアント、状態管理、ミドルウェア、コンテキストプロバイダーなどを組み合わせて AI アプリケーションを構築できる基盤として説明されています。(Microsoft Learn)
今回の更新で中心になるのは、次の3つです。
| 更新ポイント | 何ができるようになるか | 管理者・開発者が見るべき観点 |
|---|---|---|
| ファイルアクセス | エージェントが指定フォルダー内のファイルを読み書きできる | 読み取り、保存、削除の権限をどう分けるか |
| 承認フロー | 取引実行やファイル変更などを人間の承認後に実行できる | どの操作を自動承認し、どの操作を必ず手動承認にするか |
| 永続メモリ | セッションをまたいで情報を保持できる | 保存してよい情報、保存期間、ユーザー単位の分離をどう設計するか |
重要なのは、これらが単なる便利機能ではなく、AI エージェントを業務データに接続する際の安全装置として位置づけられている点です。
影響範囲：すぐに全ユーザーへ影響する変更ではない
今回の公式情報は、Microsoft 365 管理センターの設定変更や、既存サービスへの強制ロールアウトを知らせるものではありません。対象は主に、Microsoft Agent Framework を使って AI エージェントを開発している開発者、アーキテクト、AI 基盤管理者です。
影響を受けやすいのは、次のようなチームです。
| 対象 | 影響の内容 |
|---|---|
| .NET / Python で Agent Framework を試している開発者 | サンプル実装、ツール承認、ファイルアクセス設定の見直しが必要 |
| 社内 AI エージェントを設計しているアーキテクト | データ読み書き、承認、メモリ保持の設計方針を整理する必要がある |
| Azure / Microsoft Foundry を使う AI 基盤担当者 | Foundry memory を利用する場合、リージョン、モデル、認可、スコープ設計を確認する必要がある |
| セキュリティ・コンプライアンス担当者 | エージェントが保存するファイル、記憶する情報、承認ログの扱いを確認する必要がある |
一方で、一般ユーザーが Microsoft 365 Copilot を使うだけの環境や、Agent Framework を使っていない環境では、今回の内容によって直ちに操作手順が変わるわけではありません。
更新ポイント：ファイルアクセスは「使えるフォルダーを限定する」のが前提
今回の Part 2 では、エージェントがユーザーの保有資産データを portfolio.csv から読み取り、レポートを Markdown ファイルとして保存する例が紹介されています。Agent Harness にはファイルアクセスプロバイダーが含まれており、file_access_read_file、file_access_save_file、file_access_list_files、file_access_search_files、file_access_delete_file などのツールを通じて、指定フォルダー内のファイルを扱えます。(Microsoft for Developers)
ここで実務上重要なのは、エージェントに「PC 全体」や「共有ドライブ全体」を自由に触らせるのではなく、作業用フォルダーを明示的に指定することです。公式サンプルでは working/ フォルダーを指定し、その中にある portfolio.csv を読み取る構成になっています。(Microsoft for Developers)
実務での判断基準
ファイルアクセスを有効化する場合は、最低でも次のように分けて考えるべきです。
| 操作 | リスク | 推奨される扱い |
|---|---|---|
| ファイル一覧の取得 | 低〜中 | 作業フォルダー内に限定し、自動承認候補にする |
| ファイル読み取り | 中 | 読み取り専用フォルダーなら自動承認、機密データは手動確認 |
| レポート保存 | 中 | 保存先を限定し、初回は手動承認 |
| ファイル削除 | 高 | 原則として手動承認 |
| 既存ファイルの上書き | 高 | バックアップや差分確認を前提に手動承認 |
特に社内利用では、「読み取りは安全、書き込みは危険」と単純に分けるだけでは不十分です。読み取りであっても、顧客情報、給与情報、ソースコード、契約書などを含む場合は、エージェントのプロンプトや外部ツール連携を通じて意図せず情報が流れるリスクがあります。
承認フロー：危険な操作は人間の明示的な OK を必須にする
今回の更新で最も実務に直結するのが、承認フローです。公式ブログでは、株式の売買注文を例に、place_trade のようなリスクの高いツールを承認必須にする方法が示されています。モデルがそのツールを呼び出そうとすると、Harness は即座に実行せず、承認リクエストを出します。ユーザーが承認すれば実行され、拒否すればエージェントは別の対応に切り替えます。(Microsoft for Developers)
業務システムに置き換えると、これは次のような操作に該当します。
| 業務操作 | 承認を必須にすべき理由 |
|---|---|
| 顧客へのメール送信 | 誤送信や不適切な文面のリスクがある |
| CRM の顧客情報更新 | 誤更新が営業・サポート業務に影響する |
| 請求書・見積書の作成や送付 | 金額や宛先の誤りが直接損害につながる |
| チケットのクローズ | 未解決の問い合わせを終了してしまう可能性がある |
| ファイル削除・上書き | 復旧コストが高い |
| 本番環境へのデプロイ | サービス停止や障害につながる |
AI エージェントは、自然言語の意図を推測して行動します。そのため、「ユーザーがそう言ったように見えた」だけで本番操作を実行させる設計は危険です。人間の承認を挟むことで、AI の判断ミスを業務上の事故に直結させない構成にできます。
自動承認ルール：安全な操作だけを省力化する
承認フローは安全性を高めますが、すべての操作で承認を求めると業務効率が落ちます。今回の公式ブログでは、読み取り専用のファイル操作を自動承認し、保存、削除、取引などは手動承認に残す例が紹介されています。(Microsoft for Developers)
この考え方は、社内エージェントの設計でも非常に重要です。承認が多すぎるとユーザーは機械的に「承認」を押すようになり、本当に危険な操作を見落とします。逆に承認が少なすぎると、AI が勝手に変更・送信・削除を行うリスクが高まります。
承認設計のおすすめパターン
| 操作タイプ | 例 | 推奨設定 |
|---|---|---|
| 参照のみ | ナレッジ検索、作業フォルダー内のファイル読み取り | 条件付き自動承認 |
| 下書き作成 | レポート作成、メール文案生成 | 自動実行可。ただし送信は別扱い |
| 新規保存 | レポートファイルの保存 | 初回または保存先変更時に承認 |
| 外部送信 | メール送信、Teams 投稿、チケット更新 | 原則手動承認 |
| 削除・上書き | ファイル削除、DB 更新、権限変更 | 必ず手動承認 |
| 金銭・契約に関わる操作 | 発注、決済、契約書送付 | 必ず手動承認。可能なら二重承認 |
Microsoft のサンプルでは、一定金額未満の小さな取引を自動承認し、それ以上は手動承認にするカスタムルールも示されています。これは、業務システムで言えば「少額経費は自動処理、大きな支払いは承認者確認」と同じ発想です。(Microsoft for Developers)
ただし、金額や件数だけで判断するのは危険です。実務では、宛先、データ分類、対象システム、時間帯、ユーザー権限も含めてルール化する必要があります。
「Always approve」は便利だが、管理ルールなしで使うと危険
公式ブログでは、同じツールの承認を繰り返す手間を減らすために、「Always approve this tool」や「Always approve this tool with these arguments」といった継続的な承認の選択肢も紹介されています。前者は同じツールなら引数に関係なく自動承認し、後者は同じ引数の場合のみ自動承認します。これらのルールはセッション状態に記録され、セッションのエクスポート・インポートでも引き継がれると説明されています。(Microsoft for Developers)
管理者目線では、この機能は慎重に扱うべきです。特に「任意の引数で常に承認」は、対象や数量が変わっても通ってしまうため、危険な操作には向きません。
使い分けの目安
| 選択肢 | 向いている場面 | 避けるべき場面 |
|---|---|---|
| 1回だけ承認 | 初回実行、検証環境、本番操作 | 毎回同じ安全操作を行う場合 |
| 同じ引数だけ常に承認 | 同じ保存先、同じ読み取り対象、固定レポート生成 | 引数に顧客IDや金額が含まれる場合 |
| ツール全体を常に承認 | 読み取り専用の低リスクツール | 送信、削除、更新、発注、権限変更 |
実務では、「常に承認」をユーザー任せにせず、組織のポリシーとして許可する範囲を決めるべきです。たとえば、読み取り専用の社内 FAQ 検索は常時承認可、顧客へのメール送信は常時承認不可、といったルールです。
永続メモリ：ファイルメモリと Foundry memory を使い分ける
今回の公式ブログでは、永続メモリとして「File memory」と「Foundry memory」の2種類が紹介されています。File memory は、エージェントが明示的にファイルとして保存する粗い粒度のメモリです。一方、Foundry memory は会話からユーザーの嗜好や事実を抽出し、後のセッションで呼び出せる細かい粒度のメモリとして説明されています。(Microsoft for Developers)
Microsoft Learn でも、Foundry Agent Service の Memory は、セッションをまたいでユーザーの好み、会話履歴、パーソナライズに使う長期メモリとして位置づけられています。メモリは抽出、統合、検索の流れで扱われ、ユーザーごとのスコープで分離する設計が重要です。(Microsoft Learn)
2種類のメモリの違い
| 種類 | 向いている用途 | 管理上の注意 |
|---|---|---|
| File memory | ウォッチリスト、作業メモ、下書き、エージェントが明示的に管理するファイル | 保存場所、セッション ID、バックアップ、削除方法を確認する |
| Foundry memory | ユーザーの好み、長期的な前提、会話の要約 | スコープ設計、保持期間、機密情報の除外、リージョン対応を確認する |
File memory は「エージェントが自分でノートを残す」イメージです。たとえば、営業支援エージェントが「A社向け提案メモ」を保存するような用途に向いています。
Foundry memory は「ユーザーの継続的な文脈を覚える」イメージです。たとえば、「このユーザーは短い回答を好む」「この顧客は毎月末にレポートを確認する」といった情報を次回以降に活用できます。
Foundry memory を使う場合の確認事項
Foundry memory は便利ですが、導入前に確認すべき点があります。Microsoft Learn では、Memory in Foundry Agent Service と Memory Store API はプレビューとして扱われ、利用条件や価格が変わる可能性があるとされています。また、利用には対応する Azure OpenAI のチャットモデルと埋め込みモデルのデプロイが必要です。(Microsoft Learn)
さらに、公式ブログでは Foundry memory が特定リージョンでのみ利用可能と説明されているため、グローバル展開を予定している企業は、利用リージョンを必ず確認する必要があります。(Microsoft for Developers)
導入前チェックリスト
| 確認項目 | 見るべきポイント |
|---|---|
| リージョン | 利用予定の Foundry プロジェクトが memory 対応リージョンにあるか |
| モデル | チャットモデルと埋め込みモデルを用意できるか |
| スコープ | ユーザー単位、顧客単位、部署単位など、分離キーをどう設計するか |
| 保存対象 | 好み、作業履歴、会話要約など、保存してよい情報を定義しているか |
| 保存禁止情報 | 認証情報、秘密鍵、個人番号、決済情報などを保存しない設計か |
| 保持期間 | TTL や削除ポリシーを業務要件に合わせて設定できるか |
| セキュリティテスト | プロンプトインジェクションやメモリ汚染への耐性を検証しているか |
特に注意したいのは、メモリが「便利な記憶」だけでなく、「誤った情報を長く残すリスク」にもなる点です。Microsoft Learn でも、メモリを扱う際はプロンプトインジェクションやメモリ破損への対策が必要だと説明されています。(Microsoft Learn)
設定変更：既存環境に自動適用される変更ではなく、実装時に選ぶ構成
今回の内容は、管理センターで一括変更するタイプの設定ではありません。開発者が Agent Framework のコード内で、ファイルアクセスストア、承認必須ツール、自動承認ルール、メモリプロバイダーを構成する内容です。
たとえば .NET では、ファイルアクセス用に FileSystemAgentFileStore を指定し、承認が必要な関数を ApprovalRequiredAIFunction でラップします。Python では、FileSystemAgentFileStore や @tool(approval_mode="always_require") を使う例が示されています。(Microsoft for Developers)
実務では、次のように導入段階を分けると安全です。
| 段階 | 実施内容 | ゴール |
|---|---|---|
| 検証 | ローカルのテストフォルダーだけを対象にする | エージェントの読み書き挙動を把握する |
| 限定展開 | 読み取り専用データと下書き保存だけを許可する | 承認フローの運用負荷を確認する |
| 業務接続 | CRM、チケット、ファイル共有などと連携する | 更新・送信・削除の承認基準を固める |
| 本番運用 | ログ、監査、例外処理、権限分離を整備する | AI エージェントを継続運用できる状態にする |
一気に本番システムへ接続するのではなく、まずは「読み取り」「下書き」「保存」「外部実行」の順にリスクを上げていくのが現実的です。
移行期限：公式ブログ上では明示されていない
2026年6月29日の公式ブログでは、特定の日付までに移行が必要という期限は示されていません。したがって、現時点では「強制移行への対応」ではなく、「Agent Framework を使う場合の安全な実装パターンを取り入れる更新」と考えるべきです。(Microsoft for Developers)
ただし、GitHub の Microsoft Agent Framework リリースでは、FileAccess や FileMemory、HarnessAgent 周辺に実験的な破壊的変更が含まれるリリースも確認できます。たとえば Python 1.10.0 のリリースノートでは、ファイルアクセスツールの承認必須化や FileMemoryProvider の統合などが「BREAKING — experimental」として記載されています。(GitHub)
そのため、サンプルコードや検証コードを最新パッケージへ上げる場合は、単にバージョンを更新するだけでなく、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| ファイルアクセスツールの名前や挙動 | 既存コードの呼び出し名や承認設定が変わる可能性がある |
| 読み取り専用ツールの自動承認 | 期待どおりにプロンプトが出るか、出ないかを確認する必要がある |
| FileMemoryProvider の保存先 | セッション ID や保存フォルダーが想定どおりか確認する必要がある |
| 承認ルールの評価順 | 先に true を返すルールが優先されるため、ルール順序が重要 |
| Foundry memory のスコープ | ユーザー間で記憶が混ざらないようにする必要がある |
管理者が確認すべきポイント
今回の更新を受けて、管理者やアーキテクトが最初に行うべきことは、Agent Framework の導入有無を棚卸しすることです。開発チームが PoC として使っている場合でも、ファイルアクセスや外部システム連携を始めると、管理対象として扱う必要があります。
確認すべきチェックリスト
| 項目 | 確認内容 |
|---|---|
| 利用状況 | 社内で Microsoft Agent Framework の PoC や本番利用があるか |
| 実行環境 | ローカル、CI/CD、サーバー、Azure 上など、どこでエージェントが動くか |
| ファイルアクセス範囲 | エージェントが参照・保存できるフォルダーが限定されているか |
| 書き込み権限 | 保存、上書き、削除が必要最小限に制限されているか |
| 承認対象 | 送信、更新、削除、金銭処理、本番操作が必ず承認対象になっているか |
| 自動承認ルール | 読み取り専用など低リスク操作に限定されているか |
| メモリ保存対象 | 保存してよい情報と禁止する情報が定義されているか |
| ログ・監査 | 誰が、いつ、何を承認したか追跡できるか |
| リージョン | Foundry memory を使う場合、対応リージョンとデータ所在地を確認しているか |
| パッケージ更新 | .NET / Python のリリースノートを確認してから更新しているか |
この中でも優先度が高いのは、ファイルアクセス範囲、承認対象、自動承認ルール、メモリ保存対象の4つです。ここが曖昧なまま進めると、AI エージェントが業務データを扱えるようになった後に、アクセス制御や監査の設計を後追いで整えることになります。
よくある失敗と避け方
作業フォルダーを広く取りすぎる
最も起こりやすい失敗は、エージェントの作業フォルダーを広く取りすぎることです。たとえば、ユーザーのホームディレクトリや共有ドライブ全体を対象にすると、意図しないファイルの読み取りや削除につながる可能性があります。
対策は、用途ごとに専用フォルダーを作ることです。レポート生成用、入力データ用、下書き保存用のように分けると、権限管理と監査がしやすくなります。
「読み取り専用なら安全」と考えてしまう
読み取り専用でも、機密情報を含むファイルをエージェントがプロンプトに取り込む時点でリスクがあります。特に外部ツール、Web 検索、サードパーティモデルと組み合わせる場合は、データの流れを確認する必要があります。
Microsoft Learn でも、Agent Framework を使ってサードパーティシステムと連携する場合、共有・保持・処理されるデータを確認し、適切なアクセス許可や境界、承認を管理する責任が利用者側にあると説明されています。(Microsoft Learn)
自動承認を広く設定しすぎる
自動承認は便利ですが、広く設定しすぎると人間の確認が機能しなくなります。特に「同じツールなら常に承認」は、引数が変わっても通るため注意が必要です。
安全に使うなら、「読み取り専用」「特定フォルダー内」「特定ファイル形式のみ」「特定ユーザーのみ」など、複数条件を組み合わせるべきです。
メモリに保存してはいけない情報を決めていない
Foundry memory や File memory を使う場合、保存してよい情報だけでなく、保存してはいけない情報を明確にする必要があります。認証情報、API キー、秘密鍵、個人番号、決済情報、医療情報、契約上保存できない顧客情報などは、原則としてメモリに残さない設計にすべきです。
Foundry memory では、ユーザーごとのスコープ設計も重要です。スコープを誤ると、別ユーザーの情報が混ざるリスクがあります。Microsoft Learn では、scope パラメーターでメモリを分離し、ユーザーごとの安全な体験を実現することが説明されています。(Microsoft Learn)
実務でのおすすめ導入順
Agent Harness の機能を業務環境に取り入れるなら、次の順番で進めると失敗しにくくなります。
| 順番 | 実施内容 | 判断基準 |
| -: | —————————— | ———————— |
| 1 | Agent Framework の利用状況を棚卸しする | PoC、個人検証、業務利用を分ける |
| 2 | ファイルアクセスの対象フォルダーを限定する | 入力、出力、メモリを分離する |
| 3 | 危険なツールを承認必須にする | 送信、更新、削除、金銭、本番操作を優先 |
| 4 | 読み取り専用の自動承認を検討する | 承認疲れを防ぐため、低リスク操作のみ対象 |
| 5 | メモリに保存する情報を定義する | 保存可、保存不可、保存期間を文書化する |
| 6 | Foundry memory のリージョンとモデルを確認する | グローバル展開前に利用可否を確認する |
| 7 | ログと監査を整える | 承認者、操作内容、引数、結果を追跡する |
| 8 | パッケージ更新前にリリースノートを確認する | experimental な破壊的変更に注意する |
最初から高度なメモリや自動承認を組み込む必要はありません。まずは、読み取り対象を限定し、書き込みや外部実行を承認必須にするだけでも、安全性は大きく向上します。
まとめ：今回の更新は「AI エージェントに実データを触らせる前の安全設計」
Microsoft の「Agent Harness: Working with your data, safely」は、Microsoft Agent Framework の Agent Harness を使って、AI エージェントに実データを安全に扱わせるための重要な更新情報です。
今回押さえるべきポイントは、次の4つです。
- ファイルアクセスは、必ず作業フォルダーを限定して設計する
- 削除、送信、更新、取引などの危険な操作は人間の承認を必須にする
- 自動承認は読み取り専用など低リスク操作に限定する
- メモリは File memory と Foundry memory の違いを理解し、保存対象とスコープを管理する
移行期限や強制適用が示された変更ではありませんが、Agent Framework を使って社内 AI エージェントを構築するなら、今回の内容は早めに設計へ取り込む価値があります。まずは既存の PoC やサンプル実装を確認し、エージェントが「どのデータを読めるのか」「どの操作を実行できるのか」「何を記憶するのか」を一覧化するところから始めるのが現実的です。
コメント