◆ AIの弱点を仕組みで補う｜RAG・埋め込み・トークン・温度を業務判断に要る分だけ

社内のFAQ対応にAIを使い始めたところ、繰り返し同じ不満が出た。「規定を聞いても一般論しか返ってこない」。ベンダーに相談すると「ファインチューニングをすれば直る」と提案され、見積もりを取ると想像していた額の何倍もの費用が並んでいた。結局、必要だったのは自社の文書を検索して回答に添える仕組みだけで、ファインチューニングまでは要らなかった。

別の月には利用料金が急に増えていた。原因は、長い日本語の資料を毎回貼り付けて要約させる使い方だった。キャッチコピーの案出しでは似たような無難な案しか出ないのに、見積もりの計算をさせると数字が動く、ということもあった。前者は発想の幅がほしいのに手堅すぎ、後者は正確さがほしいのにぶれていて、求めている性質と逆のことが起きていた。

これらは、AIの外側にある仕組み——検索との組み合わせ、学習のさせ方、文章の数値化、料金の単位、出力のばらつきを調整するつまみ——を知らないまま使っていたために起きていた。この記事では、業務で判断が必要になる範囲だけを扱う。

■ この無料部分だけでできること

- RAG(検索を組み合わせる仕組み)が必要になる場面と、導入前にまず試すべきことが分かる

- ファインチューニングと転移学習の違いが分かり、「本当にファインチューニングが要るか」を見極められるようになる

- 埋め込み(意味検索)の仕組みが分かり、表記ゆれに強い検索・分類の要否を判断できるようになる

- トークンの仕組みと日本語が不利になる理由が分かり、料金とコンテキストウィンドウの消費を抑える工夫ができるようになる

- 温度(temperature)などのパラメータの役割が分かり、正確性重視とアイデア出しで使い分けられるようになる

- AIに計算をさせてはいけない理由と、任せてよい形の分担が分かる

- 「そのまま使ってよい場面」と「人の確認を挟むべき場面」を、実害の大きさという一つの基準で線引きできるようになる

無料部分だけで、AI活用の手法を選ぶ骨子として使える内容は揃う。ここで基本的な判断は成り立つように書いている。

■ こんなところで止まっていませんか

- 「社内規定を聞いても一般論しか返ってこない」と言われ、ファインチューニングが要るのか判断がつかない

- 埋め込みやベクトル検索という言葉を聞くたびに、自社に必要かどうか判断できず聞き流している

- 日本語でのやり取りが増えるにつれ、AIの利用料金がなぜか想定より早く膨らんでいる

- キャッチコピーの案出しでは似たような案しか出ず、逆に見積もり計算では数字がぶれる、といった「求めている性質と逆の結果」に困っている

- どの作業ならAIの出力をそのまま使ってよいかを担当者の感覚だけで決めていて、社内で基準が揃っていない

■ なぜそうなるのか

上に挙げたつまずきは、バラバラの現象に見えて、二つの理由に整理できる。ひとつは、AI単体では「知らないこと」「苦手なこと」がそもそもあり、外側の仕組みで補う必要があるという理由(RAG・ファインチューニング・埋め込み)。もうひとつは、AIの出力には料金・分量・ばらつきを左右する「つまみ」があり、知らずに使うと求めている性質と逆の結果を引き寄せてしまうという理由(トークン・温度・計算)。

この記事では、前半でAIの弱点を補う3つの仕組み(RAG・ファインチューニング・埋め込み)を扱い、続けて出力を調整する2つの要素(トークン・温度)、計算をさせてはいけない理由を扱ったうえで、最後に「そのまま使ってよい場面」と「確認を挟むべき場面」の線引きに落とし込む。前から順に読むことで、知識が業務判断の一つの型につながっていく。

────────────────────

■ 1. RAG(検索を組み合わせる仕組み)が必要になる場面

RAGとは「Retrieval-Augmented Generation(検索拡張生成)」の略で、AIが回答を作る前に、関連する文書や情報をデータベースなどから検索して取り出し、その内容を踏まえたうえで文章を生成する仕組みを指す。AIは学習データにない情報や、社内限定の情報については、そもそも知りようがない。RAGは、その「知らない部分」を、質問のたびに外部から取ってきた資料で補うためのアプローチである。

