AI用語集

検索エンジンに内容を理解させ、利用者が自サイトを見つけられるようにする取り組み。

Google は「検索エンジンにコンテンツを理解してもらい、利用者がサイトを見つけて訪問するかどうかを判断できるようにすること」と説明しています。AI検索の登場で「SEOは終わった」と言われることがありますが、Google は2026年5月公開の公式ガイドで、生成AI機能は検索の中核のランキング・品質システムに基づいているため SEO のベストプラクティスは引き続き有効だと明記しています。本ページに並ぶ他の3〜4文字の略語は、いずれもこの SEO との違いを主張する形で登場しました。

出典: Google 検索セントラル

大規模言語モデルの回答に自社の情報が使われやすくなるよう整える取り組みを指す呼称。

Large Language Model Optimization の略として使われますが、提唱した組織や標準化団体は確認できず、SEOツールのベンダーや代理店の用語集がそれぞれ定義を出している状態です。同じ略語が「大規模言語モデル自体をチューニングすること」の意味でも使われており、二通りの意味が併存している点に注意が必要です。Google の公式ドキュメントはこの語を採用しておらず、生成AI検索に向けた最適化も結局は SEO であるという立場を示しています。

確認上の注記: 一次情報を探しましたが、標準化団体や提唱者による定義文は確認できませんでした（確認できたのはベンダーの用語集のみ）。

一次情報となる出典は確認できませんでした

AI Optimization の略として使われるが、AI Overviews の略とも読まれ、意味が定まらない略語。

業界では「AI Optimization（AI最適化）」の意味で使われる一方、実務の会話では Google の「AI Overviews」の略として読まれる場面のほうが多いという指摘があります。さらに IT分野には一体型PCや簡易水冷（All-In-One）という既存の用法があり、文脈なしでは通じません。公式な定義は確認できなかったため、使うなら毎回その場で定義を添えるか、別の語を選ぶのが無難です。

確認上の注記: 検索で確認しましたが、一次情報となる定義文は確認できませんでした。

一次情報となる出典は確認できませんでした

生成AIの回答の中に自社の情報が現れやすくするための最適化を指す語。学術論文が初出。

本ページに並ぶ略語の中で唯一、学術論文という形の出典を持ちます。Aggarwal らの論文「GEO: Generative Engine Optimization」が、生成エンジンの応答における可視性を高めるための枠組みとして提示しました。ただし論文が扱う内容と、その後マーケティング業界で「GEO」と呼ばれているものの中身は必ずしも一致しません。Google は公式ガイドで GEO という語に言及しつつ、生成AI検索に向けた最適化は検索体験に向けた最適化であり SEO であるとしています。

出典: arXiv（Aggarwal ほか）

検索やAIが直接示す「答え」に自社の情報が採用されるようにする取り組みを指す語。

Answer Engine Optimization の略ですが、提唱者や標準化団体は確認できず、代理店やツールベンダーの記事がそれぞれ定義を出している状態です。Google は公式ガイドで「AEO は answer engine optimization の略」と紹介したうえで、生成AI検索に向けた最適化は SEO であるという立場を取っています。なお AEO は貿易・通関の分野で「Authorized Economic Operator（認定事業者）」の略として確立しており、業種をまたぐと誤解を招きます。

確認上の注記: Google による語への言及は確認しましたが、提唱者による定義は確認できませんでした。

出典: Google 検索セントラル（語への言及として）

Google の検索結果の上部に表示される、AIが生成した要約とリンクのまとまり。

Google は「複雑な話題や質問の要点を早くつかみ、さらに詳しく知るためのリンクへの出発点になる」機能だと説明しています。掲載されるための追加要件や特別な最適化は不要で、通常どおり Google 検索にインデックスされ表示対象であることが条件だと明記されています。新しい機械可読ファイル・AI用のテキストファイル・専用のマークアップも必要ないと書かれています。

出典: Google 検索セントラル

Google 検索の中で、複雑な質問にAIが推論しながら答える専用のモード。

2025年3月に実験として発表され、Google は「さらなる探索・推論・複雑な比較が必要な検索に特に役立つ」としています。内部では「クエリファンアウト」、すなわちひとつの質問を複数のサブトピックの検索に分けて同時に投げ、結果を統合する手法を使うと説明されています。利用者が入力した語そのものではなく、そこから派生した複数の検索語で情報が集められるため、キーワード単位の順位という従来の見方が当てはまりにくくなります。AI Overviews と同じく、掲載のための特別な最適化は不要とされています。

出典: Google 公式ブログ

