Depth over Breadth — AIは深く使え

あなたのチームに、月15万ドル（約2,200万円）分のAIトークンを消費しているエンジニアはいますか。

いるかもしれません。Metaでは一人のエンジニアが200万ドル相当を使い切ったケースすら報告されています。MetaとMicrosoftはエンジニアのAIトークン消費量をランキング化し、「生産性指標」として扱い始めました。

使えば使うほど生産的。そういう空気が、今のテック業界を覆っています。

この空気には名前がついています。「Tokenmaxxing」です。

Tokenmaxxingという病

Tokenmaxxingとは、AIワークフローにおいて可能な限り大きなコンテキストとトークンを投入し続ける行動パターンのことです。「より多くのトークンを使えば、より良い結果が出る」という直感に基づいています。

一見すると合理的です。AIは使わなければ価値を生みません。だから使う量を増やす。企業はその量を測定して評価する。エンジニアは評価されるために量を増やす。

しかし、これはかつてのLoC（Lines of Code）問題とまったく同じ構造です。コードの行数が多いエンジニアを「生産性が高い」と評価したら何が起きたか。無駄に長いコード、コピペの横行、リファクタリングの軽視。活動を成果と混同する罠に、業界はまた足を踏み入れようとしています。

The Pragmatic Engineerの著者Gergely Oroszは、この問題を正面から指摘しています。エンジニア自身は「20%生産性が向上した」と感じているのに、実測では平均30%低下しているケースがある、と。体感と実態の乖離。これがTokenmaxxingの本質的な危険性です。

Shopify CTOが突きつけた二項対立

では、どうすればいいのか。Shopify CTOのMikhail Parakhinが明快な回答を出しました。

「Depth over Breadth」——幅ではなく、深さを選べ。

Parakhinはこの二つを対比します。

幅（Breadth）= LLM Slot Machine。1つの問題に対してLLMを50回、100回、500回と並列で走らせる。どれか1つが当たればいい。スロットマシンのレバーを引き続ける発想です。コストは10倍に膨らみ、スループットは2倍にしかならない。しかも、500の結果から「当たり」を選ぶ判断力がエンジニアに求められます。数が増えれば増えるほど、人間はその判断を誤る。

深さ（Depth）= Serial Autoresearch Loops。仮説を立て、実験し、結果を評価し、改善する。このループを直列で深く回す。各ステップの出力が次のステップの入力になるため、理解が積み上がっていきます。さらにParakhinが強調するのは「critique loop（批判ループ）」の組み込みです。AIの出力を別のAIに批判させ、その批判を元のAIにフィードバックする。1回のやりとりではなく、何層もの検証を重ねる。

Shopifyは全社員にOpus 4.6の無制限予算を付与しました。ただし条件があります。「それ以下のモデルは使うな」。これは量的な制限ではなく質的なガードレールです。安いモデルで大量に回すのではなく、最高品質のモデルで深く掘れ、というメッセージなのです。

「コードを読んでください」——Vibe Codingの撤回

この「深さ優先」の流れを象徴するもう一つの出来事があります。

Context Engineering（コンテキストエンジニアリング）の提唱者として知られるDex Horthyが、6ヶ月前の自身の主張を公開撤回しました。かつて彼はVibe Coding——AIにコード生成を任せて「雰囲気」で進める手法——を全面支持していました。それを、公の場で取り消したのです。

撤回の理由は痛烈です。

「Vibe Codingは、コンパイル済みのJARファイルをチェックインしてソースコードを捨てるのと同じだ」

つまり、AIが生成したコードをそのまま受け入れることは、コードの理解を放棄することと等しい。動いているけれど、なぜ動いているのかわからない。修正が必要になったとき、手の打ちようがない。

Horthyが代わりに提唱するのが RPI（Research → Plan → Implement）ワークフローです。まず調査し、次に計画を立て、その上で初めて実装に入る。AIに「とりあえず書いて」と頼む前に、人間が問題を深く理解する。

そして彼が繰り返すフレーズが、これです。

「Please read the code.」

コードを読め。AIが書いたものであっても、いや、AIが書いたものだからこそ。

「Slow the fuck down」——現場のシニアは何を思っているか

業界にはもう一つ、興味深い対立軸があります。「Z/L Continuum」と呼ばれる思想的スペクトラムです。

L側に立つのはOpenAIのLopopolo。彼の立場はこうです。「コードそのものは負債だ。テストとプロンプトの修正に集中すべきだ」。つまり、AIが書くコードの詳細に人間が介入する必要はない。品質はテストで担保し、コード自体は使い捨てでいい。

Z側に立つのはPi Zechner。彼の主張は一言に凝縮されています。

「Slow the fuck down. Read every fucking line.」

