作成日: 2026-07-12 JST
目的: Jack Dorsey / Block / Goose / Builderbot / 「AIで会社構造を変える」とは何かを、あとで読み返せるように整理する。
0. 最初の結論
Blockの話は、単に「AIにコードを書かせる」ではない。
かなり圧縮すると、こういう話。
個人がCodexなどでやっている「フォルダを見せる、手順書を読ませる、ファイルを直させる、結果を人間が確認する」というAI作業代行を、Blockという大企業のSlack、Linear/Jira、Git、CI、社内ルール、レビュー、権限管理に接続し、開発作業の一部を会社規模の標準レール上で処理できるようにした。
ただし、それだけでもまだ半分。Block公式記事で示されている上位構想は、さらに組織構造の話に踏み込んでいる。
従来は管理職・階層がやっていた「会社の状態把握」「情報の中継」「進捗確認」「文脈共有」「調整」を、AIが読む会社全体の情報モデルに寄せて、会社を階層ではなく“intelligence”として動かす。
これはBlock公式記事の「From Hierarchy to Intelligence」が主張している内容。Blockは「多くの会社はAIをcopilotとして配って既存構造を少し良くしているだけだが、Blockは会社をintelligence、あるいはmini-AGIとして作る」と説明している。
出典: Block公式 “From Hierarchy to Intelligence”
https://block.xyz/inside/from-hierarchy-to-intelligence
1. Block / Square / Cash App の前提
Blockは、もともとSquare, Inc.だった会社。2021年12月に、会社名をBlock, Inc.へ変更することを発表した。Squareという名前は消えたのではなく、店向け事業ブランドとして残っている。
出典: Square公式プレスリリース “Square, Inc. Changes Name to Block”
https://squareup.com/us/en/press/square-changes-name-to-block
今のBlockは、Square、Cash App、Afterpay、TIDAL、Bitkey、Protoを持つ会社として説明されている。Squareは売り手向け、Cash Appは個人向け送金・金融アプリ、Afterpayは後払い・分割払い系、BitkeyはBitcoin用セルフカストディウォレット、ProtoはBitcoin mining系。
出典: Block公式トップ / Investor Relations
https://block.xyz/ https://investors.block.xyz/overview/default.aspx
今回の話で出てきたSquareは、ゲーム会社のスクウェア・エニックスではない。Blockの中の「店向け決済・POS・売上管理」系の事業。
2. Squareの裏側で発生する仕事
Squareは表面だけ見ると「レジ」や「決済端末」だが、実際には店の売上、決済、返金、レシート、在庫、会計、スタッフ管理、レポートなどが絡む業務システムになる。
たとえば、店がSquareで決済する場合、裏では次のような処理やシステムが関係し得る。
- 決済方法の確認
- 決済ネットワークとの通信
- 店の売上記録
- 手数料計算
- レシート生成
- 返金時の整合
- 売上レポートへの反映
- 不正・リスク管理
- サポート用履歴
- 監査・ログ
そのため、「返金画面の表示を少し直す」という見た目の小さい変更でも、裏側では複数サービス、複数API、複数リポジトリ、複数テストにまたがる可能性がある。
この具体例は説明用の整理であり、Blockが公開した実在チケットを確認したものではない。事実として確認できるのは、Block公式がBuilderbotについて「数億行のコード」「数百サービス」「Block全体の複雑さ」を扱うために作った、と説明している点。
出典: Block公式 “Block rolls out Builderbot...”
3. 「コード編集」と「PR作業」の意味
ここで出てきたPRは、広告・宣伝のPublic Relationsではない。開発用語のPull Request。
意味は、
このコード変更を共有・統合先のコードベースへ取り込んでよいか確認してください
という提出・レビュー手続き。
流れはこう。
- 共有コードを直接触らず、作業用ブランチを作る
- そこでコードを修正する
- Pull Requestを出す
- CIという自動テスト・自動チェックを走らせる
- 人間が差分をレビューする
- OKなら対象ブランチへマージする
つまりBuilderbotが「PRを作る」と言う場合は、広告文を作るという意味ではなく、コード変更案をGitHub/GitLab等の開発フローへ提出するという意味。
Block公式は、BuilderbotがLinear/Jiraからチケットを取り、ブランチを作り、コードを書き、Pull Requestを開き、CIを見て、フィードバックに基づいて反復すると説明している。
出典: Block公式 “Block rolls out Builderbot...”
4. Gooseとは何か
Gooseは、Blockが作ったAIエージェント基盤。単なるチャットではなく、LLMを実際の行動へつなぐためのフレームワークとして説明されている。
Gooseは、MCPを通じて、コンテンツリポジトリ、業務ツール、開発環境などにつながる。デスクトップアプリ、CLI、カスタムUI、モデル選択も想定されている。
出典: Block公式 “Block Open Source Introduces codename goose”
https://block.xyz/inside/block-open-source-introduces-codename-goose
Gooseができることは、検索、コード移動、コード作成、ファイル読み書き、コード実行、テスト実行、依存関係インストール、出力修正など。
出典: Block公式 “Block Open Source Introduces codename goose”
https://block.xyz/inside/block-open-source-introduces-codename-goose
重要なのは、Goose単体の能力は今となっては特別な魔法ではない点。Codex、Claude Code、Goose、Hermes、OpenClaw系は、大枠では「ファイルを読む、書く、コマンドを実行する、外部ツールにつなぐ、手順書やスキルを読む」という点で似ている。
OpenAIのCodex CLIも、ローカル端末で動き、選択したディレクトリ内のコードを読み、変更し、実行できると説明されている。
出典: OpenAI Developers “Codex CLI”
https://learn.chatgpt.com/docs/codex/cli
Claude Codeも、ターミナルからファイル編集、コマンド実行、プロジェクト管理を行うCLIとして説明されている。
出典: Anthropic “Claude Code overview”
https://code.claude.com/docs/en/overview
つまり、個人がCodexで「このフォルダを見て」「この見本を参考にして」「このPDFを直して」とやらせるのと、原理はかなり近い。
5. Builderbotとは何か
Builderbotは、Gooseを基盤に作られた、Block社内の開発作業用オーケストレーション層。
Block公式は、Builderbotを「Block全体のコードベースにまたがって複数AIエージェントを調整するorchestration layer」と説明している。Slack内で@builderbotを呼ぶと、バグ修正、複数サービスをまたぐ移行、新機能などについて、調査、計画、実装を始める。
出典: Block公式 “Block rolls out Builderbot...”
Builderbotは、単一リポジトリ用のAI coding assistantではなく、Block全体のコードベース、サービス、API、慣習を扱うことを狙っている。Block公式は、Cash App担当エンジニアが触ったことのないSquare側サービスを変更できる、という例で説明している。
出典: Block公式 “Block rolls out Builderbot...”
公開されている公式説明では、Builderbotは以下を行う。
- Slackのスレッド内で呼ばれる
- Linear/Jiraからチケットを取る
- ブランチを作る
- コードを書く
- Pull Requestを開く
- CIを見る
- フィードバックに応じて直す
- 人間が価値を出すべきところで介入する
- 顧客データ、決済情報、個人識別情報にはアクセスしない
出典: Block公式 “Block rolls out Builderbot...”
公開数字として、BlockはBuilderbotが1日20万件以上のoperationを実行し、週に約1,500件のPull Requestをマージし、Block全体の本番コード変更の約15%に当たると説明している。
出典: Block公式 “Block rolls out Builderbot...”
6. BuilderbotはOSSなのか
GitHubにblock/builderbotという公開リポジトリがある。現在のREADMEでは、このリポジトリを「Builderbot apps, shared UI packages, and Rust crates」を含むモノレポと説明しており、Apache-2.0ライセンスで公開されている。
出典: GitHub block/builderbot
https://github.com/block/builderbot
ただし、ここは区別が必要。
block/builderbotという公開リポジトリが存在することと、Block社内でSlack、Linear/Jira、Git、CI、全社コードベースに接続して動いているBuilderbot本体、またはその主要なオーケストレーションコードがそのまま公開されていることは同じではない。
公開リポジトリにはアプリ、共有UIパッケージ、Rust crateが含まれる。一方、Block社内のSlack、Linear/Jira、Git、CI、全社コードベース、社内ルール、権限管理、レビュー運用まで含む完全な社内運用環境が、そのまま公開されているとは確認できない。
結論としては、
Builderbotという名前の公開コードリポジトリはある。 ただし、それをそのまま「Block社内版BuilderbotがOSSとして完全公開されている」と解釈することはできない。
7. RAGというより、文脈取得 + Skills + world model + エージェント実行
RAGという言葉で雑に言えば、半分はそう。
RAGは、AIに答えさせる前に、必要なドキュメント、コード、過去PR、チケット、手順書などを検索して文脈として渡す仕組み。
Block公式はBuilderbotやworld modelの説明で「RAG」という単語を前面に出しているわけではない。しかし、Blockは「意思決定、議論、コード、設計、計画、問題、進捗がartifactとして記録され、company world modelの材料になる」と説明している。これはこちら側の整理では、RAG的な文脈取得・検索・参照層に近い。
出典: Block公式 “From Hierarchy to Intelligence”
https://block.xyz/inside/from-hierarchy-to-intelligence
ただし、RAGだけなら「資料を探して回答する」まで。Builderbotはそこに、ファイル編集、ブランチ作成、Pull Request作成、CI監視、レビュー反映を足している。だから正確には、
RAG + エージェント + ツール接続 + Git/CI連携 + 社内手順 + レビュー + 人間承認
と見るのが近い。
8. 「権限増やしただけ」なのか
技術の芯だけ見ると、かなり近い。
個人でCodexを使う場合も、対象フォルダを渡し、見本を渡し、手順を渡せば、AIはファイルを読んで直す。Blockも本質的には、AIが触れる情報と道具を増やしている。
ただし大企業では「権限を増やしただけ」では事故になる。Blockが公開記事で説明している制御やレビューの仕組みには、以下が含まれる。
- 顧客データ、決済情報、個人識別情報にはアクセスしない
- ソースコードとシステム設定に限定する
- Pull Requestとして提出する
- CIを通す
- レビューを受ける
- 人間が最終承認する
出典: Block公式 “Block rolls out Builderbot...”
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
だから、より正確には、
権限を増やしただけではなく、権限、文脈、手順、チェック、レビュー、停止地点を会社規模で設計した。
となる。
9. 「手順書を毎回読ませると重いから、間にもう一個入れた」なのか
これもかなり近い。
Block Engineeringは、AIエージェントは魔法のようにコードベースやチームの業務プロセスを知っているわけではない、と説明している。その上で、Agent Skillsによって、エージェントが必要な知識を使える形にパッケージできると説明している。
出典: Block Engineering “3 Principles for Designing Agent Skills”
https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills
Agent Skillsは、SKILL.mdを含むフォルダで、エージェントが必要時に発見して読み込む手順書・プレイブックのようなもの。Blockは社内に100以上のSkillsと、frontend、android、iOSなどの役割・チーム向けバンドルを作っている。
出典: Block Engineering “3 Principles for Designing Agent Skills”
https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills
つまり、巨大な会社の全手順書を毎回全部AIのコンテキストに入れるのではなく、
- まず小さい入口・目次を読む
- 今の作業に関係するSkillだけ読む
- 必要なスクリプト、テンプレート、MCP、設定だけ使う
- 作業する
- レビュー専用のチェックを走らせる
という構造にしている。
Block Engineeringは、AGENTS.mdだけではworld modelを十分に表現できず、しかもそこへ情報を増やすと、そのディレクトリに来るすべてのエージェントへ負担になると説明している。そのため、.agents/checks/*.mdやAgent Skillsによって、必要な文脈を必要時に読み込ませる設計を採っている。
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
この点は、会話で出た理解、
規模が大きくなって、全手順書を毎回コンテキストに入れると無駄が大きいから、必要な情報だけ必要時に読み込む層を作った
に近い。
ただし、その「もう一個」は単なるキャッシュではない。役割は以下を含む。
- 文脈ルーター
- 作業別マニュアル棚
- ルール・チェックの入口
- レビュー用サブエージェントの呼び出し
- 人間承認前の検査
なお、アクセス権限や危険領域の制限は重要だが、Skillsだけの役割ではなく、別の制御層も含めて考える必要がある。
10. Skillsの設計思想
Block Engineeringの記事では、Skills設計の重要点として、エージェントに判断させるべき部分と、判断させてはいけない部分を分けることを強調している。
たとえば、同じ入力なら同じ結果になってほしい採点、CLIコマンド、SQL構造、命名規則などは、LLMに自由判断させず、スクリプト、テンプレート、ハードルールに入れるべきだとしている。
出典: Block Engineering “3 Principles for Designing Agent Skills”
https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills
逆に、結果の説明、コードベースごとの文脈理解、新しい内容の生成、会話的な相談はエージェントの仕事にする。Block Engineeringはこの分離を「rules and execution」と「interpretation and action」の2ゾーンとして説明している。
出典: Block Engineering “3 Principles for Designing Agent Skills”
https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills
これはかなり重要。
つまりBlockは「AIに全部任せる」とは言っていない。むしろ、
再現性が必要なところはスクリプトやハードルールへ逃がす。 文脈理解や生成が必要なところだけAIにやらせる。
という設計。
11. レビュー側のAI化
Block Engineeringは、Builderbotを単なるassistantではなく、システムを守る“protector”として説明している。
つまりAIは、ただ「聞かれたら答える補助」ではなく、研究、計画、実装の流れの中で、会社全体のworld modelに沿うように変更を観察し、推奨し、ステアリングする役割を持つ。
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
具体的には、各リポジトリでjust fmtやjust testのような共通CLI入口を整備し、エージェントが新しいリポジトリに来ても、同じ形式でフォーマットやテストを走らせられるようにしている。
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
さらに、sq agents reviewというCLIを全ワークステーションやクラウドエージェントrunnerへ配布し、Pull Requestに対して、ローカル知識とグローバル知識を含むレビューを走らせると説明している。
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
レビューは単一プロンプトではなく、API標準、payments/配下のPCI準拠、auth/のセキュリティレビューのように、観点ごとのサブエージェントで走らせ、その結果を統合する。
出典: Block Engineering “Protecting Our Systems with Intelligence”
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
この点は、大企業でAIを使う上で重要。AIにコードを書かせるだけなら個人でもできる。Blockがやっているのは、その後のレビュー・品質維持・アーキテクチャ保護までAI用に整備すること。
12. 会社構造として何を変えようとしているのか
ここが本体。
従来の会社は、階層で動く。
社員
↓
リーダー
↓
マネージャー
↓
部長
↓
役員
↓
CEO
この階層は、単なる偉さの表現ではなく、情報を集め、整理し、上に渡し、下に戻すための仕組み。
Block公式は、従来の管理職の仕事を「チームで何が起きているかを把握し、その文脈を上下に伝えること」と説明している。
従来は、たとえば次のような仕事を人間の管理職が担当してきた。
- 現場で何が起きているか把握する
- 情報を上へ伝える
- 上からの方針を下へ伝える
- チーム間の進捗を調整する
- 誰が何をしているか把握する
- 問題や停滞を見つける
- 必要な情報を必要な人へ渡す
つまり、
現場で問題が起きる
↓
リーダーへ報告
↓
マネージャーへ報告
↓
必要なら別部署と調整
↓
判断や方針が戻ってくる
という形で、情報が人間の階層を上下する。
Blockが変えようとしているのは、この「人間を経由した情報中継」。
BlockはRemote-firstであり、意思決定、議論、コード、設計、計画、問題、進捗など、仕事の多くがartifactとして記録される。
それらをAIが継続的に読み、会社全体の状態をcompany world modelとして維持する。
理想上は、
現場で問題が起きる
↓
world modelに状態が反映される
↓
必要な人がその文脈を直接取得する
↓
その場で判断・行動する
という形へ寄せられる。
つまり、これまで管理職が担ってきた、
- 状況把握
- 情報中継
- 進捗確認
- 文脈共有
- チーム間調整
の一部を、AIが読む会社全体の情報モデルへ移そうとしている。
では、人間は何をするのか。
Block公式は、新しい組織における人間の役割を、大きく3つに整理している。
Individual Contributor（IC）
実際にコードを書き、モデルを作り、システムやインターフェースを構築・運用する専門家。
従来はマネージャーが渡していた周辺情報や状況をworld modelから得ることで、自分の担当領域について、上から細かく指示されるのを待たずに判断する。
Directly Responsible Individual（DRI）
特定の問題、機会、顧客成果について直接責任を持つ人。
たとえば「特定顧客層の解約率を下げる」といった問題を一定期間担当し、必要に応じて複数チームのリソースを使って解決する。
固定された部署の階層を上がって承認を待つのではなく、問題を中心に必要な人や能力を組み合わせる役割。
Player-coach
自分自身も実務をしながら、周囲の人材育成も担当する人。
従来型マネージャーのように、1日の大半を進捗確認、情報中継、調整会議、優先順位交渉に使うのではなく、自分も実際の仕事をしながら人を育てる。
かなり単純化すると、Blockの構想では、
world model
→ 情報共有・状況把握・文脈提供
DRI
→ 問題・戦略・優先順位への責任
Individual Contributor
→ 実務・専門的な判断・実装
Player-coach
→ 実務・専門性・人材育成
という分担になる。
そのためBlockは、従来のような恒久的な中間管理職層は不要になるという構想まで示している。
つまり、
社員の上にリーダー、その上にマネージャー、その上に部長を置き、それぞれが情報を集めて上へ渡す構造そのものを減らそうとしている。
ということ。
ただし、これは「AIが会社のすべてを決める」という話ではない。
Block自身も、人間はAIがまだ十分に扱えない現実との接点に必要だとしている。
たとえば、
- 直感
- 明確な方向性を示す判断
- 文化的文脈
- 人間同士の信頼関係
- 倫理的判断
- 前例のない状況
- 間違えた時の損失が極めて大きい判断
といった領域。
だからBlockの構想をかなり単純化すると、
従来：
人間の階層が情報を運び、調整し、判断する
Blockの構想：
AIのworld modelが情報と文脈を運び、
人間は実務、問題解決、人材育成、重要判断へ寄る
ということになる。
これが、「会社をhierarchyではなくintelligenceとして動かす」というBlockの構想の具体的な中身。
Builderbotは、この構想の中では「開発現場のAI化」を担当する部品の一つ。
上位の構想は、
人間の管理階層が持っていた情報流通機能を、AIが読む会社全体の情報モデルに寄せる。
という組織改革。
ただし、Block自身も、この移行はまだ初期段階であり、難しく、うまく機能する前に壊れる部分もあるだろうと認めている。
したがって、これは完成済みで成功が証明された組織モデルではない。
Blockが実際に進めている、大規模な組織実験として見るのが正確。
13. 「AI-fed, human-finished」の読み方
周辺投稿で使われていた “ai-fed, human-finished.” は、直訳を一意に決めにくい表現。
自然な日本語に寄せるなら、
AIが前工程や材料供給を担い、人間が仕上げた
程度が安全。
“finished”には「仕上げられた」と「終わった」の両方の意味があるので、「人間は終わった」という言葉遊びとして読む余地はある。ただし、“human-finished”は複合語としては「人間によって仕上げられた」という解釈が自然で、元投稿者がダブルミーニングを意図したとは確認できない。
Block文脈では、次のように読むのが近い。
AIが材料、調査、実装、整理、レビュー前処理を担当し、人間は最後の判断、責任、品質、方向づけを担当する。
ただし、この表現はBlock公式の中核概念ではなく、周辺投稿の言い回しとして扱うのが安全。
14. 人員削減との関係
Blockは2026年2月、大規模な人員削減を発表した。
BlockのQ4 2025株主向け書簡では、従業員数を10,000人超から6,000人弱へ減らし、4,000人超が退職または協議対象になると説明している。Dorseyは同じ書簡で、intelligence toolsによって会社を作り運営する意味が変わったこと、かなり小さいチームでもより多く、より良くできると考えていることを述べている。
出典: Block Q4 2025 Shareholder Letter
https://s29.q4cdn.com/628966176/files/doc_financials/2025/q4/Q4-2025-Shareholder-Letter_Block.pdf
Reutersも、Blockが4,000人超、ほぼ半分のworkforceを削減し、AIを業務全体に埋め込むoverhaulの一部と報じた。
出典: Reuters
APも、Blockが10,000人超の従業員から4,000人超を削減し、AI活用による再構成を理由にしていると報じた。
出典: AP News
https://apnews.com/article/block-dorsey-layoffs-ai-jobs-18e00a0b278977b0a87893f55e3db7bb
ここで重要なのは、Block自身がAIによる組織再設計と人員削減を結びつけて説明している点。一方で、公式発表は技術説明であると同時に、投資家・市場向けの経営説明でもあるため、その主張と実際の成果は分けて見る必要がある。
事実としては、Block公式の「From Hierarchy to Intelligence」は、Blockが階層ではなくintelligenceとして会社を作ろうとしていることを説明している。一方で、それが人員削減として正しかったか、成功するかは別問題。Block自身も、この移行は初期段階であり、難しく、壊れる部分があるだろうと書いている。
出典: Block公式 “From Hierarchy to Intelligence”
https://block.xyz/inside/from-hierarchy-to-intelligence
15. 個人がもうやっていることとの違い
会話で出た理解は正しい。
個人はもうやっている。 Blockは、それを会社規模でやった。
個人の場合、Codexなどに、
- このフォルダを見て
- 上の階層に見本があるから参考にして
- このPDFを探して
- このmd形式に直して
- このログを読んで
- このコマンドを修正して
と指示すれば作業できる。
Blockの場合は、それを個人のプロンプト依存にせず、会社の仕組みに入れた。
- この種類の作業ならこのSkillを読む
- このリポジトリでは
just fmtとjust testを使う - この領域はPCIレビューを走らせる
- このAPI変更は社内標準チェックを走らせる
- 顧客データや決済情報は読ませない
- Pull Requestとして提出する
- CIで確認する
- 最後は人間が承認する
つまり、個人が毎回プロンプトで渡している段取りを、会社の標準レールにした。
16. どこが特別で、どこが普通か
技術部品としては普通
Goose、Codex、Claude Code、Hermes、OpenClaw系は、大枠で同じ方向に収束している。
共通部品はだいたい以下。
- LLM
- ファイル読み書き
- コマンド実行
- ブラウザやAPIなど外部ツール接続
- RAGやSkillsによる文脈取得
- 権限管理
- 人間確認
だから「Codexと一緒じゃないの？」は、作業原理は同系統。
ただし、実装、権限管理、接続先、レビュー機構、組織運用への組み込み方は違う。
会社運用としては重い
違いは、個人PCではなく企業全体でやること。
企業では、顧客データ、決済、監査、セキュリティ、責任者、レビュー、ログ、規制が絡む。AIにただ権限を渡すだけではなく、どこまで読めるか、どこで止めるか、何をチェックするか、誰が承認するかを設計しないと使えない。
経営判断としては未検証
Blockは、AIで会社の情報流通・開発・レビューを変え、管理階層や人数まで減らそうとしている。これは大胆だが、正しいと証明されたわけではない。
Block公式も「初期段階」「難しい」「壊れる部分があるだろう」と認めている。
出典: Block公式 “From Hierarchy to Intelligence”
https://block.xyz/inside/from-hierarchy-to-intelligence
17. 誤解しやすい用語まとめ
| 用語 | 意味 |
|---|---|
| Block | 旧Square, Inc.。現在の親会社。Square、Cash App、Afterpayなどを持つ |
| Square | Block内の店向け決済・POS・売上管理ブランド |
| Cash App | Block内の個人向け送金・金融アプリ |
| Goose | Block発のOSS AIエージェント基盤 |
| Builderbot | Goose系をBlock社内のSlack、Jira/Linear、Git、CI、全社コードベースに接続した開発作業オーケストレーション層 |
| PR | ここではPull Request。広告PRではない |
| CI | 自動テスト・自動検査の仕組み |
| RAG | 必要な資料・コード・ルールを検索してAIへ渡す仕組み。Blockのworld model/SkillsはRAG的だが、Block公式がすべてをRAGと呼んでいるわけではない |
| Skill | AIが必要時に読む作業別手順書・プレイブック |
| AGENTS.md | AI coding agent向けの説明書・ルールファイル |
| world model | 会社全体の状態、構造、ルール、進捗、設計をAIが把握するための情報モデルというBlock側の概念 |
18. 最終整理
会話全体を、飛躍を落として整理するとこう。
- BlockはSquare、Cash App、Afterpay、TIDAL、Bitkey、Protoなどを持ち、金融サービスを中心に複数事業を展開するテクノロジー企業。
- SquareはBlock内の店向け決済・POS事業で、旧社名でもあった。
- BlockはGooseというAIエージェント基盤をOSSとして出した。
- Goose自体は、CodexやClaude Codeなどと同じく、ファイル操作、コード実行、外部ツール接続を行うAI作業員に近い。
- BlockはGooseを土台に、Builderbotという社内開発作業のオーケストレーション層を作った。
- BuilderbotはSlackで呼ばれ、Linear/Jira、Git、CI、全社コードベース、社内ルールに接続して、調査、計画、実装、Pull Request、CI監視、フィードバック反映を行う。
- Builderbotはソースコードとシステム設定だけを扱い、顧客データ、決済情報、個人識別情報にはアクセスしないとBlockは説明している。
- BlockはSkills、AGENTS.md、
.agents/checks/*.md、just fmt/just test、sq agents reviewなどを使い、AIが毎回全部の手順書を読むのではなく、必要な文脈だけ段階的に読み込む設計をしている。 - Blockの本体の主張は、開発現場の自動化だけではない。従来の管理職・階層がやっていた情報中継と調整を、AIのcompany world modelへ寄せ、会社をhierarchyではなくintelligenceとして動かすこと。
- 技術の芯は、個人がCodexでやっていることの延長。違いは、会社規模で権限、文脈、手順、レビュー、CI、承認を標準化したこと。
- BlockはAIによる組織再設計と大規模人員削減を結びつけて説明しているが、その経営判断が成功するかは未検証。
- “ai-fed, human-finished.” は、Block文脈では「AIが前工程や材料供給を担い、人間が最後に判断・仕上げする」と読むのが自然。言葉遊びとして別の読み方も可能だが、元投稿者の意図までは確認できない。
19. 情報源一覧
主要一次情報
Block公式: From Hierarchy to Intelligence
https://block.xyz/inside/from-hierarchy-to-intelligence
Block公式: Builderbot発表
Block公式: codename goose発表
https://block.xyz/inside/block-open-source-introduces-codename-goose
Block Engineering: 3 Principles for Designing Agent Skills
https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills
Block Engineering: Protecting Our Systems with Intelligence
https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence
GitHub: block/builderbot https://github.com/block/builderbot
Block Q4 2025 Shareholder Letter
https://s29.q4cdn.com/628966176/files/doc_financials/2025/q4/Q4-2025-Shareholder-Letter_Block.pdf
Block公式トップ
Block Investor Relations
https://investors.block.xyz/overview/default.aspx
Square公式: Square, Inc. Changes Name to Block
https://squareup.com/us/en/press/square-changes-name-to-block
OpenAI Developers: Codex CLI
https://learn.chatgpt.com/docs/codex/cli
Anthropic Docs: Claude Code overview
https://code.claude.com/docs/en/overview
補助情報・報道
Reuters: Block workforce cuts and AI overhaul
AP News: Block layoffs citing AI
https://apnews.com/article/block-dorsey-layoffs-ai-jobs-18e00a0b278977b0a87893f55e3db7bb
20. 注意点
- Block公式は、自社の構想を前向きに説明している。したがって、「Blockがそう設計し、そう説明している経営・組織・AI導入構想」として読む必要がある。
- Builderbotの週1,500PR、15%などの数字はBlock公式発表ベース。実際の品質、障害率、レビュー負荷、社員士気、長期保守性まではその数字だけでは判断できない。
block/builderbotという公開GitHubリポジトリは存在するが、Block社内版Builderbot本体や、その完全なオーケストレーション・運用環境がそのままOSSとして公開されているとは確認できない。- RAGという表現は、こちら側の整理。Block公式がすべてをRAGと呼んでいるわけではない。
- 「AIに会社を任せる」というより、「AIが情報処理・下作業・レビュー前処理を行い、人間が最後の判断をする」という方が公開情報に近い。
21. 未検証の部分
- 週1,500PRが「価値ある変更」かは不明。
- PR数は生産性指標として弱い。
- CI通過と長期保守性は別問題。
- 人間レビュー負荷が減ったのか、別の形で増えたのかは不明。
- 社員の士気、知識継承、責任境界への影響は公式数字だけでは判断不能。
- 顧客データにアクセスしないとされるが、source code / system configurationだけでも機密性は高い。
- world modelが強いほど、間違った前提を全社的に拡散するリスクもある。
- 「AIが階層を置き換える」は、情報流通には効いても、評価・責任・倫理・意思決定まで置き換えられるとは限らない。
参考リンクについて
この記事で紹介している外部リンクは、公開後にURL変更やページ削除などでリンク切れになる可能性があります。
確認時点ではリンク先を確認していますが、後からリンク切れを確認した場合は、該当リンクに取り消し線を付けて「リンク切れ」と明記する方針です。