［開発者向け］Blockは数千件のプルリクエストをどう動かしているか——Claude Fableによるオーケストレーションと安全対策

2026-10-102026-10-12

はじめに

　Anthropicは2026年10月8日、SquareやCash Appを展開する米Blockで、AI機能の開発を率いるBradley Axen氏へのインタビューを公開しました。Claude Fable 5による全社規模のコード移行の進め方や、安全対策の考え方が語られています。本稿では、その要点を整理します。

参考記事

タイトル: How Block orchestrates Claude Fable across thousands of pull requests
著者: Anthropic（Bradley Axen氏へのインタビュー）
発行元: Anthropic（Claude Perspectives）
発行日: 2026年10月8日
URL: https://claude.com/ja/resources/articles/how-block-orchestrates-claude-fable-across-thousands-of-pull-requests

要点

Blockでは、Claude Fable 5が設計を担い、数十のOpusやSonnetに個別の作業を割り振る形で、数百〜数千件のプルリクエストにわたるコード移行を進めている
1回の移行で、Fableが指揮した1,000件規模のプルリクエストをマージすることもあるという
同社は、モデルとエフォート（推論の労力）の組み合わせを1つの「格子」として捉え、用途ごとにすべての組み合わせを評価している
本番へのマージやデプロイは必ず人が行い、2人の承認を必要とするなど、AIが単独で重要な変更を本番に出せない仕組みにしている
個人が得た知見を組織の仕組みに蓄え、誰がエージェントを動かしても最善の文脈が使える状態を目指している

詳細解説

BlockとBradley Axen氏

　Blockは、事業者向けのSquareや個人向けのCash Appなど、事業者や個人が経済活動に参加するためのツールを提供している企業です。Axen氏は同社のAI機能を率いており、そのチームは、人とAIエージェントが同じ場で働くためのオープンソースのワークスペース「Buzz」などのAI製品を開発し、SquareやCash Appのチームと顧客向けのAI機能も作っています。

　インタビューでは、Claude Opus 5やClaude Fable 5といった最先端モデルがエンジニアの仕事をどう変えたか、Fableを使ったエージェントのオーケストレーション（複数のエージェントを指揮・調整すること）、全社員が最先端モデルを使える環境での安全対策の役割が語られています。

AIが変えたのは「作り方」

　Axen氏は、AIがBlockの仕事に与えた最大の影響は「ものの作り方」であり、その大きさはいくら強調してもしすぎることはないと述べています。2025年のClaude Codeのようなツールではまだ多くの手作業での介入が必要でしたが、モデルが賢くなるにつれ、設計とエンジニアリングの仕事は、移行そのものの設計、エージェントの振る舞いのレビュー、顧客向け機能の開発へと移っていったといいます。

　同氏は次の段階として、こうした技術をBlockの製品を通じて顧客に届けることを挙げています。小規模事業者が時間をかけたくない裏方の業務を担ったり、Cash Appの利用者の家計管理を助けたりする価値は大きく、AIが顧客のニーズに応じてその場で新しいインターフェースを作るような未来を想定しています。今後は、特定の問題を解くためにAIで製品がその都度作られるようになると考えているといいます。

全社規模のコード移行をFableが指揮

　同氏によれば、Claudeの新しい最先端モデルで最も変わったのは、ソフトウェアを作れる規模です。コードを書くことは今も中心的な作業ですが、全社規模の移行をAIで行えるようになりました。2025年にはこの夢はほとんど実現せず、Fable 5の登場前は、問題の形がよほど整っていなければ最先端モデルの力は発揮されなかったといいます。

　Blockにとって移行とは、複数のリポジトリにまたがる数百から数千件のプルリクエスト、数百万行のコードを意味することがあります。以前は人がその作業を調整し、モデルは1件か数件のプルリクエストを担うだけでした。Fableでは、多数のセッションにまたがる作業をFable自身が指揮しています。役割分担は次のとおりです。

人間のエンジニア: 全体の舵取りをする
Fable: データモデル、API仕様、アルゴリズムといった高い次元の設計を担う
OpusやSonnetなどの小さく費用対効果の高いモデル（最大数十）: 実際のファイル編集やテストの実行など、個別の作業を担う

