Claude CodeをAmazon Bedrock経由で動かしてみた

1. はじめに

1.1. この記事の目的

近年、コード生成AIエージェント の普及が加速しています。Anthropic の Claude CodeやOpenAIのCodexなど、ターミナルから対話的にコードを書かせるツールが増え、日常の開発フローに組み込む例も珍しくなくなってきました。

中でも Claude Code は、Anthropic公式のCLIコーディングエージェントです。ソースコードをフォルダごと読み込ませて、解析や修正といった作業を、ターミナル上で対話的に進められます。

一般的には、Claude Codeから Anthropic API に直接接続して使うのが定番です。個人で試すには最も手軽で、Pro/Maxといったサブスクプランも使えるため、立ち上がりが圧倒的に速いのが利点です。

しかし、組織で業務利用する場面では、Anthropic API直契約だけでは満たしにくい要件 が出てきます。たとえば「データはどこに保管されるのか」「APIキーをどう配り、誰がどれだけ使ったかをどう監査するか」といった、データ管理・アクセス管理・ガバナンスにまたがる観点があります。

これらを解決する仕組みのひとつが、Claude Codeを Amazon Bedrock 経由で動作させる構成 です。Bedrock経由にすると、データはAWSの管理境界に閉じ、認証・監査・データの所在がすべてAWSの既存基盤に乗ります。

この記事では、Claude CodeをBedrock経由で動かす方法を、個人検証から組織配布まで段階的に扱います。

1.2. なぜBedrock経由にするのか

Claude Codeを単に動かすだけならAnthropic APIを直接使う方がシンプルですが、組織で配布・運用する段階に入ると、データ管理・アクセス管理・監査 の3つの軸で要件が変わってきます。

観点	Anthropic API 直契約の課題	Bedrock 経由での解決
データ管理	データを米国 Anthropic 社が管理する基盤で扱うため、CLOUD Act など米国法の管轄下に置かれる	保存先を指定リージョン（東京など）に固定でき、Anthropic 社は顧客のプロンプト・出力・ログに一切アクセスできない（Data protection（Amazon Bedrock User Guide））
アクセス管理	アクセス管理が Anthropic Console（独自の管理画面）で行われ、組織の既存 AWS / ID 管理基盤とは別系統になる	既存IDプロバイダ（Entra ID / Okta / Cognito 等）に統合可能。退職時の即時失効が既存のAWS基盤の中で完結する
監査	利用追跡は Anthropic 独自のコンソールでの限定的な確認にとどまり、組織の既存監査基盤に統合できない	CloudTrail で全呼び出しを記録でき、AWS 既存のコンプライアンス認証（SOC・ISO・PCI DSS 等）の範囲に Bedrock も含まれる（Compliance validation for Amazon Bedrock（AWS公式ドキュメント））

以上のように、データの保管場所を組織が指定したい・既存のID基盤と監査基盤に乗せたい・AWSのコンプライアンス認証範囲で運用したい といった要件が出てくる組織では、Bedrock 経由の方が運用上の整合性を取りやすくなります。逆に、これらの要件が無い場合は、Anthropic API 直契約のシンプルさと最新機能の追従しやすさが上回るケースが多いです。

ただし、Bedrock経由を選ぶときには次のトレードオフがあります。

• チャット機能は対象外。ブラウザ版のチャットは Bedrock への切り替えができず、デスクトップアプリは Bedrock に切り替えるとチャットが表示されなくなる
• 公式コネクタ機能が利用できなくなる
• Bedrock側での新モデル・新機能の対応が、Anthropic直契約に比べて数週間〜数ヶ月遅れるケースがある
• 料金は Bedrock の従量課金体系となり、Claude.ai の Pro/Max などの個人サブスクの定額枠は使えない
• IAM・OIDC・CloudFormation等のAWS固有の知識を前提とした構築になる

このように、Bedrock 経由にもメリットとトレードオフの両方があるため、最終的には組織の要件と照らし合わせて判断することになります。とくにチャット機能や公式コネクタが業務メンバーの普段使いに組み込まれているチームでは、Bedrock 経由への切り替えがそのまま運用上の致命的な支障になりかねないため、この影響範囲を移行前に必ず確認することを推奨します。本記事では「Bedrock 経由を選ぶ」前提で、その具体的な構築手順を扱っていきます。

1.3. 本記事で使う ccwb ツール

AWS は Claude Code の組織配布向けに Guidance for Claude Code with Amazon Bedrock という公式ガイダンスを提供しています。本記事の2章以降は、このガイダンスの流れを参考にして進めます。

中核ツールは ccwb（claude-code-with-bedrock） というもので、AWS公式が GitHub で公開している Python ベースの CLI ツールです。AWS 管理者が ccwb を実行することで、対話形式での構成設定 → CloudFormation スタックのデプロイ → エンドユーザー向けインストーラのビルド → 配布までを コマンド数本で一気通貫に 行えます。手動でやれば数日かかる構築作業を、ほぼ自動化できる点が最大の特徴です。

なお、ccwb は IdP（OIDC プロバイダ）として Microsoft Entra ID / Okta / Auth0 / IAM Identity Center / Amazon Cognito User Pool などに対応していますが、本記事では AWS 内で完結する Amazon Cognito User Pool を採用します。追加サービスのサインアップが不要で、個人検証から組織展開まで同じ仕組みで進められるためです。

本記事で参照する公式ドキュメントは大きく3つです。新しいページを参照するときに、その都度リンクを再掲します。

• AWS Solutions Library のソリューションページ — ソリューションの位置づけ・概要・8ステップアーキテクチャを確認できる
• GitHubリポジトリの README — 認証モード・オプション機能などの全体仕様を確認できる
• QUICK_START.md — デプロイ手順をステップバイステップで確認できる

なお、ccwb で具体的に作られる AWS リソースは2章冒頭、エンドユーザーが Claude Code を起動してから Bedrock が応答するまでの流れは3章冒頭で扱います。

💡 ポイント
本記事は、個人のAWSアカウント1つで一人で完走できる構成 として記載しています。組織で本格展開するときに別のIDプロバイダへ切り替えやすいよう、要所で「組織で使う場合はこうする」という補足説明を併記しています。

1.4. 記事の構成

この記事の構成は以下のとおりです。

• 2章では ccwb デプロイツールを使って、OIDC + 一時クレデンシャル方式の認証基盤と配布パッケージをセットアップする（管理者の作業）
• 3章では管理者から受け取ったインストーラを実行し、Cognito ログイン経由で Bedrock 上の Claude Code を起動する（利用者の作業）
• 4章では ccwb が提供するオプション機能（モニタリング・分析・クォータ強制・Windowsビルド・配布ポータル）を段階的に有効化する
• 5章では公式ガイダンスがカバーしていない「組織で利用するためのTips」（ビルド対象の絞り込み・配布方法の選択肢・追加のセキュリティ設定・IdP の選択基準・Anthropic API 直契約との使い分け）をまとめる
• 6章では検証で作成したAWSリソースを ccwb destroy で一括削除し、課金を止める

2〜3章は本来「組織配布のための仕組み」ですが、個人のAWSアカウント1つで一人でも完走できる構成 として書いています。OIDCプロバイダにはAWS内で完結する Amazon Cognito User Pool を使うため、追加の外部サービス契約も不要です。要所で「組織で使う場合はこうする」という補足説明を併記しているので、個人検証から組織展開へスムーズに移行できます。

💡 ポイント
Claude Codeおよび Amazon Bedrockの対応モデル・リージョン・機能、公式ガイダンスの提供物は頻繁に更新されます。手順の画面と実際のコンソール表示や ccwb の挙動が異なる場合は、Guidance for Claude Code with Amazon Bedrock（AWS公式） と GitHubリポジトリのREADME を優先して参照してください。

2. AWS環境構築とインストーラの作成（管理者の作業）

ここからは AWS 管理者の作業です。ccwb を使って Cognito User Pool・IAM ロール・配布パッケージなどをまとめてセットアップしていきます。具体的には、以下の流れで進めます。2.1〜2.10 がそれぞれの工程に対応します。

1. 使用するツールやアカウントを準備する
2. Bedrock のモデルアクセスを有効化する
3. ccwb の依存パッケージ管理に使う Poetry をインストールする
4. 公式リポジトリを取得し、ccwb の依存関係をインストールする
5. Cognito User Pool をデプロイし、エンドユーザーが認証するための窓口を用意する
6. 対話形式の設定ウィザードで、認証・インフラ・モデルなどの構成を決める
7. CloudFormation でインフラ一式をデプロイする
8. macOS / Windows 向けの配布パッケージをビルドする
9. デプロイした構成が正しく動作するかを検証する
10. 生成されたインストーラをエンドユーザーに配布する

2.1. 事前準備

QUICK_START.md の冒頭には、想定する読者像と所要時間が明記されています。

Time Required: 2-3 hours for initial deployment Skill Level: AWS administrator with IAM/CloudFormation experience

ここの「AWS administrator with IAM/CloudFormation experience」という記述から、AWSアカウントの管理者権限を持ち、IAM・CloudFormationの基本操作に慣れている人 が前提読者であることが読み取れます。個人検証であっても、自分の個人AWSアカウントに対して管理者として作業する想定です。

このソリューションを進める管理者に必要な権限・有効化・ローカル環境のツールを、項目ごとに「何のために使うか」「まだ準備できていない場合の入手先」を併記して示します。

AWSアカウント

CloudFormation・IAM・Cognito・Bedrockへの権限を持つ管理者ロールが必要です。お持ちでない場合は AWS公式の「アカウント作成の流れ」 を参考に、AWSアカウントを作成してください。

AWS CLI v2

ccwb 実行時の AWS 認証情報解決や、デプロイ後の動作確認に使います。以下のコマンドでバージョンを確認します。

aws --version

aws-cli/2.x.x ... のように出力されればインストール済みです。コマンドが見つからない、あるいは aws-cli/1.x.x が表示される場合は、Installing or updating to the latest version of the AWS CLI（AWS公式ドキュメント） に記載があります（画面右上の言語セレクタで日本語表示に切り替えられます）。

Git

公式ガイダンスのリポジトリをローカルにクローンするために使います。以下のコマンドでバージョンを確認します。

git --version

git version 2.x.x のように出力されればインストール済みです。コマンドが見つからない場合は、Git 公式サイト からインストールしてください。

Python 3.10〜3.12

ccwb が Python ベースのツールであるため、対応バージョンが必要です。以下のコマンドでバージョンを確認します（Windows の場合は python --version）。

python3 --version

