Jamf、Amazon Bedrock のリアルタイム支出管理を構築しトークノミクス課題に対処

生成 AI の利用コストは、これまで経験したどの経費項目とも性質が異なります。従来のコンピューティングリソースは用意された容量に応じてスケールしますが、AI の利用コストは「行動」に比例して増減します。例えば、一人のエンジニアが高額なモデルに対してエージェント型のコーディングループを実行すれば、数時間でチーム全体が1 週間で使う以上のトークンを消費してしまうのです。

これが「トークノミクス（トークン経済）」の問題です。利用状況は請求書が届くまで見えないため、コスト管理や投資対効果（ROI）の証明が困難になります。AI アクセスを拡大する前に経営陣が求めるのは、3 つの答えです。「1 人あたりの支出はいくらなのか」「エンジニアの生産性を損なわずに上限を設定できるか」「それに見合う生産性向上が見込めるのか」。

76,000 社以上の組織で Apple デバイスの管理とセキュリティを担う信頼されている企業、Jamf はこの課題に直面しました。AI を活用した開発を加速させるため、エンジニアリング部門に対して Amazon Bedrock の利用権限を広範囲に付与しました。その結果、生産性は向上しましたが、同時に AI FinOps（ファイナンス・オペレーション）の必要性も高まりました。すなわち、ユーザーごとの可視性とコスト責任の明確化です。

Jamf は、個人レベルでこの課題を解決する本番環境システムを構築しました。この記事では、AWS Identity and Access Management (IAM) の Customer Managed Policies (CMP)、Amazon Athena を活用したコスト可視化、そしてサーバーレスのAWS Lambda による執行ループを用いて、このアーキテクチャを構築する方法をご紹介します。記事を読み終える頃には、アクティブなセッションを中断させることなく、ニアリアルタイムで階層別支出制限を適用できる、実証済みの運用パターンが手に入るでしょう。これは AI コストガバナンスの機能です。

ソリューション概要

Jamf のソリューションでは、各エンジニアの日次 Amazon Bedrock 利用額を追跡し、予算に近づくと段階的なモデル制限を適用します。例えば、日次予算の 80% に達すると Anthropic Claude Opus へのアクセスを拒否し、100% に達すると Sonnet へのアクセスもブロックします。ただし Anthropic Claude Haiku は制限しないため、エンジニアは低コストモデルを利用して作業を継続できます。制限は数分以内に反映され、再認証は不要で、翌日のリセット時に自動的に解除されます。正当な理由により追加の予算が必要なエンジニアには、文書化された例外申請プロセスを通じて、時間限定での上限引き上げが認められます。

このアーキテクチャは、支出の計測、制限対象者の特定と通知、そして制限の実行という 3 つの課題に対応しています。それぞれの課題には、目的に特化したサーバーレスコンポーネントが担当します。

図 1: Amazon Bedrock のリアルタイム支出管理

全体の流れは以下の通りです。

計測

• 呼び出しとログ記録 — エンジニアが AWS IAM Identity Center（SSO）セッションを通じて Amazon Bedrock を bedrock:InvokeModel で呼び出すと、Amazon Bedrock はその呼び出しを、あなたが設定した Amazon Simple Storage Service（Amazon S3）バケットにログとして記録します。記録される情報には、モデル ID、入力・出力のトークン数、ユーザーIDなどが含まれます。

決定と通知

• 費用計測 — Amazon Athena の view（bedrock_cost_today）がこれらのログを読み取り、公開されているモデル料率にトークン数を乗算することで、ユーザーごとの日次支出を計算します。Athena は生ログに対して直接 queries を実行するため、別途データパイプラインを用意する必要はありません。

適用判断 — AWS Lambda の適用ハンドラーは、Amazon EventBridge のスケジュールによって 15 分ごとに起動されます。このハンドラーは Athena ビューから当日の支出額を読み取り、個別のエンジニアに付与されたカスタム・タイムボックス制限を保持する Amazon DynamoDB の例外テーブルと照合します。

通知 — 同じ適用ハンドラーは、Amazon DynamoDB の状態テーブルから各ユーザーの直前のステータスも読み取ります。支出が新しい閾値を超えた場合、そのティアに対してエンジニアに 1 回限りの Slack DM を送信し、制限が突然やってくることを防ぎます。

適用

• 適用アクション — 閾値を超えたエンジニアそれぞれに対し、Lambda は iam:CreatePolicyVersion API を使用して、対応する CMP の新しいバージョンを公開します。このポリシーは、saml:sub 条件キーを通じて特定のユーザーを対象とします。

• リアルタイム評価 — CMP は IAM の permission set に紐付けられます。エンジニアが次に Amazon Bedrock を呼び出す際、IAM が更新されたポリシーを評価し、再認証なしでリクエストの許可または拒否を行います。

前提条件

このソリューションを展開するには、以下の準備が必要です：

Amazon Bedrock のリアルタイム支出管理を実現するために必要な環境は以下の通りです。

