all-agentic-architectures を採用前に読む: 35パターンの共通インターフェースと deterministic-picker の実際
35 production-grade agentic AI architectures (Reflexion, LATS, GraphRAG, MemGPT, Voyager, BrowserAgent, ...) — a Python library and runnable textbook with multi-provider LLM support and a 17-task benchmark leaderboard.
ひと目でわかる
- これは何？
- 35種のエージェント設計を単一の Architecture クラスにまとめ、17タスクのベンチマークで比較する Python ライブラリ兼実行可能な教科書。採用判断で確認すべきは、共通契約の範囲と、ノートブックが実行済みであるという主張の検証手段である。
- 誰に向いている？
- 35種のパターンを横並びで比較したい教育・調査目的の読者、および Reflection や ReAct のような単一パターンを .run(task) の共通契約で素早く試したい読者には向く。逆に、本番のエージェント基盤として長期運用する目的で採用する場合は、ノートブックの実行結果を自分の API キーで再現し、provider ごとの挙動差と deterministic-picker の採点ロジックが自分のタスクで妥当かを先に確かめる必要がある。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 86 日前です。
- 何の言語で書かれている？
- 主に Jupyter Notebook です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
35のパターンを1つの .run(task) に畳むという設計判断
このリポジトリが解こうとしているのは、エージェント設計の比較が困難という問題である。Reflection、LATS、GraphRAG、MemGPT といったパターンは論文ごとに実装の形が異なり、同じタスクで並べて評価しようとすると、入出力の形を揃える作業だけで比較の意味が薄れる。README は「Same .run(task) interface across all 35 architectures」と述べており、すべてのパターンが Architecture クラスとして同じ契約を実装し、ArchitectureResult という同じ戻り値の形を返す。対象読者は、複数のパターンを実際に動かして違いを見たい開発者と、パターンの理論を実行結果と突き合わせて読みたい学習者である。パターン名をクラス名に置き換えるだけで下流のコードを変えずに済む、というのがこの統一の実利になる。
deterministic-picker が採点の平坦化にどう対処するか
リポジトリが技術的な中心に置いているのが deterministic-picker パターンである。README の説明では、LLM を評価者として使う箇所すべてで、LLM には真偽値や列挙型といったカテゴリカルな特徴だけを確定させ、最終的な判定信号は Python 側で組み立てる。理由は LLM-as-Scorer がスコアを狭い帯域に押し込めてしまう病理で、10点満点を求めても 7 から 9 の間に収束し、パターン間の差が見えなくなる。この規律は35アーキテクチャのうち13で適用され、残り9は設計上そもそもこの問題の影響を受けないと README は説明している。採点を LLM の自由記述に任せず、判断の合成を決定的なコードに移すという発想であり、ベンチマークの数値を読むときは、この層がどこにあるかを意識しないと順位の意味を誤読する。
LangGraph の状態機械の上に何を載せているか
実装の土台は LangGraph の状態機械である。各パターンは状態遷移として表現され、反復や分岐の制御はそのグラフに乗る。README のクイックスタートにある Reflection の例では、llm、max_iterations、target_score の3つを渡し、run の戻り値から result.output と result.metadata["final_score"] を取り出している。つまり反復回数と目標スコアという、パターンの挙動を決める主要なノブがコンストラクタの引数として露出している。マルチプロバイダ対応も特徴で、Nebius、OpenAI、Anthropic、Groq、Ollama、Together、Fireworks、Mistral、Google の9社が列挙されている。LLM の取得は get_llm() という単一の入口に集約されており、プロバイダの切り替えがアーキテクチャ側のコードに波及しない構造になっている。
インストールと実行: extra 指定と .env のキー
インストールは extra で機能を選ぶ形である。README のクイックスタートは pip install "agentic-architectures[nebius,faiss,tavily]" を示しており、検索に Tavily、ベクトル検索に faiss、既定のプロバイダに Nebius を想定している。クローンから始める場合は python -m venv .venv で仮想環境を作り、pip install -e ".[dev,test,docs,nebius,faiss,tavily,networkx]" を実行し、cp .env.example .env のうえで NEBIUS_API_KEY などを記入する。README はこの手順のあとに pytest -q を実行すると283件のテストが約30秒で通ると記載しているが、これは著者環境での記述であり、自分のマシンで同じ時間になる保証はない。GraphRAG や Graph Memory を使うなら networkx の extra が必要になる点は、依存を絞りたい場合に見落としやすい。
ノートブックが「実行済み」であるという主張の扱い方
このリポジトリの売りは、各パターンに fully executed な Jupyter Notebook が付属し、その理論が合成例ではなく取得済みの実行結果に対して書かれているという点である。README の表は MOCKED RUNS を 0 と掲げている。ただし、ここで読者が確認できるのは著者の実行記録が残っているという事実までで、自分の API キーとモデルで同じ出力が得られるかは別問題である。プロバイダやモデルのバージョンが変われば、同じノートブックでも記録された出力は再現しない。採用検討の段階では、自分のタスクで1つか2つのノートブックを上から順に実行し、記録との差がどこで生じるかを眺めるほうが、リポジトリ全体の信頼性を測る近道になる。
17タスクのベンチマークを成熟度の証拠と読まない
17のベンチマークタスクとリーダーボードは、パターン選択の材料として用意されている。ただしタスク数とアーキテクチャ数は同じではなく、リーダーボードは各アーキテクチャを関連するタスクに対してのみ並べる形式だと README は説明している。つまり全パターンが全タスクで採点されているわけではない。加えて、ベンチマークの数値は deterministic-picker の合成ロジックに依存するため、採点基準を変えれば順位も変わりうる。リーダーボードを「どのパターンが優れているか」の結論として読むのではなく、自分のタスクに近いタスクでどのパターンが候補になるかを絞る入口として使うのが妥当である。
LangGraph を直接使う場合との違い
比較対象として素直なのは、LangGraph を自分で組む場合である。LangGraph は状態機械を構築するための汎用の道具で、ノードとエッジの設計、状態のスキーマ、チェックポイントの扱いをすべて自分で決める。all-agentic-architectures はその上に、文献で名前の付いた35のパターンを既製のクラスとして載せ、入出力の契約を揃えたものである。得られるのは比較のしやすさと、パターンごとの実装を読む手間の削減であり、失うのは制御の細かさである。たとえば反復の停止条件を独自の指標で決めたい場合、既製クラスの引数で足りなければ結局は中身を読んで書き換えることになる。逆に、ReAct や Reflection のような枯れたパターンを1つだけ試したいなら、状態機械を一から設計するより速い。
向かないケースと、採用前に確認する3点
向かないのは、エージェントの実行を本番のワークロードとして長期運用し、再現性と監査を厳しく求める場合である。ノートブックの出力は著者の実行時点の記録であり、モデルの更新で挙動が変わる。また9社のプロバイダを列挙しているが、すべてのアーキテクチャが全プロバイダで同じように動く保証は README からは読み取れない。採用前に確認すべきは、第一に自分のタスクに近いノートブックを自分のキーで実行し記録との差を見ること、第二に deterministic-picker が適用されていない22のアーキテクチャのうち、自分が使うものの採点がどう決まるかをコードで確認すること、第三に networkx や faiss など extra の依存が自分の環境で許容できるかである。ライセンスは MIT で、表示を残せば改変と再配布が認められる。ただしノートブックに含まれる第三者モデルの出力やデータの扱いは別途確認が必要で、ここは法的助言ではなく確認事項の提示にとどめる。
編集部の結論
35種のパターンを横並びで比較したい教育・調査目的の読者、および Reflection や ReAct のような単一パターンを .run(task) の共通契約で素早く試したい読者には向く。逆に、本番のエージェント基盤として長期運用する目的で採用する場合は、ノートブックの実行結果を自分の API キーで再現し、provider ごとの挙動差と deterministic-picker の採点ロジックが自分のタスクで妥当かを先に確かめる必要がある。MIT ライセンスなのでコードの流用は可能だが、ノートブックに記録された出力はあくまで著者の実行時点のものであり、自分の環境での再現性を保証するものではない。
コミュニティノート