Ixとは｜コードベースをグラフ化しClaude Codeに渡すCLI——26言語対応と常駐コストを実測

コードベースの全体像を掴む作業は、いまだに「読んで、grepして、推測する」の繰り返しです。ix-infrastructure/Ixは、そこにコードベースの地図を持ち込むApache-2.0のCLIです。tree-sitterでリポジトリを解析し、シンボル・呼び出し・importの関係をグラフとしてローカルのデータベースに永続化する。人間はix explainやix impactで構造を辿り、AIアシスタントは同じグラフを永続メモリとして参照する——というのが設計思想で、Claude Code向けのプラグインも公式に配布されています。★620（2026-08-09時点）、まだalpha表記のプロジェクトです。

本記事はREADMEの要約ではありません。実際にmacOS（darwin-arm64）へインストールし、全対応言語を1ファイルずつ含む検証用リポジトリを作って測りました。結論から言うと、コンセプトは筋が通っている一方で、「26言語対応」の内訳・動作要件・削減率の3点は、公開情報だけを読んで想像する姿とかなり違いました。

なお、Ixが前提とするClaude Code側の導入・設定・運用についてはClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめています。

Ixとは——コードベースを常駐グラフに変えるCLI

Ixの実体は、CLI（TypeScript）と解析エンジン（core-ingestion）、そしてグラフを保持するバックエンドの3層です。READMEはix map .を「グラフを構築する」コマンドとして紹介していますが、実際に触ると役割はもう少し分かれています。取り込みはix ingestが担い、ix mapは取り込み済みのグラフから階層構造を描画するコマンドでした（ix map実行時にも差分の取り込みは走ります）。

ここで押さえておきたいのは、グラフの実体がファイルではなくデータベースにあるという点です。ローカルに.ixのようなJSONやSQLiteを置く方式ではなく、Dockerで動くArangoDBに書き込みます。これが後述する常駐コストの理由であり、同時に「セッションをまたいで理解が残る」という売り文句の実装でもあります。

もう1つ、ライセンスの粒度に触れておきます。GitHub上のリポジトリはApache-2.0で、CLIと解析エンジンのソースは全部読めます。一方でグラフを保持するmemory-layer（Scala製）は別の非公開リポジトリにあり、配布はコンテナイメージの形だけです。これは隠されているわけではなく、CONTRIBUTING.mdが「The Scala backend (memory-layer) lives in a separate private repo」と明記しています。実際にそのリポジトリへAPIでアクセスすると404が返り、非公開であることが確認できました。ただし成果物側のix-memory-layer-dist（ビルド済みJARの配布用）はpublicなので、正確には「ソースは非公開・成果物は公開」という状態です。

インストールと最初のコマンド

macOS / Linuxはワンライナーです。Windowsは事前にNode.jsとDocker Desktopを入れてからPowerShell版を実行します。

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

パイプでshに流す形式なので中身を確認しておきたいところですが、この点は確認が取れました。ix-infra.comが配信するinstall.shと、リポジトリ内のscripts/install/install.shをdiffした結果は差分ゼロ（バイト単位で一致）でした。つまりApache-2.0で公開されているスクリプトそのものが配信されています。実行前に落として読みたい場合は次のようにします。

curl -fsSL https://ix-infra.com/install.sh -o install.sh
less install.sh          # 何をするか確認してから
sh install.sh

インストーラはNode.js・Git・ripgrep・Dockerの有無を確認し、足りないものだけ入れます。今回の環境では既にすべて揃っていたため、Node.jsとDockerには一切触れずに進みました（Dockerが未検出かつ/Applications/Docker.appも無い場合にのみDocker Desktopを新規インストールする分岐に入ります）。導入後の基本コマンドは次の4つです。

ix status          # バックエンドに到達できるか
ix docker start    # バックエンド（ArangoDB + memory-layer）を起動
ix init            # このディレクトリをワークスペースとして登録
ix ingest .        # コードを取り込んでグラフを構築

