「AIエンジニアと話していて、専門用語が分からず議論についていけない」「経営層に技術選択を説明する時、用語の使い分けが曖昧で説得力が出ない」——AI活用が広がる中で、業務担当者・推進担当者・経営層が共通して直面する課題である。

本稿では、業務でAIを扱う担当者が押さえるべき 6つの主要技術用語 を、定義・歴史・実装観点・相互関係まで体系的に整理する。技術ベンダーや支援会社との対話、社内の意思決定、外部資料の読解で必要になる基礎用語を、1本にまとめた実務リファレンスとして利用されたい。

本稿で扱う6用語:

  1. 機械学習（ML）・ディープラーニング（DL） — AIの基礎概念
  2. LLM（大規模言語モデル） — 現在のAI活用の中核
  3. プロンプトエンジニアリング — LLMを使いこなす技術
  4. Chain of Thought（CoT）・Reasoning — LLMの思考過程設計
  5. Fine-tuning — モデルカスタマイズの基礎
  6. AI Observability・LLMOps — 運用監視の仕組み

各用語の詳しい技術トピックは個別記事（RAGとは、Fine-tuning vs RAG、AIエージェント業務導入の設計論 等）も併せて参照されたい。

第1部 / 機械学習・ディープラーニングとは

機械学習（Machine Learning, ML）

機械学習 とは、データから自動的にパターンを学習し、新しいデータに対して予測・判断を行う技術の総称である。事前にすべてのルールを人間がプログラムするのではなく、「例示から学ぶ」アプローチを取る。

主な分類:

分類 内容 代表例
教師あり学習 正解付きデータから学習 スパムメール判定、画像分類、需要予測
教師なし学習 正解なしでパターン発見 顧客クラスタリング、異常検知
強化学習 試行錯誤と報酬から学習 ロボット制御、ゲームAI、推薦システム最適化

歴史的には、1950年代から「機械学習」概念は存在したが、計算能力とデータ量の制約で長らく実用が限定されていた。2010年前後から、計算能力・データ量・アルゴリズムの3要素が揃い、急速に実用化が進んだ。

ディープラーニング（Deep Learning, DL）

ディープラーニング は、機械学習の一分野で、多層のニューラルネットワーク を用いる手法を指す。「ディープ（深い）」は、ネットワークの層が深い（多い）ことに由来する。

従来の機械学習との最大の違いは、特徴量の自動抽出 にある。かつては「どんな特徴に着目するか」を人間が設計する必要があったが、ディープラーニングはこの特徴設計そのものをデータから自動学習する。その代わり、性能はデータ量に比例して伸びる性質を持ち、GPUなどの高性能ハードウェアを前提とする計算リソース要求の高さがコストとして付いてくる。この方向性が広く認知されたのは、2012年の画像認識コンペティション ImageNet で、ディープラーニングを使ったAlexNetが既存手法を大きく上回ったことがきっかけである。

MLとDLの関係 — どちらを使うかは問題の複雑さ次第

機械学習がディープラーニングを内包する（機械学習 ⊃ ディープラーニング）という階層関係を踏まえると、業務での使い分けの基準が見えてくる。画像・音声・自然言語処理のように、特徴を人手で定義しきれない複雑な領域ではディープラーニングが優位に立つ一方、需要予測のようなシンプルな予測タスクでは、決定木や線形回帰といった従来型の機械学習のほうが、説明性も運用コストも有利なことが多い。新しいほど良いわけではなく、問題の複雑さに手法を合わせるという判断が出発点になる。

現在のLLM（大規模言語モデル）は、ディープラーニングの中でも特に「Transformer」というアーキテクチャを用いた 巨大なディープラーニングモデル である。

第2部 / LLM（大規模言語モデル）とは

定義

LLM（Large Language Model、大規模言語モデル） とは、膨大なテキストデータで学習された、自然言語の生成・理解を行う巨大なディープラーニングモデルである。

