Vibe Coding時代のAIエージェントOSS 7カテゴリ整理

Vibe Coding 周辺では「今追うべき AI エージェント OSS 7 選」のような記事が増えています。ただ、実務で重要なのはどの repo が一番バズっているかではなく、その OSS が何の責務を持ち、どこまで production flow に入れてよいかです。

TheAgency、promptfoo、Impeccable、OpenViking、nanochat、Heretic のようなプロジェクトは、同じ「AI エージェントツール」という箱に入っていても役割がまったく違います。さらに、social simulation のように research 寄りで、日常開発の中心には置きにくいカテゴリもあります。

本記事では、Fireship の動画で話題になった周辺プロジェクト群を、そのまま「2026 年最新ランキング」として消費するのではなく、7 つのカテゴリに分けて整理します。各カテゴリについて、公式 README や docs で確認できる範囲の役割と、導入前に見るべき論点をまとめます。

---

この記事でわかること

1. 7カテゴリの違い: multi-agent framework、eval/red team、design skill、context DB、simulation sandbox、model training harness、safety-bypass research tool は何が違うのか
2. 導入前の判断軸: source of truth、評価、権限、法務、運用責任をどう見るべきか
3. 現実的な導入順: どこから試し、どこを research 用に隔離すべきか

基本情報

---

まず結論: 7カテゴリは同じ土俵にいない

最初に押さえたいのは、ここで扱う 7 カテゴリが同じ problem を解いているわけではないという点です。

この表からわかるように、TheAgency vs promptfoo や OpenViking vs nanochat は、置き換え関係ではありません。比較する前に、自分が欲しいのは orchestration なのか、evaluation なのか、memory なのか、research sandbox なのかを分ける必要があります。

---

先に答えるべき 5 つの質問

ツール名より先に、次の 5 問に答えると判断がぶれにくくなります。

1. 何を自動化したいのか

2. source of truth はどこに置くのか

• repo と pull request を正本にするのか
• prompt / rules / knowledge file をどこで管理するのか
• context store を別で持つのか
• 実験結果や eval を CI に戻すのか

特に TheAgency や OpenViking のようなツールは、agent が何を参照し、何を学習済みの前提にするかをファイルや階層として管理します。ここが曖昧だと、agent 数を増やしても再現性が出ません。

3. production flow に入れるのか、research sandbox に留めるのか

この線引きは早めに決めるべきです。

• promptfoo は production flow に組み込みやすい
• Impeccable は design review の補助として入りやすい
• OpenViking は長期運用で効くが、導入はやや重い
• social simulation 系、nanochat、Heretic は research 寄りで、production の中心には置きにくい

4. 誰がレビュー責任を持つのか

導入の成否は「賢さ」より誰が承認するかで決まりやすいです。

• agent が作った diff を誰が見るか
• eval failure を誰が triage するか
• security / policy 例外を誰が許可するか
• model training の dataset と compute を誰が管理するか

5. 法務・ポリシー上の境界は明確か

特に red team、guardrail removal、独自モデル学習は、技術判断だけでは終わりません。

• 利用規約に反しないか
• 学習データやログの扱いが組織ルールに合うか
• 危険な出力をどう隔離するか
• 実験結果を production 環境へ持ち込む条件は何か

---

実務で試しやすい4カテゴリ

ここでは、比較的 production flow に近づけやすい 4 カテゴリを見ます。

1. TheAgency — multi-agent development framework

TheAgency の README は、Claude Code 上で複数 agent を動かし、agent knowledge、workstreams、principals、quality gates を持つconvention-over-configuration な multi-agent frameworkとして整理しています。

ここで重要なのは、「agent を増やせること」よりも、knowledge をどこに蓄積し、handoff をどう記録し、人間がどこで承認するかが先に定義されている点です。

向いている場面

• repo ごとの規約を agent に継続的に覚えさせたい
• 複数 task を役割分担させたい
• knowledge file や worklog を使って、session をまたいで学習を蓄積したい

先に確認したい論点

2. 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 は維持すると明記されています。

向いている場面

• prompt や model の変更を勘で決めたくない
• prompt injection や leakage のような脆弱性を継続的に見たい
• PR や CI に eval 結果を載せたい

先に確認したい論点

3. Impeccable — design skill / anti-pattern guard

Impeccable は README 上で、frontend design に特化した skill bundle と anti-pattern detector として説明されています。18 個の command と、typography / color / motion / responsive design などの reference を持つ構成です。

つまり Impeccable は runtime の agent platform ではなく、生成済みの UI をどの観点で直すかを AI に教える design skillと見るのが正確です。

向いている場面

• Vibe Coding で作った UI が似たり寄ったりになる
• 既存の design system に合わせた修正プロンプトを毎回書きたくない
• a11y、spacing、motion、copy をレビューの観点として揃えたい

先に確認したい論点

4. OpenViking — context database

OpenViking の README は、memory / resources / skills を viking:// の filesystem paradigm で扱う context database として整理しています。tiered context loading、recursive retrieval、visualized retrieval trajectory、automatic session management が中心概念です。

