OpenCode Zen vs Go：どちらを選ぶか、併用は可能か

目次

• まず、みんなが混同している3つの名前を整理しよう
• 比較表:BYOK、Zen、Go
• 10ドルに実際に収まるもの
• エージェント1ターンあたりの実際のコスト、視点を整えるために
• 私の提案:設計と実行を分離する

  • なぜこれが技術的にうまくいくのか
  • 具体的なワークフロー、ステップごとに
  • 実行可能なスペックの例
• 必要性と複雑さに応じてAIを選ぶ
• Goプランを使い倒すための実践的な10のコツ
• このワークフローと相性の良い実践的なツール
• Goが答えにならないとき
• 締めくくり
• よくある質問

  • OpenCode GoはClaude CodeやCodexの代わりになりますか
  • GoとZenを同時に使えますか
  • 月10ドルのプランには実際どれくらいのタスクが収まりますか
  • なぜGrok 4.5はGoで月に600リクエストしか使えないのですか
  • 上限を使い切ったらどうなりますか
  • OpenCode Goはチームでの利用に向いていますか
  • 自分のデータは学習に使われますか
• あわせて読みたい
• 出典

まず、みんなが混同している3つの名前を整理しよう

OpenCodeはAnomalyが開発・保守しているオープンソースのターミナル型コーディングエージェントだ。これがツールそのものである。TUI上でコードを書き、エージェントがリポジトリを読み、ファイルを編集し、コマンドを実行し、差分を見せてくれる。無料で、これまでもずっと無料だった。

OpenCode Zenはまったく別物だ。これはモデルのゲートウェイ——仲介役——であり、OpenCodeのチームがある現実的な問題にぶつかった末に構築したものだ。コーディングに使えると謳うモデルは何十種類もあるが、エージェントとしてまともに機能するものはごくわずかで、しかもうまく機能するモデルでさえ、どのプロバイダーが提供するかによって結果が大きく変わる。同じモデルでも、あるプロバイダーでは素晴らしい成果を出し、別のプロバイダーでは平凡な結果しか出さないことがある。ラベルは同じなのにだ。Zenはこの問題への回答だ。モデルを検証し、開発元のチームと話し、プロバイダーと交渉して正しく提供させ、モデルとプロバイダーの組み合わせでベンチマークを取り、厳選されたリストを公開している。従量課金制で、100万トークンあたりの価格が明示されており、決済処理手数料以外の上乗せは公表されていない。

OpenCode Goは3つ目のピース、そして最も新しいものだ。月10ドル(初月は5ドル)の定額サブスクリプションで、あのリストの一部——オープンモデル群——にアクセスでき、利用上限はトークンではなくドル建てで設定されている。「無制限」プランではないし、そう謳ってもいない。明示された倍率があるプランだ。10ドル払えば、チームの目標としてはおよそ60ドル分の利用量を渡す、という設計になっている。

💡 利用上限に使える$5クレジットを獲得する このOpenCode Goのリンクから登録すると、利用上限に直接充当される$5クレジットがもらえる。1セントも使わないうちに、最初のお試し1カ月分がほぼカバーされてしまう。

この3つは互いに独立している。自分のOpenAIやAnthropicのAPIキーを使ってOpenCodeを使い、ZenにもGoにも一銭も払わないこともできる。OpenCode以外のエージェントからZenを使うこともできる。そしてGoとZenを同時に持つこともでき、実はこれが以下で私が推奨する構成だ。

比較表:BYOK、Zen、Go

	OpenCode BYOK	OpenCode Zen	OpenCode Go
