AIエージェント開発に役立つ一次文献11選｜基礎論文から最新仕様まで

AIエージェントは動きが速い領域です。速いからこそ、二次解説を追うほど「その時点の言い切り」ごと陳腐化しやすくなります。モデルの性能ランキングも、推奨フレームワークも、数か月後には前提が変わっています。

では、11本の一次文献のうちどれが、実装が変わっても再利用できる「残る設計語彙」を与えてくれるのか。そして、それぞれはエージェントのどの壊れ方——インターフェース設計、停止条件、評価の粒度——に効くために読むのか。この記事はその仕分けです。

私がこの3本を最初に挙げる理由

二次解説だけを追う設計には、構造的なリスクがあると考えています。二次解説は「その時点でうまくいった設定」を要約するため、stop条件やobservationの整形といった地味な前提条件が省略されがちです。省略された前提条件は、実装が別のタスクや別のモデルに変わった瞬間に、そのまま事故の原因になり得ます。だからこそ、壊れ方の理屈を説明できる一次文献に立ち返る方が、遠回りに見えて再利用性が高いというのがこの記事の立場です。

私はこれまで、ReAct・Transformer・Chain-of-Thought・Swarm・MetaGPT・A-MEM をそれぞれ1本ずつ深掘りして書いてきました（記事末尾にリンクします）。そのうえで私は、AIエージェントの実装で最初に読むべきは最新のフレームワーク比較記事ではなく、ReAct・SWE-Agent・AgentBench の3本だと考えています。

理由は、エージェントの事故がモデルの賢さではなく「インターフェース設計・停止条件・評価の粒度」で起きるからです。ただしこの主張には境界があります。フレームワーク選定や最新モデルの性能比較にはこの3本は役立ちません。そこは release notes と実測が正しい情報源です。あくまで「なぜ壊れるか、どの抽象が残るか」を理解する目的での主張だと理解してください。

この記事は 2026-04-15 時点の一次情報で全文見直しています。ベータ機能や標準仕様は数か月で前提が変わるため、リンク先の原典を都度確認することをおすすめします。

11本を選ぶ基準はシンプルです。有名だからではなく、次の4つの観点でエージェント設計に再利用しやすいものを選んでいます。

前提: 陳腐化する情報と、残る設計語彙

“

本記事でいう「一次文献」

• 査読論文や arXiv 論文
• 公式仕様書
• 公式 README / 公式実装ドキュメント

AIエージェント分野では、論文だけでなく仕様や公式 docs 自体が実装上の正本になるため、この記事ではそれらも同列に扱います。

この記事を貫く区別が2つあります。

1つ目は、陳腐化する情報と残る設計語彙の区別です。モデルの性能ランキング、ベータ機能の仕様、いま推奨されているフレームワークは、release note 1本で覆ります。これが陳腐化する情報です。一方、observation loop（ReAct）、Agent-Computer Interface（SWE-Agent）、host / client / server（MCP）のような抽象は、実装が変わっても再利用できます。反証可能にするために線を引くと——次の release note や公式アナウンスで内容が上書きされるものは陳腐化側、上書きされてもなお構造として説明力を持つものが残る語彙側です。この記事が選ぶ11本は、後者を優先的に含む文献です。

2つ目は、エージェントが壊れる3か所という読み方の軸です。多くの agent 事故は、モデルの賢さではなく (1) インターフェース設計、(2) 停止条件、(3) 評価の粒度、のどこかで起きます。以降、各文献をこの軸で仕分けます。

なお、この記事は「残る語彙」を与える静的なリストです。self-evolving や memory まわりの直近の研究動向、つまりまだ陳腐化側にあるかもしれない話題は、2025年のAIエージェント研究動向 に別途まとめています。

基礎3本: 原理を押さえる

1. ReAct: Synergizing Reasoning and Acting in Language Models (2022)

ReAct は、推論と行動を交互に進める Thought -> Action -> Observation の基本ループを提示した論文です（Yao et al., ICLR 2023）。reasoning trace が行動計画を助け、行動結果が次の推論を更新する構造で、いまの多くの tool-using agent が採るループの原型として読みやすい内容です。

私がこれを最初に挙げるのは、ReAct が「どのツールを呼ぶか」より前に「観測結果をどう次の判断へ戻すか」を考えさせてくれるからです。壊れる3か所のうち、停止条件とログ設計に直接効きます。原典の詳細は、以前まとめた ReActの解説記事 にも書いています。

