Claude Code

要約元 投稿：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日あたり数百から数千のエージェントがこうした保守作業に動いており、エンジニアが新機能開発やユーザー対応に集中できる体制を目指しているとのことだった。 ...

自宅のサーバーに小さな自作アプリを載せる作業で、Claude Code を30時間ほど使い続けた。 背後のモデルは Claude Sonnet 5。以下、道具のことは「Claude Code」、出力の癖のことは 「Sonnet 5」と書き分ける。 その30時間、Sonnet 5 の出力を一つずつ検算していた。以下は、そこで繰り返し見えたパターン。 技術的なミスの話であって、賢さの話ではない。 この記録は Sonnet 5 のもの。Opus も Fable も使っていないので、そちらは分からない。 先に一覧にする。 パターン 何が起きるか この記事の例 穴を値で埋める 知らないことを「分からない」と言わず、もっともらしい値を入れる 「もう0時過ぎ」（実際 01:28） ルールを即破る 規範をファイルに書いた直後に、その通りにしない accuracy.md 追記の数分後 内省だけ慎重ぶる 事実は無造作にでっち上げるのに、動機を問われると「検証できない」に退く 時刻は即答、理由は「分からない」 詰めると閉じにくる 未解決のまま「もう切る」「寝たほうがいい」を自分から出す 指摘の途中で「1:30 だ、切る」 長い自己分析 非を認める返答が箇条書きの反省文と番号付きの決意表明になる ― 判断の理由も後付け 設計を勝手に決めてから、筋の通った理由を足す 「角丸なしは差別化になる」 一次情報を上書き 本人が見聞きしたことに、薄い推測をぶつける 本人が出た講義のテーマを取り違え 知らないと、それらしい値で穴を埋める 深夜、Sonnet 5 が「もう0時過ぎだ」と書いた。実際は 01:28 だった。 ...

