Claude Code企業導入ガイド｜AWS Bedrock・Microsoft Foundryの2パターン比較【2026年最新】

2026年3月6日

「Claude Codeを使いたいが、サブスク契約ができない」という壁

Claude Codeの実力は知っている。個人では毎日使っている。しかし、会社で使おうとすると「サブスクリプション契約ができない」という壁にぶつかる — そんな経験をしている方は多いのではないでしょうか。

日本企業、特に製造業やエンタープライズ環境では、以下のような制約が当たり前に存在します。

外部SaaSへのソースコード・業務データ送信が原則禁止
利用ツールはIT部門の承認リストに限定
個人のAnthropicアカウントで業務データを扱うのはコンプライアンス違反
新規SaaS契約は稟議・セキュリティ審査で数ヶ月かかる

Claude Codeの個人サブスクリプション（Max $100/月、Pro $20/月）を会社で契約しようとしても、「前例がない」「Anthropicとの直接契約は承認できない」と言われるケースは珍しくありません。

しかし、諦める必要はありません。 AWS BedrockやMicrosoft Foundryといった、すでに社内で承認されているクラウドプロバイダーのAPI経由であれば、サブスク契約なしでClaude Codeを業務に導入できます。

私の会社では、セキュリティ審査を経て AWSとAzureのAPI利用が承認されていた ため、この2つの経路でClaude Codeを導入しました。本記事ではこの 2パターンの導入方法 と、誰でもダブルクリックで起動できる ワンクリック起動ランチャー の作り方を共有します。

なお、Claude Codeには他にも接続方法（Google Cloud Vertex AI等）があります。自社の環境に合った方法については、Claude Code公式ドキュメントをご確認ください。

この記事のポイント

サブスク契約なしでもClaude Codeは使える（AWS Bedrock / Microsoft Foundry経由）
既存のクラウド契約枠を活用するのでIT部門の承認が通りやすい
バッチファイル1枚配るだけで同僚も即使えるワンクリック起動ランチャーを公開

Claude Code企業導入の2パターン

企業環境でClaude Codeを利用するには、クラウドプロバイダーのAPI経由が現実的です。AWS BedrockとMicrosoft Foundry、自社のクラウド環境に合わせて選択しましょう。

比較表

項目	AWS Bedrock経由	Microsoft Foundry経由
セキュリティ	高（VPC内・IAM制御）	高（Entra ID・RBAC）
セットアップ難度	中（AWS CLI・SSO設定）	中（Foundry・Entra ID設定）
コスト体系	従量課金（API利用量）	従量課金（API利用量）
既存契約活用	AWS契約に含められる	MACC対応で既存契約活用可
利用可能モデル	Opus 4.6 / Sonnet 4.6 等	Opus 4.6 / Sonnet 4.6 等
適したユーザー	AWS環境がある企業	Azure/M365メインの企業
IT部門の承認	通りやすい（AWSは承認済みが多い）	通りやすい（Azureは承認済みが多い）

パターン1: AWS Bedrock経由 — ライトユーザーの入口に最適

なぜAWS Bedrockなのか

多くの日本企業では、すでにAWSを利用しています。AWS契約の枠組みの中でClaude APIを利用できるBedrock経由は、IT部門への説明が最も通りやすいパターンです。

具体的なメリットは以下の通りです。

既存のAWS契約・支払いフローをそのまま利用可能
SSO認証（Okta/Azure AD等）との統合で、個別のAPIキー配布が不要
IAMポリシーで利用者・利用範囲を細かく制御可能
VPC内通信でデータの外部流出リスクを最小化
CloudWatch / CloudTrail で利用状況の監査ログを自動取得

セットアップの自動化

筆者の環境では、ライトユーザーがClaude Codeを手軽に体験できるよう、セットアップを完全自動化するバッチファイルを作成しました。以下の処理をワンクリックで実行します。

1. AWS SSO認証（ブラウザでのSSO承認）
2. AWS CLI設定の自動生成（~/.aws/config）
3. Git Bashの導入確認・パス設定
4. 環境変数の設定（CLAUDE_CODE_USE_BEDROCK=1, AWS_REGION 等）
5. Claude Codeの起動確認

特にポイントとなるのは、AWS SSO認証との連携です。aws sso login --profile [プロファイル名] でブラウザが開き、普段使っている社内IDで認証するだけでClaude Codeが使えるようになります。APIキーの管理やローテーションを利用者に意識させない設計にできます。

環境変数設定

Claude CodeをBedrock経由で使うための最小限の環境変数設定は以下の通り。

# 必須: Bedrock利用を有効化
export CLAUDE_CODE_USE_BEDROCK=1

# 必須: リージョン指定
export AWS_REGION=us-east-1

