前回記事からの進化点を含む、最新版 LocalForge の完全ガイドです。
RAG対応・tree-sitterシンボル抽出・依存関係グラフ・差分編集など、機能が大きく強化されました。

「どこから手を付ければいい？」という苦しみ

新しいプロジェクトにアサインされたとき、こんな経験はないでしょうか。

リポジトリをクローンして ls を叩いたら、ディレクトリが20個。
ファイル数を確認したら2,000超。
ドキュメントは半分が古く、半分が英語。

どこから読めばいいかわからず、丸一日かけてようやく「このファイルが入口っぽい」と気づく——
そういったコードオンボーディングの非効率さは、経験年数に関係なく誰もが感じる課題です。

この記事では、そんな状況を打破した 完全ローカル動作のAIコード解析ツール「LocalForge」 の最新版を紹介します。前回公開した初期バージョンからアーキテクチャを大幅に刷新し、速度・精度・使い勝手がすべて向上しました。

LocalForgeとは

LocalForgeは、Ollamaをバックエンドに使った完全ローカルのAI駆動コード解析IDEです。

クラウドAPIを一切使わないため：

APIコストがゼロ
コードが外部に送信されない（社内コード・業務ロジックも安心）
オフライン環境でも動作する

主な機能は3つのモードに集約されています。

モード	何ができるか
Generate	AIがプロジェクト構成を提案し、ファイルをゼロから生成。SEARCH/REPLACE差分編集にも対応
Resume	既存プロジェクト（外部製も可）の続行・拡張・Q&A継続
Explain	コードベースを丸ごと解析し、11セクションのレポートを生成。RAG対応Q&Aも可能

今回フォーカスするのはExplainモードです。

前回バージョンからの主な強化点

前回の記事で紹介した版から、以下の点が大きく進化しました。

1. LLMを使わないインデックス構築（速度革命）

旧版ではファイルサマリー生成にLLMを多用していました。新版では3ティア分類を導入し、LLM呼び出しをほぼゼロに削減。

Tier-0: パスとサイズだけで判定（ファイルを開かない）
  └── .lock, .json, .svg, テストファイル... → 即時確定

Tier-1: 内容を読んでヒューリスティック判定
  └── ミニファイ済み、自動生成、20行以下のファイル... → LLM不要

Tier-2: tree-sitterによるシンボル抽出
  └── 実際のソースコード → クラス・関数・インポートを構造解析
      Python/JS/TS/SQL/Go/Rust/Java... に対応

2,000ファイルでも LLMが実際に介在するのはQ&Aとレポート生成のみ という設計になっています。

2. RAG（検索拡張生成）の本格導入

sentence-transformers/all-MiniLM-L6-v2（プロセス内実行、Ollamaへのリクエスト不要）でファイルサマリーをChromaDBにベクトル化。

Q&Aでは「質問に意味的に近いファイル」を自動選別してLLMに渡すため、2,000ファイルあっても的外れな回答になりにくくなりました。RAGが使えない環境ではBM25キーワード検索に自動フォールバックします。

3. 依存関係グラフの自動解決

Python の import 文・JS/TS の import/require 文を静的解析し、ファイル間の依存関係を自動構築。Q&Aでは「このファイルが何をインポートしているか」「どこからインポートされているか」がLLMのコンテキストに含まれるようになり、回答の精度が向上しました。

4. SEARCH/REPLACE差分編集

Generateモードでは、既存ファイルの差分だけを生成・適用する方式に刷新。ファイル全体を書き直す旧方式と比べ、トークン消費が大幅に削減されました。適用失敗時は自動リトライ＆バックアップからのロールバックも行います。

5. マルチプロジェクト・ワークスペース

複数のプロジェクトを横断して参照できるワークスペース機能を追加。「このプロジェクトが依存している別リポジトリ」もQ&Aのコンテキストに含められます。

6. ドキュメントファイル対応

.pdf / .docx / .xlsx / .pptx などのオフィス文書もインデックス対象になりました。仕様書・設計書が混在するプロジェクトでも、コードと一緒に解析できます。

実際にやってみた：2,247ファイルの解析

以下の構成のプロジェクトをCPUのみ（RAM 32GB）、モデルqwen3-coder:30bで解析しました。

総ファイル数: 2,247ファイル（すべてインデックス済み）

言語構成:
  Python:      597ファイル
  TypeScript:  591ファイル
  SQL:         212ファイル
  XLSX:         79ファイル
  DOCX:         50ファイル
  PDF:          26ファイル
  Markdown:    293ファイル
  YAML:         24ファイル
  JSON:         23ファイル
  Bash:         17ファイル  他

インデックス構築：約20秒　👈ここが大きく減りました。
レポート生成：15分程度　👈qwen3-coder:30bは18GBの為32GB-RAMも対応できる（コスパは良い）
その後のQ&A：数十分かかります　👈コンテキストが大きいためLLM処理に時間がかかりますがよい回答を得られた。

1時間後には、プロジェクト全体の構造・データフロー・依存関係・潜在的な技術的負債まで把握できていました。

生成されるレポートの構成

Explainモードで生成されるレポートは11セクション固定です。

#	セクション名	内容
1	Project Overview	プロジェクトの概要・目的・規模
2	Module Map	モジュール構成の全体図
3	Entry Points & Startup Flow	起動ファイルと実行フロー
4	Data Flow	データの流れと変換ロジック
5	Key Interfaces & Contracts	主要なAPI・インターフェース定義
6	External Dependencies	外部ライブラリ・サービスへの依存
7	Configuration	設定ファイルと環境変数
8	Test Coverage	テストの範囲と品質
9	Notable Patterns & Design Decisions	設計パターン・アーキテクチャの判断
10	Potential Issues & Technical Debt	潜在的な問題点と技術的負債
11	How to Extend This Project	拡張方法・開発ガイド

