ナレッジグラフとは何ですか？

人、会社、案件、契約といった対象を節点として置き、それらの関係を線としてつないだ形で知識を持つやり方です。文書をそのまま検索するのではなく、対象どうしのつながりをたどって答えを出せる点が特徴になります。

作業の履歴と知識を同じ場所に置いてはいけないのですか？

かなうテックの見解として、分けることを勧めています。作業の系譜は「何が変わったか、どれが親か、どの枝がまだ生きているか」に答えるもので、知識のグラフは「どんな対象があり、どう関係し、どの出典が支えるか」に答えるものです。答えるべき問いが違います。

グラフにすると何ができるようになりますか？

かなうテックの見解では、共有メモリ、根拠づけ、持続する世界モデルの3つです。担当ごとの記録を突き合わせずに済み、出力に出所を付けられ、セッションをまたいで状態が残ります。

どんなライブラリでグラフを持てばよいですか？

Pythonであれば NetworkX の MultiDiGraph が使えます。公式ドキュメントによれば、これは多重辺を保持できる有向グラフのクラスで、同じ節点の組を複数の辺で結ぶことができ、自己ループも許されます。同じ相手との関係が複数ある業務データに向いています。

AIの抽出結果を安定した形で受け取るにはどうしますか？

Anthropic の構造化出力（Structured outputs）を使います。公式ドキュメントは、これがClaudeの応答を特定のスキーマに従わせ、後続処理で扱える妥当な出力を保証するものだと説明しています。JSON outputs と厳密なツール利用の2つの機能があります。

スキーマはどう書けばよいですか？

生のJSON Schemaを書く方法のほかに、Anthropic の公式ドキュメントはPythonの例としてPydanticのモデルを使う方法を案内しています。使い慣れたスキーマ定義の道具をそのまま使える形です。

抽出と名寄せでモデルを分けるべきですか？

これはかなうテックの設計判断であり、公式の推奨ではありません。件数が多く判定が単純な抽出は軽量なモデルで、文脈を読む必要がある名寄せは上位のモデルで処理する分け方を採っています。費用と精度の兼ね合いで決まります。

同じ人物や同じ案件をまとめる処理で失敗するとどうなりますか？

別人を1つの節点に潰してしまうと、下流のすべての集計が両者の所属、案件、日付、行動を混ぜ始めます。まとめすぎは、つながってはいるが誤ったグラフを作ります。まとめた比率の高さを成果として見ないことが重要です。

何から始めればよいですか？

かなうテックでは、1日目に残す場所を1つに決め、1週目に出典を必ず付け、1か月目に関係を明示的に持ち、2か月目に問い合わせで使う、という順序を勧めています。最初からグラフを作る必要はありません。

ナレッジグラフを作らないほうがよいのはどんな場合ですか？

答えが1つの文書の中で完結する場合、関係が固定的で単純な場合、更新の担い手が決まらない場合です。この条件ではテーブルや全文検索で足ります。エージェントを使っているからグラフが要る、という順序で考えないことです。

ナレッジグラフをいつ持ち込むか：3つの役割と導入順序【2026年版】

この記事の概要

項目	内容
対象読者	AIに社内の知識を扱わせたい開発者、および記録と根拠づけの設計を考えるDX担当者
対象テーマ	業務の知識をグラフとして持つべき場合と持つべきでない場合、そして導入の順序
想定読了時間	約12〜15分
最終更新	2026年8月2日
出典基準	公開されている一次ソース（公式ドキュメント）のみを事実として記述。かなうテックの見解は文中で明示して区別

本記事は全3回シリーズの第3回（最終回）です。第1回ではエージェント1体のループ設計を、第2回では複数体の協働と記録の残し方を扱いました。

本記事で述べる設計論の大部分は、かなうテック（屋号：Kanau Tech™）の見解です。公式に定義された方法論ではありません。実装の足場として引用する部分だけ、公式ドキュメントを出典として明示します。

イントロ：残すべきなのは「やったこと」か、「わかったこと」か

第2回では、試したこと全部を枝としてたどれる形で残す設計を見ました。ここで残っているのは、作業の記録です。何を変え、どうなり、採用したかしなかったか。

