DeepWiki-Openの使い方｜GitHubリポジトリからAI Wikiを自動生成するOSSをセルフホスト

この記事ではRAGに特化して解説します。RAG全般は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ をご覧ください。

DeepWiki-Openとは — リポジトリからAIドキュメントを自動生成するOSS

DeepWiki-Openは、GitHub・GitLab・BitbucketのリポジトリをAIで解析し、構造化されたWikiドキュメントを自動生成するオープンソースツールだ。2026年4月時点でGitHub Star数は15,500を超え、MITライセンスで公開されている。

READMEすら読まずにコードの全体像を把握したい、新しいOSSの仕組みを素早く理解したい — そんな場面で威力を発揮する。リポジトリURLを入力するだけで、以下の成果物が自動生成される。

• 構造化されたWikiページ — コードベースの機能・設計・モジュール構成を整理したドキュメント
• Mermaid図 — アーキテクチャ図、データフロー図、シーケンス図を自動描画
• RAGベースQ&A — コードに対して自然言語で質問し、関連コードを根拠にした回答を取得
• DeepResearch — 複雑なテーマについて最大5回の反復調査を実行する深掘り機能

技術スタックはフロントエンドがNext.js 15 + React 19、バックエンドがFastAPI（Python）。ベクトル検索にFAISS、LLMフレームワークにAdalFlowを採用している。

なお、同名の「DeepWiki」（Cognition AI / Devin提供のホスティング版）とは別プロジェクトだ。本記事はセルフホスト可能なOSS版「DeepWiki-Open」を解説する。

リポジトリの実測値（2026年7月31日時点）

READMEが挙げる処理の流れは5段階だ。①コード構造の解析 → ②包括的なドキュメント生成 → ③仕組みを説明する図の作成 → ④ナビゲートしやすいWikiへの整理 → ⑤codemap（コード中心のガイドツアー）の生成。最後のcodemapは比較的新しい追加で、2026年7月30日のコミット（Feat/codemap pr）で入っている。

公式ドキュメントの現在地 — 英語READMEは2.0告知だけ、日本語READMEに全手順が残っている

DeepWiki-Openを2026年に導入しようとすると、最初につまずくのが公式READMEだ。ここは知らないと確実に迷うので先に書いておく。

英語版 README.md は2026年5月に大きく書き換えられ、現在は2,058バイトしかない。中身は「Deepwiki-Open 2.0（Grok Wiki is now live）」の告知と、https://grok-wiki.com へのダウンロード導線、コントリビュート方法、ライセンス表記だけ。インストール手順も環境変数もプロバイダー設定も、英語READMEからは消えている。

ところが、リポジトリ本体は何も失われていない。

・docker-compose.yml / Dockerfile / Dockerfile-ollama-local / Dockerfile-litellm — Docker一式は健在
・run.sh — 起動スクリプトも残っている
・api/ src/ — バックエンドとフロントエンドの実装がそのまま
・Ollama-instruction.md — ローカルLLM向けの独立した手順書
・LICENSE — MITライセンス本文も存在（license APIでMITと判定される）

つまり 「セルフホストできなくなった」のではなく、英語READMEが製品版の入口に置き換わっただけだ。

なお、grok-wiki.com で配布される 2.0（Grok Wiki）は別の配布形態であり、本記事が扱うのはあくまでリポジトリをセルフホストする方だ。自分のコードを外部サービスに渡さずに解析したい、社内リポジトリで使いたい、という用途ではセルフホスト一択になる。

仕組みと主要機能 — RAG・ベクトル検索・DeepResearch

DeepWiki-Openの処理パイプラインは5ステップで構成される。

ベクトル埋め込みとRAG — コードをチャンクに分割し、FAISS（Facebook AI Similarity Search）でベクトルインデックスを構築する。Q&A機能では質問に関連するコード断片をベクトル検索で取得し、LLMに渡して根拠に基づいた回答を生成する。RAGFlowのようなエンタープライズRAGとは異なり、コードリポジトリ特化の軽量実装だ。

