ナレッジグラフを渡すとAIのコストは下がりますか？

問いの型によります。かなうテックが422ファイルのリポジトリで測った範囲では、総コストは7.6%増えました。複数の仕組みをまたぐ問いでは3割下がり、grepで終わる問いでは5割増えています。

Claude CodeにMCPのmemoryサーバを入れるにはどうしますか？

claude mcp add memory -- npx -y @modelcontextprotocol/server-memory を実行します。転送方式はstdioが既定なので指定は不要です。-s で設定の適用範囲（local、user、project）を選べます。

グラフの保存先はどこになりますか？

公式実装のソースによれば、既定ではサーバ本体と同じディレクトリに memory.jsonl が作られます。プロジェクト内に置きたい場合は環境変数 MEMORY_FILE_PATH に絶対パスを渡してください。相対パスはサーバ側のディレクトリを基準に解決されます。

AIのコストや所要時間はどうやって測ればよいですか？

claude -p "問い" --output-format json を使うと、コスト、所要時間、ターン数、キャッシュ読み取りトークンがJSONで返ります。対話画面の数字を目視で読むより再現性があり、プロンプト全文がコマンドに残ります。

グラフが古くなるとどうなりますか？

推測より悪くなる場合があります。かなうテックの実測では、構築直後にもかかわらず、グラフに記録されなかった関係を「関係が無い」として報告する場面が出ました。時間が経てば、この種の欠落は増えます。

Claude Codeに構造を渡して測ってみた：効いた問いと効かなかった問い【2026年版】

この記事の概要

本記事は全4回シリーズの第3回です。

第1回で概念、第2回で標準を扱いました。

今回は実装です。

そして、実際に測った数字を出します。

先に結論を書きます。

422ファイル、約1万行のリポジトリで24回測った範囲では、総コストは下がりませんでした。

探索の回数は23%減りましたが、総コストは7.6%増え、所要時間は25%増えました。

同時に、問いの型によって符号が割れることも分かりました。

以下、測り方と数字と、そこから引ける線を順に書きます。

Part 1. 先例としてのリポジトリマップ

コードの構造をAIに渡すという発想には先例があります。

AIペアプログラミングのCLIであるAiderは、リポジトリマップという仕組みを持っています。

Aiderの公式ブログによれば、このマップはtree-sitterを使ってソースファイルからシンボルの定義を取り出し、自動的に構築されます¹。

大きなリポジトリではマップ自体が大きくなりすぎるため、絞り込みが入ります。

公式ドキュメントの説明では、各ソースファイルを節点とし、依存関係のあるファイルどうしを辺で結んだグラフを作り、そのグラフに対するランキングのアルゴリズムでマップ全体を分析します²。

渡す量は --map-tokens で決まり、既定は1,000トークンです²。

ただし固定ではなく、チャットの状態に応じて動的に調整されると説明されています²。

設計の考え方は、実装の全体を見せる必要はなく、必要なファイルを自分で特定できるだけの情報があればよい、というものです。

第1回のPart 5で挙げた、探索の回数が減ることと渡す情報の密度が上がることを、コードの領域で実装した形にあたります。

Part 2. MCPのmemoryサーバで手を動かす

Claude Codeで最も手軽に構造を持たせる手段が、MCPの公式リファレンス実装であるmemoryサーバです。

正式名称はKnowledge Graph Memory Serverで、ローカルのナレッジグラフを使って記憶を持続させる基本的な実装だと説明されています³。

なお公式リポジトリで現在も維持されているサーバは7つほどで、memoryはその1つです³。

データモデル

3つの要素で構成されます³。

Entities：グラフの節点。一意の名前、entityType（person、organization、event など）、observationsのリストを持つ
Relations：節点どうしの有向のつながり。from、to、relationType を持ち、常に能動態で保存される（works_at など）
Observations：エンティティに紐づく事実の文字列。独立して追加、削除でき、1つにつき1つの事実にすべきものとされる

Observationsを細かく保つという指針は、後で効いてきます。

