モデル / データセット
tailcallhq/forgecode avatar
tailcallhq/forgecode

Forge: ターミナルに常駐するコーディングエージェントの実像

AI enabled pair programmer for Claude, GPT, O Series, Grok, Deepseek, Gemini and 300+ models

スター 7,629フォーク 1,463RustApache-2.0

ひと目でわかる

これは何?
Rust 製の CLI コーディングエージェント Forge を、3 つの動作モード、forge.yaml による設定、ZSH プラグインの `:` プレフィックスという実際の仕組みから読み解く。導入判断で確認すべき境界も示す。
誰に向いている?
ターミナルから離れずに複数モデルを使い分けたい個人開発者や、OpenRouter 経由でモデルを切り替えながら試したい小規模チームには、Forge の TUI と `:` プレフィックスの組み合わせは検討に値する。逆に、GUI ベースの差分レビューや、複数人での会話履歴共有を前提とするワークフローには向かない。
商用利用できる?
できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 2 日前です。
何の言語で書かれている?
主に Rust です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Forge が埋めようとしている穴は「ターミナルとモデルの往復」

コーディングエージェントの多くは、エディタの拡張機能か、ブラウザのチャット画面として提供される。Forge が狙うのはそのどちらでもなく、シェルそのものである。README は Forge を「AI-Enhanced Terminal Development Environment」と位置づけ、`curl -fsSL https://forgecode.dev/cli | sh` の一行で導入できるとしている。対象読者は、コードの説明、機能追加、デバッグ、コードレビュー、リファクタリング、Git のコンフリクト解消といった作業を、ターミナルから出ずに進めたい開発者だ。README の Usage Examples には、認証システムの説明を求める質問や、React のクラスコンポーネントを Hooks に書き換える依頼が例として並んでいる。つまり対象は特定の言語やフレームワークではなく、シェルを主戦場にしている人全般である。ここで注意したいのは、Forge 自体がモデルを提供するわけではない点だ。Claude、GPT、O Series、Grok、Deepseek、Gemini など 300 以上のモデルを、利用者自身の資格情報で呼び出す。モデルの選定と費用は利用者側に残る。

3 つのモードは排他ではなく、作業の粒度で選ぶ

Forge の動作は 3 つに分かれ、README も「この区別を最初に理解しておくと混乱を避けられる」と書いている。第一が TUI で、引数なしの `forge` で起動する対話セッションだ。多段階の作業はここで行う。`forge conversation resume <id>` で過去のセッションを再開できる。第二がワンショットの CLI モードで、単発の問い合わせに向く。第三が ZSH プラグインで、シェル上で `:` から始まるコマンドとして呼び出す。この 3 つ目の設計が Forge の性格を最もよく表している。`:` の後ろにエージェント名やプロンプト、ファイル添付、会話管理、Git 操作、シェルコマンドツール、セッションと設定、Skills といったコマンド群が続く。つまりシェルのプロンプトそのものをエージェントの入口にしている。エディタを開き直す必要も、別ウィンドウに切り替える必要もない。ただしこの統合は ZSH に依存する。bash や fish を使っている場合、この `:` 体系はそのままでは使えない。README は ZSH 以外のシェル向けの代替を説明していない。

モデル接続は provider login と forge.yaml の二層で設定する

導入は README の Quickstart に従えば短い。`curl -fsSL https://forgecode.dev/cli | sh` で本体を入れ、初回起動時に表示される対話フローで資格情報を設定する。事前に設定したい場合は `forge provider login` を実行してから `forge` を起動する。資格情報の管理方法として README は「Managing Provider Credentials」の節を設け、環境変数による方法は deprecated として退けている。つまり新しい構成では、環境変数に API キーを直接置くのではなく、provider login の対話フローを通すことが推奨されている。挙動の調整は forge.yaml で行う。README には「forge.yaml Configuration Options」と「Environment Variables」の節があり、MCP の設定も別節で扱う。MCP は Model Context Protocol の設定で、外部ツールをエージェントから呼べるようにするものだ。設定ファイルと環境変数と MCP が別々の節に分かれている点は、設定の入口が複数あることを意味する。導入時はどれを一次の情報源にするかを決めておかないと、後から設定の出所が追えなくなる。

restricted shell は「安全」ではなく「影響範囲を狭める」仕組み

