5秒で結論： 同じモデルを使っても、何を毎回コンテキストへ入れるか、何回モデルを呼ぶか、ツール結果をどれだけ抱えるか、どこで圧縮するかで消費量は大きく変わり得る。モデルがエンジンなら、CodexやOpenCodeのようなハーネスは変速機・燃料噴射・ナビ・整備士をまとめたものだ。同じエンジンでも燃費が同じとは限らない。
1. 「同じ5時間枠なのに倍走る」――まず、これはベンチマークではなく体験談
SNSで、ある開発者が「CodexからOpenCodeへ変え、同じGPT-5.6 SolをChatGPT認証で使ったところ、同じ5時間枠・週間枠でも倍以上仕事が進む感覚がある」と投稿した。
返信欄では、別のハーネスとしてpiを勧める声、コンテキスト上限設定の違いを疑う声、ルーターやテレメトリで実消費を見たいという声も出た。
ここで一番大事なのは、「OpenCodeなら公式に2倍使える」とは誰も証明していないことだ。これは有力な観察ではあるが、統制された比較試験ではない。
一方、OpenAIはCodexの使用量について、固定メッセージ数ではなく、モデル、タスクの実行場所、複雑さ、コンテキスト、推論、速度、ツールなどで変動すると説明している。プランによっては5時間枠と週間枠の両方がある。
つまり「ハーネスを変えたら燃費が変わった」という現象そのものは、仕組み上かなり自然である。
2. ハーネスとは何か――AI本体の外側にある「全部」
モデルだけを見ると話は単純だ。
Sol = 頭脳。
だが実際のコーディングエージェントは、その頭脳の周りに大量の設備を持つ。
- system instructionをどう組むか
- どのファイルを読むか
- 過去会話を何トークン残すか
- shellやGitHubなど何個のツールを見せるか
- tool outputをどこまで次のターンへ持ち越すか
- 失敗時に何回retryするか
- plan、implementation、reviewを何周するか
- context overflow前に圧縮するか
- subagentへ分けるか
- いつ「終わった」と判定するか
この一式が、広い意味でのハーネスである。
OpenAI自身もCodexについて「harness」という言葉を使い、モデルと各クライアント・ツール・会話状態をつなぐApp Serverを説明している。
だから、
モデルが同じ = システム全体が同じ
ではない。
同じV8エンジンを積んでも、2トンのSUVと軽い車体で燃費が同じにならないのと同じだ。
3. AIの燃費を壊す犯人は、だいたい「毎ターン持っていく荷物」
エージェントの消費量は、単に「返事を何文字書いたか」では決まらない。
長いセッションでは、毎回の推論に、
- 長い会話履歴
- 大きなsystem prompt
- AGENTS.mdやルール
- MCPのtool schema
- GitHubから読んだ大量のファイル
- shellの長大なログ
- test結果
- 過去の失敗
- 次のretry用情報
が乗る。
一回だけなら軽い。
問題は、これを10回、20回、30回と再送・再解釈することだ。
「ログを100KB読んだ」より、100KB級の文脈を抱えたまま何度もモデルを呼ぶ方が効くことがある。
さらに、ハーネスAが一つの作業を15ターンで終えるのに、ハーネスBがplan→確認→探索→再探索→review→再reviewで30ターン使えば、同じモデルでも当然差が出る。
燃費はエンジン性能だけではなく、
荷物 × 往復回数 × 再試行回数
で壊れる。
4. OpenCodeが面白い理由――ChatGPT認証、MCP、compactionが同じ箱にある
OpenCodeの公式ドキュメントでは、OpenAI接続時にChatGPT Plus/Proを選び、ブラウザで認証できる。APIキーを手入力する経路とは別に用意されている。
また、OpenCodeはMCPクライアントとしてローカルMCPとリモートMCPの両方を追加できる。
つまり、
OpenCode → GitHub MCP → データベースMCP → 自前API → その他の外部ツール
という構成が取れる。
さらにOpenCodeには自動compactionがあり、長いセッションの古いactive contextをcheckpointへ置き換える。現行ドキュメントでは自動compactionがデフォルトで有効で、生成された要約とおおむね直近15,000 tokenを残す構成例が示されている。
これは「古い会話を削除する」というより、
倉庫には履歴を残しつつ、次の出撃には必要な荷物だけ積む
という設計に近い。
ただし万能ではない。OpenCode自身が、MCPサーバーを増やすとtool schemaなどがcontextを消費し、特にGitHub MCPのような大きなMCPはコンテキストを圧迫しやすいと警告している。
MCPを20個つないで「これで最強！」とやると、勇者の装備欄に倉庫そのものを装備することになる。
5. ChatGPTからMCPで全部動かすのも、発想はほぼ同じ
ChatGPTを中央に置き、MCPや外部コネクタ経由でGitHub、サーバー、クラウド、ストレージなどを操作する構成も、本質的には「モデル＋ハーネス＋ツール」である。
配線図にすると単純だ。
ChatGPT → MCP / connector → GitHub・サーバー・クラウド・ストレージ
ChatGPTが判断し、MCPが手足になり、各サービスが実世界側の状態を持つ。
これはOpenCodeでも同じだ。
OpenCode → MCP / shell / API → repository・server・cloud
違いは、どこに会話状態を持たせ、どこでtool loopを回し、どこでcontextを圧縮するかである。
だから「ChatGPTからMCPで全部動かしているのと一緒か？」への答えは、かなりYES。
同じ建築思想で、司令室の製品名が違う。
6. ではChatGPTからOpenCodeへ仕事を投げられるのか
OpenCodeは公式に「MCPを使う側」をサポートしている。一方、引用した公式ドキュメントではOpenCode自体をそのまま汎用MCPサーバーとして公開するモードより、HTTP/OpenAPIサーバーとSDK、またはACPの入口が明示されている。
opencode serveを使うと、OpenCodeをヘッドレスHTTPサーバーとして起動し、OpenAPI経由でセッションやエージェントをプログラム制御できる。JS/TS SDKもある。
したがって、ChatGPT側からOpenCodeへ仕事を投げたいなら、きれいな構成はこうなる。
ChatGPT → 薄いMCPブリッジ → OpenCode Server → Sol → MCP / shell / API → GitHub・クラウド等
MCPブリッジが公開する道具は、極端に少なくていい。
- opencode_run_task
- opencode_get_status
- opencode_get_result
くらいでよい。
ChatGPT側へGitHubの何十個ものtool schemaや巨大ログを毎回持ち込まず、OpenCode側で長い実作業を完結させ、最後の結果だけ返す。
ここで初めて「燃費改善」が設計になる。
7. 消費量を本気で減らすなら、AIを減らすより「AIへ戻す回数」を減らす
一番ありがちな失敗は、安いモデルへ変えれば全部解決すると思うことだ。
もちろんモデル選択は効く。
しかし長時間の自動作業では、それ以上に、
- 決定論的な処理はscriptへ出す
- stateとreceiptを機械側に持つ
- toolを必要なものだけ有効化する
- 長大ログは要約・抽出してからモデルへ渡す
- 同じファイルを何度も読み直さない
- 失敗理由とnext actionを状態として保存する
- 曖昧な判断だけ高性能モデルへ戻す
- 最終的なproduction readbackだけ人間側へ返す
という分離が効く。
理想形は、
AI = 曖昧さを処理する担当
script / workflow = 確定した手順を回す担当
GitHub / DB / state = 記憶する担当
である。
AIに「次なにするんだっけ？」を毎回考えさせると、そのたびに倉庫の棚卸しが始まる。
機械にnextActionを書かせておけば、AIは必要なときだけ呼べる。
8. ただし「OpenCodeなら同じ枠で必ず得」はまだ言えない
OpenAI公式に確認できるのは、CodexとWorkが共有利用枠を使い、プランによって5時間枠・週間枠があり、使用量がコンテキストやツールなどで変動すること。
OpenCode公式に確認できるのは、ChatGPT Plus/Pro認証を使えること。
しかし、OpenCode経由のChatGPT OAuth利用がOpenAI側でCodexとまったく同じ計量式・同じ内部係数で消費されるか、またOpenCodeなら常に何倍得か、という比較表は両者の公式資料にはない。
したがって、
「倍走った」は面白い実測報告。
「必ず倍走る」は未確認。
ここを混ぜない方がいい。
本当に比較するなら、同じrepo、同じモデル、同じ作業、同じ終了条件で、
- 総モデル呼び出し回数
- input/output token
- compaction回数
- tool call回数
- wall-clock time
- 完了した変更数
- 再試行回数
- 最終テスト結果
を取る。
「何時間使えた」ではなく、1成功タスクあたり何を消費したかを見る。
それが本当の燃費である。
9. 結論――AI時代、モデル選びの次に効くのは「配線」
以前は「どのモデルが一番賢いか」が中心だった。
エージェント時代は、それだけでは足りない。
同じモデルでも、
- コンテキストの詰め方
- ツールの数
- 状態管理
- 圧縮
- retry
- 終了判定
- 外部workflowとの分担
で、仕事量が変わる。
モデルはエンジン。
ハーネスは、燃料噴射、変速機、ナビ、ピットクルー、トランク容量まで全部まとめたシステム。
だから「同じSolなのになんでこんなに違うんだ」は、むしろ自然な疑問である。
そしてMCPで複数サービスをつなぎ始めた瞬間、自分がやっていることは「AIを使う」から、
AIの周りに仕事場を設計する
へ変わっている。
最後に一番身も蓋もない話をすると、最強のMCPは「何でもAIに聞く」ことではない。
AIに聞かなくていい工程を増やすことである。
参考資料
- OpenAI, Unlocking the Codex harness: how we built the App Server https://openai.com/index/unlocking-the-codex-harness/
- OpenAI Help Center, ChatGPTプランでCodexを使う https://help.openai.com/ja-jp/articles/11369540
- OpenAI Help Center, WorkとCodexでのGPT-6 Astraの利用量管理 https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex
- OpenCode Docs, Providers https://opencode.ai/docs/providers
- OpenCode Docs, MCP servers https://opencode.ai/v2/docs/mcp-servers
- OpenCode Docs, Compaction https://opencode.ai/v2/docs/compaction
- OpenCode Docs, Server / SDK https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/
- OpenCode Docs, ACP https://opencode.ai/v2/docs/cli/acp/
