コンテキストウィンドウ入門 AIの作業机を
のぞいてみよう。

本棚にあることと、今読めることは違う

あなたは、友だちと学校新聞をつくることになった。図書室の一角には、文化祭のメモ、行事の案内、写真、去年の新聞が広がっている。AIに「この資料から、初めて読む人にもわかる記事を書いて」と頼もう。学校新聞の経験がなくても、家族旅行の予定表や好きなゲームの攻略メモを作る場面に置き換えて読めるよ。

AIの画面に昔の会話がずっと残っていると、AIも全文を毎回読んでいるように見える。でも、画面に残る履歴と、モデルに今回渡される内容は別だ。製品は会話を保存しながら、モデルに渡す内容を選んだり、短くしたり、必要な部分を取り出したりすることがある。

そこで登場するのが「コンテキスト」。今回の質問を理解するための手がかり、という意味だ。「それを赤くして」の「それ」が何なのかは、前の会話を読まないとわからない。その前の会話も、記事の材料も、作業のルールも、返事を作るときの手がかりになる。

その情報を扱える範囲を、コンテキストウィンドウと呼ぶ。ウィンドウは、窓。いま見えている範囲を指す言葉だ。机のたとえでは、いま資料を広げて作業できる面積にあたる。

「覚えている」にも、いろいろある

AIが会話の中であなたの名前を言えたなら、今回の机に名前が載っていたのかもしれない。製品の保存メモ機能から名前が取り出されたのかもしれない。毎回同じ仕組みとは限らないし、名前を言えただけで「全履歴を永久に暗記した」とは判断できない。

さらに、AIが一般的な日本語や計算のしかたを知っていることは、毎回の机にその教科書が置かれているという意味でもない。訓練で身につけた能力、今渡した資料、製品が保管する記録。この三つを分けると、話がずっと整理しやすくなる。

トークンは「文字数」と同じではない

机の幅や奥行きを測るのに、センチメートルを使うね。AIの情報量を数えるときによく使う単位は、トークンだ。文章をAIが処理しやすい部品に分けた、その一つ一つを数える。部品には一文字、単語の一部、複数文字、句読点などが入ることがある。

「東京で猫が昼寝しています」という文を、人間ならひと続きの文として読む。AIに渡すときは、ある決まりで部品に分かれる。この分ける仕組みをトークナイザーという。モデルごとに使う仕組みが違う場合があるから、同じ文章でもトークン数が同じとは限らない。

日本語は「何文字で何トークン」と固定できない

漢字、ひらがな、英字、絵文字、長いURL、プログラムの記号。それぞれが同じ効率で部品に分かれるとは限らない。「日本語は必ず一文字一トークン」「一トークンはいつも何文字」という換算を覚えると、資料の入る量を間違えやすい。

たとえば「AI」と「エーアイ」と「人工知能」は、近い意味を持つ。でも文字数も部品の分かれ方も違う。長いURLや、短いURLが大量に並ぶ一覧が、読みやすい文章より多くの部品を使うこともある。意味の量、見た目の長さ、トークン数は、きれいに一対一では結びつかない。

正確に知りたいなら、対象モデルに合った公式の数え方や、その製品が示す使用量を見る。ここで「文章を短くすればいい」とだけ考えるのも惜しい。短くしすぎて大事な条件を落とすと、使う部品は減っても仕事は失敗するからだ。

KとMは、桁を読むための略号

この教材ではKは千、Mは百万として読む。500Kは500,000、1Mは1,000,000。Kは机の型番でも、賢さの点数でもない。単に大きな数字を短く書いている。

ただし「約1M」と「1,050,000」は、丸め方が違う。細かい仕様を比べるときは、元の数字まで確認しよう。「約1Mだからぴったり100万」と置き換えると、50,000の差を消してしまう。

読む資料だけでなく、返事を書く空きも要る

大きな机いっぱいに紙を積んだら、どこで原稿を書く？　AIの利用でも、渡す資料の量と、作ってほしい答えの長さを一緒に考える必要がある。

入力はあなたの最新メッセージだけとは限らない。前の会話、優先される指示、道具を使った結果、画像の情報などが加わる。たとえばAIがファイルを読む道具を使ったら、道具から返った本文も次の作業の材料になる。自分で一文字も打っていない場面でも、机は埋まっていくことがある。

