AIは前の会話を覚えているのか。情報の置き場所を決める3分類

現場から上がってくる不満で、地味に多いのがこれです。
「前に伝えたことを覚えていない」。
AIの記憶の仕組みがどうなっているのか、そこが疑問になります。

自社の事業内容、使っている用語、文章のトーンを毎回説明し直すのが面倒で、使うのをやめてしまう人が出てきます。

この不満の正体は、情報をどこに置くか決まっていない点にあります。
置き場所には層があって、層によって残る範囲が違います。

ということで、この整理を書いていきます。
案件ごとの前提をまとめる話はClaudeのProjectsを組織で使う。前提の共有と権限の設計で個別に扱っています。

置き場所は3つの層に分かれる

呼び方はサービスによって違いますが、構造のほうはだいたい共通しているので、まず3層を順番に見ていきます。
第1層はその場の会話で、いま話している一連のやり取りの中だけで有効な情報です。
「この資料を読んで」「もう少し短くして」といったものが該当し、会話を閉じた時点で消えます。

第2層は作業の単位で、1つの案件やプロジェクトに紐づく情報です。
関係する資料やその案件固有の前提、進行中の判断などが入り、同じ案件の別の会話でも参照されます。

第3層は組織のナレッジで、会社として変わらない情報です。
事業内容、製品の仕様、社内用語、文章の作法といった、誰が使うときも共通して必要な情報がここに入ります。
「覚えていない」という不満は、第3層に置くべき情報を第1層で毎回伝えていることから起きます。

第3層にあたる組織のナレッジを、どこに置いてどう保っていくかの全体は、社内ナレッジをAIで活用する方法。ツール導入・RAG・手持ちのAIの選び方で扱っています。

どこに何を置くかは、1問で決まる

判断に迷ったときは、「この情報は、次に別の作業をするときにも必要か」を1つだけ問います。
次の作業で必要ないものは、第1層に置いておきます。
今回だけの指示、今回渡す資料、今回の分量の指定などです。

ここに置くべきものを上の層に置いてしまうと、次の作業で邪魔になります。
「前回の指定が残っていて、今回は違うのに反映されない」という事故が起きるからです。

同じ案件で必要なものは、その顧客の状況や案件の経緯、関係者の名前、決まっている前提など、案件が終われば不要になるものごと第2層に置きます。
また、どの作業でも必要なもの、自社の説明や製品情報、用語の定義、文章のトーン、禁止する表現あたりは第3層に置きます。

第3層に置くものは、実務の感覚では意外に少ないです。
「毎回必要」と思っているものの多くは、実は業務ごとに違うからです。
ここを整理せずに第3層へ詰め込むと、関係のない前提が全部の作業に効いてしまいます。

具体的に組織のナレッジとして置くべきものは、5つ程度に収まります。
まず、会社と事業の説明です。
何をしている会社か、誰に何を提供しているかを3〜5行で書きます。

次に、社内用語の定義です。
自社独自の呼び方や略語を10〜20語ほど書き出します。
用語をそろえる話は発注・指示の共通言語をそろえる。専門用語リストを組織資産にするで扱っています。

3つ目が、主要な製品・サービスの概要です。
名前と一行の説明を並べます。

4つめが文章のトーンで、使う言葉の水準、避ける表現、敬語の程度です。
5つめが禁止事項で、断定してはいけないことと入力してはいけない情報です。
何を入れてよいかの線引きは生成AIに入れてはいけない情報とは。社内ルールを3段階で線引きするにまとめてあります。

この5つ以上は置かないほうがいいと思っています。
長い前提は指示との優先順位が曖昧になるからです。

第2層は最も効くが、引き継ぎで消える

3つの層のうち、実務でいちばん効果があるのは第2層です。
理由は、業務が案件単位で進むからです。
1つの顧客への提案、1つのプロジェクト、1つの採用といった単位に紐づく情報は量がありますし、毎回同じものを使います。

第2層に置くと効くものは4つで、関係する資料、その案件の経緯、決まっている前提、使う様式です。
案件が終わったら第2層は閉じます。
終わった案件の情報が残り続けると、次の案件に混ざるからです。
「前の顧客の情報が出てきた」という事故は、ここの整理が効いていないことから起きます。

層の話でいちばん実務的な論点はここで、担当が変わったときに第1層と第2層の情報が消えます。
第3層は組織のものなので残りますが、第2層は担当者のアカウントに紐づいており引き継ぎで失われやすく、第1層はそもそも残りません。

だから運用としては、第2層の情報のうち残すべきものを別の場所に出す必要があります。
案件の経緯、決まった前提、判断の理由といったもので、案件の記録として共有の場所に残しておきます。
「AIとのやり取りの中にしかない情報を作らない」というのが、この層の運用の原則です。

やり取りの中で重要な判断が決まったら、それを外に書き出します。
ここを習慣にしておかないと、担当が変わった時点で経緯が丸ごと消えます。