しかし業務で必要になる記憶には、もう1種類あります。この会社の担当は誰か。この案件はどの契約に紐づくか。その情報はどの資料に書いてあったか。

これは作業の記録ではなく、業務そのものについて分かっていることです。本記事は、この2つ目の記憶をどう持つかを扱います。

Part 1: 作業の系譜と知識は、別のグラフである

1-1 系譜のグラフが答えられること

第2回で見た commit の DAG は、作業の系譜を表します。答えられるのは、何が変わったか、どの試行が親か、誰が作ったか、どの枝がまだ生きているか、といった問いです。

時間の前後関係と、派生の関係だけを持っています。だから「この結果はどこから来たか」をたどれます。

1-2 知識のグラフが答えられること

一方、業務の知識が答えるべきなのは別種の問いです。どんな対象があるか。それらはどう関係するか。その関係を支える出典は何か。矛盾する記述はないか。

こちらには時間の前後関係が中心にありません。中心にあるのは、対象どうしのつながりです。

1-3 1つに混ぜると何が壊れるか

この2つを1つのグラフに潰すと、どちらの問いにも答えにくくなります。

作業の系譜は、後から書き換えないことに意味があります。一度残した試行の記録を上書きし始めると、たどれるという性質が失われます。

業務の知識は逆に、更新され続けることに意味があります。担当者が変わり、契約が更新され、以前の記述が古くなる。古い記述を消さずに、新しい記述が古い記述に取って代わったという関係を持たせる必要があります。

保存の方針が正反対です。片方は追記のみ、もう片方は版を持って置き換わる。 1つの仕組みで両方を満たそうとすると、どちらかの性質を諦めることになります。

1-4 中小企業の業務に置き換えると

この区別は、システムの話をする前の段階で効いてきます。

多くの職場では、この2つが同じ場所に混ざっています。たとえば案件フォルダの中に、やりとりの経緯と、確定した条件が並んで置かれている。すると「結局いくらで合意したのか」を知るために、経緯を全部読むことになります。

分けるとは、フォルダを2つにすることではありません。確定した事実には、いつ時点の何であるかと、どの資料に基づくかを付けて別に置く。経緯はそのまま時系列で残す。この2つを別々に引けるようにするだけで、探す時間はかなり減ります。

Part 2: グラフに担わせる3つの役割

ここから述べる3つの役割は、かなうテックが実務で使い分けている整理です。

2-1 共有メモリ

複数の担当が同じ案件を調べるとき、それぞれの手元に情報が溜まります。最後にまとめる人は、全員の記録を読んで突き合わせることになります。

所見を構造化した形でグラフへ書き込んでおくと、この突き合わせが要らなくなります。まとめる側は、誰がどの資料を読んだかを追わずに、グラフをたどって統合できます。

エージェントを複数動かす場合、この効果はさらに大きくなります。指揮役のコンテキストへ作業役のやりとりを丸ごと写す必要がなくなるからです。

2-2 根拠づけ

出力に出所を付けられることが、2つ目の役割です。

たとえば「この取引先が、あの案件に関わる部材を納入した」という主張があるとします。グラフを持っていれば、納入の関係と、案件への関与の関係が両方存在するかを確認できます。無ければ、どの関係が足りないかを構造として返せます。

自由記述の指摘より、受け取った側が直しやすくなります。「根拠が弱い」ではなく「この関係を示す出典が無い」と返るからです。

2-3 持続する世界モデル

3つ目は、セッションをまたいで残ることです。会話の履歴に頼った記憶は、会話が終われば消えます。

長期の調査、複数回にまたがる計画、資料を少しずつ取り込んでいく作業では、この差が決定的になります。矛盾の追跡、いつ時点の事実か、どの決定がどの決定に取って代わったか。こうした情報は、会話の外に置かないと保てません。

2-4 3つを1つの仕組みで満たそうとしない

この3つは、必要とする性質が異なります。共有メモリは書き込みの速さが要ります。根拠づけは出典の厳密さが要ります。持続する世界モデルは版の管理が要ります。

最初から3つ全部を満たす仕組みを作ろうとすると、どれも中途半端になります。自社にとって痛みが大きい1つから始めるほうが進みます。

Part 3: 実装の足場

3-1 グラフ構造をどう持つか

