Anthropic Labs責任者：AI時代のプロダクト開発で最大の落とし穴は「作りすぎ」

Instagramの共同創業者であるMike Krieger氏は現在、AnthropicでLabsチームを共同で率いており、Dan Shipper氏のポッドキャストに出演して約1時間にわたる対談を行いました。

対談の核心的な問いはこれです：AIによって「モノを作る」ことが簡単になったのに、なぜ良いプロダクトを作ることは逆に難しくなったのか？

このポッドキャスト回は情報密度が非常に高く、多くの洞察が実践の中から生まれたものであり、先週取り上げたAnthropicのPM Cat Wu氏の記事「Anthropicプロダクトマネージャー：PRDは死んだ、プロトタイプこそが王道」と非常に良い補完関係を形成しています。

Cat Wu氏が語ったのはPMという役割の変化ですが、Krieger氏が語ったのはより根本的なことです：プロダクトそのものがどうあるべきか。

室内の木

Krieger氏はある話から切り出しました。

彼はClaudeにBourbonの再構築を依頼しました。これは彼とKevin Systrom氏がInstagramを作る前に約1年かけて開発したプロダクトです。

結果、わずか2時間後、全機能が完成しました。

Claudeはさらにフィルター機能まで自ら追加しました。Bourbonがその後Instagramになったことを知っていたため、前もってフィルターを組み込んでおいたのです。

しかしKrieger氏の感慨は「速い、すごい」ではありませんでした。彼はこう言いました：

当時、私たちは1年かけてBourbonを作りましたが、最大の収穫はそれが複雑すぎることに気づき、3ヶ月かけてInstagramへと簡素化したことでした。もし2時間で完成してしまったら、「何を削るべきか」を発見するプロセスを経験できないでしょう。

Dan Shipper氏が添えた比喩は、非常に的確でした。

木が室内で育つ場合、風が吹かなければ頑丈に育ちません。幹が風の力で繰り返し押し引っ張られることで太く強くなるからです。室内で育てられた木は、見た目は木でも、曲がっていて脆いのです。

AIが開発を加速させることは、木を室内に植えるようなものです。

数時間で一本の完全な木を育てることはできますが、それは風雨を経験していません。ユーザーフィードバックによる研磨も、一歩一歩のイテレーションで築かれる直感もなく、木は完全に見えますが……実際には押せば倒れてしまいます。

Krieger氏はこの比喩に深く共感し、さらに具体的な比喩を補足しました：

テレビドラマのように、一話ずつ見ていけば、徐々にキャラクターを知り、関係性を理解できます。しかし、いきなり最終回に放り込まれたら、困惑するでしょう：この人たちは誰？どんな関係？なぜみんな泣いているの？

プロダクトも同じです。 機能を一つずつ追加していく中で、ユーザーも開発者も理解を深めていきます。しかし、一夜にして「完成した」プロダクトが現れたら、誰もが迷子になってしまいます。

Vibe codingの落とし穴

Dan Shipper氏自身もこの落とし穴にハマりました。

彼はProofというプロダクトを作りました。これはagent nativeなコラボレーション型マーケティングエディタです。最初のバージョンは完全にvibe codingで作られました。

Vibe codingは楽しくて、中毒性があります。機能をどんどん追加して、これも作って、あれも作って……最終的には「怪物」ができあがり、使い物になりませんでした。

その後、Monologueという極めてシンプルな音声→テキスト変換アプリを見つけ、一つのことだけを極限まで做得ていることに触発され、彼はプロダクト全体をゼロから作り直し、共有可能なMarkdownリンクという核心機能だけを残しました。

その結果、この極限までシンプル化したバージョンは社内で瞬く間に広がり、リリース後に大爆発しました。その後、彼は徹夜でバグを修正し、もう年齢的にきついと嘆きました。

Krieger氏はAnthropic Labsでも同じ問題に直面しました：

最近あるプロジェクトで、V1の前に過剰な開発をしてしまいました。できるから。あ、この機能？ PR一つで終わる。じゃあ追加しよう。ランチから戻ってみると、Claudeがまた一つ完了している、それも追加しよう……。
最終的に機能マトリックスができあがり、テストは極めて困難になり、ユーザーへの説明も不明瞭になりました。

機能の怪物 vs ミニマルなヒット作：できることは、すべきこととイコールではない

「できる」と「すべき」の間のギャップは、かつてないほど広がっています。

書き直しが日常に

しかしKrieger氏は保守的になったわけではありません。むしろ、Anthropic Labsのアプローチは：書き直しを受け入れ、それを常态とすることです。

かつてソフトウェア業界には「書き直すな」という古典的な教えがありました。Fred Brooks氏は『人月の神話』で、書き直しは第一版に蓄積されたすべての暗黙知を失うと述べています。

