Instagram創業者との対談：Anthropicが「Fable 5」をリリース——手作業によるコード記述の時代は終わりを迎えた
TechFlow厳選深潮セレクト
Instagram創業者との対談：Anthropicが「Fable 5」をリリース——手作業によるコード記述の時代は終わりを迎えた
Sonnet と Fable 5 は、体感レベルがまったく異なります。
Web3業界の深掘り報道に専念し潮流を洞察編集・翻訳：TechFlow
ゲスト：マイク・クリーガー（Mike Krieger）氏、Instagram共同創設者
司会：ダン・シッパー（Dan Shipper）氏
ポッドキャスト元：Every
オリジナルタイトル：Mike Krieger Lets Fable 5 Code While He Sleeps
放送日：2026年6月11日
要点まとめ
マイク・クリーガー氏はInstagramの共同創設者として、過去20年間にわたって人類社会に最も大きな影響を与えた消費者向けアプリケーションの一つを自ら手がけました。そして今日、彼は「エージェントネイティブ（AIネイティブ）」製品開発の最前線に立ち、Anthropic Labsのリーダーとして、究極の課題に挑んでいます。「世界で最も優れたAIモデルを、本物の開発者たちの手に渡したとき、技術の能力限界はどこまで押し広げられるのか？」
Fableの正式リリースから5か月前の段階で、彼が社内での初の体験アクセス権を取得した際、その衝撃と失速感は今でも鮮明に記憶に残っています。「やれやれ、また完全な初心者に戻ってしまったな」と、当時彼はチームに対して自虐的に語りました。彼は突然、これまで数十年にわたって積み重ねてきた効率性向上、開発戦略、さらには時間管理に関する経験則が、一瞬にして陳腐化してしまったことに気づいたのです。モデルの進化スピードは、すでに彼の既存のワークフローを大きく凌駕していました。
本回では、司会者とマイク・クリーガー氏による深遠な対談を通じて、Fableのような時代を超えるハードコアなモデルと並走し、ソフトウェアを共に構築することとは、一体どのような体験なのかを探ります。この新たな人間とAIの共生状態において、どのような新しい開発リズムが生まれ、どんな厳しい課題に直面し、そして想像を超えるような究極の可能性が開かれるのでしょうか？
注目すべき主張の要約
Fableがマイクのワークフローをどのように根本的に再構築したか
- 「真の認知的アップグレードは、最初の体験ではなく、数週間にわたる集中した継続的な使用によって得られるものだ……関わり時間が長くなるにつれ、人々は突如気づく：『これまで私はこのモデルを十分に活用していなかった。もう一歩踏み出し、この世代のモデルの能力限界を改めて考え直さなければならない』と。」
- 「今の正しい使い方は、よりマクロかつ十分な意図を伝えたうえで、あとは完全に任せるということだ。驚嘆すべき成果を一度に提供するだけでなく、さらに恐ろしいことに、その機能の将来の進化方向やプロジェクト全体のコンテキストを理解する能力がある。」
- 「私を最も圧倒したのは、その自動クローズループ（自己完結）能力だ。例えばこう考える：『マイクが今夜、複雑なタスクを実行するよう命じた。だが、リモートサーバーがダウンしており、作業が止まっている。それならまず、自分自身でモックバックエンドを書いてカバーしよう……』という具合だ。このようなレベルのタスクを委託し、最終的な成果を完全に信頼できるという体験は、非常に衝撃的だ。」
- 「これまで我々は、こうしたモデルを『アシスタント』や『パートナー』と比喩してきたが、今やそれは、責任を負い、大量のコア業務を遂行できる『本格的なチームメイト』に近づいている。」
SonnetとFable、それぞれを使うべきタイミングとは
- 「これはまったく次元の異なる感覚だ。単に1秒あたりのトークン出力数の問題ではない。むしろ、この課題を解くためにどれだけの『脳容量』が必要かという問題なのだ。時に、シンプルな回答には、過剰な深層思考など不要である。」
- 「私がiOSアプリを開く大多数の場面では、Fableを動員するほどの重い作業をこなすつもりはない……『この問題にはFableを呼ぶ必要すらない。Sonnetに答えさせればいい』という微妙な判断感覚を、最近強く実感している。」
- 「Fableは、私が初めて『推論努力度（Reasoning Effort）』を自ら調整する必要に迫られたモデルでもある。……以前Opusを使っていたときは、このパラメータをほとんど調整しなかった。なぜなら、当時のモデルのスケーラビリティ範囲はそれほど広くなかったからだ。しかしFableの可変幅は本当に広い。」
Fable 5がもたらすAgent-nativeアーキテクチャ
- 「いわゆるAgent-nativeアーキテクチャの第一段階とは、製品内のすべてのコアコンポーネントおよびデータが、エージェントに対して完全にオープンであり、それぞれに対応するツール呼び出しインターフェースを持つことである。これはすでにソフトウェア業界における『最低限の生存ライン』になりつつある——悲しいことに、現時点で市場に出ているほとんどのソフトウェアは、この基本条件すら満たしていないのが実情だ。」
- 「アプリ内でチャットボタンを長押しすると、私たちのホスト型エージェントが起動し、『コード修正指示』を受け取る……私は子供と外で遊んでいるときに『このフローティングボタンのiOS上での位置が低すぎます』と感じ、アプリ内でそのままそれを伝えただけで、エージェントがバックグラウンドでコードを修正してくれた。」
- 「Claudeをソフトウェアにどう組み込むか？それは単なる『利用』のレベルにとどまるべきではない。むしろ、ソフトウェアの『構築』そのものの骨髄に深く埋め込まれるべきだ。」
構築コストの急激な縮小
- 「InstagramのV1バージョンを振り返ると——機能的には、私が今週末に作ったメディア追跡ツールよりも確かに多く持っているが、量的差異という意味では、本質的な違いはまったくない。あのV1を作り上げるために、ケヴィンと私は連続して5晩徹夜した……ところが今や、構築時間は信じられないほど短縮されている。」
- 「『意図』から『実行』へ至るまでのあの深い溝は、プログラミングを知らない一般の人々にとって、すでに平準化されてしまった。……これは私の人生で初めて、自分の頭の中にあるアイデアと現実世界に存在するものとの間に、まったく距離がないと感じた瞬間だ。私はそれをそのまま形にできるのだ。」
- 「人間の創造力は無限である。そして今日私たちが成し遂げている最も素晴らしいことは、『心に思い描いたものを現実に変える能力を持つ』人々の範囲を、無限に拡大していることだ。」
ソフトウェアエンジニアリングは死んだのか？
- 「ソフトウェアエンジニアリングの本質は完全に変わった。それはまさに天変地異とも言える激変を経ている……純粋にコードを書く職人気質の時代は、ほぼ確実に、二度と戻ってこないだろう。」
- 「上級エンジニアの役割は依然として不可欠だ：長年の事故対応経験により絶対的な冷静さを保ち、ログデータを網羅的に収集し、緊急措置を講じ、その後で根本的な長期的修復策を立案する必要がある。」
- 「かつてシリコンバレーで流行した『コードが議論に勝つ（Code wins arguments）』という言葉について、個人的にはあまり賛同できなかった。なぜならその裏には『コードが書ける者が、発言権を握る』という暗黙の前提があるからだ。しかし今や、状況は逆転して非常に興味深い展開を見せている：製品のある方向性について意見が分かれているとき、しばしばコードを書かないPMが『さっき自分でデモを作ってみたんだけど……』と話しかけてくる。これだけで、全く別次元の高次元な対話が即座に始まるのだ。」
- 「最も顕著な特徴は、恐怖を覚えるほどの開発並列度と、チームがワークフローを高度に抽象化する絶対的な必要性だ。ただし、唯一、一貫して変わっていないのは、人間が製品に対して抱く『所有権と責任感』である。」
検証の仕組みと価格
- 「現在の『コスト』という概念は、多面的なものへと進化している——単なる『一回の問い合わせコスト』だけでなく、『一件のタスクを完全に遂行するための総合コスト』を計算する必要がある。Fableが私を最も驚かせた点はまさに後者だ：常に一発で正しく仕事を完了しようとし、私がパソコンの前で何回もやり取りする必要がない。」
- 「この新しい常態に適応し、どう共に働くかを理解することは、私たち全員が学ばなければならない。……私が何かを構築する際、Claudeが出すすべてのPR（プルリクエスト）に、iOSのPRであれUIレイヤーの変更であれ、必ず写真または動画を添付するようにしている。これによって、大きな安心感を得ている。」
- 「動画は、Claudeにとって極めて未活用のツールである。最近、私はあるプロトタイプを試している：Claudeが構築したものを動画録画し、FFmpegと併用して、それをClaudeに与え、フレーム単位で分析させ、『このアニメーションにカクつきがある。直します』と言わせるのだ。スクリーンショットでは決して捉えられない、その一瞬の問題を動画なら捉えられる。」
ダイナミックワークフロー
- 「前世代のモデルの『最低限の生存ライン』では、プロジェクトには『複雑度の天井』が存在していた。ビジネスコードやロジックが一定規模以上に膨らむと、大規模言語モデルは『頭だけを見て尻を無視する』ようになる……だが今や、コードを書かない女性同僚が、Fableクラスのモデルを活用して、彼女のシステムをバックグラウンドで数か月にわたって育て続けている。そのソフトウェアが、まるで生きている有機体のように、AIの灌漑によって絶え間なく成長し、成長し、猛烈に進化していく様子を、あなたは明瞭に見ることができる。」
- 「ワークフローは、良い中間地点だ。チャットでそれを編成し、コードで表現し、清潔なUI上で実行される。各ステップで何が起こっているかが明示される。今後、我々は長期間の視野を持つ作業とチャットをつなぐために、同様の方法を採用していくだろう。」
Fableがマイクのワークフローをどのように根本的に再構築したか
司会 ダン・シッパー：本回のゲストは、Anthropic Labsの責任者であり、Instagramの共同創設者でもあるマイク・クリーガー氏です。マイク、このモデルを深く使い込んだ後のリアルな体験をお聞かせください。こんなに強力なモデルが登場したとき、毎日それを重度に使っている人がこう言うと、「ここが驚くほど強い」「ここが実際にワークフローを変えた」「ここは実はそこまででもない」という情報は、技術を日常にどう取り入れるかを考える上で、非常に貴重な指針になります。
マイク・クリーガー：
まさにその通りです。この経験自体がとても興味深いものです。Fableの正式リリースの数か月前、私たちは社内でMythosクラスのいくつかのモデルをすでに使用していました。外部の開発者がこれらを使って何を作るかを見るのを楽しみにしていたのですが、ご指摘の通り、真の認知的アップグレードは、初日の体験ではなく、数週間にわたる集中した継続的な使用によって得られるものです。
我々は、以前のモデルでもこうした認知の再構築を経験しています。昨年12月下旬から今年1月初旬にかけて、Opus 4.5および4.6を集中して使用した際、関わり時間が長くなるにつれ、人々は突如気づきました。「これまで私はこのモデルを十分に活用していなかった。もう一歩踏み出し、この世代のモデルの能力限界を改めて考え直さなければならない」と。
司会 ダン・シッパー：Our Everyチーム内でもすでに一部のメンバーが使用を始めています。ある人は「このモデルを操るためには、まったく新しいスキルツリーが必要だ」と述べており、特に技術的背景を持たず、知識労働中心の同僚たちは、どう手をつけていいかわからずにいるようです。一方、エージェント（AIエージェント）のオーケストレーションを担当するメンバーは、「学ぶべき新技術が多すぎる」と嘆いています。
マイク・クリーガー：「ワークフローの変換」というお言葉は、まさに核心を突いています——それは単なる操作手順の変更ではなく、むしろ考え方そのものの変革です。ちょうどタイミングよく、このモデルの登場は私の職務変更期と重なりました：私はちょうどCPO（最高製品責任者）からLabsへ移り、再び開発者モードに戻ったところでした。移動してから約1か月半～2か月の頃、社内で初めてこのようなモデルの実行が成功しました。私はパソコンの前に座り、「やれやれ、また初心者に戻ってしまったな」と思いました。なぜなら、これまでのプロンプト作成習慣や、タスクを分解する思考法が、このモデルの前では完全に古びてしまっていたからです。
あなたの時間感覚とインタラクション・スタイルは進化しなければなりません。以前なら、「機能のアイデアがあります。まずは第一ステップから始めましょう」と言うところですが、今やそれは絶対にできません。今の正しい使い方は：よりマクロかつ十分な意図を伝えたうえで、あとは完全に任せるということです。 3月～4月頃には、すでにその能力に驚かされていました——驚嘆すべき成果を一度に提供するだけでなく、さらに恐ろしいことに、その機能の将来の進化方向やプロジェクト全体のコンテキストを理解する能力があるのです。
そしてこの進化は、まだ止まっていません。今朝も飛行機の中で仕事の話をしていたのですが、「大部分の仕事は、実はリモートで完遂できる」と気づきました。Wi-Fiが途切れるのではないかと不安に思うこともなくなりました。なぜなら、ネット切断前に適切なコンテキストと命令（例えば、ループ実行するコマンド）を設定しておけば、それが終了するまでタスクを監視し続けるからです。
過去2か月間、私は何度もこのようなハイライト・モーメントを経験しました：就寝前にClaudeに「おやすみなさい」と言い、複雑なタスクを投げると、翌朝起きたときにはすべて完了しています——通常は深夜2時頃に主体部分が終わり、残りの4時間は細部の磨きに費やされています。
最も私を圧倒したのは、その自動クローズループ能力です。例えばこう考えます：「マイクが今夜、複雑なタスクを実行するよう命じた。だが、リモートサーバーがダウンしており、作業が止まっている。それならまず、自分自身でモックバックエンドを書いてカバーしよう。問題をドキュメントに記録し、まず全体のフローを実行・保存し、明日サーバーが復旧したら修正しよう。」このようなレベルのタスクを委託し、最終的な成果を完全に信頼できるという体験は、非常に衝撃的です。
もちろん、結果は必ず確認しなければなりません——これは完全な検証メカニズムに関係し、後に詳しく説明できますが、それはクローズループの極めて重要な一環です。しかし、この経験は私にこう問いかけます：このようなモデルに直面したとき、果たして何が「効率的」と言えるのか？これまで我々は、こうしたモデルを『アシスタント』や『パートナー』と比喩してきたが、今やそれは、責任を負い、大量のコア業務を遂行できる『本格的なチームメイト』に近づいているのです。
司会 ダン・シッパー：では、あなたの日常的なワークフローは具体的にどのようなものなのでしょうか？私は気づいたのですが、宏大なタスクを投げ、長文で詳細を伝え、数時間あるいは一晩かけて処理させるとき、そのパフォーマンスは最も高いようです。しかし、日常的な些細なタスクでは、遅く、高価で、使う気になれないという印象もあります。実際の仕事では、それをどうバランス取っているのでしょうか？あなたの技術スタックにおいて、それはどのような位置づけですか？
マイク・クリーガー：
私は今、主に初期のアーキテクチャ設計およびソリューションの合意形成に使うようになりました。これは非常に興味深い変化であり、現在すべてのモデルが克服すべき難問でもあります。
この点については、Instagramを立ち上げた経験に感謝しています——ロサンゼルスの一台のサーバーで最小限のバージョンを急ごしらねで立ち上げ、その後大量同時接続への対応やスケーリングを行い、最終的にFacebookのインフラに統合するまでの一連の過程は、『プロジェクトのどの段階で、どのレベルのアーキテクチャ抽象化と複雑さを適用すべきか』という直感を養ってくれました。
そのため、私は今もFableと頻繁に相互作用を続けています。時には、見た目は完璧な実装案を提示されても、「この機能は近々本番投入する予定です。単一マシン以外の負荷耐性も考慮する必要があります」と指摘します。このような双方向のやりとりは極めて重要です。しかし、アーキテクチャ設計の段階では、通常、HTMLページを生成させて、私たちの議論内容を視覚化し、チームと共有します。Markdownファイルでも構いませんが、私は図表付きの方が好みです。
こうして、とても興味深いパラダイムが生まれました：一緒に考え抜き、計画を立て、チームとの合意形成のためのドキュメントを生み出す。 今や、プロトタイプの構築速度が劇的に短縮されたため、事前の合意と調整がより重要になっています——たとえ「小さなステップで素早く進める」デモから始め、その後で厳密なシステムアーキテクチャを逆算的に導き出すとしても、事前のコミュニケーションは不可欠です。まさにここが、人間の思考と協働が依然として深く組み込まれているプロセスの一部なのです。
実行段階では、夜間やまとまった昼の時間を活用して、異なるタスクモジュールを並行して処理させることで、私はこれまでよりもずっと多くの並列セッションを維持しています。私は、長時間実行中のClaude Codeセッションを常時開いておくのが好きで、タスクをバックグラウンドのサブエージェントにフォーク（派生）させ、メインスレッドは私の新しい指示にいつでも応答できるようにします。あるいは、ブラウザで同時に5〜6個のタブを開き、それぞれが長期間の複雑なタスクを処理するようにすることもあります。
この、長期的な視野を持ち、「心配しないで、任せてください。少し時間がかかりますが」という運用モードには、確かに大きな可能性が秘められています。私たちは現在、製品レベルでこうした体験をより良くサポートする方法を模索しています——あなたは「即時応答」と「長時間実行」の両方の状態を兼ね備えたいと思うでしょう。それらの相互作用は非常に興味深いものです。私の個人的な好みは、少なくとも一つの高コンテキストかつ極めて高速に応答するClaudeウィンドウを手元に保つことです。それは「いつでも待機中、一声で即座に起動したり、サブタスクを派生させたりできます」という直感を伴います。
SonnetとFable、それぞれを使うべきタイミングとは
司会 ダン・シッパー：例えば、あなたが道を歩いていて、ふと疑問が浮かんだとき——Fableを取り出して使うでしょうか？それはまるで「蚊を退治するためにロケットランチャーを使う」ようなものではないでしょうか？それとも、異なるモデルを頻繁に切り替えているのでしょうか？
マイク・クリーガー：
先日、私は何をするにもFableを使っていました。すると、あなたが仰った通りの体験をしました——画面を見つめ、ひたすら考え続けている様子を眺めていたのです。
しかし先週、ちょっと恥ずかしいほど単純な質問を調べる必要があり、NBAファイナルについてでした。そのとき、私はスマートフォンのモバイル版Sonnetに切り替えたのですが、すぐに気づきました。「ああ、そうだった！こういう素早い質問は、昔からSonnetで調べていたんだ。」これはまったく次元の異なる感覚です。単に1秒あたりのトークン出力数の問題ではなく、この課題を解くためにどれだけの『脳容量』が必要かという問題なのです。時に、シンプルな回答には、過剰な深層思考など不要であるのです。
私たちの製品チームにとっても、これは非常に興味深い問題です。総じて言えば、ユーザーが日々のフロントエンドでどのモデルを選ぶかを悩ませたくはありません。理想的には、長期的には、それらを極めて直感的で、すぐに使えるシナリオの「バケット」に収束させたいものです。あるいは、インタラクション・インターフェースに基づいて分流させるのも一案です——実際のところ、私がiOSアプリを操作する大多数の場面では、Fableを呼び出すほどの重い作業をこなすつもりはないからです。したがって、UI側でモデルを無意識に固定するというアプローチも考えられます。今後、これが製品レベルで何を意味するかをしっかり探っていく必要があります。しかし、「この問題にはFableを呼ぶ必要すらない。Sonnetに答えさせればいい」という微妙な判断感覚を、最近強く実感しています。
おっしゃる通り、高頻度・細粒度のインタラクティブなタスクに対しては、Fableは自然と深く考えようとします。実際、Fableは私が初めて『推論努力度（Reasoning Effort）』を自ら調整する必要に迫られたモデルでもあります——時には「ただUIスタイルを変更したいだけだ。努力度を『中程度』に設定して、その効果を見てみよう」と考えます。以前Opusを使っていたときは、このパラメータをほとんど調整しなかった。なぜなら、当時のモデルのスケーラビリティ範囲はそれほど広くなかったからです。しかしFableの可変幅は本当に広いのです。
マイクが週末に作ったメディア追跡ツールが明らかにする、agent-nativeアーキテクチャの本質
司会 ダン・シッパー：あなたが実際にそれを使って作ったものを見せていただけますか？
マイク・クリーガー：
この新モデルのリリースに際して、私たちはチーム全員に、個人アカウントでそれを使ってみるよう勧めました。特に週末の時間を使ってもらうことを推奨しました。これはとても面白い試みで、Anthropic内部には多くのカスタム生産性ツールがありますが、時折一歩引いて、最も純粋な状態に戻ってみるのです。「ただ純粋なClaude Codeを使って、週末に自分だけの楽しい小さなものをつくる。」そんな感覚はとても素晴らしいものです。
司会 ダン・シッパー：あなたはターミナルアプリで実行したのですか？それともデスクトップアプリですか？
マイク・クリーガー：
とても良い質問ですね。私はほとんどの時間をターミナルで過ごしています。しかし面白いことに、私の妻は専門のエンジニアではありません。UX（ユーザーエクスペリエンス）デザイナーとPM（プロダクトマネージャー）の背景を持っていますが、彼女はデスクトップアプリを通してClaude Codeを完全に愛しました。デスクトップアプリは、彼女が底辺の高度な抽象概念から遮断してくれたからだと思います。しかし、私がこのプロジェクトを実行する際には、Ghosttyとターミナルを使いました。
私は、完璧な「メディア進行度トラッカー」が欲しかったのです——普段はゲームをしたり、ドラマを観たり、友人からのおすすめをたくさん受けます。私の収納習慣に完全に適合するツールが必要でした。私の2つのコア基準は以下の通りです。第一に、追加が極めて容易であること：Claudeに音声またはテキストで一言伝えるだけで、インターネット全体を検索し、情報を補完・分類して整理してくれる。第二に、能動的なプッシュ通知：新シーズンやゲームの続編がリリースされた場合、自動的に探しに行くこと。
大部分のUIはFableが一発で完成させました。これはすでに非常にすごいことです。しかし、私がLabsで今年ずっと追い続けているテーマは：ソフトウェアチーム——つまり今はClaude——とソフトウェアそのものとの距離を、いかにさらに縮めるか？
それは土曜日の朝のことでした。私は週末全体を子供と過ごす予定で、開発は基本的に「断続的」なものでした：子供と山登りに行き、帰宅し、数行書き、また外出する。山登り中にも、進捗をチラッと見る忍不住衝動がありました——子供といるときはスマホを見るのはいけないことですが、スマホでリモートでタスクがどこまで進んでいるかを監視するのは、とても爽快な気分でした。
そこで私はあるアイデアを思いつきました：ちょっと過激な実験として、ソフトウェアがその内部から自己修正するようにすることはできないか？
私は、モバイル版とウェブ版の2つのバージョンを同時に作成させました。もともとチャットインタフェースを用意していたので、直接Claudeに「このURLを追跡リストに追加してください」と言えます。しかし、すべてのソフトウェアがこのような能力を獲得することを目指しました——私は、さまざまな複雑なメニューを掘り下げて機能を探すのはもう嫌なのです。
Dan、多くの点で、私はエージェントネイティブアーキテクチャを、最も極限の境界まで押し進めようとしているのです。
いわゆるAgent-nativeアーキテクチャの第一段階とは、製品内のすべてのコアコンポーネントおよびデータが、エージェントに対して完全にオープンであり、それぞれに対応するツール呼び出しインターフェースを持つことである。これはすでにソフトウェア業界における『最低限の生存ライン』になりつつある——悲しいことに、現時点で市場に出ているほとんどのソフトウェアは、この基本条件すら満たしていないのが実情だ。
良い例があります：先日、誰かがブラジルの神ドラマを紹介してくれました。ゴイアニアでの放射性物質漏洩事件を扱った作品で、名前が非常に長く、覚えにくいものでした。私は曖昧にシステムに一言伝えると、Claudeが即座に検索し、正確に分類してくれました。これは、自分が直感でGoogleを検索して彷徨うより、はるかに優れた体験です。
しかし、私が本当に夢中になっている次のステップは：モバイル環境下で、ソフトウェアの内部からソフトウェア自体を直接修正するということが、どう展開していくのか？
私が行った——正確には私がClaudeに指示した——のは、このようなインタラクションです：アプリ内でチャットボタンを長押しすると、私たちのホスト型エージェントが起動し、「コード修正指示」を受け取り、Vercelのライブプレビュー（Live Preview）機能を活用して即座に効果を確認します。この機能モジュールもほぼ一発で動作し、非常にクールでした。その後、私は少しずつ新しいアイデアを追加していきました。ハードコアなプレイヤーであれば、Diff（コード差分）ビューを確認したり、ホスト型エージェントの会話履歴をクリックして、それが実際に何を変更したかを確認することもできます——ただし、私はほとんど見ません。なぜなら、個人用の玩具プロジェクトにおいては、長期的な保守性など気にしないからです（笑）。
これは本当に中毒性があります。子供と外で遊んでいるときに、「このフローティングボタンのiOS上での位置が低すぎます」と気づき、アプリ内でそのままそれを伝えただけで、エージェントがバックグラウンドでコードを修正してくれました。Expoの開発ツールチェーンと組み合わせると、私のスマートフォン上で直接ホットリロード（Hot Reload）を実行してくれ、その瞬間の体験はまさに絶妙でした。
このものは、百万ユーザーの並列アクセスに耐えられる本番レベルの品質である必要はありません。しかし、それは私に非常に優れたコントロール感を与えます：週末が終わり、パソコンを閉じた瞬間にプロジェクトが停止する必要はありません——あなたはそれを重度に使いながら、その使い方の過程で、いつでもそれを改造できるのです。このエンドツーエンドのリアルタイムクローズループにより、あなたは無限に反復・進化させることができます。
これは単にFableのハードコアなエンジニアリング構築能力を華麗に披露するだけのものではなく、私たちが常に議論している究極の命題の縮図でもあります：Claudeをソフトウェアにどう組み込むか？それは単なる『利用』のレベルにとどまるべきではない。むしろ、ソフトウェアの『構築』そのものの骨髄に深く埋め込まれるべきだ。
構築コストの急激な縮小
司会 ダン・シッパー：私は皆さんにぜひ認識していただきたいことがあります：このようなツールは、10年、20年前にも、別の方法で作ることはできたかもしれません。しかし、今のような方法では絶対に作れませんでした。ソフトウェアの構築コストは、崖崩れのように急激に縮小しています。Instagramを制作していた当時、このような完成度のプロジェクトを実現するには、どれだけのリソースが必要だったでしょうか？今ではどれだけ必要でしょうか？この時代の劇的変化を、数字で教えてください。
マイク・クリーガー：
私はその時代をよく思い出します。Instagramの創業初期、私は自分を非常に効率的なエンジニアだと考えていました——モバイル開発に情熱を持ち、製品の方向性に対する直感も鋭かったです。それでも、頭の中に浮かんだアイデアを最終的に完全に実現するまでには、少なくとも4～5晩の徹夜が必要でした。当時は徹夜が日常茶飯事でした：朝4時まで修行し、昼まで眠る——このような生活リズムは、家庭生活とは完全に隔離されていましたが、それが当時の私の「ビルダー（構築者）モード」だったのです。
InstagramのV1バージョンを振り返ると——機能的には、私が今週末に作ったメディア追跡ツールよりも確かに多く持っているが、量的差異という意味では、本質的な違いはまったくない。あのV1を作り上げるために、我和ケヴィンは連続して5晩徹夜しました：私はフロントエンドとバックエンドのすべてを一人で担当し、ケヴィンは初期の画像フィルターを担当しました。しかも、これは私たち二人がいずれも長年にわたってiOS開発の経験を持っているという前提の上での話です。
当時の反復サイクルの息苦しさは、さらに言及する価値があります。製品が一発でヒットした後、私たちの頭の中には無数の新アイデアが詰まっていましたが、当時のすべてのエネルギーは、大規模トラフィック下でサーバーが落ちないようにすること、あるいはわずかな追加機能をなんとか実装することに費やされていました。ハッシュタグ（#）機能ひとつを完成させるのに、私は1週間を費やしました。そして、他にも実現したい1万のアイデアが、スケジュール上で固く封印されていたのです。
だから、これは単に時間が短縮されたという話ではありません——確かに構築時間は信じられないほど短縮されていますが、それ以上に重要なのは、その裏側の硬貨のもう一面です：今や、あなたは極めて滑らかで流動的な方法で、既に手元にあるものを即座に反復・改善できるのです。
さらに、この恩恵は、私のような専門的なソフトウェアエンジニアや創業者の輪をはるかに超えて広がり始めています。以前は、優れたビジネスアイデアを持っていても、自分でコードを書けない場合、選択肢は2つしかありませんでした：外注に頼む——しかし、その過程で深刻な情報の歪みや不十分な納品が起こる可能性が高い、あるいは、必死に資金調達を試みる。しかし今や、『意図』から『実行』へ至るまでのあの深い溝は、プログラミングを知らない一般の人々にとって、すでに平準化されてしまった。
先日、私の同僚から内部メッセージ（Ping）が届きました。私たちは彼女のために内部ツールを設定し、Fableの機能と、私たちの内部MCP（モデルコンテキストプロトコル）へのアクセス権を連携させました。彼女は採用（HR）担当者で、興奮してこう言いました：「これは私の人生で初めて、自分の頭の中にあるものと、現実世界に存在するものとの間に、まったく距離がないと感じた瞬間です。私はそれをそのまま形にできるのです。」
その瞬間は、彼女にとって間違いなく、画期的な衝撃の瞬間でした。もし4～5年前のことなら、彼女が独自の業務ツールを使いたいと思ったとしても、既存のソフトウェアを寄せ集めてごまかすか、内部ツールチームのエンジニアに泣きつくしかありませんでした——しかし、そのエンジニアのJiraの要望リストには、すでに50件以上の優先度の高い依頼が並んでいたはずです。しかし今や、彼女はコードの世界で自由に開拓を楽しんでいます。
これが、私が未来で最も期待している点です：人間の創造力は無限である。そして、今日私たちが成し遂げている最も素晴らしいことは、『心に思い描いたものを現実に変える能力を持つ』人々の範囲を、無限に拡大していることだ。
ソフトウェアエンジニアリングは死んだのか？
司会 ダン・シッパー：私はあなたの見解に完全に賛同します。しかし、おそらく今多くの人が心に懸けている究極の疑問があります。あなたが先ほど説明したすべてを聞いて、ソフトウェアエンジニアリングという職種は、完全に終焉を迎えてしまったのでしょうか？
マイク・クリーガー：
むしろ、ソフトウェアエンジニアリングの本質は完全に変わったと言えるでしょう。それはまさに天変地異とも言える激変を経ているのです。
もし、Instagramを作っていた時代に「ソフトウェアエンジニアリングとは何か？」と尋ねられたなら、私はこう答えたでしょう：「厄介な設計課題を徹底的に考え抜き、システムアーキテクチャを構築し、TextMateやXcodeで膨大な時間を費やす。Django ORM（オブジェクト関係マッピング）の低層の詳細を追究し、デプロイして、Bugを苦労して修正する。」今や、このプロセスの大部分が覆され、製品マネジメントの領域へと急速に近づきつつあります。今や、プロダクトマネージャーとエンジニアの間の明確な境界線は、極めて曖昧になってきています。これは、私たち自身のR&Dチームでも明確に見られます。
しかし、「ソフトウェアエンジニアリング」というあまりにも硬直的な文字通りの定義から離れ、より広義の「ソフトウェア生産」あるいは「ソフトウェア開発」——単にプログラマーがコードを書くという狭い領域に限定せず——を俯瞰すれば、この業界はむしろ元気いっぱいであり、かつてないほど中心的な地位に立っていることに気づきます。
Fableの登場は、AIモデルへの私の信頼を新たな高みへと引き上げてくれました——私は今、それを「完全自動クローズループを実行させ、合理的なシステムアーキテクチャ設計さえも任せられる」レベルまで信頼し始めています。技術実行の側面において、AIはすでに非常に遠くまで到達しています。しかし、「ソフトウェアという芸術の魂をつかむ」——つまり、ユーザーのどんな痛みを和らげているのか、作り出したものがどれほど驚くべき体験を提供しているのか——といった、トップレベルの判断力は、依然として非常に純粋で、機械に代替不可能な人間の特性です。
もちろん、このような痛みを伴う転換は、多くの人にとって無痛ではありません。
この世界には、多くの人々が「純粋に手作業でコードを書く」職人技に深く魅了されてきました。私もかつてそうでした。「このバグに3日間悩まされ、今日ついに解決できた！」という快感は代替できません。以前は、夢の中でコードと格闘することさえありました——もしそのような経験があれば、夢の中ではまさに死に物狂いで取り組んでいるロジックが繰り広げられ、目覚めた瞬間に突然閃いて解決策が浮かぶという経験です。この純粋な職人時代は、ほぼ確実に、二度と戻ってこないでしょう。
最近、私が知る中で最も優れたハードコアエンジニアたちと話す機会がありましたが、彼らは皆、強い複雑な感情を私に伝えています：一方では、伝統的な職人技が消滅していくという大きな喪失感を目の当たりにし、他方では、「天が開いたように、私の並列生産性が驚くほど高まっている」という極めて興奮した気持ちを抱いている。
Anthropicのエンジニアリングチームが今、どのように働いているか
司会 ダン・シッパー：この命題が成立する——ソフトウェアエンジニアリングは生き延び、しかも非常に元気だ——とすれば、Anthropic内部では、自社のR&Dチームが日常的にどのように仕事をしているのでしょうか？
マイク・クリーガー：
ここにはいくつか非常に明確なトレンドがあり、私は完全なソフトウェアライフサイクルと、私が毎日目にする開発の日常を絡めて説明します。
まず、依然として大量の「人間による合意形成」が行われています。チームは会議室に集まり、Coworkの次の進化方向についてブレインストーミングし、その青写真をメンバーごとの責任領域に分割します。このステップは依然として極めて重要です。なぜなら、現在のClaudeが空中から感知できない多くのグローバルなコンテキストを、人間のみが把握できるからです——例えば、この製品の真の商業的意図、現在の開発における隠れた課題、あるいは、近日中に終了する予定の他の製品ライン、あるいは極めて巧妙な方法で統合される予定の他の製品ラインなどの情報です。
私たちのチームには、各メンバーに複数のClaude巨大タワーが配備されていますが、管理上の責任は依然としてDRI（Directly Responsible Individual、直接責任者）という肩書きで個人に負わせています。各人が製品の特定モジュールに責任を持っています。この仕組みは短期的には消えることはないと考えています。なぜなら、「チームが分散して協働し、製品を磨き上げる」というマクロな大局観と、「今日、Claudeにこの具体的なタスクを実行させるにはどうすればいいか」というミクロな実行の間には、本質的なギャップがあるからです。私たちは極めて簡潔な会議制を推進していますが、このような事前のブレインストーミングと合意形成の会議は、依然として不可欠です。
第二に、大量の「非同期委任」が行われています。私たちの多くのエンジニアは、自分専用のパーソナルダッシュボードをカスタマイズしており、自分のClaude軍団が何をしているかを監視しています：「私のClaude Codeはどこまで進んだか？」「承認待ちでキューに溜まっているものは何か？」「他の同僚や、他の大規模言語モデルによるコードレビューで却下されたPRは、どれを私が介入して修正する必要があるか？」
今や、エンジニアの大部分のエネルギーは、このような作業のメンテナンスに費やされています。これらの協働ツールの一部は標準化を進めていますが、大部分は濃厚なギーク個人色を保っています——かつてプログラマーが自分のデスクトップウィンドウをパーソナライズするのが好きだったのと同じように、今や彼らは自分の大規模言語モデルのワークフローをパーソナライズしています。
第三に、本番環境下でのコードの実際の動作状況を理解することです。これは、現在の大規模言語モデルが全力で取り組んでいるもう一つの最前線です。Fableはこの点で着実な進歩を示していますが、まだ長い道のりがあります：例えば、コードがデプロイされて本番に上がった後に、実際に何が起こるのかを深く理解することです。システムはクラッシュし、予期せぬ奇妙な障害が発生します——正直言って、Instagramが2012年から2016年までの数年間、私はそのオンライン事故対応とアーキテクチャのスケーリングに、半分以上の命を捧げました。オンラインでの突発的な事象への対応において、上級エンジニアの役割は依然として不可欠です：長年の事故対応経験を基に絶対的な冷静さを保ち、ログデータを網羅的に収集し、緊急措置を講じ、その後で根本的な長期的修復策を立案する必要があります。
最後に強調したい点は：「エンジニアリングプロトタイプ」が今日果たす役割が完全に変わったことです。
あなたは、手元にあるものが単なるデモなのか、本番投入を前提としたプロダクションレベルのコードなのかを、極めて明確に区別する必要があります。かつてシリコンバレーで流行した「コードが議論に勝つ（Code wins arguments）」という言葉について、個人的にはあまり賛同できませんでした。なぜならその裏には「コードが書ける者が、発言権を握る」という暗黙の前提があるからです。しかし今や、状況は逆転して非常に興味深い展開を見せています：製品のある方向性について意見が分かれているとき、しばしばコードを書かないPMが「さっき自分でデモを作ってみたんだけど……」と話しかけてくる。そのデモは8つのディテールでまだ荒いかもしれませんが、「この道筋は絶対に通じる！」と主張します。これだけで、全く別次元の高次元な対話が即座に始まるのです。
振り返れば、私たちの現在のすべての開発姿勢は、6か月前と比べてまったく様変わりしています。最も顕著な特徴は恐怖を覚えるほどの開発並列度と、チームがワークフローを高度に抽象化する絶対的な必要性です。
しかし、唯一、一貫して変わっていないのは、人間が製品に対して抱く「所有権と責任感」です。
検証の仕組み
司会 ダン・シッパー：Fableは非常に高価です。私がテストしているとき、まるでキャンディショップに入った子供のように興奮して「これを、これを、そしてこれを！」と叫んでいます。しかし、支払いのときになると、毎回エンターキーを押す前に心配になります。「これで100ドル、いやそれ以上が吹っ飛ぶのではないか？」この高価格は、実際には「誰が使えるか」「何に使うか」に対して、目に見えない壁を築いていると思います。あなたはこの商業的コストパフォーマンスをどう評価しますか？
マイク・クリーガー：
専門的なソフトウェアエンジニアリングの領域では、この帳簿は実際には最も明確につけられます。価格設定については、内部で多くの次元の検討がなされています。確かにOpusよりはかなり高価ですが、単発で提供される驚嘆すべき作業量を商業的な観点から評価すれば、多くの点で安すぎるほどで、まるで無料で提供しているかのようです。もちろん、誰もがそれぞれの経済的帳簿を持っています。
ソフトウェアチームの観点から見ると、第一段階は企業が従業員にAIプログラミングを受容させること——モデルはまだ初期段階で、ツールも整っていない；第二段階は、誰が一番多く使っているかを競わせるランキングを導入すること——これはあまり理想的でないインセンティブ体制を生み出す；第三段階は、誰が最も効果的に使っているかを把握し、そうした人たちにできるだけ多く使ってもらい、無駄を生まない明確なプロセスを確立することです。
Fableはこの第三段階のロジックに完璧に適合しています。あなたがハードコアな成果を継続的に出し、ビジネス内で実際に真金の価値を生み出すことができれば、企業内部には自然と、あなたを無限に支援するポジティブなフィードバックループの予算メカニズムが形成されます。
個人使用に関しては、私は自分のクレジットカードで自費でサービスを購入してテストを行っています。この場合、あなたは確かにケチケチし、より慎重になります。しかし興味深いことに、私が週末に作ったメディア追跡ツールは、実際には普段よりほんの少し多くお金を使った程度で、個人用の遊びプロジェクトとしては、数千ドルを燃やすようなことはまったくありませんでした。
今、価格によって本当に足止めされているのは、大企業の保護下にない、価格に極めて敏感なオープンソース愛好家や独立開発者（Indie Hackers）です。彼らへの私のアドバイスは：思い切って実行してみてください。無限の「やり取りのやり直し」を経ずに、一度にどれだけのものを提供できるかを確かめてみてください。
今の『コスト』という概念は、多面的なものへと進化している——単なる『一回の問い合わせコスト』だけでなく、『一件のタスクを完全に遂行するための総合コスト』を計算する必要がある。 Fableが私を最も驚かせた点はまさに後者です：常に一発で正しく仕事を完了しようとし、私がパソコンの前で何回もやり取りする必要がないのです。
司会 ダン・シッパー：私が最も衝撃を受けたのは、あなたが宏大なタスクを投げると、提出された成果には隅々まで細部が推演され尽くしていて、その窒息するほどの繊細さは、これまでのどのモデルでも体験したことがありません。訓練に関する内幕を少し教えていただけますか？いったい何が、これほど恐ろしい洞察力を生み出したのでしょうか？
マイク・クリーガー：
多くの点で、それはチームの大量の作業の延長線上にあります——私の予測訓練およびRLチームには、ただただ敬服するばかりです。私にとって最も明確な進化は、「現在のこの作業に対する感知」ではなく、「システム全体に対する感知」です。
私は、そのような神がかり的な操作に何度も驚かされます。例えば、コードを書き終えた直後に、突然こう言います：「偉いさん、本番環境ではこの設定が違う可能性がありますよ。あなたの機能スイッチはオンになっていますか？もしオフなら、私が今書いたコードは本番投入しても機能しませんよ。」
あるいは、コードレビューのフィードバックに対して——人間からでも、他のClaudeからでも——単に「ああ、それは問題ですね。直します」と言うのではなく、現在の忠実度の下でリスクを受け入れるかどうかを真剣に考えたり、別のレビュアー——しばしば別のFableモデル——を反論したりします。「あなたの意図は理解しましたが、私は反論します。それは間違っていると考えます。」
モデルにこのような判断力を与えることは極めて重要です。私が指摘するならば、その進化で最も大きな点は、膝反射的に「はいはい、直します」と即座に言うのではなく、「ちょっと考えさせてください。私はまだ同意しません」という能力です。これは非常に有用です。
Claude Codeのような製品が市場にあることは極めて貴重です。なぜなら、生きたものがあることで、「ここがモデルが得意なところ、ここが不得意なところ」と人々が明確に言えるからです。私たちはEveryの仲間たちを、最も信頼するフィードバック源のリストの非常に上位に位置づけています。なぜなら、彼らがモデルに数日にわたる高強度のタスクを繰り返し与えることで、私たちが次世代で何を改善すべきかを深く考える上で極めて重要だからです。
司会 ダン・シッパー：チャットは、このモデルにとって最も適したインタラクション・インターフェースなのでしょうか？これは、単なるラウンドロビン式ではなく、誰かにタスクを委任するようなものです。これは、あなたがそれをどう使うべきか、あるいはこのインターフェースをどう見るかに、どう影響するのでしょうか？
マイク・クリーガー：
メッセージの送信と受信という基本的なモデルは、完全に間違っているわけではありませんが、私たちはいくつかの方向で進化する必要があります。
第一に：あなたのノートパソコンは、正しい場所なのでしょうか？これが、私が先ほどモバイル端末が個人プロジェクトに非常に便利であると述べた理由です。Claude Codeの創作者は、これらのモデルがどのように使われるかについて常に半歩先を行っています。およそ9か月前に彼と話したとき、彼は「私のClaude Codeの作業の大部分をモバイル端末に移しました」と言っていました。当時は懐疑的でしたが、特にFableのレベルになると、会話が継続可能で、Anthropicにはリモート開発機があるので、第一のポイントは：仕事が発生する場所と、仕事について議論する場所を切り離すことです。
第二点は、私が先ほど述べたこととつながります：Fableがこれまで議論し、決定し、提案したすべてのものを、どうすれば理解可能なものにできるか？これは、私たちが現在考えている領域です。図表を描くことができるスキルはありますが、現在のチャットUIは十分ではありません。Fableは時に膨大なテキストを提示し、あなたは散歩に出かけるくらいの余裕が必要になることもあります。私が始めたことの一つは、「この件についてのコンテキストは、私よりずっと多いです。では、複雑さを徐々に開示するという、より漸進的なアプローチをしましょうか？」です。
第三点は、多人数モードで、これはまだ初期段階の模索です。ある意味では、DRIと所有領域の構造があるため、重要なタスクは通常、一人と数人のClaudeの間で流れていきます。しかし、すべての場合がそう明確ではありません——例えば、事故対応では、複数の人が同時に考えています。あるいは、複数の交差する分野が集まるプロジェクトなどです。チャットの共有で一部は解決できますが、将来的にはこのようなニーズが出てくるでしょう：ある人が立ち上げた独立したClaudeが、多くの作業を完了しましたが、それがチーム内の他のすべての進行中の作業と同期を保てるか？これは、次に来る興味深く、まだ十分に掘り下げられていない最前線です。興奮すべきことに、モデルは今や、本当にチームメイトとなる能力を持っていますが、私たちが正しい抽象化を持っていないために、その能力を妨げているだけなのです。
司会 ダン・シッパー：これは、私がこのモデルを主に自分のvibe codingプロジェクトで使っていることに思い至りますが、組織内で使う場合、問題があります：私はモデルが今やったすべての部分を本当に理解しているでしょうか？モデルが今やったもののコンテキストを、私の頭に移すにはどうすればよいでしょうか？これは大きなボトルネックです。「私はどれだけ理解する必要があるか」という線をどこに引くか、そして十分なコンテキストを持って安心感を得るにはどうすればよいのか、あなたはどう考えますか？
マイク・クリーガー：
大きく2つの要素があります。第一に、検証です。私は今年初めに、検証の重要性を完全に納得させられました。これは、私がフルタイムでコードを書いていた時代の一つの出来事と共通しています：自分のアイデアを囲む、最もタイトな開発サイクルを見つけることです。Instagramの時代には、Xcodeで新しいビルドターゲットを作成し、その画面と合成データのみを含め、そのサイクルだけを反復することが意味することもありました。私は新人エンジニアに「もし私が一つだけ教えるなら、それはあなたのプロジェクトにこれを導入することだ。そうすれば、ずっと速くなります」と指導していました。
現在の状況は：私が何かを構築する際、Claudeが出すすべてのPRに、iOSのPRであれUIレイヤーの変更であれ、必ず写真または動画を添付するようにしています。これによって、大きな安心感を得ています。Fableは数時間かけて作業し、「終わりました」と報告してくるかもしれませんが、あなたが「ここがすべてのUIのスクリーンショットギャラリーです」という表示を見れば、非常に役立ちます。「スクリーンショットの8枚目にあるエラー状態——私は実際には見たことがありませんが、ユーザーが遭遇した場合にどうなるかはわかります。これを修正しましょう。」包括的な検証は、私たちが内部で積極的に進めていることです。
第二に：最終的には、あなたが自分の仕事に責任を負う必要があります。多くの人が毎日Claudeを使っていますが、依然として説明責任があります——「Claudeがコードを書いたかもしれないが、あなたはどのマクロな意思決定がなされたかを理解する必要があります。」私は多くのエンジニアが実践を始めているのを見ています：Claudeが作業を終えたら、その後に続く会話で「私がしたすべての妥協点を、本当に徹底的に理解できているか？」を確認します。どんな小さな成果物であれ、それを理解しやすくする価値があるのです。
会議中はとても面白いです——誰かが「このPRは準備ができました」と言い、別の人が「Xを選びましたか、Yを選びましたか？」と尋ねると、一瞬の沈黙が訪れます。「正直言って、あまり確信が持てません——マージする前に確認します。」この新しい常態に適応し、どう共に働くかを理解することは、私たち全員が学ばなければならないのです。
司会 ダン・シッパー：あなたが先ほど言及したこの「検証サイクル」には、非常に大きな想像空間があります。自動化されたスクリーンショットや画面共有に加えて、他にどんなよりハードコアなアプローチを模索していますか？
マイク・クリーガー：
私たちの核心的なアプローチは：静的なデータを注入するのではなく、実際のプロセスを実行させることができるか？システムが複雑になるにつれ、これはますます難しくなります。例えば、Fableが作成したiOSアプリが、ワンクリックで私たちのシミュレーション環境にログインし、すべての最も本物に近いテストアカウントと高忠実度の実際のストリームデータを呼び出せるようにしなければなりません。しかし同時に、ボタンの微調整をテストする際に、毎回8ステップの煩雑な新規ユーザー登録プロセスを実行する必要はないと考えます。そのため、AI専用の特別な高度な権限と暗号化された共有キー体系を独自に開発し、AIが事前チェックポイントを一瞬で通過し、最もコアなビジネス現場に直接入り込めるようにしました。これにより、AIのテスト体験は、実際のユーザーが手にした体験と、ほぼピクセル単位で一致するのです。
第二に、既知のパスと現在の変更パスの組み合わせ——前者はリグレッションテストに非常に価値があります。私たちは、理想化されたワークフローをテキストで表現し、Claudeがそれを繰り返しチェックできるようにしています。また、Claudeは現在行っている変更の意図を非常にうまく表現できるため、この部分は深く練習されます。この二つの組み合わせは重要です。
視覚検証も非常に重要で、動画はClaudeにとって極めて未活用のツールです。最近、私はあるプロトタイプを試しています：Claudeが構築したものを動画録画し、FFmpegと併用して、それをClaudeに与え、フレーム単位で分析させ、「このアニメーションにカクつきがある。直します」と言わせるのです。スクリーンショットでは決して捉えられない、その一瞬の問題を動画なら捉えられるのです。
エンドツーエンドでテストしにくい部分については、Claudeが信頼できるシミュレーションバックエンドを構築するか、既存のものを使用するのも非常に面白いです。アーティファクトの時代において、LLM以前の時代には非常に包括的なテストがありました。すべてのインフラストラクチャには、単体テストで高速に実行可能な優れたメモリ実装がありました。今、これをClaudeの領域に拡張しています：私はかなり堅牢なバックエンドを持つものを開発していますが、私の開発サーバーでは起動が難しいため、Claudeが一発で優れた代替品を提供してくれました。時間の経過とともに、この代替品はコードそのものの進化とともに進化しています。以前は「これを同期させるのは大変だ」と言っていたでしょう。今では「Claudeが変更を読み取り、代替品を適応させ、両方を同期させる。それでいい」と思うだけです。
司会 ダン・シッパー：非常に興味深いアーキテクチャがあります：バグを報告すると、エージェントが自動的に修正し、顧客に「修正しました」とメッセージを送信します。Fable上でこのようなプロセスに変化はありますか？
マイク・クリーガー：
いくつかの観点があります。人間とClaudeの層において、私が何度も目撃したことは：誰かがSlackのフィードバックチャンネルでバグを報告すると、そのスレッドがClaude Codeの会話に渡されるということです。Slack MCPのおかげで、実際にそのスレッドを取得し、私の身分で返信することができます：「これはマイクのClaudeです。修正しました。PRリンクはこちらです。」しかし、その後にこう言います：「お待ちください——まだ本番投入されていません。本番投入後に再度ご連絡いたします。」数時間後：「今回のデプロイが完了しました。修正が機能しているか、お試しください。」このようなクローズループのフォローアップは比較的新しいものです。私は、私の身分で対話している長期実行中のClaude Codeの会話が複数あります。その中には、免責事項もいくつか挿入しています。
第二に、先ほど話した品位と判断力が戻ってきます。一つのレベルは「バグの報告があったので、修正する」というものですが、もう一つのレベルは、良い判断力です。週末に私はある状況に遭遇しました。私たちの内部システムが長期間稼働しており、再起動されておらず、メモリリークが発生していました。良い判断はこうです：「マイク、今週末です。サーバーを再起動すれば、今すぐ解決できます。私は非同期で長期的な修正のPRを開きます。」もしClaudeにこのようなバグから修正までのプロセスを介入させたいなら、あなたは本当に、優れたSREやエンジニアが理解するものすべてを理解してほしいのです：目の前の問題を解決するが、プラットフォームを再構築するかどうかは別問題です。このバランスを理解することは極めて重要です。
人々がこのモデルを使って構築すべきもの
司会 ダン・シッパー：この新世代モデルが最も熱狂を呼び起こす点は、単に下限を引き上げ、背景のない一般人でもワンクリックで自分専用のアプリを作れるようにするだけでなく、専門家の天井をも打ち破っている点です。もし今、あなたが職業エンジニアやスタートアップの創業者であるなら、かつては想像すらできなかったハードコアなプロジェクトを、一人で完遂できる能力を完全に持ち合わせています。あなたが考える、人々がまだ気づいていないが、実際にはこの世代のモデルで大胆に挑戦できる最先端分野は何でしょうか？
マイク・クリーガー：
いくつかのアイデアを挙げると、まずは楽しいものから始めましょう。人々は、自分たちの世界の複雑さをどう表現するかについて、多くの創造的なアイデアを持っています。どの分野にも、あなたが特に詳しいものがあります。そして、いつも「これを他人にどう説明するか？他の分野の技術をこれに応用できないか？」というバージョンが存在します。私の妻の例を挙げると、彼女は最近、環境工学——特に地熱エネルギー分野——に跨領域で没頭しています。そこには、頭を抱えるような複雑な数学モデルと流体力学シミュレーションが溢れています。しかし、Fableという世代の推論モデルが断絶的に進化したおかげで、彼女は本来自分の専門外であったハードコアな技術を、自分の研究に完全に移植することに成功しました。今や、彼女はFableに指示して、PyTorchを全面的に活用したエンドツーエンドのディープラーニングシミュレーションシステムを構築させることもできます——これは、かつて彼女のような非コンピュータ科学の研究者にとっては、まさに天文学的な話でした。
第二に、自分にとって非常に独特な問題を解決するために、ソフトウェアを組み合わせる能力です。私たちの内部では、可能な限り多くの内部システムをMCP化し、適切な権限構造とデプロイ設定を整えることに大量の作業を費やしています。外部にも優れたPaaSプラットフォームがあり、Claudeに直接尋ねれば、それをセットアップしてくれます。しかし、私が特に好きなのは、「ずっと欲しかったものを自分で作る」という感覚です。
もう一つ、最近私を完全に衝撃させたことがあります。私たちの商業化チームの同僚の一人で、技術的背景を持たない女性が、Claudeを彼女の日常業務プロセスの毛細血管のすべてに深く統合しています。最も恐ろしいのは、V1バージョンを完成させた後で満足せず——彼女はそのツールを手に、バックグラウンドで大規模言語モデルと共に、数か月にわたって高強度の反復を続けているのです。
これは、この世代の推論モデルが最も過小評価され、最も魅力的な点を明らかにしています：前世代のモデルの「最低限の生存ライン」では、プロジェクトには「複雑度の天井」が存在していました。ビジネスコードやロジックが一定規模以上に膨らむと、大規模言語モデルは「頭だけを見て尻を無視する」ようになり、新しい機能を追加しようとすると、爆発的にエラーを出し、既存のアーキテクチャを壊してしまうのです。
しかし今や、コードを書かないこの女性同僚が、Fableクラスのモデルの支援を受け、彼女のシステムをバックグラウンドで数か月にわたって育て続けています。そのソフトウェアが、まるで生きている有機体のように、AIの灌漑によって絶え間なく成長し、成長し、猛烈に進化していく様子を、あなたは明瞭に見ることができるのです。 今や、彼女はこの非常に大規模で複雑な自作システムを、私たちの商業化部門全体に完全に展開し始めています。
プログラマーの背景を持たない一般人が、一人で、長期間のソフトウェアの複雑度の天井を、このような窒息するほどの高さまで押し上げることができること——これは、人類の科学技術史上、前例のない奇跡です。
ダイナミックワークフロー
司会 ダン・シッパー：あなたが言及したもう一つの非常に強力なものは、ダイナミックワークフローです。詳しく説明していただけますか？
マイク・クリーガー：
私たちの内部では、こうした先端ツールを頻繁にカスタマイズし、私はオフィスでツールの開発者たちに「このツールはいつ公開されるんですか？」と執拗に催促します。時には、根底にあるハードコアなインフラ制約のために、内部限定でしか実行できない場合もありますが、私たちは全力でこれらの宝をできるだけ早く市場に送り出そうとしています。私にとって、ダイナミックワークフローは、まさに世界を驚かせるものなのです。
Fableのようなモデルが特に強力である理由は2つあります。第一に、それは深く意味のある作業のために、足場を構築するのを助けてくれるからです。私がFableで行った最も狂気じみたことの一つは、非常に複雑な内部Pythonプロジェクトをそのまま投げ込み、そのコアビジネス全体をTypeScriptバージョンに完全に再構成してもらうことです——当時、私たちは非常に具体的な本番デプロイの考慮事項を持っていました。
Instagramの時代には、上層部が非常に真剣に議論したことがあります。「IGの基盤コードをHack言語で完全に書き直し、Facebookのインフラにシームレスに統合するべきか？」そのときの結論は：絶対にやらない。現実的に実行不可能だ。
しかし、先週末、私は同様に複雑なコアコードベースに直面し、バックグラウンドにダイナミックワークフローを投げ込み、その後週末を満喫しました。私が設定したワークフローは：既存のコードを深く理解し、すべてがどのように動作するかを説明する仕様書のようなドキュメントを生成し、モジュールごとに翻訳し、増分テストを行い、対抗的検証を行い、見落としをチェックするというものでした。月曜日に心を落ち着けてパソコンを開くと、奇跡が起こっていました——それはTypeScriptとBunの開発ツールチェーン上で動作する新しいシステムになっており、あるアーキテクチャのレベルでは、私のPythonオリジナル版よりも洗練されており、さらに高速でした。
もう一つ、より魅力的な長期的な理由は：ダイナミックワークフローの普及に伴い、近い将来、異なる難易度のサブタスクを、対応する複雑度のモデルの階層にシームレスに割り当てられるようになることです。
司会 ダン・シッパー：このワークフローをまだ使ったことがない人に向けて、あなたがそれをどう作成したかを教えてください。どう設計し、それが良いものであるとどう確認したのでしょうか？
マイク・クリーガー：
このチューニングプロセスは、ギーク的な反復の面白さに満ちています。私は最初に、Claude Codeを開き、「兄弟、今、非常に厄介な再構成の大仕事がある。さあ、一緒に完全自動のワークフローを設計しよう」と言いました。
すると、Claudeは計画を提示しました。私は「これは近いけど、機能の見落としをチェックするために、3〜4つの追加検証レベルが必要だ」と言いました。すると、Claudeは「これがあなたのプランです。準備はいいですか？」と返しました。ワークフローはコードで表現されるので、これは非常に価値があります。実際にどう進めるつもりかが明確に見えるのです。
完全な移植が終わった後、私はいくつかの小さな調整項目を持ち、それらをミニワークフローとして、前のワークフローの出力に基づいてさらに続きました。これは、「チャットが正しいインターフェースか？」という問題に戻ります。ワークフローは良い中間地点です。チャットでそれを編成し、コードで表現し、清潔なUI上で実行されます。各ステップで何が起こっているかが明示されます。今後、我々は長期間の視野を持つ作業とチャットをつなぐために、同様の方法を採用していくでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
深潮TechFlow
