AIを開発に使うとき、最初に考えるべきなのは「どのモデルが一番賢いか」だけではありません。

もっと重要なのは、誰が判断し、誰が手を動かし、どこで検証するかです。

この記事では、Claude／Codexを「上司」、CLIを「指示系統」、OpenCode Goを「部下AI」として置く考え方を整理します。これは人間の役割をAIに置き換える話ではなく、作業を分けて、コストと管理の摩擦を下げるための設計です。

先に結論
OpenCode Goの価値は「最強AIを月$10で無制限に使えること」ではありません。一つの入口から複数のコーディングモデルを使い分け、実装担当を増やしやすくすることです。価格は初月$5、その後$10/月。使用上限があり、Claude／Codexなど上司役AIの契約費用は別です。

いまのAI開発は、全員を「上司」にしがち

高性能なAIチャットを複数契約し、同じ依頼を何度も投げる。これでも作業は進みます。

ただし、設計、実装、検証、修正のすべてを一つの高額AIに任せると、次の問題が出ます。

• どの契約で何を実行したかが散らばる
• 依頼のたびに文脈を渡し直す
• 高度な判断が不要な実装・反復にも、上位モデルを使い続ける
• AIの出力を比較するための役割分担がない

ここで言う「上司」とは、コードを一行も書かない存在ではありません。仕様を詰め、優先順位を決め、危険な変更を止め、実装結果を採点する役です。

そして「部下AI」は、決められたタスクをCLI経由で実装・検証・修正する役です。

流れにすると次のようになります。

人間（目的・制約を決める） → 上司AI（Claude／Codex、計画・レビュー） → CLI（タスクを渡す） → 部下AI（OpenCode Go、実装・検証） → 上司AIへ戻す → 人間へ報告

この形にすると、人間は「何を作るか」「どこまで変えてよいか」「できたと言える条件は何か」に集中できます。

従来の構成と、役割を分ける構成

AIツールの契約数を減らすこと自体が目的ではありません。目的は、判断にお金を使い、反復の担当を整えることです。

観点	従来の構成	上司＋部下AIの構成
指揮役	複数の高額AIを用途ごとに行き来	Claude／Codexを中心に計画・レビュー
実行役	個別契約のAIやAPIを都度切替	OpenCode Go経由で複数モデルを使い分け
依頼経路	チャット、IDE、Web画面に分散	CLIを共通の指示窓口にする
管理対象	契約、APIキー、文脈、切替手順	上司AIの判断と部下AIの実行を分離

もちろん、ClaudeやCodexだけで作業が完結するなら、無理に構成を増やす必要はありません。

この設計が効くのは、次のような反復が多いときです。

• 小さなUI修正を複数回回す
• テスト追加・実行・失敗箇所の修正を繰り返す
• 同じ要件を複数の実装案で試す
• 既存コードベースの調査と変更を分けたい

判断基準
「上司AIが1回で決めた方が安い仕事」と「実装回数が多いので部下AIに回す仕事」を、まず分けます。モデル名ではなく、再試行回数とレビューの重要度で考えるのが実用的です。

月$10は、何に対する料金なのか

OpenCode Goの公式価格は、初月$5、以後$10/月です。ただしこれはOpenCode Go単体のサブスクリプションであり、Claude／Codexなどを上司として併用する場合の料金は含みません。

さらに、Goには使用上限があります。公式ドキュメントでは、利用上限をリクエスト回数ではなくドル換算で示しています。

期間	Goの公式上限
5時間	$12相当
1週間	$30相当
1か月	$60相当

高コストのモデルほど同じ枠で実行できる回数は少なく、低コストのモデルほど回数は増えます。上限に達した後も無料モデルを利用でき、Zen残高があれば残高へフォールバックする設定も可能です。

だから「一般構成は月$30〜$200、こちらは+$10」と単純に置き換えるのではなく、次の式で考えるのが正確です。

月額の目安 ＝ 上司AIの契約費用 ＋ OpenCode Go $10 ＋ 必要なら追加API／残高

誤解しないために
「月$10」は固定費の入口であり、無制限利用の宣言ではありません。モデル一覧・上限・プライバシー条件は変更され得るため、契約前に必ず公式仕様を確認してください。

上司 → CLI → 部下AI：実際の流れ

この構成の要は、上司AIに「実装して」とだけ頼まないことです。先に判断を終え、部下AIには終わりのある仕事を渡します。

1. 上司AIに、指示を決めさせる

Claude／Codexには、目的、対象ファイル、変更しない範囲、受け入れ条件を固めてもらいます。

