future-agi/future-agi: 計測・評価・シミュレーション・ガードレールを1つのDockerスタックに束ねる自己ホスト型LLM運用基盤
Open-source, end-to-end platform for evaluating, observing, and improving LLM and AI agent applications. Tracing · Evals · Simulations · Datasets · Gateway · Guardrails. Self-hostable. Apache 2.0.
ひと目でわかる
- これは何？
- トレース、評価、シミュレーション、ゲートウェイ、ガードレールを単一のフィードバックループに統合しようとするApache 2.0のPython製プラットフォーム。READMEが示す構成と導入コマンドを読み、ツールを1本化することの利点と、その統合が裏返しになる場面を整理する。
- 誰に向いている？
- 採用を検討すべきなのは、評価・観測・ガードレールを別々のSaaSで縫い合わせる運用に疲れ、データを自社環境に置いたまま単一のフィードバックループで回したいチームだ。逆に、トレースだけあれば足りる段階のプロジェクトや、すでに特定ベンダーの評価基盤に深く依存している構成には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
どの断絶を埋めようとしているのか
READMEが掲げる問題設定は明快で、評価、可観測性、ガードレールを別々のツールで組み立てると「ループが閉じない」というものだ。トレースはLangfuse、評価はBraintrust、ゲートウェイはHelicone、ガードレールはGuardrails AI、シミュレータは自作、という構成を名指しで挙げ、これを1つのプラットフォームに畳むと説明している。対象読者は、プロトタイプではなく本番運用に入ったエージェントを抱えるチームである。READMEの表現を借りれば「simulate → evaluate → protect → monitor → optimize」という流れを、データが一方向に流れて終わるのではなく戻ってくるループとして扱う。ここで重要なのは、機能の寄せ集めではなく、あるツールの出力が別のツールの入力になることを前提にした設計だという主張だ。トレースから得た失敗例をデータセットに落とし、それを評価とシミュレーションに使い、結果を次のバージョンの判断材料にする、という一連の経路が同じスタック内で完結するかどうかが、この製品の中心的な問いになる。
リポジトリ構成から見える提供形態の二重性
READMEのクイックスタートは、クラウドとセルフホストの2経路を並べて提示する。クラウド側はapp.futureagi.comでのサインアップとpip install ai-evaluationのみで、インストール作業がない。セルフホスト側はgit cloneでリポジトリを取得し、bin/installを実行する。Pythonパッケージのai-evaluationと、npmの@traceai/fi-coreという2つの配布物がバッジで示されており、計装ライブラリが言語ごとに分かれていることが読み取れる。Python側の例ではfi_instrumentationのregisterと、traceai_openaiのOpenAIInstrumentorを使い、既存のOpenAI呼び出しをそのまま計装する。つまりアプリケーションコードの書き換えではなく、計装の登録という形でトレースを載せる設計だ。OpenTelemetryを土台にしているとREADMEは述べており、50以上のフレームワーク向けinstrumentorが同梱されるとしている。この「既存コードを保ったまま計装だけ差し込む」方針は、導入時の変更量を小さく見せる一方で、計装ライブラリのバージョン追随が運用負荷になることを意味する。
セルフホストの実手順と、アップグレード時にだけ走るコマンド
セルフホストはDocker DesktopまたはDocker EngineとDocker Composeが前提で、macOS、Linux、WSLでは./bin/install、Windows PowerShellでは.\bin\install.ps1を実行する。ソースビルドではなく公開済みイメージを使うとREADMEは説明しており、起動後はhttp://localhost:3000を開く。本番向けには./deploy/setup.shでシークレットを生成し、イメージのバージョンを固定するよう案内している。ここで見落としやすいのがアップグレード時の手順だ。すでにトレースが入っているインストールを更新した場合、新しいスタックが正常になってから./bin/property-catalog-backfill --execute（Windowsでは.\bin\property-catalog-backfill.ps1 -Execute）を明示的に実行しないと、非アクティブな統合プロパティカタログが初期化されない。通常の再起動では履歴スキャンは走らないと明記されている。このコマンドはDocker Composeがすでに選択したイメージをそのまま使い、ブランチやソース、イメージの取得は行わない。アクティブなワークスペースはスキップし、カタログの永続レジャーを通じて再開する。対象はセルフホストのスーパーバイザが許可したアクティブなワークスペースとプロジェクトに限られ、ソースウィンドウは366日のローリングだと説明されている。つまり、この期間より古いデータや非アクティブなワークスペースはバックフィルの対象外になる。
ゲートウェイの数値と、それが測っているもの
READMEはGoで書かれたゲートウェイの性能として、重み付きルーティングで約9.9ナノ秒、t3.xlargeで約29kリクエスト毎秒、ガードレール有効時のP99が21ミリ秒以下という数字を挙げ、コミットされたベンチマークハーネスで再現可能だとしている。ここは慎重に読むべき箇所だ。これらの値はこの記事で検証したものではなく、READMEの主張である。9.9ナノ秒という桁はルーティング判定そのもののコストを示すもので、リクエスト全体のレイテンシではない。29k req/sというスループットも、どのペイロード、どのモデル、どのガードレール構成で測ったかによって意味が変わる。評価基盤を選ぶ際に性能値だけを見て判断するのは危うい。むしろ注目すべきは、ベンチマークハーネスがリポジトリにコミットされているという設計判断のほうだ。数値を鵜呑みにするのではなく、自分のワークロードに近い条件でハーネスを回せる余地が残されている点を、採用判断の材料として扱いたい。
評価ロジックがブラックボックスでないことの意味
READMEはApache 2.0のコアについて、すべての評価器、すべてのプロンプト、すべてのトレースが検査可能で「no black-box scoring」だと述べている。評価基盤を選ぶとき、スコアがどのように計算されたかが説明できないと、本番の判断に使えない。特にLLM-as-a-judgeを使う評価では、判定に使ったプロンプトとモデルが変わればスコアの意味も変わる。プロンプトがリポジトリ内で読める形になっていることは、スコアの再現性と監査の観点で実利がある。ただし、これは評価器の中身が正しいことを保証するものではない。プロンプトを読めることと、そのプロンプトが自分のドメインに適していることは別問題だ。また、セルフホストを選ぶ動機としてデータ主権が挙げられているが、クラウド側ではSOC 2 Type IIやHIPAA、データのリージョン保持が示されている。規制対応の要件がある場合、どちらの経路を選ぶかで確認すべき項目が変わる。
Nightlyリリースであることの実務的な重み
READMEの冒頭には「Nightly release for early testing」という警告があり、粗さを覚悟するよう求めている。安定版は後日とされている。リリース一覧を見るとv1.37.1、v1.37.0、v1.36.1が数日おきに並んでおり、更新の頻度が高いことがわかる。活発な開発は利点だが、本番のオブザーバビリティ基盤としては無視できない性質でもある。トレースの保存形式やカタログのスキーマが動く可能性があり、先ほどのproperty-catalog-backfillが存在すること自体、アップグレードがデータ移行を伴う場合があることを示している。評価やガードレールをCIに組み込んでいる場合、ライブラリの更新でスコアや判定が変わりうる。導入するなら、イメージのバージョンを固定し、更新は検証環境で先に当てる運用が前提になる。READMEが./deploy/setup.shでイメージのバージョンを固定するよう案内しているのは、この文脈で読むと納得がいく。
LangfuseやBraintrustとどう棲み分けるか
READMEは対抗馬としてLangfuse、Braintrust、Helicone、Guardrails AIを名指しし、これらを縫い合わせる代わりに1つに畳むと主張する。違いは機能の有無ではなく統合の度合いにある。Langfuseはトレースとプロンプト管理を中心に据えた観測ツールで、評価機能も持つが、ゲートウェイやガードレールまでを同じループで扱うことは想定していない。Braintrustは評価とデータセット管理に強みがあり、本番のトラフィック制御は別レイヤーになる。future-agiの設計は、計装したトレースをそのままデータセットと評価に回し、ゲートウェイとガードレールが本番のリクエスト経路上で同じデータを参照する、という一本化を売りにする。裏返せば、すでにLangfuseでトレース基盤を固め、Braintrustで評価の文化を築いているチームにとって、移行は計装の張り替えとダッシュボードの作り直しを意味する。統合の恩恵はループを実際に閉じたときに初めて出るので、ツールを1本化するだけで評価が回り始めるわけではない。
向くチーム、向かないチーム、最初に確かめること
向くのは、エージェントを本番に出していて、失敗の再現、評価、ガードレール、ルーティングを別々のツールで面倒を見ているチームだ。特に、トレースをデータセットに変換して次のバージョンの評価に使う、という往復を手作業でつないでいるなら、その作業を減らせる可能性がある。データを自社環境に置く必要があり、かつApache 2.0のコアを検査できることに価値がある場合も候補になる。向かないのは、まだトレースを取る段階に達していないプロトタイプ、あるいは観測だけを目的としていて評価やガードレールを必要としない構成だ。機能が多いほど、使わない機能の更新にも付き合うことになる。導入前に確かめるべきは3点ある。第一に、fi_instrumentationで自分のエージェントを計装したときに、デバッグに足る粒度のトレースが出るか。第二に、既存のトレースがある状態からのアップグレードでproperty-catalog-backfillが何を対象にし、366日の窓の外にあるデータがどう扱われるか。第三に、Nightlyリリースの更新頻度に対して、イメージのバージョン固定と検証環境での先行適用を運用に組み込めるか。この3点が自チームの制約に収まらないなら、統合の利点より追随コストが上回る。
編集部の結論
採用を検討すべきなのは、評価・観測・ガードレールを別々のSaaSで縫い合わせる運用に疲れ、データを自社環境に置いたまま単一のフィードバックループで回したいチームだ。逆に、トレースだけあれば足りる段階のプロジェクトや、すでに特定ベンダーの評価基盤に深く依存している構成には向かない。README自身が「Nightly release for early testing」と明記しているため、まず./bin/installでスタックを立ち上げ、自分のエージェントをfi_instrumentationで計装してトレースが期待どおりの粒度で出るかを確認する。既存インストールにトレースが入っている場合は、アップグレード後に./bin/property-catalog-backfill --executeを実行しないと過去データが新しいカタログに載らない点を、導入前の検証項目に含めておきたい。
コミュニティノート