「大規模」という呼称は、三つの規模の桁外れさに由来する。モデルが内部に持つパラメータ数は数十億から数兆個に及び、学習に使うテキストは数TBから数十TB規模（モデルにより幅が大きい）、そしてその学習には数千から数万のGPUを数週間から数ヶ月にわたって動かす計算リソースが要る。この規模ゆえに、ゼロから自社で構築するのは現実的でなく、後述するように既存モデルをいかに活用するかが業務利用の主戦場になる。

現代の代表的なLLM:

  • GPT系（OpenAI）: GPT-3、GPT-4o、o1 など
  • Claude系（Anthropic）
  • Gemini系（Google）
  • オープンソース: Llama（Meta）、Mistral、Qwen、DeepSeek など

Transformerアーキテクチャ

現代のLLMは、Transformer と呼ばれるニューラルネットワークアーキテクチャに基づく。2017年にGoogleの研究者が発表した論文「Attention is All You Need」（Vaswani et al., 2017）が起点となった。

Transformerの核心は Attention（注意機構）: 入力文の中で「どの単語に注目すべきか」を動的に判断する仕組み。これにより、長い文脈の理解と、並列計算による高速学習が可能になった。

2018年のBERT、2020年のGPT-3を経て、2022年末のChatGPTで一般の認知が爆発的に広がった。

得意と不得意を分ける境界線

LLMが本領を発揮するのは、言語を入出力とする処理である。要約・翻訳・文章作成・コード生成といったテキスト生成、知識ベースを踏まえた質問応答、文書からの分類・情報抽出、そして第4部で扱う論理的な思考の連鎖による推論——いずれも、言葉のパターンを操る作業だ。

裏を返せば、不得意も同じ性質から生まれる。LLMは学習時点までのテキストからパターンを獲得しているため、モデルのカットオフ以降の最新情報は原理的に知らず、ここは RAGとは で扱う外部知識参照で補う必要がある。大きな数値の四則演算や複雑な計算も、論理的に解いているのではなく統計的に「それらしい答え」を出している以上、誤りやすい。さらに、もっともらしい嘘を生成するハルシネーションのリスクは構造的に残り、医療・法律のような高度な専門知識も不十分なケースが多い。これらは使い方を誤った結果ではなく、LLMという技術の性質に根ざした限界として理解しておくべきものである。

どの提供形態を選ぶか — 機密性が分岐点

LLMを業務に組み込むとき、最初に決まるのは「モデルの中身」ではなく「どこで動かすか」である。OpenAI・Anthropic・GoogleのAPIを直接呼び出す形が最も手軽で、最新モデルへの追随も早いが、入力データが社外のクラウドに渡るため、扱うデータの機密度が高い業務では情報統制部門との調整が前提になる。これを嫌う場合は、LlamaやQwenといったオープンソースモデルを自社環境でホストする選択肢があるが、GPU調達と運用人員という固定費が乗る。両者の折衷が、Azure OpenAI Service・Amazon Bedrock・Google Vertex AIといったマネージドサービスで、データを自社のクラウド契約の境界内に留めたまま商用モデルを使える点が、日本企業の稟議では通りやすい。

実務上の判断軸は、機密性・コスト・カスタマイズ性・運用負荷の四つだが、これらは独立しておらず、機密性を最優先に倒すと運用負荷とコストが跳ね上がる、という相反関係を理解しておくことが肝心である。多くの中堅企業にとっては、まず最も機密度の低い業務でAPIまたはマネージドサービスを使って成果を出し、機密業務へは段階的に広げる順序が現実的だ。「どの業務を最初にAI化するか」という見極めそのものが成果を左右する点についてはAIは足し算より引き算 — 仕事の再配置で詳しく論じている。

第3部 / プロンプトエンジニアリングとは

定義

プロンプトエンジニアリング とは、LLMに対する 入力（プロンプト）を工夫することで、期待する出力を得る技術 である。モデル自体を変更せず、入力の設計だけで品質を制御する。