例：

目的：LPの申込導線を改善する
変更範囲：heroセクションとCTA周辺のみ
守ること：既存の配色・レスポンシブ挙動・計測イベントを壊さない
完了条件：モバイル表示でCTAが見切れず、既存テストが通る

この段階では、上司AIの役割は「曖昧な依頼を、検証できるタスクにすること」です。

2. CLIで、部下AIに渡す

OpenCodeでは、Goをプロバイダーとして接続し、モデルを選んで実行できます。公式手順は、ZenでGoを購読してAPIキーを取得し、TUIで/connectからOpenCode Goを選択、/modelsで利用可能モデルを確認する流れです。

部下AIには、上司AIが作った指示をそのまま渡します。依頼を小さくすると、差分・ログ・テスト結果をレビューしやすくなります。

3. 実装・検証の結果を、上司AIが読む

部下AIの出力を採用する前に、上司AIへ戻します。

• 変更差分は目的に合っているか
• テスト／ビルドは通っているか
• 想定外に広い変更をしていないか
• 次に直すべき点は何か

このループを回せば、部下AIを「正解を出す箱」ではなく、検証可能な作業を速く進める担当として扱えます。

OpenCode Goを選ぶ理由は、モデルを固定しないこと

OpenCode Goは、公式がテスト・推奨する複数のコーディング向けモデルへのアクセスを提供します。モデル一覧は更新されるため、この記事では個々のモデルの優劣を固定しません。

重要なのは、仕事の種類でモデルを変えられることです。

• 軽い修正・テスト反復：低コストモデルを優先
• 難しい設計やレビュー：上司AI、またはより強いモデルを選ぶ
• 長いコードベースの調査：文脈長・ツール利用に合うモデルで試す
• 機密性の高い作業：モデル別の保持・学習条件を確認し、必要なら別プロバイダー／ローカル実行を選ぶ

OpenCode GoはOpenCodeに必須ではありません。OpenCodeは他のプロバイダーも使えるため、Goを「唯一の入口」にするのではなく、選択肢を一つ増やす位置づけが健全です。

Kimi・Z.ai・DeepSeekと比べるときの軸

比較で大切なのは、月額だけで勝敗を決めないことです。サービスごとに、チャット中心か、開発エージェント中心か、定額か従量か、モデルを自分で選ぶかが違います。

選択肢	主な考え方	向いている場面
OpenCode Go	OpenCode向けに検証された複数モデルを、月額＋使用枠で使い分ける	CLI中心で、実装担当の選択肢を増やしたい
Kimi	個別チャット／開発プランを中心に使う	特定サービスの操作感とモデルを軸に進めたい
Z.ai	GLM系の開発プランを中心に使う	GLM系を主力に試したい
DeepSeek API	従量課金で利用量を細かく調整する	月額固定より、API使用量で最適化したい

バナーの課金額はあくまで比較時点の目安です。プラン、地域、キャンペーン、モデル構成は変わるため、契約判断は各社の公式価格ページで確認してください。

向いている人・向いていない人

向いている人

• Claude／Codexで要件整理やレビューをしている
• CLIで開発タスクを渡すことに抵抗がない
• 一つのモデルに固定せず、実装作業で比較したい
• 個別APIの管理を増やしすぎたくない
• AIに任せる範囲を、テストや差分で確認できる

まだ向いていない人

• まずは一つのチャットAIで質問したいだけ
• CLIやプロジェクト単位の作業が不要
• 利用上限を気にせず、特定の上位モデルだけを長時間使いたい
• 機密コードの扱いについて、モデル別のデータ条件を確認できない

今日から試す最小構成

1. 上司役をClaudeまたはCodexのどちらか一つに決める
2. 小さな実装タスクを一つ選び、受け入れ条件を3行で書く
3. OpenCode Goを接続し、低コストモデルで実装・テストを一度回す
4. 差分とログを上司AIにレビューさせる
5. 完成度、修正回数、コスト感を記録する

いきなり「AI社員を何人も雇う」必要はありません。

まずは、上司が仕様を決め、部下が一つの小さな仕事を終え、結果を上司が確認する。この一周だけを体験すると、AIツールを増やす意味と、増やさない方がよい場面の両方が見えてきます。

この記事の要点
AIに仕事を丸投げするのではなく、判断・指示・実装・検証を分ける。OpenCode Goは、そのうち「実装担当」を増やすための、低価格だが上限のある選択肢です。

OpenCode Goを見てみる →