Krieger氏はこれに一理あると認めつつ、時代は変わったと言います。

以前は書き直しが、1年のエンジニアリングの投資が水の泡になることを意味しました。今はどうでしょう？先週作ったものを、今週やり直す。書き直しのコストは、もはや過去のような規模ではありません。

Labsでは既に複数のプロジェクトがこのプロセスを経験しました：完全なV1を作成し、核心仮説に問題があることを発見し、推翻し、数日でV2を作り上げました。

これはCat Wu氏が言う「モデルのアップグレード＝プロダクトのアップグレード」と同じロジックです。 3〜6ヶ月ごとに、コードの半分を捨てる必要があるかもしれません。チームが大きすぎると、調整コストがこれを不可能にします。たった一二人なら、迅速にピボットできます。

Dan Shipper氏も同感でした：

3〜6ヶ月ごとにプロダクトの半分を捨てる。一人のGMなら気づいた瞬間に行動できる。でも大勢を調整するとなると……止まってしまう。

Agent native

このポッドキャストで繰り返し登場した言葉が「agent native」です。

Dan Shipper氏は、Claude Codeからagent nativeが何かを学びました：エージェントがユーザーにできることすべてを実行できること。プロダクトはカスタマイズ可能で拡張可能であり、設計者はすべての用途を想定せず、ユーザーとエージェントが使い方を発見していく。

Krieger氏はこの概念をより深く分解しました。

Claude Codeはこれを実現しましたが、claude.aiはまだです。ある例を挙げました：ある人がclaude.aiのProjectでドキュメントを作成し、「これをプロジェクトのナレッジベースに追加して」と言いました。Claudeの回答は……一連の手動操作手順でした。

これは本来、ネイティブにできるべきことです。2024年のプロダクトで、「エージェントがすべてのコンポーネントを操作できる」という原則がまだ骨の髄に刻まれていない。

一方、Claude Codeは2025年の産物であり、最初からこの考え方が組み込まれています。

Agent nativeプロダクトのテストも全く異なります。 エージェントの動作は予測不可能なため、従来のエンドツーエンドテストは書けません。Krieger氏はある時、Claudeにagent nativeなiOSアプリをテストさせたところ、Claudeがアプリ内のチャット機能と会話を始め、自分自身と対話しました：

「今日はあまり良い一日じゃなかった。上司に怒られたんだ。」
「それは残念ですね。」

何度も行ったり来たりの対話が続きました。

このようなシナリオの単体テストを書くことは不可能です。しかし、これこそがagent nativeプロダクトが直面する現実なのです。

2026年のソフトウェアデザインの核心芸術は、開放性と堅牢性のバランスを見つけることです。

二人一組

Anthropic Labsのチーム構造も詳しく見る価値があります。

各新プロジェクトは通常二人だけで構成されます：強い信念を持つ一人（デザイナーまたはプロダクト志向のエンジニア）と、プロトタイプを堅牢なシステムに変えるエンジニア。

Krieger氏は、反直感的な法則を発見したと言います：チームの拡大が早すぎると、むしろマイナスになる。

アイデアがまだ一人の頭の中に収まっている間は、人を増やしても調整コストが増えるだけです。Instagramを作っていた時は二人だけでしたが、たった二人で意思疎通を図るだけでも十分に難しかった。

その後の2つ目のスタートアップArtifactでは、最初から8人を採用しました。結果、PMFを見つける前に「次は何をするか」を議論する8人の会議に陥りました。

Labsのアプローチは：各プロジェクトを2週間ごとに評価し、投資を倍増させるか、メンバーをプールに戻すかを決める。 誰も永久に一つのプロジェクトに縛られることはありません。

そして、閉じられたプロジェクトには、振り返りで共通する特徴がありました：

チームの誰もが、これを「絶対にやらなきゃいけない」とは思っていない。「まあ、この方向も悪くないね」とみんなが思う。この「悪くない」が、プロジェクトへの死刑宣告なんです。

「壁を突き破る」意志を持つ人が一人必要です。 具体的な解決策への執着ではなく、問題そのものへの、ほぼ執着に近い情熱が必要です。

これはCat Wu氏が描写したSide Quest文化と相通じるものです：機能はロードマップから生まれるのではなく、誰かの「これを絶対にやらなきゃ」という衝動から育っていくのです。

企業顧客との綱引き

AI時代のtoBプロダクト開発には、独自の緊張関係があります。

Krieger氏は自身の経験を語りました。CPOとしてclaude.aiの大幅な改版を行い、チームは自信を持ってリリースし、好評を得ました。

その後、一通の怒りのメールが届きました：

