AI駆動開発でトークンを浪費しない技術: なぜ我々はtree-sitterでリポジトリを圧縮するのか？

AI駆動開発（AIDD: AI-Driven Development）が日常化した今、エンジニアが最も頻繁に直面する壁が**「コンテキストウィンドウの制限とトークンの浪費」**です。

ChatGPT、Claude、Cursor、Aider などのAIに「この機能を追加して」「このバグを直して」と依頼する際、多くの人が以下のどちらかの悪手を打っています。

1. ディレクトリ構造だけをコピペする: ファイル名しか分からないため、AIは「どのファイルに何の関数があるか」を推測（当てずっぽう）で回答し、存在しないメソッドを呼び出す。
2. 関連しそうなコードを片っ端からコピペする: 関数本体の何千行もの生ロジックでコンテキストが埋まり、トークン課金が跳ね上がる上、AIが肝心の指示を見失って幻覚（ハルシネーション）を起こす。

---

1. 解決策: 「生コード」ではなく「AST（抽象構文木）構造」を渡す

人間の熟練エンジニアが他人のリポジトリを初めて読むとき、すべてのファイルの全行を最初から読み込む人はいません。 まず**「クラス一覧」「関数の型シグネチャ」「引数と戻り値」「ドックストリング」**に目を通し、全体の責任境界を頭の中にマップとして構築してから、必要な箇所だけを精読します。

これをAIに対しても行うのが、ProjectCodeMap のアプローチです。

graph LR
    Code[生コード 10,000行<br/>(約 40,000 トークン)] -->|tree-sitter AST解析| Filter[シグネチャ & ドックストリング抽出]
    Filter -->|XML構造化出力| Output[最適化マップ<br/>(約 6,000 トークン: 85%削減)]
    Output -->|ワンショット注入| LLM[Claude 3.7 / GPT-4 / Cursor]

---

2. なぜ XML 形式が出力として優れているのか？

フロンティアLLM（特に Claude 系）は、構造化データを理解する際に XMLタグ（<file path="...">）を最も正確にパース します。

Markdownのインデントだけだと、ファイルが深くなった際にAIが階層構造を見失うリスクがありますが、明確な閉じタグを持つXMLでシグネチャを渡すことで、AIは「リポジトリ全体の設計図」を完璧に記憶した状態でコード生成を開始できます。

---

3. ワンライナーで今すぐ試す

インストール不要で、プロジェクトルートで以下のコマンドを叩くだけで即座に出力されます。

# uvx で即座に実行
uvx project-code-map --format xml > context.xml

生成された context.xml を AI チャットや Cursor のルールに設定するだけで、AIの回答精度が一段上のレベルに進化します。

詳細な機能と仕様は ProjectCodeMap 製品ページ をご覧ください。