この記事で分かること
- AIシステムを出力や業務目的から見分ける考え方
- 代表的な方式の入力データ、出力、評価軸、向く業務
- 課題から候補方式を絞り、PoCで比較する具体的な手順
- 生成AIなどで起きやすい方式選定の誤解と、運用上の注意点
AIの種類は「何を出力するか」と「何を解くか」で考える
AIシステムは、生成AIだけを指す言葉ではありません。入力をもとに、予測、コンテンツ、推薦、判断などを出力し、現実または仮想の環境に影響を与える仕組みも含まれます。つまり、売上予測を出すモデルも、画像の欠陥候補を示す仕組みも、文章を作る生成AIも、それぞれ目的の異なるAIシステムです。
方式を整理するときは、二つの軸を混同しないようにします。一つは「予測」「認識」「推薦」「最適化」「生成」といったタスク、もう一つは機械学習、深層学習、大規模言語モデルなどの技術です。たとえば画像認識はタスク名であり、その裏側でどのモデルを使うかは別の選択です。同じ目的を複数の技術で実現できる場合もあれば、一つの業務に複数の方式を組み合わせる場合もあります。
「AIを導入する」という言い方だけでは、必要な機能が決まりません。結果が数値なのか、分類ラベルなのか、候補一覧なのか、実行手順なのかを先に定義すると、学習に必要なデータと確認すべき品質も見えてきます。AIの活用領域を業務別に考えたい場合は、AIシステムの業務別活用事例も参考になります。
AIシステムの主な種類を目的別に比較
下表は、業務でよく検討されるタスクを比較したものです。「向く業務」は方式を検討する入口であり、導入すれば必ず効果が出るという意味ではありません。特に評価軸は、モデルの正解率だけではなく、現場で必要な結果や人の作業を含めて設計します。
| 方式・目的 | 入力データ | 出力 | 向く業務 | 評価軸の例 | 注意点 |
|---|---|---|---|---|---|
| 予測 | 売上・受注・在庫などの時系列と、季節や販促等の関連情報 | 将来の数値や確率 | 需要見通し、納期や故障の予兆、要員計画 | 予測誤差、期間別の偏り、予測を使った業務判断の妥当性 | 急な制度変更や供給制約は過去の傾向だけでは捉えにくい。予測期間と更新頻度を決める。 |
| 分類・判定 | 過去の案件・問い合わせ・検査結果など、正解ラベルのある記録 | カテゴリ、合否、リスク区分など | 問い合わせ振り分け、申請書確認の優先順位付け、検品補助 | 適合率・再現率、クラス別の誤り、見逃しと誤警告の業務コスト | ラベルの揺れや少数カテゴリに注意する。最終判定を自動化する前に誤り時の扱いを決める。 |
| 画像認識・OCR | 写真、カメラ映像、図面、帳票の画像 | 物体や領域、異常候補、文字列、位置情報 | 外観検査、部品の有無確認、帳票の読み取り、画像の仕分け | 対象ごとの検出率、誤検出、文字の読み取り正確さ、撮影条件別の品質 | 照明・角度・解像度や、現場での撮影ばらつきが結果に影響する。人の確認工程も設計する。 |
| 音声認識・言語解析 | 音声、会話記録、メール、問い合わせ文など | 文字起こし、話者や意図の分類、抽出項目 | 会議記録、電話内容の検索、問い合わせ分類、音声入力 | 文字誤り、固有名詞の認識率、分類精度、確認・修正にかかる時間 | 雑音、専門語、方言、話者の重なりに注意する。録音や個人情報の取り扱いを確認する。 |
| 推薦・ランキング | 利用者や案件の属性、閲覧・購入・選択履歴、候補情報 | 候補の順位、関連項目、提示理由 | 商品提案、類似案件や文書の提示、担当者と案件の組み合わせ | クリックや採用だけでなく、適合度、カバレッジ、偏り、業務上の成果 | 履歴が少ない新規利用者・新商品に弱くなりやすい。推薦の偏りと人による上書きを見る。 |
| 異常検知 | センサー値、取引ログ、システムログなど通常時の記録 | 異常スコア、逸脱した時刻や項目、確認候補 | 設備監視、入力ミス候補の発見、不正・障害の調査支援 | 異常の検出率、誤報の件数、発見までの時間、現場確認の負荷 | 異常の正解例が少ないことがある。スコアが高いことと原因が特定できたことは別。 |
| 最適化・計画 | 作業条件、制約、資源量、優先順位、守るべきルール | 配分、順序、予定、制約を満たす案 | 配送や勤務の割当、製造順序、在庫配分、作業計画 | 制約を守る割合、目的値、計画作成時間、変更への対応しやすさ | 現場ルールを制約として正確に表す必要がある。最適値だけでなく実行可能性を確認する。 |
| 生成AI | 指示文、参照文書、会話履歴、画像・音声など（方式による） | 文章、要約、回答案、コード、画像や音声など | 下書き、社内文書の検索補助、問い合わせ回答案、情報整理 | 正確さ、根拠との一致、抜けや誤り、修正量、安全性、応答時間 | 自然な文章でも事実とは限らない。参照元、権限、機密情報、確認責任を設計する。 |
同じ業務でも、入力の形や意思決定の流れによって候補は変わります。たとえば、帳票の文字を項目に取り込むならOCRと入力チェック、内容を要約するなら生成AI、過去の帳票から処理区分を振り分けるなら分類が候補になります。目的の異なる処理を一つの「AI機能」としてまとめず、どの工程にどの出力を置くかを分けて考えると、評価もしやすくなります。
予測・分類は「未来を見積もる」のか「区分を選ぶ」のか
予測は、過去の推移や関連する条件から、これから起きる数値や確率を見積もる方式です。販売数量や来月の問い合わせ件数を予測するなら、日付と対象をそろえた履歴に加え、季節、営業日、販促など結果に関係する情報を検討します。出力は一本の数値だけでなく、幅や確率で扱うこともできます。現場が知りたいのが「いくつになりそうか」か「不足する可能性があるか」で、表示や評価の形が変わります。
一方、分類は新しい記録を既定のグループに振り分けます。たとえば問い合わせを「請求」「操作」「不具合」に分けたり、画像から部品の有無を判定したりする用途です。学習用の記録には、どの分類が正しいかを示すラベルが必要になることが多く、過去データの分類基準が人や部署によって異なると、モデル以前に正解をそろえる作業が発生します。ラベルの根拠が記録されているかも確認しましょう。
どちらも「正解率」だけでは判断できません。予測では平均的な誤差に加えて、繁忙期や重要な商品で予測が大きく外れないかを調べます。分類では、誤って見逃す問題と誤って通知する問題の影響が異なります。設備の危険兆候を見逃すコストが高い場面と、担当者に警告が多く届きすぎると運用が止まる場面では、重視する指標や閾値は変わります。
画像・音声の認識は、現場の入力条件を先に確認する
画像認識は画像に写る対象や状態を見つけたり、カテゴリを付けたりします。物体検出は対象物の位置も含めて示し、画像分類は画像全体など決めた単位へラベルを付ける方法です。OCRは画像内の文字を読み取ります。いずれも写真や帳票のデータだけでなく、撮影角度、カメラ、照明、解像度、帳票の版、かすれや傾きといった条件の記録が評価に影響します。
画像を集める場合は、正しく撮影できた例だけでなく、実際の運用で起こるぼけや反射、隠れ、背景の違いも含めて確認します。作業者が撮影するなら、撮影位置をガイドした場合としない場合を分けて試すことも有効です。モデルが出すのは検査の代行結果なのか、人が見直す箇所の候補なのか、用途を明確にします。誤検出の修正や、確認対象の画像を呼び出す操作まで含めて作業時間を見てください。
音声認識では、音声から文字列を作る処理と、文字列から話題や意図を分類する処理を区別します。通話の内容を検索したいなら文字起こしが中心ですが、問い合わせの種類を振り分けたいならその後の分類まで必要です。話者の交代や専門用語、録音環境によって修正の手間が変わるため、平均的な音声だけでなく、実際に利用する窓口や現場でサンプルを確認します。音声の保存期間や、誰が記録を閲覧できるかも機能要件に含めます。
推薦と最適化は「選択肢を示す」と「制約の中で計画する」
推薦システムは、利用者や案件に合いそうな選択肢を探し、順位や関連候補として提示します。商品なら閲覧・購入履歴と商品情報、社内文書なら検索語や文書の内容、担当者割当ならスキルや予定など、目的によって必要なデータが異なります。候補を出すだけでなく、候補が妥当だったか、利用者が受け入れたか、似た候補ばかりに偏っていないかを見ます。少ない履歴しかない人や新しく追加された候補にも、別の提示方法を用意すると運用が安定しやすくなります。
最適化は、定義した条件を守りながら、目的関数をできるだけ良くする計画や割当を求めます。たとえば勤務計画なら、必要人数、資格、勤務時間、休み希望を制約として整理し、人員配置の公平さや残業の抑制を目標に置きます。制約を曖昧な文章のまま渡すだけでは計画に落とせません。現場で暗黙に守られている例外や、同じ優先度の要望がぶつかったときのルールを聞き取り、実行可能な条件として表します。
推薦は「候補を示して、人が選ぶ」流れに向き、最適化は「制約と目標を与えて、条件を満たす組み合わせを計算する」流れに向きます。ただし、実務では両者の境目にある課題もあります。たとえば、類似案件を提案して人が担当者を決めるなら推薦が中心ですが、資格や稼働時間を必須条件にした自動割当では最適化を組み合わせることがあります。現場で最終的に誰が何を決定するかを図にすると、方式の役割を切り分けられます。
生成AIは文章作成だけでなく、参照・確認の設計が要る
生成AIは、指示や参照情報をもとに文章、要約、回答案などのコンテンツを作ります。問い合わせへの返信案を作るなら、入力として質問文だけを渡すのか、商品仕様や社内手順も参照させるのかで、回答に期待できる範囲が違います。社内規程に沿う回答を作りたいのに、根拠資料を渡さずに一般的な生成AIだけを使うと、規程と異なる内容でも流暢に見える回答が出ることがあります。根拠となる文書を検索して生成時に与える構成を検討しても、検索結果が適切か、人が検証できるかは別途確認が必要です。
生成AIを候補にする際は、「文章を作りたい」という希望を、作業単位まで分けてみます。たとえば、会議の要約、定型メールの下書き、社内規程の検索、申請理由の要点抽出では、求める出力も間違いの許容度も異なります。要約なら重要事項の抜け、規程の検索なら回答と出典箇所の一致、メールの下書きなら修正にかかった時間や誤送信防止の仕組みを評価します。文の自然さだけを評価軸にすると、事実の正しさや根拠の不一致を見過ごします。
使う人が判断する工程を残す場合は、確認画面、引用元の表示、修正結果の記録、承認と送信の権限をあらかじめ決めます。顧客へ自動送信する、契約や審査の結論を自動で確定するなど、影響が大きい使い方では、誤りを発見・停止・訂正する流れも必要です。入力に含めてよい個人情報や機密情報、生成結果を保存する場所、外部サービスへ送られるデータの範囲は、利用する仕組みの条件を踏まえて確認します。AIの種類を選んで終わりにせず、利用者、運用責任者、更新担当者まで決めておきます。
データの用意や評価方法を具体化する段階では、AIシステム開発に必要なデータの整備・評価の基本もあわせて確認してください。方式を選ぶ前にデータの粒度、正解ラベルの有無、評価用データの分離を把握すると、PoC後に前提が崩れる事態を避けやすくなります。
解決したい課題から候補方式を絞る
技術一覧を見てから業務を当てはめるより、「今の作業で何が滞り、結果を誰が使うか」から始めるほうが選定しやすくなります。次の順で業務の事実を整理します。
- 困っている作業を具体化する。「問い合わせ対応を効率化したい」だけでなく、内容確認、担当振り分け、回答検索、文章作成、記録のどこに時間や手戻りがあるのかを分けます。
- 望む出力を決める。将来の数値なら予測、既定カテゴリなら分類、画像や音声から情報を読むなら認識、候補の順位なら推薦、条件を満たす予定なら最適化、文章案や要約なら生成が候補です。
- 入力可能なデータを棚卸しする。形式、件数、期間、欠損、更新頻度、正解ラベル、利用権限を確認します。必要なデータがない場合は、最初に収集や記録方法を整えることも選択肢です。
- 人とシステムの役割を分ける。誰がAIの出力を確認し、例外を処理し、結果を確定するのかを定義します。どこまで自動化するかは、誤った場合の影響と修正手段から決めます。
- 成功を測る基準を置く。モデルの指標と業務指標を分け、処理時間、確認件数、見逃し、再作業などの何が変われば実用に進めるか合意します。
候補が複数残った場合は、方式を一つに絞り込む前に、シンプルなルールや既存の検索機能も比較対象に加えます。過去の記録だけで明確な条件分岐ができる業務に、複雑なモデルを足すと、説明や保守の負担が増えることがあります。反対に、画像を人が見て転記しているなど、ルールでは扱いにくい入力を処理するなら、認識技術の検証が有力になります。
開発全体の工程や要件整理も知りたい場合は、AIシステム開発の導入・運用手順を参照してください。要望の整理、データ確認、方式検証、システム連携、運用後の見直しは一続きの計画として扱います。
PoCで複数方式を比べる手順
PoCは「AIが動いた」と示すデモではなく、業務の条件下で候補方式を比較し、次に進む判断材料を作る小規模な検証です。開始前に、比較する案と評価方法を決めておきます。
- 検証対象を一つの作業に区切る。対象部署、入力、出力、利用者、対象外の例外を決めます。「在庫管理をAI化する」では大きすぎるため、「特定商品の週次需要を予測して発注担当者の確認候補にする」のように限定します。
- 現在の基準値と方法を記録する。今の処理時間、判断手順、誤りや手戻り、使用している表やシステムを把握します。現行のルール、手作業、既製機能も基準案として残すと、AIを使う意味を比較できます。
- 同じ条件の評価データを作る。実運用で起こりうるデータを用い、学習や設定に使う情報と最終評価用の情報を分けます。例外、繁忙期、入力品質の違いも含め、匿名化や利用権限、持ち出し可否を確認します。
- 案ごとの評価指標を定義する。予測なら誤差と過大・過小の偏り、分類ならクラス別の見逃しと誤警告、認識なら誤読の種類、生成なら根拠との一致と人の修正量、最適化なら制約違反と計画の実行可能性を測ります。
- 同じデータで候補を並べる。異なるモデル、既製のAIサービス、ルールベースなどを比較するとき、入力条件と合否基準をそろえます。正解例だけではなく、境界例や誤りが起きると困るケースも確認します。
- 利用者の作業を含めて試す。結果を見て人が修正し、承認し、既存システムに登録するところまで試行します。モデル指標がよくても、確認画面が使いにくい、データ入力が増える、例外処理に手間がかかるなら、実業務での効果は限られます。
- 継続・見直し・中止を判断する。目標に届いたかだけでなく、データ更新、誤りの監視、問い合わせ対応、費用、担当者の役割を含めて、運用できるかを評価します。追加のデータ整備やルール修正が必要なら、次の検証条件を明示します。
PoCの比較表には、候補方式、必要データ、モデル指標、業務指標、確認者、例外の扱い、運用上の課題を並べると、技術者以外も判断しやすくなります。成功ラインを検証後に都合よく変えないために、試行前に「何が確認できたら実装へ進むか」「何が判明したら追加検証に戻るか」を関係者で合意してください。
AIシステムの方式選びで誤解しやすい例
「AIを使えば在庫数を自動で決められる」
需要を見積もる問題と、発注量を決める問題は関連しますが同じではありません。予測モデルが出すのは将来需要の見込みであり、発注量を決定するには、在庫、納期、発注単位、欠品と過剰在庫の扱いなどの条件が必要です。見込みを担当者に提示するだけなら予測が中心、制約を踏まえた発注案まで出すなら最適化や業務ルールを組み合わせる可能性があります。最終確定する人と、予測が外れた際の対応も決めましょう。
「チャットにしたいから生成AIを導入する」
問い合わせの多くが決まった選択肢や定型回答で処理できるなら、FAQ検索や選択式のフォームのほうが誤解なく運用できる場合があります。会話の揺れを理解して複数の資料から回答を組み立てる必要があるときは生成AIが候補になりますが、回答根拠を示す方法、答えられない場合の案内、人への引継ぎ、誤回答の監視を合わせて考えます。見た目が対話形式であることだけでAIの必要性を決めないようにします。
「帳票を読ませるなら生成AIだけでよい」
帳票から文字を読み、金額や日付を所定の項目へ取り込む課題は、OCRや文書認識、入力チェックが中心になることがあります。複数の帳票を要約して説明する工程では生成AIを追加できますが、文字の読み間違いがあると、その後の文章が自然でも値は誤ったままです。読み取り精度、項目ごとの検証、訂正方法を評価し、生成AIと認識処理の役割を分けてください。
「モデルの正解率が高ければ本番で使える」
評価データが実際の入力と違う、少数の重要ケースが集計値に埋もれる、確認者が処理しきれないなどの理由で、検証時と本番の結果が変わることがあります。モデル単体の精度に加えて、データの更新、利用者への表示、誤りを戻す手段、運用中の変化を確認してから適用範囲を広げます。高い数字を一つ示すだけでは、どの業務に安全に使えるか判断できません。
導入前に確認したいデータ・運用・責任
AIの方式を選んだ後は、その仕組みを支えるデータと業務の持ち方を決めます。記録を長く集めていることと、学習や評価に使えることは同義ではありません。入力値の定義が変わっていないか、欠損がどのように生まれるか、ラベルは誰が何を根拠に付けたかを確かめます。結果に個人や部署間の偏りが現れないか、利用目的に照らしてデータを使う権限があるかも確認します。
運用設計では、モデルの更新者、出力の確認者、誤りを受け付ける窓口、利用停止の判断者を定めます。処理量や入力傾向が変わると、導入時には問題がなかったモデルでも、現場に合わなくなることがあります。出力のログを残す範囲や保管期間を含め、どの状態を監視し、どの条件で再学習・再設定・停止を行うかを決めます。判断をAIに任せる割合が高いほど、利用者が結果を覆す手段や責任の所在を明確にする必要があります。
AI利用に伴う説明、リスク確認、関係者の役割は、プロジェクトの規模や利用場面に合わせて検討します。経済産業省のAI事業者ガイドライン第1.2版など、利用時点の公的な指針も参照し、組織の規程や契約、業界上の要件と突き合わせてください。ガイドラインを読んだだけで個別案件の適法性や安全性が確定するわけではありません。実際のデータ、利用者、判断の影響を踏まえて、必要な責任者や確認手順を定めます。
AI開発は、モデルを作る工程だけでは完結しません。どの課題を解くかを定め、データを確認し、試行結果を現場に合わせ、運用後に状況を監視する必要があります。候補方式を比較しても社内で判断しきれないときは、現行業務の整理、データの利用可否、システム連携、運用の責任分担を一緒に洗い出すと、必要な開発範囲が明確になります。
まとめ
AIシステムの種類は名前から選ぶのではなく、必要な出力、使える入力データ、業務で守る条件から選びます。数値を見積もるなら予測、区分を付けるなら分類、画像や音声から情報を読むなら認識、選択肢を順位付けするなら推薦、条件を満たす計画を作るなら最適化、文章や要約を作るなら生成AIが候補になります。複数の処理を組み合わせる場合は、工程ごとに役割と評価軸を切り分けましょう。
PoCでは、現行方法を基準に置き、実データに近い共通条件で方式を比較します。モデルの数値だけでなく、利用者の確認や修正、データ更新、例外対応、責任分担まで試して、実装に進むかを判断します。AIを使うことが目的になるのではなく、現場の課題に対して必要な仕組みを小さく確かめることが、選定の出発点です。
よくある質問
AIシステムは生成AIと同じですか？
同じではありません。生成AIは文章や画像などを作る方式の一つです。予測、分類、画像認識、音声認識、推薦、最適化など、業務上の目的に応じた多様なAIシステムがあります。
予測と分類はどう違いますか？
予測は将来の数値や確率を見積もるタスク、分類は記録をあらかじめ決めたカテゴリへ割り当てるタスクです。需要量の見込みは予測、問い合わせの種類分けは分類が代表例です。
手元にデータが少なくてもPoCはできますか？
できる場合はありますが、検証できる範囲はデータの種類や目的に左右されます。少量のサンプルで操作画面やデータ連携を確かめることはできても、実運用での精度や効果を評価するには不足することがあります。まずデータの内容、正解例、利用条件を確認し、何を確かめられるPoCかを明確にします。
PoCでは何方式を比較すべきですか？
一律の数はありません。業務目的に合う候補を選び、現行の手作業やルールベースも基準案として比較します。異なる方式を多く試すことより、同じ条件・評価指標で実務上の差が判断できる範囲に絞ることが大切です。
AIの精度だけで導入を決めてよいですか？
精度だけでは決められません。誤りの種類や影響、人の確認に必要な時間、データの更新、システム連携、費用、運用担当者も確認します。業務で必要な基準を事前に置き、運用まで含めて実現できるかを判断してください。
