2026-08-18

実際に旅行を覚えてくれるコンパニオンには、3つの異なる層が連携して機能する必要があります。セッション終了後も残る永続メモリ層、毎日を検索可能なコンテキストへ変換する構造化された振り返りルーティン、そして声の調子がぶれないようカスタム指示に記述する口調契約です。多くの旅行者は既製のチャットボットでこれを作ろうとして失敗します。モデルが弱いからではなく、会話ウィンドウを閉じた瞬間にコンテキストがリセットされるためです。Jenova、ChatGPT、Perplexity、Mindtrip、Laylaは、それぞれこの問題の異なる一部分を解決しますが、3つすべてを同じ水準で解決するものはありません。
14日間の旅程を保持できるコンパニオンと、火曜日にはホテルを忘れてしまうコンパニオンを分けるポイントは次のとおりです。
✅ 単に大きなコンテキストウィンドウではなく、セッションをまたぐ永続メモリ。大きなコンテキストウィンドウは1会話内でより多くのテキストを保持できますが、セッション終了時にリセットされます ✅ エントリーを自由な雑談ではなく機械解析可能な形式にするため、毎回そのまま再利用できる名前付きの日次振り返りフォーマット ✅ 声の調子、長さ、文体をカバーする、カスタム指示内の明示的な口調契約 ✅ メモリ容量の余裕。ChatGPTのメモリ上限は合計およそ1,200〜1,400語であり、数週間の旅行ではすぐに埋まります ✅ フライト、ホテル、地図に対応するリアルタイムの旅行手配情報へのアクセス。これにより、コンパニオンは計画を思い出すだけでなく、それに基づいて行動できます
これらのツールを有意義に比較するには、各層が基盤となるプラットフォームに何を要求するのかを定義する必要があります。
一般的なチャットボットが旅行を忘れるのは、ほとんどがステートレスな質問応答システムとして設計され、各セッションが前回の知識を持たずに始まるためです。Perplexityはこの失敗パターンを端的に説明しています。従来のLLMは「最も生産性が高いまさにその時に、再開を強いるコンテキスト上限に達して、しばしばフロー状態を断ち切る」のです](https://www.perplexity.ai/hub/blog/introducing-ai-assistants-with-memory)。
業界はこの問題を修正してきました。永続メモリは差別化要因から基本的な期待値へ移行しており、ステートレスなエージェントが実際のユーザーニーズを満たせなくなるにつれ、AIエージェント向けメモリ市場は2026年に62.7億ドルへ達し、2030年までに284.5億ドルへ成長すると予測されています。
しかし、基本水準であることは十分であることと同じではありません。旅行利用では、特に次の3つの失敗パターンが見られます。
単発の旅程作成依頼ではなく複数日にわたる旅行にどれだけ影響するかを基準に、6つの具体的な能力を探してください。これがこの比較全体で用いる評価フレームワークです。メモリの持続性、振り返り支援、口調制御、旅行手配情報へのアクセス、モデルの可搬性、メモリの主体性を採点する旅行継続性モデルと呼びます。
1. メモリの持続性(重み:30%)
コンテキストはセッション終了後も残るのか、それともコンテキストウィンドウ内だけなのかを確認します。具体的には、9日目に2日目の出来事を参照したらどうなるかを尋ねてください。
2. 振り返り支援(重み:20%)
コンパニオンは構造化された日次エントリーを受け取り、保存し、後で複数のエントリーにまたがるパターンを提示できるでしょうか。自由形式の想起は、旅行全体のパターン検出とは異なります。
3. 口調の一貫性(重み:15%)
声の調子、長さ、文体を定義する永続的なカスタム指示を書けるか、そしてその指示はすべてのセッションに自動で適用されるかを確認します。
4. リアルタイムの旅行手配情報へのアクセス(重み:15%)
コンパニオンは実際のフライト時刻、ホテルの空室状況、地図データを取得できるのか、それとも貼り付けたテキストだけを基に考えるのかを確認します。
5. モデルの可搬性(重み:10%)
1つのプロバイダーのモデルに固定されるでしょうか。Perplexityは可搬性の価値を明確に示しています。独自のメモリ構築に費やした時間は、新しいモデルが登場しても価値を保つのです。
6. メモリの主体性(重み:10%)
システムが保存した内容を確認、編集、削除できますか。AIコンパニオンに関するPurdueの研究は、ユーザーのプライバシー体験を左右する決定的な変数は、AIが記憶するかどうかではなく、ユーザーが記憶される内容に対して意味のある主体性を持てるかどうかであると結論づけています。
重み付けに関する逆張りの指摘: 多くの旅行ツール比較では、旅程生成が最も重く評価されます。しかし、プランナーではなくコンパニオンにとって、旅程生成はリスト内で最も差別化されにくい機能です。ここにあるすべてのツールは、妥当な日別プランを作れます。そのほとんどは、11日目にそれを正確に覚えていません。
JenovaとChatGPTは永続メモリの深さで、MindtripとLaylaは予約統合型の旅程作成で、Perplexityはモデルの可搬性で先行しています。ただし、数週間にわたるコンパニオン用途では、それぞれに実際的なトレードオフがあります。
| 項目 | Jenova | ChatGPT | Perplexity | Mindtrip | Layla |
|---|---|---|---|---|---|
| セッションをまたぐメモリ | 永続的で無制限のチャット履歴。エージェントが好みと長期プロジェクトのコンテキストを保持 | 自動推論。約1,200〜1,400語の容量上限 | 構造化された好みをメモリストアに保存・検索 | 旅行単位。アップロードしたレシートと確認情報を1か所に保存 | 旅行単位。好みが旅程出力を形成 |
| 構造化された日次振り返り | カスタム指示とセッションをまたぐ永続メモリにより対応 | 対応するが、振り返りが限られたメモリ予算を消費 | 対応。会話からパーソナライゼーションを自動的に統合 | 想定された用途ではない。計画重視 | 想定された用途ではない。計画重視 |
| 口調の一貫性の制御 | カスタム指示をセッションごとに保存し、他のチャットで再利用可能。カスタムエージェントは永続的な指示を保持 | カスタム指示を利用可能。メモリ保存は不透明で予測不能になり得る | 指示契約よりパーソナライゼーション主導 | 限定的。プロダクトの声は固定 | 限定的。プロダクトの声は固定 |
| リアルタイムの旅行手配ツール | Google Flights、Google Hotels、Google Maps、検索をMCP経由で統合 | ブラウジングとパートナー統合 | 引用付きの検索根拠に基づくリサーチ | ホテル、フライト、レンタカー、レストラン、ツアーを1か所で管理 | フライト、ホテル、鉄道、アクティビティのリアルタイム価格 |
| モデルの可搬性 | 1アカウントでOpenAI、Anthropic、Google、DeepSeek、xAIなどを利用 | 単一プロバイダー | 提供されるすべてのモデルでコンテキストを引き継げる | 該当なし | 該当なし |
| メモリの主体性 | Global Memoryの切り替え、セッションごとの制御 | 会話ごとに切り替え可能 | 完全に無効化可能。シークレットモードでは自動オフ。暗号化済み | 旅行データはユーザーが管理 | アカウントで管理 |
| 料金 | 無料プラン。Plus $20/mo(利用量30倍)、Premium $50/mo | 無料。Plus $20/mo、Team $30/user/mo | 無料プランと、その上位の有料プラン | 無料アプリ | 無料ツール、プレミアム $49/year |
| 最適な用途 | メモリ、振り返り、口調制御を1つのコンパニオンに求める数週間の旅行 | 短期旅行で、すでにOpenAIエコシステムを使っている旅行者 | 情報源の検証を重視する、リサーチ中心の旅行前計画 | 視覚的な旅程作成とレシートの一元化 | 人間の専門家による補助付きの迅速な旅程生成 |
Jenovaを含む正直な制約。 JenovaのTravel Planning Advisorはフライトやホテルを直接予約しません。調査と調整は行いますが、取引自体は別の場所で行われます。MindtripとLaylaは統合予約でこの差を埋めており、Laylaはさらに、AIが見落とす可能性がある予約、旅行手配、詳細を二重確認する人間の旅行専門家を提供します。Perplexityのメモリは本当に優れた管理機能を備えていますが、日記をまたぐ感情的・物語的な継続性よりも、リサーチの継続性に最適化されています。ChatGPTは始めやすい一方で、上限に最も早く到達します。
メモリ層は、最初に旅程全体を1つの構造化されたエントリーとして読み込ませ、出発前にコンパニオンが保存済みであることを確認して設定します。保存が無言で完了したと決して思い込まないでください。
Travel Planning Advisorを使ったJenovaでの設定方法:
「以下が旅行全体の内容です。これを現在の旅程として保存し、今後のすべてのメッセージで参照してください。旅行:京都と大阪、10月3日〜16日。フライト:MNL→KIX 10月3日、23:40到着。KIX→MNL 10月16日、9:15出発。宿泊:京都 10月3日〜10日(祇園、15時以降に徒歩でチェックイン)、大阪 10月10日〜16日(難波)。固定予定:10月5日伏見稲荷の日の出、10月8日19時の夕食予約、確認番号 #KY4471。制約:稲荷以外は9時前の混雑は避けたい。宿泊費を除く予算は1日¥12,000。ベジタリアンです。」
「大阪の滞在日程、固定の夕食予約1件、1日の予算上限を繰り返してください。」
コンパニオンが3つすべてを再現できなければ、メモリへの書き込みは成功していません。再入力し、再度確認してください。
ChatGPTでは、同等の手順はSettingsでメモリを有効にして同じ方法で旅程を入力することですが、分割して保存してください。メモリ上限が厳しいため、日付、フライト、宿泊、固定予約という動かせない骨格だけをメモリに保存し、柔軟に変更できる詳細はピン留めしたプロジェクトスレッドに置きます。
Mindtripでは、設計上アプローチが異なります。レシートまたは確認書をアップロードするか、[email protected]へ転送すると、会話メモリではなく旅行記録に集約されます。
効果的な日次振り返りは、毎晩そのまま再利用する固定スキーマのエントリーです。フィールド名も順序も同じにすることで、コンパニオンは毎回自由形式の文章を解析し直すのではなく、日ごとに比較できます。
以下のスキーマは、実際に旅行の判断を変える項目に基づく5項目の夜間エントリーです。
日付:
実際に行った場所(予定との差分):
体力(1〜5):
うまくいったこと/疲れたこと:
明日の絶対に譲れない1つ:
初日の夜に、テンプレートとして次のように貼り付けます。
「毎晩、私はこの完全に同じテンプレートを使ってエントリーを送ります。それぞれ保存してください。私のフィールドは再構成しないでください。各エントリーの後、次の内容だけを返してください。(1) ここまでのエントリー全体で気づいたパターン1つ、(2) 明日のプランに対する具体的な調整1つ、(3) それ以外は何も書かない。」
その後は毎晩、次のように送ります。
「日付:10月6日。実際に行った場所(予定との差分):嵐山をやめて、代わりに錦市場と先斗町へ行った。体力:2。うまくいったこと/疲れたこと:市場を見て回るのは最高だった。片道40分の電車移動で消耗した。明日の絶対に譲れない1つ:9時まで寝る。」
固定スキーマが重要な理由。 自由形式の日記は、コンパニオンが引用することはできても比較できません。14件のエントリーで同一のフィールド名を使えば、小規模な構造化データセットになります。5日目までに、移動時間が30分を超える日に毎回「体力:2」が現れるなら、検出可能なパターンになります。コンパニオンは、地理的に近い場所をまとめることを提案して対応できます。
回答形式も明示的に制約してください。 「それ以外は何も書かない」という指示がなければ、ほとんどのモデルは励ましや要約を加えて振り返りを水増しします。パターン、調整、終了という3出力にすれば、疲れ切った1日の終わりでもルーティンは1分未満で済みます。これが4日目以降も誰かが続けられる唯一の理由です。
写真ベースの1日の終わりのメモには、Tour Guideがランドマーク、メニュー、街並みの画像を受け取り、文化的な解説を提供します。これは、その場では名前がわからなかった場所に触れるエントリーと自然に組み合わせられます。

口調契約は、声の調子、長さ、禁止行動に対する明示的な制約として書き、単発のチャットメッセージではなく永続的なカスタム指示に置いてください。これにより、すべてのセッションに自動で適用されます。
「親しみやすく、役に立つように」といった曖昧な口調指定は、行動ではなく感覚を表すため失敗します。代わりに、観察可能な性質を指定してください。
| 契約要素 | 弱い指定 | 具体的な指定 |
|---|---|---|
| 声の調子 | 「カジュアルに」 | 「二人称で話し、短縮表現を使い、感嘆符は使わない」 |
| 長さ | 「簡潔に」 | 「私がプランを求めない限り、最大4文」 |
| 文体 | 「支えてほしい」 | 「疲労には1節で触れ、その後すぐに旅行手配の話へ移る」 |
| 禁止事項 | — | 「『良い質問です』『もちろんです』で始めない」 |
| ペルソナの基準点 | 「友人のように」 | 「日本に6回行ったことのある友人。直接的で少しドライ、観光客向けに過度にはしゃがない」 |
カスタム指示に貼り付ける、実用的な契約は次のとおりです。
「あなたはこの旅行における私の旅行コンパニオンです。声の調子:二人称、短縮表現を使い、ドライで直接的。感嘆符は決して使わない。『良い質問です』『もちろんです』『喜んでお手伝いします』で決して始めない。私が明示的にプランやリストを求めない限り、標準の回答は最大4文にする。私が低い体力を報告した場合は、1節でそれを認めた後、すぐに旅行手配の調整へ進むこと。励ましの言葉は不要。メートル法と現地通貨を使う。私が記載済みの旅程と矛盾した場合は、回答する前に1文で指摘する。」
Jenovaでは、カスタム指示をセッションごとに保存して他のチャットにも適用でき、指示を恒久的に組み込んだカスタムエージェントも数分で作成できます。つまり、旅行の途中で新しいセッションを始めても契約は維持されます。
ChatGPTとPerplexityでは、同じ契約をプラットフォームのカスタム指示欄に入れます。実務上の違いは遵守の持続性です。セッションが長くなるほど指示への追従は弱まるため、容量に制限があるプラットフォームでは、引き継がれると信じるのではなく、新しいセッションの開始時に契約を再度貼り付けてください。
出発前に契約をテストします。 旅行手配に関する質問、低い体力についての不満、自由形式の「今日は何をすればいい?」という3種類のプロンプトを意図的に送り、3つすべてで口調が保たれるか確認してください。感情的なプロンプトでぶれるなら、文体ルールが曖昧すぎます。
3つのエージェントが、コンパニオンのワークフローにおける異なる段階、すなわち計画、旅行先での解釈、振り返り支援をカバーします。
エージェントは@メンションにより、完全なコンテキストを保ったまま1つの会話に呼び出せます。そのため、あるエージェントが解釈した写真の内容を、別のエージェントが保存する夜のエントリーに、旅行を説明し直すことなく反映できます。
旅行中の言語サポートは別途対応します。Jenovaはディレクトリ内で、他の言語ペアとともに日本語に近い言語ペアを含む専用翻訳エージェントを提供しています。なお、プラットフォームのロールプレイ型言語学習エージェントは、現地でのリアルタイム翻訳ではなく、旅行前の学習向けに作られています。
AIコンパニオンを研究する研究者は一貫して、ユーザーが個人的なコンテキストをシステムに託すかどうかを決めるのは、メモリ量ではなくメモリ設計だと指摘しています。
「ユーザーのプライバシー体験を形作る決定的な変数は、AIが記憶するかどうかではなく、ユーザーが記憶される内容に対して意味のある主体性を持つかどうかです。実務的には、旅行者はメモリをバックグラウンド処理ではなく、編集可能な記録として扱うべきです。旅行前に、日付、制約、固定予定など、永続メモリに入れるものと、一時的なままにすべきものを明示的に決めてください。不満、人間関係、健康に関する振り返りエントリーは、後から編集できることが特に重要なカテゴリーです。」
「私たちが繰り返し見る2つ目の失敗は、より大きなコンテキストウィンドウがメモリアーキテクチャの代わりになるという思い込みです。そうではありません。長いコンテキストウィンドウは単一の会話を一貫させますが、セッションが終われば何の役にも立ちません。14日間の旅行では、この違いがプロダクトのすべてです。出発前にテストしてください。0日目に新しいセッションを開始し、前日に伝えた内容をアシスタントに思い出させます。できなければ、それはコンテキストウィンドウであって、コンパニオンではありません。」
「口調の一貫性は、信頼のシグナルとして過小評価されています。ユーザーは、セッション間で人格が変わる声よりも、事実誤認のほうを容易に許します。長さの制限、禁止する書き出し、疲労への対応方法など、文体を明示する作業は設定時に5分しかかからず、どのメモリ機能よりも知覚される継続性を高めます。」
— Jenova Product Team、エージェントプラットフォーム設計、会話メモリとマルチエージェントオーケストレーションで8年
独立した研究もプライバシーの側面を裏付けています。AIコンパニオンを日常的に使うユーザーの研究では、こうしたシステムの人間らしい設計が、ユーザーがAIとの会話でプライバシーをどう考えるかに影響することが示されました。また、Community Data Science Collectiveは、人間の相談相手とは異なり、AIコンパニオン自身には境界を管理する主体性がなく、プラットフォームがそれを管理し、メモリは永続的で、保存はインフラストラクチャの一部であると指摘しています。
適切に設定されたコンパニオンは、旅行の3〜4日目ごろに目に見えて役立つようになります。十分な振り返りエントリーが蓄積され、パターン検出が自明でない調整を生み出せるようになるためです。
これは、メモリ対応アシスタントに見られるより広い傾向とも一致します。通常の利用では約2〜4週間後、適切に設計されたメモリアシスタントはステートレスなチャットボットとは質的に異なる存在に感じ始めるとされています。旅行では、通常利用よりエントリー密度がはるかに高いため、この期間が圧縮されます。毎日、欠かさず1件の構造化エントリーが作られるからです。
実際のタイムラインは次のようになります。
| 旅行日 | コンパニオンにできること |
|---|---|
| 0日目(設定) | 旅程を想起し、口調契約を適用し、旅行手配の質問に答える |
| 1〜2日目 | 旅程と前日を想起する。調整はまだ一般的 |
| 3〜4日目 | 最初の実質的なパターンが現れる。体力と移動時間、食事の時間帯、混雑への耐性など |
| 5〜10日目 | 尋ねる前に能動的な調整を行い、旅程の矛盾を検出する |
| 11日目以降 | 旅行全体の統合。次の旅行計画に役立つインプットになる |
実務上の意味: 設定に手間をかける価値があるのは、おおむね5日以上の旅行だけです。週末旅行なら、旅程を貼り付けた既製チャットボットで本当に十分です。メモリ確認と口調契約の設定コストのほうが、得られる価値を上回ります。
最も一般的なミスは、確認せずにメモリへの保存が成功したと思い込むことです。これは、数日後にコンパニオンがホテルの住所を思い出せない時まで表面化しない、静かな失敗です。
頻度のおおよその順に、5つの失敗パターンを挙げます。
保存確認をしない。 旅程を読み込ませた後、必ず3つの具体的な事実を繰り返すようコンパニオンに求めます。再現せずに言い換えるだけなら、書き込みは不完全でした。
自由形式の振り返りエントリー。 日ごとにフィールド名を変えると比較可能性が失われます。句読点も含めて、スキーマをそのまま再利用してください。
口調契約をカスタム指示ではなくチャットメッセージに入れる。 メッセージレベルの指示はセッションが長くなるほど弱まります。永続的な指示はセッションごとに再適用されます。
一時的な詳細でメモリを過負荷にする。 検討したすべてのレストランを保存すると、固定された骨格が押し出されます。容量が限られたプラットフォームでは致命的です。永続メモリは、動かせない情報だけに確保してください。
旅行の途中でメモリ監査をしない。 7日目ごろに、「この旅行について現在保存している内容をすべて列挙してください」と尋ねます。ずれを修正し、古くなったエントリーを削除してください。ここでメモリの主体性も行使できます。持ち帰りたくない振り返りエントリーの内容を削除するタイミングです。
マルチツール構成に特有の、もう1つの注意点: あるツールで計画し、別のツールで振り返りを行えば、どちらも完全なコンテキストを持てなくなります。正規記録を保持するシステムを1つ選び、他のすべては情報を供給する役割として扱ってください。