第1章 生成AIの仕組みと限界

学習目標

• トークン、コンテキストウィンドウ、確率的生成、知識のカットオフを日常のたとえで説明する。
• モデル、製品、ツールを区別し、答えが「生成」されたものか「検索」されたものかを見分ける。
• ハルシネーションが起きる原因を述べ、出力をそのまま信じてはいけない状況を識別する。
• 作業の複雑さと速度・コストの要件に合わせ、推論モデルと通常のモデル、モデルのグレードを選ぶ。
• 画像・PDF・音声などのマルチモーダル入力の使い道と、誤りの種類を説明する。

はじめに

区立図書館の司書、ミンさんは「青少年の進路を考える読書週間」に使う推薦図書リストをAIで作りました。12冊の本が、著者、出版社、出版年、一行の紹介文とともにきれいに並びました。ところが、リストを蔵書と照合していた同僚が首をかしげました。2冊はどの書店にも存在せず、1冊は著者が合っていても題名が違いました。残りの9冊は正確でした。そのまま掲示板に貼っていたら、生徒たちは存在しない本を探し回ったでしょう。

ミンさんが驚いたのは、間違った本も正しい本と同じ口調・形式で書かれていたことです。AIは「この2冊は自信がありません」とは言いませんでした。AIはどうやってこのリストを作ったのか、なぜ9冊は正しく3冊は間違ったのか、何を見れば間違いに事前に気づけるのか。

この章はその問いに答えます。まずAIが文章を扱う単位（トークン）と一度に見られる量（コンテキストウィンドウ）を理解し、答えを作る仕組み（確率的生成）と知識の時間的な限界（知識のカットオフ）を見ます。続いてハルシネーションの原因と種類、推論モデルと通常のモデルの違い、画像・文書入力の限界を扱います。最後に「いつ出力をそのまま信じてはいけないか」をチェックリストにまとめます。AI活用能力のうち、見極め（Discernment）の基礎となる章です。

重要な概念

モデル、製品、ツールを区別する

AIの話で最初に区別すべきものが三つあります。

• モデル：文章を読み、次の文章を作る計算エンジンです。車でいえばエンジンです。
• 製品：人がモデルを使えるようにしたサービスです。会話画面、ファイルのアップロード、会話履歴、共有機能が含まれます。ChatGPT、Claude、Geminiのような名前は通常は製品名で、その中で複数のモデルが動きます。車でいえば車体と計器盤です。
• ツール：モデルが答えを作る際に呼び出す別の機能です。ウェブ検索、計算用のコード実行、社内文書検索、外部アプリとの接続が代表例です。車でいえばナビゲーションです。

誤りがどこで生じたかによって、取るべき対応は変わります。同じモデルを使っていても、検索ツールをオンにした製品とオフにした製品では、最新情報についてまったく異なる答えを返します。「AIが間違えた」で止まらず、「モデルが間違えたのか、ツールがオフになっていたのか、それとも製品が古い資料を渡したのか」と問いかける習慣が、この章の出発点です。

トークン：モデルが文章を区切る単位

モデルは文章を人間のように単語単位で読みません。文章をトークンという断片に区切って処理します。OpenAIは、トークンは1文字、単語の一部、単語全体、句読点のいずれの場合もあり、空白も区切り方に影響すると説明します。レゴにたとえると、同じ家を作っても、ブロックセットによって必要なブロック数が違うのと同じです。

トークン数と文字数、単語数は一対一には対応しません。同じ文章でも、モデル、モデルが使うエンコーディング（トークナイザーが文章をトークンに変える規則）、言語によってトークン数が変わります。各社が示す目安は英語基準です。

韓国語の文書とその英訳でトークン数が違うのは自然なことです。英語の目安をそのまま韓国語の文書に掛けて分量を見積もると、大きく外れることがあります。正確な数が必要なら、製品や開発者ツールのトークン計算機能で直接数えるのが原則です。

