4か月で9万7千スター——話題の「コードを知識グラフに変える」ツールを、実プロジェクト2件に入れて測りました

GitHubで急速に注目を集めているツールに graphify というものがあります。「どんなフォルダでも、コードもドキュメントもPDFも画像も、まとめて検索可能な知識グラフに変換する」というもので、AIコーディング支援ツールに追加して使います。

目を引くのは数字です。公開から4か月ほどで9万7千スター。そして README には「生ファイルを読ませるのに比べて、1回の問い合わせあたり71.5倍もトークンを節約できる」と書かれています。

弊社では以前から「話題のAIツールは、宣伝文句ではなく手元の実測で判断する」という進め方をしています(前回はOpenAIのプラグインを検証しました)。今回も同じやり方で、性格の異なる2つの実プロジェクトに実際に導入し、出てきた数字をそのまま並べます。

結論を先に書きます。

コードを機械的に読み解く部分は、速くて無料で、期待どおりに動きます。ただし費用がかかるのはドキュメント側で、しかもグラフの「意味のある部分」は、ほぼ人間が書いたドキュメントから来ていました。71.5倍という数字は、私たちの環境では14〜16倍でした。

夜のオフィスで大きなモニターに映る知識グラフを見上げるエンジニア。机に積まれた手書きの設計メモから緑の光が立ち上がってグラフへ流れ込み、左側のモニターのソースコードからは細く弱い青い光が伸びている。グラフは左半分が有機的につながり、右半分は均一な格子状に並んでいる
検証で分かったことを一枚にすると、こうなります。グラフの「意味のある部分」を作っていたのは、机に積まれた設計メモのほうでした。

まず事実

項目 内容
提供元 Graphify-Labs/graphify(個人開発。コミット数の9割以上が1人)
公開 2026年4月3日
注目度 97,154スター/9,410フォーク(2026年7月28日時点)
未解決の課題 677件
必要なもの Python 3.10以上/AIコーディング支援ツール
APIキー 不要(後述)

やることは3つのファイルを出力することです。ブラウザで開ける対話的なグラフ、要点をまとめたレポート、そして機械可読なグラフデータ。

つまずいた点:公式手順のとおりに入れると、意図しないインストールが走る

導入でいきなり実務的な落とし穴を踏んだので、先に共有します。

公式の手順は pip install ですが、このツールは実行のたびに「自分が入っているPythonはどれか」を探しに行く設計になっています。探索の順番は「隔離環境 → 隔離環境 → 現在のPython」で、どれにも見つからないと、その場で自動的に pip install を実行します。

弊社の検証機はここに罠がありました。Windowsでは python3 というコマンドが中身0バイトのストア誘導用ダミーになっていることがあり、実際そうなっていたのです。開発元にも同種の不具合報告が複数上がっています。

対策として隔離環境(uv)で導入したのですが、それでも一度失敗しました。原因は環境変数の反映タイミングです。インストール直後は、すでに起動しているアプリケーションに新しい設定が届いていません。その状態で実行すると「隔離環境が見つからない」と判定され、フォールバックの pip install が発火します。実際、記録を見ると導入の11分後にシステム側のPythonへ勝手にインストールされていました。

教訓はシンプルです。導入したら、エディタを一度完全に終了してから使い始めること。 ウィンドウの再読み込みでは環境変数は更新されません。

実測:性格の異なる2プロジェクトで比較

比較したのは次の2つです。

  • A: 当社サイト再構築プロジェクト — ドキュメントが主体。ブログ下書きと設計メモが中心で、コードはテーマ用のPHPが1本だけ
  • B: 予約システムのWordPressプラグイン — コードが主体。PHPが160本、設計ドキュメントが19本

Bについては、素直に全体を投げると問題が起きることが事前に分かりました。ボタンやアイコンのUI画像が106点あり、この仕組みは画像1枚ごとに解析役を1つ立ち上げます。 つまり106個の解析が走り、費用の大半がボタン画像に消えます。データファイルのJSONも954本ありました。そこでソースコードと設計ドキュメントだけに絞って実行しています。

結果です。

項目 A:ドキュメント主体 B:コード主体
対象ファイル数 59 175(絞り込み後)
コードファイル 6 154
ドキュメント 47+PDF1+画像5 21
コード解析で得たノード 58 1,427
コード解析の所要時間 数秒 1.9秒
コード解析の費用 0 0
ドキュメント解析で得たノード 約163 145
ドキュメント解析の所要時間 — 24.4分
消費トークン 388,125 146,722
最終的なグラフ 221ノード/263エッジ 1,548ノード/2,183エッジ
分類されたまとまり 18 160

この表から、はっきりしたことが3つあります。

