AI自動化を安全に委ねるための体験と実行基盤の設計

チャットUIは、曖昧な依頼を言葉で渡せるため、AI機能の入口として有効です。しかし、業務システムの更新や外部サービスへの操作まで任せる場面では、会話の流れだけに判断・権限・実行結果を閉じ込めると、何が起きたかを後から確かめにくくなります。モデルが意図を取り違えた時に、誰がどの操作を許可し、どのデータを変え、どこまで戻せるのかも曖昧になります。

LLMは確率的に文章や計画を生成するため、同じ状況でも出力が揺れます。一方、権限判定や更新処理には再現性が必要です。ここでLLMに直接アクセストークンや更新権限を渡すと、モデルの出力がそのまま実行可能な命令になります。安全性をプロンプトの注意書きだけで支える構成は、権限境界として弱すぎます。

必要なのは、判断と実行を分け、人が判断に参加できる情報を画面に残すことです。AIは「何をすべきか」の候補と計画をつくり、決定的な実行基盤は「誰が、どの条件で、どの操作を実行できるか」を検査します。UIはこの二つをつなぎ、人が委任の範囲を調整できる場所になります。

安全な自動化は、一回の指示と実行で完結しません。利用者が情報を受け取り、意味を判断し、委任範囲を決め、実行を観察し、後から振り返る連続した体験です。この流れのどこかが欠けると、便利でも利用者が責任を持って使い続けることは難しくなります。

最初の「受け取る」では、通知、期限、異常、入力待ちの情報を、重要度と根拠とともに提示します。次の「判断する」では、AIが状況の要約だけでなく、選択肢、期待される影響、判断に使った情報を示します。「委ねる」では、利用者が対象、期限、操作範囲、予算などを確認し、必要な場合だけ明示的に承認します。

「実行を見る」では、実行中か、待機中か、失敗したかを、個々のツール呼び出しまで追えるようにします。最後の「振り返る」では、実行結果、根拠、承認、変更前後、取消または修正の可否を履歴として残します。5段階を一つの画面へ詰め込む必要はありませんが、段階間で情報が失われない設計が重要です。

アーキテクチャでは、LLMを判断・計画の層に限定します。ここでは、状況を整理し、可能な操作を選び、依存関係を含む実行計画を構造化して返します。計画は自然言語の説明だけでなく、ツール名、入力候補、想定結果、危険度、必要な承認を含むデータとして扱うと、UIと検査層の双方で再利用できます。

実行は、型付きツールAPIだけが担います。各ツールは、入力スキーマ、出力スキーマ、副作用、取消可能性、必要な権限を明示します。たとえば更新系のツールは、対象IDだけでなく、更新前の版番号や期待状態を受け取り、途中で状態が変わっていれば停止するようにします。LLMが直接データベースや外部APIを操作する経路はつくりません。

ポリシー層は、実行前に利用者、組織上の役割、対象データ、委任済みの範囲、時間帯、危険度を照合します。ツールが実行可能かどうかは、LLMの提案内容ではなく、この層の判定で決めます。UIは、計画、承認、実行中の状態、履歴を表示・編集する責務を持ち、実行権限そのものを画面表示の有無に依存させません。

状況カードには、いま起きていること、影響を受ける対象、急ぎ度、情報源の更新時刻を置きます。次に判断カードで、AIの推奨、代替案、推奨しない理由、判断の根拠を分けて表示します。要約文だけでは利用者が誤った前提に気づきにくいため、根拠となる記録へ戻れる導線を用意します。

実行プレビューは、承認の直前に「どのツールを、どの順序で、どの対象へ呼ぶか」を固定した形で見せます。更新前後の差分、外部への送信内容、想定される待機時間、失敗した場合の停止位置を表示すると、利用者は便利さと引き換えに何を委ねるかを判断できます。承認UIは、単に実行ボタンを置くのではなく、承認者、承認時刻、承認した計画の版を記録します。

実行後はタイムラインで、計画作成、承認、各ツールの開始と完了、入力検証、ポリシー拒否、再試行、取消の順序を示します。監査・記憶は、会話履歴をそのまま保存する場所ではありません。後から検証に必要な、状況の要約、根拠ID、計画、承認、ツール入出力の要約、結果、修正を関連づけて保存する場所として設計します。

すべての操作を毎回承認にすると、自動化は使われなくなります。反対に、すべてを自動実行にすると、利用者が意図しない変更を見落とします。承認の要否は、操作が情報を見るだけか、外部へ影響するか、戻せるか、影響範囲を事前に確定できるかで分類します。

閲覧・要約は、権限を持つ情報の範囲内であれば、原則として都度承認を省けます。下書きは、保存先を明示し、送信や公開を別操作にすることで委任しやすくなります。可逆操作は、差分と取消期限を示したうえで、条件付きの自動実行を検討できます。高影響または不可逆な操作は、対象と結果を固定した明示承認に寄せ、複数人の承認や時間を置いた再確認が必要な場合もあります。

外部からのリクエストを受ける公開APIは、認証、入力検証、レート制限、監査の入口にします。ここで利用者の権限と委任状態を解決し、推論に必要な最小限の文脈だけを内部へ渡します。公開経路に推論用の資格情報や広い実行権限を置かないことで、外部公開面と実行面の影響範囲を分けられます。

推論基盤は、必要に応じて閉域ネットワークで動かし、公開APIからのみ到達できるようにします。推論側は、文脈の整理、モデル呼び出し、計画の構造化までを扱い、実行用の認証情報には触れません。型付きツールAPIへ渡すのは、ポリシー層を通過した構造化計画だけです。

モデルは固定前提にせず、軽量なモデルと高品質なモデルを処理の性質で振り分けます。短い分類、入力の正規化、既知の形式への変換は軽量なモデルへ、根拠の比較や複数段階の計画は高品質なモデルへ送ると、応答時間と費用を制御しやすくなります。モデル選択の理由、入力サイズ、結果の品質指標を監査に残すと、後からルーティングを見直せます。

もっとも避けたいのは、LLMに直接権限を渡すことです。モデルの出力に権限を判断させるのではなく、実行のたびにポリシー層とツールAPIが検査する必要があります。プロンプトで「この操作はしない」と指示しても、それはアクセス制御にはなりません。

次に、実行内容を利用者から隠す設計です。自動化が複数のツールを呼ぶほど、完了通知だけでは失敗の原因も影響範囲も分かりません。実行プレビュー、タイムライン、結果の差分を設け、拒否・中断・失敗も成功と同じ粒度で表示します。

根拠や取消可能性を示さないことも、利用者の判断を難しくします。提案には根拠への参照を、更新には変更前後と戻し方を、不可逆操作にはその事実を明示します。また、特定モデルの応答形式や性能を前提に計画・実行を密結合させると、モデル変更時に安全性まで崩れます。モデルの差は推論アダプタへ閉じ込め、ツール契約とポリシーはモデルから独立させます。

テストは、LLMがもっともらしい計画を返すことだけでは足りません。権限不足、委任期限切れ、対象の状態変更、入力スキーマ不一致、承認した計画の改変、ツールのタイムアウト、途中失敗、取消要求を含めて、実行基盤が期待どおり停止するかを検証します。ポリシー判定とツールAPIは、モデルを使わない決定的な単体テストを厚くできます。

結合テストでは、計画の版と承認の版が一致しない時に実行されないこと、再試行で同じ更新が重複しないこと、実行タイムラインと監査記録が矛盾しないことを確認します。外部連携を持つ操作は、検証環境での模擬実行と、本番の読み取り専用確認を分け、実データに対する検証の範囲を狭く保ちます。

運用では、モデルごとの失敗率、ポリシー拒否率、承認後の取消率、手動修正率、ツールごとの実行時間を観測します。数値を単純な成功率だけにまとめず、どの段階で利用者の判断が止まっているかを見ることで、モデル、UI、ツール契約のどこを直すべきかを判断できます。

AI自動化を設計する時は、「モデルが何をできるか」より先に、「利用者が何を見て、どこで委ね、実行後に何を確かめられるか」を決めます。判断・計画を担うLLM、実行を担う型付きツールAPI、権限を検査するポリシー層、承認と履歴を担うUIを分けると、それぞれを変更しても安全境界を保ちやすくなります。

具体的には、操作をリスクと取消可能性で分類すること、承認する計画を版として固定すること、実行の全段階を監査可能にすること、モデルを差し替えられるようにすることが、最初に置くべき判断軸です。自動化は人の判断を消すためのものではなく、判断が必要な場所を明確にし、委ねた後も責任を持って扱えるようにするための仕組みとして設計します。