グラフ・エンジニアリングの先に圏論はあるか

グラフ・エンジニアリングの先に圏論はあるか

AIエージェントの作業をグラフとして記述する技術から、処理の合成則を記述する技術へ

1　グラフ・エンジニアリングは何を変えようとしているのか

2026年7月、「Graph Engineering」という言葉がAI開発者の間で目立つようになった。直接のきっかけになった資料の1つが、「Karpathyループを1000倍改善した」と紹介された11頁の文書である。ただし、この文書はAnthropicやAndrej Karpathyの公式発表ではなく、公開情報を独自にまとめたものだった。「1000倍」という数値にも比較実験はない。したがって、グラフ・エンジニアリングは、現時点で確立された研究分野の名称というより、複数エージェントを用いるAIシステムで進みつつある設計上の変化に、新しい名前を与えたものと考えるのがよい[1]。

その出発点として参照されているのが、Karpathyのautoresearchである。このシステムでは、AIエージェントが学習コードを変更し、5分間の学習を実行し、検証指標を測定する。結果が改善していれば変更を残し、悪化していれば捨て、次の実験へ進む。人間が直接編集する中心的な対象はPythonコードではなく、エージェントへの指示を記したprogram.mdである。つまり、生成、実行、測定、採否というループを自動化し、そのループ自体を人間が設計する[2]。

問題は、これを複数のエージェントへ拡張したときに生じる。例えば、3つのエージェントが別々の仮説を調べ、それぞれ資料を検索し、途中結果を残し、別のエージェントが比較し、その後に文章を生成するとしよう。必要になるのは、単なる会話履歴ではない。「どの作業がどの作業に依存するか」「どの資料からどの主張が作られたか」「どの成果物がどの版から派生したか」「どの候補が評価によって棄却されたか」を、後から辿れる形で保存しなければならない。

Anthropicの調査システムも、統括エージェントが複数の下位エージェントへ調査を割り振り、それぞれが並列に探索した結果を集約する構成を採っている。また、長時間動作するエージェント基盤では、モデルを呼び出す部分、ツールを実行する部分、セッション記録を保存する部分を分離し、どれかが停止しても状態を復元できるようにしている。こうした設計は「グラフ・エンジニアリング」という名称とは独立に発達してきたが、状態をモデルの会話履歴から外へ出し、明示的な構造として管理するという点では共通している[3]。

グラフ・エンジニアリングを一般化すると、作業の依存関係、成果物の来歴、知識と証拠の関係、評価結果などを、有向グラフとして保持する設計だと考えられる。頂点には作業、成果物、主張、資料、評価などを置き、「次に実行する」「ここから派生した」「この資料がこの主張を支持する」といった関係を有向辺で表す。

この方法には明確な利点がある。複数の探索を並行して進めても、どの結果がどこから生じたかを見失いにくい。失敗した処理を途中から再開できる。エージェントが交代しても、過去の作業状態を共有できる。グラフ・エンジニアリングが目指しているのは、AIの仕事を会話という一時的な流れから切り離し、持続的で追跡可能な構造として扱えるようにすることである。

2　しかし、グラフにしただけでは解けない問題がある

ここで、単純な作業手順を考えてみる。

質問 → 調査 → 検証 → 執筆

有向グラフとして表すなら、各作業に頂点を割り当て、その実行順序に従って頂点間に有向辺を張ればよい。

では、「調査」を担当するエージェントを別のモデルへ交換したらどうなるだろうか。

新しいエージェントが同じ形式の結果を返すなら、グラフ上では同じ位置に置き換えることができる。しかし実際に必要なのは、もっと強い条件である。新しい調査エージェントも資料の出典を残すのか。確信度の扱いは変わらないのか。後段の検証エージェントが必要とする情報を失わないか。2つの調査処理を連続して行った場合、その結果に対応する成果物の来歴も正しく連なるのか。

普通の有向グラフは、A → Bという有向辺を表せる。その一方で、この辺がどのような変換を意味し、別の辺と続けて辿ったときに何を保存すべきかまでは規定しない。

さらに、作業グラフとは別に成果物の来歴を表すグラフを持っている場合を考えよう。

調査 → 検証
調査メモ → 検証済み資料

グラフ・エンジニアリングでは、この2つのグラフを識別子やデータベース上の参照によって対応づけられる。しかし、「作業側で2つの処理を連続させたなら、それに対応する成果物側の変換も同じ順序で連なる」という規則は、有向グラフだけからは導かれない。開発者が別途コードを書き、試験によって整合性を確かめることになる。

