AIエージェントのメモリ管理とは｜会話履歴が費用を膨らませる仕組み

社内向け AI エージェントの PoC を回していると、ある時点で経理から連絡が入ります。「API の利用料、先月の倍になっていますが何かありましたか」。利用者数はほとんど変わっていないのに、請求額だけが伸びている。心当たりを探しても、思い当たるのは「現場からの要望で、会話の文脈を覚えるようにした」ことくらいです。

同じ時期に、ベンダーからの見積書には「メモリ基盤構築」「ベクトルDB 運用費（月額）」といった項目が並んでいます。それぞれ何の費用なのか、金額が妥当なのか、社内で説明を求められても答えられません。かといって現場からは「前回の話を毎回説明し直すのが面倒だ、全部覚えさせてほしい」という声が上がり続けています。

これら3つの出来事は、実は同じ一つの設計判断から生まれています。それが「AIエージェントのメモリ管理」、つまり会話履歴と文脈をどこまで保持し、どこから捨てるかの設計です。ここは技術的な実装の話に見えるため、発注側は判断をベンダーに委ねがちですが、その選択がそのまま毎月のランニングコストと回答精度の両方を決めてしまいます。

やっかいなのは、コストと精度が逆方向に動くことです。多く覚えさせれば精度は上がりますが費用も上がる。削れば安くなりますが、必要な文脈が落ちて使い物にならなくなる可能性があります。この線引きを判断するには、「どの設計判断が、どの経路を通って、いくらの費用になるのか」という因果を押さえておく必要があります。

本記事では、AIエージェントのメモリ管理の仕組みを発注・要件定義側の視点で整理し、会話履歴の累積が費用に跳ね返る3つの経路、保持方式による増え方の違い、業務タイプ別の「どこまで覚えさせるか」の目安、そして見積り・要件定義でベンダーに確認すべき項目までを解説します。ライブラリ選定や実装コードには踏み込まず、要件を決めて費用を承認する立場の方が判断できる粒度でまとめます。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

AIエージェントのメモリ管理とは？会話履歴と記憶の違い

AIエージェントのメモリ管理とは、会話履歴をひたすら保存することではありません。何を残し、何を捨て、必要な場面でどう取り出すかを決める設計を指します。この定義から入らないと、後段の費用の議論がすべてずれてしまいます。

現場から上がってくる「全部覚えさせてほしい」という要望は、実のところ複数の異なる仕組みの束です。まずはそれを切り分けるところから始めます。

会話履歴と「記憶」は何が違うのか

会話履歴と記憶は、混同されやすいものの、業務上の意味がまったく異なります。

会話履歴は、いま進行しているやり取りの流れそのものです。「さっきの見積もりの件だけど」と言われたときに、その「さっき」が何を指すのかを追えるようにするためのものです。会話が終われば役目を終える情報も多く含まれます。

記憶は、会話をまたいで積み上がる前提の情報です。「この利用者は営業部所属で、担当は関西エリア」「この案件の予算上限は300万円」といった、次回以降の会話でも参照される情報を指します。

この違いが重要なのは、保持コストの発生の仕方がまったく違うからです。会話履歴は会話が終われば消してよいため、コストは会話の長さに比例します。一方で記憶は消さずに溜め続ける前提なので、コストは利用者数と運用期間に比例して積み上がっていきます。現場が「覚えてほしい」と言うとき、この二つのどちらを指しているのかを確認するだけで、必要な設計と費用の桁が変わります。

短期記憶（コンテキスト内保持）と長期記憶（外部保存）の2層

AIエージェントのメモリ管理を費用の観点から理解するうえでは、記憶の分類を細かく学ぶ必要はありません。短期記憶と長期記憶の2層で整理すれば十分です。

短期記憶は、AI に質問を送るたびに「これまでの会話の流れ」を一緒に添えることで実現されます。特別なデータベースは不要ですが、送る量そのものが課金対象になります。