課金モデル	無料(プロバイダーに直接支払う)	従量課金、プリペイド残高制	定額サブスクリプション
価格	$0 + APIで使った分の実費	消費トークンに応じて課金	初月$5、以降は月$10
カタログ	対応する任意のプロバイダー	約70モデル:Claude、GPT、Gemini、Grok、Qwen、DeepSeek、GLM、Kimi、MiniMax	オープンモデル18種:Grok 4.5、GLM-5.2/5.1、GPT 5.6 Luna、Kimi K3/K2.7/K2.6、Qwen3.8/3.7/3.6、DeepSeek V4 Pro/Flash、MiniMax M3/M2.7、MiMo-V2.5、Hy3
フロンティアモデル	APIに課金すれば利用可	利用可(Claude Opus 5、GPT 5.6 Sol、Gemini 3.1 Pro、Claude Fable 5)	不可、Grok 4.5とGPT 5.6 Lunaを除く
利用上限	利用中のプロバイダー次第	自分の残高と設定した月間上限	5時間ごとに$12・週$30・月$60
自動チャージ	該当なし	あり:残高が$5を下回ると$20チャージ(金額変更・無効化も可能)	該当なし(定額のため)
上限到達後	該当なし	チャージするか停止	無料モデルは引き続き利用可、「Use balance」を有効にすればZenの残高に切り替わる
チーム利用	手動	ロール付きワークスペース、メンバーごとの上限、モデルの有効化管理(ベータ期間中は無料)	ワークスペースにつき1人のみ契約可能
データ保持	利用中のプロバイダー次第	明記された例外を除き保持ゼロ	ほぼ全モデルで0日間、Grok 4.5とGPT 5.6 Lunaのみ30日間
自分のキーを持ち込む(BYOK)	デフォルトの利用形態	可能。Zen内で自分のOpenAI/AnthropicキーをBYOKで使える	不可
向いている人	すでに契約やクレジットを持っている人	フロンティアモデルと細かい制御が必要な人	実行量が多く、選択に時間をかけたくない人

この表をざっくり読むと、Zenは市場価格の全カタログ、Goは天井付きの安価なサブセット、ということになる。両者は競合ではなく補完関係にある。

10ドルに実際に収まるもの

ここが多くのレビューが物足りなくなるポイントだ。「10ドルで18モデル」という見出しを繰り返すばかりで、実際に何ができるかを決める仕組みを説明していない。

Goが渡してくるのはトークンではない。ドル建ての予算であり、それは選んだモデルの価格が示す速度で消費されていく。財布は同時に3つある。5時間ごとに12ドル、週に30ドル、月に60ドルだ。5時間枠は暴走セッションに対するファイアウォールであり、週枠は月の使い分を3日で使い切ってしまうことを防ぎ、月枠が本当の天井になる。

しかし、ほとんど誰も言及しない、実は最も重要な第2のレイヤーがある。すべてのモデルが同じ予算を割り当てられているわけではないということだ。公式ドキュメントにはモデルごとの「usage」列が公開されており、そこを見ると、あるモデルには60ドル分の利用枠が含まれ、別のモデルにはわずか15ドル分しか含まれていないことが分かる。チームの説明は正直だ。ほとんどのモデルではボリュームディスカウントと専有GPUキャパシティを確保できたため、その節約分を6倍の倍率として還元しているという。そうできなかったモデル——非常に新しいか、公開価格がすでに割引済みのもの——は倍率が1.5倍にとどまる。

これによりGoのカタログは2つのリーグに分かれる。

60ドルリーグ(倍率6倍): GLM-5.2、GLM-5.1、Kimi K2.7 Code、Kimi K2.6、MiMo-V2.5、MiniMax M3、MiniMax M2.7、Qwen3.7 Max、Qwen3.7 Plus、Qwen3.6 Plus、DeepSeek V4 Flash、Hy3。

15ドルリーグ(倍率1.5倍): Grok 4.5、GPT 5.6 Luna、Kimi K3、MiMo-V2.5-Pro、Qwen3.8 Max、DeepSeek V4 Pro。

OpenCodeが公開している実際の利用パターンの推計に基づき、これを実際のリクエスト数に換算すると次のようになる。

