SHOEISHA iD

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

CodeZine(コードジン) ProductZine

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

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

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

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

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

 仕様を定めただけでは、Devinがその通りに仕上げる保証はありません。そもそも仕様が正しく伝わらなければ守りようがなく、伝わっても逸脱は起こり得ます。そこで、仕様を確実に渡して逸脱を防ぎ、それでも生じたズレを見つけて正す仕組みがハーネスです。ハーネスは本来「馬具」のこと。馬を縛り付けるのではなく、自由に走らせつつ方向だけを制御する道具です。AIへの統制も同じで、Devinの自律性を奪わず、逸脱だけを抑えることを目指します。

 ハーネスは書く前に伝える(プロンプトとコンテキストで仕様を渡す)と書いた後に確かめる(ゲートで適合を検証する)の2系統に整理でき、これを4段階で積み上げます。

図1:ハーネスの4段階
図1:ハーネスの4段階

 統制は指示する→教える→機械的に検証する→推論的にレビューする、と一段ずつ積み上げます。書いた後の検証書く前に渡した仕様を合否基準にするため土台なしには働きません。各段の仕組みも、運用で出た失敗を取り込んで育てていきます。

書く前に伝えるハーネス:プロンプトとコンテキストで仕様を渡す

 ここでは、Devinが書き始める前に仕様を渡し、逸脱の余地そのものを減らします。タスクごとに変わるプロンプト(Level 1)と、全セッション共通のコンテキスト(Level 2)の2段で構成します。

Level 1 プロンプト設計:仕様を実行可能な依頼に落とす

 ハーネスの最初の一歩は、タスクごとに変わる依頼をその場で渡すプロンプト(Level 1)です。プロンプトは、仕様駆動とハーネスの合流点にあたります。仕様駆動で定めた中身(要件・設計・受入基準)に、ハーネス固有の制御(前提・禁止事項・終了条件)を上乗せして1つの依頼に組み立てます。

 上乗せする3項目では、先回りで曖昧さを潰すのがコツです。「新人が混乱しそうな箇所」を想像し、先に埋めます。

  • 前提:対象ファイル・関連コードなど、このタスクで参照させたい情報。
  • 禁止事項:明示的に「禁止」と伝えたい制約があれば書きます。たとえば「DBスキーマ変更やpublic APIの破壊的変更は禁止」など。
  • 終了条件:うまくいかないときに止める基準。書かないと、失敗ループから抜け出せず時間とACU(Devinがタスクを実行するために消費する計算リソースの基本単位)を浪費します。

定型作業はPlaybook・Skillsにまとめる

 プロンプトに毎回書く定型作業(OpenAPI定義からのコード生成、ユニットテスト手順など)は、テンプレートとしてまとめておけば毎回書かずに済みます。まとめ先はDevinが用意するPlaybookSkillsの2種類で、粒度トリガーが異なります。Playbookはタスク完遂までの一連の手順書で、人間がセッション開始時に「これで進めて」と明示指定します。Skillsは個別作業の手順で、Devinが必要に応じて自動参照します(Playbook実行中にも自動で読み込まれます)。

表2:手順を再利用する2つの仕組み

仕組み 内容と例 トリガー
Playbook
(粒度:大/手順書)
タスク完遂までの一連の作業手順
例:「画面への項目追加」(仕様に基づく調査→実装→ユニットテスト→E2E→PR作成)
人間がセッション開始時に明示指定
Skills
(粒度:小/個別手順)
特定作業の実行手順
例:「影響範囲調査」「ユニットテスト手順」
Devinが必要に応じて自動参照(Playbook実行中にも自動で読み込まれる)

Level 2 コンテキスト設計:チームの共通前提として渡す

なぜコンテキストが必要なのか

 プロジェクトの技術スタック・アーキテクチャー・コーディング規約といったチームの共通前提は、Devinに明示的に伝えないと新規コードで踏襲されません。かといって毎回プロンプトに書くのは非効率で、書き漏れも起こります。そこで全セッションで参照されるよう、共通設計をコンテキストとして整備します。これがないと、局所最適の積み重ねで全体の一貫性が崩れます。

コンテキストを書く場所

 書く場所はAGENTS.mdKnowledgeの2つです。迷ったらAGENTS.mdに書きます。セッション開始時に必ず全文ロードされ、Gitでバージョン管理でき、DevinやCodexなどの多くのAI開発ツールが読み込む事実上の業界標準だからです。Knowledgeは「リポジトリーを超えて共有したい」「トリガー条件で必要な場面に確実に注入したい」場合に絞ります。

表3:2つの仕組みの使い分け

仕組み 管理場所 読み込みタイミング
AGENTS.md リポジトリー(Gitでバージョン管理) セッション開始時に必ず全文
Knowledge Devin UI トリガーまたはピン留めで参照

次のページ
書いた後に確かめるハーネス:ゲートで仕様への適合を検証する

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

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」など、さまざまなカンファレンスを企画・運営しています。

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

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

メールバックナンバー