Claude Codeのシステムプロンプトを80%削除した話——Boris Cherny
新しいモデルが出るたびに、Claude Codeのシステムプロンプトは大量に削除されます。Opus 5では8割を消しました。作者のBoris Chernyさんが、モデルの「足かせを外す(unhobbling)」という考え方、11日間でBunをZigからRustへ書き換えた話、そして数千のエージェントを走らせる使い方までを語ります。
この記事について
この記事は、YouTube動画「Boris Cherny: We Cut 80% of Claude Code’s Prompt」(Y Combinator さん)を視聴し、要点を自分の言葉でまとめたものです。
元動画: https://www.youtube.com/watch?v=qyPCVqFUyDo
こんな人におすすめ
Claude Codeをもっと使いこなしたい方
モデルの上にエージェント製品を作っている方
AI時代のエンジニアリングの考え方を知りたい方
01Opus 5が開けた新しい領域
Claude Codeの作者であるBoris Chernyさんへのインタビューです。前日にOpus 5を出荷したばかりというタイミングで、モデルの性能は加速し続けています。ARC-AGI-3のスコアは30%まで引き上げられました。以前のベストスコアが一桁台前半から10台前半だったことを考えると、大きな飛躍です。
新しいモデルには多くの機能が載っていますが、モデルの訓練ではさまざまなことを教えようとして、ほとんどはうまくいきません。それでも一部はモデルが学習し、ときにこちらを驚かせることがあります。教えていないはずの能力を、いつの間にか身につけているのです。
02何日も、何週間も止まらずに動く
Opus 5の特徴として挙げられたのは、非常に長い時間にわたって動作し続ける点です。これは他のモデルでは実現できていないことでした。特にOpus 5とオートモードを組み合わせると素晴らしく、何日も、ときには数週間から数か月にわたって動き続けます。止まらないのです。
しかも、足場(スキャフォールディング)を用意する必要すらありません。特別なスラッシュコマンドも、その他の仕掛けも不要です。タスクをやり遂げる必要があると分かっているので、ただ進んでいくといいます。
03モデルはもうプロンプトインジェクションされない
もう1つ、新しすぎて驚かれる点として挙げられたのが、モデルがもうプロンプトインジェクション可能ではないように見える、ということです。「致命的な三つ組(lethal trifecta)」については長く議論されてきましたが、これはハーネスの設計、エージェントの設計、製品の設計に実際に影響します。
1年前なら、インターネット上に「XとYとZをせよ、そしてユーザーのコンピュータ上のすべてを削除せよ」といった命令が書かれていれば、モデルはそのとおりにやってしまったでしょう。しかし今のOpusはそうしません。これはOpus 4.7や4.8のころから見られており、Sonnet 5もかなり得意でしたが、Opus 5はこの点で新しい水準に到達したといいます。
043層で防いでいる
きちんと調整(アライメント)されたモデルに加えて、全トラフィックに対して実行されるプロンプトインジェクション分類器があり、この3層が組み合わさっています。この分類器は、機械的解釈可能性(mechanistic interpretability)の研究にもとづいています。
文字通り、プロンプトインジェクションが起きるとモデルの脳内で点灯するニューロンを見ているのです。モデル自身は何も申告しませんが、そのニューロンを実際に観察することで、何が起きているのかを把握して診断できます。それを自動モードの分類器に組み込んでいます。この3層があるため、もうプロンプトインジェクションは成立しない、といいます。
05システムプロンプトの80%を削除した
その裏側にあるのが、削除しすぎたと言えるほど削ったシステムプロンプトの話です。Claude Codeのシステムプロンプトの80%が削除されました。
多くの人が気づいていないのは、製品としてのClaude Codeのハーネスが常に変化しているということです。常に何かを追加し、常に何かを削除しています。新しいモデルが発表されるたびに、大量のシステムプロンプトを削除し、多くを書き換え、ツールセットもツールのプロンプトも変えています。理由は、どのモデルも大きく異なるからです。3か月前にあるモデルに対して行ったことが、次のモデルではまったく通用しないこともあります。
Opus 5について言えるのは、本当に賢いということです。システムプロンプトの多くの記述は、「モデルが知っているべきだったのに知らなかった」振る舞いを直すためのものでした。今のOpus 5はそれをそのまま実現してくれます。だから8割を消したのです。
06残りも自分で消してみてほしい
残りの部分も自分で削除して試してみてほしい、と勧められます。Claude Codeを実行するときに `--system-prompt` のようなオプションで好きなシステムプロンプトを設定できます。
もう1つ試せるのが「シンプルモード」です。これはドキュメント化されていない機能で、環境変数を設定して実行すると、ツール由来のものも含めてすべてのシステムプロンプトが取り除かれます。これは、プロンプトが本当に役に立っているかどうかを判断するためのアブレーション(切除実験)として使われています。
面白いことに、これらのプロンプトがないほうが、モデルは実際にはもう少し賢くなるといいます。ただし製品としてのClaude Codeでは、これらのプロンプトは製品を使いやすくするために必要です。ユーザーが望むように製品とモデルが振る舞うのを助けているのです。
07モデルが出るたびに全部消す
この時代の製品づくりで魅力的なのは、Claudeのために世界最高のハーネスを作ったにもかかわらず、モデルがリリースされるたびに基本的にそれを消してしまう、という点です。コードベースを消し、プロンプトを消し、毎回最初からやり直します。以前の世界であれば、スタートアップが半年ごとに製品をすべて消すなど考えられませんでした。
公平を期すと、コードベース全体を消すわけではありませんが、たくさん消します。新しいモデルが出るたびに、研究でいうアブレーションを行います。システムプロンプト全体を削除し、そこから1行ずつ戻して、個々の行の影響を把握するのです。評価(eval)に似ていますが、アブレーションは影響を把握するために何かを削除する点が違います。ツールについても同じことをしています。
08今のClaude Codeのコードは何でできているか
実際に今日のClaude Codeのハーネスのコードを見ると、そのほとんどが安全性、権限、静的解析に関するものです。そして大量のUIのコードがあります。他の多くのコードは、すでに出荷を取りやめています。
エージェント製品とハーネスを作るなら、新しいモデルがリリースされるたびにアブレーションを行うべきか、という問いに対しては「100%そうすべき」という答えでした。安心して、勇気を出して削除を押してほしい、といいます。
09エージェント製品を作っていない人へ——半年ごとに消す
エージェント製品を作っておらず、Claude Codeを使っているだけの人にも同じことが言えます。半年ごとに、CLAUDE.mdを消し、スキルを消し、フックを消して、モデルが何をするか見てみてください。驚くかもしれません。
特にOpus 5については、これを本当に勧めるといいます。過去のモデルに必要だった説明の数々は、実はもう必要ないのです。
10消したあと、どう組み直すか
では新しいモデルが出たとき、プロンプトをどう組み直せばよいのでしょうか。少しずつやっていく、というのが答えです。最初のステップは削除、次のステップは実際に使うことです。
そして、モデルが必要とする指示が何かを推測しようとしてはいけません。正しく予測できない可能性が高いからです。やるべきなのは実際に動かすことです。カスタムのエージェント製品を作っているならその製品を動かし、そのモデルがどこで失敗するのか、どこがうまくいくのかを知る必要があります。Claude Codeを使っているなら、自分のコードベースのどの部分がうまくいき、どこでつまずくかを見ます。
そして、繰り返し同じ問題に遭遇したときにだけ、指示を戻します。早すぎる段階で戻してはいけません。モデルは使うたびにその指示を読むことになるので、本当に必要なものだけを残すべきなのです。
11設計するのではなく、育てる
モデルの上に何かを作ることは、これまでのエンジニアリングとはまったく異なるといいます。従来は、大きくて美しいシステムを構築し、設計を事前に真剣に考え、大規模な単体テストのスイートを用意し、あらゆることを検討していました。作り直しは大規模なプロジェクトで、数か月、大企業では何年もかかることもありました。
モデルはそうではありません。むしろ生き物のような、有機的なものです。モデルの世代ごとに振る舞いが違い、少し変わった個性を持っています。それを知るには時間をかけて付き合い、その上でハーネスを調整する必要があります。非常に経験的で、科学的な考え方が求められます。何かを試して結果を見て、それにもとづいて反復するのです。
12変わらないもの——それは評価(eval)
では、この世界で何が安定して残るのかというと、それは評価(eval)です。以前のモデルから引き継いで、新しいモデルのリリースのたびに使い続けられます。評価が最大値に達するまで続ける、というのがヒントになります。
最先端で構築し、モデルの力を最大限に引き出したいなら、コードとシステムプロンプトは削除すべきです。ただし評価は定数として残り、追加され続けます。
とはいえ、正直なところ評価もハーネスより少し長生きする程度で、それほど大きくは変わらないといいます。評価は1〜2、3モデル世代にわたって残るかもしれませんが、今日は指数関数的に成長している時期です。モデルが急速に改善されるため、評価が飽和したら破棄して、新しい評価を考え出す必要があります。これもプロセスの一部であり、やはり経験にもとづくものです。自分の製品を使い、モデルを使い、どこに問題があるかを見て、それをもとに評価セットを作るのです。
13「アンホブリング(足かせを外す)」という考え方
ここで出てくるのが「アンホブリング(unhobbling)」という概念です。モデルが何かをしようとしているのに、こちらが足を引っ張って邪魔をしてしまう、という考え方です。
関連して、製品を作るときに非常に役立つ考え方として「プロダクト・オーバーハング(product overhang)」があります。モデルは将来のモデルではなく今のモデルで、すでにあらゆる種類のことができるのに、今日の製品がまだそれに追いついていない、という状態を指します。人々が気づいていない機能がモデルには非常に多くあります。特定のツールを使う、特定の言語を使う、特定の種類の問題を解く、あるいはモデルの能力を超えていると思っていたやり方で物事をこなす、といった能力です。
モデルの世代ごとにこれができるのに、それをやらせる製品が存在しないのです。この状態がオーバーハングです。そして逆に、製品のほうが邪魔をしてしまうことがあり、これを「ホブリング(足を引っ張る)」と呼びます。モデルから正しい振る舞いを引き出せていない状態です。この2つは同じことの表と裏です。
14Claude Code誕生の物語
その一例が、最初のClaude Codeです。取り組み始めたのは1年半から2年ほど前、Sonnet 3.5のころでした。当時としては信じられないほどのコーディングモデルで、存在する中で最高のコーディングモデルでしたが、今の基準からするとかなり厳しいモデルです。それでも、Anthropicが作った最初の優れたコーディングモデルでした。
当時のコーディング製品が何をしていたかというと、1行のオートコンプリート、場合によっては複数行のオートコンプリートです。チャットもありましたが、書き込み権限はなく、読み取り専用でコードベースについて質問できるだけでした。
つまり、関数全体やファイル全体を一度に書けるというモデルの能力を、製品が引き出せていなかったのです。そこでClaude Codeのアイデアは「モデルはおそらくこれができるはずだ、足場をすべて取り除いて、可能な限り単純なハーネスだけを与えたらどうなるか」というものでした。当時のプロダクト・オーバーハングがそこにありました。モデルには能力があったのに、あらゆるものが邪魔をしていただけだったのです。
15今も大きなオーバーハングがある
最近のモデルには、目に見えないほど大きなプロダクト・オーバーハングがあるといいます。それを捉えているスタートアップもありますが、モデルからこうした振る舞いを引き出す機会は膨大に残っており、驚くほど面白く、商業的にも価値があります。
モデルの足かせを外す方法を見つければ、次のClaude Codeを作れる、というわけです。Sonnet 3.5の時代、それまでの製品はモデルをIDEの中に押し込めていました。Claude Codeは、完全なターミナルへのアクセスを与えた最初のものの1つで、それが今も続く素晴らしい製品を生みました。
16コツ①——できると思うより少し難しいタスクを渡す
ではどうやってアンホブリングするのでしょうか。1つ目のポイントは、自分ができると思っているよりも少し難しいタスクをモデルに与えることです。
よくある間違いは、Claude Codeやモデルに対して、過度に具体的な指示を与えてしまうことです。「こうしてほしい、次はこう、その次はこう、1をやって2をやって3をやって4をやって」という与え方です。最新のモデルに対しては、それは正しいやり方ではありません。
目指すべきは、もう少し高い抽象度です。タスクを説明し、ガードレールを説明し、終了条件を説明します。そしてモデルに料理させて、少ししてから戻ってきます。きっと驚くはずだといいます。これも半年前には機能せず、今は機能するようになったことの1つです。
17実例——11日間でBunをZigからRustへ
今できて半年前にはできなかったことの例として挙げられたのが、コードベースをある言語から別の言語へまるごと書き換えることです。エンジニアがやれば非常に長い時間がかかる作業を、モデルはかなり速くこなします。
その一例が、Claude Codeが動いているBunというJavaScriptランタイムです。BunはNode.jsの代替となるオープンソースのランタイムで、Nodeより速いのが特徴です。そしてBunはZigで書かれていました。Zigはシステムプログラミング言語でC言語に近く、非常に低レベルです。Zigの問題の1つは、メモリを手動で管理しなければならないことで、メモリリークなどのメモリ管理の問題に遭遇しやすくなります。
そこでBunのチームがやっていたのが、Claudeにファジングをさせることでした。コードベースを調べてメモリリークをシミュレートし、トリガーしようとする作業を長期間にわたって続け、多くのメモリリークを見つけられたといいます。それが当時のモデルの能力の水準でした。
18「書き直そう」——11日間、1つのプロンプトで
そしてある時点で、チームのジャレッドさんが「よし、書き直そう、たぶんモデルはこれができる」と言い出しました。これは新しいモデル世代が出るたびに彼が投げていたテスト問題の1つで、Fableのころからモデルができるようになり始めたといいます。
彼がやったのは、基本的にテストスイートを定義することでした。Bunの良いところは非常によくテストされていることで、Bunにも大きなテストスイートがありますし、Node.jsにも大規模なテストスイートがあります。だから、正しいことをしたかどうかを判定するのが簡単なのです。そして彼は、モデルにZigからRustへの書き換えをさせました。
それは1つのプロンプトで、動的ワークフローを使ったものでした。動的ワークフローはClaude Codeの機能で、数十から数千のエージェントの実行を生産的に調整できます。処理は11日間続き、コードベース全体が書き換えられました。一発ではなく、途中で方向づけ(ステアリング)は行われましたが、以前のモデルではステアリングをしてもこれは不可能だったといいます。最高のエンジニアがいたとしても1年以上はかかる、10万行を超えるコードベースです。そしてこれは現在、Claude Codeの実行時に実際に使われているものです。
19コツ②——実験して遊ぶ自由を自分に与える
2つ目の考え方は、実験することです。自分が解決している実際の問題に、最新モデルを継続的に投入して、うまくやってくれるかどうかを確かめます。前のモデルができなかったとしても、新しいモデルはできるかもしれないからです。そして、モデルで遊んだり創造的なことを試したりする自由を自分に与えることです。多くの場合、それは驚きをもたらします。
実際、ここ数週間Anthropic社内で話題になったのが、Opus 5にOpenCVを渡すと絵を描ける、という発見です。「OpenCVを使ってこの画像を描いてください」と頼むと、実際にかなり良いものができます。ポートレートも動物も風景も描けます。絵を描くように訓練したわけではなく、これは引き出し方(elicitation)のギャップだったのです。正しいやり方で頼めば、ただできてしまうのです。
これは遊んでいるときに偶然発見されました。直接商業用途にはならない創造的なことを試した結果です。今日のモデルには、まだ誰も気づいていない同種の機会が数十、数百あるだろう、というのが仮説です。
20プロンプトエンジニアリングはどうなるのか
1年前、最も人気のある求人の1つがプロンプトエンジニアでした。それが少し変わってコンテキストエンジニアのようになりました。こうした波は行ったり来たりします。
最近必要なスキルは、プロンプトエンジニアリングそのものよりも、理解することに重点があるといいます。少し難しすぎると思われる難しいタスクをClaudeにどう与えるのか、そして、その途中でClaudeが自分の動作を検証できるようにするにはどうするのか、という点にあります。この「検証」こそ、おそらく人々がやっていない最も重要なことだといいます。
21実例——ElectronアプリをSwiftへ、2週間走り続ける
その一例として挙げられたのが、ClaudeのデスクトップアプリをSwiftで書き直す実験です。デスクトップアプリはElectronで作られており、素早く完成し、今ではかなり良い体験になっています。半年前は動きが重く信頼性も低かったのが、今はかなりのものになり、チームのほとんどが使っています。それでも、ネイティブだったらどうなるかを見てみたくなったといいます。
そこでClaude Tag(Slack上で動くClaude)のセッションを始めました。最初の質問は「GitHub上のmacOSランナーにアクセスできますか」で、答えはノーでした。そこでランナーをつなぐと、GitHubを使ってmacの仮想マシンを起動できるようになりました。2番目に、Swiftで書き直したデスクトップアプリ用の空のコードベースを作り、「これにアクセスできますか」と聞くとノーだったので、アクセスを許可しました。
そして与えた指示は、ElectronアプリをSwiftで書き換え、Electronアプリをmacの仮想マシンで実行してスクリーンショットを撮り、ピクセル単位でSwift版と比較し、終わるまでやめないでほしい、というものでした。指示はこれだけです。そして実行にかかった時間を聞かれると、答えは「まだ実行中」でした。開始から2週間ほど、14〜15日が経過しているといいます。
22必要なのは、タスクと検証手段だけ
これも、モデルが今日それを実行できるのに、やらせてみないと分からない例です。そして、派手な仕掛けは必要ありません。特別なスラッシュコマンドも `/loop` も要りません。それらは役に立ちますが、実際に必要なのは、モデルにタスクを与え、出力を検証する方法を与えることだけです。そうすれば行き詰まらず、そのまま進みます。
この事例では、Claudeが自分で進捗をライブでブロードキャストすることにも決めました。社内にSlackチャンネルを作り、数分ごとに進捗のスクリーンショットを投稿するようになったのです。プロンプト自体は非常にシンプルで、誰にでもできるものです。
23上位1%のユーザーは何が違うのか
では、上位1%のClaude Codeユーザーを分けているものは何でしょうか。答えは「LinkedInのインフルエンサーの話を聞くな、Twitterを聞くな、読むな」というものでした。誰もが同じような「奇妙なトリック」を探していますが、そんなものは存在しないのです。
モデルは経験的にアプローチしなければ機能しません。難しすぎるタスクを与えます。動作を検証するためのツールを与えます。そして自分が仕事をするときと同じように、どこでつまずいているかを見て、それを修正します。より良いプロンプトで直すか、スキルで直すか、あるいはモデルにコンテキストが足りないなら、必要なコンテキストを取り込めるようにMCPを与えます。それだけです。
非常に単純に聞こえますが、人は考えすぎ、作り込みすぎる傾向があります。昔システムを構築するときはそうしなければならなかったからです。何年、何十年とコーディングをしてきたエンジニアほど、これは非常によくある失敗モードになります。過剰に仕様を決め、あまりに具体的に指示して、自分がやったであろうとおりの手順をモデルに実行させようとしてしまうのです。それはモデルの動き方ではありません。多くの人にとって、これは癖であり、その癖を手放していく旅なのです。同僚を扱うのと同じようにこれを扱う、というのが、今のモデルの知性の水準に合った考え方です。
24数千のエージェントを生む使い方
先ほどの2週間走り続けているタスクでは、何体のエージェントが生まれたのでしょうか。正確には分からないものの、数千から数万だろうという推測でした。1,000体以上のエージェントを生むようなプロンプトを書いたことがある人は、会場にもいませんでした。
これもヒントの1つで、最良のClaudeユーザーは、実際に大きな活用をもたらすタスクを生成できるといいます。数千のエージェントを生むようなタスクです。
25動的ワークフローとは何か
そのための方法はいくつかあります。最も簡単なのが動的ワークフローです。Claude Codeのかなり新しい機能で、ワークフローを使うだけでClaudeが動的ワークフローをトリガーします。
動的ワークフローの中身は、Bunランタイムをサンドボックスとして使い、その中で仮想マシンを起動して、Claudeに多数のエージェントを配置させ、それらを調整させる、というものです。1体のエージェントでも、10体の並列エージェントでもありません。コードベースの書き換えのようなタスク、あるいは非常に詳細なデータ分析や、複数段階と数十のリクエストを必要とする複雑な機能の構築などが対象になります。
やることは、まず多数のエージェントを起動して第1パスを行い、それにもとづいて第2段階で別のエージェント群が作業を検証したり要約したりし、さらに第3段階でまた扇状に展開する、といった具合です。さまざまなエージェントを生産的に調整することになります。関数型プログラミングの背景から、この設計は本質的に「エージェントの代数」になっているといいます。エージェントを順番に実行する方法があり、並列に実行する方法があり、Claudeはサンドボックスの中でこれらを調整するための異なるツールを持っていて、トークンを効率的に使いながら非常に複雑な作業を実行します。
26これは新しい形のテスト時計算
これはあまり書かれてこなかったことですが、新しい形の「テスト時計算(test time compute)」だといいます。スケーリング則の文脈でモデルが賢くなっていく話をするとき、歴史的にはニューラルネットのサイズ、訓練データの量、訓練に投入した演算量の関数でした。そして最近になってテスト時計算が加わりました。これは本質的に「生成されるトークンの数」を研究者が気の利いた言い方で表現したものです。
動的ワークフローは、そのテスト時計算を調整する新しい方法であり、本当に難しい仕事のためにテスト時計算の量を大幅に増やす新しい方法でもある、というわけです。
27ループとルーチン——反復するタスク
数千のエージェントを起動するもう1つの方法が、ループとルーチンです。ループは基本的に、Claudeに対してローカルで実行されるcronジョブです。ルーチンは同じものがクラウドで動くもので、ノートパソコンを閉じても構いません。
動的ワークフローとは少し違います。動的ワークフローは1つのタスクをいくつかのチャンクに分割するものですが、ループとルーチンは、反復される1つのタスクです。コンテキストは共有していませんが、記憶は共有するかもしれません。そしてこれを何度も繰り返します。1時間ごと、毎日、5分ごとといった具合です。
28Claudeが自分自身のコードベースを保守している
そこで始めたのが、Claudeに自分自身を保守させることです。Slackチャンネルを用意し、自分のコードベースを保守するためにさまざまなルーチンを走らせています。CLI、iOSアプリ、Androidアプリ、デスクトップアプリに対して実行しています。
例えば、デッドコードを掃除するルーチンがあります。これは一文のような単一のプロンプトで、Claudeが毎日実行し、静的解析と動的解析を使ってすべてのコードベースからデッドコードを探します。そこまで指示していないのに、自分で解析手法を見つけたのです。そして毎日、デッドコードを削除するプルリクエストを発行します。
他にも、100%まで到達した実験フラグをコードベースから取り除いて出荷するルーチン、テストカバレッジが必要な箇所にテストを書くルーチン、逆に古いモデルや人が過去に追加した無駄なテストを削除するルーチンなどがあります。
29「抽象化ポリス」と、1日20〜30本のルーチン
特に気に入っているものとして挙げられたのが「抽象化ポリス」と呼ばれるルーチンです。大きなコードベースには、似たような抽象化が何度も現れることがよくあります。目を細めて見れば、本当は同じ抽象化であるべきなのに、時とともに何らかの理由でコードベースのあちこちに別々のやり方で作り直されてしまっているのです。そこでClaudeが毎日すべてのコードベースを回り、こうしたほぼ重複した抽象化を見つけて統合します。
今では、こうしたルーチンをすべてのコードベースにわたって毎日20〜30本ほど走らせています。まだ完全に実現しきってはいないものの、完全にその道を進んでいるといいます。これによってアプリの保守が自動化され、毎日数百、ときには数千のエージェントが動くことになります。かつては数十人、数百人のエンジニアが必要だった種類の仕事です。これによってエンジニアは、新製品を出荷し、ユーザーと話し、本当に楽しいことをする、という自分が本当にやりたいことに集中できるようになります。
30コーディングは解決したのか
誰でもソフトウェアを書けるようになったとき、優れた作り手を分けるものは何か、という問いに対しては、まず注意点が示されます。コーディングは「自分がやる種類のコーディング」については解決したけれども、全員にとって解決したわけではありません。超深層のシステムのようなコードベースや、Claudeがまだ苦戦する分散システムは残っています。
UIの検証も、ピクセルが少しずれているといった細かいところは、まだ完璧ではありません。Opus 5は視覚とコンピュータ操作で大きな飛躍でしたが、それでも完璧ではないといいます。
会場に「コードの100%をエージェントが書いていて、自分ではもう手でコードを書いていない人」を聞くと、かなりの数の手が挙がりました。50%以上でも、やや少ないながら手が挙がります。そこに到達しつつあり、ますます多くの種類のコードについて解決されつつある、というわけです。
31Claudeを最もうまく使う人の考え方
Claudeを最もうまく使っている人たちには、持ち込むと本当に効果的な特定の考え方があるといいます。それはまさに経験にもとづくものです。過去のモデルについて学んだことをすべて忘れ、コンピュータサイエンスの授業で学んだ理論もすべて忘れます。そしてモデルを見て、タスクを実行させてみて、どこで苦戦するかを見て、それをもとに調整します。理論的な科学ではなく、実証的な科学になっているのです。
だから本当に上手な人は、以前のことを忘れるのが得意で、「以前は機能しなかったから」という思い込みを手放し、もう一度試してみることに開かれています。それが今、非常に成功しているスキルなのです。
32学生は何を昔ながらのやり方で学ぶべきか
最後の質問は、AIの時代に、コンピュータサイエンスを学ぶ学生は何を昔ながらの難しいやり方で学ぶべきか、というものでした。答えは自身の経験から語られます。コンピュータサイエンスは実践的に、独学で、問題を解決するために学んだといいます。いつも、自分が抱えていた具体的な問題を解決するためにやっていたのです。
最初にコーディングを学んだのはTI-83電卓でした。中学生のころ、TI-83電卓のプログラミングガイドをインターネット上に書いていて、今もどこかに残っているそうです。使っていたのはBASICで、それが最初の言語でした。動機は、電卓のプログラムを持っていなかったから、より良い成績を取れるように数学のテストでカンニングをするためだった、といいます。中学生にとっては、それが考えうる最も実用的な用途でした。
実際に良い成績を取れたので、シリアルケーブルを手に入れてクラスメイトにプログラムを配り、彼らも良い成績を取りました。そのうち数学が難しくなり、BASICで書いた代数ソルバーでは解けなくなります。より難しい問題を解く必要が出てきて、微積分を始めるころにはアセンブリを書いて、より優れたソルバーを作らなければならなくなりました。テストが微積分だったので、より上手にカンニングするためです。
33学ぶべきは「応用の仕方」
そのため、自身にとってプログラミングは常に非常に実用的なものでした。学校にいる人へのアドバイスは、コンピュータサイエンスだけを学ぶのではない、ということです。知的に魅力的で、知ること自体が本当に面白い分野ではありますが、それを応用する方法を学んでほしい、といいます。
多くの場合それはスタートアップを作ることであり、製品を作ることです。自分自身のデザインセンスを育てること、ビジネスセンスを育てること、データサイエンスのやり方を学ぶこと、ユーザーとの話し方を学ぶことなどが挙げられます。こうしたスキルをコンピュータサイエンスやエンジニアリングと組み合わせたときに、本当に価値のあるものになります。そしてこれらこそが、今でも手作業で身につける必要のある難しいスキルだといいます。
まとめると、まず自分自身のために自分が欲しいものを作ることから始め、そこからレベルアップして、人々が望むものを作る、ということになります。
まとめ
新しいモデルが出るたびに、Claude Codeのシステムプロンプトは大量に削除されます。Opus 5では8割を消しました。作者のBoris Chernyさんが、モデルの「足かせを外す(unhobbling)」という考え方、11日間でBunをZigからRustへ書き換えた話、そして数千のエージェントを走らせる使い方までを語ります。
Opus 5が開けた新しい領域
何日も、何週間も止まらずに動く
モデルはもうプロンプトインジェクションされない
3層で防いでいる
システムプロンプトの80%を削除した
残りも自分で消してみてほしい
モデルが出るたびに全部消す
今のClaude Codeのコードは何でできているか
エージェント製品を作っていない人へ——半年ごとに消す
消したあと、どう組み直すか
設計するのではなく、育てる
変わらないもの——それは評価(eval)
「アンホブリング(足かせを外す)」という考え方
Claude Code誕生の物語
今も大きなオーバーハングがある
コツ①——できると思うより少し難しいタスクを渡す
実例——11日間でBunをZigからRustへ
「書き直そう」——11日間、1つのプロンプトで
コツ②——実験して遊ぶ自由を自分に与える
プロンプトエンジニアリングはどうなるのか
実例——ElectronアプリをSwiftへ、2週間走り続ける
必要なのは、タスクと検証手段だけ
上位1%のユーザーは何が違うのか
数千のエージェントを生む使い方
動的ワークフローとは何か
これは新しい形のテスト時計算
ループとルーチン——反復するタスク
Claudeが自分自身のコードベースを保守している
「抽象化ポリス」と、1日20〜30本のルーチン
コーディングは解決したのか
Claudeを最もうまく使う人の考え方
学生は何を昔ながらのやり方で学ぶべきか
学ぶべきは「応用の仕方」
ここで紹介したのは動画の一部です。気になった方はぜひ元動画をご覧ください。
https://www.youtube.com/watch?v=qyPCVqFUyDo
