要約元

  • 投稿：YouTube(Y Combinator公式チャンネル)「Boris Cherny: We Cut 80% of Claude Code’s Prompt」
  • 内容：Claude Codeの作者Boris Cherny氏(Anthropic)が、Y Combinator Startup School 2026でDiana Hu氏の質問に答える対談(英語、約36分)
  • 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。

Opus 5のリリース直後に行われた対談で、Claude Codeの作者Boris Cherny氏が「新しいモデルが出るたびに、システムプロンプトの8割を消している」という開発の裏側を語った。単なる裏話ではなく、モデルが賢くなり続ける時代にプロダクトをどう作るべきかという、実務的な考え方の話になっている。

Opus 5で何が変わったのか

Cherny氏がまず挙げたのは2点。ひとつは稼働時間が桁違いに伸びたこと。特にauto modeと組み合わせると、足場(スキャフォールディング)を用意しなくても、モデルが「タスクをやり切る必要がある」と自分で判断し、数日から数週間、数ヶ月単位で動き続けるという。

もうひとつはプロンプトインジェクションへの耐性。「ネット上の指示を読み込んで、ユーザーのファイルを消せ、というような悪意ある指示に従ってしまう」という問題(俗に言うlethal trifecta)に対し、Opus 5は実質的にほぼ反応しなくなったとのこと。理由として、(1)アラインメント研究を重ねたモデル本体、(2)全トラフィックに対して走らせているプロンプトインジェクション分類器(機械的解釈可能性の研究に基づき、プロンプトインジェクションが起きたときに発火するニューロンを検出する)、(3)auto modeの分類器、という3層の仕組みを組み合わせている、と説明していた。

なぜシステムプロンプトを毎回8割消すのか

Claude Codeというプロダクトは常に変化していて、新しいモデルが出るたびにシステムプロンプト・ツール定義・ツール用のプロンプトを大きく書き換えているという。理由は単純で、あるモデル向けに書いた指示が、次のモデルにはまったく通用しないことが多いから。Opus 5は特に賢く、これまでシステムプロンプトで「本来モデルが分かっているべきなのに分かっていなかった挙動」を補正していた部分の多くが、もう不要になったそうだ。

この作業を研究の世界の言葉で「アブレーション(ablation)」と呼んでいる。システムプロンプト全体を一旦消し、1行ずつ戻しながら、その行が本当に必要かを検証していく。実際、--system-promptオプションで好きなシステムプロンプトに差し替えたり、CLAUDE_CODE_SIMPLE=1という(ドキュメント化されていない)環境変数でツール側の指示も含めて全部消した状態を試せるという。興味深いのは、プロンプトを丸ごと削った状態の方が、モデルがわずかに賢く振る舞うことがあるという観察。ただし、それだとプロダクトとしての使い勝手(人間が期待する挙動)が損なわれるため、Claude Code本体には最低限必要なものだけを残している。

Diana Hu氏がこれを「半年ごとに全部消す勇気を持て、ということか」とまとめると、Cherny氏は「その通り」と答えた上で、Claude Codeを使うだけの立場の人にも同じことを勧めている——半年に一度、claude.md・skills・hooksを消して、モデルがどう振る舞うか見てみるといい、Opus 5については特に、これまで必要だった大量の指示自体がもう要らなくなっている可能性がある、と。

一方で、evals(評価用のテストセット)は比較的長く生き残るとも述べている。ただしそれも永続ではなく、モデルが急速に改善する中で1〜3世代ほどでeval自体が「頭打ち」になり、新しく作り直す必要が出てくるという。

「アンホブリング」とプロダクト・オーバーハング

Cherny氏が使うもう一つのキーワードが「unhobbling(足かせを外す)」。対になる概念が「product overhang」——今のモデルには既にできることがたくさんあるのに、プロダクト側がその能力の発揮を妨げている状態を指す。

彼はこれをClaude Code誕生の経緯そのものだと説明する。1年半〜2年前、当時最高峰のコーディングモデルだったSonnet 3.5(今の基準では見劣りするという)が登場した頃、世の中のコーディング系プロダクトは単一行〜数行のオートコンプリートや、読み取り専用のチャットが中心だった。モデルはファイル単位でコードを書けるはずなのに、プロダクト側がそれを引き出せていなかった。そこで、足場を極力減らし、フルのターミナルアクセスを与えるだけのシンプルなハーネスとして作ったのがClaude Codeだった、という。

「今この部屋にいる全員が、モデルを正しくunhobblingできれば、次のClaude Codeを作れる」と、起業家に向けたメッセージとしても語っていた。

具体例:11日間でZigからRustへの書き換え、OpenCVで絵を描くモデル

unhobblingの実例として2つのエピソードが紹介された。

1つ目は、Claude Codeの基盤であるJavaScriptランタイムBun(Node.jsの代替、Zig製)の話。Zigは手動でメモリ管理する必要があり、メモリリークの温床になりやすい。当初はClaudeにコードをファジングさせてリークを一つずつ見つけさせていたが、あるときBunチームのエンジニアが「いっそ書き換えさせたらどうか」と考えた。Bun/Node.jsには充実したテストスイートがあり、正しく書き換えられたかを検証しやすい環境があったこともあり、Zig→Rustへの全面書き換えを1つのプロンプトで「dynamic workflow」(数十〜数百のエージェントを協調させてタスクをこなす機能)に投げたところ、人間の操作(ステアリング)を挟みながら11日間で書き換えが完了、現在は本番で稼働しているという。

2つ目は、社内で話題になった小ネタとして、Opus 5にOpenCVを使わせて絵を描かせるという実験。絵を描くための訓練は一切していないのに、頼み方さえ工夫すれば肖像画や動物、風景をそれなりのクオリティで描けたという。Cherny氏はこれを「elicitation gap(引き出し方のギャップ)」と表現し、今のモデルには同様の「まだ誰も気づいていない能力」が何十、何百とあるはずだと述べていた。