　Axen氏は、この構成は経済的にも成り立っていると述べています。初期の結果では、オーケストレーターである最先端モデルのトークンを、複雑な事前の計画に使ったうえで、トークンの多くを小さな作業用のモデルに回しても、品質は落ちていないといいます。全体はBuzz上で動かしており、人とAIエージェントが共有のチャンネルやスレッドで並んで働くため、チームの進み具合がよく見えるとしています。1回の移行で、Fableが指揮した1,000件のプルリクエストをマージすることもあり、エンジニアは機械的な作業ではなく難しい設計判断に集中できるようになったといいます。

　「賢いモデルに計画させ、安いモデルに実行させる」という分担は、これまでも理論上は語られてきましたが、本稿としては、1,000件規模の実際の移行で品質を保てたという報告は、この構成が実務で成り立つことを示す具体例として意味があると受け止めています。Faireが1人のエンジニアで18か月分の移行を完遂した事例とあわせて見ると、大規模なコード移行がAIエージェントの代表的な活用先になりつつあることがうかがえます。

「常に最先端モデル」ではなくなった

　Axen氏は、多くのモデルがその後差を縮め、Opusも非常に優れているとしつつ、Fableが出た瞬間、一度に扱える問題の大きさが大きく変わったと述べています。Blockのチームはそれに引き寄せられ、さらに一段高い抽象度、一段大きな規模で働くとはどういうことかを模索し始めたといいます。

　現在は、モデルの効率が議論の中心になっています。Fableの最先端の知能は大きな問題に取り組むときに最も価値があり、コード変更の細部の多くは小さなモデルに任せるという考え方です。同氏は、LLMをコードに使い始めて以来、「常に最先端のモデルを100%使えばよい」が答えにならなかったのは、文字どおり初めてだと語っています。

　こうしたモデルのオーケストレーションには新しい道具が必要だとも指摘しています。1つの会話を前提にしたツールでは、45のエージェントと常に一緒に働く状況に画面が追いつかないため、Buzzにはマルチエージェントのワークフローが用意されています。同氏は、今後は複数の人が多数のエージェントと対話し、組織が定型作業には効率的なモデルを、大きな問題には最先端モデルを選ぶ形になると見ています。

Fableに任せた最も難しい問題

　Axen氏は、Fableに任せた最も難しい問題として2つを挙げています。

大規模な移行: Fableが作業を行う仕組み全体を指揮した、数千件規模のプルリクエストにわたる移行
技術的負債の継続的な解消: 約100万行規模のコードベースで、技術的負債が日々増えないようにすること

　2つ目について、同氏は、これまでになく多くのプルリクエストを出荷しており、機能追加や変更が増えた分、システムに技術的負債がたまる速さもかつてなく上がっていると説明します。それに見合うだけ保守の力を高める仕組みが欠けていましたが、それがようやく実現しつつあるといいます。エージェントが毎日または毎週コードベース全体を見回り、「ここはどうなっているか、何を整理・統合すべきか」を確認しているそうです。

　AIで開発の速度が上がると、それに比例して保守の負担も増えるという指摘は重要だと思います。本稿としては、「作るためのAI」と「片付けるためのAI」を対にして運用するという考え方は、AIを開発に取り入れる組織が見落としやすい視点だと考えています。

全員に最先端モデルを、ただし効率よく

　Blockでは、技術職のすべての人に最先端モデルへの完全なアクセスを与えています。常に可能性の最前線で働くことが、同社の戦略の大きな部分を占めているためです。

　一方で、READMEの誤字を直すためにFableを使うのは資源の無駄遣いだと同氏は述べます。そこで、作業に応じてどのモデルを使うべきかを社員に提案する「自動選択ツール」を開発しており、大小の最先端モデルを組み合わせたマルチエージェントの仕組みもその助けになっているといいます。会社としての目標は「最初から効率的に動く」ことで、全員が作業に合ったモデルを選べるようになれば、速度を落とさずに費用対効果を大きく高められるとしています。

エフォートは「目盛り」ではなく「格子」