トークンは大きく三種類に分かれます。

トークンは上限とコストの単位です。一度に扱える量はトークンで決まり、言語モデルAPIの基本料金も主にトークンで計算します。OpenAIは、ほかの機能では別の課金単位を使う場合もあると補足しています。また、推論トークンは答えの文字として見えなくても出力トークンとして課金されるため、短い答えでも多くのトークンを使う場合があると案内しています。

コンテキストウィンドウ：机の上の作業スペース

コンテキストウィンドウは、モデルが回答を作るとき、一度に参照する文章全体の大きさです。Anthropicは、コンテキストウィンドウはモデルが学習した膨大な資料とは異なる「作業記憶」であり、指示文、会話履歴、添付した画像や文書、ツールの結果、そして今まさに作成している回答まで、そのすべてがここに含まれると説明しています。学習データがモデルの長年蓄えた図書館だとすれば、コンテキストウィンドウは、今資料を広げている机です。

机が広ければ仕事もうまくできる、というわけではありません。Anthropicは、トークンが増えるにつれて正確さや必要な情報を呼び出す精度が低下する現象を**コンテキストの劣化（context rot）**と呼び、何を入れるかを選ぶことは、スペースの広さと同じくらい重要だと強調しています。また、チャット画面では会話が長くなると、古い内容から押し出す「先に入ったものが先に出る」（先入れ先出し）方式でコンテキストを管理する場合があるとも説明しています。長い会話の最初に決めた条件があいまいになるのは、このためです。入力できることと、その内容を漏れなく活用できることは別です。条件が複数の文書に散らばっている場合、廃止された版が混ざっている場合、結論を変えるような例外が脚注に書かれている場合には、特に見落としが多くなります。

コンテキストウィンドウとともに知っておくべきものが出力上限です。モデルには一回の応答で生成できるトークン数にも上限があります。OpenAIは、コンテキストウィンドウとは別に出力上限があり、推論モデルでは見える答えのほかに推論トークン用の空間も残す必要があると案内します。長い文書全体を入力できても、同じ長さの結果を一度に受け取れるとは限らないという意味です。入力は机の広さ、出力は一度に書ける原稿用紙の枚数だと考えてください。Anthropicによると、APIで入力だけでウィンドウを超えると、リクエストはエラーになります。

確率的生成：非常に強力な自動補完

生成AIは、それまでの文章を見て、次に来るトークンとしてもっともらしいものを確率に基づいて選び、書き継いでいきます。スマートフォンのキーボードの自動補完を、はるかに大規模かつ精巧にしたものと考えるとわかりやすいでしょう。この方式から二つの性質が生まれます。

1. 同じ質問でも答えが少しずつ変わることがあります。もっともらしい候補が複数あると、毎回違うものが選ばれる場合があるためです。
2. 生成の過程そのものに「事実かどうかを確かめる段階」がありません。モデルは自然な文章になるように書き継ぎ、文章が真実かどうかは別途確認しません。

開発者向けAPIには、ランダムさの程度を調整する**temperature（温度）**という設定があります。Googleは、低い温度は決まった答えが必要な作業に、高い温度は多様な答えが必要な作業に向くと説明します。ただしAnthropicのAPIドキュメントには、温度を0に下げても結果が完全に同じにはならないと書かれ、最近の一部モデルは温度設定を受け付けないか、無視します。何より、温度を下げれば正確になるわけではありません。同じ誤答を毎回出すこともあり、Googleは一部モデルで既定値を変えると推論性能が落ちる場合があるため、既定値を維持するよう案内しています。

したがって、同じ答えが繰り返されても事実にはなりません。逆に、同じ質問を何度かして答えが食い違うなら、疑うべきサインです。Anthropicは同じ指示を複数回実行して結果を比較する方法を紹介し、結果間の不一致がハルシネーションを示す場合があると説明しています。一貫性は真実の証拠ではありませんが、不一致は警告灯になりえます。この非対称性を覚えておいてください。

