町工場が生成AIと業務データ連携でOEE85％を目指す物語

午後六時を知らせるチャイムが、青空メンテナンスのオフィスに小さく響いた。窓の外では、点検車のエンジン音が遠ざかっていく。営業企画の紬は、三つの画面を見比べながら、マウスを忙しく動かしていた。

左の画面には、営業担当が入力したCRMの商談メモがある。中央には、別画面で開いた生成AIがある。右の画面には、顧客との履歴や案件の状態を管理するCRMの登録画面が待っていた。

「大橋さん、今日の東浜工業さまの商談メモ、こちらで要約しますね」

「助かるよ。現場から戻ったばかりで、まだ整理できていなくて」

紬は、メモの文章を指でなぞった。そこには、「冷却設備の停止が増えている」「保守契約の見直しを検討」「来週、現場責任者を交えて再度説明」と書かれている。言葉は短く、書いた人によって順番も表現も違っていた。

紬は文章をコピーし、生成AIの入力欄へ貼り付けた。そして、「商談要約、次回アクション、顧客の関心事項を整理してください」と入力した。しばらくすると、画面に整った文章が並んだ。

「商談要約は、冷却設備の停止増加を背景に、保守契約の見直しを検討中。次回アクションは、来週、現場責任者へ点検事例を説明。顧客の関心事項は、停止時間の短縮と保守費用の妥当性……」

「うん。文章としては、すごく読みやすいね」

大橋が紬の背後から画面をのぞき込んだ。紬も小さくうなずいたが、そのままでは仕事が終わらないことを知っていた。

CRMには、「案件概要」「次回対応日」「受注確度」「顧客の課題」といった入力欄が並んでいる。生成AIの回答は一つの文章になっているため、紬は内容を読み取り、どの部分をどの欄へ入れるかを自分で決めなければならなかった。

まず、要約の一部をコピーして「案件概要」へ貼り付けた。次に、「停止時間の短縮」を探して「顧客の課題」へ移した。けれど、「来週」という言葉は、CRMが求める日付の形になっていない。

「次回対応日は、来週の何曜日にしよう……。大橋さん、先方との約束は決まっていますか？」

「まだだよ。現場責任者の予定を確認してから。受注確度も、今は『検討中』くらいかな」

紬はCRMの選択欄を開いた。「低い」「中」「高い」と並ぶ選択肢の前で、手が止まった。AIは「保守契約の見直しを検討中」と書いていたが、それが社内の受注確度でどれに当たるのかは、文章を読んだ人の判断に残されていた。

そのとき、別の営業担当から声が飛んできた。

「紬さん、昨日の西川製作所の分もお願いできますか。メールと電話の内容が混ざっていて、登録する時間がなくて」

「はい。今の分が終わったら見ますね」

紬は返事をしながら、画面を切り替えた。別の商談メモには、顧客名の略称と担当者名が違う表記で書かれている。生成AIへ送る前に、個人情報や社内だけの情報をどこまで含めてよいかも、毎回確認しなければならなかった。

大橋が、申し訳なさそうに笑った。

「AIに聞くところまでは早いのに、戻すところで時間がかかるね」

その言葉に、紬は手を止めた。生成AIは、散らかったメモを読みやすい文章に変えてくれる。けれど、その文章をCRMへ戻す道は、画面の間に細い紙の橋をかけるような作業だった。

「たぶん、便利な別窓として使っているからですよね。AIにまとめてもらって、私が読んで、また手で入力している」

「じゃあ、どうなればいいんだろう」

紬はCRMの空欄を見つめた。生成AIがCRMの中で呼び出され、商談メモをもとに「案件概要」や「顧客の関心事項」の更新案を作る。次回対応日は候補として示し、受注確度は理由と一緒に確認できる。

「まず、AIが出すものを、文章だけにしないことかもしれません。CRMが読める形で、項目ごとに返してもらうんです」

大橋が首をかしげた。

「項目ごとに？」

「はい。たとえばJSON Schemaです。難しそうに聞こえるけれど、入力欄の設計図みたいなものです。案件概要は文字、次回対応日は日付、受注確度は決められた選択肢、と先に決めておくんです」

紬は、白いメモ用紙に小さな箱を描いた。箱の中に「案件概要」「次回対応日」「受注確度」「顧客の関心事項」と書く。その横に、「確認済みか」という欄も加えた。

「それなら、AIが考えることと、CRMへ登録することを分けられますね」

