NOT A HOTELのAIコンシェルジュ「Kevin」の開発における苦悩。AIエージェント開発に必要な技術と開発思想のUnlearn

こんにちは。NOT A HOTELでAI EngineerとしてAIコンシェルジュ「Kevin」の開発を行っている佐藤 裕介と申します。

実はAI Engineerを名乗るのはこのnoteが初めてで、元のロールとしてはProduct Managerです。

なのに今回あえて「AI Engineer」と名乗った背景は、AI プロダクト（≒ AIエージェント）の開発の前提となる思考方法が、従来のプロダクトとは大きく異なっており、僕自身が自社のAIコンシェルジュ「Kevin」の開発・改修を推進する中で、思考方法をUnlearnすることが必要だったことに起因します。

このnoteでは「弊社のプロダクト開発に特化した話」や、「最新のAI ツールのTips」は取り扱わず「AI プロダクトを作るための前提となる知識や知見」を共有したいと思っています。

AI プロダクトを開発したいと考えているソフトウェア開発者はもちろん、この領域に少しでも興味を持っているビジネスパーソンの方々にも読んでもらえると嬉しいです。

AIの「記憶」はどのように実装されているのか

この次にAIが「あなたは佐藤さんですよね」と答えられることをもって、このnoteでは「AIに記憶が実装されている」と定義します。

とはいえ、ChatGPTやGeminiやClaudeを使っていると、AIが「あなたは佐藤さんですよね」と答えられることは当然であると感じるはずです。
しかし、上記の会話を成立させるためには「AIに対して記憶が実装されていること」が前提であることを、僕たちは理解しなければいけません。

大規模言語モデル（LLM）は記憶を持たない

ChatGPTやGeminiなどのAIチャットサービスの基幹技術となる大規模言語モデル（以降 LLM と呼称）は、元来、記憶を持たないステートレスな存在です。
そして、上記に対して「記憶」と呼べる仕組みを実装したものが、僕たちが普段使っているChatGPTなどのサービスとなるのです。

LLMは入力に基づいて確率的に応答を生成しますが、過去のメッセージ履歴やユーザー情報をLLM自体の内部に保持しているわけではありません。
つまり「記憶」と呼ばれるものはLLMそのものの機能ではなく、アプリケーション側に後から実装された仕組みなのです。

今日では「AIが記憶を持っていること」が、当然の体験となっています。
そのため「記憶はアプリケーション側で実装された機能である」という事実は、AIプロダクト開発において見過ごされがちな前提となっています。

AIプロダクトは、なぜ記憶があるように振る舞えるのか

ではAIの「記憶」はどのように実現しているのか。2025年10月時点では、実は、以下のように、とてもシンプルな仕組みによって成り立っています。

このように、僕たちがAIに対してメッセージを送信すると、ユーザーには不可視なところで、それ以前の全てのメッセージ内容が都度、AIに対して送られています。
そしてAIはそれら全てのメッセージの内容をもとに、次にユーザーに送るメッセージ（レスポンス）を生成します。「AIの記憶」にあたるものの正体は、こんなにも単純な仕組みなのです。

余談ではありますが、LLMには、一度に処理できる情報量（= Max Token）の上限が設けられており、その制約に対応する機能の影響で「AIと長く会話をしていると回答精度が下がる」という現象につながります。

具体的には、メッセージのやり取りを繰り返していくことで、送信するメッセージの量がMax Tokenに近づくと、アプリケーション側で「これまでの会話内容を要約して保持する」仕組みが動作します。

しかし、その要約の過程でユーザーが重要だと感じている情報が省かれてしまうことがあり、その結果、私たちは「AIの回答が少しずつ的外れになってきた」と感じるのです。

世の中のAIプロダクトは「AIが記憶を持っていること」が、当然の要件になっていますが、上記のように、これ自体はアプリケーション側の機能であってLLMが元来から備えている機能ではありません。
ですので、僕自身がAIプロダクトの開発に対して本格的に携わる中で、最初に理解が必要だった点が「AIへの記憶の実装」でした。

ここまでで、僕たちが経験的に理解している「長期間のチャット継続による回答精度の低下」を例にあげながらLLMの特性について説明いたしました。

AIの短期記憶（= コンテキスト）をマネジメントすることで回答精度を引き上げる

結論から申し上げますと、2025年10月時点でAIプロダクト（≒ AIエージェント）の開発や改善に対して、最も重要なことのひとつが「AIに記憶させることのマネジメント」です。

その点をご理解いただくために、少し遠回りに感じたかもしれませんが「元来ステートレスなLLMが、記憶をもっているように振る舞うための機能実装」を説明させていただきました。

ここからは具体的な例をもとに、コンテキストの設計について説明していきます。

AIプロダクトの改善ポイントは「プロンプト + コンテキスト」

AIチャットサービスが登場した当初から「プロンプト（= LLMへの指示）」が重要であることは広く知られており、今日でもそれは変わっていません。それに加え、2025年10月時点においては「コンテキスト（= LLMに対してサービス側が動的に注入する情報）」の有効性が注目されています。

実際の設計の例