長期記憶は、会話から抽出した情報を外部のデータベースに保存し、必要になったときに検索して取り出す仕組みです。保存基盤そのものの費用が別途かかりますが、会話の長さとは独立して機能します。

ベンダー見積りに「メモリ基盤構築」「ベクトルDB 運用費」という項目が並んでいる場合、それは長期記憶の側の費用です。短期記憶だけで足りる要件であれば、これらの項目は本来不要になります。逆に、長期記憶を導入したからといって短期記憶側の課金が消えるわけでもありません。両方が同時に走る構成が一般的です。

AIエージェントが文脈保持のために会話履歴を毎回送り直す仕組み

短期記憶がなぜ課金につながるのかを理解するには、AI エージェントが文脈保持をどう実現しているかを知る必要があります。ここが本記事のすべての費用の議論の出発点になります。

LLM は前回の会話を覚えていない（ステートレスという前提）

意外に思われるかもしれませんが、LLM の API は前回のやり取りを一切記憶していません。1回のリクエストは完全に独立しており、前の会話との連続性を API 側が管理する仕組みは基本的にありません。この性質をステートレスと呼びます。

チャット画面で会話が続いているように見えるのは、アプリケーション側が過去のやり取りを保存しておき、次の質問を送るときにそれまでの会話を丸ごと添えて送り直しているからです。AI は毎回「初対面」の状態で、渡された会話の記録を読み直したうえで回答を組み立てています。

つまり、文脈保持は「AI が覚えている」のではなく「毎回思い出させている」というのが実態です。

文脈保持のために履歴を送り直すと入力量が積み上がる

この構造の帰結として、会話のターン数が増えるほど、1回あたりに送る入力量が増えていきます。

3ターン目の質問では、過去2ターン分の会話を添えて送ります。10ターン目では過去9ターン分です。30ターン目では過去29ターン分をまとめて送ることになります。しかも、これに加えて業務ルールや口調の指示といった固定のシステムプロンプトが毎回付随します。

LLM の API 料金は、送った入力トークンと生成された出力トークンの量に応じて課金される従量制が一般的です。たとえば Claude Sonnet 5 の場合、基本入力単価は100万トークンあたり2ドル、出力単価は100万トークンあたり10ドルと公表されています（Anthropic 公式の料金ページ）。OpenAI の API も同様に入力と出力で単価を分けた従量課金です（OpenAI 公式の料金ページ）。

したがって、会話が長くなるほど毎回の入力トークン数が増え、その分だけ請求額が伸びます。利用者数が変わっていないのに請求が倍になった、という現象の多くはここに原因があります。トークンという単位そのものや料金の計算方法については、LLMのトークンとAPI料金の仕組みで詳しく解説しています。

コンテキストウィンドウの上限を超えるとどうなるか

送れる入力量には上限があります。この上限をコンテキストウィンドウと呼びます。

会話が長引いて上限に近づくと、多くの実装では古い履歴から順に切り捨てる処理が入ります。この切り捨ては自動的に行われるため、利用者からは「AI が急に前提を忘れた」ように見えます。会話の序盤で伝えた重要な条件が落ちた状態で回答が生成されるため、内容が的外れになったり、すでに合意した前提を再度確認してきたりします。

やっかいなのは、この劣化がエラーとして表面化しない点です。システムは正常に動作しており、返ってくる回答も文章としては自然です。品質が落ちていることに気づけるのは、業務内容を知っている現場の担当者だけになります。上限そのものの詳しい仕組みと設計上の制約については、コンテキストウィンドウの制約を参照してください。

ここまでで、「会話が長くなると費用が増える」「上限を超えると精度が落ちる」という2つの帰結が、どちらも同じ「履歴を毎回送り直す」構造から出ていることが見えてきました。次はこの費用の側を分解していきます。

AIエージェントのメモリ管理が費用に直結する3つの経路

「メモリ管理をするとコストが増える」という説明では、見積りの妥当性は判断できません。判断するには、費用がどの経路を通って発生しているかを分けて見る必要があります。AIエージェントのメモリ コストは、大きく3つの経路に分解できます。

