AI用語の定義のズレが数千万円規模のプロジェクトを破綻させる現状に、TechCrunchが決定的なガイドラインを提示しました。

3行要約

• AIバブルに伴う用語の氾濫を整理し、ハルシネーションやLLMなどの基幹用語を実務レベルで定義し直した。
• 「なんとなく」で使われていた技術用語に明確な境界線を引くことで、顧客と開発者のミスコミュニケーションを防ぐ土台が完成した。
• 開発者はこれらの用語を共通言語として、SLA（サービス品質保証）の策定や要件定義の精緻化に活用すべき。

何が起きたのか

AIの進化スピードがあまりに速すぎた結果、現場では「言葉のインフレと混同」が深刻な問題になっています。私がSIerで働いていた5年前には想像もできなかったことですが、今や役員会議で「ハルシネーション」という言葉が飛び交い、しかもその解釈が人によってバラバラという末期的な状況です。

今回、TechCrunchが公開した「AI基本用語ガイド」は、単なる初心者向けの単語帳ではありません。これは、混沌としたAI業界における「公式辞書」の策定に近い意味を持っています。なぜ今このタイミングなのか。それは、AIが「触って遊ぶもの」から「基幹システムに組み込むもの」へとフェーズが変わったからです。

例えば「ハルシネーション（幻覚）」という言葉一つとっても、開発者は「確率統計的な出力エラー」と捉えますが、ビジネスサイドは「AIが嘘をついた」と擬人化して捉えがちです。この認識の乖離が、「AIなら100%正しい答えを出すはずだ」という過度な期待を生み、最終的なシステム納品時のトラブルに直結しています。

今回のガイドでは、LLM（大規模言語モデル）、マルチモーダル、パラメータ、ファインチューニングといった、我々が日常的に、しかし曖昧に使ってきた用語が整理されました。これは、AI開発における「契約書」や「仕様書」を書く際の、標準プロトコルとしての役割を果たすことになるでしょう。

技術的に何が新しいのか

今回の用語定義において、私が特に注目したのは「ハルシネーション」と「グラウンディング（根拠付け）」の関係性を整理した点です。従来、ハルシネーションは「LLMのバグ」のように扱われてきました。しかし、技術的な本質を言えば、LLMは常に「もっともらしい次の単語」を予測しているだけであり、事実かどうかの判定機能は持っていません。

今回のガイドでは、この仕組みを「確率的な推論」として再定義し、それを補完する技術としてのRAG（検索拡張生成）の重要性を浮き彫りにしています。開発者目線で言えば、以下の3つの概念の切り分けが明確になったことが大きいです。

1. パラメータと推論の関係 モデルの「重み」としてのパラメータが、どのように出力の多様性に寄与するのか。RTX 4090を2枚挿してローカルLLMを動かしていると分かりますが、7B（70億）パラメータと70B（700億）パラメータでは、「知っていること」の量ではなく「論理の組み立て精度」が圧倒的に違います。この差を「知識量」ではなく「構造的推論能力」として定義したのは実務的です。

2. マルチモーダルの本質 単に「画像が扱える」ということではなく、テキスト、音声、画像が「同一のベクトル空間」で処理されることを指します。これにより、従来の「OCR＋テキスト解析」というパイプラインではなく、直接画像から文脈を読み取るエンドツーエンドの処理が標準技術として位置づけられました。

3. コンテキストウィンドウの解釈 「一度に読み込める量」という物理的な制限から、「短期記憶のキャパシティ」というリソース管理の概念へと昇格しました。Gemini 1.5 Proの200万トークンと、GPT-4oの12.8万トークンでは、設計思想（アーキテクチャ）そのものが異なることを、非エンジニアにも説明しやすくなったと言えます。

# ハルシネーション抑制の例：以前はプロンプトで「嘘をつくな」と言っていた
# 今後は定義に基づき、グラウンディング（根拠）を明示させる設計が標準
def generated_response_with_grounding(query, context):
    # 用語ガイドに基づいた実装思想
    prompt = f"以下の【根拠】のみに基づいて回答してください。根拠にない場合は『不明』と答えてください。\n\n【根拠】: {context}\n\n質問: {query}"
    return llm.generate(prompt)

数字で見る競合比較

用語の定義が揃ったところで、現在の主要モデルがそれらをどの程度のスペックで実現しているかを数値で比較します。ここで重要なのは「最大値」ではなく「実用域」での性能です。

