Microsoft Foundry / Azure OpenAIの運用担当者が今回まず押さえるべき結論は、Claude Codeを「個人開発者向けのAIコーディングツール」としてではなく、AzureのID管理、RBAC、監視、課金管理の中で使えるエンタープライズ向け開発エージェントとして評価すべき、という点です。
2026年4月23日更新のMicrosoft Learn「Configure Claude Code for Microsoft Foundry」では、Claude Code CLIやVS Code拡張をMicrosoft Foundryに接続し、Microsoft Entra IDまたはAPIキーで認証し、CLAUDE.mdでプロジェクト文脈を渡し、Azure RBACやGitHub Actionsまで含めて運用する流れが整理されています。すぐに試す前に、サブスクリプション条件、対応リージョン、モデルデプロイ、権限設計を確認することが失敗を避ける近道です。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIでClaude Codeを使う意味
Claude Codeは、コードベースを読み取り、ファイル編集、コマンド実行、開発ツール連携を行うエージェント型のコーディングツールです。Microsoft Foundry向けに構成すると、Claude Codeの推論リクエストをMicrosoft Foundry上のClaudeモデルへルーティングでき、Azure側のコンプライアンス境界、プライベートネットワーク、ロールベースアクセス制御、コスト管理を活用しやすくなります。(Microsoft Learn)
これは、単に「ClaudeをAzureから呼べる」という話ではありません。実務上の価値は、開発者が使うAIコーディングエージェントを、IT管理者が統制できる形に寄せられることです。
たとえば、次のような組織では検討価値が高くなります。
| 利用シーン | Microsoft Foundry経由が向いている理由 |
|---|---|
| 社内コードをAIコーディング支援に使いたい | Azureの認証、権限、監視、ネットワーク管理に寄せやすい |
| Azure OpenAIやFoundry Modelsをすでに運用している | 既存のAzure管理プロセスに組み込みやすい |
| 開発チームごとに利用範囲を分けたい | Azure RBACでユーザー、グループ、プロジェクト単位の権限設計がしやすい |
| CI/CDでコードレビューやテスト生成を自動化したい | GitHub Actionsとの組み合わせを前提に設計できる |
| コストや利用量を管理したい | Foundryポータル、Azure Monitor、Azure Cost Managementで確認しやすい |
一方で、個人の小規模検証や、Azure側の契約・権限調整に時間をかけられないケースでは、直接Claude Codeを使うほうが導入は簡単です。社内導入では「便利だから使う」ではなく、「どのコード、どのユーザー、どのリポジトリ、どのコスト上限で使わせるか」まで決めてから進めるべきです。
2026年4月更新で特に見るべきポイント
今回の公式ドキュメントで実務上重要なのは、Claude Codeの設定手順だけでなく、企業導入で問題になりやすい周辺設定まで一連の流れとして示されたことです。
| 注目ポイント | 実務での意味 |
|---|---|
| Claude Code CLIとVS Code拡張の両方を扱っている | ターミナル派とIDE派の開発者を同じFoundry基盤で運用しやすい |
| Microsoft Entra ID認証を推奨している | APIキー配布に頼らず、退職者対応や権限変更をAzure側で管理しやすい |
| Foundryリソース名またはBase URLで接続できる | 環境変数管理により、端末・CI・開発環境ごとの構成を標準化しやすい |
CLAUDE.mdによるプロジェクト文脈を明示している | コード規約、アーキテクチャ、テスト方針をAIに継続的に読ませやすい |
| Azure RBAC、GitHub Actions、監視、トラブルシューティングまで含む | PoC止まりではなく、チーム展開を前提に設計しやすい |
特にIT adminsとproduct ownersが見るべきなのは、インストール手順よりも「誰に、どの権限で、どのモデルを、どの開発フローで使わせるか」です。Claude Codeはファイル編集やコマンド実行を行えるため、通常のチャットAIよりも運用ガードレールの重要度が高くなります。
導入前に確認すべき前提条件
Claude Code for Microsoft Foundryを試す前に、まずAzure側の条件を確認します。公式ドキュメントでは、有効な支払い方法を持つAzureサブスクリプション、Microsoft Foundryへのアクセス、Claudeモデルに対応したリージョンのFoundryプロジェクト、リソースグループでのContributorまたはOwner権限、Azure Marketplaceへのアクセスなどが前提として示されています。(Microsoft Learn)
特に注意したいのは、サブスクリプションとリージョンです。公式ページでは、CSPサブスクリプション、無料試用、学生向け、スタートアップクレジット系、Azureクレジットのみのスポンサードサブスクリプションなどが対象外として挙げられています。また、Claudeモデルの利用ページでは、ClaudeモデルのFoundry利用資格やクォータ条件にも触れられているため、企業導入では契約種別を事前に確認するのが安全です。(Microsoft Learn)
対応リージョンも重要です。公式情報では、Claudeモデルを利用するMicrosoft Foundryプロジェクトの対応リージョンとしてEast US 2とSweden Centralが示されています。日本国内のデータ所在地や業界規制が関係する場合は、「Azureだから問題ない」と判断せず、利用部門、法務、セキュリティ部門で確認してからPoCに進めるべきです。(Microsoft Learn)
Claude Codeで使うモデルをどう選ぶか
Claude Codeは用途に応じて複数のClaudeモデルを使い分けます。公式ドキュメントでは、一般的なコーディング向けにSonnet、軽量な読み取りや小規模編集向けにHaiku、複雑な推論向けにOpusが示されています。(Microsoft Learn)
| Claude Codeでの役割 | 推奨デプロイ例 | 向いている作業 | 導入時の判断 |
|---|---|---|---|
| Primary model | claude-sonnet-4-6 | 通常のコード理解、修正、設計相談 | まずPoCで優先して用意する |
| Fast model | claude-haiku-4-5 | ファイル読み取り、小さな編集、軽量タスク | コストと速度を重視するチームで有効 |
| Extended thinking | claude-opus-4-6 | 複雑な設計、長い推論、難度の高いレビュー | 利用目的とコストを見て追加する |
ここで失敗しやすいのは、モデル名とデプロイ名を混同することです。Azure上で作成したデプロイ名が、環境変数で指定する値と一致していないと、Claude Codeはモデルを見つけられません。モデルをデプロイしたら、Foundryポータルの詳細画面でデプロイ名、Target URI、Keyを確認し、設定値として記録しておきましょう。
Model Routerを使う選択肢もありますが、公式ドキュメントでは、Model Router version 2025-11-18が一部のClaudeモデルをサポートする一方、claude-sonnet-4-6やclaude-opus-4-6は現時点でサポート対象外とされています。新しいSonnetやOpusを明示的に使いたい場合は、Model Routerではなく個別デプロイを参照する構成にしたほうが確実です。(Microsoft Learn)
基本設定の流れ
設定の全体像は、次の順序で進めると整理しやすくなります。
| 手順 | 作業 | 管理者が確認すること |
|---|---|---|
| 1 | Foundryプロジェクトを作成 | リージョン、課金、Marketplace利用可否 |
| 2 | Claudeモデルをデプロイ | Sonnet、Haiku、Opusの必要性とデプロイ名 |
| 3 | 認証方式を決める | 原則はMicrosoft Entra ID、検証用途のみAPIキー |
| 4 | Claude Code CLIをインストール | 端末配布方法、更新管理、社内ポリシー |
| 5 | 環境変数を設定 | Foundryリソース名、モデルデプロイ名、APIキー有無 |
| 6 | /statusで接続確認 | API providerがMicrosoft Foundryになっているか |
| 7 | CLAUDE.mdを作成 | コード規約、テスト方針、禁止事項を明文化 |
| 8 | RBACを設定 | Azure AI User、管理者、開発者のスコープ |
| 9 | 監視とコスト確認 | トークン、リクエスト、レイテンシ、エラー率 |
Claude Code CLIのインストールでは、Microsoft LearnがネイティブインストーラーまたはHomebrewを案内しており、npmインストール方式は非推奨とされています。組織端末では、curl | bashやirm | iexの実行がセキュリティポリシーで制限されることがあるため、社内配布方式や検証済みスクリプトの扱いを先に決めておくと展開がスムーズです。(Microsoft Learn)
環境変数の設定例
Claude CodeをMicrosoft Foundryに接続するには、Foundry統合を有効化し、リソース名またはBase URLを指定します。Bash / WSLでは、次のように設定します。
export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_RESOURCE=<your-resource-name>
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet-4-6"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="claude-haiku-4-5"
export ANTHROPIC_DEFAULT_OPUS_MODEL="claude-opus-4-6"PowerShellでは、次のように設定します。
$env:CLAUDE_CODE_USE_FOUNDRY = "1"
$env:ANTHROPIC_FOUNDRY_RESOURCE = "<your-resource-name>"
$env:ANTHROPIC_DEFAULT_SONNET_MODEL = "claude-sonnet-4-6"
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL = "claude-haiku-4-5"
$env:ANTHROPIC_DEFAULT_OPUS_MODEL = "claude-opus-4-6"ANTHROPIC_FOUNDRY_RESOURCEを使うと、Claude Codeはhttps://<resource-name>.services.ai.azure.com/anthropic形式のエンドポイントを構成します。Base URLを明示したい場合は、ANTHROPIC_FOUNDRY_BASE_URLを使う選択肢もあります。(Microsoft Learn)
ここでの実務ポイントは、環境変数を個人の端末だけに閉じないことです。チーム展開する場合は、開発端末、Dev Container、CI/CD、VS Code設定で同じ値をどう配布するかを決めておきます。特にモデルデプロイ名は、後から変更すると利用者全員に影響します。最初に命名規則を決めておきましょう。
認証はMicrosoft Entra IDを基本にする
Claude Code for Microsoft Foundryでは、Microsoft Entra IDとAPIキーの2つの認証方式が使えます。公式ドキュメントでは、企業環境、チームアクセス、CI/CDではMicrosoft Entra IDが推奨されています。APIキーは、短期検証やAzure CLIを使えない環境には便利ですが、秘密情報の管理が必要になります。(Microsoft Learn)
| 認証方式 | 向いている用途 | 注意点 |
|---|---|---|
| Microsoft Entra ID | 社内標準運用、チーム利用、権限管理、監査 | az login、テナント、RBACの設計が必要 |
| APIキー | 短期PoC、閉じた検証環境、Azure CLIが使えない端末 | キー漏えい、ローテーション、権限の細分化が課題 |
Microsoft Foundry使用時は、Claude Code内の/loginや/logoutではなく、Azure側の資格情報で認証します。テナントが複数ある企業では、az login --tenant <tenant-id>で正しいテナントにサインインしているかを確認してください。az account showで対象サブスクリプションを確認する習慣も重要です。(Microsoft Learn)
Azure RBACでチーム展開を設計する
チームにClaude Code利用を許可する場合は、Azure RBACを先に設計します。Microsoft FoundryのRBACドキュメントでは、Microsoft Entra ID認証を使う場合にRBACが適用され、キー認証ではキーがロール制限なしのアクセスを与えるため、より細かな制御にはEntra ID認証が推奨されています。(Microsoft Learn)
Claude CodeでFoundry上のClaudeモデルを呼び出すだけなら、公式ドキュメントではAzure AI UserまたはCognitive Services Userがモデル呼び出しとデプロイ表示に必要な権限として示されています。Foundryネイティブな最小権限としてはAzure AI Userを基本に考えるのが分かりやすいです。(Microsoft Learn)
| 役割 | 推奨される権限設計の例 |
|---|---|
| IT管理者 | サブスクリプションまたはリソースグループでOwner。課金、ネットワーク、ポリシーを管理 |
| AI基盤管理者 | FoundryリソースでAzure AI Account Ownerまたは必要な管理ロール |
| チームリード | FoundryリソースまたはプロジェクトでAzure AI Project Manager |
| 開発者 | FoundryプロジェクトでAzure AI User、必要に応じてFoundryリソースでReader |
| CI/CD用サービスプリンシパル | 必要なプロジェクトまたはリソースに限定してAzure AI User相当を付与 |
実務では、個人ユーザーに直接ロールを付けるより、Microsoft Entra IDのセキュリティグループにロールを割り当てるほうが管理しやすくなります。入退社、プロジェクト異動、外部委託メンバーの参加がある組織では、グループ単位の付与を標準にしましょう。
CLAUDE.mdでAIにプロジェクトの前提を渡す
CLAUDE.mdは、Claude Codeにプロジェクト固有の文脈を渡すための重要なファイルです。公式ドキュメントでは、グローバル設定、リポジトリルート、現在のディレクトリのCLAUDE.mdを上から順に読み込み、後のファイルが前の設定を上書きする形でマージされると説明されています。(Microsoft Learn)
単に「このプロジェクトはECサイトです」と書くだけでは効果が薄くなります。開発者がコードレビューで毎回指摘している内容を、AIに最初から渡すのがコツです。
## Project Overview
社内向け在庫管理システム。APIはFastAPI、フロントエンドはReactで構成。
## Coding Rules
- 既存のディレクトリ構成を変更しない
- APIレスポンス形式は既存のschemaを優先する
- DBマイグレーションは必ずレビュー対象にする
- 認証・認可まわりの変更は実装前に方針を提示する
## Test Policy
- API変更時はpytestを追加する
- UI変更時は主要なユーザーフローのテスト観点を提示する
- 外部APIを直接叩くテストは書かない
## Do Not
- 本番シークレットを読み取ろうとしない
- 既存のログ出力方針を勝手に変更しない
- 大規模リファクタリングを確認なしに実行しないCLAUDE.mdは、AI向けのREADMEではなく「チームの開発判断基準」です。コード規約、禁止事項、テスト方針、セキュリティ制約、リリースルールを書いておくと、Claude Codeの提案がプロジェクトに合いやすくなります。
VS Code拡張とGitHub Actionsでの活用
VS Code拡張を使う場合は、拡張機能側に環境変数を設定します。公式ドキュメントでは、VS Codeの設定からClaude CodeのEnvironment Variablesを編集し、CLAUDE_CODE_USE_FOUNDRY、ANTHROPIC_FOUNDRY_RESOURCE、必要に応じてANTHROPIC_FOUNDRY_API_KEYを設定する流れが示されています。(Microsoft Learn)
注意点は、ターミナルで環境変数を設定していても、VS Codeがその環境を引き継いでいない場合があることです。特にWSLとWindowsホストをまたぐ環境では、Windows側とWSL側のどちらで拡張が値を見ているかを確認してください。接続できないときは、環境変数を設定したターミナルからcode .で起動すると切り分けしやすくなります。(Microsoft Learn)
GitHub Actionsでは、プルリクエスト時のテスト生成や、コメント内の@claudeをトリガーにしたレビュー支援が想定されています。APIキーを使う場合は、リポジトリのSecretsに保存し、ワークフロー内でCLAUDE_CODE_USE_FOUNDRY、ANTHROPIC_FOUNDRY_RESOURCE、ANTHROPIC_FOUNDRY_API_KEYを渡します。(Microsoft Learn)
ただし、CI/CDでClaude Codeに編集権限を与える場合は、最初から広い権限を渡さないでください。対象パス、実行トリガー、許可するツール、PRへの書き込み権限を最小化し、最初は「テスト案の生成」「レビューコメント作成」など低リスクな用途から始めるのが現実的です。
監視・コスト管理で見るべき指標
Claude Codeをチーム展開する場合、最初のPoCから利用量を可視化しておくべきです。Microsoft Foundry Modelsの監視では、FoundryポータルやAzure Monitorでメトリックを確認でき、コスト関連はAzure Cost Managementへのリンクから消費後のコストデータを確認できます。コストデータはAzureポータルのCost analysisに反映されるまでおおよそ数時間の遅延があるとされています。(Microsoft Learn)
見るべき指標は、次の4つです。
| 指標 | 見る理由 |
|---|---|
| トークン消費量 | 想定以上の長文コンテキストや無駄な再試行を発見する |
| リクエスト数 | チーム別・用途別の利用傾向を把握する |
| レイテンシ | 開発者体験の悪化やモデル選択のミスマッチを検出する |
| エラー率・429 | クォータ不足、認証不備、過剰な自動実行を見つける |
Azure OpenAIをすでに監視しているチームは、メトリックのカテゴリにも注意が必要です。Microsoftの監視ドキュメントでは、Azure OpenAIカテゴリだけでなく、Azure OpenAI、DeepSeek、Phiなどを含むModelsカテゴリへの切り替えが推奨されています。Foundry Models全体を見たい場合は、既存ダッシュボードの対象範囲を見直しましょう。(Microsoft Learn)
また、Foundry Modelsのリソース制限として、1つのFoundryリソース内の最大デプロイ数は32とされています。Claudeモデルを複数バージョンで検証し続けると、不要なデプロイが残って上限に近づくことがあります。使わなくなったデプロイは削除し、命名規則と棚卸しルールを用意しておくと運用が安定します。(Microsoft Learn)
よくあるつまずきと対処法
| 症状 | よくある原因 | 対処 |
|---|---|---|
| Claude CodeがAnthropicログインを求める | CLAUDE_CODE_USE_FOUNDRY=1が設定されていない | 環境変数を設定し、ターミナルやVS Codeを再起動する |
Failed to get tokenが出る | Azure CLI未ログイン、テナント不一致 | az loginまたはaz login --tenant <tenant-id>を実行する |
| モデルが見つからない | デプロイ名と環境変数の値が一致していない | Foundryのデプロイ名を確認し、ANTHROPIC_DEFAULT_*_MODELを修正する |
| 401 / 403が出る | APIキー不備、RBAC不足、対象リソース違い | キー、サブスクリプション、Azure AI User権限を確認する |
| 429が出る | レート制限またはクォータ不足 | 利用量を監視し、リトライ制御やクォータ申請を検討する |
| VS Code拡張が接続できない | VS Codeが環境変数を読み込んでいない | 設定JSONを確認し、必要なら環境変数設定後にcode .で起動する |
| WSL環境だけ失敗する | WindowsホストとWSLで環境変数の参照先が違う | 両方に必要な変数を設定し、拡張の実行環境を確認する |
この種のエラーは、Claude Code自体の問題というより、Azure側の認証、RBAC、モデルデプロイ名、リージョン条件が原因になりやすいです。問い合わせを受ける管理者は、最初に/statusの出力、az account show、対象Foundryリソース名、モデルデプロイ名を確認すると切り分けが速くなります。(Microsoft Learn)
導入判断のチェックリスト
Microsoft Foundry / Azure OpenAIの運用チームがClaude Codeを導入するなら、次の順で進めるのが現実的です。
| フェーズ | やること | 合格ライン |
|---|---|---|
| 事前確認 | サブスクリプション、請求、リージョン、Marketplace権限を確認 | モデルをデプロイできること |
| 小規模PoC | 1つのリポジトリ、少人数、Entra ID認証で試す | /statusでMicrosoft Foundryが表示されること |
| 開発ルール整備 | CLAUDE.mdに規約、禁止事項、テスト方針を書く | AIの提案がチーム方針から外れにくいこと |
| 権限設計 | Azure AI Userを中心にグループ単位で付与 | 個人直付けの権限が増えすぎないこと |
| 監視設計 | トークン、リクエスト、エラー、コストを見る | 利用増加時に異常を検出できること |
| CI/CD展開 | GitHub Actionsでレビューやテスト生成を限定的に使う | 書き込み権限と対象パスが制限されていること |
最初から全社展開する必要はありません。まずは、影響範囲の小さいリポジトリでSonnet中心のPoCを行い、CLAUDE.md、RBAC、監視ダッシュボード、トラブルシューティング手順をセットで作るのが効果的です。その後、Haikuによる軽量処理、Opusによる難度の高い設計レビュー、GitHub Actionsによる自動レビューへ段階的に広げていくと、便利さと統制のバランスを取りやすくなります。
Microsoft Foundry経由のClaude Codeは、開発者の生産性向上だけでなく、AIコーディング支援を企業のAzureガバナンスに乗せるための選択肢です。次に取るべき行動は、インストールではなく、まず自社のサブスクリプション条件、リージョン要件、RBAC設計、対象リポジトリを確認することです。そこまで決めてから設定に進めば、PoC後に本番展開へ移行しやすくなります。
コメント