目次

概要
アーキテクチャ方針
共通コンポーネント
解析パターン
統合フロー
データモデル
このアーキテクチャの利点
実装ガイド

1. 概要

1.1 目的

ソースコード構造解析における複数のアプローチ（LSPベース、ASTベース、正規表現ベース）を統合し、以下を実現する：

多言語対応: 20+言語で基本的な構造解析
高精度解析: TypeScript/JavaScriptなど特定言語で完全な型情報・依存関係・呼び出しグラフ
統一インターフェース: 解析パターンに関わらず同じAPIで利用可能
高速化: キャッシュ戦略で重複解析を削減
段階的フォールバック: 高精度解析→通常解析→最小限解析の3段階

1.2 設計原則

原則	説明
統一性	全ての解析パターンで同じデータモデルを出力
段階性	言語・ファイルサイズ・要件に応じて解析精度を選択
共通化	キャッシュ、LSP通信、シンボル正規化を共通コンポーネント化
拡張性	新しい言語・解析手法を追加しやすい設計
効率性	不要な解析をスキップ、結果を再利用

2. アーキテクチャ方針

2.1 全体構造図

2.2 レイヤー構造

3. 共通コンポーネント

両方の解析パターンで共有する基盤機能。

3.1 統合キャッシュマネージャー

責務: 解析結果の保存・取得・無効化

概要:

ファイルのMD5ハッシュをキーとして解析結果をキャッシュする。メモリ内キャッシュとディスクキャッシュの2層構造により、頻繁にアクセスされるファイルは高速に取得でき、大量のファイルも永続的に保存できる。ファイルが変更された場合はハッシュ値が変わるため自動的にキャッシュが無効化され、常に最新の解析結果が提供される。また、TTL（生存時間）により一定期間アクセスされないキャッシュは自動的に削除される。

特徴:

✅ 2段階キャッシュ: メモリ（高速） + ディスク（永続）
✅ ハッシュ検証: ファイル変更を自動検出
✅ TTL管理: 古いキャッシュを自動削除
✅ 解析モード対応: 高精度/通常/最小限で別々にキャッシュ

3.2 LSPクライアントプール

責務: 複数言語のLSPクライアントを管理

概要:

20以上の言語に対応したLSPクライアントを一元管理する。各言語用のLSPサーバーを必要に応じて起動し、プロセスとして常駐させる。クライアント数の上限を設定してリソース消費を制御し、同じファイルへの複数回のアクセスは同じセッションを再利用することで効率化する。LSPサーバーがクラッシュした場合は自動的に再起動し、ユーザーには透過的にサービスを継続する。

特徴:

✅ 多言語対応: 20+言語のLSPを統一管理
✅ 自動再起動: クラッシュ時の自動復旧
✅ リソース管理: クライアント数の上限制御
✅ セッション再利用: 同じファイルへの複数アクセスを効率化

3.3 シンボル正規化エンジン

責務: 異なるソースからのシンボル情報を統一形式に変換

概要:

LSP、ts-morph、正規表現など、異なる解析ソースから得られたシンボル情報を統一データモデル（UnifiedSymbol）に変換する。各ソースの特性に応じて情報を抽出し、複数ソースから得られた情報をマージして最も完全な情報を構築する。TypeScriptの場合は型情報や型パラメータを詳細に抽出し、シンボル間の親子関係を自動的に構築してツリー構造を形成する。

特徴:

✅ 多ソース対応: LSP、ts-morph、正規表現を統一
✅ 情報補完: 複数ソースをマージして情報を充実
✅ 型情報抽出: TypeScriptの型情報を詳細に抽出
✅ 親子関係構築: シンボルツリーを自動構築

3.4 シンボルインデックス

責務: 解析結果の高速検索・フィルタリング

概要:

解析されたシンボル情報をインデックス化し、名前・種類・ファイルパスなど複数の軸で高速に検索できるようにする。シンボル間の呼び出し関係（caller/callee）を双方向に管理し、「このメソッドを呼び出している箇所」や「このメソッドが呼び出している関数」を即座に取得できる。また、複数階層にわたる呼び出しチェーンを追跡し、依存関係の全体像を把握できる。

