自律型エンジニア組織の構築 - エンジ・ジョーンズ氏、アジェンティック AI 財団

Block の 3,500 人が AI エージェント組織へ変容した実態：生産性向上とレイオフの皮肉な結末

ブロック（旧 Square）は、3,500 人のエンジニアを「自律型 AI エンジニア組織」へと劇的に変革しました。AI エージェントを単なるツールではなく、主要な生産手段として位置づけたこの試みは、コード生成量の爆発的増加と時間短縮という驚異的な成果をもたらしましたが、その直後に訪れた大規模レイオフは、「技術的進歩の目的」について業界全体に深い問いを投げかけています。

AI エージェント成熟度モデル：0 から 5 の段階で組織を定義する

Block では、エンジニアと AI の関わり方を「成熟度モデル（Maturity Model）」によって 0 から 5 のステージまで定義しました。これは単なるツールの導入状況ではなく、「どのように考え、委任し、調整するか」という行動様式に焦点を当てた評価基準です。

• ステージ 0: AI ツールを全く使用しない状態。
• ステージ 1: 自動補完（コードの予測）は使うが、エージェントモードでの利用はない。
• ステージ 2: エージェントとチャットするが、PR（プルリクエスト）作成には使わない。
• ステージ 3: タスクをエージェントに委任し、その出力を確認・修正する。
• ステージ 4: 複数のエージェントを並行して実行し、オーケストレーションを行う。
• ステージ 5: エンジニアが完全なタスクを委譲。人間の手を介さずとも、出荷可能な結果を生み出す状態。

「エンジニアはエージェントをワークフローの中核メンバーとして扱う必要があることを意味します。単に AI を使ってコードを書くのを手伝わせるだけでなく、実際にエージェントと連携して作業することです。」

導入当初、多くのエンジニアはステージ 1 と 2 の間にとどまっていました。「AI は使っているが、新機能のリリーススピードは上がっていない」という CEO の指摘は、このギャップを如実に示していました。真にインパクトを出すには、IDE 内での利用を超え、「構築とリリースの仕組み」に AI を統合する必要があると考えたのです。

1% パワーユーザー戦略：全員への強制ではなく「AI チャンピオン」を選抜

3,500 人の全社員をいきなりステージ 5 に引き上げることは不可能でした。そこで Block が採ったのは、90/9/1 の法則（デジタルコミュニティにおける活動比率）に基づく「1% パワーユーザー戦略」です。

全社から約 50 名のエンジニアを選抜し、「AI チャンピオン」として任命しました。選定基準は明確でした。

• 重要リポジトリを担うテックリードやマネージャー。
• AI の実装に週 30% 以上の時間を割ける余裕がある人。
• AI の非決定論的な性質（結果が毎回異なること）に挫けず、すぐに諦めない忍耐力を持つ人。

「箱から出してすぐには使えないことが多いため、そのようにしてしまわないか？... 私のような戦略が、すべての個人が自らレベルアップすることに依存しているなら、私はそのような広範な影響を見ることは決してないでしょう。」

彼らは Square、Cash App、Afterpay、Tidal といった主要プロダクトや、フロントエンド、モバイル、インフラなどあらゆる部門から選ばれました。トップダウンで「こうしろ」と命令するのではなく、「リポジトリを AI 対応にする」ための標準コンポーネント（agents.md や claude.md などの文脈ファイル、ガードレールとなるルールファイル）を各自が模索させました。

結果として、Web とモバイルでは異なるアプローチが必要になるなど、万能な解決策は存在しないことが判明。しかし、各チャンピオンが自社のリポジトリに適したパターンを見つけ出し、類似の規模を持つチーム同士で自然に収束していくという、スケーラブルな成功モデルが生まれました。

ネイティブな委譲フロー：Slack と Jira での「エージェント・タスク」化