立ち止まれ。一行一行読め。

過激に聞こえます。しかし、シニアエンジニアやテックリーダーの多くが、表向きはL側のポジションを取りつつ、私的にはZ側に共感していると言われています。実際にコードベースの品質に責任を持つ人間は、「読まなくていい」とは思えない。

これは個人の性格の問題ではありません。構造の問題です。AIが書くコードの量が増えるほど、レビューの負荷が上がる。レビューの負荷が上がるほど、一行一行を読む余裕がなくなる。余裕がなくなると、品質が下がる。品質が下がると、修正コストが増える。修正コストが増えると、さらにAIに頼る。

この悪循環を断ち切るには、最初のステップ——AIに書かせる量そのもの——を制御するしかない。つまり、深さを選ぶということです。

「人間がボトルネック」の真実

中島聡さんが指摘する構造も、ここに繋がります。

AIが書くのは実装だけ。要件定義、設計、レビュー、動作確認は人間の仕事です。実はAI時代の開発プロセスの大半は、人間のターンなのです。

「AIの作業を待つ時間より、AIが自分の指示を待つ時間の方が長い」

自分もClaude Codeを毎日使っていて、この感覚を強く持っています。AIは一瞬で500行のコードを出力する。でもそのコードを読んで理解し、次の指示を出すのに自分は10分かかる。ボトルネックは常に自分です。

だとしたら、解くべき問題は「AIをもっと速くすること」ではなく「自分の判断速度を上げること」です。そして判断速度を上げるには、浅く広くではなく、深く理解する必要がある。ここでもまた、Depth over Breadthに行き着きます。

自分のワークフローで実践していること

抽象論だけでは説得力がないので、自分のClaude Code運用の実例を書きます。

RPIワークフローの徹底。まずPlanモードで設計を固め、Exploreエージェントで既存コードを調査し、その結果を踏まえて実装する。「とりあえず書いて」は原則やりません。1つのコンテキストウィンドウの中で、理解を段階的に積み上げていく。これがSerial Autoresearch Loopの個人版です。

モデルの使い分け。サブエージェントを起動する際、タスクの性質に応じてモデルを選びます。コードベースの検索にはhaiku（高速・低コスト）、設計レビューにはsonnet（バランス型）、複雑なアーキテクチャ判断にはopus（最深推論）。配分はおよそ6:3:1。全部をopusで回すのは「幅」の発想であり、タスクの性質に合わせてモデルを選ぶのが「深さ」の発想です。

token-efficiency.mdという運用ルール。自分はClaude Codeの設定ファイルに、トークン効率のルールを明文化しています。「ファイル全体を読む前にGrepで必要箇所を特定する」「コンテキストの80%を超えたら大規模リファクタリングを開始しない」。こうした制約を事前に設けることで、無意識のTokenmaxxingを防いでいます。

critique loopの実装。コードを書いた後、別のサブエージェントにレビューさせる。「このコードを承認する前に、問題点を3つ挙げて」と指示する。自分自身の目だけでなく、AIの目も使って深さを確保する。ただし、最終判断は自分がします。

Tasteful Tokenmaxxingとは何か

Parakhinが使った「Tasteful Tokenmaxxing」という表現が秀逸です。「tasteful」は「趣味の良い」「センスのある」という意味。トークンを使うな、とは言っていない。使い方にセンスを持て、と言っている。

たとえるなら、料理です。塩を振れば味が出る。だからといって塩を大量に振れば美味しくなるわけではない。適切な量を、適切なタイミングで、適切な食材に。これが「tasteful」です。

AIも同じ。トークンを投入すれば成果が出る。だからといって大量に投入すれば良いわけではない。適切なモデルを、適切なフェーズで、適切な問題に。深さを伴った投入だけが、意味のある成果を生みます。

あなたは今日から何をすべきか

この記事を読んだ後、具体的に何が変わるべきか。3つ提案します。

1. 「とりあえずAIに聞く」をやめる。問題を自分で言語化し、調査し、仮説を立ててからAIに渡す。AIの仕事は「あなたの代わりに考えること」ではなく「あなたの思考を加速すること」です。

2. AIが書いたコードを読む。全行読む必要はありません。でも、構造は理解する。なぜこの実装になったのかを説明できる状態にする。説明できないコードをマージしない。

3. 消費量ではなく解決した問題の数を数える。今日何トークン使ったかではなく、今日何個の問題を解決したか。この指標の切り替えだけで、行動が変わります。

AIの民主化が進み、誰もが同じモデルにアクセスできる時代になりました。差がつくのは「何を使うか」ではなく「どう使うか」です。

深さを選んでください。それが、2026年のAI活用で最もリターンの高い戦略です。