The Real Barrier to AI Agents in Large Enterprises: Insights from Microsoft Scout

AIエージェントのM365連携が、これまで社内セキュリティの壁で殺され続けてきた。

M365 MCP → 接続不可

Claude in Chrome → 動作せず

Notion MCP → 死

そんな大企業の窓際課長が、今日のMicrosoft Scout発表（2026/6/2）を見て本気で考えた。

Scoutは塀の中に最初からいる。

でも今日一番衝撃だったのは、セキュリティポリシーの壁より、個人情報ポリシーの壁の方が遥かに高いということだった。

※この記事は私の環境での考察です。他社・他環境での動作を保証するものではありません（2026年6月3日時点の情報）。

第1章：ScoutとOpenClawを、まず整理します

ScoutはOpenClaw（オープンソースのAIエージェント）をM365向けに企業対応した、常時稼働型エージェントです。

OpenClawは2026年1月、オーストリアの開発者Peter Steinberger氏が公開した個人向けAIエージェントです。

OpenClawは公開後すぐに爆発的に広がり、開発者のOpenAI参加後も独立財団に移管されたコミュニティ主導で開発が続き、2026年4月にはGitHubスター30万超を記録しました。

私も以前からOpenClawには注目していて、自宅でNemoClawというOpenClaw系のクローン環境を導入検証していました。エンタープライズ成熟には半年はかかると見て、今年度後半に職場での本格検証を予定していました。そのウォーミングアップとして個人環境でも試していたということです。

ただ、エンタープライズ導入という観点では、OpenClawには3つの課題がありました。

①セキュリティ面の不安が拭えない。

OpenClawは自由度が高い反面、企業環境での利用には怖さが伴います。セキュリティ上の問題が指摘されてきたことも、エンタープライズ導入をためらわせる要因でした。

②導入からメンテナンスまでのハードルが高い。

セットアップから設定・運用まで技術的なハードルが高く、エンジニアリソースのない企業では継続運用が難しいのが実態です。Xでも「導入できても、その後のメンテナンスが大変で実作業には使えていない」という声をよく見かけます。

③M365との連携が弱い。

2026年3月時点で、OpenClawのネイティブM365統合はコミュニティから一番望まれているリクエストでしたが、実現には至っていませんでした。Google Workspaceとの連携（gog）は成熟していたのとは対照的に、Outlook・OneDrive・Teamsカレンダーは「予定機能」の状態でした。

ScoutはこのOpenClawの課題のうち、①セキュリティと③M365連携については大きくクリアしてきました。企業向けセキュリティ制御の組み込み、Intune・Purview・Entraによるガバナンス統合、そしてTeams・Outlook・OneDrive・SharePointへのネイティブ接続がその答えです。②の導入・メンテナンスのハードルについても改善が期待されますが、Xでの観測ではFrontier経由の設定はまだ複雑な模様で、完全にクリアとまでは言えなさそうです。

Scoutは、Teamsのメッセージ・Outlookのメールを常時監視しながら、会議の日程調整・締め切り案件の検知・カレンダーブロックを先回りしてこなします。Microsoftはこれを「always-on personal agent」と位置づけています。プロンプトを待つのではなく、先に動くエージェントです。

ただし現時点はFrontierプログラム限定で、GitHubCopilotライセンスとIntune設定が必要です。大企業の一般ユーザーが使えるのはまだ先になります。

第2章：なぜ社内でMCPが死ぬのか、構造から話します

外から繋ごうとするから殺される。MCPが死ぬ理由はこれに尽きます。

私がClaude Enterprise導入時に直面した壁がこれでした。M365 MCP・Claude in Chrome・Notion MCP。期待していた外部連携機能のほぼすべてが死にました。

何度設定を確認しても繋がらない。調べてやっと、社内のセキュリティポリシーが原因だとわかりました。

企業のネットワーク環境では、外部サービスへのHTTPS・WebSocket接続がセキュリティツールによる検査や制限の対象になります。

MCPが使うプロトコルの通信が遮断されるケースはよくあることです。

