クラウド型のAIコーディングエージェントは月額100ドル超のプランが必要になる場面も多い。コードやプロンプトを社外に送りたくない開発者向けに、Goose・Ollama・Qwen3-coderの3層構成でローカル完結の代替環境が注目を集めています。
この記事では、各ツールの役割分担と連携の仕組み、クラウド型サービスとの違い、導入時の前提条件を整理します。
この記事でわかること
- Goose・Ollama・Qwen3-coderがそれぞれ担う役割
- 3ツールが連携してコードを生成・適用する流れ
- Claude CodeやCodexと比べたメリットと制約
- ローカル運用に必要なハードウェアと設定の要点
3層スタックが解決する課題
Claude CodeやOpenAI Codexは、エージェント（タスク管理）・ランタイム（モデル実行）・コーディングLLM（コード生成）を一体で提供します。一方、Goose・Ollama・Qwen3-coderはこの3層を分離し、すべてローカルPC上で動かせます。
ZDNETのDavid Gewirtz氏によると、月額20ドル程度のプランでは数時間単位のエージェントコーディングが限界になり、丸一日使うなら月額100〜200ドルの上位プランが必要になるケースがあると報じています（参考）。加えて、クラウド処理はソースコードの持ち出し規約やセキュリティ要件と衝突する可能性があります。
ローカル構成なら、モデル推論もファイル操作も自端末内で完結するため、通信コストとデータ外部送信の両方を抑えられます。2025年7月にJack Dorsey氏がXで「goose + qwen3-coder = wow」と投稿したことも、この組み合わせへの関心を押し上げました。
Qwen3-coder：コードを書くエンジン
https://ollama.com/library/qwen3-coder
Qwen3-coderはAlibaba（アリババ）が公開するQwen3シリーズのコーディング特化モデルです。チャットUIのような対話フロントとは別物で、プロンプトからコードを生成し、リファクタリングや差分比較、バグ修正の指示に応じる部分を担います。
Ollama経由で利用するqwen3-coder:30bは、総パラメータ30Bのうち推論時に3.3Bだけを活性化するMixture-of-Experts（MoE）構造です。モデルサイズは約19GB、ネイティブで256Kトークンのコンテキストを持ち、リポジトリ規模のコード理解を想定した設計になっています。7.5Tトークン（コード比率70%）で事前学習され、SWE-Benchなどのベンチマーク向けに強化学習も施されています。
ただしLLM単体では多段階ワークフローの管理や「いつ作業を止めるか」の判断はできません。会話の文脈も、現在のセッション範囲に限定されます。コード生成の「頭脳」として位置づけます。
Ollama：モデルを動かすランタイム
OllamaはローカルLLMのダウンロード・インストール・推論を担うランタイムです。CPUやGPU上でモデルを実行し、http://localhost:11434のAPIで他アプリから呼び出せます。Goose公式ドキュメントでも、OllamaプロバイダーはOpenAI互換APIとツール呼び出し（function calling）に対応すると記載されています。
データベースに例えるなら、LLMがデータ本体、Ollamaがそのデータを読み出すエンジンに相当します。モデルの切り替え、バージョン管理、リソース制御を一手に引き受けます。一方でプロジェクト目標の理解やタスク管理は行いません。コーディング能力は、読み込んだモデルが持つ知識に依存します。
Gooseから接続するには、Ollamaアプリの設定で「Expose Ollama to the network」を有効にする必要があります。ZDNETの検証では、コンテキスト長を32Kに設定し、128GB RAMのMac Studioで運用した事例が紹介されています（参考）。エージェント用途ではGOOSE_INPUT_LIMIT環境変数でコンテキスト窓を広げることも推奨されています。
Goose：意図を解釈するエージェント
GooseはBlock社が開発したオープンソースのAIエージェントで、現在はLinux Foundation傘下のAgentic AI Foundation（AAIF）がメンテナンスしています。Apache 2.0ライセンスで、macOS・Linux・Windows向けのデスクトップアプリとCLIが提供されています。
Gooseはコードそのものを生成しません。ユーザーの自然言語指示を解釈し、分析・計画・コード生成・テストのステップに分解してOllama経由でLLMへ依頼します。「リポジトリをスキャンして変更案を出し、差分を適用して」と指示したときの指揮役です。会話とタスクの文脈をセッション横断で保持し、変更が局所修正で済むかモジュール単位の書き換えが必要かを判断します。
15以上のLLMプロバイダーと接続でき、Model Context Protocol（MCP）経由で70以上の拡張機能を追加できます。Ollamaをプロバイダーに選び、モデルとしてqwen3-coder:30bを指定すれば、今回の3層構成が完成します。
実際の処理フロー
典型的なワークフローは次の通りです。
- 開発者がプログラミング目標を自然言語で入力する
- Gooseが目標を解釈し、次に取るべきアクションを決定する
- Gooseが精密化したコーディングプロンプトをOllamaへ送信する
- OllamaがQwen3-coderをローカルで推論し、コードまたは分析結果を返す
- Gooseが結果を適用・修正・再依頼のいずれかに振り分ける
Claude CodeやCodexも内部では同様の3層構造を持ちますが、フロントエンドの裏でクラウド基盤に統合されています。Gooseスタックは各層を独立させているため、コーディングモデルだけ別のLLMに差し替えたり、Ollamaの設定だけ最適化したりと、モジュール単位の変更が可能です。
導入の流れと動作確認
導入順序はOllama → Qwen3-coder → Gooseが安全です。Ollama未起動のままGooseを先に設定すると接続に失敗するためです。
- Ollamaをインストールし、
qwen3-coder:30bを取得する（ollama pull qwen3-coder:30b） - Ollamaのネットワーク公開を有効にし、常時起動させる
- GooseデスクトップアプリまたはCLIをインストールする
- プロバイダー設定でOllamaを選び、モデルに
qwen3-coder:30bを指定する - 作業ディレクトリを指定し、簡単なコーディングタスクで動作を確認する
ZDNETの初期検証では、WordPressプラグインの簡易課題に5回のやり直しが必要だったと報告されています（参考）。チャットボット単体の一発回答とは異なり、エージェントは実ファイルを直接編集するため、反復修正でコードベース自体は改善していきます。M4 Max・128GB RAMのMac Studioでは、Claude CodeやCodexと体感差のない応答速度だったとのことです。16GB RAMのM1 MacではOllama単体でも動作が重いという別の検証結果もあり、ハードウェア要件は無視できません。
クラウド型サービスとの使い分け
| 観点 | Goose + Ollama + Qwen3-coder | Claude Code / Codex |
|---|---|---|
| 費用 | ソフトウェア自体は無料（電気代・GPU/RAMは別） | 月額20〜200ドル |
| データの所在 | ローカル完結 | クラウド処理 |
| モデル品質 | Qwen3-coderはSWE-Bench向けに最適化 | GPT-5.2-codexやOpus 4.5など最先端モデル |
| カスタマイズ | モデル・ランタイム・エージェントを個別に差し替え可能 | 一体型で選択肢は限定的 |
機密性の高いコードベースや、オフライン環境での開発にはローカルスタックが有力です。大規模プロジェクトで最高品質の推論が必要な場面では、クラウド型の上位モデルに軍配が上がる場面もあります。Gewirtz氏は続編でiPadアプリの本格開発にこのスタックを適用する検証を予定しており、実用性の最終判断は大規模タスクの結果待ちです。
注意点
qwen3-coder:30bは約19GBのストレージを消費します。480B版をローカル実行するには250GB以上のメモリが必要で、一般の開発PCでは30B版が現実的な選択肢です。Ollamaは利用中もバックグラウンドで常時起動が必要です。精度面では、シンプルな課題でも複数回の修正が要するケースがあるため、本番投入前に手元のリポジトリで十分な試行を行ってください。