Claude CodeとGooseの比較：コスト、制御、開発者のワークフロー

Claude CodeとGooseの比較：開発者が本当に気にする代替可能性の問題

最近一緒に仕事をしたチームには、一見単純なコストの問題がありました。八人のエンジニアが移行作業中にClaude Codeを頻繁に使っていて、月額サブスクリプションの費用が急に目立つようになり、財務部門からオープンソースのエージェントで代替できないかと尋ねられたのです。Gooseは、ローカルファーストで拡張性があり、複数のモデルプロバイダーに接続できるため、すぐに候補に挙がりました。説明だけを聞けば、魅力は明快です。ターミナルでエージェントを使うワークフローを維持し、ユーザー数に応じたサブスクリプションを追加せずに済み、モデルの呼び出し先も自由に選べます。

しかし実際には、「無料」と「同等」は同じ意味ではありません。

本当に比較すべきなのは、Gooseがファイルを編集したり、シェルコマンドを実行したりできるかどうかではありません。それは可能です。問題は、開発者の実際の働き方において、GooseがClaude Codeを代替できるかどうかです。複数ファイルにまたがるリファクタリング、テストを軸にした反復作業、リポジトリを踏まえた推論、エンタープライズ向けの管理機能、Claude本来のモデル動作、そして、ごく普通の火曜日の午前中を、アシスタントのデバッグに半分費やすことなく乗り切れる、当たり前の信頼性が問われます。

これは、Claude CodeとGooseを比較検討する開発者向けの実践的な比較です。検索意図を絞り、Gooseは現実的にClaude Codeを置き換えられるのか、また、どのような条件でその答えが変わるのかを扱います。

要点

Gooseを「無料のClaude Code」と捉えるのは誤りです。Gooseは、適切なモデルと設定を組み合わせることで優れた性能を発揮できる、オープンなエージェントランタイムと理解するほうが適切です。Claude Codeは、Anthropicのコーディングワークフローを中心に、より明確な設計方針に基づいて作られた製品です。

Claude Codeが標準で提供するもの

Claude Codeの最大の強みは、特定のコマンドではありません。標準の使い方が、実際のソフトウェア開発作業に合わせてすでに整えられていることです。

通常のセッションは次のようになります。

cd ~/work/payments-service
claude

続いて、セッション内で次のように指示します。

Read the failing test output, inspect the relevant code paths, and make the smallest fix.
Run the focused test before changing anything else.

単発のタスクを直接実行する場合：

claude "Find why invoice retries are duplicating events and propose a minimal patch"

実際にClaude Codeが役立つのは、ワークフローに関する多くの前提を適切に踏まえているからです。

• リポジトリのコンテキストが重要であることを理解しています。
• 編集前にファイルを調査できます。
• テストを実行し、失敗に対応できます。
• 設定に応じて、機微な操作に際して許可を求めます。
• コードの推論や長期的な編集作業に強いSonnet 4.6やOpus 4.8などのClaudeモデルに合わせて調整されています。

日常の作業では、Claude Codeが次のような用途で使われるのをよく見かけます。

• 「変更する前に、このサービスの境界を説明してください。」
• 「このバグを再現する、失敗するテストを追加してください。」
• 「公開APIを変更せずに、このモジュールをリファクタリングしてください。」
• 「本番環境でこの設定値が読み取られる箇所を探してください。」
• 「このエンドポイントと、すべての呼び出し元を更新してください。」
• 「この差分をレビューして、リグレッションがないか確認してください。」

重要なのは、Claude Codeが提供する機能は、単にターミナル内のチャット欄ではないという点です。読み取り、推論、修正、実行、反復というコーディングのループを実現します。

一般的な設定パターンとして、リスクのある操作には明示的な許可を必要とする方法があります。たとえば、チームでは、アシスタントが実行できる操作を制限するために、プロジェクト内のローカル設定をよく使います。

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(pytest:*)",
      "Bash(git diff:*)",
      "Bash(git status:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(rm -rf:*)",
      "Bash(kubectl delete:*)"
    ]
  }
}

具体的なポリシーは環境によって異なりますが、原則は変わりません。開発者が実行するのと同じ安全な検証コマンドはアシスタントにも実行させ、共有インフラを変更したりコードを公開したりするコマンドはブロックします。

Gooseが実際に提供するもの