Python 3.10.x 〜 Python 3.12.x の範囲で出力されればインストール済みです。それ以外のバージョンが表示されたり、コマンドが見つからない場合は、Python 公式ダウンロードページ から対応バージョンをインストールしてください。なお、システムに新しい Python（例: 3.13）が入っている状態でも、Poetry が後続の poetry install で対応バージョン（3.10〜3.12）を自動選択するため、追加でインストールする必要はありません。

2.2. Bedrockのモデルアクセス有効化

Bedrock では、利用したいモデルは 初回呼び出し時に自動で有効化される 仕組みになっています。まだ有効化していない場合や、有効化済みかどうか分からない場合は、一度テスト実行して有効化しておく必要があります。詳細は Request access to models（AWS公式ドキュメント） に記載があります。

そこで本記事では、東京リージョン（ap-northeast-1）の Bedrock Playground という機能で Claude Sonnet 4.6、Claude Opus 4.8、Claude Haiku 4.5 を一度ずつ実行して、3つのモデルを有効化します。Claude Code は メインモデル（コードの作成・修正など中核の処理を担う）と サブモデル（コマンド出力の要約など軽量な裏方処理を担う）を使い分けており、メインモデルは Sonnet と Opus のいずれかを選択できます。Sonnet を中心に使う想定でも、後から Opus に切り替えたくなる場面はあるため、ここで Sonnet・Opus・Haiku の3つを先に有効化しておきます。

各モデルの位置づけと特徴は次の通りです。

モデル	Claude Code内の位置づけ	速度・コストの傾向
Claude Opus 4.8	メインモデル。最高性能を求めるときに選ぶ。複雑な設計判断や長時間の自律タスクで真価を発揮する	3モデルの中で最も低速で、最もコストが高い
Claude Sonnet 4.6	メインモデル。日常的なコーディング・リファクタリング・レビューを幅広くこなす	速度とコストのバランスが取れている
Claude Haiku 4.5	サブモデル。コマンド出力の要約など、本体の処理を裏で支える軽量タスクを担う	3モデルの中で最も高速で、最もコストが低い

💡 ポイント
上記のモデルバージョン（Opus 4.8、Sonnet 4.6、Haiku 4.5）は 2026 年 5 月時点で公開されている最新版です。実際に手を動かす際は、その時点の最新版に読み替えてください。利用可能なモデルは、Bedrock のマネジメントコンソールの「Model catalog」から確認できます。

本記事の後続手順では、メインモデルとして Sonnet 4.6 を選ぶ前提で進めます。Opus 4.8 を使いたい場合は、Claude Code のモデル切り替え機能で後から差し替えられます。

AWS マネジメントコンソール右上のリージョンセレクタから「アジアパシフィック（東京）ap-northeast-1」を選び、その状態で Bedrock のコンソールを開きます。左メニューの「Playgrounds」を開くと、以下のような初期画面が表示されます。

中央に表示される「モデルを選択」ボタンをクリックすると、モデル選択モーダルが開きます。モーダルは「1. カテゴリ」「2. モデル」「3. 推論」の3カラム構成になっているので、以下の順で Claude Sonnet 4.6 を指定して「適用」をクリックします。

• 「1. カテゴリ」: Anthropic を選択
• 「3. 推論」: JP Anthropic Claude Sonnet 4.6 を選択

東京リージョンでは Sonnet 4.6 が直接提供されていないため、JP クロスリージョン推論プロファイル経由でアクセスします（データを APAC 圏内に閉じる目的でもこの選択が適切です）。

下部のテキストボックスに「こんにちは」と入力して「Run」を押すと、モデルが応答を返します。この時点で Claude Sonnet 4.6 が自動的に有効化されます。

続いて、再度「モデルを選択」を開き、同じ要領で Claude Opus 4.8 を指定します。

• 「1. カテゴリ」: Anthropic
• 「2. モデル」: Claude Opus 4.8 v1
• 「3. 推論」: JP Anthropic Claude Opus 4.8

「こんにちは」と入力して「Run」を押します。これで Claude Opus 4.8 も有効化されます。

最後に、Claude Haiku 4.5 も同様に指定します。

• 「1. カテゴリ」: Anthropic
• 「2. モデル」: Claude Haiku 4.5 v1
• 「3. 推論」: JP Anthropic Claude Haiku 4.5

「こんにちは」と入力して「Run」を押します。これで Claude Haiku 4.5 も有効化されます。

3つのモデルすべてが Playground から応答を返せば、東京リージョンでこれらのモデルが呼び出し可能な状態になっています。

⚠️ Playground で AccessDeniedException が出る場合

Playground で「Run」を押した時に、次のような AccessDeniedException が表示されることがあります。 > Model access is denied due to IAM user or service role is not authorized to perform the required AWS Marketplace actions (aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe) to enable access to this model. Bedrock のモデル有効化は内部的に AWS Marketplace のサブスクリプション機能を経由するため、aws-marketplace:ViewSubscriptions と aws-marketplace:Subscribe の権限が必要です。本記事の手順では管理者ロール（AdministratorAccess など）で作業している前提のため通常は発生しませんが、権限を絞った IAM ユーザ・ロールで作業している場合に発生します。 対処方法は以下のいずれかです。 - 管理者権限（AdministratorAccess）を持つ IAM ユーザ・ロールで Playground を実行する - 現在のロールに aws-marketplace:ViewSubscriptions と aws-marketplace:Subscribe を付与する 権限を修正した直後の場合は、エラーメッセージにあるとおり 2 分ほど待ってから再実行してください。

2.3. Poetry のインストール

ccwb を動かすには、Python のいくつかの追加ライブラリ（外部の便利機能をまとめた部品）が必要になります。これらをまとめて準備するために、AWS公式ガイダンスでは Poetry という Python 向けのツールを採用しています。Poetry を使うと、必要なライブラリと、そのバージョンを正確に揃えた状態をプロジェクトごとに自動で用意してくれるため、他のプロジェクトの環境を壊す心配なく ccwb を動かせます。公式ガイダンスのリポジトリでも ccwb が必要とするライブラリは Poetry の形式で定義されているので、後続の手順では poetry install というコマンド1つで必要なライブラリ一式を揃えられます。