AIが答える前に外部の文書を検索し、その内容をもとに回答を作る仕組み。

2020年の論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」が初出で、学習済みモデルが内部に持つ知識と、外部から引いてくる知識を組み合わせるものとして説明されています。モデルを再学習させずに新しい情報や社内文書を扱えるため、業務利用では標準的な手法になりました。ただし検索が外せば回答も外れるため、誤りがなくなるわけではありません。

出典: arXiv（Lewis ほか、2020）

AIの回答を、実在する情報源に結びつけて根拠づけること。

Google は Gemini API の「Grounding with Google Search」を、モデルをリアルタイムのウェブ情報につなぐ機能と説明し、目的として「実世界の情報に基づかせることでハルシネーションを減らす」「事実の正確さを高める」を挙げています。RAG と重なる概念ですが、RAG が仕組みの名前であるのに対し、グラウンディングは「根拠に結びついている状態」を指して使われることが多い語です。公式の記述は「減らす」であって「なくす」ではない点に注意してください。

出典: Google Gemini API ドキュメント

AIの回答の中で、その記述の根拠になった文書やページを示すもの。

Anthropic は Claude の Citations 機能を、回答を提供元の文書に根拠づけ、各主張を支える箇所を正確に返すことで、答えを検証し利用者に出典を示せるようにするものだと説明しています。AI検索の文脈では「自社のページが引用されたか」が可視性の指標として使われます。ただし引用されることと、クリックされて実際に訪問が発生することは別である点に注意が必要です。

出典: Anthropic 公式ドキュメント

検索した人が結果ページの上で用を済ませ、どのサイトも訪問しない検索のこと。

数字が真っ向から割れている代表例です。SparkToro は Similarweb のクリックストリームデータを用いた調査で、2026年1〜4月の米国 Google 検索のうちクリックに至らないものが約68%だとしています（同社はモバイルアプリ経由を含まない等の限界も明記しています）。一方 Google は2025年8月の公式ブログで「ウェブサイトへの総オーガニッククリック数は前年比でおおむね安定している」と反論していますが、根拠となる数値や測定方法は公開していません。どちらの主張もそのまま自社の見込みには使えないため、自社の Search Console と解析ツールで測るのが確実です。

出典: Google 公式ブログ／SparkToro 調査

サイト所有者が、自動巡回プログラムに「どこを取得してよいか」を伝えるためサイト直下に置くファイル。

1994年からの慣習が、2022年9月に IETF の RFC 9309「Robots Exclusion Protocol」として標準化されました。RFC は「これらのルールはアクセス認可の一形態ではない」と明記しており、強制力はなく、従うかどうかは巡回側に委ねられています。最大の誤解は、制御できるのは取得（クロール）であってインデックスや学習ではない点で、Google 自身も「ウェブページを Google から締め出すための仕組みではない」とし、掲載を防ぐには noindex かパスワード保護を使うよう案内しています。AI の学習可否も、robots.txt が学習を止める仕組みなのではなく、各AI企業が自社のユーザーエージェント名を robots.txt で読む運用を自主的に採っているだけです。

出典: IETF RFC 9309

OpenAI が生成AIの基盤モデルを改善するためにウェブを収集するクローラー。robots.txt で拒否できる。

OpenAI は用途別に複数のユーザーエージェントを公開しており、役割が異なります。GPTBot は学習用（拒否は「生成AI基盤モデルの学習に使わせない意思表示」と説明されます）、OAI-SearchBot は ChatGPT の検索機能で表示するため、ChatGPT-User は利用者の操作に応じてその場で取得するためのものです。したがって「GPTBot だけ拒否して検索表示には出す」という切り分けが可能で、GPTBot を止めれば ChatGPT に一切出なくなるという理解は誤りです。

出典: OpenAI 公式ドキュメント

Anthropic が Claude の生成AIモデル向けにウェブを収集するクローラー。robots.txt で拒否できる。

Anthropic も役割の異なる3つのロボットを公開しています。ClaudeBot は学習に寄与しうるウェブコンテンツの収集、Claude-User は利用者が質問した際にその場でサイトへアクセスするもの、Claude-SearchBot は検索結果の品質改善のためのものです。robots.txt の標準的な指示に加え、非標準拡張の Crawl-delay にも対応するとしています。IPアドレスでのブロックは robots.txt の読み取り自体を妨げるため推奨されないと明記されています。

確認上の注記: 公式ヘルプにはトークン名と用途は記載されていますが、完全なユーザーエージェント文字列は記載がないため掲載していません（他社と体裁を揃えるための推測はしていません）。

