AIの実務組み込み ― 業務データ活用・システム連携編

組み込みの共通構造

本章では、AIを実際の業務システムに組み込む代表的な形を11種類扱います。個別の用途に入る前に、すべてに共通する構造を押さえます。

業務組み込みは、例外なく次の4要素で構成されます。

1. 入力の取り込み ― どこからデータを受け取るか。ファイル、メール、既存システム、センサー。
2. AIによる処理 ― 抽出、分類、予測、要約、生成。
3. 人の確認 ― どの条件で人が見るか。全件、条件付き、抜き取り。
4. 結果の書き戻し ― 処理結果をどこに保存し、次の工程にどう渡すか。

実務上の作業量は、2ではなく1・3・4に集中します。AIの処理自体は、多くの場合API呼び出しの数十行で済みます。時間がかかるのは入出力の接続と、人の確認工程の設計です。この認識のずれが、見積もりの食い違いの主要な原因になります(第9章)。

もう1つの共通点として、すべての用途で「AIが処理できなかったもの」の受け皿が必要です。この受け皿がない設計は、稼働開始後に業務が滞留します。

帳票・書類のデータ化

請求書、納品書、申込書、検査票といった紙やPDFの書類から、必要な項目を読み取ってデータにする用途です。AI-OCR(紙やPDFの文字を読み取ってデータ化する技術。OCRは光学文字認識の略)と呼ばれます。

従来のOCRとの違い

従来型は、読み取る位置を座標で指定する方式が中心でした。書式が変わるたびに設定が必要になります。AIを用いた方式は、項目の意味から位置を判断できるため、取引先ごとに書式が違っても対応できる点が大きな違いです。

精度の限界と設計

苦手なものは明確です。手書き文字、かすれたスキャン、押印と重なった数字、複数の表が入り組んだ様式。したがって設計の中心は精度を上げることではなく、読み取り結果の確信度によって人の確認に振り分ける仕組みを作ることです。

実務的な設計の型は次のとおりです。

• 金額・口座番号・日付といった重要項目は、確信度に関わらず人が確認する
• それ以外は確信度のしきい値を決め、下回るものだけ確認に回す
• 確認時の修正内容を記録し、修正が多い項目・取引先を月次で見る
• 修正が集中する箇所は、書式の統一を取引先に依頼する交渉材料にする

4番目は見落とされがちですが効果が大きい対応です。読み取りの難しさは書式に起因することが多く、書式を揃えてもらうほうが技術的な改善より確実な場合があります。

需要予測・異常検知

過去の実績から将来の数値を出す予測と、通常と違う状態を見つける異常検知です。発注量の決定、在庫の適正化、設備の故障予兆、不正取引の検知などに使われます。

必要なデータの条件

この領域の成否は手法よりデータの揃い方で決まります。最低限必要な条件は次のとおりです。

• 期間 ― 季節変動を捉えるには、少なくとも2〜3年分の履歴が必要です。半年分では判断材料になりません。
• 粒度 ― 日次で予測したいなら日次の履歴が必要です。月次の集計しか残っていない場合、日次の予測は作れません。
• 外部要因の記録 ― 販促、天候、休日、競合の動きが記録されていないと、外れた理由を説明できません。
• 欠品・機会損失の記録 ― これが最も見落とされます。「売れなかった日」と「在庫がなくて売れなかった日」が同じ数字として記録されていると、需要を過小に学習します。

異常検知に特有の難しさ

異常検知では、異常のデータがほとんど存在しないという構造的な問題があります。不良品が0.1%しか出ない工程では、正常なデータばかりで学習することになります。

対処は2つです。正常なパターンから外れたものを検出する方式を使うこと。そして見落としと誤検出のどちらを許容するかを先に決めることです(第1章の適合率・再現率)。設備の故障予兆では見落としが致命的なので、誤報を許容して感度を上げるのが通常の選択になります。

会議・応対ログの要約

議事録の作成、コールセンターの応対記録の要約、日報からの課題抽出などです。導入の敷居が低く、効果も実感しやすい領域です。

