DeepWiki-Openとは？GitHubのコードをローカルでWiki化するOSSの導入手順と未修正CVEへの備え

DeepWiki-Openは、GitHub・GitLab・Bitbucketのリポジトリをクローンして解析し、図付きのWikiとチャットをまとめて生成するオープンソース（MITライセンス）です。Cognitionの公式DeepWikiと違って自分のPCやサーバーで動かせるうえ、生成と埋め込みの両方をOllamaなどのローカルモデルにすれば、コードを外部のAPIへ送らずに済みます。一方で、2026年8〜9月にCVEが3件公開され、2026年9月27日時点の最新コミットでも該当箇所が直っていません。本記事では、導入手順とOllamaでのローカル実行に加えて、動かす前に取るべき防御策まで整理します。

まとめ：DeepWiki-Openの要点

• リポジトリを入れるとWiki・Mermaid図・RAGチャット（Ask）・多段調査（DeepResearch）・Codemapを生成するセルフホスト型のOSS。本体のライセンス料は無料で、かかるのはLLMのAPI利用料と実行マシンの費用
• 英語READMEからは2026年5月に導入手順が消え、後継アプリ「Grok Wiki」の案内が中心になった。手順は日本語版の README.ja.md に残っている
• 既定の生成モデルはGoogle gemini-2.5-flash、既定の埋め込みはOpenAI。Geminiのキーだけでは埋め込みで止まるので、DEEPWIKI_EMBEDDER_TYPE を合わせる
• OllamaとローカルのEmbeddingを組み合わせれば、APIキーなしで完結する
• CVE-2026-72567（CVSS 9.8）など3件が未修正。Dockerで隔離し、ポートは 127.0.0.1 に限定、使わないときは止める

公開リポジトリを読むだけなら、無料の公式DeepWikiで足ります。セルフホストが必要になる条件は、後半の「採用判断」で扱います。

DeepWiki-Openの開発状況（2026年9月時点）

リポジトリの実測値

開発元はAsyncFuncAI（リポジトリは AsyncFuncAI/deepwiki-open）です。2026年9月27日にGitHub APIで取得した値は、スター18,082・フォーク2,007・ライセンスMIT・最終コミット2026年9月3日（d92819a）でした。リリースもタグも1つもないため、どの時点のコードを動かしているかはコミットハッシュで管理するしかありません。後述のCVEも「コミット○○まで影響」という書き方で登録されています。

英語READMEの縮小とGrok Wikiへの移行

「英語のREADMEを開いたら手順がない」と戸惑う原因は、この1年の方針転換にあります。READMEのコミット履歴を追うと次の順で変わっています。

英語READMEが縮んだあともコードの更新は続いています。Docker構成・設定ファイル・手順を書いた README.ja.md などの各言語版はそのまま残っているので、導入時は日本語版を参照します。

公式DeepWiki・Grok Wikiとの違い

「DeepWiki」という名前のものは3つあり、運営元も動く場所も違います。

公式DeepWiki（deepwiki.com）とMCPサーバー

公式版は、URLの github.com を deepwiki.com に置き換えるだけで、公開リポジトリのWikiを読めます。Devinのドキュメントによると、Wiki生成には努力レベルが3段階あり、Lowは無料、Mediumは1 Wikiあたり約5〜10 ACU、Highは約20〜40 ACUです（ACUの単価や消費の抑え方はDevin Session ToolのACU費用を抑える運用で扱っています）。リポジトリ直下に .devin/wiki.json を置くと、生成するページを指定できます。

「deepwiki api」で探している場合、提供されているのはREST APIではなくMCPサーバーです。https://mcp.deepwiki.com/mcp は認証なしの無料サービスで、read_wiki_structure・read_wiki_contents・ask_question の3ツールを持ちます。Claude Codeなら claude mcp add -s user -t http deepwiki https://mcp.deepwiki.com/mcp の1行で追加できます（MCPの権限設定はClaude Codeの導入と権限設定の手順を参照）。対象は公開リポジトリだけで、非公開リポジトリにはDevinアカウントとAPIキーが必要です。

Grok Wiki（DeepWiki-Open 2.0）

README上で「Deepwiki-Open 2.0」と呼ばれているのがGrok Wikiです。xAIのGrokとは関係なく、手元のCLIエージェント（Grok CLI・Codex CLI・Claude Codeなど）を使って、GitHubリポジトリやローカルのコードからWikiを作るデスクトップアプリです。2026年8月18日公開の0.0.38の配布物はApple Silicon向けdmgだけで、IntelのMac・Windows・Linuxの版はありません。GitHubの AsyncFuncAI/grok-wiki にはREADMEと配布物しかなく、ソースコードもライセンス表記も置かれていません。MITで公開されているDeepWiki-Openとは、この点で扱いが変わります。

DeepWiki-Openの解析処理と生成物

処理はPython（FastAPI）のバックエンドとNext.jsのフロントエンドに分かれます。バックエンドはリポジトリを ~/.adalflow/repos/ にクローンし、ファイルを350語ずつ（重なり100語）に分割して埋め込みを作り、~/.adalflow/databases/ に保存します。質問やページ生成のたびに、FAISSで関連度の高い20チャンクを取り出してLLMに渡すRAG構成です。生成済みのWikiは ~/.adalflow/wikicache/ にJSONでキャッシュされ、同じリポジトリを開き直しても再生成しません。

Ask・DeepResearch・Codemapの違い

Ask画面にはFast・Deep Research・Codemapの3モードがあります。Fastは、Wikiを読みながらリポジトリに質問できるRAGチャットです。Deep Researchは調査計画・途中経過・結論の順に自動で続き、最大5回で打ち切って最終回答をまとめます。回数ぶんLLMを呼ぶので、APIの利用料もその分増えます。2026年7月に追加されたCodemapは、コードに根拠を置いて処理の流れをたどる説明を生成するモードです。Wiki本文はMermaid図入りで、MarkdownかJSONで書き出せます。UIとWikiの言語は日本語を含む10言語から選べます。

Dockerでの導入手順

.envの作成とdocker compose

推奨はDocker Composeです。後述のCVEでファイルを読まれた場合でも、読まれる範囲をコンテナの中に閉じ込められるためです。既定構成ではGeminiで文章を生成し、OpenAIで埋め込みを作るので、両方のキーを入れます。

起動の前に、同梱の docker-compose.yml のポート指定を書き換えます。元の "${PORT:-8001}:${PORT:-8001}" と "3000:3000" のままだと、Dockerはホストの全インターフェースで待ち受け、同じネットワークの他の端末からも届きます。両方の先頭に 127.0.0.1: を付けてください。

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

# docker-compose.yml の ports を次の2行に書き換える
#   - "127.0.0.1:${PORT:-8001}:${PORT:-8001}"
#   - "127.0.0.1:3000:3000"

cat > .env <<'EOF'
GOOGLE_API_KEY=your_google_api_key
OPENAI_API_KEY=your_openai_api_key
EOF

docker compose up -d
# UI: http://127.0.0.1:3000  API: http://127.0.0.1:8001/health

コンテナのメモリ上限は6GBに設定されています。イメージの中身を読むときはDockerfileの主要命令とベストプラクティスが参考になります。

手動起動（Python 3.11以上・Node.js）

# バックエンド（Python 3.11以上・リポジトリ直下で実行）
python -m pip install poetry==2.0.1
poetry install -C api
"$(poetry -C api env info -p)/bin/python" -m uvicorn api.main:app --host 127.0.0.1 --port 8001

# フロントエンド（別ターミナル）
npm install
npm run dev -- --hostname 127.0.0.1

READMEにある python -m api.main での起動は、api/main.py が待受先を 0.0.0.0 に固定しているため、全インターフェースに公開されます。上の例はPoetryが作った仮想環境のPythonでUvicornを直接起動し、待受先を 127.0.0.1 に絞っています。手動起動ではバックエンドを動かすユーザーが読めるファイル全体が脆弱性の影響範囲になる点も、Dockerを勧める理由です。フロントエンドはNext.js 15系で、Dockerイメージの中ではNode.js 20を使っています。

モデルプロバイダーと埋め込みの設定

生成モデルの候補は api/config/generator.json に定義されています。2026年9月3日のコミット時点で並んでいるのは次の7プロバイダーで、どれもUIの「カスタムモデル」で任意のモデル名を指定できます。

BedrockとAzureの既定モデルは古い世代のまま残っています。使うときは、自分のアカウントで提供中のモデルIDをカスタムモデル欄に入れてください。

埋め込みモデルの既定値と切り替え

生成モデルとは別に、埋め込みモデルの設定があります。api/config.py は DEEPWIKI_EMBEDDER_TYPE が未設定だと openai を選び、text-embedding-3-small（256次元）で埋め込みを作ります。生成をGeminiにしても、OpenAIのキーがなければインデックス作成で失敗します。Googleだけで済ませるなら DEEPWIKI_EMBEDDER_TYPE=google（gemini-embedding-001）、ローカルなら ollama（nomic-embed-text）、AWSなら bedrock（Titan Embeddings v2）を指定します。埋め込みの種類を変えたら、既存のインデックスは作り直しになります。

LiteLLM経由の構成（2026年9月追加）

2026年9月1日のコミットで、LiteLLMプロキシを挟む docker-compose-litellm.yml が加わりました。LLMの切り替えや利用料の集計をLiteLLM側でまとめたいチーム向けです。この構成ファイルはPostgreSQLを5432番、LiteLLMを4000番で公開しています。さらにマスターキーを sk-1234、DBのパスワードを litellm_password に初期設定しているので、LITELLM_MASTER_KEY と LITELLM_DB_PASSWORD を必ず上書きします。

Ollamaで完全ローカルに動かす手順

生成も埋め込みもOllamaで行えば、コードも質問も外部のAPIへ送られません。公式の Ollama-instruction.md によると、RAMは最低8GB（推奨16GB以上）です。CPUは4コア以上、ストレージはモデル用に10GB以上の空きが推奨で、GPUは任意です。

ollama pull nomic-embed-text
ollama pull qwen3:1.7b

# .env
DEEPWIKI_EMBEDDER_TYPE=ollama
OLLAMA_HOST=http://localhost:11434

起動後、UIのモデルプロバイダーで「Ollama」を選びます。既定の qwen3:1.7b は17億パラメータの小型モデルです。メモリに余裕があれば、候補に並ぶ qwen3:8b や llama3:8b に切り替えられます。DeepWiki-OpenをDockerで動かしてOllamaをホスト側で動かす場合、コンテナから見た localhost はコンテナ自身を指します。DeepWiki-Openの .env には OLLAMA_HOST=http://host.docker.internal:11434 のようにホストのアドレスを指定してください。Linuxではこの名前が標準で引けないため、docker-compose.yml のdeepwikiサービスに extra_hosts: ["host.docker.internal:host-gateway"] を足します。さらに、Ollamaサーバーは既定で 127.0.0.1 だけで待ち受けるので、Ollama側の待受アドレス（こちらも環境変数名は OLLAMA_HOST）をDockerのブリッジから届く値に変える必要があります。その際はファイアウォールで、Ollamaが社内LANに開かないよう絞ってください。Ollamaやモデルの選び方はローカルLLMとOllamaでの構築手順で解説しています。

プライベートリポジトリとアクセストークンの扱い

非公開リポジトリは、UIの「+ アクセストークンを追加」からGitHub・GitLab・Bitbucketのトークンを渡すと読めます。バックエンドはトークンをクローン用URLに埋め込みます（GitHubは トークン@github.com、GitLabは oauth2:トークン@、BitbucketはAPIトークンなら x-bitbucket-api-token-auth）。

注意したいのは、この方式ではトークンがディスクに残ることです。トークン入りのURLでgit cloneすると、.git/config の remote.origin.url にURLがトークンごと平文で保存されます。つまり ~/.adalflow/repos/ 配下にトークンが残り続けます。加えてUIは、入力したトークンを遷移先ページのURLクエリ（?token=）に載せます。ブラウザの履歴や、リバースプロキシを挟んだ場合のアクセスログにも残ります。読み取り専用で対象リポジトリを絞った短期のトークン（GitHubならfine-grained token）を使い、解析後はトークンを失効させるのが安全です。

未修正のCVE3件と公開前の防御策

2026年8〜9月に、DeepWiki-Openの脆弱性が3件CVEとして登録されました。どれも認証なしで悪用できる種類です。

CVE-2026-72567は、キャッシュ用エンドポイントが owner・repo・repo_type をそのままファイルパスに使うパストラバーサルです。CVE-2026-72602は、/local_repo/structure が絶対パスを受け取り、認証なしでディレクトリ一覧を返す問題です。CVE-2026-90946では、チャットのWebSocketが repo_url にファイルシステムのパスを受け付けます。そのため、Python・JavaScript・YAML・JSONなど対応拡張子のファイルが読み出され、そこに書かれた認証情報も漏れます。報告者のIssue #536によると、既定の除外設定で .env や *.ini は対象外ですが、ソースに直書きした秘密情報、credentials.json、クラウドやKubernetesのYAMLは読まれます。同じ入口で任意のホストへ git clone させるSSRFも指摘されています。

コミットd92819aのソースで確認した未対策箇所

CVE-2026-90946の影響範囲「d92819aまで」は、2026年9月27日時点の最新コミットそのものです。つまり、いまcloneしたコードは影響を受けます。9月3日時点のソースを読むと、次の状態でした。

• /local_repo/structure は任意のパスをそのまま os.walk に渡している
• キャッシュのファイル名は owner・repo・repo_type を連結して作っており、パスの検査がない
• DEEPWIKI_AUTH_CODE を照合しているのは DELETE /api/wiki_cache だけで、チャット・一覧取得・Wiki生成は認証を見ていない
• フロントエンドの next.config.ts が /local_repo/structure と /api/wiki_cache を3000番からバックエンドへ中継している