1つの文字列に複数の事実を詰め込むと、消したい事実だけを消せなくなります。

提供される道具

9つのツールが提供されます³。

create_entities、create_relations、add_observations、delete_entities、delete_observations、delete_relations、read_graph、search_nodes、open_nodes の9つです。

加えて、グラフ全体を memory://knowledge-graph というMCPリソースとして読み出せます³。

変更系のツールは更新の通知を発行するため、購読しているクライアントは変更を追えます³。

導入

claude mcp add memory -- npx -y @modelcontextprotocol/server-memory

転送方式はstdioが既定なので、指定は不要です。

設定の適用範囲は -s で選べます（local、user、project）。

保存先には落とし穴がある

公式実装のソースを読むと、既定の保存先はサーバ本体と同じディレクトリの memory.jsonl です⁴。

プロジェクトの直下ではありません。

npx で導入すると、パッケージが展開された場所に置かれます。

環境変数 MEMORY_FILE_PATH で変更できますが、ここにも注意が要ります。

相対パスを渡した場合、サーバ側のディレクトリを基準に解決されます⁴。

プロジェクトの中に置きたければ、絶対パスを渡す必要があります。

以下は今回の計測で実際に使った設定です。

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": { "MEMORY_FILE_PATH": "/絶対パス/measurement/ontology-memory.jsonl" }
    }
  }
}

Part 3. 自分のリポジトリで測った

ここからが本記事の中心です。

なぜ自分で測るのか

グラフを入れるとコストが何割減る、といった数字はいくつか流通しています。

今回、それらの出典を一次資料まで辿ろうとしましたが、辿り着けませんでした。

引用元をさかのぼると、別の記事に行き当たり、そこにも一次資料がない、という形です。

辿れない数字は本記事には書きません。

代わりに、自分の環境で測った数字だけを出します。

測定条件

項目	値
対象	自社サイトのリポジトリ。追跡ファイル422、TypeScript 92ファイル・9,937行
CLI	Claude Code 2.1.220
主モデル	Sonnet
副モデル	Opus（1問のみ追試）
実施日	2026年8月2日
反復	各条件・各問い2回
実行数	Sonnet 20回、Opus 4回、グラフ構築1回

測り方

対話画面の数字を目で読む方法は再現性がありません。

headlessの実行とJSON出力を使いました。

claude -p "問い" --output-format json \
  --strict-mcp-config --mcp-config ./mcp-config.json \
  --disable-slash-commands --permission-mode bypassPermissions \
  --model sonnet

返るJSONから、total_cost_usd、duration_ms、num_turns、usage.cache_read_input_tokens、usage.output_tokens を記録しました。

--strict-mcp-config を付けている理由があります。

これを付けないと、その環境につないである他のMCPサーバの定義がすべて読み込まれます。

実際に測ると、「1+1は」という最小の問いですら、環境の定義だけで7万トークンが積まれていました。

サーバとスキル一覧を切ると5万トークンまで下がります。

差の2万トークンは問いと無関係な固定費であり、グラフの効果を測るうえでは純粋なノイズです。

自分の環境の構成を測ってしまわないよう、両条件から他のサーバを外しました。

問いは5本、先に固定した

実行前に問いと正解を決め、実行中も実行後も変えていません。

ブログ記事の必須項目を1つ増やすとき、変更が必要なファイルを全て挙げよ
ビルドを失敗させる検証は何種類あり、どのファイルで実装され、どこから起動されるか
ある関数はどこから呼ばれているか、全て挙げよ
記事を1本公開するとき、記事ファイル以外に更新が必要なファイルと、更新しなかった場合に起きること
新しいサービスページを1ページ追加するとき、触るべきファイルを順に挙げよ

条件Aはグラフなし、条件Bはグラフありで、A、B、A、Bと交互に実行しました。

交互にしたのは、プロンプトキャッシュの影響を片側に寄せないためです。

グラフの構築コスト

条件Bのグラフは、手書きではなくAIに作らせました。

