DevinのPlaybookとKnowledge、どう使い分ける？

## はじめに
Devinの能力を最大限に引き出すためには、PlaybookとKnowledgeという2つの重要な機能を理解し、使い分けることが不可欠です。

- 「毎回同じような指示を出すのが面倒...」
- 「プロジェクト固有のルールをDevinに覚えてほしい...」

こんな風に感じたことはありませんか？

本記事では、Devinをまるで優秀な新メンバーのように育てるための「Playbook」と「Knowledge」の機能について解説し、その効果的な使い分けを具体的な利用シーンと共にまとめます。

## Playbookとは？ - タスク自動化のための「レシピ」

Playbookは、繰り返し行う定型的なタスクを自動化するための「手順書」や「レシピ」のようなものです。特定のタスクを完了させるための一連のコマンドやゴールを定義しておくことで、Devinがその指示に沿って自律的に作業を実行してくれます。

### 主な特徴

- **再利用性**: 一度作成すれば、同じタスクを何度でもDevinに実行させることができます。
- **共有可能**: チームやコミュニティでPlaybookを共有し、ベストプラクティスを横展開できます。
- **手続き的**: 「何（What）」を「どの順番（How）」で実行するのか、という手続き的な指示を定義します。

### 具体的な利用シーン

- 新しい機能開発時の環境構築
- データベースのマイグレーション実行
- 新規コンポーネントの雛形作成とセットアップ
- サードパーティのライブラリ導入と初期設定

**決まった手順の「作業（Doing）」をDevinに任せたいとき**に使います。


## Knowledgeとは？ - Devinを育てる「教科書」

Knowledgeは、**Devinがタスクを実行する際に常に参照すべき「知識」や「ルール」を共有するための機能**です。これは、新しいエンジニアをプロジェクトにオンボーディングする際に、ドキュメントを渡したり、口頭でルールを伝えたりするプロセスに似ています。

ここに情報を登録しておくと、Devinはすべてのセッションを通じてその知識を記憶し、タスクを遂行する上で適切な判断を下すための参考にします。

### 主な特徴

- **永続性**: 一度登録すれば、Devinはその知識を忘れず、関連するすべてのタスクで活用します。
- **自律的参照**: 「この情報を使え」と明示的に指示しなくても、Devinが必要だと判断した際に自ら情報を参照します。
- **宣言的**: 「どうあるべきか」「何を知っておくべきか」という宣言的な情報を記述します。

### 具体的な利用シーン

- プロジェクト固有のコーディング規約やスタイルガイド
- よく発生するバグとその解決策の共有
- 社内ライブラリや独自ツールのAPIドキュメント、利用方法
- 本番環境へのデプロイワークフローやテスト手順
- 利用すべきでないライブラリや非推奨の関数リスト

**プロジェクト固有の「知識（Knowing）」をDevinに覚えておいてほしいとき**に使います。

---

## 具体例で考える！「アプリのバージョンアップ」タスクの判断フロー
「理屈はわかったけど、自分のタスクだとどっちか迷う...」と感じるかもしれません。ここでは、多くの開発者が行う「**リポジトリで管理しているアプリのバージョンアップ**」というタスクを例に、具体的な判断フローを見ていきましょう。
#### Step 1: まず、タスクを「作業手順」と「ルール」に分解する
「アプリのバージョンを上げてリリース準備をして」という一つのタスクも、よく見ると2つの要素に分解できます。
- **🛠️ 作業手順 (Doing / How-to)**
  - `package.json`のバージョン番号を書き換える
  - `npm install`で依存関係を更新する
  - `CHANGELOG.md`に変更点を追記する
  - `git commit`と`git tag`でコミットとタグを作成する
  - `git push`でリモートリポジトリに反映する

- **📖 ルール (Knowing / What-to-know)**
  - バージョン番号は「セマンティックバージョニング」に従うべき
  - コミットメッセージは「`chore(release): vX.Y.Z`」の形式にすべき
  - CHANGELOGは「Keep a Changelog」のフォーマットで書くべき
  - リリース作業は「`main`ブランチ」から行うべき
#### Step 2: 分解した要素を書き場所に割り当てる
分解できれば、あとは簡単です。それぞれの要素を最適な場所に割り当てていきましょう。
- **🛠️ 作業手順 → Playbookへ**
  - 「どうやるか（How）」という具体的な**手順**は、Playbookに記述します。
  - これにより、一連のバージョンアップ作業が**自動化**されます。
- **📖 ルール → Knowledgeへ**
  - 「どうあるべきか（What）」という**規約**は、Knowledgeに記述します。
  - これにより、Devinが行う作業の**品質が担保**されます。
#### Step 3: Devinの動きを想像する 🤖
この分担によって、Devinは以下のように賢く動いてくれます。
1. あなたはDevinに「このPlaybookを使ってアプリのバージョンアップをして」と指示します。
2. Devinは**Playbook**に従って、`package.json`の更新や`npm install`を**手順通りに**実行します。
3. コミットの段階になると、Devinは**Knowledge**を自律的に参照し、「あ、このプロジェクトのコミット規約は `chore(release): vX.Y.Z` だったな」と理解し、**ルールに沿った**コミットメッセージを生成します。
このように、具体的なタスクを「手順」と「ルール」に分解することで、迷うことなくPlaybookとKnowledgeを効果的に使い分けることができます。

---

## まとめ: PlaybookとKnowledgeの効果的な使い分け

それぞれの機能を理解したところで、本題の「使い分け」を一覧表にまとめます。どちらを使うべきか迷った際の判断基準としてご活用ください。

| 観点 | Playbooks | Knowledge |
| --- | --- | --- |
| **目的** | 特定タスクの**実行手順**を定義し、自動化する | プロジェクトに関する**背景情報やルール**を提供し、タスク品質を向上させる |
| **情報の性質** | 手続き的・命令的（何を、どの順番で実行するか） | 宣言的・記述的: （どうあるべきか、何を知っておくべきか） |
| **永続性** | セッション単位（揮発性）タスク実行時に都度適用する | 永続的: 一度登録すれば、Devinが常に自律的に参照する |
| **比喩** | タスクのレシピ、手順書 | プロジェクトの教科書、申し送り事項** |
| **指示の仕方** | 「この**手順**でやって」 | 「この**知識**を覚えておいて」 |

## おわりに

Devinの**Playbook**と**Knowledge**は、それぞれ異なる目的を持つ強力な機能です。

- **Playbook**で定型作業を自動化し、開発の初速を上げる。
- **Knowledge**でプロジェクトの知識を教え込み、Devinの判断精度とアウトプットの品質を高める。

## 関連
- [Creating Playbooks - Devin Docs](https://docs.devin.ai/product-guides/creating-playbooks)
- [Knowledge - Devin Docs](https://docs.devin.ai/product-guides/knowledge)