はじめに サーバーワークスの池田です。 今週（3/22〜3/28）の Claude Code は v2.1.83 がリリースされました。Desktop アプリでは Computer Use と Dispatch が research preview として登場し、CLI では Auto Mode やクラウド定期タスクが追加された大型アップデート週です。 この記事で分かること Computer Use で Claude が Mac の画面を直接操作できるようになったこと。設定方法とアプリごとの権限レベル。 Dispatch でスマホから Mac にタスクを投げ、完了通知を受け取れること。Cowo…

本稿は、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 sso login --profile=your-profile-name export CLAUDE_CODE_USE_BEDROCK=1 export AWS_PROFILE=your-profile-name 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 コストと使用状況レポートに反映されます。アプリケーションプロファイルを作成するには、以下のコマンドを実行します。 aws bedrock create-inference-profile \ --inference-profile-name team-data-science \ --model-source arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4 \ --tags team=data-science costcenter=engineering タグはコストと使用状況レポートに表示されるため、次のようなクエリが可能です。 "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 インターフェイスはビジネスインテリジェンスツールと統合でき、スプレッドシート、機械学習モデル、またはプロジェクト管理システムへのエクスポートを可能にします。 例えば、部署ごとの月次コスト分析を確認するには、以下のようなクエリを使用します。 SELECT department, SUM(input_tokens) * 0.003 / 1000 as input_cost, SUM(output_tokens) * 0.015 / 1000 as output_cost, COUNT(DISTINCT user_email) as active_users FROM claude_code_metrics WHERE year = 2024 AND month = 1 GROUP BY department ORDER BY (input_cost + output_cost) DESC; このインフラストラクチャには、追加コストが発生します。Data Firehose はデータ取り込み、S3 はデータ保存、Athena はスキャンデータのクエリごとにそれぞれ課金されます。 履歴分析、複雑なクエリ、またはビジネスインテリジェンスツールとの統合が必要な場合は分析を有効にしてください。小規模な導入や、主にリアルタイム監視に重点を置く組織であればダッシュボードだけで十分な場合もありますが、Claude Code に本格的な投資を行う企業は、分析レイヤーを実装すべきです。これにより、投資対効果 (ROI) を実証し、長期的に利用を最適化するために必要な可視性が得られます。 クォータ ガイダンスソリューションのクォータを利用すると、個々の開発者やチームに使用制限を設定し、組織としてトークン消費を制御・管理できます。クォータを実装する前に、まずはモニタリングを有効にして、通常の使用パターンを理解することを推奨します。使用状況データからは通常、トークン消費量が多いほど生産性が高くなる傾向があり、ヘビーユーザーがそれに見合った価値を提供していることを示唆しています。 クォータシステムは、以下のような形式で制限値を DynamoDB に保存します。 { "userId": "jane@example.com", "monthlyLimit": 1000000, "currentUsage": 750000, "resetDate": "2025-02-01" } CloudWatch Events によってトリガーされる Lambda 関数が 15 分ごとにトークン消費を集計し、DynamoDB を更新するとともに、しきい値を超えた場合に SNS へ通知を発行します。 モニタリング比較 以下の表は、各モニタリング手法におけるトレードオフをまとめたものです。 機能 CloudWatch 呼び出しログ記録 OpenTelemetry ダッシュボードと分析 セットアップの複雑さ なし 低 中 中 ユーザー属性 なし IAM Identity 完全 完全 リアルタイムメトリクス あり なし あり あり コードレベルのメトリクス なし なし あり あり 履歴分析 限定的 あり あり あり コスト配分 アカウントレベル アカウントレベル ユーザー、チーム、部門 ユーザー、チーム、部門 トークン追跡 集計値のみ リクエストごと ユーザーごと トレンドを含むユーザーごと クォータ適用 手動 手動 可能 可能 運用オーバーヘッド 最小 低 中 中 コスト 最小 低 中 中 ユースケース POC 基本的な監査 本番環境 ROI を重視する企業 実装のまとめ このセクションでは、認証方法、組織アーキテクチャ、およびモニタリング戦略を推奨されるデプロイパターンに統合し、デプロイの成熟度に合わせた実装の優先順位についてのガイダンスを提供します。このアーキテクチャは、セキュリティ、運用のシンプルさ、そして包括的な可視性のバランスをとっています。開発者は企業の認証情報で 1 日 1 回認証を行い、管理者はダッシュボードでリアルタイムの使用状況を確認し、セキュリティチームは CloudTrail の監査ログと OpenTelemetry を通じた包括的なユーザー属性付きメトリクスを取得します。 実装パス このガイダンスソリューションは、インタラクティブなセットアッププロセスを通じて迅速なデプロイをサポートしており、数時間以内に認証とモニタリングを稼働させることができます。まずはパイロットグループにフルスタックをデプロイし、実際の使用データを収集してから、検証されたパターンに基づいて拡大してください。 デプロイ – Guidance for Claude Code with Amazon Bedrock リポジトリをクローンし、対話型の poetry run ccwb 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 です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。

