ブログ · ガイド · 2026年10月28日
オーケストレーターに承認ステップを持たせる方法: AEGIS を実例にしたパターン
開示: 100monkeys.ai はこのガイドの実例である AEGIS を開発しています。AEGIS に関する部分は作り手による説明として読んでください。パターンそのものは一般的なもので、どのオーケストレーターにも当てはまります。このガイドは AEGIS の公開ドキュメントをもとに当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文ガイドの翻訳です。
承認ステップとは、自動化された実行の中で作業が止まり、人がこれから起きることをそのまま読み、その人の回答があったときだけ実行が続く地点のことです。一時停止できるオーケストレーターは多くありますが、その停止を確実に保てるものは多くありません。ここでは私たちが使っているパターンを、AEGIS by 100monkeys.ai, in beta を実例にして順に説明します。
パターンを一段落で
ゲートは、エージェントが行為を準備した後、行為が起きる前に置きます。レビュー担当者には要約ではなく、準備されたものそのものを見せます。無応答が何を意味するかを事前に決めます。両方の回答に明示的な行き先を与えます。レビュー担当者が今いる場所から答えられるようにし、回答を実行の履歴に残します。却下された下書きが永遠にループしないよう、再試行に上限を設けます。
ステップ 1. 人の判断が要る行為を列挙する
すべてのステップにゲートが要るわけではありません。何にでもゲートを置くと、人は読まずに承認するようになります。サンドボックスの外に出て取り消せない行為にゲートを置きます。外部の人へのメッセージ送信、保護されたブランチへのマージ、お金を使うこと、データの削除、公開です。それ以外は、事前に書いたポリシーの下で実行できます。当社の論文 Red levers(英語)は、これを二種類の停止と呼んでいます。実行前に決めてランタイムが強制する制限と、一つの行為に結びついた、その行為の時点での承認です。
ステップ 2. エージェントの作業を行為の手前で分ける
下書きと送信を一つのステップで行うエージェントは、途中で止められません。準備する状態と実行する状態に分けて、ゲートが立つ場所を作ります。AEGIS ではワークフローは宣言的なステートマシンで、ゲートはそれ自体が一つの状態、kind: Human です:
spec:
initial_state: DRAFT
states:
DRAFT:
kind: Agent
agent: draft-agent
transitions:
- condition: on_success
target: APPROVE
APPROVE:
kind: Human
prompt: |
About to send:
{{DRAFT.output}}
Approve? (yes/no)
timeout: 86400s
transitions:
- condition: input_equals_yes
target: SEND
- condition: input_equals_no
target: DISCARDこの形は AEGIS ドキュメントの Building Workflows ページに倣っています。draft-agent、SEND、DISCARD は、あなた自身のエージェントと状態に置き換えてください。
ステップ 3. レビュー担当者の前に実物を置く
ゲートのプロンプトはレビュー担当者に見えるすべてなので、準備された出力をそこに埋め込みます。AEGIS のプロンプトは Blackboard テンプレートを受け付けます。上の {{DRAFT.output}} は前の状態の出力で、ドキュメントには {{QUALITY_CHECK.output.score}} のように前の状態のスコアを使う例もあります。「エージェントがメールを送ろうとしています」と見せられた人は説明を承認しており、メールそのものを見せられた人はメールを承認しています。
ステップ 4. 無応答の意味を決める
すべてのゲートにはタイムアウトと、期限切れ時のルールが必要です。Human Approvals ページでは timeout_seconds の既定値は 3600 です。既定の reject_on_timeout: false では、応答のないゲートは実行を human_input_timeout で失敗させます。reject_on_timeout: true では無応答が「いいえ」として扱われ、実行は却下の経路に進みます。回答がないことをエラーではなくきれいな「いいえ」にしたいときは後者を選んでください。無応答を「はい」にしてはいけません。
フィールドについての注意: Human Approvals ページは timeout_seconds と条件 approved、rejected を使い、Building Workflows ページは timeout と input_equals_yes、input_equals_no を使っています。どちらか一つの形に統一し、実行しているバージョンの Workflow Manifest Reference を確認してください。
ステップ 5. 両方の回答に行き先を与え、ループに上限を設ける
「いいえ」は回答であって、後で処理する失敗ではありません。行き先の状態を与えます。破棄するか、レビュー担当者のコメントを添えて下書きをエージェントに戻すかです。却下を下書きの状態に戻すと、実行にはループができます。AEGIS はそれに上限を設けます。状態ごとの max_state_visits(既定 5、上限 20)と、実行ごとの max_total_transitions(既定 50、上限 100)です。レビュー担当者が許容できる試行回数に合わせて設定してください。
ステップ 6. レビュー担当者がいる場所から答えられるようにする
誰も見ないゲートは、ただのタイムアウトです。AEGIS では同じゲートに三通りの方法で答えられます:
- コマンドラインから:
aegis workflow signal <execution-id> --response yes。 - 自分のクライアントから: 待機中のゲートを
GET /v1/workflow-gates?status=pendingで一覧し、POST /v1/workflows/executions/{id}/signalで答えます。本文は{ "response": "yes", "feedback": "Keep the flag name short." }のようになります。 - Zaru Web で: 自分が開始した実行のゲートは保留中の承認の一つとして表示され、許可された語ごとにボタンが一つあります。ドキュメントによれば、Zaru のコンパニオンにはどのモードでもゲートに答えるツールが与えられないため、行為を準備したモデルがそれを承認することはできません。
どのオーケストレーターでも確かめるべきなのはこの最後の性質です。エージェントが自分のゲートの鍵を持っていてはいけません。
ステップ 7. 回答を残す
承認は証拠です。ゲートが回答されるか期限切れになった後も、AEGIS はそれを一覧に残します。?status=answered は、選ばれた語、コメント、閉じた時刻、その後に実行が何をしたかとともに各ゲートを返します。誰が答えたかも記録してください。Human Approvals ページの承認エンドポイントは approved_by フィールドを受け取り、却下には reason が必須です。
ステップ 8. 信頼する前にゲートをテストする
ワークフローを三回実行します。「はい」と答える、「いいえ」と答える、期限切れにする、の三通りです。それぞれの経路が意図した場所に着くこと、そして回答の前にゲートより後の処理が何も走っていないことを確認します。次に、ゲートが出た後で下書きを変更し、レビュー担当者に実際に実行されるものが見えることを確認します。オーケストレーターが承認を内容ではなく説明に結びつけているなら、ここで分かります。
次に読むもの
自分のサーバーでこのパターンを最初から最後まで試すには、新しい Ubuntu VPS に AEGIS をインストールし、最初の承認付きタスクを実行するに従ってください。各ゲートの周りで何を記録し何に署名するかは、本番 AI エージェントのトレーサビリティ・チェックリストを読んでください。同じ承認の考え方を個人アシスタントで使うなら、メールとカレンダーを承認付きで任せられる Zaru アシスタントを設定するをご覧ください。