サイオステクノロジー株式会社 Saman 2026年3月末、広く使われているHTTPライブラリ Axios がサプライチェーン攻撃の標的になりました。 サプライチェーン攻撃とは、利用者が普段から信頼しているソフトウェアや配布経路を悪用して、マルウェアを届ける手口です。今回の事件は「有名なライブラリが乗っ取られた」という単純な話ではなく、現代のソフトウェア開発が持つ構造的な脆弱性を突いた、非常に巧妙なものでした。 本記事は、Elastic Security Labsが公開した調査・分析レポートを中心にもとにまとめています。技術的な詳細や検知ルールについては、ぜひ Elastic Security Labsの公式記事 またはElasticのJoe Desimoneさんが Github Gist で公開しているものを直接ご参照ください。 目次 何が起きたのか なぜこれほど危険だったのか Elasticはどう検知していたのか 1つの設計思想から生まれた攻撃 感染が疑われる場合の対応 この事例が示すもの 何が起きたのか 攻撃者はAxiosメンテナーのnpmアカウントを乗っ取り、悪意あるバージョン（ axios@1.14.1 と axios@0.30.4 ）をnpmに公開しました。通常、Axiosは GitHub Actions を経由した公開フローを採用していますが、今回は通常とは異なる公開経路が使われた可能性があり、直接CLIから公開されたとみられています。 この悪意あるバージョンには、 plain-crypto-js@4.2.1 という不正な依存パッケージが仕込まれていました。パッケージには postinstall という仕組みがあり、インストール完了後に自動でコードを実行できます。今回はこれを悪用して setup.js が自動起動し、攻撃者のコードが走る状態になっていました。 つまり、利用者は npm installをしただけで、知らぬ間に攻撃者のコードを実行してしまう可能性がありました。 Huntressの観測によると、パッケージ公開からわずか 89秒後 に最初の感染が確認されています。公開時間が短くても、被害は十分に広がることが証明されました。 なお、問題はAxiosそのものではなく、配布経路が一時的に侵害された点にあります。 なぜこれほど危険だったのか ① 自分でAxiosを入れていなくても感染する Axiosは非常に広く使われているため、別のパッケージが内部で依存しているケース（トランジティブ依存）も多くあります。「自分のプロジェクトにAxiosはない」と思っていても、気づかないうちに入っていた、というケースが起こり得ます。 ② バグでも脆弱性でもない攻撃だった 今回はCVEやゼロデイ脆弱性を突いたものではありません。信頼された公開経路そのものが武器にされた事件です。どれだけコードが安全でも、配布フローが侵害されれば意味をなしません。 ③ Windows・macOS・Linuxすべてが対象 setup.js は難読化されており、実行時にOSを判別してそれぞれに対応したマルウェアを起動します。開発者のPC、CI/CDパイプライン、本番サーバーまで、環境を問わず標的になり得ました。 Elasticはどう検知していたのか Elastic Security Labsが注目したのは、ドメイン名やファイルハッシュではなく、 プロセスの実行チェーン です。これはエンドポイント上の振る舞い（EDR的な観点）に基づく検知であり、「何が実行されたか」ではなく「どのように実行されたか」に着目しています。 node 起動 → OSコマンド実行 → 外部からファイル取得 → 実行 正規のパッケージインストールでは、このような流れは通常起きません。攻撃者はドメイン名やファイル名を変えることはできますが、npm install 直後のこの不自然な実行の連鎖はそう簡単には変えられない、という考え方です。 OSごとの検知シグナルも具体的に示されています。Linuxでは node 後の sh/curl 起動とPythonスクリプトの実行、Windowsではエンコードされた PowerShell の実行と永続化の試み、macOSでは osascript の利用や不審なパスへのファイル配置が観測されました。 さらにElasticは、この問題を把握した後に GitHub Security Advisory を提出し、検知ルールと詳細分析を公開するなど、情報共有にも積極的に動いていました。 1つの設計思想から生まれた攻撃 Elasticの詳細分析（”One RAT to Rule Them All”）によると、OS別に異なるマルウェアが使われていたように見えて、実際には通信構造とコマンド体系が共通していました。 実装言語はOSごとに違っても、攻撃者は クロスプラットフォームで動く1つの統一されたRAT（遠隔操作マルウェア）運用 を設計していたと考えられます。これは場当たり的な攻撃ではなく、計画的・組織的に準備された攻撃であることを示しています。 感染が疑われる場合の対応 Huntressは、影響を受けたバージョンを導入していた場合、 ファイルを削除して終わりにしてはいけない と強く警告しています。 RATが一度動いてしまうと、何が参照・持ち出されたかを完全に特定することは困難です。推奨される対応は以下の通りです。 資格情報・トークンのローテーション 影響範囲の徹底調査 必要に応じた環境の再構築 「マルウェアを消した」ことと「安全が戻った」ことは別物です。特にシークレットやアクセストークンが置かれるCI/CD環境では、侵害前提の対応が求められます。 この事例が示すもの 今回のAxios事件は、オープンソースを使うこと自体が危険だという話ではありません。むしろ、依存関係が当たり前になった現代の開発では、 守るべき対象も「コードの品質」から「サプライチェーン全体の信頼性」へと広がっている ことを示した事件です。 89秒で感染が始まるスピードは、人手による確認だけでは対応が追いつかないことを如実に示しています。固定のIOCに頼るだけでなく、インストール直後の不自然な実行チェーンを監視する仕組みを持てているかどうか、今一度見直すきっかけにしてください。 参考元 Elastic Security Labs, Elastic releases detections for the Axios supply chain compromise Elastic Security Labs, Inside the Axios supply chain compromise – one RAT to rule them all Huntress, Supply Chain Compromise of axios npm Package Joe Desimone, axios_compromise.md (GitHub Gist) The post Axiosサプライチェーン攻撃速報：Elasticはこの攻撃をどう検知したのか first appeared on Elastic Portal .