経路1 会話履歴の累積による入力トークン費用

もっとも大きく、もっとも見落とされやすいのがこの経路です。先ほど見たとおり、文脈保持のために過去の会話を毎回送り直す構造から発生します。

特徴は、会話1件あたりの費用が、ターン数の増加に対して加速度的に増えることです。10ターンの会話と20ターンの会話では、費用は2倍ではなく3倍以上になります（具体的な数値は次の章で示します）。この非線形性を理解していないと、PoC の実績から本番の月額を大きく見誤ります。

この経路に効く設計判断は、「何ターン分の履歴を送るか」「古い履歴を要約して圧縮するか」「固定部分をキャッシュするか」です。追加のインフラを導入しなくても、この経路だけで費用は数倍変わります。

経路2 長期記憶の保存・検索にかかる費用

AIエージェント ベクトルDB 記憶の構成を取る場合に発生する経路です。会話をまたいで情報を持ち越すために、外部のデータベースに情報を保存し、必要なときに検索して取り出します。

この経路の費用は、さらに複数のメーターに分かれます。ベクトルデータベースの一つである Pinecone の Standard プランを例に取ると、公表されている課金要素は次のように分かれています（Pinecone 公式の料金ページ）。

ここから読み取れるのは、保存量そのものよりも検索回数と最低月額のほうが効きやすいという構造です。テキストの記憶データは1GB に達するまでにかなりの量を必要とするため、中小規模の運用ではストレージ費用は小さく収まります。一方で、読み取りは会話のたびに発生するため、利用者数と会話数に比例して積み上がります。

これに加えて、保存するテキストをベクトル化する「埋め込み生成」の費用がかかります。埋め込み専用モデルの単価は生成モデルよりも大幅に安く、たとえば OpenAI の text-embedding-3-small は100万トークンあたり0.02ドルと公表されています（OpenAI 公式の料金ページ）。埋め込み生成が費用のボトルネックになるケースは多くありません。

見積書に「ベクトルDB 運用費」という項目がある場合は、上記のどのメーターに対する見積りなのか、そして最低月額が発生するプランを前提にしているのかを確認する価値があります。

経路3 文脈が失われたことによる手戻り費用

3つ目は請求書に現れない経路です。しかし実務上の影響はもっとも大きくなることがあります。

履歴を切り詰めすぎると、AI は必要な前提を欠いた状態で回答します。利用者は「そうではなくて」と説明をやり直し、同じ内容を別の言い方で聞き直します。このやり直しは、次の2重の費用を生みます。

1つ目はAPI 費用の増加です。再質問はターン数を増やすため、経路1の累積をさらに押し上げます。履歴を削って安くしたはずが、やり取りの回数が増えて元の木阿弥になることがあります。

2つ目は人的コストです。AI の回答が信用できない状態になると、担当者は結局自分で確認し直すようになります。導入の目的が業務時間の削減であった場合、この時点で投資対効果の前提が崩れます。さらに、一度「使えない」という評価が定着すると利用率そのものが落ち、システムの月額費用だけが残るという状態になりかねません。

この経路は定量化が難しいため見積書には載りませんが、削りすぎのコストとして設計判断のたびに意識しておく必要があります。

3経路と設計判断の対応表

3つの経路と、それぞれに効く設計判断の対応を整理します。見積書の項目や要件定義の論点が、どの経路に対応しているかを紐づける際の参照表として使えます。

経路1と経路2は「増やすと高くなる」方向に働き、経路3は「減らしすぎると高くなる」方向に働きます。適正ラインはこの3つの交点にあり、どこにあるかは業務の性質によって変わります。

会話が長くなると費用はどう増えるのか（保持方式別の概算比較）

ここからは、LLM 会話履歴 トークン 増加の構造を数値で確認します。「会話が長くなると増える」という定性的な理解を、「どういう形で増えるか」まで具体化することが目的です。