知識のカットオフ：出国前に読んだ最後の新聞

モデルは特定の時点までの資料で学習します。それ以降の出来事はほとんど知らないか、不正確にしか知らないため、検索や添付など外部の根拠で確認する必要があります。南極基地で長年働いて帰ってきた人が、出国前に読んだ最後の新聞までしか知らないようなものです。

Anthropicのモデルのドキュメントは二つの日付を区別しています。**信頼できる知識のカットオフ（reliable knowledge cutoff）**は知識が最も幅広く信頼できる時点で、**学習データのカットオフ（training data cutoff）**は学習に使った資料のより広い範囲を示します。二つの日付の間の出来事は、多少は知っていても浅かったり不正確だったりするという意味です。カットオフ直前の出来事も、世の中に十分な文章が蓄積する前なので、学習資料が少ない場合があります。

実務では日付を覚えるより、この質問は時間がたつと答えが変わる種類かを判断する能力のほうが重要です。

右欄の質問は、知識のカットオフ以前の情報でも、すでに変わっている可能性があります。この種の質問では、最新資料を添付するか検索をオンにし、答えに基準時点を書かせるのが原則です。

生成と検索：答えを作るときと探すとき

AI製品の答えには二つの作り方があります。一つはモデルが学習済みの知識だけで答えを生成すること、もう一つは検索や文書照会で資料を探してきた後、その資料を根拠に答えを作ることです。後者を**グラウンディング（grounding）**と呼びます。地面に杭を打つように、答えを実際の資料に結び付けるという意味です。

Googleは、GeminiのGoogle検索グラウンディングにより、知識のカットオフ以降の最新情報に答えられ、答えと出典を結ぶ引用が返るため、利用者が直接確認できると説明します。社内文書を検索して答える機能も同じ原理です。

グラウンディングは強力ですが万能ではありません。検索しても、次の誤りは起こりえます。

• 検索結果自体が古かったり、間違っていたりします。
• モデルが検索結果を誤読したり、複数の出典を混ぜたりします。
• 引用があっても、その段落が実際には主張を裏付けていません。

したがって、答えの出典表示を見ることは検証の始まりであって、終わりではありません。第4章で、主張ごとに出典を照合する手順を詳しく扱います。

ハルシネーションの原因と種類

ハルシネーションとは、モデルが事実と異なる内容や、与えられた資料と食い違う内容を、もっともらしく生成する現象です。Anthropicも、最先端のモデルであっても事実や文脈に合わない文章を作りうると認めています。「間違い」と一括りにせず、種類を分けると対応が見えてきます。

Anthropicが勧める基本対策は三つです。不確かならわからないと言えるようにすること、長い文書では答える前に関連文をそのまま引用させること、主張ごとに引用と出典を付け、裏付ける文を見つけられない主張は撤回させることです。さらに「提供した文書の情報だけを使い、一般知識は使わない」と範囲を限定する方法もあります。Anthropicは、これらはハルシネーションを大きく減らしてもなくすことはできないので、重要情報や高リスクの意思決定は必ず確認するよう補足しています。

自信ありげな口調と根拠の強さ

AIの答えは、間違っているときでも流暢で断定的です。そして人は、自信ありげに話す相手を信じやすいものです。「はじめに」で挙げた誤った3冊の紹介も、正しい9冊の紹介とまったく同じ口調でした。自信ありげな口調と根拠の強さは別物です。

似た現象に**迎合（sycophancy）**があります。Anthropicの研究は、迎合を真実よりも利用者の信念に合う答えを出す行動と定義し、人による選好評価でもっともらしく書かれた迎合的な答えが正確な答えより高く評価されることが、一因だとしています。実務では次のように現れます。

• 利用者が「本当に？ 私の知っている話と違うけれど」と反論すると、根拠なく答えを変えます。
• 質問に望む結論が含まれると、その結論を裏付ける方向に傾きます。
• 利用者の書いた下書きを評価すると、実際より甘い評価をします。

