人工知能の導入

AIの導入 — とは、すでに動いている業務にモデルを組み込むことであり、その隣に別のシステムを立ち上げることではありません。モデルは会社のデータを読み、その中に規則性を見つけ、判断を出します。その判断に基づく行為は、業務が営まれている — CRM、ERP、倉庫のプログラム、レジ、ポータル、メッセンジャー — その場所のシステムが実行します。

そのためプロジェクトはモデルの選定ではなく、四つの答えから始まります：どのデータがあり、それはどのような状態か。どの判断を下す必要があるのか。誰が何でその判断を実行するのか。何の数字で改善が見えるのか。このうち一つでも欠ければ、モデルは誰も責任を負わないデータ源をもう一つ増やすだけになります。

AIが不要な場面。 規則が一行で書けるなら — 「在庫が五個を下回ったら仕入部門へ通知」 — それは規則として書きます：安く、予測でき、一行ずつ検証できます。AIが適するのは、判断材料が数十あり、それが時とともに変わり、人がこれまで「勘で」決めてきた場面です：問い合わせの分類、需要の見積もり、異例の取引の検出、書式の定まらない書類からの項目の抽出。

集めたデータはそのままでは使えません：同じ品目が三通りの名前で呼ばれ、単位が入り混じり、記録の半分には必須の属性がなく、一部の行は同じ取引の重複です。そのような集合で学習したモデルは、規則性を見つけるのではなく、無秩序を再現します。

AIによる処理 はここで三つの課題を担います：記録を一つの形に整えること、属性のないところに属性を付けること、そして元のデータには存在しなかったカテゴリーへ対象を振り分けることです。

• 正規化 — 日付、数値、単位、電話番号、住所、登記情報の書式を統一します
• 名称の突き合わせ — 「ケーブルVVGng 3x2.5」「VVG-ng 3*2.5」「ケーブル vvgng 3x2.5 GOST」を、一つの品目にまとめます
• 欠けた値の補完 — 欠けているカテゴリー、ブランド、単位を、そのカードの他の項目から推定します
• 分類 — 商品をグループへ、問い合わせをテーマへ、支払いを費目へ、取引先をセグメントへ振り分けます
• 属性の抽出 — 説明文から特性を取り出します：容量、重量、出力、成分、消費期限
• 重複の検出 — 同じ取引先の二つのカードや、同じ納品の二つの書類を、文字列の一致ではなく項目の組み合わせで見つけます
• 矛盾の確認 — 在庫がマイナス、出荷日が注文日より前、品目の合計が書類の総額と一致しない

行為： 確からしい訂正は自動で適用され、元の値とともに記録に残ります。判断の分かれるものは、一件ずつのメールではなく一つの一覧として、そのマスタの持ち主の確認へ回ります。

なぜこれが独立した仕事なのか

データの質は、プロジェクト前の一度きりの片づけではなく、絶えず続く仕事です：マスタは毎日増え、仕入先は価格表の書式を変え、担当者は既存のカードを探す代わりに新しく作ります。そのためクレンジングの規則とモデルは、データとともにシステムの中で生き、取り込みのたびに適用されます。

どの訂正にも、実行者 — 規則かモデルか — と、時刻、旧い値、新しい値があります。これは形式主義ではありません：履歴がなければ、先月のレポートが今日は別の数字を示す理由を調べられません。

結果

マスタは枝分かれしなくなり、商品グループと費目のレポートは互いに一致し、データの準備が分析プロジェクトの期間の大半を食うこともなくなります。

通常のレポートは、与えられた問いに答えます：月ごとの売上、支店ごとの販売、倉庫ごとの在庫。問いを立てるのは人であり、そのため見えるのは、誰かが見ようと思いついた分だけです。

AIによる処理 はここで向きを変えます：モデルが自ら断面を見て回り、指標の振る舞いが想定と違うものを持ってきます。「グラフを描いて」ではなく、「いつもと違うことが起きている場所が三つあり、それはこういうことと関係している」と示すのです。

高度な分析が行うこと：

• セグメント分け — 顧客、販売の拠点、商品を、あらかじめ考えたカテゴリーではなく、実際の振る舞いでグループ分けします
• 指標の分解 — 売上の落ち込みを、カテゴリー、支店、チャネル、平均購入単価の寄与に分けます：何が落ちたのかが見えます
• 出来事どうしの関係 — 注文、顧客、拠点のどの特徴が、キャンセル、返品、支払いの遅れ、顧客の離脱をより多く伴うのか
• リスクの評価 — 注文が取り消される、請求が期限内に支払われない、顧客が買わなくなる、それぞれの確からしさ
• 注目の順位づけ — 調べるべき対象の一覧を、五十音順ではなく、起こり得る損失の大きさで並べます
• 普通の言葉での問い合わせ — データへの問いを言葉で。回答には情報源と期間の明示が必須です

