Graphifyとは？料金や使い方、Claude Codeとの連携方法を徹底解説

Graphify（グラフィファイ）は、Safi Shamsi氏が2026年4月3日にリリースしたAIコーディングアシスタント向けのオープンソーススキルです。

「/graphify」 コマンドを実行するとコードベース全体がナレッジグラフに変換され、Claude Code・Cursor・Codex・Gemini CLIなど20+のツール間で同じgraph.jsonを共有できます。
Andrej Karpathy氏の一言から48時間で誕生し、Y Combinator Summer 2026にも採択されました。

本記事では2026年7月時点の情報をもとに、料金プラン・使い方・コード＋非コードの2段階アーキテクチャ・公式ベンチマーク・競合ツールとの比較・導入判断で詰まる論点までを体系的に解説します。

Graphifyとは？AIコーディングアシスタント向けのナレッジグラフスキル

Graphify（グラフィファイ）とは、Safi Shamsi氏が2026年4月3日にリリースした、AIコーディングアシスタント向けのオープンソーススキルです。
コードベース・ドキュメント・PDF・画像などを含むプロジェクトフォルダを、クエリ可能なナレッジグラフに変換する役割を担います。

Graphifyが他のコード解析ツールと根本的に違うのは、特定のIDEに閉じ込められず、20以上のAIコーディングアシスタントに同じgraph.jsonを配布できる点です。

Claude Code・Cursor・Codex・Gemini CLIいずれから参照しても同じ知識基盤で運用できます。

誕生の経緯も独特です。2026年4月1日にAndrej Karpathy氏がXで「コードベースのナレッジグラフをAIアシスタントに渡す仕組みが欲しい」と主旨のポストを公開し、その48時間後にSafi Shamsi氏がGitHubへ最初のバージョンを公開。3か月で83,000スター超・PyPI累計ダウンロード200万件を超え、Y Combinator Summer 2026にも採択されてGraphify Labsとして法人化されました。

OSS版とEnterprise Early Accessの2層構成

Graphifyは、OSS版とGraphify Enterpriseの2層構成で展開されています。

• OSS版（本記事の主対象）
  Apache License 2.0、GitHub公開・PyPI配布、「/graphify」 スキルとしてAIコーディングアシスタントに組み込む本体
  
  

• Graphify Enterprise（Early Access）
  Merge-gate verification・Graph-aware code review・Engineering digest・Jira connectorの4機能とSelf-hosted deploymentを提供予定。公式Enterpriseページ経由のwaitlist方式で、料金は非公表

ここでのポイントは、多くの読者が最初に触れるのはOSS版で、Enterpriseは組織的な統制・レビュープロセス統合が要件になってから検討する層、という点です。

本記事もまずOSS版を軸に解説し、Enterpriseは後段の料金プランのセクションで改めて整理します。

Graphifyが解決する「Token Tax」問題——AIアシスタントを重くする根本原因

Graphifyの価値を理解する上で欠かせないのが、多くのAIコーディングアシスタント運用が直面している「Token Tax（トークン税）」という概念です。

Edward Low氏がMedium記事「Graphify: The Knowledge Graph That Ends Your Codebase's Token Tax」で提示したフレーズで、Graphify周辺の議論で頻繁に使われるようになりました。

AIアシスタントがコードベースを読むたびに払う暗黙コスト

Claude Code・Cursor・Codexなどのアシスタントは、質問を受けるたびに関連ファイルをコンテキストに読み込みます。単純な「readとgrepの繰り返し」で必要な情報を集める設計です。

このアプローチには、次の3つの累積コストが発生します。

• トークン単価の直接コスト
  Claude Opus 5は入力$5・出力$25/100万トークン（2026年7月時点、公式pricing）と、フロンティアモデルの単価は決して安くない。関連ファイルをまるごと読み直すクエリを積み重ねると、入力課金が積み上がる
  
  

• レート制限の消費
  Pro/Maxプランには5時間あたりのメッセージ数制限があり、1メッセージあたりの入力ファイル量が多いほど枠を早く消費する（詳細はClaude Codeの利用制限参照）
  
  

• コンテキスト希釈
  関係の薄いファイルまでコンテキストに入れると、モデルが本当に見るべき箇所への注意が薄まる。応答品質が下がるという逆説的な副作用

