AIエージェント コストの盲点：有料フォールバックが既定経路になった日

AIエージェント コスト事故の記録

高くついた原因は、異常に大きなモデル呼び出しではありません。ファイルの受け渡しが遮断され、本来は常用する設計ではない従量課金フォールバックが処理を背負うことになった点です。

2026-09-18 → 09-19、2つの自律型パブリッシングエージェントは、いずれもサンドボックス内のライターが記事を作り、サイト側が公開するという大枠の流れで動いていました。一方のエージェントは新しいサーバーで再起動されたばかりでした。このエージェントは12時間で18本の記事を公開しましたが、18件すべてのペイロードに画像の説明はあっても、画像ファイルは1つも入っていませんでした。

サイトは、その説明を画像生成リクエストとして扱いました。有料の画像モデルによって18枚のカバーと約26点の図版が生成され、1記事当たりの費用は約$0.45でした。従量課金ゲートウェイの残高は2つの媒体で共有されており、01:15 UTCに$8.30から$0になりました。

画像数と1記事当たりの費用は概算として記録されているため、ここでも概算のまま扱う必要があります。この情報だけでは、共有残高の動きを厳密に復元できません。また、2種類の出力欠落件数は、それぞれ別に観測されたものです。重複を除いた影響記事数を合算できる根拠にはなりません。

証拠が示す破断点はアップロード境界です

ペイロード、実行ジャーナル、残高の3つが、同じ問題箇所を指しています。ライターは画像を説明できても、その画像ファイルを引き渡せませんでした。

• 18件すべてのペイロードにシーンの説明があり、画像ファイルは0でした。これはレンダリング品質の小さな問題ではありません。成果物が公開境界を一度も越えていなかったことを意味します。
• 一方の実行ジャーナルには画像ツールへの言及が10回あり、もう一方は0回でした。どちらのエージェントにも、同じバージョンのCLI、同じツール、同じフラグが用意されていました。この差から、機能自体は存在していたものの、2つ目のライターから到達できる経路には組み込まれていなかったことが分かります。
• サイトが説明文から有料画像を生成している間に、共有残高は01:15 UTCに$8.30から$0へ減りました。決済経路が止まると、2つの媒体の両方でカバーと埋め込みが欠落しました。

このインシデントがパブリッシング以外にも重要なのは、そのためです。エージェントのコストは、モデル選定、トークン使用量、リトライ回数の問題として語られがちです。しかし今回の費用は、その1層手前、つまりファイルを作るプロセスと、アップロードに必要な認証情報とを隔てるセキュリティ境界から生じていました。

安全なサンドボックスが有料経路を唯一の選択肢にした仕組み

サイトのキーをサンドボックス内のライターに渡さない判断は、セキュリティ上正しいものです。設計上の誤りは、そのキーが必須のアップロード処理を、ライターのワークフロー内に残したことです。

サンドボックスは、エージェントがアクセス・変更できる範囲を制限します。今回、ライターのシェルはサイトのキーを受け取れませんでした。画像のアップロードにはそのキーが必要だったため、レンダリング済みファイルを保存先へ直接渡す経路には、サンドボックス内から到達できませんでした。

それでもペイロードは、カバー用のシーンと本文内画像用のシーン説明を受け付けていました。フォールバックとは、優先経路が完了できないときに使う代替経路です。説明だけが入り、ファイルのないペイロードが届いたため、サイトは従量課金ゲートウェイ経由で画像を生成しました。代替経路が、いつの間にか唯一の経路になっていたのです。

もう一方のエージェントには、別の到達可能な経路がありました。そのライターはサブスクリプションに含まれる画像ツールでファイルをレンダリングし、自らアップロードしていました。「サブスクリプションに含まれる」とは、サブスクリプション自体が無料だったという意味ではありません。その実行では、欠けた画像を1枚ずつ、今回問題になった別建ての従量課金フォールバックへ送らなかったという意味です。

教訓は、サンドボックスを弱くすることではありません。認証情報を使う処理を、境界の信頼できる側へ移すことです。AIエージェント向けコードサンドボックスの選択は重要ですが、どの製品を選んでも、到達できない認証必須の処理をライターに割り当てたワークフローまでは修復できません。

doneが誤った状態だった理由

決済エラーは、ジョブの結果を変えるべきでした。しかし実際には、402がソフトフェイルとして処理されました。つまり、システムはエラーを記録または許容し、ジョブを停止せずに処理を続けました。

この判断によって、タスクの完了と出力の完了が切り離されました。記事本文は公開できたため、必須のカバーや埋め込みが存在しなくても、ジョブはdoneと報告しました。

