グラフエンジニアリングとは何か｜「プロンプトは死ぬ」の出どころを追いかけて分かったこと

こんにちは、株式会社TIMEWELLの濱本です。

Xで流れてきた投稿のスクリーンショットを見せてもらいました。Google Brainの立ち上げに関わったアンドリュー・ング氏の発言として、こう書かれています。「プロンプティングは6ヶ月以内に死にます。ループとグラフがそれに取って代わるでしょう」。スタンフォードでの2時間の講義から、というただし書きつきです。

グラフはうちの中核技術なので、正直これは我田引水しやすい話です。だからこそ最初に出どころを確認しました。結果を先に書きます。この発言、一次情報にたどり着けませんでした。

出どころを追いかけたら、たどり着けませんでした

同じ趣旨の投稿が複数のアカウントから出ています。ただ、並べてみると文言が一致しません。

「プロンプティングは6ヶ月で死ぬ。優れたAIエンジニアはすでに自己改善するループを作っている」。「プロンプティングは6ヶ月で死ぬ。グラフがそれに取って代わる」。「3〜6ヶ月で全員が自己改善ループを使うようになる。プロンプティングはもう無い」。

**置き換わる対象が、投稿ごとにループだったりグラフだったり両方だったりします。**同じ講義を聞いた人が同じ発言を引いているなら、こうはなりにくい。伝言ゲームの兆候だと思いました。ング氏本人のアカウント、DeepLearning.AIの発信、スタンフォード側の告知を当たりましたが、この発言に対応する一次情報は見つけられませんでした。

ここは慎重に書きます。**見つけられなかったことは、言っていないことの証明ではありません。**私が探せる範囲に無かった、というだけです¹。ただ、確認できないものを確認できたかのように引くと、その先の話が全部ぐらつきます。

確認できた事実のほうを書きます。DeepLearning.AIには「Agentic Knowledge Graph Construction」という講座が実在します。Neo4jとの共同で、講師は同社のAndreas Kollegger氏。アンドリュー・ング氏は講師ではありません²。内容は、Google の Agent Development Kit を使い、構造化データと非構造化データからノードと関係を抽出する複数のエージェントを設計して、製品の不具合の根本原因を特定するナレッジグラフを自動構築する、というものです。3時間8分、12本の動画レッスン²。

ング氏自身の主張として確認できるのは、2024年に整理したエージェント型ワークフローの4つのデザインパターンです。Reflection（内省）、Tool use（ツール利用）、Planning（計画）、Multi-agent collaboration（複数エージェントの協働）³。

つまり、拡散している一文の真偽はさておき、グラフを使って組む流れが実在することは確かめられます。ここから先は、その中身の話をします。

グラフエンジニアリングとは何か

ひとことで言えば、データを**ノード（もの）とエッジ（関係）**として設計し、関係そのものを検索と推論の対象にする設計手法です。

普通のRAGを思い浮かべてください。質問文をベクトルに変換して、似ているテキストを探してくる。よくできた仕組みですが、この方式が持っていない情報がひとつあります。文書どうしのつながりです。

例で考えたほうが早いと思います。「A社の親会社の、そのまた親会社はどこか」と聞いたとします。ベクトル検索は「親会社」という語を含む似た文書を返してきます。運が良ければ答えが書いてある文書に当たりますが、**A社からB社へ、B社からC社へと2段さかのぼる作業そのものは、類似度計算のどこにも含まれていません。**似ているかどうかと、つながっているかどうかは、別の情報です。

グラフはここが違います。A社というノードから「親会社である」という辺をたどってB社に着き、もう一度たどってC社に着く。答えを探すのではなく組み立てる。この差が効いてくる場面が、実務にはかなりあります。

作業の中心はスキーマ設計です。どんなノード型を置くか（会社、人、製品、案件、規制条項）、どんな関係型を置くか（出資する、供給する、承認した、参照している）。ここが雑だと、あとでどれだけ良いモデルを載せても答えは出ません。先ほどの講座が「エージェントにノードと関係を抽出させる」ことを主題にしているのも、この設計と抽出が一番手のかかる部分だからだと思います。

