Graphifyはフォルダを知識グラフにする。71.5倍には前提がある

Graphify は今週だけでおよそ 7,300 個のスターを稼ぎ、GitHub の週間トレンド上位に食い込んだ。累計は 137,000 を超えている。売り文句は一行で済む。コーディングエージェントにフォルダを向けて /graphify . と打てば、その中身の知識グラフが返ってくる、というものだ。

面白いのはグラフそのものではない。グラフに添えられた数字のほうだ。生のファイルを読む場合と比べて、クエリあたりのトークン消費が 71.5x 少ない。これが一般に成り立つなら、これは便利ツールではなく、エージェントが抱えなければならないコンテキストの量そのものに対する変更になる。

どこから来たのか

作者の safishamsi は、このプロジェクトを Andrej Karpathy のある癖への回答として位置づけている。論文、ツイート、スクリーンショット、メモを /raw フォルダに放り込み、あとから何も見つけられなくなる、あの癖だ。よく分かる話であり、ほとんどの事例より正直な出自でもある。市場ではなく、失敗のパターンを語っているからだ。

掲げられている目標は「自分の文書を検索する」より狭い。セッションをまたいで生き残る持続的な何かを作ること、そして何を抽出し、何を推論したのかを明示すること。グラフの各エッジには EXTRACTED、INFERRED、AMBIGUOUS のいずれかのタグが付く。珍しい設計判断であり、私の見るところでは、この仕組み全体でいちばん価値のある部分だ。

実際に何をするのか

インストールは 2 コマンド。そう、PyPI のパッケージ名は暫定的に間違っている：

pip install graphifyy && graphify install

Y が二つ並ぶのはタイプミスではなく命名紛争の結果だ。CLI も skill コマンドも、今なお graphify である。Windows でインストール後にコマンドが認識されない場合は、Python の Scripts フォルダを PATH に通すか、pipx install graphifyy を使えばこの問題自体を回避できる。

そして Claude Code の中で、任意のディレクトリにおいて：

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

出力は graphify-out/ に落ちる。クリックして辿れる対話的な graph.html、vault として開ける obsidian/ フォルダ、数週間後に問い合わせても何も読み直さずに済む永続的な graph.json、SHA256 をキーにして変更のあったファイルだけを処理する cache/、そして god nodes と呼ばれる次数最大の概念と、複合スコアで順位づけられた「意外なつながり」を並べた GRAPH_REPORT.md。このスコアでは、コードから論文へのエッジがコード同士のエッジより重く扱われる。

マルチモーダル部分は売り文句ではなく実装だ。コードファイルは tree-sitter による AST 解析とコールグラフの走査を通す。Markdown、PDF、画像は Claude を通す。散文から概念と関係を、論文から引用を掘り起こし、スクリーンショット、図解、ホワイトボードの写真、他言語の画像には視覚能力を使う。

このツールの中に住みたくない人間にとって重要なエクスポートもある。--svg、Gephi や yEd 向けの --graphml、そして --neo4j は、稼働中のデータベースを要求する代わりに cypher.txt を生成する。スタックは NetworkX、graspologic 経由の Leiden クラスタリング、tree-sitter、vis.js。サーバーはない。Claude の呼び出しを除けば、何もマシンの外に出ない。

71.5x という数字を分解する

ベンチマークのコーパスは 52 ファイル。Karpathy のリポジトリ、論文 5 本、画像 4 枚。結果は、生のファイルを読む場合に比べてクエリあたりのトークンが 71.5x 少ない、というものだ。

このリポジトリは、これがどうスケールするかについて異例なほど正直で、その正直さは引用に値するほど珍しい。トークンの削減幅はコーパスの規模とともに大きくなる。一方、6 ファイル程度ではグラフの価値は圧縮ではなく構造の明瞭さにあり、6 ファイルならそもそもコンテキストウィンドウに収まるからだ。彼ら自身が graphify のソースと Transformer 論文で示した例は 5.4x。合成のライブラリファイル 6 個ではおよそ 1x である。