「そう。AIが直接書き換えるのではなく、まず更新案を出す。私たちが確認してから登録する。システム同士をつなぐiPaaSが、その間を運ぶ通り道になれば、コピーと貼り付けを減らせそうです」

大橋は、さっきまで空欄だったCRMの画面を見た。紬はそこに、ただ文章を貼るのではない新しい流れを思い描いた。生成AIの出力を業務データへ戻すとは、きれいな文章を移すことではなく、業務システムが扱える形にして、人の確認を通って登録することなのだ。

オフィスの照明が一列ずつ消え始めた。紬は最後の商談メモを保存し、白いメモ用紙をCRM画面の横に置いた。

「明日、まずはこの一件で試してみましょう。戻す道を、手で作り直さなくていい形にできるかもしれません」

翌朝、営業企画の窓に淡い光が差し込んでいました。紬がパソコンを開くと、前日に顧客を訪問した営業担当の佐伯が、折りたたんだメモを持ってやってきました。紙には、面談の話と顧客の希望が急いだ文字で並んでいました。

「紬さん、昨日の青葉精機さんです。更新には前向きでした。次に何をすればいいか、まとめてもらえますか」

「はい。すぐに整理しますね」

紬はメモを読み、会社名や担当者名を確認しました。それから、会社で使っている生成AIの画面を開き、面談内容を貼り付けました。「顧客の意向を要約し、次の対応案も作ってください」と入力します。

しばらくすると、画面に落ち着いた文章が現れました。「顧客は契約更新に前向き。次回は担当者へ製品資料を送付し、導入時期を確認する」と書かれています。文章としては自然でした。紬は、これならすぐCRMに記録できると思いました。

けれど、CRMの入力画面には、別の形が並んでいました。顧客ID、案件ID、対応種別、次回アクションです。文章をそのまま貼る場所は、メモ欄しかありませんでした。

「顧客IDは……検索して、案件IDも別に入れて。対応種別は、更新提案かな」

紬は顧客名を検索し、表示された番号を画面から写しました。次に案件を探し、対応種別を選びます。その横で、AIの文章をメモ欄へ貼り付けました。きれいな文章が入ると、画面全体が整ったように見えました。

電話が鳴りました。佐伯が別の顧客について尋ねてきたため、紬はそちらの画面へ移りました。AIの文章に「資料を送る」と書かれていたので、次回アクションも記録したつもりになっていました。実際には、次回アクションの登録欄は空白のままでした。

昼前、営業会議のために案件一覧を開くと、青葉精機の状態は「提案中」のままでした。更新に前向きという新しい話は、一覧には表れていません。資料送付の仕事も、担当者の作業一覧には出ていませんでした。

「えっ……登録されていない」

紬の指が止まりました。急いで案件を開き、空白になっていた次回アクションを埋めようとします。AIの文章から「次回は担当者へ製品資料を送付し、導入時期を確認する」をコピーし、日付の欄へ貼り付けました。

赤い表示が出ました。日付欄は、決められた日付の形だけを受け取る項目です。「資料を送付し、導入時期を確認する」という文章は、日付ではありません。CRMは登録を受け付けず、紬の画面には未保存の文字だけが残りました。

「文章は合っているのに、入れる場所が違う……」

そのとき、大橋が後ろから画面をのぞきました。紬は、AIが間違えたのだと思いながら、起きたことを話しました。大橋は画面の空白と、メモ欄に貼られた文章を交互に見ました。

「AIの返事が間違ったというより、返事を受け取る箱がなかったんだ」

紬は顔を上げました。大橋は、顧客IDや案件IDを入れる箱、対応種別を選ぶ箱、次回アクションの日付を入れる箱が必要だと話しました。文章を返してもらうだけでは、CRMの項目へ自然には分かれないのです。

さらに、紬は別の不安も口にしました。顧客名や担当者名を含むメモを、外部の画面へ手で貼り付けたからです。どの情報をどこへ送ったのか、あとから確認しようとしても、コピーした範囲と送信先が記録に残っていませんでした。

「便利だから貼った。でも、確認する人も、確認する場所も決めていなかったんですね」

大橋は小さくうなずきました。AIの答えをそのままCRMへ流すのではなく、いったん確認できる形で受け取る必要があります。顧客IDや案件IDが本当に合っているか、対応種別が社内のルールに合うか、次回の日付が正しいかを、人が見るための場所です。