初日に知りたい情報がすべてここに揃います。

セットアップは5分で完了

# 1. Ollamaをインストール
#    https://ollama.com からOS向けパッケージをダウンロード
ollama pull qwen3-coder:30b          # お好みのモデルを取得
ollama pull nomic-embed-text:latest  # RAG用埋め込みモデル（任意）

# 2. LocalForgeをクローン＆インストール
git clone https://github.com/Rikiza89/localforge_web
cd localforge_web
python -m venv venv
source venv/bin/activate   # Windows: venv\Scripts\activate
pip install -r requirements.txt

# 3. 起動
python main.py

pywebviewが使える環境ではネイティブウィンドウが開きます。
Docker・ヘッドレス環境ではブラウザで http://localhost:7331 を開くだけです。
LAN上の別デバイス（タブレット・スマートフォン）からもアクセスできます。

実際の使い方：Explainモードステップバイステップ

Step 1：フォルダを開く

ヘッダーの「📁 フォルダを開く」で解析したいプロジェクトフォルダを選択します。
コードが入ったフォルダを選ぶとExplainモードが自動検出されます。

Step 2：インデックスを構築する（初期は自動で開始する）

「⚙ インデックス構築」ボタンを押すと処理が始まります。

処理の流れ:
  ① Tier-0/1でロック・設定・テストファイルを高速処理
  ② Tier-2でソースコードをtree-sitterでシンボル抽出
  ③ 依存関係を静的解析（import文を解決）
  ④ ChromaDBにベクトル埋め込み（RAG有効時）

ステータスバーに インデックス構築中: src/main.py (1024/2247) のように進捗が表示されます。
2回目以降は変更ファイルのみ再処理されるため、数秒で完了します。

Step 3：レポートを生成する

「✦ レポート生成」ボタンを押すと、11セクションのレポートがストリーミングで生成されます。
右側の「Ollamaライブ出力」パネルで中間出力をリアルタイムに確認できます。

Step 4：Q&Aで深掘りする

レポート完成後、チャット欄から自由に質問できます。

質問例:
「認証フローはどのファイルで実装されていますか？」
「データベースのスキーマ設計を説明してください」
「このプロジェクトに新しいAPIエンドポイントを追加するには？」
「技術的負債の中で最優先で対処すべき箇所はどこですか？」

RAGが有効なら、ベクトル検索 → 依存関係展開（BFS 5ホップ）→ コンテキスト組み立て → LLM生成という流れで、関連するファイルだけが自動的に選ばれます。

ピン留め機能：特定のモジュールを集中解析

ファイルツリー上部の「📎」ボタンでピン留めモードに入ります。
チェックボックスでファイルやフォルダを選択すると、以後のQ&Aではそのファイルがコンテキストに必ず含まれます。

「このモジュールだけを深く聞きたい」「設計書と対応するコードを一緒に解析したい」という場面で重宝します。

CPU環境でのパフォーマンスTips

qwen3-coder:30bのような大型モデルをCPUで動かす際のコツをまとめます。

① CPUスレッド数の調整
右サイドバーの「CPU スレッド」スライダーで使用スレッド数を調整できます。
他の作業と並行する場合は半分程度に絞ると安定します。

② RAG埋め込みの無効化（超高速モード）
config.json で "enable_rag": false を設定するとベクトル埋め込みをスキップし、インデックス構築が大幅に速くなります。Q&AはBM25検索で動作します。

③ モデルのアンロード
ヘッダーの「⏏ 解放」ボタンで現在のモデルをRAMから解放できます。
別モデルに切り替えるときや、メモリを空けたいときに使います。

④ バックグラウンドプリロード
Q&Aボタンを押した瞬間から、コンテキスト組み立てと並行してモデルのRAMロードが始まります。初回応答までの待機時間が体感で大きく改善されています。

対応モデルについて

Ollamaで動く任意のモデルを使用できます。

モデル	特徴	CPU 32GB での動作
`qwen3-coder:30b`	コード理解に特化、高精度	◎ 実績あり
`gemma4:e4b`	軽量・汎用	◎ 快適
`gemma4:26b`	思考プロセス可視化対応	△ 重め
`qwen3.6:27b`	思考プロセス可視化対応	△ 重め
`qwen2.5-coder:7b`	コード理解に特化、軽量	◎ 早い

Gemmaのような「シンキングモデル」は、<think> タグ内の推論トークンをOllamaライブパネルに分離表示する機能も備えています。

まとめ

課題	LocalForgeでの解決
大規模コードの全体像がわからない	11セクションのAIレポートを自動生成
どのファイルがエントリポイントか不明	Entry Points & Startup Flowセクション
ファイル間の依存関係が複雑	静的解析による依存関係グラフを自動構築
APIコストが気になる	完全ローカル動作でコストゼロ
社内コードを外部に送りたくない	Ollamaのみ使用、データは外部に出ない
毎回フルスキャンが遅い	増分インデックスで差分のみ再処理
PDFや仕様書も一緒に解析したい	.pdf/.docx/.xlsx/.pptxに対応済み

「コードを読む前に、まずAIに概要を教えてもらう」というオンボーディングのスタイルは、初心者だけでなく、久しぶりに触るプロジェクトに戻るベテランにも有効です。

完全ローカルで動くからこそ、業務コードでも遠慮なく使えます。ぜひ試してみてください。

参考リンク

Ollama公式サイト
LocalForge リポジトリ:

埋め込みモデル: nomic-embed-text:latest, sentence-transformers/all-MiniLM-L6-v2
使用モデル例: qwen3-coder:30b, gemma4:26b, gemma4:e4b, qwen2.5-coder:7b