AIエージェント導入前、非構造化データの例外を洗い出す旅

朝七時四十五分。星川商事の八階にある受注センターでは、複合機の低い音と、キーボードをたたく音が重なっていた。窓の外には、まだ少し青い朝の空が広がっている。業務改善担当の水野葵は、紙コップのコーヒーを横に置き、二つのモニターを見つめていた。

画面には、緑色の「処理完了」が縦に並んでいた。顧客名、商品コード、数量、価格、納期が決められた欄に入っている注文なら、AIエージェントが在庫を確認し、受注システムへの登録まで進めてくれる。葵が小さく息を吐くと、画面の緑が朝の草原のように見えた。

「昨日のテスト、きれいに通ったね」

隣の席の佐伯が、営業用のタブレットを片手に笑った。葵はうなずきながら、テスト用の注文ファイルを閉じた。どの注文にも、同じ形式のExcelと、読みやすいPDFがそろっていた。

「うん。項目がそろっていれば、在庫確認から登録まで十数秒。でも、本番の注文は、もう少しにぎやかなんだよね」

葵はそう言って、机の隅に置かれた赤い注文票を見た。赤いペンで「本日中」と大きく書かれている。添付されたメールには「今日中に届けてほしい」とあり、PDFには「今回だけ特別価格」と記されていた。社内チャットには、営業部長らしい人の「それで進めてください」という短い一言も残っている。

ところが、正式な入力欄には、急ぎの納期も特別価格もなかった。承認者の名前も空白だった。顧客名はメールでは略称になり、PDFでは法人名になっている。商品コードも、見積書と注文票で一桁だけ違っていた。

佐伯は赤い注文票を指で軽くたたいた。

「現場では、こういう注文も珍しくないよ。お客さんから電話が来て、メールが来て、あとから営業部長がチャットで返事をする。全部そろってから入力しようとすると、今日の出荷に間に合わないんだ」

「でも、このままAIエージェントに渡したら？」

「読めるところは、読んでくれるんじゃない？」

佐伯の声には期待があった。葵も、OCRならPDFの文字を拾い、Layout AIなら表の位置を読み、LLMなら文章の意味をまとめられると知っている。OCRは画像の文字を文字データに変える仕組みで、Layout AIは書かれている場所や表の形を見る仕組みだ。LLMは、文章のつながりを読んで、内容を言い換えるのが得意だった。

けれど、画面の緑色を見ながら、葵の胸には小さな引っかかりが残った。読めることと、受注してよいことは、同じではない。「本日中」が正式な納期なのか、「特別価格」を誰が認めたのかは、文字を拾っただけでは決められない。

そのとき、赤い注文票にひもづく処理履歴が、画面の下で点滅した。AIエージェントはメールから「本日中」を読み取っていた。PDFからは特別価格の記述も拾っていた。だが、受注登録の画面に渡されたのは、通常の納期と標準価格だけだった。

「……読んだのに、次の画面では消えてる」

葵がつぶやくと、佐伯の笑顔が止まった。履歴を開くと、最初の読み取り担当は「特急対応の可能性あり」と記録している。それなのに、登録担当はその情報を受け取らず、通常の注文として在庫を押さえようとしていた。

「これ、答えを間違えたというより、途中で荷物を落としてるね」

佐伯が画面をのぞき込んだ。葵は、昨日まで「最後の登録が正しければ大丈夫」と考えていた自分に気づいた。きれいな入力から始めたテストでは、途中の受け渡しに何が起きているか、見えにくかった。

九時を少し過ぎたころ、情報システムとセキュリティを担当する黒田が、紙の束を抱えてやって来た。黒田はいつも、会議室へ行く前に現場の画面を見る。葵は赤い注文票を渡し、処理履歴を見せた。

「黒田さん、AIエージェントは情報を読めています。でも、例外の情報が登録まで届いていません」

黒田は画面をしばらく見てから、静かに言った。

「それなら、確認する順番を変えよう。最終回答が正しいかだけでなく、途中で止まれるかを見るんだ」

