5章生成AI・LLMと機械学習のしくみ

この章では、生成AIがどのような技術の組み合わせで動いているかを学びます。数式を暗記することよりも、仕組みを知って「何が保証されず、どこを評価すべきか」を理解することが目的です。

この章の対象者

LLM、RAG、Transformerなどの用語を理解したい方
生成AIの得意・不得意を技術的に説明したい方
AI導入や開発の判断に必要な基礎を身に付けたい方

この章でできるようになること

機械学習、深層学習、LLM、生成AIの関係を説明できる。
トークン、確率的生成、Transformer、コンテキストの役割を説明できる。
RAGとファインチューニングの違いを説明できる。
技術的な仕組みと、正確性・安全性の保証を区別できる。

5-1. 機械学習からLLMまで

概念	役割	関係
AI	知的作業を支援する技術群の総称	最も広い概念
機械学習（ML）	データからパターンを推定する方法	AIの一部
深層学習（DL）	多層ニューラルネットワークを使う機械学習	MLの一部
大規模言語モデル（LLM）	大量の言語データで学習し、文章等を扱うモデル	多くはDLを用いる
生成AI	文章・画像・音声・コードなどを生成するAI	LLMを含むが、LLMだけではない

LLMは、入力されたトークン列に続きやすいトークンを確率的に選び、出力を生成します。この仕組みは自然な文章を作る一方、事実性や一貫性を自動的に保証しません。【E1】

5-2. Transformerとコンテキスト

Transformerは、入力内の要素同士の関係をAttention（注意機構）で扱うアーキテクチャです。現代のLLMの主要な基盤の一つですが、すべての生成AIが同じ構造ではありません。【E2】

図表案（Mermaid記法）

flowchart LR
  A[入力文書・質問] --> B[トークン化]
  B --> C[Transformerによる関係の計算]
  C --> D[次トークンの確率分布]
  D --> E[トークンを選択]
  E --> F[出力]

用語	技術的な意味	利用上の意味
トークン	モデルが処理する文字列の分割単位	料金・入力上限・出力上限に影響する【E5】
コンテキスト	生成時に参照する入力情報全体	長い会話や資料では重要情報を整理して渡す【E5】
コンテキストウィンドウ	一度に参照できるトークン量の上限	上限内でも理解・正確性は保証されない【E5】
Temperature	次トークン選択の多様性に関わる設定	低くしても事実性は保証されない

トークンと料金：最初に押さえること

お金に関する重要事項
APIを使う場合は、送った文章だけでなく、受け取った文章や会話履歴なども利用量に含まれ得ます。契約前・大量処理前には、必ず利用するサービス・モデルの公式料金表と利用量画面を確認してください。【E5】【E6】

トークンは、文字数や単語数そのものではありません。モデルが使う「トークナイザー」が文章を分割した単位であり、空白、記号、単語の一部なども数えられます。分割方法はモデルやエンコーディングで異なるため、「日本語○文字で必ず○トークン」のような固定換算はできません。正確な数は、利用するモデルに対応した公式のカウント手段で確認します。【E5】

初心者向けの目安
英語では、1トークンはおおよそ4文字、または0.75語が目安とされます。ただし、この目安を日本語、記号、コードへそのまま当てはめることはできません。正確な数は、対象モデルの公式トークナイザーまたは利用量情報で確認します。【E5】

何が利用量に含まれるか

区分	代表的に含まれるもの	利用時の注意
入力トークン	質問、指示、会話履歴、添付資料から渡した本文、RAGで検索して渡す文章、ツール定義・ツール結果など	長い資料や会話をそのまま繰り返し送ると、利用量が増えやすい【E5】【E6】
出力トークン	AIが生成した回答、要約、コード、表など	長い回答を求めるほど増えやすい。必要な長さ・形式を先に指定する【E5】【E6】
キャッシュ・追加機能	一部サービスのキャッシュ利用、推論用トークン、検索・実行などの追加機能	通常の入力・出力とは別の単価や追加料金がある場合がある。機能別の料金表を確認する【E5】【E6】

サービスによっては、1回の処理で参照できるトークン量に「入力と出力を合わせた」上限があります。長い資料を渡すほど、回答のために残る余地が小さくなったり、上限超過で受け付けられなかったりすることがあります。上限内でも、重要な条件を正しく扱えることや回答の正確性は保証されません。【E5】

API料金の見方

APIの従量課金では、入力と出力で単価が分かれていることが一般的です。概算は、次のように考えます。料金表の単位は「100万トークン」などサービスごとに異なるため、単位をそろえて計算します。【E6】

概算額 ＝ (入力トークン数 ÷ 入力単価の課金単位 × 入力単価)
       ＋ (出力トークン数 ÷ 出力単価の課金単位 × 出力単価)
       ＋ キャッシュ・検索・実行などの追加料金（ある場合）

たとえば、入力が20,000トークン、出力が3,000トークンだった場合は、それぞれを当該モデルの入力単価・出力単価に掛けて合計します。ここでは固定の金額を示しません。モデル、地域、通貨、キャッシュ、ツール、契約条件、料金改定によって実額が変わるためです。【E6】【E7】

Web画面で使う定額・席数課金のプランと、APIのトークン従量課金は、同じサービス名でも別の料金体系である場合があります。「チャット画面を使っているから、入力した文字数がそのままAPI料金になる」とは限りません。自分が使う入口（Web画面、API、組織契約、代理店契約）を確認し、その契約の公式料金・上限・追加機能の条件を確認します。【E7】

予算超過を防ぐ5つの手順

小さく試す：代表的な1件を実行し、実際の入力・出力トークン数と費用を記録する。【E5】【E6】
件数を掛けて見積もる：1件あたりの実績に予定件数を掛け、再試行・長文回答の余裕も加える。
入力を必要十分にする：目的に無関係な会話履歴や資料を毎回渡さず、必要な部分を選ぶ。長文は分割・要約・検索結果の絞り込みを検討する。【E5】
出力を設計する：「箇条書き5点」「300字以内」のように、必要な回答量を指定する。ただし、重要な確認を省略して費用だけを下げない。
大量処理は上限を決める：利用量の監視、予算アラート、1日・1ジョブあたりの上限を設定し、検索・ツール・添付ファイルを使う処理は別途試算する。【E5】【E6】

確認の原則
料金の例や換算式は見積もりの補助です。請求額の保証ではありません。契約・発注・大量実行の直前に、対象モデルと機能の公式料金表、利用規約、利用量画面を確認します。【E6】【E7】

5-3. ハルシネーションが起こりやすい理由

モデルは、入力に合う可能性が高い表現を生成します。しかし、モデル内部のパラメータに保存されたパターンは、出典を持つデータベースや真偽判定器ではありません。そのため、実在しない出典、古い情報、前後で矛盾する内容を出すことがあります。【E1】

要因	例	対策の方向
知識の古さ	制度・料金・人事が古い	公式資料・検索結果を確認する
質問の曖昧さ	前提が不足している	条件・用語・対象時点を明示する
参照資料の不足	社内文書を知らない	RAGなどで根拠文書を与える
長い文脈	重要条件が埋もれる	要点を整理し、段階に分ける
出力の確率性	同じ質問でも表現が変わる	重要な用途ではテスト・記録を行う

5-4. RAGとファインチューニング

RAG（Retrieval-Augmented Generation）は、質問に関連する外部文書を検索し、その文書をコンテキストとして与えて回答を生成する構成です。更新しやすい文書を参照させたり、回答の根拠を示したりするために用いられます。【E3】

方法	何を変えるか	向いている場面	注意点
プロンプト	その場の指示・例	表現、形式、単発の作業	長期的な知識更新には向かない
RAG	参照する外部文書	最新の規程、社内FAQ、根拠提示	検索漏れ・誤読・権限漏れに注意
ファインチューニング	モデルのパラメータ	特定形式、専門的な出力傾向	データ品質、コスト、評価が必要

Markdownで構造化したプロンプト例

# 公開済みイベント案内の整形

## 目的
支給された案内文を、親しみやすい表現へ整える。

## 入力資料
下の「原文」だけを根拠にする。新しい事実は追加しない。

## 条件
- 日時・場所・参加費は原文どおりに残す
- 不明な項目は推測せず「要確認」と示す

## 出力形式
見出し1つ、本文、持ち物の箇条書き。

この例で変えているのは、その場の表現と出力形式です。最新の規程や社内文書を正しく答えさせるには、構造化プロンプトだけでなく、適切な参照文書・検索・検証が必要です。【E3】

重要
RAGは誤情報を減らすことを期待できても、検索された資料が正しいこと、モデルが正しく読めること、引用が対応することを保証しません。検索・回答・引用をそれぞれ評価します。【E1】【E3】

5-5. ミニ演習：技術選定を説明する

次の場面で、プロンプト、RAG、ファインチューニングのどれを検討するか考えます。

毎週変わる社内イベントの案内文を整えたい。
決まった帳票形式で、公開済み文章を変換したい。
社内規程を根拠付きで回答する仕組みを作りたい。

振り返り

何を最新に保つ必要があるか。
誰が参照文書を更新・承認するか。
正確性をどのテストで評価するか。
どの方法でも人の確認が必要な場面はどこか。

まとめ

生成AIは、機械学習・深層学習・LLMなどの技術を含む広い仕組みである。
LLMはトークンを確率的に生成するため、自然な文章でも正確性は保証されない。
トークンは文字数と固定対応せず、APIでは入力・出力・追加機能の利用量が費用と上限に関わる。実額は公式料金表で確認する。【E5】【E6】
RAGは外部文書を参照させる構成、ファインチューニングはモデルを追加学習する方法である。
技術を選ぶときは、目的、データ、更新頻度、評価、権限、安全性を一緒に考える。

次の講座

次は 6章「組織へのAI導入と業務活用」 で、組織にAIを導入する際のルール、評価、運用、監査を学びます。

出典・エビデンス

本文の対象	根拠資料	確認した内容
生成AIの誤情報・信頼性・評価	【E1】	confabulation等のリスク、信頼できるAIの特性、リスク管理
Transformerの基本構造	【E2】	Attentionに基づくTransformerアーキテクチャの提案
RAGの基本構成	【E3】	パラメトリックモデルと外部の非パラメトリック記憶を組み合わせる生成手法
人のフィードバックによる調整	【E4】	人の選好を使った指示追従モデルの調整手法の例
トークン化、入力・出力、コンテキスト上限	【E5】	トークンの分割、入力・出力・キャッシュ・推論トークン、合計上限、公式カウント手段
APIの入力・出力・キャッシュ・ツール利用の料金	【E6】	入力・出力の単価区分、キャッシュ、ツール利用時の追加利用量・料金、見積もり例
定額・席数課金プランの確認	【E7】	組織向けプランの月額・席数課金と、機能・上限の条件

【E1】 NIST, *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*（NIST AI 600-1、2024年7月26日）

https://doi.org/10.6028/NIST.AI.600-1

【E2】 Vaswani et al., *Attention Is All You Need*（2017）

https://arxiv.org/abs/1706.03762

【E3】 Lewis et al., *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks*（2020）

https://arxiv.org/abs/2005.11401

【E4】 Ouyang et al., *Training language models to follow instructions with human feedback*（2022）

https://arxiv.org/abs/2203.02155

【E5】 OpenAI Help Center, *What are tokens and how to count them?*（利用前に最新版を確認）

https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them

【E6】 Anthropic, *Pricing — Claude Platform Docs*（利用前に最新版を確認）

https://platform.claude.com/docs/en/about-claude/pricing

【E7】 OpenAI, *Business Pricing*（利用前に最新版を確認）

https://openai.com/business/pricing/

参照日：2026年7月15日。本文は代表的な技術概念を説明するものであり、特定モデルの構造・能力・提供条件を保証するものではありません。料金・上限・提供条件は変わるため、利用・契約の直前に各サービスの公式資料を確認してください。

図表案として記載されているMermaid記法は、内容を確認できるコード形式で掲載しています。

5章 生成AI・LLMと機械学習のしくみ