承認キューはAIの提案とホームサーバーの操作をどのように分離するのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does an Approval Queue Separate AI Suggestions From Home Server Actions? - Zima Store Online

承認キューは、提案されたツール呼び出しを保留状態で保存し、独立した判断によって実行が許可されるまで待機させることで、AIの提案とホームサーバー上の操作を分離します。

これにより、高影響の自動化は2段階のシステムになります。エージェントは正確な操作を準備できますが、承認と再検証が完了するまで、ファイル、サービス、アカウント、デバイスは変更されません。

エージェントはまず副作用ではなく提案を生成する

承認キューによって、高影響の判断の出力は「今すぐ実行」から「保留中の操作を作成」に変わります。

モデルはパラメーターを設定できますが、外部システムはまだ変更されません。

Temporalの承認パターンでは、外部から承認の判断が届くまでワークフローの実行を停止します。この待機状態もワークフローの状態の一部です。LangChainのHuman-in-the-loopミドルウェアは、実行前にツール呼び出しを中断できます。これは、LangChainのHuman-in-the-loopミドルウェアで説明されている「まず提案する」という境界を示しています。

そのため、削除、権限変更、コンテナの再起動、大量移動などを、対象を変更しないままレビュー可能なデータにできます。

保留中のレコードでレビュー対象の操作を固定する

キューには、ツール名、対象、引数、依頼者、理由、作成日時を保存する必要があります。これらのフィールドを固定することで、承認が包括的な権限に変わるのを防げます。

TemporalのHuman-in-the-loopの例では、シグナルベースの承認と永続的な待機を使用しており、待機中もワークフローが状態を保持できることを示しています。Temporalは承認をワークフローの待機状態としてモデル化しているため、保留中の操作レコードを最終的な副作用から分離できます。詳しくはTemporalの承認パターンをご覧ください。

提案が「Jellyfinを再起動する」ものであれば、その承認によって、後からPostgreSQLを再起動する別の変更まで許可されるべきではありません。

重要なパラメーター変更があった場合は、以前の判断を無効にする必要があります。

レビュアーは承認、編集、拒否、期限切れを選択する

承認は二者択一である必要はありません。レビュアーは、操作を拒否したり、変更せずに承認したり、制約されたパラメーターを変更したり、コンテキストが古くなった場合に期限切れにしたりできます。

Temporalでは、ワークフローシグナルを通じて承認データを取得します。これにより、レビュアーのメタデータも永続的なワークフロー状態の一部になります。AWS Step Functionsには、続行前に一時停止する人による承認ワークフローがあり、AWS Step Functionsの人による承認で説明されている承認または拒否への遷移を示しています。

編集には制限を設ける必要があります。レビューUIで任意のシェルコマンドへの置き換えを受け付けると、意思決定のゲートではなく、2つ目の無制限なツール実行面になってしまいます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

実行時には古いコンテキストを信頼せず再検証する

承認は、提案から長い時間が経過してから届くことがあります。その間に、ファイルが移動したり、サービスが復旧したり、権限が変わったりする可能性があります。

永続的なワークフローは、判断が届くまで停止したままにできます。その後、実行側は承認済みのパラメーターに対して、スキーマチェック、認可、事前条件を再実行する必要があります。Camundaは明示的なワークフロー構造内でエージェント処理を扱うため、以前に提案された操作を実行に移す前に状態を再検証する必要性を裏付けています。詳しくはCamundaのエージェント型ワークフロー制御をご覧ください。

これにより、承認によって古い前提が固定されるのを防げます。対象が現在は別のバージョンを指している場合、削除を拒否できます。また、サービスがすでに正常な状態なら、再起動をスキップできます。

承認はスキーマと権限の上に境界を追加する

スキーマ検証は、操作が構造的に有効かどうかを確認します。認可は、呼び出し元にその操作を実行する権限があるかどうかを確認します。

承認は、特定の有効かつ認可済みの副作用を、今この時点で実行に移すべきかどうかを確認します。

ZimaSpaceの読み取り専用のホームAIエージェント戦略では、変更の前に観察することを推奨しています。MCPのツールガイダンスでは、ツールの呼び出しとユーザーに見える制御を別の関心事として扱っており、スキーマ、権限、承認の階層的な関係を支えています。詳しくはMCPのツール安全性ガイダンスをご覧ください。

同じ境界は、ZimaSpaceのセルフホスト型エージェントの承認ゲートの例にも見られます。そこでは、ゲート付きツールが自動的に変更を適用するのではなく、レビューのために停止します。

バイパス経路が閉じられていなければキューは役に立たない

同じエージェントが、同等の制限のないエンドポイントを直接呼び出せるなら、承認システムは機能しません。高影響の経路には同じ強制適用境界を設けるか、別途拒否する必要があります。

MCPは、機密性の高い操作について明示的なユーザー確認を推奨しています。承認キューによって、その確認を永続的かつ監査可能なものにできます。Microsoft Agent Frameworkでは、実行前に承認を必要とする関数ツールを設定できます。これは、実行経路が承認層を回避できない場合にのみ承認層が機能する理由を示しています。詳しくはMicrosoft Agent Frameworkのツール承認をご覧ください。

リスクの低い読み取り操作は、自動的に実行してもかまいません。目的は摩擦を最大化することではなく、提案と副作用の間に強制適用可能な遷移を設けることです。