OSSにforgecodeが選ばれる理由｜特徴と使い方の全体像

Claude Codeを試してみたものの、プロバイダ固定の運用や組織の統制ポリシーとの相性に悩むエンジニアは少なくありません。代替候補としてAiderやOpenCode、そして新興のforgecode（tailcallhq/forgecode）が挙がるものの、どれも一長一短で比較情報が散逸しがちです。

とくに初めて触れるOSSの採用判断では、「何者か」「既存ツールとどう違うのか」「メンテナンスは健全か」「自プロジェクトに導入してよいか」という4つの論点を短時間で整理する必要があります。公式サイトとREADMEを往復して情報を拾うのは骨の折れる作業です。

本記事ではforgecodeの公式情報（GitHubリポジトリ、公式サイト、公式ドキュメント）を一次ソースとし、Aider・OpenCodeとの差分を8軸マトリクスで整理します。動作検証は行わず、あくまで公開ドキュメントをもとに「採用判断の材料」として全体像を提示することが目的です。

想定する読者は、ターミナル中心の開発フローにAIペアプログラマを組み込みたい中堅エンジニアです。読了後に「One-Shotモードから試す」「permissions.yamlを整備してチームに広げる」といった次の一手を具体化できるよう、使い方と健全性指標も併せて解説します。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

forgecodeとは｜tailcallhq提供のOSS AIペアプログラマ

forgecodeはtailcallhq社が公開するOSS（オープンソースソフトウェア）のAIペアプログラマCLIです。公式のリポジトリ説明は「AI enabled pair programmer for Claude, GPT, O Series, Grok, Deepseek, Gemini and 300+ models」と記載されており、Claude・GPT・Gemini・Grokなど300以上のモデルにまたがって動作するマルチプロバイダ設計が特徴です（GitHub: tailcallhq/forgecode）。

公式ドキュメントでは自身を「Claude Code but with first-class support for many AI providers」と位置づけており、リポジトリのTopicsにも open-source-claude-code というタグが含まれています。Claude Codeのオルタナティブとして、作者側が明示的にポジショニングを行っている点は押さえておきたいところです（公式ドキュメント）。

プロジェクトの立ち位置

forgecodeは「ターミナルを離れずにAIの力を借りたい」というニーズに向けて設計されています。エディタ統合型のCursorやVS Code拡張とは対照的に、CLI・TUI・シェルプラグインの3つの入り口を通じて、既存の開発フローにAIペアプログラマを差し込む思想です。Topicsには ai-pair-programming・cli-assistant・command-line・open-router・llm などが並び、ターミナル派エンジニアとマルチモデル運用の両方をコアオーディエンスとしていることが読み取れます。

基本情報（2026年4月時点）

リポジトリのメタ情報は次のとおりです（出典: GitHub API経由で取得した repo-meta.json）。

Apache-2.0ライセンスで公開されており、商用利用・改変・再配布が可能なゆるやかなライセンス形態です。メイン言語はRustで、後述するとおりシングルバイナリ配布と相性のよい構成になっています。

forgecodeが選ばれる6つの理由

公式ドキュメントとリポジトリ情報を整理すると、forgecodeが類似ツールに対して差別化している要素は次の6点に集約されます。類似OSSと並べたとき、どこが独自性として立ち上がるのかを順に見ていきます。

1. Rust実装による配布容易性

forgecodeはRustで実装されており、主要言語比率の約93%がRustです。配布物はワンライナーのインストールスクリプトで取得でき、Pythonランタイム・Node.jsランタイム・追加のパッケージマネージャを必要としません。READMEに掲載されているインストールコマンドは次のとおりです。

出典: README.md

社内で利用する開発者の言語スタックが混在している場合や、CI/CDランナーに余計な依存を持ち込みたくない場合、単体バイナリで導入できる点は採用判断の大きな追い風になります。

2. 3つの操作モード（TUI / One-Shot / ZSHプラグイン）

forgecodeは同じエージェントを3通りの入り口から呼び出せます。用途に応じて、対話型で深掘りするか、ワンショットで質問するか、シェルに統合するかを選択できる設計です。

• Interactive TUIモード: forge コマンドで対話型セッションを開始する
• One-Shot CLIモード: forge -p "..." で単発のプロンプトに結果を返す
• ZSHプラグインモード: ZSHセッション内で : プレフィックスを使ってAIを呼び出す

とくにZSHプラグインモードは、他のAIコーディングエージェントでは採用例が少ないユニークなUXです。既存のシェル作業を中断せず、思いついたタイミングでAI支援を差し込める設計になっています。

3. forge / sage / museの3エージェント体制

forgecodeには役割の異なる3種類の組み込みエージェントが用意されており、タスクの性質に応じて使い分けることが推奨されています。

• forge: 実装（コード変更）を担当するデフォルトエージェント
• sage: 読み取り専用で調査・説明を担う研究エージェント
• muse: 計画・設計・アーキテクチャ検討に特化したエージェント