Gooseが魅力的なのは、別の理由からです。開発者がエージェント層をより主体的に管理できます。単一ベンダーが一貫して提供するコーディングアシスタントを受け入れる代わりに、オープンソースのエージェントをローカルで実行し、好みのプロバイダーやツールに接続できます。

一般的なGooseのセットアップは、次のような形に近くなります。

# Install Goose using the current recommended installer for your platform
goose configure
goose session

設定時に、プロバイダーとモデルを選択します。詳細は環境によって異なりますが、概念的には次のような設定になります。

provider: anthropic
model: claude-sonnet-4-6
extensions:
  developer:
    enabled: true
  memory:
    enabled: true

また、ローカルモデルを試す場合は次のようになります。

provider: ollama
model: qwen2.5-coder:32b
extensions:
  developer:
    enabled: true

この柔軟性こそが重要な点です。Gooseは、Anthropicのモデル、ローカルモデル、その他のプロバイダーのバックエンドと組み合わせて使えます。拡張機能を通じた統合に加え、セットアップによってはMCP形式のツール接続も利用できます。

シンプルなGooseのワークフローは、次のようになります。

cd ~/work/billing-api
goose session

続いて：

Inspect the retry scheduler and explain why duplicate invoice events are possible.
Do not edit files yet.

または：

Create a patch that makes the retry operation idempotent.
Run the focused unit tests if available.

Gooseを適切に設定し、性能の高いモデルと組み合わせれば、Claude Codeのループに近い使用感を得られます。性能の低いモデル、不完全なツール設定、あるいは壊れやすいローカル環境への依存がある場合は、すぐに差が現れます。

これが中心となるトレードオフです。Gooseでは制御の自由度が得られますが、その分、統合作業をより多く引き受けることになります。

コスト：クライアントが無料でも、コーディングが無料になるわけではありません

この比較で最も大きな誤解は、コストに関するものです。

Gooseがオープンソースであることで、クライアントのサブスクリプション費用を削減、またはなくすことはできます。しかし、モデルの推論コストが魔法のようになくなるわけではありません。Gooseの接続先を有料のホスト型モデルにすれば、引き続きトークンに対して料金を支払います。ローカルモデルに接続する場合は、ハードウェア、レイテンシー、品質上のトレードオフ、セットアップ時間、運用保守という形でコストを負担します。

実用的なコスト比較は、次のようになります。

個人の開発者であれば、Gooseとローカルモデルの組み合わせで、小規模な編集、説明、スクリプト作成の支援には十分かもしれません。大規模なTypeScriptモノレポや、並行処理に微妙な挙動があるPythonサービスで本格的な作業を行うチームにとっては、エージェントのラッパーよりもモデルの品質が重要です。

現在のClaudeのラインアップと比較する場合は、特にそう言えます。Sonnet 4.6は能力とコストのバランスがよく、コーディングの日常利用で実用的なモデルとなることが多いです。Opus 4.8は、より難しいアーキテクチャの検討や複数段階のデバッグ作業に取っておきたいモデルです。Haiku 4.5は、深い推論よりも速度とコストが重要な場合に役立ちます。Fable 5の1Mコンテキストは、非常に大きなコンテキストを扱うワークフローの判断を変えます。ただし、大きなコンテキストは、適切な検索と厳密なタスク設定の代わりにはなりません。

API経由でGooseからClaudeモデルを利用する場合、コストの議論の中心は「Claude Code対Goose」ではなく、サブスクリプションのパッケージとトークン従量課金のインフラの比較になります。

ローカル環境での制御と企業の制約

Gooseの最も強い訴求点は、制御できることです。

ツールの実行場所、許可されるプロバイダー、開発者のマシン設定について組織に厳格な要件がある場合、Gooseでは自ら管理できる範囲が広がります。設定の標準化、バージョンの固定、拡張機能の定義、承認済みゲートウェイ経由でのモデル通信のルーティングが可能です。

たとえば、企業向けのラッパーでは、環境変数を通じてプロバイダーの設定を指定することがあります。

export GOOSE_PROVIDER=anthropic
export ANTHROPIC_API_KEY="$AI_GATEWAY_ANTHROPIC_KEY"
export GOOSE_MODEL=claude-sonnet-4-6

goose session

または、社内プロキシ経由でルーティングします。

export ANTHROPIC_BASE_URL="https://ai-gateway.internal.example.com/anthropic"
export ANTHROPIC_API_KEY="$DEVELOPER_AI_TOKEN"
goose session