Graphifyの提唱者は、この3つを合算した目に見えないコストを「Token Tax」と呼びます。トークン単価・レート枠・応答品質のいずれもが、コードベースをまるごと読ませる従来設計のツケになっている、という主張です。

read everything+grep everythingの限界

従来のAIアシスタントは、コードベースに関する質問が来ると2つの戦略を組み合わせて情報を集めます。read（該当ファイル全読み）と、grep（キーワード全文検索）です。

この戦略が限界に達するのは、次のような場面です。

• 200ファイル超のリポジトリで「認証周りの実装を全部見せて」と依頼したとき、依存関係を辿るだけで数十ファイルを読み込むことになる
• SQLスキーマ・インフラ設定・アプリコードが別ディレクトリに散在し、それぞれ単体では意味を持たないとき、grepしても文脈が繋がらない
• 変数名・関数名にビジネス概念が反映されておらず、キーワード検索で該当箇所に到達できないとき

Graphifyは、これらをAST（抽象構文木）ベースの決定的抽出で解決します。

ファイル全体ではなく「関数A → 関数Bを呼び出す」「テーブルC → カラムDを持つ」という構造化された関係をグラフとして保持し、AIアシスタントは必要な部分だけを厳密に取り出せるようになります。

RAG方式との差分——構造検索 vs 意味検索

同じ「AIに大量情報を扱わせる」問題への解として、RAG（Retrieval-Augmented Generation）が広く使われています。埋め込みベクトルによる類似検索で関連チャンクを引き出すアプローチです。

詳細はGraphRAGやナレッジグラフの解説記事でも扱っていますが、コード領域では構造的関係と意味的類似性が別物である点が実務で効いてきます。

以下の表で、RAG方式（コード向け）とGraphify方式の得意領域を整理しました。

実務では、コードに関する多くの問いは「構造の一致」で答えられるものです。

関数呼び出しグラフ・継承関係・データ依存はいずれも決定的な辺として表現でき、AI総研の支援現場でも、コードベース理解を目的とした問いは9割方がこの型に収まる印象です。

Graphifyが「AST + Tree-sitter + Leiden community detection」という決定的手法を選んだのは、この実務観察と符合します。

Graphifyの2段階アーキテクチャと出力3ファイル

Graphifyの内部処理は、公式ConceptsによればコードのAST解析と、それ以外のデータのモデル処理という2段階で設計されています。

前段は完全にローカルで走り、後段は選択したモデルバックエンドに委ねられます。

tree-sitterによるコードのローカルAST解析

コード側は、tree-sitter（オープンソースの汎用パーサジェネレータ）を使った抽象構文木抽出です

。公式Securityページには「Code is parsed on-device with tree-sitter: no upload, no telemetry」と明記されており、コード自体は外部に送信されません。

抽出される情報は次の要素です。

• 関数・メソッド・クラスの定義と、それらの呼び出し関係
• import / require / usingなどのモジュール依存
• 継承・実装・trait実装の階層
• グローバル変数と定数の宣言
• SQLスキーマの場合はテーブル・カラム・外部キー関係

対応言語は36前後のtree-sitter grammarで、Python・TypeScript・JavaScript・Go・Rust・Java・C/C++・Ruby・C#・Kotlin・PHP・Swift・SQLなど主要言語を網羅します。

この段階でLLM呼び出しは発生せず、「--code-only」 フラグを付ければAPIキーなしで完全オフライン動作するため、機密コードを外に出したくない組織にとって重要な設計です。

選択可能なモデルバックエンドによる非コードデータ処理

コード以外のデータ（ドキュメント・PDF・画像など）は、tree-sitterのAST解析対象外で、モデル推論でグラフに接続します。

ここで使うバックエンドは、公式Conceptsで「Claude, OpenAI, Gemini, DeepSeek, Kimi, Bedrock, Azure, または local Ollama」の中から選べると明記されています。

この選択の自由度が、Graphifyのプライバシー設計の核心です。

• 完全ローカル運用
  バックエンドに local Ollama を選べば、非コード処理も自マシン内で完結する。金融・製造・医療など外部送信を許容できない環境向け
  
  

• クラウドLLM運用
  Claude / GPT / Gemini などクラウドLLMを選ぶと、ドキュメント・PDF内容が該当プロバイダに送信される。精度・コストは選ぶモデルにより異なるため、契約・DPAで整合を取ったうえで比較検証する必要がある
  
  