紬はホワイトボードに、四つの項目を書きました。顧客ID、案件ID、対応種別、次回アクションです。その下に「確認済み」と書き、承認されるまではCRMを更新しない線を引きました。

「AIには、自由な文章ではなく、この項目の形で返してもらいましょう。項目と型を決める設計図は、JSON Schemaと呼べるそうです」

「箱の大きさと、入るものを先に決めるんだね。日付の箱に文章を入れないようにする」

午後、紬は生成AIの指示文を作り直しました。AIが考えた更新案は、まず確認用の中間データへ入り、形式と内容を検査します。問題がなければ紬が承認し、連携基盤、いわゆるiPaaSがCRMへ反映する流れです。

その日の夕方、青葉精機の案件には、正しい次回アクションが表示されました。案件一覧の古い状態も変わり、佐伯の作業一覧には資料送付の仕事が届きました。紬は、きれいな文章を眺めるだけでなく、次に誰が何をするのかまで見える画面を、静かに確かめました。

紬は、CRMの画面から生成AIを呼び出し、その結果を同じ画面で確認したいと蓮に相談した。蓮は情報システム室の白いホワイトボードの前に立ち、青いペンのふたを外した。

「蓮さん、AIに商談を要約してもらうところまではできました。でも、結果をCRMへ戻すときに、項目を手で写しています。画面の中で確認して、そのまま登録できませんか」

「できます。ただ、先に決めることがあります。AIに、どんな返事を返してほしいかです」

蓮は、ホワイトボードの左端にCRM画面と書いた。そこから矢印を伸ばし、API、生成AI、構造化データ、検証、人の確認、業務データ登録と順に書いていく。APIは、システム同士が話すための通り道だと、蓮は短く説明した。

「この順番で、CRM画面 → API → 生成AI → 構造化データ → 検証 → 人の確認 → 業務データ登録。AIの文章を、そのまま戻すのではありません。戻せる形にして、確かめてから戻します」

紬は、白い線の上を目で追った。これまでの画面では、AIの返事がきれいな文章になっているかを見ていた。しかし、CRMが必要としているのは、文章の美しさだけではない。

「では、AIには何を返してもらうんですか」

蓮は、ホワイトボードに小さな箱を描いた。その箱の名前を、JSON Schemaと書いた。

「JSON Schemaは、AIの返事を入れる箱の形です。箱の中に何を入れるか、文字なのか日付なのか、必ず必要なものは何か、選べる値は何かを先に決めます」

「返事の内容を、入れ物から決めるんですね」

「そうです。例えば、商談要約、顧客の課題、次回アクション、対応期限、受注確度、要確認フラグです。対応期限は日付の形にします。受注確度は、決めた範囲の値だけにします。要確認フラグは、確認が必要かどうかを示します」

蓮は六つの項目を箱の中に並べた。紬は、空欄のまま戻ってくる項目が減る気がして、少し背筋を伸ばした。

「箱ができたら、次は五つの段階です。一つ目はSchema定義。返却項目、データの型、必須項目、許可する値を決めます」

蓮は項目の横に、小さなチェック印を描いた。

「二つ目は生成です。CRMからAPIを通して情報を送り、生成AIに構造化された形で返してもらいます。GoogleのGemini APIやAzure OpenAIのようなサービスでも、決めた形に合わせて返す方法があります」

「文章ではなく、項目の集まりとして返してもらうんですね」

「その通りです。三つ目は再検証。返ってきたデータがJSON Schemaに沿っているかを見ます。項目の抜け、型の違い、日付の崩れがないかを確認します」

蓮は、箱の外側に赤い線を引いた。紬が首をかしげると、蓮はペンを置いて振り返った。

「ただし、JSONとして正しくても、内容が業務上正しいとは限りません。例えば顧客IDが実際には存在しない。対応期限が過去の日付になっている。担当者の権限では登録できない。そんなことがあります」

「形が合っていることと、仕事で使えることは別なんですね」

「はい。だから四つ目に業務ルール検証を置きます。顧客IDの存在、対応期限の妥当性、権限、登録条件を、業務システム側で確かめます」

最後に、蓮は円を二つ描いた。一つは生成AIへ戻る矢印で、もう一つは紬へ向かう矢印だった。

「五つ目はリトライです。形式の不備や一時的なAPIエラーなら、原因を添えてもう一度実行します。それでも直らなければ、無理に登録しません。人の確認へ戻します」