README の Why Forge? には「Secure by design」として、restricted shell モードがファイルシステムへのアクセスを制限し、意図しない変更を防ぐと書かれている。ここは正確に読む必要がある。制限がかかるのは restricted shell モードのときであり、常時ではない。エージェントがファイルを書き換えたりシェルコマンドを実行したりできる以上、モードの切り替えを誤れば制限は外れる。README はこのモードをどう切り替えるか、どの操作がブロックされるかの一覧を提示していない。したがって、restricted shell を有効にした状態で自分の作業ディレクトリに対して何ができて何ができないかを、導入前に自分で確かめる必要がある。もう一点、`curl ... | sh` というインストール方法自体が、取得したスクリプトをそのまま実行する形式である。利便性と引き換えに、内容を確認せずに実行することになる。CI や共有マシンへの導入を検討しているなら、この点は先に決めておくべき論点だ。

会話の継続と Git 連携が実務で効く場面

TUI の価値は、単発の質問ではなく文脈を保持したまま作業を進められることにある。`forge conversation resume <id>` が用意されているのは、セッションが ID で識別され、後から再開できる設計だからだ。長いリファクタリングや、複数ファイルにまたがる変更では、この継続性が効く。ZSH プラグイン側にも会話管理と Git 連携のコマンド群がある。README の Usage Examples には、`feature/user-profile` を main にマージしようとしてコンフリクトした状況を Forge に相談する例が載っている。差分の意味を説明させ、どちらを採るかを判断する使い方だ。ただし、これらはあくまでエージェントとの対話であり、マージの最終判断は利用者に残る。ZSH プラグインには Semantic Search (Workspace) の節もあり、作業ディレクトリ横断の検索ができると読める。ここは README の記述が簡潔で、インデックスをいつどう作るのか、どのファイルが対象外になるのかは読み取れない。大規模なモノレポで使うなら、この検索がどの範囲を対象にするかを先に確認したい。

向かないケースと、代わりに検討する選択肢

Forge が向かないのは、まず GUI での差分レビューを前提とするチームだ。Forge の出力はターミナルに閉じる。変更を視覚的に確認し、行単位でコメントを付けるような流れは、この設計の外にある。次に、複数人で会話履歴を共有したい場合。conversation は ID で管理されるが、README はそれをチームで共有する方法を説明していない。第三に、ZSH 以外のシェルを標準とする環境。`:` プレフィックスの体系はそのままでは使えない。代替として挙げるなら、エディタ統合型のエージェントだ。こちらは差分をエディタ内で確認しながら適用できる点が根本的に違う。Forge はターミナルから出ないことを選び、エディタ統合型はエディタに留まることを選ぶ。この違いは機能の多寡ではなく、作業の起点をどこに置くかという設計判断である。シェルでビルドとテストを回しながら進める人には Forge が合い、エディタでコードを読みながら進める人には合わない。

Apache-2.0 とメンテナンスコストの読み方

ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。Apache-2.0 は商用利用を含む利用と改変を許すが、特許条項や帰属表示の条件が付く。自組織のポリシーに照らした判断は法務の領域であり、ここで結論は出せない。メンテナンスの観点では、リリースが v2.13.19 から v2.13.21 まで約 1 週間で 3 回出ている。活発な更新は利点である一方、forge.yaml のキーや CLI オプションが短期間で変わる可能性も意味する。README の README 内の目次には Provider Configuration の下に「Deprecated: Environment Variables」という節があり、環境変数による資格情報設定がすでに非推奨へ移行した例が確認できる。設定を環境変数に寄せている場合、移行が必要になる。追従コストを見積もるなら、forge.yaml のキーと `:` コマンドの一覧を自組織の設定と突き合わせ、リリースノートで差分を確認する運用を先に決めておくのが現実的だ。CLA assistant のバッジがあることから、外部からのコントリビューションには CLA への同意が求められる。

編集部の結論

ターミナルから離れずに複数モデルを使い分けたい個人開発者や、OpenRouter 経由でモデルを切り替えながら試したい小規模チームには、Forge の TUI と `:` プレフィックスの組み合わせは検討に値する。逆に、GUI ベースの差分レビューや、複数人での会話履歴共有を前提とするワークフローには向かない。導入前に確認すべきは 3 点で、第一に `forge provider login` で扱う認証情報がどこに保存されるか、第二に forge.yaml の restricted shell 関連設定が自分の作業ディレクトリでどう効くか、第三に MCP サーバーを追加した場合にどのツールがエージェントから呼べる状態になるかである。この 3 点を自分の環境で実際に確かめるまで、本番リポジトリでの利用は避けたほうがよい。

公式情報源

  1. License: Apache-2.0
  2. Project website
  3. README
  4. Releases
  5. tailcallhq/forgecode on GitHub
コミュニティノート

コミュニティノート