日本語

GenerateとExecuteの境界線：ガードレールが重要な理由

GenerateとExecuteを並べて比較し、ガードレールの境界線を強調した図

Rachelの話をしましょう。彼女は90名の保険代理店を経営しており、解約率も良好でビジネスをよく知るチームを持っています。昨年春、オペレーション責任者が新しいパイロットについて熱心に話しかけてきました。代理店のメールシステムにAIアシスタントを接続したいというものでした。AIは入ってくる問い合わせを分析し、パーソナライズされた返信のドラフトを作成し、夜間に自動で送信する。フォローアップの漏れが減り、応答時間が短くなり、見込み客の満足度が上がるという話でした。

Rachelはその提案を承認しました。ドラフト作成を自動化するというアイデアだと理解していました。

送信も自動化されていることには気づいていませんでした。

ローンチ翌朝、彼女の受信ボックスには転送されたクレームが届いていました。AIが生成したメールが340人の見込み客に送られており、間違ったポリシータイプの更新見積もりが提示され、テストされていなかった差し込みフィールドに間違った名前が入っていました。受信者の中には、AIシステムに登録されていることを知らされていなかった既存クライアントが数名いました。そのうち3名が怒って電話してきました。

Rachelが悪い意思決定をしたのではありません。説明のない決定をしたのです。チームはドラフト作成と送信を同じことと見なしていました。

この記事はRachelのために、そしてAIパイロットが曖昧な引き継ぎによってインシデントに一歩手前まで来ているすべてのリーダーのために書きました。

1文での違い

GenerateはAIのコンテキスト内に存在するアーティファクトを生成します。ExecuteはAIの外部のシステムに変更をコミットし、他の人とプロセスがすぐに見ることができます。

その1文に論点のすべてが含まれています。しかし、具体的に見ていく価値があります。

境界線が存在する4つの場所

抽象的な区別は、特定のワークフローで見ると明確になります。同じアクティビティが境界線の前後でどのように見えるかを示す4つの例を挙げます。

アクション Generate（境界線の前） Execute（境界線の後）
メール AIが見込み客の名前、企業、関連するコンテキストを含むフォローアップのドラフトを作成する AIがドラフトを見込み客の受信ボックスに送信する
コード AIがバグの修正を書き、ローカルにPull Requestを作成する AIがPull RequestをMainブランチにマージする
返金 AIが340ドルの返金を推奨し、承認メッセージのドラフトを作成する AIがStripeで返金を処理しサポートチケットをクローズする
カレンダー AIが両者の空き状況に基づいて3つの候補日時を提案する AIがカレンダーの招待を送信し枠を確保する

すべての行において、Generate側はレビュー可能なものを生成します：文書、推奨事項、計画。AIの外部では何も変わっていません。人間はそれを読み、編集し、拒否し、改善できます。エラーのコストはゼロです。なぜなら、ドラフトはまだどこにも行っていないからです。

Execute側では、現実のことが起きました。口座からお金が出ました。コードは本番環境にあります。メッセージが誰かの受信ボックスに届いています。誰かの1時間が約束されました。これらのいずれかを取り消すには手間がかかります。取り消せないものもあります。

境界線が重要な理由

リスクの議論はシンプルです。

Generateのエラーは恥をかかせます。AIが悪いメールのドラフトを作ったとしても、それを読んで送らなければいい。推奨される返金額が間違っていれば、人間が気づきます。書いたコードにバグがあれば、開発者がレビューで見つけます。Generateのエラーはコストが低い。それは誰かが判断するまでシステム内に留まります。

Executeのエラーはお金を失い、信頼を損ない、しばしば取り戻せません。1万人の顧客への間違った一括送信。午前2時に処理された二重返金。コアワークフローを壊す本番環境へのコードデプロイ。間違ったアジェンダでクライアントに送られたカレンダー招待。これらはドラフトの中ではなく、現実世界で起きる出来事であり、それを解消するには実際のリソースが必要になることがあります。法的なリスクも生じることがあります。

この非対称性こそ、ACE FrameworkがGenerateとExecuteを別のCapabilityとして扱う理由です。スライドでは似たように見えます。「AIがメールのドラフトを作成して送信する」は1つのことのように聞こえます。実際には、まったく異なるリスクプロファイルとガバナンス要件を持つ2つのことです。

ガバナンス、承認ワークフロー、Human-in-the-loopポリシーはすべて、GenerateからExecuteへのTransitionで何が起きるかをコントロールするために存在します。そのTransitionが明示的に設計されていれば、ほとんどのAIインシデントは起きません。暗黙的に想定されているときは、起きてしまいます。

製品設計における境界線

