AIを支える技術の仕組み

この章の位置づけ

前章では、AIを分類する座標軸を作りました。本章では、その中で現在の中心にある生成AIの内側の仕組みを扱います。

目的は研究水準の理解ではありません。実務で次の判断ができるようになることです。「この要望はRAGで解く問題か、ファインチューニングが必要か」「この処理に推論モデルを使うべきか」「なぜこの出力が不安定なのか」。仕組みを知らないと、これらはすべてベンダーの説明を信じるしかない判断になります。

本章の内容は第11章から第14章(開発・実装編)の前提知識にもなります。

Transformerと自己注意機構

現在の大規模言語モデルの土台は、2017年に提案されたTransformerという構造です。実務判断に効く性質だけを取り出すと、次の2点になります。

1つ目は、文章全体の関係を一度に計算すること。「その契約は前項の条件を満たす場合に限り有効とする」という文で、「その」が何を指し、「前項の条件」がどこにあるかを、文章全体を見渡して重み付けします。この仕組みを自己注意機構と呼びます。前から順に読む方式に比べ、離れた語の関係を捉えやすくなります。

2つ目は、計算を並列に進められること。これが実務的にはより重要でした。並列化できるということは、計算装置を増やせば学習規模を拡大できることを意味します。ここから、モデルを大きくする方向の開発競争が始まりました(第0章)。

ただし自己注意機構には計算量の性質上の制約があります。扱う文章が長くなるほど計算量が急に増えるため、一度に渡せる文章量(コンテキストウィンドウ)には上限があり、長くすると費用と応答時間が増えます。長い文書をそのまま全部渡す設計が費用面で不利になる理由がここにあります。

学習の仕組み ― 3つの段階

モデルができるまでには段階があります。この区別は、モデルの振る舞いを理解するうえで有用です。

事前学習(Pre-training)

大量の文章を使って、言葉のつながりの規則性を学ぶ段階です。この段階で知識の大部分が入ります。学習に使われた文章の時点までしか知らないという性質は、ここで決まります。

費用の大半もこの段階にかかります。だから利用者側が事前学習を行うことは通常ありません。既存のモデルを土台として使うのが前提です(基盤モデル)。

事後学習・指示チューニング(SFT)

事前学習だけのモデルは、文章の続きを予測するだけで、指示に従う振る舞いをしません。「要約してください」と言われたときに要約を返すようにするには、指示と望ましい応答の組を学習させる必要があります。この段階を指示チューニングと呼びます。

人間のフィードバックによる調整(RLHF等)

さらに、人間が「こちらの回答のほうが良い」と選んだ結果を使って、応答の傾向を調整する段階があります。有害な出力を減らし、丁寧さや形式を整えるのはこの段階の効果です。

この段階があることは、実務上2つの意味を持ちます。1つは、同じ基盤モデルでも調整の方針によって振る舞いが変わること。もう1つは、この調整が「無難な回答」に寄る傾向を生むことです。専門的な断定を避ける、留保を多く付けるといった傾向は、この調整の副作用として現れます。

推論モデル ― 考える時間を増やす仕組み

近年の重要な変化です。従来のモデルは、質問を受けたらすぐに回答を生成していました。これに対し、回答を出す前に内部で長く検討する動作が一般化しています。推論モデル、思考モデルなどと呼ばれます。

ここで注意が必要なのは、これが必ずしも別のモデルではないことです。同じモデルのまま検討量を切り替えられる形が増えており、製品では「思考」「推論」などの名前で強弱として提供されます(第1章)。したがって選定の単位は「推論モデルを使うか」ではなく、処理ごとに検討量をどう設定するかになります。

仕組みの要点は、応答時に使う計算量を増やすことです。従来は「モデルを大きくする」ことで性能を上げてきましたが、この系統は「同じモデルで、答える前により多く計算する」ことで性能を上げます。数学的な問題、複数段の論理を要する判断、コードの設計といった領域で、明確な差が出ます。

設定によって変わるトレードオフ

実務判断に直結する点です。従来の「高性能なモデルは遅くて高い」というトレードオフとは、性質が変わります。

使い分けの判断軸

3つの問いで決まります。

1. その処理は多段の判断を含むか ― 「この文書から金額を抜く」は単段です。「複数の条件を突き合わせて適用される料率を決める」は多段です。
2. 待ち時間は許容されるか ― 対話型の窓口では数十秒の待ちは使われない理由になります。夜間の一括処理なら問題になりません。
3. 1件あたりの費用が業務価値に見合うか ― 件数×単価で概算し、業務効果と比べます。