行為： 見つかったことはダッシュボードにとどまりません — 宛先と期限を持つ課題になります：落ち込んだ拠点を調べる、リスク層の顧客に連絡する、返品の増えたカテゴリーを確認する。

定型業務とは、一日に何十回も繰り返され、注意を要するが技能は要しない作業です：メールからカードへデータを移す、支払いを費目に振り分ける、担当者を割り当てる、書類がそろっているか確認する、ステータスを付ける。

AIによる処理 が必要なのは、入力が形式化されていない場面です：メールは言葉で書かれ、書類は見慣れない書式で届き、申し込みは顧客ごとに言い回しが違います。モデルがそうした入力を構造に整え、その先は通常の規則 — 予測でき、検証できるもの — が業務を進めます。

自動処理へ移るもの：

• 受信したメールと申し込みの仕分け
• 問い合わせのテーマと緊急度の判定
• 担当者と期限の割り当て
• 顧客カードと商談の作成
• 書類からのデータ抽出
• 書類と注文・請求の照合
• 支払いの費目と契約への振り分け
• 書類一式がそろっているかの確認
• 定型的な問い合わせへの回答の作成
• 文章の翻訳と表記の統一
• 雛形に沿った明細や証明書の作成
• 説明文からの商品カードの項目の入力
• 着手前の申し込みの記入もれの確認
• 作業キューの優先順位づけ
• シフト、日、区画ごとのまとめ
• 出来事に応じた責任者への通知

行為と成果： 作業はシステムが実行し、実行者、時刻、元の値とともに記録に残ります。社員はデータの入力から、例外の処理 — モデルが確信を持てない場面や、誤りの代償が大きい場面 — へ移ります。

データ： 納品書、請求書、受領書、契約書、仕様書、支払指図書、申請書、機器の仕様書、添付付きのメール。書式はさまざまです：pdf、スマートフォンの写真、スキャン、出力ファイル、紙の原本。

AIによる処理： 文字の認識、書類の種類の判定、項目と表部分の抽出、品目マスタとの突き合わせ、そして書類と注文・契約・取引先との結び付け。項目ごとに、値とそれに対する確からしさを返します。

何を抽出するか：

• 当事者の登記情報 — 名称、登録番号、住所、銀行口座情報
• 書類の番号と日付 、契約、請求、注文への参照
• 表の部分 — 品目、数量、単価、金額、税率
• 合計 — 税抜額、税額、支払総額、通貨
• 期限と条件 — 支払期限、納入条件、保証、違約金
• 署名と押印 — 真正性ではなく有無を：真正性は、法的効力を持つ書類のやり取りの領分です

行為： 書類を注文と請求と照合し、食い違いを一覧に出し、書類は登録されるか、特定の社員の確認へ回されます。 結果： 書類の入力が独立した職務でなくなり、食い違いは月次の締めではなく支払いの前に見つかります。

境目はどこにあるか

認識は、どの書類の集合でも百パーセントの精度を出しませんし、出す必要もありません。要点は別のところにあります：システムは、どの項目を信頼し、どの項目の確認を求めるのかを示します。オペレーターは書類を丸ごと打ち込む代わりに、指し示された数項目を確認します。

元の画像の質が悪いことは、黙って誤る理由にはなりません：ぶれた写真、切れたページ、仕様書の二枚目の欠落は明示され、理由を添えて差出人へ返されます。

結果

処理の速さが受信の量に左右されなくなり、経理と調達は、社員一人ひとりのメールボックスではなく一つの一覧で書類の状態を見られるようになります。

データ： メール、サイトからの申し込み、メッセンジャーの連絡、通話の書き起こし、サポートのチャットのやり取り、レビューと評価。これらはすべて形式の定まらない文章で、これまで人が読んで仕分けてきたものです。

AIによる処理： 問い合わせをテーマと下位テーマに振り分け、緊急度と調子を判定し、本文から注文番号、商品名、住所などの実体を抽出し、問い合わせを顧客の履歴と結び付けます。同じ用件についての再度の問い合わせは、一つの事案にまとめられます。