スキーマを飛ばすとどうなるか。よくあるのは、関係型を「関連する」ひとつで済ませてしまうパターンです。AとBが関連している、とだけ記録すると、出資しているのか、供給しているのか、単に同じ資料に出てきただけなのかが区別できません。**辺に意味が無いグラフは、結局のところ点の集まりと変わりません。**逆に言えば、関係型をきちんと分けた瞬間から、たどれる問いが一気に増えます。

もうひとつ、意外と見落とされるのが時間です。出資関係も供給関係も、いつからいつまでの話なのかで答えが変わります。辺に有効期間を持たせておかないと、3年前に解消された資本関係で今日の判定をしてしまう。過去のスナップショットに戻って確認したいという要求は、あとから必ず出てきます。最初に入れておくほうが安いところです。

社内のAI活用がどこまで進んでいるかを先に把握したい方は、AI活用レベル診断で現在地を見てから読み進めると、後半が具体的になると思います。

「ループとグラフ」は、実は別のレイヤーの話

拡散している投稿がややこしいのは、ループとグラフを並べて語っている点です。この2つ、同じ層の話ではありません。

グラフは知識の構造の話です。何と何がどうつながっているかを、システムが持っておく形式。ループは実行の制御の話です。一度出力して終わりにせず、結果を評価してやり直す流れ。ング氏の4パターンで言えば、Reflectionがループ側、Planningがグラフ側の発想に近いものです³。

両方使う設計はもちろんありますが、「プロンプトがループとグラフに置き換わる」という言い方は、層の違う2つを1つの主語にまとめてしまっています。個人的には、プロンプトが死ぬのではなく、プロンプトの置き場所が変わるという理解のほうが実装に近いと感じています。人間が毎回チャット欄に長文を打ち込む代わりに、グラフの構造とループの制御がその役割の大半を引き受ける。プロンプト自体はシステムの内側に残ります。

輸出管理は、もともとグラフの問題でした

ここからが、私たちが実際に手を動かしている領域の話です。

輸出管理の取引先スクリーニングは、本質的にグラフの問題です。理屈ではなく、制度がそういう形をしています。

分かりやすいのが米国BISの50%ルールです。規制対象リストに載っている事業者が直接50%以上を保有する子会社だけでなく、被支配関係を合算して判断します。つまり、目の前の取引先が規制対象でなくても、株主をさかのぼった先に規制対象がいれば影響が及ぶ。これは株主の辺をたどって到達可能かを調べる作業そのものです。制度の詳細と計算例はBIS 50%ルールの完全解説にまとめました。

**実質的支配者（BO）**の特定も同じ構造です。法人の背後にいる自然人までさかのぼるので、階層を何段も上がることになります。こちらは実質的支配者とは何かで扱いました。

どちらも、文書の類似度検索では原理的に解けません。「この会社は危ないですか」と聞いて似た文書を返してもらっても、資本の連鎖はたどれない。辺をたどるしかないのです。

当社の輸出管理AIエージェントTRAFEEDがナレッジグラフを基盤にしているのは、この理由です。論文9,000万件、特許1億件、研究者30万人を含む2億件超のナレッジグラフを持っていて、取引先の懸念度を5秒で可視化します。岡山大学との共同実証で過去審査データ約3万件を用い、AI判定精度95%以上を確認しました（自社調べ）。特許第7862062号を取得し、20組織以上で使われています。ただし外為法上、最終的な該非判定を行うのは貴社の輸出管理責任者です。出力は判定の根拠資料としてお使いください。ここは制度上動かせない線です。

社内のナレッジも、本当はつながっています

輸出管理は極端な例に見えるかもしれません。でも社内文書も同じです。

ある仕様書は、どの案件のもので、どの顧客に紐づいていて、誰が書いて、どのレビューを通って、どの不具合報告につながったのか。**書かれた時点では全部つながっていた情報です。**それをフォルダに入れてベクトル化した瞬間に、線が消えます。似た文書は出てくるけれど、「この不具合と同じ原因の案件が過去にあったか」には答えられない。

