- コーディングエージェントが「これはどう動くの?」のような構造的な質問に答えるとき、通常は grep → ファイルを開く → import を追跡、を何十回も繰り返してトークンを消費する
- @ttsc/graph は、TypeScript コンパイラがすでに解釈済みのコードグラフ(何が何を呼び出し/依存しているか)を MCP としてエージェントに渡し、ファイルを掘り返す代わりにグラフから直接答えさせる
- 設計の中核は2つ
- インデックスのみを返す – ソース本文は絶対に渡さず、名前・エッジ・シグネチャ・
file:linespan のみを返す → 応答サイズがリポジトリ規模に依存せず、トークンが膨らまない - Chain-of-Thought を強制 – 単一ツールの入力が型スキーマなので、エージェントは
question → draft → reviewを埋めてからでないとリクエストできない。typia がスキーマ+バリデータにコンパイルされ、「推論をスキップ」したものを呼び出し境界で拒否する
- インデックスのみを返す – ソース本文は絶対に渡さず、名前・エッジ・シグネチャ・
- 結果: open question 基準でトークンを約10倍削減し、回答品質は同等(8つのリポジトリ × 4つのモデル、保守的な中央値)
- なぜコンパイラなのか: tree-sitter のようなヒューリスティックなパーサーでは、tsconfig paths エイリアス・モノレポの相互参照・シンボリックリンク・re-export チェーンを解決できない。実際のモジュール解決を完了したコンパイラでなければ正確性が得られず、信頼できない → エージェントが確信して停止できる
- 先行例との比較: codegraph / codebase-memory-mcp / serena も同じアイデアを先に出していたが、open question ではトークンが減らないか、むしろ baseline より多く使う(著者ベンチ、zod 基準で3ツールとも +22〜27%)
- 限界: TypeScript 専用(広さより深さ)、TypeScript v7(Go ランタイム、現在 RC)が必要。4行でインストール
まだコメントはありません。