翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# よくある質問
このセクションでは、Amazon Bedrock のコスト帰属メカニズムの選択と組み合わせに関する一般的な質問に回答します。
## メソッドの選択
**Q: ユーザーごと、プロンプトごとの属性が必要です。選択内容**
A: 請求ベースのメソッドではなく、[モデル呼び出しログ](model-invocation-logging.md)を使用します。ネイティブメソッド ([IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)、[プロジェクト](cost-mgmt-projects.md)、[アプリケーション推論プロファイル](cost-mgmt-application-inference-profiles.md)、) は、AWSCost Explorer と CUR で集計されたドル[WorkSpaces](cost-mgmt-workspaces.md)のみを生成するため、リクエストごとの行は生成されません。プロンプトごとのビューはログにのみ存在し、ユーザーは 2 つの場所のいずれかから取得できます。
最初のオプションは、呼び出しごとに request-metadata タグを設定することです。
```
client.converse(
modelId=...,
messages=[...],
requestMetadata={"user": "alice@example.com"},
)
```
2 つ目は、自動キャプチャされた に依存することです。これは`identity.arn`、発信者がユーザーごとの で IAM ロールを引き受ける場合に機能します`RoleSessionName`。ログに記録されたトークン数からコストを計算します。ユーザーあたりの請求書精度ドルも必要な場合は、 [IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)と一緒に実行します。
**Q: 特定のシナリオがあります。どの方法を使用すればよいですか?**
A: 次の表を使用して、シナリオをメソッドに一致させます。
| シナリオ | 使用アイテム |
| --- | --- |
| 毎月の請求には、各チームの支出が必要です。 | [IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md) (チーム別のタグ）、またはタグ付けされた [プロジェクト](cost-mgmt-projects.md) または [アプリケーション推論プロファイル](cost-mgmt-application-inference-profiles.md) |
| 機能ごとに、個々のプロンプトあたりのコストが必要です。 | [リクエストごとのメタデータのタグ付け](cost-mgmt-request-metadata.md) [モデル呼び出しログ](model-invocation-logging.md)を使用する |
| 多くのモデルを実行し、アプリケーションごとに 1 つのコストバケットが必要です。 | [プロジェクト](cost-mgmt-projects.md) on bedrock-mantle — 1 つのプロジェクトで多くのモデルにまたがることができます |
| InvokeModel または Converse で、アプリケーションあたりのドルが必要です。 | [アプリケーション推論プロファイル](cost-mgmt-application-inference-profiles.md) |
| Amazon Bedrock の前には、多くのユーザーにサービスを提供するゲートウェイがあります。 | ユーザーあたりのsts:AssumeRole請求額とプロンプト[リクエストごとのメタデータのタグ付け](cost-mgmt-request-metadata.md)ごとの詳細 |
**Q: プロジェクトまたはアプリケーション推論プロファイルを使用する必要がありますか?**
A: どちらもAWSCost Explorer と CUR で集計されたドルを提供します。エンドポイントとスケールで選択します。
+ [アプリケーション推論プロファイル](cost-mgmt-application-inference-profiles.md) は`bedrock-runtime`エンドポイント (InvokeModel と Converse) で動作しますが、モデル固有です。モデルごとに 1 つのプロファイルを作成するため、モデルやチームを追加するとリソース数が増加します。
+ [プロジェクト](cost-mgmt-projects.md) は`bedrock-mantle`エンドポイント (応答とチャットの完了) で作業し、1 つのプロジェクトが多くのモデルにまたがることができます。ワークロードごとに多くのモデルがある場合、スケールは向上しますが、マントルのみになります。
ユーザーごとの詳細には、いずれか 1 つ[IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)と一緒に を使用します。
## コストと使用状況レポートの質問
**Q: コスト属性のクラシック CUR と CUR 2.0 の違いは何ですか?**
A: [プロジェクト](cost-mgmt-projects.md)、、[アプリケーション推論プロファイル](cost-mgmt-application-inference-profiles.md)、IAM プリンシパルタグからアクティブ化されたコスト配分タグは[WorkSpaces](cost-mgmt-workspaces.md)、従来の CUR と CUR 2.0 の両方に表示されます。違いは、 がタグ付けなしで[IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)機能する自動発信者 ID 列です。その列 — 「呼び出しを行ったユーザー」データは、発信者 ID オプションが選択された CUR 2.0 (AWSデータエクスポート) エクスポートにのみ存在します。明細項目データにユーザーごとのネイティブ属性が必要な場合は、CUR 2.0 が必要です。
**Q: 個々のプロンプトのコストはAWSCost Explorer または CUR で確認できますか?**
A: いいえ。従来の CUR と CUR 2.0 の両方が 1 時間または 1 日の使用タイプごとにコストを集計し、どちらも明細項目にリクエストごとの識別子を持ちません。プロンプトごとの詳細は、[モデル呼び出しログ](model-invocation-logging.md)にのみ存在します。調整のために、プロンプトごとのコストではなく、モデルと使用状況タイプの粒度でログを CUR に結合します。
**Q: コストは CUR にありますが、タグとトークンはログにあります。組み合わせるにはどうすればよいですか?**
A: パターンは 2 つあります。請求書精度の合計については、モデル/使用量タイプ/日単位の CUR にログを結合します。プロンプトごとのコストについては、ログに記録されたトークン数とトークンごとの発行レートから計算します。次の CloudWatch Logs Insights クエリは、計算にフィードするユーザーごと、モデルごとのトークンの合計を生成します。
```
fields requestMetadata.user as user, modelId,
input.inputTokenCount as inTokens,
output.outputTokenCount as outTokens
| stats sum(inTokens) as totalInput,
sum(outTokens) as totalOutput,
count() as calls
by user, modelId
```
計算された数値は推定値です。モデル化しない限り、割引、コミットメント、バッチ料金、無料利用枠、プロビジョニングされたスループットは反映されません。詳細については、「[ログからのコストの取得](cost-mgmt-request-metadata.md#cost-mgmt-request-metadata-getting-cost)」を参照してください。
## メカニズムの違い
**Q: IAM セッションタグとリクエストメタデータの違いは何ですか?**
A: バインドと送信先。セッションタグは に 1 回設定`sts:AssumeRole`され、そのセッションの認証情報を使用して行われた呼び出しごとに一定です。AWSCost Explorer と CUR (従来の CUR と CUR 2.0 の両方) の集計請求データとしてのみ表示されます。リクエストメタデータは呼び出しごとに設定され、リクエストごとに異なり、呼び出しログに記録されます。
ユーザーごと、プロンプトごとの属性については、リクエストメタデータを使用します。ユーザーあたりの請求額については、セッションタグを使用するか、発信者 ID ARN に依存します。
**Q: リクエストメタデータは請求書に表示されますか?**
A: いいえ。リクエストメタデータはコスト配分タグではありません。これは[モデル呼び出しログ](model-invocation-logging.md)にのみ書き込まれ、AWSCost Explorer や CUR には表示されません。運用分析やプロンプトごとの分析に使用し、請求額にはネイティブメソッド ( [IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)や など[プロジェクト](cost-mgmt-projects.md)) を使用します。
## 実装
**Q: 属性は LLM ゲートウェイの背後でどのように機能しますか?**
A: Amazon Bedrock は、ゲートウェイのロールを発信者の ID として記録します。ユーザーレベルの属性を保持するには、ユーザーごとにロールを引き受け、セッションの有効期間の認証情報をキャッシュし、ユーザーをセッションタグ (請求金額) または として `RoleSessionName` (ユーザーがログ`identity.arn`に入るように) 渡します。
```
sts.assume_role(
RoleArn=GATEWAY_ROLE,
RoleSessionName="alice",
Tags=[{"Key": "user", "Value": "alice@example.com"}],
)
```
リクエストごとのAWS STS呼び出しがないプロンプトごとの詳細については、代わりに各呼び出しの[リクエストメタデータ](cost-mgmt-request-metadata.md)でユーザーを設定します。
**Q: すべての呼び出しにタグを付けるように要求できますか?**
A: Amazon Bedrock 側からではありません。リクエストメタデータは呼び出しごとにオプトインされ、Amazon Bedrock はそれを省略する呼び出しを拒否しません。リソースのみを管理するAWSタグポリシーではありません。すべてのリクエストでスタンプする共有クライアントまたは LLM ゲートウェイにタグ付けを適用します。呼び出し元 ID が自動的にキャプチャされるため、常にコールごとのコードがない属性の場合は[IAM プリンシパル属性](cost-mgmt-iam-principal-tracking.md)、 を使用します。
**Q: 各通話で設定するフィールドと自動のフィールドはどれですか?**
A: ログレコードのほとんどすべてが Amazon Bedrock によって自動的にキャプチャされます: `accountId`、`region`、`modelId``requestId`、、`identity.arn`、、入出力トークン数、スキーマメタデータ。呼び出しごとに指定するフィールドは のみです`requestMetadata`。タグ`modelId`として を設定するのではなく、呼び出したモデルまたは推論プロファイルです。