「Fine-tuning」（第5部）が モデルを変える のに対し、プロンプトエンジニアリングは 入力を変える アプローチであり、最も低コスト・高速で試行錯誤できる手法である。

出力を安定させる基本の組み立て

プロンプトの品質は、ほとんどが「指示の具体性」で決まる。「うまく書いて」のような曖昧な依頼ではモデルが文脈を補完してしまい出力がぶれるが、「対象: 経営層、目的: 投資判断材料、長さ: 300字、トーン: ですます調」のように条件を構造化すると、生成結果は格段に安定する。そのうえで「あなたはベテランの法務担当者として回答してください」と役割を与えれば、語彙と観点が専門家寄りに揃い、JSONやMarkdown、表形式といった出力フォーマットを指定すれば、生成結果をそのまま後続の処理に流し込めるようになる。逆に「数字を含めない」「200字以内」「断定的でなく確率的に表現する」といった禁止・制約を明示することも、暴走を抑える有効な手立てである。

さらに精度を上げたいときに効くのが、入力に正解例を埋め込む Few-shot プロンプティング だ。下のように業種とテーマの対応を二、三例示してから本命の問いを置くと、モデルは形式と粒度を例に倣って出力する。

Q: 製造業
A: 製造業は工場の自動化、品質管理、サプライチェーン最適化が主要テーマ

Q: 小売業
A: 小売業は在庫最適化、需要予測、顧客分析が主要テーマ

Q: 金融業
A:

ここから先は応用領域になる。思考過程を出力させる Chain of Thought（次節で詳述）、同じ問いに複数回答えさせて多数決を取る Self-Consistency、複数の思考経路を並行に探索する Tree of Thoughts、思考と行動（ツール呼び出し）を組み合わせる ReAct などがあり、扱う問題が複雑になるほど効果を発揮する。

まずプロンプトで限界まで詰める理由

プロンプトエンジニアリングは、業務特化のAI活用で最初に手をつけるべき層である。理由は単純で、モデルを書き換えず入力だけを変えるため、試行錯誤のサイクルが分単位で回り、失敗しても捨てるコストがほぼゼロだからだ。Fine-tuningのようにデータ整備とGPU資源を要する手法へ進む前に、「そもそもプロンプトだけでどこまで達成できるか」を徹底的に検証しておくと、後工程で費やす投資の妥当性を経営層に説明しやすくなる。実際、現場で「Fine-tuningが必要」と判断された案件の多くは、プロンプト設計と次節のRAGを尽くす前に高コストな手法へ飛びついていたケースである。

第4部 / Chain of Thought（CoT）・Reasoningとは

定義

Chain of Thought（CoT、思考の連鎖） とは、LLMに 「考える過程を出力させる」 ことで、複雑な推論問題の精度を向上させる技術である。

2022年にGoogleの研究者らが論文「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」（Wei et al., 2022）で提案し、その後LLMの推論能力研究の中核トピックになった。

動作原理

通常のプロンプト:

Q: りんごが5個あります。3個食べました。何個残っていますか？
A: 2個

CoTプロンプト:

Q: りんごが5個あります。3個食べました。何個残っていますか？
A: ステップごとに考えます。
  - 最初は5個
  - 3個食べた
  - 残り = 5 - 3 = 2
  答え: 2個

シンプルな問題では差がないが、複雑な計算・論理推論・多段階の問題 では、CoTが大きく精度を改善することが知られている。

Zero-shot CoT

最もシンプルな実装は、プロンプトに 「Let's think step by step」 または 「ステップごとに考えてみよう」 という指示を追加するだけ。これだけで多くの問題で精度が向上する（Kojima et al., 2022）。

Reasoning モデル（次世代）

2024年以降、CoT を モデル自体に組み込んだ「Reasoningモデル」 が登場している。

代表例:

  • OpenAI o1 / o3 シリーズ: 内部的に思考プロセスを行う
  • DeepSeek-R1: オープンソースの推論特化モデル
  • Claude の Extended Thinking