実務では、処理の種類でモデルを振り分ける構成が費用と品質の両面で有利になります。定型処理は小さいモデルか検討量を抑えた設定、複雑な判断だけ検討量を上げる。この振り分けはアーキテクチャの設計事項です(第13章)。

プロンプトエンジニアリングの基礎

指示の書き方で出力は変わります。ただし変わるのは指示した範囲の中身だけで、指示しなかった観点は出てきません。この限界を踏まえたうえで、効果が確認されている技法を挙げます。

ゼロショットとフューショット

例を示さずに指示するのがゼロショット、望ましい入出力の例をいくつか示すのがフューショットです。出力の形式を揃えたい場合、フューショットが最も確実な方法です。分類や抽出の業務では、実際の正解例を3〜5件添えるだけで安定性が上がります。

Chain-of-Thought(思考の連鎖)

「順を追って考えてください」のように、途中の考えを書かせてから結論を出させる方法です。多段の判断を要する処理で精度が上がることが報告されています。

ただし、推論モデルの登場でこの技法の位置づけは変わりました。推論モデルは内部で同等の検討を行うため、明示的な指示の効果は相対的に小さくなります。使っているモデルの系統によって、有効な技法が違うという認識が必要です。

システムプロンプトの役割

会話全体に効く前提の指示です。役割(「あなたは社内規程に基づいて回答する担当者です」)、制約(「規程に記載がない場合は『記載なし』と答える」)、出力形式をここに置きます。

業務利用では、「わからない場合の振る舞い」をシステムプロンプトで明示します。これを書かないと、根拠がない場合でも推測で答えます。

テンプレート化と再利用

個人が試行錯誤したプロンプトは、その人の手元に残るだけでは資産になりません。業務で使うものは、テンプレートとして共有し、変更履歴を管理する対象にします。プロンプトの変更は出力の変化を招くため、バージョン管理の対象になります(第13章)。

RAG(検索拡張生成)の仕組みと活用

社内の情報に基づいて回答させたい、という要望に対する標準的な答えがRAGです。モデルに知識を覚えさせるのではなく、回答のたびに関連文書を検索して渡す方式です。

埋め込みとベクトル検索

文章を数値の並び(ベクトル)に変換すると、意味の近さを距離として計算できます。この変換を埋め込みと呼びます。質問も同じ方法でベクトルにし、近い文書を探すのがベクトル検索です。

この方式の利点は、言葉が一致しなくても意味が近い文書を拾えることです。「有給の申請方法」という質問で「年次有給休暇の取得手続」という文書を見つけられます。

社内文書を参照させる仕組み

構成は次の工程になります。

1. 社内文書を適切な長さに分割する(分割の粒度が精度に大きく影響します)
2. 各断片を埋め込みに変換して保存する
3. 質問を受けたら、近い断片を検索する
4. 見つけた断片と質問をモデルに渡し、根拠を示した回答を作らせる

実務で最も手間がかかるのは1と、その前段にある文書の整理です。同じ規程の新旧版が混在していれば、AIは古い方を根拠に答えることがあります。「どの文書が正か」を決める作業は避けられません(第6・7章)。

RAGの限界

「RAGを使っているから正確」という説明は不正確です。次の限界が残ります。

• 検索漏れ ― 必要な文書が拾えなければ、答えは出ません。あるいは推測で答えます。
• 断片化の影響 ― 表や条件分岐を含む文書は、分割によって意味が壊れることがあります。
• 鮮度 ― 元の文書が更新されていなければ、回答も古いままです。更新の担当を決める必要があります。
• 矛盾の解決 ― 複数の文書が異なることを述べている場合、どちらを採るかの判断はモデルに委ねられます。

したがってRAGを入れても、出典を必ず表示させ、利用者が原文を確認できる経路を残す設計が必要です。

構造化出力 ― 形式をスキーマで縛る

「出力の形式が毎回揃わないので後続の処理が落ちる」という問題には、専用の解があります。返してほしい項目構成を機械が読める形(スキーマ)で宣言し、モデルにその形以外を出させないやり方です。構造化出力、あるいはスキーマ指定などと呼ばれます。

実務上の意味は3つです。

