**「sfo-jfk」を適切な写真に変える方法** 1. **適切な画像を選ぶ** - サンフランシスコ国際空港（SFO）またはジョン F ケネディ国際空港（JFK）の高解像度写真を探します。 - 両方を表示したい場合は、分割画面レイアウトを検討してください。 2. **文脈に合ったテキストを追加** - HelveticaやArialなどのクリーンなフォントを使用します。 - 「sfo-jfk」を中心または角に配置し、重要なディテールを遮らないようにします。 3. **視覚効果を施す** - 画像が際立つよう明るさとコントラストを調整します。 - テキストの読みやすさを高めるため、薄い影や輪郭を追加します。 4. **適切な形式でエクスポート** - ウェブ用は72 dpiでJPEGまたはPNGに保存し、印刷用は300 dpiに設定します。 - オンライン共有の場合はファイルサイズを2 MB以下に抑えます。 5. **オプション：地図オーバーレイを入れる** - ２つの空港を結ぶ薄い線を追加し、ルートを視覚化します。 - 各端に「SFO」と「JFK」をラベル付けします。 これらの手順に従うことで、単なる文字列「sfo-jfk」をプレゼンテーションやソーシャルメディアに適した魅力的でプロフェッショナルな写真へと変換できます。

味覚を持つ AI アプリのデザイン

「sfo‑jfk」のような自由形式クエリを、美しい画像に変えるにはどうすればよいのでしょうか？

実は、最近この問題に直面しました。ユーザーが旅行を作成するとき、その目的地の美しい写真を見つけて提示する必要があります。そのためには、「何でも理解して手作業で選んだ写真を返せる」システムが不可欠です。

私が行った解決策は、LLM（大規模言語モデル）で意味を解析し、その間に従来のソフトウェアエンジニアリングを挟み、最後に優れた写真家が撮影した画像を人力でキュレーションするというものでした。以下では、このプロセスを踏むことで、AI を「乱雑さ」ではなく「仕上げられたもの」として活用できるヒントを共有します。

問題設定

Stardrift という AI 旅行計画アプリで、ユーザーはチャットボックスに好きなことを書き込みます。
その入力から、魅力的なホームページ画像を作成する必要があります。

いくつかの単純な解決策（実際には難しい）

• AI 生成画像：各会話ごとに AI が画像を描く
  • ただし、AI 生成はクオリティが低く、コストも高い。
• Google 検索：目的地の写真を検索
  • 著作権問題や「これは Buffalo, NY の写真か？」という不確定要素があります。

結局私がしたかったことは、「場所」→「画像」の美しいマッピングを手動で作成し、任意のクエリに対応させることでした。
この課題を分解すると、3 つの主要な問題に落ち着きます：

1. 自由形式クエリ（例：sfo→jfk） を 場所 に変換する。
2. 場所 → 写真 のデータベースを構築する。
3. 上記を結合し、データベースに無い場所でも「近似」画像を返せるシステムを作る。

1. 「場所」とは何か？

技術的には最も単純ですが、設計上は最も難しい部分でした。
現在では Haiku のような LLM に「SFO‑JFK tomorrow」を投げて、行き先を教えてもらうことができます（5 年前なら不可能だった技術です）。

しかし何を求めるかを慎重に決める必要があります。

• 「SFO‑JFK」 → 「ニューヨーク」 を返すべき
• 「Plan me a road‑trip around the Isle of Skye」→ スコットランド全体ではなく、実際の “Isle of Skye” の写真を返す

多くの場合、ユーザーはチャット内で複数場所を言及します。
「フランス・ドイツ・ベルギーを巡るハネムーン」などです。
そこで私は「場所」を （名前＋タイプ） と定義し、クエリからそのリストを作る設計にしました。

class Place:
    type: Union["region" | "city" | "country"]
    name: str

def query_to_place(query: str) -> list[Place]:
    ...

• sfo‑jfk

  →

  [Place(type="city", name="New York")]

• Plan me a 3-day road trip around the Isle of Skye

  →

  [Place(type="region", name="Isle of Skye")]

2. 「場所」→画像のマッピングを作る

「場所」の定義ができたので、実際に写真データベースを構築しました。
これは最も楽しかった部分です。

1. 上記

   query_to_place

   を実際の Stardrift クエリサンプルに適用し、人気順に並べました。
2. Unsplash（高品質なフォトバンク）から API で上位5枚を取得する内部ツールを書きました。
   • 1 時間あたり約20件しか処理できない制限があるため、数日かけて初期データベース（500 件程度）を作成しました。

結果として「場所」に対して美しい写真が紐付いたデータベースを手に入れました。

3. システム全体を統合

クエリ→場所、場所→画像のマッピングはできたものの、ユーザーは想定外の場所を問い合わせることがあります。
LLM は「NYC」「New York」「New York City」など表記がバラつくため、完全一致で検索すると失敗します。

そこで Google Maps を利用して 任意の場所名 → 緯度・経度 に変換し、データベース内に最も近いポイントを探す方法を採用しました。

例：

• Deadvlei

  （知らない場所）
  • API が (24.7° S, 15.2° E) を返す → データベース上で最も近い点は (24.8° S, 15.3° E) の Namibia
  • 「美しいナミビアの海」の画像を返す

この手法でほとんどのケースに対応できますが、欠落している場所（主にアフリカ・南米）が残ります。そこでマップ上でギャップを確認し、手動で補完しました。

最後に

システムにはいくつかの課題があります：

• 都市は多いが地域は少ない → 「Gold Coast」→「Brisbane」の画像になることも。
• 私の好み（ゴールデンアワー）に偏りがある。

とはいえ、これは小規模でありながら洗練された AI プロジェクトです。
最高の AI 製品は すべてを AI に任せる ものではなく、AI が得意とする領域だけに使うものです。このケースでも、ソフトウェアエンジニアリング・AI エンジニアリング・人力キュレーションを組み合わせました。

Stardrift の技術ブログからのクロス投稿です。
Write & Learn ミートアップでこの記事を書いた Sarah Chieng と swyx に感謝します。