はじめに：使いどころは「任せ方」で決まる
「この作業、Devinに任せられるだろうか」。導入でいちばん知りたいのは、たいていここです。答えは、タスクの種類ではなく どこまで任せるか（任せ方） で決まります。会議の裏で1件を片付けてもらうのか、アラートを合図に自動で起動させるのか、数百を同時に走らせるのか。なかでも効果がもっとも大きいのが、最後に紹介するような「数百ものDevinを同時に走らせる」任せ方です。
第2回で「自律度の低い順に紹介する」と予告したユースケースを、本稿ではその任せ方を軸に、3つのタイプへ分けて見ていきます。ユースケースは各任せ方に付随するものとして紹介します。タイプ1 裏で任せる／タイプ2 自動で動き出す／タイプ3 並列で量をこなすという順に、任せる範囲を一段ずつ広げていきます。広げるのは、1人が1件を投げるところから、起動そのもの、さらに数十〜数百の並列へ、という順序です。タイプごとに、新しく効き始める軸（タイプ1＝非同期／タイプ2＝トリガー自走／タイプ3＝並列）が一段ずつ加わっていく点に注目してください。
任せ方はタイプごとに一段ずつ上がっていきますが、Devinに渡す仕様（＝受入基準）と逸脱を防ぐ禁止事項、それらを検証するハーネス（第2回の機械的ゲート＝CIを中心に）は、どのタイプでも同じ型のままです。第2回の仕様駆動＋ハーネスをそのまま土台に使い、変えるのは任せる範囲だけです。まずはこの3タイプの全体像を押さえましょう（図1）。
タイプ1：裏で任せる
最初の一歩に選ぶなら、（1）影響範囲が限定的で切り戻しやすい、（2）合否を機械判定できる、（3）効果を測りやすい、の3条件を備えたタスクが向きます。小さく安全な成功の積み上げが、エンタープライズでの定着を左右するからです。
具体的には、軽微な修正・テスト追加・カバレッジの穴埋め・ドキュメント整備などです。いずれも1リポジトリー・1機能で完結し、3時間程度で終わる小さなタスクです。こうしたタスクをDevinに投げたら、あとは別の仕事に取りかかれます。朝いちばんに「このテストを足しておいて」と投げておけば、昼にはPRが上がっている。合否はCIが自動で判定するので、張り付いて見ている必要はありません。失敗しても元に戻せるので、任せて離れても安心です。依頼は1タスクずつ・起動も毎回人が行う、いちばん基本の任せ方でもあります。以降はテスト追加を代表例に勘所を見ていきます。
仕様の渡し方と落とし穴
手を離したあとは、途中で軌道修正できません。だからこそ、判断の基準は依頼の時点で決めておく必要があります。決めておくのは、受入基準（できたと言える条件）と禁止事項（踏み込ませない範囲）の2つだけで十分です。受入基準は、「テストを充実させる」のような曖昧な言い方のままにせず、CIが合否を自動で判定できる形（第2回でいうハーネス）まで具体化します。具体的には次のように書きます。
- 新規テストがパスする：追加したテストがグリーンであること
- デグレを起こさない：既存テストの全件パスを維持すること
- 対象箇所のカバレッジが基準以上：例えば「変更対象ファイルの行カバレッジ80％以上」のように数値で固定する
こう書いておけば、裏で走ったDevinのPRを、人が中身を精査しなくてもCIの緑／赤だけで一次判定できます。
一方、付きっきりで見張らないからこそ、禁止事項を先に決めておくことも大切です。テスト追加を任せると、次の3つはとくに起こりがちなので、先回りして塞いでおきます。
- テストを通すために本体を直す：テストが落ちると、テストではなく本体コードのほうを書き換えて緑にしてしまう。挙動が勝手に変わり、バグが「通ったこと」になる。本体の変更は禁じ、テスト追加だけに限定する。本体に修正が要るなら別PRに分ける
- カバレッジ稼ぎの素通りテスト：カバレッジ基準を満たすためだけに、コードを呼ぶだけでアサーションのないテストを量産する。数字は緑でもバグは何も捕まえない。「実行するだけ」を禁じ、1テストに必ず意味のあるアサーションを置かせる
- モックで固めて素通り：依存をモックで固め、結局そのモックの戻り値を検証しているだけの「何も試していない」テストを書く。本物の入出力を検証させ、モックの戻り値そのものをアサーションさせない
導入事例
このタイプの実例がチケット販売事業者（社内内製チーム）です。品質管理を起点に、単体テスト生成やドキュメントの定期メンテナンスといったタイプ1の作業から着手して定着させた好例です[1]。
[1] ULSコンサルティング「ウルシステムズ、ぴあ内製開発チームにおける『Devin』の活用を支援」（2025年6月17日）
