Claude Code はツールではない、世界観だ——Cat Wu のインタビューから読み解く7つのプロダクト哲学

プロダクトに関わる人なら、Claude Code のプロダクト責任者 Cat Wu のこの2つのインタビューをぜひ見てほしい。1つは Lenny's Podcast での単独インタビュー、もう1つは Boris Cherny と一緒に出演した Every.to の《AI & I》。合計で3時間以上、情報密度が高すぎて2回流しで聞いた。

多くの人がこのインタビューで話題にしているのは、Anthropic がどうやって6ヶ月分の機能を1週間、あるいは1日でリリースできるようにしたかという点だ。スピードアップは確かに狂っているが、私が一番感じたのはスピードではなく、別のところにある。

本当にインスピレーションを得たのは、Claude Code というプロダクトに宿る、一貫した世界観だ。これを7つの原則に分解できる。1つ1つを取り出すと直感に反するが、合わせると AI ネイティブプロダクトのあるべき姿が見える。以下、順を追って説明する。

1

Plan Mode は機能ではなく、世界観だ。

Boris Cherny が番組で重い一言を言った。

"plan mode に切り替えて、Claude にやるべきことをまずステップごとに提示させ、書き始める前に計画をすり合わせる——複雑なタスクの成功率は2倍、いや3倍になる。"

2倍から3倍。この数字を初めて聞いた時、ちょっと震えた。

操作自体は Shift+Tab を2回押すだけだ。番組でも触れられていたが、Boris 自身も難しい機能を作るときは、まず plan mode にして計画をすり合わせてから書き始める。コードは1行も書いていないのだ。

問題は、なぜ見た目が UI オプションのような小さなスイッチが、これほど成功率を引き上げられるのかだ。

その背後にはプロダクトレベルの前提がある——モデルは幻覚を起こすことを認めるので、意図をまずテーブルに出す必要がある。Plan Mode はユーザーに見せるためではなく、モデルのためにある——モデルに考えることを強制し、それから行動に移させる。

多くの人は Plan Mode を「ユーザーに AI の計画をチェックさせるもの」と捉えているが、より正確な言い方は「AI に思考ステップを飛ばさせないもの」だ。

「思考の可視化」をプロダクトレベルの仕組みにすること、それが世界観だ。

2

モデルの能力に合わせて足場を切り、機能を積み重ねない。

Cat Wu が Lenny's で微妙な概念を持ち出した。AGI-pilled というものだ——簡単に言えば「AGI への賭けの度合い」だ。彼女は AGI-pilled の度合いを適切に保つことが、プロダクトで最も難しいことの1つだと言った。

AGI-pilled すぎると現実離れしたプロダクトビジョンになるし、AGI-pilled すぎないとモデルの能力を無駄にする。新しいモデルが出るたびに、このバランスポイントを再調整しなければならない。

彼女と Boris の哲学は「作るのと同じくらい削る」ことだ。機能を廃止するのは、失敗したからではなく、よりシンプルで直感的な実装パスが見つかったからだ。

最も具体的な例は todo list だ。初期のモデルは完了項目を信頼性高くチェックできず、チームは数メッセージごとにリマインダーを送る system reminder を追加するしかなかった。新しいモデルが出た後、この「リマインダー足場」は余分なものになり、直接削除された。

Cat は固定のベンチマークテストも持っている——Claude Code に Excalidraw でテーブル機能を追加させることだ。2025年6月の Opus 4 はたまに成功するだけだった。1年も経たないうちに、2026年4月の Opus 4.6 は一発で成功し、何千人ものエンジニアの前でライブデモができた。

1年間のスパンで、「たまに成功」から「一発成功」へ。足場の削除のリズムは、完全にモデルの能力に合わせている。

他社が機能を追っている間に、彼らはモデルを追っている——モデルが強くなるごとに、足場は1つずつ削られる。

3

Swiss Cheese 多層防御は、vibe coding ではない。

Anthropic 内部ではこの仕組みを Swiss Cheese Model と呼んでいる——多層の重ね合わせで、各層に穴があっても、重ねると穴がなくなる。

Claude Code というプロダクトに落とし込むと、Boris は番組で PR を実行する具体的な5ステップを説明していた。

