BlockがClaude Fable 5で数千PRのコード移行を回す方法

Blockは、数百から数千本のプルリクエスト(PR)にまたがるコード移行を、Claude Fable 5に全体を取り仕切らせて進めています。Fableは設計と計画を担当し、ファイル編集やテスト実行は、より安価なOpusやSonnetに渡す構成です。

語ったのは、BlockでAI capabilitiesを率いるBradley Axen氏です。Anthropicが2026年10月8日に公開したインタビューで、数字はすべて本人の発言です。第三者の検証は付いていません。

要点

1つの移行が何千PRにもなる現場で何が変わったか

Axen氏によれば、Blockでは大規模なコード移行がAIの担当領域になりました。移行1件の規模は、複数リポジトリ、数百万行、数百から数千のPRです。

以前は人間が調整役で、モデルが引き受けられたのは1本か数本のPRでした。Fable 5が出てからは、Fableが多数のセッションにまたがって作業を指揮しています。氏は2025年について、同じ構想はあっても実際にはほとんどうまくいかなかったと振り返っています。Fable 5より前は、フロンティアモデルが活きるには、問題の形がかなり整っている必要があったとも話しています。

エンジニアの仕事は、移行そのものの設計、エージェントの挙動のレビュー、顧客向け機能の開発へ移りました。ひとつの移行でFableが取りまとめて統合するPRは、千本に達することがあるといいます。

Fableが計画し、小型モデルが実作業をする分担

役割分担は次の形です。

費用の見立ても語られています。初期の結果では、オーケストレーターは複雑な事前計画にフロンティアトークンを使い、その後はトークンの大半を小型ワーカーが消費する形になり、品質は下がっていないとのことです。

この運用は、Blockがオープンソースで公開する協働ワークスペースBuzzの上で動いています。Buzzは人間とAIエージェントが共有チャンネルとスレッドで一緒に働く場で、チームの進み具合を一望できる点が利点だと説明されています。Axen氏は、1つの会話に閉じたツールのインターフェースは、常時45のエージェントと動く働き方に追いつかないとも述べています。

インタビューは、ワーカー側の編集や実行をどのツールが担うかには触れていません。Claude Codeで同じことをしているとは書かれていないため、次節は「同じ分担を手元で組むなら」という別の話です。

「常に最上位モデル」が答えでなくなった

Axen氏の発言で目を引くのは、LLMをコードに使い始めてから初めて、答えが「最上位モデルを100%使う」ではなくなったという一節です。

Fableが際立つのは大きな問題を扱うときで、コード変更の細部は小さなモデルに埋めてもらう。そのため、Blockの議論の中心はモデルの効率に移りました。

同じ考えは、全社のモデル選びにも及びます。技術職の全員に最上位モデルへの完全なアクセスを与える一方で、READMEの誤字直しにFableを使うのは明らかに無駄だと氏は言います。そこで、どのモデルをいつ使うかを提案する自動セレクターを作っているところです。

effortの扱いも特徴的です。氏は、xhighのモデルとmediumの同じモデルは別物に感じるといい、effortを一本の軸として動かすものとは見ていません。低effortのFableが、高effortの別モデルより良いこともあり得るからです。そのため、ユースケースごとに全モデル×全effortの組み合わせでベンチマークを取っています。

Claude Codeで同じ分担を組む

ここからは、Claude Codeのサブエージェント機能で似た分担を作る場合の話です。Blockの構成の再現ではなく、仕様上できることの整理になります。

モデルはサブエージェントごとに指定できる

サブエージェントの定義ファイルにはmodel欄があり、sonnet・opus・haiku・fableのエイリアスか、完全なモデルID、inheritを指定できます。メインの会話をFableで動かし、実作業のワーカーだけを軽いモデルにする、という分担はこの欄で表現できます。

次は、そのための定義ファイルの一例です。公式の書式に沿った形で、Blockの設定そのものではありません。

---
name: migration-worker
description: 移行計画の1タスクを受け取り、指定されたファイルの編集とテスト実行だけを行う
tools: Read, Edit, Bash, Grep, Glob
model: sonnet
effort: medium
---
 
渡されたタスクに書かれたファイルだけを編集する。
設計判断が必要になったら、編集せずに理由を添えて報告する。
編集後は指定のテストコマンドを実行し、結果をそのまま返す。

effort欄で、サブエージェントごとに思考の深さも変えられます。選べる水準はlow・medium・high・xhigh・maxで、使える水準はモデルに依存します。Fable 5.1とFable 5にも、この5水準が載っています。

実際にどのモデルで動いたかは/tasksで見る

モデルの決まり方には順序があります。