公式の提供コマンドでは :sage how does the caching layer work? や :muse design a deployment strategy のように、自然言語の先頭にエージェント名を付けて使い分ける形が示されています（README.md）。単一エージェントに役割を押し付けず、「読み取り」と「変更」と「設計」で権限・振る舞いを分けるアプローチは、本番コードを触る際の事故を減らす実運用向きの設計といえます。

4. MCP（Model Context Protocol）サポート

forgecodeはMCPに対応しており、リポジトリ直下の .mcp.json でMCPサーバとの連携を構成できます。公式ドキュメントの設定ファイル一覧には .mcp.json が明記されており、外部ツール・データソースをエージェントのコンテキストに接続する拡張ポイントとして用意されています（公式ドキュメント）。

社内のナレッジベース・チケットシステム・独自データベースを参照させたいチームにとって、MCP対応は中期的な統合コストに直結する評価軸です。

5. permissions.yamlによるセキュア実行

forgecodeは permissions.yaml を通じてシェル実行権限を細かく制御できる設計を備えています。restricted shellモードと組み合わせて、AIエージェントが実行可能なコマンドのスコープを明示的に縛ることができます（公式ドキュメント）。

AIペアプログラマを本番寄りの環境に導入する際、「破壊的な操作をどう防ぐか」は必ず問われる論点です。forgecodeのように権限定義ファイルを公式にサポートしているツールは、チームのセキュリティポリシーに沿って運用を設計しやすい利点があります。

6. 300+モデル対応とプロバイダ切り替え

forgecodeはAnthropic（Claude 3.7 Sonnet / Claude 4 Sonnet）、OpenAI（GPT / O Series）、Google Vertex AI / Gemini、Groq、Amazon Bedrock、OpenRouter、DeepSeek、xAI Grok、Mistral、Meta、Qwenなど300以上のモデルに対応していると公表されています。認証はCLIから forge provider login を実行する形で登録できます。

出典: README.md

また、forgecodeの公式サイトではTermBench 2.0において81.8%を達成したと主張されています（※公式サイト掲載の自己評価であり、独立機関による第三者評価ではありません）。ベンチマーク数値は参考情報として扱い、自社のユースケースに対してはトライアル検証が必要です。

使い方の全体像｜インストールから3モードの使い分けまで

ここからは公式ドキュメントとREADMEに記載されている使い方をもとに、forgecodeを動かすまでの流れを俯瞰します。本章ではドキュメント記載の手順をダイジェストで紹介するにとどめ、動作検証は行いません。実際に利用する際は必ず最新のドキュメントを参照してください。

インストール

READMEにはワンライナーのインストール手順が掲載されています。

出典: README.md

このスニペットはインストールスクリプトを取得し、プロバイダ認証を行い、インタラクティブセッションを起動するまでを1セットで示しています。

Interactive TUIモード

引数なしで forge を実行すると、対話型のTUIセッションが開始されます。継続的にコードベースを参照しながら質問・編集を重ねるユースケースに向いています。

出典: README.md

One-Shot CLIモード

-p オプションに自然言語のプロンプトを渡すと、ワンショットで結果だけが返ってきます。既存のシェルスクリプトやエディタのキーバインドから呼び出すのに適したモードです。

出典: README.md

コミットメッセージ生成（forge commit）、自然言語からシェルコマンドへの翻訳（forge suggest）、保存済み会話の再開（forge conversation resume）など、サブコマンドベースのユーティリティも揃っています。

ZSHプラグインモード

ZSHプラグインをセットアップすると、シェルプロンプト上で : プレフィックスを使ってforgecodeを呼び出せるようになります。READMEには次のような使用例が示されています。

出典: README.md

: の直後に自然言語を書けばforgeエージェントが、:sage や :muse と書けば対応する専門エージェントが起動する設計です。ZSHを常用しているエンジニアにとっては、別ウィンドウやエディタを切り替えずにAIを呼び出せる体験価値は大きなポイントになります。

類似OSSとの差分｜Aider・OpenCodeと何が違うか

forgecodeの採用判断を進めるうえで避けて通れないのが、先行する類似OSSとの比較です。ここでは代表格としてAider-AI/aiderとsst/opencode（OpenCode）を取り上げ、それぞれのコンセプトとforgecodeとの違いを整理します。

Aiderとの違い（Git自動コミット vs ZSHプラグインUX）

AiderはPython実装の老舗AIペアプログラマで、ターミナル内で編集・Git自動コミットを一気通貫で行うワークフローを中核としています。リポジトリ全体のマップを作成して大規模コードベースに追従する設計が特徴で、100以上のプログラミング言語をサポートすると公表されています。

forgecodeとの最大の違いは、AiderがGit操作を前提にした「ファイル編集→自動コミット」モデルであるのに対し、forgecodeはCLI・TUI・ZSHプラグインという3モードで「シェル作業への組み込み」に重心を置いている点です。リポジトリ全体を書き換えるような大規模リファクタリングにはAiderが、日々のシェル作業に寄り添う軽い呼び出しにはforgecodeが相性がよいと整理できます。

OpenCodeとの違い（2エージェント vs 3エージェント）

