エージェントアシスタント：安全なカレンダーおよびGmail統合

私の主張：カレンダー、Gmail、および接続されたアプリで動作する安全で使いやすいエージェントアシスタントを構築するには、権限を最優先にするランタイムの設計、計画と実行の分離、監査およびロールバックフローを実行層に日初めから組み込む必要があります。この記事では、到達するための緊密なエンジニアリングチェックリストと実行可能なプロンプトを提供します。

エージェントアシスタントのための権限設計

ユーザーごとのOAuthと最小特権スコープから始めます。管理者が明示的にドメインの委任を要求しない限り、共有サービスアカウントではなくユーザーにバウンドしたOAuthを使用します。Googleの細かなスコープに関するドキュメントが基準です；すべてのエージェント機能を単一のOAuthスコープにマッピングし、そのスコープの人間が読める意図を文書化します。トークンはプロンプトから除外します。ボールトに保存し、ポリシーを強制する実行サービスの内部で呼び出し時にのみ資格情報を注入します。

許可を製品UXとして扱うチームは、明確な同意画面とスコーププレビューを持っており、サポートチケットが著しく少なくなることを観察しました。我々が直面した問題の一つは、素朴なリフレッシュロジックからのトークン増殖です；リフレッシュを集中管理し、リフレッシュトークンを定期的に回転します。

計画と実行

アシスタントをプランナーとアクチュエーターに分けます。プランナーは最近のスレッドを読み、2つの会議時間を提案し、ドラフトメールを作成する明確なアクションプランを生成します。アクチュエーターは、ポリシー確認と、敏感なアクションに対する人間の確認ステップの後にのみ実行します。このパターンは、モデルが特権操作を即興で行うのを防ぎ、認可を監査可能にします。

実用的なトレードオフ：人間の承認による遅延がリスクを低下させることに対するものです。多くのカレンダーやメールアクションの場合、30〜60秒の人間介入待機が許容されます。高頻度作業に対しては、アクションごとのクリックよりもバッチ承認が効果的です。

テスト、ログ、および回復

すべてのアクションは、要求された意図、プランナーの出力、ポリシー決定、アクターコール、および返されたAPIレスポンスを含む不変な監査エントリを生成する必要があります。リプレイ可能なコマンド形式を保持して、リプレイおよびロールバックできるようにします。直近N件のアクションに対してワンクリックの取り消しを提供し、イベントをキャンセルし、修正のフォローアップを送信するなどの補償イベントを作成する回復フローを提供します。

プロンプトレベルのガードレールは、外部ポリシーエンジンがない場合に失敗することを観察しました。実際には、モデルが見た目には妥当でもポリシーに違反する変更を提案することがあります。信頼度が調整された閾値以下のときに任意の書き込みを拒否する実行ゲートは、これらのインシデントを減少させます。

製品およびエンジニアリングのチェックリスト

1. ユーザーごとのOAuthと最小スコープ、および明示的な同意文。 2. ランタイムで資格情報を注入するトークンボールトと実行サービス。 3. ポリシー確認付きのプランナー/アクターの分離。 4. 敏感なアクションのための人間介入のエスカレーション。 5. 不変の監査ログとリプレイ可能なアクション形式。 6. 明確なUIの配慮とともにロールバックおよび補償フロー。

製品UXを人間とAIのワークフローの設計に記載されたワークフローパターンにリンクし、AIエージェントとチャットボットの違いのプライマーを使用してプランナー/アクターの分割を正当化します。

自分でも試してみてください。以下のプロンプトは、プランナーの出力とアクチュエーターの安全な指示を示しています。プランナーからは簡潔なJSONのような計画を、アクチュエーターからは短い確認を期待してください。

このプロンプトは、候補となる会議時間の制約付き計画とその理由を生成するようモデルに要求します；これをプランナーとして使用します。候補スロットは2〜3件、各スロットの1文の理由を期待してください。

あなたは会議のプランナーです。ユーザーには3つの空き時間があります：午前10時、午後2時30分、午後4時。ISO形式で正確に3つの候補会議時間を返し、各々の1文の理由と、招待が外部のメールに触れるかどうかを示す1文のプライバシーノートを提供してください。

このプロンプトはアクチュエーターのためのものです。人間確認トークンとプランYが与えられた場合、イベントを作成する前にポリシーチェックを行い、ポリシーチェックがパスした場合にのみCalendar.CreateEventを呼び出すことを期待します。

アクチュエーター：ユーザー確認トークンXとプランYのもと、policy_check(policy_id:calendar_write)がパスした場合のみ、フィールド{start,end,attendees,summary}を使ってCalendar.CreateEventを呼び出します。policy_checkが失敗した場合は、失敗コードと人間の行動が必要であることを返します。

反論としては、厳格なコントロールが採用を遅らせるということです。私の推定では、チームがこれらのパターンを強制すると、初期のユーザー保持が改善されます。信頼が高まるためです。初期のアクティベーションが遅くても、それによるトレードオフは明確です：これらのコントロールなしで迅速に展開すると、測定可能なリスクと高い修復コストが生じます。