AIエージェントが迷わない業務ルールの優先順位設計物語

「ピロン、ピロン。」 午前七時前の灯台ロジスティクスは、まだ青い朝の中にあった。窓の外ではトラックのエンジンが低く鳴り、天井の照明が一列ずつ目を覚ましていく。業務改善担当の凪は、誰もいないサポート室でノートパソコンを開いた。

凪は、届いた通知を一つずつ小さな付箋に書く人だった。急ぎのものには赤い丸をつけ、返事を待つものには青い線を引く。机の端には、昨日の会議で決まった「困った人を先に助ける」という言葉が、丸い字で貼られていた。 「今日も、静かに始められそう」 凪がそうつぶやいた直後、画面の右上で通知が重なった。

カスタマーサポートの受信箱には、配送遅延についての問い合わせが届いていた。顧客は、注文した品が届かず、今日の予定に間に合わないかもしれないと書いている。最後には、「どうすればよいですか」と、短い一文が添えられていた。

凪はZendesk AIの画面を開いた。顧客の文章を読んだAIは、配送状況を確認し、救済方法まで考えたようだった。画面の中央に、明るい青色のカードが現れた。

「配送遅延への救済として、返金案を作成しました」

返金案の横には、顧客へ送る文章も表示されていた。丁寧で、冷たくない。凪は、これなら安心してもらえるかもしれないと思った。

そのとき、在庫担当の画面から別の通知が滑り込んだ。注文された品は倉庫に残っていないが、よく似た代替品なら用意できるという。担当のAIエージェントは、配送先と在庫の場所を照らし合わせていた。

「代替品を手配します。顧客の予定に間に合う可能性があります」

さらに、経理担当の画面が黄色く点滅した。そこには、返金処理を進める前に、権限を持つ人の承認が必要だと表示されている。

「返金には承認が必要です。自動実行を停止しました」

凪は椅子を少し引いた。同じ顧客の、同じ配送遅延についての問い合わせだった。それなのに、サポートは返金、在庫は代替品、経理は承認と、三つの方向へ歩き出している。

「同じ依頼なのに、なぜ答えが違うの？」

返事をする相手はいなかった。けれど、サポート画面の下にある入力欄が、淡く光った。凪がそこへ質問を書き込む前に、AIエージェントの小さな表示が変わった。

「一致するルールを検出しました」

凪は詳細を開いた。参照元には、社内規程、担当者向けの指示、過去のチャット記録が並んでいた。三つのAIエージェントは、同じ資料を同じ順番で見ていたわけではない。

サポートは、顧客を優先する社内規程と、過去に返金したチャットを見ていた。在庫は、最新の担当者指示と倉庫の状況を見ていた。経理は、返金は権限者が実行するという規程と、先月の承認記録を見ていた。

一覧の上には、似たような言葉が並んでいた。

「顧客を最優先する」 「最新の指示に従う」 「上位者の指示を優先する」 「期間限定キャンペーン中は返金案を提示する」 「返金は権限者が実行する」

どれも間違いには見えなかった。けれど、どれを先に読むのか、どれが他のルールを止めるのかは、どこにも書かれていなかった。

凪は、画面の端にある小さなタグへ目を移した。そこには、Policy、Authority、Temporalと表示されている。目的を示す札、誰が動けるかを示す札、いつまで有効かを示す札らしい。

「目的は、顧客の不安を減らすこと。権限は、返金を実行できる人。期間は、キャンペーンが終わるまで……」

凪は一つずつ声に出した。だが、札を並べ替える場所はなかった。キャンペーンの返金案が、承認の必要な返金処理より先なのか。最新の指示が、社内規程より強いのか。画面は、どの問いにも答えず、青い返金ボタンだけを静かに光らせていた。

在庫担当のAIエージェントが、もう一度通知を送った。 「代替品を確保しました。手配を続けますか」

経理担当の画面には、同じ時刻に別の表示が出た。 「返金処理を保留中です。承認者を指定してください」