• IAM ロール、カスタマーマネージドポリシー、AWS Lambda 関数、Amazon Athena ワークグループ、Amazon S3 バケット、および Amazon DynamoDB テーブルを作成する権限を持つ AWS アカウント。
• ユーザーに割り当てるために設定したパーミッションセットを備えた AWS IAM Identity Center。
• ログを Amazon S3 バケットへ転送するように設定された Amazon Bedrock の モデル呼び出しログ 機能。
• 適切な認証情報を設定した AWS コマンドラインインターフェース (AWS CLI)。

デプロイ手順

本記事のコードは、https://github.com/aws-samples/sample-bedrock-spend-enforcement から入手できます。全体の流れを要約すると以下のようになります。

ステップ 1: Amazon Athena のコストビュー作成

Amazon Bedrock の呼び出しログは JSON 形式で Amazon S3 に保存されます。まずはログの保存場所に対して Athena テーブルを作成し、トークン数をドル換算するビューを設定します。このビューでは、各モデルの公開されているトークン単価を用いて入力トークンと出力トークンを計算し、ユーザー ID と日付ごとに集計します。

リージョンごとの Amazon Bedrock の料金 に基づき、レート定数を書き換えてください。各モデルファミリーには明示的な価格分岐が必要です。マッピングされていないモデルは、フェイルセーフとして最高ティアで課金されます（0 ドルではありません）。これにより、認識されないモデルが制限を回避できなくなります。関連するアラートを確認し、対象モデルの実際の料金を速やかに追加してください。

ステップ 2: カスタマー管理ポリシーの作成

saml:sub の値で特定された特定のユーザーグループに対して、モデルファミリーの使用を拒否する実行ポリシーを作成します。最初はユーザーリストを空にしておきます。Lambda がランタイム時に新しいポリシーバージョンを公開することで、このリストを自動で埋めていきます。作成したポリシーは IAM 権限セットにアタッチしてください。iam:CreatePolicyVersion を使用してこれらのカスタマー管理ポリシーを更新すると、再プロビジョニングを行わずに即座に変更が反映されます。

ステップ 3: 実行用 Lambda のデプロイとスケジュール設定

実行ハンドラーをデプロイし、Amazon EventBridge を使って 15 分ごとに自動実行されるようにスケジュールを設定します。各実行時、ハンドラーは Athena ビューを照会し、DynamoDB の例外テーブルからデータを読み取り、各ティアごとの制限対象ユーザーリストを計算して、更新された CMP（カスタマー管理ポリシー）バージョンを公開します。

この設計は、構築段階から冪等性を持っています。各実行では、その日の累積支出に基づいて制限対象ユーザーリストを最初から再計算するため、増分変更を適用するわけではありません。ハンドラーを連続して実行しても、あるいは一度実行をスキップしても、追いついた時点では同じ結果が得られます。二重適用されるものも、ロールバックが必要なものもありません。

日次リセットも暗黙的に処理されます。Athena ビューは、選択した基準時区間の 00:00 を起点とするローリングな日次ウィンドウに支出をスコープします。このウィンドウが切り替わると、次の実行で再計算されるリストにはしきい値を超えなくなったユーザーが含まれなくなり、その後の iam:CreatePolicyVersion コールで自動的に CMP による制限が解除されます。解除用の別コードパスを維持する必要も、同期外になるリスクもありません。

ステップ 4：例外ワークフローの追加

大規模な移行や顧客対応、モデル評価などでは、一部のエンジニアがより高い利用制限を正当に必要とする場合があります。ポリシーを手動で編集するのではなく、管理者が時間限定のカスタム制限を一時的に付与できる Slack のスラッシュコマンド（/bedrock-limit）を用意しましょう。このコマンドは、エンジニアのID、引き上げられた制限値、有効期限のタイムスタンプを DynamoDB の例外テーブルに登録します。さらに、誰がいつ許可し、どのチケットに基づいて許可したかという監査証跡も記録されます。

有効期限のタイムスタンプに DynamoDB の Time to Live (TTL) 属性を設定しておけば、例外データは自動的に期限切れで削除されます。次に実行される際、制限適用用の Lambda はアクティブな例外を読み取り、各エンジニアの閾値をそれに応じて調整します。

教訓

本番環境でこのシステムを運用したことで、共有すべきいくつかの教訓が得られました。

• コスト: このユースケースでは、AWS Lambda、DynamoDB、S3 の利用料は数百人のエンジニアに対して月額 10 ドル未満に抑えられました。ただし Amazon Athena は慎重に設計する必要があります。利用料はスキャン範囲と実行頻度に比例して増大するため、インボイスログのスキーマはトークン数や ID/モデルメタデータなど最小限に絞り込み、各実行時に生ログを繰り返しスキャンするのではなく、事前集約されたコストビューを 1 回だけクエリするようにしましょう。

JSON ログでは、選択した列に関わらずすべてのクエリが全バイトをスキャンします。Athena はフィルタを適用する前に各行をデシリアライズする必要があり、同じビューに対して 4 つの異なるフィルタリングされたクエリを実行しても、それぞれ約 11 GB をスキャンしてしまいます。列プルーニングや述語プッシュダウンは、行指向の JSON には効果がありません。解決策として、派生クエリを SELECT ... GROUP BY で統合し、結果をアプリケーション側で分割するか、ログを Parquet のようなカラム指向フォーマットに変換してください。