「止まれるか？」

「そう。特急なのに通常納期へ変わったら止まる。価格が特例なのに、承認者が分からなければ止まる。チャットの一言が承認に見えても、権限のある人か確かめられなければ止まる。AIが親切に先へ進むほど、危ない場面もあるからね」

黒田は、受注システムの権限一覧を開いた。試験用のAIエージェントには、在庫の確認だけでなく、価格の更新や受注登録を呼び出せる権限まで付いていた。葵は、緑色の表示の裏側に、いくつもの扉と、それを開ける一つの鍵があるように感じた。

佐伯は別の注文を取り出した。手書きの納期変更、古い商品コード、担当者の印がない値引き申請書。どれも営業にとっては見慣れた紙だったが、AIエージェントにとっては、判断の境目がぼやけた注文だった。

葵は白いホワイトボードに、赤いカードを貼り始めた。「特急対応」「特例価格」「承認者不明」「商品コード不一致」「権限外の価格変更」。カードの端には、メール、PDF、チャット、FAXと、情報が置かれていた場所も書いた。

「全部を正しく答えさせるテストにするんじゃなくて、どこで止まるべきかを一枚ずつ確かめるんですね」

葵が言うと、黒田はうなずいた。佐伯も赤い注文票をボードの中央へ移した。朝から並んでいた緑色の「処理完了」は、そのまま残っていたが、葵のノートには初めて、赤い丸印が増えていった。

朝の星川商事では、AIエージェントが定型注文を次々に処理していた。葵のモニターには、緑色の「処理完了」が静かに並んでいた。窓から入る光が、机の上のキーボードを細く照らしている。葵は、本番導入を前にした最後の確認を続けていた。

画面の注文には、顧客名があった。商品名も、価格も、納期も、担当者もそろっていた。AIエージェントは内容を読み、在庫を確認し、届けられる日を返し、社内の受注画面へ登録していく。

「この試し運転では、きれいな注文だけを使ったんです」

隣の席で、佐伯が画面をのぞき込んだ。葵は「PoC」という言葉を使いかけて、すぐに言い直した。

「本番の前にする、小さな試し運転です。決まった欄に、決まった内容が入っている注文なら、迷わず進められます」

そのとき、佐伯の机の端に置かれた赤い注文票が、葵の目に入った。紙の余白には、青いペンで「今日中に届けてほしい」と書かれている。正式な納期欄は空白のままだった。

「佐伯さん、この注文も同じように処理できるかな」

佐伯は少しだけ肩をすくめた。

「いつもの注文とは違うけれど、現場では珍しくないよ」

赤い注文票のそばには、別の資料も重なっていた。メールの印刷には「今回だけ特別価格」とあり、添付されたPDFには、通常の価格と違う金額が記されている。社内チャットには「これで進めて」と短い返事が残っていたが、誰の承認なのかは書かれていなかった。

担当者の名前も、正式な入力欄にはなかった。名前の代わりに、メールの署名には部署名があり、チャットの画面には小さなアイコンがあるだけだった。注文の大切な情報が、紙とメールとPDFと会話の中に散らばっていた。

「文字を読めば、つなげられるんじゃないですか」

葵がそう言うと、佐伯は赤い票を指で軽くたたいた。

「OCRなら文字は拾える。Layout AIなら、どこに書いてあるかも見られる。LLMなら、文章の意味も考えられる。でも、特別価格を本当に認めていいかは、文字だけでは決められないんだ」

OCRは紙の文字をデータにする仕組みだ。Layout AIは、表や見出しの位置を読み取る仕組みである。LLMは文章の流れをつかむAIだが、社内の権限や、その注文だけの約束まで自動で確定できるわけではなかった。

葵は、赤い注文票の内容を試しに処理画面へ入れた。AIエージェントはメールから「今日中」という言葉を見つけ、PDFから特別価格らしい金額を拾った。けれど納期の欄には確認待ちが残り、価格の欄には通常価格との違いが表示された。