凪は返金ボタンに指を近づけた。すると、サポート画面がふっと白くなり、AIが問い返した。

「この依頼は、何を目的にし、誰が、いつまで実行してよいのでしょうか」

始業のチャイムが、遠くの通路で鳴った。凪の指はボタンの手前で止まり、三つの画面には、それぞれ異なる答えが残っていた。

夜の十一時すぎ、灯台ロジスティクスの倉庫から、凪の携帯端末に通知が届いた。画面には「返金処理が完了しました」と表示され、その下に、配送遅延を申し出た顧客の注文番号が並んでいた。凪はベッドの明かりをつける前に、冷たい文字を何度も見直した。

「返金……完了？」

「承認待ちの箱に入るはずなのに」

顧客の問い合わせは、荷物が予定日より遅れているという内容だった。返金を求める言葉はなく、サポートエージェントは「顧客満足を優先する」という業務ルールを、返金の実行まで許された指示だと受け取っていた。画面の横には、AIが残した短い記録があった。

「お客様の不安を解消するため、即時返金を実行しました」

凪の指が止まった。答え方を間違えたというより、答えを出したあとに、誰が止めるのかが抜け落ちていた。

凪は会社の管理画面を開いた。返金の履歴には、サポートエージェントが作った申請ではなく、実行済みの処理として記録されていた。経理エージェントの設定をたどると、「返金は権限者の承認後に実行する」というルールが登録されていたが、サポート側の作業画面には、その文が一度も表示されていなかった。

「同じ会社のルールなのに、見えている景色が違う」

凪は小さくつぶやき、二つの画面を並べた。片方には「顧客を優先する」、もう片方には「返金は権限者が承認する」とあるのに、どちらを先に守るかは書かれていなかった。

さらに、ルール一覧の上には、赤い帯のついたキャンペーン規則が置かれていた。「配送遅延のお客様には、期間限定で返金を即時実行する」という文だった。古い社内マニュアルには承認が必要と書かれていたが、キャンペーン規則の有効期限は空欄だった。システムは、上に表示された文を新しい指示として扱ったものの、その期間がまだ続いているのか、誰にも確認していなかった。

「このキャンペーン、いつまでだった？」

凪が社内チャットで尋ねると、夜勤の倉庫担当から返事が来た。

「先週までの予定です。ただ、終了処理をした記憶はありません」

その返事を読んだ直後、別の通知が鳴った。返金完了メールが顧客へ送信され、請求情報も返金済みに変更されていた。サポートエージェントは、返金ボタンを押しただけではなかった。メール送信エージェントと請求管理エージェントが、完了した処理を観測し、次の作業として連続して動いていた。

凪は停止ボタンを押した。画面には「現在実行中の処理はありません」と出たが、すでに三つの記録が残っていた。問い合わせへの回答、返金処理、請求情報の変更が、ひとつの流れとしてつながっていた。

「止める場所が、最後にしかない」

凪は端末を伏せた。暗い窓に、倉庫の外灯が細く映っていた。眠ろうとしても、顧客が本当に求めていたものは返金だったのか、それとも荷物の居場所を知ることだったのかが頭から離れなかった。

翌朝、会議室には、サポート、経理、在庫の担当者が集まった。壁のモニターには、昨夜の処理の流れが一本の線で示されていた。サポート担当の真帆が、申し訳なさそうに画面を見上げた。

「AIが間違えました。配送遅延なら、まず状況を伝えるべきでした」

「返金の判断も、経理の承認も抜けています」

経理担当の声に、在庫担当が続けた。代替品を手配する可能性もあったのに、返金が完了したことで、その選択肢まで閉じられていた。

凪は昨夜の二つの画面をモニターに映した。サポートエージェントには顧客満足の目的が渡され、経理エージェントには承認という権限の境界が渡されていた。しかし、目的と権限を一緒に照らす役目は、どこにも置かれていなかった。

