グラフエンジニアリングとMarkdown知識グラフ

2026年7月18日、ピーター・シュタインベルガーがX上に、ループからグラフへの移行についての半ば冗談めいた問いを投げました。ハメル・フセインがそれを受けて Loop Engineering Is Dead. Enter Graph Engineering. と題した記事を公開します。一週間でこの語はどこにでも現れるようになりました。

大半は、この分野が新しい「工学」を鋳造する速度への冗談でした。プロンプトエンジニアリングからコンテキストエンジニアリング、ハーネスエンジニアリング、ループエンジニアリング、そしてグラフエンジニアリングまで約18か月。定義は大きく重なっています。

それでも冗談が刺さったのは、実在する何かを指していたからです。残す価値のある部分を見ていきます。

「グラフエンジニアリング」の三つの意味

この語は少なくとも三つの異なる考えを抱えて登場しました。ネット上の混乱の多くは、人々がそれらを行き来しながら議論していることに由来します。

1. オーケストレーションのグラフ。 マルチエージェント系を while ループではなく明示的なグラフとして設計する。型付きノード、型付き遷移、再開できるチェックポイント。LangGraphやTemporalの領域です。本物の工学ですが、主に効いてくるのはエージェント基盤を作る側です。

2. ループのグラフ。 互いを監視し合う自己改善サイクルのネットワーク。概念としては面白く、大方の評価では現時点で最も実行しづらいもの。

3. グラフ構造をもつ知識と記憶。 エージェントの知識を、実際に辿れる型付きのノードと辺として保持する。毎回読み直して関係を推測し直す文書の山ではなく。

オーケストレーション基盤を作っていないなら——エージェントがワークスペースに入ってくるのを眺めている大半の人がそうです——日々を変えるのは三つ目です。しかも三つの中で最も古く、最も裏付けがあります。知識グラフはこの語より数十年先んじています。

辺が検索に勝つ理由

腑に落ちる例を挙げます。

エージェントにこう尋ねます。「なぜジョブキューでRedisをやめたのか？」

全文検索は「Redis」を含む文書をすべて返します。少し働いていれば数十件になり、そのどれも答えではありません。ベクトル検索は質問に似て聞こえる文書を返します。しばしばこちらのほうが厄介です。意味的には近く、因果的には無関係だからです。

グラフなら三ホップで答えます。

ジョブキュー --decided_by--> ADR-007（Postgresキュー）
ADR-007      --supersedes--> ADR-003（Redisキュー）
ADR-003      --caused------> インシデント 2026-03-11

答えはどの単一文書にもありません。文書間の経路にあります。検索は経路を返せません。ノードを返して、あとはあなたが自分で繋ぐことを期待します。

そして決定的な細部に注目してください。辺には名前が付いています。supersedes は caused ではないし decided_by でもない。ラベルを外せば「これらのファイルは何らかの関係がある」に逆戻りし、エージェントは全部開いて関係を推論し直す羽目になります。まさに避けたかった作業です。

型付きの辺がすべてです。残りは配管にすぎません。

あなたのMarkdown保管庫はすでに8割

一連の議論で最も過小評価されている指摘がこれです。よく手入れされたMarkdown保管庫は、すでにGraphRAG索引の大半である。

wikilink付きのノート群が無料で与えてくれるものを考えてみてください。

• ノード —— 一つの考え、出典、決定につき一ファイル
• 辺 —— すべての [[wikilink]] は誰かが意図して張ったつながり
• 実体解決が構造的に解決済み —— [[ADR-007]] はどこに現れても同じノード。あいまい一致も、埋め込みの衝突も、「この二つの言及は同じものか」という問いも不要

最後の点は小さくありません。実体解決こそ、自動の知識グラフ構築パイプラインの多くが静かに崩れる場所です。保管庫がそれを回避できるのは、人間が一度だけ実体に名前を与え、リンクがそのまま同一性になっているからです。

素の保管庫に欠けているのはラベルです。[[ADR-007]] は二つのノートが繋がっていることは教えてくれます。どう繋がっているかは教えません。それが残りの2割です。

実際にどう動くか

Minibase Vault はまさにこの部分を中心に作られているので、可能性を抽象的に語るより、動きを具体的に書きます。

ノードは読むことから生まれる。 残す価値のあるものの上でMinibaseの拡張機能をクリックすると——ドキュメント、RFC、Xのスレッド、講演——きれいなMarkdownとしてローカルのナレッジベースに着地します。コピペも、エクスポート工程も、ブラウザが落ちたら消える「あとで読む」タブもありません。

辺は理由付きで記録される。 保管庫はルートに _graph.json を持ちます。

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claudeが保管庫のMCPサーバを通じて自分で書き込みます。ノートを横断して読み、つながりに気づいたときに。それらは各ナレッジベースの _index.md に Related: の行として浮かび上がり、網の目はモデルだけでなくあなたにも見えるようになります。

経路はページに凝縮される。 関連ノートの塊が十分に濃くなると、Claudeはそれらを出典付きの _topic-*.md ページに統合できます。次にその塊に属する何かを保存したとき、統合ページはすでにそこにあり、更新されます。これが複利の一歩です。保管庫は大きくなるだけでなく、賢くなります。

孤立ノートには印がつく。 lint の一巡が、重複・孤立ノート・古びた内容・統合しごろの塊を報告します。グラフは劣化します。誰かがそれに気づく必要があります。

すべてローカルで動きます。検索索引はBM25ランキングのSQLite FTS5、グラフはJSONファイル、ノートの内容がマシンを出ることはありません。

過熱を冷ましておきたい点

正直な留保を二つ。一週間で流行した語であり、流行は中身を追い越すからです。

Minibaseの辺が持つのは理由であって、形式的な型ではありません。 "reason": "Both explain the attention mechanism" は文であって supersedes ではない。ラベルなしのwikilinkよりはるかに良く、オントロジーにははるかに届きません。規模のあるマルチホップ推論のために厳密な型付き関係が要るなら、本物のグラフデータベースが必要です。その保守コストについては自分に正直であるべきです。

大半の人にはどれも要りません。 知識が50ノートなら検索で足ります。グラフが元を取り始めるのは、自分が何を持っているか忘れ始めるほど材料が溜まったとき、そして問いが語彙的（「どこで読んだか」）ではなく因果的（「なぜそうしたか」）になったときです。

「グラフエンジニアリング」という語はおそらく年を越さないでしょう。その下にある考え——ノート間の構造は、ノートの量より価値がある——は、名前を持つずっと前から真であり、名前が消えた後も真であり続けます。

退屈な版から始める

1. 読んだものをブックマークではなくMarkdownで保存する。ブックマークは腐るものへのポインタ、ファイルは手元にあるもの。
2. ローカルの一つのフォルダに、出典ごとに一ファイルで置く。
3. AIにフォルダ全体を読ませる——コピペではなくMCPで——そして二つの文書がなければ答えられない問いを投げる。
4. 見つかったつながりを記録する。そして翌月もう一度尋ねる。

オーケストレーションのフレームワークを出荷しない人にとってのグラフエンジニアリングとは、これです。つながりを書き留めた コンテキストエンジニアリング にほかなりません。

---

MinibaseはどんなウェブページもワンクリックできれいなMarkdownに変換し、AIが検索し関連づけられるローカル保管庫へ直接保存します。拡張機能は保存無制限で無料。Minibase Plus（月5.99ドル／年34.99ドル）でAIテンプレート、履歴、動画の文字起こしが加わります。minibase.md。