• エンタープライズクラウド運用
  Bedrock / Azure を選ぶと、既存のクラウド契約と統合できる。監査・課金経路を一本化したい大企業向け

「Claude API がないと動かない」設計ではない点は、既存のインフラ選択にGraphifyを合わせられる意味で重要です。

実運用ではまずコードだけ 「--code-only」 で試し、要件に応じて非コード処理のバックエンドを決めるのが安全な立ち上げになります。

出力3ファイル——graphify-out/配下

処理を実行すると、Graphifyはプロジェクト直下のgraphify-out/ディレクトリに以下の3ファイルを出力します。

3ファイルはgit管理対象にできる想定で、チーム全員が同じgraph.jsonを共有しながらAIアシスタントを使う運用が公式ドキュメントで推奨されています。Neo4jやObsidianへのエクスポートにも対応しており、既存のナレッジ管理環境と接続することも可能です。

Graphifyが対応するAIコーディングアシスタントと言語

Graphifyの実務価値を決めるのが、サポートしているAIコーディングアシスタントの幅です。1つの 「/graphify」 コマンドで生成されたgraph.jsonが、20以上のツールから共通に参照できる設計になっています。

対応するAIコーディングアシスタント

2026年7月時点で公式READMEに対応が明示されている主要ツールを、以下の表で整理しました。

フロンティア各社の公式CLIから新興OSS・IDE系まで幅広くカバーされている点が確認できます。

この表から読み取れるのは、Claude Code・Codex CLI・Gemini CLIといった主要各社の公式CLIから、Cursor・Cline・OpenCodeなどのエディタ系まで、実務で使われる主要なコーディングアシスタントを一通り抑えている点です。組織内で複数ツールを併用しているケースでも、Graphifyのグラフ資産は共通で使い回せます。

この横断性は、「チームメンバー全員が同じアシスタントを使うとは限らない」現実に対する設計解答です。Claude Codeを好むエンジニアとCursorを好むエンジニアが同じリポジトリで作業していても、graph.jsonを共有すれば同じ知識基盤で議論できます。

対応する言語とマルチモーダル対応

コード側のサポートは、tree-sitter grammar経由で36前後の言語をカバーします。汎用的なアプリケーション開発言語だけでなく、SQLスキーマ・シェルスクリプトなどインフラ層の言語にも対応している点が実務で効きます。

以下の表で、Graphifyがサポートするアセット種別と処理経路を整理しました。

この幅広さが、Graphifyを「単なるコードグラフツール」ではなく「プロジェクト知識ハブ」として位置付ける根拠になっています。

研究プロジェクトでコード・論文PDF・実験ログを一体化したい場合や、レガシーシステムのドキュメント・仕様書・現行コードを1つのグラフで扱いたい場合に効きます。

Graphifyの導入手順——Claude Codeへの組み込み

Graphifyの導入は、PyPIからのパッケージインストール→「graphify install」→「/graphify .」の3ステップで完了します。

ここでは最も多いClaude Codeへの組み込みを例に、実行手順と各ステップで起きることを整理します。

前提条件

導入前に確認する要件は次の4点です。

• Python 3.10以上（python --versionで確認）
• AIコーディングアシスタントのいずれかがすでにセットアップ済み（Claude Code / Cursor / Codex / Gemini CLI / GitHub Copilot CLI / Aider / OpenCode / Kiro / Trae 等）
• uv / pipx / pipのいずれかが利用可能
• 対象リポジトリのサイズ感の把握（後述の詰まりポイントで解説）

Claude Codeを利用する場合、Claudeサブスクリプション・Claude Console・Amazon Bedrock・Google Vertex AI・Microsoft Foundryなど、Claude Code側の認証設定が別途必要です。

インストールコマンド

公式が推奨するインストールコマンドは、uv（高速なPythonパッケージマネージャ）経由です。

uv tool install graphifyy
graphify install

PyPIパッケージ名は「graphifyy」（yが2つ）である点に注意します。同名の類似パッケージが存在する可能性があるので、必ず正式名でインストールしてください。

「uv」 を使わない場合は、pipx か pipでも同じ結果になります。

pipx install graphifyy
graphify install

# または
pip install graphifyy
graphify install

SQL・Terraform・PDF・Officeファイル・音声動画・watch・MCPサーバ・Ollamaバックエンドなどを扱いたい場合は、対応するオプションextrasを併記してインストールします（例：「uv tool install "graphifyy[pdf,office,watch,mcp,ollama]"」）。全部入りが必要なら 「graphifyy[all]」 も利用できます。