従来の「vector DB に全部入れる」より、agent が扱う context を階層化し、何をどの粒度で読み込んだかを追跡したいときに意味が出ます。

向いている場面

• 長く動く agent が context を食い散らかしている
• memory、docs、skills を別々に持っていて統一できていない
• retrieval の経路が見えず、なぜ誤答したか説明しにくい

先に確認したい論点

---

research 寄りで扱うべき3カテゴリ

ここからは、production の中心より研究や検証で隔離して扱う方が安全なカテゴリです。

5. Simulation sandbox — social simulation 系

このカテゴリは、外部データやニュース、イベントを複数 agent に渡して、議論や予測をさせるタイプの実験環境です。動画で取り上げられた例のように見た目は派手ですが、実務で必要なのは「賢そうに議論すること」ではなく、その出力をどう評価し、どこまで意思決定に使えるかです。

production に直結しにくい理由

• 外部データの provenance が曖昧になりやすい
• agent 間議論の見た目と、予測精度は別問題
• domain knowledge が強く必要で、汎用ツールとしては使いにくい
• docs や maintainer activity が薄いと評価しづらい

6. nanochat — model training harness

nanochat の README では、single GPU node で tokenization、pretraining、finetuning、evaluation、inference、chat UI まで扱える experimental harness として説明されています。これは「すぐ使える coding agent」というより、小型 LLM を自前で育てる研究基盤です。

向いている場面

• SLM の学習・評価を end-to-end で理解したい
• dataset、hyperparameter、hardware の関係を実験したい
• API 利用ではなく、自社で小規模モデル研究を回したい

先に確認したい論点

7. Heretic — safety-bypass research tool

Heretic の README は、language model の censorship や safety alignment を automatic に除去する研究ツールとして書かれています。abliteration / directional ablation の最適化を自動化するもので、README 自体も research feature として位置づけています。

ここで重要なこと

このカテゴリは「強い agent を作る近道」ではありません。むしろ、production に安易に入れてはいけないカテゴリです。

• 組織ポリシーや法務と衝突しやすい
• 危険出力の封じ込め設計が必要
• 研究用途でも隔離環境とログ管理が必要
• 公開サービスや顧客向け導入の文脈では扱いが非常に重い

---

現実的な導入順はこの4段階

ランキングで消費するより、次の順で考えると失敗しにくくなります。

1. まず source of truth と役割分担を決める

repo、rules、knowledge file、PR review をどう回すかを決める段階です。ここでは TheAgency のような multi-agent framework の考え方が役立ちます。

2. 次に eval / red team を入れる

agent の autonomy を増やす前に、promptfoo のような評価基盤を先に入れた方が事故を減らせます。生成品質と安全性を測れないまま自動化だけ進めると、後で回収コストが跳ねます。

3. UI と context は、必要になった時点で足す

• 生成 UI の品質が問題なら Impeccable
• memory と retrieval が問題なら OpenViking

どちらも便利ですが、最初から全部載せる必要はありません。

4. research track は production track と分ける

nanochat や Heretic、social simulation 系は、実験として価値があっても production の主線とは別です。repo、権限、予算、レビュー責任を分けて運用した方が安全です。

---

よくある質問（FAQ）

Q1. promptfoo は OpenAI に加わった後も使えますか？

公式 README と company update では、OpenAI の一部になった後も open source / MIT license は維持すると案内されています。ただし、機能や商用プランの位置づけは変わりうるため、導入前に current docs を確認してください。

Q2. OpenViking はベクターDBの代わりになりますか？

完全な置き換えというより、agent が使う context を memory / resources / skills として整理する別レイヤーと見る方が正確です。既存 RAG と共存させる設計もあり得ます。

Q3. nanochat は安く自社LLMを作る近道ですか？

小型モデル研究の入口としては有力ですが、安い = 運用が簡単ではありません。GPU、データ、評価、再現性まで含めて回せる体制が必要です。

Q4. Heretic は agent の性能改善に使うべきですか？

一般的なプロダクト開発では推奨しません。研究用途でも、ポリシー、法務、隔離環境、ログ管理を前提に扱うカテゴリです。

Q5. まず何から試すのが現実的ですか？

多くのチームでは、repo 規約の明文化と eval / red team の整備から始めるのが現実的です。その後、必要に応じて design skill や context database を足すのが堅実です。

---

まとめ

Vibe Coding 周辺の OSS は、1 枚のランキング表に押し込むと判断を誤ります。TheAgency は orchestration、promptfoo は evaluation、Impeccable は design guard、OpenViking は context、nanochat は training、Heretic は research です。まずは何を自動化したいか、どこまで production に入れるかを分けて考えるべきです。

とくに durable な順で言えば、source of truth の整備 → eval / red team → 必要に応じた design / context 補強 → research の隔離という順で見ると、流行語に振り回されにくくなります。

---

関連記事

---

参考リソース

• 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トレンドシリーズの一部です。