• 形式のばらつきが原理的に消える ― 項目の欠落や型の違いによる後続処理の失敗がなくなります。プロンプトで「JSONで返して」と頼む方式とは、保証の水準が違います。
• 追加の学習費用がかからない ― 形式を揃えるためにファインチューニングを行う必要はありません。
• 項目を変えるのが安い ― スキーマの記述を直すだけで済み、再学習は不要です。

ただし、揃うのは形式だけです。各項目に入る値が正しいかどうかは別問題で、そこは検証セットで測る領域です(第14章)。「形式が揃った」を「精度が上がった」と読み替えないでください。

ファインチューニングとその使い所

モデル自体を追加学習させて、振る舞いを変える方法です。RAGや構造化出力と混同されやすいので、本当に追加学習が必要になる場面を明確にします。前節のとおり、出力形式を揃えたいだけなら追加学習は不要です。

ファインチューニングが向く場面

• 文体・トーンを揃えたい ― 自社の文書規約に沿った文章を安定して出させる場合。
• 専門的な分類の判断基準を教えたい ― 業界固有の区分に沿った分類を、大量の正解例で覚えさせる場合。
• プロンプトを短くして費用を下げたい ― 毎回長い指示を送る代わりに、モデル側に振る舞いを入れる場合。

RAGとの使い分け

判断の基準は1つです。足したいのが「知識」ならRAG、変えたいのが「振る舞い」ならファインチューニング。

費用構造も違います。RAGは検索基盤の構築と維持が主で、文書を更新すれば反映されます。ファインチューニングは学習と検証の工数がかかり、内容が変わるたびに再学習が必要です。更新頻度が高い情報をファインチューニングで扱うのは、多くの場合誤った選択です。

AIエージェントの仕組み

ツール利用(Function Calling)

モデルに「使える道具の一覧」を渡し、必要に応じて呼び出させる仕組みです。在庫を調べる、メールを送る、計算する、といった処理を外部の関数として定義し、モデルが引数を組み立てて呼び出します。

実務上の要点は、道具の定義がそのままモデルに与える権限になることです。「メールを送る道具」を渡せば、モデルはメールを送れます。定義の一覧が権限の一覧です。

自律的なマルチステップ実行

目的を渡すと、モデルが手順を決め、道具を順に使い、結果を見て次を決める形です。人が各段を確認しない分だけ速く、同じ理由で誤りも進行します。

設計の原則は2つです。読み取りだけで足りる処理に書き込み・送信・削除の権限を与えない。取り返しのつかない操作の前に人の承認を挟む。この2点で被害の上限が決まります(第21章)。

マルチエージェント連携

役割の違う複数のエージェントを組み合わせる構成です。計画する役、実行する役、検証する役に分ける形が代表的です。

期待できるのは、検証役を分けることで誤りに気づきやすくなる点です。一方で、工程が増えるほど費用と待ち時間が増え、障害の原因を追いにくくなります。単一のエージェントで足りる処理を多段にすると、費用と複雑さだけが増えます。

マルチモーダルAI

テキストだけでなく、画像・音声・動画を同じモデルで扱えるものです。実務では次の用途で効きます。

• 図表を含む資料をそのまま読ませる(表の構造を理解した回答が得られる)
• 画面のスクリーンショットから操作手順を説明させる
• 現場写真と点検記録を突き合わせる
• 手書きのメモを含む書類を処理する

注意点は、画像の読み取り精度は文字の鮮明さに依存することです。かすれたスキャンや押印と重なった数字は、専用のOCRと同様に苦手です(第4章)。

外部連携の規格

AIを外部のデータやツールにつなぐ方法は、標準化が進んでいる領域です。かつては提供元ごとの独自の拡張機構(プラグインと呼ばれた仕組みなど)が用いられていましたが、現在はモデルと外部システムの接続を共通の形式で扱う規格(MCPなど)を用いる構成が広がっています。

実務上の意味は2つです。接続先を変えても実装の作り直しが減ること、そして接続の一覧が権限の一覧として管理しやすくなることです。後者はガバナンスの観点で重要で、どのAIがどの社内システムに触れるかを一元的に把握できるかどうかが分かれます(第16章)。

一方で、第三者が公開している接続サーバを入れる行為は、それ自体が外部要素の取り込みです。配布元、道具の定義に何が書かれているか、渡すトークンの範囲。この3点を確認の対象にしてください(第21章)。接続の追加は、実質的にアクセス権限の付与です。