埋め込みとは、このシステムが内部リンクや検索のために関連コンテンツを照合できるよう、コンテンツを変換して保存した表現です。カバーの欠落はページを見れば分かります。一方、埋め込みの欠落は見えにくく、記事自体は存在していても、発見したり関連付けたりする仕組みからは抜け落ちたままになります。そのため、5本の記事が埋め込みなしで公開されても、最終ステータスには不具合が表れませんでした。

正しい完了条件は単純です。ワークフローが必須と定めた出力がそろうまで、ジョブを完了扱いにしてはいけません。カバーが必須なら、カバーの存在を確認します。埋め込みが必須なら、埋め込みを確認します。データベースに本文の行があるだけでは、公開ジョブが完了した証拠にはなりません。

開発者・運用者・購入担当者への示唆

同じインシデントでも、立場によって見直すべき判断は3つに分かれます。

開発者：サンドボックスだけでなく、受け渡しを設計する

開発者は認証情報の境界を図にし、それを越える各工程に担当を割り当てる必要があります。「ライターにキーを渡さない」はセキュリティルールです。その隣に「ライターがそのキーでアップロードする」という要件を残すことはできません。

どのエージェントシステムも、生成された意図と外部への副作用の境界に突き当たります。説明を書くのは意図です。画像を保存する、従量課金プロバイダーに料金を支払う、記事を公開するといった処理は副作用です。それぞれに、信頼できる明確な実行主体、観測可能な結果、親ジョブまで伝わる失敗状態が必要です。

運用者：複数プロダクトが共有する依存先を監視する

共有の従量課金残高は、ベンダー設定の小さな項目ではなく、共有インフラとして扱うべきです。今回、2つの媒体のカバー、図版、埋め込みが同じ残高に依存していました。そのため、一方のライターのフォールバック動作が、もう一方の媒体の信頼性まで変えてしまいました。

AIエージェントAPIの予算管理を使えば支出は制限できますが、上限を設けるだけでは成果物の経路は正しくなりません。共有ヒューズに名前を付け、その健全性をアラート対象にし、残高の枯渇を依存するすべてのワークフローから見えるようにします。元の記録にはアラートのしきい値も修正後の測定値もないため、ここで推測してはいけません。

購入担当者：正常系が崩れた後を確認する

購入担当者が確認すべきなのは、フォールバックが従量課金か、どのプロダクトがその予算を共有するか、そしてフォールバックが支払えないときにジョブが何を報告するかです。デモが一度成功しただけでは、どの問いにも答えられません。

実用的な契約には、必須出力、認証情報を持つ主体、有料フォールバック、出力欠落時に返すステータスを明記します。費用の発生や不完全な公開につながるリトライには、AIエージェントのリトライに対する人間の承認も制御手段になります。これは成果物の契約を補完するものであり、置き換えるものではありません。

今すぐ動くか、待つか、現状のままにするか

サンドボックス内のライターが説明を送れても、その説明が代替するファイルをステージングできない場合、複数のプロダクトが有料の依存先を共有している場合、またはフォールバックに失敗してもdoneで終わる場合は、今すぐ対応が必要です。設計変更を待てるのは、保存済みファイルが境界を越えたことを現在のログで証明でき、必須出力の欠落がすでに成功を阻止している場合に限られます。必須の公開出力が、直接にもフォールバック生成経由でもその残高に依存していないワークフローだけが、今回の共有残高障害の影響を受けません。

過大評価されているもの：フォールバックを増やしても耐障害性は高まりません

ジョブを先へ進めるだけで、フォールバックが耐障害性になるわけではありません。そのコスト、依存先、出力品質、失敗状態を把握できて初めて、耐障害性として機能します。

今回のフォールバックは、残高がある間は役に立ちました。同時に、本来のアップロード経路へ到達できない事実を覆い隠しました。この組み合わせは危険です。表面的には利用可能に見えるため、壊れた境界を明らかにするはずのシグナルが遅れてしまいます。

別のプロバイダーを追加しても、根本問題は解決しません。doneと必須成果物が切り離されたまま、別の請求と別のソフトエラーが増える可能性があります。目指すべきは、代替経路をできるだけ多く集めることではありません。エージェントが実際に到達できる本来の経路と、有料であることが見え、失敗時には明確にエラーを返すフォールバックです。

フォールバックコストを見える状態に保つ設計ルール

修正は担当の明確化から始め、次にコストと完了条件を明示します。

認証情報は信頼できるプロセスに置く

