Goose：MCP ネイティブで、手元のマシンで動き、サーバーを持つあらゆるものと話せる AI エージェント

👁️ — 回閲覧

Goose は Apache-2.0 の汎用 AI エージェント（CLI、デスクトップ、API）で、自分のマシン上で動く。新たな能力は閉じたプラグインストアではなく Model Context Protocol 拡張から生まれ、ガバナンスは現在 Linux Foundation にある。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

これは何か

Goose は、手元のマシンで動く汎用 AI エージェントで、CLI、ネイティブのデスクトップアプリ、そして組み込み可能な API として提供される。単なる自動補完やチャットボックスではない。シェルコマンドを実行し、ファイルを編集し、コードを走らせ、あなたが自然言語で与えた目標に向けて複数ステップのワークフローを連ねていく。リポジトリ上の一行のタグラインはこうだ。「your native open source AI agent — desktop app, CLI, and API — for code, workflows, and everything in between.」

本プロジェクトは Apache-2.0 ライセンスのオープンソースで、主に Rust で書かれている。Block（Square／Cash App の親会社）でコードネーム「goose」として始まったが、注目すべきガバナンス上の動きとして、その後 Linux Foundation 傘下の Agentic AI Foundation（AAIF） へ移管された —— 正規のリポジトリは現在 aaif-goose/goose にある。本稿執筆時点で GitHub リポジトリのスター数はおよそ 48,100、そして最新リリースの v1.37.0 は 2026 年 6 月 3 日付 —— 私が確認した数日前であり、これは活発に動いている速いプロジェクトだ。特定のベンダーに縛りつけるのではなく、幅広いモデルプロバイダ（Anthropic、OpenAI、Google、Ollama、OpenRouter、Bedrock など）に接続する。

なぜこのアーキテクチャが興味深いのか

決定的な賭けは、能力は専有のプラグインカタログではなく、開かれたプロトコルから来るべきだという点にある。Goose は、ツールとデータをエージェントに公開するための開放標準である Model Context Protocol（MCP） の、最も早く、最も深い採用者の一つだった。リポジトリは MCP 経由で 70 以上の拡張に接続できることを謳っており、その帰結は大きい。MCP サーバーを提供するサービス —— GitHub、Jira、Slack、データベース、監視ダッシュボード —— は、保守側がそれぞれにあつらえの統合を書かなくても、Goose から使えるようになる。エージェントの手の届く範囲は、一社のロードマップが許す範囲ではなく、エコシステムの成長とともに広がる。

二つ目の構造的な選択はガバナンスだ。プロジェクトを中立な財団の下へ移すことは、その方向性がもはや単一ベンダーの商業的優先順位に左右されないことを意味する —— あるエージェントにインフラを賭けるなら、これは実質的な考慮点だ。二つの姿勢を比べてみよう。

率直に読み解けば、Goose を強力にしているその開放性が、同時にその影響範囲をも広げている。シェルコマンドを実行し、任意のサードパーティ MCP サーバーに接続するエージェントは、多くのものに手が届く。だからこそ信頼境界はよく考えるに値する。

インストールと実行

プロジェクト自身のサイトと README に示されているインストールコマンドは、CLI を curl からブートストラップする bash だ。

# install the goose CLI (verbatim from goose-docs.ai / the repo README)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# then configure a provider + model and start a session
goose configure
goose session

あらゆる curl | bash インストーラと同様、少しでも不安があるならシェルへ流し込む前にスクリプトを読むこと —— これはプロジェクトの GitHub リリースから取得されるが、この習慣は持っておく価値がある。

実務メモ

私が実際にやるとすれば、こうする。カタログまるごとではなく、あえて小さな MCP 拡張の集合から Goose を立ち上げる。初日からすべてを —— GitHub、Slack、データベース、クラウドを —— 配線したくなる誘惑がある。私はむしろ、使い捨てのブランチ上で、組み込みの developer（シェル + ファイル編集）拡張から始め、エージェントがどう計画し動くかを観察し、あるリモート MCP サーバーがどんな認証情報とスコープを要求するかを理解してから初めて、それを追加する。拡張を一つ有効にするたびに、新たな攻撃面と、環境内の新たな秘密の一式が加わる。「MCP サーバーを足す」ことは、依存関係を一つ足すのと同じ慎重さで扱うべきだ。中断可能なセッションはここで助けになる —— 最初の数回は、何か重要なものに対して自由に走らせるのではなく、ハンドルに手を添えておこう。

私が特にこの種のエージェントに手を伸ばすのは、タスクがファイルだけでなくツールをまたぐときだ。CI の失敗を再現し、本物のデータストアに問い合わせ、PR を立て、チャンネルに通知する。このツール横断的な手の届き方こそ、純粋なコード編集エージェントに対して MCP モデルが真価を発揮する場所だ。

見落とされがちな視点

見出しは「開かれたエージェント」だが、より静かで、より重大な変化は、ロックインがどこへ移るかにある。エージェントを、いかなる単一のモデルベンダーからも、いかなる単一のプラグインストアからも切り離すことで、Goose は依存リスクを消し去るというより、それを MCP エコシステムそのもの へと移し替える —— サーバー群、その認証モデル、そしてそれらの保守の健全さへと。十数個のサードパーティ MCP サーバーを軸にワークフローを組み立てるチームは、ベンダーロックインを、拡散したサプライチェーン依存と引き換えにしたことになる。各サーバーは誰か他人が出すコードであり、それぞれ独自の更新ペース、セキュリティ姿勢、そして保守されなくなる確率を持つ。それはおそらくより良い場所だ —— 開放標準は閉じたものに勝る —— が、依存がないわけではない。Goose で勝つチームは、有効にした MCP サーバーを本番の依存関係のように扱う。バージョンを固定し、レビューし、どれが欠かせないかを把握する。財団によるガバナンスはエージェントの中立性を解決する。だが、あなたがそこにボルト留めする拡張の長い裾野の寿命については、何も語らない。