キャリアプロダクト開発部の森 ＠jiskanulo です。 私ごとですが今年で45歳、WEBサービスの開発歴は20年以上になります。世間的にはベテランエンジニアとかシニアエンジニアとかと称される類だと自認しています。 そんな私ですが2026年1月に基本情報技術者試験を受験して合格しました。 この記事は、ベテランエンジニアが基本情報技術者試験をスキル棚卸しツールとして活用した体験と、受験しなくても使えるセルフチェックの方法を紹介します。 www.ipa.go.jp 受験の動機 結果 得意と苦手が可視化された 得意だった領域 苦手だった領域 得意と苦手のコントラストが意味するもの 試験範囲でスキルを棚卸しする方法 受験のTips CBT受験の雰囲気 集中力の維持に課題 まとめ 受験の動機 受験したきっかけは昨今のAIエージェントを前提とした開発手法の変化です。 ファインディではAIエージェントの導入・検証を積極的に行っています。 私もDevin, GitHub Copilot Chat, Cline, Claude Codeなどさまざまなツールやサービスを日々の開発業務に導入すべく検証していました。 2025年6月頃からClaude Codeを本格的に使用しはじめ、2026年3月現在では私自身が手でコードを書くことは全くなくなりました。 昨今のAIエージェントが主となり開発を進める体制では、AIエージェントへ適切な指示を出す力、AIエージェントからの提案を判断し承認・修正するための力が求められます。 この力をつけるための基礎知識として、基本情報技術者試験の内容はちょうどよいと感じています。 また、2025年末に開発部で「基本情報技術者試験の合格を目指しましょう」という方針も出たこともあり、社内のメンバーが続々と受験・合格している流れに乗りました。 受験理由をもう一つ挙げると、実は基本情報技術者試験を20年ほど前に受験して不合格になっており再挑戦をしないままでした。 さらに後年に応用情報技術者試験を受験し合格しているのですが、応用情報は持っているのに基本情報は持っていないというチグハグ感を解消したかったのです。 近いうちにデータベーススペシャリスト試験を受けようと考えていたところ、2026年度からCBT（コンピュータベースの試験）方式に移行するという情報があり、CBTの雰囲気を先に体験しておきたいという思いもありました。 ただデータベーススペシャリスト試験の実施そのものが2026年中は不明瞭な状況です。動向を注視しつつ、申し込みが再開されたらすぐエントリーしたいですね。 www.ipa.go.jp 結果 科目Aは705点、科目Bは680点となんとか合格できました。もう少し余裕を持って合格したかったのですが、そこは今後の伸びしろとします。 得意と苦手が可視化された 受験して最も収穫だったのは、自分のスキルの輪郭がはっきり見えたことです。 得意だった領域 計算問題やコードリーディング、データベース正規化や稼働率計算などの問題はスムーズに解けました。 日常業務でコードを書き、レビューし、設計・運用を考えることを毎日やっているので、実務経験がそのまま得点に結びつきました。 過去問の模擬試験でもこれらの分野は正答率が高く、特別な対策をしなくても安定して解ける状態でした。 苦手だった領域 一方、会計管理や財務指標に関する問題には苦戦しました。損益分岐点、ROI、減価償却といったテーマは過去問を解いていても正答率が目に見えて低い分野でした。 振り返ってみると、日々の開発業務で財務指標を意識する場面はほとんどありませんでした。 業務で触れない領域は経験年数に関係なく穴のまま残っている。この気づきが、受験して得た最大の収穫でした。 得意と苦手のコントラストが意味するもの この経験から見えたことは、エンジニアのスキルは実務でカバーしている範囲には自然と強くなれるが、逆に触れていない範囲は何年経っても盲点のままだということです。 基本情報技術者試験の出題範囲はITエンジニアの基礎知識を広くカバーしています。 だからこそ、受験すると自分のスキルマップの中で「どこが埋まっていて、どこが空白か」が浮き彫りになります。 試験のための勉強がすぐにサービス開発に活かせるかというとそうでもないのですが、自分の基礎知識の全体像を把握するにはちょうどいい粒度だと感じました。 試験範囲でスキルを棚卸しする方法 受験するにあたり、基本情報技術者試験ドットコムに大変お世話になりました。 www.fe-siken.com 私の場合は1日30分、20日間ほどで合計600問を回答しました。無料サービスの範囲でも十分に過去問を試すことができますし、有料のメンバー登録をすると学習の記録管理がしやすくなります。 スキル棚卸しをするために、まず科目Aの過去問を解いてみてください。 分野ごとの正答率が記録されるので、自分がどの分野に強く、どの分野に穴があるかが数値で可視化されます。 参考として、基本情報技術者試験の科目A出題範囲をもとにしたセルフチェック表を載せておきます。自分が「得意」「苦手」「触れたことがない」のどれに当たるか振り返ってみてください。 分野 自己評価（筆者の例） 基礎理論（離散数学、情報理論等） 得意 アルゴリズムとプログラミング 得意 コンピュータ構成要素 得意 システム構成要素 得意 ソフトウェア 得意 ハードウェア 苦手 データベース 得意 ネットワーク 苦手 セキュリティ 得意 マネジメント（プロジェクト・サービス） 苦手 ストラテジ（経営戦略・法務） 苦手 表のとおり、実務で日常的に使う分野は得意、そうでない分野は苦手という傾向がはっきり出ました。 正答率が安定して高い分野は実務でカバーできている基礎知識。低い分野やまったく分からない分野は、業務で触れていない盲点です。「知っているつもりだったが正確には理解できていなかった」という曖昧な領域も見つかるかもしれません。 受験のTips CBT受験の雰囲気 当日午後に受験会場に着くと、試験開始時刻前でも受験を始めてよいと案内されました。 パソコンに向かう前に持ち物検査を終えて着席。 キーボードはログイン時にしか使わず、試験中はマウス操作のみ。紙とペンは貸してもらい、筆算やコードのトレースをしながら回答しました。 回答完了ボタンを押すとすぐに得点が表示され、合否をその場で確認できました。結果待ちのモヤモヤがなかったのは嬉しいポイントでした。 集中力の維持に課題 科目Bの時点で集中力が切れてしまったのが今回の反省点です。 20年前は午前問題のあとに2時間ほどの昼休みがあり、リフレッシュしてから午後問題に臨めました。現在の形式では科目Aのあと10分の休憩で科目Bが始まるため、体力的にも精神的にも消耗した状態で後半戦に入ることになります。 受験する前には十分に体調を整えて臨むことをおすすめします。 まとめ 基本情報技術者試験は、資格取得という目的だけでなく、自分のスキルの得意と苦手を可視化するツールとして活用できました。 スキルを可視化できたこともあり、今年中にデータベーススペシャリスト試験の合格を目指して準備を進めていこうと思います。 みなさんも試験を受けてみてください。受験しなくても、過去問を試すだけでスキルの棚卸しになりますよ。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers