「7年前の失敗」へのリベンジ：Agent Memoryが変える予約システムの未来

今から7年前、私は世界第3位の規模を誇る予約システムの構築プロジェクトに参画していました。

予算はxx億円?（構築ベンダー５〜６社：Marketing、顧客カルテ、予約システム、顧客ポータルなど）。ある大手ベンダーのパッケージをベースにカスタマイズする方針でしたが、結果は――「プロジェクト中止」でした。

理由は明確でした。

• 性能が出ない：複雑なリソースの空き状況計算にDBが耐えきれない。
• ロジックの破綻：顧客ごとに所要時間が変わるなどの「複雑な予約」を、パッケージの硬直的なデータ構造では吸収できず、スパゲッティコードと化した。

結局、スクラッチで作り直す話が出たり、運用に耐えないと判断されたりと、現場はボロボロでした。

しかし今、生成AIの進化、特に「RAGからAgent Memoryへ」の流れにより、あの時あきらめた理想を実現できる可能性が見えてきました。

本記事では、過去の「痛み（Pain）」から学んだ、Agent時代における新しい予約システムのアーキテクチャ案（Learn From Pain）を共有します。

1. なぜ、従来のDB中心型は「大規模・複雑予約」で死ぬのか

従来の予約システムは、AIの文脈で言うと「Naive RAG」に近い構造をしています。基本的に「ユーザーが来るたびにデータベース（DB）を見に行き、その時点の結果を返す」仕組みです。

💀 課題①：UXを破壊する「椅子取りゲーム」

アクセスが集中すると、DBロック待ちが発生します。「空きがあります」と画面に出ているのに、入力して確定ボタンを押すと「埋まりました」とエラーになる。 これは、「検索した瞬間」と「予約確定した瞬間」のタイムラグを、DBのトランザクションだけで制御しようとするために起こる「ガッカリ体験」です。

💀 課題②：動的リソース計算の限界

私が7年前に最も苦しんだのがここです。例えば「脱毛サロン」の予約を想像してください。

• Aさん（小柄）：施術範囲が狭いので45分
• Bさん（大柄）：施術範囲が広いので60分

これをSQLや静的なロジックで実装しようとすると、条件分岐が爆発します。さらに「部屋の空き」と「スタッフの空き」と「機材の空き」をクロスチェックして...となると、DBへの負荷は指数関数的に跳ね上がり、システムは停止します。

2. 解決策：Agentを「交通整理役（Dispatcher）」にする

この問題を解決するのが、「Memory in Agents」のアプローチです。

予約リクエストを直接DBに投げるのではなく、「文脈（Context）と記憶（Memory）を持ったAgent」に投げます。Agentはステート（状態）を保持し、ユーザーとの対話の中で、メモリ上で高速に交通整理を行います。

アーキテクチャの比較

以下は、従来型とAgent型の違いを示した図です。

3. シナリオ：Agentの「脳内」で起きていること

では、実際にAgentのメモリ（Short-term Memory）でどのように予約が捌かれるのか、具体的なシナリオで見てみましょう。

シチュエーション：8月2日 16:00〜 の残り1枠を巡る攻防

処理フローの可視化

Agent内部での処理詳細

同時多発的な問い合わせ（14:06:10）

山田さん、鈴木さん、佐藤さんが同時にアクセスします。DBには行きません。Agentのメモリ上のキューに入ります。

Agentによる調停（14:06:11）

Agentは考えます。

• 「現在空きは1枠のみ」
• 「山田様はVIP（LTVが高い）だ」

判断： 山田様のためにメモリ上で仮押さえ（Soft Lock）を実行。

3.ユーザーへの回答（14:06:12）

• 山田さんへ： 「予約可能です（5分間枠を確保しています）」
• 鈴木さん・佐藤さんへ： 「申し訳ありません、現在キャンセル待ちです」

4.遅れてきたユーザーへの対応

後から来た田中さんが検索しても、Agentは自分のメモリを見て「満席です」と即答します。DBへの負荷はゼロです。

4. Agent Memory アプローチがもたらす3つの革命

①「ぬか喜び」させない確実なUX

「画面で見てから確定ボタンを押す」までの間に席がなくなる悲劇を防げます。Agentがコンシェルジュのように「席を取っておきましたよ」と振る舞うからです。

②「複雑な所要時間」も対話の中で解決

Agentは顧客プロファイル（Memory）を参照できます。「山田さんは前回時間がかかったから、通常45分のところを60分枠で計算しよう」といった動的な調整を、複雑な改修なしにAgentの推論で行えます。これこそが、かつてパッケージシステムでは実現できなかった柔軟性です。

③ DB負荷の劇的な低減

Read（参照）リクエストの大部分をAgentのメモリで捌くため、バックエンドのDBは「確定した予約（Write）」のみを受け付ければ良くなります。大規模アクセス時のパフォーマンス問題が根本から解消されます。

5. 仮説から実装へ：次なる挑戦

もちろん、今回ご紹介したアーキテクチャは現時点では「発想（Idea）」の段階です。実運用レベルでのレイテンシや、Agentインスタンスが落ちた場合の復旧プロセスなど、フィジビリティ（実現可能性）の確認はこれから必要になります。

しかし、直近でいくつかのAgentシステムを構築してきた私の経験則から言えば、この設計は技術的に十分「実現可能」であると確信しています。

かつてのように、できないことを無理やりRDBでやろうとするのではなく、LLMとAgentの特性を活かした自然な設計だからです。

Next Step

私はこの「Pain」を解消するために、実際にAgent Memoryを用いたプロトタイプを作成し、技術検証（PoC）を行う予定です。

• 本当に数千リクエストを捌けるのか？
• Agentのメモリ管理は破綻しないか？

その検証結果については、また別の機会に技術的な詳細とともに発表させてください。

結論：7年前の悪夢を終わらせる

かつてxx億をかけても実現できなかった「理想の予約システム」。

それが今、Agentic RAG / Agent Memoryという技術によって、よりシンプルに、よりスマートに構築できるようになりました。

静的なデータベースを管理するのではなく、動的な状態（State）を持つAgentを管理する。

このパラダイムシフトこそが、次世代の予約システム構築の鍵となるはずです。この実験と挑戦に、ぜひご期待ください。