DeepResearch — 単純なQ&Aでは足りない複雑なテーマに対応する機能。「リサーチ計画→調査→中間報告→追加調査→最終結論」のサイクルを最大5回反復する。大規模リポジトリのアーキテクチャ分析や、モジュール間の依存関係の調査に有効。

プライベートリポジトリ対応 — GitHub・GitLabのPersonal Access Tokenを入力することで、プライベートリポジトリも解析できる。

データ保存先 — すべてのデータは ~/.adalflow/ 配下に保存される。

インストールとLLMプロバイダー設定

Dockerで起動（推奨）

最も手軽なのはDocker Composeでの起動だ。

# リポジトリをクローン
git clone https://github.com/AsyncFuncAI/deepwiki-open.git
cd deepwiki-open

# APIキーを設定（少なくとも1つ必要）
cat > .env << 'EOF'
OPENAI_API_KEY=sk-your-openai-key
GOOGLE_API_KEY=your-google-api-key
EOF

# Docker Composeで起動
docker-compose up

起動後、http://localhost:3000 にアクセスすればWiki生成画面が表示される。

Docker Hubからイメージを直接pullして実行することもできる。

docker pull ghcr.io/asyncfuncai/deepwiki-open:latest

docker run -p 8001:8001 -p 3000:3000 \
  -e OPENAI_API_KEY=sk-your-key \
  -e GOOGLE_API_KEY=your-google-key \
  -v ~/.adalflow:/root/.adalflow \
  ghcr.io/asyncfuncai/deepwiki-open:latest

手動セットアップ

Docker以外で動かす場合は、バックエンドとフロントエンドを個別に起動する。

# バックエンド（FastAPI / ポート8001）
python3 -m pip install poetry==2.0.1
poetry install -C api
python3 -m api.main

# フロントエンド（Next.js / ポート3000）— 別ターミナルで
npm install
npm run dev

7つのLLMプロバイダー

DeepWiki-Openは7つのLLMプロバイダーをサポートする。UIから切り替え可能で、用途やコストに応じて選択できる。

埋め込みモデルも切替可能で、OpenAI（text-embedding-3-small）、Google（text-embedding-004）、Ollama（ローカル）、AWS Bedrockから選べる。ただし埋め込みプロバイダーを変更すると、既存のベクトルインデックスを再生成する必要がある点に注意。

Ollamaでの完全ローカル実行

外部APIキーなしで動かしたい場合はOllamaを使う。

# Ollamaのインストールとモデル取得
curl -fsSL https://ollama.ai/install.sh | sh
ollama pull llama3
ollama pull nomic-embed-text

# .envにOllamaのエンドポイントを設定
echo "OLLAMA_HOST=http://localhost:11434" > .env

# Docker Composeで起動
docker-compose up

UIのプロバイダー選択で「Ollama」を選べば、すべての処理がローカルで完結する。

生成されるWikiには何が入るのか — 5段階の処理を分解する

「Wikiを自動生成する」と言われても、実際に何が出てくるのかが分からないと導入判断ができない。READMEが挙げる5段階を、出力物の観点で分解する。

⑤のcodemapが比較的新しい。①〜④が「読み物としてのドキュメント」を作るのに対し、codemapはコードそのものを順路つきで辿らせる——「まずここを読み、次にここ」という導線を作る機能だ。新規参画者のオンボーディングのように、読む順番が価値になる場面を狙った追加と読める。

そして、生成物は静的なドキュメントで終わらない。RAGベースのQ&Aが乗るため、「この認証はどこで実装されている？」といった質問をWikiに対して投げられる。埋め込みとインデックスは ~/.adalflow/databases/ に永続化されるので、同じリポジトリに何度質問しても再解析は走らない。

実務での使いどころは、「READMEが薄いOSSを評価するとき」と「引き継いだコードベースの全体像を掴むとき」の2つに集約される。どちらも「コードはあるが説明が無い」状況であり、まさにDeepWiki-Openが埋めようとしている穴だ。

使い方 — 最短ルートと、手動セットアップの4ステップ

ここからは実際に動かす手順を追う。やることは「APIキーを置く」「起動する」「リポジトリURLを入れる」の3つで、それ以上でも以下でもない。

