Ixとは？コードベースマップをClaude Codeに渡すOSS CLI

コーディングエージェントを長く使うほど、同じ説明を繰り返している感覚が増えていきます。新しいセッションを開くたびに「このサービスの境界はどこか」「この関数を触ると何が壊れるか」を、grep やファイル読み直しで再構築する。コンテキストは消費され、回答は再び推測に寄りがちです。

📑目次

1. Ixとは何か — living system map の位置づけ
2. 何が新しいか — 記憶・ハーネス・repo pack とのレイヤ比較
3. 導入手順 — CLI・Docker・Claude Code プラグイン
4. 主要コマンドと実務ワークフロー（map → explain → impact → trace）
5. 採用判断チェックリストと alpha のリスク
6. よくある質問（FAQ）
7. まとめ — 今日やること

Ix（ix-infrastructure/Ix）は、その再構築コストを「会話の記憶」ではなく「コードから作る構造マップ」で減らそうとする OSS です。

具体的には以下の作業を行います。

• tree-sitter でリポジトリを解析する
• シンボル・呼び出し・import のグラフをローカルに保持する
• ix map / explain / impact / trace といった境界付きの問い合わせを人間と AI の両方に渡す

ライセンスは Apache-2.0、公式ステータスは alpha です。

本記事で整理する範囲は次の通りです。

• Ix の位置づけ
• 記憶系ツールやハーネスとのレイヤ差
• 導入手順と主要コマンド
• 採用判断のチェックリスト

トークン削減の百分率はベンダー主張として扱い、採用可否は自リポジトリでの短い実験で判断する前提とします。

---

Ixとは何か — living system map の位置づけ

定義

結論から言うと、Ixはリポジトリ全体をクエリ可能なliving system mapにするCLIツールです。

公式READMEの一文は「Understand any codebase instantly. System intelligence for codebases, built for humans and AI.」です。ドキュメントでは「Persistent, queryable code memory for LLM assistants and humans.」と位置づけられています。

仕組み

仕組みは次の3段階に整理できます。

1. tree-sitter でソースをパースする（README は最大26言語を主張）
2. シンボル / call / import のグラフをローカル backend（ArangoDB via Docker）へ保存する
3. ix map / explain / impact / trace などで、境界付きの構造質問を返す

設計の要点

重要なのは、構造そのものをLLMに推測させない設計を前面に押し出している点です。

• Show HN でも「No LLM inferring structure」と説明されている
• セマンティック検索や長期記憶の拡張はロードマップ側の話として分離されている
• グラフはマシン上に残るため、セッションをまたいでも「毎回ゼロから地図を描き直す」必要がない

ステータスと第三者確認

ステータス面では公式がalpha版であることを明記し、APIや挙動の変更があり得ると警告しています。

第三者の確認情報は次の通りです。

• MAGI Archive（2026-08-07）: architecture map とトークン利用の文脈で独立に取り上げ
• MCP Skills: Verified 約 7.6/10（2026-08-11 時点スナップショット、★約679 / forks 56、Apache-2.0）としてカタログ化
• SkillsLLM: CLI ワークフローと multi-agent インストール面を掲載

存在と導入面の第三者確認はできます。ただしREADMEの削減率ベンチをそのまま再現した独立検証ではありません。

出典（2026年8月時点）:

• GitHub ix-infrastructure/Ix
• Ix Docs
• MCP Skills
• MAGI Archive

---

何が新しいか — 記憶・ハーネス・repo pack とのレイヤ比較

Ixの新しさは「もう一つのチャット要約ツール」ではなく、構造のsource of truthをローカルに持つ点にあります。似た問題意識を持つツールは増えていますが、保持する情報の本質が異なります。

レイヤ比較表

レイヤ	代表例	保持するもの	強み	弱み・注意
構造マップ	Ix	シンボル/依存/フローの決定論グラフ	変更影響・追跡が構造ベース	Docker backend、alpha、学習コスト
会話/要約メモリ	claude-mem 系	セッション要約・ノート	人間向け文脈の継続	アーキテクチャの真実源にはなりにくい
ベクトル/RAG 記憶	OptMem 等	埋め込み検索	自然文の曖昧検索	構造的な「壊れる範囲」は弱い
エージェント・ハーネス	jcode 等	実行ループ・権限・ワークフロー	作業の自動化	コード構造の地図そのものではない
repo pack / 一括投入	各種 pack	その場のファイル束	即席コンテキスト	永続マップにならない・トークンが大きい