本稿は、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 です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。

こんにちは! 今回初めて AWS Weekly Roundup を担当する Daniel Abib です。私は、生成 AI と Amazon Bedrock を専門とする AWS シニアスペシャリストソリューションアーキテクトです。ソリューションアーキテクチャ、ソフトウェア開発、クラウドアーキテクチャでの経験は 28 年を超え、Amazon Bedrock を使って生成 AI の力を活かせるようにスタートアップとエンタープライズ企業を支援しています。AWS 勤務歴は 6 年半以上で、中南米全域のお客様と密接に連携しています。また、サーバーレステクノロジーにも情熱を持っています。 仕事とエンデュランススポーツ以外では、Cecília (7 才) とRafael (4 才) の父親として全力を注いでいます。子どもたちは、どんな分散システムよりも毎日を忙しく、そして幸せにしてくれます。私の拠点はサンパウロです。 LinkedIn と X (@DCABib) では、生成 AI、Amazon Bedrock、AWSサーバーレスサービスに関する洞察を投稿していますが、アイアンマンの懐かしい思い出を投稿することもたまにあります。 それでは、2026 年 3 月 23 日週の AWS ニュースを見ていきましょう。 2026 年 3 月 16 日週のリリース 2026 年 3 月 16 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Redshift がダッシュボードと ETL ワークロードでの新規クエリのパフォーマンスを最大 7 倍に向上 – ダッシュボードと ETL ワークロードでの新規クエリに対し、Amazon Redshift が最大 7 倍速いパフォーマンスを達成できるようになりました。初めて実行するクエリ (キャッシュされた結果がないもの) の実行速度が大幅に向上するため、インタラクティブなダッシュボードの待機時間短縮と、ETL パイプラインの迅速化が可能になります。これは、キャッシュヒットの頻度が低く、クエリの変動性が高いワークロードに特に大きなインパクトをもたらします。 Amazon Bedrock での NVIDIA Nemotron 3 Super 提供開始 – Amazon Bedrock で NVIDIA Nemotron 3 Super を利用できるようになり、統合 Bedrock API を通じてアクセスできる基盤モデルのラインナップが拡大されました。Nemotron 3 Super は、テキスト生成、複雑な推論、要約、コード生成などのタスク向けに最適化された高性能言語モデルです。これからは、インフラストラクチャを管理しなくても、既存の Bedrock ワークフローで他の基盤モデルとともに Nemotron 3 Super を呼び出すことができるようになります。 エンタープライズ AI 向けに Nova モデルをカスタマイズするためのシームレスな手段、Nova Forge SDK の導入 – Nova Forge SDK は、エンタープライズユースケース向けに Amazon Nova モデルをファインチューニングしてカスタマイズするための効率的な手段を提供します。Nova モデルをドメイン固有のデータに適合させ、Amazon Bedrock 内にそれらを直接デプロイできるため、目的に合わせて AI ソリューションを構築する複雑性が軽減されます。モデルのカスタマイズという面倒な作業は SDK が処理するので、ユーザーは基盤となるインフラストラクチャではなく、ビジネスロジックに集中できます。 Amazon Corretto 26 の一般提供開始 – Amazon Corretto 26 の一般提供が開始されました。これは、OpenJDK の無償/本番環境対応ディストリビューションの最新 LTS (長期サポート) リリースです。Corretto 26 には、最新の Java 言語機能、パフォーマンス改善、セキュリティパッチが含まれており、これらすべてが AWS の長期サポートによって支えられています。Corretto 26 は、Amazon Linux、Windows、macOS、および Docker イメージ上の開発環境と本番環境全体でご利用いただけます。 AWS Lambda がアベイラビリティーゾーンメタデータのサポートを開始 – AWS Lambda が、関数の呼び出しにアベイラビリティーゾーンメタデータを提供するようになりました。Lambda 関数が実行されているアベイラビリティーゾーンを特定できるようになるため、より優れたオブザーバビリティと、より多くの情報に基づいたアーキテクチャ上の判断が可能になるとともに、レイテンシーの影響を受けやすいワークロードとマルチ AZ ワークロードのトラブルシューティングが容易になります。これは特に、Lambda 実行とアーキテクチャ内にある他の AZ アウェアなサービスとの関連付けに便利です。 Amazon CloudWatch Logs が HTTP ベースのプロトコルを使用したログ取り込みのサポートを開始 – Amazon CloudWatch Logs が、HTTP ベースのプロトコルを使用したログの取り込みをサポートするようになり、標準の HTTP エンドポイントを使用するアプリケーションとサービスからのログの送信がよりシンプルになりました。カスタムエージェントや追加の SDK 統合を必要とすることなく CloudWatch Logs にログをルーティングできるようになったため、ワークロード全体でログを一元管理するハードルが低くなります。 Amazon EKS が Provisioned Control Plane クラスターに対する 99.99% のサービスレベルアグリーメントと新しい 8XL スケーリングティアを発表 – Amazon EKS が Provisioned Control Plane で実行されるクラスターに対して 99.99% のサービスレベルアグリーメント (SLA) の提供を開始しました。これは、標準コントロールプレーンで提供される 99.95% の SLA を超えるものです。EKS には、利用可能な Provisioned Control Plane ティアの中でも最も大きい 8XL スケーリングティアも導入されます。このティアの Kubernetes API サーバーリクエスト処理能力は、すぐ下のティアである 4XL ティアの 2 倍であるため、AI/機械学習トレーニング、ハイパフォーマンスコンピューティング (HPC)、大規模なデータ処理といった大規模ワークロードに最適です。 AWS のその他のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Kiro for students – 学生向けの Kiro の提供が開始され、次世代のビルダーが AI 駆動の開発ツールに無料でアクセスできるようになりました。Swami Sivasubramanian が LinkedIn で共有 したように、「学生は、テクノロジーを形作る未来の意思決定者です」。Kiro は、開発初日から AI を使って構築する実践的な体験を学生に提供します。皆さん自身が学生、または学生である方をご存知なら、Kiro for students は AI 支援の開発で構築を始める絶好の機会です。 Strands Steering Hook が 100% のエージェント精度を達成 – Strands Agents チームは、Steering Hook が 100% のエージェント精度を達成できることを示す結果を発表しました。これは、エージェントの行動を制御するためのプロンプトエンジニアリングとリジッドなワークフローアプローチの両方をしのぐ結果です。Swami が LinkedIn で言及 しているとおり、信頼性のある AI エージェントの構築は、しばしばモデル行動をガイドする方法の見直しを意味します。そんな中、Steering Hook はエージェントの信頼性につながる新しい魅力的な手段を提供します。 AWS Builder Center でのバッジ導入 – AWS Builder Center に、ビルダーコミュニティ内での貢献と成果を評価するためのバッジが登場しました。バッジは、ソリューションの共有、チャレンジへの参加、仲間のビルダーとの交流によって獲得できます。専門知識をアピールし、成長を追跡するためのすばらしい方法です。 共に構築し続ける: コミュニティの力 – AWS エコシステムにおけるコミュニティ主導の学習とコラボレーションの力に関する思慮に富んだ読み物です。AWS を使い始めたばかりであるか、何年も構築してきたかにかかわらず、ビルダーコミュニティは、互いにつながり、知識を共有し、共に成長できる場所です。ビルダーコミュニティをチェックしてみてください。自信を持ってお勧めします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。近日開催される AWS Summit には、パリ (4 月 1 日)、ロンドン (4 月 22 日)、バンガロール (4 月 23〜24 日)、シンガポール (5 月 6 日)、テルアビブ (5 月 6 日)、ストックホルム (5 月 7 日) などがあります。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。近日開催されるイベントには、サンフランシスコ (4 月 10 日) およびルーマニア (4 月 23～24 日) があります。 AWSome Women Summit LATAM – 3 月 28 日にメキシコシティで開催されるこのイベントは、中南米全域でクラウドテクノロジーに携わる女性の功績を称え、エンパワーメントを図ることを目的としています。中南米テクノロジーコミュニティのすばらしいイニシアチブです。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。今後開催される AWS 主導の対面および仮想イベント、スタートアップイベント、デベロッパー向けのイベントについては、 AWS イベントとウェビナー をご覧ください。 2026 年 3 月 23 日週のニュースは以上です。2026 年 3 月 30 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。