# 推奨: SSOプロファイルを指定
export AWS_PROFILE=your-sso-profile

Bedrockで利用可能なモデル

2026年3月時点で、Bedrockでは以下のClaudeモデルが利用可能です。

Claude Opus 4.6 — 最高精度（コード生成・複雑な推論に最適）
Claude Sonnet 4.6 — バランス型（日常業務に推奨）
Claude Haiku 4.5 — 高速・低コスト（単純なタスクに最適）

Bedrock経由の場合、Claude Codeのデフォルトのメインモデルは Claude Sonnet 4.6 が選択されます。Opus 4.6を使いたい場合は、環境変数 ANTHROPIC_MODEL や ANTHROPIC_DEFAULT_OPUS_MODEL で明示的に指定してください。

コスト目安

Bedrock経由の料金は完全従量課金制です。目安として:

ライトユーザー（1日数回の質問）: 月額 $5-20 程度
ヘビーユーザー（日常的にコーディング支援）: 月額 $50-200 程度
チーム利用（5-10名）: 月額 $200-1,000 程度

個人サブスクリプション（Max $100/月、Pro $20/月）と比較して、利用量が少ないうちは従量課金の方が安くなります。ヘビーユーザーはサブスクリプションの方がコストパフォーマンスが良い場合もあります。

ある程度APIを使っての業務での検証を行い、効果を見極め、定額プランへの社内契約への提案に持っていくのが良いかと思います。

パターン2: Microsoft Foundry経由 — M365メインの企業に最適

Microsoft Foundry経由のClaude

Microsoft Foundry（旧Azure AI Foundry）でもClaudeモデルが利用可能になっています。Microsoft 365やEntra IDをメインで使っている企業にとっては、こちらの方が導入しやすいでしょう。

主なメリット

Microsoft Entra ID（旧Azure AD）認証との統合 — 既存のID基盤をそのまま活用
RBAC（ロールベースアクセス制御）でチーム・プロジェクト単位のアクセス管理
MACC対応 — Microsoftとの既存年間契約枠内でClaude利用料を消化可能
コンプライアンス — Microsoftのエンタープライズグレードのセキュリティ基盤上で動作

セットアップの概要

Microsoft Foundry経由でClaude Codeを接続する場合の環境変数設定:

# Microsoft Foundry経由を有効化
export CLAUDE_CODE_USE_FOUNDRY=1

# Azureリソース名を指定（{resource}は自分のリソース名に置き換え）
export ANTHROPIC_FOUNDRY_RESOURCE={resource}
# または完全なベースURLを指定:
# export ANTHROPIC_FOUNDRY_BASE_URL=https://{resource}.services.ai.azure.com/anthropic

認証はANTHROPIC_FOUNDRY_API_KEYを設定するか、Azure CLIのaz loginでEntra ID認証を利用します。ANTHROPIC_FOUNDRY_API_KEYを設定しない場合、Claude Codeは自動的にAzure SDKのデフォルト認証チェーンを使用します。

私の環境では、本社IT部門がMicrosoft Foundry上でClaudeモデルの提供を開始したタイミングでこの方法を追加導入しました。既にBedrock経由の環境を運用していましたが、部署や個人の好み、既存の契約形態に応じて選択肢を増やすことで、社内展開の障壁を下げる効果がありました。

注意点

2026年3月時点で、Microsoft Foundry上のClaude利用可能リージョンは East US 2 と Sweden Central に限られます。Japan Eastリージョンでの提供は確認できておらず、日本からのアクセスにはネットワークレイテンシを考慮する必要があります。ただし、Claude Codeの利用ではリアルタイム性がそこまで求められないため、実用上大きな問題にはならないケースが多いです。

実践: バッチファイル1枚で起動できる「ワンクリックランチャー」

導入方法がわかっても、同僚に「環境変数を設定して、AWS CLIを入れて、SSOログインして…」と説明するのは現実的ではありません。筆者は バッチファイル1枚を配るだけで、誰でもClaude Codeを起動できるランチャー を作成しました。

ランチャーの全体構成

ユーザーPC                         ネットワーク共有
┌──────────────────┐              ┌────────────────────────┐
│ claudecode.bat   │──UNC参照──▶ 　│ claude.ps1（本体）      │
│ （2行のBAT）      │              │ models.json（設定）     │
└──────────────────┘              └────────────────────────┘
        │                                  │
        │ ダブルクリック                      │ 自動処理
        ▼                                  ▼
   Claude Code起動              ・プロキシ自動設定
   （BATの場所で）               ・AWS SSO認証
                                ・モデル選択
                                ・環境変数セット

この設計のポイントは3つです。

