この記事で分かること
- AIシステムをモデル単体ではなく、データ処理や業務画面を含む仕組みとして見る方法
- 入力データの前処理、特徴量、埋め込みがそれぞれ何をしているか
- 従来型機械学習の学習と、生成AIの事前学習・追加学習の違い
- 学習済みモデルを使う推論、RAGの検索、出力後の監視の役割
- 実務でAIの結果を確認し、改善につなげるときの考え方
AIシステムはモデルだけでなく一連の処理でできている
AIモデルとは、データから規則や関係を学び、入力に対して予測や生成を行う計算部分です。一方、AIシステムは、そのモデルを実際の業務で使うためのデータ接続、入力画面、前処理、モデルを呼び出す処理、結果の確認や保存までを含む全体です。モデルの性能がよくても、必要なデータを渡せない、結果を確認できない、エラー時に止まったままになる、といった状態では業務上の役には立ちません。
基本的な流れは、入力データ → 前処理・特徴量化 → 学習済みモデルによる推論 → 出力 → 評価・監視・改善です。「学習」はモデルの振る舞いを作る準備工程、「推論」は完成したモデルを使って新しい入力を処理する工程です。この2つは目的が異なり、多くの業務システムでは問い合わせのたびにモデルを学習し直すわけではありません。
AIシステムの全体像をさらに広くつかみたい場合は、AIシステムの種類や導入効果を整理した解説も参考になります。ここでは、モデル内部の数式を追うのではなく、業務の入力がどこを通り、どう結果になるかに焦点を当てます。
モデルの前後には、業務につなぐ仕組みがある
利用者が問い合わせやファイルを送ると、アプリケーションは入力形式や権限を確認し、必要なデータを取得します。その後、AIに渡す形式へ変換してモデルを呼び出し、モデルの出力を業務で扱いやすい形に整えます。例えば、問い合わせ分類なら「返品」「請求」「その他」といったラベルを画面に返し、担当者へ振り分ける処理が続きます。文章生成なら、回答案を表示する前に引用元や禁止語を確認したり、担当者の承認を求めたりする場合があります。
このようにモデルの入出力を支える部分には、データベース、ファイル保管場所、API、認証、ログ、管理画面などが含まれます。どの部品を使うかは用途や既存システムによって変わります。大切なのは、「AIを入れること」だけを目的にせず、今の業務のどの判断や作業を支援するのかを定めることです。モデルからの応答を、そのまま確定処理として採用するか、人が確認してから使うかも、扱う情報や失敗時の影響を踏まえて決めます。
入力データを整えると、モデルが扱える情報になる
AIの出発点は、予測や回答につながるデータです。表計算の行、業務システムの履歴、画像、音声、文書、操作ログなど、対象に応じて入力の種類は異なります。集めれば十分というわけではありません。目的に関係する情報が含まれているか、値の意味や記録方法がそろっているか、欠損や重複、誤入力がないかを確認します。過去データに本番では使えない情報が混ざっていると、学習時は当たるように見えても、実際には同じ判断ができないことがあります。
たとえば、問い合わせの対応時間を予測するなら、過去の問い合わせ本文、問い合わせ時点で分かるカテゴリや窓口、対応にかかった時間などを用意できます。しかし、対応後にしか分からない「最終対応結果」を入力にも含めてしまうと、予測時点ではその値を知ることができません。学習データでしか得られない情報に頼る状態を避け、運用時点で本当に取得できる項目を使うことが重要です。
問い合わせ履歴は、行ごとの「例」としてAIに渡される
表形式の機械学習では、1行を1件の例、列を入力項目や正解ラベルとして扱うことがよくあります。問い合わせ分類なら、本文や受付時刻、問い合わせ経路が入力項目になり、担当者が付けたカテゴリが正解ラベルになります。ただし、生の表をどのモデルにもそのまま渡せるとは限りません。空欄の扱い、日時の表現、単位、表記ゆれ、個人情報の取り扱いを含めて、データを整える必要があります。
例えば「請求書が届かない」「請求書未着」「請求書を受け取っていない」という表現が同じ問題を表すなら、カテゴリ名や正解データの付け方を見直す余地があります。反対に、異なる意味の問い合わせを無理に一つの分類へまとめれば、モデルは境界を学びにくくなります。データ整備では、単に空欄を埋めるだけでなく、「業務上何を同じとみなすか」を現場と決める作業も必要です。
前処理は、運用時にも同じ手順で行う
前処理とは、AIモデルが扱えるように入力値をそろえたり変換したりする作業です。数値なら単位の統一や範囲の調整、カテゴリならコード化、文章なら不要な形式の整理、画像ならサイズや色の形式の調整などがあります。どの処理が必要かは、モデルの種類とデータにより異なります。高性能な深層学習モデルでは、特徴の抽出をモデル自身が多く担う場合もあります。それでも、形式の確認や欠損への対応など、システム側で必要になる前処理は残ります。
学習用データだけに適用した変換を、本番入力にも再現できるようにしておくことが大切です。例えば学習時に「平均値で欠損を補う」「数値を一定範囲に正規化する」と決めたら、推論時もその学習用データで決めたルールを使います。本番入力だけ別の基準で変換すると、モデルにとって数値の意味が変わり、期待した結果にならない可能性があります。学習環境と運用環境の処理を対応させる考え方は、学習・推論のずれを防ぐ基本です。
また、モデルの評価では、学習用・検証用・テスト用のデータを分ける方法があります。学習用データでモデルのパラメータを調整し、検証用データで設定や方式を選び、最後にテスト用データで未知の例への性能を確認します。同じテストデータを見ながら何度も改良すると、そのデータに合わせすぎて、実際の未知データでの性能を正しく測れなくなることがあります。データ分割の割合は用途やデータ量で決まり、一律の正解があるわけではありません。
AI開発で使うデータの集め方や整備、評価設計を確認したい場合は、AIシステム開発に必要なデータの整備と評価の基本もあわせてご覧ください。
特徴量と埋め込みは、情報をモデル向けの数値表現にする
多くの機械学習モデルは、入力された情報を数値として処理します。そこで、元の業務データからモデルに渡す項目を選び、数値へ変換します。この処理後の入力値を特徴量と呼び、1件分の特徴量を並べたものを特徴ベクトルと呼ぶことがあります。たとえば、納期遅延の予測では、注文数、在庫量、曜日、商品カテゴリなどを特徴量として表現できます。元データから何を特徴として作るかを人が設計する作業は、特徴量設計や特徴量エンジニアリングと呼ばれます。
「数字に変換する」といっても、文字を適当に数字へ置き換えればよいわけではありません。商品カテゴリに1、2、3という番号を振るだけでは、その番号の大小に意味があるとモデルが解釈することがあります。カテゴリであれば、用途に合ったコード化を行います。数値の桁がばらばらなら正規化を使うこともあります。こうした変換は、モデルがデータ中の関係を学びやすくするための表現づくりです。
埋め込みは、意味や関係を数値ベクトルで表す方法
埋め込み（embedding）は、文章や画像などを多次元の数値ベクトルへ写した表現です。目的に応じて学習された埋め込みモデルを使うと、似た意味や用途の情報がベクトル空間で近い位置になるよう表現できる場合があります。たとえば、質問文と社内文書を同じ方式でベクトル化し、質問と意味的に近い文書を検索する、といった使い方があります。
ここで注意したいのは、「埋め込み」が一種類の処理を意味するわけではない点です。生成AIの内部では、文章をトークンに分け、そのトークンIDをモデルが処理する数値表現へ変換します。一方、検索や分類で使う埋め込みモデルは、文章や画像を比較・検索しやすいベクトルとして出力する目的で使います。内部のトークン表現と、検索用に外から利用する埋め込みベクトルは関連する用語ですが、使う目的や形式は同じとは限りません。
学習ではモデルのパラメータを調整し、推論ではそのモデルを使う
機械学習の「学習」は、用意した例からモデルのパラメータを調整する工程です。教師あり学習なら、入力と正解ラベルを用意します。例えば、過去の問い合わせ内容と「請求」「操作方法」「返品」などの分類結果をモデルに見せ、予測と正解の違いを損失として計算します。学習アルゴリズムは、その損失を小さくするようにパラメータを繰り返し更新します。学習が終わると、モデルの重みなどを保存し、評価を経て運用環境へ配置します。
モデルの学習中には、訓練データに対する誤差だけでなく、未知の入力にどれだけ対応できそうかを確認します。訓練データに過度に合わせすぎると、記憶した例では正しく見えても、新しい例への予測が悪くなることがあります。検証やテストは、実業務での使いやすさや誤判定の影響を含めてモデルを判断するためのものです。評価指標も正解率だけとは限らず、見逃しと誤検知のコスト、処理時間、利用者が修正する割合など、目的に合うものを選びます。
推論は、学習済みモデルで新しい入力を処理する工程
推論（inference）では、運用環境で届いた新しいデータを学習済みモデルに渡し、分類、予測、要約、文章生成などの出力を得ます。多くの一般的な構成では、推論時にパラメータを更新せず、学習済みのモデルを使います。利用者が問い合わせを送るたびにモデルの重みを再学習させることとは別の処理です。継続学習やオンライン学習のように運用中にモデルを更新する設計もありますが、それは更新条件、データ品質、評価や切り戻しを含めて明示的に設計する仕組みです。
分類モデルの出力が「請求0.72、操作方法0.21、その他0.07」なら、0.72はそのモデルや設定に基づくスコアです。必ずしも「請求である確率が正確に72％」とそのまま読める値ではありません。必要に応じて確率の校正を行い、どの値以上なら自動処理するかのしきい値を決めます。誤分類の影響が大きい業務なら、迷った結果を人へ回すルールや、AIが回答できない場合の代替手段を用意します。
つまり学習と推論の違いは、モデルを作る処理か、作られたモデルで入力を処理する処理かです。モデルの更新が必要になった場合は、新しいデータを点検し、再学習や追加学習を行い、改めて評価したうえで新しいモデル版を配備するのが基本です。運用中のモデルをいつ、どの条件で更新するかは、システムの目的やデータの変化に応じて決めます。
従来型の機械学習と生成AIでは、得意な出力と準備が違う
従来型の機械学習は、決められた形式の入力から、クラス名、数値、順位などを予測する用途で多く使われます。例えば、画像に写った製品の種類を分類する、取引が不正かどうかを判定する、需要数を予測するといった課題です。学習データには、予測したい結果の正解がある場合が多く、特徴量設計と評価指標が重要になります。ただし、機械学習全体が必ず教師ありとは限らず、正解ラベルを使わない学習や、報酬を基に行動を改善する方法もあります。
生成AIは、文章、画像、音声、コードなど、新しいコンテンツを出力するモデルの総称として使われます。大規模言語モデル（LLM）の一例では、文章をトークンという単位に分割し、前後の文脈をもとに次に続くトークンを予測するよう事前学習します。その後、指示に従う応答をさせるための追加学習や調整を行う場合があります。モデルが文章を生成するときは、入力文脈と、それまでに生成したトークンを使って次のトークンを順番に選び、出力を組み立てます。
したがって、生成AIでも「学習」と「推論」は別です。事前学習や追加学習はモデルの重みを調整する工程であり、利用者のプロンプトに返答を作るのは推論です。入力文に例や条件を添えて回答を誘導する方法は、推論時の文脈づくりです。指示文を与えただけでモデルの重みが必ず更新されるわけではありません。
追加学習、プロンプト、RAGは、別々の調整手段
自社の用途に合わせる手段はいくつかあり、同じ「AIに情報を覚えさせる方法」とひとまとめにすると誤解につながります。追加学習（ファインチューニング）は、事前学習済みモデルに、目的に合った例を使ってさらに学習させ、モデルのパラメータを調整する方法です。出力の形式や特定作業の振る舞いをそろえる用途などで検討されます。使うデータや学習方法によって費用、準備、効果は異なります。
プロンプト設計は、モデルに渡す指示、質問、例、制約などを工夫する方法です。モデル自体を学習し直す必要はありません。RAG（検索拡張生成）は、回答のたびに外部の文書やデータを検索し、見つかった情報をモデルへ文脈として渡して生成させる構成です。一般的な業務向けRAGでは、質問時に検索するための文書インデックスを先に作りますが、検索結果を使う回答処理は推論時に行います。RAGを設けたことだけで、基盤モデルが追加学習されたり、検索文書がモデルの重みに書き込まれたりするわけではありません。
この3つは置き換え関係とは限らず、プロンプトとRAGを組み合わせたり、追加学習と検索を併用したりすることもあります。最新の規程や社内文書を根拠に回答したいなら、まず文書の更新頻度、アクセス権、検索品質を確認します。回答の口調や定型フォーマットを安定させたいなら、プロンプトや追加学習のどちらが適切か、評価用データを用いて比較します。方式の名前から期待を決めるのではなく、業務上の目的と検証結果から選ぶことが大切です。
それぞれの方式の位置づけや注意点を比べる場合は、生成AIシステムと従来型AIの違いをまとめた解説も役立ちます。
RAGでは、検索が推論の前に入り、回答の材料を加える
RAGは、生成AIが学習時点の知識だけに頼らず、外部の情報を参照して回答を作るための代表的な構成です。社内規程や製品マニュアルのように、内容を後から更新したい情報がある場合、文書を検索可能な状態にし、質問に関係する箇所を取り出してモデルに渡します。モデルが回答を生成するときに、その資料を「参照すべき文脈」として使えるようにする考え方です。
文書の登録と質問への回答は、二つのタイミングに分かれる
文書の準備方法は、採用する検索方式によって変わります。キーワード検索は語句の一致を使い、ベクトル検索は意味の近さを使います。両方の候補を組み合わせるハイブリッド検索もあります。ベクトル検索を使う構成では、文書からテキストを抽出し、見出しや段落を考慮して検索単位に分割したうえで、各部分を埋め込みベクトルに変換し、本文や文書IDなどのメタデータとともに検索用のインデックスへ登録します。キーワード検索では語句やフィールドを検索できるよう索引を作るなど、方式に応じた準備が必要です。文書更新時は対応する索引へ変更を反映します。登録後は文字抽出の失敗、分割の仕方、古い版の混在などを確認します。
質問を受けた後の推論では、利用者の質問も検索向けの表現に変換し、質問と関連する可能性が高い文書部分を検索します。必要なら、文書のアクセス権で候補を絞ったり、関連度の再評価を行ったりします。その候補と質問を一緒に言語モデルへ渡し、回答を生成します。大まかな流れは、質問 → 検索 → 関連文書を選ぶ → 質問と文書をモデルに渡す → 回答です。
検索の正しさと、生成文の確かさを別々に見る
RAGを導入しても、回答が自動的に正確になるわけではありません。質問に合った文書を取得できない、古い文書を優先してしまう、必要な段落が分割で欠ける、利用者に閲覧権限のない情報が検索候補に入る、といった問題が起こり得ます。さらに、関連文書を渡しても、モデルが内容を誤って要約したり、文書にない説明を付け足したりする可能性があります。
そのため、RAGの評価は一つの正解率だけで済ませず、検索で必要な資料が上位に出たか、回答が資料に沿っているか、引用元を正しく示せたか、権限のない情報を返していないかなどを確認します。回答がどの文書や段落に基づいたかを利用者が確かめられるよう、出典情報を画面に表示することも有効です。重要な判断を完全自動にしない、回答できない場合は保留する、担当者へつなぐといった制御も設計します。
RAGにおける文書検索と文章生成の組み合わせは、学術研究でも検索部と生成部を組み合わせた構成として整理されています。ただし、研究論文で評価された仕組みと、特定の会社の業務システムが同じ性能を持つことは別問題です。文書の種類、質問の傾向、検索方式、モデル、評価データによって結果は変わるため、自社のデータで確かめます。
出力は、業務で使える形に整えて初めて価値になる
モデルの出力を受け取ったら、形式、値の範囲、必須項目の有無、危険な内容が含まれていないかなどを確認します。分類結果であれば、ラベルを担当部署や既存の業務コードへ変換し、確信度の低いものは確認待ちにする方法があります。文章生成であれば、文字数や書式を整えたり、参照資料を併記したり、個人情報や機密情報の取り扱いを見直したりします。モデルにJSONなどの構造化出力を求めても、受け取った内容の形式検証はシステム側で行う必要があります。
人が関与する場所は、失敗の影響に応じて決めます。社内の下書き作成なら、担当者が確認して修正した後に送信できるでしょう。請求金額、契約条件、採用可否など、間違った自動判断が大きな影響を持つ仕事では、予測値だけで確定させず、責任者の確認や既存ルールとの照合を組み込むことが重要です。AIに任せる範囲、AIが判断できないときの動作、修正責任を持つ人を事前に定めておきます。
監視とフィードバックは、すぐに再学習することとは違う
AIシステムは公開して終わりではありません。入力データの形式が変わったり、業務のルールや利用者の行動が変わったりすると、以前のテストで良かったモデルでも本番で期待どおりに働かなくなることがあります。運用では、入力エラーの件数、応答時間、処理の失敗、モデルやデータの版、予測結果の分布、担当者の修正率などを監視します。正解データが後から分かる業務なら、一定期間後に予測結果と実際の結果を照合し、精度の変化を評価できます。
利用者の「この回答は誤り」「この分類でよい」といった反応は、改善のヒントになります。ただし、そのフィードバックが直ちにモデルの学習へ反映されるとは限りません。人が誤りを確認してラベルを確定し、個人情報や不適切なデータを除き、代表性や偏りを確認してから、評価データや追加学習データとして使うのが安全です。システムログを集めるだけで品質改善が進むのではなく、誰がどの基準で確認し、どのリリースで反映するかまで運用手順に含めます。
改善方法も再学習だけではありません。入力フォームを分かりやすくする、前処理の不具合を直す、検索対象の文書を更新する、判断のしきい値を調整する、担当者への引き継ぎ条件を変えるなど、モデルの外側を改善した方がよい場合があります。新しいモデルを導入するなら、旧モデルとの比較、限定ユーザーでの確認、問題時の切り戻しを計画します。AIシステムの性能とは、モデル単体の評価だけでなく、業務での成果、安定性、利用者の確認負担を含めて見るものです。
運用で確認したい項目を、モデル・データ・業務に分ける
監視項目を整理するときは、モデル、データ、システム、業務結果を分けて考えると原因を追いやすくなります。モデル側では、正解データと比較した誤りやスコアの変化を確認します。データ側では、必須項目の欠損、形式の変更、入力傾向の変化を見ます。システム側では、応答時間、タイムアウト、APIエラー、検索の失敗を記録します。業務側では、処理時間の短縮、差し戻し、担当者の修正、利用継続など、導入目的に合った結果を追います。
予測の正解がすぐに得られない場合は、品質の評価に人手の確認が必要なことがあります。特に文章生成では、文法的に自然な回答でも、根拠がない、最新のルールに反している、業務上の質問に答えていない場合があります。少数の代表的な質問を定期的に再評価する仕組みや、利用者からの訂正をレビューする流れを持つと、変化を把握しやすくなります。監視のために集めるログは、目的と保存期間を決め、必要以上の個人情報や機密情報を記録しないようにします。
導入前に、AIの仕組みを業務要件へ結び付ける
AIシステムの工程を知ると、「データを準備し、モデルを学習して、使う」という大枠が見えます。しかし、すべてのAI導入で自社データを使って基盤モデルをゼロから学習するわけではありません。既存モデルをAPIで利用する、既存の機械学習モデルに業務データで学習させる、検索で文書を参照する、ルールベースの処理と組み合わせるなど、目的に応じた選択肢があります。必要なデータ、更新頻度、求める回答の根拠、許容できる間違い、運用できる担当者を確認して、方式を決めます。
最初に決めたいのは、AIを使うことで改善したい業務上の結果です。「AIを導入する」ではなく、「問い合わせの一次分類にかかる時間を減らす」「類似文書を探す時間を短縮する」のように、対象となる作業と現状を具体化します。そのうえで、入力データが業務内で利用できるか、期待する出力をどう評価するか、誤りを誰が確認するか、既存システムとどのように接続するかを整理します。
学習や推論を単独の技術作業と考えず、入力から監視までを含む仕組みとして設計すれば、必要な費用や運用負担、リスクも見通しやすくなります。構想段階でデータや要件の不足が見つかった場合は、いきなり大規模な開発へ進まず、目的と実現方法を段階的に整理する方法があります。
AIの活用範囲や実装方法を具体化したい場合は、AI開発の相談窓口をご確認ください。既存システムとの接続や、まず何を確認すべきか整理したい場合は、開発前診断・ロードマップも利用できます。
AIシステムの仕組みに関するよくある質問
AIの「学習」と「推論」は何が違いますか？
学習は、訓練データを使ってモデルのパラメータを調整し、モデルを作る工程です。推論は、学習済みモデルへ新しい入力を渡し、分類や予測、生成などの結果を得る工程です。一般的な運用構成では、問い合わせが届くたびに重みを学習し直すわけではありません。
生成AIに質問を入力すると、そのたびにAIは賢くなりますか？
通常は、質問と回答が発生しただけで、その場でモデルのパラメータが更新されるわけではありません。質問文は推論時の入力文脈として使われます。利用記録を後から確認し、品質やデータの扱いを点検したうえで、追加学習などに使う仕組みを別途設計することはあります。
RAGを導入すれば、社内文書をAIが完全に理解できますか？
いいえ。RAGは質問に関係する可能性のある文書を検索し、その情報を生成時の文脈として渡す仕組みです。文書の抽出や分割、検索、アクセス制御、回答の生成にそれぞれ誤りが起こる可能性があります。自社の質問と文書を使い、検索結果と回答の両方を評価する必要があります。
生成AIを使うなら、自社データを使った追加学習は必須ですか？
必須ではありません。指示文を工夫して使う、外部文書を検索するRAGを構成する、追加学習でモデルの振る舞いを調整するなど、複数の方法があります。扱う情報の更新頻度や、求める出力、利用するデータの条件を踏まえて比較します。
AIの出力は、そのまま業務で使ってよいですか？
出力を自動採用できるかは、用途と誤りの影響で決まります。影響が小さい作業では結果を自動利用できる場合がありますが、重要な判断では担当者の確認、しきい値、根拠の表示、保留や差し戻しなどを組み合わせます。導入前に、誤った場合の対応と責任範囲を決めてください。
まとめ：入力・モデル・運用をつないで考える
AIシステムは、データを集めて整える工程、モデルを学習・選定する工程、学習済みモデルを使う推論工程、出力を業務へ返す工程、稼働後の監視と改善で成り立ちます。従来型の機械学習では、業務データから分類や数値予測を行う構成が多く、生成AIでは、事前学習済みモデルが入力文脈をもとに新しい文章などを生成します。RAGは、質問への回答時に外部文書を検索し、生成AIへ文脈として渡す仕組みであり、検索用データの登録とモデルの学習は別の処理です。
最初に整理するのは、解決したい業務、使える入力データ、求める出力、失敗時の影響、運用後の確認方法です。これらを一つの流れとして設計すると、AIが担当する部分と、人や既存システムが支える部分を切り分けやすくなります。
