チャット画面の外にあるAI
AIを業務に入れるという話は、多くの場合「チャット画面で質問して答えをもらう」使い方から始まります。しかし業務で効果が出やすいのは、むしろ人が画面を開かない領域です。毎日届く請求書の数字を転記する、倉庫の在庫を読んで発注量を決める、応対記録を要約して次の担当者に渡す。こうしたすでに毎日発生している作業にAIを差し込むほうが、効果を測りやすく、続きます。
この章では代表的な組み込み例を横並びで見ていきます。どれも共通して、「AIが8割やり、残り2割を人が確認する」という形になります。その2割をどこに置くかが設計の中心です。
帳票・書類のデータ化
請求書、納品書、申込書といった紙やPDFの書類から、必要な項目を読み取ってデータにする用途です。AI-OCR(紙やPDFの文字を読み取ってデータ化する技術。OCRは光学文字認識の略)と呼ばれます。
従来のOCRとの違いは、書式が揃っていなくても項目の意味から読み取れる点です。取引先ごとに請求書のレイアウトが違っても、「請求金額」がどこにあるかを判断できます。ここが実務では大きく効きます。
一方で限界もはっきりしています。手書き文字、かすれたスキャン、押印と重なった数字は今も苦手です。したがって設計の要点は精度を上げることではなく、自信のない読み取りを人の確認に回す仕組みを作ることです。読み取り結果に確信度が出る製品であれば、しきい値を決めて振り分けます。金額と口座番号だけは必ず人が見る、という運用も現実的です。
需要予測・異常検知
過去の実績から将来の数値を出す予測と、通常と違う状態を見つける異常検知は、生成AIのブーム以前から使われてきた領域です。発注量の決定、在庫の適正化、設備の故障予兆の検知などに使われます。
この領域で成否を決めるのは、モデルの種類よりもデータの揃い方です。3年分の日次データがあれば季節変動を捉えられますが、半年分では判断材料になりません。また、キャンペーンや天候といった外部要因が記録されていないと、予測が外れた理由を説明できません。
朝凪精機では、おととし補修部品の需要予測を試しましたが、予測はまったく当たりませんでした。原因を調べると、問題はモデルではなく入力データにありました。欠品が記録されていなかったため、在庫がなくて出荷できなかった月が、注文の少なかった月として読まれていたのです。「注文がなかった月」と「注文はあったのに出せなかった月」が、同じ数字として学習されていました。二月七日、クラウゼル・テクノロジーズへ送る質問を書いていた席で、情報システム課の倉田はこの件を持ち出し、データが現実の何を落としているかを先に見ないと同じことになる、と話しました。予測が当たらないときは、まず入力データが現実のどの部分を落としているかを疑うほうが早いということです。
この場面は物語之巻 第2話「三週間で届いた提案書」に出てきます。
会議・応対ログの要約
議事録の作成、コールセンターの応対記録の要約、日報からの課題抽出などです。生成AIの得意分野であり、導入のハードルも低い領域です。
ただし要約は「情報を捨てる」処理です。何を残し何を捨てるかの基準を指示しないと、担当者が必要としている情報が落ちます。実務では、要約の形式を先に決めるのが有効です。「決定事項・宿題・期限・未決の論点」の4項目に必ず埋める、といった型を与えると、出力のばらつきが小さくなり、抜けにも気づきやすくなります。
また、要約は元の記録を置き換えるものではありません。元の音声や文字起こしを残しておき、疑わしいときに戻れるようにしておく必要があります。
翻訳・文字起こし
精度が実用水準に達している代表例ですが、限界の出方に癖がある点は押さえておくべきです。
- 翻訳は、社内固有の用語・製品名・部署名を一般語に訳してしまうことがあります。用語集を渡せる製品であれば必ず登録します。
- 文字起こしは、複数人が同時に話す場面、専門用語、方言で精度が落ちます。会議の録音環境を整えるほうが、モデルを変えるより効果が出ることも多いです。
- どちらも「もっともらしい誤り」が出ます。数字と固有名詞は誤っても文章として自然なので、読んでも気づけません。契約金額や日付は人が突き合わせる工程を残します。
問い合わせ対応とチャットボット
社内規程やFAQを参照して質問に答える仕組みは、需要の大きい用途です。ここで重要なのは、AIに知識を「覚えさせる」のではなく、回答時に社内文書を参照させる作り方が主流だという点です。文書を更新すれば回答も変わるため、運用が現実的になります。
この方式でも、参照すべき文書を拾えなければ答えは出ません。ありがちな失敗は、文書の管理が整っていない状態で導入してしまうことです。同じ規程の新旧版が両方置かれていれば、AIは古い方を根拠に答えることがあります。導入前に「どの文書が正なのか」を決める作業が必要で、これは第3章のデータ化の話に直結します。
もう一つ必須なのが、答えられないときの動きです。「わかりません」と言って人に引き継ぐ経路を必ず用意します。無理に答えさせる設定は、誤った案内という形で事故になります。
API連携で既存システムに組み込む
ここまでの用途を自社の仕組みに入れる場合、API(システム同士がデータをやり取りするための接続口)を通じてAIを呼び出す形が基本になります。自社システムがデータを送り、AIが結果を返し、その結果を自社システムが保存・表示する、という流れです。
組み込みで検討すべき点は、AIの精度よりも周辺の設計に集中します。
- 失敗したときの動き ― 応答が遅い、エラーが返る、想定外の形式が返る場合に、業務を止めないための処理を決めます。
- 費用の見積もり ― 多くは処理量に応じた課金です。1件あたりの費用と、月の想定件数から上限を見積もります。
- ログの保存 ― 入力と出力を残しておかないと、あとから「なぜこの結果になったのか」を追えません。
- 送信するデータの範囲 ― 必要な項目だけを送る設計にします。全文を送る必要がある場面は意外に少ないものです。
「AIをつなぐだけなので1週間でできます」という見積もりが出てきたら、上の4点がどう設計されているかを聞いてください。API呼び出し自体は確かに短時間で書けます。実務で時間がかかるのは、失敗時の動き・ログ・権限・費用上限という周辺部分です。ここが抜けた実装は、動くデモとしては完成しますが、業務では使えません(この差は第4章で詳しく扱います)。
組み込みの共通形 ― 人の確認をどこに置くか
紹介した用途はすべて、AIの出力をそのまま最終結果にはしていません。確認の置き方には3つの型があります。
- 全件を人が確認する ― 導入初期はここから始めます。AIは下書きを作る役です。
- 条件で振り分ける ― 確信度が低いもの、金額が大きいもの、新規取引先のものだけを人が見ます。運用が安定してきたらこの形に移ります。
- 事後に抜き取り検査する ― 全件を自動処理し、一定割合を後から点検します。誤りの影響が小さい処理に向きます。
どの型を選ぶかは、精度ではなく間違えたときの影響の大きさで決めます。社内向けの要約なら3、請求処理なら1か2です。この判断軸は第8章でもう一度使います。