Ix自身のリポジトリ（223ファイル）を取り込んだ結果は次の通りでした。

Ingest summary
  processed:   223 files (5.70s)
  rev:         3

nodes (9,884 total)   config_entry 5,212 / chunk 2,606 / function 744 / module 717 / file 223 / interface 108
edges (22,016 total)  CONTAINS 6,240 / DEFINES 6,240 / CALLS 5,221 / IMPORTS 717 / REFERENCES 366

ノードの内訳を見ると、このツールが何を「理解」しているかが分かります。最多のconfig_entry（5,212）はYAMLやJSONの設定値で、function（744）とinterface（108）がTypeScriptのコード構造、chunk（2,606）は本文の分割単位です。エッジ側ではCALLSが5,221本あり、これがix impactの「変更したら何に響くか」を支えています。一方でREFERENCESは366本と少なく、動的な参照まで追い切れているわけではないことも読み取れます。実際ix explainの出力にも「Some downstream calls could not be resolved to named entities」という但し書きが出ました。グラフは完全な真実ではなく、静的解析で辿れた範囲の地図だという前提は持っておくべきです。

ix explainの出力は、LLMを経由しないテンプレート生成です。たとえばtryLoadGrammarを引くと「appears to be a helper within index.ts」「Called by: 1 entities」「Its usage is localized」といった構造由来の説明が返ります。文章の巧みさを期待するものではなく、呼び出し元・依存の深さ・変更リスクを機械的に出す道具だと捉えるのが正確です。ix impactはもう少し実用的で、languageFromPathに対して「Direct callers: 9」「Medium risk — widely shared dependency」と返しました。

「26言語対応」の内訳を実測する

READMEは26言語のパース対応と、6つの設定・データ形式の認識を掲げています。この数字自体はソースと突き合わせても正確でした。core-ingestion/src/queries.tsで中身が空でないクエリを数えるとちょうど26個、文法パッケージも12＋14で26個あり、1対1で対応します。

しかし内訳を見ると、26言語は同じ強度で支えられていません。

12言語（TypeScript / JavaScript / Python / Java / C / C++ / C# / Go / Ruby / Rust / PHP / Scala）はdependenciesに入っており、インストールできなければインストール自体が失敗します。残る14言語（Kotlin / Swift / R / Elixir / Make / Bash / Haskell / Zig / HTML / XML / HCL / CSS / Lua / SAS）はoptionalDependenciesです。ここが重要で、任意依存の文法は読み込みに失敗しても例外を投げず、nullを返して静かに欠落します。リポジトリのコメント自身がその設計を明言しています。

A grammar that can’t load on this platform (e.g. tree-sitter-sas has no win32 prebuild) is simply absent; its files go unparsed.

つまり、対応言語表に載っていても、プラットフォームにビルド済みバイナリが無ければ、そのファイルはエラーも警告も出さずに地図から消えます。配布版（darwin-arm64）のビルド済みバイナリを確認したところ、13個は6プラットフォーム分揃っていた一方、tree-sitter-sasだけは darwin-arm64 / darwin-x64 / linux-x64 の3つしかなく、Windowsとlinux-arm64には存在しませんでした。SASを扱う環境は限られるとはいえ、「26言語対応」の26は環境によって目減りする数字だと理解しておく必要があります。

なお、当初は「クエリが空の7形式＝シンボルは取れない」と考えていましたが、これは誤りでした。YAML・JSON・TOML・SQL・Dockerfile・Markdown・LaTeXにはtree-sitterを使わない独自パーサがindex.tsに実装されており、実測でもconfig_entry（YAML/JSON/TOML/Dockerfile）・table（SQL）・sectionとheading（Markdown）・moduleとenvironment（LaTeX）を実際に生成しました。

Kotlinがグラフに載らない——クエリ非互換を特定する