この節の数値は、構造を理解するために簡略化した概算モデルです。 実際の費用は、選ぶモデル・提供元・実装方式・日本語と英語の比率などによって変わります。金額そのものを持ち帰るのではなく、保持方式によって増え方の形が変わるという点を読み取ってください。

概算に用いた前提条件

出力側の費用や要約を生成する際の費用を除いているのは、保持方式の違いが入力側にどう現れるかだけを抜き出して比較するためです。

全履歴を毎回送る場合の増え方

もっとも単純な実装で、過去のやり取りをすべて添えて送ります。

このとき、Nターン目の入力量は「固定部分2,000 + 1,000 ×（N−1）」です。会話全体で累積すると、ターン数の2乗に比例して増えていきます。10ターンから20ターンに倍増したときに費用が2倍ではなく3.5倍になるのは、この性質によるものです。

直近N件だけ保持する場合の増え方

古い履歴を捨て、直近の数ターンだけを送る方式です。

このとき、6ターン目以降の入力量は「固定部分2,000 + 直近5ターン分5,000 = 7,000トークン」で一定になります。会話全体の累積はターン数に比例する直線になり、長い会話でも予測可能な範囲に収まります。

要約を併用する場合の増え方

直近5ターンをそのまま送りつつ、それより古い履歴は要約して圧縮した形で添える方式です。

入力量は「固定部分2,000 + 直近5ターン分5,000 + 要約500 = 7,500トークン」で頭打ちになります。直近N件保持よりわずかに高くなりますが、会話序盤の重要な前提を保持できるため、経路3の手戻りを抑えられます。ただし、要約を生成するための API 呼び出しが別途発生する点は見積りに含める必要があります。

3方式の累積入力トークン数と、上記の単価で換算した1会話あたりの概算費用は次のようになります。

読み取るべきポイントは3つあります。

短い会話では差がほとんど出ません。 10ターンの時点では3方式の差は2割程度です。PoC で短いやり取りしか試していない場合、保持方式の違いは請求額に現れません。

長い会話で差が開きます。 50ターンでは全履歴方式が直近5ターン方式の約4倍になります。10ターンでの2割の差が、50ターンでは4倍の差になるという増え方の違いが、この表の本質です。

要約併用の追加コストは小さい。 直近N件保持と要約併用の差は数パーセントにとどまります。文脈を保つ効果を考えると、要約の追加負担は多くの場合で見合う範囲に収まります。

PoC の実績から本番費用を見積もるときの考え方

上記の構造を踏まえると、PoC の請求額をそのまま人数倍して本番費用とする見積りは危険です。PoC で試した会話の長さが、本番運用での会話の長さと同じとは限らないからです。

外挿する際は、最低限次の3つを分けて考えます。

1. 1会話あたりの平均ターン数：PoC では5ターン程度でも、本番で現場が使い込むと20〜30ターンになることがあります。全履歴方式ではここが2乗で効きます
2. 1日あたりの会話件数：利用者数だけでなく「1人あたり1日何回使うか」を見積もります
3. 稼働日数：月20営業日か、24時間365日か

たとえば、月2,000会話・1会話30ターンという想定を上記の単価に当てはめると、全履歴方式では入力側だけで月約1,980ドル、直近5ターン方式では月約780ドルとなり、保持方式の選択だけで月1,200ドル前後の差が生じます。年間では1万4,000ドル規模の違いになります。

ベンダー見積りを受け取ったら、その金額がどの保持方式・何ターン想定で計算されたものかを確認してください。前提が書かれていない見積りは、会話が想定より長くなった時点で崩れます。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

コストと精度を両立するメモリ管理の設計パターン

保持方式の選択が費用を左右することは見てきました。ここでは実務で使われる代表的なパターンについて、「何が安くなるか」「何を失うか」「どんな業務に向くか」を整理します。実装の詳細やライブラリ選定には踏み込まず、要件を決める側が判断できる粒度で扱います。

直近N件だけ残す（スライディングウィンドウ）

