「自然な旅行プラン」は一日にして成らず。AIプロンプト設計の泥臭い試行錯誤

こんにちは、Tabidea 開発者の Tomokichi です。

前回の技術スタックの話に引き続き、今回はTabideaの心臓部であるAI(LLM)へのプロンプト設計について、泥臭い開発の裏側をお話しします。「ChatGPTのAPIを叩けば、簡単に旅行アプリが作れるでしょ？」 Tabideaを作り始めた当初、私も少しだけそう思っていました。しかし、いざ開発を始めてみると、AIが生成する旅行プランは「ツッコミどころのオンパレード」だったのです。

初期AIが叩き出した「地獄の旅行プラン」

最初のプロンプトは、ごくシンプルなものでした。 あなたは優秀な旅行プランナーです。ユーザーの要望に合わせて1日の旅行プランを提案してください。 結果として返ってきたのは、以下のような人間を無視したプランです。

❌ 瞬間移動プラン 「10:00 浅草寺 → 11:00 鎌倉大仏」（移動に1時間半かかるのに、見学時間を無視している）

❌ ストイックすぎる修行プラン 「9:00 神社A → 10:00 神社B → 11:00 神社C → 12:00 神社D」（観光地をひたすら詰め込み、休憩や食事の概念がない）

これらは、AIが「テキスト上の関係性」は理解していても、物理的な距離人間の体力時間の制約といった現実世界の文脈(コモンセンス)を理解していないために起こります。

自然なプランを作るための「プロンプトの3本柱」

この「地獄のプラン」を「人間にとって心地よい自然なプラン」に引き上げるため、Tabideaの裏側のプロンプトは、何度も何度も改修を重ねて現在に至ります。特に効果的だった3つの工夫を紹介します。

1. 「時間」と「体力」の制約を明示する

AIに「人間らしさ」を教えるため、プロンプトに強い制約（ルール）を書き込みました。

スポットの滞在時間は、その場所の規模に応じて最低45分〜120分を確保すること。

移動時間は仮の計算で構わないが、最低でもスポット間に30分のバッファを持たせること。

1日に回る主要観光スポットは、多くても3〜4箇所に留めること。詰め込みすぎは厳禁です。

2. 「なぜそのスポットなのか」という理由（Reasoning）を出力させる

LLMは、思考の過程をテキストとして出力させることで、論理的な破綻が少なくなる特性があります。ただスポットを列挙させるのではなく、内部データとしてなぜ前のスポットからここを選んだのかなぜこの時間帯なのかという理由を必ず出力させるようにしました。

3. JSON スキーマによる厳密な構造化 (Structured Output)

UIに綺麗にマッピングするために、AIの出力は完璧なJSONフォーマットである必要があります。 OpenAIの Function Callingを駆使し、スキーマを強制しています。

「プロンプトエンジニアリング」は「ユーザー理解」である

プロンプトをいじり続けて気づいたのは、AIにうまく指示を出せないのは、自分自身が良い旅行プランとは何かを言語化できていないからだということです。「のんびりしたプランにして」と指示して失敗するのは、「のんびり」の定義が曖昧だからです。 AI開発におけるプロンプト設計は、単なる「呪文探し」ではなく、人間が心地よいと感じる体験(UX)を、徹底的に解像度高く言語化する作業なのだと実感しています。