Devin導入を全社に広げるには？ 小さく始めて組織の力に育てるための、個人→チーム→全社の3ステップロードマップ

DevinではじめるエンタープライズAI開発　第4回

【ステップ1】個人：小さく任せ、指摘をハーネスへ反映する

　第一歩は1人の手元で始めます。準備は2つ。1つ目は対象選び。普段もっとも時間を取られている定型タスクから、第3回の3条件（効果を測りやすい・影響範囲が限定的で切り戻しやすい・合否を機械判定できる）を満たすものを選びます。そのうえで、選んだタスクの現状の件数と工数を控えておきます。この数字が、後の効果確認と投資判断の比較基準になります。2つ目は環境整備。Devinが開発できる環境と、PRを作るたびにビルドとテストが自動で走り、その結果がPRの画面に合否として表示されるCIを整えます。CIが未整備なら、その構築こそ最初の依頼に向いています。Devinが今後安全に働くためのハーネスをDevin自身に整えさせるのは、導入初期の成功体験として好相性です。

　準備ができたら、人間が3時間程度で終わる規模の変更を1セッションで任せます。本稿で題材にする「既存の商品一覧APIへの項目追加」なら、既存実装パターンの調査、レスポンスDTOへの項目追加、テスト追加、OpenAPI定義の更新、PR作成までです。1回目のPRには、null時の扱いが既存仕様と違う、テストが正常系だけ、といったレビュー指摘が並ぶはずです。ここで「使えない」と判断してしまうのが、Devin導入が止まる典型です。指摘は手戻りではなく、ハーネスを育てる改善素材です。

　このステップの中核が、集まった指摘を分類してハーネスに反映する改善ループです。指摘の種類が決まれば、反映先も決まります（表1）。反映先はいずれも第2回で解説した仕組みです。

表1：レビュー指摘の分類と反映先

指摘の種類	観察される事象の例	反映先
仕様理解	項目の意味を取り違える／null時の扱いが既存仕様と違う	プロンプト・Playbook（受入基準の具体化）
既存コード理解	DTOの命名規則と違う／既存の共通部品を使わず新設する	AGENTS.md・Knowledge
品質	テストが正常系だけ／異常系やエラー処理が考慮されていない	Skills・Playbook・CIチェックの追加
作業範囲	依頼範囲外のリファクタリングが混ざる／頼んでいない周辺変更が入る	プロンプトの禁止事項・終了条件

　反映は小さな作業です。命名規則ならAGENTS.mdに1行追記し、機械的に検知できる品質指摘ならCIに機械判定のゲートを1本足します。1件ずつは数分で終わる作業ですが、一度反映すれば、同じ指摘が出なくなる状態が次の依頼以降ずっと続きます。指摘が出てから直すだけでなく、実装パターン・層ごとの責務・命名規則・避けるべき古い書き方を既存コードからDevinに調査させ、AGENTS.mdやKnowledgeに先回りで反映するルール抽出も有効です。

　試す期間は1〜4週間で先に区切ります。期限と判断基準がないまま始めると、「まだ試している最中」のまま判断が先送りされ続けるからです。期間の終わりにKPIを確認し、8割に近づいたら次のステップへ。伸び悩むなら対象タスクとハーネスを見直し、期間を区切り直してもう一周します。「広げる・引き返す」を主観ではなく数字で判断できます。

【ステップ2】チーム：個人の成功を、チームの型にする

　1人の手元でKPIが8割に近づいたら、次はチームに広げます。ここでの落とし穴が成功の個人依存です。「あの人が依頼するとうまくいく」状態のまま使う人数だけ増やしても、品質は依頼する人ごとにばらつくだけです。ステップ1の改善ループを一周するたびに、項目追加を「どう依頼すればうまくいくか」という知見が、依頼文の形で手元に残っていきます。この依頼の型は手順書としてPlaybookに、影響範囲調査やテスト手順といった個別作業はSkillsに、技術スタックや規約などどの依頼でも変わらない前提はAGENTS.mdに落とします。こうして、誰が依頼しても同じ品質が出る状態を先に作ります。

　Devinに任せる範囲は、変更が頻繁に起きる機能から広げます。理由は3つ。よく変更される機能ほど改善効果を毎週実感でき、依頼の回数が多いほど指摘が蓄積して改善ループが速く回り、「この画面だけ例外仕様がある」といった現場の暗黙知が多く潜んでいるからです。変更頻度は、Gitのコミット履歴やチケット数から機械的に割り出せます。題材でいえば、まず商品一覧APIと同型の改修が頻発する注文APIや在庫APIへ横に広げ、続いて集計バッチや管理画面といった別種の定型改修へ踏み出します。広げる先の領域ごとに、先にルール抽出を走らせてから任せ始めます。

　DevinのPRが増えるほど、ボトルネックは実装からレビューへ移ります。このレビューの詰まりを防ぐため、1次レビューを第2回の推論的ゲート（Devin Review）に任せ、人間は設計判断に集中します。この分担を、PRが溢れる前に決めておきます。また、指摘のハーネスへの反映も人の手作業だけでは回らなくなるため、この反映作業自体をDevinに任せ、次のような依頼を定期実行します。

プロンプト例（ハーネス改善セッション・抜粋）

# 要件
過去2週間にDevinが作成したPRのレビューコメントを分類し、
3件以上繰り返された指摘をハーネスに反映する。

# 前提
- 対象：Devinが作成したPRのレビューコメントとCI失敗ログ
- 既存のAGENTS.md / Knowledge / Skills / CI設定を参照する

# 受入基準
- 指摘を「仕様理解／既存コード理解／品質／作業範囲」に分類し、件数を集計したレポート
- 3件以上の指摘ごとに、反映先（AGENTS.md・Skills・CI等）への変更案をPRとして提出

# 禁止事項
- アプリケーション本体のコード変更（反映先はハーネス側のファイルに限る）

# 終了条件
- 変更案PRの提出。対象PRが5件未満の期間は、レポートのみで終了
- 反映先が判断できない指摘が過半のときは、実施せず理由を報告して終了

　チーム運営では、週次のふりかえりも有効です。うまく使えたセッションとうまく使えなかったセッションを毎週Devinにレポートさせ、それを材料にチームでふりかえります。良い依頼の仕方はPlaybookへ、つまずきの原因はハーネスの改善へと落ちていきます。Cognition AI社自身も、完了したセッションの分析結果を次のセッションの改善に活かすサイクルで、DevinをDevin自身の開発に使っています^[1]。Devinに作業させるだけでなく、Devinが働きやすい環境もDevinで育てるわけです。

[1] Cognition「How Cognition Uses Devin to Build Devin」