対応言語の裏を取るため、26言語＋7形式を1ファイルずつ含む33ファイルの検証リポジトリを作り、すべて同じ形（2つの関数が互いを呼ぶ）で書いて取り込みました。結果は164ノード・239エッジ。ほとんどの言語は期待通りにシンボルを出しましたが、Kotlinだけが0件でした。

最初は書き方の問題を疑いました。式ボディ（fun f(x: Int): Int = ...）が拾われないのかと考え、クラス定義＋ブロックボディ＋トップレベル関数という最も一般的な形に書き直しましたが、結果は変わらず0件でした。

切り分けると、原因は文法でもパースでもありませんでした。tree-sitter-kotlinの読み込みは成功し、検証ファイルもhasError: falseで正しくパースされ、class_declarationとfunction_declarationのノードが得られます。落ちていたのはクエリのコンパイルでした。

Query error of type TSQueryErrorNodeType

同梱のKOTLIN_QUERIESを、同梱のtree-sitter-kotlinに対してコンパイルすると、存在しないノード型を参照しているというエラーで失敗します。クエリが組み立てられない以上、.ktファイルからは何も抽出されません。同じ手順でHTML・XML・Swift・Zig・HCL・Haskellのクエリを試すと、いずれも正常にコンパイルできたため、これはKotlin固有の不整合です。

ix ingest . --force
ix inventory --kind class  | grep -i "\.kt$"
ix inventory --kind function | grep -i "\.kt$"

なおHTMLは、クエリ自体は正常でも抽出対象が<script src>によるimportのみで、定義シンボルを持ちません。これは不具合ではなく設計上の割り切りです。XMLは最小構成の検証ファイルでは何も拾いませんでしたが、より複雑な構造なら拾う可能性があり、ここでは不具合とは判定していません。

Node 22.13.1で無言のSIGSEGV——バージョン境界の実測

検証で最初にぶつかったのは、Kotlinよりもっと手前の問題でした。ix ingest .が何も出力せずに終了コード139（SIGSEGV）で落ちる。stdoutもstderrも完全に空で、ix statsは0ノードのまま。原因を示す手がかりがゼロです。

--langで言語を1つずつ絞っても全部139だったため、特定の文法ではなく共通部分だと当たりをつけ、ネイティブモジュールの読み込みだけを切り出しました。require('tree-sitter')——これだけでクラッシュします。Ixのコードは1行も動いていません。

この症状は既知でした。Issue #308「[bug] Segmentation Fault on map」が2026-07-08から立っており、メンテナが2026-08-09に原因を公表しています。要旨は「Node 20が、Node 22でビルドされたネイティブアドオンを読み込んで落ちている」「配布バイナリはNode 22.14でビルドしている」「v0.9.0で下限をNode 22に引き上げた」というものでした。

ところが今回落ちたのはv0.9.0であり、Nodeは22.13.1です。修正後のバージョンで、修正後の要件（Node 22以上）を満たしているのに落ちました。そこで同一マシン・同一のix v0.9.0のまま、Nodeだけを差し替えて測り直しました。

境界は22.14.0でした。これは公式説明にある「配布バイナリのビルドに使ったNode」と一致します。厄介なのは、22.13.1と22.14.0が同じABI 127である点です。ネイティブアドオンの互換性チェックに使われる番号が同じなので、メジャーバージョンによる下限チェックでは検出できません。実際、インストーラはNODE_MIN_MAJOR=22、package.jsonはengines.node >= 22.0.0、READMEは「Node.js 22 or newer」と、3か所すべてが22を要件としています。つまり22.13.1は、公式が示す要件を3か所とも満たしたうえで無言のSIGSEGVに当たります。今回実測したのは22.13.1と22.14.0の2点なので、22.0〜22.12がどうなるかは確認していませんが、少なくとも「Node 22なら大丈夫」とは言えない状態です。

node --version                                   # 22.14.0 未満なら要注意
cd ~/.ix/cli/core-ingestion
node -e "require('tree-sitter'); console.log('OK')"
echo "exit=$?"                                    # 139 ならネイティブモジュールの読み込み失敗