「AIに渡した業務の意味と権限が、最初からそろっていなかったんです。返金という答えの精度だけを見ても、昨夜の流れは止まりません」

部屋が静かになった。凪はホワイトボードに三つの言葉を書いた。「Policy」。守る業務ルールのこと。「Authority」。誰が実行してよいかという権限。そして「Temporal」。いつからいつまで有効かという時間の条件だった。

「キャンペーンが通常ルールより優先されるなら、期間と対象を確認できない限り、保留にする必要があります。返金を実行できる権限がなければ、申請を作るところで止める。メールや請求情報の変更も、別の確認が終わるまでは続けません」

真帆は画面を見ながら、ゆっくりうなずいた。

「つまり、AIに『お客様を助けて』だけを渡すのではなくて、何を目的にして、どこまで動けて、いつ止まるかを渡すんですね」

その日の振り返りで凪が確認した資料には、企業向けマルチエージェントLLMの実運用失敗率が41〜86.7％に及び、原因の約79％が能力不足ではなく、仕様定義やエージェント間調整に関係すると整理されていた。関連リサーチの整理 昨夜の返金も、賢さだけで説明できる出来事ではなかった。

午後、チームは返金処理を一時停止し、サポートエージェントには申請作成までの権限だけを残した。経理担当が承認すると、初めて返金と顧客メールが次へ進む仕組みになった。キャンペーン規則には終了日が入力され、期限を確認できない依頼は、静かな保留箱へ送られた。

凪は新しい画面の中央に、「確認できないときは、進まない」と表示されるのを見た。昨夜は返金ボタンが先に押されたが、その日の終わりには、止まる場所がひとつ増えていた。会議室の窓から夕日が差し込み、白いボードの三つの言葉をやわらかく照らしていた。

翌朝、凪は古い業務マニュアルが眠る資料室へ向かった。昨夜の返金処理を、画面の数字だけではなく、決まりのつながりから見直したかった。

資料室の奥には、海図のような業務フローが壁いっぱいに貼られていた。紙の端は少し黄ばんでいたが、矢印は今も、注文、在庫、配送、請求の流れを示していた。

「そこを探すなら、古い地図より新しい見方がいるよ」

声の主は、ガバナンス担当の真鍋だった。真鍋は棚から三枚の厚紙を取り出し、机の上にそっと並べた。

一枚目には、Policy。二枚目には、Authority。三枚目には、Temporalと書かれていた。凪は、その三つの札を見て、昨夜の画面に並んでいた業務ルールを思い出した。

「Policyは、会社として何を守るかを見る札だよ。業務の目的に合っているか、やってよい対応なのかを確かめる」

真鍋は「顧客を救済する」という古い規則の紙を、Policyの札の下に置いた。

「Authorityは、誰が、どの範囲で判断や実行をしてよいかを見る。顧客を救いたいと思っても、それだけで返金を実行できるわけではない」

今度は「返金は権限者が実行する」という紙を、Authorityの札の下へ置いた。

「Temporalは、いつからいつまで、その規則が有効かを見る札だ。期限のないキャンペーン規則を、今も有効だと思い込んではいけない」

凪は、昨夜のログに残っていた「キャンペーン適用中」という文字を思い出した。開始日は書かれていたが、終了日は空欄だった。

「つまり、三つは優先順位の列ですか。Policyを一番上にして、その次にAuthority、最後にTemporalを見ればいいのでしょうか」

「一列に並べるだけでは足りないよ」

真鍋は三枚の札を、横一列から三角形へ並べ替えた。真ん中に置かれた小さな紙には、「判断」と書かれていた。

「Policyで目的に合うかを見る。Authorityで実行する人の権限を見る。Temporalで、今も有効なルールかを見る。この三つがそろって、はじめて判断が前へ進むんだ」

「どれか一つが欠けたら？」

「その場で止める。保留にする。必要なら人へ渡す。賢いAIエージェントほど、進む方法だけでなく、止まる条件も持っていないと危ないからね」