「M365の外にあるMCPサーバーに外から繋ごうとする」という設計が、企業のセキュリティポリシーと根本的に相性が悪いのです。

塀の外から穴を空けようとするから、守衛に止められます。

MCPが死ぬ理由はセキュリティが強すぎるからではなく、「社内端末から、社外のMCPサーバーへ直接つなぎにいく」という設計そのものの問題です。

ここを理解しておくと、次の章が腑に落ちます。

第3章：ScoutがこのMCP死を突破するかもしれない理由

ScoutはM365の内側で動きます。だから外部MCPより社内ネットワークで生き残る可能性が高い。

Teams・Outlook・OneDrive・SharePointへの接続は外部MCPサーバーへの直通接続とは構造が違い、ScoutがM365の正規機能として提供されるなら社内ネットワークで生き残る可能性が高いと考えています。

外から繋ごうとするから殺される。

Scoutは最初から塀の中にいます。

これが今回の発表で一番重要な点です。

これまで現場の人間がやってきたことは「社内セキュリティの壁を越えて外部MCPサーバーに繋ぐ」という試みでした。それは構造的に難しく、ScoutはM365の正規機能として動くため「穴を空ける必要そのもの」がなくなる可能性があります。

さらにCopilot Studioではすでにリモートのサーバー連携が進んでおり、M365側からツールに接続する経路が整備されつつあります。社内セキュリティポリシーで死んでいたMCPが、M365側の管理された経路で生き返る可能性が出てきました。ただし「可能性」の話です。「必ず生き残る」とは断言できません。

第4章：でも手放しでは喜べない。3つの現実を話します

ここが今日一番の発見です。セキュリティポリシーの壁よりずっと高い壁が、別のところにあります。

①大企業の一般ユーザーにはまだ届かない

現在ScoutはFrontierプログラム限定の実験的リリースです。GitHubCopilotライセンスとIntune設定が必要で、今すぐ全社展開できるものではありません。

加えて、Scoutは現在、米国での試験提供のみです（日経新聞・2026年6月2日「米国で試験提供」と報道）。Frontierプログラムは「初期リリースは英語・米国ベースから開始」というパターンをとっており、日本語環境への展開はさらにその先になります。

うちの会社の場合、Microsoft側のCopilot Coworkですら発表から2か月以上経っても展開が来ていません。Scoutが一般ユーザーに届くまで相当な時間がかかることは折り込んでおく必要があります。

②GitHubCopilotライセンスという追加条件——そして6月1日からの従量課金問題

ScoutにはGitHubCopilotライセンスが必要です。ただし今月から、そのGitHub Copilotの料金体系が大きく変わっています。

2026年6月1日、GitHubはCopilotの全プランを従量課金（GitHub AI Credits、1クレジット＝$0.01）へ移行しました。各プランには月額料金と同額分のクレジット枠が含まれており、通常のコード補完は無制限で引き続き使えます。ただしチャット・エージェント動作はトークン消費量に応じてこのクレジット枠を消費し、枠を超えた分は追加課金になります。

Scoutは「常時稼働」のエージェントです。メール・カレンダー・Teamsを常時監視しながら、バックグラウンドで処理し続けます。この継続的な動作が月額料金内のクレジット枠に収まるのか、大幅に超過するのか、これは使ってみないことにはわかりません。

通常のCopilot利用でも、エージェントモードを使い込むと含まれるクレジット枠の10〜50倍の費用が膨らんだケースが報告されています。常時稼働型のScoutが何百人分もバックグラウンドで動き続けた場合、基本クレジット枠を大幅に超過するリスクは十分にあります。

GitHubCopilotライセンスの要件は「ライセンスを取得すればよい」という話ではなく、「含まれるクレジット枠の範囲内に収まるのか、超過した場合のコストはいくらになるのか」を稟議で説明できるか、という別の壁になっています。

本格導入前に小規模なPoC（概念実証）で実際のAI Credits消費量を押さえておくことが必須になりそうです。

③本当の壁は「個人情報ポリシー」だった