常駐コストと「トークン削減率」の出どころ

グラフをデータベースに置く設計の代償は、素直にマシンリソースとして現れます。インストーラが~/.ix/backend/docker-compose.ymlへ書き出す構成は、リポジトリのdocker-compose.standalone.ymlとバイト単位で一致していました。中身はArangoDBとmemory-layerの2サービスです。

イメージ合計976MB、アイドル時の常駐RAMは約670MiB。restart: unless-stoppedが指定されているため、明示的に止めない限りDocker起動時に一緒に上がってきます。ただしix docker stopで停止できるので、避けられない常駐ではありません。

セキュリティ面では、ArangoDBがARANGO_NO_AUTH: "1"（認証なし）で起動している点に触れておきます。ただし公平に書くと、両サービスとも127.0.0.1に明示的にバインドされており、ネットワークへ露出はしません。docs/prerequisites.mdもポートとlocalhost限定であることを明記しています。正確な影響範囲は「同じマシン上のプロセスなら、資格情報なしでコードベースのグラフ全体を読み書きできる」ということです。共有マシンや、信頼できないコードを走らせる開発機では意識しておく価値があります。

そしてもう1つ、READMEの目立つ主張——「30-99.7% fewer tokens」の出どころです。Ixにはix savingsというコマンドがあり、削減量を表示します。

savings.tsを読むと、CLIがしているのはGET /v1/savingsの結果を整形することだけで、計算はしていません。実際にAPIを直接叩くと、次の値が返りました。

{"commandCount":43,"tokensSaved":161176,"naiveTokens":184782,"actualTokens":23606}

naiveTokens（生のファイルを読ませていたら消費したはずの量）とactualTokensの差が削減量で、この場合87.2%です。このnaiveTokensはソース非公開のmemory-layerが算出した反実仮想であり、公開コードから検証はできません。

さらに注意すべきは、この43コマンドがLLMを1度も経由していないことです。筆者が手でCLIを叩いただけのセッションに対して、Ixは「$5.32節約」「322.4mLの水を節約」と表示しました。金額は入力70%・出力30%という固定按分で、水はWATER_ML_PER_1K_TOKENS = 2という出典の記載がない定数で算出されています。

類似ツールとの比較——コードベース地図の選び方

コードベースをグラフ化してAIに渡すツールは既に複数あります。Ixの位置づけを、当サイトで扱ってきたツールと並べて整理します。

Ixの特徴は「サーバを立てる側に振り切っている」ことです。ファイル型のツールが持ち回りやすさを取るのに対し、Ixはデータベースを常駐させる代わりに、リビジョン管理・ワークスペース分離・差分パッチといったデータベース的な機能を得ています。実際、リポジトリのIssueには「ワークスペース間でノードIDが衝突する」「backend更新後に再マップを促す」といった、DBを持つプロダクト特有の課題と修正が並んでいます。

alpha表記の通り、まだ荒さの残るプロジェクトです。ただし今回見つけた問題の扱い方——Issue #308でメンテナが「Both of you were on Node 20」「That is our bug, not anything about your setup」と原因を明示し、再現手順つきで公表している姿勢——は、この種の若いツールとしては信頼できる部類だと感じました。Node 22.13.1の件は、その修正がもう一歩届いていない箇所です。導入を検討するなら、まずnode --versionを確認し、主要言語が必須依存側の12言語に入っているかを見るところから始めるのが確実です。

参照ソース

・ix-infrastructure/Ix（公式リポジトリ・README） — プロジェクトの説明・対応言語一覧・インストール手順
・core-ingestion/src/index.ts — 文法ローダの実装と、任意依存が無言で欠落する設計についてのコメント
・docker-compose.standalone.yml — ArangoDBとmemory-layerの構成・バインド設定
・Issue #308「[bug] Segmentation Fault on map」 — SIGSEGVの原因究明とNode下限引き上げの経緯
・CONTRIBUTING.md — memory-layerが別の非公開リポジトリにあることの記載