AI-DLC Workflow V2のガバナンス: 自社のガイドライン・ポリシーをどう守らせるか
「AIに開発を任せたいけど、うちのセキュリティポリシーや開発ガイドラインはちゃんと守られるの？」。導入を検討するガバナンス部門から、よく聞かれる不安ではないでしょうか。この記事では、AI-DLC Workflow V2が「成果物がガイドラインに合致しているか」をどう担保するのかを整理しましょう。シリーズ第29回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 29AI-DLC Workflow V2のガバナンス: 自社のガイドライン・ポリシーをどう守らせるか This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）シリーズの第29回です。これまで、V2の個別の仕組み（memory、sensors、承認ゲート、review-class、plugin）をそれぞれ単体で見てきました。今回はそれらを「エンタープライズ・ガバナンス」という一つの関心ごとから束ね直します。
今回のゴールは、AIエージェントによる開発でも自社の開発ガイドラインやセキュリティポリシーへの「合致」を担保できる、という見通しを掴むことです。より正確に言えば、「完全に保証する」のではなく、「合致を高い確度で担保し、確認した事実を証跡として残す」ための設計思想を理解することです。
先に結論の骨格を述べておきます。V2は、①ルールを注入し（memory）、②機械で測れる合致は自動検証し（sensors）、③機械で測れない合致は人間が判断して止め（承認ゲート＋review-class）、④確認した事実を監査証跡に残す（audit trail）、という多層構造でガバナンスを担保します。一つの仕組みに頼るのではなく、層を重ねることで「合致の確からしさ」を上げる。これが本記事を貫く中心命題です。
では、そもそも何が課題なのかから見ていきましょう。
2. 課題：お客様の声と、○×で割り切れない問題
AI-DLC Workflowを導入しているお客様から、ガバナンスに関する声が寄せられています。代表的なものを挙げると、次のような内容です。
- 自社のセキュリティポリシーを遵守してほしい
- 自社の品質チェック基準を満たしてほしい
- 各工程に設けた承認ゲートのチェックを通したい
- 自社の開発ガイドラインを守らせたい
- セキュリティチェックシートの全項目を埋められるようにしたい
これらは、AIエージェントによる開発を導入するとき、企業のガバナンス部門が抱く典型的な不安です。ここで重要なのは、課題の重心がどこにあるかです。
ゲートの有無ではなく、合致しているか
一見すると、これらの声は「承認ゲートがあるか」「監査証跡が残るか」といった機能の有無を問うているように見えます。しかし本質はそこではありません。問われているのは、「エージェントが生成した成果物が、自社のガイドラインやポリシーに合致しているか」です。
言い換えれば、ゲートという関所が設置されていること自体は答えの半分でしかありません。関所を通る成果物が、本当にポリシーの中身に沿っているかが重要です。
○×で表せる部分と、表せない部分
そこで一つの区別が効いてきます。ガバナンス要件は「○×（二値）で表せる部分」と「○×では表せない部分」に分かれる、という認識です。
○×で表せる＝機能の有無。 「各工程に承認ゲートがあるか」「監査証跡が残るか」「ルールを宣言的に注入する場所があるか」「自動チェックを工程に差し込めるか」。こうした問いは、V2に該当する機能（承認ゲート、audit trail、memory、sensors）が存在するため、○と答えられます。
○×では表せない＝要件の充足。 「品質チェック基準を満たせるか」は、機械で検証できる項目と、設計の妥当性のように機械では検証できない項目に分かれます。「開発ガイドラインを守らせられるか」は、memoryに記述できても、AIがそれを遵守するかどうかは確率的で、担保の強さにはグラデーションがあります。「セキュリティチェックシートを全部埋められるか」は項目次第で、どの工程で誰がどう埋めるかという運用設計の問題になります。これらは○×では割り切れません。
ここで一つ、正直に述べておくべきことがあります。V2はガバナンスの銀の弾丸ではありません。機械で検証できない品質項目は存在しますし、ガイドラインをmemoryに書いてもAIが完全に遵守する保証はありません。この限界を認めたうえで、「では、どうやって合致の確からしさを上げるか」を設計の問題として扱うのが、V2のアプローチです。
3. 中心命題：合致の担保を4ステップの多層で
では、合致をどう担保するのか。V2の答えは、一つの強力な関門を作ることではなく、性質の異なる担保手段を層として重ねることです。
4ステップの流れ
担保は次の4ステップで構成されます。
- ルール注入（memory） — ガイドラインやポリシーを、エージェントが読むルールとして各工程に注入する
- 自動検証（sensors） — 機械で測れる合致は、承認ゲートの手前で決定論的に検証する
- 人間判断（承認ゲート＋review-class） — 機械で測れない合致は、人間がレビューして工程を止める／進める
- 証跡（audit trail） — 確認した事実を監査イベントとして自動で記録する
この順序には意味があります。まず事前にルールで縛り（①）、機械で確定できることは自動でふるいにかけ（②）、機械では判定できないことを人間の判断に委ね（③）、そのすべての結果を記録として残す（④）。前の層が取りこぼしたものを、次の層が受け止める構造です。
図にすると、次のようになります。
対応表の使い分け
ここで、課題の章で触れた区別が設計に直結します。対応表（○×マッピング）は「機能の有無」の層にのみ用います。「自社のポリシーを宣言的に書く場所はありますか？→○（memory）」「自動チェックを工程に差し込めますか？→○（sensors）」といった具合です。
一方、「要件の充足」は対応表では語れません。充足は、上の4ステップの多層構造で語ります。「このポリシーは、memoryで注入し、機械で測れる部分はsensorsで検証し、測れない部分は承認ゲートで人間が確認する」。合致の担保とは、一行の○×ではなく、この多層の配置そのものです。
4. 3つの担保レイヤー
では、担保の中核となる3つのレイヤーを一つずつ見ていきましょう。それぞれの節の末尾に「できること／できないこと」を対で示します。限界を正直に置くことが、次の層への接続点になります。
4-1. 事前に縛る：memory
最初の層は、ルールを事前に注入するmemoryです。詳しくはMemoryの回（シリーズ第6回 ）で扱いましたが、ガバナンスの観点から要点を整理します。
V2のルールは、ワークスペースの
aidlc/spaces/\<active-space\>/memory/ に、3つの層のファイルとして置かれます。| レイヤー | ファイル | 役割 |
|---|---|---|
| org | org.md | フレームワーク＋組織全体のデフォルト・ガードレール |
| team | team.md | チームが承認したプラクティス |
| project | project.md | このプロジェクト固有の特殊化 |
これらはワークフロー開始時に
org → team → project の順で一つのチェーンとして解決されます。解決モデルはstrict-additive（厳密加算）で、適用可能なルールがすべてエージェントのコンテキストに積み上がります。狭いスコープが広いスコープを暗黙に上書きすることはなく、矛盾するルールは書き込み時点のチェックで止められます。ガバナンスの文脈で言えば、ここが「自社のガイドラインやポリシーを宣言的に書く場所」です。たとえば
org.md に「シークレットをハードコードしない」「入力は境界で検証する」といったルールを置けば、以降のすべての工程でエージェントがその前提を読みます。実際、本リポジトリのフェーズ別ガードレール（phases/construction.md など）にも、こうしたセキュリティ・エラーハンドリングのルールが宣言されています。ただし、ここに最初の限界があります。memoryにルールを書いても、AIがそれを確実に遵守する保証はありません。LLMの振る舞いは確率的であり、ルールの注入は「遵守の確率を上げる」ことであって「遵守の保証」ではありません。だからこそ、後続の層（自動検証と人間判断）で裏取りをします。
できること: ガイドライン・ポリシーを宣言的に注入し、全工程のエージェントに届ける。層（org/team/project）で強制範囲を設計できる。
できないこと: 書いただけでは遵守は保証されない（確率的）。memory単体では「合致したか」を検証できない。
できないこと: 書いただけでは遵守は保証されない（確率的）。memory単体では「合致したか」を検証できない。
4-2. 自動で検証する：sensors＋traceability
2つ目の層は、機械で測れる合致を自動で検証するsensorsです。詳しくはセンサーの回（シリーズ第13回）で扱いました。
sensorsは、承認ゲートの手前で動く決定論的（計算的）な検証です。LLMの解釈に依存せず、プログラムとしてYes/Noを確定させます。位置づけはadvisory（助言）で、ゲートをブロックするのではなく、人間の判断材料を提供します。sensorが失敗しても、人間が「これは意図的だ」と判断すればApproveできます。
V2には標準のセンサーが同梱されています。本リポジトリの
.kiro/sensors/ に置かれているマニフェストで確認できる範囲では、次のようなものがあります。| センサー | 何を検証するか | カテゴリ |
|---|---|---|
| required-sections | 成果物に必要なH2見出しが揃っているか | document-shape |
| claim-sources | 主張ブロックに根拠となるソースタグが付いているか | document-provenance |
| upstream-coverage | 宣言した上流成果物への参照が実際にあるか | document-shape |
| traceability | traceability.json の要素単位の被覆・ターゲット・孤立を検証 | document-traceability |
| linter | 生成コードがlintルールに違反していないか | code-quality |
| type-check | 型エラーが残っていないか | code-quality |
各センサーは
.kiro/sensors/aidlc-\<id\>.md というマニフェストで定義され、matches のグロブパターンで発火対象のファイルを絞ります。ステージ側のフロントマターにある sensors: リストが、どのステージにどの検証を適用するかを決めます。ガバナンスの文脈では、「機械で確定できる合致」をここで自動化できます。たとえば「主張には必ず根拠タグを付ける」はclaim-sourcesで、「生成コードに型エラーを残さない」はtype-checkで検証できます。traceabilityセンサーは、要件からコードまでの対応付け（traceability.json）に欠落や孤立がないかを決定論的に確認します。
ただし、ここにも限界があります。sensorsが判定できるのは、パターンが明確でYes/Noに落ちる項目だけです。「この設計はビジネス要件を満たしているか」「このアーキテクチャ選択は妥当か」といった、文脈理解を要する項目は機械判定できません。それは次の層、人間の判断に委ねられます。
できること: 機械で確定できる合致を、ゲートの手前で自動検証し、結果を監査証跡に残す。LLMに依存せず決定論的に判定する。
できないこと: 設計の妥当性のような、文脈理解を要する項目は検証できない。advisoryのため、単体でゲートを止める性質ではない。
できないこと: 設計の妥当性のような、文脈理解を要する項目は検証できない。advisoryのため、単体でゲートを止める性質ではない。
4-3. 工程で止める：承認ゲート＋review-class
3つ目の層は、機械で測れない合致を人間が判断する承認ゲートです。承認ゲートとセッション管理の回（シリーズ第16回 ）で扱った仕組みを、ガバナンスの観点から見直します。
承認ゲートは、各ステージの完了時に人間がレビューし、先に進むか（Approve）、修正を求めるか（Request Changes）を決める関所です。初期化フェーズの3ステージを除く各ステージに設置されています。エージェントがどれだけ成果物を生成しても、人間がApproveしない限り工程は先に進みません。
ここが「機械で測れない合致」を担保する層です。ポリシーへの合致のうち、sensorsで確定できない部分（設計判断の妥当性、要件の充足度、文脈に照らした適切さ）は、人間がゲートで確認します。
このゲートの手前には、レビュー専任エージェントによる自動レビューを置けます。レビューの強度を制御するのがreview-classで、Reviewer Classの回（シリーズ第22回 ）で扱いました。review-classは3段階です。
- adversarial（反論型）: レビューエージェントが成果物を「反論」し、NOT-READYならリードが修正して再レビューする反復ループ
- advisory（助言型）: 1回だけのレビューパス。所見を出すが修正ループには入らず、判定を承認ゲートに引き渡す
- none（レビューなし）: レビューエージェントを起動しない
有効なクラスは、「ステージ宣言
review_class」「スコープ上限 review_cap」「実行時オーバーライド --review」の3入力から、low-wins（最も軽いものが勝つ）で決まります。ガバナンスの文脈では、承認ゲートが「最後の砦」です。機械で取りこぼした合致を、人間の判断で止める。そして、この判断はadvisoryなsensorsの結果やレビューエージェントの所見を材料にして行われます。
ただし、ここにも限界があります。承認ゲートは人間の判断に依存するため、判断の質はレビュワーの力量と注意に左右されます。また、ゲートは「止める」仕組みであって、「何が正しい合致か」を定義する仕組みではありません。何を基準に承認するかは、人間が持ち込む必要があります。
できること: 機械で測れない合致を人間が判断して止める／進める。レビューエージェントの所見やsensorsの結果を判断材料にできる。承認・却下を監査証跡に記録する。
できないこと: 判断の質は人間に依存する。承認基準そのものはゲートが定義しない（運用で持ち込む）。
できないこと: 判断の質は人間に依存する。承認基準そのものはゲートが定義しない（運用で持ち込む）。
証跡は記録するだけでなく活用する
4ステップの最後、④証跡（audit trail）について補足します。ここで強調したいのは、証跡は記録するだけでなく、確認し活用することも同じく重要だという点です。
V2は、どのルールに対して、どの成果物が、誰のレビューと承認で合致を確認されたかを、監査イベントとして自動的に記録します（
GATE_APPROVED、REVIEW_COMPLETED など）。この記録は「記録して終わり」ではなく、後から振り返り・共有・追跡に使えます。Audit Trailの回（シリーズ第21回）で扱った活用手段を、ガバナンスの観点から挙げます。- replay（
/aidlc-replay）: 監査ログと成果物から、何が・どの順序で・なぜ決まったかを読みやすいナラティブとして再生します。読み取り専用で、ワークフローの状態は変更しません。セッションに参加していなかったガバナンス担当者が、合致を確認した経緯を後から追う用途に向きます。 - outcomes-pack（
/aidlc-outcomes-pack）: ワークフロー完了後に、引き継ぎ文書OUTCOMES.mdを生成します。何が作られ、どう確認され、どう続けるかをまとめた形で、監査対応やチームへの引き継ぎに使えます。 - 監査イベントの時系列: インテントごとに蓄積された監査イベントは、時系列として後から再構成できます。「このステージの承認はいつ・誰が・どの根拠で行ったか」を特定の観点で辿れます。
ガバナンスの観点では、ここが効いてきます。合致を確認した事実が構造化された形で残り、しかもそれを後から読み返せる。「証跡が残る」だけなら受け身の記録ですが、replay や outcomes-pack で能動的に確認・共有することで、監査対応やレビューが工程の副産物として成立します。承認ゲートで合致を判断し（③）、その判断を証跡に残し（④）、残した証跡を活用して振り返る。この往復が、ガバナンスを「一度通せば終わり」ではなく継続的に点検できる仕組みにします。
5. 応用：組み合わせ・工夫でガバナンスを作り込む
3つの層は、単独で使うより組み合わせたときに効きます。では、具体的な作り込みのパターンを見ていきましょう。ここで扱うのは、本リポジトリの一次情報で確認できた範囲の運用です。
A. review-classの濃淡でレビュー強度を設計する
review-classは工程やリスクに応じて使い分けられます。本番相当の重要な設計・実装ステージは
adversarial で反復レビューをかけ、PoCや軽量な工程は advisory で単発の所見にとどめる、といった濃淡です。実際、本リポジトリのスコープ定義では、
bugfix・poc・workshop が review_cap: advisory を宣言し、スコープ全体でレビューを軽量側に寄せています。一方 enterprise や feature はreview_capを宣言せず、ステージ宣言のクラスをそのまま使います。リスクの高い仕事ほど厚いレビューを、という設計を宣言的に表現できます。B. 人の指摘をcustom sensorに格上げする（learnings連携）
人間がレビューで繰り返し指摘する観点のうち、機械で判定できるものは、custom sensorに格上げして次回から自動検出できます。
V2には学習ループ（learnings）という仕組みがあり、人間のフィードバックをプロジェクト固有のルールとして永続化します。この学習ループの中で、人間がある学習を「センサーとして残す」と判断すると、学習ゲートのツールがマニフェストの作成と発火元ステージへの紐付けを行います（監査イベント
SENSOR_PROPOSED）。この紐付けは次回のワークフローから自動で有効になります。カスタムセンサーの用意は、人間が能動的に設計するパスと、学習ループが提案するパスの両方から起こりえます。ガバナンスの観点では、これは「人間の暗黙知を、機械で守れる形に移す」運用です。最初は人間がゲートで指摘していた項目を、検証可能なものから順にsensorsへ移し、人間の判断を本当に判断が要る項目に集中させていきます。
具体例：「許可されていないライセンスのOSSを使用しない」
ここで一つ、具体的なルールで「memoryに書くこと」と「sensorで機械チェックすること」の違いを確かめておきましょう。「許可されていないライセンスのOSSを使用しないこと」という開発ガイドラインを例にします。このルールは、1つの中に「機械で測れる部分」と「測れない部分」が同居する例です。
このルールは、次の3層に分かれます。
- memoryに書く（方針を伝える） —
org.mdなどに「許可されていないライセンスのOSSを使用しないこと」と記述すれば、エージェントはこの方針を読みます。ただし、ここで注意が必要です。memoryに書いただけでは、エージェントが実際に許可外ライセンスの依存を避ける保証はありません。遵守は確率的で、「書いたから守られる」とは言えません。 - custom sensorに落とす（機械判定できる大部分を自動検出する） — ここが機械チェックの肝です。依存マニフェストやlockfile（
package.json、pom.xml、Cargo.tomlなど）を走査して依存を列挙し、各依存のライセンスを取得して、許可リストと照合する。禁止ライセンスがあれば違反として検出する。この処理をcustom sensorとして実装すれば、承認ゲートの手前で自動的に走ります。ここで重要なのは、memoryに方針を書くこととは別に、許可リストとライセンス抽出ロジックを持ったsensorを作って初めて機械チェックになる、という点です。memoryの記述がそのまま検証に変わるわけではありません。 - 人間レビューで判断する（グレーゾーン） — 機械判定には限界があります。ライセンス表記が欠落・不正確で抽出できないOSS、デュアルライセンスでどちらを選ぶかの判断、「許可リストにないが実質同等で許容してよいか」という例外判断。これらは○×では確定せず、承認ゲートで人間が判断します。
つまり「許可されていないライセンスのOSSを使用しない」というルールは、memoryに書く（方針）、custom sensorで照合する（機械判定できる部分）、人間がゲートで判断する（グレーゾーン）という3層に分かれます。本記事の中心命題、すなわち合致はルール注入・自動検証・人間判断の多層で担保するという考え方が、1つのルールの中で見える例です。
なお、sensorsは位置づけとしてはadvisory（助言）で、ゲートをブロックするわけではありません。検出結果を人間の判断材料として示します。「禁止ライセンスを検出したら必ず止める」ところまで強制したい場合は、第6章で述べる「工程内で守らせる」設計やCI側での失敗扱いと組み合わせます。
C. memory階層の使い分けで強制範囲を設計する
ルールの強制範囲は、memoryの3層（org/team/project）で設計できます。組織全体に効かせたいガバナンスルールは
org.md に、チームの合意事項は team.md に、このプロジェクト固有の制約は project.md に置きます。3層のルールはどれかが別のどれかを打ち消すのではなく、すべてが足し合わされて効くため、どの層に置くかが「どこまで広く効かせるか」の設計そのものになります。E. practices-discoveryで規約を明文化する
チームの既存のガバナンス規約がある場合、practices-discoveryで明文化できます。practices-discoveryはInceptionフェーズのステージで、チームのやり方を聞き取り、affirmed practices（承認された実践）として記録します。
本リポジトリの
org.md にも、practices-discoveryで ## Mandated（ALWAYS …）と ## Forbidden（NEVER …）のルールが追記される旨が記されています。ここで明文化された規約は、以降の工程にルールとして効きます。「暗黙のチーム規約」を「工程に効く明文のルール」へ変える入り口が、practices-discoveryです。6. セキュリティチェックシートを工程内で守らせる
お客様の声の中でも具体的だったのが、「セキュリティチェックシートの全項目を埋められるようにしたい」というものでした。これを題材に、3つの層をどう組み合わせるかを見ていきましょう。
ポイントは、チェックシートを「後付けで証跡をマッピングする」のではなく、「守らないと工程が進まない設計」に落とすことです。項目の性質ごとに、担う層が変わります。
項目の性質で層を割り当てる
チェックシートの項目を、3つの性質に分けて考えます。
機械判定可能な項目 → custom sensorで自動検出する。 「シークレットがハードコードされていないか」「特定の危険なパターンが含まれていないか」のように、プログラムで検出できる項目は、custom sensorで自動検証します。センサーの標準同梱とカスタム追加の仕組みは、センサーの回（シリーズ第13回）で扱ったとおりです。発火対象を
matches グロブで絞り、作成したセンサーの id を、発火させたいステージ定義の sensors: リストに追記して紐付けます（学習ループ経由ならこの紐付けは自動で行われます）。宣言できる項目 → memory(rules)で各ステージに強制する。 「入力は境界で検証する」「エラーは握りつぶさない」のように、エージェントの振る舞いとして宣言できる項目は、memoryのルールとして注入します。本リポジトリの
phases/construction.md には、まさにこうしたセキュリティ・エラーハンドリングのルールが宣言されています。人間判断が要る項目 → 承認ゲートの承認基準に組み込む。 「この設計はセキュリティ要件に照らして妥当か」のように、文脈判断が要る項目は、承認ゲートの承認基準に組み込みます。レビューエージェント（adversarial／advisory）の所見を材料に、人間がゲートで確認します。
証跡は副産物
ここで強調したいのは、設計の重心が「守らせること」にある点です。sensorsは工程の手前で機械検証をかけ、memoryのルールは各ステージのエージェントに届き、承認ゲートは人間がApproveしない限り先に進ませません。つまり、チェックシートの項目を「工程の中で守る」仕組みに織り込みます。
そして、その結果として監査証跡が残ります。sensorsの
SENSOR_PASSED／SENSOR_FAILED、承認ゲートの GATE_APPROVED、レビューの REVIEW_COMPLETED といったイベントが、audit trailに自動で記録されます。証跡は「後から埋める書類」ではなく、「守る過程で自動的に落ちてくる副産物」です。チェックシートを埋めるための作業ではなく、工程を正しく通った事実が記録として残る、という順序になります。7. 自社ガバナンスに合わせて作り込む
最後に、自社固有のガバナンスへの作り込み（カスタマイズ）を見ていきましょう。詳しい手順はPluginの回（シリーズ第23回 ）で扱っています。
作り込みには、変更対象の置き場所で2つの経路があります。この区別はガバナンス上も重要なので、先に押さえておきます。
- プロジェクト直下への追加（project-tier）: このプロジェクトのハーネスディレクトリ（
.kiro/）配下に直接足す経路です。たとえば学習ループが custom sensor を用意するとき、.kiro/sensors/aidlc-\<id\>.mdを作ってステージに紐付けます。このプロジェクト限定の追加で、配布や再利用は想定しません。フレームワーク本体のソース（core/）を書き換えるわけではありませんが、このインストールのハーネスに直接足す形です。 - プラグイン経由（配布可能）:
plugins/\<name\>/という独立したディレクトリに束ねる経路です。作者が所有・バージョン管理し、他のプロジェクトへ配布・再利用できます。core/も合成後の.kiro/の手編集も避けられます。
どちらを選ぶかは「このプロジェクトだけで使うか、配布して再利用するか」で決まります。以下、具体的な手段を、どちらの経路に属し・誰が実行し・どのファイルを変えるかとあわせて見ていきます。
カスタムスコープ
自社標準プロセスを一つのスコープとして保存できます。V2のスコープは「どのステージをEXECUTE（実行）し、どれをSKIP（スキップ）するか」を定義したものです。自社の標準的な進め方に合わせてステージ構成を固め、再利用可能なスコープとして保存できます（監査イベント
SCOPE_SAVED）。ここで注意したいのは、この保存操作は人間が手で打つものではなく、「このプランをスコープとして保存したい」と頼むとワークフロー（コンダクターのエージェント）が実行する、という点です。保存されたスコープは
aidlc/scopes/\<name\>.md に記録され、ハーネス側（.kiro/scopes/aidlc-\<name\>.md）と、ルーティングが読むコンパイル済みのスコープ定義に反映されます。保存後は、新しい作業を始めるときにそのスコープ名を指定すれば、自社標準の工程構成を毎回再現できます。custom sensor（2つの経路：project-tier 直接追加 / プラグイン配布）
標準の同梱センサーでカバーできない自社固有の検証ルールは、custom sensorで追加します。センサーは2つのファイルに触れる作業で成立します。
- マニフェストを作る —
.kiro/sensors/aidlc-\<id\>.md（または配布するならプラグイン配下）に、センサー定義を置きます。フロントマターの主なフィールドは、id（識別子）、command（検証を実行するコマンド）、matches（発火対象ファイルを絞るグロブ）、default_severity（advisoryなど）、fire_on（gateなど発火タイミング）です。 - ステージに紐付ける — 作成したセンサーの
idを、発火させたいステージ定義のフロントマターにあるsensors:リストに追記します。「sensors:に紐付ける」とは、この id の追記のことです。ここに載せたステージでだけ、そのセンサーが走ります。
この2つがどちらの経路で行われるかで、置き場所と実行主体が変わります。
- project-tier（このプロジェクト限定）: 学習ループ経由で用意する場合、学習ゲートのツールが
.kiro/sensors/aidlc-\<id\>.mdの作成と発火元ステージのsensors:への追記を、同一の処理の中で自動的に行います（SENSOR_PROPOSED）。人間が手でsensors:を編集する前提ではありません。このプロジェクトのハーネスに直接足す形で、配布は想定しません。 - プラグイン経由（配布可能）:
plugins/\<name\>/配下にマニフェストを置き、合成（後述）で取り込みます。作者が所有・バージョン管理でき、他プロジェクトへ再利用できます。
いずれの経路でも、次回のワークフローのコンパイル時点からそのセンサーが有効になります。機械で判定できる自社ルールを、工程内の自動チェックとして組み込めます。
レビューの観点を自社仕様にする
「自社の観点で成果物をレビューしてほしい」という要望も、カスタマイズで応えられます。ただし、ここでも○×で割り切れないため、2つの手段を使い分けるのが要点です。
まず、レビューエージェント（LLM）は確率的に動くため、「自社の観点を毎回必ず漏れなく指摘する」保証はありません。これはmemoryのルールと同じ性質です。したがって、自社の観点のうち機械で判定できるものは、レビューエージェントに期待するよりcustom sensorにするほうが確実です。sensorは決定論的に毎回同じ観点を検査します。「自社の観点でチェックしてほしい」の多くは、実はこちらで満たせます。
一方、判断を要する観点（設計がポリシーの趣旨に沿うか、例外が妥当かなど）は、レビューエージェントのペルソナを自社仕様にする方法があります。V2のレビューエージェントはペルソナにレビュー観点を持っており、既存エージェントを土台に自社の観点を持つカスタムエージェントを構成できます。ただし、カスタムエージェントもLLMである以上、観点を書いても毎回必ずその観点で指摘する保証はありません。最終的な合致の判断は、承認ゲートで人間が担います。
整理すると、「自社の観点でチェックしてほしい」は、機械で測れる観点はcustom sensor（確実・毎回同じ）、判断を要する観点はカスタムエージェントの助言＋人間ゲート（LLM単体では非保証）、という役割分担になります。レビューエージェントのペルソナだけに頼るより、この分担のほうがガバナンス担保としては確実です。
プラグインでステージ・エージェントを足す（配布可能）
自社固有の工程を、正規のステージとしてワークフローに組み込むこともできます。Pluginの回（シリーズ第23回 ）で扱ったとおり、プラグインは
core/（フレームワーク本体）を一切編集せず、追加したいものを plugins/\<name\>/ という独立したディレクトリに束ねます。具体的な置き場所は次のとおりです。- ステージを足す:
plugins/\<name\>/stages/\<phase\>/\<slug\>.md（\<phase\>がフェーズのディレクトリ、ファイル名の語幹が slug）に、通常のステージファイルを置きます。frontmatter にplugin: \<name\>を書き、scopes:に有効化したいスコープを列挙します。scopes:に載せたスコープでだけ、そのステージが動きます。 - エージェントを足す:
plugins/\<name\>/agents/\<plugin\>-\<role\>-agent.mdにエージェント定義を置きます。frontmatter のnameはファイル名の語幹と一致させ、plugin:に自分のプラグイン名を設定します。合成後に自動で発見され、自分のプラグインのステージがlead_agentやsupport_agentsとして指名できます。 - 既存ステージを壊さず拡張する（contribution）: 標準ステージに確認手順や成果物を足したいときは、元のステージファイルに触れず、
plugins/\<name\>/contributions/\<phase\>/\<slug\>.mdに足したい内容だけを置き、合成のときに重ね合わせます。
合成と選択。 プラグインを配置したら、合成（
aidlc plugin sync）が (1) 新規ファイルのコピー、(2) contribution の既存ステージソースへのマージ、(3) スコープ・ステージ定義の再コンパイル、を行います。再コンパイルは合成の一部として走るため、通常は手で叩く必要はありません。そして、どのプラグインを有効にするかはインストール側（人間）が選びます。aidlc plugin list で確認し、aidlc plugin select aidlc,\<name\> で有効集合を指定します。「プラグインは（作者が）足す、インストール側（人間）が選ぶ」という分担です。すべてのプラグインを無効にすれば、インストールは素の core と同一に戻ります。ガバナンスの観点では、これは「自社固有の工程を、スキップできない正規の関所として組み込む」手段です。たとえば自社固有のセキュリティレビュー工程を一つのステージとして定義し、該当スコープで必ず通るように配置すれば、「守らないと進めない設計」をワークフローのレベルで表現できます。プラグイン経由なら本体を書き換えないため、フレームワークの更新にも追従しやすくなります。
なお、カスタムエージェントやカスタムステージの詳細な作り方、委任型ステージでのハーネス固有の登録などは、Pluginの回（シリーズ第23回 ）で確認できる範囲が正確です。
8. おわりに
この記事では、V2がエンタープライズ・ガバナンスへの「合致」をどう担保するのかを見てきました。
要点を整理します。
- 課題の重心は「合致しているか」: ゲートがあるかどうかではなく、成果物がガイドライン・ポリシーに合致しているかが本質です
- ○×で割り切れる部分と割り切れない部分: 対応表（○×マッピング）は機能の有無の層にのみ使い、要件の充足は多層構造で語ります
- 4ステップの多層: ①memoryでルールを注入し、②sensorsで機械的に検証し、③承認ゲート＋review-classで人間が判断し、④audit trailに証跡を残します
- 各層の限界を次の層が補う: memoryは遵守を保証しない、sensorsは機械判定できる項目に限る、ゲートは人間の判断に依存する。だから層を重ねます
- 守らせる設計、証跡は副産物: チェックシートは後付けのマッピングではなく、工程内で守る設計に落とし、その過程で証跡が自動的に残ります
- 自社向けの作り込み: カスタムスコープ、custom sensor、カスタムステージ・pluginで、自社固有のガバナンスを工程に組み込めます
最後に、V2はガバナンスへの「完全な合致」を保証するものではありません。memoryにルールを書いてもAIが確実に守るとは限らず、sensorsが検証できない項目も残ります。それでも、性質の異なる担保手段を層として重ねることで、合致の確からしさを着実に上げ、確認した事実を証跡として残せます。
「保証はできないが、高い確度で担保し、記録を残せる」。この誠実な線引きこそ、AIエージェント開発にガバナンスを持ち込むための、現実的で前向きな出発点になります。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 29AI-DLC Workflow V2のガバナンス: 自社のガイドライン・ポリシーをどう守らせるか This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article