もっとも単純な方式です。会話が進むたびに古い履歴を押し出し、直近のN件だけを保持します。

安くなるのは経路1です。入力量が一定値で頭打ちになるため、会話がどれだけ長引いても1ターンあたりの費用が読めます。実装も単純で、追加のインフラを必要としません。

失うのは、押し出された部分の情報です。会話の冒頭で伝えた前提条件（予算・納期・対象部署など）は、Nターンを過ぎた時点で完全に消えます。しかも消えたことは利用者に通知されません。

短いやり取りで完結する用途、あるいは1つの質問に1つの回答で終わる用途に向きます。逆に、条件を積み上げながら結論に近づいていく相談型の用途には向きません。

古い履歴を要約して圧縮する

会話履歴 要約 圧縮の方式です。押し出される履歴をそのまま捨てるのではなく、要点だけを短くまとめて残します。

安くなるのは同じく経路1ですが、スライディングウィンドウより緩やかです。要約の分だけ入力量が増えるためです。ただし前節で見たとおり、その増分は数パーセント程度に収まります。

失うのは要約の過程で落ちた細部です。要約は必ず情報を圧縮するため、どの情報を残すかの優先度設計が品質を決めます。「数値・固有名詞・確定した合意事項は必ず残す」といったルールを要件として明示しておくことが有効です。また、要約を生成する API 呼び出しの費用と処理時間が別途かかります。

条件を積み上げていく相談型の用途、複数回にわたって進捗を共有する業務支援の用途に向きます。

必要なときだけ取り出す（ベクトル検索による想起）

長期記憶を外部のデータベースに保存しておき、そのときの質問に関連する情報だけを検索して取り出す方式です。全部を毎回送るのではなく、必要な分だけを引いてくる考え方です。

安くなるのは経路1です。保存している情報がどれだけ増えても、毎回送るのは検索でヒットした数件だけなので、入力量が蓄積量に比例して増えません。会話をまたいだ記憶を持たせつつ、入力量を抑えられる点が最大の利点です。

代わりに経路2が発生します。ベクトルデータベースの月額費用、検索のたびの読み取りユニット、保存時の書き込みユニットと埋め込み生成の費用です。加えて、検索で必要な情報が引けなかった場合には文脈が欠落するという新しいリスクが生まれます。検索精度そのものが品質を左右するため、期待通りに動かないときの原因追及が難しくなります。

会話をまたいだ記憶が業務上必須である用途、参照すべき情報量が大きく全部は送れない用途に向きます。逆に、単発で完結する用途に導入すると経路2の費用だけが積み上がります。

プロンプトキャッシュで繰り返し部分の費用を抑える

毎回同じ内容を送っている部分（業務ルール・口調の指示・参照文書など）を提供側にキャッシュさせ、2回目以降は割引単価で処理してもらう仕組みです。

割引率は大きく、Anthropic の公式ドキュメントによれば、キャッシュから読み出した入力トークンは基本入力単価の10分の1で課金されます。ただしキャッシュに書き込む際は基本単価の1.25倍（有効期間5分の場合）または2倍（有効期間1時間の場合）がかかるため、5分キャッシュでは1回、1時間キャッシュでは2回読み出した時点で元が取れる計算になります（Anthropic 公式の料金ページ）。OpenAI の API にもキャッシュ済み入力の割引単価が設定されています（OpenAI 公式の料金ページ）。

注意すべきは有効期間です。Anthropic のプロンプトキャッシュは既定で5分、オプションで1時間と公表されています（Anthropic 公式のプロンプトキャッシュ解説）。連続してやり取りする用途では効果が大きい一方、利用者が数十分に1回しか使わない用途では、キャッシュが期限切れになるため書き込み費用だけがかさむ可能性があります。

失うものはほとんどありませんが、利用パターンによっては効かないという点を要件定義の段階で確認しておく必要があります。

パターン別の得失比較表