この種の構成は、ログの集中管理、予算管理、許可リスト、通信の検査が必要な場合に魅力的です。

一方、会社がすでにAnthropicの製品の制御機能を受け入れており、ローカルでの構築作業を抑えながら、サポートのあるClaudeネイティブの使用体験を求める場合は、Claude Codeのほうが魅力的です。セキュリティポリシー、開発者のトレーニング、リポジトリ単位のガードレールは引き続き必要ですが、エージェント基盤を自ら構築する作業は少なくなります。

ローカルファーストのツールでよくある落とし穴は、「自分たちで制御できる」が「自分たちで保守する」に変わり得ることです。誰かが次の問いに答える必要があります。

• どのモデルが承認されていますか？
• どの拡張機能がインストールされていますか？
• シークレットがプロンプトに漏れ込むのをどう防ぎますか？
• ログをどのように保存し、または無効にしますか？
• エージェントはどのコマンドを実行できますか？
• macOS、Linux、シェル、Pythonのバージョン、Nodeのバージョン、企業のエンドポイント管理ツールにまたがる障害を、どのようにデバッグしますか？

Claude Codeでもこれらの問いがなくなるわけではありませんが、製品としてサポートされる範囲はより明確です。

日々のワークフロー：違いが現れる場面

通常の開発作業のループを見ると、置き換えられるかという問いが具体的になります。

1. リポジトリの理解

Claude Codeは、編集前に全体像を把握するよう求めたときに強みを発揮します。

Map the request flow for POST /invoices from route handler to database write.
List the files involved and identify where idempotency should live.
Do not make changes yet.

適切に設定されたGooseも、特に能力の高いモデルを使えば、同じことができます。リスクは、品質の低いモデルが十分にファイルを調べずに、自信を持って要約してしまう可能性があることです。これはGoose固有の失敗ではなく、エージェントという仕組みに共通する失敗です。ただし、Gooseはプロバイダーを柔軟に選べるため、チームが重要なワークフローで性能の低いモデルを試す可能性は高くなります。

2. 複数ファイルの編集

対象を絞った変更であれば、どちらのツールも対応できます。

Rename RetryPolicy.maxAttempts to RetryPolicy.maximumAttempts across the repo.
Update tests and run the focused suite.

編集が生成コード、テストフィクスチャ、フレームワークの規約にまたがる場合に実際に何が起こるかは、モデルとツールの性能が重要になる場面です。Claude Codeは、Claudeネイティブの体験がまさにこの用途に合わせて調整されているため、一般に一連の作業全体を通じて一貫性が高いと感じられます。Gooseも、プロバイダーのモデルが高性能で、ファイル操作ツールが信頼できれば同等の体験を実現できますが、そのための設定は利用者に委ねられます。

3. テストの実行

役に立つアシスタントは、編集するだけでなく、検証も行うべきです。

pytest tests/billing/test_invoice_retries.py -q
npm test -- --run retry-policy
cargo test retry_policy

どちらのツールでも、私はエージェントに漠然と「テストを実行して」と頼むより、具体的なテストコマンドを指定することを好みます。無駄な時間を減らし、エージェントが誤って統合テスト一式を実行するのを防げるからです。

適切なプロンプトの例は次のとおりです。

Make the minimal fix, then run:
pytest tests/billing/test_invoice_retries.py -q

If it fails, show the failure and inspect before making a second edit.

Claude Codeは、この一連の作業を円滑に進める傾向があります。Gooseも対応できますが、シェル連携と権限を適切に設定する必要があります。

4. 長いコンテキストを使う作業

大きなコンテキストは便利ですが、使い方を誤りやすいものです。リポジトリ全体をコンテキストに入れることが、最初の一手として最適なケースはほとんどありません。

Claudeモデルでは、特にコンテキストウィンドウが拡大するにつれ、開発者は次のような大まかな質問をしたくなりがちです。

Review the whole repo and tell me what to refactor.

それでは曖昧な出力になります。より良い例は次のとおりです。

Inspect the authentication middleware, route registration, and user repository.
Find one concrete reason session refresh fails after password rotation.
Return the evidence before suggesting a patch.

この指針は、GooseにもClaude Codeにも同じように当てはまります。ツールを使っても、タスクを明確に定義する必要はなくなりません。

