エンタープライズのAI導入で、モデルの賢さと同じくらい——時にそれ以上に——重くのしかかってきた問いがあります。「そのモデルは、誰の管理下で、どこで動くのか」です。フロンティアモデルを使いたくても、「データを社外のベンダーAPIに出せない」「認証・課金・監査を既存の仕組みに乗せられない」という理由で見送った企業は少なくありません。2026年6月末、この構図を大きく動かす発表がありました。**AnthropicのClaudeが、Microsoft Foundry（旧 Azure AI Foundry）で一般提供（GA）**になったのです（Anthropic公式、Microsoft Azure Blog）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「どのモデルを、どう安全に業務へ載せるか」を日々支援しています。本稿は「Claudeが速くなった／賢くなった」という話ではありません。フロンティアモデルが自社クラウドの統制の内側で動くようになり、企業のモデル選定が『APIをつなぐ』から『カタログから選ぶ』へ変わる——その構造変化と、日本企業が押さえるべき勘所を実務目線で整理します。
何が起きたのか——ClaudeがMicrosoft FoundryでGA
要点は3つです。
- 2026年6月29日、ClaudeがMicrosoft FoundryでGA。Claude Opus 4.8 や Haiku 4.5 といった現行モデルが Messages API 経由で利用可能になりました（米国データゾーン構成では Sonnet 5 を含む）。プロンプトキャッシュや拡張思考（extended thinking）にも対応します（Microsoft Learn）。
- Azure上のNVIDIA GB300で動く。Azureホスト構成のClaudeは、NVIDIA GB300 Blackwell Ultra を使った Microsoft 管理下のインフラで推論されます（NVIDIA公式ブログ）。エージェントのような長時間・大規模な処理を、本番品質のインフラで回せることを意味します。
- 既存のAzure運用の中に収まる。認証は Microsoft Entra ID、権限は Azure RBAC、支払いは Azure の請求、統制は既存のガバナンスポリシー——普段Microsoftのサービスに使っているのと同じ管理面で、Claudeを扱えるようになりました。
これまで「Claudeを使う」といえば、Anthropic（あるいはAWS Bedrock／Google Vertex）のAPIを別途契約し、認証も課金も監査も“もう一つの経路”として作り込む必要がありました。GAによって、その経路が 自社が既に統制しているAzureの内側 に一本化されたのが、今回の本質です。
「どこで、誰の管理下で動くか」——2つのデプロイ形態
Microsoft Foundry のClaudeには、統制の観点で押さえるべき2つの選択肢があります。
| 選択肢 | 実行場所と管理面 | 向いている用途 |
|---|---|---|
| Hosted on Azure | Azure環境で実行。Entra ID認証・Azure RBAC・Azure課金・既存ガバナンスに統合。米国データゾーンによるデータ処理の所在制御が可能 | 認証・課金・監査を自社のAzure運用に揃えたい本番ワークロード |
| Hosted on Anthropic（旧 Foundry Preview） | Anthropic側のインフラで実行 | Azure側にまだ来ていない最新機能・モデルをいち早く使いたい場合 |
特にエンタープライズにとって効いてくるのが、Hosted on Azure 側の統制です。データ処理の所在を選べる米国データゾーンが用意され、機微なワークロード向けにはゼロデータ保持（zero data retention）——API呼び出し完了後にプロンプトや出力を保持しない設定——も選べます。「フロンティアモデルは使いたいが、データの扱いを自社ポリシーの外に置けない」という規制業種の壁を、構成の選択で下げられるようになった、という点が重要です。
ただし「自社のAzureテナントの中で動く」ことと、「日本国内でデータが完結する」ことは別問題です。現時点で選択できるのは米国データゾーンなどであり、日本のデータ所在（データレジデンシー）要件がある場合は、提供リージョンとデータゾーンの構成を必ず個別に確認してください。「Azureだから安心」で止めず、どのリージョンで推論され、どこにログが残るのかまで詰めるのが実務の要諦です（データ主権の考え方はソブリンAIの稿にまとめました）。
「単一モデル時代」の終わり——モデルは“カタログから選ぶ”ものになった
今回の発表が示すもう一つの潮流は、エンタープライズAIの「単一モデル時代」が終わりつつあることです。
Microsoft Foundry は、もともと OpenAI の GPT に加え、Meta の Llama、Mistral、Cohere といった各社モデルを同じカタログ・同じ管理面の下に並べてきました。そこにClaudeが加わったことで、企業は「1社のモデルに全社を賭ける」のではなく、用途ごとに最適なモデルを、同じ統制の中で選び分けることができます。実際、Microsoft 365 Copilot の Researcher では、GPT が下書きし Claude が正確性・引用の妥当性をレビューする、といった複数モデル併用の構成も採られています（Microsoft公式）。
これは調達・アーキテクチャの両面で意味を持ちます。
- 調達: モデルは「別途API契約する外部サービス」から、「自社のクラウド予算・権限・監査の内側でスイッチできるカタログ項目」に近づいた。ベンダーロックインの重心が下がり、モデルの入れ替えが構成変更に近づく。
- アーキテクチャ: アプリ側を特定モデルに密結合させず、モデルを差し替え可能な部品として扱う設計が現実的になった。コスト・速度・精度・データ要件で使い分ける「マルチモデル前提」が、例外ではなく既定になっていく。
モデルがカタログ化するほど、アプリ側を特定モデルAPIに直結させる設計は割に合わなくなります。プロンプト・ツール接続・評価をモデル非依存の層で持ち、モデルは構成で差し替える——この作りにしておくと、次に出る「より安い／より速い／データ要件に合う」モデルへ、業務ロジックを壊さずに移れます（モデル供給リスクの分散はこちらの稿も参照）。
統制の重心は「どのモデルか」から「エージェントが何をするか」へ
ここで注意したいのは、「フロンティアモデルが自社クラウドの統制下で動く」ことと、「AIエージェントが統制されている」ことは、まったく別だという点です。
Entra ID・RBAC・データゾーンが守るのは、主に**「誰がモデルを呼べるか」「データがどこで処理されるか」です。しかしエージェント時代のリスクは、その一段先——「モデルが（ツールを通じて）何を実行したか」にあります。基幹システムを更新する、メールを送る、外部にデータを渡す。こうした行為（アクション）**は、モデルがAzure内で動いていようと、それ自体では制御されません。
つまり、今回のGAで手に入るのは強固な“入口”の統制であって、“出口”＝エージェントの実行の統制ではない、ということです。ここを取り違えると、「Azureの内側だから安全」という誤った安心のまま、承認も監査もないエージェントに実システムへの手を持たせてしまいます。エージェントの統制は、モデルの実行場所ではなく、ツール単位の実行権限・実行前承認・監査ログで設計するのが筋です（この論点はツール単位の統制の稿で詳述しました）。
homula の観点——「選べるモデル」を前提に、統合と統制を土台に置く
モデルがカタログから選べる時代に、日本企業がとるべき勝ち筋は明確です。モデルの当たり外れに賭けるのではなく、どのモデルでも成果を出せる“土台”を持つこと。homula が推奨する順序は次の通りです。
- 接続層をモデル非依存で持つ。homula の統合プラットフォーム Agens は、MCP（Model Context Protocol）を活用して 200以上のツールと構築ゼロで接続します。業務システムへの配管をモデルから切り離しておけば、Foundry上でClaudeを選ぼうとGPTを選ぼうと、業務ロジックはそのまま使い回せます。
- “出口”の統制を先に敷く。モデルがどこで動くかに関わらず、実システムに手が届くエージェントには統制が要ります。Agens Control は、実行前の承認フロー・DLP・RBAC・5年分の監査ログを提供し、「どのエージェントが・何を・いつ実行したか」を後から証明できる状態を作ります。入口（Entra ID/RBAC）と出口（ツール実行の承認・監査）の両輪が揃って初めて、フロンティアモデルを安心して本番に載せられます。
- 小さく検証してから広げる。homula の AIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結。「どのモデルが自社の業務に効くか」を、実データに近い形で早期に見極められます。
homula は、n8n / Dify / LangGraph などを用いた接続前提のエージェント設計で、処理時間を93%削減した実績があります。モデルの選択肢が増えることは追い風ですが、成果の源泉は依然としてつなぐ配管と、誰が何をできるかの統制にあります。
まとめ
- 2026年6月29日、ClaudeがMicrosoft FoundryでGA。Entra ID認証・Azure課金・RBAC・米国データゾーンという自社の統制の内側で、Azure上のNVIDIA GB300を使ってフロンティアモデルを動かせるようになった。
- これは「Claudeが速い」話ではなく、モデル選定が『外部APIをつなぐ』から『統制されたカタログから選ぶ』へ変わる構造変化。GPT・Llama等と並ぶ「選べるモデル」としてのマルチモデル前提が既定になりつつある。
- ただし、入口（誰がモデルを呼べるか）の統制と、出口（エージェントが何を実行するか）の統制は別物。「Azureの内側だから安全」で止めず、ツール単位の承認・監査で“出口”を設計する必要がある。
- 日本企業は、モデル非依存の接続層＋実行の統制を土台に置き、その上でモデルを構成として選び分けるのが堅い。日本のデータ所在要件は、リージョンとデータゾーンまで詰めて確認する。
「選べるモデル」が増えるほど、勝負を分けるのは賢いモデル選びより、どのモデルでも成果を出せる土台——つなぐ配管と、実行の統制です。homula は、その土台づくりから本番・全社展開までを伴走します。