• 原典: ReAct: Synergizing Reasoning and Acting in Language Models

2. Attention Is All You Need (2017)

Transformer が self-attention によって並列計算しやすい系列変換を実現した論文です（Vaswani et al., NeurIPS 2017）。いまの LLM 実務で頻出する「長い文脈」「計算コスト」「位置表現」の起点がここにあります。

AIエージェントは LLM の上に構築されるため、モデルの得意不得意を理解しないまま loop 設計だけを議論しても限界があります。壊れる3か所には直接対応しませんが、他の3本を理解する土台として先に触れておく価値があります。詳しくは Transformerの解説記事 にまとめています。

• 原典: Attention Is All You Need

3. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022)

中間推論ステップを明示させる prompting が、十分大きいモデルでは複数の推論課題を改善することを示した論文です（Wei et al., NeurIPS 2022）。以後の decomposition、reflection、verifier 系設計の土台になっています。現行製品が内部で何をしているかを断定するためではなく、段階的推論を外部設計へ落とす発想を学ぶために読む価値があります。詳細は Chain-of-Thoughtの解説記事 を参照してください。

• 原典: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

実装4本: 設計感覚を鍛える

4. SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering (2024)

SWE-Agent は、ソフトウェア修正タスク向けにエージェント専用の Agent-Computer Interface（ACI）を設計した研究です（Yang, Jimenez, Wettig, Lieret, Yao et al., 2024）。コード検索、編集、テスト実行を一連の操作として扱いやすくし、「モデル性能」だけでなく「インターフェース設計」が agent の成否を左右することを示しています。

これは実体験の検証ではなく原典の要約に基づく整理ですが、SWE-Agent の論文が示す比較実験の構図は示唆的です。同じモデルでも、検索・編集・実行を汎用シェルのように扱わせた場合と、ACIとして専用の操作単位に整えた場合とでタスク解決率が変わる、という比較が論文の核になっています。つまり差を生んでいるのはモデルの賢さではなく、道具立ての設計だという点です。

coding agent を作るときに重要なのは、賢いモデル名よりも、探索・編集・検証の流れをどう道具立てするかです。壊れる3か所のうち、インターフェース設計にもっとも直接効く1本です。

• 原典: SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering
• 関連 benchmark: SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

5. MCP / A2A 仕様

MCP は host / client / server 間で context、tools、prompts をやり取りするための標準仕様です。A2A は、異なるフレームワークやベンダー上の agent 同士が能力を公開し、長い task を協調実行するための open protocol です。どちらも「自前の接着コード」を減らし、相互運用の語彙を揃える役割を持ちます。

仕様書だけを読むと、host / client / server という語彙が整っている分、接続境界の設計はすでに解決済みの問題に見えてしまいます。しかし前述のMCPセキュリティ危機に関する記事が扱っているのは、まさにその境界——どのtoolにどこまでの権限を渡すか、どの経路でcontextが漏れ得るか——が仕様の外側に置かれているという指摘です。仕様を読むことと、境界のリスクを設計することは別の作業だと捉えておくべきだと考えます。

エージェント実装が進むほど、問題はモデル性能より接続境界に移ります。インターフェース設計の壊れ方に効く一方、仕様を中立に読むだけでは実運用のリスクは見えません。MCP の実運用上のセキュリティ境界については、MCPプロトコルのセキュリティ危機に関する記事 で扱っている内容が counterweight になります。

• 原典: Model Context Protocol Specification
• 原典: A2A Protocol GitHub

6. Anthropic Computer Use ドキュメント

Computer Use は、スクリーンショットを見てマウス・キーボード操作を行うベータ機能です。公式 docs は beta header、agent loop、sandboxed environment、tool version を明示しています。GUI 系エージェントは理論よりも実装条件の差分で壊れやすい領域なので、安全確認やデータ保持の前提まで含めて確認できる公式 docs は、噂ベースの比較より優先して読むべき文書です。

• 原典: Computer use tool - Claude API Docs

7. Swarm README / MetaGPT

Swarm は Agent と handoff を最小単位にした軽量な multi-agent orchestration の実験実装です（現行 README では experimental / educational 扱いで、production には Agents SDK への移行が推奨されています）。MetaGPT はプロダクトマネージャー、アーキテクト、エンジニアのような役割をエージェントに割り当て、SOP で協調させる枠組みです（Hong et al., 2023）。