AIツールを評価しているか、自分のワークフローを設定しているなら、Generate-Executeの境界線はデザインパターンとして現れます。

  1. ユーザーがタスクを開始する（またはトリガーが自動的に発火する）
  2. AIが実行する：Ingest → Analyze → Generate（アーティファクトが生成され、外部への変更はない）
  3. ユーザーが出力を確認する
  4. ユーザーが承認する（境界線、ワークフローで最も重要な瞬間）
  5. システムが外部世界でアクションを実行する

ステップ4が要となります。意図的にスピードのために省略するか、誰も指定しなかったために偶然に省略することで、Rachelのメールが340人に送られました。

これをうまく処理するAIツールは、境界線を目に見える形にします。IntercomのAIはエージェントが送信前に確認できるよう返信のドラフトを表示します。GitHub Copilotはコード補完を提案しますが、それをコミットしません。CalendlyのAIは候補時間を提案しますが、受信者が確認するまで予約しません。これらは制限ではありません。機能です。明示的な承認ステップこそ、ツールを大規模に使えるほど信頼できるものにします。

境界線における5つのパターン

すべてのワークフローが同じアプローチを必要とするわけではありません。これらの5つのパターンを使えば、リスクと量に基づいてキャリブレーションできます。

1. レビューゲート

すべてのExecuteは外部世界で何かが起きる前に明示的な人間の承認を必要とします。高価値または取り消し不能なアクションに最適：1,000ドル以上の返金、重要アカウントへのメール、人事に関する決定。制限：1日数十件の承認を超えるとスケールしません。選択的に使用してください。

2. しきい値

AIは定義された上限まで自律的に実行し、それを超えるとアクションがレビューのために一時停止します。例：AIが50ドル以下の返金リクエストを自動処理し、それより高いものをフラグします。しきい値はポリシー文書ではなく、システム設定に存在します。ほとんどのケースは安全だが、末尾に監視が必要な中程度の量と価値の混在した意思決定に最適です。

3. 取り消し可能なもののみ

AIはシステムサポートされた元に戻す操作のあるアクションのみ実行できます。「タスクを作成する」は取り消し可能です。「メールを送信する」はそうではありません。「CRMフィールドを更新する」は取り消し可能です。「レコードを削除する」はそうではありません。リストを定義し、AIはその中でExecuteできます。取り消し不能性が主なリスクである大量ワークフローに最適です。

4. シャドウモード

Executeは完全に無効化されます。システムが取るべきすべてのアクションをログに記録しますが、何も実行しません。2週間シャドウモードを実行し、ログを確認し、予想しなかったエッジケースを見つけてから、ライブ実行を有効にしてください。これが、コストがかかる前に午前2時の二重返金シナリオを見つける方法です。

5. レート制限

AIは時間枠内でN件までのアクションを実行し、継続前に人間のレビューサイクルのために一時停止します。例：1日50件の営業メールを自律的に送信。51件目にキューが一時停止し、誰かが次のバッチをレビューします。主なリスクが時間の経過とともにドリフトすることである、大量・個々のリスクが低いワークフローに最適です。

これらのパターンは相互排他的ではありません。うまく設計されたワークフローは返金にはしきい値を、データ更新には取り消し可能なもののみを、最初の2週間はシャドウモードを使うかもしれません。

GenerateとExecuteを統合して良い場合

一部のワークフローにはレビューゲートが必要ありません。AIが人間のレビューなしに行動できるよう、GenerateとExecuteを統合することが適切なのは、次の3つすべてが当てはまる場合です。

アクションがリスクの低いものである。 文書内のオートコンプリート、スペルチェック、内部チケットへの提案タグ。AIが間違えても、コストはごくわずかです。

アクションが明確に取り消し可能である。 Undoが速く、インターフェースに組み込まれており、誰かに連絡する必要がありません。2秒で修正できるなら、ゲートはおそらく不要なオーバーヘッドです。

スコープが明確に定義されており、限定的である。 自分の文書内でのオートコンプリートは、顧客に送られるメールを作成するのとは異なります。「この関数を書く」は「この関数を本番環境にデプロイする」とは異なります。

注意すべきパターン：チームはデモが素晴らしく、スピードが欲しいためにGenerateとExecuteを統合します。境界線を省略します。なぜならそれが官僚主義のように感じられるからです。6週間後、クライアントになぜAIが他の人の見積もりを送ったのかを説明することになります。

境界線を絶対に統合してはならない場合

AIがどれほど自信満々に見えても、パイロット結果がどれほど良くても、ゲートがどれほどの時間コストがかかっても、常に人間の承認ステップが必要なアクションのカテゴリーがあります。これらは：

顧客が目にするコミュニケーション。 あなたのブランドを付けて顧客の受信ボックス、SMS、またはアプリ通知に届くものすべて。AIはドラフトを作成できます。人間が承認します。

金融取引。 返金、請求、送金、発注書。デフォルトは常にレビューです。量によっては最終的にしきい値の自動化が正当化されることがありますが、その実績で判断してください。