ガバナンスは採用を制限するのではなく、加速させるものです。戦略的な洞察は一見逆説的に思えますが、ユーザーごとの厳格な上限を設定したことで、リーダーシップ層はアクセスを縮小するどころか、むしろ拡大することに安心感を持つようになりました。支出状況が可視化されたため、Jamf は AI 活用エンジニアの数を自信を持って増やすことが可能になったのです。

常に利用可能なモデルを用意することです。低コストのモデルを常時稼働させておくのは意図的な選択でした。予算の 100% を使用しているエンジニアでも業務は継続できるため、強制措置が生産性を完全に阻害することはありません。

新しいモデルには明示的な価格分岐が必要です。価格マップを運用上の主要な資産として扱い、モデルが有効化されたその瞬間に追加してください。

IAM ポリシーのバージョン制限です。管理ポリシーは最大 5 バージョンまで保持されます。強制処理を行う Lambda は、新しいバージョンを作成する前に最も古いデフォルト以外のバージョンを削除する必要があります。これを怠ると iam:CreatePolicyVersion が失敗します。

Amazon Athena の非同期クエリモデルを考慮してください。Athena のクエリは、即座に結果が返されるのではなく、送信されてからポーリングされます。Lambda ハンドラーでは、まずクエリを開始し、完了するまで待機した後に結果を読み取る必要があります。これに合わせて関数のタイムアウト設定も適切に行ってください。

クリーンアップ

継続的な課金や強制制御を回避するため、作成したリソースはすべて削除してください。

結論

本稿では、Jamf がカスタマー管理ポリシー、Amazon Athena を活用したコストビュー、そしてサーバーレスの AWS Lambda ループを用いて、Amazon Bedrock 上でリアルタイムかつユーザーごとの支出制限を実現する方法を解説しました。生成 AI の導入が拡大する中で成功するのは、「誰がいくら使っているか把握でき、速度を落とさずに上限を設定可能で、その価値を実証できる」という回答を自信を持って出せる組織です。コストガバナンスは、AI への「ノー」ではなく「イエス」を増やすための安全装置なのです。

いよいよ、皆様も探索の段階に入ります。ご不明な点やサポートが必要な場合は、AWS Support や担当の AWS アカウントチームまでお気軽にお問い合わせください。

著者について

Arun Chandapillai

アールンは、ビジネスファーストのクラウド導入戦略を通じて顧客の IT 近代化を加速させることに情熱を注ぐシニアクラウドアーキテクトです。エージェントワークフローから本番環境対応アプリケーションまで、AWS 上で AI および生成 AI ソリューションの構築と展開を専門としています。自動車愛好家であり、積極的な登壇者でもあるアールンは、「与えたものに応じて返ってくる」という信念のもと、社会還元にも力を入れています。

Cami Persson

カミは AWS でシニアアカウントマネージャーを務め、独立系ソフトウェアベンダー（ISV）と連携してクラウド導入と AI の統合を通じて価値創造を推進しています。パートナー企業の収益成長と、大規模なプラットフォームの近代化を加速させることに注力しています。ミネアポリスに拠点を置き、夫と共に暮らしています。

Aditya Mettu

アディティヤは AWS のテクニカルアカウントマネージャーとして、独立系ソフトウェアベンダー（ISV）の顧客をサポートしています。エンジニアリングチームが AWS 上で生成 AI を信頼性高く、かつコスト効果的に運用できるよう支援しており、特に Amazon Bedrock などのサービスにおける AI FinOps（コスト可視化、ガバナンス、最適化）に注力しています。クラウド利用データを実用的なガードレールに変換し、突発的なコスト増を招くことなくチームが AI の導入を拡大できる環境づくりに取り組んでいます。

アンディ・ベルナード

アンディは、クラウドインフラストラクチャ、FinOps（財務運営）、AI 設計の交差点で活動するエンジニアです。エンジニアの邪魔をせず、クリーンにスケールできるシステム構築を専門としています。Jamf がチームの速度を落とさずに安全に AI を導入できるよう支援する、クラウド自動化および生成 AI プラットフォームの開発を担当しています。

アンソニー・ダンハム

アンソニーは、クラウドコストの最適化、自動化、財務ガバナンスに注力する FinOps エンジニアです。金融・経済学とデータサイエンスのバックグラウンドをクラウドエンジニアリングの専門知識と組み合わせ、チームが AWS および生成 AI ワークロードのコストを理解し、管理、最適化できるよう支援しています。

レヴィ・マコーミック

レヴィはエンジニアリング部門のディレクターで、電話サポートやトレーニング、メンタリング、アーキテクチャ設計、アプリケーション設計、顧客対応など、テクノロジー業界で 25 年以上の実績があります。開発者体験の向上とクラウドプラットフォームの活用を情熱的に推進し、すべてのエンジニアが 10 倍の生産性を発揮できる環境づくりに取り組んでいます。