特徴:

✅ 高速検索: インデックスベースの検索
✅ 多軸フィルタ: 名前、種類、ファイルパスで絞り込み
✅ 呼び出しグラフ: 双方向の関係性を管理
✅ チェーン検索: 複数階層の呼び出し関係を追跡

4. 解析パターン

4.1 高精度解析パターン（TypeScript/JavaScript専用）

適用条件:

ファイル拡張子: .ts, .tsx, .js, .jsx
ファイルサイズ: < 1MB（設定可能）
ユーザー要求: 完全な型情報・依存関係が必要

処理フロー:

解析手順:

AST解析: ts-morphを使用してTypeScript/JavaScriptのASTを構築し、完全な型情報を抽出
LSP補完: TypeScript LSPから追加のシンボル情報を取得し、ASTで不足している情報を補完
正規表現フォールバック: ASTやLSPで取得できなかったシンボルを正規表現で抽出
情報統合: 3つのソースから得られた情報をマージし、最も完全なシンボル情報を構築
呼び出しグラフ構築: 関数呼び出しを解析して双方向の依存関係グラフを作成
セキュリティ境界検出: 認証・DB・IOなどのキーワードから重要な境界を識別
メタデータ抽出: import/export、async/await、例外処理などの情報を収集

4.2 通常解析パターン（多言語対応）

適用条件:

TypeScript/JavaScript以外の全言語
ファイルサイズ: 制限なし
ユーザー要求: 基本的なシンボル情報で十分

処理フロー:

解析手順:

LSP起動: 対象言語のLanguage Serverをプールから取得または新規起動
シンボル取得: LSPのリクエストでファイル内の全シンボルを取得
情報正規化: LSPの言語固有のシンボル形式を統一データモデルに変換
参照解析: 必要に応じて各シンボルの参照箇所を取得
基本メタデータ: シンボルの位置、種類、名前などの基本情報を収集

4.3 最小限解析パターン（フォールバック）

適用条件:

LSPが利用できない言語
構文エラーがあるファイル
非コードファイル（設定ファイルなど）

処理フロー:

解析手順:

パターンマッチング: 言語に応じた正規表現パターンで関数・クラス・変数の定義を検索
行単位解析: ファイルを行ごとに走査し、定義パターンにマッチする箇所を抽出
簡易情報構築: シンボル名、種類、開始行などの最小限の情報を構築
ベストエフォート: エラーがあっても解析を継続し、取得できた情報だけを返す

5. 統合フロー

5.1 全体フロー図

5.2 解析ルーターの実装

解析ルーターは、入力ファイルに対して最適な解析パターンを選択する中央制御機能を提供します。

判定ロジック:

キャッシュチェック: ファイルのMD5ハッシュでキャッシュを検索し、ヒットすれば即座に返却
言語判定: ファイル拡張子とMIMEタイプから言語を識別
パターン選択:
- TypeScript/JavaScriptで1MB未満 → 高精度解析パターン
- LSP対応言語 → 通常解析パターン
- その他 → 最小限解析パターン（正規表現）
フォールバック処理: 上位パターンでエラーが発生した場合は下位パターンに自動的にフォールバック

6. データモデル

6.1 統一シンボル形式（UnifiedSymbol）

全ての解析パターンが出力する統一データモデル。LSP、AST、正規表現のいずれから取得されたシンボルも、このモデルに変換されます。

主要フィールド:

識別情報: 名前、種類（class/method/function/variable等）、完全修飾名
位置情報: ファイルパス、開始行・列、終了行・列、インデントレベル
階層情報: 親シンボル、子シンボルのリスト、名前パス（階層的な識別子）
型情報: 型名、型パラメータ、戻り値型（TypeScript/JavaScript等）
メタデータ: 可視性、修飾子（static/async等）、ドキュメント文字列
関係情報: 呼び出し先（callees）、呼び出し元（callers）、参照箇所

6.2 メタデータ構造

高精度解析で取得される追加情報。TypeScript/JavaScriptの解析で特に詳細な情報が利用可能です。

メタデータの内容:

依存関係: import文、export文、モジュール依存
実行特性: 非同期関数、ジェネレータ、例外処理
セキュリティ境界: 認証、データベースアクセス、ファイルI/O、ネットワーク通信の検出
呼び出しグラフ: 関数・メソッド間の双方向の依存関係マップ
デコレータ: TypeScriptのデコレータ、アノテーション情報

7. このアーキテクチャの利点

このアーキテクチャは、AIエージェントとLLMベースのコーディング支援ツールに3つの主要な利点を提供します：

コンテキストウィンドウの大幅な削減：トークン効率の最大化
AIエージェントの精度向上：Language Server Protocolによる意味理解
プロジェクト知識の永続化：セッションをまたいだ継続性

7.1 コンテキストウィンドウの大幅な削減

7.1.1 削減の原理

削減の4つの柱

シンボル単位の取得: ファイル全体ではなく、必要な関数・クラスだけを取得
メタデータ検索: コード本体を読まずにメタデータで絞り込み
呼び出しグラフ活用: 事前構築されたグラフから即座に関連コードを特定
段階的情報取得: 概要から詳細へ、必要に応じて追加取得

7.1.2 シンボルレベルのピンポイント操作

従来のコーディングエージェント：

ファイル全体を読み込んで正規表現や文字列検索で目的の箇所を探す必要があります。大きなファイルでは数万トークンを消費し、さらにLLMが正確な位置を特定するのに追加のトークンを要します。

このアーキテクチャ：

シンボルインデックスを使用して、名前や種類で直接目的のシンボルを検索できます。ファイル全体ではなく、必要なシンボル（関数やクラス）だけをピンポイントで取得できるため、トークン消費を大幅に削減できます

具体例：10,000行のTypeScriptファイルで特定のメソッドを編集

従来の方法：ファイル全体を読み込む → 約15,000トークン
このアーキテクチャ：
1. ファイルのシンボル一覧取得 → 約500トークン
2. 目的のメソッドだけ取得 → 約100トークン
3. 編集実行

節約率：約96% (600トークン vs 15,000トークン)

7.1.3 削減効果の定量評価

典型的な削減率

操作	従来のトークン数	このアーキテクチャ	削減率
関数1つの実装確認	15,000	200	98.7%
依存関係の調査	500,000	1,000	99.8%
呼び出し元の検索	500,000	500	99.9%
クラス概要の把握	50,000	800	98.4%
セキュリティ監査	500,000	2,000	99.6%

総合削減効果: 平均95-99%のトークン削減

7.1.4 ユースケース1: AIエージェントによるバグ修正

シナリオ

ユーザーから「nullチェックが抜けているバグを修正して」というリクエスト

従来のアプローチ

プロジェクト内の全ファイルを検索
検索対象の文字列を含む全ファイルを取得
該当する50個のファイル全体をLLMに送信（各10,000トークン）

トークン消費: 500,000トークン
問題点:

コンテキストウィンドウを圧迫
無関係なコードも含まれノイズが多い
処理が遅い、コストが高い

このアーキテクチャでのアプローチ

find_symbol(name="getUser", kind="function") でシンボルを検索
該当する1つの関数定義だけを取得（250トークン）
LLMに送信して修正実行

トークン消費: 250トークン
削減率: 99.95%

削減の仕組み図

7.1.5 ユースケース2: コードレビューでのセキュリティチェック

シナリオ

Pull Requestで、認証・DB操作・ファイルIOなどセキュリティ境界のあるコードをレビュー

従来のアプローチ

Pull Request の全変更ファイルを取得
150個のファイル全体を読み込む（各1,000トークン）
LLMに全コードを送信してセキュリティリスクを分析

トークン消費: 150,000トークン

このアーキテクチャでのアプローチ

セキュリティ境界のシンボルのみ抽出
該当する25個のシンボルだけを取得（各100トークン）
LLMに送信してセキュリティレビュー実行

トークン消費: 2,500トークン
削減率: 98.3%

7.1.6 ユースケース3: 影響範囲調査

シナリオ

Databaseクラスのメソッドシグネチャを変更する際、影響を受けるコードを全て特定

