メインコンテンツへスキップ

概要

Devin はリポジトリを自動でインデックス化し、アーキテクチャ図、ソースへのリンク、コードベースの要約を含む Wiki を生成します。 コードベースの馴染みのない部分をすばやく理解するために活用できます。サイドバーから確認してください。 Ask Devin は Wiki 内の情報を利用して、コードベース内の関連するコンテキストをより適切に把握・特定します。
DeepWiki はオンボーディング中にリポジトリを接続すると自動生成されます。

公開リポジトリ向け

公開 GitHub リポジトリに対応した無料版の DeepWikiAsk Devin が利用可能になりました。見慣れないコードベースをすばやく理解できるように、アーキテクチャ図、ドキュメント、ソースコードへのリンクを自動生成します。コードベースについて複雑な質問を投げかけて、コンテキストに根ざした具体的な回答を得ることもできます。 deepwiki.com にアクセスして、React、TensorFlow、LangChain などの人気オープンソースリポジトリをはじめ、数多くのリポジトリを探索してみてください。また、自分の公開 GitHub リポジトリの URL を登録して、インデックス作成を依頼することもできます。 今すぐ DeepWiki を試す →

DeepWiki の制御

Steerable Wiki UI .devin/wiki.json ファイルを使うと、Devin のデフォルトの wiki 生成動作を制御できます。これは、組み込みの制限に達する可能性がある大規模リポジトリでは特に重要です。 wiki 生成中にリポジトリのルートディレクトリで .devin/wiki.json ファイルが見つかった場合、指定された repo_notespages を使用して wiki 生成を制御します。pages が指定されている場合、デフォルトのクラスターベースのプランニングをスキップし、指定したページだけを正確に作成します。これにより、自動生成システムではスキップされてしまう場合でも、コードベースの重要な部分が確実にドキュメント化されるようになります。

設定形式

リポジトリのルートに、以下の構造で .devin/wiki.json ファイルを作成します。
{
  "repo_notes": [
    {
      "content": "このリポジトリのcui/フォルダには主要なUIコンポーネントが含まれており、ドキュメント作成時に優先して扱う必要があります",
      "author": "Team Lead"
    }
  ],
  "pages": [
    {
      "title": "CUIコンポーネント概要",
      "purpose": "cui/フォルダの構造と主要なUIコンポーネントをドキュメント化する",
      "parent": null
    },
    {
      "title": "認証システム",
      "purpose": "認証フローと関連コンポーネントをドキュメント化する",
      "parent": null
    },
    {
      "title": "ログインコンポーネント",
      "purpose": "ログイン関連のUIコンポーネントの詳細ドキュメント",
      "parent": "Authentication System"
    }
  ]
}

設定項目

repo_notes (Array)

ドキュメンテーションシステムがリポジトリをより正確に理解できるようにするためのコンテキストやガイダンスを提供します。
  • content (string, required): ノートの内容(最大 10,000 文字)
  • author (string, optional): ノートの作成者

pages (Array, optional)

wiki に作成するページを厳密に指定します。 このフィールドは任意です。repo_notes のみを含めた場合でも、システムはあなたのノートをもとに構成と重点を判断して wiki を生成し、すべてのページを個別に定義する必要はありません。 pages を指定した場合、それらは明示的な指示として扱われます。JSON で定義したページのみが生成され、それ以上でもそれ以下でもありません。
  • title (string, required): ページタイトル(一意かつ空でない必要があります)
  • purpose (string, required): このページで何を文書化するか
  • parent (string, optional): 階層構造のための親ページのタイトル
  • page_notes (array, optional): このページに固有の追加ノート

検証の制限

  • 最大 30 ページ(エンタープライズでは 80 ページ)
  • ノート数は合計で最大 100 個(repo_notes とすべての page_notes の合計)
  • ノート 1 件あたり最大 10,000 文字
  • ページタイトルは一意で、かつ空であってはなりません

実用例

例 1: Wiki 生成をガイドする Repo Notes の利用

特定のページを定義したくない場合は、wiki 生成をガイドするために repo_notes のみを指定できます。これにより、Devin はあなたの優先事項や注力したい領域を考慮しながら、ドキュメント構造を自動的に作成できます。これは、すべてのページを自分で明示的に設計しなくても、カバレッジと重点箇所をより適切に高めたい場合に有用です。
{
  "repo_notes": [
    {
      "content": "このリポジトリは3つの主要領域で構成されています:Reactコンポーネントを含むfrontend/フォルダ、APIサービスを含むbackend/フォルダ、デプロイメントスクリプトを含むinfra/フォルダ。ドキュメントでは、これらの各部分の連携方法を明確にし、バックエンドAPI層を最重要項目として強調してください。"
    }
  ]
}

例 2: 特定のフォルダがドキュメントに含まれるようにする