この形は正しい。コーパスがすでにコンテキストウィンドウに収まっているなら、節約しているのはトークンではなく、地図を買っているのだ。50 ファイルの混在コーパスなら、節約は現実的で大きい。代替手段はファイルを一度読むことではなく、何度も、複数のターンにわたって読み直すことだからだ。エージェントはそのたびに現在地を見失う。

この比較は、一方では graphify に少し甘く、もう一方では過小評価でもある。生ファイルの読み込みは最悪ケースのベースラインであり、チューニングされた検索インデックスなら生ファイルより見栄えはよくなる。だが検索インデックスが返すのは passage で、graphify が返すのは関係だ。「アテンションとオプティマイザを結ぶものは何か」の答えは passage ではなくパスである。これは別種のクエリであり、ベクトルストアが担えるのはそのうち片方だけだ。

「ベクトルストアなし」は本気のアーキテクチャ判断である

ほとんどの検索システムはテキストを分割し、埋め込み、最近傍探索を行う。Graphify はそれを全部飛ばす。コードはローカルで決定的な AST 解析、散文と画像は LLM による抽出、そこからグラフを組む。埋め込みの工程も、類似度検索もない。

代わりに手に入るのは説明可能性だ。二つのものがなぜつながっているのかを尋ねれば、エッジが返ってくる。しかも各エッジには、原文から抽出したのかモデルが推論したのかが記されている。ベクトルインデックスにはできない芸当だ。あれが教えてくれるのは、コサイン距離が小さかった、ということだけである。

代償はカバレッジだ。グラフは抽出器が見つけたものしか知らない。抽出のパスが関係を取りこぼせば、どんなクエリでもそれは浮かび上がらず、曖昧検索のフォールバックもない。AMBIGUOUS タグはその事実への正直な表明であり、--mode deep というフラグが存在するのは、既定のパスがエッジの推論に保守的なためだ。

どこで居場所を得るか

この種のツールについての私の経験では、ワークフローは二つある。

一つ目は、見慣れないコードベースへのオンボーディングだ。「関数 X はどこか」ではない。それは grep で足りる。「ここで構造を支えている概念は何で、そのうちどれが課金処理に触っているのか」だ。これはグラフの問いであり、god nodes のレポートは 2 分で読める形で答えてくれる。

二つ目はマルチエージェントの場合。複数のエージェントが並行してコードを書くと、リポジトリに対する各々のモデルは数分で古くなる。コミットのたびに再構築されるグラフ（graphify hook install が post-commit フックを設定する）や、ファイル保存時に再構築されるグラフ（--watch）は、五つに食い違った推測ではなく、同じ最新の地図をすべてのエージェントに渡す。

明白な限界はこれだ。これはまず Claude Code の skill として作られている。手動インストールの経路は SKILL.md を ~/.claude/skills/graphify/ に置き、CLAUDE.md に一行足す。他のクライアントが使える MCP サーバーモード（--mcp）もあるが、使い勝手は明らかに一つのエコシステム向けに最適化されている。そして Claude への依存は、大規模なコーパスでは抽出パスに実際のコストがかかることを意味する。

正直な結論

Graphify は検索エンジンではないし、検索エンジンとして評価すべきでもない。これはフォルダの中身についての、持続的で検査可能なモデルであり、どこを推測したのかを教えてくれるという変わった性質を備えている。137,000 スターを集め、一週間トレンドに居座ったプロジェクトについて興味深いのは、このグラフが立派かどうかではない。推論にタグを付けるという習慣が、答えだけを求めるユーザーとの接触に耐えられるかどうかだ。

おそらく大多数は query だけを使い、エッジのラベルは無視し、graph.json を開くことはないだろう。使い続けるのは、答えではなく地図を必要としていた人たちだ。