従来のアプローチ

プロジェクト全体をgrepでDatabaseを検索
該当する500個のファイル全体を読み込む（各1,000トークン）
LLMに全コードを送信して影響箇所を特定

トークン消費: 500,000トークン

このアーキテクチャでのアプローチ

find_symbol(name_path="/Database/*") でDatabaseクラスのメソッドを取得
呼び出しグラフからcallersを辿り、影響を受けるシンボルをリスト化
影響箇所のシンボル名のみをLLMに送信（コード本体は不要）

トークン消費: 700トークン
削減率: 99.86%

呼び出しグラフの活用図

重要: 呼び出しグラフは事前構築済みのため、検索は瞬時でトークン消費ゼロ

7.1.7 ユースケース4: 段階的な情報取得

シナリオ

新しいモジュールの理解（UserServiceクラス）

段階的アプローチ

概要取得: クラスのメソッド一覧とシグネチャを取得（300トークン）
詳細確認: 気になるメソッド1つだけ取得（200トークン）
依存関係: 依存関係を確認（100トークン）

削減効果

フェーズ	従来	このアーキテクチャ	説明
1. 概要	15,000	300	ファイル全体 vs シグネチャのみ
2. 詳細	15,000	200	全メソッド vs 1メソッドのみ
3. 依存	500,000	100	全プロジェクト vs メタデータのみ
合計	530,000	600	99.89%削減

7.1.8 実装パターン: コンテキスト最適化レイヤー

AIエージェントに組み込む際の推奨パターン

AIエージェントにこのアーキテクチャを組み込む際は、以下のレイヤーパターンを推奨します：

検索レイヤー: シンボルインデックスでの事前検索・フィルタリング
取得レイヤー: 必要最小限のシンボルだけを取得
キャッシュレイヤー: 取得済みシンボルの再利用
監視レイヤー: トークン消費量の測定とレポート

7.1.9 削減効果の測定

トークン削減効果を測定するには、以下の指標を追跡します：

リクエストごとの入力トークン数（before/after比較）
シンボル取得数とファイル読み込み数の比較
キャッシュヒット率
平均削減率の計算

出力例:
トークン削減効果を測定するには、以下の指標を追跡します：

リクエストごとの入力トークン数（before/after比較）
シンボル取得数とファイル読み込み数の比較
キャッシュヒット率
平均削減率の計算

7.1.10 ベストプラクティス

1. インデックス検索を優先

Request #1: Bug fix in getUser function
  - Traditional: 500,000 tokens
  - This architecture: 250 tokens
  - Reduction: 99.95%

Average reduction rate: 98.7%

2. メタデータで事前フィルタリング

推奨: インデックス検索

インデックスを使用することで、ファイルを開かずに目的のシンボルを特定できます。

非推奨: grep や全ファイル走査

ファイル内容を読む必要があり、大量のトークンを消費します。

3. 段階的に情報取得

推奨: メタデータ検索

メタデータ（async、型情報、セキュリティ境界など）で事前に絞り込み、コード本体は必要なものだけ取得します。

非推奨: 全コードを取得してからLLMでフィルタリング

コンテキストウィンドウの無駄遣いになります。

4. 呼び出しグラフを活用

推奨: 概要 → 詳細の順で段階的に取得

1. get_overview() - シンボル一覧
2. find_symbol() - 必要なシンボルのみ
3. get_related() - 関連シンボル（必要なら）

非推奨: 最初から全コード取得

必要ない情報まで含まれ、無駄が多くなります。

7.1.11 まとめ：削減の確実性

要素	削減率	確実性	理由
シンボル単位取得	90-96%	✅ 確実	必要な関数だけ取得するため
メタデータ検索	99%+	✅ 確実	コード本体を読まないため
呼び出しグラフ	99%+	✅ 確実	事前構築済みグラフから取得
段階的取得	80-95%	✅ 確実	不要な情報を取得しないため
キャッシュ活用	100%	✅ 確実	2回目以降は即座に取得

総合削減効果: 平均95-99%のトークン削減が確実に実現

