「見つけた」と「推測した」に札を付ける。コードを知識グラフにする道具

コードやPDFを読み込んで知識グラフを作るスキルが公開されています。ベクトル検索を使わず、辺の種類で確からしさを分けているのが特徴です。

この記事の結論

  1. コード・文書・PDF・画像をまとめて1つのグラフにする
  2. ベクトル検索を使わない。コードは構文解析で確定的に読む
  3. 辺に「見つけた」「推測した」「曖昧」の札を付ける
  • コード・文書・PDF・画像をまとめて1つのグラフにする
  • ベクトル検索を使わない。コードは構文解析で確定的に読む
  • 辺に「見つけた」「推測した」「曖昧」の札を付ける

Claude Code などで使えるスキルgraphifyが公開されている。

やることは「コードベースを知識グラフにする」。この手の道具は珍しくないが、設計の考え方が他と違うので整理しておく。

何をするものか

フォルダを指定すると、中身を読んでグラフを作る。出てくるのはこれらになる。

  • 対話できるグラフ(HTML) — 節点をクリックして辿れる
  • Obsidianの保管庫として開ける形式
  • 記事形式のwiki — エージェントがファイルを読んで辿れる
  • レポート — 中心になっている概念、意外なつながり、聞くべき質問
  • グラフのJSON — 後日また使える

扱える種類も広い。

種類読み方
コード構文解析(tree-sitter)+呼び出し関係の走査
文書(.md .txt .rst)概念と関係をAIで取り出す
論文(.pdf)引用の抽出と概念の取り出し
画像(.png .jpg など)画像認識で読む。図やホワイトボードの写真も
SPONSORED

ベクトル検索を使わない

ここが一番の特徴になる。説明文に「no vector store」と明記されている。

この種の道具は、普通なら文章を数値の並びに変換して、似ているものを探す作りにする。手軽だが、なぜそれが出てきたのかを説明できない。

graphifyはコードについては構文解析で確定的に読む。関数がどこから呼ばれているかは、推測ではなく構文として決まっているからだ。

確定的に読める部分と、読めない部分を分けている

一方で、文書や画像は構文解析できない。そこはAIで読む。つまり確からしさが違う情報が、同じグラフに混ざる。

その扱いが、この道具の肝になる。

すべての辺に EXTRACTED(見つけた)、INFERRED(推測した)、AMBIGUOUS(曖昧) の札が付く。何が見つかったもので、何が推測かが常に分かる。

混ぜるが、区別を残すという設計だ。

これは今月ずっと書いてきた話と同じ

このサイトでは10月、企業の発表を読んで「確認された」と「可能性がある」を分けるという話を何度も書いた。

graphifyがやっているのは、それを機械の出力に対してやるということになる。

AIに何かを読ませると、確かなことと推測が同じ調子で出てくる。読む側には区別がつかない。札が付いていれば、少なくとも疑う場所が分かる。

公表されている数字

説明文には、トークン量の比較が載っている。

混在した資料(リポジトリ+論文+画像、52ファイル)で、生のファイルを読む場合と比べて71.5倍少ないトークンで1回の問い合わせができる。

ただし、そのすぐ後に効かない条件も書いてある。

トークンの削減量は資料の規模に比例する。6ファイルなら、そもそも文脈に収まるので、グラフの価値は圧縮ではなく構造の見通しになる。

実際、載っている3つの例のうち1つは削減がほぼ1倍だ。効かない例を自分で載せているのは、信用できる書き方だと思う。

数字の読み方については自社測定のベンチマークをどう受け取るかに書いた。今回は入力と出力の両方が公開されていて、自分で確かめられる形になっている。

使うときに確認すること

導入の前に見ておきたい点を挙げる。

項目内容
ライセンスApache-2.0
必要なものClaude Code と Python 3.10以上
動く場所手元で動く。サーバーもNeo4jも不要
版PyPI の graphifyy が 0.9.92

いくつか引っかかる点

  • PyPIの名前が graphifyy — 説明では「graphify の名前を取り戻している間の一時的なもの」とされている。実際、graphify は取得されていない
  • バージョンが 0.9.92 — まだ1.0ではない
  • 既定のブランチが v8 — READMEの表示は v1 を指しており、ずれている

とくに名前の件は、似た名前のパッケージを入れてしまう危険があるので注意したい。名前が1文字違うものを入れる形は、取り違えが起きやすい。

自分では動かしていない

正直に書いておくと、この記事は公開されている説明文と、リポジトリの情報を読んで書いたものになる。実際に動かして確かめてはいない。

なので71.5倍という数字も、出力の質も、こちらで検証したものではない。書けるのは「何をすると言っているか」と「その設計をどう読むか」までになる。

試すなら、自分の小さめのプロジェクトで、出てきたグラフを目で確かめるのが早いと思う。札が付いている以上、INFERRED の辺がどれくらい当たっているかは見れば分かる。

まとめ

  • コード・文書・PDF・画像を1つの知識グラフにするスキル
  • ベクトル検索を使わない。コードは構文解析で確定的に読む
  • 辺にEXTRACTED / INFERRED / AMBIGUOUS の札を付ける
  • 確かなことと推測を混ぜるが、区別は残すという設計
  • トークンの削減は資料の規模に比例。小さい資料では効かないと自分で書いている
  • Apache-2.0、手元で動く、サーバー不要
  • PyPIの名前が1文字違う点と、まだ0.9系である点は確認してから
SPONSORED

出典

  • Graphify-Labs/graphify(GitHub)(README、対応する種類と抽出方法、辺の分類、トークン削減の数値と条件、技術構成、ライセンス。2026年10月19日に確認)
  • PyPI「graphifyy」(バージョン 0.9.92、Python 3.10以上)

本記事は2026年10月19日時点の公開情報に基づく。筆者は実際に動作させて検証していない。記載した数値はいずれも公開されている説明によるもので、独自に測定したものではない。導入の前に、ライセンスと配布元を必ず自分で確認すること。

新しい記事が出たら、ブラウザの通知でお知らせします。

メールアドレスの登録は要りません。いつでも止められます。

AUTHOR

北海道のWEB屋

北海道を拠点に、Web業界14年・サポート実績1,000件以上。WordPressの復旧、サーバー移転、独自ドメインとメールの設定、PHP・JavaScriptの修正まで対応します。相談と見積もりは無料です。

SPONSORED

関連記事

RELATED