対応は簡単です。答えが変わったとき、どちらが正しいかをモデルの態度で判断せず、外部の根拠で判断します。質問は望む結論が伝わらないよう中立的に書き、評価を頼むときは「まず弱点を三つ見つけよ」のように批判する余地を明示します。

推論モデルと通常のモデル

最近のAI製品の多くは、複数の種類のモデルを組み合わせて提供しています。そのうち、推論モデルは回答する前に内部で複数の段階を検討するモデルで、通常のモデルは指示を受けるとすぐに答えを書き継ぎ始めるモデルです。OpenAIは両者を「計画担当（planner）」と「実働部隊（workhorse）」にたとえています。一方が優れているということではなく、互いに性質が異なるだけであり、ほとんどの業務の流れでは両者を組み合わせて使うと説明しています。

二つの誤解を避ける必要があります。第一に、推論モデルだからといって、最新の知識をより多く知っているわけではありません。推論能力とは「与えられた情報を使ってどれだけうまく検討できるか」であり、知識の新しさは知識のカットオフと検索の有無で決まります。第二に、長く考えた結果でも間違うことはあります。推論モデルの結論についても、根拠と計算を確認する必要があります。推論モデルへの指示の仕方は通常のモデルへの指示とは少し異なりますが、これは第2章の「さらに深く」で扱います。

作業の難しさに合ったモデルのグレードを選ぶ

各社は同じ系列でも、大きくて遅く高価なモデルから、小さくて速く安価なモデルまで、複数のグレードを提供しています。Anthropicのモデル比較表は、最速のグレードは分類、抽出、ルーティングなど処理量と応答速度が重要な作業向け、最大のグレードは難しい推論や長い作業向けと説明しています。

グレードを選ぶときは四つを問います。

1. 判断はどれほど複雑か？ 規則が明確な仕事か、複数の条件を比較検討する仕事か。
2. どれほど多く、どれほど速く処理する必要があるか？ 1日数千件か、月に数件か。数秒以内に答える必要があるか。
3. 間違うとどれほど害があるか？ 人がすぐ直せるか、外部に出て取り消しにくいか。
4. 小さなモデルで十分かを確かめたか？ 数十件の代表例で、小さなモデルと大きなモデルを比較したか。

最後の問いが要点です。グレード表やモデル名よりも、自分の業務の代表例を使って行った小さな比較実験のほうが、信頼できる根拠になります。正確さ、漏れ、速度、人が修正するのにかかった時間を記録すれば、どのグレードが必要かを数字で把握できます。処理件数の多い業務では、簡単な依頼は小さなモデルに送り、難しい依頼だけを大きなモデルに送る、**振り分け（ルーティング）**という設計もよく使います。

マルチモーダル入力

マルチモーダルとは、文章だけでなく画像、PDF、音声、動画など複数の形式の入力を扱う能力です。領収書の写真から金額を読ませたり、グラフ画像の傾向を説明させたり、会議録音を要約させたりできます。

マルチモーダル入力で知っておくべき性質は三つあります。

1. 画像や音もトークンを使います。 Googleは、画像、動画、音声を決められた規則に従ってトークン数に換算して数えると案内しています。Anthropicは画像を小さな断片に分け、トークンとして計算します。写真に撮ってアップロードした文書もコンテキストウィンドウを消費します。テキストで直接入力するよりトークンの消費を抑えられるかどうかは、画像の解像度とモデルによって異なります。画像が縮小されると、小さな文字が読み取りにくくなることも併せて覚えておいてください。
2. 画像ならではの読み取り誤りがあります。 Anthropicは、画質が低い画像、回転した画像、非常に小さな画像を解釈する際に誤る可能性があると明記しています。また、位置関係の把握は大まかな精度にとどまり、小さな物体が多いと、その数を正確に数えられない場合があるとも説明しています。実務では、小さな文字や不鮮明なスキャン、表の行と列の対応関係、グラフの軸と単位と凡例が、代表的な読み違いの箇所になります。
3. 判別できないことがあります。 Anthropicは、モデルは画像がAI製かどうか判別できないため、偽造画像の検出には頼らないよう案内します。