最短ルート：Docker Composeで一発起動

まず動かして雰囲気を掴みたいなら、Dockerが最短だ。

git clone https://github.com/AsyncFuncAI/deepwiki-open.git
cd deepwiki-open

# APIキーを .env に置く（GoogleとOpenAIの2つが基本）
echo "GOOGLE_API_KEY=your_google_api_key" > .env
echo "OPENAI_API_KEY=your_openai_api_key" >> .env

docker-compose up

docker-compose.yml はホストの ~/.adalflow をコンテナ内の /root/.adalflow にマウントする。ここに クローンしたリポジトリ（repos/）・埋め込みとインデックス（databases/）・生成済みWikiのキャッシュ（wikicache/） が保存されるため、コンテナを停止・削除してもデータは消えない。同じリポジトリを2回目に開くときが速いのはこの仕組みによる。

手動セットアップの4ステップ

バックエンド（Python）とフロントエンド（Next.js）を別々に動かす構成で、公式ドキュメントはこちらを「推奨」としている。開発中に片方だけ再起動できるので、設定を詰める段階ではこちらが扱いやすい。

ステップ1：.env にAPIキーを置く

GOOGLE_API_KEY=your_google_api_key
OPENAI_API_KEY=your_openai_api_key
# OpenRouter経由のモデルを使う場合のみ
OPENROUTER_API_KEY=your_openrouter_api_key

ステップ2：バックエンドを起動

python -m pip install poetry==2.0.1 && poetry install -C api
python -m api.main

ステップ3：フロントエンドを起動

npm install && npm run dev

ステップ4：ブラウザで開いてURLを入れる

http://localhost:3000 を開き、解析したいリポジトリのURLを入力して「Wikiを生成」を押す。GitHub・GitLab・Bitbucketのいずれも受け付ける（例：https://github.com/openai/codex）。プライベートリポジトリを解析したい場合は、「+ アクセストークンを追加」から個人アクセストークン（PAT）を入力する——ここを知らずに「プライベートリポジトリが読めない」と詰まるケースが多い。

MCP連携とアクセス制御

DeepWiki MCPサーバー

Cognition AIが提供するDeepWiki MCPサーバーを使えば、AIコーディングツールからリポジトリのドキュメントに直接アクセスできる。公開リポジトリが対象で、50,000以上のリポジトリがインデックス済み。

Claude Codeでの設定は1コマンドで完了する。

# Claude CodeにDeepWiki MCPサーバーを追加
claude mcp add -s user -t http deepwiki https://mcp.deepwiki.com/mcp

CursorやWindsurfでは mcp.json に以下を追加する。

{
  "mcpServers": {
    "deepwiki": {
      "serverUrl": "https://mcp.deepwiki.com/mcp"
    }
  }
}

MCPサーバーは3つのツールを提供する。

セルフホスト版のアクセス制御

DeepWiki-Openをチーム内で公開する場合、認証モードで保護できる。

# .envに追加
DEEPWIKI_AUTH_MODE=true
DEEPWIKI_AUTH_CODE=your-secret-code

対応LLMプロバイダーは7つ — ただしREADMEに書かれているのは4つだけ

プロバイダー選択はDeepWiki-Openの設計上の要で、ここを理解しておくと「どのモデルで動かすか」の自由度が一気に上がる。

READMEが説明しているのは4つだ。

ところが、実際の設定ファイル api/config/generator.json の providers を数えると 7つある。

# 対応プロバイダーを自分で数える
curl -s https://raw.githubusercontent.com/AsyncFuncAI/deepwiki-open/main/api/config/generator.json \
  | python3 -c "import json,sys; print(list(json.load(sys.stdin)['providers']))"

出てくるのは dashscope / google / openai / openrouter / ollama / bedrock / azure の7つ（2026年7月31日時点の実測）。READMEに一切登場しない bedrock（Amazon Bedrock）・azure（Azure OpenAI）・dashscope（Alibaba）が設定ファイルには存在する。

