Graphify：ベクトルストアなしで、あらゆるコードベースを検索可能な知識グラフに変える

コードベースは年々大きくなり、その周囲にはノート、論文、スクリーンショットも積み上がっていく。ところがコーディングエージェントは、新しいセッションを始めるたびに、同じ生ファイルをほぼ一から読み直すことが多い。これはトークンを大量に消費するうえ、セッションをまたいだ知識の蓄積も生まない。Graphify はこの課題に向けたオープンソースのプロジェクトである。Claude Code のスキルとして動作し、Claude Code 上で /graphify と入力すると、フォルダ内のファイルを読み込んで知識グラフを構築し、利用者がそれまで気づいていなかった構造を返してくれる。プロジェクトの説明によれば、生ファイルを直接読む場合と比べてクエリあたりのトークン数は 71.5 分の 1 になり、グラフはセッションをまたいで保持され、「見つけたこと」と「推測したこと」を区別して示すという。README は Andrej Karpathy が /raw フォルダに論文やツイート、スクリーンショット、メモを放り込んでいる習慣にも触れ、そうした資料が増えるほど活用できなくなる問題への答えとして自らを位置づけている。ただし、71.5 倍という数字はプロジェクト自身の記述であり、私たちは再現していない。保証ではなく、桁の目安として受け取るべきである。

第一の特徴は、完全なマルチモーダル対応である。入力はソースコードに限らない。PDF、Markdown、スクリーンショット、図表、ホワイトボードの写真、さらに他言語の文字を含む画像まで、そのまま投入できる。Graphify は Claude の視覚機能を使い、こうした異種の資料から概念と関係を抽出して、ひとつのグラフに接続する。たとえば手描きのシステム構成図、設計レビューの PDF、中核モジュールのソースコードが、互いに結びついたノードとして同じ構造に並ぶ。三つの別々のフォルダに散らばったままにならないのである。文書が述べていることとコードが行っていることを何度も突き合わせるチームにとって、統一された表現には実際の価値がある。この設計は、タイトルにある「ベクトルストア不要」の意味も説明している。クエリは埋め込み空間での類似度ではなく、明示的なノードとエッジに基づく。近傍探索の曖昧さと引き換えに、人間が検査し、異議を唱えられる関係を得るという選択である。 第二の特徴は、成果物の設計が丁寧なことである。フォルダに対して /graphify を実行すると graphify-out ディレクトリが生成され、役割が明確に分かれている。graph.html は対話型のグラフで、ノードをクリックし、検索し、コミュニティごとに絞り込める。obsidian フォルダはそのまま Obsidian のボールトとして開ける。--wiki オプションを付けると、エージェントの巡回用にウィキペディア風の記事も書き出される。GRAPH_REPORT.md は報告書で、最も密に結びついた中核概念である「ゴッドノード」、意外なつながり、次に問うべき質問の候補が並ぶ。graph.json は永続化されたグラフ本体であり、数週間後でも元の資料を読み直さずに問い合わせられる。最後に cache フォルダには SHA256 のキャッシュがあり、再実行時には変更のあったファイルだけが処理される。人が閲覧する経路とエージェントが利用する経路の両方に配慮し、増分キャッシュによって日々の更新コストも抑えている。

導入は軽量である。必要なのは Claude Code と Python 3.10 以上で、pip install graphifyy を実行し、続けて graphify install を実行する。注意すべき点がひとつある。PyPI 上のパッケージ名は、graphify という名前を回収中のため、一時的に y が二つの graphifyy になっている。コマンドラインツールとスキルのコマンドは、これまで通り graphify である。Windows でインストール後にコマンドが認識されない場合は、Python の Scripts フォルダを PATH に加えるか、pipx を使う。macOS で外部管理環境のエラーが出たときも pipx が有効である。手動で入れることも可能で、curl でスキルファイル SKILL.md を ~/.claude/skills/graphify に保存し、~/.claude/CLAUDE.md に登録する。その後は任意のディレクトリで Claude Code を開き、/graphify とドットを入力すれば始められる。 業界の視点では、Graphify は注目すべき方向を示している。長期記憶をベクトルデータベースだけに任せず、モデルに資料を一度明示的なグラフへ「コンパイル」させ、以後のクエリではそのグラフだけを読む方式である。利点は、結果を監査でき、増分更新ができ、セッションをまたいで安定することだ。代償として、グラフの品質はモデルによる抽出の正確さに左右され、誤ったエッジは一度書き込まれると再利用される。発見と推測を分けるという方針はこのリスクへの対応だが、どこまで機能するかは自分のコーパスで確かめる必要がある。大きなフォルダの初回構築ではモデルを呼び出し、特に視覚抽出には相応のコストがかかる。SHA256 キャッシュが減らせるのは二回目以降の負担だけである。私たちの勧めは実務的だ。まず中規模のリポジトリで試し、GRAPH_REPORT.md のゴッドノードを自分の理解と照らし合わせ、いくつかのエッジを元資料までたどって確認する。そのうえで日常のエージェント作業に組み込むか判断するのがよい。結果が信頼できるなら、コード、文書、視覚資料をつなぐ共通の文脈基盤になり得る。