モデル	リクエスト数/5時間	リクエスト数/週	リクエスト数/月	リーグ
DeepSeek V4 Flash	31,650	79,050	158,150	60
MiMo-V2.5	30,100	75,200	150,400	60
Qwen3.7 Plus	4,300	10,800	21,600	60
Hy3	4,300	10,750	21,500	60
MiniMax M2.7	3,400	8,500	17,000	60
DeepSeek V4 Pro	3,450	8,550	17,150	15
Qwen3.6 Plus	3,300	8,200	16,300	60
MiMo-V2.5-Pro	3,250	8,150	16,300	15
MiniMax M3	3,200	8,000	16,000	60
Kimi K2.7 Code	1,350	3,380	6,750	60
Kimi K2.6	1,150	2,880	5,750	60
GLM-5.2 / GLM-5.1	880	2,150	4,300	60
Qwen3.7 Max	340	840	1,690	60
GPT 5.6 Luna	2,050	5,100	10,250	15
Qwen3.8 Max	160	400	810	15
Grok 4.5	120	300	600	15
Kimi K3	110	250	490	15

この差を見てほしい。DeepSeek V4 Flashは月に158,000リクエスト使えるのに対し、Kimi K3はわずか490だ。同じ月10ドルのプラン内で、安いほうと高いほうの間に320倍の差があるということになる。Goを「常に一番良いモデルを選ぶビュッフェ」のように使う人は、初日で5時間の上限に激突するだろう。

そして、この大きな数字は正しい物差しで捉える必要がある。「このエンドポイントにJWT認証を追加し、テストを書いて、ドキュメントを更新して」という本物のエージェントタスクは、1リクエストでは済まない。30〜150ターンかかる。ファイルを読み、差分を提案し、テストを走らせ、失敗を確認し、修正し、また走らせる、という具合だ。この物差しで測ると、GLM-5.2の月4,300リクエストは、中規模タスクにしておよそ月30〜100件分に相当する。個人開発者や個人プロジェクトにとっては余裕がある量だ。しかし4人チームが1つのアカウントを共有するには足りない——そもそもそれは許可されておらず、ワークスペースにつき契約できるのは1人だけだ。

Zenの部分や戦略の話を抜きにして、Goの価格と利用上限だけに絞ったレビューが読みたいなら、それに特化した記事を書いている。OpenCode Go:価格、利用上限、そして2026年に検討する価値はあるか。

エージェント1ターンあたりの実際のコスト、視点を整えるために

ここで提案する戦略がなぜ機能するのかを理解するには、各モデルで典型的なエージェント1ターンにいくらかかるかを計算してみるとよい。現実的で一定のプロファイル——新規入力トークン約800、キャッシュから読み込むトークン60,000(リポジトリのコンテキストであり、コストの大半を占める部分)、出力トークン250——を使い、Zenの公開価格を適用すると次のようになる。

モデル	ターンあたりの推定コスト	$1あたりのターン数
GPT 5.6 Luna	$0.00166	約600
DeepSeek V4 Flash	$0.00186	約540
MiniMax M3	$0.0041	約240
Kimi K2.7 Code	$0.0132	約76
Claude Sonnet 5	$0.0161	約62
GLM-5.2	$0.0178	約56
Grok 4.5	$0.0211	約47
Claude Opus 5	$0.0403	約25
GPT 5.6 Sol	$0.0415	約24
Claude Fable 5	$0.0805	約12

上記のプロファイルとZenのドキュメントに公開されている価格に基づく独自試算(Go内では、これらの一部モデルはさらに安く提供されている)。実際の消費量はリポジトリのサイズやキャッシュの活用度によって変わる。

一目瞭然なのは、フロンティアモデルと「働き手」モデルの差が30%や2倍程度ではないということだ。Claude Fable 5は同じ1ターンでGPT 5.6 LunaやDeepSeek V4 Flashの40倍以上のコストがかかり、Goプラン内ではその差はさらに広がる。ここで気まずい問いが浮かぶ。「ファイルを読み、差分を適用し、テストを走らせる」という150ターンに、本当に世界最高のモデルが必要なのだろうか。