このアーキテクチャを採用することで、LLMのコンテキストウィンドウを効率的に活用し、以下を実現できます：

✅ より多くのタスクを1回のリクエストで処理
✅ より大きなプロジェクトを扱える
✅ APIコストの大幅削減
✅ 応答速度の向上
✅ より正確な回答（ノイズが少ない）

7.2 AIエージェントの精度向上

7.2.1 Language Server Protocol (LSP) による意味理解

テキストベース検索の限界：
従来: 正規表現やgrepで検索

grep -r "authenticate" src/  # ノイズが多い

このアーキテクチャ: LSPの意味理解

find_symbol(name="authenticate", kind=SymbolKind.Method)
# 正確なメソッド定義のみ取得

シンボルベース検索の優位性：
従来: 正規表現やgrepで検索

grep -r "authenticate" src/  # ノイズが多い

このアーキテクチャ: LSPの意味理解

find_symbol(name="authenticate", kind=SymbolKind.Method)
# 正確なメソッド定義のみ取得

7.2.2 名前パスマッチングによる精密な検索

シンボルの階層構造を活用した検索パターン：

名前パスを使用することで、階層的にシンボルを特定できます：

UserServiceクラスのgetUserメソッド
UserServiceの全メソッド
任意のクラスのgetUserメソッド
validateで始まる全シンボル

これにより、ファイルパスではなく、コードの構造に基づいて検索できます。

この仕組みにより、以下が可能：

正確なターゲティング: 意図したシンボルのみを取得
曖昧性の排除: 同名の異なるシンボルを区別
階層的な検索: クラス内のメソッド、ネストしたクラスなどを正確に指定

7.2.3 LSPによる高度な機能

Language Server Protocolが提供する主要機能：

textDocument/documentSymbol: ファイル内のシンボル一覧取得
textDocument/definition: シンボル定義へのジャンプ
textDocument/references: シンボル参照検索
textDocument/hover: シンボル情報表示（型情報、ドキュメント）
textDocument/didChange: ドキュメント変更通知（同期保持）

これらにより、IDE並みの高精度な操作が可能になります。

7.2.4 参照検索による影響範囲の正確な把握

言語サーバーの静的解析を活用：

LSPは編集内容をリアルタイムで追跡し、変更された箇所だけを再解析します。これにより：

ファイル全体の再読み込みが不要
シンボル情報が常に最新
編集中もシンボル検索が可能
エラーや警告の即座な取得

利点：

コード全体をgrepする必要なし
文字列一致ではなく意味的な参照を検出
コメント内の記述などの誤検出を回避

7.2.5 編集の精度：インデント保持とシンボル単位の置換

従来の文字列置換の問題：
シンボル単位で編集できるため、以下が可能になります：

インデントを自動保持（手動計算不要）
シンボルの境界を正確に認識
複数箇所の一括置換が安全
コメントやドキュメントも含めて置換

シンボルベース編集の利点：
シンボル単位で編集できるため、以下が可能になります：

インデントを自動保持（手動計算不要）
シンボルの境界を正確に認識
複数箇所の一括置換が安全
コメントやドキュメントも含めて置換

編集処理の流れ：

シンボルの位置を言語サーバーから取得
行番号とインデントを解析
適切なインデントで新しいコードを挿入/置換
言語サーバーに変更を通知（textDocument/didChange）

7.2.6 行番号ベース編集からの脱却

行番号ベース編集が失敗する理由：

LLMは行番号のカウントが不正確
編集後に行番号がずれるが、LLMがそれを理解できない
複数回の編集で累積的にずれが大きくなる

シンボル名ベース編集への転換 = 精度が飛躍的に向上：

シンボル名は編集後も変わらない（リネーム時は明示的）
言語サーバーが常に最新の位置を把握
複数ファイルにまたがる編集も正確

7.2.7 20以上の言語に対応した統一インターフェース

言語サーバー抽象化レイヤーにより、以下が可能：

実装の詳細は、各コンポーネントの「概要」セクションと「特徴」リストを参照してください。

利点：

すべての言語で同じツール・同じ操作
一貫した高精度な編集が可能
新しい言語への対応も容易

7.3 プロジェクト知識の永続化

7.3.1 Markdown形式の人間にも読めるメモリ

メモリシステムの設計哲学：

人間可読: Markdown形式で保存
編集可能: テキストエディタで直接編集可能
バージョン管理: Gitで管理可能
プロジェクト固有: .project_name/memories/ に保存

メモリの保存先：
プロジェクトの知識をMarkdown形式で永続化することで：

人間が読める形式で知識を保存
AIエージェントがセッションをまたいで知識を再利用
チーム全体で知識を共有可能
バージョン管理システムで追跡可能

7.3.2 自動オンボーディングプロセス

プロジェクトを初めて解析する際、以下の情報を自動収集：

オンボーディングフロー詳細：

プロジェクト構造分析
- ディレクトリツリー取得
- 重要ファイル特定（README, package.json等）
- ソースファイル数・種類カウント
重要ファイル読み取り
- README.md
- package.json / requirements.txt / Cargo.toml
- .gitignore
- 主要設定ファイル
エントリーポイント推定
- main.py, index.ts, main.rs等の検出
- エントリーファイルのシンボル概要取得
テスト方法推定
- テストディレクトリ検出
- テストフレームワーク特定（pytest, jest等）
- テストコマンド推定
ビルド方法推定
- ビルドツール特定（cargo, npm, gradle等）
- ビルドコマンド推定
アーキテクチャ理解
- 主要モジュール/パッケージ特定
- 依存関係分析
- デザインパターン推定
メモリ作成
- 上記情報をMarkdownファイルとして保存
- 構造化された形式で記録

7.3.3 セッションをまたいだ知識の活用

シナリオ：長期的なプロジェクト作業

Day 1:
実装の詳細は、各コンポーネントの「概要」セクションと「特徴」リストを参照してください。

Day 2 (新しいセッション):
実装の詳細は、各コンポーネントの「概要」セクションと「特徴」リストを参照してください。

利点：

毎回プロジェクト全体を読み直す必要なし
過去のセッションで得た知識を活用
文脈を理解した上での作業が可能

7.3.4 コンテキスト枯渇時の継続性

長いタスクでコンテキストが一杯になった場合の対処：

コンテキストウィンドウが枯渇する前に：

現在のタスクの進捗状況をメモリに書き込み
重要な設計決定や課題をメモリに記録
次のセッションで必要な情報を整理

新しいセッションでは、メモリから情報を読み取り、タスクを継続できます。

利点：

トークン制限を回避
文脈を失わずに作業継続
複数日にわたる作業も可能
サマリー化による情報損失を最小限に

7.3.5 メモリの実際の活用例

実装の詳細は、各コンポーネントの「概要」セクションと「特徴」リストを参照してください。

この知識があることで：

新しい機能追加時に一貫性のあるコードを生成
プロジェクトの規約を遵守
毎回同じ説明を繰り返す必要なし

7.3.6 メモリシステムの種類と用途

メモリの種類	内容	用途
architecture.md	アーキテクチャ概要	全体構造の理解
project_structure.md	プロジェクト構造	ファイル・ディレクトリ配置の把握
how_to_test.md	テスト実行方法	テストコマンド、フレームワーク
how_to_build.md	ビルド手順	ビルドコマンド、依存関係
coding_conventions.md	コーディング規約	スタイル、命名規則
key_symbols.md	重要なシンボル	主要クラス・関数の一覧
task_progress.md	タスク進捗	作業の継続性確保

7.4 3つの利点の相乗効果

7.4.1 個別の利点のまとめ

コンテキストウィンドウの削減
- シンボルレベルのピンポイント操作
- 最大96%のトークン削減
- キャッシングによる高速化
- API費用の大幅削減
精度向上
- LSPによる意味理解
- シンボル名ベースの正確な編集
- クロスファイル参照の追跡
- 20以上の言語で統一された操作
知識の永続化
- Markdown形式の人間にも読めるメモリ
- 自動オンボーディング
- セッションをまたいだ文脈保持
- コンテキスト枯渇時の継続性

7.4.2 相乗効果による価値

これら3つが組み合わさることで実現される実用的価値：