ここで、別の方法が考えられる。どの頂点間に辺があるかを記録するだけではなく、次のようなことまで数学的に記述する方法である。

• それぞれの処理が何を何へ変換するのか
• どの処理どうしを合成できるのか
• 合成したときに何を保存しなければならないのか
• 異なるグラフの間で、どのような対応を保つべきなのか

その候補になるのが圏論である。

3　圏論的AIエンジニアリングとは何か

「圏論的AIエンジニアリング」は、現在確立した研究分野の正式名称ではない。本稿では、AIエージェント、作業手順、成果物、知識、評価などを圏論的な構造によって記述し、処理の合成や異なる構造間の変換をAIシステムの設計と実行に利用する考え方を、便宜的にこう呼ぶ。

この考え方がグラフ・エンジニアリングから自然に出てくるのは、圏が有向グラフに似た構造を持ちながら、射の合成という追加の規則を備えているからである。

圏では、基本となる要素を「対象」と「射」に分ける。例えば、成果物の型を対象、AIエージェントによる処理を射とみなす。

A ─f→ B

B ─g→ C

g∘f : A → C

A ─f→ Bを「資料集合Aを、調査エージェントfが証拠集合Bに変換する」と読む。さらに、B ─g→ Cを「証拠集合Bを、検証処理gが検証済み証拠Cに変換する」とする。このとき、g∘f : A → Cという合成が定義される。

有向グラフでもAからBを経てCに至る道は表せる。圏論では、それに加えて、この道を1つの合成された射として扱える。したがって「調査してから検証する」という一連の処理全体を、さらに大きな作業手順の1つの構成要素として利用できる。

複数の処理を並列に扱う場合にはモノイド圏を利用できる。異なる圏の間で構造を保った対応を定めるものが関手であり、2つの関手の間の対応を記述するものが自然変換である。圏論には、個々の対象そのものよりも、対象間の変換とその合成に注目して体系を記述するための数学が蓄積されている。

この考え方をAIエンジニアリングへ応用すれば、1つの巨大なグラフにすべてを詰め込む必要もなくなる。例えば、作業を表す圏、成果物と来歴を表す圏、知識と証拠を表す構造、評価を表す圏を別々に考えることができる。

𝒯 = 作業を表す圏
𝒜 = 成果物と来歴を表す圏
𝒦 = 知識と証拠を表す構造
ℰ = 評価を表す圏

そのうえで、F : 𝒯 → 𝒜という関手を置く。これは、作業を表す構造と、成果物の来歴を表す構造との対応を記述するものだと考えられる。

F(g∘f) = F(g)∘F(f)

関手は合成を保存する。したがって、作業側でfとgを続けて実行するなら、それに対応する成果物側の変換も同じ合成関係を保たなければならない。このような条件を、個別のプログラム上の取り決めではなく、システムが満たすべき規則として記述できる。

この考え方にはAI以前から実例がある。David Spivakは、データベースのスキーマを小圏、実際のデータを集合への関手として表し、スキーマ間の関手からデータ移行を体系的に導く方法を示した。異なるデータ構造の間で何を保存しながら移行するかを圏論によって記述する考え方は、すでに具体的な計算機科学へ応用されている[4]。

4　この考えを具体化する試みはすでに始まっている

圏論をAIエンジニアリング全体の基礎として用いる統一的な方法は、まだ成立していない。しかし、そのために必要と思われる要素を個別に形にした試みは、2026年時点ですでに存在する。

William WaitesのPlumbingは、複数エージェントの通信と処理の流れを型付きで記述し、実行前に構造上の不整合を検査する言語である。Waitesは、現在の複数エージェント基盤では処理の合成や通信構造に対する形式的な保証が弱く、不整合が実行時まで現れない問題を指摘している。Plumbingでは、エージェントの処理と通信路からなるグラフを実行前に検査し、一定の範囲でデッドロックなども調べる[5]。

Fiona Y. WangとMarkus J. BuehlerのCategoryScienceClawは、別の側面を扱う。そこでは、候補モデル、棄却された案、評価、成果物、来歴を保存し、AIシステム自身が作業構造を変更しても過去との対応を追跡できるようにする。論文では、固定されたスキーマを圏として扱い、その上のシステム状態を関手として表す。スキーマが変化した場合には、Kan拡張を利用して旧状態を新しい構造へ移す方法が提案されている[6]。

FunctorFlowはさらに、図式として記述されたAIシステムを圏論的な中間表現へ変換し、そこから実行可能な計算を組み立てる試みである。現在の公開実装には、圏、関手、自然変換、Kan拡張、積や引き戻しなどを扱う機能があり、一部についてLeanによる証明書を生成する機構も備える[7]。

