AI-DLC Workflow V2のcollaboratorとguard policy: 専門エージェントを加える設定と、承認後に中身が変わったら止めるか進めるかの設定
「専門エージェントを呼ぶか、lead だけで進めるか」。「承認したものが後から変わったら、止めるか、記録して進めるか」。AI-DLC Workflow V2.11.0で、この2つをそれぞれ切り替える設定が実装されました。参加するエージェントを決めるのが collaborator、承認後の変更の扱いを決めるのが guard policy です。独立した2つの軸を、今回は順番に見ていきましょう。シリーズ第30回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 30AI-DLC Workflow V2のcollaboratorとguard policy: 専門エージェントを加える設定と、承認後に中身が変わったら止めるか進めるかの設定 This article
1. はじめに
本記事はV2解説シリーズの第30回です。新しく設定できるようになった2つのスイッチ、collaborator の on/off と guard policy の strict / relaxed / off を取り上げます。
スコープや深度の調整を扱った回 で「どのステージをどれだけ手厚く進めるか」を見ました。collaborator と guard policy は、スコープが決める既定とは別に、作業ごとに切り替えられる設定です。前者はステージに専門エージェントを加えるかどうか、後者は承認したものが後から変わったときの扱いを決めます。
この記事では、2つがそれぞれ何を切り替えるのか、どう頼むのか、スコープごとの既定はどうなっているのか、そしていつ on にして、いつ off にするのかを見ていきます。独立した2つの軸なので、まず collaborator から順番に整理しましょう。
2. collaborator on/off とは
collaborator の on/off は、ステージに参加するエージェントの範囲を切り替える設定です。
V2のステージには、作業の主担当となる lead エージェントがいます。ステージによっては、そこに専門分野を持つ support エージェント（collaborator と呼びます）が加わって、一緒に作業します。たとえばセキュリティやコンプライアンスの観点を持つエージェントが、lead の書いた成果物に脇から意見を出すといった形です（エージェントの顔ぶれはエージェントの解説記事 で紹介しています）。
collaborator を on にすると、lead に加えてこうした専門エージェントが参加します。off にすると、lead が単独で進めます。off のとき、各ステージは lead だけで動きます。複数の専門エージェントが同時に意見を出す形や、連鎖して引き継ぐ形のステージでも、off なら lead がその役割を単独で担います。
ここで押さえておきたいのは、off にしても、ステージが本来書くべき成果物はそのまま作られるという点です。参加するエージェントの数が変わるだけで、作られるものが減るわけではありません。
もう1つ、collaborator の on/off とは別の仕組みとして、成果物をあとからチェックする reviewer があります。reviewer は collaborator とは独立していて、collaborator を off にしても影響を受けません。レビューはレビューとして、別に動きます。
では、なぜ off という既定があるのでしょうか。collaborator は、enterprise を除く組み込みスコープで既定が off です。これは、最初の1回を軽く始められるようにしておき、専門エージェントを加えるのはチームが必要と判断したときに意識して行う、という考え方によるものです。
off のメリットは具体的です。専門エージェントを呼ばないため、ステージごとに動くエージェントの数が減り、読み込む情報も lead のものだけで済みます。複数の専門エージェントが参加するステージでは、エージェントどうしのやり取りがそれだけ増えますが、off ならそのやり取りがなく軽く進みます。私が試したところ、同じ作業を collaborator off と on で進めたとき、off は on のおよそ半分ほどの時間で完了しました。
言い換えれば、collaborator は「専門エージェントを加えるか、lead だけで進めるか」のスイッチです。手早く進めたいか、専門エージェントを交えて手厚く進めたいかを選べます。
3. guard policy strict / relaxed / off とは
続いて guard policy を見ていきましょう。V2には、誰も頼んでいない変更を止めるためのチェックがいくつかあります。これらのチェックは、もともとエージェント（ワークフロー）の動きを抑えるための仕組みでした。ところが、以前のバージョンではこの変更が人が決めたことなのか、AIが誤って編集したのかを区別できず、人の操作まで止めてしまう場面がありました。そこで「チェックはエージェントへの関門、鍵は人が握る」と整理し直し、1つの設定でまとめて切り替えられるようにしたのが guard policy です。
つまり、あなたが頼んだことはそのまま通し、チェックが働くのは、誰も頼んでいない動き（承認済みの入力が後から変わる、本来の手順を飛ばして状態を書き換える、など）に対してだけ、という設計です。guard policy は、その関門をどこまで働かせるかを strict / relaxed / off の3つの値で切り替えます。
まず1つめの働きは、承認済みの入力が後から変わったときの扱いです。V2では、あなたがいったん承認したものや確認したものが、あとから変わることがあります。たとえば承認済みの計画が、ビルドを始める前に書き換わるような場合です。
- strict: その承認を開き直します。作業はいったん止まり、何が変わったかを1文で示して、もう一度あなたに確認します。
- relaxed と off: そのまま進めます。変わったことは記録に1行残り、あなたには1行で知らされますが、作業は止まりません。承認やその根拠は消えず、そのまま保たれます。
ここで押さえておきたいのは、strict が止まるのは「承認した当の入力が変わったとき」だということです。承認後に別の作業が動いただけなら、どの値でも止まらず、変わったことを1行記録して進みます。strict は、承認の前提が崩れた場面に絞って立ち止まる仕組みです。
2つめの働きは、いくつかのチェックをどこまで働かせるかです。V2には、誰も頼んでいない変更を止めるためのチェックがいくつかあり、guard policy の値によって、そのうちどれを働かせたまま／ゆるめるかが変わります。
| guard policy | ゆるめるチェック（何を対象に止めるか） |
|---|---|
| strict | ゆるめない（すべて働かせる） |
| relaxed | 計画の再承認（承認済みの計画が、承認後に変わった状態でビルドに進むこと）と、レビュー済み内容の凍結（レビューを受けた成果物を、受理後に書き換えること）をゆるめる |
| off | 上の2つに加えて、状態遷移の直接操作（ワークフロー本来の手順を飛ばした状態の書き換え）と、レビュアーの読み取り範囲（レビュアーが担当外の内容まで読むこと）をゆるめる |
どの値でも、「人の承認そのもの」を担保するチェックはゆるめません。あなたの承認が確かにあなたのものであることは、どの設定でも守られます。ゆるめられたチェックが何かを通したときは、そのつど記録に残ります。
言い換えれば、guard policy はエージェント側の関門をどこまで開けておくかのスイッチです。strict は、承認の前提が崩れたら立ち止まって確認し、relaxed と off は記録を残して進みます。
4. 設定方法
これらの設定は、チャット内の会話で頼めば切り替えられます。たとえば、
- 「専門エージェントを呼んで」→ collaborator が on になり、いまの作業で専門エージェントが参加します。「ここから先は lead だけで」と言えば off に戻ります。
- 「ファイルが変わっても再承認を求めないで」→ guard policy が relaxed になり、変更は1行記録して進むようになります。
- 「変更に厳しくして」→ guard policy が strict に戻り、承認の前提が崩れたら確認し直すようになります。
ここで1点、guard policy を relaxed や off に下げるのは、本人からの依頼があってはじめて行われます（会話での依頼でもコマンドでも構いません）。チームの決まりとして strict が記録されている場合は、下げる依頼は断られ、その決まりが書かれたファイルが示されます。strict に戻す（厳しくする）方向は、いつでも会話でそのまま行えます。
設定を頼むときに大事なのが、どこまで及ぶかです。これらは、作業の単位で切り替えます。いま進めている作業にだけ効き、次の作業では、またそのスコープの既定に戻ります（collaborator には、このほかに環境全体で一括して無効にする切り替えもあります）。切り替えたあとは「どこに効いたか」が1行で示されます。
この記事では、設定ファイルの中身やコードには踏み込みません。会話で頼むのが手軽な方法です。
会話のほかに、専用のコマンドでも切り替えられます。
| 設定 | 作業単位で切り替え | 環境全体で無効化 |
|---|---|---|
| collaborator | /aidlc --collaborators on|off | AIDLC_DISABLE_COLLABORATORS=1 |
| guard policy（全体） | /aidlc --guard-policy strict|relaxed|off | — |
| guard policy（個別のチェック） | /aidlc config set guard.<fence> on|off | — |
guard policy を relaxed や off に下げる場合は、前述のとおり本人からの依頼として扱われ、チームの決まりで strict が固定されているときは断られます。
5. 各スコープでの既定
では、何も頼まなかったときに2つの設定がどうなっているか、スコープごとの既定を見ていきましょう。次の表は、一次情報で確認できた、組み込みの各スコープの既定値です。
| スコープ | collaborator | guard policy |
|---|---|---|
| enterprise | on | strict |
| 上記以外の組み込み10スコープ | off | off |
enterprise だけが collaborator on・guard policy strict で、それ以外のスコープ（bugfix, classic, express, feature, infra, mvp, poc, refactor, security-patch, workshop）は collaborator off・guard policy off が既定です。スコープを指定せずに始めたときの既定スコープも、collaborator と guard policy はどちらも off から始まります。
この既定は、最初の1回を軽く始められるように振ってあります。collaborator は、最初は lead 単独で走り出し、専門エージェントを加えるのはチームが必要と判断したときに意識して切り替える、という考え方で off が既定です。guard policy も enterprise 以外は off が既定で、関門をゆるめた状態から始まります。エージェントを少なく確認も少なめで手早く始めたいケースには off が、手厚さを最初から求めるケースには enterprise の既定が合います。
6. 使い分けの例
概念と既定を押さえたところで、いつ on/strict にして、いつ off/relaxed にするかの判断軸を、具体的な場面で見ていきましょう。
collaborator を on にしたくなるのは、たとえば次のような場面です。
- セキュリティやコンプライアンスの観点を、設計の段階で確実に織り込みたいとき
- 判断が難しく、複数の専門分野の視点を交えて検討したいとき
逆に off のままでよいのは、次のような場面です。
- 作業の範囲が明確で、lead だけで十分に進められるとき
- まず素早く形にして、手厚さはあとから足したいとき
guard policy を strict にしたくなるのは、次のような場面です。
- 承認した内容が後から変わったら、立ち止まって確認し直したいとき
- 変更の経緯を厳密に押さえておきたいとき
逆に relaxed や off が合うのは、次のような場面です。
- 細かな変更のたびに聞き直されると、かえって手が止まるとき
- 試作や調査のように、速く回すことを優先したいとき
この2つは、別々の軸であることを押さえておくと使い分けやすくなります。collaborator は「専門エージェントを加えるか、lead だけで進めるか」、guard policy は「承認の前提が崩れたときに立ち止まるか、記録して進むか」です。片方だけを切り替えてもかまいません。たとえば、専門エージェントを加えずに（collaborator off）進めつつ、変更には厳しく構える（guard policy strict）といった組み合わせも選べます。両方を off / relaxed 寄りに揃えればエージェントが少なく確認も少なめで手早く、両方を on / strict 寄りに揃えればエージェントが多く確認も多めで手厚くなります。作業の性質に合わせて、2つの軸を別々に選べます。
7. まとめ
今回は、V2で新しく切り替えられるようになった collaborator と guard policy を見てきました。
- collaborator on/off は、ステージに参加するエージェントの範囲を切り替えます。on は lead ＋専門エージェント、off は lead 単独です。reviewer は別の仕組みで、影響を受けません。
- guard policy strict / relaxed / off は、エージェント側の関門をどこまで働かせるかを切り替えます。strict は承認の前提が崩れたら開き直し、relaxed と off は1行記録して進みます。どの値でも、人の承認そのものは守られます。
- どちらも会話で頼めば切り替わります。どちらも作業の単位で効き、collaborator には環境全体で無効にする切り替えもあります。
- 既定は、enterprise だけが collaborator on・guard policy strict、他の組み込みスコープは off です。
collaborator は「専門エージェントを加えるか、lead だけで進めるか」、guard policy は「承認の前提が崩れたときに立ち止まるか、記録して進むか」。この2つの軸を、作業の性質に合わせて別々に選べます。手早く進めたいときは off/relaxed 寄りに、手厚く進めたいときは on/strict 寄りに、必要な範囲で調整していきましょう。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 30AI-DLC Workflow V2のcollaboratorとguard policy: 専門エージェントを加える設定と、承認後に中身が変わったら止めるか進めるかの設定 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