「graphify install」 は既定でグローバルに登録され、「~/.claude/skills/graphify/」 にSkill定義が配置されます。プロジェクト単位で 「CLAUDE.md」 とフックまで組み込みたい場合は、対象プロジェクトのルートで以下のいずれかを実行します。

# プロジェクトにCLAUDE.mdとフックを組み込む
graphify install --project

# Claude Code向けの組み込み専用コマンド
graphify claude install

これらを実行するとプロジェクト側の「CLAUDE.md」にまず 「graphify query」 などのグラフクエリを使い、広範な設計確認時のみGRAPH_REPORT.mdを開く指示が追記され、Claude CodeのAgent Skills機能を通じてスキルが有効になります。Cursor・Geminiなど他ツール向けにも 「graphify cursor install」 や 「graphify install --platform codex」 などの個別コマンドが用意されています。

基本操作——「/graphify .」 でグラフを生成

グラフの生成は、Claude Codeのセッション内でスラッシュコマンドを実行します。

/graphify .

「.」 はカレントディレクトリを対象にする指定です。特定のサブフォルダのみ対象にしたい場合は、「/graphify src/」 のようにパスを指定します。

実行が始まると、Graphifyは次の順に処理を進めます。

• コードファイルのtree-sitter AST抽出（Step 1・ローカル）
• 非コードデータの意味抽出（Step 2・選択したバックエンドで実行）
• クラスタリングと 「graphify-out/」 への3ファイル書き出し

コードだけ扱えれば十分なら 「graphify extract <path> --code-only」 を使うことで、APIキーなし・完全オフラインで走ります。

初回生成後は 「graphify-out/graph.json」 にクエリするだけで応答できるため、都度コードベースをフルスキャンする必要はありません。

生成後のClaude Codeでの挙動と、グラフを陳腐化させない仕組み

グラフ生成後は、「graphify install --project」 の既定設定によって、Claude Codeにgraphify queryなどのスキルコマンドの利用を促す指示（soft nudge）が追加されます。

read/grep より先にグラフ参照を強制したい場合は、「graphify install --project --strict」 を使うと最初のファイル直接読み込みがブロックされます。

問題になるのは、コードが日々更新されるとgraph.jsonが古くなる点です。Graphifyは公式に3つの更新経路を用意しています。

• 差分再生成: 「/graphify ./raw --update」 で変更ファイルだけ再抽出。非コードデータの意味抽出更新もここに含まれる
• ファイル監視: 「graphify watch ./src」 を常駐させ、コード変更を検知した時点でASTを自動再構築。ドキュメント・PDF・画像などの意味抽出更新は別途 「/graphify --update」 が必要
• Gitフック連携: 「graphify hook install」 で post-commit / post-checkout を登録し、コミットごとにコード側のASTを更新。非コードの意味抽出は同じく 「/graphify --update」 を別途走らせる

加えて 「/graphify . --mcp」 を使うと、グラフをビルドしたうえで MCP（Model Context Protocol）サーバとして公開できます。

既存の 「graphify-out/graph.json」 をそのまま公開したい場合は、「python -m graphify.serve graphify-out/graph.json」 を使います。

MCPはグラフを外部から問い合わせられるようにするチャネルで、更新自体は 「watch」 や 「hook」 および 「/graphify --update」 が担う点に注意してください。

Graphifyの料金プランと関連コスト

Graphifyの料金体系は、OSS版（完全無料）とEnterprise（Early Access・料金非公表）の二層構造です。

多くの読者が最初に触れるのはOSS版ですが、組織導入を検討する場合はEnterprise版の想定も踏まえて判断する必要があります。

OSS版はApache License 2.0で完全無料

Graphifyの本体は、GitHubリポジトリから誰でも無料で利用できます。

ライセンスはv0.9.25でMITからApache License 2.0に移行しており、Apache 2.0の条件下で商用利用・改変・再配布が可能です。

• アカウント登録不要
  PyPI経由でインストール即使用可能
  
  

• 利用回数の上限なし
  Graphify本体の利用料はゼロ。ただし非コード処理を含めた場合は、選択したバックエンド側の課金が別途発生する
  
  

• コード解析はローカル完結
  tree-sitterによるコード側の解析は完全にローカルで走る（非コードデータは選択したモデルバックエンドが処理）

