Amazon Web Services ブログ
Claude Code on Amazon Bedrock のデプロイパターンとベストプラクティス
本稿は、2025 年 11 月 19 日に AWS Machine Learning Blog で公開された “Claude Code deployment patterns and best practices with Amazon Bedrock” を翻訳したものです。
Claude Code は、Anthropic が提供する AI 駆動のコーディングアシスタントで、自然言語による対話を通じて開発者がコードの作成、レビュー、修正を行うのを支援します。Amazon Bedrock は、主要な AI 企業の基盤モデルに単一の API からアクセスできるフルマネージドサービスです。本記事では、 Claude Code を Amazon Bedrock でデプロイする方法を解説します。認証方式、インフラの選択、モニタリング戦略など、エンタープライズ規模で安全にデプロイするためのノウハウを紹介します。
ほとんどの企業への推奨事項
guidance-for-claude-code-with-amazon-bedrock の利用を推奨します。これは数時間以内にデプロイ可能な実績あるパターンです。
推奨されるスタック構成
- 認証:AWS IAM フェデレーションを使用した直接の IdP 統合
- インフラストラクチャ:専用 AWS アカウントと Amazon Bedrock のパブリックエンドポイント
- モニタリング:OpenTelemetry、CloudWatch ダッシュボード、分析
このアーキテクチャは、ユーザー属性の特定、キャパシティ管理、コストおよび開発者の生産性の可視性を備えた安全なアクセスを提供します。
認証方法
Claude Code のデプロイは、Amazon Bedrock への認証から始まります。認証方法の選択は、セキュリティ、モニタリング、運用、および開発者体験に影響を与えます。
認証方式の比較
| 機能 | Amazon Bedrock API キー | aws login | IAM Identity Center
による SSO |
直接の IdP 統合 |
| セッション期間 | 無期限 | 設定可能
(最大12時間) |
設定可能
(最大12時間) |
設定可能
(最大12時間) |
| セットアップ時間 | 数分 | 数分 | 数時間 | 数時間 |
| セキュリティリスク | 高 | 低 | 低 | 低 |
| ユーザー属性特定 | なし | 基本的 | 基本的 | 完全 |
| MFA サポート | なし | あり | あり | あり |
| OpenTelemetry
統合 |
なし | 限定的 | 限定的 | 完全 |
| コスト配分 | なし | 限定的 | 限定的 | 完全 |
| 運用オーバーヘッド | 高 | 中 | 中 | 低 |
| ユースケース | 短期テスト | テストと限定的なデプロイ | 迅速な SSO デプロイ | 本番環境デプロイ |
以下では、上記の表に示されたトレードオフと実装上の考慮事項について説明します。
Amazon Bedrock API キー
Amazon Bedrock は、概念実証(PoC)への最短パスとして API キーをサポートしています。短期(12 時間)および長期(1 日から 1 年、または無期限)の両方のキーを、AWS Management Console、AWS CLI、または SDK を通じて生成できます。
ただし、API キーは、MFA なしの永続的なアクセス、手動配布の必要性、リポジトリへの誤コミットのリスクなどによりセキュリティの脆弱性を生み出します。コスト配分やモニタリングのためのユーザー特定もできません。Amazon Bedrock の API Key は検証時のご利用を推奨します。
コンソール認証 (aws login)
aws login コマンドは、ブラウザベースの認証フローを通じてAWS Management Console の認証情報を Amazon Bedrock へのアクセスに使用します。API キーなしで迅速なセットアップをサポートし、テストや小規模なデプロイに推奨されています。
シングルサインオン (IAM Identity Center による SSO)
AWS IAM Identity Center は、OpenID Connect(OIDC)を通じてエンタープライズ ID プロバイダーと統合します。OIDC は、ID プロバイダーがユーザー ID を検証し、アプリケーションと認証情報を共有できるようにする認証プロトコルで、シングルサインオンを可能にします。この統合により、開発者は API キーを配布することなく、企業の認証情報を使用して Amazon Bedrock にアクセスできます。
開発者はaws sso login コマンドを使用して AWS IAM Identity Center で認証を行い、セッション期間を設定可能な一時認証情報を取得します。この認証情報は自動更新されるため、認証情報管理の運用負荷を軽減しつつ、一時的なアクセス権限によってセキュリティを向上させます。
AWS アクセスに IAM Identity Center を使用している組織は、このパターンを Claude Code にも拡張できます。ただし、OpenTelemetry の属性抽出のための OIDC JWT トークンを公開していないため、詳細なユーザーレベルのモニタリングは制限されます。
この認証方法は、詳細なモニタリングよりも迅速な SSO デプロイを優先する組織や、包括的なメトリクスがまだ必要とされない初期展開に適しています。
ID プロバイダーとの連携ソリューション ( 直接の IdP 統合 )
本番環境での Claude Code デプロイメントには、ID プロバイダー(Okta、Azure AD、Auth0、または AWS Cognito User Pools)との直接的な OIDC 連携を推奨します。guidance-for-claude-code-with-amazon-bedrock というソリューションでは、企業の ID プロバイダーを AWS IAM と直接連携し、モニタリングのためのユーザーコンテキストを含む一時的な認証情報を生成します。
ソリューションの詳細を一部紹介すると、プロセス認証情報プロバイダーは、認可コードの傍受を防ぐセキュリティ拡張機能である PKCE を利用した OAuth 2.0 のフローをオーケストレーションします。開発者はブラウザで認証を行い、OIDC トークンを AWS の一時的な認証情報と交換します。ヘルパースクリプトは AWS Security Token Service(STS)ののAssumeRoleWithWebIdentity を使用して、Amazon Bedrock を利用するための InvokeModel と InvokeModelWithStreaming の認証情報を持つロールを引き受けます。直接の IAM フェデレーションは最大 12 時間のセッション期間をサポートし、JWT トークンはセッション全体を通じてアクセス可能なままであるため、OpenTelemetry を通じたモニタリングによってメールアドレス、部署、チームなどのユーザー属性を追跡できます。
本ソリューションでは、Cognito Identity Pool と 直接の IAM フェデレーションの両方のパターンを実装していますが、シンプルさの観点から直接の IAM フェデレーションを推奨しています。このソリューションは、OIDC プロバイダーの統合設定、必要な IAM インフラストラクチャのデプロイ、Windows、macOS、Linux 用の配布パッケージをビルドする対話型セットアップウィザードを提供します。
開発者は、認証情報プロセスを使用するように AWS CLI プロファイルを設定するインストールパッケージを受け取ります。認証は企業の認証情報を通じて行われ、認証情報を更新するためにブラウザが自動的に開きます。認証プロセスはトークンのキャッシュ、認証情報の更新、およびエラーリカバリを処理します。
詳細な使用状況のモニタリング、開発者ごとのコスト配分、および包括的な監査証跡を必要とする組織にとって、IAM フェデレーションを通じた直接の IdP 統合は、後述する高度なモニタリング機能の基盤となります。
導入時の検討事項
認証以外にも、アーキテクチャの決定が Claude Code の AWS インフラストラクチャとの統合方法を形成します。これらの選択は、運用の複雑さ、コスト管理、使用ポリシーの実施に影響します。
パブリックエンドポイント
Amazon Bedrock は、最小限の運用オーバーヘッドで利用可能な、管理されたパブリック API エンドポイントを複数の AWS リージョンで提供しています。インフラ、スケーリング、可用性、セキュリティパッチはAWSが管理します。開発者は AWS CLI プロファイルまたは環境変数を通じて標準的な AWS 認証情報を使用します。直接の IdP 統合による OpenTelemetry メトリクスと組み合わせることで、パブリックエンドポイントを通じて個々の開発者、部門、またはコストセンターごとに使用状況を追跡でき、AWS IAM レベルで制御できます。例えば、開発者ごとのレート制限を実装するには、CloudWatch メトリクスや CloudTrail ログを監視し、自動的にアクションを実行するインフラストラクチャが必要です。カスタムビジネスロジックに基づいてリクエストレベルで即座にブロックする必要がある組織では、LLM(大規模言語モデル)ゲートウェイパターンなどの追加コンポーネントが必要になる場合があります。Amazon Bedrock のパブリックエンドポイントは、シンプルさ、AWS マネージドの信頼性、コストアラート、適切な制御メカニズムのバランスを提供するため、ほとんどの組織にとって十分です。
LLM ゲートウェイ
LLM ゲートウェイは、開発者と Amazon Bedrock の間に中間アプリケーション層を導入し、カスタムインフラを通じてリクエストをルーティングします。Guidance for Multi-Provider Generative AI Gateway on AWS では、このパターンを説明しており、ロードバランシングと一元化された認証情報管理を備えたコンテナ化されたプロキシサービスをデプロイします。
このアーキテクチャは以下の場合に最適です。
- マルチプロバイダーサポート:可用性、コスト、または機能に基づいて Amazon Bedrock、OpenAI、Azure OpenAI 間でルーティングする場合
- カスタムミドルウェア:リクエストレベルでの独自のプロンプトエンジニアリング、コンテンツフィルタリング、またはプロンプトインジェクション検知を行う場合
- リクエストレベルのポリシー適用:IAM の機能を超えたカスタムビジネスロジックに基づいて、リクエストを即座にブロックする場合
ゲートウェイは統一された API とリアルタイム追跡を提供しますが、運用オーバーヘッドが追加されます。Amazon Elastic Container Service (Amazon ECS)/Amazon Elastic Kubernetes Service (Amazon EKS) インフラストラクチャ、Elastic Load Balancing (ELB) Application Load Balancer、Amazon ElastiCache、Amazon Relational Database Service (Amazon RDS) の管理、レイテンシーの増加、そしてゲートウェイの問題が Claude Code の使用をブロックする新たな障害点が発生します。LLM ゲートウェイは、LLM にプログラム的に呼び出しを行うアプリケーションにおいて、一元的なモニタリング、ユーザーごとの可視性、統一されたアクセス制御を提供するのに優れています。
従来の API アクセスシナリオでは、組織はモニタリングとユーザー帰属の機能を得るためにゲートウェイをデプロイできます。しかし、Claude Code ガイダンスソリューションには、直接の IdP 認証、OpenTelemetry メトリクス、IAM ポリシー、CloudWatch ダッシュボードを通じたモニタリングと属性特定機能が既に含まれています。ガイダンスソリューションに LLM ゲートウェイを追加すると、既存の機能と重複します。マルチプロバイダーサポート、カスタムミドルウェア、または IAM を超えたリクエストレベルのポリシー制御が必要な場合にのみ、ゲートウェイの使用を検討してください。
専用 AWS アカウント実装
コーディングアシスタントの推論は、開発環境や本番環境のワークロードとは別の単一の専用アカウントに集約することを推奨します。このアプローチには 5 つの主要なメリットがあります。
- 運用の簡素化: 複数のアカウントにわたって追跡する代わりに、統合されたダッシュボードを通じてクォータを管理し、使用状況をモニタリングできます。クォータの引き上げ要求はアカウントごとではなく一度で済みます。
- 明確なコスト可視性: AWS Cost Explorer とコストと使用状況レポートは、複雑なタグ付けなしで Claude Code の料金を直接表示します。OpenTelemetry メトリクスにより、部門やチームレベルの配分が可能になります。
- 一元化されたセキュリティ: CloudTrail ログはモニタリングとコンプライアンスのために一箇所に集約されます。モニタリングスタックを一度デプロイするだけで、開発者からのメトリクスを収集できます。
- 本番環境の保護: アカウントレベルの分離により、Claude Code の使用がクォータを使い果たし、本番アプリケーションのスロットリングを引き起こすことを防ぎます。また、本番トラフィックの急増が開発者の生産性に影響を与えません。
- 実装: クロスアカウントでの IAM 設定により、開発者は制限されたロールにフェデレーションする ID プロバイダーを通じて認証を行い、適切なガードレールを備えたモデル呼び出し権限のみを付与されます。
この戦略は、直接の IdP 認証と OpenTelemetry モニタリングと統合されています。ID プロバイダーは認証を処理し、専用アカウントが推論を処理し、開発アカウントはアプリケーションに集中します。
推論プロファイル
Amazon Bedrock 推論プロファイルはリソースへのタグ付けを通じてコスト追跡を提供しますが、開発者ごとの粒度にはスケールしません。コスト配分のためのアプリケーションプロファイルを作成できますが、1000 人以上の個々の開発者のプロファイル管理は運用上の負担となります。推論プロファイルは、10 〜 50 程度の個別のチームで隔離されたコスト追跡を必要とする組織や、マネージドに AWS リージョン間でリクエストを分散するクロスリージョン推論を使用する場合に最適です。包括的なモニタリングよりも、基本的なコスト配分を必要とするシナリオに理想的です。
システム定義のクロスリージョン推論プロファイルは、複数の AWS リージョン間でリクエストを自動的にルーティングし、より高いスループットと可用性のために負荷を分散します。クロスリージョンプロファイル(例:us.anthropic.claude-sonnet-4)を呼び出すと、Amazon Bedrock はリクエストを処理するために利用可能なリージョンを選択します。
アプリケーション推論プロファイルは、アカウントで明示的に作成するプロファイルであり、通常はシステム定義のプロファイルやリージョン内の特定のモデルをラップしたものです。アプリケーションプロファイルにはteam:data-scienceやproject:fraud-detectionといったカスタムキーバリューペアをタグ付けでき、これらはコスト配分分析のために AWS コストと使用状況レポートに反映されます。アプリケーションプロファイルを作成するには、以下のコマンドを実行します。
タグはコストと使用状況レポートに表示されるため、次のようなクエリが可能です。
"What did the data-science team spend on Amazon Bedrock last month?"
各プロファイルは API 呼び出しで明示的に参照する必要があり、開発者の認証情報設定は共有エンドポイントではなく、独自のプロファイルを指定する必要があります。
推論プロファイルの詳細については、Amazon Bedrock 推論プロファイルのドキュメントをご覧ください。
モニタリング
効果的なモニタリング戦略は、使用状況、コスト、影響を追跡することで、Claude Code を単なる生産性ツールから測定可能な投資へと変革します。
段階的な拡張パス
モニタリングのレイヤーは補完的なものです。組織は通常、基本的な可視性から始め、ROI の要件が追加のインフラストラクチャを正当化するにつれて機能を追加していきます。