これらは、ユーザーが特別な指示をしなくても、内部で時間をかけて推論を行う。複雑な数学・コーディング・科学的問題に強い。

効くタスクと過剰になるタスク

CoTやReasoningモデルが投資に見合うのは、答えに至る「途中の論理」が間違いの温床になるタスクである。社内規程との整合性チェックのように複数の条件を突き合わせる意思決定支援、料金計算や税務計算のように一段でも桁を間違えると結論が崩れる多段階計算、そして因果や場合分けを要する論理推論——こうした領域では、思考過程を明示させること自体が誤りの自己検出として働き、精度が目に見えて上がる。

一方で、文書からの単純な情報抽出や、定型フォーマットへの文章生成にCoTを適用しても、得られる精度向上はわずかで、トークン消費と応答時間だけが膨らむ。Reasoningモデルは内部で長く思考する分、1リクエストあたりのコストと待ち時間が通常モデルより大きくなりやすいため、全業務に一律で当てると運用費が想定外に跳ねる。判断軸は「このタスクは途中の論理を間違えうるか」であり、間違えようのない定型処理には軽量モデルを充て、難所だけにReasoningを差すという使い分けが、品質とコストの両立につながる。

第5部 / Fine-tuningとは

定義

Fine-tuning（ファインチューニング） とは、既に学習済みのLLMに 追加学習を施し、特定の領域や用途に最適化 する技術である。モデルのパラメータ自体を更新するため、プロンプトエンジニアリングと異なり、効果が持続する。

コストを左右する手法の違い

Fine-tuningと一口に言っても、計算コストの桁が手法ごとに大きく異なる。古典的なのはモデル全体のパラメータを更新する 全パラメータFine-tuning（Full Fine-tuning） で、精度向上の余地は最も大きいものの、計算コスト・GPU資源・必要なデータ量がいずれも極めて高く、自前で行える企業は限られる。

この壁を下げたのが LoRA（Low-Rank Adaptation） である。Microsoft の研究者が2021年に発表した手法（Hu et al., 2021）で、モデルの大半を凍結し、追加の小さな行列だけを学習 する。学習対象のパラメータを大幅に削減でき（LoRA論文では GPT-3 で学習パラメータ数を約1万分の1に、学習時GPUメモリを約3分の1に縮小）、それでも全パラメータFine-tuningに近い精度を達成できる。QLoRA はさらに量子化（精度を下げて軽量化）を組み合わせ、コンシューマGPUでもLLMをFine-tuneできるようにした手法だ。こうした PEFT（Parameter-Efficient Fine-Tuning） 系手法の登場によって、企業がFine-tuningに取り組むハードルは大幅に下がった。

これらが「何を知っているか」を調整する手法だとすれば、「どう振る舞うか」を整えるのが人間フィードバックを使う学習である。RLHF（Reinforcement Learning from Human Feedback） は人間の評価データを用いてLLMの出力を改善する手法で、ChatGPTを含む現代の対話型LLMの多くがこの手法で訓練されている。これを単純化した代替手法が DPO（Direct Preference Optimization） で、実装が容易なことから近年広く使われている。

RAGとの分かれ目 — 目的が「振る舞い」か「知識」か

Fine-tuningが効くのは、出力の型そのものを固定したいときである。医療所見書・法務契約書・営業資料のように、特定のフォーマットやスタイルを徹底させたい場合、プロンプトに収まりきらない数百〜数千の例示パターンを内部化させたい場合、あるいはRAGよりトークン消費を抑えてレスポンス速度とコストを下げたい場合、そして業界用語や専門知識を振る舞いとして定着させたい場合に、追加学習という投資が報われる。

