業務をAI化するときのアルゴリズムは、「目的が数値の最小化・最大化か」「ルールで書けるか」「正解付きの過去データがあるか」「言葉の曖昧さを扱う必要があるか」の順に問うと選べます。LLMは便利ですが、シフト表や税額計算のように答えが一つに決まる処理には向きません。この記事では、主な技術の向き不向きと、業務フローのどこに人の確認を入れるかを、ひとつの会社の業務を例に整理します。
「とりあえずLLM」が危ない理由
生成AIが身近になってから、業務改善の相談で「AIで何とかできないか」と言われる場面が増えました。ここで、どの処理もLLMに任せる設計をしてしまうと、あとで困ります。
LLMの出力は確率的で、同じ入力でも毎回少しずつ違う答えが返ります。もっともらしい誤りを出すこともあります。文章の要約や分類のように、もともと答えに幅がある処理ならそれで問題ありません。しかし、配送ルートや勤務シフトのように「制約を満たすなかで最もよい答え」が数学的に決まる処理をLLMに任せると、制約違反や非効率な答えが混じり、毎回人が確かめる手間が残ります。
逆に、厳密に解ける問題を数理最適化で解けば、解は一意に決まり、人の確認はほとんど要りません。技術を選ぶことは、そのまま業務フローに人の確認工程をいくつ置くかを決めることでもあります。
何で解くかの判断フロー
次の順に問います。
Q1. 目的は数値の最小化／最大化か？
├─ はい
│ ├─ 目的と制約を数式で書ける → 線形計画・整数計画・ネットワークフロー
│ └─ 書けないが評価はできる（1回の試行が高コスト） → ベイズ最適化
└─ いいえ
├─ 明確なルールで書ける → ルールベース
├─ 正解付きの過去データで予測する → 教師あり機械学習
├─ 構造の発見や異常の検知が目的 → 教師なし機械学習
└─ 自然言語や暗黙知を扱う → LLM（社内情報が要るならRAG）
判断の軸はシンプルで、目的を数値で最小化・最大化できるなら最適化を考え、できないなら曖昧さが残るので、AIの出力に人の確認を組み合わせます。
主な技術の比較
| 技術 | 入力 | 出力 | 解の性質 | 人の確認 | 向く業務の例 |
|---|---|---|---|---|---|
| ルールベース | 入力値と明示されたルール | ルールどおりの確定値 | 確定 | 不要 | 税額計算、入力チェック、在庫切れ警告 |
| 線形計画法 | 線形の目的関数と制約 | 最適な変数の値 | 厳密解 | 不要 | 生産計画、配合の決定 |
| 整数計画法 | 目的関数と整数の制約 | 整数の最適解 | 規模が大きいと近似解のことも | 通常は不要 | シフト表、配送の割り当て |
| ネットワークフロー | ノードと辺、容量、コスト | 最短経路、最大流、最小費用 | 厳密解 | 不要 | 物流網、経路探索、マッチング |
| ベイズ最適化 | 評価に手間がかかる関数 | よいパラメータの推定値 | 確率的な近似 | 採否は人 | 配合や条件の試行、パラメータ調整 |
| 教師あり機械学習 | 特徴量と正解ラベル付き過去データ | 予測値 | 確率的 | 必要 | 需要予測、解約予測、不良の判定 |
| 教師なし機械学習 | ラベルなしのデータ | グループ分け、異常度 | 解釈が必要 | 必要 | 顧客の分類、異常検知 |
| LLM | 自然言語の指示 | 自然言語の応答 | 確率的で揺らぐ | 必要 | 要約、分類、文章作成、問い合わせ対応 |
実行時間にも差があります。ルールベースは一瞬で終わり、線形計画やネットワークフローはかなり大きな規模でも短時間で解けます。整数計画は問題の規模によって時間が大きく伸びることがあります。機械学習は学習に時間がかかり、予測自体は速く返ります。LLMは1回の応答に数秒かかることもあります。
LLMに社内の情報を答えさせる：RAGとエンベディング
LLMは一般的な知識には答えられても、その会社の就業規則や製品マニュアルのような社内情報は知りません。そこで使われるのがRAG（検索拡張生成）です。
- 質問に関係する社内文書を検索する
- 見つけた文書をプロンプトに含めて、LLMに回答を作らせる
回答の質は1の検索で決まります。間違った文書を渡されれば、LLMは間違った回答を作るからです。この検索で使われるのがエンベディングです。エンベディングは文章を数値の並び（ベクトル）に変換する技術で、意味が近い文章ほど近いベクトルになります。近さはコサイン類似度、つまり2つのベクトルの向きがどれだけ揃っているかで測ります。
キーワード検索との違いは次の例でわかります。
質問：「在宅勤務の申請方法は？」
キーワード検索
→ 「在宅勤務」「申請」を含む文書を探す
→ 「テレワーク実施手続き」は見つからない（言葉が違う）
エンベディングによる意味検索
→ 質問と文書をそれぞれベクトルにし、近い文書を探す
→ 「テレワーク実施手続き」が見つかる（意味が近い）
RAGを設計するときに考えることは、どの単位で文書を区切ってベクトル化するか、何件を取り出してLLMに渡すか、取り出せなかったときにどう答えさせるか、です。ここも出力は確率的なので、回答の根拠になった文書を一緒に表示し、利用者が元の文書を確かめられるようにしておきます。
例題：設備保守会社の業務をAI化する
空調設備の保守を請け負う会社から「業務全体をAIで効率化したい」と相談を受けたとします。業務を分けてみると、性質の違う処理が混ざっています。
| 業務 | 処理の性質 | 選ぶ技術 | 下流に置く工程 |
|---|---|---|---|
| 修理依頼メールの内容を分類する | 自由文で表現がばらつく | LLM | 担当者が分類結果を確認 |
| 技術者の訪問スケジュールを組む | 移動時間の合計を最小化、資格や時間帯の制約あり | 整数計画法 | そのまま配信、例外だけ調整 |
| 部品の来月の必要数を見込む | 過去の交換実績から予測 | 教師あり機械学習 | 購買担当が発注量を承認 |
| 作業費の見積金額を出す | 単価表と作業時間で計算できる | ルールベース | 通知のみ |
| 技術者が過去の修理記録を調べる | 社内文書から関連する記録を探す | RAG | 回答に元記録へのリンクを添える |
| 稼働データから故障の前兆を見つける | 正解ラベルがない | 教師なし機械学習 | 技術者が原因を判断 |
ひとまとめに「AI化」と言っても、半分近くはLLMを使わない処理です。特にスケジュール作成は、LLMに頼むと資格のない技術者を割り当てるような制約違反が混ざりやすく、整数計画で解くほうが確実です。
業務フローに人の確認をどう入れるか
技術を決めたら、その出力の性質に合わせて下流の工程を設計します。
| 上流の処理 | 下流に必要な工程 |
|---|---|
| ルールベース | 通知だけでよい |
| 厳密な最適化（線形・整数計画、ネットワークフロー） | そのまま実行してよい |
| ベイズ最適化 | 採用するかを人が判断 |
| 教師あり機械学習 | 担当者の承認 |
| 教師なし機械学習 | 結果の意味づけ、原因の特定 |
| LLM（文章の作成） | 担当者の最終チェック |
| LLM（判断） | 承認フロー |
確率的な出力をそのまま次の工程に流す設計は避けます。業務フロー図を描くときに、AIの処理の後ろに確認の工程が置かれているかを確かめてください。
PoCで確かめることと段階導入
本開発の前に小さく試すPoCでは、速度や画面の作り込みは後回しにして、業務がそもそもAIで成り立つかだけを確かめます。見るべき点はおおむね次の3つです。
- 散らばった入力から、必要な項目を表の形で取り出せるか
- 取り出した値に業務の判断や計算を当てて、正しい結果を出せるか
- 1つの結果を、宛先ごとに違う様式へ正しく書き出せるか
このとき、プロンプトやルールをいきなり書き始めないことが大切です。先に「この入力ならこの出力が正解」という対応表を作り、それを仕様にします。正解が先にあれば精度を測れますし、改善したかどうかも判断でき、顧客との合意にも使えます。例外的な入力や、現場の暗黙知が要るケースを多めに入れておくと、仕様が早く固まります。
導入も一度に進めず、段階を踏みます。まず決まった計算式で動くルールベースで業務を回し、データがたまったら機械学習の予測に置き換え、制約を整理できたら最適化に進む、という順です。段階ごとに、次に進む条件（精度、現場での利用状況など）を要件として決めておきます。
よくある失敗
- 答えが一つに決まる処理をLLMに任せる。シフト表、最短経路、税額計算は、それぞれ整数計画、経路探索のアルゴリズム、ルールベースで解けます
- 数値の予測をLLMの文章でやらせる。需要予測のように数値データから学ぶ処理は、機械学習のほうが向いています
- 確率的な出力の後ろに確認工程を置かない。予測やLLMの出力が誤っていたときに、誰も気づかないまま後工程に流れます
- RAGの生成部分ばかり調整する。回答がおかしいときは、まず検索で正しい文書が取れているかを確かめます
- 正解データなしでPoCを始める。何をもって成功とするかが決まらず、「なんとなく動いた」で終わります
この記事のまとめ
- 技術の選び方は「最小化・最大化か→ルールで書けるか→正解付きデータがあるか→言葉の曖昧さを扱うか」の順に問う
- 厳密に解ける問題は最適化やルールで解けば、人の確認がほぼ要らない
- 機械学習とLLMは出力が確率的なので、下流に人の確認工程を置く
- 社内情報に答えさせるならRAG。精度はエンベディングによる検索で決まる
- PoCは入力と正解出力の対応表を先に作り、導入はルール→機械学習→最適化と段階を踏む
この内容はロードマップのステップ6「進めて作る」で扱う技術です。業務フローに確認工程を組み込む考え方はTOBE業務フローの描き方と、作ったあとの確かめ方は動作確認の基本とあわせて読むと理解しやすくなります。体系的な解説はFDEガイドの「AIと最適化」と、API呼び出しからエンベディング、RAGまでを実装で学ぶ「AIプロダクト開発カリキュラム」にあり、スライド・演習問題・テストは lecture.iplot.jp で取り組めます。