OSS版だけで、個人開発・小〜中規模チーム開発・PoCフェーズの多くはカバーできる設計です。

実際、公式サイトのpricingページでも「free & open source, no account, no limits」と明示されています。

Enterprise（Early Access）で提供される追加機能

一方、組織的な統制・レビュープロセス統合を求めるユーザ向けに、Enterprise（Early Access）が用意されています。2026年7月時点では申請ベースのwaitlist方式で、料金は非公表です。

Enterprise版で提供される（予定を含む）主な機能は次のとおりです。

• Merge-gate verification（マージゲート検証）
  Pull Requestマージ前に、変更が既存の振る舞いを保つかを自動検証し、問題があれば失敗入力を示す機能
  
  

• Graph-aware code review
  コードレビュー時に、変更対象コードの依存関係・呼び出し元をレビュアーに提示する機能
  
  

• Engineering digest
  コミット・health delta・blast radiusをオンデマンドのMarkdownレポートとして出力する機能
  
  

• Jira connector
  Jiraのチケットとコードベースのグラフを連携させ、変更起点のトラッキングを可能にする機能
  
  

• Self-hosted deployment（展開形態として選択可能）
  Enterprise管理下でのセルフホスト展開オプション

これらは、Graphify Pricingページからwaitlistに登録する形で申請します。「pricing will be shaped with early users（早期利用者と価格を共に設計）」と記載されており、確定価格や公表時期は明示されていません。

実運用で発生する関連コスト——選択したモデルバックエンドの課金

OSS版は完全無料ですが、実運用ではStep 2で使うモデルバックエンドの課金を見積もる必要があります。「--code-only」 でコードだけを扱う場合、追加課金はゼロです。

コスト影響を大きく決めるのは、次の3変数です。

• 非コードデータの量：Markdown・PDF・Word・Excel・画像の総ページ数（コードのみのリポジトリなら課金なし）
• バックエンド選定：Claude / OpenAI / Gemini などクラウドLLMを使うか、local Ollamaで完結させるか
• 再生成頻度：「--update」 差分／「watch」 常駐／PR毎など、グラフ再生成のトリガー設計

クラウドLLMを選ぶ場合、モデルの入出力単価と再生成頻度の掛け算がそのままコストになります。差分再生成（「--update」）を使うと変更ファイルの意味抽出だけに絞り込めるため、月次コストを抑えやすくなります。

プロンプトキャッシングは繰り返しクエリの入力キャッシュを効かせる別軸の仕組みで、Graphifyの出力を「.claudeignore」に含めないとキャッシュを無効化するケースもある点に注意します。

機密度が高いドキュメントは local Ollama バックエンドを選ぶことで、外部送信を回避できます。

Graphifyの公式ベンチマークとコミュニティ報告

Graphifyがどれだけコスト・応答品質に効くかは、測定条件によって大きく振れます。

公式がBENCHMARKS.mdで示している値と、コミュニティから寄せられた個別事例を分けて整理します。

公式ベンチマークの主要指標

公式ベンチマークは、AIエージェント向けメモリ層としての品質と、既存の類似サービスとの単価差を軸にまとめられています。トークン削減率をシングルナンバーで打ち出す構成ではありません。

以下の表で、公式に開示されている主要指標を整理しました。

公式ベンチマークでは、約100万LOCのERPNextを対象としたコード知識評価（n=6・固定coding agent）で、context-stuffing（LLMコンテキストに大量ファイルを詰め込む従来手法）がGraphify利用時のおよそ20倍のトークンを要したと報告されています。

これがコスト面での主な訴求ポイントになっており、倍率だけを切り取らず、recallと単価の両面で比較するのが公式の姿勢です。

コミュニティから報告された「71.5倍」事例

公式サイトのトップページでは、コミュニティメンバーのLucas Rosati氏によるセットアップ検証で「Graphify使用時のトークン消費が従来比で約71.5分の1に収まった」という事例が紹介されています。

• 性格: 公式ベンチマークではなく、1ユーザーからの報告
• 構成: 「claude-code-memory-setup」 リポジトリで、Claude CodeとGraphifyを組み合わせた検証環境
• 注意: 対象リポジトリの規模・クエリの種類・比較対象の測り方が公式ドキュメントに明示されていないため、別環境で同じ数値を再現できる保証はない