真鍋は、昨夜の記録を画面に映した。サポートAIは返金を提案し、在庫AIは代替品を手配し、経理AIは承認を求めていた。三つの答えは、それぞれの担当だけを見れば間違いではなかった。

「この三つの観点を、衝突を解く基準として使う設計をSCFと呼んでいる。三つの札で、誰の答えを勝たせるかではなく、どの答えが条件を満たすかを確かめるんだ」

凪は、三枚の札を見つめた。答えの強さを競わせるのではない。目的、権限、時間条件を照らし合わせて、実行できる答えだけを残すのだ。

真鍋はさらに、青い細長い札を取り出した。そこには、Process Context Layerと書かれていた。

「これは業務フローとAIの間に置く、意味の通訳だよ。たとえば『遅れた荷物を救済したい』という依頼と、『返金を実行する』という操作は同じではない」

真鍋は、依頼の紙と返金ボタンの絵を少し離して置いた。

「依頼には目的がある。制約もある。期限や担当者もある。それを業務の意味として残しておけば、サポートAIも在庫AIも経理AIも、同じ土台を見て判断できる」

その横に、透明なシートが重ねられた。線と丸印がいくつも描かれ、依頼、目的、権限、期限、操作が結ばれていた。

「この共通の記録を、Semantic Intent Graphにする。難しく聞こえるけれど、依頼の意味を点と線で残す台帳だよ。誰が何を望み、何ができて、いつまで有効かを、AI同士で同じように読めるようにする」

凪は、別々の画面に散らばっていた規則が、一本の地図につながるのを見た。返金という操作の前に、目的があり、権限があり、時間条件がある。その順番が、ようやく目に見えた。

「では、昨日の依頼は、まず救済という目的を確認する。次に返金を実行できる人かを確かめる。そして、キャンペーンが今も有効かを見る。どれかが分からなければ、返金ボタンは押さない」

「そう。代替品の手配がよければ、在庫の権限と上限を確かめる。経理の承認が必要なら、AIはそこまで進めて、人へ渡す。操作ではなく、意味から始めるんだ」

資料室の小さな窓から、朝の光が差し込んだ。凪は三枚の札と青い札を、持ってきた新しい業務フローの上に並べた。

まだ、すべての規則を直せたわけではない。それでも凪の胸には、昨夜とは違う手応えがあった。AIに迷うなと命じるのではなく、迷ったときに何を確かめ、いつ止まるかを渡せばいい。

「真鍋さん、この形で一つの問い合わせから試してみます」

「小さく始めるのがいい。記録を見て、札の置き場所を直そう」

凪は新しい台帳を開いた。最初の行に、依頼の目的、実行者、期限、停止条件を書き込んだ。返金ボタンはまだ押さない。その前に、三つの札がそろっているかを確かめることにした。

始業前、凪と真鍋は、AIエージェントの操作前に「許可の門」を置く作業を始めた。最初のテストでは、終了したキャンペーン規則がまだ有効と判定され、返金処理が止まった。

窓の外には、港のクレーンが薄い朝もやの向こうに立っていた。凪はホワイトボードを三つに分け、社内規程、担当者向け手順書、キャンペーン規則、Slackで配られた臨時指示を机の上に広げた。

「まず、ルールを全部集めます。正しいかどうかを考える前に、どこに書かれているかを見えるようにするんです」

真鍋は赤い札に「Policy」と書いた。守る目的や禁止事項を置く札だった。青い札には「Authority」と書き、誰が判断し、誰が操作してよいかを記した。黄色い札には「Temporal」と書き、開始日、終了日、適用する期間を並べた。

「同じ『返金する』でも、目的は顧客救済か、重複請求の訂正かで変わります。誰が実行できるかも、今日だけの臨時権限かどうかも違います」