両ツールを活用するAPIワークフロー

チームによっては、どちらか一方だけを選ぶべきではありません。よくある構成は次のとおりです。

• 対話的な開発にはClaude Code。
• 繰り返し実行できる自動化にはAPI呼び出し。
• ローカルでの実験や独自のプロバイダールーティングにはGoose。

たとえば、CIに関連するスクリプトからClaude APIを直接呼び出し、構造化されたレビューコメントを生成できます。

import os
import anthropic

client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

diff = open("diff.txt", "r", encoding="utf-8").read()

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1200,
    messages=[
        {
            "role": "user",
            "content": (
                "Review this diff for likely regressions. "
                "Return JSON with fields: risk_level, findings, tests_to_run.\n\n"
                f"{diff}"
            ),
        }
    ],
)

print(message.content[0].text)

想定するレスポンスの形式：

{
  "risk_level": "medium",
  "findings": [
    {
      "file": "src/retry.ts",
      "issue": "Backoff state is shared across tenants",
      "why_it_matters": "A noisy tenant can slow retries for unrelated tenants"
    }
  ],
  "tests_to_run": [
    "npm test -- --run retry"
  ]
}

これは対話型エージェントの代替ではありませんが、それぞれの役割の境界を示しています。Claude CodeとGooseは開発者向けのツールです。プロンプト、スキーマ、失敗時の処理を自分で管理する、決定論的で繰り返し実行できるワークフローには、APIのほうが適しています。

Gooseは現実的にClaude Codeを置き換えられるか？

一部の開発者にとっては、可能です。

多くのチームにとっては、難しいでしょう。

GooseがClaude Codeを置き換えられる可能性が高いのは、次のような場合です。

• プロバイダーの認証情報や拡張機能の設定に抵抗がない。
• 洗練された標準の体験よりも、ローカルファーストの制御を重視する。
• タスクの複雑さが小規模から中規模である。
• ローカルモデルでは不十分な場合に、高性能な有料モデルを使う意思がある。
• 組織内にエージェントの構成を維持管理できる人がいる。

Claude Codeを置き換えるのが難しいのは、次のような場合です。

• 開発者が、複数のステップからなるコーディングの反復作業で一日中利用している。
• 手間の少ない導入手順が必要である。
• Claudeネイティブの動作と、現行のAnthropicモデルとの統合を重視する。
• ツールチェーンの構成要素を減らしたい。
• クライアントのオープン性よりも、エンタープライズ向けの管理機能、サポートのしやすさ、予測可能な開発者体験を重視する。

率直に言えば、GooseはClaude Codeのワークフローの一部を置き換えられます。すべてを置き換えられるかどうかは、Goose自体よりも、それを支えるモデル、設定、運用の徹底度に左右されます。

サブスクリプション料金だけを基準に評価する場合は、実際の作業項目を使って二週間のトライアルを実施してください。以下を記録してください：

• 最初の有用なパッチが得られるまでの時間。
• 失敗したツール呼び出しの回数。
• タスクごとに人間が修正を加えた回数。
• APIを利用するGooseセッションのトークン費用。
• 設定とデバッグに開発者が費やした時間。
• レビュー後の最終的な差分の品質。

機能チェックリストよりも、こうした記録のほうが多くを教えてくれます。

実践上のポイント

「Claude Code対Goose」は、単純な有料か無料かの選択ではありません。少ない設定で洗練されたClaudeネイティブのコーディングワークフローを求める開発者には、Claude Codeのほうが有力な標準の選択肢です。導入直後の使いやすさよりも、ローカルでの制御、プロバイダー選択の柔軟性、オープンな拡張性を重視する場合、Gooseは魅力的です。

個人開発者にとって、Gooseは間違いなく試す価値があります。チームでは、実際のチケット、実際のリポジトリ、実際の費用記録を使って評価してください。クライアントが無料だからといって利用も無料だと考えたり、難しいコードの推論でローカルモデルがSonnet 4.6やOpus 4.8に匹敵すると考えたりしないでください。

私の基本的な推奨は実用的なものです。開発者の処理能力が最も重要な場面ではClaude Codeを使い続け、制御とカスタマイズが最も重要な場面ではGooseを試し、繰り返し実行する自動化にはClaude APIを直接使ってください。正解は、単独の勝者を選ぶことではなく、複数を組み合わせたワークフローかもしれません。