SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

DevinではじめるエンタープライズAI開発

Devinの成果物の質を上げる!「仕様駆動」と「ハーネス設計」~仕様を、書く前に伝え、書いた後に確かめて「1回の依頼で80点」を目指す

DevinではじめるエンタープライズAI開発 第2回

 第1回では、Devinの強みが「タスクを丸ごと任せられる自律性」にあることを見てきました。しかし自律性は、使い方しだいで諸刃の剣にもなります。任せて期待どおりの成果が返ればよいのですが、そうでなければ人間はレビューと手直しに追われ、かえって時間を失いかねません。両者を分けるのは、Devinの性能ではなく「依頼のしかた」です。本稿では、1回の依頼でそのまま使える成果物を引き出すための設計「仕様駆動」と「ハーネス」を、プロンプト・コンテキスト・ゲートの3点から解説します。

はじめに:自律性が高いほど、依頼の設計が成果を決める

 第1回で見たように、Devinの強みは自律性です。しかし自律性が高いほど人間の手を離れる時間も長くなり、何を任せ・どう検証するかが成果物の質を左右します。

 今回のテーマは、その「依頼の設計」です。ひとつの目安になるのが、「1回の依頼で80点」という水準です。80点とは、人間が軽く手直しすれば完成に届く水準を指します。この水準に届けば、人間はレビューのボトルネックから外れ、1人で複数のDevinを並行して動かせます。届かなければ、追加の依頼と手直しを繰り返し、結局は人間がボトルネックのままになります。本稿では「商品一覧APIの追加」を題材に、この80点を引き出す依頼のしかたを具体化していきます。

 その鍵となる2本の柱が、「何を作るか」を定める仕様駆動と、「その通りに作らせる」ハーネスです。今回は、まず仕様駆動を、続いてプロンプト・コンテキストからゲートまでを束ねるハーネス設計を解説します。

仕様駆動:何を作るかを定める

 第1回の末尾で予告した「プロンプト設計」を突き詰めると、行き着くのは「何を作るかを正確に伝える」という一点です。あいまいな指示では合否基準が人間の頭の中にしかなく、結果が人のスキルに依存します。仕様駆動はこの「何を作るか」を仕様として明文化し、それを起点に計画・成果物・フィードバックを駆動する考え方です。仕様はDevinに与える正しいゴールであり、後段で「仕様通りにできたか」を判定する基準にもなります。

仕様の3要素:要件・設計・受入基準

 仕様は分厚い設計書ではなく、要件(What:何を作るか)・設計(How:どう作るか)・受入基準(Done:どこまでで完成か)の3要素を明文化したものです。

  • 要件(What):目的・対象ユーザー・主要シナリオ。「何を/誰のために/どんな場面で」が埋まれば十分です。抜けると、Devinはタスクの意図を取り違え、機能はあっても価値のない実装に行き着きます。
  • 設計(How):作り方(インターフェース・エンティティ・処理シーケンス)と、守るべき制約(変えてはいけない既存仕様)。抜けると、Devinは欠けた前提を推測で埋め、組織の方針や暗黙の制約から外れます。
  • 受入基準(Done):通すべきテスト・満たすべき動作・チェック項目。「どこまでできたら完成か」を具体的に書きます。抜けると、後段のハーネス(テスト・CI・レビュー)が機能せず「動いた」ことしか確認できなくなります。

 特に受入基準は着手前に固めるのが重要です。Anthropicも、長時間タスクのハーネスで生成役と評価役がコードを書く前に「完成(Done)の条件」を合意してから着手する設計を採用しています[1]。仕様駆動開発(SDD)の実装であるAWSのKiroやGitHubのSpec Kitは3つ目に実装タスクの分解を置きますが、本稿が受入基準を置くのは、分解はDevin自身が行うからです[2]

[1] Anthropic「Harness design for long-running application development」(Anthropic Engineering Blog)

[2] AWS「Kiro」は requirements.md/design.md/tasks.md、GitHub「Spec Kit」は spec/plan/tasks で構成する。

仕様は客観的に判定できる形で書く

 3要素はいずれも、人によって解釈が分かれない客観的な形で書くことが鍵です。要素ごとに、適した書き方を示します(以下、「商品一覧APIの追加」というタスクを題材に例示します)。

表1:3要素を客観的に書く例

要素 書き方
要件(What) チェックリスト

□ 商品一覧を1ページ20件で表示

□ 30件超でページネーションが出る

□ 未ログインでも閲覧できる

設計(How) 出力形式・インターフェース定義 GET /products?page=N&size=M、レスポンスは { items: [{ id, name, price }], totalCount: number }
受入基準(Done) テスト 新規E2Eテスト「商品30件登録→2ページ目に10件表示」がパス/既存ユニットテスト全件パス

 Ask Devinを活用して、リポジトリーの情報から仕様のたたき台をDevinに作らせるのもいいでしょう。ただし要件と受入基準は「何が欲しいか/何をもって完成とするか」という人間の意思決定です。Devinに下書きさせても、最終判断は人間が下します。

 仕様が具体的であるほど、書いた後の検証は確かな合否基準を持てます。まず仕様を定めることが出発点です。次節からは、この仕様をDevinに守らせる仕組み、すなわちハーネスを見ていきます。

次のページ
ハーネス:4段階で積み上げるAI統制

この記事は参考になりましたか?

DevinではじめるエンタープライズAI開発連載記事一覧
この記事の著者

山河 征紀(ULSコンサルティング株式会社)(ヤマカワ マサキ)

 ULSコンサルティング株式会社  AI駆動開発推進室 室長、AI駆動開発コンサルタント 独立系ソフトウェアハウスでプロジェクトマネージャーとして基幹システム開発を率いたのち、2008年にULSコンサルティングに参画。 ミドルウェア開発とITアーキテクチャ設計を専門とし、インメモリーデータグリッドを...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

名取 美穂(ULSコンサルティング株式会社)(ナトリ ミホ)

 2006年入社以来、上流工程から実装、保守運用まで幅広く手がけてきた。近年は社内各所に点在する知見を収集・整理し、必要な人へ届けるナレッジの普及活動に取り組むほか、DevinをGA直後に自社導入し、Devin Enterpriseの全社展開を主導。現在はDevin管理者として、組織アカウントやワー...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

中野 誠(ULSコンサルティング株式会社)(ナカノ マコト)

 事業会社でのシステム開発を経て、ULSコンサルティングに参画。業務システム刷新、アーキテクチャ設計、スクラム開発、開発プロセス改善などに従事。DDDによるモデリングを得意とし、現場PMとしての実践経験をもとに、技術とプロセスの両面から開発組織の改善を支援している。近年はDevinやClaude C...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/24745 2026/08/03 09:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー