GitHub Copilot CLI ユーザーが ForgeCode を試してみた：TerminalBench 上位の『コーディングハーネス』は何が違うのか

📌 追記（2026-04-07） 本記事公開後にPremiumRequestの消費量を確認したところ、4/7 時点では 3 つほどのタスクを振っただけで 41 Premium Request を消費した。性能は間違いないものだと感じたが、少なくとも現時点ではGithubCopilotのモデルでは使用せず、OpenCodeZenなどの無料モデルの性能向上用として使用するほうが良さそうだ。

「ハーネス」って何？ 最初は自分もわからなかった

AI コーディングツールを調べていると、最近よく「コーディングハーネス」という言葉が出てくる。

最初は「ハーネス？ 安全帯？」と思ったのだけど、ここでいう Harness はそういう意味ではなく、AI が実際に手を動かすための実行基盤みたいなものらしい。

もう少し雑にいうと、こんな違いがある。

• 普通のチャット型 AI：解決策を文章で返すのが中心
• コーディングハーネス：ファイルを読んで、編集して、コマンドを実行して、必要ならテストや再試行まで回す

つまりハーネスは、単に「賢い回答を返す仕組み」ではなくて、AI がターミナルやコードベースの中で仕事を完走するための土台だと思うとわかりやすい。

この意味では、GitHub Copilot CLI も ForgeCode も同じカテゴリに入る。どちらもターミナルから使えて、プロジェクトを読んで、必要な操作を進めていくからだ。

なので今回の話は「ForgeCode vs 補完 AI」ではなく、どちらかというと 『ターミナルで動くエージェント同士の違い』 を見る話になる。

TerminalBench は何を見ているベンチマークなのか

ForgeCode の名前を知ったきっかけは、TerminalBench のリーダーボードだった。

このベンチマークが面白いのは、ただコードを 1 つ生成して終わりではなく、本物の Linux ターミナル環境でタスクを最後までこなせるかを見ているところ。

例えば公開ページには、こんな系統の課題が並ぶ。

• ビルドや実行環境を整えて完走する
• サーバーやツールを立ち上げて検証する
• 鍵生成や署名検証のような手順を通す
• Web アプリやライブラリの不具合を修正してテストまで通す

要するに「コードを書けるか」よりも、ターミナルで実務っぽいタスクをやり切れるかを測っている感じ。

2026-03-12 時点の上位はこんな感じ

同じ 81.8% でも、公開リーダーボード上の順位表記は GPT-5.4 構成が 1 位、Claude Opus 4.6 構成が 2 位になっていた。

ここで気になったのが、Claude Opus 4.6 を使った ForgeCode が 81.8% なのに、Claude Code は 58.0% だったこと。

同じモデルでも結果がかなり違う。つまり、モデルの性能だけではなく、そのモデルをどう使うか＝ハーネス側の設計 がかなり効いていそうだと感じた。

ちなみに、この記事を書いている時点では GitHub Copilot CLI の公式スコアは TerminalBench に掲載されていなかった。なので Copilot CLI を数値で横比較するより、設計思想や使い勝手の違いを見るほうが自然そうだった。

Reddit で見かけた「Copilot の利用枠を食いやすい」話

ForgeCode を試してみようと思ったきっかけの 1 つが、Reddit で見かけた「ForgeCode を GitHub Copilot 経由で使うと、プレミアム系の利用枠が速く減る」という話だった。

この件は、いま読むと ForgeCode 自体が無駄に大量消費していた というより、GitHub Copilot 向けの最適化ヘッダーが不足していて、リクエストの分類がうまくいっていなかった ことがポイントだったようだ。

2026-04-03 にマージされた PR #2813 のタイトルは、fix: add GitHub Copilot optimization headers for billing. になっている。説明文には次のヘッダー追加が書かれていた。

• x-initiator
• Openai-Intent
• Copilot-Vision-Request
• anthropic-beta

PR の説明では、これらは GitHub Copilot のリクエスト使用量の最適化や課金分類の精度向上 のために入れたとされていた。

なので現時点では、

「ForgeCode を使うと Copilot の利用枠が異常に減るらしい」

という話は、少なくともそのまま鵜呑みにしないほうがよさそう。試すなら、最新バージョン前提で見るのが安全だと思う。

実際のセットアップはかなり素直だった

公式ドキュメントを見ながら入れてみた。

前提条件

• Zsh が入っていること
• Nerd Font をターミナルに設定していること

Nerd Font は見た目用の要素が大きいけど、公式ドキュメントでも前提に入っている。

1. インストール

curl -fsSL https://forgecode.dev/cli | sh

インストール後は確認のためにこれも叩ける。

forge --help

2. Zsh プラグイン設定

forge zsh setup

セットアップが終わったら、ターミナル再起動か exec zsh が必要。

exec zsh

もし : が反応しないなら、公式にはこれも案内されていた。

forge zsh doctor

3. プロバイダーへログイン

:login

ここ、最初ちょっとハマりそうだと思ったのが記法。

• コマンド は :login のように スペースなし
• 普通のプロンプト は : のあとに スペースあり

たとえば通常の会話ならこう。

: このリポジトリの構成をざっくり教えて

4. モデル選択

:model

OpenAI / Anthropic / OpenRouter などを選べる。OpenRouter を使うと、1 つのキーでいろいろなモデルを切り替えられるので楽そうだった。

5. 最初の 1 回を送る

: Hi! What is the time?

公式ドキュメントの流れもかなり単純で、CLI を入れる → Zsh 連携を有効にする → プロバイダー設定 → 使い始める の 4 ステップで理解できた。

触ってみた感想：たしかに「ターミナルに溶け込んでいる」