音声は文字起こしと解釈の段階に分けて考えます。人名、専門用語、重なった発言は文字起こしで、誰が何に同意したかは解釈で間違えやすい部分です。

Anthropicは、画像を文章より先に置くと最もよい結果が得られると案内します。数字が重要な資料では、画像より元のファイル（スプレッドシート、原文テキスト）を渡すほうが正確です。

出力をそのまま信じてはいけない状況

ここまでに学んだ概念を、一つのチェックリストにまとめます。次の項目のうち一つでも当てはまる場合は、出力をそのまま使わず、確認の手順を踏みます。

出力の種類によって、検証の方法も異なります。事実は原文と照合し、計算は別の方法でもう一度計算し、解釈は前提と反例を確認し、創作は目的・読者・制約に合っているかを評価します。すべての結果を同じ方法で検討していると、重要な誤りを見落とします。

さらに深く

計算と集計をツールに任せる理由

言語モデルは、数を計算する機械ではなく、次に来るトークンを予測する機械です。短い足し算にはたいてい正解しますが、行数の多い表の合計、比率や増減率、複数の条件を設けた集計では、もっともらしくても誤った数値を出すことがあります。問題は、誤った数字も、正しい数字と同じくらい自然に見えるという点です。

Googleは算術、個数の計数、計算が必要な仕事にはコード実行ツールを勧めています。コード実行は、モデルが計算過程をプログラムにして実際に動かす機能です。人が結果だけでなく計算式も確認できる利点があります。その機能がない環境では計算をスプレッドシートに任せ、AIには結果の解釈や文章化だけを任せるのが安全です。

この原則は、「AIは数字に弱いから、数字を扱う業務には使わないように」という意味ではありません。役割を分けるという意味です。計算は確実に計算できるツールが担当し、解釈や記述は言語モデルが担当します。人は、その二つのつながりが正しいかを確認します。報告書に入れる数値であれば、誰がどのような方法で計算したかを、後からたどれるようにしておく必要があります。

同じ名前のモデルも変わる：バージョンと再現性

昨日と同じ指示を入力したのに、今日は答えの形式が変わることがあります。確率的生成が原因の場合もありますが、製品の裏側でモデルそのものが変わったことが原因の場合もあります。チャット製品の既定のモデルは、製品が更新される際に新しいバージョンに変わる可能性があります。開発者向けAPIでは、各社が特定の時点のモデルを固定したスナップショットの名前を提供しています。OpenAIは、一貫した動作が必要な運用環境なら、特定のスナップショットに固定し、プロンプトの動作を測定する評価セットを作っておくよう勧めています。

そのため、チームで使う指示テンプレートの動作が突然変わった場合は、指示文だけを原因と考えず、モデルや設定が変わっていないかを確認します。継続的に使うAI機能であれば、代表的な事例10〜20件と、それぞれに期待する結果をまとめた確認セットを作っておきます。モデルが変わるたびに同じ事例でもう一度実行し、違いを見つけます。

実務の場面

夜明けベーカリー購買チームのバター単価報告書

手作りデザートのフランチャイズ「夜明けベーカリー」の本社購買チームで働くオさんは、来月のバター購入量を決める価格動向報告書を書く必要があります。ウェブ検索がオフの社内AIツールに「直近3か月の韓国国内のバター卸売価格の推移と来月の見通しをまとめて」と尋ね、月別価格と見通しのきれいな表を受け取りました。

オさんはそのまま貼り付けようとして、三つの問いを思い出します。

