2026年8月9日、GitHubユーザーapexethdevは、openai/codexにIssue #37674を投稿しました。
報告対象は、Codex CLIからAmazon Bedrock経由でGPT-5.6 Solを使った作業です。
3,656リクエストで、キャッシュ書き込み費用の推計が約1,182ドルに達しました。
企業がAIエージェントを使うときは、モデル料金だけでなく、キャッシュの読み書きも監視対象になります。
※本記事は2026年8月28日時点の情報です。
報告された実例｜3,656リクエストで推定約1,400ドル
Issueの対象は、Codex CLI 0.147.0のネイティブamazon-bedrockプロバイダーです。
Amazon Bedrock Mantle Responses APIのus-east-1を経由し、openai.gpt-5.6-solを使っていました。
報告者は、2026年8月5日から8月8日までの完了済み日を集計しました。
| 項目 | Issueに示された内容 |
|---|---|
| リクエスト数 | 3,656 |
| キャッシュ書き込み | 171.94M tokens |
| 推定キャッシュ書き込み費用 | 1,182.09米ドル（約17万7,314円） |
| 推定総費用 | 1,386.46米ドル（約20万8,000円） |
円換算は、金額の規模を把握するための概算です。※1ドル=150円で換算。
1,182.09米ドルと1,386.46米ドルは、Cost Explorerの使用量とレートカードから算出した推計値です。
確定したAWS請求額ではありません。為替や適用レートでも円換算は変わります。
Issue本文では、キャッシュ書き込みがモデル推定支出の約85%を占めたと説明されています。
この比率は、入力内容の再利用が進まないと、書き込み側の費用が積み上がることを示します。
ポイント
本件の金額は、3,656リクエストと171.94Mのキャッシュ書き込みから算出された推計値です。確定請求額とは分けて扱い、費用の内訳を確認する必要があります。
コストが膨らんだ仕組み｜キャッシュ制御とツール変更を分けて見る
Issueの調査では、Codexがセッション単位のprompt_cache_keyを送っていました。
一方、HTTPとWebSocketのResponsesリクエスト型には、明示的な指定が含まれていませんでした。
- prompt_cache_options
- prompt_cache_breakpoint
- config.tomlから追加するためのリクエスト本文の変換
内蔵のAmazon Bedrockプロバイダーは、トランスポートと認証の設定を提供します。
しかし、リクエスト本文の構造を変換する機能はなく、設定だけで指定を補えませんでした。
AWSの仕様では、GPT-5.6 Solなどにprompt_cache_breakpointのexplicitモードがあります。
安定したシステム指示やツール定義を前に置き、変化する最新入力を後ろに置く設計が示されています。
ただし、キャッシュ書き込みが起きる理由は一つではありません。
コールドスタート、異なるプロンプト、フォーク、コンパクションでも書き込みは起こり得ます。
今回の具体的なキャッシュミスについて、メンテナーはweb search toolの追加が原因である可能性を説明しました。
つまり、明示的なキャッシュ制御を送れない制約と、web search toolによるキャッシュミスの可能性は、別の論点です。
AIエージェントの構成を考える際は、AIエージェントの拡張規格と同じく、ツール追加が実行経路へ与える影響を確認する必要があります。
ポイント
コスト増は、Codex単独の欠陥と単純化できません。リクエスト型の制約、キャッシュミスにつながるツール変更、プロンプトの変化を分けて切り分けることが重要です。
別報告と対応状況｜回避策からBedrock側の修正まで
Hacker Newsには、別の利用者によるBedrock上のCodex利用報告も掲載されました。
その報告では、キャッシュの読み書き比率が5%未満で、通常の約10倍の費用になったとされています。
投稿者は、web_search = “disabled”を回避策として示しました。
この設定にしても、シェルコマンドなど別のツール経由でウェブ検索を実行できると説明されています。
別の参加者は、web_search = “cached”ではキャッシュ読み取りが0のままでした。
web_search = “disabled”にすると、キャッシュが通常どおり再開したと報告しています。
2026年8月20日、メンテナーはBedrockチームと修正に取り組んでいると説明しました。
2026年8月21日には、Bedrock側のweb search tool向け修正のデプロイ完了が報告されました。
us-east-2、us-west-2、us-east-1で機能を確認したとして、Issueはクローズされています。
対応状況を読むときは、暫定回避策と、Bedrock側でデプロイされた修正を区別することが大切です。
ポイント
web_searchの無効化は、別経路の検索を残した暫定策として報告されました。8月21日にはBedrock側の修正デプロイが報告され、Issueはクローズされています。
企業のコストガバナンス｜監視・上限・段階的な緩和策
企業が同様の構成を使う場合、請求確定を待ってから対処する運用は適しません。
本番投入前に、固定プレフィックスのキャッシュ読み取りと書き込みを実測します。
実行中は、cache_write_tokensとcached_tokensを別々に監視します。
書き込みだけ増え、読み取りが0または極端に少ない場合は、異常の兆候として扱います。
切り分けでは、次のような実行条件を並べて見ます。
- キャッシュ制御
- ツール定義
- プロンプトの安定性
- モデル、リージョン、クライアントバージョン
AWS Budgetsでは、実績または予測のコストと使用量に閾値を設定できます。
閾値に達したとき、通知に加えてIAMポリシーやSCPを適用するアクションも選べます。
アクションは、手動承認または自動実行から選択できます。
ただし、AWS Budgetsの情報更新は最大で1日3回です。
通常は前回更新から8〜12時間後とされるため、リアルタイム停止装置とはみなせません。
実行側の利用量監視と組み合わせ、異常時にはweb search toolなどの可変機能を段階的に無効化します。
AIモデルの費用比較は、11種のAIモデルを同一指示で比べた実験も参考になります。
運用時のログや評価を整える考え方は、マルチエージェントの落とし穴とも接点があります。
ポイント
上限設定だけでは、実行中の急増を即時に止められません。利用量の分離監視、実績・予測のBudget、異常時の設定変更を組み合わせます。
コスト統制の確認項目｜導入前と運用中に分けて点検
確認項目は、費用の発生後ではなく、導入前から運用に組み込みます。
- 固定プレフィックス：キャッシュ読み取りと書き込みを本番投入前に実測する
- トークン監視：cache_write_tokensとcached_tokensを別々に追う
- Budget設定：日次・月次で実績値と予測値の閾値を設定する
- 緩和策：異常時にweb search toolなどを段階的に無効化できる設定を用意する
特に、キャッシュ書き込みだけが増えたときの連絡先と判断者を決めておきます。
モデルやリージョンの変更時も、同じ観測項目で比較できる状態を保ちます。
AIエージェントを複数の業務へ広げるなら、クローズドAIエージェントのような構成論だけでなく、費用の責任分界も決めます。
この点検は、料金表を読むだけでは完了しません。
実際のプロンプト、ツール定義、モデル、リージョンをそろえて、読み書きを測ることが出発点です。
ポイント
導入前は固定プレフィックスを実測し、運用中は書き込みと読み取りを分けて監視します。閾値と異常時の設定変更を事前に決めると、費用の急増に対応しやすくなります。
よくある質問（FAQ）
Q. 約1,400ドルは確定した請求額ですか？
いいえ。Cost Explorerの使用量とレートカードから算出した推計値です。確定したAWS請求額ではありません。
Q. コスト増の原因はCodexだけですか？
単一原因とはいえません。明示的なキャッシュ制御の制約に加え、web search toolによるキャッシュミスの可能性が説明されています。
Q. web_searchを無効化すると検索できなくなりますか？
いいえ。web search toolを無効化しても、シェルコマンドなど別のツール経由でウェブ検索を実行できると説明されています。
Q. 企業は何を監視すべきですか？
cache_write_tokensとcached_tokensを分けて監視し、AWS Budgetsの実績・予測閾値と異常時の設定変更を組み合わせます。
まとめ
Codex CLIとAmazon Bedrockの組み合わせで、キャッシュ書き込み費用が膨らんだ事例が報告されました。
Issueに示された総費用は約1,386ドルの推計値で、確定請求額ではありません。
原因は、明示的なキャッシュ制御の制約と、web search toolによるキャッシュミスの可能性を分けて捉えます。
8月21日にはBedrock側の修正デプロイが報告され、Issueはクローズされました。
企業側では、トークンの分離監視、Budgetの閾値、異常時の設定変更を運用に組み込みます。
参考情報：
関連記事
- 同一指示でAIモデル11種を比較した実験を解説｜コスト216倍差のモデル選定ポイント
- マルチエージェントAIの落とし穴を解説｜Anthropic研究に見る協調失敗の教訓
- Agent Plugins 1.0を解説｜主要ベンダー横断のAIエージェント拡張規格と選定ポイント
- クローズドAIエージェントを解説｜機密データを外に出さないAI活用の仕組みと導入ポイント
- 非人間IDを解説｜AIエージェントの権限管理と監視のポイント
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。