ほとんどの場合、必要ない。世界最高のモデルが本当に必要なのは、「何を、どう作るか」を決める工程だ。そしてその決断にかかるのは5〜10ターンであって、150ターンではない。

私の提案:設計と実行を分離する

この記事の核心はここにある。試行錯誤を重ねた末の私のワークフローはこうだ。スペックはClaudeかGrokで設計し、その実行はOpenCode Goで行う。

私個人は主にClaudeを使う——アーキテクチャに関わる決断ならOpus 5、もっと日常的なスペックならSonnet 5——そして、違う視点でのセカンドオピニオンが欲しいときや、モデルに歯に衣着せぬ直接的な回答をしてほしいときはGrokを使う。この段階に関してはCodexも同様によく機能する。それが普段使っているツールであれば構わない。重要なのはブランドではなく、その「役割」だ。

この論理は、まともなアジャイル手法ならどこでも適用しているものと同じだ。リファインメントと実行は別の活動であり、コストもリスクプロファイルも異なる。アーキテクトに単体テストを書かせる人はいないし、ジュニアにデータモデルを決めさせる人もいない。この2つを1つのフロンティアモデルとの1本の会話に混ぜ込むと、実行作業に対してアーキテクト価格を何時間も払い続けることになる。

なぜこれが技術的にうまくいくのか

実行担当のモデルに創造性は要らない。必要なのは従順さと能力だ。スペックが良ければ——どのファイルを触るか、どんな契約を満たすか、どんなエッジケースをカバーするか、成功をどう検証するかが書かれていれば——そのタスクは「これを設計せよ」ではなく「これをコードに書き起こし、検証せよ」に変わる。GLM-5.2やKimi K2.7 Codeのようなモデルは、これを完璧にこなせる。

一方でスペックが悪いと、実行担当のモデルは即興を始めてしまう。そしてそこで人々は「オープンモデルは使い物にならない」と結論づける。実際は使い物にならないのではなく、2つの仕事を頼んでおいて1つ分しか払っていないだけなのだ。

具体的なワークフロー、ステップごとに

1. ClaudeまたはGrokとの設計会話。 まだコードは書かない。問題、ビジネス上のコンテキスト、制約を説明する。提案の前に質問してくれるよう明示的に頼むこと。ここで高価なモデルの5〜15ターンを使うが、これがプロセス全体の中で最も投資効率の良いターンになる。

2. スペックをファイルとして生成する。 markdownでの出力を依頼し、最低限次の構成にする。目的、コンテキスト(現状何が存在するか)、明示的なスコープ、明示的なスコープ外、触るファイル、契約とインターフェース、エッジケース、検証可能な受け入れ基準、検証計画。これをリポジトリに保存する。例えばspecs/2026-08-12-auth-jwt.mdのように。gitで管理することが重要なポイントの一部であり、それはドキュメントであり、トレーサビリティでもある。

3. アトミックなタスクに分割する。 スペックの各タスクは、エージェントが曖昧さなく完了・検証できるものにする。あるタスクの途中でプロダクトの意思決定が必要になるなら、それはまだ実行の準備ができていない。ステップ1に戻ろう。

4. OpenCode Goで実行する。 リポジトリでOpenCodeを開き、スペックを指定し、働き手モデルに作業させる。私のデフォルトの割り当ては、主実装にはGLM-5.2かKimi K2.7 Code、機械的な作業(リネーム、構文の移行、繰り返しテストの生成、importの更新)にはMiniMax M3かDeepSeek V4 Flashだ。

5. 必要な場合のみ、高価なモデルでレビューする。 テストが通り、差分が読みやすければ不要だ。何か違和感があれば、その具体的な疑問点を添えて差分をClaudeかGrokに渡す。それは3ターンであって、30ターンではない。