これらは排他ではなく、組み合わせて使うのが一般的です。実務では「直近5ターン＋それ以前は要約＋固定部分はキャッシュ」といった構成がよく取られます。ベンダー提案を受ける際は、どのパターンをどう組み合わせる想定かを確認すると、見積り金額の根拠が読み解きやすくなります。

業務タイプ別「どこまで覚えさせるか」の目安

ここまでの内容を、自社ケースに当てはめられる形にします。「どこまで覚えさせるか」の適正ラインは業務の性質によって変わるため、3つの類型に分けて目安を示します。

単発Q&A・社内検索型

社内規程の確認、経費精算のルール照会、製品仕様の問い合わせなど、1つの質問に1つの回答で完結する用途です。

必要なのはセッション内の会話履歴だけで、長期記憶はほぼ不要です。「昨日この人が何を聞いたか」を覚えている必要はありません。むしろ覚えていると、前回の質問に引きずられた回答をするリスクがあります。

現場から「覚えさせてほしい」という要望が出た場合は、具体的に何を覚えていてほしいのかを掘り下げてください。多くの場合、実際のニーズは「同じ説明を毎回入力するのが面倒」であり、これはシステムプロンプトへの定型情報の埋め込みで解決できます。

継続的な業務支援・問い合わせ対応型

顧客からの問い合わせ対応、案件の進行管理、稟議書の作成支援など、1つのテーマについて複数回にわたってやり取りが続く用途です。

必要なのは案件やテーマの単位でまとまった記憶です。「この案件の予算上限」「先週合意した仕様」といった情報を持ち越す必要がありますが、それは案件が終われば不要になります。恒久的な保存は必要ありません。

この類型でとくに効くのが、保存の単位を「利用者」ではなく「案件」に置く設計です。案件終了とともに記憶を破棄する運用にすれば、蓄積が青天井にならず、後述する情報管理のリスクも同時に抑えられます。

個人最適化・アシスタント型

利用者ごとの好みや業務スタイルを学習し、対話を重ねるほど使いやすくなることを狙う用途です。パーソナルアシスタント的な位置づけになります。

この類型では長期記憶が本質的に必要です。ただし、何でも覚えさせる設計にはしないことが重要になります。

保存対象を限定する設計は、費用の抑制だけでなく品質にも効きます。会話から自動的に抽出した情報を無制限に保存すると、誤った推測や一時的な事情が「記憶」として定着し、後の回答を歪める原因になります。

3類型の比較と自社ケースの当てはめ方

自社ケースを当てはめる際は、次の順で考えると整理しやすくなります。

1. 会話をまたいで参照する情報があるか：なければ単発Q&A型で、長期記憶の見積り項目は不要です
2. その情報はいつまで必要か：案件終了までなら継続的業務支援型、恒久的に必要なら個人最適化型です
3. 1つの会話は何ターン続きそうか：10ターン未満なら保持方式の違いは費用にほとんど影響しません。20ターンを超えるなら保持方式の設計が費用を大きく左右します

なお、AIエージェントにメモリ機能を持たせるべきかどうかという要否そのものを検討している段階であれば、メモリ機能が自社に必要かの判断軸で導入可否の考え方を整理しています。

会話履歴を保持するときに見落とされやすいリスク

保持範囲を決める判断には、費用以外の制約も関わります。ここでは実務上とくに見落とされやすい2点を扱います。いずれも長く多く覚えさせるほど負担が増えるという点で、費用と同じ方向に働きます。

個人情報・機密情報が蓄積し続けるリスク

会話履歴を長期保存するということは、そこに含まれる個人情報や機密情報も同時に保存し続けるということです。AIエージェント メモリ 個人情報の観点では、次の点が論点になります。

入力される情報を事前に制御できません。 利用者は業務の流れの中で、顧客名・連絡先・取引条件・人事情報などを自然に入力します。「入力しないでください」という運用ルールだけで防ぐのは現実的ではありません。長期記憶を有効にしている場合、これらが自動的に抽出・保存される可能性があります。