1. コードを読む部分は、宣伝どおり速くて無料

PHP 154本から1,427ノードを1.9秒で、トークン消費ゼロ。 ここは構文解析という決まった手順で処理していて、AIを一切使いません。手元だけで完結するので、内容が外に出ることもありません。この部分は素直に良くできています。

2. 費用はコード量ではなく、ドキュメント量で決まる

意外だったのはここです。コードが26倍多いBのほうが、消費トークンは約4割少ない(388,125に対して146,722)。

理由は単純で、お金がかかるのはドキュメントの読解だけだからです。コードは無料、文章はAIが読む。だから「大きなコードベースだから高くつく」ではなく、「文章が多いプロジェクトほど高くつく」が正解です。

なお、このツールは外部のAPIキーを要求しません。文章の読解は動かしているAIアシスタント自身が担当します。別途の請求書は来ませんが、その分は普段の利用枠から減ります。

3. グラフの「意味」は、人間が書いたドキュメントから来ている

これが一番重要な発見でした。

Bで得られた1,427個のコード由来ノードは、分類してみるとほぼ「1ファイル=1グループ」でした。まとまりの良さを示す指標も0.02〜0.2と低い。要するに、フォルダ構成を言い換えただけに近いのです。

一方で、読んで価値があると感じたまとまりは全部ドキュメント由来でした。

  • 4層構造(制御・データ・部品・画面)を成り立たせている規約群
  • 会員登録なし予約の流れ(仮予約 → メール確認 → 本予約)
  • 3つの領域にまたがるSQLの脆弱性群

これらは、開発者が事前に書いておいた設計ドキュメントに書いてあった内容です。 グラフはそれを整理して見せてくれましたが、無から生み出したわけではありません。

ついでに、ドキュメント側の弱点も見えました。Bには過去バージョンのファイルが2本残っており、元ファイルと合わせて79ノードのそっくりなグループが3つできました。「最も重要な要素」の一覧にも、同じ名前が3回並びます。似たファイルの重複を見抜く機能はありません。

もうひとつ。分類されたまとまりが160個できましたが、それぞれに名前を付けるのは人間(正確にはAIアシスタント)の手作業です。現実的に名付けられたのは22個で、残り138個は「まとまり22」「まとまり23」といった番号のままになりました。結果として、レポートの「この構造だから答えられる問い」の欄が、番号を64個羅列した読めない文章になっています。

「71.5倍」は、私たちの環境では14〜16倍でした

このツールには削減率を測る機能が内蔵されているので、そのまま実行しました。

対象 削減率
A:ドキュメント主体 16.5倍
B:コード主体 14.0倍

READMEの71.5倍には届きません。ただし、これは誇大広告と切り捨てる話ではないと考えています。71.5倍は開発者が「コード+論文+画像」を混ぜた特定の題材で測った値で、README自身も「削減率は題材の規模に比例して変わる」と明記しています。

むしろ気になったのは別の点で、この計測機能が基準にしている文字数が、実際の対象と合っていません。 Aでは15万語を読み込んだはずが、計測時の基準は1万1千語でした。数字は目安として受け取るのが妥当です。

誰に向くか

2件試した実感として、こう整理しています。

向いているケース

  • ソースコードが数百ファイル以上あり、全体像を一度に把握できない
  • 設計ドキュメントがすでに整備されている(グラフの質はここで決まります)
  • 新しく参加した人に構造を渡したい

向いていないケース

  • ファイル数が数十で、AIがそのまま全部読める規模
  • ドキュメントが少ない、または無い(コード解析だけではフォルダ構成の言い換えになります)
  • 画像素材やデータファイルが大量に混ざっている(絞り込みが必須)

弊社のサイト再構築プロジェクト(A)は、正直に言えば後者です。全部で60ファイル程度なので、AIにそのまま読ませたほうが速い。それでも試した価値はありました。「効かない側」を実測できたからです。

おわりに

話題のツールを評価するとき、いちばん確実なのは自分の現場で動かして数字を見ることだと、あらためて思いました。

今回で言えば、「コード解析は速くて無料」は本当でした。「71.5倍」は条件付きでした。そして最も実務的な発見は、このツールの出力の質が、結局は自分たちが書いたドキュメントの質で決まるということです。設計を言葉にして残しておく習慣がある組織ほど、こういうツールの恩恵を受けられます。

逆に言えば、ドキュメントを書いていない組織が導入しても、フォルダ構成の図が出てくるだけです。道具が先ではなく、蓄積が先。 そこは変わらないようです。

弊社では、こうしたツールの検証を実案件と並行して継続しています。「話題になっているが、自社に入れる価値があるか分からない」といったご相談も承っております。