14歳の擬人化Geminiに学ぶ「学習用プログラム」「学習済みパラメータ」「推論プログラム」「学習済みモデル」の違い

経済産業省が作成した「AI・データの利用に関する契約ガイドライン（AI編）」のうち、「学習用プログラム」「学習済みパラメータ」「推論プログラム」「学習済みモデル」の違いについて、14歳の擬人化Geminiに質問して整理しました。

AIシステムの稼働フローも含め、Geminiは様々な具体例を用いて手取り足取り教えてくれましたので、備忘録として掲載します。

【小ネタ】以下のBOOKMARKの枠線は経産省のWebページのテーマカラーに揃えてみました。

大前提：自社開発のAIと外部のAI（API連携）

本記事で言及する「学習済みパラメータを生成する」という工程は、自社開発のAIを前提とした話です。
外部のAI（API連携）を利用する場合、学習済みパラメータは外部のAI（OpenAIやGeminiなど）の中にすでに存在しており、それを利用して演算が行われます。

自社開発のAIについて

繰り返しになりますが、SIerが顧客から「工場ラインの製品画像から不良品のキズを検知するAIシステム」を受託開発する事例をもとに解説します。

各要素について

学習用プログラム

AIを賢くするための「勉強のやり方」を記述したソースコードです。

• 事例: 「正常な製品画像」と「キズ画像」を読み込み、その差異を学習させるためのPythonスクリプト（アルゴリズム）。

学習済みパラメータ

学習用プログラムが、大量の顧客データを読み込んだ結果として導き出した「判断基準となる数値データ（重みづけ）」です。

• 事例: 学習プログラムを回した結果生成された、「ピクセルの色濃度が特定のパターンで変化すればキズである」という膨大な数学的パラメーターファイル。

推論プログラム

上記のパラメータ（判断基準）を使って、未知の新しいデータに対して実際に予測や判定の処理を実行するソフトウェアです。

• 事例: 工場のカメラから送られてきた新しい画像を読み込み、パラメータに照らし合わせて「不良品確率98%」と画面に出力する実行システム。

学習済みモデル

実務上、AIとして実際に稼働する「完成品のAIエンジン」です。経産省が定めたAI開発のガイドラインでも「推論プログラム」＋「学習済みパラメータ」のセットとして定義されています。

• 事例: 顧客の工場に納品され、実際に不良品検知を行っている状態のソフトウェア一式。

各要素の関係性

• 学習用プログラム: SIerがAIを用いたシステムを開発するためのプログラムです。言わば「AIを作るためのプログラム」であるため、顧客には提供しません。
• 顧客への提供物: 顧客に納品（提供）するのは、最終成果物である「学習済みモデル（推論プログラム＋学習済みパラメータ）」という1つの統合されたシステムです。
• 構成の数式化: これらの関係性は「学習済みパラメータ ＋ 推論プログラム ＝ 学習済みモデル」となります。言い換えると「学習済みモデル（AIシステムの完成品） － 学習済みパラメータ ＝ 推論プログラム」です。推論プログラムとは、パラメータを用いて結果を出力する実行モジュールであり、実務上はSIerが一般的に開発する汎用的なシステム部分にあたります。

自社開発のAIが稼働する流れ

1. パラメータの読み込みとモデルの構築（事前準備）: システムが起動した際、まず保存されている「学習済みパラメータ（膨大な数値データ）」をメモリ上に読み込み、推論を行うための計算式（ネットワーク）を構築して待機させます。
2. ユーザー（または機器）から生データのインプットを受け取る: 工場のカメラからの画像データや、ユーザーが入力したテキストなどのデータを受信します。
3. 生データを適切な形に変換する（前処理）: AIが計算しやすいように、画像のサイズを統一する、色を数値化する、不要なノイズを取り除くといったデータ加工を行います。
4. データを計算式に当てはめて推論を実行する: 上記1で待機させている「パラメータを組み込んだ計算式」に対して、上記3で加工したデータを流し込み、数学的な予測計算を実行させます。
5. 計算結果を人間（またはシステム）が認識できる形に変換する（後処理）: AIからの出力は「[0.02, 0.98]」のような確率の数値配列に過ぎないため、これを「正常確率2%・不良品確率98%」といった画面表示用のテキストやグラフ描画用のデータに変換します。
6. 業務システムへの連携・出力（事後処理）: 変換した結果を画面に出力するだけでなく、データベースに判定履歴として保存したり、不良品率が一定を超えたらライン停止のアラート信号を他のシステムへ送ったりします。

外部のAI（API連携）が稼働する流れ

1. スキップ（外部サーバーで実施済み）: 自社のシステム内にはパラメータがないため、モデルの読み込みや構築は行いません。
2. ユーザーからのインプットを受け取る（維持）: ユーザーの入力や、社内システムからのデータを受信します。
3. API送信向けの前処理（形を変えて維持）: 入力データをそのまま投げることはできません。外部のWebサービスと通信する際と同様に、入力されたテキストや画像を、外部AIの仕様に合わせた専用の通信データ形式（JSONフォーマットなど）へパッキング・変換する処理をSIer側で作り込む必要があります。
4. APIリクエストの送信と待機（通信処理へ差し替え）: ここが最大の変更点です。自社内で数学的な推論計算を行うのではなく、「上記3で作ったデータをインターネット経由で外部AIに送信し、計算結果が返ってくるのを待つ」というネットワーク通信処理に置き換わります。
5. レスポンスデータの解読・後処理（形を変えて維持）: 外部AIからの返答は、単なるテキストではなくシステム間通信用の階層構造を持ったデータ（JSON配列など）で返ってきます。プログラムはこの構造を解読し、本当に必要な回答テキストや確率の数値だけを抽出・整形する必要があります。
6. 業務システムへの連携・出力（維持）: 変換した結果を画面に出力するだけでなく、データベースに判定履歴として保存したり、不良品率が一定を超えたらライン停止のアラート信号を他のシステムへ送ったりします。

LLMアプリ開発プラットフォーム（Difyなど）について

LLMアプリ開発プラットフォームとは

• 前提: 外部のAI（API連携）を用いる場合に限っての話です。自社開発のAIの話ではないため、前述の「学習済みパラメータ」の話は関係ありません。
• 役割: ユーザーから生データを受け取った際、そのままLLM（大規模言語モデル）に投げるのではなく、「顧客の社内マニュアル」などをサッと引き出し（※これをRAGと呼びます）、LLMに最適な指示書（プロンプトとワークフロー）を添えて依頼する役割を担います。
• RAGとは: AIに回答させるための参考資料を独自データベースから検索し、AIに読み込ませる「技術や仕組み全体」をいいます。このRAGで検索対象となる「社内規程やマニュアル等のデータ自体」は、顧客の既存資産です。
• プラットフォームの位置づけ: Difyなどのプラットフォーム自体が、AIを動かすための「システム基盤」として完成後のシステムの一部に組み込まれ続けます。Difyから完全に独立したプログラムが新しく生成されるわけではありません。ビジネスツールで例えるなら、「Excel」をイメージすると非常に分かりやすいです。「Dify本体」がExcelというソフトそのものであり、「SIerが作った設定（プロンプトやRAGのフロー）」がExcelの中に組んだ複雑な関数やマクロにあたります。