第1章：責任分界（人間 / エージェント / CI）
この章で扱うこと
- 人間の責務（仕様化/承認/責任）と、エージェントの責務（調査/実装/反復）の分離
- CI の責務（品質ゲート、監査可能性）
なぜ責任分界が必要か
AI を開発プロセスに組み込むと、作業速度が上がる一方で、誤変更も同様に高速化します。 そのため、「誰が何に責任を持つか」 と 「どこで自動化を止めるか」 を先に決めておく必要があります。
本書では、最小構成として次の 3 者に分けます。
- 人間：仕様（Issue）、承認（Review）、責任（Merge）
- エージェント：調査/実装/反復（ただし意思決定は代替しない）
- CI：品質ゲート（テスト/静的解析/ポリシー）と監査可能性
3者モデル（Human / Agent / CI）
Human（仕様・承認・責任）
- 期待成果と受入基準を Issue に落とす（曖昧さを減らす）
- 変更の妥当性をレビューし、必要に応じて設計判断を行う
- マージとリリースに関する最終責任を負う（説明責任を含む）
Agent（調査・実装・反復）
- 既存コード/ドキュメントの調査、影響範囲の洗い出し
- 指定された制約の下での実装、テスト追加、ドキュメント更新
- CI 失敗やレビュー指摘に対する反復（小さく直し、再検証する）
エージェントは「作業者」であり、責任主体（意思決定者）ではありません。
CI（品質ゲート・監査）
- 再現可能な検証（lint/test/build/link-check など）を機械的に担保する
- ポリシー違反の検知（例：危険コマンド、Secrets の混入、依存更新の妥当性）
- 実行ログが残る形で、変更の品質と経路を監査可能にする
RACI（例）
運用設計の初期は、RACI（Responsible/Accountable/Consulted/Informed）を置くと合意形成が速くなります。
| 作業 | Human | Agent | CI |
|---|---|---|---|
| 仕様化（Issue） | A/R | C | I |
| 実装（コード変更） | A | R | C |
| テスト追加 | A | R | C |
| 検証（テスト/静的解析） | A | C | R |
| レビュー | A/R | C | I |
| マージ | A/R | I | C |
注記: R=Responsible（実行責任）、A=Accountable（最終責任）、C=Consulted（相談先）、I=Informed（通知対象）
境界設計の要点
- 仕様の粒度：受入基準が曖昧だと、エージェントの探索空間が増え、手戻りとリスクが増大します。
- 権限とSecrets：最小権限（Least Privilege）を原則にし、Secrets の到達範囲と監査ログを設計します。
- 自動化の停止線：自動化は「提案」までに留め、最終判断（承認/マージ/公開）は人間が担います。
- 失敗の扱い：CI 失敗やレビュー指摘は「原因の切り分け→最小修正→再実行」の短いループで回します。
関連テンプレ（参照）
Companion repo: itdojp/GitHub-AgentOps-companion
- 実行仕様 Issue（エージェント作業依頼）:
.github/ISSUE_TEMPLATE/agent-task.yml - PR テンプレ:
.github/PULL_REQUEST_TEMPLATE.md
章末チェックリスト（ドラフト）
注記: 本チェックリストは最小構成です。組織の運用ポリシー（権限、監査、リリース手順）に合わせて拡張してください。
- Issue が「実行仕様（受入基準・制約・検証）」を満たしている
- エージェントに任せる範囲と、人間承認が必要な範囲が定義されている
- CI で担保する品質ゲート（lint/test/link-check 等）が定義されている