トレンドまとめ
Vibe Coding時代のAIエージェントOSS 7カテゴリ整理
「今追うべき AI エージェント OSS 7 選」のような記事をそのままランキングとして消費すると、判断を誤ります。orchestration が欲しくて記事を読んでいるのに、気づけば evaluation ツールと比較してしまう——そんな取り違えが起きるのは、TheAgency、promptfoo、Impeccable、OpenViking、nanochat、Heretic のようなプロジェクトが、同じ「AI エージェントツール」の箱に入っていても解いている問題（責務）がまったく違うからです。
本記事では、Fireship の動画で束ねられた周辺プロジェクト群を、公式 README や docs で確認できる範囲の役割にもとづいて 7 カテゴリに整理し直します。AIコーディングツール5カテゴリ比較 や LangChain完全ガイド と同じく、「人気順」ではなく「責務／surface で切る」という立場を、OSS レイヤーに適用する形です。
先に結論を書きます。複数 agent を回し始めたチームであれば、この 7 カテゴリのうち最初に production の主線へ入れるべきは eval / red team（promptfoo 型）だと私は考えます。orchestration（TheAgency 型）で agent 数を増やすより先に評価基盤を置くべきで、design skill と context DB は「詰まってから」足せばよい。そして social simulation・nanochat・Heretic の 3 つは、価値があっても production の主線には入れず、権限・予算・法務・レビュー責任を分けた research track に隔離すべきです。
ただしこの順序主張には境界があります。まだ agent を 1 つしか動かしていない段階なら、評価より先に「何を正本にするか」の明文化が要ります。この記事は、その線引きを README レベルの事実から組み立てる素振りです。
前提
機能、対応モデル、課金、配布方法は変化が速いため、導入前に必ず各プロジェクトの current docs / README を確認してください。ガードレール除去や red team 系のツールは、技術的に可能でも、組織ポリシーや法務レビューを通した上で扱う必要があります。
前提：2つの定義と5つの問い
この記事を駆動する定義は 2 つです。
責務による切り分け——そのOSSが解いている問題が、orchestration（複数agentの運用）・evaluation（出力の評価）・design（生成UIの補正）・context（記憶の管理）・training（モデル育成）・research（安全境界の検証）のどれかという区分です。同じ「AIエージェントOSS」でも責務が違えば置き換え関係にはなりません。TheAgency vs promptfoo は比較対象ではなく、両方要る組み合わせです。
production track と research track の境界——あるツールの出力を評価軸で測れるか、データの出所（provenance）が明確か、組織の法務・ポリシーと衝突しないか、の3点で判定します。この3点を満たさないカテゴリは、どれだけ見た目が派手でも production の主線には置きません。
この2つの定義を使うと、次の5つの問いに答えられるようになります。何を自動化したいのか。正本（repo、rules、knowledge file、eval結果）をどこに置くか。production flow に入れるのか research sandbox に留めるのか。diff・eval failure・法務例外を誰が承認するのか。利用規約やデータの扱いは組織ルールに合うか——この5問への回答が、後段のカテゴリ選びの実質です。
7カテゴリの地図
| カテゴリ | 代表例 | README / docs で確認しやすい役割 | 導入前に見るべきこと |
|---|---|---|---|
| Multi-agent development framework | TheAgency | Claude Code 上で複数 agent、workstreams、knowledge、quality gate を運用する枠組み | repo 規約、handoff、human approval、作業分担 |
| Eval / red team | promptfoo | LLM app の評価、比較、red teaming、CI/CD 連携 | 評価データ、security review、CI への組み込み |
| Design skill / anti-pattern guard | Impeccable | frontend design 用の skill bundle と design anti-pattern の検出 | 既存 design system との相性、導入先ツール、レビュー責任 |
| Context database | OpenViking | memory / resources / skills を filesystem 的に扱う context 管理 | storage 設計、retrieval 可観測性、provider 依存、運用負荷 |
| Simulation sandbox | social simulation 系プロジェクト | 複数 agent に外部シグナルを渡して議論させる実験環境 | データの出所、評価方法、言語対応、production との距離 |
| Model training harness | nanochat | tokenization から pretraining、finetuning、evaluation、chat UI までを含む実験基盤 | GPU 予算、学習データ、再現性、研究体制 |
| Safety-bypass research tool | Heretic | safety alignment / censorship removal を自動化する研究ツール | 組織ポリシー、法務、隔離環境、用途制限 |
production寄り2カテゴリを深掘りする
TheAgency — multi-agent development framework
TheAgency の README は、Claude Code 上で複数 agent を動かし、agent knowledge、workstreams、principals、quality gates を持つ convention-over-configuration な multi-agent framework として整理しています。ここで重要なのは、「agent を増やせること」ではなく、知識をどこに蓄積し、handoff をどう記録し、人間がどこで承認するかが先に定義されている点です。この順序——役割分担よりも handoff と承認点が先——こそが、evaluation より前に orchestration を置くのは早計だという本記事の主張の根拠になります。
個人的には、この手のフレームワークで最初につまずくのは「agentの数」ではなく「規約の不在」だと考えています。knowledge fileやhandoffの置き場所を先に決めないままagentを増やすと、session をまたいだ瞬間に再現性が崩れる——これは multi-agent 系ツール全般に共通するリスクであり、TheAgency の README が handoff と承認点を先に定義しているのは、その落とし穴への対処として理にかなっていると見ています。
| 論点 | 見るべきこと |
|---|---|
| 役割分割 | 何人分の agent を置くかではなく、どの責務で切るか |
| handoff | 依頼・成果物・次 action をどこへ残すか |
| 品質 gate | tests / lint / review を agent 任せにしすぎないか |
| 人間の承認点 | commit、push、PR、deploy のどこで止めるか |
promptfoo — eval / red team
promptfoo の README では、LLM evals & red teaming を主目的にした CLI / library として整理されており、モデル比較、vulnerability scanning、CI/CD integration まで含めて運用できるようになっています。現在は OpenAI の一部ですが、README と company update では open source / MIT license は維持すると明記されています。
私は、複数 agent を回し始めたチームであれば、TheAgency のような orchestration より先に promptfoo のような評価基盤を production の主線に置くべきだと考えます。理由は単純で、生成品質と安全性を測れないまま agent の autonomy だけ増やすと、後で問題を回収するコストが跳ねるからです。何を良い出力とみなすかが定義されていない状態で agent 数を増やすのは、物差しのないまま生産量を増やすのに近い。
この順序を強調したいのは、評価軸を後回しにしたまま agent の自動化度だけを上げていくと、問題が表面化した時点ではすでに出力量が積み上がっており、どこから見直すべきかの切り分け自体が難しくなると考えるからです。逆に言えば、eval を CI に組み込んでおけば、少なくとも「何が悪化したか」を後から機械的に特定できる状態を保てます。この非対称性——後から気づくコストと先に仕込むコストの差——が、evaluation を orchestration より先に置くべきだという立場の根拠です。
| 論点 | 見るべきこと |
|---|---|
| 評価軸 | 何を良い出力とみなすかが先に定義されているか |
| 失敗時の運用 | eval failure を誰が直すか |
| provider 差分 | model ごとに同じ prompt をそのまま比較してよいか |
| security scope | red team の対象をどこまで広げるか |
evaluation の中身をさらに深掘りしたい場合は、AIエージェントのセキュリティとpromptfoo で identity・権限・監視までの4層として展開しています。本記事は「7カテゴリの中でどこに置くべきか」の側を扱い、evalそのものの設計はそちらに委ねます。
補強2カテゴリは「詰まってから」でよい
Impeccable — design skill / anti-pattern guard
Impeccable は README上、frontend design に特化した skill bundle と anti-pattern detector として説明されています。18個の command と、typography / color / motion / responsive design などの reference を持つ構成です。runtime の agent platform ではなく、生成済みの UI をどの観点で直すかを AI に教える design skill と見るのが正確です。生成 UI が似たり寄ったりになってから足せば十分で、最初から常設する必要はありません。
| 論点 | 見るべきこと |
|---|---|
| 正本 | Figma / design tokens / 実装済み CSS のどれを正本にするか |
| 対象ツール | Cursor、Claude Code、Codex などどこで使うか |
| 人手レビュー | 見た目の一貫性を誰が最終判断するか |
OpenViking — context database
OpenViking の README は、memory / resources / skills を viking:// の filesystem paradigm で扱う context database として整理しています。tiered context loading、recursive retrieval、visualized retrieval trajectory が中心概念です。長く動く agent が context を食い散らかし始めてから導入を検討すれば足りるカテゴリで、導入コストは軽くありません。
| 論点 | 見るべきこと |
|---|---|
| 導入コスト | provider、storage、server 運用を許容できるか |
| 境界 | 既存 RAG / vector DB とどう共存させるか |
| 可観測性 | retrieval のログを誰が見るか |
research track に隔離すべき3カテゴリ
ここからは、production の中心より研究や検証で隔離して扱う方が安全なカテゴリです。判定基準は先に定義した3点——評価軸で出力を測れるか、データの出所が明確か、法務・ポリシーと衝突しないか——です。
Simulation sandbox（social simulation系） は、外部データやニュースを複数 agent に渡して議論・予測させる実験環境です。動画で取り上げられた例のように見た目は派手ですが、外部データの出所が曖昧になりやすく、agent 間議論の見た目と予測精度は別問題です。評価軸を作れないまま production に置くのは、3条件のうち最初の1つで落ちます。
nanochat（model training harness） は、single GPU node で tokenization から pretraining、finetuning、evaluation、chat UI までを扱う experimental harness です。「すぐ使える coding agent」ではなく、小型 LLM を自前で育てる研究基盤であり、GPU 予算・学習データの権利・再現性のすべてを自分たちで持てて初めて意味を持ちます。
Heretic（safety-bypass research tool） は、language model の censorship や safety alignment を automatic に除去する研究ツールです。abliteration の最適化を自動化するもので、README自体が research feature と位置づけています。強い agent を作る近道ではなく、組織ポリシーや法務と衝突しやすく、危険出力の封じ込め設計と隔離環境・ログ管理を前提にしないと扱えないカテゴリです。
この3カテゴリをresearch trackに隔離すべきだという主張の根底にあるのは、「見た目の説得力」と「production投入に足る評価軸」は別軸だという考え方です。simulation sandbox は agent 間の議論が活発に見えても、それが予測精度の高さを意味するわけではなく、nanochat のような training harness は GPU予算・学習データの権利・再現性という前提条件が揃って初めて研究として成立します。派手さで判断するのではなく、3条件（評価軸・出所・法務適合）のどれか一つでも欠ければ隔離する、という基準の一貫性を優先すべきだと考えます。
再ソート：production主線への近さ × 導入コスト・法務リスク
本文で見た7カテゴリを、要約ではなく別の軸で並べ替えます。縦軸を「production主線への近さ」、横軸を「導入コスト・法務リスク」とすると、次のレバーが見えてきます。
- 主線に最初に入れる: 正本（repo規約・knowledge file）の明文化 → eval / red team（promptfoo）。ここは近さも高く、コストも相対的に低い。
- 必要になってから足す: design skill（Impeccable）、context database（OpenViking）。近さは中程度で、導入コストは用途次第で伸びる。最初から全部載せる必要はない。
- research trackに隔離する: simulation sandbox、model training harness（nanochat）、safety-bypass research tool（Heretic）。production主線への近さは低く、法務・予算・ログ管理のコストは高い。権限と予算とレビュー責任を分けて運用したほうが安全です。
この並べ替えから引けるレバーは1つです——評価軸を先に作れるカテゴリから主線に入れ、評価軸を作れないカテゴリは隔離する。7つの固有名詞を覚えるより、この1つの基準を持ち帰るほうが応用が効きます。
自分の持ち帰り
私は、複数agentを回し始めた段階のチームには、eval / red team を先に、design / context は詰まってから、simulation・training・safety-bypass研究系は隔離、という順序を勧めます。ただし境界は明確にしておきたい。まだ agent を1つしか動かしていない段階なら、この順序の前に「正本をどこに置くか」を明文化するほうが先です。評価すべき対象が定まっていないところに評価基盤を置いても、測るものがありません。
この地図をどのフェーズのチームに適用するかは、正本が明文化されているかどうかで大きく変わるべきだと考えています。正本が定まっていない段階で評価基盤やdesign skillを先に足しても、何を基準に評価するかが揺れたままになり、投資が空回りしやすい。だからこそ「正本の明文化が先、評価基盤はその後」という順序を、フェーズを問わない一般則ではなく、境界条件付きの推奨として持ち帰ってほしいと思います。
関連記事
参考リソース
- Fireship: code report - 7 new AI agent tools you need to know about
- TheAgency Starter - GitHub
- promptfoo - GitHub
- promptfoo joining OpenAI
- Impeccable - GitHub
- OpenViking - GitHub
- nanochat - GitHub
- Heretic - GitHub
本記事はネクサフローのAIトレンドシリーズの一部です。この地図が、ランキングとしてではなく、責務を見分けるための判断材料として使われることを願っています。
