書いた後に確かめるハーネス：ゲートで仕様への適合を検証する
書く前に仕様を渡しても、Devinが指示どおりに仕上げる保証はありません。この「お願いだけでは届かない部分」を「仕組み」で補うのが、ここから扱う書いた後の確認です。
書いた後の確認には機械的ゲートと推論的ゲートの2つがあり、両者はコストと確実性のトレードオフの関係にあります。機械的ゲートは確実性は高いものの、テストやチェックを書く必要があり準備コストが高いため、まずコストの低い推論的ゲートで観点を試し、繰り返し引っかかる項目だけを確実な機械的ゲートに固定するのが実務的です。
Level 3 機械的ゲート：lint・CI・テストでとめる
lint・CI・テストは「書いた後」に働くルールベースの仕組みです。たとえば、lint警告ゼロ、静的解析の指摘ゼロ、テストカバレッジ80％以上、というように各観点に閾値を設けます。下回ったときは、エラー内容をもとにDevinが修正・再実行を自律的に回します。
ただし、すべてのチェックを同じ場所でまとめて回すとムダが出ます。lintは数秒、E2Eテストは数十分。重いチェックを毎回流せば待ち時間が膨らみ、逆に軽いチェックをマージ直前まで遅らせれば初歩的なミスの発見が遅れます。そこでチェックの重さに応じて3層に分けて配置し、軽いものは早く・安く、重いものは通る見込みのあるPRにだけかけます。
表4：3層ゲートの設計
| ゲート | 実行環境・所要時間 | チェック内容 | 商品一覧APIでの例 |
|---|---|---|---|
| PR前ゲート | Devin環境・即時 | lint・型・ユニットテスト | ページネーション計算のユニットテスト |
| PR時ゲート | CI・数分 | 契約テスト・静的解析・セキュリティスキャン | GET /products?page=2&size=10 の契約テスト |
| マージ前ゲート | CI・数十分 | 結合・E2Eテスト | 「商品30件登録→2ページ目に10件表示」E2Eテスト |
PR前ゲートはDevin自身が実施します。lint / test / build のコマンドをDevinに登録（Devinの Blueprints）しておけば、コマンドの失敗時の修正・再実行まで任せられます。
ポイントは失敗メッセージの書き方です。lintやテストの素の出力をそのまま流すのではなく、CIステップやnpmスクリプトで整形して原因・修正方法・参照先を埋め込めば、DevinはCIのログを読んで自力で修正・再実行できます。たとえば：
$ npm run lint:check ❌ Lint失敗: import順違反 (src/products.ts:3) → 自動修正可: `npm run lint:fix` を実行 → 規約詳細: docs/rules/import.md を参照
このように「何が起きたか／どう直すか／参照先はどこか」を構造化して埋め込めば、Devinはこれを読んで npm run lint:fix を自動実行し、参照先の規約も踏まえて再修正します。
Level 4 推論的ゲート：AIがAIをレビューする
機械的ルールでは捉えきれない観点にはDevin Reviewが有効です。REVIEW.mdに書いた規約・アンチパターン等をPRに当てはめ、問題を指摘し、Auto-Fixで直せるものは自動修正します。
推論的ゲートで重要なのが、実装役とレビュー役を分けることです。同じAIに自分の成果物をレビューさせると甘くなりがちだからです。Anthropicも、エージェントが自己評価で甘くなる傾向を踏まえ、実装役に自己レビューさせるよりも、切り離したレビュー役を懐疑的に振る舞わせるほうが有効だと報告しています[1]。
Devin Reviewに与える観点の入り口は、Devin Reviewが読み取るリポジトリー直下の規約ファイルREVIEW.mdに書きます。プロジェクト固有の規約や避けたいアンチパターンなどを書き、規約本体はdocs/rules/に単一情報源（SSOT：Single Source of Truth）として置き、REVIEW.mdからは参照にとどめれば二重管理を避けられます。
仕様駆動とハーネスを1セッションで回す
仕様駆動でゴールを、ハーネスで仕組みを整えました。最後に、両者を1セッションで協働させる運用サイクルを示します。仕様駆動が判断基準を与え、ハーネスがその基準で自律検証します。
仕様駆動開発サイクル：5ステップ
要望を仕様に落とし、その仕様を起点に次の5ステップでセッションを回します。
人間は①要望・②仕様作成・④レビュー・⑤改善を担い、③実装からPR作成までをDevin＋ハーネスに任せます。
仕様駆動レビュー：「動いた」は合格ではない
③で作られたPRでは、変更理由・変更内容・影響範囲・受入基準の検証結果・テスト結果・確認手順を含めて受け取ります。各受入基準に「実行したテスト・確認した動作」を1対1で紐づけさせれば、PRが仕様と検証の対応表になり、レビュアーは読むだけで合否を判定できます。
表5：PRに含める「受入基準 × 検証」対応表（例：商品一覧API）
| 受入基準 | 検証方法 | 結果 |
|---|---|---|
| 商品一覧を1ページ20件で表示 | ユニットテスト products.test.ts::list_default_size |
✅ |
| 30件超でページネーションが出る | E2Eテスト pagination.spec.ts::show_when_over_30 |
✅ |
| 未ログインでも閲覧できる | 契約テスト products.contract.test.ts::anonymous_access |
✅ |
画面上は動いて見えても、セキュリティ要件や仕様の抜けは外からは判別できません。だから徹底したいのは、「動いた」は合格ではないという原則です。合格と呼べるのは「受入基準で検証済み」のときだけです。
不合格を検知し、仕様とハーネスを改善する
④レビューのフィードバックは仕様（受入基準）に紐づけて返します。曖昧なフィードバックではなく「受入基準の5番目が不合格」と具体的に伝えれば、Devinは修正範囲を正確に絞れます。
そして本質は、検知した不合格を、同じ失敗を繰り返さない改善につなげることです。原因に応じて、仕様かハーネスのどこかを強化します。
- Devinがタスクの意図を取り違えた → 仕様を具体化する（仕様駆動）
- 対象ファイルや前提が伝わっていなかった → プロンプトを補う（Level 1）
- 規約と違う書き方を繰り返す → コンテキストを追記する（Level 2）
- 本来止めるべき不備が素通り → 書いた後の確認を強化する（Level 3・4）
失敗は「やり直しのコスト」ではなく、仕様とハーネスを育てる「学習機会」です。
まとめと次回予告
1回の依頼で80点。その鍵は仕様駆動とハーネスでした。
仕様駆動で正しいゴールを定め、ハーネスが4段階で一段ずつ支える。プロンプトとコンテキストで仕様を渡し、機械的・推論的ゲートで適合を検証する。仕様が一貫した拠り所であり、これが品質を組織として安定させるDevin活用の基本戦略です。
ただし、品質を担保できても、何から始めるか・どこまで任せるかの段取りが甘いと、Devin導入は失速します。次回（第3回）では、Devinの任せ方を軸にユースケースを整理します。任せる範囲を段階的に広げながら、明日から始められる具体例と、Claude Code/Codex との違いがどこで決定的になるかを示します。