紬は、赤い矢印の先に自分の名前があるのを見た。AIに任せる場所と、自分が見る場所が、はっきり分かれていた。

「AIは提案や下書きを作る役目です。最終登録の前には、紬さんが内容を確認して承認します。誰が見て、何を直し、いつ登録したかもログに残します」

そのとき、蓮はCRMと生成AIの間に、もう一つの箱を描いた。箱にはAI Gatewayと書かれていた。

「AIの提供元を、CRMに直接埋め込まない方法もあります。共通の窓口を一つ置くんです。将来、複数のモデルを使い分けたり、サービスを乗り換えたりしても、CRM側の項目設計を変えにくくなります」

紬は、最初に見た白紙の画面を思い出した。AIの返事を受け取るたびに、手で写していた時間。その時間をなくすには、AIを賢くするだけでは足りなかった。

「AIを業務に戻すには、AIを賢くするだけでなく、戻る道を先に作るんですね」

蓮はうなずき、ホワイトボードの最後に小さく「確認してから登録」と書いた。紬はCRMの画面を開き、六つの項目を並べた。空欄の箱は、もう不安な空白には見えなかった。次に何を確かめればよいかを、静かに教えてくれる設計図になっていた。

最初の試運転で、青空メンテナンスの画面に赤いエラーが点滅した。蓮たちは、生成AIを全社へ広げる前に、商談メモの要約とCRM登録だけに絞った小さなPoCを始めていた。

会議室のモニターには、Salesforceの商談画面が映っていた。営業担当の紬がメモを開くと、画面の右上に「AIで要約する」というボタンがある。押すと画面を切り替えず、商談の要約、顧客名、顧客ID、受注確度、要確認フラグが下書きとして表示される仕組みだった。

「まずは、営業さんが三分で確認できるところまでにします。登録は、承認のあとです」

蓮は、ボタンからAI Gatewayへ送る流れを指でなぞった。Gatewayは商談メモと案件IDを受け取り、Azure OpenAIへ依頼する。返ってきたJSONは、JSON Schemaで形を検査し、そのあとPower Automateが業務ルールを確認して、Salesforceへ戻す設計だった。

「JSONで返ってくれば、そのまま登録できるんですよね」

紬が尋ねると、蓮は首を横に振った。

「形が正しくても、中身が仕事に使えるとは限りません。だから、二つの検査を分けます」

一件目のメモを送ると、数秒後に下書きが現れた。文章は自然だったが、「要確認フラグ」が空欄のままだった。画面の左には赤い「Schemaエラー」と表示され、必須項目がないため登録できないと書かれている。

蓮は、JSON Schemaの必須項目に要確認フラグを加えた。エラーの内容を次の依頼にも添え、形式エラーだけは自動で一度だけ再生成する。再生成されたJSONには、要確認フラグがfalseとして入った。

「赤いエラーが出ても、すぐ失敗扱いにしないんですね」

「はい。形の問題なら、AIに直す機会を渡します。ただし、意味の問題は人に返します」

二件目では、受注確度に「かなり高い」と入っていた。文章としてはわかりやすいが、Salesforceで許可されている値は「高」「中」「低」だけだった。画面には黄色の「業務ルール確認」と出て、蓮は選択肢にない値を自動登録しないよう止めた。

三件目では、顧客名は正しかった。ところが顧客IDは、似た名前を持つ別の候補と一致していた。紬の名前の横に、確認待ちを示す小さな印が灯る。

「顧客名が合っていても、IDが違えば登録しません。担当者が候補を見て、正しいIDを選ぶまで待ちます」

そのとき、Azure OpenAIからの応答が遅れた。紬がもう一度ボタンを押すと、同じ商談に二つの依頼が飛んだ。片方が先に戻り、もう片方も処理中のまま残った。

蓮はボタンを一時的に無効にし、案件IDと依頼IDを組み合わせた重複防止用のキーを追加した。すでに同じキーの依頼があれば、新しい送信を受け付けず、画面には「処理中」と表示する。時間切れになった場合は、決めた回数だけ待って再試行し、それでも戻らなければ失敗として確認待ちに送る。

「急いでいる人ほど、何度も押しますからね」

真琴がそう言うと、紬は小さく笑った。

「押したのに動かないと、不安になります。でも、二重登録よりは安心です」