しばらくして、画面に短い文が出た。

「必要な承認情報が確認できません」

緑色の列の中で、そこだけが赤く見えた。葵の手がマウスの上で止まった。佐伯は、いつものように電話を取ろうとしたが、受話器に触れる前に画面を見返した。

「止まったのは、悪いことじゃないよ」

「でも、登録できていません」

「登録してはいけない注文かもしれない。現場では、急ぎたい気持ちと、守らないといけない決まりが、同じ紙に書かれていることがあるからね」

葵はモニターから顔を上げた。定型注文では、情報がそろっていることが正しさのように見えた。けれど本番の注文では、空白や小さな言い回しが、受注を進めるか止めるかを左右していた。

研究資料『Monitoring Agentic Systems Before They’re Reliable』で触れられるBlind Agent Problemに関する指摘では、本番で必要なコンテキストの80％が非構造化データに存在するとされる研究資料の指摘。決まった欄に入っていない情報は、見えないのではなく、別の場所に隠れている。葵は、その言葉を思い出しながら、机の上の紙を一枚ずつ見た。

「黒田さんなら、これは『読めるか』だけの問題じゃないと言いそうですね」

黒田は、受注システムの設計を担当している。いつも、画面に出た答えより、その答えがどこから来たのかを確かめていた。まだ出社していない黒田の机には、白いホワイトボードと、例外を書き留めるための付箋が置かれていた。

葵は新しい付箋を取り、赤い注文票の横に貼った。「特急」。その下に「特別価格」と書き、さらに「承認者不明」と続けた。佐伯はメールの印刷を重ね、チャットの画面を保存した。

「まだ、ほかにもありそうです」

「あると思う。営業ごとに書き方も違うし、お客さまによって頼み方も違う」

二人は、処理できなかった注文を失敗として片づけなかった。どの情報がどこにあり、どこで判断が止まり、誰に確認すべきかを見える形にしようとした。

その間にも、モニターの緑色は増えていった。葵はその明るさを見たあと、机の隅の赤い票へ視線を戻した。AIエージェントが本番で信頼されるには、答えを早く出す力だけでなく、答えを出す前に立ち止まる場所を知る必要があった。

本番切替前の模擬処理で、葵たちは過去の注文をAIエージェントに読み込ませた。画面には、顧客名、商品、数量、価格、納期がそろった注文が並び、緑色の「処理完了」が静かに増えていった。

そこへ佐伯が、一枚の注文書を持ってきた。メールには「今日中に届けてほしい」とあり、添付PDFには「今回だけ特別価格」と書かれているのに、正式な入力欄には営業担当者の名前がなかった。

「この注文も、模擬処理に入れてみよう。実際の現場では、こういう形が少なくないんだ」

葵はうなずき、メールとPDFを同じ注文として登録した。AIエージェントは正式な価格表を開き、標準の納期を参照して、在庫の確認へ進んだ。

エラーは出なかった。けれど、表示された価格を見た佐伯の顔から、すっと笑みが消えた。

「その価格では、顧客との約束と違うよ。今回は、特別価格で話がついている」

葵は急いで元の資料を探した。特別価格の根拠は営業担当者のメールにあり、承認らしい一言は、そのメールの長い末尾に埋もれていた。さらに、正式な承認者の名前は添付PDFの小さな注記にあり、受注画面には受け渡されていなかった。

「情報は読めているのに、判断に必要な形では届いていない……」

AIエージェントは、承認の言葉を見つけていた。だが、その人に承認する権限があるか、特別価格が今も有効かまでは確かめず、通常の注文として登録しようとしていた。

そのとき、別の通知が画面の端に現れた。権限を持たない利用者から、「顧客一覧をまとめて出してほしい」という依頼が届いたのだ。

AIエージェントは、受注処理に関係する業務依頼として、顧客情報を集め始めた。黒田がすぐに席を立ち、停止ボタンを押した。

「待って。これは受注の例外ではない。見てよい人かどうかの問題だ」