Pythonであれば、NetworkX の MultiDiGraph が素直な選択になります。公式ドキュメントは、これを多重辺を保持できる有向グラフのクラスと説明しています^[1]。多重辺とは、2つの節点のあいだに複数の辺があることです。それぞれの辺は任意のデータや属性を持て、自己ループも許されます^[1]。

業務データでは、同じ相手との関係が複数あるのが普通です。同じ会社が、発注元でもあり外注先でもある。この形をそのまま持てることが、多重辺が要る理由です。

3-2 抽出結果の形を固定する

文書から対象と関係を取り出す工程では、出力の形が毎回変わると後段が壊れます。

Anthropic の構造化出力（Structured outputs）は、この問題に対する公式の機能です。公式ドキュメントは、これをClaudeの応答を特定のスキーマに従わせ、後続処理のために妥当で解析可能な出力を保証するものと説明しています^[2]。機能は2つに分かれており、応答を特定のJSON形式で受け取る JSON outputs と、ツール名と入力のスキーマ検証を保証する厳密なツール利用です^[2]。

スキーマの書き方も選べます。生のJSON Schemaを書く代わりに、使い慣れたスキーマ定義の道具を使えると公式ドキュメントは述べており、Pythonの例として Pydantic のモデルが挙げられています^[2]。

ここで重要なのは、学習済みの固有表現抽出器や関係分類器を用意しなくてよくなる点です。スキーマの定義そのものが、抽出の仕様になります。

3-3 モデルをどう使い分けるか

抽出と名寄せで使うモデルを分けるかどうかは、公式に推奨があるわけではありません。ここからはかなうテックの設計判断です。

件数が多く判定が単純な抽出は、軽量なモデルで処理します。一方、同じ対象を指す複数の表記をまとめる名寄せは、文脈を読む必要があるため上位のモデルに任せます。

なぜ名寄せが難しいのか。表記が似ているかどうかでは決まらないからです。まったく文字の重ならない2つの表記が同じ対象を指すことも、よく似た2つの表記が別の対象を指すこともあります。文字列の類似度では届きません。説明文や周辺の記述を文脈上の証拠として使い、判断する処理になります。

3-4 名寄せは、間違えると圧縮より高くつく

名寄せの評価で、まとめた比率の高さを成果として見ないことが重要です。

別の対象を1つの節点に潰すと、下流のすべての集計が混ざり始めます。 2人の担当者を1つにまとめてしまえば、所属も案件も日付も行動も混ざったまま、それらしい答えが返ってくるようになります。つながってはいるが誤ったグラフができあがり、しかも見た目には気付きにくくなります。

そこで、まとめた結果には元の表記、出典の文書、まとめた根拠、確からしさ、その処理を行った実行の記録を残します。残しておけば、誤ってまとめた箇所だけを後から戻せます。全部を作り直す必要がなくなります。

この考え方は第1回で扱ったループの規律と同じです。巻き戻せる形にしておく、ということです。

Part 4: 導入順序

ここから示す順序は、かなうテックが実務で採っている進め方です。

4-1 1日目：残す場所を1つに決める

グラフを作る必要はありません。まず、確定した事実を書き込む場所を1つに決めます。表計算でも、業務システムの1つのテーブルでもかまいません。

決めることは1つです。確定した事実は、経緯とは別のここに書く。

4-2 1週目：出典を必ず付ける

書き込む1件ごとに、どの資料に基づくかを付けます。資料名でも、メールの日付でも、システムの画面名でもかまいません。

これを最初からやっておくかどうかで、後の作業量が変わります。出典のない事実は、後から出典を付け直せません。どこから来たか分からなくなった時点で、確認し直すしかなくなります。

4-3 1か月目：関係を明示的に持つ

事実が溜まってきたら、対象どうしの関係を別の列や別の表として持ちます。この会社とこの案件、この案件とこの契約、というつながりです。

この段階で初めて、グラフに近い形になります。逆に言えば、ここまでは関係テーブルで足ります。

4-4 2か月目：問い合わせで使う

つながりをたどる問いを、実際に投げてみます。この取引先が関わった案件のうち、今も継続しているものはどれか。この担当者が抜けたら、影響が出る案件はどれか。