Intune環境も、GitHubCopilotのルートも。技術的な前提条件はおそらく揃いつつあります。

ではなぜMicrosoft側のCopilot Coworkすら2か月以上来ないのか。

Scoutは社員のメール・カレンダー・チャット履歴を自然に読み込みます。業務を自動化するために。

ここで確認しておきたいのは、社員の氏名やメールアドレスも個人情報に該当するということです。個人を識別できる情報はすべて個人情報です。Scoutが読み込むメール・カレンダー・チャットには、この個人情報が大量に含まれています。

技術的には、CopilotがMicrosoft Graph経由でユーザーのメール・予定・チャット・ファイルを処理するという話です。しかし社内規定上は「AIに個人情報・機密情報を処理させてよいのか」という整理を避けて通れません。

これは技術の話ではなく、ポリシーの話です。IT部門が設定を変えればいい話ではありません。「社員のメールをAIが読むことを会社として認めるか」という判断です。そこに合意が取れて初めて、Scoutは動き始めます。

私自身、Claude Enterprise導入時にこの壁にぶち当たりました。社内に個人情報を扱えるLLMサービスはそもそも存在せず、「機密情報の入力はOK・個人情報の入力はNG」という整理で導入しました。おそらく多くの大企業で同様の壁があるはずです。

技術の壁は設定変更で越えられます。でもポリシーの壁は、人と時間と合意が必要なのです。

この難しさを示す事例があります。

2026年4月、情報セキュリティの研究者から、日本の裁判所のMicrosoft 365環境で、少なくとも14名分の職員の個人識別子が外部から取得可能な状態にあるという報告が出ました。

少なくとも報告上は、TeamsとOutlookの「Safe Links」機能がURLを書き換える際に職員情報を平文のまま埋め込む仕様と、外部連絡先検索機能がデフォルトで有効だったことの組み合わせが原因だったという指摘です。報告が正しければ、M365の「親切設計」が個人情報を漏らしていたことになります。

私の観測範囲では、AIクラスタでこの件を取り上げているのを見たことがありません。Scoutの話をする上でこの事実は無視できないと思っています。

Scoutは確かに塀の中にいます。でも塀の中でも、M365自体の仕様によって別の経路で情報が外に出ていく可能性があります。

社内セキュリティポリシーは技術的な設定変更で越えられるかもしれません。

でも個人情報ポリシーの壁は、IT部門・法務・コンプライアンス・情報セキュリティが合意するまで動かせません。

第5章：今日から始める3つのアクション

①社内のCopilotコミュニティで、この話を騒ぐ

IT部門に直接パスが社内にない場合、Copilotコミュニティが唯一の発信の場です。「Scoutを使うためには、個人情報ポリシーの整理が必要だ」という情報を投げ込む。AI推進担当として声を上げることが、最初のアクションです。

②「Copilot個人情報ポリシー」の現状を確認する

Scoutが動く前提は、CopilotがM365内の個人情報データを処理することへの社内合意です。今の自分の会社でそのポリシーがどうなっているかを確認し、整理されていないなら誰に働きかければよいかを把握しておく。速やかに確認する予定です。

③米国先行リリースの情報にアンテナを張り続ける

Scoutは現在、米国での試験提供からのスタートです。実際に使った人の体験談、個人情報ポリシーの整理方法、GitHubCopilot従量課金の実際の消費量など、有益な情報がXや英語圏から出始めるはずです。自分の環境でどう適用できそうかを情報が出るたびに整理していく。それが今できる一番現実的なアクションです。

同じ大企業でMCPが死ぬ壁にぶち当たっている方、教えてください。

個人情報ポリシーの壁を越えるきっかけ、みなさんの会社ではどうやって作りましたか？

ここまで読んでいただきありがとうございます。

私は大企業窓際課長として、Claude Coworkを毎日現場にぶち込みながら試行錯誤を続けています。

同じ立場で「Claudeを使いたいのに社内で使えない」「MCPが死ぬ」と悩んでいる管理職の方は、実際に動いている事例やプロンプトをXで随時共有しています。

→ @madogiwacowork