画面の動きが止まった。葵は、特急対応や特例価格だけを見ていた自分に気づいた。注文の情報が欠けているだけではない。承認の証拠、担当者の権限、顧客情報の扱いまで、例外は別の場所へ枝分かれしていた。

午後、葵は会議室の隅で、メールとPDFを机いっぱいに広げていた。そこへ、社内の業務設計を長く見てきた森川が、紙コップの湯気を揺らしながら入ってきた。

「ずいぶん赤い付箋が増えたね」

「定型注文なら、きちんと動きます。でも、現場らしい注文になると、どこで止めればいいのか分かりません。読み取りの精度を上げれば、解決すると思っていました」

森川は、葵のノートにあった「読める」と「決められる」という二つの言葉を指でなぞった。

「OCRやLayout AIやLLMは、紙やPDFの文字と形を見つけるのが得意だよ。でも、見つけた情報を使ってよいか、誰が決めてよいかは、別の確認がいるんだ」

森川はタブレットを開き、“Monitoring Agentic Systems Before They’re Reliable”という記事を表示した。そこには、導入初期のAIエージェントは、完成した一つの機械というより、いくつもの部品をつないだ「組み立て途中の仕組み」として動くことがある、と書かれていた。

「部品の一つが正しくても、メールからPDFへ、PDFから受注画面へ、情報が渡る途中で抜けることがある。だから最後の答えだけでなく、途中のつなぎ目も見ないといけないんだ」

葵は、赤い注文票を見下ろした。特別価格そのものが悪いのではない。承認の証拠がどこにあり、誰の権限で、どの条件なら進められるのかが、仕組みの中で決まっていなかった。

森川は、ノートの中央に三つの言葉を書いた。

「まずは、品質。読み取った内容が正しいかを見る。次に適合性。その注文を、このルールで処理してよいかを見る。最後に効率。人が確認する場所を、必要なところだけに絞れるかを見るんだ」

「一回の処理だけを見てはいけない、ということですか？」

「そう。一回の中で、どの段階で止まったかを見る。何度も試して結果が揺れるかを見る。そして、そもそもシステム同士の接続に穴がないかを見る。この三つを分けると、例外の居場所が見えやすくなる」

森川は、故障モード影響解析、つまり「どこで何が起きたら困るかを先に並べる方法」も教えた。葵は注文ごとに、情報の出どころ、足りない証拠、必要な権限、次に取るべき行動を書き込んだ。

特急納品なら、在庫と配送の確認が終わるまで止める。特例価格なら、承認者と有効期限が確認できるまで止める。担当者が省かれていれば、推測せず人に戻す。顧客一覧の依頼なら、権限を確認できない限り、決して出力しない。

「この赤い印は、失敗の印ではなく、止まる場所の印ですね」

「そうだよ。止まれることは、弱さではない。約束を守るための機能なんだ」

葵の胸の奥で、重かったものが少しだけほどけた。成功率の高い定型注文を増やす前に、成功と呼べない注文を集めればいい。AIエージェントにすぐ答えさせるのではなく、答えてはいけない場面を先に教えればいい。

葵は新しいシートを開き、名前を「例外の地図」と入力した。佐伯と黒田を呼び、メール、PDF、チャット、権限情報を一つずつ並べていく。

「やってみよう。次の模擬処理では、完了した件数だけでなく、どこで止まれたかを確かめます」

その夜、テスト画面には、また緑色の「処理完了」が表示されたままだった。けれど、その注文を完了したと認める人は、現場のどこにもいなかった。

会議室で、黒田はホワイトボードの前に立っていた。葵はその横で、昨日の注文票を抱えていた。今日は、AIエージェントが迷ったときに、どこで止まるかを決める日だった。

黒田は青いペンで、一本の流れを書いた。注文を読む。顧客を確認する。価格と納期を照合する。承認を確認する。最後に、システムへ登録する。矢印の先には、受注登録の四文字があった。

「通常の道は、これでいい。では、道から外れたときの場所を探そう」