出典: GitHub Ix README、Ix Docs、SkillsLLM Ix（2026年8月時点）

判断軸

判断軸はシンプルです。

• 毎回の説明コストを下げたいのか
• 変更の影響範囲を依存関係で見たいのか
• 作業ループそのものを自動化したいのか

Ixが特に効きやすいのは前二者です。

レイヤの使い分け

• CLAUDE.md や会話メモリ: 「方針・好み・作業メモ」を運ぶ
• Ix: 「このシンボルは誰に呼ばれ、何に依存するか」を返す
• ハーネス: 実行と権限の問題を解く
• repo pack: 一度きりの投入に強い一方、永続マップにはならない

置き換えではなく併用が自然です。

---

導入手順 — CLI・Docker・Claude Code プラグイン

前提チェック

導入前に、環境が要件を満たしているかを先に確認します。公式READMEが挙げる前提条件は次の通りです。

• ✓ Node.js 22+
• ✓ Git
• ✓ ripgrep（ix text 用途）
• ✓ Docker + Docker Compose
• ✓ macOS/Linux なら curl、Windows なら PowerShell

インストール

インストールは公式提供のスクリプトが中心です。

# macOS / Linux
curl -fsSL https://ix-infra.com/install.sh | sh

# Windows (PowerShell)
irm https://ix-infra.com/install.ps1 | iex

Intel Mac は prebuilt が無い場合があり、README は Homebrew tap からの source build を案内しています。curl | sh 系は便利な一方で、実行前にスクリプト内容を確認する運用が安全です。

初回の健全性確認

初回の健全性確認は次の順序で行うと分かりやすいです。

1. ix status で backend 到達を確認
2. 不通なら ix docker start
3. ix doctor で server / DB / graph integrity を見る
4. 対象リポジトリで ix map. を実行してグラフを構築

Claude Code プラグインと他エージェント

Claude Code 向けは公式 Docs の ix-memory プラグイン経路が厚いです。

1. /plugin marketplace add ix-infrastructure/ix-claude-plugin
2. /plugin install ix-memory
3. 再起動または reload
4. 前提として ix status が ok、PATH に jq と rg

他のエージェントと失敗時の切り分けは次の通りです。

• Codex / Cursor / Gemini / OpenCode / OpenClaw: 各 install script や extension がある
• 汎用経路: リポジトリへ AGENTS.md を置き JSON モードでループする案内がある
• よくある失敗: Ix backend not reachable（原因の多くは Docker 未起動）
• 切り分け: IX_DEBUG=1 が使える

出典（2026年8月時点）:

• GitHub Install/Requirements
• Ix Docs

---

主要コマンドと実務ワークフロー（map → explain → impact → trace）

日常コマンド

日常的に使う核となるのは、Docsが示す次のコマンド群です。

• ix map — パースとグラフ更新
• ix search <term> --kind class — 種別付き検索
• ix explain <symbol> — 役割・重要度・caller/dependent（ソース全文を毎回読まない）
• ix impact <target> — 変更の blast radius
• ix rank --by dependents --kind class --top 10 — ホットスポット抽出
• ix read <symbol> — 名前や行範囲でソース取得

加えて README 例の ix trace <flow>、Docs の --format json / --format llm がエージェント連携で効きます。

推奨ループと Claude plugin

推奨される利用ループは次の順序です。

1. overview で再開する
2. impact で影響を確認する
3. rank でホットスポットを見る
4. 変更後に map を更新する

Claude pluginのskill面:

• /ix-understand
• /ix-investigate
• /ix-impact
• /ix-plan
• /ix-debug
• /ix-architecture
• /ix-docs

hooksの要点:

• Grep/Glob/Read の前に graph クエリを挟む
• edit 後に map を更新する
• backend 不通時は silent bail する

「プラグインを入れたのに効いていない」ときはstatusを先に疑います。

実務シナリオ

実務での使い方は用途ごとに分けると運用しやすくなります。

• オンボーディング: map → rank → 上位シンボルを explain
• リファクタ前: impact → callers 確認 → テスト対象の抽出
• 障害調査: 症状から investigate/debug skill → 必要な箇所だけ read

「全部のコードをLLMに読ませる」のではなく、「地図で当たりを付けてから読む」アプローチに寄せるのがIxの正しい使い方です。

---

採用判断チェックリストと alpha のリスク