考え方の入口としては「読む分＋作る分が、扱える範囲に収まるか」と見るといい。実際の製品では、出力の予約、推論に使う量、隠れた指示の扱いなどで計算が変わる。答えを組み立てるための処理を、ここでは推論と呼ぶ。推論に使うトークンが出力側の予算に含まれる方式もある。画面に見える答えだけが、出力のすべてとは限らないんだ。

もう一つの壁もある。「机に空きはたくさんあるけれど、一回に書ける回答には別の長さの上限がある」という壁だ。公式の最大コンテキストが1,050,000で、最大出力が128,000と書かれていても、両方を同時に満額使える保証ではない。最大出力の値を、いつでも作られる回答の長さとも混同しないでね。

上限にぶつかったときの動きは製品次第

上限を超えたら、エラーになる製品も、古い情報を渡さなくなる製品も、要約に置き換える製品もある。自動処理があるからといって、大事な条件が必ず保護されるとは限らない。表示された警告や説明を読み、必要な条件を改めて渡すといい。

「いま使っている割合」が画面に出ても、何を含む割合なのかを確認しよう。入力だけなのか、予約した出力も含むのか、いつ更新されるのか。違う製品のパーセントを、そのまま比べても同じ物差しにならないことがある。

「Solは標準500K、最大1M」は、対象を分けて確認する

ニュースで「このAIは最大1M」と聞いた。友だちは「普段は500Kだよ」と言った。どちらが本当？　この問いでは、数字を比べる前にどのモデルを、どの製品で、どんな条件で使う話かをそろえる必要がある。

数字には、別々の名札がついている

モデルの上限は、橋が耐えられる重さに似ている。製品の既定値は、ふだん通す車の運用ルール。あなたの設定は、運転手が出した希望。今回の使用量は、実際に載せた荷物だ。橋の最大値を知っても、どの車でもその重さで通行できるとまでは言えない。

「Sol」とだけ言うと、モデルの版が曖昧になる。GPT-6.1 Sol、GPT-6 Sol、別のモデルでは仕様が違い得る。さらに公式のモデル案内では、GPT-6.1 Sol／GPT-6 Sol／GPT-6 LunaをWork・Codexで使えるモデルとして説明し、Chatでは利用できないと明記している。APIのモデルページを見て「自分のChat画面でも同じ」と結論しないこと。

入力欄に大きな数字を書くだけでは、机は広がらない

設定を変更できるサービスでも、モデルやサービスが対応する範囲は別にある。「容量を100万にして」と書くだけで、その範囲を超えられるわけではない。ゲームの設定に「飛行速度1000」と入力しても、ゲームが受け入れなければ飛べないのと同じだよ。

この仮定なら、600K相当の資料は500Kの範囲にそのまま入らず、1Mの範囲なら入力と出力の配分次第で扱える可能性が生まれる。でも、40K相当しか使わない質問では、どちらも容量内だ。机が大きくなったから、必ず答えが長くなるわけではない。

「最大1M」と書いた記事を読んだら、「モデル名と版は？　APIなのか製品画面なのか？　標準と最大のどちらか？　出力上限は？　確認日は？」を尋ねよう。大人の話にケチをつけるためではない。条件をそろえれば、自分の使い方に役立つ情報になるからだ。

最大容量と、毎回広げる量は別の話

もし広い机を使えるなら、最初からいつも最大にしておけばよさそうだね。この疑問は自然だ。ただし、ここでは「実際にSolのある製品で最大が既定ではない」と確定して話しているわけではない。最大と既定が違う設計にする理由を、一般的な考え方として探ろう。

まず、大きな机を予約することと、大きな机を紙で埋めることを分ける。机の容量を1Mにしただけで、短い質問が自動的に1Mぶんの資料へ増えるわけではない。速度や費用に影響するのは、実際に渡す量、作る量、推論に使う量、製品の仕組みなどだ。容量の設定だけから「必ず遅い」「必ず高い」と言うのは早すぎる。

使い方のコツ · 以下は一般的な設計上の考え方

たくさん載せると、読む仕事が増えることがある

学校新聞に載せる「今週の話題3本」を作る場面で考えよう。今週の資料3本と書式の指示があれば書けるのに、先月の話題100本、過去の没原稿、何年も前の作業ログまで載せたらどうだろう。モデルは、その情報を処理することになる。実際の処理時間や料金はモデル・製品・料金方式によるが、扱う量が増えることで待ち時間や費用が増える場合がある。