　エフォートの扱いについて、Axen氏は興味深い見方を示しています。毎日LLMを扱っている同氏でも、xhighエフォートのモデルは、同じモデルのmediumとは別のモデルのように感じられるといいます。エフォートは順に上がっていく1本の目盛りではなく、Fableのlowが他のモデルのxhighより優れていることもありうるため、モデルとエフォートの組み合わせ全体を「格子」として最適化する必要があると考えています。Blockでは、ベンチマークを取るすべての用途で、すべてのモデルのすべてのエフォートを確認しているそうです。

　そのうえで、全社のAI活用を担う立場としては、「この種の作業には、このモデルのhighを既定にする」といった明確な推奨を求めているといいます。ツールができるだけ自動でそれを行い、専門家は望めば自分で探れるようにするのが理想だとしています。

　本稿としては、エフォートを「同じモデルの強弱」ではなく「別の選択肢」として扱う発想は、コストと品質の両面からモデルを選ぶ際に参考になると受け止めています。ただし、すべての組み合わせを評価するには相応の手間と費用がかかるため、まずは主要な用途に絞って比較するところから始めるのが現実的だと思います。

安全対策：保証が必要なことは人が握る

　安全対策について、Axen氏は、保証が必要なほど重要なこともあり、LLMをコードベースで自由に動かす準備はまだできていないと述べています。Blockでの主な仕組みは次のとおりです。

本番に関わる操作は人が行う: mainブランチへのマージや本番環境へのデプロイ、フィーチャーフラグなど関連する変更は、常に人が担う。エージェントはコードを変更できるが、その変更はセキュリティチェックを通過したうえで、デプロイには2人の承認が必要となる。この二重承認により、LLMが単独でこうした変更を出すことはできない
初期設定で安全な仕組み: 社員が注意していないとノートPCでできてしまうことは意外に多いため、守りやすいリモートの作業環境を重視している（LLMがディスクを埋めてしまうといった問題の対策にもなる）。ネットワークは拒否リストではなく許可リストで管理するなど、最悪の問題を防ぐ設計にしている
モデルを介さないチェック: 安全上の防護策の多くは、モデルを使わずに動く安価で効率的なチェックで、社員が使う作業画面に組み込んでいる。正規表現で済む場合もあり、小さな分類器の活用も増えている

　一方で、日々の生産性のために、ブロックするほどではない作業はあえて許可しています。モデルがプルリクエストを作成し、コードをレビューし、ログや分析用のデータベースに問い合わせることは、意図的に認めているといいます。

　そこで重要になるのが、モデル自体に組み込まれた安全対策です。Fableなどの最先端モデルが危険な行為に加担しないよう調整されていることと、Anthropic自身の安全分類器がそれに当たります。Blockのテストでは、誰かがClaudeに二重承認の仕組みを「うまくすり抜けて」と頼んでも、回避を試みることを拒否したといい、同社はこれもベンチマークとして測っているそうです。

　本稿としては、「絶対に破られてはならないことは仕組みで止める」「生産性のための操作は許可し、モデルの安全性に頼る」という2層の切り分けが、この事例で最も実務的に参考になる部分だと考えています。モデルの判断に任せる範囲と、人や仕組みが保証する範囲をあらかじめ線引きしておくことが、エージェントを広く使う前提になると思います。

知見を個人から組織へ

　他のエンジニアリングチームへの助言として、Axen氏は、組織としての成熟は、文脈や組織の知識が個人ではなく仕組みのレベルで記憶されるようになったときに訪れると述べています。Blockでは数千人がAIを使いながら、何がうまくいくかを個人として学び、周囲の仕組みを改善しています。同氏自身も、本来はフロントエンドの開発者ではないものの、ノートPCに置いた複数のスキル（Claude向けの手順書）のおかげで、SquareのWebフロントエンドの開発に参加できているといいます。

　同社の目標は、実際に作業をする人々から学んだことをすべて文書化し、誰もが恩恵を受けられる仕組みに組み込むことです。エージェントを動かすたびに、最善の文脈が使える状態にしたいとしています。

　個人のノートPCにあるスキルや工夫を、組織全体の資産に引き上げるという課題は、AIの活用が広がるほど多くの企業が直面するものだと考えられます。本稿としては、ツールの導入より、こうした知識の共有の仕組みづくりが、組織としてのAI活用の差を生むのではないかと受け止めています。