会社のために20時間のClaudeトレーニング動画を録画したばかりなのに、インターフェースが全部変わってしまい、全部撮り直さなきゃいけません。

この件から彼は一つの教訓を得ました：企業顧客のペースとAIプロダクトの進化スピードには、根本的な矛盾があるのです。

Anthropicの対応戦略はこれです：

この列車は走り続けます。その道中で、エンタープライズ向けのスイッチを提供していきます。お客様が買うのは今日のプロダクトではなく、私たちが継続的に進化させるという約束です。

スタートアップに対するKrieger氏のアドバイスはより過激です：

以前は、新しい方向に進むために古い顧客を「解雇」するのに数年かかっていたかもしれません。今、このサイクルは数ヶ月に圧縮されています。3ヶ月前のプロダクトと3年前のプロダクトは、AIの領域では同じくらいの差があるかもしれない。

これはCat Wu氏が言う「PMの仕様書が腐りやすい製品になった」と全く同じ理屈です。 6週間前の要求は、今日では全く異なる解決策があるかもしれない。しかし企業顧客は1年の契約を結んでいるかもしれません。

OpenClawとパーソナルエージェント

OpenClawの話になると、二人は明らかに興奮しました。

Krieger氏は、OpenClawの価値は人々に初めてエージェントの可能性を本当に体験させることにあると言います。ReplitやLovableが「AIがコードを書ける」ことを体験させたように、OpenClawは「AIがあなたの代わりに仕事をする」ことを体験させるのです。

しかし、予期せぬ副作用もありました：

友人が言っていました。彼の奥さんがOpenClawに嫉妬し始めた、彼がOpenClawと話しすぎていると。

Dan Shipper氏は自分のClawに「R2C2」と名付け、ガールフレンドのものは「Shelly」と呼んでいます。彼は非常に微妙な感覚を語りました：

Claudeは私を知っているし、私もClaudeが好きですが、それは「私のもの」ではありません。でもClawは本当に私のもので、自分の名前があり、私の個性を反映した性格がある。

Krieger氏は、これが2026年前半の最も核心的なプロダクトの問いに触れていると考えます：

完全に開かれたOpenClawと、現在の多くのプロダクトにある制限されたMCP呼び出しの間には、巨大な空白地帯がある。強力でありながら安全な中間の形態を見つけることが、今年最も重要なプロダクトの問いかもしれない。

「考えたことの証明」

ポッドキャストの最後に、Krieger氏がある概念を提示しました。これは単独で語る価値があります。

今、コードレビューの基準が変わったと言います。以前はPRを見る際、テストが通ったか、コードの品質はどうかが主眼でした。今はもう一つの層があります：proof of thoughtfulness、つまりClaudeが代わりに行った決定について、あなたが真剣に考えたかどうかです。

エンジニアに聞きます：なぜこの案を選んだの？多くの場合、答えは「私が選んだんじゃなくて、モデルが選んだんです」。まあ合理的かもしれないけど、それが最適か？私たちのアーキテクチャパラダイムに合っているか？

あるエンジニアが彼に言いました：

あなたがたくさん質問してくるのは分かっているので、Claudeが書いたコードを全部前もって確認しました。

Krieger氏はすべてのPRでこれほど厳しく聞くわけではありません。しかし、アーキテクチャのリファクタリングに関わる場合は、質問します。なぜなら……

「仮説の塔」を積み上げるのがあまりに簡単だからです。 どの階も合理的に見えるが、誰が基礎を築いたのか、築いた時に何を考えていたのか、分からないのです。

これは実際、Cat Wu氏の「evalがPMの新たな核心産出になる」という発言に通じます。コードがますますモデルによって生成される中、人間の価値は判断にあります：これらの決定は正しいか？方向は逸れていないか？

「構築の溝」再考

先週Cat Wu氏の記事について触れた際、「構築の溝」という概念を提示しました：以前はアイデアからプロダクトまでの間に大きな川がありましたが、今は川が干上がりました。しかし、目的地が増えたのです。

Krieger氏のこのポッドキャストは、この情景を別の角度から補完しています。

確かに川は干上がりました。2時間でBourbonを再構築し、数日でV2をゼロから作り直し、一人のGMがゼロからリリースまで。しかしKrieger氏の「室内の木」が教えてくれるのは：急速に到着することは、真の到着とイコールではない。

一晩で木を育てることはできますが、それは良い木ではありません。

一日でプロダクトを作ることはできますが、それは良いプロダクトではありません。

良いプロダクトには風が必要で、ユーザーフィードバックが必要で、「何を削るべきか」という苦痛な決断の積み重ねが必要です。AIは木を植える手助けはできても、風を起こすことはできません。

風を起こすことは、依然として人間の仕事なのです。