最後のメモには、自然な営業文が入っていた。「必ず値下げできます」という一文だった。社内規程では、承認前に価格を約束してはいけない。形式検査を通ったJSONでも、規程に反する表現は登録できないため、画面は黄色のまま止まった。

蓮は、社内規程と営業文の禁止表現を確認する検査を業務ルール側に置いた。要約案は残すが、登録処理は一時停止する。紬が「価格は社内確認後に提案します」と修正し、承認ボタンを押したときだけ、Power AutomateがSalesforceへ反映する。

「AIに直接CRMを触らせないのは、こういう時のためなんですね」

真琴が言うと、蓮は画面を三つに分けて見せた。生成された要約や項目は出力データに置き、処理中や確認待ちは状態データに置く。誰が何を承認し、どこで止まり、なぜ失敗したかは、監査証跡として別に保存する。

中間結果、会話履歴、失敗理由、確認者の名前は、外部の永続ストレージであるAzure Blob Storageにも保存した。判断ログには、「何を登録しようとしたか」「どこで失敗したか」「次回にどう防ぐか」を残す。三種類の情報を同じ場所に混ぜないことで、後から見た人にも流れが追いやすくなる。

「保存するだけでなく、戻れる道も残すんですね」

「はい。登録前なら止められます。あとから原因を探すこともできます」

夕方、紬は一件の下書きを確認し、顧客IDを正しい候補へ直した。受注確度を許可された値に変え、規程に触れる文を削ると、画面の黄色い印が消えた。承認を押すと、Salesforceの商談欄に要約が入り、横には確認者と処理履歴が残った。

すべてが緑になったわけではない。まだ、顧客IDの不一致や権限不足は自動登録せず、紬の確認箱へ送られる。赤いエラーも一つ残っていたが、そこには原因と次の対応が書かれていた。

PoCの次は、対象チームを増やすPilotへ進む。採用率、修正量、エラー率、処理時間、差し戻しの傾向を見ながら、どこまで任せられるかを確かめる。さらにScaleへ進むときも、AI Gatewayの内側でモデル提供元を切り替えられるようにし、Salesforceへ返す項目とSchemaは変えない。

帰り際、真琴は赤い表示の残るモニターを見た。失敗は隠されていない。それでも、失敗した場所が見えることで、次に直す場所も見えていた。工場の停止記録を設備改善へつなぐ日も、こうした小さな確認の積み重ねから始まる気がした。

改修を終えたSalesforceの商談画面で、営業担当の彩は、別の生成AI画面を探さずに「要約を作成」ボタンを押しました。以前は、AIの画面とCRMを行き来し、紙のメモを見ながら項目を一つずつ写していました。

画面の中央に、商談の要約が現れました。右側には、次回アクションと期限の案が並び、その下には、根拠となったメール、面談メモ、問い合わせ内容が表示されていました。

「この要約は、先ほどの面談メモとメールから作られています。ここだけ確認すればいいんですね」

彩が指で触れると、取引先名、相談内容、次回の連絡日、担当者候補が色分けされました。確かな項目は白く、判断が必要な項目は淡い黄色です。要確認箇所が見えるだけで、長い文章を最初から読み直す時間が変わりました。

画面の下には、AIの案をそのまま確定するのではなく、「承認」「修正」「再生成」の三つのボタンがありました。彩は面談メモに戻り、次回の連絡日だけを直してから、「承認」を押しました。

承認を受けた案は、すぐにSalesforceの各項目へ分かれて登録されました。会社名は取引先情報へ、相談内容は商談メモへ、次回アクションは担当者のタスクへ送られます。AIが直接CRMを書き換えるのではなく、人の確認を通ってから、連携基盤のiPaaSが反映する流れです。

そのとき、画面の一部が赤くなりました。担当者候補に、登録されていない社員名が含まれていたのです。システムは該当箇所と理由を示し、彩に担当者の選び直し、またはAIへの再生成を求めました。

「止まる場所が分かるなら、怖さが違います。前は、登録できない理由を後から探していました」

紬は運用画面を開きました。そこには、処理時間、AI案の採用率、修正量、エラー率、差し戻し件数が並び、登録後の品質も確認できました。どの案が採用されたか、誰がどこを直したか、どの根拠を見て承認したかも、履歴として残っています。

