6月24日、astle dsa（※編集部注：著者名が不自然なため、元記事で要確認）が「Agentic Frameworks: Or different ways to make LLM API calls」と題した記事を公開した。LangChainやAutoGenといったエージェントフレームワークの内部構造を突き詰めると、結局「LLM APIコールの異なる呼び出し方」にすぎない——この挑発的な主張を出発点に、乱立するフレームワークを4つのパラダイムに分解して見せる。
「エージェント」の正体はAPIコールのパターンにすぎない
LangChainやLangGraph、AutoGenといったエージェントフレームワークが乱立する昨今、その内部構造を突き詰めると何が残るか。著者の主張はシンプルだ。エージェントフレームワークとは、つまるところLLM APIコールの異なる呼び出し方である。
前提として、最も原始的なAPIコールは2種類だ。テキストを入力してテキストを得る「TITO（Text-In, Text-Out）」と、JSONや構造化出力を得るものだ。この2種類を組み合わせることで、以下の4つのパラダイムが導出できると論じている。
4つのコアパラダイム
1. シーケンシングモデル（Sequencing Model）
最もシンプルな構造。LLMを順番に呼び出し、前のAPIコールの出力を次の入力に渡していく。コンテキスト管理とツール使用を各コールに分離できる。
2. ブランチングモデル（Branching Model）
シーケンシングモデルに「並列呼び出し」を加えたもの。依存関係のない2つのタスクを同時にLLMへ投げる。**LangGraph、n8n、Mantraなど現在の「エージェント」実装のほぼすべてがこのパラダイムに該当する**。各ノードをシステムプロンプト＋ツールセットで定義したワークフローグラフがその典型だ。
3. ループモデル（Looping Model）
最も広く実装され、実効性が高いとされるフレームワーク。外側にREPL（Read-Eval-Print Loop）、内側にwhileループを持つ二重構造だ。
外ループ（REPL）: ユーザーのリクエストを受け取る
内ループ（while）:
1. LLM APIを呼び出す
2. ツールを実行する
3. 結果をコンテキストに追加する
4. LLMがプレーンテキストを出力、またはstopツールを呼んだら終了
Codex、Claude Code、Piがこの実装例として挙げられている。なお実装上の注意として、このループはReActメソッドを使わないと機能しない点が強調されている。ReActとはReasoning（推論）とActing（行動）を交互に繰り返す手法で、「まず全体の計画を立ててから実行する」のではなく、1ステップごとに思考トレースを挟みながら逐次的に行動を決定していく点が特徴だ。
4. リカーシブモデル（Recursive Model）＝RLM
最も新しく、注目を集めているパラダイム。「自己呼び出しツール」を持ったLLMという構造だ。
RLM（Recursive Language Model）は新しいモデルアーキテクチャではない。LLMのAPIコールに「自分自身を呼び出すツール」を渡すだけのエンジニアリング上の工夫だ。これによりLLMはタスクを委譲し、コンテキストを分割し、サブエージェントを生成できる。Claude Codeが現在実装しているマルチエージェント構成がこれに相当する。
ブランチングモデルとの違いは明確だ。ブランチングでは外部のオーケストレーターコードが次のAPIコールを制御するが、RLMではLLM自身がツールとして自己呼び出しを行う。
論文著者らは、このself-callツールに特化したファインチューニングがモデル性能を大きく向上させると主張しており、実際にファインチューニングを行ったフォローアップ論文も公開されている。
パラダイムの組み合わせと「スウォームモデル」
4つの基本パラダイムを組み合わせる方向性も論じられている。最も興味深いのがスウォームモデル（Swarm Model）だ。
各エージェントに独立した環境（ワークスペース）を割り当て、特定の環境内でのみ行動させる。エージェント間の直接通信ではなく、環境そのものを通じて情報を共有する構造だ。これはシステム設計におけるブラックボードパターン（複数のコンポーネントが共有のデータ構造＝「黒板」に書き込み・読み出しを行うことで間接的に協調する設計パターン）と同一であり、生物学ではスティグマジー（アリやシロアリが巣の構造物を介して間接的に協調するメカニズム）とも呼ばれる。
実装イメージとしては、例えば100のサブエージェントが共有ファイルシステムやデータベースをワークスペースとして持ち、各エージェントは「自分の担当ディレクトリへの書き込み」だけを行う。他エージェントの進捗はそのワークスペースを参照することで把握するため、エージェント同士がメッセージを直接やり取りする必要がない。
スケール面での優位性が主な動機だ。1000エージェントが互いに直接通信すると組み合わせ爆発が起きるが、各エージェントが共有媒体に書き込むだけなら協調コストは線形に近く抑えられる。
根本的な制約
どのアーキテクチャも、フロンティアLLMがツール呼び出しに特化してファインチューニングされているという前提の上に成り立っている。RLMの研究者らも、self-callツールへの追加ファインチューニングが有効と述べており、アーキテクチャの巧みさだけでは解決できないモデル側の要件がある。
分散システムと同様に、エージェント間の調整問題（coordination problem）も依然として未解決の課題として残る。互いのコンテキストを知らないエージェント同士が干渉し合い、全体の品質が劣化するリスクだ。
詳細はAgentic Frameworks: Or different ways to make LLM API callsを参照していただきたい。