実行可能なスペックの例

# Spec: 検索用パブリックエンドポイントのレート制限

## 目的
現在無防備なエンドポイント `GET /api/search` の悪用を防ぐ。

## コンテキスト
- Express 4 + Redis はすでに `src/lib/redis.ts` で利用可能
- 認証ミドルウェアは `src/middleware/auth.ts`(模倣すべきパターン)
- ミドルウェアのテストはまだ存在しない

## スコープ
- ルートごとに設定可能な再利用可能ミドルウェア `rateLimit`
- `GET /api/search` にのみ適用
- Redis上でのスライディングウィンドウ、IPごとに60秒間60リクエスト
- `Retry-After` ヘッダー付きで429を返す

## スコープ外
- 認証済みユーザー単位のレート制限(フェーズ2)
- メトリクスダッシュボード
- 検索アルゴリズム自体の変更

## ファイル
- 新規作成: `src/middleware/rateLimit.ts`
- 新規作成: `src/middleware/__tests__/rateLimit.test.ts`
- 変更: `src/routes/search.ts`(ミドルウェアの追加のみ)

## 契約
```ts
rateLimit(opts: { windowMs: number; max: number; keyPrefix: string }): RequestHandler
```

## エッジケース
- Redisダウン時 → リクエストは通過させ、警告をログに記録(フェイルオープン)
- リクエストにIPがない場合 → `req.socket.remoteAddress` を使用し、それもなければ制限しない
- 時刻: クライアントのタイムスタンプではなく、サーバーの `Date.now()` を使う

## 受け入れ基準
- [ ] 60秒間に60リクエストは通過し、61件目は429を返す
- [ ] `Retry-After` ヘッダーにリセットまでの秒数が入っている
- [ ] Redisダウン時でもテストはグリーンのまま
- [ ] `npm test` と `npm run lint` がグリーン
- [ ] 「ファイル」欄に記載のないファイルが変更されていない

## 検証
`npm test -- rateLimit` と `npm run lint` を実行する。

このようなスペックであれば、GLM-5.2は涼しい顔で実行できる。おそらく25〜40ターンで完了するだろう。ターンあたり約0.014ドルのGo予算だとすると、月間割り当て60ドルのうち半ドル程度で済む。これなら月に100回以上こなせる。

必要性と複雑さに応じてAIを選ぶ

これは最もお金と苛立ちを節約できる習慣でありながら、実践している人が最も少ない習慣でもある。どんなチャットを開く前にも問うべき正しい問いは「どのモデルが一番良いか」ではなく、「これはどういう種類の作業か」だ。

私は4つのレベルで考えている。

レベル0 — 機械的作業。 変数のリネーム、フォーマットの変換、ボイラープレートの生成、設定ファイルの翻訳、すでに確立されたパターンからの反復的なテストの記述。決断は不要だ。存在する中で最も安いものを使う。DeepSeek V4 Flash、MiMo-V2.5、GPT 5.6 Lunaなど。結果が間違っていてもすぐに分かるし、やり直しのコストもほぼゼロだ。

レベル1 — ガイド付き実装。 明確なスペックがあり、それをコンパイルが通り、テストに合格し、プロジェクトの規約に従うコードに変換する必要がある。実力は必要だがプロダクト判断は不要だ。ここにGLM-5.2、Kimi K2.7 Code、MiniMax M3、Qwen3.7 Plusが位置する。プログラミングの実作業の70%はここに当たり、まさにGoの得意領域だ。

レベル2 — 限定された設計判断。 何かを決めなければならないが、既知の枠組みの中でだ。このテーブルをどうモデリングするか、このケースにどのパターンを使うか、このモジュールをどう構造化するか。ここでハードルが上がる。Grok 4.5、Claude Sonnet 5、GPT 5.6 Terraなど。ターン数自体は少ないので、単価が高くても請求額への影響は思ったより小さい。