リポジトリを読ませ、エンティティと関係を登録させる形です。

結果は63エンティティ、74関係。

構築にかかったのは4分54秒と1.09ドルでした。

この時点で分かることがあります。

構築費は、質問2回から3回分にあたります。

数回しか問わないなら、元が取れません。

結果

Sonnetでの20回の合計です。

指標	グラフなし	グラフあり	差
合計コスト	3.3507ドル	3.6067ドル	+7.6%
合計所要時間	375.5秒	470.6秒	+25.3%
合計ターン数	95	73	−23.2%
キャッシュ読み取り	4,245,515	3,511,286	−17.3%
出力トークン	24,032	34,155	+42.1%

探索は確かに減りました。

ターン数が23%、キャッシュ読み取りが17%減っています。

ファイルを片端から開く挙動は、実際に減りました。

しかし出力トークンが42%増え、コストと時間はむしろ悪化しました。

グラフを見たAIは、探索を減らした分だけ長く詳しい回答を書きます。

表が増え、根拠の列挙が増えます。

読む量が減れば安く速くなる、という説明は、読む量の部分だけが当たり、支払いの部分が外れました。

問いごとに符号が割れる

問い	種類	なし	あり	差	ターン数
1. 影響範囲	広くたどる	0.7944	1.1486	+44.6%	31 → 24
2. 検証の所在	grepで済む	0.4179	0.5571	+33.3%	10 → 12
3. 呼び出し元	grepで済む	0.2850	0.4393	+54.1%	4 → 10
4. 公開時の同期	広くたどる	1.0428	0.9014	−13.6%	30 → 18
5. ページ追加の手順	広くたどる	0.8105	0.5603	−30.9%	20 → 9

はっきり分かれました。

効いたのは問い4と問い5です。

どちらも複数の仕組みをまたいで、順序と依存を答える形の問いです。

問い5はターン数が20から9に半減し、コストが3割下がりました。

逆効果だったのは問い2と問い3です。

どちらもgrep一発で終わります。

グラフなしの条件では、問い3は2ターン、0.048ドルで正解にたどり着いています。

グラフありの条件はグラフを読み、さらにgrepで裏を取るため、6ターン、0.141ドルかかりました。

答えが1か所にある問いに対して、グラフは純粋な上乗せになります。

問い1が広くたどる型なのにグラフありのほうが高いのは、2回目の実行が突出したためです。

2回では外れ値をならせません。

モデルを変えると符号が反転した

同じ問い1をOpusで追試しました。

指標	グラフなし	グラフあり	差
合計コスト	1.8050ドル	1.5500ドル	−14.1%
合計所要時間	191.4秒	155.8秒	−18.6%
合計ターン数	41	31	−24.4%

Sonnetで44.6%増だった問いが、Opusでは14.1%減になりました。

1つのモデルで測った数字を、オントロジーの効果として一般化することはできません。

回答の質は変わらなかった

コストと時間を見ない状態で、回答本文だけを正解表と突き合わせて採点しました。

グラフなしは8つが正解、2つが一部漏れ。

グラフありは7つが正解、3つが一部漏れ。

どちらも致命的な誤りはありませんでした。

この規模で精度が上がる、とは言えません。

Part 4. 観測できた2つの失敗モード

数字より重要かもしれない部分です。

グラフが粗いと、確認作業がかえって増える

構築されたグラフには、あるページがライブラリを呼び出す、という関係が記録されていました。

しかし実際に呼んでいたのは別の関数です。

関係がファイル単位で記録されており、関数単位ではありませんでした。

グラフありの条件は、これを見たうえでgrepで裏を取り直しています。

回答本文に「grepで実際のコードを確認し、上記4箇所のみが正しいことを検証済み」と書かれていました。

グラフが粗いと、AIはグラフを信じずに検証します。

検証の分だけターンが増えます。

問い3でグラフありが3倍かかった主な原因はこれです。

グラフに無いものは「無い」として報告される

問い5で、グラフありの条件はヘッダーとフッターについてこう答えました。