出典: Anthropic プライバシーセンター

Google の生成AIへのコンテンツ利用可否を robots.txt で示すための名前。クローラーそのものではない。

公式には「単独のプロダクトトークン」と説明され、「Google-Extended は独自の HTTP リクエスト・ユーザーエージェント文字列を持たず、クロールは既存の Google のユーザーエージェントで行われる」と明記されています。つまりこの名前のボットは実在せず、取得は既存の Googlebot 等が行い、この名前は「その取得結果を生成AIに使ってよいか」の意思表示にだけ使われます。対象は Gemini アプリや Vertex AI の Gemini モデルの学習とグラウンディングで、「Google-Extended はサイトの Google 検索への掲載に影響せず、Google 検索のランキングシグナルとしても使われない」と明記されています。

確認上の注記: 旧URL（search/docs/crawling-indexing/google-extended）は404のため、現行の掲載先で確認しました。

出典: Google Crawling Infrastructure

Perplexity が回答に引用・リンクするサイトを収集するクローラー。robots.txt で拒否できる。

公式ドキュメントには PerplexityBot と Perplexity-User の2つが記載されています。PerplexityBot は Perplexity の検索結果にサイトを表示・リンクするためのもの、Perplexity-User は利用者の操作に応じてその場でページを取得するものです。両者とも「AI基盤モデルの学習用にコンテンツを収集するものではない」と明記されています。したがって PerplexityBot を拒否することは「学習を止める」ではなく「Perplexity の回答に引用・掲載されなくなる」ことを意味します。

出典: Perplexity 公式ドキュメント

AIに読ませる要約とリンク集を Markdown でサイト直下に置く提案。標準規格ではない。

Jeremy Howard 氏が2024年9月に提唱し、llmstxt.org が一次情報です。仕様は community input を募る段階にあり、IETF や W3C 等による標準化は受けていません。効果については見解が正面から食い違っています。Google は AI 最適化ガイドで「Google 検索に出るために新しい機械可読ファイルや AI 用テキストファイルを作る必要はない」「作っても Google 検索はそれらを無視するため、可視性や順位を助けも害もしない」と明記しています。一方 llmstxt.org 側は多数のサイトが公開していると述べていますが、これは各社が自社ドキュメント用に公開している事実であって、各社のAIが他サイトの llms.txt を読んでいることの確認ではありません。

確認上の注記: 主要AI企業が実際に llms.txt を取得・利用していると明言した一次情報は確認できませんでした。第三者記事やSNS投稿での言及は、一次情報の基準を満たさないため採用していません。

出典: llmstxt.org（提唱者サイト）／Google 検索セントラル

ページの内容を機械が読める形で書き添える仕組み。JSON-LD はその記法で、W3C 勧告。

JSON-LD 1.1 は2020年7月付の W3C 勧告で、Linked Data を JSON 形式で表現する書式と定義されます。Google は構造化データを「ページに関する情報を提供しページ内容を分類するための標準化された形式」と説明し、記法としては原則 JSON-LD を推奨しています。ただし「構造化データを入れるとAI検索に出やすくなる」という主張については、Google はむしろ逆のことを書いており、AI最適化ガイドに「生成AI検索に構造化データは必須ではなく、追加すべき特別な schema.org マークアップも存在しない」とあります。リッチリザルトの対象になるという従来のSEO上の意義とは分けて考える必要があります。

出典: W3C JSON-LD 1.1 勧告／Google 検索セントラル

構造化データで使う語彙（用語の集まり）。主要検索エンジン各社が共同で運営している。

公式 FAQ では、主要検索エンジンが支持する構造化データのマークアップ用スキーマを作ってウェブを改善する共同の取り組みだと定義され、Google・Microsoft・Yandex・Yahoo! の共同事業として始まりました。schema.org が定めるのは語彙であって書式ではない点が重要で、同じ語彙を Microdata・RDFa・JSON-LD のいずれの構文でも書き表せます。実務では「schema.org イコール JSON-LD」と混同されがちですが、schema.org が語彙（何を意味する項目か）、JSON-LD がそれを書く構文（どう書くか）という役割分担になります。

出典: schema.org 公式 FAQ

サイト内のURL一覧を検索エンジンに知らせるXMLファイル。発見を助けるだけで掲載は保証しない。