製造業のお客様と話していて、いちばん多いのがこの形の困りごとです。「同じ不具合を、5年前に別の事業部が解決している気がする」。担当者はそう感じているのに、検索では出てこない。当時の報告書は残っているのですが、その報告書と今の案件を結ぶ線が、どこにも記録されていないからです。人が辞めると同時に線が消える、という言い方をされたこともあります。

ZEROCKでGraphRAGを採っているのは、この線を残すためです。国内のAWSサーバーで動かし、誰がどのナレッジにアクセスできるかを統制した上で、関係をたどれる形で持つ。アクセス統制とグラフは相性が良くて、**誰がどのノードを見てよいかを辺の側で表現できます。**部署も権限も、結局は関係だからです。RAGとGraphRAGの違いをもう少し細かく知りたい方は、RAG・GraphRAGのよくある質問20選に技術寄りの整理があります。

今日から試せること

長い話になりましたが、始め方は地味です。2つ挙げます。

**ひとつめ。紙にスキーマを描いてみる。**自社の業務で登場する「もの」を5つ、それらの間の「関係」を5つ書き出す。会社・製品・案件・人・規制。出資する・供給する・承認する・参照する・違反する。これだけで、いま持っているデータのどこに関係が記録されていないかが見えます。だいたいの会社で、関係はメールと会議と誰かの頭の中にしか無いはずです。

ふたつめ。「関係」を問う質問を10個作って、今の検索に投げてみる。「この部品を使っている製品を全部出して」「この顧客と同じ業界で似た不具合が起きた案件は」「この取引先の株主をたどった先に規制対象はいるか」。答えられなかった質問が、グラフが必要な場所です。

冒頭の引用に戻ります。私はあの一文を裏取りできませんでした。それでも、グラフで組む話そのものは本物だと思っています。**バズった一文を疑うことと、その先にある技術を評価することは、両立します。**むしろコンプライアンス領域で製品を出している会社としては、両方やらないといけない。裏取りできない話を根拠に設計を変える、というのが一番まずいやり方です。

社内ナレッジをグラフで持ち直す話も、輸出管理をグラフで組む話も、具体的な状況を聞かせていただくのが早いです。個別相談からどうぞ。

---

Footnotes

1. 本記事で検証対象とした「プロンプティングは6ヶ月以内に死ぬ」という趣旨の投稿は、2026年7月から8月にかけて複数のアカウントから拡散しているが、置き換わる対象が「self-improving loops」であるもの、「graphs」であるもの、両方を挙げるものが混在し、文言が一致しない。本記事執筆時点（2026年8月9日）で、アンドリュー・ング氏本人のアカウント、DeepLearning.AI の発信、スタンフォード大学側の告知のいずれにも、この発言に対応する一次情報を確認できなかった。発言が存在しないことの証明ではなく、確認できなかったという事実の記載である。拡散元の投稿については、エンゲージメント目的の転載が含まれるため個別のURLは掲げない。 ↩

2. DeepLearning.AI「Agentic Knowledge Graph Construction」。Neo4jとの共同開発講座で、講師は同社 Lead for GenAI Innovation の Andreas Kollegger。Google の Agent Development Kit（ADK）、Cypher、Neo4j を使用し、構造化データと非構造化データからノードと関係を抽出する複数エージェントのシステムを設計して、製品の不具合の根本原因を特定するナレッジグラフを構築する。レベルは Intermediate、所要 3時間8分、動画レッスン12本、コード例8本、採点課題1本。アンドリュー・ング氏は本講座の講師ではない。https://www.deeplearning.ai/courses/agentic-knowledge-graph-construction/ ／ 同社にはこのほか Andreas Kollegger 講師の「Knowledge Graphs for RAG」、アンドリュー・ング氏講師の「Agentic AI」がある https://www.deeplearning.ai/courses ↩ ↩²

3. アンドリュー・ング氏が2024年3月に自身のアカウントで示した、エージェント型ワークフローの4つのデザインパターン（Reflection、Tool use、Planning、Multi-agent collaboration）。https://x.com/AndrewYNg/status/1773393357022298617 ↩ ↩²