本記事は 2026 年 8 月 27 日 に公開された「 A year of expanding choice for VMware customers on AWS 」を翻訳したものです。 Amazon EVS が一般提供 (GA) を開始してから 1 年以上が経ちました。人材やツール、運用ワークフローへの既存の投資を維持しながらクラウドでより多くの選択肢を求めていた VMware ワークロードのお客様にとって、Amazon EVS の GA 開始は大きな節目でした。Amazon EVS を使用すると、AWS 環境と統合された Amazon EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を実行できます。チームは VMware のソリューションを継続して使用しながら、AWS の機能とグローバルな展開力を活用できます。 この 1 年間で新しい VCF バージョンのサポートを追加し、デプロイの自動化機能をリリースし、新しい EC2 インスタンスへの対応も拡大してきました。VCF 9 の Memory Tiering や NSX Federation の設定に関するガイダンスも公開し、新しい Windows Server ライセンスの権利オプションも導入しました。これらの機能追加により AWS で稼働する VMware ワークロードのデプロイ、運用、スケーリング、保護をお客様がより細かく制御できるように取り組んでいます。 ここからは最初の 1 年間でお届けした内容を詳しく紹介します。 VCF 9 を思い通りにデプロイ 今年に入って Amazon EVS での VCF 9.0 および 9.1 のサポート を発表しました。VCF 9 では Amazon EVS が VPC 内に EC2 ベアメタルインフラストラクチャをプロビジョニングし、アーキテクチャや設定はネイティブの VCF Installer でお客様自身が管理します。この制御レベルは VCF のライフサイクル全体に及ぶため、オンプレミスと同じ VCF の機能を Amazon EVS でも利用できます。 自動インストールを好むチーム向けには Solutions for Amazon EVS GitHub リポジトリ で Amazon EVS Deployment Orchestrator を公開しました。Amazon EVS Deployment Orchestrator には Amazon EVS 上に完全に構成された VCF 9 環境をデプロイするためのエンドツーエンドの自動化が含まれています。今後も計画、デプロイ、移行、運用のための新しいソリューションを追加していきます。 新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール 4 月には i7i.metal-24xl のサポート を追加して EC2 インスタンスの選択肢を拡大し、本日 i7i.metal-48xl のサポート を発表します。この新しいインスタンスは物理コア 96 個、メモリ 1.5 TB、ローカル NVMe ストレージ 45 TB を備え、負荷の高い VMware ワークロードに対応する大きなキャパシティを提供します。 第 5 世代 Intel Xeon Scalable プロセッサーを搭載した i7i インスタンスは、i4i インスタンスと比べてコンピューティング性能が最大 23% 向上し、料金性能比も 10% 以上向上しています。i7i.metal-48xl はコア数とメモリ容量が増えているため、ホストあたりでより多くの VM を実行でき、少ないホスト数でも環境を拡張できます。 また Amazon EVS の対応リージョンを 22 の AWS リージョンに拡大し、エンドユーザーの近くにワークロードを配置したり、ビジネス目標やデータ主権の要件に合わせたデプロイができるようになりました。さらに環境の最大サイズを 16 ホストから 32 ホストに増やしました。1 つの環境内で大規模な単一クラスターを構築することも、複数の小規模クラスターに分けることも、要件に合わせて自由に組み合わせることもできます。 Memory Tiering でクラスター密度を向上 VCF 9 は、ホストがローカル NVMe ストレージを追加メモリとして利用できる Memory Tiering を導入しました。同じホスト数でもクラスターが実質的に最大 2 倍のメモリを扱えるようになり、VM の密度を高めながらハードウェアとライセンスのコストを削減できます。Memory Tiering は i4i および i7i の両インスタンスファミリーに対応しています。 Memory Tiering の詳細解説 ではこの機能の仕組みや、Amazon EVS でのサイジングと有効化について説明しています。 Windows Server のライセンスをシンプルに Windows Server のライセンスは VMware の移行を計画する際に障壁となることがあります。 Amazon EVS Windows Server Licensing では Windows VM を実行するための 2 つの選択肢を用意しています。対象となる Windows Server ライセンスと移行権を持つお客様は、そのライセンスをそのまま Amazon EVS に持ち込めます。移行権のない VM については、Amazon EVS で Windows Server ライセンスの権利を追加し、使用した分だけ vCPU 時間単位で料金を支払えます。権利は環境の変化に応じて追加・削除できるため、個々の VM 単位でライセンスを付与し、ホスト全体にライセンスを付与するコストを回避できます。 Amazon EVS で VMware ワークロードを保護・復旧 Amazon EVS を使うと、チームが既に使い慣れた VMware のツールとプロセスのまま、AWS 上で VMware ワークロードを柔軟に保護・復旧できます。オンデマンドで復旧環境をデプロイし、ワークロードを変更せずに稼働させ、復旧目標に合わせてキャパシティをスケールできます。 Amazon EVS における VMware ワークロードの災害復旧ガイド では復旧方法と保護オプションを比較しており、ワークロードごとに復旧時間、復旧時点、コスト、運用要件のバランスを取れます。 サイト間でネットワークとセキュリティを拡張 またオンプレミスの NSX 環境と Amazon EVS 環境を単一のコントロールプレーンで管理できる NSX Federation のサポートも発表しました。NSX Federation により拠点をまたいでネットワークセグメントとセキュリティポリシーを拡張し、データセンターと AWS の間で統一されたネットワーキング基盤を構築できます。大規模なレイヤー 2 拡張、統一された Distributed Firewall ポリシー、簡素化された災害復旧のフェイルオーバーを必要とするお客様にとって、NSX Federation は HCX の移行ワークフローを補完する長期的なネットワーキングと復旧の基盤となります。 NSX Federation の詳細解説 では両方の技術がどのように連携し、それぞれがどのような場面に適しているかを説明しています。 より広い選択肢を提供した 1 年間 今年リリースしたすべての機能はチームが使い慣れた VMware のツールと運用ワークフローを維持しながら、Amazon EVS でより多くの制御、選択肢、柔軟性を提供するという目標を支えるものです。VMware を利用している組織であれば、Amazon EVS を VMware ベースのワークロードを実行する世界最高の場所にしたいと考えています。 次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください 最新の取り組みを実際にご覧になりたい方は、8 月 31 日から 9 月 3 日までラスベガスの The Venetian で開催される VMware Explore 2026 にぜひお越しください。 今すぐセッションをスケジュールに追加してください 。 ブレイクアウトセッション [CLOB2172LVS] Amazon EVS with VCF 9: Expanding choice and flexibility for VMware on AWS – 9 月 2 日(水) | 午後 3:15 – 午後 4:00 | Level 3, San Polo 3505 20 分間シアターセッション [CLOQT2319LVS] 20-minute guide to running VMware Cloud Foundation 9 on Amazon EVS – 8 月 31 日(月) | 午後 5:30 – 午後 5:50 | The Hub Theater VMware Explore にご参加の有無を問わず、皆様が取り組んでいる内容についてぜひお聞かせください。 Amazon EVS の製品ページ にアクセスして利用を開始するか、AWS のアカウントチームに連絡して次のステップを検討してください。 著者について Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とトランスフォーメーションを担当しています。マーケティングとテクノロジー分野で7年以上の経験を持ち、複雑な技術を分かりやすく伝えるストーリーづくりに情熱を注いでいます。AWS の業務以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーとして、VMware、SAP、Red Hat OpenShift のワークロードを担当するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアの分野で25年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis AWS のシニアテクニカルプロダクトマネージャーとして、インフラストラクチャの移行と Amazon Elastic VMware Service を担当しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS のサービスを活用してお客様がビジネス成果を達成することを支援することに情熱を注いでいます。プライベートでは、旅行を通じて様々な場所や人々、文化に触れることを楽しんでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本記事は2026年4月17日に公開された「 Introducing granular cost attribution for Amazon Bedrock 」を翻訳したものです。 AI による推論がクラウド支出の大きな割合を占めるようになる中、誰が、そして何がコストを押し上げているのかを把握することは、チャージバック、コスト最適化、財務計画にとって不可欠です。本日、Amazon Bedrock 推論のきめ細かなコスト配分機能を発表します。 Amazon Bedrock は、推論コストを API コールを実行した IAM プリンシパルに自動的に紐付けるようになりました。 IAM プリンシパル とは、IAM ユーザー、アプリケーションが引き受けたロール、または Okta や Entra ID などのプロバイダーからのフェデレーテッド ID のことです。この紐付けは AWS Billing に反映され、モデルを問わず機能します。管理すべきリソースはなく、既存のワークフローを変更する必要もありません。オプションのコスト配分タグを使用すれば、AWS Cost Explorer や AWS Cost and Usage Reports (CUR 2.0) で、チーム別、プロジェクト別、またはカスタムディメンション別にコストを集計できます。 この記事では、Amazon Bedrock のきめ細かなコスト配分の仕組みを紹介し、コスト追跡のシナリオ例を解説します。 きめ細かなコスト配分の仕組み CUR 2.0 では、データエクスポート設定で IAM プリンシパルデータを有効にすると、どの AWS Identity and Access Management (IAM) プリンシパルが Amazon Bedrock を呼び出しているか、またそれぞれがいくら使っているかを確認できます。以下に例を示します。 line_item_iam_principal line_item_usage_type line_item_unblended_cost arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-input-tokens $0.069 arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-output-tokens $0.214 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-input-tokens $0.198 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-output-tokens $0.990 ここでは、Alice が Claude 4.6 Sonnet を、Bob が Claude 4.6 Opus を使用していること、そしてそれぞれが入力トークンと出力トークンにいくら費やしているかを確認できます。以下の表は、各アイデンティティタイプに対して line_item_iam_principal 列に含まれる内容を示しています。 Bedrock の呼び出し方法 line_item_iam_principal AWS IAM ユーザー …user/alice Bedrock キー (IAM ユーザーにマッピング) …user/BedrockAPIKey-234s AWS IAM ロール (例: AWS Lambda 関数) …assumed-role/AppRole/session フェデレーテッドユーザー (例: ID プロバイダーからのユーザー) …assumed-role/Role/user@acme.org タグを使った集計と Cost Explorer での活用 チーム別、プロジェクト別、またはコストセンター別にコストを集計するには、IAM プリンシパルにタグを追加します。タグは次の2つの方法で請求データに反映されます。 プリンシパルタグ は、IAM ユーザーまたはロールに直接アタッチされます。一度設定すれば、そのプリンシパルからのすべてのリクエストに適用されます。 セッションタグ は、ユーザーやアプリケーションが IAM ロールを引き受けて一時的な認証情報を取得する際に動的に渡されるか、ID プロバイダーのアサーションに埋め込まれます。詳細については、「 Pass session tags in AWS STS 」を参照してください。 AWS Billing で コスト配分タグ として有効化すると、両方のタグタイプが CUR 2.0 の tags 列に iamPrincipal/ プレフィックス付きで表示されます。以下に例を示します。 Bedrock の呼び出し方法 line_item_iam_principal tags AWS IAM ユーザー …user/alice {“iamPrincipal/team”:”ds”} AWS IAM ロール …assumed-role/AppRole/session {“iamPrincipal/project”:”chatbot”} フェデレーテッドユーザー …assumed-role/Role/user@acme.org {“iamPrincipal/team”:”eng”} コスト配分戦略の構築に関する詳細なガイダンスについては、「 Best Practices for Tagging AWS Resources 」を参照してください。 シナリオ別クイックスタート セットアップ方法は、ユーザーやアプリケーションが Amazon Bedrock をどのように呼び出すかによって異なります。以下の表は、各アクセスパターンにおいて CUR 2.0 で利用可能な紐付け情報と、タグベースの集計のために設定すべき内容をまとめたものです。 セットアップ CUR 2.0 での紐付け情報 タグによる集計および Cost Explorer のための設定方法 シナリオ IAM ユーザーまたは API キーを使用する開発者 各ユーザーの ARN が CUR 2.0 に表示される IAM ユーザーにタグをアタッチする 1 IAM ロールを使用するアプリケーション 各ロールの ARN が CUR 2.0 に表示される IAM ロールにタグをアタッチする 2 IdP を通じて認証するユーザー ARN 内のセッション名でユーザーを識別 IdP からセッション名とタグを渡す 3 Bedrock にプロキシする LLM ゲートウェイ ゲートウェイのロールのみ表示される (全ユーザーが単一の ID) ユーザーごとに AssumeRole でセッション名とタグを追加する 4 注: シナリオ 1～3 では、CUR 2.0 の line_item_iam_principal 列により、呼び出し元ごとのアイデンティティの紐付け情報が得られます。タグが必要になるのは、カスタムディメンション (チーム、コストセンター、テナント) で集計したい場合や、Cost Explorer で視覚的な分析やアラートを利用したい場合のみです。シナリオ 4 では、ユーザーレベルの紐付け情報を得るために、ユーザーごとのセッション管理が必要です。これがない場合、すべてのトラフィックがゲートウェイの単一ロールに紐付けられます。 タグを追加した後、AWS Billing コンソールまたは UpdateCostAllocationTagsStatus API で コスト配分タグを有効化 してください。タグは 24～48 時間以内に Cost Explorer と CUR 2.0 に反映されます。 以降のセクションでは、いくつかの一般的なシナリオを解説します。 シナリオ 1: IAM ユーザーと API キーによるユーザーごとの追跡 ユースケース: 個々の開発者が IAM ユーザーの認証情報や Amazon Bedrock API キーを使用する、小規模チーム、開発環境、または迅速なプロトタイピングを行う場面。 仕組み: 各チームメンバーは長期認証情報を持つ専用の IAM ユーザーを持っています。例えば user-1 や user-2 が Amazon Bedrock を呼び出すと、Amazon Bedrock は認証時にその IAM ユーザーの Amazon Resource Name (ARN) を自動的に記録します。CUR 2.0 では、誰がいくら使っているかを確認できます。 チーム別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えばデータサイエンスチームのメンバー全体の合計支出を確認したい場合 — IAM ユーザーにタグをアタッチします。タグは IAM コンソール、AWS Command Line Interface (AWS CLI)、または AWS API で追加できます。以下の例では AWS CLI を使用しています。 # データサイエンスチームのユーザーにタグを付ける aws iam tag-user \ --user-name user-1 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" aws iam tag-user \ --user-name user-2 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" CUR 2.0 に表示される内容: Cost and Usage Report には個々のユーザー ID とそのタグの両方が記録されるため、以下の例に示すように、2 つのディメンションで分析を行うことができます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-input-tokens $0.0693 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-output-tokens $0.2145 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-input-tokens $0.1980 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-output-tokens $0.9900 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} line_item_usage_type 列にはリージョン、モデル、トークンの方向 (入力と出力) がエンコードされているため、「user-1 が Sonnet の入力トークンと出力トークンにそれぞれいくら使ったか？」や「誰が Opus を使っていて、誰が Sonnet を使っているか？」といった質問に答えることができます。 このデータから、いくつかの方法でコストを分析できます: ユーザー別: line_item_iam_principal でフィルタリングすると、各ユーザーの正確な支出額を確認できます。ヘビーユーザーの特定や、個人の実験コストの追跡に役立ちます。 モデル別: line_item_usage_type でフィルタリングすると、モデルごとの支出を比較できます。例えば、誰が Opus のコストを押し上げていて、誰が Sonnet を使っているかがわかります。 チーム別: iamPrincipal/team でグループ化すると、データサイエンスチームのメンバー全体の合計支出を確認できます。部門別のチャージバックに役立ちます。 このアプローチは、ユーザー数が管理可能な範囲にあり、最もシンプルなセットアップで済ませたい場合に最適です。各ユーザーの認証情報によって請求データ上で直接本人を識別することが可能になり、タグを使えばコストをより上位のディメンションにまとめることもできます。 Amazon Bedrock API キーの使用: Amazon Bedrock は、他の AI プロバイダーと同様のシンプルな認証体験を提供する API キーもサポートしています。 API キー は IAM プリンシパルに関連付けられています。API キーで行われたリクエストは対応する IAM アイデンティティに紐付けられるため、同様に line_item_iam_principal およびタグベースの紐付けがそのまま適用されます。つまり、開発者に API キーを配布したり、アプリケーションに埋め込んだりしている組織でも、コストを元の IAM ユーザーやロールまで追跡できます。 シナリオ 2: IAM ロールによるアプリケーションごとの追跡 ユースケース: (人間ではなく) アプリケーションが Amazon Bedrock を呼び出す本番用ワークロードで、プロジェクトやサービスごとにコストを追跡したい場合。 仕組み: 例えば、ドキュメント処理サービス (app-1) とチャットサービス (app-2) という 2 つのバックエンドアプリケーションがあるとします。各アプリケーションはコンピューティングインフラストラクチャ (Amazon EC2、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) など) 上で動作し、専用の IAM ロールを引き受けて Amazon Bedrock を呼び出します。いずれかのアプリケーションが Amazon Bedrock を呼び出すと、引き受けたロールの ARN が自動的に記録されます。この紐付け情報は CUR 2.0 レポートに反映され、アプリケーションごとのコスト可視性が得られます。 line_item_iam_principal でフィルタリングすると、ロール名が含まれているため、アプリケーションごとの合計支出を確認できます。また、 line_item_usage_type でフィルタリングすると、サービス間でのモデル使用状況を比較できます。タグの使用は任意です。アプリケーションがリクエストやバッチジョブごとに一意のセッション名を生成する場合は、さらに細かいレベルでコストを追跡できます。 プロジェクト別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えば DocFlow と ChatBackend の合計支出を比較したい場合 — IAM ロールにタグをアタッチします。 # ドキュメント処理ロールにタグを付ける aws iam tag-role \ --role-name Role-1 \ --tags Key=project,Value="DocFlow" Key=cost-center,Value="12345" # チャットサービスロールにタグを付ける aws iam tag-role \ --role-name Role-2 \ --tags Key=project,Value="ChatBackend" Key=cost-center,Value="12345" app-1 が Role-1 を引き受けて Amazon Bedrock を呼び出すと、リクエストは引き受けたロールのセッションに紐付けられます。ロールのタグは自動的に請求データに反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal には、以下の例に示すように、セッション名を含む引き受けたロールの完全な ARN が表示されます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Sonnet-input-tokens $0.0330 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Opus-output-tokens $0.1650 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-input-tokens $0.0810 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-output-tokens $0.0500 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} これにより、複数の方法で分析できます。 ロールでフィルタリング: ARN のロール名部分を使って、アプリケーションごとの合計支出を確認できます。 セッションでフィルタリング: セッション名を使って、リクエストやバッチジョブごとのコストを追跡できます。 プロジェクトで集計: iamPrincipal/project でグループ化して、DocFlow と ChatBackend のコストを比較できます。 コストセンターで集計: iamPrincipal/cost-center でグループ化して、同じチームが所有するアプリケーション全体の合計支出を確認できます。 このアプローチは、各サービスが独自の IAM ロールを持つマイクロサービスアーキテクチャに最適です。これはセキュリティのベストプラクティスであると同時に、コスト配分のメカニズムとしても機能します。 シナリオ 3: フェデレーテッド認証によるユーザーごとの追跡 ユースケース: ユーザーが企業の ID プロバイダー (Auth0、Okta、Azure AD、Amazon Cognito) を通じて認証し、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) フェデレーション経由で AWS にアクセスするエンタープライズ環境。 仕組み: ユーザーは ID プロバイダー (IdP) を通じて認証し、共有の IAM ロールを引き受けます。ユーザーごとの紐付けは 2 つのメカニズムによって得られます。 セッション名 (引き受けたロールの ARN に埋め込まれたユーザー ID) と セッションタグ (IdP から渡されるチーム、コストセンターなど) です。1 つの IAM ロールがすべてのユーザーに対応するため、ユーザーごとの IAM リソースを管理する必要はありません。 セッション名 (緑色でハイライト) が line_item_iam_principal に表示される内容です: arn:aws:sts::123456789012:assumed-role/BedrockRole/ user-1@acme.org 図 1. フェデレーテッド認証シナリオにおける ID フロー OIDC フェデレーション (Auth0、Cognito、Okta OIDC) の場合: IdP を IAM OIDC プロバイダーとして登録し、 sts:AssumeRoleWithWebIdentity と sts:TagSession を許可する信頼ポリシーを持つロールを作成し、IdP が ID トークンに https://aws.amazon.com/tags クレームを挿入するよう設定します。AWS Security Token Service (AWS STS) はこのクレームからセッションタグを自動的に抽出します。呼び出し元のアプリケーションは、 AssumeRoleWithWebIdentity を呼び出す際に –role-session-name をユーザーのメールアドレス (または別の識別子) に設定します。 SAML フェデレーション (Okta、Azure AD、Ping、ADFS) の場合: IdP で SAML 属性マッピングを設定し、アサーションに RoleSessionName (例: ユーザーのメールアドレス) と PrincipalTag:* 属性 (チーム、コストセンター) を渡すようにします。セッション名とタグはどちらも署名済みアサーションに埋め込まれるため、呼び出し元のアプリケーションが個別に設定する必要はありません。IAM ロールには sts:AssumeRoleWithSAML と sts:TagSession の権限が必要です。 どちらの場合も、タグはアサーションまたはトークン内に暗号的に署名されているため、ユーザーが自身のコスト配分情報を改ざんすることはできません。 CUR 2.0 に表示される内容:&nbsp; line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-input-tokens $0.283 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-output-tokens $0.990 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-input-tokens $0.165 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-output-tokens $0.264 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} この例では、user-1 が Opus を、user-2 が Sonnet を使用しています。両者は同じ IAM ロールを共有していますが、それぞれ個別に識別できます。 iamPrincipal/team でグループ化すれば部門別のチャージバックが可能になり、セッション名を抽出すればユーザーごとの分析ができます。 シナリオ 4: LLM ゲートウェイを介したユーザーごとの追跡 ユースケース: ユーザーと Amazon Bedrock の間に大規模言語モデル (LLM) ゲートウェイまたはプロキシ (LiteLLM、カスタム API ゲートウェイ、Kong、Envoy、または自社開発サービス) を配置している組織。 問題点: ゲートウェイは独自のレイヤーでユーザーを認証した後、ゲートウェイのコンピューティングにアタッチされた単一の IAM ロールを使用して Amazon Bedrock を呼び出します。追加の対応を行わない場合、すべての Amazon Bedrock コールが CUR 2.0 上で単一のアイデンティティとして表示され、ユーザーごとやテナントごとの可視性は得られません。 解決策: ユーザーごとのセッション管理 ゲートウェイは各ユーザーに対して Amazon Bedrock スコープのロールに対し AssumeRole を呼び出し、ユーザーの ID を --role-session-name として、ユーザーの属性 (チーム、テナント、コストセンター) を --tags として渡します。生成されたユーザーごとの認証情報はキャッシュされ (最大 1 時間有効)、同じユーザーからの後続リクエストに再利用されます。これには 2 つの IAM ロールが必要です。1 つ目はゲートウェイ実行ロールで、 sts:AssumeRole と sts:TagSession のアクセス許可を持ちます。2 つ目は Amazon Bedrock 呼び出しロールで、ゲートウェイロールから信頼され、Amazon Bedrock API にスコープが限定されています。 図 2. LLM ゲートウェイシナリオにおける ID フロー 実装上の主な考慮事項: セッションのキャッシュ : AssumeRole によるレイテンシーの追加はわずかです。TTL (Time to Live) を 1 時間に設定すれば、STS の呼び出しはリクエストごとではなく、ユーザーごとに 1 時間に 1 回で済みます。 キャッシュサイズは 総ユーザー数ではなく、 同時接続ユーザー数に比例します (同時接続ユーザーが 500 であれば、キャッシュされるセッションも約 500)。 STS のレート制限 はデフォルトでアカウントあたり毎秒 500 AssumeRole コールです。高スループットのゲートウェイの場合は引き上げをリクエストしてください。 セッションタグは一度設定するとそのセッション内では変更できません 。タグの変更は次回のセッション作成時に反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-input-tokens $0.081 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-output-tokens $0.163 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-input-tokens $0.526 {“iamPrincipal/tenant”:”acme-corp”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-output-tokens $0.925 {“iamPrincipal/tenant”:”acme-corp”} ゲートウェイでユーザーごとのセッション管理を行わない場合、ゲートウェイのトラフィックはすべてゲートウェイの単一ロールに紐付けられます。セッション管理を追加することが、ユーザーごとおよびテナントごとの紐付けを実現するための鍵となります。 シナリオの選び方 IAM ユーザーまたは Amazon Bedrock API キーを使用する開発者 → シナリオ 1 AWS コンピューティング上で IAM ロールを使用するアプリケーション/サービス → シナリオ 2 IdP (Auth0、Okta、Azure AD) を通じて認証するユーザー → シナリオ 3 Amazon Bedrock の前段に配置された LLM ゲートウェイまたはプロキシ → シナリオ 4 マルチテナント SaaS を構築する場合 → シナリオ 4 (テナント ID をセッション名 + セッションタグとして使用) Claude Code ワークロード → シナリオ 3 AWS Billing でのタグの有効化 AWS Billing コンソール を開きます コスト配分タグ に移動します タグが少なくとも 1 つの Amazon Bedrock リクエストに使用された後 (最大 24 時間かかります)、AWS マネジメントコンソールの IAM カテゴリの下にそのタグが表示されます 有効化したいタグを選択し、「 有効化 (Activate) 」を選択します CUR 2.0 の場合は、データエクスポート設定の作成時または更新時に IAM プリンシパルを有効にする必要もあります。 Cost Explorer でのコスト表示 有効化すると、IAM タグが Cost Explorer の「 タグ (Tags) 」ドロップダウンの IAM カテゴリの下に表示されます。以下のことが可能です。 team = data-science でフィルタリングして、そのチームの Amazon Bedrock の合計支出を確認する tenant でグループ化して、顧客間のコストを比較する ディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答える 利用を開始するには Amazon Bedrock の新しいコスト配分機能は、追加費用なしで商用リージョンで利用可能です。開始するには以下の手順に従ってください。 アクセスパターンを特定する。 開発者が IAM ユーザーや API キーで Amazon Bedrock を直接呼び出しているか (シナリオ 1)？ アプリケーションが IAM ロールを使用しているか (シナリオ 2)？ ユーザーが ID プロバイダーを通じて認証しているか (シナリオ 3)？ それともトラフィックが LLM ゲートウェイを経由しているか (シナリオ 4)？ CUR 2.0 で IAM プリンシパルデータを有効にする。 データエクスポート設定を更新して、IAM プリンシパルデータを含めるようにします。 集計が必要な場合や Cost Explorer でフィルタリングしたい場合はタグを追加する。 IAM ユーザーまたはロールにタグをアタッチするか、IdP からセッション名とタグを渡すよう設定するか、ゲートウェイにユーザーごとのセッション管理を追加します。その後、AWS Billing コンソールでコスト配分タグを有効化します。 分析する。 有効化から 24～48 時間以内に、タグが Cost Explorer と CUR 2.0 に表示されます。チームでフィルタリング、プロジェクトでグループ化、またはディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答えることができます。 まとめ 推論に誰がいくら使っているかを把握することは、チャージバック、予測、最適化の第一歩です。Amazon Bedrock のきめ細かなコスト配分を使えば、既に導入済みの IAM アイデンティティとタグのメカニズムを活用して、推論リクエストを特定のユーザー、アプリケーション、またはテナントまで追跡できます。チームが IAM 認証情報で Amazon Bedrock を直接呼び出す場合でも、フェデレーテッド認証を経由する場合でも、LLM ゲートウェイを介する場合でも、AWS CUR 2.0 と AWS Cost Explorer が必要な可視性を追加費用なしで提供します。 著者について Ba’Carri Johnson は Amazon Bedrock チームのシニアテクニカルプロダクトマネージャーで、AWS AI のコスト管理とガバナンスを専門としています。AI インフラストラクチャ、コンピューターサイエンス、戦略のバックグラウンドを持ち、プロダクトイノベーションと組織が責任を持って AI をスケールさせるための支援に取り組んでいます。余暇には旅行やアウトドアを楽しんでいます。 Vadim Omeltchenko は Amazon Bedrock の Go-to-Market 担当シニアソリューションアーキテクトです。AWS のお客様がクラウドでイノベーションを実現するための支援を推進しています。 Ajit Mahareddy はプロダクトおよび Go-To-Market (GTM) の経験豊富なリーダーで、プロダクトマネジメント、エンジニアリング、Go-to-Market の分野で 20 年以上の経験を持っています。現在の役職に就く前は、Uber、Turing、eHealth などの大手テクノロジー企業で AI/ML プロダクトのプロダクトマネジメントを率いていました。生成 AI 技術の発展と、生成 AI による実社会へのインパクトの創出に取り組んでいます。 Sofian Hamiti は 12 年以上にわたり AI ソリューションの構築に携わってきたテクノロジーリーダーで、顧客の成果を最大化するハイパフォーマンスチームを率いてきました。多様な人材がグローバルなインパクトを生み出し、キャリア目標を達成できるよう支援することに取り組んでいます。 <!-- '"` --> 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