配布物はBATファイル1枚だけ — ロジック本体はネットワーク共有に置くので、更新時はサーバー側を変えるだけで全端末に反映されます
初回起動時にセットアップを自動実行 — AWS CLI、Git、Claude Codeのインストールも自動で行います
拠点別のプロキシ差異を吸収 — 拠点ごとにBATを分けることで、プロキシ設定の違いに対応します

BATファイルの中身

ユーザーに配布するBATファイルはたった2行です。

@echo off
set "CLAUDE_LAUNCH_DIR=%~dp0"
powershell.exe -ExecutionPolicy Bypass -File "\\SERVER\SHARE\scripts\claude.ps1" %*

CLAUDE_LAUNCH_DIR でBATファイルの場所を記録し、Claude Codeの作業ディレクトリとして使います。PowerShellスクリプト本体はネットワーク共有から直接読み込む仕組みです。

起動時の画面イメージ

  Claude Code : v1.0.39

  Check for updates? (y/N)          <- Enterでスキップ

  Select model:
    1) Claude Sonnet 4.6   [default]  (Standard - recommended)
    2) Claude Haiku 4.5               (Fast and lightweight)
    3) Claude Opus 4.6                (Most capable - US region only)

  Choice (1-3) [1]:                 <- Enterでデフォルト選択

モデル選択後、ブラウザでSSO認証（[Allow]をクリック）するだけでClaude Codeが起動します。

誰でも簡単に利用できる環境を提供することが、普及には非常に重要だと思っており、AWS CLI、git bash、Claude Codeすべてをセットアップする機能もすべてサーバー上のPowerShellに組み込み、バッチからそのPowerShellを呼び出すようにすることで、提供後の運用（バッチの再配布がほぼ不要）も軽くなるように設計してみました。

これもすべてClaudeCodeに相談しながら、すべてバイブコーディングで実装しました。

SSO認証が不安定な場合の代替: ベアラートークン版

企業のプロキシ環境ではSSOセッションが頻繁に切れることがあります。私の会社では調子が悪い時には１時間もしないうちにエラーになったりする時もあります。AWSの問題ではなく社内ネットワークの何か問題があるんだと思います。。。

その場合の代替手段として Bedrock ベアラートークン版 も用意しました。

1. AWSアクセスポータル（ブラウザ）を開く
2. 「Command line access」からトークンをコピー
3. claudecode-apikey.bat をダブルクリック
4. トークンを貼り付けてEnter
5. Claude Codeが起動

トークンは12時間有効で、Windowsのユーザー環境変数に自動保存されます。2回目以降はEnterキーだけで再利用できるため、毎回コピペする手間がありません。

SSO版 vs ベアラートークン版の使い分け

観点	SSO版	ベアラートークン版
セキュリティ	組織管理・自動失効	有効期限あり（最大12時間）
初期設定	セットアップウィザードで自動化	不要（コピペのみ）
ネットワーク依存	SSOエンドポイントへの接続が必要	Bedrock APIのみ
セッション途中の失効	発生しやすい（プロキシ環境）	有効期限内は安定
向いている用途	日常的な社内利用・長期運用	SSOが不安定な環境・スポット利用

企業展開で実際にハマったポイント

筆者が実際に社内展開する中で遭遇した技術的な落とし穴と、その解決策を紹介します。

1. BATファイルの文字コード問題

ネットワーク共有パスに日本語フォルダが含まれる場合、BATファイルの文字コードがUTF-8だとcmd.exeがパスを正しく読めません。BATファイルは cp932（Shift-JIS） で保存する必要があります。

2. AWS CLI設定ファイルのBOM問題

PowerShellで ~/.aws/config を書き出すと、デフォルトでBOM（Byte Order Mark）が付きます。AWS CLIはBOM付きUTF-8をパースできないため、BOMなしで書き出す処理が必要です。

# BOMなしUTF-8で書き出す関数
function Write-UTF8NoBOM([string]$path, [string]$content) {
    $enc = [System.Text.UTF8Encoding]::new($false)
    [System.IO.File]::WriteAllText($path, $content, $enc)
}

3. プロキシの既存設定を壊さない

社内ユーザーの中には、すでに独自のプロキシ設定を持っている人もいます。一律に HTTP_PROXY を上書きすると既存環境を壊してしまうため、未設定の場合のみ自動設定 するロジックにしています。

4. wingetの企業プロキシ問題

企業ネットワークのSSLインスペクションにより、wingetの msstore ソースへの接続が失敗します。--source winget を指定するか、msstore ソース自体を削除することで回避できます。

最終的なファイル構成

ネットワーク共有（deploy.batで一括デプロイ）
├── claude.ps1           # メインロジック（SSO版）
├── models.json          # モデル・AWS・拠点別プロキシ設定
├── claude-admin.ps1     # 管理者向け（別Permission Set）
└── models-admin.json    # 管理者向け設定

