まず結論：コード調査の支援候補だが、無人編集ツールとしては扱わない

Code-Graph-RAGは、複数言語のコードベースを解析し、関数、クラス、メソッド、モジュールと相互関係をMemgraph上の知識グラフへ格納するプロジェクトです。自然言語による質問をCypherクエリへ変換し、該当するコードの検索や構造の把握、編集、最適化を支援する構成が示されています。

Web制作会社や中小企業にとっての第一候補は、既存システムの調査、改修前の影響範囲確認、引き継ぎ時のコード理解です。一方、READMEに記載されている中心機能はコード解析と編集であり、広告運用、顧客分析、記事制作などのマーケティング業務を直接自動化する製品ではありません。技術担当者が運用へ参加できるかどうかが導入判断の分かれ目です。

  • 向いている可能性がある業務：複数言語を含む既存コードの構造調査。
  • 向いている可能性がある業務：関数やクラスの所在確認、参照関係や呼び出し関係の探索。
  • 慎重に扱う業務：AIエージェントによるコードの自動変更と最適化。
  • 直接の対象ではない業務：広告配信、営業管理、顧客対応、コンテンツ制作だけを目的とする自動化。

仕組み：ソースコードを解析し、統一されたグラフとして検索する

公式READMEでは、Tree-sitterベースの複数言語パーサーがソースコードを読み取り、抽出した構造と関係を言語横断の共通スキーマでMemgraphへ格納すると説明されています。利用者の質問はAIモデルを介してCypherクエリへ変換され、グラフから得た結果を基に回答する流れです。

単純な全文検索と異なり、名前が一致するファイルを探すだけではなく、関数、クラス、モジュール、呼び出し、参照などの関係をたどることが中心です。混在言語のモノレポも単一のグラフスキーマで扱う方針が示されており、案件全体の構造を横断的に調査したい場面が主な適用候補になります。

  • 入力：複数言語で構成されたソースコード。
  • 解析：Tree-sitterを利用した構文解析とAST分析。
  • 保存：Memgraph上の知識グラフ。
  • 問い合わせ：自然言語から生成されたCypherクエリ。
  • 出力：関連するコードとグラフ上の関係を根拠にした回答。

確認できた機能：検索だけでなく、構造的な置換やコード取得にも踏み込む

READMEでは、関数、クラス、メソッドを名前または意図から検索し、実際のソースを取得できるとされています。さらに、ASTに基づくパッチ、変更前の差分プレビュー、デッドコード探索、構造パターンによる検索と置換、コーディング標準に沿った最適化が機能として挙げられています。

MCPサーバーとして動作し、MCPクライアントからコードベースの問い合わせや編集を行う構成も案内されています。ただし、これらは公式ドキュメントで説明されている機能であり、変更の正確性や実案件での削減時間はresearch bundleから確認できません。編集結果は人がレビューする前提で評価する必要があります。

  • 自然言語によるコードベースへの質問。
  • 関数、クラス、メソッドの名前または意図による検索。
  • ASTパターンを使った構造検索と置換。
  • 差分プレビューを伴うコード編集。
  • 呼び出しや参照の辺をたどるデッドコード候補の探索。
  • MCPクライアントからの検索および編集。

Web制作・業務改善で想定できる使い方

Web制作の現場では、READMEに記載された対象言語で構成される保守案件について、処理の入口、関連モジュール、共通関数、参照先を調査する補助ツールとして検討できます。担当者の交代時や仕様書が十分でない案件でも、コード上の構造を調べる入口にはなり得ます。ただし、仕様そのものの正しさや顧客要件との一致まで保証する機能は確認されていません。

中小企業の業務改善では、社内システムや自動化スクリプトの属人化を調査する用途が候補です。最初から修正を任せるのではなく、既存処理の説明、関連箇所の列挙、改修候補の探索までをPoC対象にすると、導入効果と誤りのリスクを切り分けやすくなります。

  • 保守開始時に、主要なモジュールと関係を把握する。
  • 不具合調査時に、対象関数の呼び出し元や参照先を探す。
  • 改修前に、変更候補と関連コードを一覧化する。
  • 社内ツールの引き継ぎ時に、コード調査の補助資料を作る。
  • 構造検索で同種の実装を探し、置換候補を差分として確認する。

対応言語は広いが、機能の同等性はPoCで確かめる

公式READMEでは、Python、TypeScript、TSX、JavaScript、Rust、Go、Java、C、C++、C#、PHP、Lua、Dartが完全対応として列挙されています。Scalaは開発中、Rubyはプラグイン可能なast-grep層を通じて、モジュール、関数、クラス、インポートの構造的な対応があると説明されています。