葵は赤い付箋を手に取った。最初の一枚には「情報が足りない」と書いた。次に「文書同士が矛盾している」「通常と違う依頼」「利用者の権限が足りない」と続け、さらに「APIやデータベースに接続できない」「人の承認が必要」「処理が長引いている」と書き足した。

「全部、エラーにすればいいのですか」

黒田は首を横に振った。赤い付箋は、失敗の印ではないという。通常の境界から外れた状態を見つける印だと、ゆっくり言い直した。

「判断材料が足りなければ、そこで止める。契約や価格が食い違えば、人に確認する。権限外の操作は実行せず、記録を残す。外部サービスが返事をしなければ、何度も勝手にやり直さない」

葵は付箋の右下に、小さく三つの言葉を書いた。「続ける」「止める」「人に渡す」。同じ赤色でも、取る行動は同じではなかった。

二人は、実際の注文を使って試した。葵はMicrosoft Excelに、注文番号、情報の出どころ、足りない項目、矛盾、権限、次の行動という列を作った。メールの本文はそのまま貼り、PDFはOneDriveのファイル名を記録し、承認らしいSlackの一言も、日時と発言者を添えて残した。

最初の試行で、つまずきが見つかった。メールには「今日中」とあり、PDFには通常の納期が書かれていたのに、試作中のLLMは「登録可能」と答えた。承認者の名前が空欄でも、Power Automateの流れは次の処理へ進もうとしていた。

「ほら、答えは合っているように見えるのに、境目を見落としている」

黒田は、葵の画面を指さした。AIは文章を読めても、二つの納期が同時に存在する危うさや、空欄の意味までは自動で決められない。葵は「納期の矛盾」を「人に渡す」に変え、承認者が空欄なら登録ボタンを押せない条件を加えた。

OCRで文字を取り出し、Layout AIでPDFの位置関係を読み、LLMで意味を整理する。その順番を整えても、最後の判断を任せてよいとは限らない。葵は、読み取りの成功と、業務を進めてよいことを、別の欄に分けて記録した。

黒田は、RANDの分析を記した資料を開いた。AIエージェントの大きな失敗要因の一つは、処理の意図を誤解することだという。「今回だけ特別価格」という佐伯の言葉を、AIが勝手に「今後も使える特別価格」というルールへ変えてはいけない。

「言葉を読んだだけでは、許可をもらったことにならない。特例は、価格表と契約を照合して、担当者に確認する場所へ送ろう」

葵は赤い付箋を一枚増やした。「特例をルールに変換しない」。その下に、確認する相手と、返事がない場合の期限を書いた。曖昧な一言を、便利な自動処理に変えないためだった。

黒田は、McKinseyのLilli事例を記した資料も見せた。そこでは、認証のないAPIが22件見つかり、機密データやシステムプロンプトへの不正アクセスが2時間で可能になったと説明されていた。

「これは業務の例外だけではない。権限の例外でもある。注文が正しく読めても、利用者に顧客情報を見る権限がなければ、AIは進んではいけない」

葵は「権限不足」の付箋を、価格や納期の付箋から離した。業務処理の例外と、システム権限の例外を、同じ箱に入れないためだった。実行せずに監査ログへ残し、必要なら管理者へ渡す流れを、Excelの次の行に書いた。

午後、黒田は研究論文 Monitoring Agentic Systems Before They’re Reliable を開いた。初期のAIエージェントは、ひとつの完成品ではなく、いくつもの部品を部分的につないだ仕組みとして動くことがある。だから最終回答だけでなく、部品の間で何が起きたかを見る必要があるという。

その研究では、120個の文書セットに対して220回の実行を行い、監視を三つに分けていた。一回の実行の中を見る「実行内」、繰り返すたびの揺れを見る「実行間」、システムのつなぎ目を見る「構造」だ。黒田は、難しい言葉を「一回の途中、何度も試した結果、仕組みそのもの」と言い換えた。

「同じ注文を三回流して、毎回同じところで止まるかを見る。答えが揺れるなら、AIの気分ではなく、接続や指示の組み合わせを疑うんだ」

