前回との接続——この講義の役割
前回のT-01では、モデルが入力と出力をトークンという単位で処理し、そのトークン数が費用を決めることを学びました。今回はその一歩先、モデルが一度の処理で読み込める情報量には上限がある、という話です。この上限を知らないと、長い会話でAIが前の話を忘れる理由も、費用が膨らむ設計の落とし穴も見抜けません。AI機能を設計するうえで欠かせない土台になります。
このスライドのポイント
- 前回T-01: モデルは入力・出力をトークンで処理し、そのトークン数が費用を決める
- 今回: モデルが一度の処理で読める情報量には上限がある
- この上限を知らないと、長い会話でAIが前の話を忘れる理由も、費用が膨らむ設計も見抜けない
定義——モデルは記憶しない、アプリが毎回送り直す
コンテキストウィンドウとは、モデルが一度の処理で参照できる情報量の上限のことで、T-01で学んだトークン数で測ります。ここで最も大切な構造を押さえます。モデル自体は、会話を記憶していません。会話が続いているように見えるのは、アプリ側が過去のやり取りを毎回まとめて送り直しているからです。これはJ-10で学んだステートレス、つまりサーバーは前回を覚えず状態はアプリ側が持つ、という構造とまったく同じです。そして送る情報が上限を超えた分は、削るか要約するかを、あらかじめ設計しておく必要があります。
このスライドのポイント
- コンテキストウィンドウ＝モデルが一度の処理で参照できる情報量の上限（トークン数で測る＝T-01）
- 核心: モデル自体は会話を記憶しない
- 続きの会話に見えるのは、アプリ側が履歴を毎回まとめて送り直しているから
- これはJ-10のステートレスと同じ構造——状態はアプリ側が持つ
- 上限を超えた分は、削るか要約するかの設計が要る
なぜ必要か——忘れる現象と費用の膨張
この構造を知らないと、まず「さっき言ったことを忘れる」という現象を説明できません。これはA-06で扱った文脈欠落を、仕組みの側から見た姿です。さらに、会話のたびに履歴を丸ごと送り直す設計をしてしまうと、やり取りを重ねるほど送るトークンが増え、S-10で学んだ費用が膨らみ続けます。この落とし穴を見抜けるかどうかが、実用に耐えるAI機能を作れるかどうかの分かれ目になります。
このスライドのポイント
- 知らないと:「さっき言ったことを忘れる」現象を説明できない（A-06の文脈欠落を仕組みの側から見た姿）
- 知らないと: 履歴を毎回丸ごと送り直す設計で、やり取りのたびに費用が膨らむ（S-10）
- この落とし穴を見抜けるかが、実用に耐えるAI機能を作れるかの分かれ目
構造——毎回の送り直しと、窓からの溢れ
仕組みを図で追いましょう。1回目の処理では、システム指示と最初の質問を送ります。2回目では、同じ指示に加えて、これまでの履歴と新しい質問をまとめて送ります。会話が進むほど、送る中身は積み上がっていきます。ところが窓のサイズ、つまり上限は固定です。入りきらなくなると、古い部分から順に窓の外へ溢れていきます。溢れた情報は、モデルにはもう見えません。
このスライドのポイント
- 1回目: 指示＋質問を送る
- 2回目: 指示＋これまでの履歴＋新しい質問を送る
- 会話が進むほど送る中身は積み上がる
- 窓のサイズ（上限）は固定——入りきらない古い部分から溢れる
Webアプリでの具体例——経費アプリのAI相談機能
具体例で見ます。経費アプリのAI相談機能で、長い対話を続けたとします。やり取りが積み上がると、最初のほうで伝えた前提が窓から溢れ、答えが少しずつぶれ始めます。対策はこうです。勘定科目のルールのような、絶対に守ってほしい大事な前提は、毎回いちばん先頭に固定で入れておきます。こうすれば、古い雑談が溢れても、肝心のルールは常にモデルの視界に残ります。この「毎回固定で入れる指示」の設計が、次回T-03のシステム指示につながります。
このスライドのポイント
- 経費アプリのAI相談機能で長い対話→最初の前提が窓から溢れ、答えがぶれる
- 対策: 勘定科目のルールなど大事な前提は、毎回いちばん先頭に固定で入れる
- 古い雑談が溢れても、肝心のルールは常にモデルの視界に残る
- この「毎回固定で入れる指示」が次回T-03のシステム指示につながる
技術サンプルカード——窓と溢れの図＋設計表
技術サンプルカードです。種別は構成図、目的はコンテキストに何を入れ、何を入れないかを設計として言葉にすることです。図では、固定サイズの窓に情報が積み上がり、上限を超えた古い部分が溢れる様子を表します。読み方の要点は二つ。窓のサイズは固定であること、そして何を残すかは自分で決められることです。設計表のとおり、固定ルールは毎回、直近の対話は残し、古い対話は要約し、全経費データは入れずに必要な分だけ検索して渡します。この最後の考え方が、次回以降のRAGにつながります。
混同しやすい概念——記憶している？送り直している？
混同しやすい点を整理します。「モデルが会話を記憶している」という見え方と、「アプリが履歴を送り直している」という実態は、まったく別物です。私たちには続きの会話に見えますが、モデルの側には毎回、初対面のように情報が渡されています。これはJ-10で学んだ、状態をどこに置くかという問題の、AI版にほかなりません。状態を持つのは、いつでもアプリ側です。
バイブコーディングでの確認点——まず中身を表示させる
確認点です。AI機能が「忘れる」「答えがぶれる」といった不調を起こしたら、原因を推測する前に、まずコンテキストの中身を見ます。AIへの質問例はこうです。「いまこのやり取りで、コンテキストに何が入っているかをそのまま表示してください」。中に入っているべき前提が溢れていないか、逆に不要なもので窓が埋まっていないかを確認します。これはP-10で学んだ切り分けを、AI機能に対して行う第一歩です。
このスライドのポイント
- AI機能が「忘れる」「ぶれる」不調を起こしたら、原因を推測する前にコンテキストの中身を見る
- 入っているべき前提が溢れていないか、不要なもので窓が埋まっていないかを確認
- これはP-10の切り分けを、AI機能に対して行う第一歩
- AIへの質問例:「いまこのやり取りで、コンテキストに何が入っているかをそのまま表示してください」
一問一答とまとめ
最後に一問一答です。会話の続きができるのは、モデルとアプリの、どちらの働きでしょうか。（間）答えは、アプリです。履歴を毎回送り直しているのはアプリであり、モデル自身は記憶していません。30秒でまとめます。コンテキストウィンドウは一度に読める情報量の上限で、超えた分は古いものから溢れます。だからこそ、何を毎回入れ、何を入れないかの設計が、品質と費用を同時に決めます。次回T-03では、その毎回入れる情報に階層があること、システム指示・ユーザー入力・モデル出力の三つの層へ進みます。関連資料は「AIエージェント入門」「AI開発ワード100」です。
このスライドのポイント
- 一問一答:「会話の続きができるのは、モデルとアプリのどちらの働き？」→ 答: アプリ（履歴を毎回送り直している。モデルは記憶しない）
- 30秒まとめ: 上限を超えた分は古いものから溢れる。だから「何を毎回入れ、何を入れないか」の設計が品質と費用を同時に決める
- 次回T-03: 毎回入れる情報の階層——システム指示・ユーザー入力・モデル出力
- 関連資料:「AIエージェント入門」「AI開発ワード100」
