本文へスキップ
メニュー

ガイド · 権限と監督

エージェントが操作する前に、境界を定義。

回答するエージェントと、記録を変更するエージェントでは責任が異なります。情報提供から操作へ進むには、誰が何を、どの条件で実行でき、結果をどう確認するかを明確に決める必要があります。

関与の3つの段階を区別

読み取りは、許可された情報源から情報を取得します。提案は、人が検討する操作案を示します。実行はシステムの状態を変更します。完全な自律性を前提とせず、業務フローに必要な段階を選びます。広い操作権限を検討する前に、情報と提案を評価できます。

実行するIDを特定

操作を実行するID、その権限、権限変更の責任者を定義します。文脈の理解によって権限が与えられるわけではありません。元システムのアクセスを確認し、担当者の役割変更も含め、範囲が役割と作業に合っていることを確かめます。

承認が必要な条件を定義

承認を業務フローに組み込みます。承認者、提示する証跡、応答がない場合や情報不足時の対応を定義します。例として、エージェントが変更申請を準備し、業務責任者が実行前に影響を確認する流れがあります。

実際に起きたことを確認

システムへ要求を送っても、完了した証拠にはなりません。設計では結果を検証し、部分的な成功に対処します。重複操作の防止、システム間の不整合の解消担当、経緯の再現に必要な情報を定義します。

停止と復旧を計画

すべての操作を元に戻せるわけではありません。停止、修正、補償処理が可能か、その権限者は誰かを評価します。安全な復旧方法がない場合は、人が実行し、エージェントは情報と推奨の準備を担当できます。

原則を製品ごとの範囲に具体化

これは計画の枠組みであり、全製品に全管理機能があるという主張ではありません。適合性評価で、製品が提供する仕組み、元システムが実施する管理、組織的手順が必要な段階を特定します。実環境で操作を有効にする前に、不足と責任者を合意します。

次のステップ

どの操作を評価したいですか?

操作を業務フローに接続する前に、情報源、実行ID、承認、検証を定義します。

ユースケースについて相談