OpenCode（sst/opencode）はGo製のTUIベースAIコーディングエージェントで、Bubble TeaベースのリッチなTUIや、Build（実装）／Plan（設計）という2種類の組み込みエージェントを提供するプロジェクトです。75以上のプロバイダにルーティングできるマルチプロバイダ対応もあわせて備えています。

forgecodeはOpenCodeのTUI志向と共通する部分を持ちつつ、エージェントを3種（forge / sage / muse）に分割している点、MCPサポートとpermissions.yamlを明示的に備えている点、ZSHプラグインを公式提供している点で差異があります。権限制御を重視するチーム、シェルに密結合したUXを求めるチームにとってはforgecodeの設計が刺さる可能性が高いといえます。

比較表（8軸マトリクス）

公式ドキュメントと各リポジトリのREADME・公開情報をもとに、主要な差分を8軸で整理します。スター数やバージョンは変動するため、数値は記事公開時点の公開情報に基づく参考値として扱ってください。

注記: TermBench 2.0の81.8%はforgecode公式サイトに掲載された自社評価であり、独立した第三者評価ではない点に留意が必要です。ベンチマーク数値は「作者が主張する性能の目安」として参照し、自社の実際のユースケースでの妥当性は別途検証することを推奨します。

メンテナンス状況・コミュニティ｜採用前に見るべき健全性指標

OSSを採用する際は、機能面だけでなくプロジェクトの活動状況も大切な判断材料です。forgecodeの健全性を示す主な指標は以下のとおりです（出典: GitHub API経由のリポジトリメタ情報、GitHub Releases）。

直近2日間で3つのマイナーリリースが公開されていることから、アクティブな開発が続いている状態と判断できます。Discussionsが有効化されており、公式Discordコミュニティも案内されていることから、質問や機能要望を投げる場も整っています。

一方で、Open Issuesが116件存在する点は、機能要望と不具合報告の切り分けを踏まえたうえで評価する必要があります。2024年12月に公開された比較的新しいプロジェクトという点も踏まえ、長期プロダクトで採用する場合はメジャーバージョンの動向・破壊的変更のポリシーを継続的にウォッチすることをおすすめします。ライセンスはApache-2.0で、商用利用・改変・再配布に関する制約も緩やかです。

forgecodeの採用判断チェックリスト

ここまでの情報を踏まえ、forgecodeの採用が向くチーム／向かないチームを整理します。意思決定の最終ゲートとして活用してください。

forgecodeが向いているケース

• 複数のLLMプロバイダを並行利用し、モデル切り替えを日常的に行いたいチーム
• ターミナル中心の開発フローで、IDE統合より軽量なAIペアプログラマを好むメンバーが多い
• AIエージェントに対してpermissions.yamlのような明示的な権限制御を敷きたいセキュリティ要件がある
• Python・Node.jsのランタイム依存を増やしたくないCI/CD環境に配布したい
• MCPで社内ナレッジやチケットシステムをAIに連携させる構想がある
• ZSHユーザーが多く、シェルの中でAI呼び出しを完結させたい

forgecodeが向かないケース

• エディタ統合（Cursor・VS Code拡張・JetBrains系）を中心にしたいチーム
• Pythonエコシステムで完結させたい前提があり、既にAiderで運用が成立している
• 大規模リポジトリに対してGit自動コミット主体のリファクタリングフローを組みたい（この場合はAiderの設計のほうが自然）
• OSSの成熟度を重視し、「5年以上の運用実績」や「保守的な破壊的変更ポリシー」を要件にしている

このチェックリストは排他的なものではなく、たとえば「普段はAiderを使いつつ、forgecodeをZSHプラグインとして併用する」といった使い分けも十分に現実的です。forgecodeはシェル統合型のUXが特徴的なので、既存ツールを置き換える前に共存を試すアプローチも検討してみてください。

まとめ｜forgecodeを試す最短ルート

forgecodeはRust製のOSS AIペアプログラマCLIで、次の要点を押さえておけば全体像を見失いません。

• Claude Codeオルタナとしての明示的なポジショニング（Topicsに open-source-claude-code）
• TUI・One-Shot・ZSHプラグインの3モードと、forge / sage / museの3エージェント体制
• MCP対応とpermissions.yamlによる権限制御を備えたセキュア運用向き設計
• 300+モデル対応とTermBench 2.0で81.8%達成の公式自己評価（独立評価ではない点に留意）
• pushed_at 2026-04-18／直近2日で3リリースというアクティブなメンテナンス状況

採用検討の最短ルートとしては、まずOne-Shot CLIモード（forge -p "..."）で軽く質問用途から試し、使用感が合えばZSHプラグインをセットアップして既存シェルフローに取り込み、チーム導入のフェーズでpermissions.yamlを整備するという三段階の進め方が現実的です。

次のステップとして、tailcallhq/forgecode（GitHub）と公式サイト（forgecode.dev）、公式ドキュメント（forgecode.dev/docs）を参照し、自チームの要件に照らしてトライアル計画を立てることをおすすめします。