ここで答えが返ってくるなら、投資は回収されています。返ってこないなら、持っている関係が足りないか、そもそもそういう問いが業務に無いということです。後者であれば、次のPartの話になります。

Part 5: グラフを持ち込まないほうがよいとき

エージェントを使っているからグラフが要る、という順序で考えないことです。

5-1 関係をたどる問いが出てこない場合

業務で実際に出てくる問いが、1つの文書を見れば答えられるものばかりなら、グラフは要りません。「この契約書の更新日はいつか」に答えるのに、つながりをたどる必要はありません。

つながりをたどる問いとは、複数の対象を経由しないと答えられない問いのことです。これが業務に無いなら、テーブルか全文検索で足ります。

5-2 関係が固定的で単純な場合

対象の種類が少なく、関係の型が変わらないなら、関係テーブルのほうが扱いやすくなります。グラフの利点は、関係の型が増えたり変わったりすることに強い点にあります。変わらないものに対しては、その利点が効きません。

5-3 更新の担い手が決まらない場合

これが実務では最も多い理由です。

グラフは放置すると膨らみます。古い事実、間違ってまとめた節点、根拠を失った関係が溜まっていきます。誰がいつ整理するかが決まっていないと、しばらくして「合っているか分からないもの」に変わります。

作る前に、更新の担当と頻度を決められないなら、まだ早いということです。第1回で述べた4条件のうち「巻き戻せる」と同じ話で、直す手段が用意されていない仕組みは、いずれ使われなくなります。

まとめ：記憶と評価をどこに置くかが、任せられる範囲を決める

3回にわたって扱ってきたのは、モデルの能力ではありませんでした。

第1回では、判定を1つに定め、時間を固定し、1周ごとに残すか捨てるかを決めるループを見ました。第2回では、試したこと全部を枝としてたどれる形にする設計と、並列化の上限とコストを見ました。第3回では、業務の知識を作業の記録とは別に持つこと、そして持たないほうがよい場合を見ました。

共通しているのは、暗黙のまま置かれていたものを、明示的な形に移すという作業です。頭の中にあった判断基準を、測れる指標にする。会話の中で流れていた経緯を、たどれる記録にする。「たぶんそうだったはず」を、出典の付いた事実にする。

そのうえで、Anthropic が公式記事で述べている助言をもう一度引いておきます^[3]。単純なプロンプトから始め、包括的な評価で最適化し、単純な解では足りないときにだけ多段のエージェント構成を足す。

順序を飛ばさないことです。記録が追えないうちにエージェントを増やしても、分からないことが増えるだけになります。

回	テーマ	示した内容
第1回	ループ設計	3つのファイルに分ける構造、1回1変更の規律、任せられる仕事の4条件
第2回	協働と探索グラフ	変更履歴を探索の記録として扱う設計、協働の5パターン、並列化の上限とコスト
第3回（本記事）	知識の置き場所	作業の系譜と知識を分ける理由、3つの役割、導入順序、グラフが不要な場合

自社の業務でどこまでを記録として残すべきか、どこから自動化に載せられるかの切り分けは、無料相談でも承っています。

参考文献

すべての出典は2026年8月2日時点のものです。

NetworkX 公式ドキュメント「MultiDiGraph」 — https://networkx.org/documentation/stable/reference/classes/multidigraph.html
Anthropic 公式ドキュメント「Structured outputs」 — https://platform.claude.com/docs/en/build-with-claude/structured-outputs
Anthropic「Building Effective AI Agents」（2024年12月19日） — https://www.anthropic.com/engineering/building-effective-agents

注記：本記事のうち、公式ドキュメントに基づく記述は Part 3-1 の MultiDiGraph の性質と、Part 3-2 の構造化出力（Structured outputs）の機能、およびまとめで引用した Anthropic の助言のみです。Part 1、Part 2、Part 3-3、Part 3-4、Part 4、Part 5 は、いずれもかなうテック（屋号：Kanau Tech™）が実務で用いている整理と判断であり、公式に定義された方法論ではありません。構造化出力の対応モデルと利用条件は変更されうるため、導入前に公式ドキュメントでご確認ください。本記事は特定のライブラリやサービスの採用を推奨するものではなく、自社の業務に合うかどうかは個別にご判断ください。