Instagram共同創業者が語るFable 5との新しい働き方——「仕事を委任して、朝に確認する」
AnthropicのHead of Labsであり、Instagramの共同創業者でもあるMike Krieger氏が、Claude Fable 5（一般公開版Mythos）のリリース直前にポッドキャストでその使用経験を語った。
単なる「モデルの紹介」ではなく、2ヶ月以上にわたる日常的な使用から得られた知見——どこが変わったか、どこはまだ変わっていないか、どう使えばよいか——が率直に語られている。AIと仕事の関係を考えるすべてのビジネスパーソンにとって、実践的な示唆が詰まった内容だ。
1. 「プロンプトの仕方が時代遅れになった」——最初の戸惑い
1-1. CPOからLabsへの移行で感じた違和感
Krieger氏が、Fable相当のモデルに最初にアクセスしたのは、CPOからAnthropicのHead of Labsに移行して1〜2ヶ月後のことだった。
「私は完全に初心者に戻ったような感覚だった。タスクを分解する方法も、プロンプトの仕方も、今の時代のモデルに対して完全に時代遅れになっていると感じた」と語る。
特に変わったのは、「インタラクションの時間軸」だという。以前なら「この機能のアイデアがある、まずここから始めよう」というやり取りを繰り返していたが、今は「意図をより完全に表現してから委任する」という形に変化した。
1-2. 朝起きると終わっている
「夜にClaudeに複雑なタスクを設定して、おやすみと伝える。するとだいたい朝2時には完了していて、あとの4時間は次の指示を待っている」とKrieger氏は述べた。
途中でリモートサービスが落ちても、「今は代替バックエンドを作って記録しておく。サービスが復旧したら修正する」という形で自律的に対処するという。「それだけの複雑なタスクを委任して、正しい結果が返ってくると信頼できる——これが私にとって最も印象的な変化だ」。
2. SonnetとFableの使い分け——道具の選択
2-1. 「すべてにFableを使うのは間違い」
Fableは、強力だが、日常的な軽い質問に使うと「ロケットランチャーで蚊を倒すような感覚」とKrieger氏は表現した。
実際に「NBA決勝に関する質問をFableに投げかけて、返答が深く考えすぎているのを見て、自分でiOSアプリをSonnetに切り替えた」という体験も語られた。
「Fableには初めて『努力レベル』設定を積極的に使うようになった。UIの微調整なら中程度の思考量で十分で、その幅が以前のOpusより明らかに広い」と述べた。
2-2. 複数セッションの並行管理
「最近は以前より多くの並行セッションを持つようになった。一つの長いCloud Codeセッションでバックグラウンドのサブエージェントを走らせる形式と、5〜6タブで長い作業を並行させる形式を状況に応じて使い分けている」とKrieger氏は語った。
3. 週末1回で作ったメディアトラッカー——「エージェントネイティブ設計」
3-1. 何を作ったか
Krieger氏が、Fableを使って個人プロジェクトとして構築したのは、「メディアトラッカー」アプリだ。ゲーム・映画・テレビ番組などの推薦を自然言語で追加でき、Claudeが自律的に検索・整理・続編情報の更新を行う。
最大の特徴は、「アプリが自分自身を修正できる」という設計だ。UIから長押しすると修正リクエストをClaude Manage Agentsに送り、差分プレビューを確認して適用できる。この「セルフモディファイング」機能もワンショットで実装されたという。
3-2. Instagram時代との比較
「Instagram v1は、私が5日間のオールナイトと共同創業者ケビンのフィルター作業を合わせてようやく完成させたものだった。それと同等の規模のものが今は週末1回で作れる」とKrieger氏は述べた。
当時は、ハッシュタグ1つ追加するにも1週間かかっていた。「今は意図と実行の間のギャップが劇的に縮まった。それが技術者ではない人にとって特に大きな変化だ」。
3-3. 「エージェントネイティブ設計」の本質
Krieger氏が今最も関心を持っている問いが、「エージェントネイティブアーキテクチャとは何か」だ。「ソフトウェアのあらゆる機能をエージェントからアクセス可能にし、ツールコールで呼び出せるようにすることが第一フェーズ。そして、エージェント自身がそのソフトウェアを修正できるようにするのが次のフェーズだ」と述べた。
4. 「ソフトウェアエンジニアリングは終わったか？」
4-1. Krieger氏の答え
「ソフトウェアエンジニアリングは"変化した"。私がInstagram時代に定義していた——難しい問題を考え抜き、テキストエディタで長時間コードを書き、デプロイ後のバグを修正する——という形は確かに劇的に変わった」とKrieger氏は述べた。
その一方で「ソフトウェア生産・開発という概念は生きている。かつてのPM/エンジニアという境界はより曖昧になり、"ソフトウェアを何のために作るか"という問いはより人間的な営みになった」と続けた。
4-2. 失われたものと得られたもの
「コードを夢で見るほど深く考え抜いて翌朝に解決策を閃く——そういう体験は確かに過去のものになりつつある」とKrieger氏は認めた。「優れたエンジニアたちと話すと、喪失感と"今は信じられない量の仕事ができる"という興奮を同時に抱えている。両方を頭の中に持ち続けることが大切だと思う」。
4-3. Anthropic社内での変化
Anthropicのエンジニアチームでは、DRI（Directly Responsible Individual）制は維持されつつも、「複数のClaudeセッションがどこで何をしているか」を管理するダッシュボードを各自が自作している。プルリクエストのレビューは、Claudeが行い、インシデント対応でもClaudeが初動修正とスラックへの進捗報告を行うようになっている。
5. 検証ループ——「委任した後に何をすべきか」
5-1. スクリーンショットと動画による確認
「すべてのプルリクエストにスクリーンショットかビデオを添付することが習慣になった」とKrieger氏は語る。数時間の作業が終わった後、エラー状態を含む全画面のギャラリーを確認することで「見たことがない状態でも、問題に気づける」という。
特に動画を使った検証が有望だという。「Claudeに実装したものの動画キャプチャとFFmpegを渡すと、アニメーションのカクつきを自律的に発見して修正する。静止画のスクリーンショットでは捉えられない部分だ」。
5-2. モック環境と回帰テスト
「自分のdevサーバーで複雑なバックエンドを立ち上げるのが難しい状況でも、Claudeがワンショットで代替プロキシを作り、コードの変化に合わせて自律的に同期を保ってくれる」という体験も語られた。
理想のワークフローとして「既知の正常パスの回帰テスト」と「現在の変更箇所の深い確認」の組み合わせを挙げた。
5-3. 「コードは自分が書いていないが、責任は自分にある」
「Claudeが書いたコードでも、それをプロダクションに出す以上、自分が責任を持つ必要がある。だからこそ、"Claudeに全てのトレードオフを説明させる"という追加の会話をするエンジニアが増えている」とKrieger氏は述べた。
6. 動的ワークフロー——「次の大きな変化」
「最も印象的な使い方は、PythonコードベースをTypeScriptに移植する作業を週末にダイナミックワークフローとして走らせたことだ」とKrieger氏は語る。
ワークフローは、「コードを深く理解 → 仕様書を作成 → モジュールごとに変換 → インクリメンタルテスト → 欠落確認」という一連の手順を自律的に実行した。「月曜の朝に確認したら、ほぼ完成していた。以前のモデルでは成功しなかっただろう」。
ワークフローを作る方法は「Claude Codeに複雑なタスクを伝えて計画を立てさせ、追加したい検証ステップを指示し、コードとして表現させてから実行する」というシンプルなプロセスだ。