逆に判断を誤りやすいのが、「社内の最新データを参照させたい」という目的をFine-tuningで解こうとするケースだ。モデルへの追加学習は知識の即時更新には向かず、データが変わるたびに再学習が必要になる。最新情報の参照が狙いなら RAG のほうが適しており、両者は競合ではなく、振る舞いはFine-tuning、知識はRAGという役割分担で組み合わせるのが定石である。詳細はFine-tuning vs RAGを参照されたい。

第6部 / AI Observability・LLMOpsとは

LLMOpsの定義

LLMOps（Large Language Model Operations） は、LLMベースのアプリケーションを本番運用するための運用基盤・プロセスの総称 である。従来のソフトウェア運用（DevOps）や機械学習運用（MLOps）から派生した概念で、LLM特有の運用課題に対応する。

AI Observability の必要性

LLMアプリケーションは、従来のソフトウェアと異なる運用課題を持つ。

課題 内容
出力の非決定性 同じ入力でも実行ごとに異なる結果になる
ハルシネーション もっともらしい嘘の生成リスク
コスト変動 トークン量により利用料が変動
モデルバージョン更新 プロバイダー側でモデルが更新され、挙動が変わる
プロンプト管理 開発・テスト・本番でのプロンプト整合性

AI Observability は、これらの課題を可視化・追跡する仕組みで、LLMOpsの中心的な機能である。

モニタリングすべき主要指標

カテゴリ 指標
利用 リクエスト数、ユニークユーザー数、業務別利用シェア
パフォーマンス レスポンス時間（p50、p95、p99）、エラー率
品質 出力の正解率、ユーザー評価、ハルシネーション率
コスト API利用料、トークン消費（入力・出力別）、コスト/ユーザー
セキュリティ 機密情報混入アラート、プロンプトインジェクション検知

LLMOpsを構成する仕組み

LLMOpsの実体は、いくつかの仕組みが連動した運用基盤である。中核にあるのが プロンプト管理 で、プロンプトはコードではないものの、本番の出力品質を左右する以上、バージョン管理・A/Bテスト・問題発生時のロールバック機構が必要になる。そのプロンプトやモデルを本番に投入してよいかを事前に判断するのが 評価フレームワーク で、テストセットに対してLLM-as-a-Judge・人手評価・自動メトリクスを組み合わせ、変更が品質を落としていないかを検証する。

運用が始まれば、各リクエストの入出力と中間ステップ（RAG検索結果やツール呼び出し）を構造化して記録する ログ・トレース が、問題発生時の根本原因分析の生命線になる。これと並行して走るのが アラート・ガードレール で、異常検知に加え、機密情報の出力ブロックや有害コンテンツのフィルタリングを担う。そして全体を経済的に成立させるのが コスト管理 であり、トークン消費の継続モニタリング、利用上限の設定、モデル選定やプロンプト圧縮によるコスト最適化を回し続ける。これらは独立した機能ではなく、ログが評価とアラートの土台になり、評価がプロンプト管理の判断材料になる、という相互依存の関係にある。

ツール領域

LLMOps ツールは急速に発展している領域で、専門ベンダーが多数存在する。観測・トレース系、評価系、プロンプト管理系などカテゴリ別の選択肢があり、業務要件・規模・既存ツールスタックに応じた選定が必要となる。

商用クラウドベンダー（AWS、Azure、Google Cloud）も、自社のLLMサービスと統合したObservability機能を提供している。

なぜ後付けが致命傷になるのか

LLMOpsで最も多い失敗は、PoCで成果が出てから運用基盤を慌てて足す順序である。ログを取らずに本番投入したアプリは、ハルシネーションやコスト急騰が起きても「いつ・どの入力で・何が起きたか」を再現できず、原因究明に時間を溶かす。出力が非決定的でプロバイダー側のモデル更新によって挙動も変わるという、第6部冒頭で挙げた性質ゆえに、従来のソフトウェアより観測の重要性が高いにもかかわらず、見た目が普通のWebアプリと変わらないために軽視されやすい。