たとえば、自社の就業規則や過去の問い合わせ履歴、製品マニュアルといった社内文書に基づいて回答してほしい場合、AIにその文書を丸ごと学習させる(後述するファインチューニング)のは手間もコストもかかるうえ、文書が更新されるたびにやり直しが必要になる。RAGを使う構成であれば、質問が来るたびに関連しそうな社内文書をキーワードや意味の近さ(後述する埋め込みの仕組みを利用することが多い)で検索し、見つかった文書の該当箇所をAIへの指示文に一緒に添えて回答させる。これにより、AIは「一般的にはこう言われている」ではなく「この会社の規定ではこうなっている」という、根拠のある回答を返しやすくなる。

業務で必要になる典型的な場面は二つある。ひとつは、自社固有のマニュアルや過去の対応履歴を踏まえた回答が必要なカスタマーサポートのチャットボットなど、社内独自のルールに基づく回答である。もうひとつは、学習データの締め切り(カットオフ)の問題を補うために、最新のニュースや価格情報を検索して回答に反映させる場面で、これも広い意味でRAGの一種と言える。

業務担当者としての判断ポイントは、「AIに社内の専門知識や最新情報を正確に扱わせたいかどうか」である。単に文章を整えたり、アイデアを広げたりする用途であれば、素のAIで十分なことが多い。一方、社内文書に基づく正確な案内や、頻繁に更新される情報を扱わせたい場合は、RAGの仕組みを持つツールや、社内文書を連携させられるサービスを選ぶ必要がある。この見極めができていないと、「社内規定を聞いても一般論しか返ってこない」といった不満につながりやすい。

■ 2. ファインチューニングと転移学習の違い、どちらが要る場面か

この二つの言葉は混同されやすいが、業務担当者としては大まかな関係性だけ理解しておけば十分である。転移学習とは、あるタスク(たとえば大量の文章から言語の一般的な規則を学ぶこと)で得た能力を、別のタスク(特定の業務での文章作成など)に応用する、という広い意味での考え方を指す。実は、現在の生成AIが幅広い話題に対応できること自体が、この転移学習の成果だと言える。汎用的な文章生成能力を土台にして、様々な業務に「応用」して使えているわけである。

ファインチューニングは、その転移学習を実現する具体的な手法のひとつで、すでに学習済みのモデルに対して、特定の目的に沿った追加のデータでさらに訓練を行い、そのモデルの出力の傾向を目的に合わせて調整する作業を指す。たとえば、自社の文体や専門用語の使い方を一貫して守らせたい、特定の形式(定型の見積書のフォーマットなど)で一貫して出力させたい、といった用途で行われることがある。

業務担当者にとって重要なのは、「ファインチューニングをするべきかどうか」の見分け方である。多くの業務課題は、実はファインチューニングをしなくても、プロンプト(指示文)の書き方を工夫したり、前章のRAGで社内資料を参照させたりするだけで解決できる。たとえば「弊社らしい文体で書いてほしい」という要望であれば、過去の自社文書のサンプルを数例プロンプトに添えて「このような文体で」と指示するだけで、十分に近い結果が得られることが多い。ファインチューニングは、モデルの重み自体を書き換える作業であるため、専門的な技術・データセットの整備・相応のコストと時間が必要になり、業務担当者が片手間で行える作業ではない。

見分けの目安としては、「毎回のプロンプトで指示すれば実現できる」ことであればプロンプトの工夫やRAGで足りる。「膨大な量の同じパターンの作業を、指示なしで安定した品質で継続的に処理したい」「非常に特殊な専門領域の応答精度を根本から底上げしたい」といった場合に、初めてファインチューニングの検討対象になる。実務上は、まずプロンプトの工夫とRAGで解決を試み、それでも要件を満たせない場合にのみ、専門知識を持つ人材や外部ベンダーへの相談を検討する、という順序で進めるのが現実的である。

■ 3. 埋め込み(ベクトル化)で「意味が近い」を測る仕組み

埋め込み(エンベディング)とは、文章や単語を、その「意味」を反映した数値の列(ベクトル)に変換する技術である。人間が読んで「この二つの文章は似た内容だ」と判断するような感覚を、AIは文字の並びの一致ではなく、この数値化された意味の近さで捉えている。