レベル3 — 結果を左右する決断。 アーキテクチャ、移行戦略、技術選定、複雑なインシデントの分析など、間違えると数週間を失うような領域。迷わずフロンティアモデルを使う。Claude Opus 5、Claude Fable 5、GPT 5.6 Sol、Gemini 3.1 Proなど。ここではセカンドオピニオンという贅沢が役に立つ。異なるファミリーの2つのモデルに同じ質問をして比較するのだ。両者が一致すれば、それは妥当なシグナルになる。意見が分かれたときこそ、自分で考えるべきポイントを正確に見つけたことになる。

すべてをまとめる原則はこうだ。**高価なモデルが決め、安いモデルが実行する。**そして同じくらい重要な系がある。もし同じタスクの80ターン目でフロンティアモデルを使っている自分に気づいたら、それは設計段階のどこかで何かがうまくいかなかった証拠だ。スペックに戻ろう。

ここで言及しておく価値のあるニュアンスがある。これは全体の哲学的な部分に触れる話だ。常に最高のモデルを使いたくなる誘惑は経済的なものではなく、心理的なものだ。そのほうが安心に感じられるからだ。しかしその安心感には実際のコストがかかっていて、それは請求書の金額だけではない。最も高性能なモデルにすべてを委ねてしまうと、重要な決断とそうでない決断を区別できなくなっていく。ツールを選ぶ前にタスクを分類することを自分に課すのは、結局のところ判断力を鍛える訓練だ。そして判断力こそが、外部委託できない唯一のものだ。

Goプランを使い倒すための実践的な10のコツ

1. デフォルトモデルを高価なものではなく働き手に設定する。 opencode.jsonで、メインモデルとして opencode-go/glm-5.2 や opencode-go/kimi-k2.7-code を設定しておく。上位モデルへの切り替えは意識的な行為であるべきで、デフォルトの状態であってはならない。

2. OpenCodeのエージェントシステムを使い、役割ごとにモデルを割り当てる。 OpenCodeでは、異なるモデルを持つ異なるエージェントを定義できる。読んで提案するだけの高性能モデルを持つ plan エージェントと、実行を担う安価なモデルを持つ build エージェントだ。これはこの記事のワークフローを自動化したものにほかならない。

3. リポジトリのルートに AGENTS.md を書く。 規約、テストコマンド、フォルダ構成、触ってはいけない箇所。そこに書いてあることは、働き手モデルが推測しなくて済むことであり、推測こそがターンを消費する原因だ。

4. キャッシュを活用する。 ターンあたりのコストの大部分はキャッシュの読み込みであり、新規トークンではない。同じコンテキストに対する長いセッションは、小さなタスクごとに新しいセッションを開くよりもターンあたりのコストがはるかに安い。関連する作業はまとめよう。

5. 月間上限ではなく5時間上限を注視する。 実際にあなたを噛みつく天井は、5時間ごとの12ドルのほうだ。集中セッションをするなら、まず安いモデルから始め、高いモデルは行き詰まったときのために温存しておく。

6. 「Use balance」はZenの残高があり、理由が分かっている場合にのみ有効にする。 これは非常ベルブだ。Goを使い切ると、ブロックされる代わりに従量課金の残高を消費し続けるようになる。締め切り前には非常に便利だが、有効にしたまま忘れると危険だ。

7. Goを使い切っても、Zenの無料モデルはそこにある。 無料期間中のモデルのリストがある(DeepSeek V4 Flash Free、MiMo-V2.5 Free、Hy3 Free、Nemotron、LongCatなど)。細かい注意点として、無料期間中はデータがモデル改善に使われる可能性がある。機密性の高いコードには使わないこと。

8. クライアントのコードを扱う前にプライバシーの表を確認する。 Goでは、ほとんどのモデルでデータ保持は0日間だが、Grok 4.5とGPT 5.6 Lunaは30日間保持する。NDA下のコードを扱っているなら、この項目はベンチマークよりも重要だ。

