Goose完全ガイド2026｜Block製OSS CLI AIエージェント

GooseとはなにかBlock製OSSエージェントの位置づけ

GooseはBlock（旧Square）が2025年1月にオープンソースで公開したCLI型AIエージェントだ。コードの提案にとどまらず、シェルコマンドの実行、ファイル編集、テスト実行、ブラウザ操作まで自律的にこなす。GitHub Stars は2026年4月時点で39,000超、コントリビューターは350名以上。2025年12月にはLinux FoundationのAgentic AI Foundation（AAIF）に寄贈され、AnthropicのMCPやOpenAIのAGENTS.mdと並ぶOSSエージェント基盤として認定された。

同カテゴリのCline・Aider・Claude Codeが「エディタ拡張」または「クラウドサービス」として提供されるのに対し、GooseはRust製のローカルバイナリとして動作するのが最大の特徴。ネットワーク遮断環境でもOllamaと組み合わせれば完全ローカル運用が可能で、エンタープライズのセキュリティ要件を満たしやすい。

本記事では、Gooseのインストールから基本操作・LLMプロバイダー設定・MCP統合・Recipe自動化・カスタム拡張開発・セキュリティ考察まで、実践的なガイドを提供する。

Claude Code・Cline・Aiderとの4エージェント比較

「結局どれを選ぶか」が最大の関心事のはず。4ツールを主要観点で整理する。

項目	Goose	Claude Code	Cline	Aider
開発元	Block / AAIF	Anthropic	OSS (コミュニティ)	OSS (Paul Gauthier)
実行形式	CLI + Desktop App	CLI	VS Code拡張	CLI
LLM選択	25+プロバイダー対応	Claude専用	マルチLLM	マルチLLM
MCP対応	ネイティブ（設計思想の中核）	あり	あり	なし
Recipe/自動化	YAMLレシピ、cronスケジュール	なし	なし	なし
完全ローカル	Ollama連携で可	不可	Ollama連携で可	Ollama連携で可
ライセンス	Apache 2.0	商用	Apache 2.0	Apache 2.0
GitHubスター数	39,000+	N/A	40,000+	24,000+

Gooseを選ぶべきケース：①複数LLMを切り替えたい、②MCPサーバーを大量に使いたい、③Recipeで定型タスクを自動化したい、④完全ローカルにしたい。Claude Code一択なのは「Claude Sonnetの最高品質で妥協したくない」という場合に限られる。詳細な比較はCline・Aider・Claude Code三強比較も参照されたい。

インストール手順 macOS・Linux・Windows

Gooseは公式のAAIFリポジトリから配布されている。CLI版とDesktop App版の2形態がある。

macOS

# Homebrew でCLIインストール（推奨）
brew install block-goose-cli

# または インストールスクリプト（Homebrewなし環境）
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# Desktop版（GUI + CLI同梱）
brew install --cask block-goose

Linux（Debian/Ubuntu系）