Python の他のパッケージ管理ツール（pip など）と違い、Poetry はシステムに最初から入っていないケースが多い ため、独立した節としてインストール手順を紹介します。なお、この後の手順で出てくるコマンドは、特に指定がなければ Mac の場合はターミナル、Windows の場合は PowerShell で実行します。複数行で記載されているコマンド（行末がバックスラッシュ \ のもの）を PowerShell で実行する場合は、バックスラッシュをバッククォート ` に置き換えるか、1行に連結して実行してください。

まず、以下のコマンドでインストール済みかどうかを確認します。

poetry --version

Poetry (version ...) のように出力されればインストール済みなので、本節はスキップして 2.4 に進んでください。コマンドが見つからない場合は、以下の手順でインストールします。

Macの場合:

curl -sSL https://install.python-poetry.org | python3 -

Windowsの場合:

(Invoke-WebRequest -Uri https://install.python-poetry.org -UseBasicParsing).Content | py -

インストール完了後、再度 poetry --version を実行してバージョンが表示されれば成功です。インストール先の調整など詳細は Poetry 公式ドキュメント に記載があります。

2.4. リポジトリを取得して依存をインストール

QUICK_START.md の Step 1 に該当する手順です。

最初に、公式ガイダンスのリポジトリをローカルに取得します。このリポジトリには ccwb ツール本体と、CloudFormationテンプレート・配布スクリプトなど、後続の作業で使うすべてのファイルが含まれている ため、必ず手元にクローンしておく必要があります。

公式ガイダンスのリポジトリを任意の作業フォルダにクローンします。

git clone https://github.com/aws-solutions-library-samples/guidance-for-claude-code-with-amazon-bedrock

以下のような実行結果が表示されれば成功です。

Cloning into 'guidance-for-claude-code-with-amazon-bedrock'...
remote: Enumerating objects: 3301, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (712/712), done.
remote: Total 3301 (delta 1514), reused 1173 (delta 1139), pack-reused 1449 (from 1)
Receiving objects: 100% (3301/3301), 5.24 MiB | 8.13 MiB/s, done.
Resolving deltas: 100% (1842/1842), done.

完了すると、現在のフォルダ配下に guidance-for-claude-code-with-amazon-bedrock というフォルダが作成され、その中に README・assets/・deployment/・source/ などのサブフォルダが展開されます。

続いて、ccwb ツール本体が置かれている source フォルダへ移動します。

cd guidance-for-claude-code-with-amazon-bedrock/source

source/ 配下には、ccwb の Python パッケージ本体と、依存関係を定義した pyproject.toml が置かれています。以降の Poetry コマンドはこのフォルダを起点に実行する前提です。

最後に、ccwb を動かすための Python 依存パッケージを Poetry の仮想環境に揃えます。

poetry install

以下のような実行結果が表示されれば成功です。

The currently activated Python version 3.13.13 is not supported by the project (>=3.10,<3.13).
Trying to find and use a compatible version.
Using python3.11 (3.11.10)
Installing dependencies from lock file

No dependencies to install or update

Installing the current project: claude-code-with-bedrock (2.3.0)

この実行結果について補足です。ccwb の対応 Python バージョンは >=3.10,<3.13 のため、システムにそれ以外のバージョン（例: 3.13）が入っていても Poetry が利用可能な互換バージョンを自動で探して使ってくれます。Installing the current project: claude-code-with-bedrock (2.3.0) が最後に表示されれば、ccwb の依存関係が Poetry の仮想環境に揃った状態になります。以降のコマンドは poetry run ccwb ... の形式で Poetry 仮想環境内の Python から ccwb を呼び出せるようになります。

2.5. Cognitoの準備

QUICK_START.md には含まれていない手順ですが、次の 2.6 で ccwb init に OIDC プロバイダの情報を入力する必要があるため、ここで先に準備しておきます。

ccwb は以下の OIDC プロバイダに対応しています。

• Amazon Cognito User Pool
• Microsoft Entra ID（旧 Azure AD）
• Okta
• Auth0
• IAM Identity Center

本記事では Amazon Cognito User Pool を使います。AWS 内で完結するため追加サービスのサインアップが不要で、個人検証から小〜中規模の組織展開まで同じ仕組みのまま進められるためです。Cognito 以外のプロバイダを使う場合のセットアップ手順は、公式リポジトリの assets/docs/providers/ 配下に用意されています。

User Pool をデプロイ

公式リポジトリには User Pool・CLI 用 App Client・Cognito Hosted UI ドメインを一括でデプロイする CloudFormation テンプレート（deployment/infrastructure/cognito-user-pool-setup.yaml）が含まれているので、これを使います。

2.4 で source/ フォルダに移動しているため、CloudFormation テンプレートの相対パス（deployment/...）を正しく解決できるよう、いったんリポジトリのルートに戻ります。

cd ..

次にテンプレートをデプロイします。<your-prefix> はグローバル一意な文字列に置き換えてください（例: <組織名や個人ID>-claude-code）。デプロイ先の AWS アカウントは aws configure で設定済みのデフォルトプロファイルに紐づくアカウントになります。複数のプロファイルを使い分けている場合は、コマンド末尾に --profile <プロファイル名> を追加して対象アカウントを指定してください。

aws cloudformation deploy \
  --template-file deployment/infrastructure/cognito-user-pool-setup.yaml \
  --stack-name claude-code-user-pool \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides \
    UserPoolName=claude-code-auth \
    DomainPrefix=<your-prefix> \
  --region ap-northeast-1

コマンドを実行すると、AWS マネジメントコンソールの「CloudFormation」画面に claude-code-user-pool スタックが作成されます。最初は CREATE_IN_PROGRESS 状態で、2〜3 分ほどで CREATE_COMPLETE に変わります。

CREATE_COMPLETE になったら、スタックを選択して「出力」（Outputs）タブを開きます。以下の3つの値を 2.6 の ccwb init で使うので、メモ帳などに控えておきます。

キー	説明	値の例
UserPoolId	Cognito User Pool ID	ap-northeast-1_xxxxxxxxx
UserPoolClientId	CLI 用 App Client ID	xxxxxxxxxxxxxxxxxxxxxxxxxx
UserPoolDomain	Cognito Hosted UI のドメイン	<DomainPrefix>.auth.ap-northeast-1.amazoncognito.com

ログイン用ユーザを作成

本記事では管理者がエンドユーザを兼ねるため、自分用のユーザを1人作成します。マネジメントコンソールで「Cognito」→「ユーザープール」→ デプロイ済みの claude-code-auth プールを開きます。「ユーザー」タブが空の状態になっているので、右上の「ユーザーを作成」をクリックします。

ユーザー作成フォームが開くので、以下の項目を入力します。

設定項目	入力値	補足
ユーザー名	任意（例: 自分のメールアドレス）	ログイン時の識別子
Eメール	受信可能なアドレス	検証メール・パスワードリセットに使用
Eメールを検証済みとしてマーク	ON	初回ログインのメール検証フローを省略できる
パスワード	任意のパスワードを設定	8文字以上、大文字・小文字・数字・記号を含む

右下の「ユーザーを作成」で確定すると、画面上部に成功メッセージが表示され、ユーザー一覧に作成したユーザーが現れます。

この状態になっていれば、このユーザで Cognito Hosted UI からログインできます。次の準備が整ったので、2.6 に進みます。

2.6. 設定ウィザードを起動

QUICK_START.md の Step 2 に該当する手順です。リポジトリと Cognito の準備が整ったので、続けて ccwb init でデプロイ内容を対話的に決めていきます。

ccwb は source/ フォルダ配下から実行する前提のため、2.5 で cd .. したリポジトリのルートから、再度 source/ に戻ります。

cd source

poetry run ccwb init

ウィザードは英語のプロンプトで対話的に進行します。下表の順番で 入力値 を指定すれば完走できます。

質問項目（実際の英語プロンプト）	設定の意味	入力値	設定の基準
Profile name	プロファイルの名前	personal-test	任意の名前を指定できる
Enable SSO authentication?	OIDC 認証を有効化するかどうか	Yes	Cognito User Pool を使うため有効化する
Enter your OIDC provider domain	OIDC プロバイダのドメイン	2.5 で控えた User Pool Domain（<DomainPrefix>.auth.ap-northeast-1.amazoncognito.com）	2.5 でデプロイした Cognito の値を入力する
Enter your Cognito User Pool ID for ap-northeast-1	Cognito User Pool ID	2.5 で控えた User Pool ID（ap-northeast-1_xxxxxxxxx）	2.5 でデプロイした Cognito の値を入力する
Enter your OIDC Client ID	OIDC クライアント ID	2.5 で控えた CLI 用 App Client ID	2.5 でデプロイした Cognito の値を入力する
Select credential storage method	AWS クレデンシャルのローカル保存方式	Session Files (Temporary storage)	個人検証では追加の OS 認証プロンプトが入らない Session Files を選ぶ
Use a custom OAuth callback port? (default: 8400)	コールバック URL のポートを変更するかどうか	No	2.5 のテンプレートが 8400 で固定しているためデフォルトを採用する
Choose federation type	AWS クレデンシャル発行の経路	Direct STS	AWS リソースが少なくデバッグも容易な Direct STS を選択する
Select AWS Region for infrastructure deployment (Cognito, IAM, monitoring)	インフラのデプロイ先リージョン	ap-northeast-1	本記事を通して東京リージョンに固定する
Stack base name (for CloudFormation)	CloudFormation スタックのプレフィックス	claude-code-auth	デフォルト値をそのまま採用する
Enable monitoring?	利用状況の可視化を有効にするかどうか	No	常時稼働コストがかかるため個人検証では無効化する
Enable Windows builds?	Windows 向けバイナリのビルドを有効にするかどうか	Yes	Windows ユーザへの配布も想定するため有効化する
Generate CoWork 3P MDM configuration during packaging?	MDM 配布用の構成ファイルを生成するかどうか	No	個人検証では不要なため無効化する
Distribution method	配布物の届け方	Disabled	2.10 の手動配布を前提とするため無効化する
Select Claude model	メインの Claude モデル	Claude Sonnet 4.6 (Global, US)	動作確認実績がある Sonnet 4.6 を採用する
Select cross-region inference profile	クロスリージョン推論プロファイル	JP Cross-Region	データ所在を APAC に閉じるため JP Cross-Region を選択する
Select source region for AWS configuration	Bedrock 呼び出し時のソースリージョン	ap-northeast-1	インフラ側のリージョンと揃えて東京に固定する
Configure Application Inference Profiles?	アプリ単位の使用量計測・予算管理を有効にするかどうか	No	個人検証では不要なため無効化する
Would you like to add resource tags?	CloudFormation で作成するリソースにタグを付与するかどうか	No	個人検証では不要なため無効化する

入力した値は ~/.ccwb/profiles/<Profile name>.json（本記事の手順なら ~/.ccwb/profiles/personal-test.json）に保存されるため、後から差分デプロイする際にも再利用されます。中身を確認したい場合は、以下のコマンドで表示できます。

Macの場合:

cat ~/.ccwb/profiles/personal-test.json

Windowsの場合:

Get-Content "$env:USERPROFILE\.ccwb\profiles\personal-test.json"

⚠️ ccwb init を再実行して既存プロファイルのプロンプトが表示される場合
過去に ccwb init を実行したことがあると、ウィザード開始時に Found N existing profile(s) と既存プロファイルが表示されます。ハンズオンの設定をゼロからやり直したい場合は、次の流れで進めます。 1. 最初の What would you like to do? で Update existing profile を選ぶ 2. 既存設定が表示されたあと、再度 What would you like to do? が表示されるので Start fresh を選ぶ 3. This will replace your existing configuration. Continue? で Yes を選ぶ その後は通常のウィザードが最初から進むので、上の表に従って入力します。

2.7. インフラをデプロイ

QUICK_START.md の Step 3 に該当する手順です。ccwb init で設定が確定したら、続けて ccwb deploy で実際のCloudFormationスタックをデプロイします。設定ウィザードで指定した内容に応じて、必要な AWS リソースが一括で作成されます。デプロイされるリソースの内訳と依存関係の詳細は assets/docs/DEPLOYMENT.md に記載があります。

📝 実行に必要な AWS 権限

公式 README の Prerequisites では、ccwb deploy の実行ユーザに以下のリソース作成権限が必要と記載されています。 > AWS account with appropriate IAM permissions to create: CloudFormation stacks, IAM OIDC Providers or Cognito Identity Pools, IAM roles and policies 加えて、有効化したオプションに応じて Amazon ECS、CloudWatch、Athena、AWS Glue、Lambda、Data Firehose、CodeBuild の各リソースを作成する権限が必要です。初回構築では、個人検証で使った IAM ユーザに AdministratorAccess ポリシーをアタッチした状態で実行するのが最も確実 です。本番運用フェーズでは、必要なサービスに絞った権限セットへ縮小することを推奨します。

ccwb deploy を実行します。

poetry run ccwb deploy

実行すると、CloudFormation コンソール上で claude-code-auth-stack などのスタックが順次作成されていきます。下記は claude-code-auth-stack が CREATE_IN_PROGRESS、2.5 でデプロイ済みの claude-code-user-pool が CREATE_COMPLETE の状態を示しています。

デプロイ完了後、ターミナルに各スタックの出力値が一覧表示されます。最後のスタックまで CREATE_COMPLETE 相当の表示で終わり、エラーで停止していなければ成功 です。所要時間は必須スタックのみで 5〜10 分、monitoring + analytics + quota を含めると 20〜30 分が目安です。

進捗を確認したい場合は別ターミナルで以下を実行します。

poetry run ccwb status

各 CloudFormation スタックの状態が一覧表示されるので、すべてのスタックが CREATE_COMPLETE で並んでいれば、次の 2.8（配布パッケージのビルド）に進める状態 です。

2.6 で入力した値に基づいてデプロイすると、東京リージョンに必要な AWS リソースが作成されます。具体的にどのリソースが作成されたかは assets/docs/DEPLOYMENT.md に記載されているので、必要に応じて参照してください。実際にデプロイされたリソースは、CloudFormation のマネジメントコンソールで各スタックの「リソース」タブを開くか、IAM・Cognito など各サービスのマネジメントコンソールから個別に確認できます。

📝 なぜマネジメントコンソールから CloudFormation を実行しないのか
ccwb deploy は CloudFormation の起動コマンドであると同時に、ccwb init で保存した設定 JSON を読み取り、有効化したオプションに応じて複数の CloudFormation テンプレートを正しい順序で適用するオーケストレータ として動作します。後続の ccwb package も、ここでデプロイされたスタックの出力値（Identity Pool ID、リージョン、エンドポイント URL など）を参照してインストーラを生成するため、ccwb 経由でデプロイしないとパッケージング側で値を解決できなくなります。 マネジメントコンソールから個別にスタックを起動することも技術的には可能ですが、設定 JSON との整合性、スタック間の依存関係、後続ステップとの連携を自前で再現する必要があり、ccwb の価値（一連の手順をワンセットで管理）が損なわれます。

2.8. 配布パッケージをビルド

QUICK_START.md の Step 4 に該当する手順です。インフラのデプロイが完了したら、エンドユーザーへの配布パッケージを AWS 管理者側で作成し、エンドユーザーに渡します。エンドユーザーは管理者から受け取ったインストーラを実行するだけでセットアップが完了する ため、配布の準備はすべて管理者側で完結します。

poetry run ccwb package

コマンドを実行すると、まず ビルド対象プラットフォームを選ぶプロンプト が表示されます。スペースキーで複数選択、Enter で確定する形式です。

? Which platform(s) do you want to build for?
   ○ macos-arm64
   ○ macos-intel
   ○ linux-x64
   ○ linux-arm64
 » ○ windows

本記事では、自分のMacのアーキテクチャ + Windows の2つを選ぶ構成を採ります。各オプションの選定基準は以下のとおりです。

選択肢	本記事での推奨	補足
macos-arm64	選ぶ（Apple Silicon Macの場合）	自分のマシンでインストーラの動作確認をするために必要
macos-intel	選ぶ（Intel Macの場合）	同上。ただし PyInstaller がクロスコンパイル非対応のため、自分の Mac とアーキテクチャが異なる側はビルドできずスキップされる
linux-x64	スキップ	ハンズオンの動作確認には不要
linux-arm64	スキップ	同上
windows	選ぶ	Enable Windows builds? = Yes で CodeBuild プロジェクトをデプロイ済みのため、CodeBuild 経由で Windows バイナリをビルドして動作確認できる

💡 ポイント
Windows のエンドユーザが Claude Code を WSL（Windows Subsystem for Linux）経由で使う場合は、windows ではなく linux-x64（ARM 環境なら linux-arm64）を選ぶ必要があります。WSL 内では Linux 用のバイナリが必要になるためです。Linux 用バイナリは Docker 上でビルドされるため、ccwb package 実行前に Docker Desktop を起動しておく必要があります（Docker が動いていないと該当ビルドはスキップされます）。

続いて、git コミットへの Claude 共同著者表記 に関するプロンプトが表示されます。

? Include 'Co-Authored-By: Claude' in git commits? (y/N)

これは、配布する config.json に焼き込まれる エンドユーザのデフォルト設定 で、Claude Code 経由で作成された git コミットの末尾に Co-Authored-By: Claude <noreply@anthropic.com> の行を自動で付けるかを決めます。

選択肢	動作
y	Claude Code 経由のコミットに自動で Claude の Co-Authored-By 行が付く
N（デフォルト）	Co-Authored-By 行は付かない（通常のコミットと同じ見た目になる）

本記事では N を選択します。理由は、検証のテストコミットに Claude の Co-Authored-By が混ざると後で本物のコミットとの区別がつきにくくなるためです。組織展開時にどちらをデフォルトにするかは、その組織のコミット履歴ポリシー（AI支援であることを明示する／ノイズを避ける）次第のため、まずデフォルトのまま動かしてから議論するほうが整理しやすくなります。

なお、エンドユーザは Claude Code の設定ファイル（~/.claude/settings.json）の includeCoAuthoredBy で個別に上書きできるため、ここで決めた値はあくまで「組織の標準値」として機能します。

選択後、プラットフォームごとにビルド処理が走ります。所要時間と前提条件はプラットフォームによって異なります。

プラットフォーム	ビルド場所	所要時間	前提条件
macOS（自分のアーキ）	ローカル	数十秒	追加準備なし
macOS（自分と異なるアーキ）	ローカル	-	python.org から universal2 版の Python を入れていないとスキップされる
Linux	ローカル（Docker）	数十秒	Docker Desktop が起動している必要がある。停止しているとスキップされる
Windows	AWS CodeBuild	約 20 分	CodeBuild 上で非同期ビルド。完了後に別途ダウンロード手順が必要（後述）

Windows ビルドぶんで CodeBuild の実行時間に応じた数十円〜数百円の課金が発生します（AWS CodeBuild の料金 参照）。

ローカルビルド対象（macOS / Linux）は ccwb package の完了時点で dist/<プロファイル名>/<タイムスタンプ>/ 配下に配置されます。Windows バイナリは CodeBuild 完了後に別途ダウンロードします（次節）。

最終的に作成されるファイルは以下のとおりです。

プラットフォーム	ファイル名	役割
Apple Silicon Mac	credential-process-macos-arm64	Mac (ARM) 向け、一時クレデンシャルを払い出すバイナリ
Intel Mac	credential-process-macos-intel	Mac (Intel) 向け、一時クレデンシャルを払い出すバイナリ
Windows	credential-process-windows.exe	Windows 向け、一時クレデンシャルを払い出すバイナリ
Mac / Linux 共通	install.sh	Unix 用インストーラ。実行時に OS / アーキテクチャを自動判定し、対応する credential-process-* を配置
Windows	install.bat	Windows 用インストーラ。credential-process-windows.exe を配置
全プラットフォーム共通	config.json	OIDC 発行者 URL、クライアント ID、IAM ロール ARN、リージョン、推論プロファイル ID などの設定値
全プラットフォーム共通	README.md	エンドユーザー向けのセットアップ手順書

Windows バイナリのダウンロード

windows を選択した場合、ビルドは CodeBuild 上で非同期実行されるため、ccwb package の完了時点では Windows バイナリは手元の dist/ に存在しません。CodeBuild の完了を待ってから別途ダウンロードします。

まずは進捗を確認します。

poetry run ccwb builds

ステータスが IN_PROGRESS の間はまだビルドが完了していないため、ダウンロードはできません。しばらく待ってから再度コマンドを実行し、ステータスが SUCCEEDED に変わったことを確認します。SUCCEEDED になっていれば、以下のコマンドで Windows バイナリを dist/ 配下にダウンロードします。

poetry run ccwb builds --status latest --download

ダウンロードが完了すると、dist/<プロファイル名>/<タイムスタンプ>/ に credential-process-windows.exe と install.bat が追加されます。

上記ファイルが dist/<プロファイル名>/<タイムスタンプ>/ 配下に揃っていれば、2.9 に進める状態 です。

📝 Mac 向けに配布する場合は Mac 端末が必要
Mac ユーザに配布する場合は、管理者側にも Mac 端末が必要になります。クロスコンパイルに対応していないため、Windows / Linux の PC では macOS バイナリをビルドできません。

2.9. セットアップを検証

QUICK_START.md の Step 5 に該当する手順です。配布パッケージがビルドできたら、エンドユーザーに配る前に、2.8 でビルドした dist/<プロファイル名>/<タイムスタンプ>/ 配下のパッケージを ccwb test で検証します。配布後にエンドユーザー側でトラブルが起きると原因切り分けが難しくなる ため、管理者環境で OIDC → STS → Bedrock のフローが通ることをここで先に確かめておきます。より細かいローカル検証手順は assets/docs/LOCAL_TESTING.md にまとまっています。

poetry run ccwb test

このコマンドは、CLI_REFERENCE.md の ccwb test セクションで列挙されている 5 項目を順に検証 します。

チェック項目	検証内容
1. パッケージ内容（Package Contents）	2.8 でビルドしたインストーラに、credential process バイナリ・設定ファイル・OpenTelemetry ヘルパが揃っているか
2. バイナリ実行（Binary Execution）	credential process バイナリがエラーなく起動するか
3. 認証 & IAM（Authentication & IAM）	Cognito User Pool 経由の OIDC 認証フローが通り、sts:AssumeRoleWithWebIdentity でフェデレーテッドロールの一時クレデンシャルが発行されるか
4. Bedrock API アクセス（Bedrock API Access）	発行された一時クレデンシャルで東京リージョンの Bedrock を実呼び出しし、推論レスポンスが返ってくるか（デフォルトの設定では代表的な 3 リージョンでテスト。1 リクエストあたり 約 $0.001 の Bedrock 料金が発生）
5. 推論プロファイル（Inference Profiles）	2.6 で指定した apac.anthropic.claude-sonnet-4-6-* のクロスリージョン推論プロファイルが、東京リージョン基準で利用可能になっているか

各項目に対して PASS 相当の結果が並び、最終的な「All tests passed」サマリが表示されれば、エンドユーザーへ配布できる状態です。途中で FAIL が出た場合は、その項目に対応する設定を見直します。

2.10. ユーザーに配布

QUICK_START.md の Step 6 に該当する手順です。配布ポータルや MDM を使った高度な配布方法は 5.2 で扱うので、ここではシンプルな手動配布を扱います。2.8 で生成された dist/<プロファイル名>/<タイムスタンプ>/ フォルダから配布先 OS に応じたファイルを取り出し、社内ストレージや共有ドライブなどでエンドユーザーに渡せば配布完了です。

以上で AWS 管理者側の作業はすべて完了です。次の 3 章では、エンドユーザーが受け取ったパッケージを実行して Claude Code を Bedrock に接続する流れを見ていきます。

3. 接続先の切り替え（利用者の作業）

ここからは Claude Code を使うエンドユーザーの作業です。2 章で管理者がセットアップした配布パッケージを使って、自分のマシンで Claude Code を Bedrock 経由で動かせる状態にしていきます。具体的には、以下の流れで進めます。3.1〜3.2 がそれぞれの工程に対応します。

1. 受け取ったインストーラを実行して認証情報の取得設定を配置する
2. Claude Code を起動して Cognito にログインし、Bedrock との接続を確認する

3.1. インストーラを実行

💡 ポイント
3.2 でブラウザによる Cognito へのログインを行います。管理者が 2.5 で作成した Cognito ユーザの認証情報（ユーザー名と初期パスワード）を、事前に管理者から受け取っておいてください。組織でフェデレーション接続（Entra ID / Okta など）を構成している場合は、その社内 ID 基盤のアカウントでログインします。

配布物を受け取ったエンドユーザーは、自分のマシンでインストーラを実行します。このインストーラ1つで、AWS CLIプロファイル設定からcredential processの配置まで自動完了する ため、エンドユーザーはAWS CLIや認証情報の知識がなくてもClaude Codeを使い始められます。

インストール前: 既存の Claude Code 設定をバックアップ

ccwb のインストーラは ~/.claude/settings.json を上書きします。Claude Code を既に使っていて独自の設定（カスタムモデルや UI 設定など）が ~/.claude/settings.json に保存されている場合は、インストール前に必ずバックアップを取っておきます。後で Anthropic API 接続に戻す際に、このバックアップから復元します（手順は 6.2）。

macOS / Linux の場合:

cp ~/.claude/settings.json ~/.claude/settings.json.bak

Windows の場合:

Copy-Item "$env:USERPROFILE\.claude\settings.json" "$env:USERPROFILE\.claude\settings.json.bak"

~/.claude/settings.json がまだ存在しない場合（Claude Code を初めて使う場合など）は、バックアップ不要です。6.2 では「バックアップを取り忘れていた場合」の手順も案内しているので、必要に応じてそちらを参照してください。

インストーラを実行

• macOS / Linux: install.sh
• Windows: install.bat

💡 ポイント
Windows + WSL（Windows Subsystem for Linux）環境で Claude Code を使う場合は、WSL 内で install.sh を実行します。WSL 内では Linux として扱われるためです。

インストーラは以下を自動で行います。

• AWS名前付きプロファイル（例: claude-code）の設定
• credential processバイナリの配置
• OIDC認証を自動化するための環境変数の設定

エンドユーザーは AWSアクセスキーを一切ローカルに置きません。代わりに、AWS CLIのcredential process仕組みを使い、Claude Codeから呼び出された瞬間にOIDC認証フローが走って一時クレデンシャルが取得されます。

3.2. Claude Codeを起動して Cognito にログイン

インストールが終わったら、実際にOIDC → STS → Bedrock の一連のフローが成立するか を確認します。任意の作業フォルダで Claude Code を起動します。

claude

初回起動時にブラウザが自動的に立ち上がり、Cognito Hosted UI のログイン画面（<DomainPrefix>.auth.ap-northeast-1.amazoncognito.com 配下）が表示されます。2.5節「Cognito User Pool をデプロイ」で作成したユーザ名（または管理者から受け取ったユーザ名）と初期パスワードを入力します。

Cognito User Pool で管理者が作成したユーザは、初回ログイン時に「強制的なパスワード変更」フロー に入ります。画面の指示に従って新しいパスワード（8文字以上・大文字・小文字・数字・記号）を設定すれば、以降は新しいパスワードでログインできるようになります。

ログインに成功すると、http://localhost:8400/callback 経由で認証情報（IDトークン）が credential-process に受け渡され、Cognito Identity Pool が AWS STS の AssumeRoleWithWebIdentity を呼び出して一時クレデンシャルが取得されます。リフレッシュトークンが有効な間（既定10時間）は、再起動してもブラウザ再ログインは不要です。

Claude Codeの対話プロンプトが表示されたら、簡単な指示を実行します。

> こんにちは

応答が返ってくれば、OIDC → STS → Bedrock のフローが成立しています。AWS管理者側で CloudTrail を確認すると、AssumeRoleWithWebIdentity のイベントと、それに続く bedrock.amazonaws.com への InvokeModelWithResponseStream 呼び出しが時系列で記録されています。userIdentity には OIDC のサブジェクト情報も含まれるため、誰がどの呼び出しをしたかが確実に追跡できます。

4. オプション機能を有効化する

2〜3章では、AWS公式ガイダンスに沿って最小構成（認証とBedrock呼び出しに必要なリソースのみ）でClaude Codeを動かしました。この構成だけでも個人検証から小規模な組織配布までは十分に機能しますが、組織で本格運用するフェーズに入ると 「誰がどれだけ使っているか」を見たくなり、次に「使いすぎる人を抑えたくなり」、最後に「広く・継続的に配布したくなる」 という順番で要件が積み上がっていきます。

本章では、ccwb のオプション機能を、この自然な順序に沿って 「可視化を追加する → 制御を追加する → 配布を強化する」 の3段階で有効化していきます。

段階	目的	対応する ccwb のオプション	本章の節
可視化	利用状況をリアルタイムに見えるようにし、長期保管・分析する	Enable monitoring / Enable analytics	4.1 / 4.2
制御	過剰な利用を抑えるため、ユーザ単位の使用量上限を強制する	Enable quota enforcement	4.3
配布強化	配布対象を Windows に広げ、ポータルでセルフサービス化する	Enable Windows builds / Enable distribution portal	4.4 / 4.5

各節は独立しており、必要な段階だけを選んで有効化できます。

💡 ポイント
オプション機能を有効化すると、Bedrockの従量課金とは別に AWSリソースの稼働・実行料金が追加で発生 します。検証後は必ず ccwb destroy でリソースを削除してください。

4.1. 可視化を追加する（Enable monitoring）

最小構成のままだと、「Claude Code が使われているか」「どのユーザがどれだけ呼んでいるか」を AWS 側からリアルタイムに観測する手段がありません。まずは利用状況をダッシュボードで見える状態にする ところから始めます。

Enable monitoring を有効化すると、ECS Fargate 上の OpenTelemetry collector + ALB + CloudWatch ダッシュボードがデプロイされ、Claude Codeの利用状況をリアルタイムに可視化できるようになります。

できるようになること

• リクエスト数・トークン数・レイテンシをCloudWatchメトリクスとして集計
• 専用ダッシュボードで「誰が・いつ・どれだけ使ったか」を一覧表示

組織でのClaude Codeの利用状況を把握したい場合に有効です。

コストの目安

月額 数十ドル（常時稼働のECS Fargate タスク + ALBが主因）。東京リージョン・小〜中規模利用を想定した目安で、組織の利用量で変動します。

有効化手順

2章で作成したプロファイルを再設定し、Enable monitoring を Yes に変更して差分デプロイします。

プロファイルの再設定を開始します。

poetry run ccwb init

ウィザードで既存プロファイル（2章で作成した personal-test 等）を選択すると、現在の設定値が読み込まれます。そのまま進めて「Optional Features Configuration」まで到達したら、Enable monitoring? を Yes に変更します。他の設定は2章と同じ値のまま進めます。

設定を保存したら、差分デプロイを実行します。

poetry run ccwb deploy

monitoring用のCloudFormationスタックが追加で作成されます。ECS Fargate + ALBの起動に10〜15分程度かかります。

動作確認

デプロイ完了後、CloudFormationの出力値からダッシュボードのエンドポイントURLを取得します。

poetry run ccwb status

出力に MonitoringDashboardURL が表示されるので、そのURLをブラウザで開きます。OpenTelemetryのダッシュボード画面が表示されれば成功です。

実際にClaude Codeを実行して、ダッシュボード上でリアルタイムにメトリクスが更新されることを確認します。

claude

Claude Codeでファイルの要約などの簡単な操作を行い、ダッシュボードをリロードすると、リクエスト数・トークン数が増加していることが確認できます。

4.2. 可視化を強化する（Enable analytics）

4.1 の monitoring でリアルタイム可視化はできるようになりましたが、CloudWatch のメトリクスは保存期間が限られており、SQLで自由に切り出すこともできません。「先月の利用量をユーザ別に集計する」「半年前のログを監査用に取り出す」といった長期保管・分析を可能にする のがこの節の目的です。

Enable analytics を有効化すると、S3 + Glue + Athena + Data Firehose による分析パイプラインがデプロイされ、利用ログを長期保管してSQLで分析できるようになります。

できるようになること

• 呼び出しイベントのメタデータ（タイムスタンプ、ユーザ、モデル、トークン数、TPM / RPM 等）をOpenTelemetry → Kinesis Data Firehose経由でS3に蓄積
• AthenaでSQLクエリを実行し、月次レポート・利用パターン分析・コスト按分などに活用
• 公式ドキュメント（assets/docs/ANALYTICS.md）で収集対象として明記されているのはメタデータのみで、プロンプト本文・出力本文の記録には言及がない

Enable monitoringによるリアルタイム可視化に加えて、ユーザ単位の利用傾向の分析や、監査要件での長期保管が必要な場合に有効です。

コストの目安

S3保管料 + Athenaクエリ実行分で、小規模なら月額数ドル〜十数ドル。データ保管期間と分析頻度で変動します。

有効化手順

プロファイルの再設定を開始します。

poetry run ccwb init

既存プロファイルを選択し、「Optional Features Configuration」で Enable monitoring? と Enable analytics? の両方を Yes に変更します（analyticsはmonitoringが前提です）。

設定を保存したら、差分デプロイを実行します。

poetry run ccwb deploy

S3バケット・Glueデータベース・Kinesis Data Firehoseが追加で作成されます。

動作確認

デプロイ完了後、Claude Codeを実行して利用ログを発生させます。

claude

数分待ってから、AWSマネジメントコンソールでS3バケットを開き、analytics/ プレフィックス配下にログファイルが配置されていることを確認します。

Athenaで以下のクエリを実行し、利用ログが取得できることを確認します。

SELECT * FROM <database>.<table> LIMIT 10;

データベース名とテーブル名は、CloudFormationスタックの出力値から確認できます。

4.3. 制御を追加する（Enable quota enforcement）

4.1〜4.2 で利用状況が見えるようになると、次に出てくる要求は 「特定ユーザの使いすぎを止めたい」「組織全体のコストに上限を引きたい」 という制御の話です。可視化が単に観測の機能だとすれば、ここからは「観測 → 介入」のフェーズに入ります。

Enable quota enforcement を有効化すると、Lambda + DynamoDB によるクォータ強制システムがデプロイされ、ユーザ単位のトークン使用量に上限を設定できるようになります。

💡 ポイント
Enable monitoring? = Yes が必須前提: クォータ機能はmonitoringスタックに依存しており、monitoringを No のままだとクォータも動作しません（assets/docs/QUOTA_MONITORING.md の Prerequisites に「Monitoring must be enabled and the dashboard stack deployed.」と明記）。

できるようになること

単純な「上限到達で遮断」だけでなく、運用に必要な機能が一通り揃っています。

• 月間トークン上限と、それを30日で割った日次バーストを別々に設定できる
• 強制モードは alert（通知のみで利用継続）と block（認証時に資格情報を発行しない）の2種類から選択できる
• 80% / 90% / 100% の多段階アラートで上限到達前に予告が出るため、突然の遮断を避けられる
• 利用者のブラウザに使用率のプログレスバーがリアルタイム表示される（警告時は黄色、ブロック時は赤色）
• 管理者は ccwb quota unblock user@example.com --duration 24h で一時的に上限超過ユーザを解放できる

これらの機能だけで、Anthropicのサブスクに近い「決まった枠内で気にせず使える」運用を ccwb 単体で組めます。詳細な仕様は assets/docs/QUOTA_MONITORING.md に記載があります。

コストの目安

monitoring分（月額数十ドル）+ クォータ機能ぶん（月額1ドル未満）。クォータ機能自体は Lambda + DynamoDB の軽量な構成で、コストの大部分はmonitoring側のECS Fargate + ALBです。

有効化手順

プロファイルの再設定を開始します。

poetry run ccwb init

既存プロファイルを選択し、「Optional Features Configuration」で以下の2つを Yes に変更します。

• Enable monitoring? → Yes（quota enforcement の必須前提）
• Enable quota enforcement? → Yes

Enable analytics? は quota enforcement の必須前提ではないため、ログ分析を行う予定がなければ No のままで構いません（コスト面でも analytics スタックぶんの S3・Firehose 料金を抑えられます）。

設定を保存したら、差分デプロイを実行します。

poetry run ccwb deploy

Lambda関数・DynamoDBテーブル・SNS Topicが追加で作成されます。

SNS購読の追加作業

アラート通知（80% / 90% / 100%）はSNS Topic経由で配信されます。デプロイ後、管理者がメール等をSNSに購読する必要があります。

CloudFormationの出力値からSNS Topic ARNを取得します。

poetry run ccwb status

出力に QuotaAlertTopicArn が表示されるので、その値を使ってメールアドレスを購読します。

aws sns subscribe \
  --topic-arn <QuotaAlertTopicArn> \
  --protocol email \
  --notification-endpoint admin@example.com \
  --region ap-northeast-1

登録したメールアドレスに確認メールが届くので、リンクをクリックして購読を確認します。

ユーザにクォータを設定

Cognitoユーザに月間トークン上限を設定します。

poetry run ccwb quota set-user user@example.com --monthly-tokens 1000000

これで、該当ユーザは月間100万トークンまで使用でき、80%（80万トークン）・90%（90万トークン）・100%到達時にSNS経由でアラートが配信されます。

動作確認

Claude Codeを起動し、大量のトークンを消費する操作（大きなファイルの要約など）を繰り返します。

claude

ブラウザでmonitoringダッシュボードを開くと、使用率のプログレスバーが表示され、80%に近づくと黄色に変わることが確認できます。

登録したメールアドレスに、80% / 90% / 100%到達時のアラートメールが届きます。

Anthropic サブスクとの比較

ccwb のクォータ強制を有効化すると、Anthropic の Pro/Max サブスクと同等以上の「サブスク的UX」を、Bedrock の従量課金の柔軟さを保ちながら組織に展開できます。

観点	Anthropic サブスク（Pro / Max）	ccwb on Bedrock
料金モデル	定額（$20 / $100 / $200 等のプラン単位）	従量課金。上限は組織で自由に定められる（ユーザ・グループ単位で ccwb quota で設定）
コスト予測	固定（人数 × プラン料金）	「人数 × 上限トークン × 単価」が 最大値、実使用分だけ請求
使い切らない人の扱い	プラン料金は満額発生（未使用分も請求される）	使った分だけ請求（未使用分は未請求）
グループ単位の上限	不可	set-group でグループ単位に指定。よく使うグループと使わないグループで上限を調整できる
残量の可視化	基本的に非公開	ブラウザにプログレスバー + ターミナル表示
段階的アラート	突然レート制限がかかる	80% / 90% / 100% の多段階アラート
管理者による一時延長	次のリセット待ち	ccwb quota unblock で延長可能
監査ログ	Anthropicコンソール（限定的）	CloudTrail + DynamoDB（完全）
データ保管	Anthropicインフラ（主に米国）	AWS 指定リージョン（東京固定可）
リセット周期	プランごとに数時間単位のローリングウィンドウ（例: 直近 5 時間の使用量で判定）	月次（毎月 1 日 0:00 UTC）+ 日次バースト（毎日 0:00 UTC）にリセット

「ユーザ体験はサブスクっぽい」けれど、組織が払うのは使われた分だけ という構造になります。ライトユーザがプラン料金分を使い切らない無駄も発生せず、ヘビーユーザは上限まで使えるため、組織全体のコスト効率が高くなります。

4.4. 配布対象を広げる（Enable Windows builds）

4.1〜4.3 で観測と制御は揃いました。ここからは 「より多くのユーザに届ける」配布フェーズ に入ります。最初の課題は OS の幅で、社内に Windows ユーザが多い組織では、macOS/Linux 向けに加えて Windows 用バイナリも用意する必要があります。

Enable Windows builds を有効化すると、AWS CodeBuildプロジェクトが作成され、Windows用バイナリを自動ビルドできるようになります。

できるようになること

• macOS / Linux用バイナリはローカルでビルドできるが、Windows用はCodeBuildが必須
• ビルドに約20分かかる
• Windows端末を配布対象に含める場合は必須

コストの目安

ビルド1回あたり数十円〜数百円。プロジェクトが存在するだけでは課金されず、ccwb package でWindowsバイナリをビルドする際のCodeBuild実行時間に応じて従量課金されます。

有効化手順

2章ですでに Enable Windows builds? = Yes を選択している場合は、追加作業は不要です。まだ有効化していない場合は、プロファイルを再設定します。

poetry run ccwb init

既存プロファイルを選択し、「Optional Features Configuration」で Enable Windows builds? を Yes に変更します。

設定を保存したら、差分デプロイを実行します。

poetry run ccwb deploy

CodeBuildプロジェクトが作成されます。

動作確認

パッケージビルド時にWindowsプラットフォームを選択します。

poetry run ccwb package

プラットフォーム選択で windows を選択（スペースキーでチェック、Enterで確定）すると、CodeBuild経由でWindowsバイナリがビルドされます。約20分後、dist/<プロファイル名>/<タイムスタンプ>/ 配下に credential-process-windows.exe と install.bat が生成されていれば成功です。

4.5. 配布をセルフサービス化する（Enable distribution portal）

4.4 で OS の幅は広がりましたが、まだ「管理者が成果物を手で配る」運用です。利用者が増えてくると、配布のたびにファイルを共有する手間や、古いバージョンが社内に残り続ける問題 が出てきます。最後のオプションでは、エンドユーザーがブラウザから最新版を自分で取りに来る形に運用を切り替えます。

Enable distribution portal を有効化すると、SSO認証付きランディングページがS3 + Lambdaでデプロイされ、エンドユーザーがブラウザでポータルにアクセスして自分のOS用インストーラをセルフサービスで取得できるようになります。

できるようになること

• エンドユーザーはブラウザでポータルにアクセスし、SSOログイン後に自分のOS用インストーラをダウンロード
• 管理者は新しいパッケージをビルドしてアップロードするだけで、エンドユーザー側は常に最新版を取得できる
• プリサインドURLの期限管理や、手動配布の煩雑さから解放される

配布方法としての位置づけや、手動配布・プリサインドURLとの比較は5.2で詳しく扱います。

コストの目安

配布量にもよるが、小規模なら月額1ドル未満。S3のストレージ料金とLambdaの実行料金が中心で、配布頻度が低ければほぼゼロに近づきます。

有効化手順

プロファイルの再設定を開始します。

poetry run ccwb init

既存プロファイルを選択し、「Optional Features Configuration」で Enable distribution portal? を Yes に変更します。配布ポータルにはWebクライアント（ブラウザからアクセスするポータルUI）が必要なため、追加で DistributionWebClientId と DistributionWebClientSecretArn を入力するプロンプトが表示されます。

これらの値は、2.5節「Cognito User Pool をデプロイ」でデプロイした claude-code-user-pool スタックのOutputsタブに DistributionWebClientId / DistributionWebClientSecretArn として出力されているので、CloudFormationコンソールから確認してコピーします。

設定を保存したら、差分デプロイを実行します。

poetry run ccwb deploy

S3バケット・Lambda関数・CloudFrontディストリビューションが作成されます。

動作確認

デプロイ完了後、CloudFormationの出力値からポータルのURLを取得します。

poetry run ccwb status

出力に DistributionPortalURL が表示されるので、そのURLをブラウザで開きます。Cognito Hosted UIのログイン画面が表示されたら、ログインします。

ログイン後、自分のOS（macOS / Windows / Linux）用のインストーラをダウンロードできるランディングページが表示されます。「Download for macOS (ARM)」のようなボタンをクリックして、インストーラがダウンロードできれば成功です。

5. 組織運用のためのTips

4章では、ccwb のオプション機能を「可視化 → 制御 → 配布強化」の順に積み上げ、組織でのClaude Code配布・利用状況の可視化・ユーザ単位の上限設定まで一通り揃えました。

本章では、ccwbの機能を超えた、組織で本格運用する際に考慮すべき観点を扱います。配布方法の選択肢・追加のセキュリティ設定・IdP選定・Anthropic API直契約との使い分けなど、組織の規模や運用ポリシーによって判断が分かれるトピックです。すべてが必須ではありませんが、本格運用に近づくほど効いてくる領域なので、必要なものから取り入れてください。

5.1. 配布パッケージのビルド対象を絞る

2.8 では対話プロンプトでビルド対象のプラットフォームを選択しましたが、--target-platform オプションを使えば対話なしで対象を指定できます。

しかし、実際の組織で運用する場合は、「配布先は Windows のみ」「Apple Silicon Mac のみ」のように、配布先の PC が絞られていることがあります。そこで --target-platform オプションでビルド対象を絞ると、時間とコストを抑えられます。

💡 ポイント
Windows バイナリをビルドするには AWS CodeBuild が必要で、ccwb init で Enable Windows builds? = Yes を有効化しておく必要があります。

指定する値	配布先
macos-arm64	Apple Silicon Mac のみ
macos-intel	Intel Mac のみ（または Intel + Apple Silicon 混在）
windows	Windows のみ
linux	Linux のみ

例として、Windows ユーザだけに配布する場合は以下のようになります。

poetry run ccwb package --target-platform windows

--target-platform オプションで指定可能な値の全リストは assets/docs/CLI_REFERENCE.md に記載があります。

5.2. 配布方法の選択肢

2.10 ではシンプルな手動配布（社内ストレージなどで dist/ 配下のファイルを共有する方式）を扱いました。本格運用フェーズでは、配布対象者の規模や更新頻度に応じて、ccwb が提供する以下 2 つの方式を検討すると運用負荷を下げられます。

プリサインドURLによる配布

ccwb distribute コマンドで、配布パッケージを格納した S3 オブジェクトへの 時限付き署名 URL を生成します。URL を受け取ったエンドユーザーは、AWS 認証情報を一切持たずにブラウザでダウンロードでき、URL の有効期限切れ後は自動的にアクセスできなくなります。

poetry run ccwb distribute

実行すると、Mac / Windows それぞれの配布パッケージをアップロード済みの S3 URL（既定で 48 時間有効、--expires-hours オプションで 1〜168 時間に変更可能）が表示されます。社内チャットや課題管理ツールで URL を共有するだけで配布が完了するため、社内ストレージにファイルを置く手間や、世代管理（古いインストーラの混在）を抑えられます。--allowed-ips オプションを付ければ社内 IP 帯からのみダウンロード可能に絞ることもでき、URL 漏洩時のリスクを下げられます（assets/docs/CLI_REFERENCE.md 参照）。

ランディングページ（配布ポータル）

4.5 で扱った Enable distribution portal? = Yes を有効化すると、ccwb が S3 + Lambda で SSO 認証付きの 配布ポータル を構築します。エンドユーザーはブラウザでポータルにアクセスし、SSO ログイン後に自分の OS に対応するインストーラをセルフサービスでダウンロードできます。

管理者は、配布のたびにプリサインド URL を再発行する必要がなく、新しいパッケージをビルドしてアップロードするだけで、エンドユーザー側は常に最新版を取得できる 状態になります。

3 つの配布方式の比較を以下にまとめます。

配布方式	対応規模	認証	管理者の手間	適したケース
手動配布（2.10）	〜数人	なし（社内ストレージのアクセス制御に依存）	配布のたびにファイル共有	個人検証・少人数チーム
プリサインドURL	数十〜数百人	URL のシークレット性 + 期限	コマンド 1 発で URL 生成	中規模配布・URL の期限管理が許容できる場合
配布ポータル	数百人以上	SSO 認証	初回のみポータルをデプロイ。以降はバイナリ更新だけで完結	大規模・継続的な配布

5.3. 追加のセキュリティ設定

公式ガイダンスでは OIDC + 一時クレデンシャル + IAM によるアクセス制御が中心です。金融・医療・公共などコンプライアンス要件が厳しい組織 では、以下を多層防御として追加検討します。

機密情報の保存を制限する

デフォルトの設定では、Bedrock 経由でやり取りしたプロンプト本文や出力本文は、AWS 側のログには記録されません。これは Bedrock の Model Invocation Logging という機能がデフォルトで無効化されているためです。

しかし、機密情報や個人情報を扱う組織では、AWS アカウント管理者が後から Model Invocation Logging を有効化してしまうと、プロンプト・出力本文が CloudWatch Logs / S3 に記録されてしまうリスク があります。

SCP や AWS Config で Model Invocation Logging の有効化を組織レベルで禁止する設定にすれば、誤有効化を防止でき、プロンプト・出力本文を AWS 側にも残さない構造を保てます（Monitor model invocation using CloudWatch Logs（AWS公式ドキュメント））。

閉域通信で Claude Code を利用する

デフォルトの設定では、Bedrock への呼び出しは インターネット経由 で行われます。

しかし、金融・医療・公共などの閉域要件がある組織では、社内ネットワークの境界外を通過する通信は許容されない ことがあります。

VPC に PrivateLink / VPC Endpoint for Bedrock を設定すれば、VPC 内から直接 Bedrock に到達でき、インターネットを経由しない閉域通信が実現できます（Use Amazon VPC and AWS PrivateLink for private connectivity（AWS公式ドキュメント））。

暗号鍵を組織側で管理する

デフォルトの設定では、Bedrock の保管データは AWS 管理の暗号鍵 で暗号化され、鍵そのものの管理権限は AWS 側にあります。

しかし、コンプライアンス要件として 暗号鍵の管理権限と利用ログを組織側で持つ必要がある組織 では、AWS 管理キーでは要件を満たせません。

KMS カスタマー管理キー（CMK） を Bedrock に紐づければ、組織側が管理する鍵で暗号化でき、鍵の利用イベントを CloudTrail で監視できます（Data encryption（AWS公式ドキュメント））。

利用可能なリージョン・モデルを組織で固定する

デフォルトの設定では、各 AWS アカウントの IAM 管理者が 自由に利用するリージョン・モデルを設定できます。

しかし、複数アカウントを跨いで「東京リージョン以外は使わせない」「許可していないモデルを禁止する」といった統制をかけたい組織では、個別 IAM ポリシーで緩められてしまうと組織レベルのガードレールが効きません。

AWS Organizations + SCP（Service Control Policy）を組織レベルで適用すれば、利用可能なリージョン・モデルを上位から制限でき、個別 IAM ポリシーで緩めることをできなくします（Service control policies（AWS公式ドキュメント））。

監査ログを長期不変で保管する

デフォルトの設定では、CloudTrail はアカウントごとに個別に記録 され、ログ用の S3 バケットも削除・改ざんの余地があります。

しかし、金融・医療・公共のように 監査要件で長期間（多くは 7 年）の不変保管が必要な組織 では、ログの削除・改ざんが許容されません。

CloudTrail Organization Trail + S3 Object Lock を構成すれば、組織全体の Bedrock 呼び出しを 1 つのバケットに集約しつつ、Object Lock で監査要件期間中の改ざん・削除を防げます（Creating a trail for an organization（AWS公式ドキュメント） / S3 Object Lock（AWS公式ドキュメント））。

異常な利用・不正アクセスを検知する

デフォルトの設定では、Bedrock の異常な利用パターンや、漏洩した認証情報による不正な API 呼び出しは検知されません。料金面でも、何らかの原因で利用量が急増した場合に気付くのは月次の請求書を見たタイミングになりがちです。

しかし、配布規模が大きい組織や、漏洩・暴走的な利用への早期対応が必要な組織では、月次の請求書を見るまで気づけないのは大きなリスク になります。

Amazon GuardDuty で不審な API 呼び出しを脅威として検知し、Cost Anomaly Detection で急激な料金の伸びを検知して通知する仕組みを入れれば、異常を発生直後に把握できます。

不適切なプロンプト・出力をフィルタリングする

デフォルトの設定では、エンドユーザーが入力したプロンプトはそのままモデルに渡り、出力もそのまま返ります。

しかし、顧客データを扱う組織や、コンプライアンス要件で出力内容の制限が必要な組織では、機密情報や個人情報の混入・不適切な出力がそのまま流通すること が事業リスクになります。

Bedrock 呼び出しの前段に Bedrock Guardrails を挟めば、PII マスキング・有害コンテンツフィルタ・トピック制限を技術的に強制でき、ユーザーが意図せず機密情報を入力した場合でも遮断・マスクできます（Amazon Bedrock Guardrails（AWS公式ドキュメント））。

クライアント側の操作リスクをルールで抑える

デフォルトの Claude Code は、--dangerously-skip-permissions オプションで権限確認をスキップでき、プロンプトに機密情報を含めて送信することも自由にできてしまいます。

しかし、Claude Code を組織内で広く展開する場合は、AWS 側のガードレールを揃えてもエンドユーザーのローカル操作までは制御できない ため、誤操作・情報漏洩のリスクが残ります。

組織として --dangerously-skip-permissions オプションの利用禁止・機密情報のプロンプト混入禁止教育・ローカル会話履歴の取り扱い方針 を運用ルールとして定めれば、ユーザー操作レイヤでのリスクを抑えられます。

5.4. IdPの選択基準

本記事では Amazon Cognito User Pool を採用しましたが、ccwb は他のOIDCプロバイダにも対応しています。組織のID基盤や運用ポリシーに応じて、以下から選びます。

IdP	向いているケース	注意点
Amazon Cognito User Pool（本記事の採用パス）	AWS内で完結させたい／軽量に立ち上げたい／クォータ強制（ユーザ単位の利用量上限）を効かせたい	セッション継続期間は既定で10時間と短め／組織の既存ID基盤と直結したい場合は別途フェデレーション設定が必要
IAM Identity Center	すでに IAM Identity Center を運用中／最大7日のブラウザ再ログイン不要セッションが欲しい／AWS Organizations と連動させたい	クォータ強制は利用不可／組織展開時にはアカウントインスタンス→組織インスタンスへの移行が必要
Microsoft Entra ID（旧 Azure AD）	Microsoft 365 / Azure基盤を持つ組織。すでに社内のID基盤として運用	Azure側でのアプリ登録、シークレット/証明書の管理が必要
Okta	すでに Okta を社内SSOとして運用	Okta側でのアプリ登録、Okta のライセンス費用
Auth0	スタートアップなどで Auth0 を採用	Auth0側でのアプリ登録

選定の指針は次のとおりです。

• すでに社内のID基盤（Entra ID / Okta 等）を持っているなら、その基盤をそのまま使うことで、AWS側に新たなID基盤を作らずに済む
• AWS基盤を中心に組み上げたい・長めのセッションを保ちたい場合は、IAM Identity Center を使うと、Organizations との統合で組織レベルのガードレールが効きやすく、最大7日のセッション継続が得られる
• ゼロから立ち上げる・クォータ強制を効かせたい場合は、Cognito User Pool が向いている。AWS内で完結し、ユーザ単位の利用量上限の機能まで使える

各IdPの個別セットアップ手順は、公式リポジトリの assets/docs/providers/ 配下に用意されています（cognito-user-pool-setup.md / microsoft-entra-id-setup.md / okta-setup.md / auth0-setup.md）。共通の準備事項として、リダイレクトURIに http://localhost:8400/callback を許可し、クライアントIDとプロバイダドメインを控えておきます。

5.5. Cognito User Pool の組織展開と Entra ID フェデレーション

2章のハンズオンでは、ccwb 用に Cognito User Pool を作り、そこに管理者がローカルユーザを直接1人作成する構成で進めました。検証フェーズや数人規模の運用であれば、この方法のままで支障なく動きます。一方で、利用人数が10人を超えてくると、Cognito にユーザを1人ずつ作って初期パスワードを別経路で配る運用 がボトルネックになります。

そこで、ある程度の人数を超えてきたタイミングで、Cognito User Pool に Entra ID（あるいは Okta 等）を SAML / OIDC の IdP として追加する 構成に移行するのが定番のステップアップ路線です。社内のID基盤と一体化させることで、エンドユーザは「いつもの社内アカウントでログイン」するだけになり、管理者側もパスワード配布・再発行・退職時の無効化作業から解放されます。

なお、IAM Identity Center に乗り換えて Entra ID と SCIM 連携する選択肢も理屈上はありますが、ccwb で クォータ強制（ユーザ単位の利用量上限） を使う前提では IAM Identity Center モードは利用できません（OIDC直結方式の Cognito 経由のみ対応）。クォータ強制を運用統制に組み込みたい場合は、引き続き Cognito User Pool を残したまま、その上に Entra ID をフェデレーション接続するのが現実解です。

Phase 1 → Phase 2 の移行フロー

段階的に進めると以下のような流れになります。

Phase	構成	想定規模	運用
Phase 1	Cognito User Pool 単体・ローカルユーザ手動作成	〜数人（個人検証〜小規模PoC）	管理者が Cognito ユーザを直接作成し、ユーザ名と初期パスワードを各ユーザに連絡
Phase 2	Cognito User Pool + Entra ID をフェデレーション IdP として追加	10人〜数百人	Entra ID のアプリアサインで利用可否を制御。Cognito 側のユーザ管理はほぼ不要

Phase 2 移行で重要なのは、ccwb 側のデプロイ済みリソース（IAM ロール・OIDC Provider・Cognito Identity Pool・配布パッケージ）はそのまま流用できる 点です。Cognito User Pool に IdP を追加するだけで、App Client ID・リダイレクトURI・Provider Domain などの値は変わらないため、再デプロイや配布物の再生成は不要です。

Phase 2 でやること

Cognito User Pool に Entra ID を SAML / OIDC IdP として追加する大まかな手順は以下のとおりです。詳細は公式の microsoft-entra-id-setup.md と Adding a SAML identity provider to a user pool（AWS公式ドキュメント） を参照してください。

1. Entra ID 側で Cognito 用のエンタープライズアプリケーション（SAML または OIDC）を登録する
2. 利用させたいユーザ・グループを、そのアプリにアサインする
3. Cognito User Pool の「IDプロバイダ」に Entra ID を追加し、属性マッピングを設定する
4. Cognito App Client の「IDプロバイダ」設定で、追加した Entra ID を有効化する
5. エンドユーザは Cognito Hosted UI の「Sign in with <IdP名>」ボタンから Entra ID 経由でログインする

ユーザは Entra ID で認証され、初回ログイン時に Cognito User Pool 側へ JIT（Just-in-Time）プロビジョニング で自動的にユーザレコードが作成されます。以降は Entra ID のグループ管理がそのままアクセス制御として機能します。

移行時の注意点：ローカルユーザと JIT 生成ユーザは別レコード扱い

Phase 2 への移行で唯一気をつけたいのが、Phase 1 で作った Cognito ローカルユーザと、Phase 2 で JIT 生成されるフェデレーテッドユーザが、同一人物であっても別レコードとして扱われる 点です。

たとえば Phase 1 で taro@example.com をローカルユーザとして登録していた場合、Phase 2 で Entra ID 経由で同じ人がログインすると、Cognito 上には EntraID_taro@example.com のような新しいユーザレコードが作られます。そのままだと、ccwb のクォータ使用量カウンタや CloudTrail の userIdentity が同じ人で2系統に分裂します。

これを避けるには2つの選択肢があります。

選択肢A: 一斉カットオーバー（推奨）

Entra ID 連携を有効化したタイミングで、Phase 1 で作った Cognito ローカルユーザを全員削除し、以降は全員 Entra ID 経由でログインする運用に揃えます。シンプルで、移行後の運用がきれいに統一されるため、特別な理由がなければこちらを選びます。クォータの過去履歴は移行時にリセットされますが、検証期間の数十時間ぶんなので影響は限定的です。

選択肢B: ID リンキング

Cognito の AdminLinkProviderForUser API を使って、ローカルユーザと Entra ID 経由のフェデレーテッドユーザを同じ profile に紐付けます。クォータ履歴の連続性を保ちたい場合の選択肢で、詳細は Linking federated users to an existing user profile（AWS公式ドキュメント） を参照してください。手間はかかります。

より厳密なライフサイクル管理が必要になったら

Entra ID で「グループから外したら即座に Cognito 側のアクセスも無効化したい」というレベルの厳密な同期が必要になった場合は、SAML / OIDC のフェデレーションだけでは実現できません（次回ログイン時に Entra ID 側で弾かれる動きにはなりますが、Cognito 側のユーザレコードは残ります）。

そのレベルの統制が必須なら、API Gateway + Lambda で Cognito Admin API を呼ぶ SCIM 2.0 互換エンドポイントを自作する 構成への発展が必要になります。実装例は Implementing SCIM with AWS Cognito（Medium） に公開されています。まずは Phase 2 まで進めてみて、フェデレーション標準の挙動で運用が回るかを判断したうえで、必要に応じて検討するのが現実的です。

5.6. Anthropic API直契約とBedrock経由の使い分け

両者は対立するものではなく、用途で使い分ける運用も多くあります。

カテゴリ	観点	Anthropic API（直契約）	Amazon Bedrock経由
料金	料金体系	Pro/Maxサブスク + 従量	従量課金のみ
認証	認証方式	APIキー	OIDC + STS一時クレデンシャル
データ	学習への利用	しない	しない（プロバイダ非到達）
データ	保管リージョン	Anthropicインフラ	AWS指定リージョンに固定可
データ	閉域通信	不可	PrivateLink可
統制	ユーザ単位の上限	限定的	ccwb の quota enforcement で月間/日次のトークン上限を強制可能（4.3）
監査	利用ログ	Anthropicコンソール	CloudTrailで完全監査
機能	新機能の追従	最速	数週間〜数ヶ月遅れ
運用	セットアップ	APIキー1つ	公式ガイダンスでデプロイ（2〜3時間）

選択の指針は次のとおりです。

• 個人で試したい・個人開発で使う場合は、手軽さと最新機能の追従が圧倒的な Anthropic API（サブスク）が向いている
• 数人〜10人程度のチーム開発では、どちらを選んでもよい
• 社内全体のAI活用基盤として展開する場合は、Bedrock経由 + 公式ガイダンスが向いている。コスト統制・ユーザ管理・監査・データ閉じ込めの全領域でメリットが出る
• 顧客のデータを扱うサービスに組み込む場合は、Bedrock経由がほぼ必須になる。データレジデンシー・閉域・監査要件を満たせる

6. リソースの削除

ここまでで、管理者側の構築・利用者側の動作確認・オプション機能の検証・組織運用の検討が一通り完了しました。検証用にデプロイした環境を放置すると、ECS Fargate や Athena などの常時稼働リソースを有効化していた場合は課金が継続するため、検証が終わったタイミングで明示的に削除する ことを推奨します。本章では、AWS 側のリソース削除と、エンドユーザー端末を元の Anthropic API 接続に戻す手順をまとめます。

6.1. AWS リソースを削除する

ccwb destroy で、ccwb deploy で作成した CloudFormation スタックとリソースを一括削除します。

poetry run ccwb destroy

実行すると、削除対象のスタック（claude-code-*）が一覧表示され、本当に削除してよいか確認プロンプトが出ます。y で進めると、ccwb deploy で作成した全スタックが依存関係を考慮した順序で削除されていきます。スタックがすべて DELETE_COMPLETE になれば完了で、所要時間は構成にもよりますが概ね 5〜15 分程度です。S3 バケットに残ったオブジェクトや、2.5節で別途デプロイした claude-code-user-pool スタックは ccwb destroy の対象外 です。不要になったら、以下のコマンドで Cognito User Pool スタックも削除します。

aws cloudformation delete-stack \
  --stack-name claude-code-user-pool \
  --region ap-northeast-1

ccwb の全コマンドの一覧は assets/docs/CLI_REFERENCE.md にあります。

6.2. エンドユーザー端末を Anthropic API 接続に戻す

ccwb のインストーラは ~/.claude/settings.json の env フィールドに CLAUDE_CODE_USE_BEDROCK などを書き込みます。Claude Code はこのファイルを起動時に読み込むため、ファイルを元に戻すだけで Anthropic API 経由の動作に戻せます。

バックアップから復元する場合（推奨）

3.1 でバックアップを取った場合は、上書きで復元します。

macOS / Linux の場合:

cp ~/.claude/settings.json.bak ~/.claude/settings.json

Windows の場合:

Copy-Item "$env:USERPROFILE\.claude\settings.json.bak" "$env:USERPROFILE\.claude\settings.json"

次に claude を起動すると、Anthropic API 経由のデフォルト動作に戻ります。

バックアップを取り忘れていた場合

~/.claude/settings.json を削除すれば、次回 Claude Code 起動時に Anthropic API 経由の動作に戻ります。

macOS / Linux の場合:

rm ~/.claude/settings.json

Windows の場合:

Remove-Item "$env:USERPROFILE\.claude\settings.json"

ただし、この方法では ccwb インストール前のユーザ独自の Claude Code 設定（カスタムモデル選択や UI 設定など）も失われます。Anthropic API 側のログインセッションは別ファイルに保存されているため、ログイン状態は維持されます。

完全に痕跡を消したい場合

ccwb のインストーラは settings.json 以外に以下も配置しています。Claude Code の動作には影響しないため必須ではありませんが、完全にクリーンにしたい場合は削除します。

• ~/.aws/config に追記された [profile <ccwb プロファイル名>] と -collector セクション（エディタで該当セクションを削除）
• ~/claude-code-with-bedrock/ ディレクトリ（credential-process バイナリの配置先）

rm -rf ~/claude-code-with-bedrock/

Windows の場合は %USERPROFILE%\.aws\config と %USERPROFILE%\claude-code-with-bedrock\ を同様に処理します。

7. まとめ

この記事では、Claude CodeをAmazon Bedrock経由で動作させる手順を、組織配布から本格運用のためのTipsまで段階的に扱いました。

• AWS環境構築とインストーラの作成（2章） は、AWS公式ガイダンス（OIDC + STS一時クレデンシャル + ccwb デプロイツール）でセキュアな配布基盤を構築する。長期APIキー・IAMアクセスキーを一切エンドユーザーに渡さず、AWSアカウントすら持たせる必要がない。個人のAWSアカウント1つで一人でも完走でき、Amazon Cognito User Pool を使って組織展開と同じ構造を試せる
• 接続先の切り替え（3章） は、管理者から受け取ったインストーラを実行し、Cognito Hosted UI 経由でログインしてBedrock上のClaude Codeを起動するまでの流れを扱った
• オプション機能（4章） は、monitoring・analytics・quota enforcement・Windows builds・distribution portalを段階的に有効化し、動作確認する手順を扱った
• 組織運用のTips（5章） は、ccwbの機能を超えた、配布方法の選択肢・セキュリティ設定・IdP選定・Anthropic API直契約との使い分けなど、組織の規模や運用ポリシーに応じて判断が分かれる観点を扱った
• リソースの削除（6章） は、検証で作成したAWSリソースを ccwb destroy で一括削除する手順と、エンドユーザー端末の接続先を元の Anthropic API に戻す手順を扱った

社内のAI活用基盤としてClaude Codeを正式採用したいフェーズの組織にとって、本ソリューションは「セキュリティと配布の最初のひと山」を一気に超えるための、もっとも筋の良い出発点です。