仕様は sitemaps.org が公開しており、1ファイルあたり5万URL・50MBが上限で、超える場合はサイトマップインデックスに分割します。changefreq と priority はあくまでヒントで、クローラーの挙動や順位を左右すると規定されているわけではありません。Google は「サイトマップは検索エンジンがサイト上のURLを発見する助けになるが、記載したすべてがクロール・インデックスされることを保証しない」とし、必須ではないことも明言しています（目安として約500ページ以下で内部リンクが行き届いていれば不要）。ただし多くの場合は置いたほうが有益だとも述べています。

出典: sitemaps.org／Google 検索セントラル

AIモデルが学習で獲得した内部の数値の個数。規模を示す目安で、「7B」なら70億個を指す。

「B」は billion（10億）を意味します。多いほど高性能とは限らない点は、資料によって書きぶりが分かれます。Google の Gemma 公式ドキュメントは「パラメータ数とビット数が大きいモデルは一般により高性能」と説明する一方、査読前論文には逆の実測が複数あります（Chinchilla 70B が Gopher 280B や GPT-3 175B を上回る、LLaMA-13B が GPT-3 175B を多くのベンチマークで上回る、など）。学習データ量や学習手法が同等でない限り、パラメータ数だけでの性能比較は成立しません。

確認上の注記: 「パラメータ数」という語自体を定義した提供元の公式ページは確認できませんでした。B＝billion の表記と、上記の性能に関する実測は一次情報で裏が取れています。

出典: arXiv（Chinchilla 論文）／Google AI for Developers

モデル内部の数値をより少ないビット数で表し直し、動かすのに必要なメモリを減らす技術。

Hugging Face の公式ドキュメントは「精度をできるだけ保ちながら、重みをより低い精度で保存することで、モデルの読み込みと利用に必要なメモリを下げるもの」と定義しています。重みは通常32ビットで保持されますが、16ビット、さらに8ビット・4ビットまで落とす手法があります。どの程度精度が落ちるかは手法とモデルによって異なり、一律には言えません。llama.cpp の公式ドキュメントも、精度低下は Perplexity などの指標で測るもので、適切な設定で軽減できると述べており、劣化幅が固定値でないことを示しています。

出典: Hugging Face Transformers ドキュメント

ローカルでAIモデルを動かすための、設定情報もまとめて1つに収めたファイル形式。

ggml 公式リポジトリの仕様書は GGUF を「GGML および GGML ベースの実行系で推論するためにモデルを保存するファイル形式」とし、GGML・GGMF・GGJT の後継であると明記しています。特徴として「単一ファイルでの配布：追加情報のための外部ファイルを必要とせず、容易に配布・読み込みができる」ことを挙げ、重みとメタデータの両方を含みます。量子化形式は F32・F16・Q4_K・Q6_K などが仕様に定義されています。

確認上の注記: GGUF が何の略かは公式仕様書に記載がなく、よく見る展開形は一次情報で確認できませんでした。Q4_K_M 等の末尾 S/M/L が何を意味するかも公式ドキュメントには説明がありません。

出典: ggml 公式リポジトリ GGUF 仕様書

モデルが一度のやり取りでまとめて参照できる文章量の上限。トークンという単位で数える。

Anthropic の公式ドキュメントは「言語モデルが応答を生成する際に参照できるすべてのテキスト。応答そのものを含む」と定義し、応答も枠に含まれると明記しています。Google の Gemini 公式も「入力トークンと出力トークンの合計の上限を定めるもの」としており、入力と出力は別枠ではありません。長ければその全部を正しく使えるわけではない点は複数の一次情報が指摘しており、Anthropic は「文脈が多ければ自動的に良いわけではない。トークン数が増えるにつれ正確さと想起が劣化する（context rot として知られる現象）」と述べています。arXiv の「Lost in the Middle」も、関連情報が文脈の中間にあると性能が大きく落ちることを報告しています。

出典: Anthropic 公式ドキュメント／Google Gemini API／arXiv:2307.03172

AIが文章を処理する際の最小単位。単語より細かく区切られることがあり、料金の計算にも使われる。

Google の公式ドキュメントは「トークンは z のような単一の文字のこともあれば cat のような単語全体のこともある。長い単語は複数のトークンに分割される」とし、Gemini では1トークンが約4文字、100トークンが英語60〜80語に相当するとしています。API 料金は入力・出力のトークン数で決まるため、課金単位でもあります。日本語・中国語は単語が空白で区切られないため専用の分割手法が必要になると Hugging Face の解説は明記しています。同じ内容の文章でも言語によってトークン数が大きく異なり、最大15倍の差が出ることが arXiv 論文で実測されており、これが利用料金・処理時間・投入できる文脈量の差につながります。