ForgeCode のいちばんわかりやすい特徴は、Zsh にかなり寄り添っている ことだと思った。

普段のシェルをそのまま使いながら、必要なときだけ : で AI に切り替える感じなので、「AI ツールを起動する」というより ターミナルの機能が 1 つ増えた 感覚に近い。

これは Copilot CLI と似ている部分もあるけど、ForgeCode のほうが Zsh プラグイン前提で日常操作に溶け込ませる設計 が強い印象だった。

あと、公式ドキュメントを読むと ForgeCode には次の役割分担がある。

• forge：実装・修正担当
• muse：計画・分析担当
• sage：調査担当（内部で使われる）

1 つのモデルに全部やらせるのではなく、調査・計画・実装を役割分担しやすい のが特徴らしい。

手元で軽く試した範囲では、こういう用途が向いていた

ここからはベンチマークではなく、あくまで自分の手元で触った感想メモ。

1. 小さめのバグ修正

たとえば Python の KeyError みたいな、原因がある程度見えている不具合。

: この関数の KeyError を修正してください

こういうのは素直に強かった。ファイルを読んで、直して、確認まで進める流れが自然。

2. 大きめのリポジトリの調査

: JWT の検証を担当しているファイルと関数を教えてください

大きいコードベースの探索では、単にキーワード検索するというより、構造を見ながら整理して返してくれる感じ があった。公開ドキュメントでも調査用の sage を内部利用すると書かれていて、この系統が得意なのは納得感がある。

3. ビルドエラーの原因調査と修正

: npm run build が失敗しています。原因を特定して修正してください

この手の「ログを読んで、直して、もう一回試す」みたいな作業は、まさにハーネス向き。

人間が横で付き合うより、AI がターミナルを回しながら反復するほうが相性がいい。

4. テストのたたき台作り

: src/utils.py の関数に対する pytest を作ってください

ゼロから全部を信じるのは危ないけど、たたき台をまとめて作る 用途としてはかなり便利だった。特に「正常系の雛形を広く作る」みたいな仕事は早い。

GitHub Copilot CLI と比べると、強い場所が違う

正直、使ってみた感想は「どっちが上か」というより、担当領域が少し違う だった。

自分の感覚では、こんな住み分けになった。

Copilot CLI が便利な場面

• GitHub の Issue / PR / リポジトリ操作を自然言語でつなげたい
• 組織管理やポリシーの整った環境で使いたい
• GitHub の文脈と一体で作業したい

ForgeCode が気持ちいい場面

• ターミナルの中で完結する作業を一気に任せたい
• ビルド、修正、再実行のループを強めに回したい
• プロバイダーやモデルを柔軟に切り替えたい

なので、結論としては 乗り換え先というより、別の得意分野を持つ道具 と見たほうがしっくりきた。

同じモデルでも差が出るのは、モデル以外の設計があるから

「同じ Claude Opus 4.6 なのに、なんでここまで差が出るの？」という疑問はやっぱり残る。

ここは断定はできないけど、公開情報を読む限りでは次の要素が大きそうだった。

1. 必要な文脈だけ取りにいく設計

公式サイトでは、ForgeCode Services が 大きなコードベースを高速にたどるコンテキストエンジン を持つと説明されていた。

全部を一度に読ませるのではなく、必要なところへ絞って取りにいけるなら、大規模リポジトリではかなり効くはず。

2. 調査・計画・実装を分けるマルチエージェント構成

公式ドキュメントには、forge / muse / sage の役割分担が明示されている。

• 調査が必要なら調査モード
• 実装が必要なら実装モード
• 計画が必要なら計画モード

という切り替えがしやすいと、1 つの会話に何でも詰め込むより安定しやすそう。

3. ツール呼び出しの補正や実行ループ

公式サイトでは tool corrections のような表現も前面に出していた。つまり、モデルが少し外しても、ハーネス側で実行を立て直す思想がある。

TerminalBench みたいな「最後までやり切れるか」を見る評価では、こういう差がそのまま成績に出やすいんだと思う。

まとめ：ForgeCode は「Copilot CLI の代替」というより、別の強い武器だった

試してみた結論を一言でいうと、ForgeCode はかなり面白かった。

特に印象に残ったのはこの 3 つ。

• Zsh に深く統合されていて、日常のターミナル操作に馴染む
• ビルドや修正の反復を任せる用途と相性がいい
• 同じモデルでもハーネスの設計でここまで差が出るのか、と実感しやすい

一方で、GitHub 周りまで含めて全部 1 本にまとめたいなら、Copilot CLI の強みもやはり大きい。

なので自分の今の感想は、

GitHub 文脈は Copilot CLI、ターミナルで完走させたい作業は ForgeCode

という使い分けがいちばんしっくりくる。

「AI にコードを書かせる」から一歩進んで、「AI にターミナルで仕事を完走させる」 ことに興味があるなら、ForgeCode はかなり触る価値があると思った。

参考リンク

• ForgeCode 公式サイト
• ForgeCode Installation & Setup
• ForgeCode ZSH Support
• ForgeCode Operating Agents
• TerminalBench 2.0 Leaderboard
• PR #2813: fix: add GitHub Copilot optimization headers for billing.
• GitHub Copilot CLI changelog（2026-01-14）

検証環境メモ

本記事の手順は、自宅の検証機（自分が普段から触っている個体）で実際に再現・操作した際の記録です。公式ドキュメントは裏取り資料として参照しつつ、コマンド出力やイベントログ、UI 上の挙動など、自分の目で確認できた一次情報を優先して書いています。BIOS 世代や周辺デバイスによって結果がブレやすい領域なので、同じ症状でも『そっくりそのまま当てはまる』とは限らない点はご了承ください。