エージェントハーネス——LLMを「動くエージェント」に変える実行環境——を自前で用意するのは、想像より重い作業です。エージェントを作ること自体は、もう難しくありません。難しいのは、それをまともに動かし続けることのほうです。ストリーミング、セッションの永続化、ツールサーバーの管理、危険な操作の前で人間に確認を取る仕組み、長時間タスクで膨れ上がるコンテキストの圧縮、そして人が触るためのUI——このあたりを毎回ゼロから作り直しているうちに、肝心のエージェントの中身に手が回らなくなります。
本記事で扱う TrueForge（トゥルーフォージ） は、その「実行ループ」の部分を丸ごと引き受けるOSSです。開発元はMLOps基盤を手がける TrueFoundry、ライセンスはMIT、TypeScript製。リポジトリの説明文は自らを「the runtime layer that turns an LLM into a working agent（LLMを動くエージェントに変えるランタイム層）」と定義しています。2026年7月23日公開という若いプロジェクトながら、8月20日時点で 1,874スター、直近のコミットは前日という速度で動いています。
エージェント基盤そのものの選択肢を横断的に見比べたい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証も合わせてどうぞ。本記事はそのうち「自分のサーバーで動かす実行基盤」という一点を深掘りします。
30秒でわかるTrueForge
・何ができるか：npx @truefoundry/trueforge の1コマンドで、チャットUI付きのエージェントサーバーが起動する。モデル・MCPサーバー・スキル・サンドボックスを画面から接続すれば、エージェントが組み上がる
・何を解決するか：セッション永続化・SSEストリーミング・ツール承認・コンテキスト圧縮といった「運用に必要だが本質ではない配管」を、自作しなくてよくなる
・何を代替できるか：Claude Managed Agentsのようなベンダーホスト型のエージェント基盤。モデルもツールも自分で選べる状態のまま、自社インフラに置ける
・注意点：ローカルモードは既定で認証なし。公式ベンチの「コスト削減率」は出典ごとに数字が違う（後述）
TrueForgeとは——「書く」フレームワークではなく「動かす」エージェントハーネス
ハーネス（harness） とは、モデルの周りを固めて「1回のAPI呼び出し」を「自律的に働くエージェント」に変える実行環境のことです。LLM本体が思考を担うなら、ハーネスは手足と作業机にあたります。ツールを呼ぶループ、ファイルを読み書きする場所、失敗したときのリトライ、履歴の管理——このレイヤの設計品質が、そのままエージェントの実用性を決めます。
この領域には既にいくつものOSSがありますが、TrueForgeの位置づけを掴むには、提供される「形」 で分けるのが早道です。
同じTypeScript製ハーネスであるFlueは、開発者が自分でコードを書いて組み立てるフレームワークで、成果物は自分のアプリケーションになります。対してTrueForgeは、起動した瞬間にチャットUIとHTTP APIが立ち上がるサーバーで、成果物は動いているサービスそのものです。「ハーネスを書きたい」のか「ハーネスを動かしたい」のか——この違いが、両者を選び分ける最初の分岐点になります。
TrueForgeが同梱するものは、大きく3つの入口に整理されています。
・チャットUI：ブラウザから直接エージェントと対話する標準画面。追加開発ゼロで使える
・HTTP API ＋ TypeScript SDK：@truefoundry/trueforge-sdk から、セッション・ターン・イベントをプログラムから制御する
・埋め込み用UI SDK：@truefoundry/trueforge-ui を自社アプリに組み込み、チャット画面ごと持ち込む
パッケージ構成とライセンスは、実際に各 package.json を確認すると次の通りでした。すべてMITで、有償版に機能を残す「オープンコア」型ではありません。
| パッケージ | バージョン | ライセンス | 役割 |
|---|---|---|---|
@truefoundry/trueforge |
0.1.4 | MIT | サーバー本体（npx で起動するのはこれ） |
@truefoundry/trueforge-core |
0.1.4 | MIT | 実行ループ・サンドボックス抽象などのコア |
@truefoundry/trueforge-sdk |
0.1.3 | MIT | TypeScriptクライアント |
@truefoundry/trueforge-ui |
0.2.4 | MIT | 埋め込み用UIコンポーネント |
Helm chart trueforge |
0.1.5 | MIT | Kubernetes配布 |
確認した版：本記事の記述は、2026年8月20日時点の main（コミット cc1e8316）と npm 公開版 @truefoundry/[email protected] に基づきます。公開1か月未満で更新が速いプロジェクトのため、細部は追随して変わる可能性があります。
インストールと起動：ローカルモードとホストモードの分かれ道
TrueForgeは、動かし方が明確に2つに分かれています。ローカルモードはSQLite1ファイルで完結し、追加のインフラがいりません。ホストモードはPostgresとRedisを前提に、Docker ComposeまたはHelmで複数レプリカを走らせます。
| モード | 想定用途 | ストレージ | 追加インフラ | 起動方法 |
|---|---|---|---|---|
| ローカル | 個人利用・お試し | SQLite | 不要 | npx @truefoundry/trueforge |
| ホスト | チーム・複数レプリカ | Postgres | Postgres＋Redis | Docker Compose または Helm |
ローカルモードは、Node.js 22.13以上があれば1行です。
npx @truefoundry/trueforge
CLIのヘルプを実行すると、既定ポートとモードの扱いが確認できます。
npx @truefoundry/trueforge --help
# Usage:
# npx @truefoundry/trueforge
# npx @truefoundry/trueforge --port <n>
#
# TrueForge v0.1.4. Start the agent server.
# Defaults to standalone mode (SQLite, no Redis) — local use only, not production-safe.
# Set STANDALONE=false with Postgres and Redis for multi-replica peering.
#
# Options:
# --port <n> HTTP port (default: 8790, or PORT env)
既定ポートは 8790、PORT 環境変数か --port で変更できます。SQLiteの置き場所は環境ごとの標準データディレクトリ配下（{env-paths data}/db/db.sqlite）で、SQLITE_PATH で上書きできます。チーム運用に移すときは STANDALONE=false を設定し、Postgres接続情報とRedisを与える——という切り替え方です。
実際に手元のmacOS（Apple Silicon・Node v22.13.1）で npx 起動を試したところ、起動バナーと警告枠、そしてローカルサンドボックスの検出ログまでは進みました。
TrueForge v0.1.4 · standalone
┌─ WARNING ────────────────────────────────────────────────────────────────┐
│ Standalone mode is intended for local use on your own machine. It is not │
│ hardened for production or shared internet access — please keep it on │
│ localhost. ... │
└──────────────────────────────────────────────────────────────────────────┘
info Local sandbox fallback is available {"platform":"darwin","shell":"/bin/bash","python":"..."}
手元環境での起動失敗について（TrueForge側の不具合ではありません）
このあと当方の環境ではプロセスが終了コード139（SIGSEGV）で落ち、HTTPリスンまで到達しませんでした。原因を切り分けたところ、TrueForgeが依存するネイティブモジュール better-sqlite3 13.0.3 が単体でもクラッシュすることが確認できました。TrueForgeを介さず node -e "new (require('better-sqlite3'))(':memory:')" を実行するだけで同じ139が再現します。プリビルドバイナリのアーキテクチャ（darwin-arm64 / Mach-O arm64）とNodeのarm64は一致しており、アーキ不整合ではありません。この事象はTrueForgeの実装に起因するものではないため、本記事では「動かなかった」ではなく「当環境のネイティブモジュールの問題で最終確認まで到達できなかった」と記録します。同種の症状に当たった場合は、Docker Composeでの起動（ネイティブモジュールをコンテナ内でビルド済みの状態にする）が回避策になります。
ハーネスが肩代わりする機能：モデル・MCP・スキル・サンドボックス
TrueForgeの設計思想は、「最初にカタログから接続しておけば、あとはエージェントがそこから選ぶ」という点にあります。モデルプロバイダ、MCPサーバー、スキル、サンドボックスをそれぞれ一度設定すると、エージェントを作るときはメニューから選ぶだけになります。プリセットは同梱のYAMLカタログから供給され、必要なら差し替えられます。
・モデル：OpenAI・Anthropic・Google Gemini などのカタログ提供元に加え、OpenAI互換エンドポイントなら何でも接続できる
・MCPツール：リモートMCPサーバーをヘッダー認証またはOAuthで接続。チャット画面内で認可を通す導線もある
・スキル：SKILL.md 形式の指示書パックをgit管理し、必要になった時点でサンドボックスへ読み込む
・サンドボックス：コードとファイル操作の隔離実行。必要になったときだけ確保され、認証情報はハーネス側に留まる
長時間タスクで効いてくるのが、コンテキスト側の作り込みです。サブエージェントへの分割、ツール定義の遅延読み込み、Code Mode、巨大なツール応答の外出し、履歴の圧縮（compaction）——このあたりが最初から揃っています。エージェントのコンテキスト管理をどう設計するかという論点そのものについては、OpenViking入門：AIエージェントのコンテキスト管理をファイルシステムで変えるByteDance発OSSの仕組みで別のアプローチを扱っています。
人間が介在するポイントも、機能として定義されています。ツール実行前の承認、エージェントから人間への質問（ask-user-questions）、そしてチャット内に操作可能なUIを生成するGenerative UIの3つです。
全体の構成と1ターンの流れ
TrueForgeを構成する要素と、1回のターンが流れる経路を整理すると次のようになります。
compaction / 大容量応答の外出し"] end subgraph store["永続化"] SQLITE["SQLite（ローカル）"] PG["Postgres + Redis（ホスト）"] end subgraph byo["自前で接続するもの"] MODEL["モデルプロバイダ"] MCP["MCP サーバー"] SBX["サンドボックス
Daytona / ローカルSRT"] end UI --> API SDK --> API EMB --> API API --> LOOP LOOP --> CTX LOOP --> MODEL LOOP --> MCP LOOP --> SBX API --> SQLITE API --> PG
ポイントは、モデル・ツール・サンドボックスがすべて「持ち込み（bring your own）」であることです。ハーネス側はどれにもロックインせず、接続先を差し替えられる状態を保ちます。認証情報はハーネス側に留まり、サンドボックスへ渡らない設計になっています。
長時間ターンの扱いにも実装上の作法があります。TrueForgeはターンのイベントをSSEでストリーミングしますが、数分かかるタスクではストリームが先に閉じることがあり、その場合もサーバー側の処理は続きます。公式ベンチのアダプタは、終端イベント turn.done を受け取らずにストリームが終わったときはターンの状態をポーリングして終端まで追う実装になっています。自前クライアントを書くなら同じ処理が必要で、これを怠ると長いタスクが「空の回答」として失敗扱いになります。
サンドボックスの実体：READMEに書かれていないローカル実行系
ここは、READMEだけを読んでいると見落とす部分です。READMEはサンドボックスについて「Daytona today; more providers planned（現時点ではDaytona、他は計画中）」とだけ書いています。ところがリポジトリの packages/trueforge/src/sandbox/ を開くと、Daytona連携とは別に local/ ディレクトリ配下のローカルサンドボックス実装が存在します。
その実体は、package.json の依存を辿ると判明します。
grep -n "sandbox-runtime" packages/trueforge/package.json
# "@anthropic-ai/sandbox-runtime": "0.0.71",
Anthropicが公開しているサンドボックスランタイム（SRT）をバージョン固定で取り込んでいる、というのが答えです。隔離の仕組みはOSごとに分かれており、コード中のコメントと定数から次のように読み取れます。
| プラットフォーム | 隔離の仕組み | ホスト側に必要なバイナリ |
|---|---|---|
| Linux | bubblewrap（bwrap）＋ seccomp |
bwrap / socat / rg |
| macOS | seatbelt（グロブによる拒否指定が使えるため rg 不要） |
なし |
| Windows | 対応プラットフォームに含まれない | — |
対応プラットフォームを表す型は linux と darwin の2値のみで、Windowsは選択肢に入っていません。前掲の起動ログで Local sandbox fallback is available {"platform":"darwin", ...} と出ていたのは、まさにこのローカルサンドボックスがmacOS上で利用可能だとサーバーが判定した瞬間のログです。
MicroVMによる隔離という別解と比べたい場合は、CubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想が対照になります。TrueForgeのローカル実行はOS標準のサンドボックス機構（bubblewrap／seatbelt）を使う方式で、仮想マシン単位の隔離とはコストと強度のバランスが異なります。
公式ベンチマークの読み方：「コスト50%削減」を一次ソースで検算する
TrueForgeの発表で最も引用されているのが、Claude Managed Agents（以下CMA）に対するコスト優位性です。ただしこの数字は、どの資料を見るかで変わります。
プレスリリースは「エージェント運用コストを50%削減する」と述べていますが、算出根拠・比較条件・ベンチマーク手法の記載がありません。一方、公式ドキュメントのBenchmarkingページは同一モデル同士の比較として「約30%安い」と書いています。そして実測値そのものは、次の通りです。上3行はリポジトリ同梱の benchmark/README.md に載っている表、下2行（deepagents）は公式のBenchmarkingページのみに載っている行です（試行数はいずれも各構成3試行）。
| 構成 | 試行数 | 正解数 / 14 | コスト | トークン |
|---|---|---|---|---|
| Claude Managed Agents · Opus 4.8 | 3 | 10.7 | $11.8 | 10.0M |
| TrueForge · Opus 4.8 | 3 | 10.7 | $8.6 | 3.7M |
| TrueForge · GLM-5.2 | 3 | 11.7 | $3.0 | 3.8M |
| deepagents · Opus 4.8 | 3 | 10.0 | $21.2 | 16.5M |
| deepagents · GLM-5.2 | 3 | 12.0 | $9.1 | 11.9M |
同一モデル（Opus 4.8）で比べると $11.8 → $8.6、つまり 約27%減 です。プレスリリースの50%とは一致しません。では50%はどこから来たのか——公式資料の中で50%を超えるのは、モデルを GLM-5.2に載せ替えた $3.0（約75%減） だけです。これは安いモデルを使った効果であって、ハーネスを替えた効果ではありません。同一モデルでの純粋なハーネス比較なら約27〜30%、というのが一次ソースから言える範囲です。エージェント用途でどのモデルを選ぶかという論点自体が効いてくることは、Kimi K2.6のエージェント運用のようなオープンモデル側の進化を見ても分かります。
ベンチマークの手法：ここは丁寧に作られている
数字の解釈には注意が要る一方で、測り方そのものは誠実に設計されています。リポジトリの benchmark/ に手法がすべて入っており、隠し味がありません。
・データセット：DevRevが公開したEnterprise-BenchのL1-L2タスク群（14タスク）。TrueFoundry側は再配布せず、DevRevの公開物を参照させる方式
・タスクの性質：Jira風のプロジェクト管理・Salesforce風のCRM・Drive風の文書ストアという3つのMCPサーバーをまたいで結合が必要な業務クエリ
・公平性：全アームに同一のシステムプロンプトと同一のタスクプロンプトを与える。タスク固有のヒントなし
・採点：ブラインドLLM審査。審査側は判定基準と回答しか見えず、正解値もどのアームの回答かも知らされない。全基準を満たした場合のみ合格で部分点なし
・試行数：各構成3試行。「セルごとの数字ではなく形を再現してほしい」と明記されている
なぜトークンが減るのか
コスト差がどこから来るのかを、公式ドキュメントは3点に整理しています。ツール呼び出し回数の削減（同じ結果に到達するまで1タスクあたり19回。他の2つは32回と40回）、履歴を再送せず圧縮すること、そして1ターンあたりのコンテキストを軽く保つことです。
ここは仕組みとして納得できる話です。エージェントが同じ課題を解くとき、ツールを呼ぶたびにそれまでの全履歴を再度モデルへ送る素朴な実装だと、ステップ数の2乗に近い勢いで入力トークンが膨らみます。TrueForgeが備える compaction（古い履歴の要約）と large_tool_response（巨大なツール応答をサンドボックスのファイルへ退避し、モデルには参照だけ渡す）は、この膨張を断ち切るための機構です。ベンチ設定で compaction のしきい値が60,000、反復上限が500に設定されているのも、「長く走るが文脈は太らせない」という同じ思想に沿っています。
つまりTrueForgeの主張は「モデルが賢いから安い」ではなく「同じモデルに同じ仕事をさせるとき、無駄な入力を送らないから安い」という構造的なものです。この理屈自体は検証可能で、実際に同一モデル・同一タスク・同一プロンプトで正解数が並んだ（10.7対10.7）という結果とも整合します。
表を読むときの2つの注意点
その上で、コードまで読むと注意すべき点が2つあります。
1つ目は「Cost / run」の単位です。 集計スクリプト aggregate.py は、コストとトークンを {アーム × タスク × 試行} のセル単位で平均 しています。つまり $8.6 は1タスク1セッションあたりの金額であり、14タスクを通しで走らせた総額ではありません。14タスク分なら単純計算で$120前後になります。「ベンチ全体が$8.6で回る」と読むと1桁ずれます。
2つ目はトークン列の正規化です。 コスト計算はフレームワークごとのトークン報告の違いを吸収しています（TrueForgeとdeepagentsは input が総プロンプト量でキャッシュ読み書きがその内訳、CMAは input が既にキャッシュ除外後の値、という差を INPUT_IS_TOTAL で補正）。ところが表に出るトークン列のほうはこの補正を通さず、単純に input + output を足しています。したがって「10.0M vs 3.7M」というトークン比較は、コスト比較ほど厳密に揃った数字ではありません。コスト側は補正済みなので、比較に使うならコスト列のほうが安全です。
なおコスト単価はOpus 4.8の既定値として、入力$5・出力$25・キャッシュ読み$0.5・キャッシュ書き$6.25（いずれも100万トークンあたり）が使われています。
再現するにはサンドボックスが要る：ベンチ設定は巨大なツール応答をサンドボックスのファイルへ退避する large_tool_response を有効にしています。公式READMEは「ここを忘れる人が多い」と明記しており、サンドボックス未設定だとコンテキストが予算を超えて max_tokens breached でターンが中断します。反復上限500、compactionしきい値60,000という設定値も併記されています。
類似エージェントハーネスとの比較：どれを選ぶか
「エージェントハーネス」を名乗るOSSは既に複数あります。当サイトで扱ってきたものと並べると、選択の軸が見えてきます。
| プロジェクト | 提供の形 | 言語 | 起動して得られるもの | 向いている人 |
|---|---|---|---|---|
| TrueForge | サーバー | TypeScript | チャットUI＋HTTP API＋SDK | まず動く実行基盤とUIが欲しい |
| Flue | フレームワーク | TypeScript | 自分で書いたアプリ | コードでハーネスを組み立てたい |
| OpenHarness | 実装参照型 | — | Claude Code的な仕組みの理解と再利用 | 内部構造を学び自作に活かしたい |
| Claude Managed Agents | マネージドサービス | — | ベンダーホストの実行環境 | 運用を持ちたくない |
TrueForgeを選ぶ理由がはっきりするのは、次のような状況です。
・UIまで含めて必要：エンジニア以外もエージェントを触る前提があり、チャット画面を自作したくない
・モデルを固定したくない：商用モデルとオープンモデルを状況で使い分けたい。ベンチの$3.0構成のような選択肢を残したい
・自社インフラに置きたい：データの所在やネットワーク境界の要件があり、ベンダーホストでは通らない
・承認フローが要る：ツール実行前に人間のレビューを挟む業務要件がある
逆に、エージェントのループそのものを自分で設計したいなら、サーバーを丸ごと受け取るTrueForgeは重すぎます。その場合はフレームワーク型のほうが素直です。既存のコーディングエージェントをそのまま使いたいだけなら、OpenHands完全ガイド：SWE-Bench 77.6%のOSS AIコーディングエージェント徹底解説のような完成品を選ぶほうが早いでしょう。
セルフホストで確認しておくこと
最後に、自社で動かす前に把握しておきたい点を挙げます。いずれも公式ドキュメントとコードの実装から確認したものです。
ローカルモードは認証なしが既定です。 READMEも起動バナーも「自分のマシン専用」「localhostに留めてほしい」と明示し、それを超えた使い方でのデータ損失や不正アクセスには責任を負わないと書いています。共有環境で使うならホストモードに切り替え、オプションのOIDCログインを設定するのが前提の運用です。
ただし、bind先の既定は安全側に倒れています。 ここは実装を確認する価値がありました。設定を読むと、HTTPのbindアドレス HOST の既定値は localhost（ループバック） です。全インターフェースに開く 0.0.0.0 は、コンテナイメージ側が明示的に設定したときにだけ適用されます。つまり「localhostに留めてほしい」という注意書きは、単なるお願いではなく既定の挙動として実装で担保されているということです。逆に言えば、HOST=0.0.0.0 を自分で設定した瞬間に、認証なしのエージェントサーバーがネットワークに露出します。
自分の環境で確認するなら、起動後に次を実行してリスンアドレスを見ておくと確実です。
# 起動中のTrueForgeがどのアドレスでリスンしているか確認する
lsof -nP -iTCP -sTCP:LISTEN | grep 8790
# 127.0.0.1:8790 または [::1]:8790 ならループバックのみ＝外部からは到達しない
# *:8790 または 0.0.0.0:8790 ならネットワークに露出している
既定の HOST=localhost は名前解決の結果しだいでIPv4（127.0.0.1）にもIPv6（[::1]）にもなり得るため、表示が [::1]:8790 でも「ループバックに閉じている」と読んで問題ありません。判断すべきはアドレスがループバックか、全インターフェース（0.0.0.0 / *）かの一点です。
チーム運用に移すときの構成も、事前に決めておく必要があります。 リポジトリのルートには docker-compose.yml と charts/trueforge（Helmチャート、バージョン0.1.5）の双方が含まれており、単一ホストで完結させたいならCompose、Kubernetes上で複数レプリカを回すならHelmという分岐になります。ホストモードで追加されるのはPostgres（セッションやエージェント定義の永続化）とRedis（レプリカ間のピアリング）で、STANDALONE=false を設定した時点でこの2つが必須になります。ストレージ層はSQLiteとPostgresで別実装（コード上も別のスキーマ定義を持つ）なので、ローカルで貯めた検証データを引き継ぐ前提で計画を立てるなら、移行方法を先に確認しておくのが安全です。
サンドボックスの前提条件も確認しておきます。 Linuxでローカルサンドボックスを使うなら、ホストに bwrap（bubblewrap）・socat・rg（ripgrep）が必要です。Windowsは対応プラットフォームに含まれないため、WSL2かコンテナ経由になります。ホスト型のDaytonaを使う場合は外部サービスへの接続とAPIキー管理が加わります。
脆弱性の報告経路は用意されています。 リポジトリには SECURITY.md が置かれ、脆弱性は公開Issueではなくそちらの手順で報告するよう明記されています。自社の資格情報とツール権限を預けるコンポーネントである以上、この窓口の有無は導入判断の材料になります。
若いプロジェクトであることも織り込むべきです。 公開から1か月未満、バージョンは0.1.x台で、コードには「この設計は見直し中」という趣旨のコメントも残っています。本番投入を検討するなら、バージョンを固定し、アップデート時の破壊的変更を前提にした運用計画を立てるのが安全です。
まとめ
TrueForgeは、「エージェントを作る」のではなく「エージェントを動かし続ける土台を配る」タイプのOSSです。モデル呼び出しからサンドボックス、承認、コンテキスト圧縮、UIまでを1本のMITライセンスのサーバーに畳んだことで、自作すると数か月かかる配管をスキップできます。
一方で、宣伝される数字は分けて読む必要があります。同一モデルでのコスト差は約27〜30%であり、大きく見える約75%はモデル自体を安価なものへ載せ替えた結果です。プレスリリースの「50%」は、公式資料のどの数字とも一致しません。ただしベンチマークの手法そのものはリポジトリに全部置かれており、ブラインド審査・部分点なし・同一プロンプトという条件も明示されています。数字の引用の仕方に注意すれば、検証可能な素材としては質の高い部類です。
READMEが「Daytona today」としか書いていないサンドボックスに、AnthropicのSRTを使ったローカル実行系が既に入っている点も含め、このプロジェクトは公表資料より実装のほうが先行しています。評価するなら、READMEではなくリポジトリを開くのが正解です。
参照ソース
・truefoundry/trueforge — GitHub公式リポジトリ（README・benchmark/・packages/ の各 package.json と実装コード）
・TrueForge Documentation — Introduction（機能一覧・セットアップ手順）
・TrueForge Documentation — Benchmarking（公式ベンチマーク結果と削減率の記述）
・@anthropic-ai/sandbox-runtime — npm（ローカルサンドボックスが依存するランタイム）
・An open source rival to Claude Managed Agents just launched — The New Stack（launch報道）
