1つのモデル、1つの請求書、そして「誰がいくら使ったか分からない」問題

複数のチームが Amazon Bedrock 経由で同じ基盤モデルを共有しているケースを考えてみます。人事チームは社内規程のQ&Aに、経理チームは財務ドキュメントの分析に、ITチームはインフラのトラブルシューティングに同じモデルを利用しています。ところが請求書を見ると、3チーム分の利用量がたった1行のラインアイテムとして計上されているだけです。

この状態では、経理部門が部署ごとにコストを按分(チャージバック)することも、チーム別の予算を設定することも、どのチームが最もコストを消費しているかを特定することもできません。実運用では非常によくある悩みです。

これを解決するのが Amazon Bedrock の application inference profile です。平たく言えば、基盤モデルをラップしたタグ付け可能なラッパーであり、このプロファイル単位でコストを特定のチームや部署に紐付けられます。さらに AWS のコスト配分タグと組み合わせることで、Cost Explorer 上で部署別の Bedrock コストを独立したラインアイテムとして確認できます。

本記事では、3つの部署用に application inference profile を作成し、タグ付けし、アプリケーションの呼び出しを部署別プロファイルにルーティングし、Cost Explorer で部署別のコスト内訳を確認するまでの流れを解説します。原文の根拠資料は AWS Architecture Blog の該当ポスト を参照してください。

AWS cloud architecture diagram showing Amazon Bedrock inference profiles routing requests from multiple departments to a shared foundation model Development Concept Image

なぜ IAM プリンシパル単位ではなく「プロファイル」なのか

まず前提を整理します。Amazon Bedrock は 呼び出し元の IAM プリンシパル単位でもコストを帰属できます。各チームがそれぞれ別の IAM 認証情報で Bedrock を呼び出す構成なら、この方式はうまく機能します。

しかし本記事のアーキテクチャは異なります。1つのアプリケーションが全部署を代表して単一の IAM ロールで Bedrock を呼び出す構成です。ユーザー個人の識別情報は AWS には渡されません。この構造では、per-caller の帰属ではチーム別の分離は不可能です(ユーザー単位のセッション管理を追加しない限り)。そこで、application inference profile にタグを付けてルーティング単位でコストを帰属させるわけです。

全体の流れ

  1. 部署ごとに application inference profile を1つずつ作成(すべて同じ基盤モデルを指す)
  2. 各プロファイルにコスト配分タグを付与(例: Team=HR)
  3. AWS Billing and Cost Management コンソールで該当タグを有効化
  4. アプリケーションが部署別 inference profile ARN へ呼び出しをルーティングするよう修正
  5. Cost Explorer で部署別のコスト内訳を確認

💡 コストに関する注意: モデルを直接呼び出しても inference profile 経由で呼び出しても per-token の料金は同一です。コスト帰属のための追加課金はありません。

アプリケーションのルーティングコード例 (Python)

ポイントは modelId パラメータに基盤モデル ID ではなく inference profile ARN を渡すだけです。API 呼び出し自体は変わりません。

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

# 部署別 inference profile ARN のマッピング
# ARN 形式: arn:aws:bedrock:region:account-id:application-inference-profile/profile-id
DEPARTMENT_PROFILES = {
    "HR": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/hr-profile-id",
    "Accounting": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/acc-profile-id",
    "IT": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/it-profile-id",
}

def invoke_for_department(department: str, prompt: str) -> str:
    # アプリケーション層でユーザーの部署を識別し、該当プロファイルへルーティング
    profile_arn = DEPARTMENT_PROFILES[department]

    response = bedrock.invoke_model(
        modelId=profile_arn,  # 基盤モデル ID ではなくプロファイル ARN を渡す
        body={
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1024,
            "messages": [{"role": "user", "content": prompt}],
        },
    )
    return response["body"].read().decode("utf-8")

# 使用例
print(invoke_for_department("HR", "社内の有給休暇規程を教えてください"))

IAM ポリシー: プロファイルと基盤モデルの両方に権限が必要

ここでハマりやすいポイントがあります。inference profile 経由で呼び出すには、プロファイルの権限と基盤モデル本体の権限の両方が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
      ]
    }
  ]
}