Claude 自身がテストを実行し、テストがなければ自分で書き、自分が生成した linter を実行し、自動レビュアーとして自分を一回チェックし、最後に人間がバックアップとして対応する。

注目すべきは、5層のうち前4層は Claude Code 自身が自分自身のために構築したものだ。どの1層も単独で間違いがないとは信じず、人間のバックアップ層に至る前に、まず自分自身で4回チェックする。

Boris にとって、vibe coding のような「なんとなくいけるだろう」という書き方は、使い捨てコードやプロトタイプには適しているが、プロダクションシステムには適さない。理由は簡単だ——プロダクションシステムの反面はモデルが弱いことではなく、反例が必ず現れることだ。

これが Swiss Cheese 思想の最も鋭い点だ：真の産業レベル AI プロダクトは、モデルが間違えないことを賭けるのではなく、必ず間違えると仮定し、構造でカバーする。

4

Antfooding——5分ごとに1つのフィードバック。

Anthropic のエンジニアは社内であだ名を付けられている——ants（アリ）だ。だから社内の利用サイクルを Antfooding と呼んでいる——dogfooding の進化版だ。

Cat は番組でかなり狂ったことを言った。

"うちのフィードバックチャンネルでは、5分ごとに新しいメッセージが流れる。"

5分ごと。この機能が本当に好きなのか、バグがあるのか、unship すべきか——5分ごとに1つのシグナルが得られる。

オフィスにいる何百人ものエンジニアは毎日 Claude Code を使っており、Cat は一回歩けば生のフィードバックを得られる。この絵が実は重要だ——Claude Code の最初のユーザーは、世界で最も厳しく、最もコードを書き、最も文句を言う一群の人たちだ。

リリース → 内部 dogfooding → 数分ごとのフィードバック → イテレーション → 再リリース。このサイクルはどれほど短いか？以前は機能の企画からリリースまで6ヶ月かかっていた（計画＋チーム横断のすり合わせ＋PRD作成）。今、Anthropic 内部の全体リズムは24時間で ship できる——注意、これはチーム全体のイテレーション速度であって、同じ機能が6ヶ月から24時間に短縮されたわけではない。

Claude Code で行き詰まったエンジニアほど、厳しいユーザーはいない。一般的なプロダクトの dogfooding は「自分たちも使う」程度だが、Antfooding は「自分たちが誰よりも厳しく使う」ことだ。

5

Subagent にお互いを批判させる。1回で決めない。

このセクションはインタビュー全体で最も私の認識を覆した部分かもしれない。

Boris は自分の code review コマンドの実行方法をこう説明していた。

最初に並行して複数の subagent を起動する——1つはスタイルガイドをチェック、1つは git history を遡って以前の実装方法を確認、1つは明らかなバグを探す。最初のラウンドで本当の問題と誤った警報の両方が出てくる。だからさらに5つの subagent を起動し、前に出てきた結果の欠点を専門に検出させる。結果、本当の問題だけがすべて見つかり、偽陽性はすべて排除される。

これを読んで少し固まった。私自身、普段 Agent プロダクトを作るときの反射神経は常に「より強いモデルに切り替える」ことだ——品質に問題があれば、第一感はモデルが足りないと考える。N個の Agent にお互いを批判させる方法は考えたこともなかった。品質はモデルの強さではなく、モデル同士の対抗に依存する。

大抵の人は Agent プロダクトを作るとき「1つの最強モデルで全部やる」と考えている。Claude Code はその逆だ——複数のモデルにぶつからせる。最初の subagent がレビューし、次の subagent がそのレビューに専門的に異議を唱える。

Cat 自身も似たような構成を使っている——1つの planner subagent、1つの code review subagent。同期対話では subagent を使い、CI では slash command を使う。やっていることは同じだ。

代償は現実的だ。subagent を多用するワークフローは、トークン消費が単一 agent の2～5倍になる。業界の公開データと比較すると、企業導入の平均は1開発者あたり月額 $150～$250 だが、Anthropic 内部では1ユーザーが1ヶ月で15万ドル分のトークンを消費した極端なケースもあった——単一の事例とはいえ、この手法の上限がどれほど高くつくかを示している。