確認上の注記: 「日本語は英語の何倍」という具体的な倍率は、OpenAI の一次情報にアクセスできなかった（HTTP 403）ため記載していません。言語間で差が出ること自体は arXiv 論文で確認済みです。

出典: Google Gemini API 公式ドキュメント／Hugging Face／arXiv:2305.15425

出力のばらつき具合を調整する設定値。低いほど安定し、高いほど多様な文章になる。

取りうる値の範囲は提供元によって異なります。OpenAI は0〜2を採り、高い値でランダムに、低い値でより焦点が絞られ決定的になると説明します。Anthropic は0〜1（既定値1.0）で「応答に注入されるランダム性の量」と定義しており、範囲が倍違うため設定値をそのまま移植すると挙動が変わります。「0にすれば完全に決定的」とは公式には言えず、Anthropic は「temperature が 0.0 であっても、結果は完全に決定的にはならない」と明記しています。

出典: Anthropic 公式 API リファレンス／OpenAI 公式 API リファレンス

生成時のランダム性を決める数値。同じ値で出力を再現しやすくなるが、完全一致は保証されない。

OpenAI は「システムは最善の努力で決定的にサンプリングし、同じ seed とパラメータを使った繰り返しのリクエストは同じ結果を返すはず」と説明する一方、「決定性は保証されない」と明記しています。さらに「リクエストパラメータが一致していても、モデルに内在する非決定性により応答が異なる可能性がわずかにある」とも記されています。ローカル実行系にも seed はありますが、llama.cpp・Ollama の公式ドキュメントはいずれも決定性の保証には言及していません。実務では「seed を固定したのに出力が変わった」は不具合ではなく仕様の範囲内と理解する必要があります。

出典: OpenAI Cookbook（公式）／llama.cpp／Ollama 公式ドキュメント

大きなモデルが持つ知識を、より小さく動かしやすいモデルに学習させて移し替える手法。

原論文は Hinton・Vinyals・Dean による2015年の「Distilling the Knowledge in a Neural Network」で、複数モデルの集団が持つ知識を、展開がずっと容易な単一のモデルに圧縮できることを示したものです。一方、現在の LLM 業界では「大きなモデルの出力を訓練データにして小さなモデルをファインチューニングする」という広い意味で使われることが多く、原義と現在の一般的用法にはずれがあります。ライセンス上の論点として、Anthropic の商用利用規約は競合するAIモデルの訓練を含む目的でのサービス利用を禁じており、他社モデルの出力を使った蒸留が規約に抵触しうる実例が確認できます。

確認上の注記: OpenAI の利用規約は HTTP 403 で開けなかったため、OpenAI 側の規約内容については記載していません。

出典: arXiv:1503.02531（Hinton ほか）／Anthropic 商用利用規約

入力ごとに一部の「専門家」だけを働かせる構造。総パラメータ数より実際に使う量が少ない。

Mistral は Mixtral 8x7B について「総パラメータは46.7Bだが、1トークンあたり12.9Bしか使わない」と説明し、8つの専門家グループからルーターが2つを選んでトークンを処理する構造だとしています。実務でもっとも誤解されるのは「アクティブパラメータが小さい＝必要メモリも小さい」という読み違いで、Hugging Face 公式ドキュメントは「各エキスパートはすべてRAMに読み込まれる必要がある」と明記しています。つまり MoE が減らすのは計算量であって、モデルを載せるメモリではありません。

出典: Mistral AI 公式ブログ／Hugging Face／arXiv:2101.03961

回答を出す前に、内部で考える過程を生成してから答えるモデル。呼び方は提供元ごとに異なる。

OpenAI は「reasoning models」と呼び、モデルが reasoning token を使って考え、プロンプトを分解して複数のアプローチを検討すると説明します。この reasoning token は表示されなくてもコンテキストを占有し、出力トークンとして課金されます。Anthropic は同種の機能を「extended thinking」と呼んでいましたが「adaptive thinking」へ移行中で、返される思考ブロックは生の思考の連鎖ではなく推論の要約だと明記しています。Google は「thinking」と呼びます。この語には業界共通の統一定義がなく、名称も制御方法も提供元ごとに異なるため、比較の際はどの提供元の用語かを必ず添える必要があります。

出典: OpenAI／Anthropic／Google Gemini API 各公式ドキュメント

学習済みモデルに追加のデータを学習させ、特定の用途や振る舞いに合わせて調整すること。