大規模プロジェクトでの効率的な作業

削減: 必要な部分だけを読み取る → トークン節約
精度: 正確な場所を編集 → 試行錯誤の削減
永続化: プロジェクト構造を理解した上で作業 → 一貫性確保

トークン制限への対処

削減: 各操作でのトークン使用量を最小化
精度: 無駄な試行錯誤を削減
永続化: メモリで文脈を保存して新セッションで継続

長期的なプロジェクトでの一貫性

削減: 毎回ファイル全体を読み直さない
精度: 意図した変更だけを実施
永続化: プロジェクトの規約やパターンを記憶

自律的な作業

削減: 効率的な情報収集
精度: 高い成功率の編集
永続化: 過去の学習を活用

7.4.3 実用的な価値

このアーキテクチャにより、以下が実現：

主要な強み：

セマンティックコード理解: シンボルレベルでのコード操作
LLM・フレームワーク非依存: どんな環境でも利用可能
トークン効率: 必要な部分だけを読み取り、コスト削減
20+言語対応: 幅広いプロジェクトで使用可能
柔軟な統合: API、ライブラリとして利用可能

推奨ユースケース：

大規模コードベースの探索: シンボルベース検索で効率的
精密なコード編集: インデント保持、シンボル単位の操作
プロジェクトオンボーディング: 自動的な理解とドキュメント化
コスト削減: トークン効率の向上により API コスト削減
長期プロジェクト: 知識の永続化により継続的な作業が可能

8. 実装ガイド

8.1 プロジェクト構造

新しいプロジェクトに初めてアクセスした際、自動的に：

プロジェクト構造を解析
主要なファイルとディレクトリを識別
アーキテクチャパターンを検出
テスト方法やビルド方法を抽出
これらをメモリとして保存

以降のセッションでこの情報を再利用できます。

8.2 設定ファイル例

設定ファイル（YAML）では、言語ごとのLSPサーバー設定、キャッシュディレクトリ、タイムアウト値などを定義します。

8.3 使用例

実装の詳細は、各コンポーネントの「概要」セクションと「特徴」リストを参照してください。

8. まとめ

8.4 統合アーキテクチャの利点

利点	詳細
最適な精度	言語・ファイルサイズ・要件に応じて最適な解析パターンを自動選択
広範な言語対応	TypeScript/JavaScriptで高精度、他20+言語で基本解析
高速化	2段階キャッシュ（メモリ+ディスク）で重複解析を削減
統一インターフェース	解析パターンに関わらず同じAPIで利用可能
段階的フォールバック	解析失敗時に自動的に低精度モードで再試行
拡張性	新しい言語・解析手法を追加しやすい設計

8.5 各解析パターンの使い分け

パターン	適用言語	取得情報	パフォーマンス	推奨用途
高精度	TS/JS	シグネチャ、型、imports/exports、callees/callers、async、例外、セキュリティ	中速（AST解析）	TypeScript/JavaScriptプロジェクトのフル解析
通常	20+言語	シンボル名、種類、位置、（オプション）参照	高速（LSPのみ）	多言語プロジェクトの基本解析
最小限	全言語	シンボル名、おおよその位置	最速（正規表現）	LSP非対応言語、構文エラーファイル

8.6 今後の拡張可能性

新しい高精度解析の追加:
- Python用（mypy + jedi + LSP）
- Java用（Eclipse JDT + LSP）
- Go用（go/ast + gopls）
AI支援解析:
- LLMを使った意味的なシンボル分類
- コード要約の自動生成
- セキュリティ境界の高精度検出
増分解析:
- Git diffベースの差分更新
- ファイル変更監視による自動再解析
分散解析:
- 大規模プロジェクトの並列解析
- リモートLSPサーバーの活用
解析結果の永続化:
- データベース統合（PostgreSQL, SQLite）
- JSONL形式でのエクスポート
- Vector DBへの埋め込み保存

このアーキテクチャにより、LSPベースの多言語対応とASTベースの高精度解析を統合し、最適なバランスで構造解析を実現できます。各アプリケーションは、この共通基盤の上に独自の機能を構築することができます。