はじめに
株式会社ネクストスケープ Chief Technology Office所属の小野塚です。
前回、「Devin（Devin Cloud）を試してみた」、そして「Devin Review」の検証に続き、今回はDevinのコードベース理解を助ける「DeepWiki」と、繰り返し行うタスクをテンプレート化する「Playbooks」「Knowledge」を試してみます。
DeepWikiとは
DeepWikiは、リポジトリを解析してアーキテクチャドキュメントを自動生成するツールです。もともとは公開GitHubリポジトリ向けの独立サービス（deepwiki.com）として知られていますが、Devinのエコシステムでは自分のプライベートリポジトリに対しても使
える形で統合されています。
入り口は大きく2つあります。
Devin Desktop内蔵版：エディタでコードのシンボル（クラス名・プロパティ名など）を右クリックし「See Wiki」を選ぶと、その場でインラインの解説が表示される
Webアプリ版（app.devin.ai/wiki）：リポジトリ全体を解析し、ナビゲーション付きのドキュメントサイトのような形で生成される
IDEで試す：シンボルを右クリック
まず手軽な方から試してみます。適当なプロパティを右クリックし、「See Wiki」を選んでみました。
▲ プロパティの定義、使われ方（Views/Shared/Error.cshtmlでの使用例）までコード引用付きで解説してくれる
ちなみに、この結果は英語のままでした（後述の言語設定を試しても、IDE組み込み版だけは英語のままだった点は後ほど触れます）。
Webアプリ版で試す：リポジトリ全体のWiki生成
次にapp.devin.ai/wikiを開き、devin-todo-app-tddリポジトリで生成してみます。
▲ 未生成のリポジトリには「Generate」ボタンが表示される
Generateボタン押下で生成が行われるのですが、今回のTodoアプリのような小規模アプリでも3～4分かかったかと思います。大規模アプリとなるとかなり時間がかかると思いますのでもし試させる方はあらかじめご承知おきを。。
生成が完了すると、左サイドバーに次のような構成でナビゲーションが作られました。
- 概要（はじめに、アプリケーションの起動と依存関係の注入(DI)）
- コアアーキテクチャ（ドメインモデル、サービスレイヤー、コントローラーレイヤー）
- プレゼンテーションレイヤー（共通レイアウトとスキャフォールディングビュー、Todo一覧ビュー）
- 静的アセットとフロントエンドライブラリ（カスタムCSSおよびJavaScript、外部ライブラリ）
- テスト（TodoServiceのテスト、TodoControllerのテスト）
- 用語集
初見のエンジニアが読む順番（概要→設計→画面→テスト）にきれいに沿っていて、単にファイル一覧を並べただけのドキュメントではなく考えられた構成となっています。
概念とコードのマッピング図
「ドメインモデル」のページには、自然言語の概念とC#の実クラスを対応づける図が表示され、単なるクラス図ではなく「人間が説明で使う言葉」と「コード上の実体」を橋渡しする「ドメインモデル」というタイトルにふさわしい見せ方となっていました。
Ask Devinで質問する
各ページの下部には「Ask Devin about devin-todo-app-tdd」というチャット欄があり、コードベースに対して直接質問できます。試しに「なぜサービス層とコントローラー層を分けているの？」と聞いてみました。
▲ 「Thinking process（4 tools used）」という思考過程を折りたたみ表示した上で、TodoController.cs:16-30のような具体的な行番号付きの引用とともに回答
この引用リンクは右側のエディタと連動していて、クリックすると該当箇所がハイライトされて開きます。単に「分離されています」で終わらず、「インターフェースによる疎結合」「DIによる組み立て」という設計上のメリットまで、実際のコードを根拠に説明してくれました。
日本語化の設定
DeepWikiは当初英語で生成されましたが、以下の設定で日本語化できます。
全体設定：app.devin.ai/settings の「Customization」ページ下部にある「DeepWiki languages」で日本語にチェック
リポジトリ単位の設定：Wiki生成前に画面右上に出る言語ドロップダウンで日本語を選んでから生成開始
大きめのリポジトリ向けには、.devin/wiki.jsonというファイルをリポジトリ直下に置くことで生成内容自体をカスタマイズできるそうです。ちょうどDevin ReviewのREVIEW.mdと同じ発想で、設定ファイルによってAIの振る舞いを制御する仕組みがここにも用意されていました。
なお、Web版の全体Wikiはこの設定で日本語化できましたが、Devin Desktop内のインライン版（シンボルを右クリックする「See Wiki」）は、同じ言語設定を反映しても英語のままでした。全体Wiki生成とIDE内の軽量解説とで、裏側の生成の仕組みが分かれている可能性があります。
Playbooksとは
次に「Playbook」について。Playbookは、よく行う作業の「手順書」をあらかじめ登録しておき、必要なときに呼び出せる機能です。公式の説明では「繰り返し行うタスク用のカスタムシステムプロンプト」「プログラムのようなものだが、厳密な構文はない」という表現がされています。
普通にDevinへ毎回プロンプトを打つのと何が違うかというと、次の3点です。
- 手順だけでなく「成功基準」「ガードレール」も書ける：「テストを先に書く」だけでなく、「全テストがPassしていること」のような判定基準もセットで定義できる
- 組織内で共有・再利用できる：Settings > Playbooksに保存されるので、誰か一人が見つけた「うまくいくやり方」をチーム全員が同じ手順で再現できる
- 呼び出すだけで一貫した動きになる：都度プロンプトを書き直す代わりに、Playbookを選ぶだけで同じ手順・同じ基準でDevinが動く
イメージとしては、「新人エンジニアに渡すチェックリスト付きの作業手順書」をDevin用に用意しておく、という感じです。公式には「KnowledgeとPlaybookは組み合わせて使うのが推奨」ともあり、Playbookで「毎回の手順」、Knowledgeで「組織固有の背景知識」を分担して持たせる設計になっています。
Playbookを作成する
試しに、以前TDD実装を依頼した時のプロンプトをそのままPlaybook化してみます。app.devin.ai/settings/playbooksを開いて「作成」します。
入力した内容は以下の通りです。
タイトル: TDDでASP.NET Core機能を実装する
説明:
このプロジェクトに新機能を実装する際、テスト駆動開発（TDD）の手順に従ってください。
手順:
1. 実装前にテスト計画を提示する
2. 必ずテストを先に書き、テストが失敗する（Red）ことを確認する
3. テストが通る最小限の実装を行う（Green）
4. 必要に応じてリファクタリングする
5. 実装後、xUnitのテストが全てPassすることを確認する
成功基準:
- 全てのテストがPassしていること
- テストが実装より先に書かれていること
本文の他に「Macro」（「!tdd」のようなプロンプト内ショートカット）と「Devin mode」という設定項目がありました。
この「Devin mode」は、Devin Desktopのチャットで見かける「Code/Ask/Plan/Bypass Permissions」といった操作モードとは別物で、セッションの計算量・モデルの階層を指定する設定でした。
- Normal：標準的なバランス型
- Fast：速度優先。簡単なタスク向けで、コストも安い
- Lite：さらに軽量・高速。ごく単純な作業向け
- Ultra：じっくり深く考える最上位モード。複雑なタスク向けで、コストも高め
- Fusion：Cognitionが最近出した新方式で、2つのモデルを同時に組み合わせて動かすことで、単一の高性能モデルより低コストで同等以上の品質を狙う仕組み
- Default：組織・個人のデフォルト設定に従う
今回のTDD Playbookは品質重視の内容なので、Defaultのままにしました。FastやLiteだと、テスト計画の提示やRed/Greenの確認を端折られる可能性があります。
Macroを「!tdd」に設定し、保存すると一覧に反映されました。
ここで面白い発見がありまして「Organization 1」の隣に「System 32」というタブがあり、Devinには最初から32個もの標準Playbookが用意されていることがわかりました。
システム標準Playbookを覗く：Bug Catcherの例
そのSystem側の一覧から「Bug Catcher」を開いてみました。
英語だったため内容を読み解くと、これは「指定したユーザーの最近のコミットを掘り返して、こっそり紛れ込んだバグを勝手に見つけて直しておいてくれる」というPlaybookでした。流れを整理すると次のようになります。
- 入力：ユーザーが「Git上のユーザー名」と「対象リポジトリ」を指定する
- 手順1：まず対象リポジトリを軽く調査し、構造や役割を把握する
- 手順2：直近100件のコミットを読み、特に指定した人のコミットのdiffを全部読んで全体の意図を把握する
- 手順3：GitHub issueで報告済みのバグ、ロジックエラー、競合状態・スレッドセーフティの問題、セキュリティ脆弱性、ルールファイル（AGENTS.md、CLAUDE.md、.windsurfrulesなど）への違反、という5つの観点でバグを探す
- 手順4：見つけた候補から一番価値が高いものを選んで修正する。特に指定した人が最近のコミットで持ち込んだ回帰を最優先する
- 成果物：実際のバグを直したPRを最低1つ返す
他のツールで使っていたモデルをDevinで使うと若干レスポンスが（良い方に）異なる印象を受けたのですが、どうやらこういったデフォルトで用意された設定のおかげのようです。
Skillsとの違い
Playbookの一覧を見ていて気になったのが、サイドバーにあった「スキル&ルール」という別項目との違いです。公式ドキュメントに比較表がありました。
要は、「そのリポジトリ固有のやり方」ならSkill、「リポジトリを問わない汎用的な手順・組織のノウハウ」ならPlaybook、という使い分けのようです。
「TDDで実装する」という今回のケースは、特定のリポジトリに縛られない汎用手順なので、Playbookの方が適切な選択となります。
ただ、一番興味深いのは、SkillsがAnthropicのClaude Skillsと同じ仕様（オープンな"Agent Skills standard"）に準拠している点です。ドキュメントには`.agents/skills/`だけでなく、「.claude/skills/」、「.cursor/skills/」、「.codex/skills/」、「.windsurf/skills/」まで全部スキャンすると明記されています。つまり、Claude Code用に書いたSKILL.mdをリポジトリに置いておけば、Devinもそのまま読み込んで使えるようです（こちらはまだ未確認です）。
実際にPlaybookを使ってみる
最後に、作成した「!tdd」のPlaybookを実際に使ってみます。Devin Cloudの新しいセッションで、次のように依頼しました。
!tdd
Todoアプリに「優先度でソートして表示する」機能を追加してください。
「Used playbook: TDDでASP.NET Core機能を実装する」という表示とともに、Playbookの中身（手順・成功基準）がそのまま展開されていました。マクロの名前が「tdd」だったから偶然TDD風に動いたわけではなく、Playbookの中身が確かに読み込まれて動いたことが確認できました。
Knowledgeとは
最後にKnowledgeを試してみます。Knowledgeは、「事実・Tips・決まりごと」を登録しておくと、Devinが必要な時に自動的に思い出して使ってくれる機能です。手順書ではなく「豆知識・背景知識の集積」というイメージです。
これまで見た3つと比べると、次のような整理になります。
- Skill：リポジトリに「SKILL.md」として置く「そのリポジトリ固有の手順」。テストの動かし方、デプロイの仕方など
- Playbook：管理画面で作る「汎用的な手順書」。`!tdd`のように明示的に呼び出して使う
- Knowledge：呼び出し不要。「このプロジェクトの用語」「よくあるハマりどころ」のような、手順ではなく事実・文脈を登録しておくと、Devinが関連しそうな時に勝手に参照してくれる
「絶対に毎回この手順を踏んでほしい」という強制力が欲しい場合はPlaybook、「知っておいてほしいが、都度指示するほどでもない」という背景情報はKnowledge、という使い分けになります。
Knowledgeを作成する
app.devin.ai/settings/knowledgeを開いて、これまでの検証で出てきた組織固有のルールを登録してみます。
タイトル: devin-todo-app-tddのレビュー・実装方針
内容:
- このプロジェクトのコードレビューはREVIEW.mdの方針（日本語コメント、Services/配下のスレッドセーフティ、CSRF対策、エスケープ漏れ、例外の握りつぶしを重点確認）に従うこと
- 新機能の実装はTDD（テスト先行）で行うことが推奨される
- レビューコメントへの対応は、GitHubのSuggested changeをそのまま使わず、コードとコメントの意図を理解した上で修正すること
作成画面には「Pin to repository」という項目があり、「None」のままだと組織内の全リポジトリに適用されるようなのですが、今回は何故かリポジトリが表示されませんでした。「Folder」も選択肢が無かったため、設定が間違っている箇所があったのかもしれません（ご容赦を。。）。
Knowledgeが実際に使われるか確認する
Knowledgeは呼び出し不要で自動的に参照される仕組みなので、Playbookのマクロを使わない新しいセッションで、次のように聞いてみました。
「ナレッジを参照（3）」という表示とともに、単に登録した内容をそのまま返すのではなく、REVIEW.mdファイル自体も確認した上で「1. REVIEW.md（正式方針）」「2. 蓄積されたナレッジ（運用上の重点方針）」と情報源を整理して回答してくれました。何も教えていないのに、Knowledgeの内容が自動的に反映されていることが確認できました。
まとめ
DeepWiki・Playbooks・Knowledgeと3つの機能を試してみて、共通して感じたのは「Devinに何かを教えるにも、レイヤーがきちんと分かれている」という設計思想です。
そのリポジトリ固有のやり方はSkill、リポジトリを問わない汎用的な手順はPlaybook、呼び出し不要の背景知識はKnowledge、そしてコードベースそのものの理解を助けるのがDeepWiki、という具合に役割が整理されており、それぞれ実際に手を動かしてみると、狙い通りに機能していることが確認できました。
当社ネクストスケープはこのように生成AIをはじめとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。
（以下当社お問合せフォーム）
当社では一緒に働いてくれる仲間を募集しています。是非以下のサイトよりお申込みください。