1. 呼び出しごとに渡すmodelパラメータ
2. サブエージェント定義のmodel欄(inheritならメインの会話のモデル)
3. 環境変数CLAUDE_CODE_SUBAGENT_MODEL
4. メインの会話のモデル

v2.1.251より前は、環境変数が最優先で、定義のmodelを上書きしていました。

全サブエージェントを1つのモデルに固定したいなら、CLAUDE_CODE_SUBAGENT_MODELに加えてCLAUDE_CODE_SUBAGENT_MODEL_FORCEを1にします(v2.1.257以降)。このとき定義のmodel欄は無視されます。

実行中のサブエージェントがどのモデルで動いているかは、/tasksの行に表示されます(v2.1.242以降)。意図したワーカーモデルに乗っているかは、ここで確かめられます。

組み込みのExploreは、Fableのときに別のモデルへ寄る場合がある

メインの会話をFableにすると、組み込みのExploreサブエージェントのモデルは接続方法で変わります。Claudeのサブスクリプション、Anthropic Console、ANTHROPIC_BASE_URL経由のLLMゲートウェイでは、opusエイリアスが指すOpusで動きます。Amazon BedrockやClaude Platform on AWSなどでは、メインの会話のモデルのままです。

軽いモデルで探索させたいなら、model: haikuを書いたExploreという名前のサブエージェントを自分で定義すると、組み込みを置き換えられます。

同時数と入れ子には上限がある

Blockの「最大で数十のワーカー」を意識すると、上限も知っておく必要があります。サブエージェントの同時実行は、既定で20です。この上限を超えて起動しようとするとConcurrent subagent limit reachedで失敗し、Claudeには再試行しないよう伝えられます。CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTSで変更できます(v2.1.217以降)。

入れ子は、メインの会話から数えて3層まで可能です。CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHで変えられ、1なら入れ子を止められます。

# 例: メインの会話をFableにして起動する
claude --model fable

計画専用モデルの切り替えとの違い

opusplanというエイリアスは、プランモードでOpus、実行でSonnetに自動で切り替えます。大枠は「計画は強いモデル、実行は軽いモデル」で似ていますが、切り替わる対象はOpusとSonnetです。Fableの計画からワーカーに振る構成は、ここで述べたサブエージェントのmodel欄で組むことになります。

Blockが人間に残した線と、モデルの外に置いたチェック

大量にPRを生むほど、どこまでを自動にするかが問題になります。Axen氏が挙げた安全策は3層です。

一方で、モデルにPRを開かせる、コードをレビューさせる、ログや分析用データベースに問い合わせさせる、といった日常の作業は意図的に許しています。ここで効くのがモデル自身の安全機構とAnthropicの安全分類器で、Blockのテストでは、二重承認を回避するよう頼まれてもClaudeは迂回を拒んだそうです。この点も社内でベンチマークしていると述べられています。

同じ型の統制を別の企業がどう設計したかは、BalyasnyがClaude Fable 5を評価し統制する方法に書いています。評価と権限制御の両方をモデルの外に置く点が共通しています。

小型ワーカーを足すと本当に安くなるのか

Blockの数字は「品質は落ちていない」という初期の感触で、費用の内訳は示されていません。オーケストレーターが得をする条件は、実測が別にあります。Managed Agentsのオーケストレーターでコストが下がる2条件では、同じモデルをチームにしただけの構成が単独の4.0倍の費用になった一方で、コストが動く状況は2つに限られていました。

移行のように、独立した部品(ファイルやPR)に割れる仕事は、そこでいう「割れる仕事」に当てはまります。ただし、自社の仕事でも当てはまるかは、effortを振って測る必要があります。Blockが全モデル×全effortで基準を取っているのも、同じ理由です。

移行を進める手順そのものは、Claude Codeのコードモダナイゼーションに整理しています。依存関係の洗い出しや、テストの合格基準を先に置く順序は、オーケストレーションの前提になります。

個人の工夫を組織の仕組みに移す

終わりに、Axen氏は個人の工夫を組織の仕組みに移す話をしています。自分のマシンには、本職ではないSquareのWebフロントエンドで作業するためのスキルがいくつもあるそうです。組織としての成熟は、そうした文脈が個人でなく、システムの側に記憶されたときに来るとの見方です。

学んだことを文書にして、全員が使える形にすれば、エージェントを動かすたびに最良の文脈が使える。Blockはそこを目標にしています。

まとめ

Blockの例は、強いモデルを全工程に使うのではなく、計画だけに集中させる運用が、少なくとも同社では成立していることを示します。分担の仕組みはClaude Codeのサブエージェントでも組めますが、ワーカーのモデル・effort・同時数は定義側で決める部分で、自社の移行で測って決めることになります。マージとデプロイを人間に残す線は、規模が大きくなるほど外せない設計です。