大規模なリポジトリで、重要なフォルダが Wiki に含まれていない場合は、それらを明示的に指定してください。
{
  "repo_notes": [
    {
      "content": "cui/フォルダには、ドキュメント化が必須の重要なUIコンポーネントが含まれています。backend/フォルダには、メインのAPIロジックが含まれています。utils/フォルダには、コードベース全体で使用される共有ユーティリティが含まれています。"
    }
  ]
}

例 3: ドキュメント化されていないコンポーネントへの対処

コードベースの一部がドキュメント化されていないことに気付いた場合:
{
  "repo_notes": [
    {
      "content": "testing/ディレクトリには、開発者が理解すべき重要なテストユーティリティとパターンが含まれています。scripts/ディレクトリには、運用に不可欠なデプロイおよびメンテナンス用のスクリプトがあります。"
    }
  ]
}

例 4: 階層的なドキュメント構造

複雑なリポジトリでは、ページを階層的に整理します。
{
  "repo_notes": [
    {
      "content": "これは、フロントエンド、バックエンド、共有コンポーネントが明確に分離されたフルスタックアプリケーションです。各コンポーネントは個別にドキュメント化する必要がありますが、相互の関係性を明確にする必要があります。"
    }
  ],
  "pages": [
    {
      "title": "アーキテクチャ概要",
      "purpose": "アプリケーションアーキテクチャとコンポーネント間の相互作用の概要"
    },
    {
      "title": "フロントエンド",
      "purpose": "フロントエンドアプリケーションの構造とコンポーネント",
      "parent": "Architecture Overview"
    },
    {
      "title": "Reactコンポーネント",
      "purpose": "Reactコンポーネント、props、使用方法の詳細ドキュメント",
      "parent": "Frontend"
    },
    {
      "title": "状態管理",
      "purpose": "ストアとデータフローを含むアプリケーション状態の管理方法",
      "parent": "Frontend"
    },
    {
      "title": "バックエンド",
      "purpose": "バックエンドサービス、API、データレイヤー",
      "parent": "Architecture Overview"
    },
    {
      "title": "APIエンドポイント",
      "purpose": "エンドポイント、リクエスト/レスポンス形式を含むREST APIドキュメント",
      "parent": "Backend"
    }
  ]
}

ベストプラクティス

1. Repo Notes を戦略的に活用する

  • コードベースのうち、どの部分が特に重要かについてのコンテキストを提供する
  • 優先すべき特定のフォルダやコンポーネントに言及する
  • システム内の各部分同士の関係を説明する

2. ページを論理的に整理する

  • まずは高レベルな概要ページから始める
  • 親子関係を設定して明確な階層構造を作る
  • 関連する機能をまとめて整理する

3. ページの目的を具体的にする

  • 各ページで何を文書化すべきかを明確に記載する
  • 注力したい特定のディレクトリ、ファイル、または概念を明示する
  • システムが意図を理解できるだけの十分な詳細を提供する

4. 既知の抜け漏れに対処する

  • コードベース内で特定の部分が見落とされているとわかっている場合は、それらを明示的に含めるようにする
  • 何を対象としているかが一目でわかる、説明的なタイトルを付ける

一般的な問題のトラブルシューティング

「一部のフォルダしかドキュメント化されない」

これは典型的な大規模リポジトリでよく起こる問題です。 解決策: .devin/wiki.json を使って、コードベースのどの部分をドキュメント化するかを明示的に指定してください。
まずは repo_notes のみを更新し、その追加コンテキストを反映して wiki を再生成してみて、更新後の wiki に不足していたフォルダが含まれるか確認してください。pages 配列は、必要な場合にのみ追加してください。

「重要なコンポーネントが wiki から抜けている」

これらのコンポーネント専用のページを追加し、その重要性を強調するために repo_notes を使用してください。
ヒント: DeepWiki はこの配列に含まれているページのみを生成するため、欠けているページだけでなく、すべてのページがこの配列に含まれていることを確認してください。
{
  "repo_notes": [
    {
      "content": "[missing-component]ディレクトリはアプリケーションにとって重要であり、詳細なドキュメント化が必要です。"
    }
  ],
  "pages": [
    {
      "title": "重要なコンポーネント名",
      "purpose": "[missing-component]ディレクトリとその機能をドキュメント化する"
    }
  ]
}

はじめに

  1. リポジトリのルートに .devin/wiki.json を作成します
  2. コードベースの構造や優先度を説明する repo_notes を追加します
  3. 必要に応じて、作成したいすべてのページを漏れなく指定し、それぞれに明確なタイトルと目的を設定します
  4. ファイルをコミットし、wiki を再生成します
これにより、システムは完全自動の解析ではなく、明示的な指示に基づいてドキュメントを生成するようになり、大規模なリポジトリでも網羅性と精度の高いドキュメントを作成できます。