Opus 5 にブログを書かせてみたが、ボツにした理由──上位モデルでも超えられなかった「合格ライン」の壁

はじめに：期待を込めて最上位モデルに任せた結果

Claude Code が v2.1.219 ¹ へアップデートされた際、モデル選択肢に最新の 「Claude Opus 5」 ² が登場しました。入力 $5.00 / MTok、出力 $25.00 / MTok という従来の Opus 単価を維持しつつ、高い推論能力を備えたモデルです。

「これほどの性能があれば、ブログ執筆パイプラインも今まで以上に高品質な記事が一発で仕上がるのではないか」──そう期待した私は、本ブログの自動執筆パイプラインを用いて「Opus 5 の検証記事」自体の作成を自律エージェントに委託しました。

しかし、結論から申し上げますと、完成した記事草案は最終的に 「ボツ（不採用）」 と判定し、公開せずに破棄する決断を下しました。

単に「生成された文章が気に入らなかった」という表面的な理由ではありません。その裏では、わずか 30分間で利用可能枠の 70% が吹き飛ぶコスト爆発と、敵対的レビューが永久に終わらない無限ループの沼が発生していたのです。本記事では、当プロジェクトで発生した生々しい実録ログとともに、最新 LLM エージェントを運用する上での致命的なアンチパターンを解き明かします。

第1章: 実録・5時間枠の70%が30分で溶けたコストとログ

最初に突きつけられたのは、圧倒的な「トークン消費の速度」でした。

Anthropic の有料プランにおける利用制限は、過去 5時間分の消費量がスライディング更新される 「5時間ローリングウィンドウ（ 5-hour rolling window ）」 ³ 方式を採用しています。API 単価は入力 $5.00 / MTok、出力 $25.00 / MTok ² です。

実際の検証ログによると、最初に実行した企画段階（ /blog-plan ）で $4.15、続く設計段階（ /blog-design ）で $3.46 相当を消費しました。以前の検証でも確認した通り、Opus 5 は非常に強力ですが、このわずか 2ステップだけで 5時間枠の上限の約 40% を使い果してしまいました。

【企画・設計段階での枠消費（検証ログ実測値）】
・/blog-plan   : $4.15 相当
・/blog-design : $3.46 相当
  ⇒ 2ステップで 5時間上限枠の約 40% を消化

さらに深刻だったのは、枠の自然回復を待って続きの工程を再実行した際のことです。再開からわずか 30分間のうちに、残り枠の 70% が一瞬で消失しました。

実行ラウンド	処理内容	枠消費率
Round 2	再設計・修正 1 （枠回復後）	35%
Round 3	再設計・修正 2	21%
Round 4	再設計・修正 3	14%
合計	30分間の再実行（ 3ラウンド分）	70% 消費

Claude Pro プランの /usage 画面に表示される利用枠のパーセンテージ（クォータ消費率）が、1ラウンド進むごとに 35%、21%、14% と急激に削られ、あっという間にレート上限へと追い込まれました。

なぜ、これほどのスピードでトークンと利用枠が枯渇してしまったのでしょうか。

第2章: なぜ収束しなかったのか？2つの要因とメカニズム

分析を進めた結果、原因はモデルの単体性能ではなく、エージェントパイプラインと人間側の操作が絡み合った 「2つの構造的要因」 にあることが判明しました。

要因①: スクショ追加による「自律メタ解析」の誘発

1つ目の要因は、進捗やトークン消費量を記録しようとして、/usage 画面の スクリーンショット画像 7枚 をコンテキストに追加したことです。

最新モデルの優れたマルチモーダル機能が、ここでは裏目に出ました。画像を追加した瞬間、エージェントは画像内の数値やグラフ、画面キャプチャ上のUI表示を自律的に読み取り始めました。その結果、本来の目的である「ブログ記事の執筆」から脱線し、「どの工程で Opus 5 を使うべきか」「画面上のトークン消費率の過不足」といった不要な自律メタ解析を始めてしまったのです。