ここでは「お買い物アドバイザー AIエージェント」を例に考えてみましょう。
まずは基本となるプロンプトは以下のようなものが想定できます。

# 役割
- あなたはユーザーのお買い物のアドバイスを行うエージェントです。

# 会話の方針
- ユーザーの預金の入出履歴を参照して、ユーザーが購入しようとしている商品が無理なく購入できるかを検討してください。
- ユーザーが購入しようとしている商品が現在の預金残高を上回っている場合、慎重な検討が必要である旨を伝えてください。
- ユーザーが購入しようとしている商品が、過去にユーザーが「やっぱり要らないかもと思った商品」と近い場合は「前に要らない」と言っていた旨を伝えてください。

ここで重要なのは「ユーザーの預金の入出履歴」「現在の預金残高」「やっぱり要らないかもと思った商品」は、変数である点です。

これらの情報は「プロンプト」の一部として取り扱われますが、AIプロダクト側が「コンテキスト」として常に最新の情報を管理することで、AIのメッセージの生成精度を高めることができます。

以下はコンテキストとして情報を注入した例です。

# 役割
- あなたはユーザーのお買い物のアドバイスを行うエージェントです。

# 会話の方針
- ユーザーの預金の入出履歴を参照して、ユーザーが購入しようとしている商品が無理なく購入できるかを検討してください。
- ユーザーが購入しようとしている商品が現在の預金残高を上回っている場合、慎重な検討が必要である旨を伝えてください。
- ユーザーが購入しようとしている商品が、過去にユーザーが「やっぱり要らないかもと思った商品」と近い場合は「前に要らない」と言っていた旨を伝えてください。

# ユーザーの資金状況
- 更新日時: 2025年10月01日
- 通帳残高: 1,000,000 円
- 入出履歴
	- 2025年10月01日,入金,金額 100,000 円,配当
	- 2025年09月30日,出金,金額 500,000 円,ローン返済

# 要らないと言ったもの
- メガネ: 最近ICL手術をした。今後メガネは基本的に不要なはず。すでにたくさん持っている。
- カメラ本体: コンデジタイプのカメラもレンズ交換式のカメラも複数所有している。慎重に考えるべき。
- 自動車: 通勤は電車なので自動車の利用シーンが限定的。買い増すにも駐車スペースがない。

例の中の「ユーザーの資金状況」は、データベースの値を参照して注入することで解決できそうですね。

一方で「要らないと言ったもの」は、データベースで管理することもできますが、会話の流れの中で「要らないと言ったものリストに登録していいですか？」と逐一確認されるのは、体験として自然ではありません。

そういったシチュエーションに向けて、特定の情報（この例では”ユーザーがやっぱり要らないといった商品”）に注目させて、会話内でその情報を取り扱った際に、AI自身が一時的に記憶・参照できるようにする技術も存在します。

コンテキストをマネジメントしてAIの自律性を高める

このように「お買い物アドバイザー AIエージェント」の例では、AIがそれまでの会話履歴を覚えていること（= 記憶していること）に加えて、サービス固有の情報がコンテキストとして伝達・更新されることで、AIが自律的に状況を判断したり、適切なアドバイスを行うことが可能になります。

上記を踏まえながら、さらに「お買い物アドバイザー AIエージェント」による体験の品質を高めようとした場合、例えば以下のような情報をコンテキストに加えることで、回答や対応できるシチュエーションが広がるかもしれません。

• ユーザーが直近購入した商品のリストをコンテキストに加える

  • → 似た買い物をしようとした際に警告する

• 資金の定期的な入出予定の情報をコンテキストで加える

  • → 分割払いやローンを使った購入計画の立案

まとめ: 「AIが何をどのように記憶するか」がAIプロダクトの開発の鍵

現在、僕は NOT A HOTEL ではオーナー向けのAIコンシェルジュ「Kevin」の改修に継続して取り組んでいます。
開発・改修の中で、AIの回答品質が一定にならなかったり、期待した接客を行わない状況に、何度も遭遇しました。

従来型のソフトウェア開発では「バグを修正する」という思考方法で問題解決が可能でしたが、AIプロダクトにおいてはそうはいきません。

AIの挙動のゆらぎは、コード上の誤りではなく、AIの“記憶”や“コンテキスト”がどのように形成・伝達されているかに起因します。
そのため、僕たちは「エラーを潰す」ではなく「ゆらぎを抑える」という思考方法 ── つまり、AIの記憶やコンテキストをトレースしながら開発や改修を進める必要がありました。

そして、まさにこの転換は僕自身にとって、従来の開発からAIプロダクトの開発に向けた思考のUnlearnそのものでした。

ご存知の通り、AIプロダクトの開発を取り巻く技術は非常に早いスピードで変化を続けています。

一方で、LLMの基幹技術が一新しない限り、「LLM」を「AIプロダクト」に昇華させるためには「記憶機能の実装が必要であること」と「コンテキストのマネジメントが有効であること」は変わらないでしょう。

それを踏まえ、このnoteが、これからAIプロダクトの開発や改修に携わる方々の情報のキャッチアップや開発思考のUnlearnの一助につながれば幸いです。