Claude と DeepWiki MCP で、GitHub に公開されている OSS を効率的に理解する方法

Claude と DeepWiki MCP で、GitHub に公開されている OSS を効率的に理解する方法
Article actions
View in Markdown

Requires Chrome (latest) built-in AI.

Requires Chrome (latest) built-in AI.

React の SSR 周りで、React Fizz と React Flight の関係を整理したくなりました。公式の docs と RFC、ソースを行き来しながら読むのは骨が折れる作業です。リポジトリを Claude にまるごと投げる手もありますが、facebook/react クラスのコードベースだとコンテキストウィンドウを余裕でオーバーしてしまいます。そこで代わりに使ったのが DeepWiki MCP でした。Cognition AI が提供している、無料・認証不要のリモート MCP サーバーで、GitHub リポジトリに対して質問を投げると AI が回答だけを返してくれます。コンテキストに流れるのは質問と回答だけで、リポジトリ本体は流れません。

本記事では、実際に使ってみて押さえておきたかった点をまとめます。

DeepWiki MCPが持つ3つの機能

公開されているツールは 3 つです。

ツール名 役割 コンテキスト消費
ask_question リポジトリへの質問に回答 小(質問と回答のみ)
read_wiki_contents ドキュメント本体を取得 大(本文がそのまま流入)
read_wiki_structure ドキュメントの目次を取得

トークンを抑えたい目的で導入しているなら、ask_question を主役にするのがよさそうです。

read_wiki_contents は基本オフのまま運用する判断になります。

セットアップ

Claude Code

Claude CodeなどのCLI系では、追加コマンドを実行しましょう。

claude mcp add -s user -t http deepwiki https://mcp.deepwiki.com/mcp

Cursor / Windsurf など

設定 JSON に以下を追加します。

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

プライベートリポジトリを扱いたい場合

DeepWiki MCP はパブリックリポジトリ専用です。プライベートを対象にしたい場合は、別物の Devin MCP を Devin アカウント+ API キーで使う必要があります。ここを混同すると「自社リポジトリで動かない」とハマるので、最初に分けて理解しておくと安全です。

DeepWikiにインデックスされてないものには使えない

DeepWiki MCP は、DeepWiki.com にインデックス済みのリポジトリだけを扱えます。試しに自分が関わっている amimoto-ami/c3-cloudfront-clear-cacheask_question で叩いたところ、Repository not found で返ってきました。

主要 OSS はだいたいインデックス済みですが、マイナーなプロジェクトや業務寄りのプロジェクトを調べたいときは、先に DeepWiki.com 上でリポジトリのインデックスを依頼する手順が必要になります。聞いてから「使えなかった」と気づくと時間を取られるので、最初に存在チェックを入れる癖をつけるのがおすすめです。

read_wiki_contents を基本オフにする運用

3 つのツールのうち、read_wiki_contents だけは扱いに注意が必要です。このツールは Wiki の本文をそのまま返すため、呼び出すとコンテキストにドキュメント全文が流入します。そのため調査するフェーズだけで最大文字数に到達してしまうリスクが発生します。

そのため今の所次のような運用にしています。

  • read_wiki_contents はクライアント側で無効化、または初手で使わない
  • システムプロンプトに「DeepWiki に問い合わせる際は ask_question を使うこと」と明示
  • 全体構造を把握したいときだけ read_wiki_structure(目次相当)を使う

ask_question は内部で関連箇所を引いてきて要約した回答だけを返してくれるので、Claude のコンテキストには「自分の質問」と「DeepWiki の回答」しか積まれません。これが DeepWiki MCP の本来の旨味です。

実際に使った例: React Fizz と React Flight

冒頭の動機に戻って、facebook/react に対してこんな質問を投げました。

SSR の設計パターンについて、React Fizz のストリーミングアーキテクチャ、ハイドレーション戦略、React Server Components との統合方法を、それぞれの責任範囲がわかるように説明してください。

ask_question の回答は、SSR HTML を流すストリーミングレンダラーである React Fizz と、Server Components のシリアライズプロトコルである React Flight が別レイヤーで動いていることを、それぞれの担当に分けて返してきました。コードのファイルパスにも触れてくれるので、深掘りしたい部分だけ後から GitHub で開けば済みます。

公式 docs と RFC を行き来する読み方と比べて、最初の地図が一気に手に入る感覚が一番のメリットでした。コードベースの「初めての一歩」に向いています。逆に「この関数の最新バージョンの実装」みたいな精緻な情報は GitHub で直接読みに行くべきで、用途を分けるのが現実的です。

DeepWikiを使う場面使わない場面

個人的な印象として、OSSの把握や設計判断などの青写真を掴みたい時にはかなり便利そうです。ただしインデックスされるまでのラグや公開リポジトリのみ対象なことなどを考えると、技術選定の前段階や、知らないコードベースに飛び込む最初の数十分の効率化ツールとして使うのが良さそうかなと思います。

参考

Share:

Hidetaka Okamoto profile photo

Hidetaka Okamoto

Developer Experience Engineer

Developer Experience Engineer. A developer specialized in serverless application development on AWS and Cloudflare. Former Stripe Developer Advocate / AWS Samurai 2017. Skilled in creating content and presentations that introduce service usage and best practices. You can follow me on Twitter at @hidetaka_dev

Related Articles

Claude と DeepWiki MCP で、GitHub に公開されている OSS を効率的に理解する方法