直感的なイメージとしては、地図上の座標を思い浮かべると分かりやすい。意味が近い文章同士は地図上の近い場所に置かれ、意味が遠い文章同士は離れた場所に置かれる、というイメージである。たとえば「返品したい」という問い合わせ文と「商品を返したいのですが」という問い合わせ文は、使われている単語こそ違うが、地図上ではごく近い位置に配置される。一方、「返品したい」と「営業時間を教えてほしい」は、単語の共通点がなくても、それ以上に意味の面で離れた位置に配置される。この「近さ」を数値的に計算できるようにしたのが埋め込みの仕組みであり、単語が一致しているかどうかに頼る従来のキーワード検索よりも、表現の違いに強い検索や比較が可能になる。

業務での応用は幅広い。カスタマーサポートでは、新しく届いた問い合わせ文を埋め込みでベクトル化し、過去の問い合わせ履歴の中から意味的に近いものを検索することで、表現は違っても内容が同じ過去の対応事例やFAQをすぐに見つけ出せる。これにより、「返金してほしい」と「お金を返してください」のように言い回しが違うだけで同じ意図の問い合わせを、別々の案件として見落とすリスクを減らせる。また、大量の文書の中から似た内容の資料をまとめてグループ分けしたり、応募書類やレビューコメントを内容の傾向ごとに分類したりする用途にも使われている。前章で触れたRAGの「関連する社内文書を検索する」部分も、多くの場合この埋め込みの仕組みによって実現されている。

業務担当者としての判断ポイントは、「表記ゆれや言い回しの違いに強い検索・分類をしたいかどうか」である。単純なキーワード一致の検索で十分な場面では従来の検索の方が仕組みも単純で扱いやすいが、顧客からの自由な文章による問い合わせのように表現が多様になる場面では、埋め込みを活用した仕組みの方が実用的な精度を出しやすい。ツールやサービスを選定する際に「意味検索に対応しているか」という観点を持っておくと、要件に合った選択がしやすくなる。

■ 4. トークンとは何か。日本語が不利になる理由と料金への影響

トークンとは、AIが文章を処理する際の最小単位のことで、「1文字」や「1単語」と一致するとは限らない。英語であれば、単語や単語の一部(接頭辞・接尾辞など)がおおむね1トークンに近い単位で扱われることが多いが、日本語の場合は文字の種類や文脈によって、1トークンに対応する文字数が変動する。多くの生成AIサービスの料金体系は、このトークン数に応じて課金される仕組みになっている。

ここで業務上注意したいのが、多くの主要な生成AIモデルの学習データやトークンの分割ルールが、英語を中心とした文章データをベースに設計されてきた経緯があり、結果として同じ内容を表現するのに、日本語の方が英語よりも多くのトークンを消費しやすい傾向があるとされている点である。たとえば同じ意味の文章を日本語と英語で書いた場合、日本語の方が数割から倍近く多いトークン数になるケースが報告されている。これは、ひらがな・カタカナ・漢字が混在する日本語の文字体系が、英語のアルファベットに比べてトークンへの分割が複雑になりやすいことが一因とされている。

これが業務にもたらす影響は主に二つある。ひとつは料金である。同じ分量の文章をやり取りしても、日本語でのやり取りの方が英語でのやり取りよりもトークン消費が多くなりやすく、結果としてコストがかさみやすい。もうひとつは処理速度と、コンテキストウィンドウ(一度に扱える文章量の上限)の圧迫である。トークン数が多いということは、同じ文字数の資料でも、コンテキストウィンドウの上限により早く到達してしまうということであり、長い日本語の資料を扱う際には特に注意が必要になる。

対策としては、まず冗長な言い回しを削り、要点を絞った日本語で指示や資料を作成することが、意外に効果が大きい。丁寧だが長い前置きは、AIとのやり取りにおいてはトークンを消費するだけで回答の質にはほとんど寄与しない。用件を簡潔にまとめる、箇条書きを活用する、といった工夫でトークン消費を抑えられる。大量の資料を扱う業務では、英語に翻訳してから処理させた方がトークン数を抑えられる場合もあるが、翻訳の精度や手間とのトレードオフになる。

料金体系の注意点も付け加えておきたい。多くのサービスは、入力(プロンプト)と出力の両方をトークン数で課金しており、単価が別に設定されている場合もある。長文の資料を毎回丸ごと貼り付けて要約させる使い方は、入力側のトークン消費が大きくなりやすく、想定より早く利用上限や費用がかさむ原因になる。定期的に同じ資料を参照させる業務であれば、要約を社内ナレッジとして保存しておく、前章のRAGの仕組みを使う、といった工夫で毎回のトークン消費を抑えられる。

