「エージェントAIの設計パターンを学びたいが、論文はどれも実装がバラバラで、結局どれがどのタスクに効くのか横並びで比べられない」——2026年、AIエージェントに本気で取り組む現場で繰り返し聞く悩みだ。Reflexion、LATS、GraphRAG、MemGPT、Voyager……有名なパターンは無数にあるが、参照実装は論文ごとに書き方も入出力も違い、比較するだけで一苦労する。
その課題に真正面から答えるのが、FareedKhan-dev が公開した all-agentic-architectures（PyPI パッケージ名 agentic-architectures）だ。文献で知られる 35 の本番級エージェントパターンを、すべて同じ契約（インターフェース）を持つ Architecture クラスにまとめ、各パターンには実際に実行済みの Jupyter ノートブックを添えた、単一の Python ライブラリ兼「生きた教科書」である。GitHub のスターは 3,849、ライセンスは MIT。基盤には LangGraph のステートマシンを使い、Nebius・OpenAI・Anthropic・Groq・Ollama・Together・Fireworks・Mistral・Google と幅広いプロバイダに対応する。
本記事は、公式リポジトリとドキュメントをもとに、all-agentic-architectures が ①結局何ができるのか／②35 のパターンをどう整理しているのか／③何が新しいのかを、事実ベースで整理する。特に、このライブラリを貫く中核の規律 deterministic-picker（LLM に点数を出させない設計）は、エージェント開発全般に効く「普遍的な作法」なので、丁寧に読み解いていく。
all-agentic-architectures とは何か：実行できる「生きた教科書」
まず全体像を押さえよう。all-agentic-architectures は、ひとことで言えば 「文献にある主要なエージェントAIパターンを、統一契約を持つ Architecture クラスとしてパッケージした単一の Python ライブラリ」だ。作者はこれを「production-grade（本番級）agentic AI patterns」の集合と位置づけている。
このライブラリの新しさは、単に「パターンを集めた」ことではない。次の 3 つが揃っている点にある。
第一に、実行できるコードであること。 35 のパターンは、解説文の中のスニペットではなく、from agentic_architectures.architectures import Reflection のように import して .run() を呼べば実際に動く、生きた実装として提供される。ローカルの Ollama を含む複数プロバイダで走るため、手を動かしながらパターンの挙動を確かめられる。
第二に、実行済みノートブックが付くこと。 各パターンには、実際にコードを走らせた Jupyter ノートブックが同梱される。ここが「教科書」としての肝で、理論の解説が『合成した架空の例』ではなく『実際の実行結果』に対して書かれている。エージェントは確率的に振る舞うため、「理屈ではこう動くはず」と「実際にこう動いた」の間にはしばしば大きな溝がある。その溝を埋め、実物の出力を見ながら学べるのが、このライブラリの教材としての価値だ。
第三に、統一契約で横並び比較できること。 35 構成すべてが同じ .run(task) インターフェースと同じ返り値（ArchitectureResult）を持つ。だからクラスを差し替えればパターンを差し替えられ、下流のコードは一切変わらない。さらに、全タスク × 全構成を比較するベンチマーク leaderboard（GitHub の説明では 17 タスクのベンチ）を同梱し、「どの構成がどのタスクに強いか」を同じ物差しで測れる。
つまり all-agentic-architectures は、「パターンの寄せ集め」ではなく、『パターンを学ぶ・動かす・比べる』の 3 つを一つの契約の上に統合したフレームワークだと理解するのが正確だ。基盤の LangGraph が「エージェントのステートマシンを組む土台」なら、本ライブラリは「その土台の上に、完成済みパターン 35 個と、それらを公平に比べる仕組みを載せたもの」にあたる。LangGraph 単体では、Reflexion を試すにも自分でグラフを設計する必要があるが、本ライブラリなら該当クラスを選んで .run() するだけで動く。
読者がまず押さえるべき結論はこうだ。all-agentic-architectures は「エージェント設計の引き出しを、実行できる形でまとめて手に入れられる」ライブラリであり、パターンを学ぶ人にも、実装の出発点を探す人にも効く、実務的な土台である。
35 のパターンをどう整理しているか：代表格を押さえる
「35 パターン」と言われても、全体像がつかみにくい。ここでは、公式が代表として挙げるパターン——Reflexion・LATS・GraphRAG・MemGPT・Voyager・BrowserAgent・Reflection など——のうち、特に有名な 5 つを数行ずつで押さえておく。いずれも文献で広く知られたパターンであり、本ライブラリはそれらを「同じ契約で呼べる実装」に揃えている点に価値がある。
Reflexion（自己反省）。 エージェントが自分の試行を言語で振り返り、その反省をメモリに書き込んで次の試行に活かすパターンだ。「やってみる → 失敗や不足を言語化して反省する → その反省を踏まえてもう一度やる」というループを回すことで、単発の生成よりも品質を高める。コード生成や問題解決のように「一発では当たらないが、フィードバックがあれば改善できる」タスクと相性が良い。
LATS（Language Agent Tree Search）。 モンテカルロ木探索（MCTS）の考え方を LLM エージェントに持ち込んだパターンで、複数の行動候補を「木」として展開し、有望な枝を評価しながら深掘りする。ReAct 的な推論・行動と、探索・評価・振り返りを統合しており、「一本道で進むのではなく、選択肢を広げて良い経路を選びたい」タスクに向く。探索を伴う分だけ計算コストは増えるため、精度とコストのトレードオフを意識して使う。
GraphRAG（知識グラフ）。 文書をベクトルとしてだけ扱う素朴な RAG に対し、文書をエンティティと関係からなる知識グラフとして構造化し、その上で検索・要約するパターンだ。素朴なベクトル検索が苦手とする「横断的・全体像的な問い（例：この資料群全体のテーマは何か）」に強いのが特徴で、複数文書をまたいだ関係の把握が要るタスクで効く。
MemGPT（長期記憶）。 LLM の限られたコンテキストウィンドウを、OS のメモリ階層のように扱うパターンだ。メインのコンテキストを「RAM」、外部ストレージを「ディスク」に見立て、必要な情報をページングしながら、長い会話や大量の記憶を扱えるようにする。「セッションをまたいでユーザーを覚えていてほしい」「長い文脈を破綻なく扱いたい」という要件で参照される。
Voyager（自律探索）。 スキルを自分で書き溜めながら成長する、自律探索型のエージェントパターン。獲得したスキルをライブラリとして再利用し、カリキュラムを自分で組み立てて未知の環境を探索していく。「環境と相互作用しながら、できることを増やしていく」タイプのタスクの代表例として知られる。
これらに加え、Web を操作する BrowserAgent や、シンプルに生成と自己修正を繰り返す Reflection など、粒度の異なるパターンが 35 個収録されている。重要なのは、これらがすべて同じ Architecture の契約に乗っていることだ。Reflexion も GraphRAG も MemGPT も、呼び出し側から見れば「arch = XXX(...) して arch.run(task) を呼ぶ」だけ。パターンごとに使い方を覚え直す必要がない。この「学習コストの一定化」こそ、35 個を一冊にまとめた意義である。
代表パターンを「何のためのパターンか／向くタスク」で対比すると、次のように整理できる。
| パターン | 中心的な考え方 | 向くタスクの例 |
|---|---|---|
| Reflexion | 試行を言語で振り返り次に活かす | コード生成・問題解決など反復改善が効くもの |
| LATS | 行動候補を木で展開し探索・評価 | 選択肢が多く最良経路を探したい推論タスク |
| GraphRAG | 文書を知識グラフ化して検索・要約 | 複数文書をまたぐ横断的・全体像的な問い |
| MemGPT | コンテキストを階層管理し長期記憶を扱う | 長い会話・セッションをまたぐ記憶の保持 |
| Voyager | スキルを蓄積し自律的に探索 | 環境と対話しながら能力を増やすタスク |
※この対比は各パターンの一般的な位置づけであり、断定的な優劣ではない。実際にどのパターンが効くかは、後述する統一契約とベンチマークで、自分のタスク上で確かめるのが本ライブラリの流儀だ。
中核の規律：deterministic-picker（LLM に点数を出させない）
ここからが本記事の核心だ。all-agentic-architectures を単なる「パターン集」と一線を画す存在にしているのが、ライブラリ全体を貫く deterministic-picker という設計規律である。これはエージェント開発全般に効く普遍的な作法なので、じっくり読み解きたい。
問題：LLM-as-Scorer は「点が団子になる」。 エージェントの内部では、しばしば「候補を評価して一番良いものを選ぶ」処理が必要になる。Reflexion なら「今の答えは十分か」、LATS なら「どの枝が有望か」を判断しなければならない。素朴なやり方は、LLM に「この候補を 0〜10 点で採点して」と頼む——いわゆる LLM-as-Scorer だ。しかしこれには厄介な病理がある。LLM に連続値のスコアを出させると、多くの候補が同じような点に固まってしまうのだ。5 つの候補を採点させたら「全部 7 点」、次のステップでも「全部 7 点」。これでは優劣が付かず、選択の意味がなくなる。この、スコアが狭い帯に張り付いて差が出ない現象を、本ライブラリは flat-band（フラットバンド、点が団子になる）病理と呼ぶ。
なぜ点が団子になるのか。LLM は「7 点」と「8 点」の境界がどこにあるかを一貫して持っておらず、連続値の微妙な差を安定して付けるのが本質的に苦手だからだ。同じ候補でも呼ぶたびに点が揺れ、かつ全体としては無難な中央値付近に寄る。結果、スコアは「差を測る物差し」として機能しなくなる。
解決：LLM にはカテゴリだけを、決定は Python で。 deterministic-picker の発想はシンプルで強力だ。LLM-as-Scorer を使う箇所すべてで、LLM には連続的な点数ではなく、真偽値や enum のような『カテゴリ的な特徴』だけを commit させる。 例えば「この答えは要件を満たしているか（True / False）」「エラーの種類は（構文 / 論理 / 不足のいずれか）」といった、離散的で判定しやすい問いに絞る。そして、最終的な決定信号——どの候補を選ぶか、次にどう動くか、ループを続けるか止めるか——は、それらのカテゴリを材料に Python 側のコードで決定的（deterministic）に合成する。
図で示した 3 ステップがそのまま処理の流れになる。
真偽値・enum など
カテゴリ特徴に commit"] LLM --> PY["Python が合成
カテゴリを材料に
決定信号を組み立てる"] PY --> OUT["決定的な選択
flat-band を回避し
安定・再現・デバッグ可能"]
この切り分けが効く理由は明快だ。LLM は「言語で判断する」のは得意だが「数値で細かく差を付ける」のは苦手——ならば、得意なカテゴリ判定だけを任せ、苦手な数値合成・優先順位付けは、決定的で検証可能なコードに任せればいい。役割分担を、それぞれの強みに合わせて切るわけだ。
deterministic-picker がもたらす具体的な利点は、次の 4 点に整理できる。
・評価の安定性：全候補が同じ点に張り付く flat-band が起きにくく、候補の間にちゃんと差が付く
・再現性：決定信号を Python が合成するため、同じ入力に対して同じ判断を返しやすく、実行ごとのブレが減る
・デバッグ性：「なぜこの候補が選ばれたのか」を、LLM の気分ではなくコードのロジックとして追える。ログに出るのはカテゴリと合成規則なので、原因を特定しやすい
・移植性：プロバイダやモデルを変えても、決定ロジックはコード側にあるため、判断の骨格が壊れにくい
素朴な LLM-as-Scorer と deterministic-picker を、観点ごとに対比すると差が鮮明になる。
| 観点 | 素朴な LLM-as-Scorer | deterministic-picker |
|---|---|---|
| 評価の安定性 | 点が団子になりやすい（flat-band） | カテゴリ＋コード合成で差が付く |
| 再現性 | 実行ごとに点が揺れやすい | 決定信号をコードが合成し安定しやすい |
| LLM に任せる範囲 | 連続値の採点（苦手な作業） | 真偽値・enum の分類（得意な作業） |
| デバッグ性 | なぜその点かを追いにくい | 選択の根拠をコードとして追える |
| 実装の重さ | プロンプト 1 本で済むが不安定 | 分類＋合成の設計が要るが堅牢 |
※これは「LLM-as-Scorer が常に劣る」という主張ではない。ラフな用途では素朴な採点で十分なこともある。deterministic-picker は、評価の安定性・再現性が重要な場面で効く『作法』として理解するのが正確だ。
そして特筆すべきは、この規律がライブラリ全体にどれだけ浸透しているかだ。公式によれば、35 構成のうち 13 でこの deterministic-picker が採用され、さらに 9 は設計上そもそもスコアリングを必要としない。つまり合計 22 の構成——過半——が、flat-band 病理に耐性を持つように作られている。特定の 1 パターンだけの小技ではなく、ライブラリを貫く一貫した設計思想として実装されている点に、このプロジェクトの真面目さが表れている。エージェント開発で「LLM に採点させたら候補が団子になって困った」経験がある人にとって、この 1 点だけでも読む価値がある。
統一契約とベンチマーク：.run() と leaderboard
deterministic-picker が「内部の質」を担保する規律なら、統一契約は「外から使う際の一貫性」を担保する仕組みだ。この 2 つが揃って初めて、35 パターンは「比べられる教材」になる。
ありがちな世界：実装がバラバラで比べられない。 パターンを論文や個別リポジトリから寄せ集めると、Reflexion はこう呼び、GraphRAG はああ呼び……と、入出力の形も引数もまちまちになる。すると「同じタスクを Reflexion と LATS で解かせて、どちらが良かったか」を比べたくても、そもそも同じ土俵に乗せる前処理で消耗してしまう。これがエージェント設計の学習・検証を難しくしてきた根本原因だ。
この教材の世界：全部が同じ契約に乗る。 all-agentic-architectures では、35 構成すべてが同じ Architecture の契約を持つ。具体的には——
・同じ入口：どのパターンも .run(task) で呼べる
・同じ返り値：結果は共通の ArchitectureResult として返る
・差し替え可能：クラスを別のパターンに変えても、下流のコードは変わらない
この「クラスを差し替えればパターンを差し替えられる」性質は、実務でもそのまま効く。ある機能を Reflection で作り始め、精度が足りないと分かったら Reflexion や LATS に差し替える——そのとき、呼び出し側のコードは基本そのままでいい。パターン選定を「後から差し替え可能な設計判断」にできるのは、契約が統一されているからこそだ。
そして leaderboard。 統一契約の真価が最も出るのが、同梱の ベンチマーク leaderboard だ。全パターンが同じ .run() で動くということは、同じタスク集合を、全構成に対して機械的に流せるということでもある。本ライブラリは、全タスク × 全構成を比較する leaderboard（GitHub の説明では 17 タスクのベンチ）を持ち、「どの構成がどのタスクに強いか」を同じ物差しで一望できる。
これは、記事冒頭で挙げた悩み——「どのパターンがどのタスクに効くのか横並びで比べられない」——への、そのままの回答だ。エージェント設計の選定を、印象論や論文の主張ではなく、同一条件で測った実測値に基づいて行える。もちろん、同梱ベンチのタスクとあなたの実タスクは別物なので、最終的には自分のタスクで測り直す必要がある。だが、「同じ契約に乗っているから、自分のタスクを追加して全構成に流すのも容易」という点が重要だ。leaderboard は完成品としても、自分用ベンチを組む雛形としても使える。
まとめると、統一契約は次の 3 段で価値を積み上げている。
.run()/ArchitectureResultの統一 → パターンごとの使い方を覚え直さなくていい- クラスの差し替え可能性 → パターン選定を後から変えられる設計判断にできる
- 全タスク × 全構成の leaderboard → 選定を実測に基づいて行える／自分用ベンチも組みやすい
deterministic-picker（内部の質）と統一契約（外部の一貫性）——この 2 本柱が、all-agentic-architectures を「ただのサンプル集」ではなく「実装できる教科書」にしている。
実際の使い方：インストールと最小例、プロバイダ切替
理屈が分かったら、動かしてみよう。ここでは公式に沿って、インストール・最小の実行例・プロバイダ切替の勘所を押さえる。
インストール。 PyPI パッケージ名は agentic-architectures。角括弧の extras で、必要なオプション依存だけを選んで入れられる。
# Nebius プロバイダ・FAISS（ベクトル検索）・Tavily（Web 検索）を含めて入れる例
pip install "agentic-architectures[nebius,faiss,tavily]"
extras は「使いたいパターンに応じて足す」のが基本だ。例えば GraphRAG のように検索を伴うパターンには faiss などのベクトルインデックス、Web を触るパターンには tavily のような検索ツールが要る。まずは最小構成で 1 つのパターンを動かし、必要になったら依存を足していくのが、環境構築でつまずかないコツだ。
最小の実行例。 統一契約のおかげで、どのパターンも「クラスを作って .run() を呼ぶ」だけで動く。最もシンプルな Reflection を例に取る。
from agentic_architectures.architectures import Reflection
# LLM を差し込み、パターン固有のパラメータを渡してインスタンス化
arch = Reflection(
llm=get_llm(), # プロバイダは get_llm 側で選ぶ（後述）
max_iterations=2, # 生成→自己修正を最大 2 回
target_score=8, # この水準に達したら打ち切る
)
# 統一契約：どのパターンも .run(task) で呼べる
result = arch.run("...") # 返り値は共通の ArchitectureResult
ここで注目したいのは、別のパターンに変えたいときは Reflection を別のクラス（例：Reflexion や LATS）に差し替えるだけで、.run("...") の呼び出し側は変わらないことだ。統一契約が、そのまま「学習のしやすさ」と「差し替えのしやすさ」に直結している。
プロバイダ切替。 LLM は get_llm() のようなヘルパを通して差し込む設計になっており、同じアーキテクチャコードのまま、バックエンドのプロバイダだけを切り替えられる。対応プロバイダは Nebius・OpenAI・Anthropic・Groq・Ollama・Together・Fireworks・Mistral・Google。重要なのは Ollama に対応している点で、ローカルで動くモデルを使えば、API キーやクラウド課金なしに手元で挙動を確かめられる。
現実的な進め方はこうだ。
- まず Ollama でローカル実行し、パターンの動きと出力の形を無料で確認する
- 感触が良ければ、安価なプロバイダで少量のタスクを流し、精度・レイテンシを見る
- 本番要件が固まったら、必要なプロバイダ（性能・コスト・データ取り扱いで選ぶ）に切り替える
このとき、アーキテクチャのコードは基本そのまま。プロバイダ選定を後回しにできるのは、LLM 差し込みが共通ヘルパに抽象化されているおかげだ。
そして、動かしながら学ぶうえで最大の資産が 実行済みノートブックだ。各パターンには、実際にコードを走らせたノートブックが付いている。「このパターンは理屈ではこう動くはず」ではなく、「実際にこう動いた」という実物の出力を見ながら、プロンプト・中間状態・最終結果を追える。まずノートブックで実物を眺め、次に自分のタスクに差し替えて .run() してみる——この順で進めると、パターンの理解が一気に立体的になる。
使いどころと注意点：どんなときに効き、何に気をつけるか
最後に、実務でどう活かすか、そして採用前に押さえておくべき注意点を、誇張なく整理する。
特にハマる使いどころ。
・エージェント設計の引き出しを増やしたい：35 のパターンを同じ契約で試せるので、「Reflexion と LATS と Reflection、うちのタスクにはどれ？」を実際に動かして比べられる。設計の語彙を、実物ベースで一気に増やせる
・パターン選定を実測で決めたい：leaderboard を土台に、自分のタスクを全構成へ流して横並び比較できる。印象論でなく数字でパターンを選びたいチームに向く
・実装の出発点がほしい：有望なパターンが見つかったら、その Architecture クラスを出発点に、自社要件へ作り込める。ゼロから設計するより速い
・LLM-as-Scorer で困っている：候補の点が団子になる問題に悩んでいるなら、deterministic-picker の実装は、自分のコードに持ち帰れる普遍的な作法として参考になる
採用前の注意点。
ライブラリの MIT と、プロバイダの規約は別物。 リポジトリは MIT で商用利用にも寛容だが、実際に呼び出す OpenAI や Anthropic 等の API 利用規約・料金・データ取り扱いは各社の規約に従う。ライセンスとプロバイダ規約を分けて確認すること。
コストは「パターン × プロバイダ」で効いてくる。 LATS のように探索を伴うパターンは、その分だけ LLM 呼び出し回数が増え、精度と引き換えにトークン消費が膨らむ。全タスクを重いパターンで回すとコストが跳ねるので、まず軽いパターン・ローカル実行で試し、必要なところだけ重いパターンに上げる、という段階的な使い分けが現実的だ。extras の入れすぎも避け、使うパターンに必要な依存だけを足すのが安全である。
ベンチの強さと、あなたのタスクでの最適さは別問題。 同梱の leaderboard で高スコアのパターンが、あなたの実際のタスク（自社ドメインの調査、特定形式の生成など）で最良とは限らない。必ず自分の代表タスクで小さくパイロットし、精度・レイテンシ・コストを実測してから本格導入すること。幸い、統一契約のおかげで自分のタスクを全構成に流すのは容易なので、この検証コストは低い。
「本番級」の言葉は額面どおりに受け取りすぎない。 作者は production-grade と表現しているが、どんなライブラリでも、あなたの本番環境（負荷・エラーハンドリング・監視・データ保護）に合わせた作り込みは別途必要だ。本ライブラリは強力な出発点だが、そのまま無検証で本番に載せるのではなく、パイロット→作り込み→段階投入の順で進めるのが堅実である。
総じて、all-agentic-architectures は 「エージェント設計を、学ぶ・動かす・比べる」を一つの契約の上で完結させた、実務的で誠実なライブラリだ。35 のパターンを実行できる形でまとめ、実行済みノートブックで理論と実物を結び、deterministic-picker という一貫した規律で内部の質を担保し、統一契約と leaderboard で公平な比較を可能にしている。エージェント開発に本気で向き合う人にとって、手元に置いておく価値のある「一冊」である。
まとめ（TLDR） ・all-agentic-architectures は、文献の 35 の本番級エージェントパターンを、統一契約を持つ
Architectureクラスにまとめた Python ライブラリ兼「生きた教科書」（★3,849・MIT・PyPI:agentic-architectures）。
・Reflexion・LATS・GraphRAG・MemGPT・Voyager など有名パターンが、どれも同じ.run(task)で呼べ、各パターンに実行済み Jupyter ノートブックが付く。理論は「合成例」でなく「実際の実行結果」に対して書かれている。
・中核の規律 deterministic-picker：LLM には真偽値・enum などカテゴリ特徴だけを commit させ、決定信号は Python で合成。LLM-as-Scorer の「点が団子になる（flat-band）」病理からの普遍的な脱出法で、35 構成中 13 が採用・9 は設計上不要（＝過半が耐性）。
・統一契約（同じ.run()/ 同じArchitectureResult）でクラスを差し替えるだけでパターンを差し替えられ、全タスク × 全構成の leaderboard で横並び比較できる。
・基盤は LangGraph、対応プロバイダは Nebius・OpenAI・Anthropic・Groq・Ollama・Together・Fireworks・Mistral・Google。pip install "agentic-architectures[...]"で導入、Ollama ならローカルで無料で試せる。
・使いどころは「設計の引き出しを増やす／パターン選定を実測で決める／実装の出発点にする」。注意点はプロバイダ規約とコスト、そして必ず自分のタスクでパイロットすること。
参照ソース
・FareedKhan-dev/all-agentic-architectures（公式リポジトリ）
・all-agentic-architectures ドキュメント（公式サイト）
・agentic-architectures（PyPI）