サンドボックス内のライターは、記事、ペイロード、そして自らレンダリングできる画像ファイルを生成します。認証が必要なアップロードは、サンドボックス外の信頼できるプロセスが実行します。キーの形をした穴を開けるのではなく、セキュリティ境界を維持する設計です。

ファイルと説明文を別の入力クラスにする

ファイルは、すぐ使える成果物です。説明文は、成果物を作るためのレシピです。両者を同じものとして扱うと、コストも失敗時の挙動も見えなくなります。

公開契約では、ステージング済みファイルを優先すべきです。説明文は、来歴と修復用データとして残します。システムが説明文を使ってフォールバック生成を実行するなら、その分岐を有料経路として明示し、結果にもそう記録する必要があります。

doneを必須出力に結び付ける

親ジョブは、約束した成果物がそろうまで待たなければなりません。カバーや埋め込みの条件を満たしていないのに、決済のソフトエラーからdoneへ進んではいけません。必須出力の確認は、後から被害を報告するだけのレポートではなく、最終的な成功状態へ移る前に行います。

依存先の健全性をタスクログから分離する

一方のエージェントは画像ツールを使い、もう一方は使わなかったことを示すジャーナルの差は有用でした。このシグナルは残すべきです。それに加えて、共有の従量課金依存先の健全性を、そこに頼るすべての媒体から見えるようにします。ジョブログが答えるのは、1つのワーカーが何を試みたかです。依存先のテレメトリーが答えるのは、共有経路が今も誰かにサービスを提供できるかです。

次のコードは、説明のための構造例であり、本番ソースではありません。表しているのは担当とステータスの流れだけです。元資料には、実装の詳細も修正後に測定した結果もありません。

// Illustrative only. This is not production source.
const handoff = {
  payload: writerOutput.payload,
  pictureFiles: writerOutput.pictureFiles,
  pictureDescriptions: writerOutput.pictureDescriptions,
};

const stagedFiles = await trustedProcess.stage(
  handoff.pictureFiles,
  "presigned PUT",
);

const fallbackRender = stagedFiles.complete
  ? null
  : await paidFallback(handoff.pictureDescriptions);

if (fallbackRender?.status === 402) {
  failJob("Paid fallback unavailable");
}

const publishableArtifacts = mergeArtifacts(
  stagedFiles,
  fallbackRender,
);

const rewrittenPayload = rewritePictureReferences(
  handoff.payload,
  publishableArtifacts,
);

rewrittenPayload.pictureDescriptions = handoff.pictureDescriptions;

assertRequiredArtifacts(rewrittenPayload);
markDone();

重要なのは処理の順序です。ライターはサイトの認証情報を受け取らずにファイルを出力し、信頼できるプロセスがそれをステージングし、ペイロードは保存済みの成果物を参照します。そして、検証済みの完了だけがdoneになれます。

コスト漏れを止める受け渡し設計

長期的に効く修正は、ライターがレンダリングし、信頼できる担当がステージングするという2段階の受け渡しです。

ライターは、すでに作成を許可されている出力の中で、ペイロードの隣に画像ファイルを配置します。サンドボックス外の信頼できるプロセスがそのファイルを受け取り、受け渡し用に認可されたアップロードであるpresigned PUTを使って送信します。提供された記録には有効期限も権限も定義されていないため、それらは事実として断定せず、実装時の選択肢として残します。

ステージング後、信頼できるプロセスはペイロードを書き換え、画像の参照先を保存済みファイルに向けます。サイトが受け取るのは、生成指示ではなく成果物です。ライターにサイトのキーを渡す必要はなくなり、渡したふりを前提に公開経路を動かすこともなくなります。

説明文はペイロードに残します。これは修復記録であり、ライターが画像をレンダリングできない場合の有料フォールバックでもあります。したがって、フォールバックに費用がかかる可能性自体は残ります。この修正は、フォールバックを消したり、測定済みの削減額を主張したりするものではありません。ファイルのステージングを到達可能な本来の経路へ戻し、有料生成を再び条件付きの処理にします。

月曜日にまずやること

認証情報を必要とする必須工程を、すべて追跡してください。ライターがその認証情報を持てないなら、処理を信頼できるプロセスへ移し、両者の間で成果物をどう受け渡すかを定義します。次に、最終ジョブ状態を、必須のカバー、埋め込み、保存済みファイルの参照がそろっていることに連動させます。説明文はファイルと一緒に残しつつ、それが起動する経路を「有料フォールバック」と明記します。

よくある質問

次回の本番環境トラブル分析はニュースレターでお届けします。