OpenAI の公式ガイドはファインチューニングを「学習された記憶」、RAG を「文脈内の記憶」として対比し、授業に出て身につけるか教科書を手元に置くかの違いだと説明しています。使い分けの指針としては、誤答の原因が文脈ではなく一貫性や振る舞いにある場合にファインチューニングを使うとされ、新しい情報や専門的な文脈を注入する用途には RAG が挙げられています。つまり知識を足したいのか振る舞いを揃えたいのかで選ぶ道具が変わる点が実務上の分かれ目です。省コストな手法として LoRA などがあり、事前学習済みの重みを凍結することで学習対象パラメータを大幅に減らせます。

出典: OpenAI 公式ガイド／Hugging Face PEFT／arXiv:2106.09685（LoRA）

手元のパソコンやサーバーの中だけで動かす大規模言語モデル、またはその使い方を指す言い方。

この語を定義している標準化団体や公式機関は確認できませんでした。ただし実行環境側の一次情報には対になる表現があり、llama.cpp の README は目標を「幅広いハードウェア上で、ローカルでもクラウドでも推論を実現すること」と記し、Ollama の公式ドキュメントもローカル実行とクラウド実行を並べて示しています。つまり「ローカル」は「自分の管理下の機材で動かす」という対比語として使われている慣用表現であり、どこまでを含むか（自宅PCのみか、自社サーバーや自社契約のクラウドを含むか）は文書ごとに揺れます。使う際はどの範囲を指すか明記したい語です。

確認上の注記: 定義そのものを定める一次情報は発見できず、対比表現のみ確認しました。

出典: llama.cpp 公式リポジトリ／Ollama 公式ドキュメント

パソコンやサーバーで大規模言語モデルを取得・実行・管理するための、無料で公開されているソフトウェア。

macOS・Windows・Linux・Docker 向けの導入手段が公式に示されています。推論エンジンについては公式 README に「Supported backends」という節があり、そこに挙げられているのは llama.cpp の1つだけです。したがって「Ollama の裏側は llama.cpp」という説明は公式記載の範囲で裏付けがあります。ただし「対応バックエンド」という書き方であり、将来的に他が加わる余地を残した表現である点には注意してください。ライセンスは MIT で、ローカルの11434番ポートに REST API を持ち、他のアプリから呼び出せます。

出典: Ollama 公式リポジトリ

大規模言語モデルを少ない準備で幅広い機器の上で動かすための、C/C++ で書かれた推論プログラム。

README は自らを「依存関係のない素の C/C++ 実装」と記し、目標を「最小限の準備と最先端の性能を、幅広いハードウェア上で」と述べています。1.5ビットから8ビットまでの整数量子化に対応し、Apple シリコン向けの Metal、NVIDIA GPU 向けの CUDA、AMD GPU 向けの HIP などのバックエンドを持ちます。ライセンスは MIT で、Ollama をはじめ多くのローカル実行ツールがこの上に成り立っています。なお本プロジェクトは以前 ggerganov/llama.cpp にあり、現在は ggml-org/llama.cpp が正式な所在です。

出典: llama.cpp 公式リポジトリ

1秒あたり何トークンを処理・生成できるかという速度の指標。測る段階によって値が大きく変わる。

単独の「トークン/秒」という数字だけでは機種やソフトの比較はできません。llama.cpp 公式のベンチマークツール llama-bench は測定を最初から分けており、入力文をまとめて読み込む段階（prompt processing）と、答えを1トークンずつ出す段階（text generation）は別々に測るのが公式の作法で、両者の値は同じ機械でも大きく異なります。既定値も測定条件の一部で、llama-bench の既定はプロンプト512トークン・生成128トークン・繰り返し5回であり、結果は平均と標準偏差で報告されます。比較表に載せるなら最低限「どちらの段階か」「モデルと量子化」「文脈長」「試行回数」を併記しないと意味を持ちません。

確認上の注記: 測定手法としては公式に定義されていますが、「推論速度」という語自体の統一定義ではありません。

出典: llama.cpp 公式 llama-bench ドキュメント

モデルを動かすのに要るメモリ量。おおよそ「規模 × 1数値あたりの大きさ」に作業用の領域を足したもの。

Hugging Face 公式ドキュメントは目安を明示しており、X billion パラメータのモデルの重みを読み込むには32ビット精度でおよそ 4×X GB、16ビット精度ではおよそ 2×X GB の VRAM が要るとしています（例：70B モデルは16ビットで約140GB）。量子化すればさらに減ります。重みだけでは足りない点が実務では効き、会話が長くなるほど KVキャッシュが増えます。同ドキュメントは、ある155億パラメータ級モデルで文脈長16,000トークンの場合の KVキャッシュが16ビットでおよそ15GB、重み本体の約半分に達する試算を示しています。なお Apple シリコンでは CPU と GPU が同じメモリを共有する統合メモリ構成のため、VRAM と本体RAM が別々に存在しません。