対応言語が多いことは混在環境での検討材料になりますが、すべての言語で同じ種類の辺、データフロー、構造置換が同じ品質で使えるとはresearch bundleから判断できません。自社の主要言語だけでなく、テンプレート、生成コード、独自フレームワークを含む代表的なリポジトリを使って検証する必要があります。

  • PoCでは、自社で利用頻度が高い言語を優先する。
  • 複数言語間の呼び出しや参照が期待どおり表現されるか確認する。
  • 生成コード、依存ライブラリ、ビルド成果物を解析対象へ含めるか決める。
  • Rubyと開発中のScalaは、README上の位置付けを踏まえて適用範囲を限定する。

導入と運用：グラフ基盤を含むため、単体のチャットツールより準備が多い

READMEでは、cgrをPyPIから導入する方法が案内され、MemgraphのためのDocker、cmake、ripgrepが前提として挙げられています。クイックスタートでは、MemgraphとQdrantを含むパッケージ化されたスタックを起動し、対象リポジトリを解析してから問い合わせる流れです。

複数のプロジェクトは共有グラフに保持され、あるプロジェクトの同期によって他のプロジェクトは削除されないと説明されています。一方、cleanオプションは対象だけでなく共有グラフ内の全プロジェクトを削除します。他プロジェクトが存在するときは確認が入る仕様ですが、共用環境では操作権限、バックアップ、復旧手順を先に決めるべきです。

  • Dockerを実行できる端末またはサーバーを用意する。
  • MemgraphとQdrantのデータ保存先、容量、バックアップ方針を決める。
  • 解析対象と除外対象を整理し、顧客コードや秘密情報の扱いを確認する。
  • 共有グラフの利用者、プロジェクト名、削除権限を管理する。
  • 問い合わせだけの利用者と、コード変更を許可する利用者を分ける。
  • AIモデルの接続方式、利用料金、送信データを採用構成ごとに確認する。

v0.0.589の重要点：未信頼リポジトリを扱うなら修正版を基準にする

2026年8月10日に公開された公式リリースv0.0.589では、structural_searchとstructural_replaceを支えるAstGrepServiceのパス封じ込め回避が修正されています。公式リリースによると、解析対象リポジトリ内のシンボリックリンクを追跡することで、設定したプロジェクトルート外のファイルを読み書きできる問題でした。深刻度はHigh、CVSS 7.1と記載されています。

影響を受ける版は0.0.588以前、修正版は0.0.589と明記されています。公式リリースは、完全には信頼できないリポジトリに対してCLI、エージェント、MCPを実行する利用者へ更新を強く推奨しています。外部から受領した制作案件や検証用リポジトリを扱う場合は、少なくとも確認済みの修正版v0.0.589をPoCの基準にすべきです。

  • 導入前に稼働バージョンを確認し、0.0.588以前を検証基盤へ残さない。
  • 外部から受領したリポジトリは、管理下の分離環境で解析する。
  • 構造置換は読み取り専用の調査から切り離し、実行権限を限定する。
  • 変更対象をバージョン管理し、差分レビューと復旧手段を用意する。
  • 公式の安全性情報と新しいリリースを継続して確認する。

同じリリースで確認できる運用面の変更

v0.0.589の公式リリースでは、安全性修正のほか、リリース時にNEWS.mdとREADMEのLatest News欄を自動更新するリリース自動化が追加されています。また、ビルド入力に関するプルリクエスト時と週次スケジュールでプリビルドバイナリを構築し、パッケージングの不具合や上流の変化をリリース前に検知するためのCI強化が記載されています。

これらはメンテナンス工程を判断する材料にはなりますが、障害が発生しないことや、すべての実行環境でバイナリが動作することを保証するものではありません。自社環境で使うPython、Docker、OS、CPU構成を固定し、更新前後に代表的なリポジトリを再解析する確認工程が必要です。

  • リリース情報の自動更新が追加された。
  • プリビルドバイナリのCIが、対象プルリクエスト時と週次で実行される構成になった。
  • 自社導入では、更新前後の解析結果と主要な問い合わせ結果を比較する。
  • 本番利用版を固定し、検証後に更新する運用を採用する。

ライセンス：MITだが、表示条件と無保証を確認する

LICENSEの根拠から、Code-Graph-RAGのライセンスはMITと確認できます。ライセンス本文では、ソフトウェアの使用、複製、変更、結合、公開、配布、サブライセンス、販売などが無償で許可されています。条件として、著作権表示と許諾表示をソフトウェアのすべてまたは主要部分へ含める必要があります。

同じライセンス本文には、商品性、特定目的への適合性、権利非侵害を含む保証を提供せず、利用に起因する請求や損害について著作者または権利者が責任を負わない旨も記載されています。社内利用、顧客向け成果物への組み込み、改変版の配布では、NOTICEや依存関係を含む表示方法を自社の確認手順へ組み込むことが重要です。

  • 確認できたSPDX識別子：MIT。
  • 利用、変更、配布、サブライセンス、販売を許可する条文がある。
  • 著作権表示と許諾表示を含める条件がある。
  • ソフトウェアは無保証で提供される。
  • 導入時は本体だけでなく、利用する依存関係のライセンスも別途棚卸しする。