■ 5. 温度(temperature)などのパラメータが結果に与える影響

同じ質問でも毎回答えが違う現象の背後には、AIの出力の振れ幅をコントロールするいくつかのパラメータがある。代表的なものが「温度(temperature)」で、これは次に来るトークンの候補をどれだけ幅広く選ぶかを調整する数値である。温度を低く設定すると、AIは最も確率の高い候補を選びやすくなり、毎回似たような手堅い回答が返ってきやすくなる。逆に温度を高く設定すると、確率がやや低い候補も選ばれやすくなり、回答にばらつきや意外性が生まれやすくなる。

もうひとつよく登場するのが「top_p(核サンプリング)」と呼ばれるパラメータで、候補となるトークンを確率の高い順に並べ、累積確率が一定の割合(たとえば90%)に達するまでの範囲に絞って選択する仕組みである。温度とは調整の仕方が異なるが、いずれも「どれだけ手堅く選ぶか、どれだけ幅を持たせるか」を制御する点で似た役割を持つ。両方を設定できるサービスもあれば、利用者が意識せず固定値で使っている場合も多い。

業務での使い分けは、「正確性や再現性を重視する作業」と「発想の幅を重視する作業」を区別することが出発点になる。定型文書の要約、議事録の整理、数値データの抽出のような「決まった答えに近づけたい」作業では、温度を低めにすることで安定した出力を得やすい。キャッチコピーの案出しや企画のブレインストーミングのような「発想の幅がむしろ価値になる」作業では、温度を高めにすることで、より多様な候補を引き出しやすい。

一般向けチャットサービスでは、利用者が温度を直接いじれないことも多いが、仕組みを知っていれば「正確性重視だから複数回投げて共通部分を採用しよう」「アイデア出しだから多めに候補を出させよう」といった工夫ができる。APIやカスタマイズ可能な業務ツールを選ぶ際は、用途に応じて温度やtop_pを調整できるかも確認しておく価値がある。

■ 6. AIに計算をさせてはいけない理由と、させていい形

大規模言語モデルの正体は、あくまで「言語モデル」であり、電卓やプログラムのような計算機ではない。AIは次に来るトークンを確率的に予測して文章を生成しているのであって、数式を内部で正確に計算しているわけではない。単純な一桁の足し算のように、学習データの中に類似のパターンが大量に含まれている計算については、文章としてのパターン認識だけでも正しい答えを返せることが多いが、桁数の大きい掛け算や、複雑な条件を伴う集計になると、途中で数字を取り違えたり、桁を間違えたりする誤りが起きやすいとされている。

具体的な例を挙げると、大きな数同士の掛け算(たとえば七桁と七桁の掛け算)や、多数の項目を含む表計算的な集計(経費明細を数十行合計する、複数の割引率を順番に適用する、など)を、AIに文章だけで解かせようとすると、一見もっともらしい過程を示しながら、最終的な答えが間違っている、ということが起こり得る。厄介なのは、この間違いも、堂々とした自然な文体で提示されるため、計算過程を丁寧に検算しない限り、誤りに気づきにくいという点である。売上集計や見積金額の計算をAIの回答だけに頼って対外的な資料に転記すると、実害のある誤りにつながりかねない。

正しい使わせ方としては、AIに「数字を直接計算させる」のではなく、「計算の手順を整理させる」「計算式そのものを作らせる」「計算を実行するプログラムやスクリプトを書かせて、それを実際に実行させる」という形にすることが有効である。多くの生成AIサービスには、AI自身が簡単なプログラムを書いて実行し、その実行結果を回答に反映させる機能が搭載されている場合があり、これを使うと、AIが言語モデルとして文章から数字を「予測」するのではなく、実際のプログラム(電卓と同じ原理で動く確実な計算処理)が計算を担当することになるため、計算精度が格段に上がる。

業務での判断としては、「複雑な計算や大量のデータ集計が絡む作業は、AIに直接答えを聞くのではなく、表計算ソフトや計算機能付きのツールと役割分担させる」という原則を持っておくとよい。計算の設計はAIに相談し、実際の計算実行は電卓・表計算ソフト・プログラムの実行機能に任せる、という分担にすることで、AIの得意分野(整理・提案)と不得意分野(厳密な数値計算)を組み合わせられる。