確認上の注記: Apple Developer の技術文書は本文が取得できなかったため、統合メモリの記述は Apple の公式発表を出典としています。

出典: Hugging Face 公式ドキュメント／Apple Newsroom

学習を終えたモデルの中身の数値（重み）が公開されていること。学習データやコードの公開は含まない。

Open Source Initiative は「学習済みニューラルネットワークの最終的な重みとバイアス」を指すと説明し、そこに含まれないものとして学習コードと学習データセットを明記しています。同記事はこの語が2023年に形式化された経緯にも触れており、単一の公式定義が業界で確立しているとは言い切れない状態です。実務上の含意は明快で、重みが手に入っても、そのモデルがどのデータでどう作られたかは分からない場合があり、再現・監査・法的な素性の確認ができないことがあります。

確認上の注記: 米国NTIAの関連報告書は接続時の証明書エラーで開けなかったため、出典に採用していません。

出典: Open Source Initiative

「重みが配られている」ことと「オープンソース」は別で、後者には公式の定義があり、AI分野では論争が続いている。

ソフトウェアについては Open Source Initiative の The Open Source Definition が基準で、ソースコードが手に入るだけでは足りないとしたうえで10項目を課します。中でも「人・団体による差別の禁止」と「用途による差別の禁止」の2項が、AIモデルの配布条件と衝突しやすい箇所です。AI向けには OSI が Open Source AI Definition v1.0 を公開し、使う・調べる・改変する・共有するの4つの自由と、データ情報・コード・パラメータの3要素を要求しています。ここが業界で割れている点で、OSI は Meta の Llama ライセンスについて一部利用者への商用利用制限と用途制限があるため基準を満たさないと述べる一方、Meta は自社モデルを open と位置づけて配布を続けており、双方の立場は一致していません。

出典: Open Source Initiative（OSD／OSAID）

配布物を使ってよい条件を定めた文書。公認の定義に適合するものと、独自の条件を付けたものがある。

Apache License 2.0 は OSI 承認で、著作権の許諾に加えて特許の許諾を明文で与え、再配布時にライセンス添付・変更ファイルの明示・NOTICE ファイルの保持を求めます。MIT License も OSI 承認で、著作権表示と許諾表示を残せば利用・改変・再配布・販売まで認める短い文面です。Llama 4 Community License Agreement は性格が異なり、OSI 承認ではありません。確認できた条項は、直前の暦月の月間アクティブユーザー数が7億人を超える場合は Meta へ別途ライセンスを申請する必要があること、再配布時に「Built with Llama」の表示と派生モデル名の先頭に「Llama」を含めること、利用が Acceptable Use Policy の遵守を求められることの3点です。

確認上の注記: 各ライセンス本文は一次情報で確認しましたが、「オープンソースか否か」という評価自体は業界で割れています（前項参照）。

出典: Open Source Initiative／Apache Software Foundation／Meta 公式ライセンス

AIが、事実でない内容を、事実であるかのように自然な文章で出力してしまう現象。

学術サーベイは「提供された元情報に対して無意味、または忠実でない生成内容」を標準的な定義とし、元情報と矛盾する内在的なものと、元情報からは検証できない外在的なものに分類しています。用語自体に批判があり、米国 NIST は生成AIリスク文書で正式名称を confabulation（作話）とし、ハルシネーションを口語表現として位置づけたうえで、これを生成モデルの設計上自然に生じる結果と説明しています。ゼロにはできません。Anthropic の公式ドキュメントは軽減技法を挙げたうえで「これらの技法はハルシネーションを大幅に減らすが、完全に排除するものではない」と明記しています。

出典: arXiv:2202.03629（Ji ほか）／NIST AI 600-1／Anthropic 公式ドキュメント

入力に紛れ込ませた指示でAIの動作を乗っ取り、意図しない出力や操作をさせる攻撃。

OWASP の定義は「利用者のプロンプトが、意図しない形で LLM の挙動や出力を変えてしまうときに生じる脆弱性」です。直接型は利用者のプロンプトが直接モデルの挙動を変えるもの、間接型はWebページやファイルなど外部から取り込んだ入力に隠された内容が挙動を変えるもので、後者はAIに資料を読ませる業務ほど効いてきます。ジェイルブレイクとは同一ではなく、OWASP はジェイルブレイクを「モデルに安全プロトコルを完全に無視させる」プロンプトインジェクションの一形態と位置づけています。OWASP は「絶対確実な防止手段があるかは不明である」と明記し、入出力のフィルタリングや高リスク操作への人間の承認といった緩和策を挙げるにとどめています。