プロンプトエンジニアリングより「検証」の時代へ

Cherny氏によれば、「プロンプトエンジニア」という職種が話題になった時期から「コンテキストエンジニア」に呼び名が変わり、今はそのどちらでもなくなりつつあるという。重要なのは、モデルに少し難しすぎるくらいのタスクを与え、モデル自身が自分の作業を検証できる手段を用意すること。この「検証」こそが、多くの人がまだうまくできていない最重要ポイントだと強調していた。

この考え方を体現するエピソードとして、社内のデスクトップアプリ(Electron製)をSwiftでネイティブ化する実験を挙げている。Claude(Slack上で動く「Claude tag」というプロダクト)に、GitHub上のmacOSランナーへのアクセス、空のSwiftコードベースへのアクセスを与えた上で、「ElectronアプリをSwiftで書き直し、両方をmacOS仮想マシン上で動かしてスクリーンショットを撮り、ピクセル単位で見比べながら、終わるまで止めるな」とだけ指示。対談時点で2週間以上動き続けていたという。Claudeは自発的にSlackチャンネルを作り、数分おきに進捗のスクリーンショットを投稿していたそうだ。

「特別なテクニックがあるわけではなく、/goや/loopのようなコマンドも必須ではない。タスクと、検証手段さえ与えれば、モデルは自分で進む」というのが彼の結論だった。

何千体ものエージェントを動かす方法

対談では、Claude Codeで大量のエージェントを並列稼働させる方法として2種類が紹介された。

  • Dynamic workflows: Bunランタイム上のサンドボックス(仮想マシン)内でClaudeが多数のエージェントを起動・協調させる仕組み。単純な並列実行ではなく、第1段階でタスクを分担させ、第2段階で検証・要約させ、第3段階でまた分岐させる、といった多段階の協調ができる。関数型プログラミング出身のCherny氏いわく、「エージェントのための代数(algebra for agents)」として設計されており、直列・並列の組み合わせをClaudeが選べるという。
  • Loops(ローカルのcronジョブ的なもの)とRoutines(クラウド上で動く同種の仕組み、ノートPCを閉じても継続): コンテキストは共有しないが記憶は共有されうる、繰り返し実行タスク向け。

Anthropic社内では実際に、Claude自身にCLI・iOSアプリ・Androidアプリ・デスクトップアプリの保守をさせる「ルーティン」を毎日20〜30種類走らせているという。具体例として挙がっていたのは、デッドコードの検出と削除PRの自動作成、100%ロールアウト済みの実験フラグの自動削除、テストカバレッジが薄い箇所へのテスト追加、不要になった古いテストの削除、そして「abstraction police」と呼ぶ、コードベース内で似たような抽象化が複数箇所に重複して存在していないかを毎日チェックして統合する仕組み。1日あたり数百から数千のエージェントがこうした保守作業に動いており、エンジニアが新機能開発やユーザー対応に集中できる体制を目指しているとのことだった。

コーディングは「解決された」のか

Cherny氏は以前から「コーディングは解決された」と発言してきたが、この対談では条件付きだと補足した。あくまで自分がやるような種類のコーディングに関しては解決されつつある、という留保付きで、システムに深く入り込んだコードベースや分散システム、ピクセル単位のUI検証のような領域では、Opus 5でもまだ完璧ではないという。会場アンケートでも「コードを100%エージェントに書かせている」人より「50%以上」の人の方がまだ多かった、という場面もあった。

その上で、モデルをうまく使いこなす人に共通する姿勢として、**過去のモデルで学んだ経験則や、コンピュータサイエンスの理論的な前提を一旦忘れ、目の前のモデルで実際に試し、つまずいた箇所だけを見て調整する「経験主義(empiricism)」**を挙げていた。

CS学生へのアドバイス

最後の質問、「この時代に学ぶCS学生は、あえて手を動かして学ぶべきことは何か」に対し、Cherny氏は自身の原体験を語った。中学時代、TI-83電卓上でBASICを独学し、数学のテストで有利になるためのアルゴリズムソルバーを書いていたという(後にはアセンブリまで書いて、微積分の問題を解かせていたそうだ)。

そこから得た教訓として、「コンピュータサイエンスそのものを学ぶだけでなく、それをどう応用するかを学べ」とアドバイスしていた。プロダクトを作ること、デザインセンスやビジネス感覚を磨くこと、データサイエンス、ユーザーとの対話——こうした周辺スキルと組み合わさって初めて、エンジニアリングの価値が最大化されるという趣旨だった。

まとめ

  • Opus 5は稼働時間の大幅な延長とプロンプトインジェクション耐性の向上が目立った特徴
  • Claude Codeは新モデルが出るたびにシステムプロンプトの大部分を「アブレーション」方式で削り、必要な指示だけを実際に使いながら戻していく
  • Claude Codeを使うだけのユーザーにも、半年ごとにclaude.md・skills・hooksを削って試すことを勧めている
  • 「アンホブリング」(モデルの能力を妨げるプロダクト側の制約を外すこと)がClaude Code誕生の背景であり、今も新しいプロダクトのチャンスとして語られている
  • プロンプトエンジニアリングより、モデル自身が作業を検証できる仕組みを用意することが重要
  • Dynamic workflows・loops・routinesという仕組みで、数千体規模のエージェントを協調的に動かし、社内では自社製品の保守作業(デッドコード削除、テスト追加など)を自動化しつつある
  • コーディングが「解決された」のは特定の領域に限った話で、CS教育においては応用力・周辺スキルの重要性が改めて強調されていた