グラフに関係が記録されていないので、必要なら別途確認すること。

事実としては、どちらもリンクを持っています。

グラフの欠落が、そのまま回答の欠落として出ました。

一方、グラフなしの条件は実ファイルを読み、フッターを行番号つきで指したうえで、既存のリンク漏れという不整合まで見つけています。

第2回のPart 4で扱った開放世界仮定が、ここで具体的な形を取りました。

書いていないことは未知であって、無いことではありません。

しかし運用上は、未知はそのまま欠落として現れます。

今回のグラフは構築直後で、鮮度は最良の状態でした。

それでもこの欠落が起きています。

時間が経てば悪化します。

グラフを持つなら、いつ、誰が、どう更新するかを先に決めることになります。

Part 5. CLAUDE.mdとの役割分担

ここからは、かなうテックが実務で使っている整理であり、公式の指針ではありません。

CLAUDE.mdとオントロジーは競合しません。

役割が違います。

CLAUDE.mdは指示です。

「APIはこのディレクトリに置く」「テストは必ず書く」のような、常に守るべきルールを書きます。

毎回のセッションで全文が読み込まれるので、少数である必要があります。

オントロジーは事実です。

何があり、どうつながっているかを書きます。

数が多くてよく、必要な部分だけを取り出して使います。

依存関係をCLAUDE.mdに箇条書きで全部書くと、毎回のセッションで全トークンを消費したうえ、結局は平らな並びなのでたどれません。

逆に「テストを必ず書け」をグラフに入れても、AIが読みに行かなければ効きません。

なお、グラフをどこに置き、誰が運用し、どの順序で導入するかという保存と運用の設計は、ナレッジグラフをいつ持ち込むかで扱っています。

Part 6. 文書からグラフを組み立てる方法

memoryサーバは、AIに手作業でグラフを作らせる方式です。

文書の集まりから体系的に組み立てる方法を、Anthropicの公式Cookbookが公開しています⁵。

扱うのは、固有表現の認識、関係の抽出、エンティティの解決、エンティティの要約という古典的な4つの作業です⁵。

手順は、抽出、エンティティ解決、グラフの組み立て、エンティティの要約、問い合わせと進み、抽出品質を測る評価の仕組みが同梱されています⁶。

数字も具体的です。

Apollo計画に関するWikipediaの要約6本から、36のエンティティと34の関係が抽出され、名寄せを経て22の正規エンティティになりました⁶。

できたグラフは22節点、34辺、連結成分は1つです⁶。

連結成分が1つであることには意味があります。

Cookbookは、連結成分が1つであることはエンティティ解決が機能した印であり、島に分かれている場合は本来まとめるべき表記ゆれがまとまっていないことを示す、と説明しています⁶。

運用の指針も書かれています。

抽出は高速で安価なモデル、エンティティ解決と要約は矛盾する証拠を評価する必要があるため上位のモデル、という使い分けです⁶。

24時間待てる処理はバッチ処理のAPIで半額になります⁶。

保存については、数十万辺まではメモリ上のライブラリで足り、それを超えるならプロパティグラフのデータベースか、3つのテーブルに分けた関係データベースに移す、という目安が示されています⁶。

失敗のしかたも2つ明記されています⁶。

1つは、まとめる処理から漏れた名前がグラフから静かに消えること。

もう1つは、まとめすぎて別の実体を1つに統合してしまうことです。

前者は節点を失い、後者は精度を失います。

Part 4で書いた2つの失敗モードのうち、後者はこのまとめすぎと同じ構造です。

なお、この手順を実装する足場については既存記事で扱っているため、本記事では手順の紹介にとどめます。

Part 7. どこから導入すべきか

実測から引ける線を書きます。

これはかなうテックの判断です。

効かない可能性が高い場合

ファイル数が数百規模のリポジトリ。

今回測った規模がここにあたり、総コストは増えました。

答えが1か所にある問いが中心の場合。

grepやファイル検索で終わる問いに対して、グラフは上乗せにしかなりません。