これらは同じ問題を解いているわけではない。Plumbingは主としてエージェント間の通信と実行、CategoryScienceClawは成果物・知識・来歴の更新、FunctorFlowは圏論的な中間表現と実際の計算との橋渡しに重点を置いている。

ここから、「これらの考えをまとめれば、グラフ・エンジニアリングよりも強いAI基盤を作れるのではないか」という発想が出てくる。数学的な道具だけを見れば、この着想はそれほど突飛ではない。

問題は、それぞれの仕組みをどのような規則で結び合わせれば、全体として一貫したAIシステムになるのかである。

5　難点1――同じ矢印でも意味が違う

作業グラフでは、有向辺が処理の順序や遷移を表す。成果物グラフでは、同じ形の矢印が「AからBが派生した」という来歴を示す。知識グラフなら、「資料Aが主張Bを支持する」という意味になるかもしれない。評価の記録なら、「候補Aが評価Bを受けた」と読むこともできる。

同じ有向グラフとして記述できても、辺が表している関係と、その関係を連ねたときの意味は異なる。

資料 → 主張
主張 → 結論

この2本の辺が存在しても、それだけで「資料 → 結論」という新しい関係を作ってよいとは限らない。資料が主張を「支持する」ことと、主張から結論が「導かれる」ことでは、関係の種類が違うからである。

圏論には、こうした異なる種類の関係や複数の入力を扱うための拡張が数多く存在する。しかし、どの数学的構造をAIシステムのどの部分に割り当てるべきかは、圏論そのものから自動的には決まらない。数学的に表現できることと、現実のシステムに適した表現を選ぶことは別の問題になる。

6　難点2――AIエージェントは普通の関数ではない

説明を単純化すれば、エージェントをf : A → Bという関数のように扱える。実際のAIエージェントは、それほど単純ではない。

同じ質問に異なる答えを返す。途中でツールを呼ぶ。検索結果によって行動を変える。失敗することもある。過去の状態を参照する。処理が途中で止まる場合もある。

計算機科学では、通常の関数だけでは表現しにくい副作用、例外、非決定的な計算などを圏論的に扱う方法として、モナドやクライスリ圏が研究されてきた。

確率的な処理についても圏論的な蓄積がある。Tobias Fritzはマルコフ圏を用いて、離散確率、測度論的確率、ガウス分布、確率過程などを共通した合成的枠組みで扱えることを示している[8]。

したがって、AIエージェントの確率性や状態を表すための数学的候補が欠けているわけではない。

難しいのは、あるエージェントの状態、確率性、ツール呼び出し、失敗、再試行を、どの圏論的構造で記述すればAIエンジニアリング上もっとも有効なのかを決めることである。候補が複数あり、その選択によってシステム全体の捉え方も変わる。

7　難点3――AIでは「同じ結果」の意味が曖昧になる

さらに厄介なのが、可換性である。

例えば、外国語文書について、「翻訳してから主張を抽出する」経路と、「主張を抽出してから翻訳する」経路を考える。理想的には、両者は同じ内容へ到達してほしい。

可換図式では、異なる経路によって得られる結果が一致することを等式として表せる。しかし、大規模言語モデルを使えば、2つの生成結果が完全に同じになることは通常期待できない。

g∘f = h

↓

d(g∘f, h) ≤ ε

必要なのは厳密な一致だけではなく、「2つの結果の差が許容範囲内に収まる」という条件である。

圏論では、射に誤差の概念を加え、処理を合成した場合に誤差がどのように蓄積するかを扱う方法も研究されている。RischelとWeichwaldは因果モデルについて、モデルを段階的に抽象化したとき、各変換で生じる誤差から合成後の誤差を評価できる枠組みを構築している[9]。

ただし、AIエージェントの場合、「文章の意味がどれだけ近いか」「引用の解釈がどれだけ一致しているか」「2つの計画が同じ目的を達成しているか」を測る尺度そのものを決めなければならない。ここは圏論だけでは決まらない。

8　難点4――構造が正しくても、内容が正しいとは限らない

圏論的な検証によって、次の条件を確認できたとしても、AIが生成した文章の事実性までは保証されない。

• 入出力の型が一致している
• 必要な来歴が保存されている
• 許可された処理だけが組み合わされている
• 関手が合成を保存している
• 指定された図式が可換である