しかし Boris の見解は強い。Subagent にお互いを批判させると、結果はむしろよりクリーンになる。対抗こそが品質の源泉だ。

AI が1回で正解することを信じるより、AI 同士をぶつけた方がいい。

6

Stop Hook が「完了」の定義を書き換える。

前のセクションでは単一点の判断を信用しないことについて述べたが、このセクションでもう一步進む——「モデルがやり終えたと言っている」ということ自体も信じるべきではない。

Boris の解法は Stop Hook だ。

"モデルを延々と走らせ続けて、本当に事が完了するまでやらせればいい。"

具体的には stop hook をテストスイートに接続する——テストが失敗したらエラーを Claude に返して修正させ、もう一度実行し、テストがすべて通るまで終わらない。「やり終えた」では完了ではなく、「テストが通った」ことが完了だ。

Boris は番組で特に強調した。Claude に自己検証可能なループを与えることは、Claude Code で良い結果を得るための最も重要なことの1つだ——このループがあれば、最終品質が2～3倍向上する。

彼自身は PostToolUse hook でコードを自動フォーマットしている——Claude は通常フォーマットに問題はないが、この hook が最後の10%を修正して CI が落ちるのを防ぐ。

これらの2層を重ねると、Stop Hook が何をしているかがわかる——「完了」という言葉を再定義している。AI 時代には、結果だけが唯一の正直なものだ。モデル自身の「完了」という宣言はカウントせず、動作したものだけがカウントされる。

7

typing から deciding へ——最も希少なのは判断力だ。

最後のセクションで、Cat が Lenny's で言った一言を、私は何度もスクリーンショットにして人に見せた。

"コードはどんどん安くなっている。より価値があるのは『何を書くべきかを判断すること』だ——そして、ある事がどれほど難しいかを理解することが、優先順位の判断に役立つ。"

彼女はさらに言った。すべての役割が融合している——PM がエンジニアリングの仕事をし、エンジニアが PM の仕事をし、デザイナーが PM の仕事をしている。彼女のチームのほぼすべての PM は、かつてエンジニアだったか、自分で PR を提出している。デザイナーも全員、フロントエンドエンジニアの出身だ。

Boris の視点はもっと鋭い。彼にとって、ソフトウェアエンジニアは写経僧のようで、AI は印刷術のようなものだ——コードはもはや希少品ではない。

このセクションで前の6カ条を振り返ると、実は同一のことだ——

Plan Mode は判断を可視化するため。足場を削るのはモデルの能力に合わせて判断を調整するため。Swiss Cheese は「モデルが間違えるかどうか」の判断を不要にするため。Antfooding は判断を早く生のフィードバックにさらすため。Subagent の批判はモデルの判断を評価するため。Stop Hook は「完了」の真偽を判断するため。

すべてのプロダクト哲学は、同じ1つのことのためにある——人を typing から解放し、deciding に集中させること。

Claude Code はエンジニアを代替するのではなく、エンジニアをタイピストの座から起こそうとしている。

---

7つの理念を貫くと、Claude Code というプロダクトの世界観が見えてくる——

AI は信頼できないと認め、多層防御を構築する。単一点の判断を信じず、互いに批判させる。モデル自身の「完了」宣言には価値を置かず、通った結果だけを重視する。人をタイピストの位置から解放し、判断に集中させる。

見終わった後の最大の感慨は驚嘆ではない。能動的に変わること、この4文字だ。

私たちが使っているプロダクトは、すでにこの世界観に従って動いている——エラーを仮定し、対抗を組織し、「完了」を再定義し、人を判断の位置へ押し上げる。ならば、私たちがプロダクトを作り、チームを組み、目の前の仕事をする方法も、これに合わせるべきではないか？ チームの協調の仕方も、ツールも、仕事の習慣も、「何が『やり終えた』ことなのか」すら再定義されなければならない。

能動的に変わらなければ、この世界観に押し流されるだけだ。

あなたもぜひ、この2つのインタビューを聞いてみてほしい。私がだらだら話すより、はるかに役立つ。

Claude Code を使っていて、最もあなたの認識を覆したデザインは何か？ コメントで教えてほしい。