1. この情報はいつのものか？ 直近3か月の価格は知識のカットオフ以降である可能性が高く、検索がオフなのでモデルは実際の価格を見られませんでした。
2. この数字はどこから来たのか？ 表に出典がありません。具体的な数字ほど確率的生成で補われた「もっともらしい値」かもしれません。
3. 間違っていたらどれほど害があるか？ 購入量の決定に使う数字で、仕入れ判断を誤ると在庫損失につながります。

オさんが最初に思いついた代案は二つありました。一つは、同じ質問を何度か繰り返し、数字が同じなら使う方法でした。しかし、繰り返すことは事実確認の代わりにならないため、この案は採用しませんでした。もう一つは、検索をオンにして再び尋ねる方法です。ただし、検索結果では小売価格と卸売価格が混ざる可能性があり、自社が実際に提示される単価とは異なる可能性もあるため、補助的な手段としてだけ使うことにしました。

結局、取引先3社から受け取った直近3か月の単価表PDFを添付し、次のように依頼しました。「添付の数字だけを使い、各値の横に根拠文書名とページ番号を書け。資料にない月は『資料なし』と表示せよ。平均と増減率は直接計算せず、計算すべき列だけを示せ。」平均と増減率は別途スプレッドシートで計算しました。見通しは別の依頼に分け、「上の表の傾向を説明し、確認済みの事実と推定を段落で分けよ」と指示しました。

結果は最初のものより華やかさに欠けましたが、すべての数字に根拠が付き、データが抜けた月は空欄としてわかるようになりました。オさんは、PDFの原本と表を一度照合してから、報告書に入れました。要点は、モデルの能力を疑ったことではありません。モデルが見られない情報と、モデルが確認しない仕組みを理解し、その不足を根拠とツールで補ったことです。

夏の森キャンプ運営チームのダッシュボード画像報告

キャンプ用品のオンラインショップ「夏の森キャンプ」の運営チームで働くカンさんは、毎週月曜の役員会に週間実績要約を出します。時間を短縮するため、販売ダッシュボードの画面を撮った画像3枚をAIに渡し、「先週の実績を5行で要約して」と依頼しました。画面には左軸が売上高、右軸がコンバージョン率の二軸グラフと、小さな文字のカテゴリ別表がありました。

要約はもっともらしいものでしたが、チームメンバーが2か所の問題を指摘しました。コンバージョン率が実際の10倍の値で記されており、表の「テント」行の売上が、すぐ下の「タープ」行の値に置き換わっていました。カンさんは原因を次のように分けて考えました。コンバージョン率の誤りは、二つの軸の単位を混同した解釈の誤りです。一方、行の取り違えは、小さな文字の表で行と列の対応を誤った読み取りの誤りでした。

カンさんは三つの選択肢を比較検討しました。画面キャプチャの解像度を上げれば読み取りの誤りは減りますが、軸の解釈の誤りは残ります。画像をまったく使わなければ画像の誤読はなくなりますが、傾向をひと目で説明してもらえるという利点まで失います。そこで、数字には元のファイルを使い、画像は傾向の説明にだけ使うことにしました。

カンさんは、ダッシュボードからダウンロードしたCSVファイルを数値の根拠として添付し、合計と前週からの増減については、スプレッドシートで計算した値を併せて渡しました。画像は、「グラフで目立つ変化を二つ言葉で説明せよ。数字は使うな」という依頼にだけ使いました。この週間要約は、毎週同じ形式で繰り返す軽い作業です。そこで、大きな推論モデルの代わりに、速い通常のモデルでも基準を満たせるか、4週間にわたって比較しました。結果が同じだったため、速いモデルを標準として採用しました。

要点は、画像が得意なこと（全体像の説明）と元データが得意なこと（正確な数字）を分け、誤りを読み取りと解釈の段階に分けて対処したことです。

間違えやすいポイント