例えば、調査エージェントが存在しない論文を引用した場合でも、論文、著者、主張、引用関係というデータ構造そのものは整合している可能性がある。

したがって、圏論的AIエンジニアリングでも経験的な評価は残る。Karpathyのautoresearchがループを成立させられるのは、変更後の学習結果を固定された指標で実測できるためである。生成した変更を保持するか捨てるかは、その外部評価に基づいて決まる[10]。

圏論による検証が役立つのは、構造上許されない変更を排除し、処理を合成したときにどの性質が保たれるかを明らかにする場面である。外界についての正しさは、測定、検索、試験、人間による確認などによって確かめる必要がある。

9　難点5――圏そのものをどう設計するか

さらに根本的なのが、何を対象とし、何を射とするかという問題である。

例えば「論文」「主張」「引用」「調査結果」を別々の対象型として定義するのか。「要約」は射なのか成果物なのか。「評価」は作業なのか、成果物間の関係なのか。

これは単なる命名の問題ではない。どの処理の合成を許し、どの性質を保存できるかが、この設計によって決まる。

自己更新するAIでは、問題がさらに複雑になる。システム自身が新しいツール、新しい成果物型、新しい評価方法を追加すれば、システムを記述するスキーマ自体が変化する。

旧スキーマから新スキーマへの関手が定まっているなら、Kan拡張などの既存理論を利用し、旧スキーマ上の情報を新しいスキーマへ移す方法を構成できる。CategoryScienceClawも、スキーマ圏の変更に伴う過去の成果物の移送を、この方法で記述している[11]。

しかし、その前に「新しいスキーマをどう設計するべきか」を決めなければならない。

圏論は、与えられた構造の間で何を保存するかを厳密に記述できる。しかし、AIシステムにとって有用な構造そのものを自動的に見つけ出す方法まで確立されているわけではない。

10　だから現在はグラフ・エンジニアリングの方が実装しやすい

ここまで見ると、グラフ・エンジニアリングが先に実装されやすい理由も分かる。

グラフ・エンジニアリングでは、頂点、辺、成果物、来歴、評価値、実行記録を保存すれば、まずシステムを動かせる。

「この有向辺は数学的にどの種類の変換なのか」を完全に決める必要はない。不整合が起きたら、試験、監視、評価器、再実行によって見つければよい。

圏論的AIエンジニアリングは、その曖昧さを減らそうとする。その代わり、実行に先立って、各処理が持つ意味と合成の規則を設計する必要がある。

現在のAIエージェントはモデル自体も急速に変化している。Anthropicも、モデルを呼び出す制御部分、実行環境、永続的なセッション記録を分離し、それぞれを交換できる構成を採っている。特定のモデルの挙動に強く依存した仕組みを固定しないためである[12]。

このような時期には、厳密な意味論を先に固定するより、比較的柔軟なグラフとして状態と関係を保存する方が実装しやすい。

グラフ・エンジニアリングの強みは、意味論を完全には決めなくても、作業の分岐、並列化、再開、来歴追跡といった実用上の利益を得られることである。

11　難点が解消されたら何が変わるか

では、これまで挙げた問題が解決されたと仮定してみよう。

AIエージェントの状態、確率性、失敗、並列処理、成果物、知識、評価について適切な圏論的表現が確立し、それらの間の対応も定義される。意味が完全には一致しない生成処理については誤差を含む合成則が整備され、圏論的な記述から実際のエージェント・グラフを生成するコンパイラの正しさも保証される。

その場合、最初に変わるのはシステム変更の扱いである。

現在なら、エージェントAをA’へ交換した後、後続処理を含めて大量の回帰試験を行う必要がある。圏論的な型と保存則が十分に確立されていれば、A’がAと同じ構造を保存している範囲を機械的に判定できる。変更が及ぶ範囲を絞り込み、必要な検証だけを重点的に行えるようになる。

次に、作業手順そのものを自動的に組み替えられる可能性が出てくる。

A → B → C
A → D → C

この2つが同じ意味を持つことが保証されており、後者の方が安価なら、コンパイラは処理を後者へ置き換えられる。並列化しても結果に必要な性質が保たれることが分かっていれば、直列処理を並列処理へ組み替えることもできる。

圏論的な中間表現は、AIの作業手順を単に保存する形式ではなく、意味を保ったまま作業手順を書き換えるための土台になりうる。

自己改善も変化する。

現在：変更 → 実行 → 評価 → 採否

圏論的検証を加えた場合：変更 → 構造の検証 → 実行 → 評価 → 採否

