はじめに：AIによる並列開発
食べログ 国内メディア開発部の相馬です。食べログの開発業務に携わっています。
私は現在、AIエージェント「Devin」を活用して、3〜4件の案件を並列で進めながら開発をしています。設計資料のたたき台作成やテストケースの洗い出しなど、以前は数時間かかっていた作業の初速が大幅に向上し、開発の進め方も大きく変わりました。
ただ、最初からこの状態だったわけではありません。
Devinを導入したとき、正直に言えば「魔法の杖」を手に入れたような感覚がありました。「これからはAIが開発を加速してくれる。タスクを渡せば勝手にいい感じに仕上げてくれるだろう」――そんな期待を抱いていました。
しかし、実際に使い始めてみると、期待どおりにはいきませんでした。曖昧な指示では意図と違うコードが生成され、手戻りが発生する。複数のタスクを同時に任せてみても、各セッション（Devinではタスクごとに独立した「セッション」という作業単位でやり取りを行います）で似たような問題が繰り返し起き、修正に追われてかえって時間を取られてしまう。「AIに任せれば楽になる」と思っていたのに、むしろ工数が増えていたのです。
そこから試行錯誤を重ね、Playbookの整備や段取り管理の工夫を積み重ねた結果、ようやく現在の並列開発のスタイルにたどり着くことができました。
本記事では、この「使うだけでは効果が出ない」状態から、「3〜4案件を並列で回せる」状態に至るまでに、何が必要だったのかを具体的に解説します。AIツールの導入を検討している方や、導入したもののうまく活用できていないと感じている方の参考になれば幸いです。
なぜDevinを選んだのか
AIエージェントにはさまざまな選択肢がありますが、私がDevinを選んだ理由は主に3つあります。
1つ目は、Playbookで作業手順や禁止事項を定義できることです。
Devinには「Playbook」という機能があり、タスクの進め方を事前に定義しておくことができます。「この手順でやってほしい」「これはやらないでほしい」といった指示をMarkdownで記述し、テンプレートとして保存できるため、同種のタスクを繰り返し依頼する際に毎回同じ説明をする必要がありません。問題が発生したら禁止事項に追加し、より良い手順を見つけたら更新する――この改善サイクルを回しやすい仕組みが、後述する並列開発の土台になりました。
2つ目は、GitHubとの連携がスムーズなことです。
PRの作成・修正・レビュー対応まで、GitHub上の開発ワークフローに自然に組み込める点が魅力です。Devinが作ったPRをGitHub上で確認し、コメントでフィードバックすると、それを受けて修正してくれる。新しいツールを覚える必要がなく、既存のGitHubフローをそのまま使える点は、導入のハードルを大きく下げてくれました。
3つ目は、すでに用意されている環境の中で、個人で必要な準備が少なく、すぐに取りかかれたことです。
社内でDevinの環境が整備されていたこともあり、複雑なセットアップなしに実際の開発タスクへすぐ着手できました。個人的には、この「気軽に始められる」という点が想像以上に大きかったと感じています。AIコーディングツールへの興味はあっても、環境構築や設定に手間がかかると「今は忙しいからまた今度」となりがちです。Devinの場合はその心理的なハードルがだいぶ低く、「ちょっと試してみよう」と思ったときにすぐ試せた。この気軽さが、結果的にAI活用を継続する上での大きなアドバンテージになりました。
並列開発を実現する条件
直面していた課題
日々の業務では、タスクは次々と積み重なっていきます。機能追加の案件や既存機能の改修、技術的負債の解消、調査依頼――やるべきことは常に複数あり、それぞれに期限があります。
しかし、従来は1件ずつ順番に対応するのが基本でした。1つの案件に集中している間、他のタスクは完全に止まってしまいます。
特にもどかしかったのは、設計資料の作成や調査に時間を取られている間、他のタスクが一切進まないことでした。設計に3時間集中すると、その間溜まった他のタスクは3時間分そのまま遅れる。「自分が別のことをしている間に、他のタスクも少しずつでも前に進んでいれば、全体の効率は大きく変わるのに」――常々そう感じていました。
AIを自走させられなかった時期
「AIツールを導入すれば、この課題は解決するだろう」
Devinを手にしたとき、最初に考えたのはこれでした。AIに複数のタスクを同時に投げて、それぞれ進めてもらえば、自然と並列開発ができるはず、と。
しかし、当時の私にはAIを自走させるための土台がありませんでした。AIへの指示の出し方やPlaybookの手順定義が手探りの状態で、タスクごとの注意事項も明文化されていませんでした。要するに、AIが自律的に動けるだけの準備が何もできていなかったのです。
結果として、さまざまな問題が発生しました。
たとえば、単純な1ファイルの修正を指示したつもりだったのに、関連のない別ファイルまで変更されてpushされていたことがありました。指示できていたと思った作業と、Devinが実際に行った作業がまったく違っていたのです。
あるセッションで出力されたコードにパフォーマンス上の問題があり、修正を指示する。すると、別のセッションでもまったく同じ種類の問題が発生している。同じ修正指示を何度も繰り返し、結局すべてのセッションの確認と修正に追われる結果となりました。
AIに任せたはずが、「AIの出力を確認して直す」という新しい作業が生まれ、かえって手間が増えてしまったのです。この経験から、AIを自走させるための土台――指示の出し方や手順の整備、禁止事項の明文化――を整えなければ、並列開発は実現しないと痛感しました。
並列開発の実態
ここで「並列開発」という言葉について補足しておきます。
「並列開発」と聞くと、3〜4案件のコードが常に同時に書かれているようなイメージを持たれるかもしれませんが、実態は少し違います。
私の場合、Devinの作業待ち時間を活用して別案件を進めることで、結果的に並列になっているというのが正確な表現です。Devinへタスクを依頼して出力を待つ間に別の案件を確認し、そちらにフィードバックを返す。そのフィードバックの反映を待つ間に、また最初のタスクに戻る――この繰り返しです。
つまり、自分自身が同時に複数の作業をしているわけではなく、Devinとのやり取りの「隙間時間」を他の案件に充てることで、全体として並列に進んでいるという状態です。
ただし、AIツールを使わなかった頃と比べると、明らかにタスクの進み方は変わりました。以前は1つのタスクへ集中するしかなかった時間帯が、複数のタスクを少しずつ前に進められる時間に変わったのは大きな違いです。
並列開発に必要な要素
この並列開発を実現するためには、前提として「役割分担」の意識が欠かせませんでした。
具体的には、AIがたたき台を作り、人間がレビューで品質を担保するという分担です。AIの出力をそのまま使うのではなく、必ず人間の目で確認する。この前提がなければ、いくら並列で進めても品質は伴わず、結局は手戻りが発生してしまいます。
この前提の上で、並列開発を実現するために必要だった要素は2つあります。
2. 全体を俯瞰して段取りを組むスキル → 「全体俯瞰と段取り管理」で詳述
AIを自走させる土台がなければ、個々のタスクでDevinは正しく動いてくれないため並列にする意味がありません。段取りのスキルがなければ、複数のタスクの優先順位や確認タイミングを管理できず、混乱するだけです。この2つは、どちらが欠けても並列開発は成立しません。
Playbookの整備：1つのタスクを自動で走らせる
なぜPlaybookが必要なのか
Devinを使い始めた当初は、「要望だけ伝えれば、いい感じにやってくれるだろう」と思っていました。
しかし実際には、見た目はそれっぽいコードが出てくるものの、中身を確認するとパフォーマンスに問題があったり想定と違う実装方針になっていたりと、期待どおりにはいかないことが続きました。「なんとなく動くけど、このまま本番には出せない」というアウトプットが繰り返されたのです。
その中で、決定的な出来事がありました。force-push事件です。
開発環境のブランチで作業中のことでした。Devinに実装を依頼し、PRが作成されたので差分を確認していたところ、どこか違和感がありました。見覚えのある変更が含まれていなかったのです。
調べてみると、2つの問題が重なっていました。1つは、最新のmasterからブランチが切られておらず、古い状態を起点に作業が進んでいたこと。もう1つは、その過程でforce-pushが実行され、作業中だったコードが上書きされてしまったことです。
背筋が凍る思いでした。
幸い、開発環境だったため大きな被害にはなりませんでしたが、これが本番に近い環境で起きていたらと考えると、ゾッとします。
この経験から、重要な教訓を得ました。
「force-pushはしない」――rebaseなどで使う場面はあるものの、共同作業のブランチでは他者の変更を上書きしてしまう危険な操作です。しかしAIにとっては、明示されなければその判断はできません。明文化されていないルールは、AIには伝わりにくいのです。
force-push以外にもさまざまな問題が発生しましたが、いずれも根本は同じでした。この気づきをきっかけに、PlaybookのForbidden actions（禁止事項）に制約を順次追加していきました。AIに同じ失敗を繰り返させないよう、問題が起きるたびにPlaybookを更新していく。この気づきが、Playbook整備の出発点になりました。
Playbookの構成
force-push事件を機に整備を始めたPlaybookですが、現在運用している構成を紹介します（機密情報を除いた抜粋です）。
## Overview（概要） 指定されたリポジトリに指定されたブランチ名でissueとPRを作成する ## Procedure（手順） 1. 基本設計資料を受け取り、issueを作成する 2. 対象リポジトリとブランチ名を確認する 3. 修正内容を確認し、承認を得てから実装に進む 4. git fetch → masterにチェックアウト → pull → 新規ブランチ作成 5. コードを修正してpush、PRを作成 6. レビュー指摘があれば修正（修正前に計画を確認） ## Forbidden actions（禁止事項） - force-pushなどブランチを破壊するコマンドは実行禁止 - 空のコミットをプッシュしない - パフォーマンス検討を怠った実装を入れない（例：N+1、不要なO(N^2)ループ、同期I/Oの多用） - 1メソッドに過剰な責務を集約しない（可読性・テスト性を損なう） - 本番相当データ量でのボトルネック確認をしないままマージしない - issueテンプレートの構造を変更してはいけない - issueテンプレートのチェックボックスにチェックを入れてはいけない
ポイントは、Procedure（手順）とForbidden actions（禁止事項）を明確に分けていることです。
Procedureは「何をどの順番でやるか」――つまり、タスクの正しい進め方を定義します。たとえば手順4の「git fetch → masterにチェックアウト → pull → 新規ブランチ作成」は、force-push事件で併発した「最新のmasterからブランチを切っていなかった」問題を防ぐために明記したものです。
一方、Forbidden actionsは「何をしてはいけないか」を定義します。こちらは過去の失敗やレビューで指摘された問題から学んだ内容を蓄積しています。
Forbidden actionsの各項目には、それぞれ背景があります。
- 「force-pushなどブランチを破壊するコマンドは実行禁止」 は、前述のforce-push事件から追加しました。
- 「パフォーマンス検討を怠った実装を入れない」 は、Devinの生成したコードをレビューした際、N+1クエリや不要なO(N2)ループの混入を確認したことがきっかけです。見た目は正しく動くコードでも、本番のデータ量では深刻なパフォーマンス問題を引き起こす可能性がある。こうした観点は、AIだけでは判断が難しい部分です。
- 「1メソッドに過剰な責務を集約しない」 は、AIが「動くコード」を最短距離で生成しようとする傾向に対する対策です。1つのメソッドにすべての処理を詰め込んで「とりあえず動く」コードを作りがちなため、可読性やテスト性の観点で明示的に制約を設けました。
- 「issueテンプレートの構造変更・チェックボックス操作の禁止」 は、issueのチェックボックスでタスクの進捗を管理しているため、AIが勝手にチェックを入れたり構造を変えたりすると、タスクの状態が正しく把握できなくなることから追加しました。
その他の項目も同様に、実際の運用やレビューで発見した問題をもとに順次追加しています。
Playbookの継続的な改善
Playbookは一度作って終わりではありません。
Devinの出力をレビューする中で新たな問題パターンを見つけたら、Forbidden actionsに追加します。より効率的な手順を発見したら、Procedureを更新します。この継続的な改善サイクルこそがPlaybookの本質であり、使い続けるほど精度が上がっていく仕組みです。
ここで面白いのは、Playbookの改善自体もDevinに手伝ってもらえるということです。たとえば、レビューで繰り返し指摘している内容があれば、「この観点をForbidden actionsへ追加してほしい」とDevinに依頼できます。Playbookの文面の整理や、新しい手順の追記もDevinに任せられるため、改善のサイクルを回す負荷が小さく済みます。Playbookを育てるためにPlaybookの対象であるDevin自身を活用できるのは、効率的な改善ループだと感じています。
また、Playbookはチーム内で共有しています。個人の失敗から学んだ教訓が、チーム全体のナレッジとして蓄積される。これは、AIツールの活用を個人の取り組みに閉じさせず、組織としての知見にしていく上で重要なポイントだと考えています。
全体俯瞰と段取り管理
「段取りを組む」というスキル
並列開発を実現するために必要な、もう1つの要素があります。それは「段取りを組む」スキルです。
これはAI時代に新しく求められるスキルではなく、仕事の基本です。私の所属する組織でも日頃から段取りの重要性が意識されており、タスクの優先順位を判断し、全体を俯瞰して進める姿勢は開発チームに根付いています。AIを活用するようになって、その基本をそのまま活かせる場面が増えたと感じています。
Playbookによって1つのタスクをDevinへ任せられるようになっても、複数のタスクを並列で管理するのは人間の仕事です。朝一で全タスクの状況を把握し、優先順位を決め、待ち時間が発生したら次のタスクにすぐ切り替える。こうした基本的なサイクルを回し続けることが、並列開発の土台になっています。
2つのレベルの段取り
段取りには2つのレベルがあります。この2つを区別して管理することが、並列開発のポイントです。
1つ目は、「1タスクに対する段取り」です。
これはPlaybookで定義し、Devinに自走させる部分です。個々のタスクをどのような手順で進めるかをPlaybookに落とし込むことで、Devinが自律的に作業を進められるようにします。ここが整備されていれば、自分が別のタスクに集中している間も、Devinは着実にタスクを前に進めてくれます。
2つ目は、「自分が持っているタスク全体に対する段取り」です。
どのタスクをどの順番で確認するか、確認の頻度をどう調整するか、急な割り込みにどう対応するか。これは自分自身で管理する部分であり、現時点ではAIに任せることが難しい部分です。
この2つが揃って初めて、並列開発が成り立ちます。Playbookだけあっても全体を管理できなければタスクは混乱しますし、段取りだけ上手くても個々のタスクが自動で走らなければ並列にはなりません。
タスクの優先順位と案件の選び方
緊急度や重要度をもとに優先順位を決め、優先度の高いタスクほどこまめにDevinの出力を確認します。待ち時間が発生したら、その間に他のタスクを一歩でも前に進めておく。この小さな積み重ねが、1日・1週間の単位で大きな差になります。
なお、並列で進める案件同士に関連性は求められません。順序依存がある場合は、設計段階であらかじめフェーズ分けをしておくことで対応しています。
得られた効果
並列開発による効果①：タスク数が増えたときのスケーラビリティ
2件程度の案件であれば、AIツールを使わなくても待ち時間に別タスクを進めることはできます。実際、従来もAの待ち時間を使ってBに着手するといった切り替えは行っていました。
しかし、これが3件、4件と増えてくると話が変わります。
従来の進め方では、各タスクの調査・設計・実装をすべて自分の手で行う必要があります。2件なら切り替えながら対応できても、3件、4件となると、それぞれのタスクの状況把握だけでも負荷が大きくなり、どのタスクも中途半端に停滞しがちでした。特に、設計資料の作成やテストケースの洗い出しなど、まとまった時間を要する作業が複数重なると、待ち時間の隙間だけでは到底回しきれません。
Devinを活用した並列開発では、各タスクの「たたき台を作る」部分をDevinに任せられるため、この制約が大きく緩和されます。
たとえば、A・B・C・Dの4案件を同時に抱えている場合、それぞれの調査・要件定義・設計をDevinに依頼しておきます。Devinが設計のたたき台を出力したら要件との整合性をレビューし、問題なければ実装に進めてもらう。Aを優先的にチェックしながら、待ち時間が発生するたびにB・C・Dの進捗を確認し、フィードバックを返していきます。
従来であれば、4件のうち優先度の低いタスクは着手すらできず放置されがちでした。しかし並列開発では、すべてのタスクが少しずつ前に進んでいるため、本格着手の時点で「調査・資料の土台が完成した状態」からスタートできます。このタスク数が増えたときに破綻しないという点が、並列開発の最大の効果だと感じています。
並列開発による効果②：柔軟な優先順位変更
もう1つの効果として、急な優先順位変更への対応力が挙げられます。
複数案件が同時に進んでいるため、突然「Bの方を先に対応してほしい」と言われた場合でも、Bにはすでに調査や設計のベースができています。ゼロからスタートするのと、土台ができた状態から始めるのとでは、対応速度がまったく違います。
優先順位の変更は実務では珍しくありません。その際に「実はもう下準備ができています」と言える状態を常に作っておけるのは、精神的な余裕にもつながっています。
並列開発を支えた「初速向上」
上記の効果は、各タスクの初速が大幅に向上したことで実現できました。
ここで言う「初速」とは、タスクの最初のたたき台ができるまでの速度のことです。具体的な数値を挙げます。
| 作業内容 | 従来 | Devin活用後 | 初速の削減率 |
|---|---|---|---|
| 設計資料のたたき台作成 | 数時間 | 約30分 | 約80〜90%削減 |
| テストケース作成 | 約1時間 | 数分 | 約90%以上削減 |
※上記はAIがたたき台を生成するまでの時間（初速）であり、その後のレビュー・修正時間を含みません。品質はその後のレビューで担保しています。
この注釈は重要なポイントです。AIが出力した設計資料やテストケースをそのまま使うわけではありません。必ず人間がレビューし、不足や誤りを修正した上で使っています。ただ、ゼロから自分で書き始めるのと、たたき台のある状態からレビュー・修正するのとでは、作業の性質がまったく異なります。 白紙から構成を考えて書く作業と、既にある文章を読んで修正する作業では、後者の方が圧倒的に速く進みます。
人間のレビューが担う役割
初速が向上した分、浮いた時間をレビューの質の向上へ充てられるようになったことも大きな変化です。
前述のとおり、Devinには要件定義や設計から実装・テストまで一連の工程を任せています。つまり、人間のレビューも実装だけでなく、要件・設計・実装・テストのすべての段階で必要になります。
Devinが作成した設計資料をレビューする際、私が特に重視しているのは以下の観点です。
- 要件と実装手段の整合性： Devinの選んだ手段が要求に対して適切か、要件の反映漏れはないかを確認する
- 設計の実現可能性と完全性： 既存システムとの整合性、運用面の考慮漏れがないかを確認する
- 機能分割の粒度： 責務の分け方が適切か、既存モジュールとの一貫性を保てているかを確認する
- パフォーマンスへの考慮： N+1クエリのような本番データ量で問題になる構造がないかを確認する
- 条件判定の網羅性： エッジケースの考慮漏れや、条件分岐の抜けがないかを確認する
これらはいずれも、AIの出力だけでは見落としやすく、人間が確認すべき観点です。
設計段階でこうしたレビューを正確に行うことで、その後のDevinによる実装の精度が大きく向上しました。 曖昧な設計のまま実装へ進むと、意図と違うコードが生成されて手戻りにつながります。逆に、設計段階でしっかり確認しておけば、Devinは正確な設計をもとに実装を進められるため、出力の品質が格段に上がります。
AIがたたき台を速く作ってくれるからこそ、人間は「判断を要するレビュー」に集中できる。この役割分担が、並列開発の品質を支えています。
おわりに：並列開発を実現するために必要だったこと
本記事では、Devinを活用した並列開発の実現方法について解説してきました。
振り返ると、並列開発を実現するために必要だったのは、AIツールの導入そのものではなく、AIツールを活かすための土台づくりでした。
具体的には、以下の2つです。
手順と禁止事項を明確に定義し、1つのタスクをDevinが自律的に進められるようにすること。Playbookは過去の失敗や発見から継続的に更新し、精度を高め続けることが重要です。
2. 全体を俯瞰して段取りを組むスキル
複数タスクの優先順位を判断し、待ち時間を活用して並列に管理すること。これはAI時代に限らず、仕事の基本スキルとして常に磨いていくものだと考えています。
そして、これら2つを支える前提として、「役割分担」 の意識があります。
AIがたたき台を作り、人間がレビューで品質を担保する。要件・設計段階で要求と手段の整合性を確認し、実装段階でコードの品質を検証し、テスト段階では網羅性を確認する。AIの出力を鵜呑みにせず、各段階で人間の経験と知識をもとに見極める。こうしたレビューの質が、最終的なアウトプットの品質を決めます。
AIは「対等な仕事のパートナー」だと考えています。ここで言う「対等」とは、AIが人間と同じ判断力を持つという意味ではありません。AIの出力を一方的に受け入れるのではなく、自分の経験と知識をもとにフィードバックし、より良いアウトプットを一緒に作り上げていく――その対話の姿勢を指しています。
AIは「魔法の杖」ではありません。ただ振るだけでは期待どおりの成果は得られません。しかしPlaybookという土台を整え、段取り管理のスキルを磨き、適切な役割分担の中で使いこなすことで、AIは強力な開発パートナーになります。
現在、段取り管理は人間である私自身が担っていますが、将来的にはこの部分もAIに任せていくことを検討しています。タスクの優先順位判断や確認タイミングの調整など、今は人間の行っている管理業務も、AIの進化とともに委ねられる範囲が広がっていくと考えています。
並列開発という成果は、こうした一つひとつの積み重ねがあって初めて実現できたものです。これからもAIと一緒に、より良い開発を目指していきたいと考えています。
食べログでは、一緒に働く仲間を募集しています。
ご興味のある方は、ぜひ採用情報をチェックしてみてください。
