承認して実行：AI の提案が統制されたアクションになるまで

モデルが草案を書き、人が承認し、その承認が実行されるものです。提案がどうゲートに届くか、ゲートが何を求めるか、そして誰かに見せる価値があるために承認が何を記録しなければならないか。

更新 2026-08-10 · 6 分で読めます

パターンの形

承認して実行は分業です。モデルは読むことを許されたものを読み、言葉で提案を書き、人に手渡します。その人は、アクションを所有するツールの中でそれを開き、何が行われるかを見て、署名します。署名が実行されるものです。真ん中の人を取り除けば、提案は画面上の一段落のままです。

順序は見た目以上に大事です。エージェント型の設計では、モデルが行動し、人は後で、行うとしてもレビューします。ここではトリガーは人のものです。それがレビューを、忙しすぎて確認できない安全網ではなく、アクションへの唯一の経路にします。

提案は人を待ちます。それぞれがカードになり、読み手がツール自身のゲートで開いて承認します。

助言と行動は違う

行動するアシスタントと助言するアシスタントは、同じ言葉で売られます。それらは異なる買い物です。違いは、リスク部門が尋ねる問いに現れ、悪い日にもう一度現れます。

失敗の仕方。助言するモデルが間違えれば、人が間違った文を読みます。行動するモデルが間違えれば、変更が環境に着地し、誰かが後で見つけます。
責任を負う名前。承認は、それを与えた人の名前を運びます。サービス ID によるアクションはサービスの名前を運び、誰も尋ねていない問いに答えます。
レビューの瞬間。助言はまだ安いうちにレビューされます。アクションは事後に、ログの中で、その週に起きた他のすべてと並んでレビューされます。

どちらの設計にも居場所があります。統制された Tableau 環境の中で承認されるのは、助言するほうです。ひとつのパブリッシュ済みデータソースは100のワークブックの下にありえ、ひとつのパーミッション変更はそのすべてに届きます。

アクションのリストがある場所

提案は、それが由来するリストと同じだけ有界です。各ツールはサーバー上で、提案可能なアクションの自身のリストを宣言します。モデルはそのリストから名前で選び、答えの末尾にアクション ID のブロックをひとつ加えます。

モデルはどのアクションかを選び、アドレスは決して選びません。サーバーはツール自身の登録済みプレフィックスからディープリンクを組み立てるので、リンクはそのツールがすでにある場所にしか導けません。
リストの外のものは落とされます。レジストリにない ID、すでに提案されたものの繰り返し、または不正な形のブロックは、答えが画面に届く前に捨てられます。
読み取り専用のツールは読み取りを提案します。ツールがスキャン、マッピング、抽出を行い、Tableau に何も書き戻さないところでは、レジストリの項目がまさにそう述べ、読み取りだけがそのツールが出せるものです。

それが、端から端まで読めるリストの実用的な価値です。このアシスタントが提案しうるすべての変更を知りたいレビュアーは、ひとつのファイルのひとつのレジストリを午後ひとつで読みます。行儀よくしろとモデルに言う指示は、そのレビュアーに読むものを何も残しません。

承認が記録するもの

誰かが「はい」をクリックしたことしか記録しない承認は、クリックです。5つのフィールドが、ゲートをダイアログボックスから分けます。

誰が承認したか: 承認の瞬間のライブセッションから取られた、名前のある人。ロールや共有アカウントは、あらゆる点で弱い。
正確に何を: 正確な項目と正確な変更。1年後の読み手が、記録だけから判断を再構築できるべきです。
どんな証拠に対して: 承認者が見ていたレポート、スキャン、検査。証拠から切り離された承認は、タイムスタンプ付きの意見です。
いつ、どの順序で: 時刻と、並びの中の位置。後の読み手は、承認が変更の前だったか後だったかを見分けられます。
繰り返すとどうなるか: 同じ承認を二度実行すると作業が二度行われるかどうか。ここのいくつかのゲートは冪等で、つまり繰り返しは状態を重複させるのではなく確定させ、ゲート上でそう述べます。

最後のフィールドは人が忘れるものです。2回目の送信で静かにもう一度作業を行うゲートは、不安からのダブルクリックを2つ目の変更に変えます。監査にはひとつの意図されたアクションに対して2つの承認が現れます。

ゲートが求めるもの

登録されたすべてのアクションは、その背後のゲートを名指しします。提案カードは、読み手が開く前に何を求められるかを伝えられます。これはレジストリ自身の要約です。

ワークブックのパブリッシュ: 二重署名と品質ゲート。新しいコピーのみを書き、パブリッシュは監査されます。
レポートの本番昇格: 合格のみのルールと拘束力のある署名。冪等なので、繰り返しの承認は重複せずに確定します。
移行の承認: 承認者の名前と、リスクをレビューしたことの確認。冪等。
退職者のアクセス削除: ロールのゲートと、その人のコンテンツに埋め込まれた認証情報の明示的な確認。冪等。
自動化の有効化: 二重管理の確認と、自動化をそもそもオンにする前のクリーンなレビュー。

表を全体として読めば、パターンが論拠です。コンテンツがパブリッシュされるところでは2つの署名。移行が走るところでは名前のある承認者。認証情報が埋め込まれているところでは確認。ゲートの重さはアクションの重さに従い、すべてにひとつの設定で座っているのではありません。

本物のゲートを見分ける

何が実行されるかを尋ねる。承認がフラグを立て、バックグラウンドのジョブが後でそれを読むなら、承認とアクションは2つのイベントで、その隙間で何かが起こりえます。
記録が何を保持するかを尋ねる。実際の承認の行をひとつ読む。人、項目、証拠を名指ししていればコントロールです。セッション ID と時刻を名指ししていればテレメトリです。
2回目のクリックが何をするかを尋ねる。テスト環境で同じ承認を二度送信し、作業が二度行われるかを見る。
可能なアクションのリストがどこにあるかを尋ねる。サーバーから読めるリストはレビューできるリストです。プロンプトの中にあるリストは希望です。

自分のチームのひとりが、自分の環境の中で4つすべてに答えられます。データシートに引用されたどんな数字も、それほど多くは教えてくれません。