「何をしないか」を定義して実現した、Devinと並列開発の実現

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社カカクコム / そうま

メンバー / バックエンドエンジニア

最終更新日2026/05/08投稿日2026/05/12

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
Enterprise	AIコーディング（実装・テストコード生成） / Playbook（作業手順・禁止事項の定義） - GitHub連携（PR作成・修正・レビュー対応）	101名〜300名	2025年12月	B to C

利用プラン	Enterprise
利用機能	AIコーディング（実装・テストコード生成） / Playbook（作業手順・禁止事項の定義） - GitHub連携（PR作成・修正・レビュー対応）
ツールの利用規模	101名〜300名
ツールの利用開始時期	2025年12月
事業形態	B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

Devinを開発フローに組み込む際、「AIがたたき台を作り、人間がレビューで品質を担保する」という役割分担を前提に設計しました。

具体的には、Playbook（手順・禁止事項の定義）を中心に据え、以下のフローで運用しています。

タスクの依頼：Playbookに基づき、調査・要件定義・設計・実装をDevinに依頼
自律的な作業：DevinがPlaybookの手順に沿ってPR作成まで自律的に進行
人間によるレビュー：要件との整合性・パフォーマンス・エッジケースなどを確認
フィードバックと修正：GitHub上のPRコメントでDevinに修正を指示

PlaybookにProcedure（手順）とForbidden actions（禁止事項）を明確に分けて定義することで、Devinが自律的に作業を進めつつも、危険な操作（force-pushなど）を防止できる仕組みにしています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

日々の業務では、機能追加・既存機能の改修・技術的負債の解消・調査依頼など、複数のタスクが常に存在し、それぞれに期限がありました。しかし、従来は1件ずつ順番に対応するのが基本で、1つの案件に集中している間は他のタスクが完全に止まってしまう状況でした。

特に、設計資料の作成や調査に数時間を要する作業が重なると、残りのタスクはその間まったく進まず、タスク数が3〜4件に増えると管理が破綻しがちでした。「自分が別の作業をしている間に、他のタスクも少しずつ前に進んでいれば全体の効率は大きく変わるのに」と常々感じていました。

どのような状態を目指していたか

複数の案件を並列で進められる開発スタイルの実現を目指していました。具体的には、AIエージェントに各タスクの「たたき台づくり」（設計資料・テストケース・実装の初期案）を任せ、人間はレビューと判断に集中することで、3〜4件の案件を同時に前に進められる状態を理想としていました。

詳しい導入経緯やPlaybookの具体例は「Devinで並列開発を実現した～「魔法の杖」を使いこなすために必要だったこと～」で解説しているためぜひご一読ください。

選定理由

最大の決め手はPlaybook機能の存在です。タスクの進め方を事前にMarkdownで定義し、テンプレートとして保存できるため、AIが自律的にタスクを進められる土台を構築できる点が他のツールにない強みでした。

また、社内でDevinの環境が整備されていたこともあり、個人レベルでの準備が少なく「ちょっと試してみよう」とすぐ始められた気軽さも大きなアドバンテージでした。

導入の成果

改善したかった課題はどれくらい解決されたか

Playbookの整備により、当初の課題であった「複数タスクの並列進行」を実現できました。現在は3〜4件の案件を並列で進めながら開発しています。

以前は1つの案件に集中するしかなかった時間帯が、複数のタスクを少しずつ前に進められる時間に変わりました。タスク数が増えたときに破綻しないスケーラビリティを獲得できた点が最大の成果です。

どのような成果が得られたか

各タスクの「初速」（最初のたたき台ができるまでの速度）が大幅に向上しました。

作業内容	従来	Devin活用後	初速の削減率
設計資料のたたき台作成	数時間	約30分	約80〜90%削減
テストケース作成	約1時間	数分	約90%以上削減

※上記はAIがたたき台を生成するまでの時間（初速）であり、その後のレビュー・修正時間を含みません。品質はその後の人間によるレビューで担保しています。

また、急な優先順位変更への対応力も向上しました。複数案件が同時に進んでいるため、突然別の案件を先に対応する必要が出ても、すでに調査や設計のベースができている状態からスタートできます。