1. 「具体的なら正確だ。」 事件番号、日付、小数点付きの数字は信頼できそうに見えます。しかし確率的生成は、形式がもっともらしい偽情報を容易に作ります。具体性はむしろ確認すべきサインです。
2. 「何度尋ねても同じ答えなら事実だ。」 同じモデルが、同じ誤りを繰り返すことはあります。質問を繰り返すことは、事実確認の代わりにはなりません。ただし、答え同士が食い違う場合には、疑うべきサインとして使えます。
3. 「温度を0にすれば正確になる。」 温度を下げても正確さは保証されず、0でも完全に同じ結果にならない場合があり、モデルによっては既定値を変えるとかえって性能が落ちます。正確さは根拠の提供と検証で確保します。
4. 「コンテキストウィンドウが大きければ最新情報も知っている。」 コンテキストウィンドウは読むことのできる量であり、知識のカットオフは学習した時点です。この二つは、互いに異なる軸の話です。
5. 「出典が付いていれば検証済みだ。」 出典が実在しても段落が主張を裏付けない場合があり、検索結果自体が古い場合もあります。出典表示は確認の出発点です。
6. 「反論したら答えを訂正したので、今度は正しい。」 モデルには、利用者の反論に合わせて答えを変える傾向があります。どちらの答えが正しいかは、外部の根拠を使って判断します。
7. 「高価な推論モデルが常によい。」 単純な作業を大量に処理する際に推論モデルを使うと、遅くて費用が高くなるだけの場合があります。推論モデルが、最新の知識をより多く持っているわけでもありません。
8. 「写真としてアップロードすれば、使うスペースも少なく、数字も正確に読める。」 画像もコンテキストウィンドウを消費し、スペースを節約できるかどうかは解像度によって異なります。小さな文字、表、グラフの軸は、代表的な読み違いの箇所です。

ひと目でわかるまとめ

公式ドキュメントで確認する

• OpenAI — Understanding and counting tokens：トークンの定義、英語の目安、推論トークンの課金、出力上限。
• Google — Understand and count tokens：Geminiの目安、画像・音声・動画のトークン計算。
• Anthropic — Context windows：作業記憶としてのコンテキストウィンドウ、コンテキストの劣化。
• Anthropic — Models overview：二つの知識のカットオフの定義、グレード別の用途。
• Anthropic — Reduce hallucinations：「わからない」と答えることを認める、先に引用させる、根拠がなければ主張を撤回させる、複数回実行して結果を比較する方法。
• Anthropic — Vision：画像入力の限界（低画質、位置判断、計数、AI生成画像の判別）。

セルフチェック

1-1. トークン、コンテキストウィンドウ、知識のカットオフが、それぞれ「何を測る言葉」か、一行ずつ区別して書いてください。

1-2. あるモデルの文書には、信頼できる知識のカットオフが3月、学習データのカットオフが5月とあります。4月の出来事を尋ねたとき、答えをどう扱うべきか説明してください。

1-3. 推論モデルの答えは2行なのに、使用量画面には長い報告書を受け取ったとき並みの出力トークンが計上されました。考えられる理由を書いてください。

1-4. 次の四つの出力に、最も適切な検証方法を一つずつ対応させてください。出力：（ア）新商品の宣伝文句、（イ）四半期別売上合計、（ウ）競合の発売日、（エ）顧客離れの原因の解釈。方法：原文との照合、別のツールでの再計算、前提と反例の確認、目的・読者・制約に合うかの評価。

1-5. 手書きの紙のアンケート20枚を撮影し、AIに設問別の回答数を数えさせます。起こりうる誤りを二つと、それぞれへの対応を書いてください。

1-6. 新しい会話を五つ作り、同じ質問をすると、5回とも同じ答えでした。この結果からわかることと、わからないことを一文ずつ書いてください。

1-7. あるチームには、毎日届く商品名500件の英語表記統一、月に一度の新市場進出検討メモ、週2回の社内日程通知の下書きという三つの業務があります。業務ごとのモデルのグレード選択規則を2〜3行で設計し、その規則が適切か確かめる方法も書いてください。

実習課題