今回のテーマ
LLMは何でも覚えているわけではなく、渡された文脈や状態をもとに応答している。現場メモ
覚えてもらうより、記録して渡す。必要な状態を外に置くと、会話が少し安定する。
はじめに
前回は、LLMとの共通言語について書きました。
Markdown、Mermaid、ECharts、ABC記譜法のように、文字として書けるものが、環境によっては図やグラフや楽譜として見える。
最初は少し不思議でしたが、使ってみるとかなり便利でした。
「図を描いて」とお願いしたら、画像ではなくMermaidの文字列が返ってくる。
最初は「え、これは図ですか？暗号ですか？」と思いましたが、対応環境で開くとちゃんと図になります。
前回の気づきを一言で言うなら、こうです。
LLMは自然言語だけでなく、人間にも機械にも扱いやすい「図になる文字」もかなり上手に扱える。
これは現場のおじさんにとって、なかなか大きな発見でした。
なぜなら、サポートセンターや業務支援の現場では、文章だけでなく、流れ、分岐、状態、判断ポイントをどう共有するかがとても大事だからです。
ただ、便利だと思って使い続けると、今度は別の違和感が出てきます。
昨日はうまくいったのに、今日は少し違う。
さっきまで分かっていたはずなのに、急に前提がずれる。
「いや、さっき言いましたよね？」と、画面に向かって言いたくなることがあります。
もちろん、相手は人間ではありません。
でも、つい言いたくなります。
おじさんは、画面にもわりと話しかけます。
最初は、自分の聞き方が悪かったのか、LLMの機嫌が悪かったのかと思いました。
しかし、どうやらそういう話だけではなさそうです。
覚えているように見えるけれど、覚えているとは限らない
ここでの話は、主にChat型の画面を使っている場合の話です。
チャット画面で会話していると、LLMはここまでの話を覚えてくれているように見えます。
実際、直前に話した内容を踏まえて返事をしてくれるので、人間としては「ちゃんと分かってくれている」と感じます。
たとえば、こんな感じです。
私：
さっきの説明を、もう少しやわらかい文章にしてください。
LLM：
承知しました。先ほどの内容を、より読みやすい表現にします。
この返しを見ると、「おお、分かってくれている」と感じます。
ちょっとした相棒感すらあります。
こちらが資料を持って会議室に入ったら、すでにホワイトボードの前で待っていてくれたような頼もしさです。
ただし、これはLLMそのものが人間のように記憶しているという意味ではありません。
多くの場合、アプリケーション側が、その時点で必要だと判断した会話履歴や補足情報をLLMに渡し、その材料をもとに返事が作られている、と考えた方が近いようです。
もちろん、製品や設定によって違いはあります。
前回の履歴をある程度渡すChat型の画面もあれば、そもそも前回の履歴を渡さない一回実行型のUIもあります。
そのため、次のような前提で使うのは少し危なそうです。
- 昨日話したから覚えているはず
- このチャットの流れなら分かっているはず
- 前に修正したから、もう同じ間違いはしないはず
人間同士なら「この前の件」で通じることもあります。
しかし、LLM相手では「この前の件」がどの範囲まで渡されているのか、利用者側からは分からないことがあります。
このあたりから、現場のおじさんの中で、LLMは優秀だけれど、意外と物忘れが激しい新人さんのように見えてきました。
ただし、覚えていないのに、たまに覚えているような顔をするタイプです。
ここが少しややこしい。
ステートレスという言葉に出会う
この話を調べていくと、ステートレス という言葉が出てきました。
業務システムに詳しい人なら聞き慣れた言葉かもしれません。
私の理解では、状態を自分の中に持ち続けるのではなく、必要な情報を外からもらって動く、という考え方です。
ものすごく乱暴に言うと、こんな感じです。
「今どういう状態か」を自分では持たないので、必要な情報は毎回ちゃんと渡してあげる必要がある。
現場のおじさん風に言うなら、こうです。
毎回、受付票と過去履歴と注意事項を机の上に置いてあげないと、前提がそろわない。
LLMとのChatでは、見た目としては会話が続いています。
しかしアプリケーションの中では、会話履歴、システム側の指示、参照させたい資料などを、その都度まとめて渡している場合があります。
一方で、履歴をほとんど渡さず、入力された内容だけを処理するUIもあります。
そう考えると、長い会話で前提がずれてくるのも、逆に毎回話がリセットされたように見えるのも、少し納得できます。
人間の感覚では、ついこう思ってしまいます。
さっき言ったでしょう。
昨日説明したでしょう。
その前提で話していたでしょう。
けれど、LLM側にその情報が十分に渡っていなければ、期待どおりには動きません。
これは物忘れというより、渡し方の問題 なのかもしれません。
会話がぐるぐる回ることもある
この仕組みを知ると、たまに起きる「同じ会話を何度も繰り返して抜け出せなくなる」感じも、少し見え方が変わります。
こちらが修正をお願いしているつもりでも、過去のやり取りが残ったまま次の返事に使われていると、LLM側は前の流れを引きずったまま、似たような回答を繰り返してしまうことがあります。
もう一つ面白いのが、「さっきのことは忘れて」と指示したときの挙動です。
人間の感覚では、本当に記憶から消してほしいと思います。
けれど、チャットの中では「忘れて」という指示自体も会話履歴に残ります。
つまり、実際にはこういう動きに近いのかもしれません。
過去の内容を完全に消す
というより、
過去の内容は残っているが、
以後の回答では使わないように指示されている
もちろん実際の仕組みは製品によって違うと思います。
ただ、現場のおじさんとしては、この理解の方がしっくりきました。
だから、会話がこじれたときは、無理にその場で直そうとするより、次のようにした方が早いことがあります。
- 新しい会話に切り替える
- 前提を短く整理し直す
- 必要な決定事項だけを貼り直す
- いったん要約を作らせてから再開する
長い会話の途中で迷子になったときは、無理に同じ道を戻るより、地図を描き直して再出発した方が早いことがあります。
現場でも、迷子の問い合わせ票を追いかけるより、状況を整理して新しいメモを作った方が早いときがあります。
あれに少し似ています。
コンテキストウィンドウは会話の器
もう一つ、コンテキストウィンドウ という言葉も出てきます。
これは、LLMが一度に参照できる情報量の上限のようなもの、と理解しています。
器が大きければ長い会話や資料を扱いやすくなりますが、無限に何でも入るわけではありません。
おじさんの感覚では、コンテキストウィンドウは会議室のテーブルのようなものです。
テーブルが大きければ、資料、議事録、前回のメモ、参考資料を広げられます。
しかし、無限に置けるわけではありません。
置きすぎると、どれが重要なのか分かりにくくなります。
そのうち、誰かが大事な資料の上にコーヒーを置きます。
現場ではよくあります。
LLMの場合、コーヒーは置きませんが、重要な前提が埋もれることはありそうです。
たとえば、会話が長くなると、アプリケーション側で過去のやり取りが要約され、一部が省略されたりすることがあります。
これは会話を続けるための工夫だと思います。
ただ、その要約でこちらの意図が少しずれると、LLMの返事も少しずれていきます。
ここで大事なのは、LLMの性能だけを見ても原因が分からないことです。
同じモデルでも、次の条件で返事の安定感は変わって見えます。
- どのアプリケーションで使っているか
- 会話履歴をどのくらい渡しているか
- 過去の会話をそのまま渡しているか、要約して渡しているか
- どの資料を参照させているか
- システム側の指示がどう設定されているか
またもや、第2話で感じたことと同じ話が出てきました。
LLMが賢いかどうかは、モデルそのものの性能だけで決まるわけではない。
クライアントアプリケーションが、どれくらい過去の会話を残しているのか。
それをそのまま渡しているのか。
要約して渡しているのか。
重要そうな部分だけを選んでいるのか。
その違いでも、かなり回答の印象が変わりそうです。
みなさんも、うまい表現ができず、全然違ったニュアンスとして伝わってしまった経験はありませんか。
口下手な私はよくあります。
アレです、アレ。
LLMとの会話でも、裏側で渡される文脈が少しずれると、似たようなことが起きるのかもしれません。
同じLLMを使っていても、ある場面ではとても話が通じるのに、別の場面では急に頼りなく感じることがあります。
以前はモデルの差だと思っていましたが、実は裏側で渡されている過去情報の量や渡し方が違うだけ、ということもありそうです。
よく見ると、多くのAIクライアントアプリには会話履歴を削除する機能があります。
あれは、こういうときに使うものなのですね。
たいした内容ではない質問や、試しに聞いただけの会話は、こまめに整理した方がよいのかもしれません。
トークン数、速度、賢さの三角関係
さらに調べていくと、もう一つ現実的な事情が見えてきました。
LLMに渡す文章や、LLMが返す文章は、ざっくり トークン という単位で扱われます。
そして多くのサービスでは、このトークン数が処理時間や利用料金に関係してきます。
おじさんの理解では、かなり乱暴に言うと、こうです。
トークンは、お金であり、時間でもある。
ただ、話はお金だけでもありません。
トークン数が増えるということは、LLMが一度に見なければならない情報も増える、ということです。
そこにはコンテキストウィンドウの上限や、モデルが一度に処理できる計算量の都合も絡みます。
そのため、過去情報をたくさん渡せば単純に賢くなる、というほど話は簡単ではなさそうです。
そう考えると、クライアントアプリケーションが過去の会話をすべて渡さない理由も少し分かります。
全部渡せば、文脈は豊かになります。
しかし、トークン数は増えます。
トークン数が増えると、処理が遅くなったり、費用が増えたりします。
逆に削りすぎると、文脈が足りず、少し頼りない返事になるかもしれません。
つまり裏側では、こんな三角関係がありそうです。
利用者としては、こう思います。
なるべく速く返してほしい。
でも、ちゃんと前提は覚えていてほしい。
できれば安く済んでほしい。
なかなか欲張りです。
でも、業務で使うなら当然そう思います。
みなさんも、LLMチャットを使っていて、こんな経験はありませんか。
私：
よしよし。だいぶ言うことを聞くようになってきたぞ。
じゃあ、全体を通して最終回答を出してもらおう。
私：
では、先ほどの質問について、もう一度考えてください。
LLM：
ここでは、これ以上会話を続けられません。
新しい会話を開始してください。
私：
あぁぁ！！！
あります。
私はあります。
いいところまで育てた会話が、突然「ここでセーブポイント終了です」と言われる感じです。
なるほど、あの「ここから先は新しい会話でお願いします」的な挙動も、こういう理由だったのかもしれません。
会話が長くなるほど、過去の情報をどこまで残すか、どこで区切るかをアプリケーション側が調整しているのだと考えると、少し腹落ちしました。
一般的なアプリケーションでは、このあたりの細かいところまで利用者がカスタマイズする機能は多くありません。
そのため、利用者としては、会話内容や渡し方で工夫するしかない訳ですが…
覚えてもらうより、記録して渡す
現場で使うなら、「LLMが覚えてくれるはず」と考えるより、必要な情報をこちらで整理して渡し、安定化をねらう方向で考えた方がよさそうです。
特に、個人で使っているアプリ環境では、会話履歴をどこまで残すか、次の応答に渡すか、要約するか、そもそも履歴を渡さないかが、製品や設定によって変わります。
つまり、同じLLMを使っていても、使う画面や設定によって「覚えているように見える範囲」は変わるということです。
ここでの結論は、かなりシンプルです。
決定事項、参照すべき資料、途中の判断結果などは、会話の中に埋もれさせず、別の形で残す。
会話履歴、要約、ナレッジ、RAG、メモリ、ワークフロー。
名前はいろいろあります。
ただ、現場目線では、次のように考えると分かりやすいです。
必要な状態をLLMの外に置いて、必要なタイミングで渡す。
ここで大事なのは、LLMやアプリ側が自動で覚えてくれることを期待しすぎないことです。
人が確認できる形で記録しておき、必要なときに渡し直す。
たとえば、こんな運用です。
## 昨日の決定事項
- 記事の対象読者は、生成AIを業務で使い始めた現場担当者
- トーンは、技術ブログだが少しユーモアを入れる
- 「AIよし、人よし、現場よし」を連載全体の合言葉にする
- 第3話では、LLMの記憶ではなく、状態の渡し方に注目する
これを翌日の作業の最初に貼り付けて、
昨日のこの前提で、第3話の続きを整理してください。
と頼むだけでも、かなり前提をそろえやすくなります。
そして、このときに活躍するのが、第2話で触れた共通言語なのだと思います。
自然言語だけで長々と説明し直すよりも、次のような形で残しておくと、人間も読み返しやすく、LLMにも渡し直しやすくなります。
- Markdownで決定事項を残す
- Mermaidで流れを残す
- 表で比較条件を残す
- 箇条書きで前提を整理する
たとえば、会話が長くなったら、途中で次のような整理を入れておくとよさそうです。
## 現時点の前提
| 項目 | 内容 |
| --- | --- |
| 目的 | Qiita連載の第3話を作成する |
| 主題 | LLMは何でも覚えているわけではない |
| 読者 | 生成AIを現場で使い始めた人 |
| トーン | 現場のおじさん目線、少しユーモアあり |
| 次にやること | 第4話につながるように、状態を外に出す話で締める |
このように、状態を外に出すだけで、LLMとの会話はかなり安定しやすくなります。
Agentという言葉が、少しだけ見えてきた
最近のGPT系のサービスでは、Chatだけでなく Agent という言葉もよく見かけるようになりました。
普通のチャットが、その場の会話を中心に返事をするものだとすると、Agentは、会話だけでなく、手順、状態、道具を組み合わせて作業を進める仕組みに近いようです。
たとえば、次のようなイメージです。
- 許可されたファイルやログを読む
- 検索する
- ブラウザを操作する
- ファイルを作成する
- 表計算を使う
- 外部ツールを呼び出す
- 複数の手順を順番に進める
このとき、最近よく出てくる MCP（Model Context Protocol） のような仕組みは、私の感覚では「AIに手足が生える」ようなものです。
手足といっても、LLM単体が急にパソコンの中を何でも見られたり、勝手に操作できたりするわけではありません。
アプリケーションやAgent基盤が、許可された範囲の情報やツールを用意し、必要なときにLLMへ渡したり、道具を使わせたりする、という見方の方が近そうです。
最初、私は単純にこう思っていました。
高度になって、秘書みたいなことができるようになったから、カッコいい呼び名になったのかな。
どうやら、それだけではなさそうです。
Chatは会話が中心です。
Agentは、会話に加えて、状態や道具を使いながら処理を進めるものとして考えた方がよさそうです。
この違いを意識すると、なぜLLM単体の記憶に頼りすぎない方がよいのかも見えてきます。
結局、みんなが「チャットだけでは少し不便だ」と感じていた部分を改善しようとした結果、LLM側から人間や業務に歩み寄った形の一つが、Agentなのかもしれません。
業務でどう扱うかは、第4話のMermaidやWorkflowの話で、もう少しだけ触れていきます。
AIよし、人よし、現場よしへ
LLMが何でも覚えてくれるなら便利です。
しかし、業務で大事なのは、便利そうに見えることよりも、人が安心して使えることだと思います。
なぜその回答になったのか。
どの前提を使ったのか。
どこからやり直せるのか。
このあたりが分かる方が、現場では助かります。
LLMの物忘れに見える現象は、単なる弱点ではなく、運用設計で補うべきポイントとして見えてきました。
- AIよし：LLMの文章生成や整理能力をうまく使う
- 人よし：人が確認できる形で前提や状態を残す
- 現場よし：業務の流れに合わせて、必要な情報を渡し直せるようにする
覚えてもらうより、記録して渡す。
これは地味ですが、現場ではかなり効く考え方だと思います。
LLMに全部を覚えてもらうより、人間が確認できる場所に状態を置く。
そして必要なときに、LLMに渡し直す。
この方が、結果として会話も業務も安定しやすくなります。
次回予告：Mermaidが図ではなくフローに見えてくる
では、状態をLLMの外に出すとして、どのように整理すればよいのでしょうか。
ここで、第2話に登場したMermaidがもう一度出てきます。
最初は図を描くための記法だと思っていました。
しかし、業務の流れやAgentの動きを考えると、人間とLLMが同じ前提を見ながら話すための共通言語としても使えそうに見えてきます。
次回は、Mermaidを単なる図としてではなく、LLMに処理の流れを伝えるためのガイドとして使う話に進みます。
連載ナビゲーション
- 連載トップ
- 前回：第2話「とある現場のおじさん、図になる文字に出会う」
- 今回：第3話「とある現場のおじさん、LLMは意外と物忘れが激しいことを知る」
- 次回：第4話「とある現場のおじさん、MermaidでLLMに歩み寄る」
※4話、5話は、9月に掲載予定です。