一方、キャッシュと呼ぶ再利用の仕組みなどで、一部の繰り返し処理が軽くなることもある。だから「長さに比例して必ず何倍」とは決められない。今使う製品の表示や公式料金、作業の実測で確かめる話だね。この教材の体験は時間や費用を測っていない。

必要な資料を残しやすくするための運用

製品が通常の範囲や整理のタイミングを選ぶ理由には、よくある作業での速さ、処理資源の配分、扱いやすさ、安定した運用などが考えられる。これは一般的な設計上の理由で、特定製品の担当者が公表した理由としては扱わない。

500Kまでで自動整理する仮定なら、会話が延々と増え続ける前に、次の仕事の材料へまとめ直せる。代わりに原文の細部を引き継げないリスクがある。1Mまで保持する仮定なら、長い資料をそのまま並べやすい。代わりに不要な材料まで長く残すことがある。どちらも、用途に合わせて判断したい。

「最大を使う？」より「何を残す？」

容量を選べる環境なら、まず資料と出力の見込みを考える。必要な原文が通常の範囲に入りきらないか。要約で落としたくない細部があるか。増えた待ち時間や費用が、実際の作業で許容できるか。その答えを見て容量を決めればいい。

短い質問に大きな容量を使うこと自体が、ただちに無駄とは限らない。広い机に紙を8枚しか置かなくてもいいんだ。ただ、広い机があるからといって、関係のない紙まで24枚ぶん集める必要はない。この二つを分けて話せたら、もうかなり正確な説明ができているよ。

容量が増えても、知能や永久記憶が増えるとは限らない

友だちが「机が2倍になったら、頭のよさも2倍になる？」と聞いた。あなたは、数学の宿題を思い出す。広い机に教科書を10冊並べても、問題の解き方が急に2倍うまくなるわけではない。

AIでも、たくさんの材料を受け取れる能力と、その材料から正しく推論する能力は別だ。広い範囲を使えることで、答えに必要な証拠を同時に渡せる利点はある。ただし、誤った資料を渡せば誤った結論へ向かうこともあるし、正しい資料があっても読み違いや計算ミスは起こり得る。

机を広くする設定が、保存メモ機能を有効にするとは限らない。会話を閉じたあとに情報が残るか、別の会話へ引き継がれるか、保存された情報が返事に使われるかは、製品の別の機能や設定の話になる。

「大量に入る」は、品質保証の印ではない

取材で「開催日は10月18日」という資料と「開催日は10月19日に変更」という資料があるとする。両方を読める範囲に入れれば、変更を見つける材料はそろう。でも、どちらが新しいかを見ずに答えたら、日付を間違える。容量を確保したあとにも、更新日や優先順位の整理が要る。

出典を示すよう頼む、重要な数字を原文と照合する、必要なら人が確認する。こうした作業は大きな容量でも省略できない。逆に、難しい仕事を小さく分けて資料を整えると、容量を増やさずにうまく進む場合もある。

全部入っても、大事な一行が使われるとは限らない

家族旅行の相談を100回続けた。最初は「歩く距離は短く」、途中で「午前は博物館」、さらに「雨なら屋内」と決めた。後半には観光地の候補や店の情報がたくさん増えた。最後にAIが作った予定は、長い徒歩移動と、雨の日の屋外イベントでいっぱいだった。

ここで考えられる原因は一つではない。最初の条件が今回の入力から外れていたかもしれない。要約で抜けたかもしれない。条件は入力に残っていたのに、回答に使われなかったかもしれない。「入っていた」と「正しく使えた」を分けると、直し方も変わる。

関連性の低い情報が混ざる

今日のニュースをまとめる材料に、去年の冗談や今は使わない文体ルールが混ざると、何が有効なのか曖昧になる。古い指示と新しい指示が矛盾することもある。「見出しは短く」と「見出しで詳しく説明して」が並んでいたら、どちらを優先するかを明記したい。

情報が長いと、必要な箇所を取りこぼしたり、離れた条件をうまく結びつけられなかったりするリスクがある。ただし、長いほど必ず品質が落ちるわけではない。モデル、課題、情報の位置、指示の明確さなどで結果は変わる。必要な長文を丁寧に渡したほうが、短く削った資料よりよい答えになる仕事もある。

読み違いを直すなら、まず条件を見える形に

「忘れないで！」だけを連呼するより、現在有効な条件を短い一覧で渡すほうが作業に役立つ。「小さい子も参加」「雨なら屋内」「変更してよいのは午後の予定」のように、どこまで守るべきかを具体的に書こう。

重要な条件を最初と最後に置く工夫はあり得る。でも、それだけで必ず守られるという魔法ではない。条件のチェック表を作り、完成結果を一つずつ照合するところまで組み合わせよう。「本文は読みやすいが出典がない」など、部分的な失敗も見つけやすくなる。

候補や検索結果を全部入れ続けるより、今の目的に関わる情報、採用した予定、確認した結果を残す。終わった試行と現在の方針を分ける。これはAIのためだけの整理ではない。翌朝の自分も、「何をしていたんだっけ？」から早く戻れるよ。

Auto Compactは、机を片づけて引継ぎを作るしくみ

会話が長くなったとき、次の作業を続けやすいように内容を整理する機能がある。これがAuto Compact（自動コンパクション）と呼ばれるものだ。compactには、小さくまとめるという意味がある。

机の紙が増えたら、新聞づくりのチームは「決定事項」「やりかけの仕事」「気をつける条件」を新しい紙にまとめる。その紙と、必要な原資料を机に残して続きを始める。自動コンパクションを考えるときは、この引継ぎのイメージが役に立つ。

ただし、このメモは理解用の比喩。実際のコンパクションが、いつも人間の読める短い要約を作るという意味ではない。APIでは、次のリクエストへ渡すための暗号化された圧縮項目を使う方式も公式に説明されている。その内部形式を、人間向けメモと同じものだと考えないでね。

どこがうれしい？

自動で整理が行われれば、上限へ近づくたびに会話を最初からやり直さずに済む。長い会話の中に埋もれた現在の目的が、短い引継ぎで見えやすくなることもある。過去の試行を減らし、今の方針に集中する助けになる。

渡す内容が短くなれば、その後の処理量や待ち時間、費用を抑えられる場合もある。ただし、整理そのものにも処理が必要だし、製品によって料金や処理方式は違う。「コンパクションすれば必ず何円安い」と、この教材から計算することはできない。

どこが困る？

要約は、元の文章の全情報を同じ形で残す作業ではない。短くするために情報を選ぶと、「公開しない」「数値は未確認」「最後の版だけ採用」のような小さな条件が落ちることがある。細かい例外、正確な引用、途中で否定された案が、うまく整理されない場合もある。

しかも、引継ぎが一見すっきりしていると、何が抜けたか気づきにくい。誤った決定事項が引き継がれれば、その後の会話もその誤りを前提に進む。整理を何度も重ねる中で、細部がさらに薄くなる可能性もある。毎回必ず劣化するという意味ではないが、重要な条件は別に管理したい。

ZIPファイルとは違う

ZIPのような可逆圧縮は、決められた方法で元のデータへ戻せる。可逆は「元に戻せる」という意味だ。文章を選んで短くした引継ぎは、元の全文を完全に戻せるとは限らない。たとえば「会議で日程を決めた」というメモだけから、会議の全発言は復元できないよね。

元の会話が製品に保存されていれば、画面や別の方法で見返せる場合はある。それは保管された原資料に戻る行為で、短い引継ぎを解凍して全文を復元したわけではない。ここを分けると、「要約から消えた」と「どこにも保存されていない」の違いも説明できる。

「使う／使わない」だけで決めなくていい

旅行計画や長いレポートでは、整理しながら続ける利点が大きい。正確な引用を扱う取材では、短い引継ぎだけに頼ると危うい。自動整理を利用しつつ、守る条件をメモに残し、引用を原資料で確かめる。組み合わせて使えるんだ。

たった一行の省略で、仕事の意味が変わる

あなたは、地域の星空観察会の案内文を作っている。チームで決めた条件はこうだ。「対象は13歳以上の初心者。参加費はまだ未定。申し込みはまだ受け付けない。数字の説明には出典を添える。まず下書きを作る」

これを「初心者向けの星空観察会の案内を作成」とまとめたら、何が消えただろう。対象の年齢、未定の料金、受付前、出典、下書きという段階。全部、仕事を正しく進めるための条件だ。主題だけ残しても、仕事のルールまでは残らない。

落ちやすいのは、主題の脇にある条件

「何を作るか」は目立つ。「何をしてはいけないか」「どこまで任されたか」「どれが未確認か」は脇に置かれやすい。それでも、実務ではこの脇の条件が大きな意味を持つ。完成原稿を作る許可と、公開する許可は違う。調べる依頼と、確定した事実を発表する依頼も違う。

取材の引用なら、発言そのものだけでなく、誰がいつ何について話したかも重要だ。「結末に驚いた」という要約だけでは、元の発言を引用したことにはならない。文脈と正確な表現を原資料へ戻って確認しよう。

良いメモは、目的・条件・原資料の場所まで残す

明日の自分が、今の仕事を15秒で思い出せるメモを作ろう。AIへ渡す引継ぎも、その延長だ。「いろいろ話して旅行の計画を立てた」だけでは、次に何をすればいいかわからない。目的、守る条件、決まったこと、まだ決まっていないことを分ける。

「確認済み」と「たぶん」を混ぜない

「博物館は開いている」と書くと、旅行の日にも確認済みに見える。「公式案内では火曜休館。旅行予定日の臨時休館は未確認」と書けば、次の人が何を信じてよいかわかる。根拠の範囲を残すことも、引継ぎの中身だよ。

決定を残すときは、理由を一言添えるといい。「徒歩の区間を短くする。小さい子も一緒に歩くため」。理由がわかれば、次の担当者が景色のよい長距離コースへ変えてしまう失敗も避けやすい。

自分で使える、引継ぎのひな形

下のメモは自由に書き換えられる。このページは入力を外へ送らず、ブラウザの保存領域にも自動保存しない。閉じたり再読み込みしたりすると入力は消えるので、残したい場合はコピーするか、ダウンロードして手元に置こう。共有する前には、氏名や機密が入っていないか自分で確認してね。

メモの品質も確かめよう

AIに引継ぎメモを作ってもらったら、元の条件と照合する。「残した制約を一覧にして」「未確認事項は未確認と書いて」「原資料を確認したことにしないで」と頼むと、点検しやすい形になる。できたメモを人が読んで、抜けや誤りを直す。

メモが長くなりすぎたら、現在有効な内容を上に置き、作業の細かい記録は別のファイルへ分ける。短い道案内と、詳しい地図の組み合わせだ。地図まで捨ててしまう必要はない。

要約・原資料・RAG・新しい会話を使い分ける

机が埋まったとき、紙を短くまとめる以外の方法もある。本棚の資料から、その質問に必要なページだけ取り出せばいい。外部の情報を探して取り出し、答えを作る材料に加える方法をRAGという。Retrieval-Augmented Generationの略で、この教材では「探してから、材料を添えて答える」と覚えておこう。

「去年の読書会の参加人数は？」という質問なら、去年の報告書の参加人数の欄を探す。全資料を毎回机へ広げなくても、必要な証拠が見つかる場合がある。検索と回答を組み合わせる考え方だ。

RAGにも、探しそこねがある

古い版を見つけたら、古い人数で答えてしまうかもしれない。検索語が合わなければ、必要なページを見つけられないかもしれない。資料を細かく分けたことで、前後の条件が切れてしまうこともある。「注記：オンライン参加は含まない」が別の場所にあるなら、数字の欄だけでは足りない。

RAGで見つかった情報も、机に載せる入力になる。RAGはコンテキストの上限をなくす魔法ではない。必要な部分を選び、限られた範囲を使いやすくする方法だ。多数の資料を横断して矛盾を探す仕事なら、一箇所だけ取り出すより、比較する資料を広くそろえる必要がある。

新しい会話は、きれいな机を用意する選択

学校新聞が完成し、家族旅行の相談を始めるなら、会話を分けると古い指示や資料を引きずりにくい。目的が大きく変わるときも、新しい会話が便利だ。ただし、新しい会話へ必要な条件が自動で全部引き継がれると考えない。必要なメモと原資料を改めて渡す。

同じ仕事でも、会話に古い案が多すぎて整理しにくいなら、現在の決定をまとめて新しい会話へ移ることができる。「新しい会話にすれば性能が必ず上がる」わけではない。足りない情報を入れ直す手間と、古い混乱を減らす利点を比べよう。

好みの保存と、今回の希望

「ふだんは甘さ控えめが好き」という保存メモがあっても、今日は「甘いココアが飲みたい」と頼むかもしれない。過去の好みを参考にすることと、今回の明確な希望を理解することは別。現在の依頼と関係の薄い記憶を全部載せる必要はない。

製品の記憶機能とRAGは、同じ名前の仕組みではないし、どちらか一方しか使えない関係でもない。保存した情報を探して取り出すこともあり得る。ただし、どんな情報が選ばれるか、どれだけ渡されるかは製品の説明で確認する。公式のDot（継続的な手助けをする製品機能）の案内も、対話のコンテキストには情報の選択があることを説明しているが、Dotの実効容量の数字はそこで公表されていない。

道具を一つだけ選ぶ必要はない。検索で原資料を探し、引用は原文で確認し、現在の目的は引継ぎメモに残す。大きな机も、この組み合わせの中の一つだ。

身近な4つの場面で、何を机に載せよう？

学校新聞を作ったら、今度は自分の暮らしへ知識を持って帰ろう。調べ学習、旅行、読書会、友だちへの説明。同じAIチャットでも、欲しい答えに合わせて机の材料が変わる。以下はすべて架空の例だよ。

調べ学習：主張を比べるには、日付と出典も一緒に

「町の公園を増やすと、夏の暑さは和らぐ？」という発表を作るとする。机には、今回読む資料、誰が何を調べたか、調べた年、出典、発表を聞く人の想定を置く。見出しだけ集めると、「どこで」「どんな条件なら」が抜けることがある。

たとえば、一つの資料は木陰の温度を調べ、別の資料は町全体の平均気温を調べているかもしれない。この二つは、同じ質問への同じ数字ではない。AIに「数字が違うから、どちらかは間違い」と早く決めさせるより、対象と測り方を比べるよう頼もう。この教材の500Kと1Mの読み方と、同じ発想だね。

開始メモの例：「この3本の資料を比べる。対象の場所、年、調べ方を分けて書く。未確認の数字は断定しない。発表は5分。出典を残し、専門用語はその場で説明する。」

広い容量なら多数の資料を並べる助けになる。ただし、資料を渡しただけで、全部の主張が確認済みになるわけではない。結論に使う数字は、元の図表や本文に戻って、何を数えた数字なのかまで照合する。引用を使うときも、AIが言い換えた文を原文として発表しない。

旅行計画：おすすめより先に、守る条件を渡す

家族の日帰り旅行を計画する。候補は博物館、公園、商店街。AIに「楽しい順番で回って」とだけ頼むと、長い徒歩移動や、夕方に間に合わない予定になるかもしれない。「小さい子も参加」「徒歩は短く」「雨なら屋内」「夕方までに帰る」を、行き先の候補と一緒に渡そう。

相談が長くなったら、過去の候補を全部残すより、現在の決定を引き継ぐ。「午前は博物館で決定」「公園は晴れた場合だけ」「店の予約はまだしない」。採用した予定と、検討しただけの案を混ぜない。料金や営業時間は古い情報があり得るので、旅行の日に合う公式案内で確認する。

宿泊を含む長い旅行なら、情報を日ごとに分ける方法もある。ただし、全日程を通じた予算や帰宅時刻は、日ごとのメモにも必要だ。作業を小さく分けるときは、「部分を分けても、全体の約束は残す」と覚えておこう。

読書会の記録：短いまとめと、正確な発言を分ける

友だちと本の感想を話し、記録をまとめる。「好きだった場面」「意見が分かれた点」「次に読む本」を整理するなら、要約が役立つ。一方、誰かの発言をそのまま紹介するなら、元の記録で表現と前後の文脈を確かめる必要がある。

「結末に驚いた」というメモだけから、「結末は最高だった」と引用符つきの発言を作ると、気持ちを変えてしまうかもしれない。驚いた理由は、うれしかったからとは限らないよね。AIが自然な文章に整えても、それが本人の正確な言葉になったとは限らない。

引継ぎの例：「感想を話題ごとに整理する。直接引用は元の記録で再確認。次回の候補は2冊あるが、まだ決定していない。記録を他の人へ見せるかは別に相談する。」

RAGや検索で該当する発言を取り出す方法もある。ただし、見つかった一文だけでは前後の意味が抜けることがある。引用の言葉だけでなく、何について話したかも見よう。読み返して答えがわからない部分は、わからないまま残して確認する。

友だちに教える：楽しいたとえに、条件を添える

「AIには作業机みたいな範囲があるんだよ」と説明したら、友だちが「じゃあ大きい机のAIは、絶対賢いんだ！」と言った。そこで文化祭の200枚のメモを思い出そう。置けることと、正しい一行を見つけられることは違う。具体例を一つ添えると、容量と能力を分けて説明しやすい。

数字を紹介するときは、モデル名、使うサービス、上限か既定値か、確認日、出典も渡す。「約1M」とだけ言うより、「このモデルのAPI仕様に書かれた最大値。あなたのアプリで使える範囲は別に確認する」と言えば、相手が自分の画面でも同じだと思い込むのを防げる。

机のマスを動かす体験を見せるなら、「これは仕組みを理解するおもちゃ。実際の速度、料金、正解率の実験ではない」と伝えよう。Auto Compactも「次へ進むための引継ぎ」と説明し、必ず人間向けの要約だけで動くわけではないことを添える。

よくある誤解を、ひとことずつ解く

こうした誤解を見つけたとき、相手を言い負かす必要はない。「その数字はAPI？　それとも今使っている製品の設定？」と聞けば、条件をそろえられる。正確な質問は、会話を楽にする道具にもなる。

6問のクイズと、30秒の説明チャレンジ

ここまで読めたら、用語を暗記するより、関係を説明できるかを試そう。答えを間違えても、説明を読んで戻ればいい。採点結果は保存も送信もされない。

家族や友だちへ、30秒で話してみよう

まず画面から目を離して説明してみよう。「机」「本棚」「引継ぎ」の関係を、相手が思い浮かべられるかな？　下には、言葉に詰まったときの例を置いたよ。

数字の話までできそうなら、こう足してみよう。「最大値と普段の設定は別。モデルと製品とプランをそろえて比べる必要がある。日本語の文字数を、トークン数へ固定で換算もできないんだ」

もっと自分の言葉にしたいなら、机をリュックや料理台に置き換えてみて。ただし「リュックに入れたら全部いつでも正確に覚える」のように、比喩から本物にない性質を足さないこと。たとえの限界まで話せたら、相手が別の例へ置き換える助けにもなる。

用語の小さな辞典

言葉を忘れたら、ここへ戻ろう。丸暗記より、「その言葉で何を説明しているか」が大事だよ。

コンテキスト

今回の質問や作業を理解するために渡される手がかり。会話、指示、資料、ツールの結果など。1章

コンテキストウィンドウ

モデルが一度の処理で扱える情報の範囲。ここでは作業机の広さにたとえた。保存できる全履歴とは別。1章

トークン／トークナイザー

トークンは、AIが情報を処理するときの部品の単位。トークナイザーは文章をその部品に分ける仕組み。文字数への固定換算はできない。2章

K／M

この教材ではKは千、Mは百万。500K＝500,000、1M＝1,000,000。「約1M」と正確な数値は区別する。2章

入力／出力

入力はAIへ渡す材料。出力はAIが生成するもの。見える返事以外の推論量などの扱いはモデル・製品で変わる。3章

モデル／製品

モデルは情報を処理し答えを生成する仕組み。製品はモデルを使うための画面、道具、設定などを含むサービスやアプリ。モデルの仕様と製品の設定を分けて確認する。4章

API

プログラムから機能を呼び出すための窓口。APIのモデル仕様は、別の製品画面での既定値をそのまま保証しない。4章

既定値／デフォルト

特に変更しないときに選ばれる初期設定。対応できる最大値とは違う場合がある。4章

プラン

契約の種類。利用枠や使える機能などの条件が異なる場合がある。数字を比べる際は対象条件をそろえる。4章

推論

与えられた情報から関係を考え、答えを組み立てること。AIの内部処理や予算の扱いは、人間の思考と同一ではない。3章

遅延（待ち時間）

結果が返るまでの待ち時間。入力・出力の量や製品の仕組みなどで変わる。容量だけからは決められない。5章

キャッシュ

以前の処理の一部を再利用して、同じ作業の負担を軽くする仕組み。条件や効果は製品ごとに違う。永久記憶の保証ではない。5章

Auto Compact／自動コンパクション

