前回記事からの進化点を含む、最新版 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