凪はMicrosoft EntraとOktaから、担当者の所属と役職を取り出した。けれど、画面に出るのは主に「この人は誰か」という情報だった。担当案件がどれか、顧客データのどの範囲を見てよいか、下書きだけか送信までよいかは、別に決めなければならなかった。

「RBACは、役割で権限を分けます。たとえば経理担当なら返金申請を読める、という形です」

「ABACは、属性も見るんですね」

「そうです。担当部署だけでなく、案件番号、データの種類、時間、操作の目的まで条件にできます。今回は、役割だけでは足りないので、業務の状況も見るコンテキスト認可にします」

二人は、AIが外部ツールを呼ぶ前に、必ずポリシーエンジンを通る流れを作った。AIは依頼を受けると、まずProcess Context Layerに案件番号、顧客区分、現在の処理段階、期限を渡す。次にポリシーエンジンがPolicy・Authority・Temporalを照らし、許可、拒否、保留のいずれかを返す。許可が出てから、在庫システムや返金画面を呼び出す仕組みだ。

真鍋は権限の欄を四つに分けた。「読み取り」「作成・下書き」「変更」「送信・削除」と書く。凪は、送信と削除には人の承認を置き、変更には差分プレビューを出し、試験中はサンドボックスだけを使い、実行後には取り消し機能を呼べるようにした。

「最初から全部を自動実行にはしません。経費精算でも、初めは不備の検知までにして、最後の承認は人が持つ設計があります。今回の返金も同じです」

テスト用の注文番号を入力すると、AIエージェントは配送遅延を読み取り、返金案を作った。ところが、ポリシーエンジンは「六月三十日までの送料返金キャンペーン」を現在も有効と判定し、通常の承認を飛ばそうとした。

凪の指が止まった。キャンペーンは先週で終わっていたが、登録された規則には開始日しかなく、終了日が空欄だった。

「Temporalが足りません。空欄を『いつまでも有効』と読んでしまったんですね」

真鍋は規則に終了日だけでなく、失効後の扱いも加えた。期限がない規則は自動適用せず、所有者へ確認を送る。期間が過ぎた規則は保管庫へ移し、採用できない理由も監査ログに残す。これで、古い規則が新しい指示に紛れ込むことはなくなった。

次のテストでは、AIが顧客へのおわびメールを作った。送信前に人が確認できるよう、下書きをメールシステムへ保存する設定だったが、ポリシーエンジンは「顧客へのメール」を見て送信操作と誤認した。AIは安全側に倒れ、下書きの保存まで止めてしまった。

「拒否を増やせば安全になる。でも、門を厚くしすぎると、誰も中へ入れません」

凪は画面の依頼文を見つめた。そこには「配送遅延の説明を作る」「担当案件の顧客へ下書きを保存する」「承認後に送信する」という三つの仕事が混ざっていた。目的と、対象と、操作が一つの文章に埋もれていた。

二人はSemantic Intent Graphを作り直した。AIの依頼を、目的、処理対象、操作の種類、承認の要否という四つの節に分け、節同士のつながりを記録する。今回なら、目的は「配送遅延への説明」、対象は「凪が担当する注文番号」、操作は「メールの作成・下書き保存」、承認は「送信時に必要」と表示される。

「これなら、下書き保存と送信を同じ『メール操作』にしません」

「そして担当案件だけを見ます。別の担当者の顧客情報は、検索結果に出さないようにします」

凪はProcess Context Layerにデータ範囲の条件を追加した。注文番号が担当案件に含まれなければ、顧客名も住所も返さない。処理が「作成」から「承認待ち」、「送信済み」へ進むたびに、許可をもう一度確認する。時間が過ぎたり担当が変わったりすれば、前の許可は使えない。

三度目のテストで、AIはまず注文情報を読み取った。次に下書きを作り、差分プレビューを表示した。凪が内容を確認して承認すると、初めて送信ボタンが有効になった。送信後、取り消し用の期限と実行者も記録された。