長い会話を、続きを進めるために整理する機能。選別や要約を含み得る。何が残るかや発動条件は実装による。8章

しきい値

ある処理を始める境目となる値。コンパクションを始めるしきい値と、モデルの最大容量は別の設定。4章

可逆圧縮

圧縮したデータを元の形へ戻せる方式。要約した文章は、このような完全復元を保証しない。8章

引継ぎメモ

次の作業を始めるために、目的、制約、決定、未確認、原資料の場所などを残す記録。10章

原資料／出典

原資料は、確認のもとになる文章や記録。出典は情報がどこから来たかを示すもの。要約だけから引用や数字を確定しない。10章

RAG

必要な情報を検索で取り出し、生成する答えの材料に加える方法。検索の抜けや資料の切り取り方には注意が要る。11章

レスポンシブ

画面の幅に応じて、文字や図の並び方を調整する作り。この教材もスマホとPCで配置が変わる。

公式出典と、確認できた範囲

数字の話は、後から変わることがある。この教材では、仕組みの説明、架空の学習例、公式仕様の確認を分けている。公式リンクへはインターネット接続が必要だが、本文・図解・体験の利用に接続は要らない。

1. GPT-6.1 Sol — APIモデル仕様対象：APIのGPT-6.1 Sol。context window 1,050,000 tokens／max output 128,000 tokens。入力272K超のAPI料金条件もここで確認。全製品の既定値の根拠ではありません。
2. Models — ChatGPTの公式モデル案内対象：モデルと製品の案内。GPT-6.1 Sol／GPT-6 Sol／GPT-6 LunaがWork・Codexで使え、Chatでは利用できないことを確認するために参照。
3. Configuration Reference — 公式設定リファレンスmodel_context_windowとmodel_auto_compact_token_limitを別の設定として確認。キーの存在は、対応上限を超えて使える保証ではありません。
4. Slash Commands — 公式コマンド案内/compactは現在のチャットのコンテキストを圧縮。クライアント差があるため、全画面共通の操作としては説明していません。
5. Compaction — API公式ガイドcontext_management／compact_threshold、暗号化された圧縮項目の引継ぎ。例の200,000は標準値の根拠ではありません。人間向けの単純要約と同一とは断定しません。
6. Tasks and memory — Dotの公式案内対話コンテキストへの情報の選択を確認。全会話が常時全量渡されるとは限りません。Dotの実効コンテキスト容量は、この案内から数値断定していません。

まだわからないことを、わからないまま残す

対象を指定しない「Solの標準500K」という主張は、モデルの版、製品、プラン、実設定、日付をそろえて確認する必要がある。公式説明に書かれていないことを、想像で補わない。「未確認」を残すのは、説明をさぼるためではなく、確認済みの事実を守るためだ。

この教材を読む時点で、仕様が変わっている可能性はある。数字を自分の利用サービスへ当てはめる前に、公式の説明で対象と日付を確かめよう。確認できた新しい数字があっても、この教材の仮定の500K対1Mの例とは分けて考える。

疑問を解くときの聞き方

「私が使っている製品は○○、モデル名は○○、プランは○○。この数字はモデル上限か、既定値か、現在の使用量か。公式のどの説明に書かれているか」を、教える人や公式の案内で確認しよう。どこが曖昧かを言葉にできれば、次の調査はずっと進めやすい。

探検の終わりに、身近な頼みごとを一つ思い浮かべてみて。「週末の予定を考える」「本の感想をまとめる」「発表の資料を比べる」。その仕事の目的と、絶対に守ってほしい条件を短いメモにしてみよう。次に誰かが「AIの記憶は100万！」と言ったら、「それ、何を数えた100万？」とやさしく聞いてみる。ここで学んだ机の使い方は、どんなサービスを使うときにも、条件を確かめる入口になる。

関連する教材

• AIの「読める量」と料金のしくみ —— トークン・コンテキスト・メモリーの超初心者ガイドトークンの数え方、APIの料金境界、キャッシュを、数字を動かせる料金計算機つきで学びたい人へ。
• AIに記憶はない —— キャッシュのやさしい話第5章で触れたキャッシュのしくみを、もう少し詳しく知りたい人へ。
• AIは長い文章で賢くなるとは限らない —— Context Rotの研究をやさしく解説入力が長くなるほどAIの回答が不安定になる現象を、18モデルを比べた研究から知りたい人へ。