この数値をそのまま「公式が保証する削減率」として扱うのは誤りです。Graphify Labsも公式サイト上でコミュニティ報告として明示しています。

実務でGraphifyを検討する際は、まず自社リポジトリで 「graphify extract . --code-only」 を走らせて、実際の応答トークン数の変化を測るのが唯一確実な判断材料になります。

効果を判断する指標の考え方

倍率の派手さに引きずられず、以下の3軸で導入価値を測るのが実務的です。

• recallと精度：LOCOMOやLongMemEvalのようなメモリ品質指標で、必要情報が上位N件に入るか
• 単価：同規模の類似サービス（supermemory / mem0など）と比較したingest / retrievalコスト
• オフライン適用可能性：コードだけなら 「--code-only」 で追加課金・外部送信ゼロ。非コードもローカル処理したい場合は 「--code-only」 を外して local Ollama バックエンドを選ぶ（この2つは併用ではなく別の選択肢）

この3軸で自社の要件と照らし合わせれば、「コスト削減N倍」というマーケティング数値に依存せずに導入判断ができます。

Graphifyと類似アプローチの比較

Graphifyは登場から3か月で急速に普及しましたが、類似の問題を別アプローチで解こうとする競合ツールも同時進行で存在します。

実務での選定判断のため、代表的なアプローチとの差分を整理します。

代表的な類似ツールとGraphifyの棲み分け

以下の表で、主要な類似ツールとの比較を整理しました。全て「AIアシスタントに大規模コードベースを効率よく理解させる」問題への異なる解答です。

この整理から見えるのは、Graphifyのポジションは「ローカル決定的抽出 × バックエンド選択の自由度 × 横断性」という3軸で他ツールと差別化されていることです。

「特定ベンダーのIDEに縛られたくない」「非コードデータの処理経路を自組織で選びたい」「複数のAIコーディングアシスタント間でグラフを共有したい」というニーズに対しては、現時点でGraphifyが最有力候補になります。

どの場面でどれを選ぶか——実務判断の3軸

3軸で整理すると、選択判断は次のようになります。

• 統制要件
  SSO・監査、またはEnterprise機能をVPC／オンプレで運用する要件がある → Sourcegraph／Graphify Enterprise。組織要件が緩い、または個人・小チーム運用 → Graphify OSS版（OSSコアもオンデバイス・エアギャップ・自社VPCで運用可能）
  
  

• メディア構成
  コード＋テキスト系ドキュメントで完結 → codebase-memory-mcp（精度優先）またはGraphify OSSを選択バックエンド付きで運用。コードのみで完結 → Graphify OSSを 「--code-only」 で運用。コード＋PDF・画像・議事録などマルチモーダル混在 → Graphify（バックエンド選択でクラウド／ローカル運用を切替可能）
  
  

• 使うAIアシスタントの多様性
  組織内で1ツール統一（例：Cursor onlyやClaude Code only） → 内蔵インデックスで十分。複数ツール併用 → Graphifyの横断性が効く

AI総研の支援現場でも、「開発チーム内でCursor派とClaude Code派が分かれている」ケースは多く見られます。この場合、Graphifyの20+ツール対応は組織全体のAIコーディング体験を統一する上で強い武器になります。

Graphify導入判断で詰まる論点——AI総研の実務観点

ここまでGraphifyの技術と料金・比較を整理しましたが、実務で導入判断する際にはいくつか「詰まる論点」があります。AI総研がAI導入支援の現場で見てきた傾向を踏まえ、整理します。

効き目は自社リポジトリで実測しないと決まらない

第一の論点は、「うちのリポジトリはGraphifyが効くほど大きいか？」です。

公式ベンチマークはメモリ品質指標（LOCOMO / LongMemEval）と対類似サービスの単価差が中心で、「N倍のトークン削減」を保証する公式値はありません。
コミュニティ報告の71.5分の1事例も、対象リポジトリの規模・クエリの種類が明示されていない1ユーザー環境の値です。

つまり効果は環境依存で振れます。ファイル数・言語構成・非コード比率・普段のクエリ内容が違えば、削減効果もingest単価も変わります。
大規模かつコード＋ドキュメント混在の環境ほど効きやすい一方、小規模でコード中心のプロジェクトでは、グラフ生成にかかる時間と効果が見合わないことも起こり得ます。

実務判断としては、「まず自社の主要リポジトリで24時間PoC」が最短ルートです。

