備考欄を読むAI、確定する人。注文から発送までの業務設計

読み落としを、担当者の注意力だけで解決しない

物語の発端は、冷凍品を受け取った人からの電話だ。受取側は冷凍庫の容量を理由に翌年の一定日以降を希望していたが、年末に届いてしまった。注文は複数の受付サイトから入り、ファイルの形も異なる。繁忙期に担当者が手作業で転記し、自由記述の要望を読み続ける工程で、条件が台帳に反映されなかった。

この状況で「転記を全部AIに任せる」とすると、元の問題を別の不確実性へ移すだけになる。動画は、入力形式の違い、備考の見落とし、最終確認の欠落を分解する。同じ列を同じ列へ移す処理には決めた規則を使い、文の意味を整理する部分にAIを置き、約束や確定は人が担う。使うAIの名前より、工程ごとの責任を決めることが先にある。

実務でも、住所のように値をそのまま保持すべき項目と、文章から条件を抽出する項目は分けたい。形式変換の段階で注文番号、件数、必須欄、重複を検査すれば、後工程へ渡してはいけないデータを早く発見できる。これは本記事の設計上の考察であり、動画内で特定のシステムを実装・検証したという意味ではない。

AI担当を成立させる七つの取り決め

動画は、事務担当の「田中さん」を七つの部品で説明する。最初は役割で、対象を備考欄の分類と台帳修正案の作成に絞る。次に参照できるナレッジを定め、返礼品一覧、冷凍便を出せる曜日、過去の備考と対応記録を材料にする。三つ目の指示文には、実行する作業だけでなく、氏名・住所を書き換えない、実現できると約束しない、自分で確定しない、という境界も含む。

四つ目の分類表では、配送時期、のし、分割配送、届け先変更、その他という既定の分類を使う。毎回モデルが分類名を自由に作ると、担当者の一覧や後工程の分岐が安定しない。「その他」は失敗した分類ではなく、既知の処理に押し込めず人へ返すための受け皿になる。複数条件を含む備考を一つの分類だけで十分扱えるかは、導入先で別に試す必要がある。

五つ目は出力形式だ。提案に原文を添えることで、確認者は元の注文へ何度も戻らずに比較できる。六つ目は引き継ぎ条件で、届け先変更、強い不満を含む文、その他に入る依頼は、修正案を進めず人へ回す。七つ目の記録では、注文番号、備考、分類、提案、確定者を残す。自然な文章で返答できるだけでは、担当業務の仕組みは完成しない。

これらは、生成AIの能力を宣伝する項目ではない。何を入力し、何を返し、どこで止め、誰が次へ進めるかを、運用側が定義する契約に近い。分類結果だけを保存して原文を捨てると、後から誤分類の理由を検討できなくなる。原文と提案、採否を対応させて残すことが改善の土台になる。

個人情報を渡す範囲も工程で分ける

物語では、氏名や住所の転記を規則による処理に置き、AIが読む範囲を備考欄に限定する。ここで注意したいのは、自由記述にも個人名、電話番号、新住所などが書かれ得ることだ。「備考だけだから個人情報がない」とは判断できない。実際の運用では、入力前に必要性を点検し、処理に不要な情報を除く設計が要る。

注文番号も、社内のデータと結び付けられるなら取扱いを決める必要がある。モデルへ渡す識別子と、原本を検索する識別子を分ける方法も考えられる。ただし、ここで特定の匿名化方式が法令上十分だと断定することはできない。接続先、保存先、閲覧者、保持期間を含め、実データを流す前に業務として確認する事項だ。

提案と確定を、画面だけでなく権限でも分離する

本編の処理は、朝の注文ファイル収集、形式統一と重複の印付け、備考の分類と提案、人による原文照合、発送日の計算、梱包時の再照合、記録による改善へ続く。AIが担当するのは、この流れの一部分だ。定型処理も人の確認も残るため、AIの返答から直接発送処理へつながる構成ではない。

人の確認を実装する一例として、n8nの公式資料は、指定したツールの実行前に処理を止め、承認または拒否を待つ仕組みを説明している。これは一般的な実装例であり、この漫画でn8nを利用していると示すものではない。

設計上は、確認待ちの提案と、出荷へ渡せる確定値を別に保持するとよい。誰が何を確認したか、元の注文が更新されていないか、同じ注文を再処理していないかも検査する。画面に「人が確認」と書くだけで、AIが更新用の権限を持ち続けていれば、境界は弱い。提案担当には必要な読取範囲だけを与え、確定処理は別の操作として扱う考え方が重要になる。

日付を読めても、出荷計画はまだ終わらない

試運転では、配送時期の条件や、のしが不要という依頼を原文と照合する。一方、届け先変更は担当者へ止めて渡す。正常な処理だけでなく、止まるべき入力で止まることも確認する構成だ。

さらに物語は、希望日を反映した後の問題を描く。ある日に出荷が集中し、自社の冷凍庫や一日あたりの出荷能力が足りなくなる。そこで日程の割り振りに、処理能力と保管容量の条件を追加し、日程調整案を人が決める流れへ修正する。作中の集中件数は架空の数字であり、現実の処理能力や改善率を示すものではない。

ここから読み取れるのは、文章理解の正しさと業務全体の実行可能性は別、ということだ。「六日以降」は六日だけを指定する条件ではない。配送希望と発送日も同一ではないため、配送に要する時間、稼働日、保管条件を合わせて考える必要がある。記事で提案するなら、原文の条件を保ちながら候補日を計算し、容量を超えた場合は未確定として戻す。顧客の希望を満たすか不明な調整を、自動で約束へ変えてはいけない。

小さな試運転で、誤りと確認負担を測る

試す際は架空の注文を使い、明確な期日、曖昧な急ぎの依頼、否定表現、複数条件、住所変更、分類外の依頼、空欄、重複をそろえたい。期待する分類だけでなく、原文にない日付を補わないこと、引き継ぎ対象を通さないこと、未承認の提案が出荷へ届かないことを確認する。処理の途中で失敗し、再実行した場合も二重に確定されないかを見る。

測る対象は生成時間だけではない。人が原文を確認する時間、提案の修正件数、引き継ぎ漏れ、確認待ちの滞留、誤配送につながる不整合を含める。発送のボトルネックが残るのに、備考を読む速度だけを上げても、全体の負担が減るとは限らない。こうした評価は今後の導入で測定すべきもので、動画から実測値を読み取ることはできない。

運営会社のRO合同会社への相談では、対象の注文形式、担当者、使っている台帳、確定権限を整理すると話を具体化しやすい。事務のAI社員「田中さん」の公式プロフィールも、掲載内容を導入設計の例とし、実際の接続方法や対応範囲は業務ごとに決めるとしている。漫画の設計思想と、個別企業で利用できる機能・費用・権限は分けて確認したい。

出典

• 柴亮太のAI社員チャンネル：本編（2026年11月1日公開） — 公開文字起こしの全台詞を確認。架空の業務設計物語。
• 同題材の完結Shorts
• n8n公式：Human-in-the-loop for tools — ツール実行前の承認機構の一般例。
• RO合同会社：事務のAI社員「田中さん」 — 提案範囲と人の確認に関する公式説明。