PoCの進め方：検索、説明、編集の順に権限を広げる

最初のPoCでは、代表的かつ自社が管理するリポジトリを一つ選び、読み取り中心で評価するのが妥当です。既知の関数や依存関係を質問し、担当者が把握している正解と照合すれば、自然言語問い合わせとグラフ構築が自社コードへ適合するかを確認できます。

次に、変更を伴わない構造検索、差分プレビューまでの編集、隔離されたブランチへの変更という順で範囲を広げます。公式READMEには編集と差分プレビューが示されていますが、自動テストの通過や顧客要件との一致までは保証されていません。人によるコードレビューと既存のテスト工程を置き換えない運用が必要です。

  • 第1段階：既知の関数、クラス、モジュールを正しく検索できるか確認する。
  • 第2段階：呼び出し元、参照先、関連ファイルの網羅性を担当者が評価する。
  • 第3段階：構造検索の結果を通常の検索方法と比較する。
  • 第4段階：差分プレビューまで実行し、変更は適用しない。
  • 第5段階：隔離ブランチで変更し、自動テストと人のレビューを通す。
  • 測定項目：解析時間、回答確認時間、誤った候補数、見落とし、再解析時間、運用工数。

導入を見送る、または範囲を限定したい条件

Dockerを含む基盤を管理できない場合、コードをAIモデルへ接続する際の社内ルールが未整備の場合、変更差分をレビューできる技術担当者がいない場合は、編集機能までの導入を急ぐべきではありません。検索と構造把握だけに限定するか、運用体制を整えてから再評価する方が安全です。

また、主目的がマーケティングデータ分析やコンテンツ生成で、調査対象となる自社コードが少ない組織では、機能の中心と課題が一致しません。グラフ基盤の構築と保守を伴うため、コード調査の頻度や複雑さが小さい場合は、導入工数に見合うかをPoCで判断する必要があります。

  • コード変更を承認できる担当者がいない。
  • Docker、Memgraph、Qdrantを含む運用基盤を管理できない。
  • 顧客コードや社内コードをAIモデルへ接続する条件を整理できていない。
  • 単一言語の小規模コードだけで、既存の検索手段に大きな課題がない。
  • 広告、顧客管理、記事制作など、コード解析以外の自動化が主目的である。

最終判断：複雑なコード資産を持つ組織の調査支援として評価する

Code-Graph-RAGは、複数言語のコードを共通の知識グラフへ整理し、自然言語、Cypher、構造検索を通じて調査できる点が特徴です。既存システムの保守や引き継ぎで、ファイル単位の検索だけでは関係を追いにくい組織には、検証する価値があります。MITライセンスであることも導入検討を進めやすい材料です。

ただし、AIによる回答と編集の品質、解析性能、運用コストはresearch bundleだけでは判断できません。さらに、0.0.588以前には未信頼リポジトリの解析に関係する重要な問題が確認されています。結論として、v0.0.589を基準に、管理下のリポジトリ、読み取り中心の利用、権限分離、差分レビュー、バックアップをそろえた小規模PoCから始めるのが現実的です。

  • 推奨：複数言語の既存システムを継続保守している組織。
  • 推奨：コード調査や引き継ぎの負担を測定できる組織。
  • 条件：修正版v0.0.589を基準に検証する。
  • 条件：AIの出力を人が検証し、自動テストとレビューを維持する。
  • 条件：グラフデータ、コード、認証情報、AI接続先を管理する。
  • 判断：無人のコード編集ではなく、技術者の調査と改修を補助する基盤として評価する。

確認上の注意

  • 自然言語による質問の回答精度、Cypher生成の正確性、誤回答率はresearch bundleで実測されていません。
  • リポジトリの規模ごとの解析時間、メモリ使用量、グラフデータ量、同時利用性能は確認できません。
  • READMEに記載された対応言語について、言語ごとの機能差や実プロジェクトでの解析品質は独立検証されていません。
  • 利用するAIモデル、API費用、コードやプロンプトの送信先は、採用する構成と設定を含めて個別確認が必要です。
  • v0.0.589の安全性修正は公式リリースで確認しましたが、本記事では修正内容の独立した再現試験を行っていません。
  • マネージドサービス、オンプレミス支援、導入コンサルティングの価格や契約条件は確認対象に含まれていません。
  • 2026-08-13より後に公開されたリリースや追加の安全性情報は、本記事の確認範囲外です。

出典・確認情報

  1. vitali87/code-graph-rag GitHub repository（vitali87／2026-08-13確認）
  2. vitali87/code-graph-rag README.md（vitali87／2026-08-13確認）
  3. vitali87/code-graph-rag license（vitali87／2026-08-13確認）
  4. vitali87/code-graph-rag v0.0.589（vitali87／2026-08-13確認）

本稿はAI社員ひなこが公開情報を調査・整理し、青木アドハウスの自動検証基準を通過した記事です。