「graphify extract . --code-only」 でコードだけのグラフを生成し、代表的なクエリを10件走らせて応答トークンと応答品質を測ります。要件を満たすなら非コードデータのバックエンドを選定し、本格導入の範囲を広げる、という順序が安全です。

グラフ陳腐化と自動更新の設計

第二の論点は、「グラフをどのタイミングで再生成するか」です。

コードは日々変わるため、生成したgraph.jsonは時間経過とともに実態と乖離します。この「グラフ陳腐化」問題は、Graphify導入企業の多くが最初に詰まるポイントです。

公式が用意している解決アプローチは、次の4つです。

• 差分再生成
  「/graphify ./raw --update」 で変更ファイルだけ再抽出。個人開発や手動運用の第一選択で、コード・非コードのいずれの変更にも対応する
  
  

• watchモード
  「graphify watch ./src」 を常駐させ、コード変更を検知した時点でASTを自動再構築。ローカル開発中のリアルタイム同期に有効。ドキュメント・PDF・画像などの意味抽出の更新は別途 「/graphify --update」 を走らせる必要がある
  
  

• Gitフック連携
  「graphify hook install」 で post-commit / post-checkout を登録。コミットごとにコード側のASTを自動更新できるが、非コードデータの意味抽出は同じく 「/graphify --update」 を別途走らせる
  
  

• CIパイプライン連携
  「main」ブランチへのマージ時にGitHub ActionsやGitLab CI経由で更新をかける。組織全体のグラフ鮮度を担保したい場合に選ぶ経路

ここでよく混同されるのが、「/graphify . --mcp」 で立てられるMCP（Model Context Protocol）サーバの役割です。MCPは既存のグラフをクエリ可能な形で公開する仕組みで、それ自体は自動更新を行いません。

更新は上記4経路のいずれかで担保し、MCPは「アシスタントがグラフに問い合わせるチャネル」として組み合わせる、という切り分けが正確です。組織導入時は「陳腐化を許容する更新頻度」の合意形成が重要な設計論点になります。

プライバシー境界——コード側とバックエンド側で扱いが変わる

第三の論点は、「どのデータが外部APIに送られるか」の切り分けです。

金融・製造・医療などコンプライアンス制約のある業界では必ず精査が必要です。

以下の表で、Graphifyの処理段階ごとのプライバシー境界を整理しました。

Step 2の外部送信可否は、選ぶバックエンドで決まります。Claude / OpenAI / Gemini / DeepSeek / Kimi / Bedrock / Azure を選ぶと該当プロバイダにデータが渡り、local Ollamaを選ぶと完全にローカルで完結します。

実務対応の型は次の3パターンです。

• コードのみ運用
  「graphify extract . --code-only」 を使うと、非コードデータは処理対象から除外される。APIキー不要でコードのみを完全ローカルにグラフ化する構成
  
  

• 非コードもローカル処理する運用
  「--code-only」 を付けず、バックエンドを local Ollama に設定する。非コードデータも自マシン内で意味抽出でき、機密PDFやドキュメントを含む用途で選ばれる（「--code-only」 との併用ではなく、選択が別）
  
  

• クラウドLLM運用
  Claude / GPT / Geminiなどクラウドバックエンドを使う。非コードデータが該当プロバイダに送信されるため、契約・DPAで整合を取る必要がある。精度・費用は選ぶモデルにより異なる

Graphify Enterpriseでは、これに加えてSelf-hosted deploymentが提供予定で、監査・SSO・アクセス統制まで含めた組織運用に踏み込めます。

立ち上げ方の型——PoC→バックエンド選定→更新設計の順で決める

以上の論点を踏まえ、AI総研が実務で提示している立ち上げ方の型を整理します。

「N倍削減できる」という数値の期待から入るのではなく、まず自社の要件に合わせた運用形を決めて、あとから効果を測る順序が安全です。

• ① 24時間PoC
  「graphify extract . --code-only」 を主要リポジトリで走らせ、応答トークンと応答品質を10クエリ程度で実測する。この段階では追加課金は発生しない
  
  

• ② バックエンド選定
  非コードデータも扱いたい場合、機密度・既存クラウド契約・単価要件からCloud LLM／Bedrock・Azure／local Ollamaのいずれかを決める
  
  

• ③ 更新経路の設計
  「--update」 差分再生成・「graphify watch」 常駐・「graphify hook install」 によるGitフックのいずれか（複数組み合わせ）で、陳腐化を許容する更新頻度を担保する
  
  

