215 億 4000 万トークン後のコードエージェント：何が不足しているか？

私のコードエージェントは、2026 年を通じて実際の作業（ウェブサイト、iOS アプリ、E コマース、CRM、音楽ツール、SEO システム、そして私自身のエージェントワークフロー）において、Claude Fable 5 および OpenAI の GPT-5.4、GPT-5.5、GPT-5.6 ファミリーを使用しました。Mac に残っていたローカルセッションログを合計したところ、その数は215 億 4000 万トークンに達しました。

この数字は途方もありません。また、文脈が必要です。

その大部分は、私のために書かれた 215 億の新しい単語ではありません。長いエージェントセッションでは、大きなコードベースと指示がコンテキストを通じて何度も送信されます。その多くはキャッシュから読み取られます。トークン数は主に、私のコードエージェントが処理したコンテキストの量を示しています。

この期間を経ての私の結論は依然として明確です。私たちはレベルアップしました。モデルは、1 年前には遥か彼方に感じられたレベルで、より長いタスクを維持し、ツールを使用し、ミスを修正できるようになっています。しかし、モデル自体は依然として、信頼できるシステムにおいて最も興味のない部分です。

215 億トークンがコードエージェントについて語るもの

私は、保存された Codex ログ内の各 `last_token_usage` 値から OpenAI の使用量をカウントしました。Fable については、通常の入力、キャッシュ作成、キャッシュ読み取り、および出力を使用して、Claude ログ内のユニークなアシスタントメッセージからカウントしました。その結果は、OpenAI や Anthropic の請求書ではなく、ローカルなアクティビティの測定値です。

高水位線方式を使用すると、GPT-5.4 は約 32 億 1000 万のキャッシュ入力トークン、GPT-5.5 は 123 億トークン、GPT-5.6 ファミリーは約 18 億 2000 万トークンを占めていました。Fable ログには、約 30 億 5000 万のキャッシュ読み取りと 1 億 8100 万のキャッシュ作成トークンが含まれていました。

そのため、合計値を人間が読めるテキスト量と比較するのは誤解を招きます。エージェント作業は大きなコンテキストを再利用します。関連する質問は、システムがそれらを正しく扱ったかどうかです。

使用量の背後にあるコードベース：59 の GitHub プロジェクト

測定時点では、私の GitHub アカウントには59 のリポジトリ（50 がプライベート、9 がパブリック）がありました。内訳はおよそ以下の通りです。

名前が完全に一致するローカルチェックアウトがあった 26 の GitHub リポジトリにおいて、ベンダー、ビルド、キャッシュ、および難読化ファイルを除外した後、690 万行の追跡されたソースコードが見つかりました。この数字は、3 つの大きなレガシー PHP プラットフォームによって支配されています。これらを除去すると、TypeScript、Python、Swift、Shell、および Astro を含む、より現代的でより自作された表面には約35 万 7000 行が残ります。

これはコード行数コンテストで勝つための試みではありません。100 万行の悪いコードは依然として負債です。これらの統計は、モデルがテストされた環境の広がり（モバイル、バックエンド、フロントエンド、自動化、コンテンツ、運用、ビジネスロジック）を示しています。

Fable 5 と GPT-5.6 は優れているが、その方法は異なる

Anthropic は Fable 5 を、大規模なコードプロジェクト、移行、および長い自律セッション向けのモデルとして説明しています。OpenAI は GPT-5.4 を、最先端のコーディング、ナレッジワーク、およびコンピューター使用の融合として説明しています。GPT-5.6 ファミリーは、焦点をさらに長期間実行されるエージェント作業に向けて押し進めています。

それは私の経験とよく一致しています。Fable は、コードの変更を開始する前に、難しい問題の形状を理解するのが得意なことが多いです。一方、GPT-5.6 Sol は、問題を掴み、ツールを使用し、作業を前進させる可能性が高いです。

X での議論も同じ分裂を示しています。

その批判は正当です。より良いモデルでも、ルーティング、価格設定、コンテキスト制限、またはセキュリティポリシーが理解しにくい場合、より悪い労働日を生み出す可能性があります。

モデルはエンジンであり、車ではない

言語モデルはコードについて推論できます。コードエージェントは、実際のシステム内で動作する必要があります。

私の実用的なスタックは以下のようになります。

各部分は異なる問題を解決します。ツールのないスキルは単なるドキュメントです。ポリシーのないツールはリスクです。ソースコントロールのないメモリは古い伝承になります。ライブチェックのないビルドは、本番環境を壊れたままにする可能性があります。

大きな飛躍はより長い作業チェーンです

それは質的な変化です。

同時に、私はモデルが以下のことを行うのを見てきました。

最後のステップが依然として最も高価です。結果が正しい場所に存在し、実ユーザーのために機能することを証明することです。

私たちがまだ欠けているもの

より良い自動モデルルーティング

私はすべてのサブタスクに対してモデル名と推論レベルを選択したくありません。システムは、全体像に最も優れたモデルにアーキテクチャレビューを送信し、機械的な変更により高速なモデルを送信し、最終的な検証を別のチェッカーに送信すべきです。

ポータブルな作業メモリ

コンテキストは依然として特定のクライアント、モデル、またはセッションファイル内に閉じ込められています。スキルと MCP は痛みを軽減しますが、エージェントはプロジェクトの実証された作業方法を失うことなくモデルを切り替えられるべきです。

一等市民としての検証

ほとんどのデモエージェントはコード生成を報酬とします。私は、検証された正しい外部状態（ライブルート、データベース行、インストールされたアプリ、送信されたメッセージ、または承認されたビルド）で終了するタスクの割合を測定したいです。

より明確なコスト

キャッシュトークンはより安価であり、場合によっては異なって報告されますが、ユーザーが見るのはしばしばすぐに消えるバーだけです。エージェントは、「このタスクは X の新しい入力トークン、Y のキャッシュ読み取り、Z の出力トークンを使用し、以下の検証された結果を作成した」と言えるべきです。

私の推奨事項：スーパープロンプトの前にシステムを構築する

検証可能な狭いタスクから始めます。エージェントに小さなツールセットを与え、ワークフローのためのスキルを書き、完了とみなされるものを定義します。その後、繰り返しの必要性が見られたら、メモリとより多くのツールを追加します。

有用なコードエージェントには、すべてへの自由なアクセスは必要ありません。必要なのは、正しいアクセス、正しい順序、そして停止ルールです。

215 億 4000 万トークンを経て、最大の改善はモデルがより美しいコードを書くようになったことではありません。モデルはより長く作業に留まることができます。私たちの仕事は、その時間を価値あるものにするガードレール、メモリ、および検証を構築することです。