# CLIスクリプト（DEB/RPM/Flatpak共通入口）
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# または最新リリースからDEBを直接取得
GOOSE_VER=$(curl -s https://api.github.com/repos/aaif-goose/goose/releases/latest | grep '"tag_name"' | cut -d'"' -f4)
wget "https://github.com/aaif-goose/goose/releases/download/${GOOSE_VER}/goose_${GOOSE_VER}_amd64.deb"
sudo dpkg -i "goose_${GOOSE_VER}_amd64.deb"

Windows（Git Bash / PowerShell）

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

# PowerShell
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/aaif-goose/goose/main/download_cli.ps1" -OutFile "download_cli.ps1"
.\download_cli.ps1

インストール後、バージョン確認で動作を確かめる。

goose --version
# goose 1.x.x

基本コマンドセッションとconfigure

最も使うのは goose session と goose configure の2コマンドだ。

# 新規セッションを開始（インタラクティブモード）
goose session

# セッション名を指定して開始
goose session --name "my-coding-session"

# 過去のセッションを再開
goose session --resume

# セッション一覧表示
goose session list

# 非インタラクティブ（スクリプト呼び出し）
goose run --text "src/main.py を解析して問題点を3つ報告して"

# プロバイダーとモデルを切り替えてセッション開始
goose session --provider anthropic --model claude-sonnet-4-6

goose configure は初回セットアップと設定変更に使うインタラクティブなウィザードだ。

goose configure

ウィザードでは「Provider」「Model」「API Key」「Extensions」を順番に設定する。設定内容は ~/.config/goose/config.yaml に書き出される。

LLMプロバイダー設定 Anthropic・OpenAI・Google・Ollama

Gooseが対応する主要プロバイダーの設定例を示す。

Anthropic（Claude）

# 環境変数で設定
export ANTHROPIC_API_KEY="sk-ant-xxxx"

# config.yamlで固定する場合
# ~/.config/goose/config.yaml
# provider: anthropic
# model: claude-sonnet-4-6

OpenAI

export OPENAI_API_KEY="sk-xxxx"
# goose configure → Provider: openai → Model: gpt-4o

Google Gemini

export GOOGLE_API_KEY="AIzaxxxx"
# goose configure → Provider: google → Model: gemini-2.5-pro

Ollama（完全ローカル）

# Ollamaを起動
ollama serve
ollama pull qwen2.5:32b  # または llama3.2、phi4 など

# GooseからOllamaを参照
export OLLAMA_HOST="http://localhost:11434"
# goose configure → Provider: ollama → Model: qwen2.5:32b

Ollamaを使えば、APIキー不要・完全オフラインでGooseを運用できる。機密情報を扱う業務や、インターネット接続が制限された環境での選択肢として有力だ。

MCP Server統合 Smitheryレジストリ連携

GooseはMCPをエクステンション機構の中核に据えている。Smithery（MCPサーバーのレジストリ）経由で3,000以上のMCPサーバーをGooseに即座に追加できる。

MCP拡張の追加は goose configure でも行えるが、コマンドラインで直接追加する方が速い。

# GitHubアクセス用MCP（公式）
npx -y @modelcontextprotocol/server-github

# Smithery経由でカスタムMCPサーバーを追加
# goose configure → Extensions → Add Extension → MCPサーバーURLまたはコマンドを指定

# 設定ファイル例: ~/.config/goose/config.yaml
extensions:
  - name: github
    type: mcp
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
  - name: filesystem
    type: mcp
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/me/projects"

MCPサーバーを追加すると、GooseはそのサーバーのToolsをセッション中に自律的に呼び出せるようになる。「GitHubのIssue一覧を取得してコードを修正してPRを出して」という指示を一度で完結できるのはMCP統合の恩恵だ。

Extensions ビルトイン拡張機能

Gooseには標準でいくつかのExtensionが同梱されている。主要なものを整理する。

# 現在有効なエクステンション一覧
goose extension list

# エクステンションを有効化/無効化
goose configure  # → Extensions タブで切替

Extension	機能	デフォルト
developer	ファイル読み書き・シェル実行・テスト実行	有効
computer_controller	スクリーンショット・マウス・キーボード操作	無効
memory	セッション間のコンテキスト永続化	無効
google_drive	Google Driveファイルの読み書き	無効
github	GitHub Issue/PR/コード操作	無効
jira	Jiraチケット操作	無効

developer エクステンションはGooseの中核機能を担う。ファイルシステム操作・シェルコマンド実行・コード編集はこれが有効でないと動かない。

Recipeファイルで再利用可能なタスク定義

GooseのRecipeは、タスクの指示・使用するExtension・パラメーター・実行スケジュールをYAMLで定義したポータブルな設定ファイルだ。CI/CDへの組み込みやチーム共有に向いている。

# daily-code-review.yaml
version: 1.0.0
title: "日次コードレビュー"
description: "変更されたファイルを自動でレビューしてSlackに報告"
instructions: |
  今日のgit diffを取得し、コード品質・セキュリティ・パフォーマンス観点でレビューしてください。
  問題点があれば重要度（High/Medium/Low）と共に箇条書きで報告してください。

settings:
  goose_provider: "anthropic"
  goose_model: "claude-sonnet-4-6"
  temperature: 0.2

extensions:
  - name: developer
    type: builtin

parameters:
  - key: target_branch
    input_type: string
    requirement: required
    description: "レビュー対象のgitブランチ名"

# レシピを実行
goose run --recipe daily-code-review.yaml --params target_branch=main

# cronでスケジュール実行（毎朝9時）
goose schedule add \
  --schedule-id daily-code-review \
  --cron "0 0 9 * * *" \
  --recipe-source ./recipes/daily-code-review.yaml

Recipeを使えば「毎朝9時に昨日のdiffをレビューしてSlackに投稿する」ような定型業務を完全自動化できる。CI/CDパイプラインに組み込んでPR単位のレビューを自動化する使い方も広がっている。

カスタム拡張機能の開発

Gooseのエクステンションは標準のMCPプロトコルに準拠しているため、任意の言語でカスタムMCPサーバーを書けばGooseのToolとして利用できる。

# カスタムMCPサーバーの最小実装例（Python）
# custom_tool.py
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import asyncio

app = Server("custom-tool")

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="fetch_internal_api",
            description="社内APIからデータを取得します",
            inputSchema={
                "type": "object",
                "properties": {
                    "endpoint": {"type": "string", "description": "APIエンドポイントのパス"}
                },
                "required": ["endpoint"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "fetch_internal_api":
        # 社内APIを呼び出す処理
        endpoint = arguments["endpoint"]
        # ... 実際のAPI呼び出し
        return [TextContent(type="text", text=f"Result from {endpoint}")]

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())

asyncio.run(main())

# Goose設定に追加
extensions:
  - name: custom-tool
    type: mcp
    command: python3
    args:
      - "/path/to/custom_tool.py"

社内のデータベース・独自APIとGooseを繋げることで、「社内KPIデータを取得してレポートを書いて」のような業務固有のタスクをエージェントに任せられるようになる。

セキュリティ考察 実行環境分離とサンドボックス

Gooseはシェルコマンドを自律実行するため、セキュリティ上の考慮が不可欠だ。主要なリスクと対策を整理する。

1. Allowlist（許可リスト）による制御
Gooseには実行可能なコマンドやアクセス可能なディレクトリを制限するAllowlist機能がある。プロダクション環境での実行は、このリストで範囲を厳密に絞るべきだ。

2. シークレット管理
APIキーはキーリング（macOSならKeychain）に格納される。フォールバックとして ~/.config/goose/secrets.yaml に平文で保存されるため、このファイルのパーミッションは600に設定すること。

chmod 600 ~/.config/goose/secrets.yaml

3. ネットワーク分離
機密データを扱う場合は、Ollamaと組み合わせてネットワークへのアウトバウンドを遮断した環境で動かすことを検討する。ANTHROPIC_API_KEY等のクラウドキーを設定しない状態でOllamaのみに向けることで、データが外部に出ない構成を取れる。

4. 人間のレビューポイント
完全自律実行はリスクが高い操作（本番DBへの書き込み・外部API呼び出し等）においては、Gooseに「実行前に確認を求める」指示をプロンプトに含めることが実務上の安全弁になる。

実運用パターン3選

パターン1：コーディング補助（Cline代替）

goose session --name "feature-dev"
# セッション内で:
# "src/api/users.ts にページネーション機能を追加して。既存のテストも更新して。"

エディタ拡張不要でターミナルから完結するため、サーバー環境での開発・Docker内作業との親和性が高い。

パターン2：リサーチと資料作成

goose run --text "競合他社XYZの最新プレスリリース3本を要約してMarkdownで docs/competitor-analysis.md に保存して"

MCPサーバー（Brave Search・Firecrawl等）を追加すればウェブ情報の収集から資料作成まで一気通貫で自動化できる。

パターン3：CI/CDへの組み込み

# .github/workflows/goose-review.yaml
name: Goose Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  goose-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Goose CLI
        run: curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
      - name: Run Goose Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          goose run --recipe .goose/pr-review.yaml \
            --params pr_number=${{ github.event.pull_request.number }}

失敗パターン4選と対処法

パターン1：「プロバイダーが接続できない」エラー
原因：APIキーが未設定 or キーリングへのアクセス失敗。
対処：export ANTHROPIC_API_KEY="sk-ant-xxxx" を明示的に設定してから再実行。

パターン2：MCPサーバーが認識されない
原因：config.yaml の記述ミス（インデント・型違い）。
対処：goose configure のインタラクティブUIで追加し直す。直接YAML編集はスキーマミスが起きやすい。

パターン3：Recipeが途中で止まる
原因：LLMのトークン上限に達している or エクステンションがタイムアウト。
対処：instructions を短く分割した複数のサブRecipeに分割する（sub-recipesフィーチャー）。

パターン4：Ollamaで性能が出ない
原因：ローカルモデルのパラメータ数が不足。
対処：コーディング用途なら最低でもqwen2.5:32bを使う。7B以下はGooseの複雑なエージェント指示についてこられないことが多い。

まとめGooseを導入すべき開発者像

Gooseは「特定エディタに縛られず、複数LLMを使い分け、MCP経由でツールを自由に拡張したい」という開発者・DevOpsエンジニアにとって現時点で最有力のOSS CLIエージェントだ。

Block発でLinux Foundationに移管済みというガバナンスの透明性も大きい。単一企業のロードマップに依存しないため、長期運用の安心感がある。

まずは brew install block-goose-cli && goose configure でClaudeまたはOllamaと接続し、15分使ってみてほしい。MCP統合の詳細はSmithery完全ガイドを、周辺ツールとの組み合わせはComposio統合ガイドも参照されたい。