9. Goを使っていても、残高付きのZenを持っておく。 Goの10ドルにZenの残高20ドルを加えることで、両者の良いところを得られる。実質的に無制限の実行力と、判断が必要な場面でのフロンティアモデルへのピンポイントなアクセスだ。それでも、プレミアムサブスクリプション1つ分より安く済む。

10. 計測する。 OpenCodeのコンソールに利用状況が表示される。1カ月間、週に1回チェックしてみれば、支出の80%が2〜3種類のタスクから来ていることに気づくはずだ。それこそが安いモデルに移すべき、あるいは再利用可能なスペックとして自動化すべき対象だ。

このワークフローと相性の良い実践的なツール

OpenCode(opencode.ai)が基盤だ。TUI、CLI、サーバーモード、IDE統合、MCPおよびAgent Skillsのサポート。インストールはワンライナーで、macOS、Linux、WSL経由のWindowsで動作する。

TUI内の /connect コマンドが、GoやZenを接続する方法だ。opencode.ai/auth のコンソールからコピーしたAPIキーを求められ、/models で利用可能なカタログを確認できる。設定上、IDはプロバイダーのプレフィックスを持つ。Go向けなら opencode-go/kimi-k3、Zen向けなら opencode/gpt-5.6-sol といった具合だ。

Claude Code、Codex CLI、あるいはGrokは設計フェーズに使う。どれを使っても構わない。重要なのは、スペックについての会話が実行の場とは別の場所で行われることだ。それだけでもコンテキストが混ざらずに済む。

gitでバージョン管理された specs/ ディレクトリ。 ささやかなことに聞こえるが、この方法の価値の半分はここにある。スペックは蓄積され、再利用され、テンプレート化されていく。そして——ここが良いところだが——後から入ってくる人やエージェントにとって最良のオンボーディング資料になる。

MCPサーバーは、エージェントに実際のコンテキストを与えるために使う。データベース、タスク管理ツール、ドキュメントへのアクセスなどだ。コンテキストを持つエージェントは必要なターン数が少なくて済み、ターン数が少ないということは消費する予算も少ないということだ。

Goの直接エンドポイントは、その上に何かを構築したい場合に使える。https://opencode.ai/zen/go/v1/chat/completions はOpenAIのSDKと互換性があり、一部のモデルは /v1/messages でAnthropic形式のフォーマットも公開している。TUIからだけでなく、自分のスクリプトからGoのサブスクリプションを使うこともできる。

Goが答えにならないとき

正直に言えば、私が推奨しない3つのシナリオがある。

作業の大部分がレベル3——アーキテクチャコンサルティング、リサーチ、分析——なら、Goはほとんど役に立たない。価値はGoに含まれていないモデルにあるからだ。素直にZenを従量課金で使おう。

チームで使うなら、Goはスケールしない。ワークスペースにつき契約できるのは1人だけだ。チームの場合は、メンバーごとの支出上限と役割に応じたモデルの有効化ができるZenのワークスペースが正しい道だ。

そして、コードが厳格に機密扱いであるなら、モデルごとのデータ保持の表を確認し、すでに契約関係のあるプロバイダーとのBYOKを検討しよう。10ドルは安いが、その会話を省略していいほど安くはない。

締めくくり

このワークフローを数カ月続けてたどり着いた結論は、OpenCodeについてのものではない。AIへの支出全般をどう考えるかについてのものだ。私たちは相変わらずツールを買い続けているが、本当に設計すべきなのはプロセスのほうなのだ。

明確な指示さえあれば、月10ドルはかなりのことができる。逆に、思考の代替として使うなら、ほとんど何もできない。Goプランはそれ単体であなたを生産的にしてくれるわけではない。その利用上限という設計によって、何が高価なモデルに値し、何がそうでないかを決めることを強制してくる。そして、一見制約のように見えるその規律こそが、結果的に仕事の質を高めてくれる。