ユーザーPC（デスクトップに配布）
├── claudecode.bat        # 拠点Aユーザー用・SSO認証
├── claudecode-HAC-A.bat  # 拠点Bユーザー用・SSO認証（認証付きプロキシ）
├── claudecode-admin.bat  # 管理者用・SSO認証
├── claudecode-apikey.bat # ベアラートークン認証版
└── claude-apikey.ps1     # ベアラートークン版ロジック

models.json で設定を一元管理しているため、モデルの追加やプロキシの変更はJSONを編集してデプロイするだけで、全ユーザーに即座に反映されます。

セキュア環境構築のベストプラクティス

企業環境でClaude Codeを展開する際に、セキュリティ面で押さえておくべきポイントを整理します。

1. データ分類の明確化

Claude Codeに渡すデータを事前に分類しておきましょう。

データ分類	扱い
公開情報（OSS、公開ドキュメント）	制限なし
社内一般情報（社内マニュアル、手順書）	Bedrock/Azure経由で利用可
機密情報（顧客データ、財務情報）	利用前にIT部門の承認が必要
極秘情報（未公開特許、M&A情報）	Claude Code利用不可

2. 環境の分離

開発環境: Claude Codeの利用を原則許可
本番環境: Claude Code生成コードの直接デプロイは禁止（必ず人間レビューを経由）
顧客データ環境: Claude Codeからのアクセスを技術的に遮断

3. 監査ログの取得

Bedrock経由であればCloudTrail、Azure経由であればActivity Logで、「誰が」「いつ」「何のモデルに」「どのくらいのトークン量で」リクエストを送ったかを自動記録できます。セキュリティ監査への対応が容易になります。

4. 利用ガイドラインの策定

技術的な制御だけでなく、人間向けのガイドラインも重要です。筆者の社内では、以下のような簡易ガイドラインを作成して展開しました。

Claude Codeに渡してよいデータの範囲
生成コードの利用ルール（必ずレビューを経てから本番適用）
インシデント発生時の報告フロー
禁止事項（顧客個人情報の入力、機密ファイルの直接アップロード等）

段階的な社内展開のロードマップ

一度に全社展開するのではなく、段階的に広げるのが現実的です。

Phase 1: パイロット（1-2ヶ月）

対象: IT部門・開発チームの有志（5-10名）
方法: AWS Bedrock経由のワンクリック環境を提供
目標: Claude Codeの有用性を実感してもらう + セキュリティ上の課題を洗い出す
KPI: 利用頻度、ユーザー満足度、セキュリティインシデント数

Phase 2: チーム展開（2-3ヶ月）

対象: 開発チーム全体 + 業務効率化に関心のある非エンジニア部門
方法: Bedrock + Microsoft Foundryの選択肢を提供
目標: 業務自動化の具体的成果を蓄積する
KPI: 自動化された業務プロセス数、削減工数

Phase 3: 全社展開（3-6ヶ月）

対象: 全社（ガイドライン遵守を条件）
方法: 2パターンの中から部署ごとに最適なものを選択
目標: AI活用の文化を定着させる
KPI: 部門別活用率、業務改善効果の集計

よくある質問（FAQ）

Q: Claude Codeに入力したデータは、AIの学習に使われますか？

A: Anthropic APIを経由する場合（Bedrock/Azure含む）、API経由のデータはモデルのトレーニングに使用されない旨が利用規約に明記されています。ただし、自社のコンプライアンス部門に最新の利用規約を確認してもらうことを推奨します。

Q: Bedrock経由とFoundry経由で、Claude Codeの性能に差はありますか？

A: 同一モデル（例: Claude Opus 4.6）を使う場合、性能に差はありません。ただし、利用可能なリージョンの違いによるネットワークレイテンシの差は存在します。日本からのアクセスであれば、Bedrockの東京リージョン（ap-northeast-1）が最もレイテンシが小さくなります。

Q: 非エンジニアでもClaude Codeを使えますか？

A: 使えます。今回紹介したワンクリックランチャーのようなものを社内展開すれば、BATファイルをダブルクリックするだけで起動できます。Claude Codeは自然言語での指示を理解してコードを生成するため、プログラミング経験がなくても業務の自動化が可能です。今、まさに私は社内のシステム部門以外へのClaudeCode普及に注力していますが、みんな驚きながら便利なことに気づき始めています。

Q: ワンクリックランチャーの配布に管理者権限は必要ですか？

A: 初回セットアップ時にAWS CLI等のインストールで管理者権限が必要になる場合がありますが、wingetが利用できる環境であればユーザー権限でインストール可能です。2回目以降の通常起動では管理者権限は不要です。

まとめ — 「サブスク契約できない」は理由にならない

今回は、企業でClaude Codeのサブスク契約ができない場合の2つの導入方法を紹介しました。