目次 はじめに 前提：私たちのチームの開発の進め方 Working Backwardsに着目した理由 「機能リリース概要」という形にアレンジした 課題は、文章を書く手間 AIで上流工程を効率化する まとめ はじめに 楽楽勤怠の給与計算オプションのプロダクトマネジメント / プロダクトオーナーをしている @k0First です。 機能の仕様を決める際、事業部との認識合わせに何度もやり取りが発生したり、開発に渡した後で仕様の意図を確認されたりすることがあります。原因を振り返ると、多くの場合、最初に作成するドキュメントで伝えるべき情報が伝えきれていないことに行き着きます。 この記事では、Amazonの「Working Backwards」という考え方を参考に、自分たちの開発体制に合わせてドキュメントの作り方を見直し、AIを使って作成を効率化した取り組みを紹介します。 前提：私たちのチームの開発の進め方 会社によって開発の進め方は異なるため、先に前提を整理しておきます。 給与計算オプションでは、機能のロードマップを事前に企画課と協議して決めています。そのうえで、各機能の仕様についてはプロダクトオーナーがドキュメントを作成し、事業部と協議しながら確定させていく流れです。 デザイナーはこのドキュメントをもとにデザインを作成し、バックエンド・フロントエンドのエンジニアは、できあがったデザインとドキュメントをもとに開発を進めます。 つまり、プロダクトオーナーが最初に作成するドキュメントが、事業部との認識合わせの土台になると同時に、デザインや開発の起点にもなります。このドキュメントの内容が不十分だと、その影響は後工程にそのまま伝わることになります。 Working Backwardsに着目した理由 Working Backwardsは、Amazonが新しいサービスや機能を企画する際に用いている手法です。開発に着手する前に、その機能が完成した後を想定した顧客向けのプレスリリースをまず書き、あわせてQ&amp;A（FAQ）をまとめます。この一式はPRFAQ（Press Release and Frequently Asked Questions）と呼ばれています。 開発企画は、放っておくと「今の仕組みや技術でできること」を起点に積み上げがちです。その積み上げ方だと、できあがってから「これは誰の、どんな課題を解決しているのか」が曖昧なまま進んでしまうことが起こり得ます。Working Backwardsは、完成後の顧客向け発表文を先に書かせることで、企画の起点を強制的に顧客の課題や体験に戻す仕組みだと理解しています。プレスリリースという体裁上、専門用語や社内事情に頼った説明ができず、平易な言葉で価値を言い切る必要がある点も、考えを整理するうえで機能しているようです。 この考え方は、私たちが抱えていた課題とも重なる部分がありました。事業部との認識合わせに時間がかかるのも、開発から仕様確認が入るのも、突き詰めると「その機能が何を解決するのか」「仕様の意図は何か」が、最初のドキュメントの時点で言い切れていないことが原因だったためです。 ただし、そのままの形式を持ち込むことはできませんでした。Amazonのプレスリリースは顧客向けの発表文であるのに対し、私たちが作成するドキュメントの読者は事業部や開発メンバーだからです。 そこで、「価値と仕様を先に言語化する」という発想だけを取り入れ、形式は自分たちの読者に合わせて作り直すことにしました。 ※Working Backwardsについては、こちらを参考にしてください。 🔗 参考リンク アマゾンの最強の働き方――Working Backwards （コリン・ブライアー、ビル・カー著） プレスリリース先行で企画を作るAmazon流のやり方【企画の道具箱 #7】 「機能リリース概要」という形にアレンジした 作成したのは、「機能リリース概要」というドキュメントです。 顧客向けのプレスリリースではなく、事業部向けのプレスリリースに近い形式にしました。前半には「どのような機能を出すのか」「その機能が顧客のどのような課題を解決するのか」を記載し、後半には事業部・開発メンバー向けに詳細な仕様を記載します。 さらに、このドキュメントを読んだ事業部や開発メンバーから想定される質問を、Q&amp;A形式でまとめました。1機能につき1ドキュメントとして、機能概要とQ&amp;Aをセットで扱う運用にしています。 この形式にしたことで、事業部との協議は、ゼロから説明するものではなく、すでに言語化された内容をもとに認識をすり合わせるものに変わりました。 課題は、文章を書く手間 一方で、この機能リリース概要には作成コストの課題がありました。 1機能1ドキュメントで、機能概要・詳細仕様・Q&amp;Aまでを揃えるとなると、書く文章量は少なくありません。事業部や開発メンバーに伝わる内容にするには、言葉の選び方にも配慮が必要です。 その結果、仕様の検討そのものよりも、それを文章に落とし込む作業に時間がかかる状態になっていました。上流工程の進め方を変えても、この部分がボトルネックになっては意味がありません。 AIで上流工程を効率化する この課題に対して、次のような流れを取り入れました。 機能リリース概要のテンプレートを、あらかじめ作成しておく テンプレートに沿って、ドラフトを作成する あらかじめ定義したブラッシュアップの観点（Skill）をもとに、AIでブラッシュアップする 完成した機能リリース概要をもとに、Q&amp;AをAIで自動作成する ポイントは、最初のドラフトは自分で書くことです。給与計算オプションは法令や計算ロジックが絡み、仕様の正確性が求められる領域のため、何を書くべきかという判断はプロダクトオーナーが担い、AIには文章を伝わりやすく整える役割を任せています。 ドラフトの作り方自体は、特別なことはしていません。テンプレートの各項目を、まず箇条書きでとりあえず埋めていきます。伝えたい内容がすでに固まっている項目については、箇条書きを飛ばして最初から文章で書いてしまうこともあります。AIに読み込ませることを意識した書き方の工夫は、特にしていません。箇条書きでも文章でも、その時点で自分が把握している情報をテンプレートの構造に沿って書き出しておく、というだけです。 ただし、入力値や出力値があらかじめ決まっている項目については、箇条書きの段階で書き切るようにしています。たとえば給与業務であれば、給与振込FBデータのように対外的に出力する項目の内容は決まっているので、ドラフトの段階で該当する値をすべて列挙しておきます。ここを曖昧にしたまま先に進めると、後工程で認識のズレが起きやすい部分だからです。構造さえテンプレートに沿っていれば、その後のブラッシュアップはSkill側の指示でカバーできるようになっています。 社内には、仕様が固まりきらない案件で、 最初からAIに書かせて書き直させるという進め方をしたチームの事例 もあります。書き直しが前提の、失敗コストが低い領域だからこそ成立する進め方だと考えています。給与計算オプションのように正確性が優先される領域では、人が骨格を作り、AIには磨きを任せる方が適していると判断しました。 ブラッシュアップについては、都度チャットで指示を出すのではなく、どのような観点で直すかをあらかじめSkillとして定義しています。「事業部が読んでもわかる粒度になっているか」「前半と後半で情報の重複や矛盾がないか」といった観点をSkill側に持たせておき、実際の作業ではGoogleドキュメントのリンクを貼り付けるだけで、その観点に沿ったブラッシュアップが行われる形にしています。毎回同じ指示を書き直す手間がなくなり、ブラッシュアップの精度も安定するようになりました。 機能リリース概要が完成した後は、その内容をもとにQ&amp;Aの作成もAIに任せます。ドキュメントを読み込ませたうえで、事業部や開発メンバーが疑問に思いそうな点を洗い出してもらう形です。自分だけで質問を想定すると視点が偏りやすいため、この工程は特に効果を感じています。 この仕組みは、完成後の修正でも活きています。開発中に仕様変更が発生した場合、該当箇所を書き換えたうえで同じブラッシュアップのSkillを呼び出せば、テンプレートの構造や表現ルールに沿った形にすぐ整え直せます。ドキュメントの体裁を保つための調整を都度自分でやり直す必要がなく、仕様変更への対応スピードにもつながっています。 参考までに、ブラッシュアップのSkillに定義している指示の一部を抜粋します。実際にはもっと長い指示書ですが、骨子は次のようなものです。 あなたは、勤怠管理・給与計算システムの「機能リリース概要」をブラッシュアップする編集アシスタントです。 読者は、事業部（営業・カスタマーサクセス・サポート・導入支援）と開発部（バックエンド・フロントエンド・デザイナー・QA・保守運用）を想定します。 # 最重要ルール - 「機能要件（Must / Better）」は、必ず機能単位でテンプレート構造（概要・入力・出力・処理・業務ルール・エラー・備考）を維持する - テンプレート構造を独自変更したり、機能をまとめたりしない # 基本方針 - 社内仕様書として自然な敬体で記載する - 冗長な説明は避ける - 元資料の内容を尊重する - 指定範囲外を大きく変更しない - 不明点は断定しない - 読みやすさよりテンプレート準拠を優先する # 出力形式 - Markdownで出力し、Googleドキュメントに貼りやすい形にする - 「本文タブ用」「Q&amp;Aタブ用」の順にコードブロックで出力する 読者の想定、テンプレート構造の維持、出力形式まで指示に落とし込んでおくことで、Googleドキュメントのリンクを貼るだけでも、毎回一定の品質でブラッシュアップされるようにしています。 この進め方に変えてから、ドキュメント作成にかかる時間は短くなりました。事業部との協議でも、機能の概要説明に使っていた時間を、認識のすり合わせそのものに使えるようになっています。 一方で、AIに任せられない部分もあります。何を書くべきか、どこまでを今回のスコープとするかという判断は、ドメイン知識をもとに人が行う必要があります。AIに任せるのは、内容を伝わる形に整える工程と、そこから疑問点を洗い出す工程で、判断そのものは自分たちで行う。この役割分担が、現時点では最も機能しています。 まとめ Working Backwardsをそのまま自分たちの開発に当てはめることは難しいと感じました。読者もドメインも異なるためです。 一方で、「価値と仕様を、開発に着手する前に言語化しておく」という考え方自体には、取り入れる価値がありました。形式は自分たちの読者に合わせて作り直し、「機能リリース概要」というドキュメントに落とし込みました。 そのドキュメント作成にかかる手間は、AIを活用することで軽減できました。ここでも、AIに何を任せ、何を自分たちで行うかの線引きは、扱っているドメインの特性に合わせて考える必要がありました。 Working Backwardsも、AIの活用も、そのまま取り入れるのではなく、自分たちの体制やドメインに合わせて調整していく。今回の取り組みを通じて、そのことを改めて確認できました。