同じ理屈は、日付の計算や単位の換算にも当てはまる。「契約開始日から180日後は何月何日か」「税抜き価格に複数の割引を順番に適用した後の金額はいくらか」といった条件が絡む計算も、文章としての予測だけで答えようとすると誤りが生じやすい。考え方の説明や計算式の組み立てはAIに任せ、最終的な数値の確定は表計算ソフトの関数や実行機能に担わせる、という二段構えが、提案力と正確さを両立させる。

■ 7. 「AIの出力をそのまま使ってよい場面」と「人の確認を挟むべき場面」の線引き

ここまでの6つの論点を踏まえると、AIの出力にはそのまま使っても実害の小さい場面と、人が内容を確認してから使うべき場面があることが見えてくる。この線引きの基準は、「AIが間違える可能性があるかどうか」ではない(AIは常に一定の確率で間違えるため、この基準ではすべての場面で確認が必要になってしまう)。実務上の基準は、「間違っていた場合に、どれだけの実害が発生するか」というリスクの大きさである。

リスクが大きく、人の確認を挟むべき場面として、まず対外的な発信が挙げられる。プレスリリース、顧客への案内文、SNSでの発信など、一度公開すると訂正が難しく、誤りが会社の信用問題に直結する場面では、AIが生成した文章の事実関係・数字・固有名詞を人が個別に確認してから発信すべきである。次に、契約や法務が絡む場面である。契約書の条文解釈、権利義務に関わる合意事項、社内規定の適用可否などは、誤った解釈がそのまま金銭的・法的なトラブルにつながるため、AIの回答を参考意見として扱い、最終判断は専門知識を持つ人(社内の法務担当者や弁護士など)が行う体制が望ましい。金額が絡む場面も同様で、見積書・請求書・経費精算のような、数字の誤りがそのまま金銭のやり取りに影響する書類は、前章で触れた計算の弱点も相まって、人による検算を挟む価値が特に高い。さらに、医療・安全・健康に関わる助言のように、誤りが人の身体や生命に影響し得る場面は、リスクが最も大きい部類に入り、AIの回答を最終的な判断材料とせず、専門家の判断を仰ぐべき領域である。

一方、人の確認を挟まなくても実害が小さい場面としては、社内向けの下書き作成(あとで自分や同僚が読んで手直しする前提のもの)、アイデア出しやブレインストーミングの叩き台、議事録のたたき台、定型的な文章のリライトや言い換えの候補出しなどが挙げられる。これらは、多少の誤りや不自然さがあっても、後工程で人の目が入ることが前提になっているため、AIの出力をそのまま次の工程に流しても、致命的な問題にはつながりにくい。

実務的には、業務の一つひとつについて「これが間違っていたら、誰にどれくらいの実害が出るか」を最初に自問する習慣を持つことが、線引きの精度を上げる近道である。実害が「自分がもう一度書き直す手間」で済むならAIの出力をそのまま活用してよいことが多く、実害が「顧客の信頼を損なう」「金銭的な損失が生じる」「法的な責任問題になる」「人の健康や安全に関わる」といったレベルに達する場合は、AIの出力を最終成果物とせず、人による確認のプロセスを業務フローに組み込んでおくべきである。

この線引きは、社内でルール化しておくと運用がぶれにくくなる。社内メモの下書きはそのまま清書に回してよいが、顧客に送るメール文面は担当者が一読してから送信する、金額や日付を含む文書は別の担当者がダブルチェックする、といった具合に、文書の種類ごとに確認の要否を決めておくとよい。担当者ごとに判断がばらつくと、確認漏れによる事故につながりやすい。マニュアルに「この文書はそのまま使ってよい」「この文書は人の確認を経てから使う」という区分を明記しておくことが、組織としてAIを安全に使いこなす土台になる。

■ ここから先に入っているもの

無料部分で扱った7つの論点は、それぞれ単体で読んでも実務に使える内容にしている。ここから先は、その7つを実際に手法を選ぶときや検算するときに使うための「道具」をまとめたパートである。無料部分の内容で足りている場合は、購入しなくてよい。

- 用途別・どの手法を選ぶかの早見表:プロンプトの工夫で足りるか、RAGが要るか、ファインチューニングまで要るかを、困りごとの症状から逆引きできる表

- AIの回答を検算する手順書:数字・固有名詞・引用を含む出力を、送信・提出の前にどう確認するかの実務手順

- 7つの論点の早見チェック表:作業に取りかかる前に1分で確認できる判定表

いずれも、読み物としてではなく、実際の作業の横に置いて使うことを想定している。