実行前承認

承認対象にするかは、失敗したときの影響範囲で判断します。

承認を推奨する例：

• ナレッジの作成・更新・削除
• 外部SaaSへの書き込み、送信、削除
• DBやスプレッドシートなど共有データの変更
• Custom MCP やメタスキル経由で設定を書き換える操作

読み取り専用の検索や、毎回同じ結果確認だけで済む低リスク操作まで承認対象にすると、自動化の速度が落ちます。

承認が必要なツール実行に到達すると、ワーカーはその場で待機します。担当者はアプリ上に表示された承認リクエストを確認し、内容が妥当なら「承認」、実行させない場合は「却下」を選びます。

承認するとワーカーは中断地点から処理を続けます。却下すると対象のツール実行は行われず、その結果を前提にワーカーの処理が進みます。

承認待ちのまま放置すると、自動化はそこで止まります。重要ワーカーでは、誰が承認を見るか、通常どの時間帯に確認するか、緊急時は誰に引き継ぐかを事前に決めておくと運用が安定します。

Slack、Discord、LINE WORKS などの受信チャネルを使う場合も、承認依頼に気づける導線を用意しておくことが重要です。

承認設定は、ワーカーの用途ごとに分けて考えるのが基本です。

• 社内調査・要約ワーカー：読み取り中心なら承認は最小限にする
• ナレッジ更新ワーカー：作成・更新・削除だけ承認対象にする
• 外部SaaS操作ワーカー：送信・削除・公開など外部に影響する操作を承認対象にする
• 管理系メタスキルを持つワーカー：設定変更系の操作を強めに制御する

設定後は代表的な依頼を1回流し、承認が必要な場面だけで止まるか確認してください。