人事に関する決定。 採用、報酬、評価、解雇に関わるもの。AIは分析を支援します。人間が決定します。

法務またはコンプライアンスに敏感なアクション。 契約書、NDA、規制上の申告、法的義務を生じさせるか規制当局が監査する可能性のあるもの。

あらゆる種類の削除。 削除はExecuteのミスの中で最も取り消しが困難なものです。まずシャドウモードで実行し、レビューゲートを追加してから、量が本当に必要とする場合にのみ自動化を検討してください。

自律型エージェントと境界線

自律型エージェントはACE Frameworkにおける最もリスクの高いDeploymentパターンです。それらは5つのCapabilityすべてをループで組み合わせ、目標に向かって複数のExecuteアクションを実行しながら進みます。ループ内の各Executeは潜在的なインシデントです。

リスクは複合します。入力を誤分類した（Analyzeのエラー）エージェントが、誤った返答のドラフトを作成し（Generateのエラー）、ループが完了する前にその誤った返答を10の下流システムにわたって実行するかもしれません。人間がログをレビューする頃には、被害は複数ステップに及んでいます。

自律型エージェントループ内のExecuteに関する3つのルール：第一に、エージェントがどのExecuteアクションを実行することを承認されているかを書き留めてください。「タスクを作成する。CRMステージを更新する。外部メールを送信しない。レコードを削除しない。」第二に、時間あたりまたは実行あたりのExecuteアクション数に厳格な上限を設け、監査実績が積み上がった後にのみ拡大してください。第三に、すべてのExecuteアクションの完全な意思決定履歴をログに記録してください。エージェントが何をIngestし、Analyzeし、Generateし、Executeしたか、タイムスタンプとともに。そのログは何か問題が起きたときに何が起きたかを理解する唯一の方法であり、必ず何かは起きます。

境界線における実際のインシデント

これらは実際に起きている失敗パターンです。仮定ではありません。実際のDeploymentからのパターンです。

レビューなしに送信されたAI生成メール。 フィルターのバグにより、1万5千件のオプトアウト済み連絡先がアウトリーチシーケンスに含まれました。AIは夜間にドラフトを作成して送信しました。翌朝には400件の配信停止、30件の怒りの返信、法的なエスカレーションが届いていました。

AIが承認した不正返金。 サポートチームのAIが200ドル以下のクレームに自動で返金を発行していました。悪意のある者が60件のほぼ同一のクレームを提出しました。AIは人間のアラートがトリガーされる前にすべてを処理しました。1万2千ドルが口座から出ました。

本番環境を壊した自律型コードデプロイ。 CI/CDパイプラインが自動テストをすべてパスしたPull Requestを自動マージしました。その変更がテストでカバーされていなかった下流の統合を壊しました。4時間の解消作業、800人の顧客への影響。

既存の予約を置き換えたAIスケジューリング。 スケジューリングAIが元のクライアントへの通知なしに、新しいリクエストに合わせてクライアントの通話を変更しました。彼らはアカウントチームにエスカレーションしました。

各インシデントは1つの根本原因を共有しています：誰かがAIがアクションを起こす前に止まると思い込み、その前提を誰も書き留めなかったのです。

Generate-Executeポリシーの構築

ポリシーは長くある必要はありません。具体的で共有されている必要があります。テンプレートを示します。

どのアクションが自動Executeか？ 具体的にリストアップしてください。「内部チームチャンネルへの通知を送信する。プロジェクト管理システムにタスクを作成する。商談がクローズ済みとマークされたときにCRMのリードステージを更新する。」このリストにないものは、自動Executeではありません。

何が人間の承認を必要とするか？ デフォルト：それ以外すべて。顧客向けコミュニケーション、金融取引、削除はサイズに関わらず常に承認が必要です。

誰が承認するか？ 担当者名ではなく役割を指定してください。「アカウントオーナーが顧客コミュニケーションを承認する。財務チームリードが500ドルを超える取引を承認する。エンジニアリングマネージャーがMainへのマージを承認する。」アクションカテゴリーごとに1人の承認者です。

何がログに記録されるか？ すべてです。AIが見たもの、決定したもの、実行したもの、誰が承認したか（または自動承認された場合はその理由）、そしてタイムスタンプ。最低90日間の保持。ワークフローを管理するすべての人の監査アクセス。

ポリシーはいつレビューされるか？ 四半期ごと。さらに、重大度に関わらず、インシデントの後は即時レビューします。

書き留めてください。チームが見つけられる場所に置いてください。

結論

Generate-Executeの境界線はAIガバナンスにおける最も重要な線です。意識的に引けば、ほとんどのAIインシデントが起きる前に防げます。無視すれば、高くつく形で発見することになります。

Generateは強力です。Executeは重大な結果をもたらします。両者の距離はたった1つの承認ステップであり、そのステップを守る価値があります。

次に読む記事