AI チャンピオンたちがリポジトリを AI フレンドリーにする準備を整えた後、次なる課題は「ネイティブな委譲フロー」の確立でした。エンジニアが業務要件を受け取る主な場所は、Jira や Linear といった課題追跡ツール、GitHub のイシュー、そして非公式な Slack です。

Block はこれらの既存プラットフォーム上で、エージェントに直接タスクを割り当てる仕組みを実装しました。特に Slack 上での活用は劇的な変化をもたらしています。

「Slack で『このバグを見ました』と投稿すると、@goose とタグ付けして確認を依頼。Goose がリポジトリを検索し、3 つの解決策を提示。エンジニアが『オプション 1 を実装して』と指示。Goose が実行し、PR リンクを返す。」

この一連の「議論→診断→課題作成→合意形成→修正」のサイクルが、わずか 5 分程度で Slack 上で完結しました。エンジニアは新しいスキルを学ぶ必要もありませんでした。既存の作業スタイルにエージェントが自然に溶け込み、スプリントの一部として機能するようになったのです。

この結果、AI が生成したコード量は69% 増加し、報告された時間節約は37%、自動 PR 数は21 倍に達しました。しかし、同時に新たなボトルネックも浮き彫りになりました。

マルチエージェントとオーケストレーション：並列実行の壁を越える「Builder Bot」

ステージ 4 への移行で直面したのは、生成された PR の増加によるコードレビューの混雑と、複数のエージェントが互いに干渉する問題です。また、エンジニアのローカルマシン（ラップトップ）ではメモリ不足や CPU 詰まりが発生し、並列実行が困難になっていました。

これを解決するために Block が導入したのが「Builder Bot」と呼ばれるオーケストレーターと、専用クラウド環境です。

1. 専用クラウドワークスペース: エージェントを孤立した環境で動作させ、ローカルリソースの負荷を解消。同時に 4〜5 件のエージェントが稼働する並列処理を可能にしました。
2. 自動修正ループ: AI コードレビューヤー（Codex）が問題を検出すると、別のエージェントが自動的に修正して PR にコミット。エンジニアは「雑な PR」ではなく、すでに品質が担保されたものをレビューするだけで済むようになりました。
3. ワールドモデルの構築: エージェントが社内の全リソースを理解するために、25,000 のリポジトリとそれらの依存関係を可視化した「世界モデル」を構築。これにより、複数のコードベースにまたがる計画や、システム全体の理解に基づいた並列探索が可能になりました。

「エンジニアが完全なタスクをエージェントに委譲できる段階です。エージェントは人間の細かな指導なしで、出荷可能な結果を生み出せます。」

この仕組みにより、Block はついにステージ 5（自律化の頂点）に到達しました。もはやエンジニアに限らず、社内の誰でも Slack で「Build-A-Bot」を実行し、バグ修正や新機能の実装を依頼できるようになったのです。

自律化の先にある問い：技術的進歩と倫理的帰結

Block の AI エンジニア組織変革は、技術的には驚異的な成功を収めました。しかし、その直後に訪れた大規模なレイオフ（人員削減）は、このプロジェクトに皮肉で重い影を落としました。

「これは私のせいでしょうか？従業員がキャリアで最も素晴らしい仕事ができるように支援したことが、最終的に彼らの解雇につながったのでしょうか？」

CEO は当初、「AI を使っているのに機能リリースが遅い」と不満を持っていましたが、組織が自律化し生産性が向上した瞬間に、その成果は「人員削減の正当化」へと転換されてしまいました。技術的進歩の目的とは何か。AI による効率化がもたらす倫理的帰結をどう向き合うべきか。

Block の事例は、大規模組織における AI エージェント導入が単なるツール利用を超え、組織構造そのものを変える可能性を示す実証例であると同時に、「自律化の先にあるべき目的」について業界全体に重要な問いを投げかけています。私たちは確かに目指すべき場所へと辿り着きましたが、その先に何があるのか、今こそ深く考える時なのです。