この数字が意味するのは、もはや「どれが最強か」という議論は無意味だということです。用語の定義に従えば、長大なドキュメントの「グラウンディング」を重視するならGemini一択ですし、コーディングにおける「論理推論の正確性（ハルシネーションの低さ）」を求めるならClaude 3.5 Sonnetが現在の最適解になります。

特にコスト面での「$3.00 vs $5.00」の差は、1日100万リクエストを捌く商用アプリでは月間で数百万円の差になります。エンジニアは「ハルシネーションが低いモデルを」と抽象的に選ぶのではなく、「許容されるハルシネーション率5%以下を、最も低コストで実現できるモデル」を、この標準用語を用いて選定する必要があります。

開発者が今すぐやるべきこと

この記事を読み終えたら、ただ「勉強になった」で終わらせず、以下の3つのアクションを明日までに実行してください。

1. 社内・チーム内「AI用語集」の同期 TechCrunchの記事をベースに、自社プロジェクトで使っている「ハルシネーション」「RAG」「プロンプト」の意味を再定義してください。特に顧客と会話する営業担当者には、「ハルシネーションはゼロにはならないが、グラウンディング技術で抑制できる」という言い換えを徹底させるべきです。

2. SLA（サービス品質保証）の見直し 「AIが正確に答えること」を要件にするのではなく、「特定データセットに対するハルシネーション率を○%以下に抑える」という数値目標に書き換えてください。標準的な定義ができたことで、ようやくこうした定量的な契約が可能になります。

3. 評価パイプラインの実装 単に「出力が良い感じだ」と主観で判断するのをやめましょう。RAGASなどのライブラリを使い、今回の定義に沿った「Faithfulness（誠実性：根拠に基づいているか）」や「Answer Relevance（回答関連性）」を自動スコアリングする仕組みを、既存のCI/CDに組み込んでください。

私の見解

正直に言えば、今回のTechCrunchのガイドを見て「今さら基本用語か」と感じるプロの方もいるでしょう。しかし、私はこれを「AI界のISO化」への第一歩として強く支持します。

SIer時代、私は「クラウド」という言葉の定義が曖昧だったせいで、数えきれないほどの不毛な会議を経験しました。顧客は「クラウドなら何でも無限にスケールして落ちないんでしょ？」と信じ込み、我々エンジニアはその幻想を打ち消すことにリソースを割かれました。今のAI業界は、まさにあの頃のデジャヴです。

「ハルシネーション」という言葉が一般名詞化したことは、AIの限界を社会が受け入れるための重要なステップです。AIは神ではなく、あくまで「確率的な推論マシン」に過ぎません。その限界を正しく定義し、数字で管理すること。それこそが、我々エンジニアが「AIマジシャン」から「AI技術者」へと脱皮するために必要なプロセスだと思います。

「AIが嘘をつくから使えない」と言っている層を、「ハルシネーション率を許容範囲に制御して運用する」というエンジニアリングの土俵に引き込む。そのための武器として、今回の用語ガイドを使い倒すべきです。

よくある質問

Q1: ハルシネーションを完全にゼロにすることは可能ですか？

結論から言えば、現在のトランスフォーマー・アーキテクチャである限り不可能です。LLMは常に確率的に次の言葉を選んでいるため、確率は限りなく低くできてもゼロにはなりません。RAGなどの外部知識参照を組み合わせて「事実に基づく確率」を高めるのが現実的な解です。

Q2: 開発現場で「ファインチューニング」と「RAG」のどちらを選ぶべきかの基準は？

情報の更新頻度と専門性で判断します。社内規定のように頻繁に変わり、正確な参照元が必要な場合はRAG。特定の口調や独自のコード生成スタイルなど、モデルの「振る舞い」そのものを変えたい場合はファインチューニングが適しています。コストと精度のバランスでは、現在はRAGが主流です。

Q3: AI用語が今後さらに増えたり変わったりする可能性はありますか？

確実にあります。特に「エージェント（自律型AI）」や「ワールドモデル」といった概念は、現在進行形で定義が揺れています。3ヶ月後には「LLM」という言葉すら古くなり、「LMM（大規模マルチモーダルモデル）」が一般用語になっている可能性が高いです。常に「技術の実態」を見て、言葉を更新し続ける姿勢が求められます。