AI コーディングツールでよく起きる問題は、コード補完はうまいのに、今見ているリポジトリ全体の構造を本当に理解しているとは限らないことです。大量のファイルを読ませれば一時的には改善しますが、コンテキストが切れると、プロジェクト内の関係性はまた失われがちです。

今日紹介する Muvon/octocode は、この問題に向き合うためのプロジェクトです。Rust で書かれたコードインテリジェンスツールで、セマンティック検索、tree-sitter による構造解析、知識グラフ、MCP server を同じローカルワークフローにまとめています。GitHub では現在およそ 376 stars。まだ大規模に知られているわけではありませんが、AI コーディング基盤としてかなり気になる小規模プロジェクトです。

プロジェクト概要

項目内容
リポジトリMuvon/octocode
Stars約 376
Forks33
主な言語Rust
ライセンスApache-2.0
最新 GitHub Release0.14.0、2026 年 4 月 13 日公開

何を解決するのか

従来の RAG では、コードベースをテキストチャンクに分割し、ベクトル検索にかける設計がよく使われます。これは「似ているコード片」を探すには役立ちますが、あるファイルが何を import しているのか、どの関数がどれを呼んでいるのか、あるモジュールがアーキテクチャ内でどんな役割を持つのかまでは自然には理解しません。

Octocode の考え方は明快です。コードを単なるテキストではなく、構造を持つシステムとして扱う。

tree-sitter でソースコードを解析し、関数、クラス、import、依存関係などを抽出します。そのうえで、それらの関係を知識グラフとして整理しつつ、自然言語によるセマンティック検索も提供します。「認証ロジックはどこか」「支払いモジュールに依存しているものは何か」「データベースエラーを扱う箇所はどこか」といった質問に向いています。

AI Agent と相性がよい理由

Octocode の注目点は、単なる CLI 検索ツールに留まらず、コードインデックス機能を MCP server として公開できるところです。

つまり Claude Desktop、Cursor、Windsurf、その他 MCP 対応クライアントから、Octocode をローカルツール群として呼び出せます。

  • semantic_search：意味でコードやドキュメントを検索する
  • view_signatures：ファイル内の関数シグネチャ、型、import 構造を見る
  • graphrag：ファイル、関数、モジュール間の関係を調べる
  • structural_search：AST パターンで特定のコード形状を探す

Agent にとっては、リポジトリ全体をプロンプトに詰め込むより安定した方法です。まず関連モジュールを見つけ、その後に関係をたどって周辺を確認できます。単発の巨大コンテキストに頼るより、調査の流れを作りやすくなります。

ローカル優先の設計

Octocode はローカル優先の設計も特徴です。インデックスと MCP server は手元のマシンで動き、.gitignore を尊重し、基本的にはローカルプロジェクトを対象にします。複数の embedding provider をサポートし、ローカルモデルを使う選択肢もあります。クラウド embedding を使う場合でも、ドキュメント上ではソース全体ではなく構造化メタデータを扱う方向が示されています。

これは社内コードベースでは重要です。AI にコードを読ませたい一方で、リポジトリ全体を外部 SaaS に預けたくないチームは多いはずです。Octocode は embedding provider への信頼問題を完全になくすわけではありませんが、コード理解の大部分を開発者のローカル環境に戻そうとしています。

日常的な使い方

基本的な流れは次のようになります。

octocode index
octocode search "authentication middleware"
octocode mcp --path .

MCP server を AI クライアントに接続すれば、アシスタントが会話中にコードを検索し、関係をたどれるようになります。

検索以外にも、README や公式サイトでは次のような日常開発機能が紹介されています。

  • staged changes から commit message を生成する
  • AI code review を実行する
  • release 関連の作業を支援する
  • commit history を検索する
  • プロジェクト用の永続メモリを持つ

「コードベース検索エンジン」と「AI 開発 CLI」を合わせたような位置づけです。実際に試すなら、まずはインデックス、セマンティック検索、MCP server から始めるのが現実的です。すべての AI 自動化機能を最初から主ワークフローに入れる必要はありません。

通常のコード検索との違い

テキストを探すだけなら、ripgrep は今でも非常に速く、信頼できます。Octocode の価値は rg の置き換えではなく、rg が苦手な種類の問いを扱える点にあります。

問い通常のテキスト検索Octocode が向いている点
変数名や文字列を探すとても向いている必須ではない
「認証フロー」のような意味検索キーワードを推測する必要がある自然言語で探せる
ファイルをまたぐ依存関係を追う手で多くのファイルを開くグラフ関係を照会できる
AI Agent にプロジェクト文脈を渡す大量に貼り付けがちMCP 経由で必要な分だけ検索できる
構造的なコードパターンを探す正規表現が壊れやすいAST パターンのほうが安定しやすい

つまり、「関数名を知っているので探したい」という場面よりも、「AI ツールにプロジェクト構造を把握してほしい」という場面で価値が出ます。

注意点

Octocode はまだ変化の速いプロジェクトです。star 数も多すぎず、release も比較的活発です。チームの中核ワークフローに入れる前に、次の点は確認したほうがよいでしょう。

  • 大きなリポジトリを索引化したときの時間とディスク使用量
  • embedding provider とのデータ境界がチーム規約に合うか
  • MCP client からの呼び出し結果が安定し、追跡できるか
  • 永続メモリがチーム共有に向くのか、個人利用に留めるべきか
  • AI review、commit、release のような機能に人間の gate を置けるか

特に安全面では、コード検索とコード理解から試すのがよさそうです。自動 commit や自動 release は別枠で評価するべきです。

まとめ

Octocode が面白いのは、AI コーディングの基礎的な課題をはっきり示しているところです。Agent に必要なのは、より大きなコンテキストだけではなく、よりよいコード地図です。

プロジェクトが大きくなるほど、ファイルを追加で詰め込むだけの方法は高くつきます。tree-sitter で構造を抽出し、知識グラフで関係を保持し、MCP 経由で Agent が必要なときに照会する。この方向は、長期的に扱いやすいコードインテリジェンス基盤に近いと思います。

Cursor、Claude Code、Codex、あるいは自作の Agent runtime にローカルコード理解能力を持たせたいなら、Muvon/octocode はウォッチリストに入れておきたいプロジェクトです。

リポジトリ：https://github.com/Muvon/octocode