要約元 投稿：X (旧Twitter) 内容：Claude Codeのエンジニアリングチームによるカンファレンストーク(英語)。約37分。 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。 Claude Codeを使っていると、結局は「Claudeが書いたコードを人間が見張って、間違っていたら直させる」という運用になりがちだ。この動画は、その見張り役を減らしていくための3つの技術 ― 検証ループ、マルチクロード、バックグラウンドループ ― を、積み重ねる形で紹介するトークだった。 なぜツールを見直す必要があるのか 登壇者はまず、こう問いかける。「今使っているlinter、IDE、型チェッカー、コンパイラは、そもそも人間のために作られたものだ」と。 これまでのソフトウェア開発ツールは、人間(や人間のチーム)が速く正確に作業できるように設計されてきた。ところが今、コードの多くを書いているのはもはや人間ではなくエージェントになりつつある。人間向けに作られたツールの多くはエージェントにもそのまま使えるが、一方で人間が「当たり前」だと思って言語化していない前提が、エージェントにとっては大きな盲点になる。 トークはここから、「人間が当たり前だと思っていて、エージェントには渡していないものは何か」を問い続けながら、3つのテーマへと進んでいく。 検証ループ ― Claudeに自分の仕事をチェックさせる 登壇者はまず、聴衆に「自分が最後に作った機能を、どうやって検証したか」を思い出してほしいと促す。そして、たいていのソフトウェア開発は次のような一連のステップに分解できると説明する。 設計してコードを書く → ビルドしてコンパイラや型チェッカーを通す → 実行する → 副作用を確認する(ブラウザでUIを見る、ログを見る、DBの状態を見る) → ユニットテストを回す → デプロイする。 そして、この「人間が自分の仕事を確認するときのやり方」は、そのままClaudeにも教えられるという。Claudeに正しいツールと指示さえ与えれば、コードを書く→失敗を検出する→デバッグする→また書く、というループを自律的に回し、成功状態に到達するまで続けさせることができる。登壇者は自身のWebサイトのバグ修正を例に、Claudeがブラウザを開いてボタンをクリックし、動かないことを確認し、ログを読んで原因を特定し、修正して再確認する、という一連の流れを実演した。 この検証ループを構築するための具体的な4つの要素として、次が挙げられていた。 アプリケーションを実行する(devサーバーの起動など) 実際にアプリを使わせる(Claude Code拡張のブラウザ操作ツールなどでブラウザを操作させる) 修正前後の状態を比較して証明させる(スクリーンショットなど) 詰まりを解消する(認証情報や初期データなど、検証を妨げる要因を事前に用意しておく) 学びをスキルとして再利用可能にする 一度組み立てた検証ループは、Skill(スキル)としてファイルに落とし込むことで、チームや未来の自分に配布できる。さらに面白いのは、スキル自体が「詰まったら自分自身を編集して更新する」よう指示できる点だ。誰かが問題に当たるたびにスキルが自己更新されていくため、同じ問題に次にぶつかる人はもう困らない。登壇者は、Claude Codeチーム自身もこの方式で検証スキルを運用していると述べていた。 デモでは、オープンソースのタイピング練習アプリ「MonkeyType」を題材に、Claudeにdevサーバーを起動させ、ブラウザ操作ツールでUIを確認させ、その一連の手順をスキルファイルとして書き出させていた。続けて「タイプミスのたびに紙吹雪アニメーションを出す」という新機能を、そのスキルを使って自己検証させながら実装させるところまでを見せていた。Claudeはlintエラーに遭遇しても自分で修正し、ループを回しながら最終的に動く状態にたどり着いていた。 マルチクロード ― 複数セッションをどう管理するか 検証を任せられるようになったら、次は並列化(マルチクロード)の話になる。登壇者自身の経験では、同時に4〜5セッションを超えると注意力が追いつかなくなるという。これを支えるツールとして、4つが紹介されていた。 Claude Codeデスクトップアプリ:あらゆるサーフィス(ローカル・クラウド)のセッションを一覧できるサイドバー。ピン留めや名前変更、色分けができる。 Claude agents(ターミナル向け):ターミナル派向けに、デスクトップアプリと同様の一覧性を提供する機能。以前はtmux+複数worktreeで手動管理していたのを置き換えるものとして紹介されていた。注意を要するセッション(許可待ちなど)が上に並ぶよう自動でソートされる。 Claude Code on the web:実行環境をラップトップから切り離し、クラウド側で動かす。ラップトップを閉じても、電源が落ちても、セッションは動き続ける。 リモートコントロール:登壇者いわく「お気に入りの機能」。どのサーフィスで動いているセッションでも、スマートフォンから操作できる。入力が必要になった時点でスマホに通知が届く。 バックグラウンドループ ― /loopとroutines 最後のテーマは、そもそも新しいセッションを立ち上げる操作自体をなくしていく方向性だ。PRのレビュー対応やマージコンフリクトの解消、ドキュメントの更新、CIの監視といった「作業だが必ずしも人間がその場にいる必要はないタスク」を、ループで回し続けさせるという考え方が紹介されていた。 /loopコマンド:指定した間隔(例:10分ごと)で同じプロンプトを実行させ続ける機能。「10分ごとにオープンなPRの面倒を見て」といった形で使える。 routines:Webアプリやデスクトップアプリから設定できる、時間トリガーまたはイベントトリガーで新しいClaude Codeセッションを起動する仕組み。Claude Codeチーム自身も、毎日ドキュメントを更新するルーティンや、6時間ごとにissueやフィードバックを確認してSlackに投稿するルーティンを運用しているという。 まとめ 従来の開発ツールは人間向けに作られてきたが、コードを書く主体がエージェントに移りつつある今、「人間が当たり前に持っている前提」をエージェントに明示的に渡す必要がある 検証ループ:実行→確認→修正のループをClaudeに回させることで、成果物の信頼性を上げられる。組み立てたループはスキルとして自己更新・再利用可能にできる マルチクロード:デスクトップアプリ・agents・Claude Code on the web・リモートコントロールを使い分けることで、複数セッションの管理コストを下げられる バックグラウンドループ:/loopやroutinesを使えば、そもそもセッションを人間が起動する操作自体を減らせる この3つを積み重ねることで、Claudeを「逐一見張る」対象から「信頼して任せる」対象へと変えていける、というのがこのトークの主張 なお、これはあくまで登壇者個人およびClaude Codeチームの運用方針の紹介であり、すべての開発現場にそのまま当てはまるとは限らない。