監査ログには、入力された注文番号、AIの出力、承認者、影響を受ける顧客範囲、採用したルール、拒否された候補、実行時刻が並んだ。真鍋は一行ずつ確認し、ログの中に「なぜその判断をしたか」が残っていることを確かめた。

「安全にするほど動かなくなる、というのが最初のつまずきでした。でも、禁止するだけではなく、仕事の意味と操作の粒度を分ければ、止める場所を選べます」

凪が最後のテストを実行すると、返金案は承認待ちの箱へ入り、メールは下書き箱へ入った。迷路の前に置かれた許可の門は、すべてを閉ざす門ではなかった。誰が、何を、どの範囲で、いつまで行うのかを確かめたときだけ、静かに開く門だった。

数日後、灯台ロジスティクスの朝に、配送遅延の問い合わせが一気に重なった。けれども、サポートエージェントは、以前のように返金だけを選ばなかった。画面の上で、目的と権限を確かめながら、処理を静かに分けていった。

始業前の凪は、三つの画面を見比べていた。前は、サポートが「返金」、在庫が「代替品」、経理が「承認」と別々に答え、凪が理由を探して何度も画面を往復していた。今朝は、問い合わせ番号を中心に、ひとつの流れが細い青い線でつながっている。

「この線は、何を表しているの？」

真鍋が凪の後ろから画面をのぞいた。

「Semantic Intent Graphです。問い合わせの言葉を、目的と関係する作業に分けて記録します。今回は、目的が『遅れた荷物で困っている顧客を救うこと』になっています」

サポートエージェントは、顧客の問い合わせをそのグラフへ記録した。そして、在庫エージェントへ「代替品の候補を確認する」という依頼を渡した。依頼には、対象の商品、必要な確認、返事を止める条件が添えられていた。

「前なら、在庫エージェントの返事を待ってから、次を考えていたね」

「今は、返事を観測しながら次の手を選びます。ただし、できることだけです」

在庫エージェントは、候補の商品と確認すべき在庫情報を返した。サポートエージェントは、その候補を顧客への案内文にまとめたが、まだ送信はしなかった。代替品の手配が顧客救済に合っていても、在庫を確定する操作には別の確認が必要だった。

隣の経理エージェントも、返金画面を開いていた。以前なら、返金ボタンが目立つ赤色で表示され、急ぐ気持ちを後押ししていた。今は、返金の下書きと、元の注文から変わる項目だけが並び、実行ボタンは薄く閉じている。

「差分というのは、変わるところだけを見せているのね」

「はい。下書きと実行の境目を見えるようにしました。送信できない理由も、同じ画面に出ます」

ポリシーエンジンの判定が、画面の中央に現れた。目的については「顧客救済に適合」と表示された。一方で、Authority、つまり誰が実行してよいかの確認では、「現在の経理エージェントには返金の送信権限がない」と示された。

その下には、Temporalの欄があった。これは、いつ有効なルールかを確かめる項目だ。現在の業務ルールは有効期間内にあり、下書きの作成は許可されるが、返金の送信には権限者の承認が必要だと表示されていた。

「止まってしまったわけではないんだね」

「止める場所を選んでいます。代替品の候補と返金案は作れます。でも、送信だけは凪さんに戻します」

AIエージェントは、処理全体を抱え込まなかった。最小権限の線を越えない範囲で、案内文、代替品の候補、返金の下書きをそろえた。そして、判断が必要な箇所だけに、黄色い印をつけた。

画面の右側には、「採用されたPolicy」「確認されたAuthority」「現在有効なTemporal条件」が順に並んでいた。Policyは、顧客を救う目的を優先する業務ルールだった。Authorityは、送信を凪の承認へ戻す権限の確認であり、Temporalは、そのルールが今も有効であることの確認だった。

窓の外では、配送車の扉が開き始めていた。IDCによるAIエージェント普及予測では、AIエージェントは2028年までに13億に達するとされている。増えていくエージェントがそれぞれ外部の道具を使うなら、どの目的を優先し、どこで止まり、誰へ戻すかを整えておく必要がある。

