TRIP×TRIP 修正記録（learn.md）
TRIP×TRIP 修正記録（learn.md）
⑥分析担当が毎サイクル追記していくファイル。新しい記事を作る前や、不具合対応をする前に必ず目を通すこと。古い記録も削除せず残す（同じ失敗を繰り返さないため）。
2026-09-30: custom-head.html が一度も読み込まれていなかった
何が起きたか：地図やタグの見た目CSSが、記事ページで一切反映されていなかった。JS側のtry/catchには何のエラーも出ず、原因究明に長時間かかった。
原因：GitHub Pagesが実際に使うminimaのバージョン（v2.5.1）の head.html には `
` の呼び出しが存在しない（この機能は未リリースのmaster版にしかなかった）。そのため _includes/custom-head.html に書いたCSSがどのページにも出力されていなかった。
直し方：_includes/head.html を自前で作り、minimaのデフォルトを上書きした上で明示的に `
` を呼ぶようにした。
教訓：CSS/JSが「動いていないように見える」バグは、コード自体のロジックミスだけでなく「そもそも読み込まれていない」可能性を先に疑うこと。本番HTMLを実際に取得して、目的のクラス名やスタイルが出力に含まれているか確認するのが一番早い。
2026-09-30: fine-grained PATの書き込みが権限設定通りにいかなかった
何が起きたか：GitHub の fine-grained Personal Access Token で「Contents: Read and write」を設定したはずなのに、Contents APIへのPUTが 403 Resource not accessible by personal access token で失敗した（2回、別々のトークンで再現）。
直し方：classic PAT（scopeは repo のみ）に切り替えたところ、即座に成功した。
教訓：このリポジトリでのGitHub Contents API書き込みは、classic PAT（repoスコープ）を優先して使う。fine-grained PATは画面上の設定が正しく見えても失敗することがある。
2026-09-30: 推奨泊数が移動時間に対して短すぎた
何が起きたか：ボラカイ島の「予算の目安」見出しが2泊3日になっていたが、同じ記事内の「おすすめ旅程」は3泊4日で書かれており矛盾していた。ユーザーからも「2泊3日は無理があるのでは」と指摘された。
直し方：destinations.yml の recommended_nights を、片道移動時間が9時間を超える行き先はすべて「最低3泊」を基準に統一。予算見出しの泊数と旅程の日数も一致させた。
教訓：「予算の目安」見出しの泊数と「おすすめ旅程」の日数は必ず一致させること（③企画担当・⑤直す担当の両方でチェック）。推奨泊数は「移動時間を差し引いても現地で2日は楽しめるか」を基準に決める。
2026-09-30: 表のセル背景が周囲から浮いて見えた
何が起きたか：ページ全体の背景はクリーム色（#F7F3EA）なのに、表のセル背景に純白（#FFFFFF）を使っていたため、「白抜き」の不自然な四角に見えるとユーザーから指摘された。
直し方：表のセル背景をページと同じクリーム系の色に統一。当初ゼブラ模様（濃淡2色）にしたが、ユーザーの希望で単色に戻した。
教訓：カード要素の背景に白（--sb-card）を使う場所と、ページに溶け込ませたい要素の背景（--sb-cream）を混同しないこと。新しい要素を追加する際は、どちらの意図かを最初に決める。
2026-09-30: JSソース内の文字列一致は動作確認にならない
何が起きたか：grepでJSソースコード中に 'quick-facts-table' などの文字列があることを確認して「正しく動いている」と誤判断したことが複数回あった。実際にはCSSが読み込まれていなかった（上記の学びを参照）。
教訓：ソースコードに文字列があることは「そのコードが存在する」証拠にしかならない。「実際にブラウザで意図通り描画されているか」は、ビルド後の本番HTML出力を取得して確認するか、ユーザーにスクリーンショットをもらうしかない。
2026-09-30: 新体制（6担当ルール）導入後、初回レビューで見つかった不備
何が起きたか：CLAUDE.md/persona.md/references.mdを整備した直後に「⑤直す担当」視点で公開4記事を見直したところ、ランカウイ島だけ destinations.yml の visa・photo・photo_credit_url が欠けていた（自動生成ルーティンで作られた記事はテンプレートの必須項目チェックが漏れやすい）。また見出し表記が「おすすめスポット」で他記事の「おすすめビーチ・スポット」と揺れていた。
直し方：外務省・マレーシア政府観光局の情報でビザ免除条件（90日以内・MDAC事前登録要）を確認し記載。Wikimedia CommonsでPantai Cenangの実写真（CC BY-SA 4.0、spots.ymlの座標とも一致）を追加。見出し表記を統一。
教訓：新しい記事を自動生成する際は、公開前チェックリスト（CLAUDE.md）の項目を機械的に確認すること。特に visa／photo／photo_credit_url は抜けやすい。見出し文言（「おすすめビーチ・スポット」など）はreferences.mdの表記に必ず合わせる。
2026-09-30: 航空券価格をWebSearchで実勢相場に合わせて更新
何が起きたか：destinations.ymlのflight_min/flight_maxが最初の設定のままで、実際の航空券検索サイトの相場と乖離していた（特にバリ島は直行便の最安値133,390円が、当時のmax設定120,000円を超えていた）。
直し方：4島それぞれについてWebSearchで「成田 ○○ 往復航空券 相場」を検索し、LCC最安値〜フルサービス航空会社の価格帯を確認してflight_min/flight_maxを更新。記事本文の予算セクションの数字（内訳の金額表示・合計金額）も連動して更新した。
教訓：航空券価格はリアルタイムAPIでの自動取得はできない（Skyscanner等は有料API契約が必要、価格は動的JS描画でスクレイピングも困難）。WebSearchで相場を調べて手動更新する運用が現実的。destinations.ymlの金額を更新したら、必ず各記事本文の「予算の目安」内の金額表記（内訳・合計）も同時に直すこと（自動計算されるのはpost.html内のプラン別ティア表示のみで、記事本文の地の文は手動で書かれているため）。
2026-09-30: 6島（リペ・レダン・ピピ・チャン・パリ・フーコック）を追加、ベトナムが対象国に加わった
何が起きたか：ユーザー指定の6島を新規追加。このうちフーコック島（ベトナム）は初めて扱う国だったため _countries/vietnam.md を新規作成し、CLAUDE.mdの対象国スコープにも追記した。
気づいたこと：レダン島は他の島と異なり、モンスーンの影響で毎年11月頃〜3月頃は島全体（ホテル・レストラン・フェリー）が休業する。ランカウイ島など西海岸とはベストシーズンが正反対（レダンは6〜8月、ランカウイは12〜2月）。ベストシーズン表に「✕＝休業」の行を設け、本文でも「11月〜3月は訪問不可」と明記して誤解を防いだ。
教訓：新しい島を追加する際、「ベストシーズンが悪い＝行かない方がいい」ではなく「そもそも物理的にアクセスできない／営業していない」ケースがある（②リサーチ担当の段階で必ず確認する）。新しい国を追加する際は _countries/*.md の新規作成とCLAUDE.mdのスコープ更新をセットで行うこと。
2026-09-30: スポット座標を実測せず概算で入れて位置がずれた
何が起きたか：チャン島のホワイトサンドビーチの座標を、島全体の中心点（destinations.ymlのlat/lng）を流用して入力してしまい、実際のビーチの位置（北西岸）とは離れた場所にピンが立っていた。ユーザーから指摘されて発覚。
直し方：OpenStreetMapのNominatim API（nominatim.openstreetmap.org/search、無料・APIキー不要）でスポット名を検索し、実測に近い座標を取得して修正。あわせてクロンプルー滝・バンバオ漁村の座標も同じ方法で精度を上げた。
教訓：地図ピン用の緯度経度は、島全体の中心点を流用したり記憶やおおよその位置から推測したりせず、必ずNominatim等のジオコーディングAPIで個別に確認すること。特に「観光の目玉になる具体的なビーチ・滝・集落」は、島の中心から離れた場所にあることが多く、概算がそのまま大きなズレになりやすい。
2026-10-01: 現地通貨の円換算は「レートにより変動」と書かずに、定期的に数字そのものを見直す運用に
何が起きたか：パリ島のフェリー運賃（ルピア表記）に円換算を追加した際、「レートにより変動」という注記を添えたが、ユーザーから「為替が変動するのは当然の前提なので注記は不要。その代わり定期的に数字自体を見直してほしい」と指摘された。
直し方：注記を削除し、片道約1,500〜1,800円／往復約3,000〜3,500円という数字のみを残した。
教訓：現地通貨→円の換算額を記事に書くときは「変動する」という言い訳的な注記をつけない（航空券価格と同じ扱い）。その代わり、航空券価格の定期更新運用（本ファイル2026-09-30の項）と同様に、為替レートを使った金額（現地通貨の円換算全般）も定期的にWebSearchで最新レートを確認し、数字を直接アップデートすること。次回の①戦略担当レビュー時や、為替が大きく動いたと感じたタイミングで見直す。
2026-10-02: 一般論（LCC＝ドンムアン空港）を検証せずに断定で書いてしまった
何が起きたか：チャン島記事で「やす旅（LCC利用）はドンムアン空港発着になることが多く、スワンナプーム空港前提のこの陸路ルートとは空港が異なる」と注記したが、これは「LCC=ドンムアン」という一般的なイメージだけで書いた未検証の一般化だった。実際にWebSearchで調べ直すと、日系LCCのZipairは成田⇔スワンナプームを運航しており、既存の陸路ルートの空港とそのまま一致することが判明。注記は不正確だったため訂正し、やす旅も同じ陸路ルートを共有する形に直した。
直し方：WebSearchで「日本 バンコク LCC 直行便」を検索し、Zipair（スワンナプーム）／タイ・エアアジアX（ドンムアン）など就航空港が航空会社ごとに違うことを確認。記事の注記を「LCCは便によって発着空港が異なる（Zipairはスワンナプーム、タイ・エアアジアXはドンムアンなど）」という正確な書き方に修正した。
教訓：「LCCはだいたいこう」「東南アジアの離島はだいたいこう」といった一般論・ステレオタイプを、個別の事実確認なしに断定的な注記として記事に書かないこと。特に「〜空港発着になることが多い」「〜の場合がほとんど」のような一般化した書き方をしそうになったら、それ自体がWebSearchで検証すべきサインと捉える。本当に確認が必要か迷ったら、迷わずWebSearchで1回検索する（コストはほぼゼロ、誤情報を公開するコストの方がはるかに高い）。大きめの新規記事・大幅な旅程変更のあとは、Agentツールで独立したサブエージェントに事実関係だけを再検証させる一手間も有効（前提を引き継がずゼロから調べ直すため、思い込みの連鎖を防げる）。