各レベルと、それがデプロイに適している状況を見ていきましょう。
注意:インフラコストは段階的に増加します。各レベルは前のレイヤーを維持しながら新しいコンポーネントを追加します。
CloudWatch
Amazon Bedrock は自動的にメトリクスを Amazon CloudWatch に発行し、呼び出し回数、スロットリングエラー、レイテンシーを追跡します。CloudWatch グラフは、リクエスト総数、平均レイテンシー、クォータ使用率などの集計傾向を最小限のデプロイ作業で表示します。このベースラインモニタリングは CloudWatch の標準料金に含まれています。呼び出しレートが急増したり、エラー率が閾値を超えたり、レイテンシが悪化したりしたときに通知する CloudWatch アラームを作成できます。
呼び出しログ記録
Amazon Bedrock 呼び出しログ記録は、各 API 呼び出しに関する詳細情報を Amazon S3 または CloudWatch Logs にキャプチャし、呼び出しメタデータと完全なリクエスト / レスポンスデータを含む個々のリクエストレコードを保存します。Amazon Athena でログを処理したり、データウェアハウスにロードしたり、カスタムツールで分析したりできます。ログには使用パターン、モデルごとの呼び出し、ピーク時の利用状況、および Amazon Bedrock アクセスの監査証跡が表示されます。
OpenTelemetry
Claude Code は、アプリケーションテレメトリデータを収集するためのオープンソースオブザーバビリティフレームワークである OpenTelemetry をサポートしています。OpenTelemetry コレクターエンドポイントを設定すると、Claude Code は Amazon Bedrock API 呼び出しと、より高レベルの開発アクティビティの両方について、詳細なメトリクスを出力します。
テレメトリは、Amazon Bedrock のデフォルトログに含まれていない詳細なコードレベルのメトリクスをキャプチャします。これには、追加 / 削除されたコード行数、修正されたファイル、使用されたプログラミング言語、Claude の提案に対する開発者の受け入れ率などが含まれます。また、ファイル編集、コード検索、ドキュメントリクエスト、リファクタリングタスクなどの主な操作も追跡します。
ガイダンスソリューションは Amazon ECS Fargate 上に OpenTelemetry インフラストラクチャをデプロイします。Application Load Balancer が HTTP(S) 経由でテレメトリを受信し、OpenTelemetry コレクターにメトリクスを転送します。コレクターは Amazon CloudWatch と Amazon S3 にデータをエクスポートします。
ダッシュボード
ガイダンスソリューションには、主要メトリクスを継続的に表示する CloudWatch ダッシュボードが含まれており、時間、日、週ごとのアクティブユーザーを追跡して、ユーザーごとのコスト計算を可能にする採用と使用の傾向を明らかにします。トークン消費は入力、出力、キャッシュされたトークンに分類され、高いキャッシュヒット率は効率的なコンテキスト再利用を示し、ユーザーごとのビューはヘビーユーザーを特定します。コードアクティビティメトリクスは、追加および削除された行を追跡し、トークン使用量と相関させて効率性と使用パターンを示します。
操作の内訳にはファイルの編集、コード検索、ドキュメントリクエストの分布が表示され、ユーザーリーダーボードにはトークン、コード行数、またはセッション時間ごとのトップ消費者が表示されます。
ダッシュボードはほぼリアルタイムで更新され、メトリクスがしきい値を超えたときに通知をトリガーする CloudWatch アラームと統合されています。ガイダンスソリューションは、複雑な集計のためのカスタム Lambda 関数を備えた CloudFormation を通じてデプロイされます。
分析
ダッシュボードはリアルタイムモニタリングに優れていますが、長期的なトレンドと複雑なユーザー行動分析には分析ツールが必要です。ガイダンスソリューションのオプションの分析スタックは、Amazon Data Firehose を使用してメトリクスを Amazon S3 にストリーミングします。AWS Glue Data Catalog がスキーマを定義し、Amazon Athena を通じてデータをクエリ可能にします。
分析レイヤーは、部門別の月間トークン消費量、プログラミング言語ごとのコード受け入れ率、チーム間のトークン効率のばらつきなどのクエリをサポートします。コスト分析は、トークンメトリクスと Amazon Bedrock の価格を結合してユーザーごとの正確なコストを計算し、部門レベルの課金配賦用に集計することで、コスト分析が高度になります。時系列分析は、予算予測のためにチームの成長に伴うコストの拡大を示します。SQL インターフェイスはビジネスインテリジェンスツールと統合でき、スプレッドシート、機械学習モデル、またはプロジェクト管理システムへのエクスポートを可能にします。
例えば、部署ごとの月次コスト分析を確認するには、以下のようなクエリを使用します。
このインフラストラクチャには、追加コストが発生します。Data Firehose はデータ取り込み、S3 はデータ保存、Athena はスキャンデータのクエリごとにそれぞれ課金されます。
履歴分析、複雑なクエリ、またはビジネスインテリジェンスツールとの統合が必要な場合は分析を有効にしてください。小規模な導入や、主にリアルタイム監視に重点を置く組織であればダッシュボードだけで十分な場合もありますが、Claude Code に本格的な投資を行う企業は、分析レイヤーを実装すべきです。これにより、投資対効果 (ROI) を実証し、長期的に利用を最適化するために必要な可視性が得られます。
クォータ
ガイダンスソリューションのクォータを利用すると、個々の開発者やチームに使用制限を設定し、組織としてトークン消費を制御・管理できます。クォータを実装する前に、まずはモニタリングを有効にして、通常の使用パターンを理解することを推奨します。使用状況データからは通常、トークン消費量が多いほど生産性が高くなる傾向があり、ヘビーユーザーがそれに見合った価値を提供していることを示唆しています。
クォータシステムは、以下のような形式で制限値を DynamoDB に保存します。
CloudWatch Events によってトリガーされる Lambda 関数が 15 分ごとにトークン消費を集計し、DynamoDB を更新するとともに、しきい値を超えた場合に SNS へ通知を発行します。
モニタリング比較
以下の表は、各モニタリング手法におけるトレードオフをまとめたものです。
| 機能 | CloudWatch | 呼び出しログ記録 | OpenTelemetry | ダッシュボードと分析 |
| セットアップの複雑さ | なし | 低 | 中 | 中 |
| ユーザー属性 | なし | IAM Identity | 完全 | 完全 |
| リアルタイムメトリクス | あり | なし | あり | あり |
| コードレベルのメトリクス | なし | なし | あり | あり |
| 履歴分析 | 限定的 | あり | あり | あり |
| コスト配分 | アカウントレベル | アカウントレベル | ユーザー、チーム、部門 | ユーザー、チーム、部門 |
| トークン追跡 | 集計値のみ | リクエストごと | ユーザーごと | トレンドを含むユーザーごと |
| クォータ適用 | 手動 | 手動 | 可能 | 可能 |
| 運用オーバーヘッド | 最小 | 低 | 中 | 中 |
| コスト | 最小 | 低 | 中 | 中 |
| ユースケース | POC | 基本的な監査 | 本番環境 | ROI を重視する企業 |
実装のまとめ
このセクションでは、認証方法、組織アーキテクチャ、およびモニタリング戦略を推奨されるデプロイパターンに統合し、デプロイの成熟度に合わせた実装の優先順位についてのガイダンスを提供します。このアーキテクチャは、セキュリティ、運用のシンプルさ、そして包括的な可視性のバランスをとっています。開発者は企業の認証情報で 1 日 1 回認証を行い、管理者はダッシュボードでリアルタイムの使用状況を確認し、セキュリティチームは CloudTrail の監査ログと OpenTelemetry を通じた包括的なユーザー属性付きメトリクスを取得します。
実装パス
このガイダンスソリューションは、インタラクティブなセットアッププロセスを通じて迅速なデプロイをサポートしており、数時間以内に認証とモニタリングを稼働させることができます。まずはパイロットグループにフルスタックをデプロイし、実際の使用データを収集してから、検証されたパターンに基づいて拡大してください。
- デプロイ – Guidance for Claude Code with Amazon Bedrock リポジトリをクローンし、対話型の
poetry runccwb initウィザードを実行します。このウィザードは ID プロバイダー、フェデレーションタイプ、AWS リージョン、およびオプションのモニタリングを設定します。CloudFormation スタックをデプロイし(通常 15 〜 30 分)、配布パッケージをビルドして、ユーザーに配布する前にローカルで認証をテストします。
- 配布 – 異なるチームから 5 〜 20 人の開発者をパイロットグループとして選定します。このグループが認証、モニタリングを検証し、本格展開の計画に必要な使用データを提供します。モニタリングを有効にしている場合、CloudWatch ダッシュボードにアクティビティが即座に表示されます。トークン消費量、コード採用率、操作タイプを監視することで、必要なキャパシティ要件の見積もり、トレーニングニーズの特定、より広範な展開に向けた価値の実証を行うことができます。
- 拡大 – Claude Code の検証が完了したら、チームまたは部門単位で採用を拡大します。履歴トレンド分析のために分析スタックを追加(通常 1 〜 2 時間)し、採用率、高パフォーマンスなチーム、およびコスト予測を確認します。
- 最適化 – 開発リーダーシップとの定期的なレビューサイクルを通じて、監視データを継続的な改善に活用します。監視データは、価値の実証、トレーニングニーズの特定、キャパシティ調整のガイドに役立ちます。
推奨パターンから逸脱する場合
上記のアーキテクチャは多くのエンタープライズ展開に適していますが、特定の状況下では異なるアプローチが正当化される場合があります。
- LLM ゲートウェイの検討 – Amazon Bedrock 以外の複数の LLM プロバイダーが必要な場合、プロンプト処理やレスポンスフィルタリング用のカスタムミドルウェアが必要な場合、またはAWS IAM 機能を超えたリクエストレベルのポリシー適用を必要とする規制環境で運用している場合。
- 推論プロファイルの検討 – 個別のコスト追跡を必要とするチームが 50 未満であり、テレメトリメトリクスよりも AWS ネイティブの請求配分を好む場合。推論プロファイルはプロジェクトベースのコスト配分には適していますが、開発者ごとの追跡にはスケールしません。
- モニタリングなしでの開始を検討 – 10 人未満の開発者による期間限定のパイロット運用で、基本的な CloudWatch メトリクスで十分な場合。スケールさせる前にモニタリングを追加することを計画してください。後からの追加には開発者へのパッケージの再配布が必要になるためです。
- API キーの検討 – セキュリティリスクが許容される期間を限定したテスト(1 週間未満)の場合のみ。
結論
Amazon Bedrock で Claude Code をエンタープライズ規模でデプロイするには、認証、アーキテクチャ、およびモニタリングについて慎重な判断が必要です。本番環境に対応したデプロイは明確なパターンに従います。直接の IdP 統合により、ユーザー属性が紐づいた安全なアクセスを提供し、専用の AWS アカウントによりキャパシティ管理を簡素化します。そして OpenTelemetry による監視が、コストと開発者の生産性に対する可視性を提供します。guidance-for-claude-code-with-amazon-bedrock は、これらのパターンをデプロイ可能なソリューションとして実装しています。まずは認証と基本的なモニタリングから始め、スケールに合わせて機能を追加していってください。
AI 駆動の開発ツールが業界標準になるにつれて、デプロイメントにおいてセキュリティ、モニタリング、運用の優秀さを優先する組織は持続的な優位性を得ることになります。このガイドは、企業全体で Claude Code の可能性を最大化するための包括的なフレームワークを提供します。
開始するには、guidance-for-claude-code-with-amazon-bedrock リポジトリにアクセスしてください。
著者について
Court Schuett:プリンシパル・スペシャリスト・ソリューションアーキテクト – GenAI として、AI コーディングアシスタントを活用して他の人々がそれらを最大限に活用できるよう支援する業務に従事しています。仕事以外では、旅行、音楽鑑賞、木工を楽しんでいます。
Jawhny Cooke:AWSにおける Anthropic の Claude Code のグローバルテックリードであり、エンタープライズがエージェンティックコーディングを大規模に運用するのを支援する専門家です。彼は顧客やパートナーと協力して、自律的コーディングワークフローの設計からマルチエージェントシステムのオーケストレーション、AWS インフラでの運用最適化まで、AI 支援開発の複雑な本番課題を解決しています。彼の仕事は最先端の AI 機能とエンタープライズグレードの信頼性を橋渡しし、組織が本番環境で Claude Code を自信を持って採用できるよう支援しています。
Karan Lakhwani:Amazon Web Services のシニアカスタマーソリューションマネージャーです。生成 AI テクノロジーを専門とし、AWS Golden Jacket 受賞者でもあります。仕事以外では、新しいレストランの開拓やスキーを楽しんでいます。
Gabe Levy:ニューヨークを拠点とする AWS のアソシエイトデリバリーコンサルタントで、主にクラウドでのアプリケーション開発に焦点を当てています。Gabe は人工知能と機械学習の副専門を持っています。AWS の顧客との仕事以外では、運動、読書、家族や友人との時間を楽しんでいます。
Gabriel Velazquez Lopez:AWS の GenAI プロダクトリーダーであり、Anthropic とのパートナーシップで AWS 上 のClaude の戦略、市場投入、製品ローンチを主導しています。
翻訳者について
山澤 良介:ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。前職では主にネットワーク案件を担当していました。好きなサービスは、Amazon Bedrock と AWS Transit Gateway です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。