Skip to Content
Docs05. 運用コスト管理
中級cost-managementprompt-caching更新: 2026-10-08この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

コスト管理

この記事の目的

Agent のコストがなぜ事前に読みにくいのかを構造から理解し、計測(タスク単位の単位経済)→ 削減(キャッシュ・履歴圧縮・モデル使い分け)→ 上限(多層の予算ガード) の 3 段階でコストを制御できるようになります。

対象読者

前提知識

本文

概要: なぜ Agent のコストは読みにくいか

単発の LLM 呼び出しと違い、Agent のコストは 3 つの変動要因を持ちます。

  1. ループ回数が入力に依存します — 同じ機能でも、簡単なタスクは 2 ステップ、厄介なタスクは 15 ステップになります
  2. 履歴を毎回再送します — LLM はステートレスなので、ループの各ステップで過去の全履歴を入力として送り直します。ステップが進むほど 1 回あたりの入力が膨らみ、総入力トークンはステップ数に対して二乗的に増えます
  3. 本文以外もトークンです — システムプロンプト・ツール定義・ツール結果がすべて入力トークンとして毎回課金されます。ツール定義が大きい構成では、ユーザーの入力より「固定費」の方が大きいことも珍しくありません

この構造から、Agent のコストは多くの場合出力ではなく入力トークンが支配的です。

詳細: まず計測 — タスク単位の単位経済

削減の前に、どこにコストが掛かっているかを計測します(可観測性とトレーシング のトレースにトークン数を記録するのが前提です)。

  • タスク 1 件あたりのコストを基本単位にします(「API 費用の月額合計」では、原因の特定も価格設定の判断もできません)
  • 平均ではなく分布で見ます。コストは裾の重い分布になりやすく、少数の暴走・迷走セッションが合計を支配していることがよくあります(P95 と最大値を見る)
  • ユーザー・テナント・機能単位で集計できるように、トレースに属性を付けておきます

詳細: 削減の主要手段

手段効くもの注意点
プロンプトキャッシュ毎回再送される固定部分(システムプロンプト・ツール定義)と伸びていく履歴キャッシュは前方一致。固定部分をプロンプトの先頭に集め、可変部分(日時・ユーザー情報)を後ろに置く構造が前提
履歴の圧縮・要約長いセッションの入力膨張圧縮で失った情報による品質劣化とのトレードオフ(メモリと状態管理)
モデルの使い分けすべてのステップに最上位モデルが必要なわけではない(分類・抽出などの部品)品質評価とセットで判断する。安いモデルで成功率が下がれば、再試行と人手対応で総コストは逆に増える
ツール結果の絞り込みツールが返す JSON の不要フィールド取りすぎない設計はツール側の責務(ツール定義の設計)
バッチ処理即時性が不要なオフラインタスク(評価スイートの実行を含む)ベンダーのバッチ API は割引がある代わりに応答が非同期

プロンプトキャッシュ(prompt caching)は Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。と特に相性が良い仕組みです。ループでは「先頭(システムプロンプト・ツール定義・これまでの履歴)は変わらず、末尾に新しいステップが足されていく」ため、各ステップの入力の大部分がキャッシュにヒットします。

設計判断: 上限は 3 層で設計する

コストの上限は 1 か所ではなく、影響範囲の異なる 3 層で掛けます。

層仕組み守るもの
タスク単位最大ステップ数・タスクあたりトークン予算(Agent ループ の停止条件)1 タスクの暴走
ユーザー・テナント単位期間あたりの利用予算・レートリミット特定ユーザーによる占有・悪用
システム全体日次・月次予算のサーキットブレーカ(インシデント対応)請求額の事故

上限に達したときの挙動も設計します。黙って切り捨てるのではなく、「ここまでの結果と、なぜ中断したかを報告して停止する」が原則です(エラー処理・リトライ・フォールバック設計)。

キャッシュの書込と読取を別に計測する

2026-09-10 確認の例では、GPT-5.6 以降は prompt_cache_options.ttl: "30m" とキャッシュ境界を扱い、usage.input_tokens_details の cached_tokens と cache_write_tokens を分けて記録します。書込は通常入力とは別の単価区分で、書込分へ通常入力単価を二重加算しません。再利用されない可変末尾まで毎回キャッシュすると、書込費用が増えるため境界の設計も評価します。

読取割引も一律ではありません。Claude のキャッシュ読取は既定 0.1x、例外は Fable 5.1 / Mythos 5.1 が 0.025x、Opus 5.5 / Sonnet 5.5 が 0.05x です(この比率は2026-10-08確認)。Sonnet 5.5は通常入力 $2 に対して読取 $0.10 / MTokで、5分・1時間の書込料金とは別です。異なるモデルの比率を流用できません。保持時間はデータ削除期限と同義ではなく、組織の保持契約と併せて確認します。

設定の更新によって前方一致を保てる機構もあります。Astra の standard・単一エージェントでは configuration_update を追記し、Claude の対応モデル・経路では per-message effort の beta を使います。元の system 本文や過去の履歴を自由に書き換えてもキャッシュが残る、という意味ではありません。対応条件は OpenAI / Claude の特化ガイドで確認します。

実務での注意点

アンチパターン

  • 月末の請求書で初めて気づく → 集計が月次・全体のみでは、原因特定も対策もできない → タスク単位の計測と日次の可視化・コストレートのアラートを入れる
  • 単価の安いモデルに変えて品質を測らない → 成功率が下がり、再試行・人手対応を含めた総コストはむしろ増える → 評価スイート(回帰テストと CI 組み込み)で品質とコストをセットで判断する
  • キャッシュを意識しないプロンプト構造 → 可変部分(日時・ユーザー名)が先頭にあるとキャッシュが毎回無効になり、割引が効かない → 固定部分を先頭に集める構造にしてからキャッシュを有効化する
  • 上限なしの自律ループ → 1 セッションの暴走・少数ユーザーの占有が予算を食い尽くす → タスク・テナント・全体の 3 層で上限を掛ける

チェックリスト

  • タスク 1 件あたりのコストを計測できる(トレースにトークン数がある)
  • コストを平均でなく分布(P95・最大)で見ている
  • プロンプトが「固定部分が先頭」の構造になっており、キャッシュが有効
  • モデル使い分け・履歴圧縮の変更は評価スイートで品質を確認してから入れている
  • タスク・テナント・全体の 3 層の上限がある
  • 上限到達時の挙動(報告して停止)が設計されている
  • コストレートのアラートがあり、対応手順に接続されている

関連トピック

参考資料

  • Claude Pricing  — モデル別キャッシュ読取比率と書込料金の区別(アクセス日: 2026-10-08、取得: 2026-10-08T04:47:02Z)
  • Prompt caching  — 本文の仕様例(アクセス日: 2026-09-10)
  • Claude Fable 5.1  — 本文の仕様例(アクセス日: 2026-09-10)
  • Prompt caching(Anthropic docs)  — 前方一致キャッシュの仕組みと料金構造の例(アクセス日: 2026-07-05)

TODO・未確認事項

可観測性とトレーシングレイテンシ最適化