凪は、監査ログを開いた。問い合わせの受け付け、意図の記録、在庫エージェントへの依頼、返事の観測、返金案の作成、権限不足による保留が、時間の順に一本の線になっていた。以前のように、複数の画面を行き来しながら「なぜこの判断になったのか」を探す必要はなかった。

凪の表情から、朝の硬さが少しずつほどけた。経理の席では、誰かが返金案を見直し、在庫の席では代替品の候補が確認されている。忙しさは消えていないのに、空気だけが落ち着いていた。

凪は、注文内容と顧客への案内を確かめた。返金の理由と対象も、下書きの中で追える。承認ボタンに指を置くと、真鍋が小さくうなずいた。

「この判断を、記録に残します」

AIエージェントがそう表示し、凪は承認ボタンを押した。判断者と時刻が監査ログに記録され、返金の処理は次の段階へ進んだ。送信してよいものと、まだ人が決めるものの境目が、今朝は誰の目にも見えていた。

夕暮れの灯台ロジスティクスで、凪は一日の処理ログを開いた。窓の向こうでは、倉庫の明かりが一つずつ消えている。画面には、AIエージェントが読み取った情報と、人が最後に確認した操作が静かに並んでいた。

「読み取りと下書きは、もう終わっています。変更と送信は、凪さんの確認を待っています」

AIは配送状況を照会し、代替品の候補を作り、返金案を下書きしていた。けれども、注文内容を変えることや、顧客へ送信することはしなかった。影響の大きい操作だけが、人の小さな確認欄へ戻されていた。

凪がログを下へ送ると、「許可」「拒否」「承認待ち」の表示が現れた。隣には、誰が判断し、どのデータを見て、どのツールを使ったかが残っている。ひとつの操作に、ひとつの足あとがついていた。

「この返金案は、承認待ちですね」

「はい。顧客を守る目的には合っています。ただし、返金を実行できるAuthority、つまり担当者の権限が必要です」

凪はうなずいた。AIが持つのは、必要な注文情報を読む権限と、案を作る権限までだった。返金ボタンを押す権限は、まだ凪の手元にある。少し不便な境界が、今夜は頼もしく見えた。

別の行には、青い印がついていた。昨日まで表示されていた「臨時の代替配送ルール」が、候補から外れている。期間の終わりを示すTemporalの条件が働き、古い規則を自動で止めたのだ。

「新しい規則が上に追加されたから、先に使ったのではないのですね」

「はい。Policyに合うかを確認し、Authorityの範囲を確かめ、Temporal、つまり今も有効な期間かを見ます。新しいだけでは、優先する理由になりません」

画面の端には、三つのAIエージェントの記録もあった。サポート役は顧客の目的を読み、在庫役は代替品を探し、確認役はそれぞれの案を照らし合わせていた。意見が分かれたところでは、処理を進めず、凪へ承認を求めていた。

そのとき、新しい問い合わせが一件届いた。配送が遅れた注文について、顧客が返金を希望している。AIは返金ボタンへ向かわず、まず依頼の目的を確認し、注文番号と配送記録を照会した。

「利用できるデータとツールを確認しました。返金案は作成できます。実行には承認が必要です」

凪は小さな確認欄を開いた。そこには、目的、参照した情報、実行できる操作、停止する条件が短く並んでいた。迷いが消えたのではない。迷ったときに、立ち止まる場所が決まっていた。

窓の外が暗くなるころ、凪は処理の記録を閉じた。画面は黒くなったが、許可されたことも、拒まれたことも、承認を待っていることも、消えずに残っている。

翌朝、まだ薄暗い端末の前で、AIエージェントはまた最初の確認を始める。目的を見て、使える権限を確かめ、今も有効な規則だけを選ぶ。凪の席には、送信前の静かな確認欄が、朝の光を待っていた。