AIエージェントの承認ワークフローとは、提案されたアクションから実行までをつなぐ統制の経路です。有用な承認は、汎用的な「続行」ボタンではありません。何が起こるのか、どの対象に対してか、どのようなデータやコストを伴うのか、成功をどう確認するのか、そしてアクションをどこで止めなければならないのかを、レビュー担当者に伝えるものです。
承認を6つの正確な項目に結び付ける
- アクション：具体的な操作。公開、送信、コード変更、デプロイ、支出、有料リサーチの実行など。
- 対象：アカウント、宛先、リポジトリ、環境、オーディエンス、またはプロバイダーのリソース。
- ペイロード：レビュー対象となる正確な文面、ファイル、パッチ、クエリ、予算、または設定。
- スコープ：許可される数量、権限、期間、副作用。
- 成功チェック：完了と「試みただけ」を区別する証拠。
- 停止条件：実行を終了させる時間、コスト、エラー、曖昧さ、またはシグナル。
可視化されたステートマシンを使う
- 提案済み：エージェントが範囲を限定したアクションを準備し、なぜ今それが重要なのかを説明します。
- レビュー中：ユーザーは対象、ペイロード、スコープ、受け入れ基準、想定される副作用を確認できます。
- 修正済みまたは却下：修正によって古い提案はクローズされ、必要に応じて新しいバージョンが作成されます。
- 承認済み：同意は、レビューされた正確なバージョンに対して記録されます。
- 実行中：専任エージェントは承認されたスコープのみを試行し、保留や失敗を報告します。
- 検証済み：プロバイダーの証拠、テスト出力、公開URL、またはその他の明示的なチェックによって結果が証明されます。
- 学習済み：次の提案の前に、結果とシグナルがプロジェクトのコンテキストに戻されます。
具体例：承認前にリサーチカードを修正する
この例はSoloopの現在の承認ルールに沿っていますが、意図的に作成した説明用の例であり、実際の顧客での実行記録を示すものではありません。曖昧な提案が、正確で監査可能なタスクへと変わる過程を示しています。
競合を調査し、何を開発すべきかを提案する。対象、情報源の範囲、コスト、受け入れ基準、停止条件が欠けているため、このバージョンは承認すべきではない。
タスクを、名前を特定した1社の競合と、承認済みの公開ドメインに限定する。日付付きの情報源リンク、反証、明示的な不明点、意思決定への引き継ぎを必須とする。ログイン、購入、トライアルの作成、連絡は禁止する。
公式ホームページ、ドキュメント、料金ページ、利用規約を確認する。コスト：有料サービスは$0。認証が必要になる前、または重要な事実を検証できない場合に停止する。
承認されたバージョン、実行者、タイムスタンプ、開いた情報源、アクセスできなかった証拠、停止条件が発動したかどうかを記録する。この記録がなければ、完了した検索もあくまで試行であり、検証済みの完了ではない。
日付付きの証拠台帳を返し、観察と推論を分け、この作業によって変わった創業者の具体的な意思決定を特定する。二次調査を需要の裏付けとして扱わない。
次のタスクを提案する前に、結果と最も重要な不明点をプロジェクトに保存する。その後の公開、メール、コード、デプロイ、支出のアクションには、それぞれに適用される承認の境界が必要となる。
エージェントの積極性ではなく、影響の大きさで関門を設ける
低リスクで元に戻せる分析は、多くの場合、軽量な統制のもとで進められます。外部へのメッセージ、公開投稿、コード変更、デプロイ、アカウント連携、有料サービス、データベースの変更、支出には、明示的なレビューが必要です。リスクは対象によっても変わります。下書きを編集することと、それを創業者の名義で公開することは同じではありません。
専任エージェントへの引き継ぎによって、そのエージェントの外部アクションが自動的に承認されるべきではありません。後のカードには、引き継ぎ時点では存在しなかった実際の宛先、文面、リポジトリ、diff、コストが含まれる場合があります。
承認疲れを防ぐ
- レビュー担当者が実際のペイロードを確認できる、安全な範囲で最も遅いタイミングで一度だけ確認する。
- リスク、対象、停止条件がすべて同じアクションだけをまとめる。
- 修正時には、すべてを読み直させるのではなく、変更された項目を示す。
- 所有権、認証、スコープが欠けている場合は、実行しない側に倒れる（フェイルクローズの）デフォルトを使う。
- 読み取り専用のリサーチを、有料サービスや外部への書き込みと区別する。
- 提案の証跡を失うことなく、ユーザーが一時停止または却下できるようにする。
何が起きたかに答えられる監査記録を残す
Soloopは、リサーチ、公開投稿、ベータ版のメール、コード変更、デプロイに承認の経路を使っています。現在の公開上の境界は重要です。X/TwitterはOAuthで稼働中、コールドメールはベータ版でGmailが必要、Redditへの投稿は手動、広告は計画立案のみ（実行はしません）、コードはサンドボックス内で実行されます。承認画面は、計画中のチャネルが稼働中であるかのように示すのではなく、実際の実行経路を説明すべきです。
- 誰がアクションを提案し、誰が承認したか？
- どの変更不可能なバージョンと対象がレビューされたか？
- 承認と実行はそれぞれいつ行われたか？
- どのプロバイダー、アカウント、リポジトリ、環境が使われたか？
- 成功、失敗、または部分的な完了を証明する証拠は何か？
- どのようなコスト、成果物、シグナル、後続の意思決定が生じたか？
実用的なレビューカード
- 目的：このアクションが支える意思決定または成果。
- なぜ今か：これを次の一手とする根拠となる証拠。
- 正確なアクションと対象：何が、どこで、どのアカウントで変わるのか。
- プレビュー：最終的な文面、ファイル、diff、クエリ、または予算。
- 受け入れと停止のチェック：完了と失敗をどう判断するか。
- 操作：承認、修正、却下、または一時停止。