だからこそ、PoC段階から最低限のログとモニタリングだけは組み込んでおくことが、結果的に本番化への近道になる。完璧な基盤を最初から作る必要はないが、「あとで足せばいい」と判断した機能ほど、トラブルが起きてから足すと高くつく。この見極めとPoC脱出の進め方はAI PoC止まり脱出フレームワークでも論じており、エージェント構成での具体はAIエージェント業務導入の設計論で扱う。

第7部 / 全体マップ — 用語の相互関係

ここまで6つの用語を解説したが、それらの相互関係を一枚図で整理する。

[基礎概念]
機械学習（ML） ⊃ ディープラーニング（DL）
                  └── Transformerアーキテクチャ
                        └── 大規模言語モデル（LLM）

[LLMの使い方]
プロンプトエンジニアリング ←→ LLM
   ├── Chain of Thought（推論強化）
   └── Few-shot, Role-playing 等

[LLMのカスタマイズ]
Fine-tuning（モデル更新）
RAG（外部知識参照） ← 別記事
プロンプト（入力工夫）

[LLMの運用]
LLMOps / AI Observability
   ├── ログ・トレース
   ├── 評価フレームワーク
   ├── プロンプト管理
   └── コスト・セキュリティ管理

意思決定をどの順序で回すか

新しいAI活用プロジェクトでは、技術選択を踏む順序そのものが投資効率を決める。出発点は要件定義で、どんなタスクをどの程度の精度と速度で処理する必要があるかを言語化する。ここが曖昧なまま先へ進むと、後の手法選択がすべて推測になる。要件が固まれば、コスト・性能・セキュリティの観点からどのLLMを使うかというモデル選定に移り、続いてプロンプト設計で「まずプロンプトエンジニアリングだけでどこまで達成できるか」を試す。プロンプトだけで足りないと確認できて初めて、知識参照ならRAG、振る舞い固定ならFine-tuningへと手段を広げる。

そして本番運用に入る前に、評価とモニタリングの仕組み、すなわちLLMOps基盤を整え、運用後はモニタリング結果を次のサイクルの要件定義へ還流させていく。この流れを貫くのが、「最初からFine-tuningに飛びつかない」「LLMOpsは後付けしない」という業務AI実装の二大原則である。順序を飛ばしたコストは、たいてい後工程で利息付きで返ってくる。

まとめ

業務担当者がAIに関する意思決定をする際、本稿の6用語は 共通言語 として機能する。技術ベンダーや支援会社との対話、社内の議論、外部資料の読解で、これらの用語の意味と相互関係を理解していることが、適切な判断の前提条件になる。

読み終えて押さえておきたい勘所は、誤解されやすい関係性に集約される。ML・DL・LLMは並列の選択肢ではなく階層関係にあり、DLはMLの一分野、LLMはDLの一形態という入れ子になっている。プロンプト・RAG・Fine-tuningも競合ではなく補完関係で、入力工夫・外部知識参照・モデル更新という別々の役割を担う。CoT/Reasoningは複雑タスクでこそ効き、シンプルなタスクには過剰になる。Fine-tuningは「知識付与」ではなく「振る舞い変更」の手段であり、最新知識の参照はRAGの領分だ。そしてLLMOpsは後付けではなく初期から組み込むほど運用が楽になる。この五つの関係を取り違えなければ、ベンダー提案の妥当性も、社内の技術選択も、格段に見通しよく判断できるようになる。

もっとも、用語を正しく理解することと、自社のどの業務にどの手法を当てるかを見極めることは別の能力である。本来ヒトがやる必要のない仕事を引き算し、空いた工数を価値ある仕事へ再配置するという発想はAIは足し算より引き算 — 仕事の再配置で論じたとおりで、技術用語はその判断を支える道具にすぎない。AX Boostでは、この見極めから技術選択・実装・定着までを FDE型コンサルティング として一体で支援し、成果報酬という形で顧客の工数削減と自社の報酬を一致させている。詳細はFDE型コンサルティング完全解説を参照されたい。

関連記事: