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

この記事の結論
- コード・文書・PDF・画像をまとめて1つのグラフにする
- ベクトル検索を使わない。コードは構文解析で確定的に読む
- 辺に「見つけた」「推測した」「曖昧」の札を付ける
- コード・文書・PDF・画像をまとめて1つのグラフにする
- ベクトル検索を使わない。コードは構文解析で確定的に読む
- 辺に「見つけた」「推測した」「曖昧」の札を付ける
Claude Code などで使えるスキルgraphifyが公開されている。
やることは「コードベースを知識グラフにする」。この手の道具は珍しくないが、設計の考え方が他と違うので整理しておく。
何をするものか
フォルダを指定すると、中身を読んでグラフを作る。出てくるのはこれらになる。
- 対話できるグラフ(HTML) — 節点をクリックして辿れる
- Obsidianの保管庫として開ける形式
- 記事形式のwiki — エージェントがファイルを読んで辿れる
- レポート — 中心になっている概念、意外なつながり、聞くべき質問
- グラフのJSON — 後日また使える
扱える種類も広い。
| 種類 | 読み方 |
|---|---|
| コード | 構文解析(tree-sitter)+呼び出し関係の走査 |
| 文書(.md .txt .rst) | 概念と関係をAIで取り出す |
| 論文(.pdf) | 引用の抽出と概念の取り出し |
| 画像(.png .jpg など) | 画像認識で読む。図やホワイトボードの写真も |
ベクトル検索を使わない
ここが一番の特徴になる。説明文に「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系である点は確認してから
出典
- Graphify-Labs/graphify(GitHub)(README、対応する種類と抽出方法、辺の分類、トークン削減の数値と条件、技術構成、ライセンス。2026年10月19日に確認)
- PyPI「graphifyy」(バージョン 0.9.92、Python 3.10以上)
本記事は2026年10月19日時点の公開情報に基づく。筆者は実際に動作させて検証していない。記載した数値はいずれも公開されている説明によるもので、独自に測定したものではない。導入の前に、ライセンスと配布元を必ず自分で確認すること。
新しい記事が出たら、ブラウザの通知でお知らせします。
メールアドレスの登録は要りません。いつでも止められます。
関連記事
RELATED
レガシー移行でAIが間違えた場所を、全部書き出した
うまくいった話より、どこで間違えたかのほうが役に立つはずなので記録しました。
インデックスの仕組みを図にした。列の並び順で効くかが決まる
インデックスは端から全部見るのをやめる仕組みです。複合インデックスは左端から連続した組み合わせしか使えません。公式の記述…
移行前の動きを記録しておかないと、直ったか分からない
「前はどうだったか」を誰も覚えていません。先に記録を取る方法を決めました。