グラフを誰も更新しない場合。

Part 4で見たとおり、欠落はそのまま回答の欠落になります。

構築直後ですらこれが起きます。

効く可能性がある場合

複数の仕組みをまたいで、順序と依存を答える問いが多い場合。

今回の測定でも、この型の問いだけは3割の改善が出ました。

同じ問いを何度も投げる場合。

構築費は1回ですが、効果は問うたびに出ます。

今回は構築に質問2回から3回分のコストがかかりました。

問いの回数が増えるほど、この初期費用は薄まります。

測ってから決める

今回いちばん強く言えることは、これです。

自分の環境で測れば、判断できます。

必要なのはコマンド1つと、事前に固定した問いと、正解表だけです。

流通している数字を根拠にするより、24回の実測のほうが自社の判断材料になります。

測定範囲の限界

本記事の数字は次の範囲に限られます。

反復は2回で、中央値は出せていません。

1つのリポジトリ、1つの規模でしか測っていません。

グラフは1回の自動構築のみで、人手で精緻化したものは試していません。

数百から数千ファイルの規模は測っていません。

効かなかったのではなく、この条件では効かなかった、というのが正確な言い方です。

Part 8. 業務で言うと何にあたるか

今回の結果は、ソフトウェア以外の場面にもそのまま当てはまります。

業務手順を関係として書き出す作業には、作る手間と、更新し続ける手間がかかります。

書き出しただけで放置すると、現場と食い違った手順書が残ります。

食い違った手順書は、手順書が無い状態より危険です。

書いてあるので、確認されないまま使われるからです。

一方で、影響範囲を問う場面は、書き出す価値が最も出る場面です。

「この規程を変えたら、どの様式に波及するか」は、今回の測定で効いた問い5と同じ形をしています。

導入の判断は、次の順序になります。

まず、自社で実際によく出る問いを書き出す。

その問いが、たどる型なのか、探す型なのかを分ける。

たどる型が多いなら、関係を書き出す価値があります。

自社の業務でどの問いが繰り返し出ているか、それが探す型かたどる型かの切り分けは、無料相談でも承っています。

シリーズ一覧

回	内容
第1回	概念。5つの構成要素、関係の型、RAGとの使い分け、参考情報と実行基盤の区別
第2回	標準。RDFのトリプル、OWL、推論、開放世界仮定、厳密さの止めどころ
第3回（本記事）	実装と実測。24回の測定、効いた問いと効かなかった問い、2つの失敗モード
第4回	業務への適用。書き起こしの5つの手順

参考文献

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

Aider 公式ブログ「Building a better repository map with tree sitter」（2023年10月22日） — https://aider.chat/2023/10/22/repomap.html
Aider 公式ドキュメント「Repository map」 — https://aider.chat/docs/repomap.html
Model Context Protocol 公式リポジトリ「Knowledge Graph Memory Server」README — https://github.com/modelcontextprotocol/servers/tree/main/src/memory
同上、src/memory/index.ts の保存先解決処理 — https://github.com/modelcontextprotocol/servers/blob/main/src/memory/index.ts
Anthropic Cookbook「Knowledge Graph Construction with Claude」README — https://github.com/anthropics/anthropic-cookbook/tree/main/capabilities/knowledge_graph
同上、guide.ipynb の本文および実行結果 — https://github.com/anthropics/anthropic-cookbook/blob/main/capabilities/knowledge_graph/guide.ipynb

注記：本記事のうち、Part 1からPart 2、およびPart 6は、公式ドキュメント、公式リポジトリのソース、公式Cookbookに基づく記述です。Part 3とPart 4の数値と観察は、かなうテック（屋号：Kanau Tech™）が2026年8月2日に自社リポジトリで実施した測定の結果であり、他の環境で同じ数字が出ることを保証するものではありません。Part 5とPart 7の判断は、かなうテックが実務で用いている整理です。ツールの仕様とモデルの挙動は変更されうるため、導入前に公式の情報をご確認ください。