保存期間と削除の責任が発生します。 個人情報を含むデータを保持する以上、利用目的の特定、保存期間の設定、削除請求への対応が必要になります。個人情報保護委員会も、生成AIサービスの利用にあたって個人情報の取り扱いに注意するよう事業者向けの注意喚起を公表しています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」）。実際の対応内容は自社の状況や契約形態によって異なるため、法務部門や専門家への確認が必要です。

削除できる設計になっているかは、あらかじめ確認が必要です。 ベクトルデータベースに保存された情報は、「特定の利用者の記憶だけを消す」という操作が実装によっては容易でない場合があります。削除要件を後から追加すると設計変更が必要になるため、要件定義の段階で確認しておく価値があります。

保存対象を限定し、保存期間を区切る設計は、費用の抑制と情報管理の負担軽減を同時に実現します。「案件終了後90日で自動削除」といった運用ルールを最初から要件に入れておくことが有効です。

古い記憶が誤答を生むリスク（更新と失効の設計）

もう一つの見落としが、保存した情報が古くなることへの対処です。

「担当者は田中さん」「単価は月80万円」といった記憶は、時間が経てば事実と食い違います。ところが多くの実装では、記憶は追記される一方で更新されません。結果として、古い情報と新しい情報が両方保存された状態になり、AI は検索でヒットしたほうを事実として回答します。

この誤答は、記憶を持たないシステムよりもたちが悪い性質があります。記憶がなければ「分かりません」と答えるところを、記憶があると自信を持って古い情報を答えてしまうためです。利用者は AI が覚えている情報を信頼しやすいため、誤りに気づきにくくなります。

対処するには、要件定義の段階で次の点を決めておく必要があります。

• 矛盾する情報が入ってきたときの扱い：新しいほうで上書きするのか、両方残して新しいほうを優先するのか
• 記憶の有効期限：一定期間参照されなかった記憶を失効させるか
• 記憶の確認手段：利用者が「AI が自分について何を覚えているか」を確認・修正できるか

3つ目は品質面だけでなく、前項の情報管理の観点からも意味があります。記憶を可視化できれば、意図せず保存された情報を利用者自身が削除できます。

保存する情報を絞る設計は、この更新・失効の管理コストも同時に下げます。覚えさせる範囲を広げるほど、費用・情報管理・鮮度維持の3つの負担が同時に増えていくという構造を押さえておいてください。

メモリ管理について見積り・要件定義で確認すべき項目

ここまでの内容を、ベンダーとの打ち合わせで使える形にまとめます。AIエージェント 運用費用 見積もりを評価する際、メモリ管理に関して確認すべき項目は5つです。

確認項目チェックリスト（5項目）

1. 保持期間

会話履歴と記憶を、それぞれいつまで保持する想定か。選択肢はおおむね「セッション内のみ」「案件・テーマ単位」「恒久」に分かれます。

確認する理由：保持期間は経路2の費用と情報管理の負担を直接決めます。恒久保持を前提とした見積りとセッション内のみの見積りでは、月額の桁が変わることがあります。

2. 保持方式

短期記憶をどう扱うか。「全履歴を送る」「直近N件のみ」「要約を併用」「ベクトル検索で想起」のどれか、あるいはどの組み合わせか。直近N件方式なら N の値も確認します。

確認する理由：保持方式は経路1の増え方の形を決めます。前述のとおり、50ターンの会話では全履歴方式と直近5ターン方式で約4倍の差が出ます。

3. 上限と超過時の挙動

1会話あたり・1利用者あたりの保持量に上限を設けるか。上限に達したときに何が起きるか（古い履歴を捨てる／要約する／エラーを返す／利用者に通知する）。

確認する理由：上限到達時の挙動は経路3の手戻り費用に直結します。黙って切り捨てる実装では、品質劣化に誰も気づけません。

4. 課金単位

費用が従量なのか固定なのか。従量であれば何に対して課金されるのか（入力トークン量／保存容量／検索回数／利用者数／会話数）。最低月額の有無も含めて確認します。