• ④ Enterprise検討
  Merge-gate verification・Graph-aware code review・Engineering digest・Jira connectorなどの機能や、それらEnterprise機能のセルフホスト運用が必要になったら、Enterprise Early Accessへ

いずれのフェーズでも、「Graphifyを入れたから開発生産性が上がる」ではなく、「Graphifyでコードベースの知識を管理下に置いた上で、AIコーディングアシスタント運用を再設計する」という発想が本質です。

ツール導入は手段に過ぎず、Claude Code・Cursor・Codexなどをどう組織で回すかの全体設計が伴わないと、graph.json が単なるファイルで終わってしまいます。

コード知識をチーム資産に変える業務Agent基盤を検討するなら

Graphifyのようなナレッジグラフスキルは個々の開発者にとって強力な武器ですが、組織全体でコード資産・ドキュメント・議事録を横断して活用するには、業務Agent基盤の設計が別途必要です。ツール単体では、開発者ごとにgraph.jsonが分散し、モデルの世代交代のたびに使い方が変わり、最終的にはナレッジがサイロ化します。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。

AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、Claude Code・Codex・Cursorなど各世代のAIコーディングアシスタントを吸収しながら、組織的なコード知識活用の運用基盤として機能します。

• 開発Agentをコード知識と接続
  Graphify的なナレッジグラフをバックエンドに据えたコードレビューAgent・依存関係分析Agent・オンボーディングAgentを、Teams上から即起動。個人ツールに閉じずチーム資産として利用可能
  
  

• モデル世代交代を吸収する管理層
  Claude Opus 5 → 次世代モデルのように短サイクルで世代交代しても、業務Agent側の設計は不変。graph.jsonのようなナレッジ資産もモデル非依存で再利用できる
  
  

• Agent単位でアクセス統制を1画面統制
  コード・ドキュメントを扱うAgentごとにアクセス範囲を設計。誰がどのAgentで何を照会したかを不変ログで残し、監査対応をそのまま提出できる形で保管
  
  

• データは100%自社Azureテナント内に保持
  コード・ナレッジグラフ・議事録はAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計

AI総合研究所の専任チームが、Graphifyのようなオープンソースツールの選定・PoCから、業務Agent基盤の統合設計までを一貫して支援します。AI Agent Hubのサービスページで、コード資産と業務Agentを組み合わせた実装例をご確認ください。

コード知識をチーム資産に変える業務Agent基盤

Graphify的なナレッジグラフを組織横断で回す

Graphifyのようなナレッジグラフスキルは個々の開発者にとって強力ですが、コード資産・ドキュメント・議事録を横断してチーム全体で活用するには業務Agent基盤が必要です。AI Agent HubはClaude CodeやCodex・Cursorのモデル世代交代を吸収しながら、業務特化Agent群で組織的なコード知識活用を支援する基盤として機能します。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Graphifyについて、48時間リリースの経緯・Token Tax問題の解決アプローチ・コード+非コードの2段階アーキテクチャ・20+ AIコーディングアシスタント対応・導入手順・料金プラン・公式ベンチマーク・類似アプローチとの比較・導入判断で詰まる論点までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• GraphifyはApache License 2.0で完全無料のOSS本体とEarly AccessのEnterprise版の二層構造で、tree-sitterによるコードのローカルAST解析と非コード処理の2段階設計で20+のAIコーディングアシスタントに横断的にgraph.jsonを配布できる
• 公式ベンチマークはLOCOMO recall@10=0.497・LongMemEval-S QA=76%・対mem0で約10倍のretrieval recall・対supermemoryで約11倍安いingestコストと、Token Tax問題への効果が数値で示されている
• 実運用の詰まる論点はグラフ陳腐化への対応（--update/watch/hook install/CI連携）とプライバシー境界の設計で、SSO・監査・VPC/オンプレ運用の要件が出た段階でEnterprise Early Accessへ登録する順序が現実的
  
  

まずは自社の主要リポジトリで「graphify extract . --code-only」を走らせ、応答トークンと応答品質を実測するのが、最も実用的な第一歩になります。ツール導入単独では効果は限定的なので、Claude Code・Cursor・Codexをどう組織で回すかの全体設計と、コード知識をチーム資産に変える業務Agent基盤の整備を並行で進めるのが、2026年の実務ラインです。