導入時の苦労・悩み

導入初期に最も苦労したのは、AIを自走させるための土台づくりです。

当初は「要望だけ伝えればいい感じにやってくれるだろう」と期待していましたが、実際には以下のような問題が頻発しました。

force-push事件 Devinに実装を依頼した際、最新のmasterからブランチが切られておらず古い状態を起点に作業が進み、さらにforce-pushが実行されて作業中のコードが上書きされた
意図しないファイル変更：単純な1ファイルの修正を指示したつもりが、関連のない別ファイルまで変更されてpushされていた
パフォーマンス問題の繰り返し：あるセッションで出力されたコードにN+1クエリなどのパフォーマンス問題があり、別のセッションでも同じ種類の問題が発生。同じ修正指示を何度も繰り返す結果になった

これらの経験から「AIには『何をしてほしいか』だけでなく『何をしないでほしいか』を明示的に伝える必要がある」ことを痛感し、Playbookの整備に本格的に取り組みました。

導入に向けた社内への説明

上長・チームへの説明

すでに社内でDevinの導入が進められており、Devinを活用した開発工程の効率化を目指していました。チーム内ではDevinの活用方法を検討していた際に、一連の開発工程をDevinに任せることを目指してまずはDevinが自走できるためのPlaybookの整備を始めました。

活用方法

各タスクの調査・要件定義・設計・実装をDevinに依頼し、Playbookに基づいて自律的に作業を進めてもらいます。Devinの出力待ちの間に別案件の確認やフィードバックを行うことで、3〜4案件が並列で進行する形です。

Devinが出力したたたき台は必ずレビューし、問題があれば修正指示を出します。Playbookはチーム内で共有しており、個人の失敗から学んだ教訓がチーム全体のナレッジとして蓄積されています。

よく使う機能

Playbook（手順・禁止事項定義）
- タスクの手順（Procedure）と禁止事項（Forbidden actions）を明確に分けて定義し、Devinが自律的に作業を進められるようにしています。問題が起きるたびに更新し、継続的に精度を高めています。
GitHub連携（PR作成・レビュー対応）
- PRの作成・修正・レビュー対応まで、GitHub上の開発ワークフローにそのまま組み込んで使用しています。Devinが作ったPRをGitHub上で確認し、コメントでフィードバックすると修正してくれます。
セッション管理
- タスクごとに独立したセッションでやり取りを行い、複数タスクを並列で管理しています。

ツールの良い点

Playbook機能により、作業手順や禁止事項を事前に定義でき、AIの自律的な作業精度を継続的に改善できる
GitHub連携がスムーズで、既存の開発ワークフローにそのまま組み込める
導入のハードルが低く、複雑なセットアップなしにすぐ実際の開発タスクへ着手できる
設計資料やテストケースのたたき台作成の初速が大幅に向上する
Playbookの改善自体もDevinに手伝ってもらえるため、改善サイクルの負荷が小さい

ツールの課題点

導入初期にAIを自走させるための土台（Playbook）整備に一定の工数が必要
明示的に禁止事項を定義しないと、force-pushや意図しないファイル変更などの問題が発生しうる
AIの出力をそのまま使うことはできず、必ず人間のレビューが必要（特にパフォーマンス面やエッジケースの考慮）

ツールを検討されている方へ

Devinは、Playbookという土台を整えることで真価を発揮する「頼れる開発パートナー」です。

最初から完璧なPlaybookを作る必要はありません。日々の運用の中で、問題が起きたらForbidden actionsに追加し、より良い手順を見つけたらProcedureを更新する。この改善サイクルを回していくことで、着実にDevinの精度が上がっていきます。Playbookの改善自体もDevinに手伝ってもらえるため、負荷も小さく済みます。

そして何より実感しているのは、AIと人間の「役割分担」がうまくはまったときの生産性の高さです。AIがたたき台を作り、人間がレビューで品質を磨き上げる。このサイクルが回り始めると、並列開発が自然と日常になっていきます。

詳しい導入経緯やPlaybookの具体例は「Devinで並列開発を実現した～「魔法の杖」を使いこなすために必要だったこと～」で解説しています。