確認する理由：課金単位が分かれば、利用が増えたときにどこがどう伸びるかを自社で試算できます。「月額○万円」とだけ書かれた見積りは、利用量が想定を超えた時点で崩れます。

5. 削除・エクスポート運用

保存された記憶を、誰が・どの単位で・どうやって削除できるか。利用者単位の削除は可能か。エクスポートして内容を確認する手段はあるか。

確認する理由：削除要件は後付けが難しく、設計変更を伴うことがあります。個人情報を含む可能性がある以上、初期段階で確認しておく必要があります。

あわせて、見積りの前提となっている想定利用量（想定利用者数・1日あたりの会話件数・1会話あたりの平均ターン数）を確認してください。この3つが明示されていない見積りは、実測値と比較して妥当性を検証することができません。

見積り項目と費用3経路の対応の読み解き方

見積書に並んでいる項目が、どの費用経路に対応しているかを紐づけると、内訳の妥当性が判断しやすくなります。

とくに注意して見たいのが、長期記憶に関する項目が業務タイプと整合しているかです。単発Q&A型の要件に対して「メモリ基盤構築」「ベクトルDB 月額」が計上されている場合、要件と設計にずれがある可能性があります。逆に、個人最適化型の要件なのに長期記憶に関する項目が一切ない場合は、後から追加開発が必要になるかもしれません。

まとめ｜メモリ管理は「保存の設計」ではなく「捨て方の設計」

AIエージェントのメモリ管理は、覚えさせる技術ではありません。何を捨てるかを決める設計です。この視点に立つと、現場からの「全部覚えさせてほしい」という要望に対して、根拠を持って線を引けるようになります。

本記事の要点を整理します。

• LLM の API はステートレスであり、文脈保持は「毎回思い出させている」ことで実現されている。だから会話が長くなるほど入力量が増え、請求額が伸びる
• 費用は3つの経路で発生する。会話履歴の累積による入力トークン費用（経路1）、長期記憶の保存・検索費用（経路2）、そして文脈欠落による手戻り費用（経路3）
• 経路1と経路2は「増やすと高くなる」方向に、経路3は「減らしすぎると高くなる」方向に働く。適正ラインはこの交点にある
• 保持方式によって増え方の形が変わる。全履歴方式はターン数の2乗で増え、直近N件方式は直線的に増える。短い会話では差が出ないが、長い会話では数倍の差になる
• 適正ラインは業務タイプで変わる。単発Q&A型は長期記憶不要、継続的業務支援型は案件単位、個人最適化型は保存対象を限定した長期記憶が必要
• 長く多く覚えさせるほど、費用だけでなく情報管理の負担と記憶の鮮度維持の負担も同時に増える

次のアクションとして、以下の順で進めることをおすすめします。

1. 自社の業務タイプを特定する：会話をまたいで参照する情報があるか、あるならいつまで必要かを整理します
2. 保持範囲を仮決めする：業務タイプに応じて、保持期間・保持方式・保存対象を仮の要件として言語化します
3. チェックリストでベンダーに確認する：保持期間・保持方式・上限と超過時の挙動・課金単位・削除運用の5項目と、見積りの前提となる想定利用量を確認します

この3ステップを踏めば、見積りの内訳を自分の言葉で説明でき、想定利用量が変わったときに費用がどう動くかも予測できるようになります。メモリ管理の設計は、技術部門だけに委ねる話ではなく、費用を承認する立場の方が判断に関わるべき領域です。

次のアクション

AI エージェントの導入を検討する初期段階で、要件の整理や費用の見立てを進めたい場合は、はじめての AI 導入ガイド――中小企業が失敗しないための7ステップもあわせてご覧ください。導入判断から運用開始までの進め方を段階ごとに整理しています。

自社のユースケースに対して、どの保持方式が適しているか・見積りの前提が妥当かを個別に検討したい場合は、お問い合わせフォームからご相談いただけます。要件を整理する段階からのご相談にも対応しています。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。