私自身、この2本もそれぞれ1本ずつ深掘りして書いてきました。どちらも「役割を増やすこと」より「どの artifact を誰が作り、誰が消費するか」という受け渡し設計が本体です。multi-agent を必要以上に複雑化しないための視点として読む価値があります。

• 原典: openai/swarm
• 参照先: OpenAI Agents SDK
• 原典: MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework

評価・標準4本: 実運用に近づく

8. AgentBench: Evaluating LLMs as Agents (2023)

AgentBench は、LLM を agent として評価するために複数環境をまたぐ multi-turn benchmark を定義した研究です（Liu et al., ICLR 2024）。コード、データベース、知識グラフ、ゲーム、Web など、単発 QA より実運用に近い設定を扱います。

本番の agent で事故が起きるのは、1回答の質よりも長い手順の途中で判断を誤るときです。壊れる3か所のうち、評価の粒度に直接効く1本で、評価設計を single-turn prompt test から scenario test へ広げる必要性を理解させてくれます。私が ReAct・SWE-Agent と並べて最初の3本に選ぶのはこのためです。

• 原典: AgentBench: Evaluating LLMs as Agents

9. A-MEM: Agentic Memory for LLM Agents (2025)

過去のやり取りを単に埋め込み検索へ流すのではなく、構造化されたメモとして整理する memory 研究です（Xu et al., 2025）。Zettelkasten 的なノート構造と agent 主導の記憶管理を組み合わせます。メモリ機構は書き込み過多や古い記憶の混入で壊れやすい領域で、A-MEM は保存量ではなく整理・検索・更新方針の問題だと教えてくれます。この文献も、以前1本掘り下げて書いています。

• 原典: A-MEM: Agentic Memory for LLM Agents

10. Voyager: An Open-Ended Embodied Agent with Large Language Models (2023)

Minecraft 環境で、エージェントが自動カリキュラムとスキルライブラリを使って継続的に能力を拡張する研究です（Wang et al., 2023）。一度得た手続きをコードとして保存し、後続タスクに再利用します。「学習するエージェント」を語るとき、単に会話履歴を保存するだけでは足りないことを示す代表的な文献です。

• 原典: Voyager: An Open-Ended Embodied Agent with Large Language Models

壊れる3か所で再ソートする

ここまで11本を「基礎/実装/評価」という発表順に近いカテゴリで並べてきました。最後に、同じ11本を「エージェントがどこで壊れるか」という別の軸で並べ直します。

この並べ替えでわかるのは、11本のうち直接「壊れ方」に効くのは半分程度で、残りは前提知識（Transformer、CoT）か、抽象を学ぶ教材（Swarm、MetaGPT）だということです。前者を後回しにしても実装は動きますが、後者を飛ばすと、なぜ動かないかを言葉にできなくなります。

私ならこの順で読む

以下の読み順は、実装で検証済みの結論というより、ここまでの整理から導かれる仮説として提示します。

私は、agent loop を初めて組むなら ReAct → SWE-Agent → AgentBench の順を勧めます。理由はすでに書いた通り、この3本が壊れる3か所をそれぞれ1つずつ担当しているからです。multi-agent を整理したいなら Swarm → MetaGPT → A2A、tool 接続を標準化したいなら ReAct → MCP → A2A、長期運用と memory を考えたいなら Voyager → A-MEM → AgentBench という順が目的に合います。

繰り返しますが、この読み順はフレームワーク選定や最新モデルの性能比較には効きません。そこは release notes と実測を見てください。

このリストは正解ではなく、あなたが作るエージェントの壊れ方に応じて読む順を組み替えるための出発点です。判断材料として使ってもらえると嬉しいです。

よくある質問

一次文献を実装に落とすコツはありますか?

論文の結論をそのまま再現しようとせず、loop、memory、handoff、evaluation のどの論点に効く文献なのかを先に決めると読みやすくなります。壊れる3か所のどこに対応するかを先に決めるのも同じ考え方です。

英語が苦手でも読めますか?

読めます。Abstract、Conclusion、図、表だけでも十分に価値があります。仕様書は論文より短く、制約条件が箇条書きで書かれていることも多いです。