設計の要点は形式を先に決めることです。要約は情報を捨てる処理なので、何を残すかを指定しないと、必要な情報が落ちます。「決定事項・宿題と担当者・期限・未決の論点」のような型を与えると、出力のばらつきが小さくなり、抜けにも気づけます。

また、要約は元の記録を置き換えるものではありません。元の音声・文字起こしを保存し、疑わしいときに戻れる経路を残す設計が必要です。この保存期間は、個人情報の取り扱い方針と整合させる必要があります(第16章)。

翻訳・文字起こし

実用水準に達している代表例ですが、限界の出方に癖があります。

• 翻訳 ― 社内固有の用語・製品名・部署名を一般語に訳してしまいます。用語集を登録できる仕組みを使い、固有名詞を固定します。
• 文字起こし ― 複数人の同時発話、専門用語、方言で精度が落ちます。録音環境の改善(マイクの位置、1人1マイク)のほうが、モデルの変更より効果が大きい場合が多いです。
• 共通 ― 数字と固有名詞の誤りは、文章として自然なため読んでも気づけません。契約金額・日付・数量は人が原文と突き合わせます。

チャットボット・FAQ自動応答

社内規程やFAQに基づいて質問に答える仕組みです。技術的な主流はRAG(第2章)で、モデルに覚えさせるのではなく回答時に文書を参照させる方式です。

この用途で失敗する原因は、ほぼ次の3つに集約されます。

1. 参照する文書が整っていない ― 新旧版の混在、散在、画像として貼られたPDF。導入前に「どの文書が正か」を決める作業が必要です(第7章)。
2. 答えられないときの動きがない ― 根拠が見つからない場合に推測で答える設定は、誤案内という形の事故になります。「わかりません」と言って人に引き継ぐ経路を必須にします。
3. 出典が表示されない ― 利用者が原文を確認できないと、回答を信頼して次に進めません。利用率が落ちる主要な原因です。

画像・映像解析

製造の外観検査、設備の点検、店舗の混雑把握、安全確認などです。認識・分類系の代表であり、精度を数値で管理できる領域です。

実務上の要点は次の3点です。

• 撮影条件の固定 ― 照明、角度、距離が変わると精度が大きく変わります。導入作業の実質は、撮影環境の整備であることが多いです。
• 不良サンプルの確保 ― 学習には不良の実例が必要です。過去の不良品を廃棄している工程では、収集から始める必要があります。
• 人の再確認の位置 ― 検査では見落としが致命的なので、感度を上げて誤検出を人が確認する設計が基本です。

映像を扱う場合、プライバシーの検討が必須になります。従業員や顧客が写る場合の取り扱い、保存期間、目的の明示です(第19・20章)。端末上で処理して映像を外部に送らない構成(エッジAI)が選択される理由もここにあります。

レポート・資料の自動生成

定型の報告書、提案書の下書き、分析結果の文章化などです。生成AIの得意分野ですが、業務で使うには2つの前提があります。

1つは、元データが構造化されていること。数値の集計結果を渡せば文章化できますが、元データが散在していれば、その集約作業が主な工数になります。

もう1つは、事実の確認工程です。生成された文章に含まれる数値は、必ず元データと突き合わせます。もっともらしい誤りは読んでも気づけません(第18章)。

メール・問い合わせ対応の自動化

受信したメールの分類、優先度付け、返信案の作成です。効果が出やすい一方、セキュリティ上の注意が最も必要な用途でもあります。

理由は、外部から届いたデータをAIが処理するためです。メール本文に指示文が埋め込まれている場合、AIがそれを指示として扱う可能性があります(間接型プロンプトインジェクション、第21章)。

したがってこの用途では、次の2点を設計の前提にします。

• AIには読み取りと下書き作成までを行わせ、送信は人が行う
• AIに与える権限に、外部への送信・社内データの検索を同時に含めない

社内ナレッジ検索・社内AIアシスタント

社内に散在する文書・過去案件・手順書を横断して検索し、回答を作る仕組みです。効果は大きいものの、権限管理が最大の設計課題になります。