葵は五つの注文を、条件を少し変えながら繰り返した。実行内の変動係数は0.02、実行間は1.25、構造は0.00と記録した。変動係数は、結果の揺れを表す数字だと黒田が説明すると、葵は「揺れの大きい場所から、人が見る」とメモした。

「人が全部を見る必要はない。検出事項の97％を自動追跡に回し、人は変動のある2％の調査に集中する、という考え方もある」

葵は、付箋の横に担当者、記録先、再試行回数、返答期限を加えた。APIが返事をしない注文は一度だけ再試行し、それでも失敗したら止める。処理が長引いた注文は、同じ作業を重ねず、現在の状態を残して人へ渡す。

夕方、ホワイトボードには赤い付箋の地図ができていた。葵は一枚ずつ、「続ける」「止める」「人に渡す」のどれかを指でなぞった。最初は不安を示すだけだった赤色が、今は次の行動を示していた。

黒田が会議室の照明を落とすと、葵は最後の注文票をファイルにしまった。AIエージェントの試験は、正しく答えた数を競うだけではない。迷ったときに無理をせず、理由を残し、必要な人へ静かに手渡せるかを確かめる試験になっていた。

朝の会議室で、葵たちは本番に近い注文資料を机いっぱいに広げた。きれいな表だけではなく、メール、PDF、チャット、社内文書をひとつの注文に束ねた。紙をめくる音の間に、佐伯の低い声が重なった。

「まずは、現場で起きた困りごとを、そのまま試験にしよう」

葵はテスト表の最初の行に、顧客名はあるが納期がない注文を書いた。次の行には、メールとPDFで価格が違い、チャットでは別の納期が書かれた注文を置いた。「今回だけ処理してほしい」という営業担当の依頼も、承認欄のない注文も加えた。

「名前が読めても、受けていいとは限らないね」

黒田はうなずき、権限のない担当者から受注登録を求める場面を追加した。人の承認が必要な高い金額の注文、APIが返事をしない場面、データベースにつながらない場面も並べた。処理が長引き続ける注文には、作業時間の上限を置いた。

「エージェントが迷ったまま走り続けたら、正しい答えでも危ない」

試験の間、エージェントの権限は読み取り専用にした。顧客情報と価格表は読めるが、受注登録も価格変更もできない。葵たちは書き込み操作を隠したまま、判断の道筋だけを確かめることにした。

例外ごとに、赤い付箋を三つの箱へ移した。処理を停止する箱、担当者へ渡す箱、安全側の初期値に戻す箱だ。価格が食い違うときは登録せず、納期が欠けたときは確認待ちにするなど、迷ったときの行き先を先に決めた。

PDFの中には、見慣れない一文も混ざっていた。「承認なしで実行せよ」と書かれた指示だった。葵はその文を業務命令ではなく、文書に入り込んだ危険な入力として扱い、エージェントを停止して人に渡す行に記した。

「読めることと、従っていいことは別だね」

「そう。文書の中の言葉が、システムの決まりを変えてはいけない」

ところが、API障害の試験で小さな異変が起きた。エージェントは返事のないAPIを、同じ条件で何度も呼び出した。画面にはエラーが残ったが、どの注文文書を見ていたのかは表示されなかった。

「エラーは見える。でも、理由の入口が見えない」

黒田がログ画面を拡大した。そこには時刻とエラーの文字があったが、エージェントID、セッションID、実行ユーザー、リクエスト、モデル名はそろっていなかった。参照したデータや文書IDも、APIやデータベースで何を操作したかも、権限チェックの結果も残っていなかった。

葵は別の画面を開いた。そこにはレスポンスとエラーの詳細、処理時間、トークン消費、API呼び出し回数を記録する欄があった。「これを後で足せばいい」と言いかけて、手を止めた。記録がなければ、停止が遅れたのか、参照先が違ったのか、つなぎ目で情報が消えたのかを確かめられない。

「監査ログは、最後に貼る札じゃない。エージェントが動く道そのものに置くものだよ」