「8001番を閉じて3000番だけ開ける」構成でも、上の2つのエンドポイントには3000番経由で届きます。DEEPWIKI_AUTH_MODE=true にしても、守られるのはWikiの削除だけです。さらにDockerfileには USER 指定がなく、コンテナ内のプロセスはrootで動きます。

ローカル限定運用とDockerでの隔離

現時点では、社内LANやクラウドのVMに公開せず、個人のPCだけで使うのが前提です。ただし 127.0.0.1 への限定は必要条件にすぎません。APIはCORSで全オリジンを許可しており、WebSocketはそもそもCORSの制限を受けません。Issue #536が指摘するとおり、利用者がブラウザで開いたWebページから、ローカルのAPIを呼ばれる経路が残ります。そこで次の対策を重ねます。

• Dockerで動かし、読まれてよいファイルしか置かない。同梱のComposeがホストからマウントするのは ~/.adalflow とログのディレクトリだけで、任意ファイル読取が届く範囲はコンテナ内とこの2か所に収まる
• ポートは両方とも 127.0.0.1 に限定し、使い終わったら docker compose stop で止める
• 渡すAPIキーはDeepWiki-Open専用に発行し、利用上限を設定しておく
• 複数人で使うなら認証付きのリバースプロキシを前に置く。ただし、認証を通った利用者がサーバー内のファイルを読める状態は変わらないので、使えるのは信頼できる少人数に限られる

今後のコミットで直ったかどうかは、git log の日付だけでは判断できません。影響範囲より新しいコミットでも、修正が入っているとは限らないからです。/local_repo/structure・/api/wiki_cache・/ws/chat の差分を読み、パスを許可したルート配下に制限する検査が入ったことを確かめてから、公開範囲を広げてください。脆弱性の詳細はCNAのVulnCheckの告知にもまとまっています。

採用判断：DeepWiki-Openが向く場面・向かない場面

向いているのは、社外に出せないリポジトリを、自分のPCの中だけで把握したい場合です。Ollamaと組み合わせればAPI費用もかかりません。ただし生成されたWikiはあくまで入口の地図です。記述は各ページのリンク先のソースで確かめる、補助ツールという位置づけで使います。

向いていないのは次の2つです。1つ目は、公開OSSを読みたいだけの場合で、公式DeepWikiが無料で同じことをしてくれます。2つ目は、チームの共有サーバーに常設して複数人で使う運用です。上で見たとおり、認証はWikiの削除にしか効かず、CVEも未修正のままです。社内ナレッジの共有基盤が目的なら、権限管理を前提に設計した社内wikiのOSS構築と権限・検索設計を先に検討し、DeepWiki-Openは個人の解析ツールと割り切るのが現実的です。Devinをすでに契約しているチームなら、非公開リポジトリも公式DeepWikiで扱えます（Devinの料金と使い方）。

DeepWiki-Openに関するよくある質問

DeepWiki-Openは無料ですか？料金はかかりますか？

本体はMITライセンスで、ライセンス料はかかりません。実際にかかるのは、GeminiやOpenAIなどクラウドのLLMを使った場合のAPI利用料と、動かすマシンの費用です。Ollamaで生成と埋め込みの両方をローカルにすれば、APIの利用料はゼロになります。

DeepWiki-Openはローカル環境で動かせますか？

動かせます。Docker ComposeかPython＋Node.jsの手動起動で立ち上がり、Ollamaと DEEPWIKI_EMBEDDER_TYPE=ollama を組み合わせれば、外部APIへの通信なしで完結します。RAMは8GB以上、推奨は16GB以上です。

DeepWikiとDeepWiki-Openは何が違いますか？

DeepWikiはCognitionがdeepwiki.comで提供するサービスで、公開リポジトリは無料、非公開リポジトリはDevinの契約が必要です。DeepWiki-Openは、それを別の開発者（AsyncFuncAI）がオープンソースで再実装したもので、自分の環境で動かし、好きなLLMを選べます。

GitHubのプライベートリポジトリでも使えますか？

使えます。UIでGitHub・GitLab・Bitbucketのアクセストークンを入力します。ただし、トークンはクローンしたリポジトリの .git/config とブラウザの履歴に平文で残ります。読み取り専用の短期トークンを使い、解析後は失効させてください。

DeepWiki-Openの脆弱性（CVE）は修正されていますか？

2026年9月27日時点では修正されていません。CVE-2026-90946の影響範囲は最新コミットの d92819a まで含み、ほかの2件の原因になったエンドポイントも認証なしのまま残っています。Dockerで隔離したうえでポートを 127.0.0.1 に限定し、ネットワークには公開しないでください。

関連記事

• Devinとは？できること・料金・使い方と他AIツールとの違い【2026年版】
• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説
• MCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組み・作り方を解説
• 社内wikiの作り方：OSS構築の手順と権限・検索設計、スクラッチ開発の判断基準