人事情報、給与、未公開の経営情報、部署限定の資料が同じ検索対象に入ると、権限のない利用者に情報が渡ります。実装では、利用者の権限に応じて検索対象を絞る仕組みが必須です。この設計を後から追加するのは困難なので、最初から権限の単位を決めて始める必要があります(第16章)。

基幹システムへのAI組み込み

ERP・SCM・CRMといった基幹システムにAIの処理を組み込む場合、他の用途とは考慮点が変わります。

• データの整合性 ― 基幹システムのデータを書き換える処理では、失敗時に中途半端な状態を残さない設計が必須です。
• 監査証跡 ― 誰が(何が)いつどう変更したかを追える記録が必要です。AIによる変更も同様に記録します。
• 承認の位置 ― 金額や在庫を動かす処理では、AIの出力は提案に留め、確定は人の承認とするのが基本です。
• 既存の権限モデルとの整合 ― AIが呼び出すときの権限を、担当者の権限と同じ枠組みで管理します。

実務では、基幹システム側の改修が制約になることが多いです。基幹システムに書き戻さず、別のデータベースに結果を保存して人が転記する構成から始めるほうが、着手が早く安全な場合もあります。

API連携の基本と設計上の注意

ここまでの用途を自社の仕組みに組み込む場合、API(システム同士がデータをやり取りするための接続口)経由でAIを呼び出す形が基本になります。呼び出し自体は難しくありません。実務で工数がかかるのは周辺です。

社外・顧客に出す場合に変わる4点

ここまで挙げた組み込み例は、いずれも社内利用を前提に書いてきました。同じ仕組みを社外の相手や顧客に向けて出す場合、判断の水準が変わります。変わるのは技術ではなく、責任の置き方です。

1. 誤りが会社の意思表示として扱われる ― 社内向けなら「AIの出力なので確認します」で済むものが、社外では回答そのものが会社の見解になります。金額・納期・適用条件・在庫の可否といった約束に関わる項目は、AIの出力をそのまま外に出さない設計が前提になります。
2. AIが応答していることを分かるようにする ― 相手が人間だと思って話しているかどうかで、受け取り方も後の説明も変わります。表示のしかたは業種の慣行や規制の側からも要請されることがあります(第19・20章)。
3. 苦情と応対記録を残す ― 社外とのやり取りは、後から「何をどう答えたか」を再現できる必要があります。入力と出力の保存期間、参照した文書の版、担当者に引き継いだ時刻。ここは社内向けより厳しく設計します(第16章)。
4. 人に渡す条件を先に決める ― 相手が繰り返し同じことを聞いている、感情的な表現が混じっている、金額や契約に触れた。この種の合図で人に切り替える条件を、稼働前に決めます。決めていないと、切り替えの判断が個々の担当者に残ります。

加えて、未成年や配慮が必要な相手が利用し得る窓口では、判断の水準がさらに上がります(第20章)。社内で1年動いた仕組みを社外に開く場合も、この4点は新規に設計する対象です。「もう動いているから」は根拠になりません。

エージェントに、どこまで任せるか

出力を返すだけの仕組みと、自分で操作を実行する仕組み(エージェント)は、同じAIでも判断が別になります。第2章で仕組みを、第21章で権限設計を扱いますが、業務側で決めるのは「何をどこまで任せるか」の1点です。

判定は3つで足ります。

運用は3段階で上げます。提案のみ → 人の承認つき実行 → 自動。段階を上げる条件と、例外が出たときの戻し先(誰の手元に落ちるか)を先に決めてください。ここを決めずに自動まで進めると、失敗した処理が誰にも拾われないまま滞留します。

人の確認をどこに置くか

すべての用途に共通する最後の設計事項です。確認の型は3つあり、選ぶ基準は精度ではなく間違えたときの影響の大きさです。

抜き取り検査を選ぶ場合、点検結果を記録することが必須です。記録がないと、確認が形骸化したことに気づけません(第14・24章)。