経営会議の机には、生成AIに関するDeloitte調査の資料が置かれていました。24カ国の経営幹部3,235名を対象にした調査では、66％が生産性向上を実感し、85％がAI投資を増やしていました。今年も投資を増やす見込みの人は91％でした。一方で、収益成長につながった企業は20％にとどまり、74％は将来の成果を期待する段階にありました（出典：Deloitte調査。調査名とURLは提供資料に記載なし）。

大橋は資料を閉じました。

「投資するかどうかより、どの仕事のどこまでを任せ、どこで人が止めるかを決めることが先だ」

紬は、運用画面の設定を一つずつ確かめました。AIの出力は登録前に人が確認できること、エラーと判断の履歴が残ること、使うモデルを切り替えてもCRMへ渡す業務データの形が変わらないこと。JSON Schemaで項目の形を整え、その後に業務ルールで意味を確かめる仕組みも、画面の奥で動いていました。

午後になると、営業席から紙をめくる音が減りました。彩は要約を読み、根拠を開き、必要なところだけを直して次の案件へ進みます。処理時間だけでなく、扱えた案件数、登録後の品質、ミスの少なさ、対応できる時間、修正量を並べて見ることで、仕事の流れそのものが見え始めました。

真琴が営業フロアを通ると、以前のように「登録が終わらない」と立ち止まる人はいませんでした。画面には、確認を待つ案件と、差し戻された案件が静かに並び、誰が次に動くかが分かります。

夕方、紬は一件の履歴を閉じました。AIが考え、人が確かめ、業務データとして戻る。その小さな道筋が、案件を止めずに次の仕事へ渡していました。

季節が変わり、営業所の窓から青い空が見える朝になった。新しく配属された陽菜は、少し緊張しながらSalesforceの商談画面を開いた。以前なら、別の画面から文章を探し、どの項目へ貼るのか迷う時間があった。

「まずは、この商談の情報を見てみよう」

陽菜が画面の「AI要約」ボタンを押すと、顧客との過去のやり取りが短い文章になって現れた。社内マニュアルも参照され、案件の分類、これまでの話、次に提案できそうな対応、注意する点が、ひとつの画面に並んでいる。参照した記録も表示されていた。

「この注意点は、前回の打ち合わせで納期を確認していないからですね」

陽菜が項目を開くと、AIの下書きの横に、確認のための理由が表示された。けれど、画面の下には「確認して承認」というボタンが残っている。AIが文章を作っても、顧客との約束を決めるのは陽菜の仕事だった。

案件の担当者を選ぶ欄には、小さな黄色の印がついていた。顧客の希望と社内の登録情報が少し違うため、「要確認」と表示され、担当者へ相談する流れも用意されている。

「迷ったまま登録しなくていいんですね」

隣の席の先輩がうなずいた。

「そうだよ。AIは候補を出す。人が確かめる。必要なら止めたり、書き直したりするんだ」

そのころ、少し離れた席で紬は運用画面を見ていた。処理中の依頼、承認を待つ案件、失敗した依頼、やり直しが成功した記録が、静かに並んでいる。誰が何を確認し、どの情報を使って登録したかという監査ログも、同じ画面からたどれた。

「失敗したものが、消えずに残っているのがいいですね」

紬がそう言うと、蓮はAI Gatewayの設定画面から目を上げた。AI Gatewayは、用途に合わせて使うモデルを切り替える通り道だ。短い分類には軽いモデルを使い、長い要約には別のモデルを使っても、Salesforceへ返すデータの形と、誰が操作できるかという権限は変わらない。

「中のモデルが変わっても、受け渡しの約束は同じにしてあります。JSON Schemaという、データの形を決める設計図で確認するんです」

蓮は画面を指でなぞった。

「形が合っているかを機械で見て、そのあと業務のルールも確かめる。おかしければ、もう一度試すか、人に戻す。だから、AIに直接システムを触らせずに済みます」

陽菜は提案文の一部を書き直した。顧客の言葉に合わせて、少しやわらかい表現に変える。すると、画面の右側に、変更した人と時刻が記録された。承認前なら、いつでも止められる仕組みだった。

窓の外では、配送車がゆっくりと営業所を出ていった。春の風が机の書類を揺らし、陽菜は最後に内容を読み返した。

「これで大丈夫です。承認します」

陽菜がボタンを押すと、画面に「登録しました」と表示された。案件は次の担当者へ静かに引き継がれ、誰かが文章を写し直すために席を立つことはなかった。新しい朝の営業所では、AIの下書きと人の判断と業務システムの記録が、同じ画面の中で並んでいた。