払える範囲で一番良いモデルでスペックを設計する。タスクをこなせる範囲で一番安いモデルで実行する。スペックはgitに保存する。これを繰り返す。

🎁 無料の$5クレジットで始める フルプランに課金する前に、このリンクからOpenCode Goに登録すると、利用上限に直接充当される$5クレジットが手に入る。月額課金にコミットする前に、この記事のワークフローが自分の働き方に合うかどうかを試す、最も安上がりな方法だ。

よくある質問

OpenCode GoはClaude CodeやCodexの代わりになりますか

いいえ、そうあるべきでもありません。Goはオープンモデルを使った実行専用のプランです。Claude CodeやCodexは、設計フェーズや判断力を要するタスクにおいて依然として優れています。この記事の提案は、どちらかを選ぶのではなく、両方を組み合わせて使うことです。

GoとZenを同時に使えますか

はい、それが私のおすすめです。Goは定額予算で実行をカバーし、Zenはフロンティアモデルへのピンポイントなアクセスを提供します。さらに「Use balance」オプションを有効にすれば、Goの上限を使い切ったときにブロックされる代わりにZenの残高に切り替わります。

月10ドルのプランには実際どれくらいのタスクが収まりますか

モデル次第です。GLM-5.2(月4,300リクエスト)と、30〜150ターンのタスクを基準にすると、月におよそ30〜100件の中規模タスクに相当します。DeepSeek V4 Flashなら、個人利用ではほぼ無制限と言えるでしょう。

なぜGrok 4.5はGoで月に600リクエストしか使えないのですか

すべてのモデルに同じ予算が割り当てられているわけではないからです。ほとんどのモデルには60ドル分の利用枠(倍率6倍)が含まれていますが、Grok 4.5、Kimi K3、GPT 5.6 Luna、Qwen3.8 Max、DeepSeek V4 Pro、MiMo-V2.5-Proなど一部のモデルには15ドル分(倍率1.5倍)しか含まれていません。これはチームがまだこれらのモデルについて割引交渉をまとめられていないためです。

上限を使い切ったらどうなりますか

カタログ内の無料モデルを引き続き使うことも、「Use balance」を有効にしてZenの残高を消費することもできます。あるいは5時間のウィンドウがリセットされるのを待つこともできます。

OpenCode Goはチームでの利用に向いていますか

直接的には向いていません。ワークスペースにつき契約できるのは1人だけです。チームの場合は、ロール、メンバーごとの支出上限、有効化するモデルの制御ができるZenのワークスペースが道になります。

自分のデータは学習に使われますか

Goのモデルでは使われません。ほぼすべてのモデルでデータ保持は0日間で、例外はGrok 4.5とGPT 5.6 Lunaの30日間です(プロバイダー側の不正利用対策ポリシーによるもの)。異なるのはZenの無料期間中のモデルのケースで、こちらはデータがモデル改善に使われることがあります。

あわせて読みたい

Zenの部分やスペック戦略の話を抜きにして、OpenCode Goの価格、利用上限、そして単体で使ってみた私の経験だけを知りたい方は、OpenCode Go:価格、利用上限、そして2026年に検討する価値はあるかをどうぞ。

OpenCodeにとどまらず、コーディング向けAIプロバイダー全体の展望に関心があるなら、2026年にもう1つのAIプロバイダーだけに依存すべきでない理由もあわせてどうぞ。

出典

• OpenCode Go — 公式ドキュメント
• OpenCode Zen — 公式ドキュメント
• OpenCode Go — プロダクトページ
• OpenCode Zen — プロダクトページ
• OpenCode — 総合ドキュメント

価格、モデル、利用上限は2026年8月12日時点で確認済み。OpenCodeのカタログは頻繁に変更されるため、購入の判断をする前に公式ドキュメントを確認してほしい。