動画記事 · LangChain
DeepWiki 内部:Cognition が Devin のためのウィキを大規模に構築する仕組み
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
Cognition の Jacob が、大規模コードベース向けウィキ生成アルゴリズムの進化と、エージェントへの文脈提供における「一次情報源」の重要性を解説する。
Cognition が語る DeepWiki の真実:LLM プロンプトに頼らない、大規模コードベースの「構造化」戦略
Cognition の Jacob は、Devin エージェントのために内部開発されたツールが、現在は 140 万リポジトリをインデックスする公開サービスへと進化し、AI エージェントの文脈理解におけるパラダイムシフトを牽引している現状を明かしました。単なる検索(RAG)とエージェント検索の対立ではなく、「一次情報源」と「事前計算された構造化データ」を組み合わせるコンテキストエンジニアリングこそが、大規模コードベースの実用化への鍵であると説いています。
内部ツールから 140 万リポジトリの公開インフラへ
DeepWiki は元々、Cognition の主力エージェントである Devin が自社の巨大なコードベースをマクロ視点で理解するための内部ツールとして開発されました。しかし、開発過程で「人間がコードベースを探索したり、オンボーディングしたりする際にも極めて有用」という価値に気づき、製品化への道が開かれました。
当初はトップ 10 万のオープンソースリポジトリからインデックスを開始しましたが、その反響は大きく、現在は 140 万リポジトリをカバーし、2,000 万件以上のクエリを処理する大規模サービスへと成長しています。この背景には、Devin の背後にあるコンテキスト層としての役割も大きく、単なるドキュメント生成を超えた「コードベースの知性」を提供するプラットフォームへと進化しています。
LLM プロンプトの限界と、アルゴリズム v2 の登場
「コーディングエージェントにプロンプトしてウィキを作成すればいいのではないか」という考えは、小規模なリポジトリであれば有効です。しかし、Cognition が扱うような 20GB に及ぶ単一リポジトリや、1,000 以上のリポジトリを横断する大規模組織のコードベースにおいては、LLM のプロンプトに頼るだけではコストとレイテンシの面で現実的ではありません。
この課題に対し、Cognition は「グラフベースのアルゴリズム(v2)」を導入しました。これは LLM に任せるのではなく、ディレクトリ構造、シンボルグラフ、Git 履歴、さらには実行時データなどの特徴量を用いてファイルをスコアリングし、クラスタリングする手法です。
「LLM がすべてを駆使するのではなく、重要なシステムや人間が関心を持つ要素を定量的に評価し、まず第一歩として何を扱うべきかをアルゴリズムで特定する」
この「スコアリングとクラスタリング」によって生成されたコードベースグラフが、エージェントが処理すべき文脈の骨格となります。これにより、モデルのコンテキスト制限や予算制約を乗り越えつつ、品質の高いウィキをスケールさせることが可能になっています。
目次作成こそがウィキの質を決める
アルゴリズム v2 の核心は、ウィキ作成プロセスにおいて「目次(Table of Contents)の生成」がいかに重要かを再認識した点にあります。Cognition は、個々のページの詳細な記述よりも、まず「どのシステムが重要か」「何をカバーすべきか」を決定する目次の設計こそが、ウィキ全体の質を左右すると捉えています。
誤った目次から始まれば、どんなに優れたページ生成を行っても最終的なウィキは破綻します。そのため、DeepWiki は以下の要素を重視して目次を構築します。
- 重要システムの特定: コードベース全体を網羅するのではなく、ユーザーが本当に知りたい核心となるシステムを抽出する。
- 用語集(Glossary)の統合: 各リポジトリ固有の「正典的な用語」を定義し、エージェントと人間の両方にとっての共通言語として末尾に配置する。
この堅固な目次に基づいて初めて、ページ間の相互リンクや引用を含む一貫性のあるドキュメントが生成されます。v2 では、この初期の構造化情報を元に、エージェント自身が異常を検知した際に追加のクラスタリングやファイルスコアリングをツールとして呼び出すなど、より自律的な適応能力を持たせることで、モデルの進化に合わせて微細なオーケストレーションから文脈提供へと重心を移しています。
一次情報源と事前計算の融合:「コンテキストエンジニアリング」の重要性
AI エージェント開発において頻繁に議論される「RAG(検索拡張生成)対 エージェント検索」という二項対立について、Jacob は明確な見解を示しました。これは二者択一の問題ではなく、信頼性の高い一次情報源と事前計算された情報を適切に組み合わせる「コンテキストエンジニアリング」の領域です。
「モデルが賢くなるほど、より多くの文脈を知的に活用できるようになる。ユーザー定義の知識、事前計算されたウィキ、MCP を通じたライブデータなど、あらゆる文脈ソースはエージェント検索の一部として統合されるべきだ」
ここで重要なのは「一次情報源(Primary Source)」の扱い方です。コードそのものが最も信頼できる真実(グランドトゥルース)であり、LLM が生成した要約や推論による誤情報のリスク(コンテキスト・ポイズニング)を避ける必要があります。
DeepWiki の役割は、この一次情報源の信頼性を担保しつつ、未知の知識を発見するための「パス圧縮」を行うことです。エージェントが直接コード全体を読み込むのではなく、事前計算された構造化グラフとウィキによって文脈を補完し、必要な部分に集中してアクセスできるように設計されています。
まとめ:自律性と構造化による次世代開発支援へ
DeepWiki の進化は、大規模コードベースにおける AI エージェントの実用化が「単純な検索」から「構造化された文脈理解」へと移行していることを示しています。LLM プロンプトのみに依存する時代を超え、アルゴリズムによる事前計算とエージェントの自律性を組み合わせた設計こそが、次世代の開発ツールやエンタープライズ AI の標準となるでしょう。
Original Source
元動画で発言を確認
プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。