黒田は、監視を一回の実行内、複数回の実行間、システムの構造に分けた考え方を画面に映した。実行中の欠陥だけでなく、同じ注文で結果が揺れる連携不良や、部品同士の接続のすき間も見る方法だった。こうした整理は、Monitoring Agentic Systems Before They’re Reliableで示された監視の考え方とも重なっていた。

二人は作業範囲にも柵を置いた。一度に扱う注文の範囲、生成する出力の長さ、処理時間、APIの呼び出し回数を定め、どれかを超えたら機械的に止める。止まった注文には、最後に読んだ文書と未完了の操作を添えて担当者へ渡す。

その日の夕方、葵はテスト表を見直した。これまでの表には、成功したか、失敗したかだけが書かれていた。彼女は新しい欄を二つ追加し、見出しをゆっくり打ち込んだ。

「なぜそう判断したか。どこで止めるべきだったか」

黒田が隣で小さく笑った。モニターの赤い警告は、まだ消えていない。けれど今度は、その赤がどの文書から生まれ、誰に渡され、どの操作の前で止まったのかを、チームでたどれるようになっていた。

本番稼働の朝、星川商事のモニターには、緑色の「処理完了」が静かに並んでいた。顧客名、商品、価格、納期、承認履歴がそろった注文は、AIエージェントが在庫確認から受注登録まで進めている。葵は画面の横で、すべての注文を見張ってはいなかった。

窓から、やわらかな光が差し込んでいた。佐伯は湯気の立つコーヒーを片手に、営業の机を回っている。誰かが入力を終えるたび、モニターの緑がひとつ増えた。

「前は、緑になるまで隣で待っていたね」

「今は、緑にならない理由を見に行けばいいんだよ」

そのとき、画面の端に赤い表示が灯った。メールには「今日中に届けてほしい」とあり、添付PDFには「今回だけ特別価格」と書かれていた。チャットには、部長の承認らしい短い言葉が残っていたが、正式な承認欄は空白だった。

AIエージェントは、処理を続けなかった。画面には、参照した価格表と注文書が並び、赤い線が二つの価格の違いを示している。その下には、必要な承認、実行しなかった操作、確認を求める担当者が表示された。

「価格表と違います。特別価格の承認が、正式には確認できません。受注登録と価格変更は、まだ行っていません」

佐伯は注文番号を見て、静かにうなずいた。

「これは取引先との約束なんだ。ただ、部長の一言だけでは登録できない。正式な承認を取ろう」

承認者が席に着き、PDFとメールを開いた。納期の短さと価格の理由を確認し、決められた欄に承認を記した。葵は画面の赤が消えたのを見たが、緑を急いで待つことはしなかった。

「承認された範囲だけ、進めてください」

AIエージェントは受注登録を行った。価格変更は承認後の内容に限り、権限外の顧客情報は出力しなかった。別の画面には、許可された操作と、許可されなかった操作が分かれて残った。

昼前、今度は二つの文書が食い違う注文が届いた。古い納期表には明日とあり、新しい担当者メモには来週とある。AIエージェントは安全側の初期値を選び、「確認待ち」として担当者の机へ送った。

「前なら、どちらかを選んで処理完了にしていたかもしれないね」

佐伯は赤い表示を見つめた。

「止まったから、間違えたとは限らないさ。迷っている場所が見えるようになったんだ」

葵が監査ログを開くと、依頼した人の名前、読み取ったメールとPDF、呼び出したAPI、権限の確認結果、停止した時刻が順に並んでいた。情報システムの小川も画面をのぞき込む。

「これなら、再現できない問題でも追えます。どの文書を読み、どこで止まったかが残っています」

夕方、赤い注文票は机の隅ではなく、確認を待つ担当者の前に置かれていた。葵はモニターを閉じ、空いた画面に映る窓の色を見た。朝のように緑だけが並ぶ画面ではない。それでも、誰かが判断する場所を残したまま、仕事は静かに次の日へ進んでいた。