- 公開日
AIの回答を読んで自分で作業する場合と、AIに外部システムの操作まで任せる場合では、確認する対象が変わります。前者では回答の内容と根拠を確かめます。後者ではそれに加え、どこまで操作してよいか、いつ止めるか、何をもって完了とするかを決め、実際の結果を確認します。
違いは、単に会話が長いか短いか、AIが高性能かどうかではありません。利用者の代わりに情報を送る、予約を作る、記録を更新するなど、外部の状態を変える範囲を渡すと、その範囲に対応した権限と確認が必要になります。
回答ができたことと、仕事が終わったことは違う
例えば「出張に向く移動方法を教えて」と質問するなら、候補、費用の目安、比較条件を受け取り、人が選ぶ使い方です。回答に誤りがあれば選択を誤るリスクはありますが、回答を生成しただけで予約が確定するわけではありません。
一方、「この便を予約して」と頼むと、対象の便、利用者、金額、支払方法、取消条件などを確認し、予約先で操作する工程が加わります。予約したつもりでも、最後の確定操作が済んでいなければ予約は未完了です。逆に、応答が返らなくても予約が成立している場合があるため、「失敗した」と決め付けてもう一度予約することも避けます。
AIエージェントという語の使われ方は一様ではありません。Anthropicの設計記事は、あらかじめ定めた経路で処理するワークフローと、モデルが手順やツール使用を動的に進めるエージェントを区別しています。これは実装の整理であり、どちらの名称でも外部操作に伴う確認を省けるわけではありません。Building effective agents
そのため、製品名や「自律型」という表示だけで任せる範囲を決めず、実際に何を読み、何を書き、誰へ送るのかを確認します。候補を比較する機能と予約を確定する機能を別々に許可できるなら、必要な方だけを使う選択もできます。
出張の候補を提案する依頼を明確にする
架空の例として、会社員が翌月の社内研修へ出張する場面を考えます。出発地と目的地、開催日、午前十時の開始、社内で認められた予算が資料にあるとします。具体的な便や運賃はここでは調査せず、依頼の設計だけを扱います。
「出張をいい感じに手配して」という元の依頼では、候補を出すだけか、予約まで進めるかが分かりません。まず提案段階は、「資料の出発地、目的地、日付、到着条件、予算に合う移動候補を比較してください。予約や購入は行わず、候補の条件、確認時点、未確認事項を示してください」と直せます。
この段階の完了条件は、判断に必要な候補と条件が揃うことです。出発・到着の時刻、移動にかかる時間、比較した費用の範囲、変更や取消の条件を確認します。検索で確認できない項目は未確認として残し、一般的な知識で埋めません。実際に情報を取得できなかったなら、実在の候補を調査済みとして示さないことも必要です。
依頼文の差し替え箇所は、日付、場所、到着の余裕、費用に含める範囲、比較したい条件です。「午前十時に始まる」ことから、会場までの移動や受付時間をどう見込むかは判断が必要です。確認できる資料を調べ、重要な不足だけを利用者へ聞くようにします。依頼時に作業・材料・条件をどう伝えるかの基本は、AIに仕事を任せる前に押さえたい5つの原則で扱っています。
予約へ進むときは、別の完了条件を足す
利用者が候補を選び、予約を任せると決めたら、対象を具体的に固定します。「先ほどの安い便」では、表示順や価格の変化で別の候補になるおそれがあるため、日付、区間、便や列車、人数、条件を確認できる形にします。
費用は基本料金だけでなく、その予約に必要な税や手数料、荷物などの必須条件を含めて確認します。変更・取消の制限が意思決定に影響するなら、それも承認前に示します。承認後に価格や条件が変わった場合は、既に許可された範囲に収まるかを確認し、範囲を超えるなら実行前に戻ります。
ここで、予約先へログインできることと、今回の予約をしてよいことを分けます。保存された決済手段が使えても、無関係な追加商品や別日程の購入まで許可されたことにはなりません。AIが必要と考えた追加サービスも、依頼の範囲や承認条件に従って判断します。
また、入力する個人情報を必要な範囲に絞ります。予約先へ渡す情報と、社内の出張理由など予約に不要な情報を混ぜません。利用するサービスに応じた承認や本人操作が必要な工程があれば、そこで人へ引き継ぐことも、委任の条件に含めます。
実行後は、外部の記録と照合する
予約の完了は、AIが「予約しました」と回答したことではなく、予約先の確認画面や確定記録などで確認します。対象、日程、利用者、金額、状態が承認した内容に合うかを照合し、確認番号など後から見直すための情報を残します。
Anthropicの同記事のAgentsの節も、エージェントが各ステップでツールの実行結果など環境から実際の状態（ground truth）を得て、進捗を評価することを重視しています。言葉だけで進捗を推測せず、操作先の状態を使うという考え方は、予約の確認にも当てはまります。
申込を受け付けただけ、支払待ち、確認待ちといった予約先の表示を、AIが報告の中で「確定」と言い換えてはいけません。予約完了と決済完了が別に表示されるなら、両方を確認します。どの証拠で何が分かったかを分ければ、利用者も次の対応を判断できます。
応答が途切れた場合は、「操作の結果を確認できていません」と伝え、対象の予約状態を調べます。重複しないと確認できるまで、同じ操作を安易に繰り返しません。確認手段がないなら、予約先の公式窓口など、利用者が状態を確かめられる方法へ引き継ぎます。
人へ戻す条件を先に決める
人への引き継ぎは、何でも分からなくなったら丸投げすることではありません。予算を超えた、候補がなくなった、必要な本人操作がある、権限を確認できない、実行結果が不明になった、といった条件を具体的に決めます。
引き継ぐときは、終わった作業、止めた箇所、確認できた事実、選択肢を渡します。例えば「選んだ便は売り切れです。予約はしていません。到着条件に合う別候補がありますが、費用が許可範囲を超えています。別候補へ変えるか判断が必要です」とすれば、利用者は何を決めればよいか分かります。
逆に、操作結果が不明なのに「予約はしていません」と言ってはいけません。状態に応じて表現を変え、何を確認すれば再開できるかを示します。停止の理由が権限不足なら、より強いアカウントへ勝手に切り替えることは解決になりません。
NISTのAI RMF Coreは、GOVERN 3.2で、人とAIの組み合わせや監督における役割と責任を定めることを挙げています。AIへ作業を渡しても、重要な判断やリスクへの責任を誰が引き受けるかは組織側で決める必要があります。AIの性能が上がっても人が決め続ける事項については、AIの性能が上がっても、人間が決めるべき目的・責任・完了条件で整理しています。
任せる工程を増やす前に、小さく一巡させる
最初から候補検索、予約、社内申請、予定表登録、関係者への連絡を一つの依頼へまとめる必要はありません。候補提案だけで目的を満たすなら、その範囲で十分な場合があります。実行を加えるなら、まず一つの操作について、承認から結果確認まで追えるかを確かめます。
例えば、候補の比較はAIが担当し、予約の最終操作は人が行う分担も考えられます。逆に、条件が明確で、権限と確認経路が整った定型操作なら、許可した範囲で実行まで任せる選択ができます。どちらが優れているかではなく、失敗時の影響と確認にかかる負担で選びます。
任せた後は、成功件数だけでなく、人が修正した内容、保留の理由、確認にかかった時間も見ます。処理が速くても、結果を確かめるために毎回すべてやり直すなら、委任する範囲や完了条件を見直す余地があります。改善したという評価には、実際の記録が必要です。
AIに仕事を任せるとは、曖昧な目的を渡して放置することではありません。対象と範囲を決め、完了を外部の状態で確認し、判断が必要な場面では人へ戻す流れを渡すことです。回答の利用から一歩進めるときは、この流れが作れているかを確認します。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