記憶に頼らない運用が、結局いちばん確実だ

3つの層を理解したうえで、運用としては記憶に頼らない形にしておくのが確実です。
なぜでしょうか？
理由は3つあります。

ひとつは、サービスの仕様そのものが変わることです。
残る範囲や期間は提供側の設計で変わるので、仕様に依存した運用は変更のたびに崩れていきます。

2つ目は、再現性がないことです。
「前に伝えたこと」がどう効いているかは確認できないので、重要な業務では前提が明示されている状態のほうが安全です。
毎回同じ前提を書かずに済ませる設計は毎回同じ前提を書かせない。組織の共通前提をデフォルト化するで扱っています。

3つ目が、引き継げないことです。
やり取りの中にしかない情報は、担当が変わると消えてしまいます。

だから実務の形はこうなります。
組織の共通前提は第3層に置き、案件の情報は第2層に置いて重要な判断は外に書き出し、今回だけの指示は毎回明示します。

重要な業務では、前提を含めた依頼文を保存して使い回します。
記憶に頼るのではなく、前提を毎回渡す形を仕組みにするわけです。

ここまでは覚えていないことへの対処ですが、逆の論点もあります。
残ることがリスクになる場合です。
第2層に案件の情報を置くと、その情報は同じ場所を使う人に見えます。

案件を複数人で回している場合は便利ですが、閲覧範囲が限られる情報が混ざると問題になります。
具体的に注意が必要なのは3種類で、採用の選考に関する情報、人事の情報、未公表の経営情報です。
これらは案件単位に置くと、後から誰が見られたかを追うのが難しくなります。

この3種類は、置き場所を分けておきます。
また、第3層に個別の人の情報を置かないようにします。
組織のナレッジは全員に効く場所なので、特定の人に関する情報を入れてはいけません。

もう1つ、現場に伝えておきたい前提があります。
やり取りの履歴は一定期間残るという点で、これは見落とされがちです。
法人契約であれば学習には使われませんが、履歴が保存される事実は変わりませんし、管理者が利用状況を把握できる構成になっていることもあります。

これは監視のための話ではなく、入力してよい情報の線引きが必要な理由になります。
「消えるから大丈夫」という前提で機密情報を入力すると、後から回収できません。

だから伝え方は2つセットにします。
「履歴は残るので、入れてよい情報の線引きを守ってください」「残るからこそ、案件の情報は再利用できます」。

前者だけを伝えると使われなくなりますし、後者だけを伝えると線引きが緩みます。
両方を並べて伝えるのが確実です。

現場に配る形にすると、3行で足ります。
今回だけの話はその会話の中で伝え、案件の情報は案件の単位にまとめて記録に書き出し、会社として変わらない情報は共通の設定に置いて推進チームが管理します。

「覚えていない」という相談が来たら、それがどの層の情報かを聞きます。
第3層の情報なら共通の設定に足しますし、第1層の情報なら毎回伝えるのが正しい運用だと説明します。
この切り分けができると、相談の大半が現場で解決します。

よくある失敗は5つ

まず、第3層に何でも詰め込むことです。
関係のない前提が全部の作業に効いて精度が落ちるので、5項目程度に絞ります。

次が、第1層の指定を上の層に置くことです。
前回の分量指定が残ってしまい、今回に反映されないという事故が起きます。

その次が、案件が終わっても第2層を閉じないことです。
次の案件に前の顧客の情報が混ざります。

4つ目が、やり取りの中にしかない情報を作ることです。
担当が変わった時点で経緯が消えるので、重要な判断は外に書き出します。
引き継ぎの様式は担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計にまとめてあります。

最後が、記憶の仕様に依存した運用を組むことです。
提供側の設計が変わると崩れるので、前提を毎回渡す形を仕組みにします。

前提を毎回渡す形を社内の決まりにするところは、当社のAI伴走支援でも、ガイドラインのドラフトを一緒に作り、話し合って仕上げる中で扱っています。

記憶に頼らず、前提を毎回渡す形を仕組みにする

「前に伝えたのに覚えていない」の正体は、情報の置き場所が決まっていないことです。
置き場所は3層に分かれていて、その場の会話、作業の単位、組織のナレッジの3つです。
判断は「この情報は次に別の作業をするときにも必要か」という1問だけで決まります。

組織のナレッジに置くのは5項目程度に絞ります。
詰め込むと、関係のない前提まで効いてしまうからです。
最も効果があるのは案件単位の層ですが、担当者に紐づいて引き継げないので、重要な判断は案件の記録として外に書き出します。

そして運用としては記憶に頼らず、前提を毎回渡す形をAIボットとして仕組みにするのが確実です。
自社の共通前提は、まず5項目だけでも書き出しておくと、あとの合意形成にかかる時間がかなり短くなります。