AIが安全に分業できる開発ハーネス

Transcript

1. 1 AIが安全に分業できる開発ハーネス 2つの設計軸がもたらす高い再現性と安全性 合同会社 DMM.com ユーザーレビューグループ 大野 皓介
2. 2 本日伝えたいこと 01 02 main Agent設計（オーケストレーション） 「sub Agentに何を割り当てて‧どこで完了とするか」を決定します sub Agent設計 修正する範囲‧読む rules‧完了条件を設定します
3. 3 Before / After - 設計があるかないかの違い
4. Before PROBLEM 計画がないため、 タスク分解と役割分担が その場判断になる main Agent 計画を作らずに実⾏開始 その場でタスクを分解‧割り振り [Agent A] 役割重複 [Agent B] 範囲不明 [Agent C] 基準不明 重複 ‧ 抜け漏れ ‧ 品質のばらつき
5. 5 After Solution 最初に実⾏計画を明 ⽰し、役割別エー ジェントへ 委譲する main Agent ① 実⾏計画を作成 → 計画承認 (人) → ② 役割別エージェントへ委譲  [unit-test-agent] ルール： unit_test_rules.md [domain-agent] ルール： domain_rules.md [review-agent] ルール： review_policy.md 役割と品質基準が明確になり、再現性のある成果物を⽣成
6. main Agentの設計（オーケストレーション）
7. 7 main Agentの設計：案件の委譲表 要素 (タスク) 割り当て (Agent) 完了条件 Domain実装 (Green) domain-agent 実装コードがテストに完全パス すること 「このタスクでは何を、誰に任せるか」を⽰す委譲表
8. 8 main Agentの設計：一貫したライフサイクルを定義 Step 2 Green (実装) Step 3 lint (静的解析) Step 4 review (検証) ライフサイクルそのものを固定することで、属⼈性を排除した⾼い再現性を担保します。 Step 1 Red (テスト失敗)
9. 9 sub Agentの設計
10. 10 レイヤー構造に合わせた sub Agent設計 他レイヤーへの要な介⼊を防ぐ src/interfaces/... interface-agent src/useacase/... usecase-agent src/domain/... domain-agent src/infra/... infra-agent
11. 11 sub Agentの設計：対象パス・ rules・完了条件の設定 3つの要素 対象パス 変更‧作成を許可する ディレクトリを限定 読む rules 準拠すべき実装パターンや規約 の制限 タスクを完了して良いとする 客観的テスト基準 src/domain/* .cursor/rules/domain/*.mdc 完了条件
12. 12 sub Agentの設計：品質系を作成する レイヤーごとの Agent interface-agent usecase-agent domain-agent infra-agent  品質系 Agent (⾃⼰レビュー防⽌) 客観的検証にのみ専念し、 実装Agentが書いたコードの品質ゲートに なります。 ▪unit-test-agent (Redフェーズ) ▪review-agent (静的コードレビュー)
13. 13 まとめ 誰でも常に同じ品質で開発を再現できるようになります。 ① main Agentの設計 （オーケストレーション） ② sub Agentの設計 実装計画を作成 sub Agentへの割り振り（移譲表） 共通の実⾏⼿順（ライフサイクル） レイヤーごと‧品質系sub Agentを作成 触る範囲‧rules‧完了条件を設定
14. Q&A
15. AIに⾃律実⾏させる前に、⼈間が「成果物（Markdown）」を承認する必須停⽌点を配置しています。 main Agentを100%信頼するのではなく、 レビュー可能な「計画書」をアウトプットさせ、⼈間が修正指⽰を出せる運⽤にしています。 1. 計画策定 要件からタスク分割、委譲表を作成 2. サマリ‧計画承認 【停⽌点】 ⼈間が内容の妥当性を合意 3. ⾃律実⾏ 承認後に各sub Agentへタスクを委譲 Q: main Agentが誤った計画を作った場合は？
16. 全履歴を渡すのではなく、必要な情報だけを抽出した構造化ファイルでバケツリレーします。 受け渡す要素 実体ファイル / 場所 ⽬的（情報のクレンジング） タスクの⽬的‧完了条件 .plans/案件名/index.md ゴールの認識合わせと客観判定基準の共有 役割‧権限‧対象パス .claude/agents/*.md 対象領域外への不要な介⼊とツール使⽤の抑制 実装規約‧ルール .cursor/rules/*.mdc ⼀貫した設計思想の強制と⽭盾の排除 前⼯程の成果物 OpenAPI⽣成物、型定義など 「境界（契約）」として決定的な情報の伝達 Q: Agent間でのコンテキスト受け渡しの⽅法は？
17. 計画書での「進捗管理」 index.md のテーブルを真実のソースとします。 物理的な検証エビデンス Agentの内部記憶に頼らず、以下の物理情報を起点に復 帰判定を⾏います。 API設計 Done Domain実装 Done UseCase実装 InProgress • Git状態： git diff main...HEAD • テスト結果： make test 等の成功エビデンス • レビュー結果： review-agentの判定ログ Q: 状態はどこに保存し、途中からどう再開するか？
18. 指⽰（プロンプト）だけでなく、ツール権限‧環境‧検証の多層防護で制御します。 1. 物理アクセス制限 Agent定義で読書可能なパスを限定 （例: src/infra/ のみ）。 2. ツール権限の剥奪 settings.json で破壊的コマンドを禁⽌ 設定。(rm -rf等) 3. 事後検証レビュー review-agentが差分を確認し、 範囲外への侵⾷を即座に検知。 Q: 対象外への変更を本当に防げますか？
19. 「⾃分で書いて⾃分で直す（⾃⼰レビュー）」を権限レベルで構造的に排除しています。 実装エージェント 検証(review)エージェント • 権限： 書込(Write/Edit)あり • ⽬的： タスクの完遂とコード実装 • 権限： 書込(Write/Edit)なし • ⽬的： 差分とルールに基づく客観的検証 Q: review Agentの客観性はどの程度保てますか？
20. 作成者と実装者を分離し、さらに第3者のレビューを通す多層防御体制です。 1. Red作成 unit-test-agent が要件から 失敗テストを作成 2. Green実装 実装Agentがテストを パスさせる最⼩実装を⾏う 3. 統合検証 review-agent が要件との 整合性を客観チェック Q: テストAgentが誤ったテストを書いた場合は？
21. 基本ライフサイクルは共通ですが、種類に応じて「検証⼿段」を置き換えます。 タスク種類 Red（期待値の定義） Green（実装と証明） アプリコード 失敗テスト作成 make test によるGreen化 API定義 OpenAPI(契約)の確定 make scalar-build での整合確認 DBマイグレーション backend側スキーマ定義先⾏ Repository/Usecaseの実装完了 Q: 実装サイクルはすべてのタスクに適⽤できますか？
22. ⼈間は「作業の承認」ではなく「⽅向性の決定」に特化することで滞留を防ぎます。 ⼈間の役割：停⽌点(Gate) 判断‧承認‧意思決定 AIの役割：⾃律ループ 定型作業‧FBループの⾼速回転 • 案件全体の⽅向性合意（③サマリ） • 実⾏計画の妥当性レビュー（⑤計画） • マージ前の最終品質確認（⑥フェーズ） • Red / Green サイクル • Lint エラーの⾃⼰修正 • review 指摘の反映‧修正 Q: ⼈間の計画承認がボトルネックになりませんか？
23. 完全な担保ではなく「制御しやすさ(Controllability)」を⼤幅に向上させました。 6つの構造的な改善点 再現性の定義 LLMは⾮決定的であり、出⼒の「完全⼀致」は⽬指しません。 • 役割の明確化: 10エージェント体制と委譲表の固定 • 範囲外変更の検知: review-agentによるgit diff確認 • 機械的な完了確認: make test/lintの⾃動パス • 実装とレビューの分離: 検証側の書込権限を物理遮断 • 状態の追跡: 進捗テーブルによる実⾏プロセスの永続化 • 再実⾏の容易性: 実装サイクルとテンプレートの定型化 本ハーネスが担保するもの 「⼿順‧役割‧評価基準」を固定することで、 成果物の品質のばらつきを抑え、安定した品質を提供します。 Q: 安全性や再現性はどの程度担保でき、どう評価するか？
24. 「複数レイヤーを跨ぐ、リスクのある変更」にこのハーネスは特化しています。 軽微な修正 1ファイルのみ、単純な⽂⾔置換な ど 探索的な調査 完了条件が事前に定義しにくい作 業 緊急対応 設計プロセスより即応性が優先さ れる場合 Q: どのようなタスクでは、この構成を使わない？
25. 今の管理 今後の構想：Harness Doc Agent フェーズ やりたいこと Context / Insight ⼈との修正意図の差分を Correction Event として分類 Consistency 既存 rules との重複‧⽭盾を⾃動検証 Integration Diff提⽰ → ⼈間承認したものだけ反映 ‧コード変更時にrulesも同⼀PRで更新 ‧繰り返されるレビュー指摘をルールへ還 元 ‧不要なルールは定期的に⼿動クリーン アップ 提案はDiff、判断は人間 信頼度付与、低信頼は保留 単発の一般論は追加しない Human Feedback Diff-based Confidence Anti-Generalism 人間の修正指示を最優先 Q: rulesの古さや⽭盾は、どう管理していますか？
26. 1つのAgentにすべてを任せず、依存順に直列実⾏します。 各フェーズの完了ごとに⼈間の承認を待って次へ進みます。 Phase 1: 契約 OpenAPI定義 openapi-agent 外部インターフェースを先⾏確定 Phase 2: 基盤 Domain / Infra データ層とビジネスロジックの実装 Phase 3: 接点 UseCase / API 上位レイヤーの結合と エントリーポイント実装 Q: 複数レイヤーの変更がある場合、どのように分担するか？
27. 1. 設計による先⾏制御 (Blueprint) ‧全体設計の管理: main Agentがindex.mdにて横断設計を 明記し管理する。 ‧契約(IF)の先⾏確定: レイヤー実装前にOpenAPI⽣成物や DomainのProtocol/型を定義し、境界線を固定する。 ‧⾃律範囲の限定: 各Agentに⽬的は共有しつつ、変更可能 な「対象範囲」を物理的に制限し侵⾷を防ぐ。 2. 統合レビューによる検証 (Guardrails) ‧横断的検証: review-agentが「レイヤー責務の分離」 「Domainへの逆⽅向依存」といったアーキテクチャ規約 を評価する。 ‧最終品質ゲート: フェーズ完了時の停⽌点および⼈間の PRレビューにて、システム全体の妥当性を最終判断する。 全体最適は、main Agentと統合レビュー（review + ⼈間）の責務です。 sub Agentは「局所実装」に専念させ、レイヤー間の整合性は別の品質ゲートで担保する構造としています。 Q: レイヤー分割による局所最適をどう防ぐ？