「チームの規模を維持したまま、出力だけを増やす」という発想が崩れ始めている。AIエージェントが実装・テスト・レビューの一部を担えるなら、従来の開発チームのピラミッド構造はその前提ごと見直しを迫られる。

Gooseはそういう変化の文脈で登場したツールの一つだ。

Gooseとは何か

Gooseは、Block（Square・Cash Appを運営する企業）が公開したオープンソースのAIエージェントだ。CLIで動く。Claude Codeや Codex CLIと同じ「コーディングエージェント」カテゴリに属するが、いくつかの点で設計思想が異なる。

GitHubでApache 2.0ライセンスで公開されており、Block社内の開発者が実際に使うために作られたツールが外部に出てきた形だ。

Gooseの構造

Gooseの特徴は、特定のLLMに縛られていない点にある。

バックエンドのLLMを切り替えられる設計になっており、Claude、GPT-4系、Geminiなど複数のプロバイダに対応する。どのモデルを使うかはユーザーが設定で決める。

拡張の仕組みはMCP（Model Context Protocol）ベースだ。独自のエクステンションレイヤーを持ち、ファイル操作・コード実行・Web検索・外部サービスとの連携をプラグインとして追加できる。エージェント本体を改造せずに機能を足せる構造になっている。

# Gooseのインストール
curl -fsSL https://github.com/block/goose/releases/latest/download/install.sh | sh

# セッションを開始する
goose session

# 特定のプロバイダで起動する
goose session --provider anthropic

セッションは会話履歴を保持する。goose session --resume で前の作業を続けられる。

ピラミッド型組織とは何か

ソフトウェア開発チームの構造は、長らく以下のようなピラミッドだった。

        ┌─────────────┐
        │  Staff / Principal  │  ← 設計・技術戦略
        ├───────────────────┤
        │     Senior Engineer     │  ← 実装の中核・レビュー
        ├───────────────────────┤
        │         Mid Engineer         │  ← 実装担当
        ├───────────────────────────┤
        │            Junior Engineer          │  ← 実装補助・テスト
        └───────────────────────────┘

このピラミッドが成立していた理由は、知識と判断力が層ごとに異なっていたからだ。ジュニアには「書いたコードを見てもらう人間」が必要で、シニアには「方針を決める人間」が必要だった。各層の人数差がそのまま組織の形になった。

AIエージェントが崩す部分

Gooseのようなエージェントは、ピラミッドの特定の層を代替し始めている。

ジュニア層のタスクを吸収する

ボイラープレートの生成・ユニットテストの作成・既知パターンの実装──これらはエージェントが担える作業になった。Gooseに「このAPIのエンドポイントを追加して、テストも書いてほしい」と伝えると、ファイルの読み取り・コード生成・テスト実行・エラー修正のサイクルを自律的に回す。

これはジュニア層が不要になるという話ではなく、「ジュニア層に任せていた作業が、エージェントによってシニア一人でさばけるようになった」という変化だ。

コードレビューの一部を機械化する

Gooseのような拡張性の高いエージェントは、diff を読んでコメントを返すレビュータスクにも使える。全てのレビューを任せるのは難しいが、「明らかなバグ・スタイル違反・テスト漏れ」の検出は機械に任せる選択肢が出てきた。人間のレビュアーは設計的な判断に集中できる。

シニアがカバーできる範囲が広がる

結果として、シニアエンジニア一人が見られる作業の範囲が変わる。従来は「シニア1人:ジュニア3人」という比率でチームを組むのが一般的だったが、エージェントの支援があれば一人で複数の作業ラインを同時に回せる。ピラミッドの底が薄くなり、全体がフラットになる。

フラット化はGoose固有の話ではない

ピラミッドの解体は、Gooseだけが起こしているわけではない。Claude Code・Codex CLI・opencode、どのエージェントも同様の圧力を組織にかける。

Gooseが関係するのは、その「誰でも使えるOSSの入口」という性格だ。特定のIDEやサブスクリプションに縛られず、自前のLLMキーで動かせる。Blockの開発者が実際に使っているという背景が、「実用に耐えるかどうか」の一定の証左になっている。

エージェントの振る舞い自体をプロンプトで変える手法──「止まらず動き続ける・必ず最新情報を調べる」──については「Beast モード」でAIはどこまで変わるかで取り上げている。

他のエージェントとの位置づけ

ツール 運営 LLM 拡張性 ライセンス 用途の広さ
Goose Block 任意（設定） MCP + 独自拡張（70+） OSS（Apache 2.0） コーディング以外も対応
Claude Code Anthropic Claude MCP 商用（サブスクリプション） コーディング特化
Codex CLI OpenAI GPT-5.5系 限定的 OSS コーディング特化
opencode SST 任意（設定） MCP + サブエージェント OSS コーディング特化

Claude CodeはAnthropicのエコシステムと深く統合されており、完成度は高い。opencode（SSTチーム製）はコーディングに特化し、build（フルアクセス）とplan（読み取り専用）の2モードで安全性を担保する設計になっている。

Gooseはこれらのコーディングエージェントとはそもそもの射程が異なる。70以上のMCP拡張を通じてコーディング以外のタスク──自動化・調査・ファイル操作・外部サービス連携──にも対応できる。コーディング専用のツールが「何を書くか」に特化するのに対し、Gooseは「何をするか」の幅が広い。

調達方針で選ぶなら、Anthropic契約があればClaude Codeが体験として安定している。自社でLLMを管理したい、複数プロバイダを使い分けたい場合にGooseかopencodeが候補に上がる。コーディング専用に割り切るならopencode、コーディング以外の自動化タスクも含めたいならGooseの選択肢が広がる。

組織的な問いへの向き合い方

エージェントがチームに浸透すると、「何人のエンジニアが必要か」という問いの立て方が変わる。頭数ではなく「何件の作業ラインを同時に走らせられるか」が問いになる。

その観点では、Gooseのような「自分でツールを追加できる・モデルを入れ替えられる」エージェントは、チームの能力拡張装置として機能する。ピラミッド型の組織設計よりも、少人数で広い作業範囲をカバーする設計の方が合ってくる。

少人数でエージェントを並列に動かす具体的な設計については1人開発でマルチエージェント体制を作る方法に実践パターンをまとめている。

これは単なる効率化ではない。チームの構造を変える話だ。

参考

  • block/goose ── Gooseの公式リポジトリ（Block）
  • sst/opencode ── opencodeの公式リポジトリ（SST）