出典: OWASP Top 10 for LLM Applications（LLM01:2025）

モデルの能力を共通の問題セットで測り、点数で比較するためのテストのこと。

一次情報が確認できた代表例に MMLU（57分野の多肢選択）、GPQA（専門家が作成した448問で、Web検索が使えても非専門家の正答率は34%にとどまる設計）、SWE-bench（実際のGitHub Issue 2,294件をコード修正で解決できるか）があります。日本語では JGLUE と Nejumi LLMリーダーボードが公開されています。汚染に注意が必要で、ベンチマークの問題が学習データに混入すると、真の能力ではなく「見たことがある」ためにスコアが上がります。arXiv の調査論文は31モデルの数学推論タスクでテストセット混入の証拠を確認し、「ベンチマークの有効性を歪め、不公平な比較を助長する」と指摘しています。したがってスコアの高さは実務での有用性を保証しません。

確認上の注記: 個々のベンチマークには一次情報がありますが、「ベンチマーク」という語そのものを定義した公式文書は確認できませんでした。

出典: arXiv:2404.18824（汚染調査）／MMLU・GPQA・SWE-bench 各論文／JGLUE・Nejumi 公式

利用者が入力した内容を、提供事業者がAIの改良（学習）に使うかどうかの扱いのこと。

各社で扱いが全く異なり、同じ会社でも消費者向けと法人・API向けで違います（以下はいずれも2026年9月6日時点で公式ページに記載されていた内容で、ポリシーは変更されます）。OpenAI の API ドキュメントは「OpenAI API に送信されたデータは、明示的にデータ共有をオプトインしない限り、OpenAI のモデルの学習や改善には使用されません」と記載しています。Anthropic は商用製品について「既定では、当社の商用製品からの入力・出力をモデルの学習には使用しません」としています。一方 Anthropic の消費者向けは2025年8月28日に方針が変わり、利用者が自分で選ぶ方式となりました（学習利用を許可した場合の保持期間は30日から5年に延長）。契約形態ごとに公式ページで確認するのが確実です。

確認上の注記: OpenAI の消費者向け ChatGPT の学習利用とオプトアウト手順は、該当ページがいずれも HTTP 403 で開けなかったため記載していません。ポリシーは変更されるため、必ずご自身の契約形態の公式ページをご確認ください。

出典: Anthropic Privacy Center／OpenAI API 公式ドキュメント

AIアプリと外部のデータやツールをつなぐ手順を共通化した、公開された規格のこと。

公式サイトは「AIアプリケーションを外部システムに接続するためのオープンソースの標準」と定義し、「AIアプリケーションにとってのUSB-Cポートのようなもの」と喩えています。サーバー側が Tools（実行できる機能）・Resources（文脈データ）・Prompts（定型テンプレート）を提供する構成で、Anthropic が2024年11月25日にオープンソースとして公開しました。リスクは公式仕様に明記されており、仕様書は利用者の明示的な同意とツール実行前の承認を求めたうえで「ツールの挙動を説明する注釈等の記述は、信頼できるサーバーから得たものでない限り、信頼できないものとして扱うべき」と定めています。つまり MCP はプロンプトインジェクションの入口を増やす構造を持ちます。

確認上の注記: Linux Foundation への移管など統治体制については公式ページで確認できなかったため記載していません。

出典: Model Context Protocol 公式ドキュメント・仕様／Anthropic 公開告知

文章や画像の意味を、数値の並び（ベクトル）に変換したもの。近いほど内容が似ている。

OpenAI の公式ドキュメントは「埋め込みとは浮動小数点数のベクトル（リスト）」であり、テキスト同士がどれだけ関連しているかを測るもので「距離が小さいほど関連性が高く、距離が大きいほど関連性が低い」と説明しています。用途として公式に挙げられているのは検索・クラスタリング・レコメンド・異常検知・分類です。実務上は RAG の「検索」部分を担い、質問文と社内文書を同じベクトル空間に置いて近いものを取り出すことで、言い回しが違っても意味で拾えるようにします。逆に言えば、埋め込みの質と対象範囲が、RAG が持ってこられる情報の上限を決めます。

出典: OpenAI API 公式ドキュメント／Hugging Face 公式ブログ