向いている条件 / 向かない条件

向いている条件は次の通りです。

• 中〜大規模、または未知リポジトリを短時間で掴みたい
• Claude Code などで構造質問を毎回やり直している
• 変更影響を感覚ではなく依存グラフで見たい

向かない、または保留が妥当な条件もあります。

• Docker を回せない環境
• 超小規模スクリプトで map コストが便益を上回る
• 本番 SLA 前提で安定 API が必須（alpha）

数値・リスクの扱い

数値の扱いには注意が必要です。

• README の 30–99.7% token 削減や daily LLM usage +43% はベンダー主張
• 第三者ソースは存在・カタログ・信頼スコアまでは確認できる
• 同一ベンチの再現は未検証
• MCP Skills の導入コメントは「evaluate は妥当、production 前に詳細レビュー」の温度感
• SkillsLLM 掲載の automated scan PASSED（2026-05-30）は参考情報であり、自前 audit の代替にはならない
• ローカル graph + Docker がデータ境界になる点は利点でもあり、backend 運用と更新追従のコストでもある

読者向け次アクション

読者向けの次のアクションは、以下の5つの手順に落とすと迷いが減ります。

1. 対象 repo で Docker 可否を確認する
2. install → ix doctor → ix map.
3. 自分の最頻タスクで explain と impact を1回ずつ試す
4. Claude Code なら ix-memory を入れ、hooks が silent bail していないか見る
5. 1週間後に、トークン体感と古いマップによる誤誘導の有無をメモし continue/stop を決める

出典（2026年8月時点）:

• GitHub Status/Results
• MCP Skills
• SkillsLLM

---

関連記事:

• CLAUDE.md設計パターン｜個人・チーム・モノレポで使い分ける構成と肥大化対策
• Better Harness（QoderAI）— Claude Code / Codex / Cursor の Loop を採点・改善する OSS（MIT）
• Puppetmaster v1.21.10 — Cursor / Claude Code / Codex / Hermes を束ねるコスト志向エージェント・スウォーム制御面

よくある質問（FAQ）

Q1. Ix は Claude のメモリ機能や CLAUDE.md の代わりになりますか？

• 答え: 別レイヤです。
• CLAUDE.md は指示・規約の always-on context、Ix はコード構造のクエリ可能な地図です。
• 方針は CLAUDE.md、構造は Ix、という併用が自然です。
• 関連: CLAUDE.md設計パターン

Q2. マップは LLM が推測して作るのですか？

• 答え: 公式 README と Show HN の説明はいずれも、コードから決定論的に構築し、LLM が構造を推測する方式ではない、という立場です。
• セマンティック拡張はロードマップ側として分けて評価するのが安全です。

Q3. 最小構成で何が必要ですか？

• 答え: Node.js 22+、Git、ripgrep、Docker が中心です。
• install 後の確認順: 1. ix status 2. ix docker start 3. ix map.

Q4. Claude Code だけで使えますか？

• 答え: Claude plugin の厚みは大きい一方、次の経路もあります。
• Codex
• Cursor
• Gemini
• OpenCode
• OpenClaw
• AGENTS.md
• エージェント横断で同じマップを共有したい場合に効きます。

Q5. トークンが本当に数十％減りますか？

• 答え: README の数値はベンダー主張です。
• 第三者は製品存在とコマンド面を確認しています。
• 実務では explain / impact 前後のプロンプト長を自環境で測るのが確実です。

Q6. 本番導入してよいですか？

• 答え: alpha です。API 変更があり得ます。
• 評価用途から始め、backend 運用と更新追従コストを見て判断するのが妥当です。

---

まとめ — 今日やること

Ixは、「エージェントに毎回コードベースを教え直す」問題に対する構造マップ解です。会話メモリやハーネスを置き換える銀の弾丸ではなく、依存関係と変更影響を先に見るためのローカル知識層として評価するのが適切です。

今日の最小限の実験は次で十分です。

1. Docker 可否を判定する
2. 公式 install を実行する
3. 自分の repo で ix map.
4. 1タスクで explain と impact を試す
5. alpha リスクを許容できるかで continue/stop を決める

Claude Code 利用者は ix-memory まで進め、hooks が実際に効いているかを status と合わせて確認してください。Skills 設計やハーネス運用と組み合わせる場合は、Claude Code Skills の書き方 と Claude Codeのハーネスとは もあわせて読むと、レイヤ分担がはっきりします。