タイプ2：自動で動き出す
次は、起動そのものを人の手から離すタイプです。タイプ1では、Devinはいったん動き出せば完遂まで自力で走りますが、動き出すきっかけは毎回人が与えます。この起動の一点が、小さなボトルネックになります。タイプ2は、人が起動する必要そのものをなくします。トリガーになるのは、アラートの発生・Issueの起票・PRの作成といったイベントか、定時実行です。これらを合図に、Devinが人手を介さず自動で起動し、完遂まで走り切ります。
代表的なのが本番障害調査です。障害のアラートが上がると、それを合図にDevinが自動起動し、ログ・コード・過去PRを調べて根拠付きの仮説を提示するところまで自走する。朝出社したときには、原因の初期切り分けがもう終わっている。これがタイプ2の景色です。
仕様の渡し方と落とし穴
人が起動しないぶん、起動のたびに指示を書き足す人もいません。そこで使うのがPlaybook、第2回で扱った「人が毎回書いていた指示をあらかじめ型にした手順書」です。タイプ1で依頼のたびに書いていた指示をPlaybookにまとめ、トリガーに紐づけておきます。第2回では人がセッション開始時に明示指定する使い方でしたが、ここではトリガーに紐づけておくことで、自動起動のたびに必ず同じ指示（仕様）が適用されます。
代表例の本番障害調査で見てみましょう。起動は、Sentry・Datadogのアラートを受けるAutomations（イベントをトリガーにDevinセッションを自動起動させる機能）のWebhookトリガーにつなぎ、そこへ調査用のPlaybookを紐づけます。人が見張らない自走では、そのPlaybookに次の2点を書いておくのが要になります。
- 調査手順：Datadog MCP（Model Context Protocol）などでメトリクスやトレースを引きつつ、ログ・コード・過去PRもあわせて調べ、根拠付きの仮説へ寄せる道筋を示しておく
- 終了条件と禁止事項：どこまでやったら止めて誰に渡すかと、どこから先はやらせないかを明記する。たとえば「根拠付きの仮説・再現手順・影響範囲を提示したら停止し、人間にエスカレーションする」まで。本番環境への変更や本体コードの修正は、調査の途中でも最後でも踏み込ませない
もうひとつの代表が脆弱性パッチの自動PRです。Snyk・Dependabotが上げた更新のうち、破壊的変更でコード修正が要るものやCIが落ちるものを、Devinが引き取ってパッチPRに仕上げます。骨格は障害調査と同じですが、成果物がコードになるぶん、タイプ1と同じ「受入基準＋禁止事項をCIゲートで機械判定する型」をそのまま使えます。受入基準はスキャンがクリア＋既存テスト全件パス。禁止するのは、ignoreを追加したりテストをskipしたりして指摘を「消すだけ」にする対症療法です。受入基準を見かけ上満たしたように見せる、逃げ道になるためです。マージや本番反映といった最後の判断は、障害調査と同じく人間が行います。
こうした障害・脆弱性への対応のほかに、時刻をトリガーに定時起動するものもあります。
- 定時起動タスク：依存ライブラリー更新チェック、週次Changelog生成、定期的なlint・カバレッジ修正などを、Devinの Automations のスケジュールトリガーで回す。第1回の Scheduled Sessions は、この Automations のスケジュール版にあたる
導入事例
「Daily Sentry Error Fixes」は、Devin公式の定例自動実行の例です[2]。毎朝スケジュールで自動起動し、Sentry MCPで前夜のエラーを集め、件数の多い順に原因を分析します。修正コードと回帰テストを含むPRをまとめて起票し、Slackに要約するところまでを自動で行います。朝にはレビュー待ちのPRが揃う、という景色です。先に説明した障害調査が「仮説を提示して止める」運用なのに対し、こちらは修正PRの作成まで進みます。ただし、マージ（＝本番反映）を判断するのは人間です。基盤はScheduled Sessionsで足り、cronを自前で構築する必要はありません。レビューで出た指摘をKnowledgeに登録しておけば、次回以降のPRに反映され、同じ手直しを繰り返さずに済みます。
[2] Devin Docs「Use Case Gallery — Daily Sentry Error Fixes」
タイプ3：並列で量をこなす
最後は、同型の作業を大量に、同時に走らせるタイプです。代表はモダナイゼーションで、JavaバージョンアップやOSSライブラリー差し替えのように、数百〜数千ファイルへ同じ変換を一斉に適用します。新規開発も、ここに入ります。同じ設計・同じ規約にのっとったAPIや画面を、数十〜数百と実装していくからです。1本ずつ中身は違っても作り方は同じなので、まとめて並列に走らせられます。Devinは Managed Devins（Devinが提供する並列実行機能）で数十〜数百セッションを同時に立ち上げられるため、この領域が本領発揮です。ここで並列が加わり、第1回で挙げたDevinの新規性（クラウド・非同期・並列・完遂まで）がすべて出そろいます。
仕様の渡し方と落とし穴
この規模を破綻させずに回すカギは、新しい仕組みを足すことではありません。タイプ1・2で固めた仕様（＝受入基準）と禁止事項、そしてハーネス（CIゲート）を、そのまま「量」へ広げて適用します。このタイプで押さえる前提は、次の4つです。
- 作り方を1パターンに絞る：モダナイゼーションなら変換を「Java 8→17 での特定APIの置換」のように1本に固定する。新規開発なら、設計・規約・共通部品を先に決めて実装の型を1本にする。型が1本だからこそ、多数のセッションが同じ受入基準を共有でき、大量のPRが同じ品質で揃う
- PRを小さく大量に分割する：1PRの粒度を「1クラスぶん・レビュー可能な大きさ」に切る。1PRが数百ファイルに膨れるとレビューが成立しなくなる
- 受入基準を固定する：モダナイゼーションで見るべきは新機能ではなく挙動が変わらないことなので、各PRの既存テスト全件パスをCIの機械判定ゲートに据える。禁止事項は、本体挙動を変える改変の禁止と対症療法の禁止で、タイプ1・2で書いたものをそのまま流用する
- タイプ1・2で受入基準とハーネスを固めておく：このタイプはゼロから始める段階ではない。人が中身を精査しなくてもCIで合否を判定できる状態になって初めて、その型を「量」へ広げられる
並列数が上がるほど問題になるのは、大量に上がるPRのレビューをどう成立させるかです。有効なのは、1PRの粒度を1クラスぶんなど小さく保ちつつ、PR作成時にDevin自身へ一次レビューをさせ、チェック観点を具体的にリスト化して与えることです。引っかかった箇所はその場で人間にエスカレーションし、早い段階で処理すれば、人手のレビューが積み残しで破綻するのを防げます。
導入事例
自治体システム開発事業者は、Java・OSS差し替えのテストコード書き換えを約200セッション同時に走らせ、工数を200人月→50人月へ圧縮しました[3]。モダナイゼーションの代表例です。海外ではLinktree社が、Devinで1か月に300件のPRを起票し、100件をマージしています[4]。新機能の実装をまとめて任せ、この量をこなした例です。新規開発でも、同じやり方が効きます
[3] ULSコンサルティング「ULSグループ、札幌市の基幹システム標準化プロジェクトで『Devin』を活用」（2025年12月24日）
[4] Cognition「Linktree expands social media platform coverage and ships new features with Devin」
ここまでの3タイプを、表にまとめると下記のようになります。
| タイプ | 任せ方 | 主なユースケース | 仕様駆動・ハーネスの当て方 |
|---|---|---|---|
| 1 裏で任せる | 1人が1件を投げ、付きっきり不要で完遂まで待つ | 軽微な修正・テスト追加・カバレッジ・ドキュメント | 受入基準と禁止事項を書き、CIで機械判定する |
| 2 自動で動き出す | アラートや時刻をトリガーに自動起動し自走 | 本番障害調査・脆弱性パッチ自動PR・定時起動タスク | 同じ受入基準・禁止事項に調査手順と終了条件を足してPlaybook化し、Automationsトリガーにつなぐ |
| 3 並列で量をこなす | 数十〜数百セッションを同時に走らせる | モダナイゼーション・新規開発 | 同じ受入基準・禁止事項のまま、作業を1パターンに揃え、PRを1クラス粒度に分割してCIで機械判定する |