これは企業導入では小さくない差だ。「Azure OpenAI しか使えない」「Bedrock 経由でないと承認が下りない」という制約のある組織でも、設定ファイルを見れば選択肢があることになる。ドキュメントに書かれていないだけで、実装は先に進んでいる——READMEだけを見て「対応していない」と判断すると導入機会を逃す。

類似ツール比較 — OpenDeepWiki・Cognition DeepWiki

リポジトリからドキュメントを自動生成するツールの比較。

選び方のポイント — セルフホストで自由にカスタマイズしたいならDeepWiki-Open。API不要で完全ローカル実行ならOllama連携のDeepWiki-Openが唯一の選択肢。公開リポジトリのドキュメントを手軽に参照するだけならCognition DeepWikiのホスティング版が最も簡単で、github.com を deepwiki.com に置き換えるだけで使える。

つまずきポイントと、向いていない使い方

導入前に知っておくと余計な時間を使わずに済む点をまとめる。

・プライベートリポジトリはPATを入れないと読めない — UI上の「+ アクセストークンを追加」が必要。エラー文が親切とは限らないので、まずここを疑う
・初回は時間がかかる — 埋め込みの生成が走るため、大きなリポジトリほど待つ。~/.adalflow/databases/ にキャッシュされるので2回目以降は速い
・キャッシュがディスクを食う — ~/.adalflow/ 配下にリポジトリ本体・埋め込み・Wikiキャッシュが溜まる。複数の大規模リポジトリを解析したあとは、ここのサイズを確認しておきたい
・既定構成ではコードが外部LLMに渡る — Google / OpenAI のAPIを使うため、社内コードで使うなら Ollama 構成か、OPENAI_BASE_URL で社内エンドポイントに向ける構成を先に検討する

向いていない使い方もはっきりしている。DeepWiki-Openが出すのは「コードから読み取れること」の整理であって、なぜその設計にしたのかという意思決定の履歴は出てこない。設計判断の背景はコードに書かれていないことが多く、それはIssueやPRの議論、あるいは人の頭の中にある。生成されたWikiは「地図」としては極めて有用だが、「なぜこの道を通したのか」の答えではない——ここを混同すると、生成物を過信することになる。

同じ「コードを構造化して理解する」系統では、リポジトリをナレッジグラフに変換してAIの検索効率を上げる Graphify入門：コード・ドキュメント・画像をナレッジグラフ化し、AIの検索トークンを71.5倍削減する が別のアプローチを取る。DeepWiki-Openが「人間が読むWiki」を作るのに対し、Graphifyは「AIが引くグラフ」を作る——出力の宛先が違うと考えると使い分けやすい。ドキュメント検索を全社的な基盤として組みたい場合は Onyx導入ガイド：企業向け社内ドキュメントAI検索基盤をDocker Composeで構築・運用する のような常設のRAG基盤が対になる。

制限事項・注意点

大規模リポジトリの処理時間 — モノレポや巨大リポジトリでは解析・埋め込み生成に時間がかかる。api/config/repo.json でファイルフィルタやサイズ上限を調整できる。

埋め込みプロバイダーのロックイン — OpenAIの埋め込みで生成したインデックスをGoogleの埋め込みで検索することはできない。プロバイダーを変更する場合はインデックスの再生成が必要。

メンテナンス体制 — 開発者は新プロジェクト「AsyncReview」に開発の主軸を移しており、DeepWiki-Openはメンテナンスモードと公表されている。コミュニティの活発さ（1,700フォーク）がリスクを緩和している。同じ「リポジトリからWiki生成」を狙うRust製の再実装として Litho（deepwiki-rs） も登場しており、軽量・高速なローカル実行を重視するなら選択肢になる。

認証モードの制約 — DEEPWIKI_AUTH_MODE はフロントエンドを保護するが、バックエンドAPIへの直接アクセスは完全には防げない。公開環境ではリバースプロキシで追加保護が推奨される。

関連記事: RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ

参照ソース

• GitHub — AsyncFuncAI/deepwiki-open
• DeepWiki-Open README（日本語）
• DeepWiki MCP サーバー
• DeepWiki MCP ドキュメント
• Cognition DeepWiki（ホスティング版）
• デモ動画（YouTube）