FuXi: ターミナル常駐型コーディングエージェントの実力と導入判断
FuXi is a fast, self-contained AI coding agent that lives in your terminal — edit code, run commands, and drive tools, with cost-aware routing across LLM providers.
ひと目でわかる
- これは何？
- Go製の単一バイナリで動くターミナルAIコーディングエージェント。プロバイダ非依存のルーティングとThink→Act→Verifyループを掲げるが、ライセンス表記はProprietaryで、外部ベンチマークスコアは未公開。導入前に何を確認すべきかを整理する。
- 誰に向いている？
- ターミナル中心のワークフローで、OpenAI互換APIキーをすでに持っており、Claude Code以外の選択肢を試したい個人開発者や少人数チームに向く。逆に、第三者ベンチマークのスコアを調達要件にしている組織、ライセンス条項を法務確認なしに通せない企業、Python製ツールの改造を前提にしたチームには向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
モデルを「作業者」に変えるという設計思想
FuXiが解こうとしているのは、モデル単体では完結しないコーディング作業の実行部分である。READMEは「The model is the engine. FuXi is the vehicle.」と表現し、モデルが答えを返すだけなのに対し、FuXiは実コードベース上で推論し、操作し、結果を検証する worker に変えると説明している。対象はターミナルで作業する開発者で、GUIエディタの拡張機能ではなくCLI常駐のエージェントを求める層だ。Claude Codeの代替として、任意のOpenAI互換モデルを持ち込みたいという動機が前面に出ている。
Think → Act → Verifyループとルーティングの実体
アーキテクチャの中心はThink → Act → Verifyのループで、READMEはこれを図版（docs/loop.png、docs/routing.png）で示している。ファイル読み書き、シェル（bash / PowerShell）、ripgrep検索、Web取得、LSP診断、Jupyter、ブラウザ操作、バックグラウンドタスク、並列サブエージェントを含む50以上のツールが1バイナリに同梱される。コスト考慮型のルーティングと自動フェイルオーバーにより、複数プロバイダをまたいで処理を振り分ける。シェルコマンドは実行前にASTベースの安全性分類器を通る点が、自律実行の制御として明示されている。セッションはディスクに永続化され、チェックポイントによる再開、ロールバック、フォークが可能。アイドル時の dreaming がセッション間のメモリを統合し、長い会話は自動圧縮される。
インストールと初期検証のコマンド
macOS / Linuxは curl -fsSL https://fuxicode.com/install.sh | bash、WindowsはPowerShellで irm https://fuxicode.com/install.ps1 | iex、CMDではinstall.cmdを取得して実行する。いずれも~/.local/bin（Windowsは%USERPROFILE%\.local\bin）に配置し、必要ならユーザーPATHに追加する。同じコマンドの再実行がそのままアップグレードになる。バージョン固定は./bootstrap.sh 0.1.2のように引数で渡す。導入後はfuxi --versionとfuxi doctorで環境（config、APIキー、git、ripgrepなど）を確認し、fuxi verifyでプロバイダ接続を検証する。起動はfuxi。TUI内では/cost、/usage、/context、/statusがコストとコンテキストの把握に使える。アンインストールはバイナリ削除と、任意で~/.fuxiの削除。
ライセンス表記のねじれをどう扱うか
ここは導入判断で最も引っかかる部分だ。リポジトリのメタデータではLicenseがNOASSERTION、READMEのバッジはProprietary、本文には「Free forever」で個人・チーム・企業にライセンス費用がかからないと書かれている。無償で使えることと、ソースがオープンであることは別の話であり、NOASSERTIONはGitHubが既知のライセンスとして認識できなかったことを意味する。フォーク、再配布、商用組み込みが可能かは本文からは読み取れない。LICENSEファイルの実物を開いて条項を確認するまで、社内標準ツールとして展開する判断はできない。
ベンチマークが自前であるという限界
READMEはSWE-bench、Terminal-Bench、Aider polyglotといった第三者ベンチマークのスコアを現時点で公開していないと明言している。代わりに置かれているのはbenchmark/REPORT.mdで、Claude Codeと同一のbaseline、同一のscorer（pytest + coverage）を使い、15のmicro dimensionと4のlarge-project dimensionで比較したとされる自己実行の結果である。README自身が「small, self-run task set」であり、agent loopを測るものでモデルの生スコアではないと注記している。この注記は誠実だが、調達や技術選定の根拠としては弱い。数字を意思決定に使うなら、自分のリポジトリで同じ手順を回す必要がある。
Claude Codeとの差分はどこにあるか
比較対象として最も具体的なのはClaude Codeである。最大の違いはプロバイダの束縛で、Claude CodeがAnthropicのモデルを前提にするのに対し、FuXiは任意のOpenAI互換モデルを持ち込める。ルーティングと自動フェイルオーバーもFuXi側の機能で、単一プロバイダ前提のツールにはない。一方でツール群の成熟度やモデルとエージェントの統合度では、自社モデルを前提に設計された側に分がある可能性がある。FuXiのREADMEが示す比較表は各製品の公開情報に基づくorientationであり、mid-2026時点のものと断っている。優劣の断定ではなく、どの制約を優先するかの話である。
メンテナンスとアップグレードの実際
配布形態はGo製の静的バイナリ1つで、ランタイム依存がない。これはアップグレードのコストを下げる。fuxi updateによる自己更新は、実行中のバイナリを置き換える前にチェックサム検証を行うとREADMEは説明している。バックグラウンドでバージョンチェックも走る。リリースは0.1.1、0.1.2、0.1.6と短期間に続いており、0.x系である点は前提として置くべきだ。設定と状態は~/.fuxiに集約されるため、バックアップや移行の対象はこのディレクトリになる。MCPクライアント、hooks、skills、plugins、slash commandsはホットリロード対応とされている。
どんなチームが採用し、どんなチームが避けるべきか
採用に向くのは、ターミナルで完結するワークフローを持ち、OpenAI互換のAPIキーをすでに管理しており、コストをプロバイダ間で最適化したい個人または少人数チームだ。MCP経由で既存ツールをつなぎたい場合も候補になる。避けるべきは、第三者ベンチマークのスコアを選定要件にしている組織、ライセンス条項を法務確認なしに通せない企業、そしてリポジトリのメタデータがPythonを主要言語としながらREADMEがGo製と述べている不一致を気にする層だ。この不一致は事実として記録しておく価値がある。最初にやることはfuxi doctorとfuxi verifyを通すこと、次に自分のプロジェクトの失敗テストを1つ直させて結果を確認することである。
編集部の結論
ターミナル中心のワークフローで、OpenAI互換APIキーをすでに持っており、Claude Code以外の選択肢を試したい個人開発者や少人数チームに向く。逆に、第三者ベンチマークのスコアを調達要件にしている組織、ライセンス条項を法務確認なしに通せない企業、Python製ツールの改造を前提にしたチームには向かない。導入前に必ず確認すべきは3点。fuxi doctorとfuxi verifyで環境とプロバイダ接続が通るか、リポジトリ同梱のbenchmark/REPORT.mdを自分で再実行できるか、そしてLICENSEファイルの実際の条項がREADMEの「Free forever」という記述と一致しているかである。
コミュニティノート