行為： 申し込みは項目の埋まった状態で担当グループのキューへ入り、対応期限は緊急度から計算され、再度の問い合わせは優先度が上がり、顧客は番号と見込みの期限を添えた確認を受け取ります。

結果： 問い合わせが朝まで共通の受信箱に置かれることはなくなり、責任者が見るのは「苦情が多い」ではなく構造です：どのテーマで流量が増えているのか、どこで回答時間が伸びているのか、どの製品が再度の問い合わせを生むのか。

流れ全体を見ると分かること

一件の問い合わせは事案を語り、流れ全体は製品と業務を語ります。期間のテーマ別の分類は、何が疑問を生んでいるのかを示します：分かりにくい説明書、商品説明の誤り、注文手続きの特定の段階の不具合、ある配送業者の遅延。

そのためテーマは頭の中から出すのではありません：まず問い合わせを意味で自動的にグループ分けし、次にできたグループを手で直して、一覧として確定します。以降それは製品とともに生き、新しいグループはシステムが提案します。

ボットは一つのモデルではなく、つながり合ういくつかの部分です。この切り分けは実務上重要です：部分ごとに、故障の原因も、指標も、直し方も異なります。

• 問い合わせの理解 — 人が何をしたいのか、どの値を挙げたのか：注文番号、日付、商品、住所
• 知識の検索 — 回答の土台になる、文書の断片と記録の選定
• システムへのアクセス — 許された操作の集合：注文を見る、申し込みを作る、配送日を変える。いずれも明示されており、ボットに勝手な行為はできません
• 回答の組み立て — モデルは、見つけたものとシステムから得たものだけで回答を作ります。出典にないことは回答に現れません
• 送信前の確認 — 回答は出典と、行為は利用者の権限と上限と突き合わせます
• 人への引き継ぎ — 引き継ぎの規則：確からしさが低い、同じ質問の繰り返し、否定的な反応、扱わないと決めたテーマ
• 記録 — 何を尋ねられ、何が見つかり、ボットが何をどのような根拠で行ったか。これがなければ苦情の調査はできません

接続の窓口 — サイトとマイページ、メッセンジャー、メール、音声認識を備えた電話回線、社内ポータル、社員の作業画面。その際の考え方は一つです：窓口が変えるのは入力の形であって、ボットに許された行為ではありません。

回答はどこから来るのか

ボットは御社の文書を「覚えて」いるわけではありません — 質問の時点でそれを探し、見つけたものに基づいて答えます。そのため規程の更新は、モデルの再学習の後ではなく、それを取り込んだ直後から効きます。そしてそのため、どの回答にも出典があります。

ボットはどう立ち上げるか

まず、実際の質問の集合を集めます — やり取り、問い合わせ、社内のチャットから。稼働前にボットをそれで検証します：回答を出典と突き合わせ、誤りを原因ごとに分析します。その後で初めて、通常はまず一つのグループに対して、ボットを利用者へ開きます。

社内アシスタントが顧客向けボットと違うのは、扱うデータです：社内の情報を、しかも特定の社員の権限の範囲で扱います。倉庫担当者と財務責任者が同じ質問をしても、答えは異なります — 参照できる文書が違うからです。

作業の場でアシスタントが行うこと：

• 規程に基づいて答える — どう手続きするか、誰が承認するか、期限は何日か、どの書式か。条項への参照を添えて
• 対象についての要約を作る — 顧客、商談、契約、注文、機器：履歴、未解決の課題、直近の期限
• 下書きを用意する — メール、見積書、問い合わせへの回答、課題の説明、打ち合わせの記録
• 社員に代わって記録する — 電話や打ち合わせの結果が、タスク、期限、カードの更新になります
• 申請を作る — 人事、調達、技術サポートへ：項目は二十項目の入力欄ではなく、会話から埋まります
• シフトのまとめを用意する — その期間に区画で何が起き、何が未了で、何に判断が必要か

結果： 社員は、必要な文書を探すことや規程を思い出すこと、入力欄を埋めることではなく、仕事そのものに時間を使えます。アシスタントは人の代わりに判断はしません — 下ごしらえを引き受けるのです。

社内の知識が一か所にあることはまれです：規程は一つのフォルダに、契約は二つ目に、技術文書は三つ目にあり、答えの半分はやり取りの中にあります。ここでファイル名の検索は役に立ちません。人が探しているのは文書ではなく、答えだからです。

データ： 規程と通達、契約と付属書、技術文書と設計文書、手順書、解決済みの問い合わせの蓄積、議事録、各種一覧、やり取りの記録 — それぞれの持ち主とアクセスの水準を明示して。