巨大な画像データと膨大なツール実行ログが蓄積したことで、いわゆる Context Window Bloat (コンテキスト肥大化) が発生し、毎ターン過去全ログを読み込む Prefill コストが肥大化していきました。

要因②: 敵対的レビュー (`blog-verify`) の泥沼（ 4周の無限ループ）

2つ目の要因は、品質向上のために導入していた検証ゲートスキル blog-verify との相互作用です。過去記事 /blog/blog-pipeline-adversarial-verification で詳しく解説した通り、このスキルは「あえて懐疑的な読者の視点」から厳格なファクトチェックを行います。

しかし今回、以下のような修正合戦が勃発しました。

blog-verify が微細な値の取り残しや表記の揺れを指摘する。
修正エージェント（ /blog-design ）が指摘を受けて設計書を修正する。
修正時の文章変更により、別の注釈や数値との間で新たな微小な不整合が発生する。
再度 blog-verify に投げると、新しい不整合に対して「要修正」判定が下りる。

このやり取りが Round 1（初回検証）から Round 2〜4 にかけて 4周連続で繰り返されました。合格ラインや妥妥点が機械的に定義されていなかったため、両エージェントが永久に合格を出せない Infinite Agentic Loops (無限エージェントループ) に陥ってしまったのです。

第3章: なぜ「記事自体」をボツと判断したのか

4周にわたる修正ループを経て、最終的に記事の草案自体は生成されました。しかし、私は完成した草案を「公開不可（ボツ）」と判断しました。

ボツにした理由は、 「AIの文章が下手だったから」ではありません 。

過剰な修正ループと脱線したメタ解析の結果、出力された文章は度重なる注釈や言い訳のような補足で埋め尽くされ、記事としての全体バランスや主張の焦点が完全に失われていたのです。

AIが出力した長大な文章を人間が検収し、脱線した箇所を削り、崩れた構成を再調整する作業コストを計算したところ、 「最初から人間が1から手動で書いた方が圧倒的に早い」 という本末転倒な状態になっていました。AI自動化の目的である生産性向上に反するため、泣く泣く作成した記事草案を破棄（ボツ）にいたしました。

第4章: 教訓・エージェント運用で避けるべきアンチパターン

この苦い失敗から得られた、自律型 AI エージェント運用における実践的教訓は以下の 3点です。

1. 実行途中で無作為に画像やログを追加しない

コンテキストウィンドウの「清浄さ」を保つことは、トークンコストだけでなくエージェントの思考のブレを防ぐ上でも極めて重要です。進捗ログや画像を途中追加すると、エージェントの関心を不要なメタ分析に引き戻してしまいます。

2. 敵対的レビューには Hard Stop（上限回数）を設ける

品質を高めるための検証ゲートであっても、無制限に回せばトークン暴走のエンジンと化します。「検証は最大 2〜3 周までとし、残った指摘は申し送り事項として人間に委ねる」という機械的な Hard Stop (強制停止ルール) が不可欠です。

3. Human-in-the-Loop (人間のディレクション)

エージェント同士の修正合戦を止め、「この品質で十分である」あるいは「これ以上の修正は不経済であるためボツにする」という最終決定を下せるのは人間しかいません。過去のアーキテクチャ解説 /blog/ai-agent-blogging-architecture や /blog/blog-pipeline-orchestrator で述べたように、完全自動化（ Full Autonomy ）を目指すのではなく、適切な境界線で人間が手綱を握る設計こそが求められます。

まとめ: AIに丸投げする時代から、境界線を設計する時代へ

Claude Opus 5 は間違いなく最高峰の知能を持ったモデルです。しかし、どれほど優秀なモデルであっても、制御構造を持たないパイプラインや無計画なフィードバックを与えれば、あっという間にトークンと時間を浪費してしまいます。

上位モデルを活かすために必要なのは、優れたプロンプトではなく、 「無限ループを止める上限設計」 と 「人間の適切なディレクション」 です。

AIエージェントの運用設計や開発プロセスの自動化、パイプライン構築に関するご相談はコンタクトフォームからお気軽にお問い合わせください。