ripwire を読む: コーディングエージェントに渡す「地図」を C++23 で作る
The ripgrep of AI context: a zero-dependency C++23 CLI + MCP server for coding agents. Find what you want without reading the repo, then check you built what you meant — blast radius, tests-to-run, quality deltas. Signatures at 74.7% fewer bytes than bodies; every guess labelled, every loss published. Paddle out with a map.
ひと目でわかる
- これは何？
- ripwire は、リポジトリを読む前にエージェントへ呼び出しグラフを渡す CLI 兼 MCP サーバーだ。索引を持たず、依存ゼロの単一バイナリで動くと README は説明する。その設計と、向かない場面を整理する。
- 誰に向いている？
- ripwire は、Claude Code や Codex のようなシェル実行可能なエージェントを常用し、リポジトリ全体を読ませるトークン消費を抑えたいチームに向く。逆に、言語サーバーによる正確な型解決や、リポジトリをまたぐ大規模な依存解析が前提のワークフローには向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ripgrep の比喩が指しているもの
README は ripwire を「AI コンテキストの ripgrep」と表現する。この比喩は検索速度の話ではなく、インターフェースの形の話だ。ripgrep が「ファイルを開かずに一致行だけを返す」ように、ripwire は「リポジトリを読まずに、触るべき場所と壊れる場所だけを返す」ことを狙う。README が掲げる目標は terminality、つまり 1 つの問いに対して 1 回の呼び出しで完結する答えを返すことだと説明されている。呼び出しのあとに grep を 3 回足すなら、それは同じ検索に二重に支払っているだけで、トークンも削れないしコーディングも速くならない、というのが README の主張だ。
対象読者は、エージェントにリポジトリを渡して変更を加えさせる開発者である。README が並べる対応エージェントは Claude Code、Codex、Cursor、Windsurf、Gemini、opencode、aider で、いずれもシェルコマンドを実行できることが前提になっている。エージェント側に「リポジトリを読む」以外の選択肢を与えたい人向けの道具だと言える。
索引もデーモンも持たない単一プロセス
README によれば、ripwire は API キーも埋め込みも索引サーバーもデーモンも使わない。1 プロセスで完結し、オフラインで動く単一バイナリとして配布される。ランタイム依存はゼロと README とバッジが明示している。
README はこの設計を、グラフデータベース型の MCP サーバーとの比較で説明している。48 個の揃えた質問を django、webpack、このリポジトリ自身に対して行った測定として、ripwire の索引は 0.25 秒から 0.45 秒、メモリは 6.6 MB から 16.5 MB、比較対象は 23 秒から 52 秒、391 MB から 623 MB だったと README は記載する。ウォーム状態のクエリは 197 ms 対 1,082 ms とされている。ここで注意すべきは、これが README 自身の記載であり、本記事が追試したものではないという点だ。方法と敗因も含めた全文は docs/EVALS.md にあると README は案内している。
仕組みとして読み取れるのは、永続的な索引を構築して問い合わせるのではなく、起動時にリポジトリを解析して呼び出しグラフを組み立て、その場で答えるという流れだ。だから索引のサイズがメモリ使用量として現れ、プロセスを終了すれば消える。デーモンを常駐させない代わりに、呼び出しごとに解析コストを払う構造だと理解できる。
トークン予算と「床値」というラベル付け
ripwire の出力で特徴的なのは、答えの不完全さを明示する仕組みだ。README は、総数になり得ないカウントには floor（床値）のラベルを付け、ゼロは「見つからなかった」を意味し「存在しない」を意味しない、切り捨てが起きた場合はすべて開示する、と説明する。答えが実際より完全に見えることを防ぐための設計だと位置づけられている。
もう 1 つがトークン予算だ。答えに対してトークン上限を指定でき、完全な答えが収まらない場合は黙って行を落とすのではなく、超過したと申告すると README は述べる。予算を指定する具体的なフラグ名や設定キーは、与えられた README の範囲では確認できない。ここは導入前に実際の --help で確かめるべき部分である。
README 自身が、この 2 つは目的地ではなく「階段」だと書いている点は率直で、好ましい。完全な答えを 1 回で返せない場合があることを認めており、その場合はそう言うと明記されている。ツールの説明として誠実な部類に入る。
インストールと最初の 1 回
README が示す導入手順は 1 行だ。RIPWIRE_REPO=redhat-et/ripwire を付けて scripts/install.sh を curl で取得して実行する。インストーラは $HOME/.local/bin に配置し、PATH に通すべき行を必要に応じて表示する。
ripwire . --for="これから行う変更を言葉で"
--for に変更内容を自然言語で渡すのが基本の使い方だと README は示している。この 1 行が CLI の起動と同時に、エージェントが「いつ ripwire を使うべきか」を学ぶためのタスク形状のスキルを、マシン上で見つかった各エージェント向けにインストールして有効化すると README は説明する。つまりインストールとエージェント設定が同じコマンドに畳まれている。
README は CLI を先に使うことを勧めている。MCP サーバーは任意の第 2 インターフェースであり、その便利さにはコストがあると明記されている。MCP の verb スキーマは、呼び出すかどうかに関わらず毎セッションでエージェントのコンテキストに載る。シェルのパイプにはこのコストがない。この指摘は具体的で、MCP を入れるかどうかの判断材料になる。
対応言語の広さと、その裏側の解析精度
README が挙げる対応言語は多い。Rust、C++、Objective-C/C++、C、Metal、CUDA、Python、Go、Swift、TypeScript、JavaScript、Java、Ruby、PHP、Lua、Elixir、Bash、C#、そして JSON、TOML、YAML、Markdown だ。トピックには tree-sitter が含まれており、解析の基盤として tree-sitter 系のパーサを使っていると推測できるが、README の本文でその点を明示した記述は与えられた範囲では確認できない。
ここは導入判断で最も注意が必要な箇所だ。言語数が多いことと、その言語で正確な呼び出しグラフが引けることは別問題である。動的ディスパッチの多い Ruby や Python、マクロとテンプレートに依存する C++、リフレクションを使う Java では、静的な呼び出し解決がどこまで届くかが言語ごとに違う。README 自身が「言語サポートと限界」という節へのリンクを張っており、限界が別途文書化されている前提で書かれている。導入前に自分の主要言語がその節でどう扱われているかを読むべきだ。
Metal や CUDA が一覧に含まれるのは珍しい。GPU カーネルを含むリポジトリを扱うチームにとっては、この一覧自体が選定理由になり得る。
向かない場面と、比較対象としての LSP 系ツール
ripwire が向かないのは、正確な型解決や参照解決が前提の作業だ。索引を持たず起動時に解析する設計は軽さと引き換えに、コンパイル済みのプロジェクト情報やビルド構成を踏まえた解決を行わない可能性が高い。README の範囲では、ビルドシステムとの統合やコンパイルデータベースの利用についての記述は見当たらない。リネームやシグネチャ変更のように、すべての参照を漏れなく列挙する必要がある作業では、clangd や rust-analyzer のような言語サーバーを基盤にしたツールのほうが適している。
もう 1 つの比較軸は、README が名指ししているグラフデータベース型のコードコンテキスト MCP サーバーだ。違いはアーキテクチャにある。相手は永続的なグラフデータベースを構築して問い合わせる。ripwire はプロセスを起動するたびに解析し直し、終了とともに捨てる。前者は大規模リポジトリでの繰り返しクエリに向き、後者はセットアップ不要と低メモリに向く。README の測定値は後者に有利に出ているが、それは README 自身が選んだ条件での比較である。
第三の選択肢は、そもそもエージェントに ripgrep とファイル読み込みを組み合わせて任せることだ。追加のツールを入れずに済むが、README が指摘する「呼び出しのあとに grep を 3 回」という二重支払いが発生する。どちらが安いかはリポジトリの規模と質問の種類に依存する。
Apache-2.0 と、維持コストの読み方
ライセンスは Apache-2.0 で、特許条項を含む標準的な許容ライセンスだ。商用利用や改変、再配布が可能で、ソース開示義務はない。ここから先は法的助言ではないので、自組織のポリシー確認は別途必要になる。
保守の観点で材料から読み取れるのは、リリースの刻みだ。v0.5.0 が 2026-09-08、v0.4.0 が 2026-09-07、v0.3.8 が 2026-08-13 で、直近 2 日でマイナーが 2 つ出ている。活発だが、0.x 系でありマイナー間で CLI の挙動や出力形式が変わる可能性は残る。エージェントのスキル定義や MCP の verb スキーマをインストーラが書き込む設計である以上、更新のたびにそれらが上書きされるかどうかは確認すべき点だ。
依存ゼロの単一バイナリという配布形態は、C++ のランタイム依存を気にせず済む反面、利用者側でビルドし直す動機が薄い。バイナリをそのまま更新する運用になるなら、バージョンを固定して更新時に出力差分を取る程度の手当てが現実的だろう。README には後方互換性に関する明示的な記述は見当たらない。
採用を決める前に確かめる 3 点
第一に、自分の主要言語が「言語サポートと限界」の節でどう説明されているかを読むこと。対応表に名前があることと、呼び出しグラフが実用になることは別だ。
第二に、出力のラベルを実際に確認すること。floor や切り捨ての開示が、自分のリポジトリで期待通りに出るかどうかは、質問の種類によって変わる。README の主張を鵜呑みにせず、自分のコードで 1 度走らせて、返ってきた答えが「完全」なのか「床値」なのかを見るべきだ。
第三に、MCP を入れるか CLI に留めるかを決めること。README 自身が CLI を安いインターフェースと位置づけ、MCP の verb スキーマが毎セッションのコンテキストを消費すると書いている。エージェントに常時ツールを見せたいかどうかは、トークン予算の設計判断であって、好みの問題ではない。
編集部の結論
ripwire は、Claude Code や Codex のようなシェル実行可能なエージェントを常用し、リポジトリ全体を読ませるトークン消費を抑えたいチームに向く。逆に、言語サーバーによる正確な型解決や、リポジトリをまたぐ大規模な依存解析が前提のワークフローには向かない。導入前に確認すべきは、自分の主要言語が README の対応表に載っているか、ripwire . --for="..." の出力が「床値」「切り捨て」といったラベルをどこで付けているか、そして MCP の verb スキーマを常時コンテキストに置くコストを許容できるか、の 3 点だ。
コミュニティノート