AIによる処理： 文書を断片に分け、断片ごとに意味で索引を作ります。質問は見出しではなく断片と突き合わせます。回答は見つかったものから組み立て、引用と、文書・ページ・版への参照を添えます。

行為と成果： 社員は同僚を回る代わりに、数秒で出典付きの回答を得ます。判断の分かれる場面は引用で検証でき、古い文書はすぐ分かります — 二年前の版から答えが来たなら、それは回答に直接書かれます。

ナレッジベースを実用にするもの

• 入口を一つに — 情報源は索引に接続します。新しい保管庫へ手作業で移すのではありません
• 版と日付 — 断片ごとに文書の版が分かり、有効なものと過去のものが区別されます
• 権限は引き継ぐ — 元のシステムから引き継ぎます。そのため索引が、アクセス制限の抜け道になりません
• 出来事に応じた更新 — 変更された文書は、月に一度の予定ではなく、その場で索引を作り直します
• 利用者からの反応 — 「回答が役に立たなかった」を画面で記録でき、質問とともに検討へ回ります
• 抜けが見える — 出典の見つからなかった質問が一覧にまとまります：それが、足りない規程を書くための課題になります

ナレッジベースが担わないこと

文書管理のシステムの代わりにはならず、正の源にもなりません：法的効力を持つ文書は、署名され保管されている場所に残ります。索引はそれを見つけて引用するための手段であって、独り歩きする別の複製ではありません。

申し込みは自由な形式で、どの窓口からでも届きます：メール、メッセージ、サイトの入力欄、電話、添付ファイル。導入前はそれを人が読み、データをシステムへ移し、種類を判定し、担当者を割り当てます — これに数分から、キューでの数時間の待ちまでがかかります。

AIによる処理： 申し込みの種類を判定し、項目 — 対象、住所、期限、連絡先、契約番号 — を抽出し、記入もれを確認し、緊急度を見積もり、顧客とその履歴に結び付けます。足りない情報は、同じ窓口で自動的に追加で尋ねます。

行為： 申し込みは項目の埋まった状態でシステムに登録され、規則に従ってグループか担当者が割り当てられ、期限が設定され、番号を添えた確認が送られます。同じ用件の重複は、二つ目の申し込みを増やすのではなく、結び付けられます。

結果： 担当者は整った申し込みを受け取り、確認のやり取りではなく仕事から始めます。受信から割り当てまでの時間が、誰がいつ共通の受信箱を開いたかに左右されなくなります。

申し込みの道のり

設定が重要なもの

• 申し込みの種類の一覧と、担当者を割り当てる規則
• 種類ごとの必須項目 — さもなければ追加の確認が機能しません
• 契約と優先度に応じた対応の期限
• 同じ用件の再度の問い合わせをまとめる規則

モデルは必ず誤ります — 問題は、どのくらいの頻度で、どこで、そしてそれがいくらの損になるかです。そのためどの導入にも二組の数字があります：モデル自体の質と、業務の変化です。前者は技術者が、後者は事業が関心を持つもので、両者は自動的には一致しません。

• 適合率と再現率 — 一つの平均値ではなく、クラスごとに個別に：まれでも代償の大きいクラスは、件数の多いクラスより重要です
• 自動で下された判断の割合 — 設定した確からしさのしきい値で、人を介さずに済んだ作業の件数
• 修正の割合 — 自動で下された判断のうち、人が取り消したり変えたりした件数
• 作業の所要時間 — 受信から完了まで。導入前の基準の水準との比較で
• 誤りの代償 — 見落としの代償と、誤検知の代償。しきい値は指標の見栄えではなく、この釣り合いで調整します
• データの移り変わり — 入力データの中身が変わり、システムに一切手を入れていないのに質が落ちること

確からしさのしきい値は定数ではなく、調整の取っ手です。上げれば自動化は減り、誤りも減ります。下げれば逆です。値は、その業務での誤りの代償から選びます。

パネルで見えること

稼働後の運用

モデルは一度きりの納品物ではありません。データは変わります：新しい商品、問い合わせのテーマ、書類の書式、仕入先が現れます。そのためプロジェクトには、新しいデータでの定期的な品質の検証、予定またはしきい値の到達による再学習、そして人が判断を修正した事案の検討を組み込みます。

オペレーターの修正は、最も価値のある学習材料です：別の集合にまとめ、次の学習で使います。こうしてシステムは、他所のデータではなく自らの仕事で良くなっていきます。