来歴を破壊する変更、型の合わない処理の組み合わせ、必須の評価処理を迂回する変更、禁止された情報経路を作る変更は、モデルを実際に動かす前に拒否できる。

これは自己改善の範囲を無制限に広げるものではない。むしろ、どの変更なら認められ、どの条件を維持しなければならないのかを明確にする方向に働く。

12　最終的には「グラフか圏論か」という選択ではなくなる

難点が解消された場合でも、有向グラフが不要になるとは考えにくい。

実行時には依然として、どの作業が待機中か、どのエージェントが動いているか、どの成果物が生成されたか、どの知識がどこから来たかを保存する必要がある。

AI作業記述
↓
圏論的中間表現
↓
型検査・合成検査・変換・最適化
↓
作業グラフ・来歴グラフ・知識グラフ
↓
AIモデル・ツール・人間

この構成では、グラフが実行状態やさまざまな関係を記録し、圏論的な記述が、グラフをどのように作り、どのような変更を許し、別のグラフとの対応をどう保つかを定める。

開発者自身が関手や自然変換を直接記述する必要もなくなるだろう。利用者が「この処理は質問を証拠集合へ変換する」「この2つの処理は並列に実行できる」「この出力には来歴が必要」と宣言すれば、内部のコンパイラが圏論的な条件を検査する形が考えられる。

その段階では、「グラフ・エンジニアリングと圏論的AIエンジニアリングのどちらを選ぶか」という問い自体が、現在ほど意味を持たなくなる。

グラフ・エンジニアリングが実現しようとしているのは、AIによる作業を会話から切り離し、頂点と辺からなる外部の追跡可能な構造として表すことである。

そこへ圏論を導入することで、グラフに表された処理や関係に合成の規則を与え、システムを変更したときに何が保たれるのかを明示できる可能性が生まれる。

グラフ・エンジニアリングによって「AIがどの経路を通って何をしたか」を追跡できるようになるとすれば、圏論を利用したAIエンジニアリングが目指すのは、「AIシステムの一部を組み替えたとき、どの性質がそのまま保たれるのか」を判断できるようにすることである。

圏論には、そのために利用できる数学的な道具がすでに相当程度そろっている。現在不足しているのは、AIエージェントという新しい計算対象に対して、どの道具をどこで使えば実際のエンジニアリング上の利益につながるのかを定める意味論と、その意味論を実際に動くシステムへ落とし込む技術である。

それらが確立されたなら、圏論はグラフ・エンジニアリングに取って代わるのではなく、大規模なグラフ・エンジニアリングを理論面から支え、システムの意味を保ちながら安全に組み替えるための基礎となる可能性がある。

注

[1] AI Builder Club, Graph Engineering and the Karpathy Loop: What’s Real, 2026. https://www.aibuilderclub.com/blog/graph-engineering-karpathy-loop

[2] Andrej Karpathy, autoresearch, 2026. https://github.com/karpathy/autoresearch

[3] Anthropic, How We Built Our Multi-Agent Research System, 2025. https://www.anthropic.com/engineering/multi-agent-research-system

[4] David I. Spivak, Functorial Data Migration, 2010. https://arxiv.org/abs/1009.1166

[5] William Waites, A Typed Language for Agent Coordination, 2026. https://leithdocs.com/ldc/documents/outgoing/plumbing/typed-language-for-agent-coordination.md

[6] Fiona Y. Wang and Markus J. Buehler, Self-Revising Discovery Systems for Science: A Categorical Framework for Agentic Artificial Intelligence, 2026. https://arxiv.org/abs/2606.01444

[7] JuliaKnowledge, FunctorFlow.jl. https://github.com/JuliaKnowledge/FunctorFlow.jl

[8] Tobias Fritz, A Synthetic Approach to Markov Kernels, Conditional Independence and Theorems on Sufficient Statistics, 2019. https://arxiv.org/abs/1908.07021

[9] Eigil F. Rischel and Sebastian Weichwald, Compositional Abstraction Error and a Category of Causal Models, 2021. https://proceedings.mlr.press/v161/rischel21a/rischel21a.pdf

[10] Andrej Karpathy, autoresearch: program.md, 2026. https://github.com/karpathy/autoresearch/blob/master/program.md

[11] Fiona Y. Wang and Markus J. Buehler, Self-Revising Discovery Systems for Science: A Categorical Framework for Agentic Artificial Intelligence, 2026. https://arxiv.org/abs/2606.01444

[12] Anthropic, Scaling Managed Agents: Decoupling the Brain from the Hands, 2026. https://www.anthropic.com/engineering/managed-agents