Boris Cherny はもう Claude にプロンプトを送っていない。
これは、誰かが広めた受け売りの言葉ではない。本人が公の場で正式に発言として記録したものだ。「私はもう Claude にプロンプトを送っていない。Claude にプロンプトを送り、次に何をすべきかを判断するループを走らせている。私の仕事はループを書くことだ」。彼はこれを、Sequoia のトーク、Acquired のインタビュー、Y Combinator の Startup School など複数の公開の場で繰り返し述べており、その根底にあるパターンこそが、この記事の本当のテーマである。ヒント集ではない。機能リストでもない。Claude Code を作った本人が、実際に日々どのように使っているのかという具体的な方法を、他人の受け売りではなく、本人の公の発言に照らして検証したものだ。
これは、Cherny が実際に語った内容と、彼が作ったツールに対する Anthropic 自身が公開しているベストプラクティスに基づく完全な解説である。
Claude Code はそもそも製品になるはずではなかった
Cherny の使い方を理解するには、まずこのツールの出自を理解する必要がある。なぜなら、その起源が設計思想を説明してくれるからだ。そしてそれは、現在このツールを使っている多くの人が認識している以上に興味深いストーリーである。
Claude Code は 2021 年、製品としてではなく、AI 安全性のアライメント研究プロジェクトとして始まった。粗削りな VS Code 拡張機能、その後 clide と呼ばれる社内 CLI ツールとして、社外の誰もその存在を知らないまま、Anthropic 内部で何年も使われていた。Cherny は 2024 年 9 月にこのプロジェクトへ加わり、同年 12 月の 2 週間のスプリントでコアを再構築した。2025 年 2 月の一般公開は静かに行われ、大きな話題にはならず、興奮というよりは肩をすくめるような反応だった。その後 Claude 4 がリリースされ、採用はほぼ一夜にして爆発的に拡大した。
現在のツールの立ち位置に関する彼自身の評価は、こう明言されている。「まだ 1% しか完成していない」。
この捉え方は、このツールへの向き合い方を左右する。Cherny は、固定された正しい使い方がある完成品を説明しているわけではない。彼が説明しているのは、ツールを使ってツールを作っているチームによって、今まさに積極的に再構築されているものだ。Claude Code は Claude Code 自身を使って繰り返し書き直されてきた。「ループエンジニアリング」という言葉が公に使われるようになる以前から存在していた、自己改善のループである。これは少し立ち止まって考える価値がある。なぜなら、多くの新規ユーザーを困惑させる疑問、すなわち「このツールの『正しい』使い方はなぜ更新され続けるのか」を説明してくれるからだ。これは矛盾ではない。作り手自身が、このツールを使って、このツールが実際に何ができるのかをリアルタイムでまだ発見している最中なのだ。
製品になる前に社内研究ツールとして何年も使われてきた歴史は、なぜ以下の設計思想の多くが、開発者向けソフトウェアとしては異例なほど主張が強いのかも説明している。ほとんどのツールは、初日から競合するニーズを持つ幅広い外部ユーザーベースを満たすために機能を積み重ねていく。Claude Code は、他の誰かのワークフローを満たす必要が生じるずっと前に、自分たちの問題を解決する小さなチームの中で、まず設計思想を蓄積した。だからこそ、一般的な「AI コーディングツール」のアドバイスではなく、Cherny 個人の具体的な使い方を理解することに、時間をかける価値があるのだ。
核心となる転換:プロンプト入力からループ設計へ
Cherny が Claude Code の実際の使い方について公に語った中で最も重要なことは、上記のループに関する発言であり、それが実際に何を意味するのかを、単なる引用に留めず実践的に掘り下げる価値がある。
プロンプトは、一度送信され、一度回答される単一の指示である。ループはシステムである。Claude にプロンプトを送り、返ってきた結果を評価し、次に何が起こるかを決定し、それを繰り返す。毎回のサイクルに人間が介在する必要はない。Cherny が明言した職務内容、「私の仕事はループを書くこと」は、彼がプロンプトを一つずつ自分で入力するのではなく、プロンプトを生成・評価するシステムの設計に時間を費やしていることを意味する。
彼の確認されている日々のワークフローは、これを直接反映している。ノートパソコンのキーボードではなく、スマートフォンを主要インターフェースとして使用。一度に 5〜10 のアクティブセッションを同時に実行し、それぞれがサブエージェントを生成でき、時には一度に数百、より深い作業では夜間に数千ものサブエージェントを実行する。数十のループがバックグラウンドで継続的に実行され、プルリクエストの監視、継続的インテグレーションの健全性維持、フィードバックの定期的なクラスタリングを行う。ノートパソコンを閉じてもサーバー側で持続するルーチンもある。
日々 Claude Code を使う人への実践的な教訓:このツールができることの上限は、単一のプロンプトがどれだけ優れているかで決まるのではない。プロンプト、チェック、再試行の自動化されたサイクルを繰り返すシステムを、どれだけうまく設計できるかで決まるのだ。
システムプロンプトで実際に変わったこと、そしてそれが重要な理由
Cherny は、Claude への指示の与え方についての考え方を示す、具体的かつ技術的な決定についても直接語っている。「私たちは最新モデル用の Claude Code システムプロンプトの約 80% を削除しました。これがシステムプロンプトの書き方について私たちが学んだことです」。
この削減は Opus 4.8 世代で具体的に行われ、システムプロンプトは約 15,000 文字から約 4,500 文字に縮小されたが、コーディング評価では測定可能な損失はなかった。この背後にある教訓は、Anthropic 自身のコンテキストエンジニアリングのガイダンスによれば、モデルが真の判断力を発揮できるほど十分に能力を持つようになれば、厳格で網羅的なルールリストは不要になるということだ。ルールは判断に変わる。ツール使用例は、自己文書化するように設計されたインターフェースに置き換わる。事前の網羅的なコンテキストは、プログレッシブディスクロージャー（段階的な開示）に置き換わり、情報はすべてのセッションにデフォルトで読み込まれるのではなく、特定の状況で実際に必要になったときにのみ表面化する。
このストーリーの単純なバージョンを複雑にするため、正直に含めるべきニュアンスが一つある。Opus 5 がリリースされたとき、独立した開発者によるテストでは、実際のシステムプロンプトは Opus 4.8 より約 72% 長くなっていた。これは上記の教訓への矛盾ではなく、より深いバージョンである。プロンプトは厳格な指示量としては縮小したが、その後、より豊かで具体的な参照情報、実例、テストスイート、評価ルーブリックなど、真により高い能力を持つモデルが実際に活用できる種類のコンテキストとして再び増加した。ここから得られる教訓は「短ければ常に良い」ではない。指示量は、特定のモデルが適切な判断を下すために実際に必要とするものに追従させるべきであり、どちらの方向にも固定目標を設定すべきではないということだ。
Anthropic のチームと同じように CLAUDE.md を書く
これは、プロジェクトレベルの指示をどのように構成すべきかに直接つながる。Anthropic 自身の公式ドキュメントは、使用すべきメンタルモデルを明確に述べている。Claude を、記憶喪失の、非常に有能だが新人の従業員のように考え、明示的な指示が必要だと考えよ。
この捉え方の実践的な意味。有能とは、一般的な能力を過剰に説明する必要がないということ、それはすでに備わっている。新人とは、あなたのプロジェクトの歴史や慣習に関する蓄積された知識がゼロであることを意味する。記憶喪失とは、すべてのセッションが毎回ゼロから始まり、CLAUDE.md だけがセッション間で確実にコンテキストを引き継ぐ唯一の手段であることを意味する。
Anthropic が文書化したガイダンスでは、このファイルを 200 行未満に抑えることを目標としており、最も規律あるチームの中には 60 行程度まで減らしているところもある。ファイルに何を含めるべきかのテスト基準は、これがほぼすべてのセッションに真に関連するものか、それとも狭い特定の作業にのみ関連するものかである。ビルドコマンド、絶対的なスタイルルール、テストの期待値、真のガードレールなど、普遍的なものはルートファイルに属する。それより狭いものは、ツールが直接サポートする @path/to/file インポート構文を使用して、セッションの特定の作業で実際に必要になったときだけコンテキストに取り込まれるインポートファイルに属する。
本当に省略できない指示については、Anthropic の社内プラクティスでは、「IMPORTANT」や「YOU MUST」という明示的な強調マーカーを使用し、Claude がそれを見逃した場合のコストが本当に高い、一握りのルールに限定している。すべてをこの方法でマークすると、無差別に適用された瞬間にシグナルとして機能しなくなるため、目的を完全に損なう。
プランモード:行動する前に理解する
ツールの実際の使い方に組み込む価値のある具体的な行動パターン:Claude に実行前に計画を立てさせること。いきなり変更に飛びつかせない。
これは単なる機能トグルではない。Anthropic の資料が説明する実際の変化を反映している。新しいモデルは、以前のモデルのように手厚い事前誘導を必要とせずに正しく計画を立てることができ、チームによっては、あらゆるタスクに明示的なプランモードのステップを強制する必要がなくなったと報告しているところもある。なぜなら、モデル自身のデフォルトの推論が、行動する前にすでに一貫した計画を生成するからだ。とはいえ、本当に複雑な複数ファイルにわたる変更では、先に明示的に計画を要求し、実行を承認する前にそれをレビューすることは、引き続き有意義に有用なチェックポイントであり、誤解した要件が多数のファイル編集に波及する前に発見できる。
サブエージェントと並行作業
Cherny が確認した、1 セッションで数百、時には数千のサブエージェントを実行するワークフローは、理解し、偶然ではなく意図的に使用する価値のある構造的な能力を示している。
メインエージェントは複雑なタスクをより小さな部分に分解し、サブエージェントを展開してそれぞれを独立して実行させることができる。それぞれが独自のコンテキストで作業するため、すべてが 1 つの連続した会話のスペースを競い合うことはない。これは同時に 2 つの目的を果たす。単一のコンテキストウィンドウをあふれさせるような作業を、より小さな複数のウィンドウに分散して実行できるようにする。さらに、実際の検証層を追加する。なぜなら、別のエージェントの出力をレビューするサブエージェントは、自分自身が生成したものではない作業をチェックしていることになり、エージェントが自分で生成したのと同じ文脈で自分の成果を採点するよりも、構造的に信頼性が高いからだ。
特に並行作業では、git worktree を使用すると、複数のセッションが別々のブランチやディレクトリで同時に作業でき、あるセッションの進行中の変更が別のセッションを妨げることがない。これは、Cherny が個人的に行っていると説明するように、多数の並行ループを実行するための機械的なインフラストラクチャであり、単一のエージェントがより速く作業するのではなく、多数のエージェントが本当に別々の作業を同時に実行することを可能にする。
grep への決定:複雑さよりもシンプルさのケーススタディ
Cherny のチームによる、よく文書化された具体的な技術決定の一つは、内面化する価値のあるより広い哲学を示している。Claude Code は、コードベース検索のベクトル検索とエンベディングをやめ、素の grep と glob を採用した。その結果についての彼自身の言葉は次の通りだ。「すべてを凌駕した。圧倒的に」。
この教訓は、この特定の決定を超えて一般化できる。より高度な響きのソリューションであるセマンティックベクトル検索は、より単純なソリューションである grep が実際に問題にうまく適合している場合、自動的に優れているわけではない。コードベースには正確な構文、正確な関数名、正確なインポートパスがあり、grep が得意とする正確でリテラルなマッチングの種類であり、ファジーなセマンティックマッチは、もっともらしいが間違った結果を表面化させることで、実際に妨げになる可能性がある。
独自のワークフローを構成する際の実践的な教訓:複雑さは能力を意味するという前提で、より複雑に聞こえるツールやアーキテクチャをデフォルトにしないこと。まず実際のユースケースでシンプルな選択肢をテストすること。多くの場合、シンプルな方が勝つ。たとえ勝たなくても、複雑なアプローチがその地位に値することを推測ではなく確認したことになる。
エージェントに自分の仕事を採点させてはいけない
Anthropic 自身のハーネスエンジニアリングのプラクティスから確認された別の原則で、独自の Claude Code ワークフローで検証ステップを構成する方法に直接関連するもの:生成と評価は真に別々の役割で行われるべきである。なぜなら、モデルが自分の出力を生成したのと同じ文脈でレビューすると、たとえ人間のレビューアーがすぐに欠陥を見つけられる場合でも、肯定的な方向に偏る傾向があるからだ。
実際には、これはコードを書くエージェントが、そのコードがリリースに十分かどうかを判断するパスと同じであってはならない、ということを意味する。別の評価ステップ、理想的には生成エージェントが持っていなかったもの、実際のテストスイートの出力や元の要件文書などへのアクセスを備えたものが、自己評価が見逃すものを捉える。これは、上記のサブエージェント検証パターンの背後にあるのと同じ原則であり、特定の機能ではなく一般的な規律として適用される。
努力レベルとコンテキスト管理
より長く、より要求の高いセッションを実行する人にとって、努力レベルを直接シグナルする方法を理解することは重要である。プロンプトに「ultrathink」を含めると、より広いセッション設定を変更せずに、その特定の応答に対して最大の推論深度をシグナルする。セッションレベルの自動ワークフローオーケストレーションでは、努力レベルを最高ティアに設定すると、セッション全体での自動タスク分解と深い推論が組み合わされる。ただし、これにはその努力ティアを実際にサポートするモデルが必要であり、すべてのモデルがサポートしているわけではない。
コンテキスト管理自体は、長時間のセッションでは意図的な注意に値する。セッションが長くなるにつれ、蓄積されたコンテキストが、今本当に重要なことのシグナルを薄め始める可能性がある。これは、肥大化した CLAUDE.md ファイルが生み出すのと同じ問題であり、ファイル内で静的に発生するのではなく、単一の会話内で動的に発生しているだけだ。新しい作業フェーズに本当に移行したときは、1 つの会話を無限に延長するのではなく、定期的に新しいセッションを開始することが、実践的で価値のある規律であり、コンテキストが多ければ必ず良いと想定するのではなく、適用する価値がある。
実例:実際のタスクへの適用
上記すべてを抽象的なものではなく具体的にするために、実際の一般的なタスクにこれらの原則がどのように組み合わさるかを示す。既存のコードベースに、適度な複雑さ、いくつかの相互接続されたファイル、いくつかの既存テストを含む、簡単ではないが特別ではない変更として新しい機能を追加する。
まず、CLAUDE.md がすでに配置されている状態から始める。短く、普遍的で、ビルドコマンドとテストコマンド、絶対的なスタイルルールが含まれ、状況依存のものは何も散らかっていない。これは、セッションが、プロジェクトの慣習をゼロから説明し直すことなく、実際に関連するコンテキストが自動的に読み込まれた状態で始まることを意味する。
機能全体を網羅的な詳細で説明する単一の長い希望的プロンプトを書く代わりに、目標を説明し、モデル自身の計画に分解を任せる。上記のシステムプロンプトの議論からの、足場を減らす哲学を信頼する。この規模のタスクでは、最初に明示的に計画を要求することは、追加ステップの価値がある。なぜなら、ここで発見された誤解された要件は、2 分の修正で済むが、後で複数のファイルにわたる変更を元に戻すのに 1 時間かかる可能性があるからだ。
計画が正しく見えたら、実行を進めさせる。タスクが自然に真に独立した部分に分割される場合、たとえばデータモデルの更新と、それを消費する UI の更新を別々に行う場合などは、サブエージェント分解の自然な候補であり、各部分が独自のコンテキストで作業し、すべてが単一の連続した会話に押し込められない。
結果を完了として扱う前に、実装エージェント自身の自己申告を信頼するのではなく、別の検証パスを実行する。これは、新しいセッション、または読み取り専用アクセスを持つサブエージェントが、実際のテスト出力と元の計画に対する差分をチェックするのと同じくらい簡単で、コードを書いたのと同じコンテキストからの自信に満ちた「これは完了です」をただ受け入れるのではない。
このウォークスルーに何が欠けているかに注目してほしい。風変わりなツールはない。異常な設定もない。単に、本当に複雑な作業にはプランファースト、本当に独立した部分にはサブエージェント分解、自己評価ではなく分離された検証、という上記すべてに貫かれる 3 つの原則を、抽象的に説明する代わりに 1 つの具体的なタスクに適用しただけである。
これを一人の枠を超えてスケールする
上記のすべては、Claude Code を意図的に使用する一人の人のためのプラクティスを説明している。Cherny 自身が確認したワークフロー、毎日数百のサブエージェント、夜間に数千、はそれ自体がすでにスケーリングの一形態であり、一人の人間が本当に大規模な並行・自動化された作業を指揮している。しかし、同じ原則は、チームがこれらのプラクティスを一緒に採用する場合にも拡張される。直接言及する価値のあるいくつかの具体的な考慮事項がある。
CLAUDE.md は、チームの複数のメンバーが Claude Code で同じコードベースに対して実際に作業し始めた瞬間に、個人の好みファイルではなくなる。チーム全体のワークフローに影響を与える共有設定に適用するのと同じレビュー規律で、それへの変更を扱うこと。チームメイトが、レビューなしで、1 回の苛立たしいセッションの後に一度きりの「ホットフィックス」指示を追加することは、実際に確実に従われなくなる肥大化した自己矛盾するファイルを生み出す、まさにそのメカニズムである。軽量なレビューステップ、マージ前に別の人が差分をちらりと見るだけであっても、それが実際の問題に蓄積される前に、意味のある割合を捕捉する。
検証規律は、ソロユーザーよりもチーム規模でさらに重要である。一人が自分のエージェント支援作業を書いてレビューしている場合、エージェントが見逃した何かを個人的に発見できる可能性が少なくともある。チームが共有レビュープロセスを通じて流れる Claude Code の出力に依存している場合、前述の分離評価原則はもはやオプションではなく、エージェントの自信に満ちた誤った自己評価が本番に到達するのを防ぐ実際のメカニズムである。なぜなら、代替案は、忙しいチームのワークフローのどこかの時点で、エージェントが自分でフラグを立てなかったものを、何らかの人間がたまたま発見することに依存することになるからだ。
定期的な CLAUDE.md 監査の明示的な所有権を確立する価値もある。これは、共有され蓄積されていくあらゆるドキュメントに推奨されるのと同じメンテナンス規律である。明確に割り当てられた所有者がいなければ、この作業は、壊れたビルドのように単一の差し迫ったタスクをブロックしないという理由で、まさに隙間から落ちていく傾向があり、6 か月間放置された追加は、普遍適用性の原則がそもそも防ごうとしている、まさにその種の肥大化した矛盾したファイルを生み出す。
これらの原則が誤って適用されるケース
上記のアイデアに対するいくつかの特定の誤読が繰り返し現れる。それぞれに単純で具体的な修正があるため、直接言及する価値がある。
「プロンプトよりループ」を、タスクの理解を完全にスキップする許可として扱うこと。 Cherny 自身の発言は、彼の仕事はループを書くことであり、ループが実際に何をすべきかを考えるのをやめたわけではない。良いループ、良い成功の定義、良い停止条件を設計することは、良い単一のプロンプトを書くのと同じくらい、問題を明確に理解することを依然として必要とする。ループは繰り返される手動タイピングを置き換えるのであって、事前の思考を置き換えるのではない。
システムプロンプト削減を「常にモデルに与えるコンテキストを減らす」と読むこと。 この記事の前半の Opus 5 の反例は、まさにこの誤読を修正するために存在する。実際の教訓は、指示量は、特定のモデルが適切な判断を下すために本当に必要とするものに一致させるべきであり、それは時にはより少ない厳格なルール列挙を意味し、時にはより豊かで具体的な参照資料を意味する、ということだ。「最新モデルはより少ないコンテキストを必要とする」という理由で無差別にコンテキストを削減することは、ニュアンスのあるモデル固有の発見を包括的なルールとして誤って適用している。
習慣で単純なタスクをサブエージェントに過度に分解すること。 サブエージェント分解は、本当に大規模で、本当に独立した作業に対してその複雑さに値する。小さな、緊密に結合された変更を、パターンを使うためだけに人為的なサブエージェント部分に分割することは、大規模なタスクでそれを正当化する利益なしに、調整オーバーヘッドを追加する。この記事の前半の実例は、部分が自然に独立している場合にのみ意図的にサブエージェントを使用し、サイズに関係なくすべてのタスクのデフォルトとしては使用しなかった。
「新しいモデルはもうそれを必要としない」という前提で検証をスキップすること。 分離評価の原則は、能力が向上するにつれて不要になる、より弱いモデルのための回避策ではない。これは自己評価に関する構造的な事実であり、モデルが自分の作業を生成したのと同じコンテキストでチェックすることは、基礎となるモデルがどれほど能力を持つようになっても、独立したチェックよりも自分のブラインドスポットを発見するのが常に難しい。これは人間のレビューアーにも当てはまり、レビューアーが賢くなるからといって、それが当てはまらなくなるわけではない。
実際に採用する価値のある日々の習慣
上記のすべてを具体的で実践的な日々の習慣にまとめると、Cherny が実証したアプローチに実際に従うことは次のようになる。
すべてのタスクを最初の試行で正しくする単一のプロンプトとして扱うのをやめる。代わりにループを設計する:タスクを試行するエージェント、試行が成功したかどうかをチェックする方法、そしてそのチェックに応じて次に何が起こるか(合格、再試行、またはあなたへの直接エスカレーション)の定義されたパス。
CLAUDE.md を短く保ち、包括的なマニュアルではなく、能力はあるがコンテキストのない新入社員のためのオンボーディング資料として扱うこと。状況依存のものは、ルートドキュメントを肥大化させる代わりに、インポートファイルに移動する。
本当に複雑な複数ファイルの作業にはプランモードを意図的に使用し、より単純で明確にスコープされたタスクでは、習慣ですべての場所に余分なステップを強制するのではなく、モデル自身のデフォルトの計画を信頼する。
大規模なタスクを、単一の連続した会話に複雑なタスク全体を保持しようとするのではなく、別々のコンテキストで作業するサブエージェントに分解する。単一のエージェントの自己評価を信頼するのではなく、別のパスを使用して重要な作業を検証する。
特定の問題を解決できる可能性のある最も単純なツールをデフォルトにすること。grep がこの正確なユースケースでベクトル検索に勝ったように、シンプルな選択肢が実際にテストされて不足していると判明した場合にのみ、より複雑さに手を伸ばす。
git worktree を使用して、本当に独立した作業に真の並列性をワークフローに組み込む。それがデフォルトの作業方法だからという理由で、すべてを 1 つの順次セッションで実行するのではなく。
この先にあるもの
Cherny 自身の「まだ 1% しか完成していない」という捉え方は、謙虚に聞こえる言葉としてではなく、実践的な発言として真剣に受け止める価値がある。上記で説明した具体的なパターン、単一のプロンプトよりもループ設計、モデルがより能力を持つにつれての積極的なシステムプロンプト削減、サブエージェント分解、分離検証は、固定された最終的な方法論ではない。それらは、その作成者自身がまだ初期段階にあると説明するツールとプラクティスの現在の状態である。
実際に構築する価値のあるスキルは、今日の特定のベストプラクティス構成を暗記することではない。ツール自体が変化し続けるにつれて適応し続けるのに十分なほど、基礎となる原則を理解することである。Cherny 自身のチームが Claude Code を使って Claude Code を繰り返し再構築し、ループを完成形として扱うのではなく洗練し続けたのと同じ方法で。
それがこの記事のすべてをつなぐ本当の一本の糸である。静的なヒントのリストではなく、実践的な哲学:単一の指示を入力する代わりにシステムを設計し、指示を引き締めて、モデルの能力が向上するにつれてより多くの作業をモデルに任せ、自己評価を信頼するのではなく独立して検証し、複雑さが実際に必要であることを証明するまでシンプルさをデフォルトにする。ツールを作った本人がどのようにそれを使っているか、その本人から直接。
@cyrilXBT をフォローして、検証済みの公式発言に基づく Claude Code の詳細な解説をさらにチェックしよう。