111122223333 の部分はご自身の AWS アカウント ID に置き換えてください。プロファイル ARN のワイルドカード(*)は、単一のアプリケーションロールが全部署のプロファイルを呼び出せるようにするためのものです。より厳密に制御したい場合は、ワイルドカードを特定のプロファイル ARN に置き換えてください。

Developer configuring application inference profile tags in AWS Bedrock console for team-level cost allocation Software Concept Art

実運用で必ず確認すべきポイント

1. タグは大文字小文字を区別する

Team と team は完全に別のタグです。これが原因で「なぜ Cost Explorer に表示されないのか」と半日溶かすケースは本当に多いです。タグキーはチームの命名規約を先に決めて、一貫して使いましょう。

2. コストデータは即時には反映されない

コスト配分タグを有効化しても、Cost Explorer に反映されるまで 24〜48 時間かかります。チュートリアルを一通り実行してすぐ確認しようとして「失敗した」と焦る方が多いですが、これは正常な挙動です。コーヒーでも飲んで待ちましょう。

3. マルチアカウント環境では payer アカウントで有効化

AWS Organizations で複数アカウントを運用している場合、管理(payer)アカウントで Team コスト配分タグを有効化する必要があります。そうすることでメンバーアカウントのタグ付き使用量が Cost Explorer に集約されます。

4. プロファイル削除は即時影響

inference profile 自体には課金されません。課金されるのは呼び出しのみです。ただし、プロファイルを削除すると、その ARN を使用しているアプリケーションに即座に影響します。 再作成すると新しい ARN が発行されるため、アプリケーション側の参照を更新する必要があります。

5. 大規模プロビジョニングは CloudFormation で

チームが数十個あるなら、コンソールで1つずつ作るのは避けましょう。AWS::Bedrock::ApplicationInferenceProfile CloudFormation リソースで IaC 管理するのが精神衛生上も良いです。

6. 本番環境では Guardrails を併用

inference profile を本番で使用する際は、ユーザー入力の検証に加えて Amazon Bedrock Guardrails で意図しないコンテンツをフィルタリングすることを推奨します。Bedrock API の通信は TLS により転送中暗号化されます。

7. この技術の限界

application inference profile はあくまでコスト帰属のための仕組みであり、アクセス制御やクォータ管理のツールではありません。チーム別のレート制限や使用量上限を強制したい場合は、別途 AWS Budgets、CloudWatch アラーム、あるいはアプリケーション層のロジックが必要です。「プロファイルを作ればチームごとに分離される」と期待してはいけません。

8. 日本の開発現場における適用コンテキスト

日本のエンタープライズや SI 環境では、部署別の IT コスト按分(チャージバック)への要求が非常に強いケースが多く見られます。特にグループ企業が共有する AI プラットフォームを運用している組織では、このパターンがそのまま内部原価計算に直結します。ただし、日本ではタグ命名ポリシーを経理部門と事前に合意しておくことが重要です。後からタグキー名を変更すると過去データとの比較ができなくなるためです。可能であれば Team のようなキーを初期段階で確定し、部署コード体系(例: 事業部コード)とマッピングしておきましょう。

AWS Cost Explorer dashboard displaying per-department Amazon Bedrock costs grouped by Team cost allocation tag Dev Environment Setup

まとめ: 次のステップへの拡張

整理すると、Amazon Bedrock application inference profile + コスト配分タグの組み合わせにより、生成AIコストをチーム単位で分離できます。各部署のコストが Cost Explorer 上で独立したラインアイテムとして表示されるため、経理部門も各チームリーダーも納得できる形になります。

新しい部署を追加したい場合は、タグ付きプロファイルをもう1つ作成するだけです。コストは自動的に別ラインとして表示されます。

さらに一歩進めたい場合、以下を推奨します。

  • AWS Budgets による部署別の支出アラートと上限設定
  • AWS Cost Anomaly Detection による異常支出パターンの検知
  • Amazon CloudWatch による部署別トークン使用量のモニタリング
  • Knowledge Bases (RAG) など上位の Bedrock 機能にも同じタグ付きプロファイル ARN を参照させ、直接のモデル呼び出しを超えた範囲までチーム別帰属を拡張

あわせて読みたい記事

このアーキテクチャは結局のところ、**「共有リソースをどう会計可能にするか」**という古くからの問題に対する AWS の答えです。あなたの組織で Bedrock の利用がすでに複数チームに広がっているなら、今がプロファイルを整理するタイミングです。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。