TRIP×TRIP 運用ルール
TRIP×TRIP 運用ルール
このリポジトリ(themakoto1981/trip-trip)で作業するすべてのセッション(スケジュール実行のクラウドルーティンを含む)が従うルールです。作業を始める前に、このファイルに加えて persona.md(各担当の人格)・references.md(お手本)・learn.md(過去の修正記録)を必ず読み込んでください。
サイト概要
- 島・ビーチ限定の日本語旅行ブログ「TRIP×TRIP」
- Jekyll + GitHub Pages(無料ホスティング)、テーマは minima
- 現在は東南アジア(タイ・フィリピン・インドネシア・マレーシア・ベトナム)に対象を限定
- 将来的にアフィリエイト収益化を想定(誇張・誤情報のない信頼性重視の記事作りが前提)
- アクセス解析はGoogle Analytics 4を導入済み(
_config.ymlのga4_id、実際の埋め込みは_includes/custom-head.html。GitHub Pagesの「トラフィック」タブとは別物で、こちらが実際の読者数を計測する唯一の手段) - Google Search Consoleにも登録・認証済み(所有権確認ファイル: リポジトリルートの
google43038d613ab7b418.html)。サイトマップ(sitemap.xml)も送信済み。新しい記事を大量追加した後などは、Search Consoleの「URL検査」から主要ページのインデックス登録をリクエストすると早くインデックスされる
技術的な制約(必ず守ること)
- ローカルにgit/ghコマンドが使えない環境が多い。その場合は GitHub Contents API(
curl+ Personal Access Token)で直接コミットする。 - PATは classic トークン(repoスコープ) を使うこと。fine-grained PATは権限設定が正しく見えても書き込みが
403 Resource not accessibleで失敗することが繰り返し起きている。詳細はlearn.md参照。 - ファイルを更新する前は必ず最新の
shaを取得してから PUT すること(他セッションとの競合を防ぐ)。 - ビルド確認は GitHub Actions の
actions/runsAPI で行うこと。レガシーな/pages/builds/latestは古い状態を返すことがあり信頼できない。 raw.githubusercontent.comはキャッシュされるため、確認時は?t=$(date +%s)を付けるか Contents API を使うこと。- ソースコード中に特定の文字列がある(grep一致)ことは、実際にブラウザで正しく描画される証拠にはならない。CSSやJSの動作確認は、ビルド完了後に本番URLを取得し、実際に出力されたHTMLの中に目的のクラス名・スタイルが含まれているかを確認すること。
6つの制作担当と引き継ぎフロー
新しい記事(島・ビーチ)を1本作るまでを、以下の6担当のリレーとして扱う。各担当の人格・思考スタイルは persona.md を参照。
- ①戦略担当 → どのジャンルで、誰に向けて、何を発信するかの方針を決める。既存記事との重複や季節性も考慮する。「②リサーチ担当」に対象ジャンル・ターゲット読者・発信方針 を渡す。
- ②リサーチ担当 → 方針に沿って、伸びている投稿や流行り(似たテーマの人気記事・SNSでの反応・検索されているキーワードなど)を調べてくる。行き方・相場・実在スポットなど記事に必須の一次情報(WebSearchでの裏取り)もここで集める。「③企画担当」にリサーチ結果(トレンド傾向+裏取り済みの事実情報) を渡す。未確認の情報は「未確認」と明記する。
- ③企画担当 → リサーチ結果から、投稿のネタと切り口を出す。現実的な日程(後述のルール参照)・予算3段階・スポット一覧など骨子も組み立てる。「④書く担当」にネタ・切り口・見出し構成の骨子 を渡す。
- ④書く担当 → 骨子をもとに、書き出しから本文、締めまで1本の記事(Markdown、front matter付き)に仕上げる。トーンは
persona.mdのブランドボイスに従う。「⑤直す担当」に記事ドラフト(.mdファイル) を渡す。 - ⑤直す担当 → AIっぽい言い回し・誤字・読みにくい箇所を見つけて直す。あわせて事実の整合性(予算の合計計算、予算見出しの泊数と旅程の泊数が一致しているか)、リンク切れ、
spots.ymlとスポット名の対応もチェックする。「⑥分析担当」に公開版と修正点のサマリー を渡す。 - ⑥分析担当 → 公開した投稿の数字を見て、次の投稿に何を反映すべきか考える。アクセス状況はGoogle Analytics 4(https://analytics.google.com/ 、プロパティ「TRIP×TRIP」)で確認する。GitHub Pagesの「トラフィック」タブ(repoのclone数等)は実際の読者数ではないので使わないこと。GA4の「レポート」→「エンゲージメント」→「ページとスクリーン」で記事ごとの閲覧数を、「集客」で流入経路を確認できる。学んだこと(ミス・工夫・ユーザーからの指摘)は
learn.mdに追記する。「①戦略担当」に次サイクルへの示唆 を渡し、ループする。
コンテンツルール
日程の現実性
- 推奨泊数(
recommended_nights)は「現地移動時間を差し引いても、丸2日は実際に楽しめる」ことを最低basisとする。 - 目安:片道の総移動時間(乗継・入国審査込み)が9時間を超える行き先は、最低3泊以上を推奨とする。
- 空港到着後すぐの長距離移動(イミグレ・空港チェックインの時間的余裕、バン/フェリーなどの実際の運行時間帯)は必ず考慮し、非現実的な弾丸日程を書かない。フェリーやバスの時刻は可能な限りWebSearchで実際の運行情報を確認する。
- 「予算の目安」の見出しにある泊数と、「おすすめ旅程」の日数は必ず一致させること。
予算3段階(やす旅/ゆる旅/ラグ旅)
- やす旅:LCC+安宿
- ゆる旅:ANA・JAL+スタンダードルーム
- ラグ旅:ANA・JAL+オーシャンビュー
- 各destinations.ymlの
flight_min/flight_max・hotel_min/hotel_max等から_layouts/post.html内のJSで自動計算される。記事本文にはプラン内訳を書きすぎず、詳細はポップアップに任せる。
購買導線(情報提供→判断→比較→予約)
- 記事は「情報を渡す」だけで終わらせない。読者を 情報提供 → 判断 → 比較 → 予約 の順に導くことを常に意識する。
- 情報提供:行き方・ベストシーズン・予算などの記事本文(既存の構成)
- 判断:早見表(国・ビザ・必要日数・誰と行く?)と予算3段階で「自分に合うか」を判断させる
- 比較:予算プランの下に「条件を変えて他の島と比較する」リンクを設置し、resultsページへ誘導する
- 予約:予算プランの直後に「✈️ 航空券を探す」「🏨 ホテルを探す」「🎫 現地ツアーを探す」の3つのCTAボタンを必ず設置する(
_layouts/post.htmlのbooking-ctaブロックとして自動生成される。新しい島を追加する際はdestinations.ymlにen_name(検索リンク用の英語表記、例: “Phuket, Thailand”)を必ず設定すること)
- 現在CTAのリンク先はアフィリエイトIDなしの通常検索リンク(Google Flights/Booking.com/Klook)。アフィリエイト契約が決まったら、この3つのURLにアフィリエイトIDを追加するだけで済む構造にしてある。リンク先サービス自体を変える場合はCLAUDE.mdのこの節も更新すること。
写真
- 実写・ライセンス確認済みの写真のみ使用(Wikimedia Commons
commons.wikimedia.org/w/api.phpで検索し、直リンクのupload.wikimedia.orgURLとライセンス・出典ページURLを確認する)。AI生成画像は使わない。
スポット地図
_data/spots.ymlに記事のslugをキーとして{name, lat, lng, desc}の配列を追加する。- 地図ピンのポップアップには Googleマップで開くリンク(
https://www.google.com/maps/search/?api=1&query=LAT,LNG)を必ず含める(無料でユーザー自身のGoogleマップアプリ/サイトに誘導するため。Google Maps JavaScript APIのような有料の埋め込みは使わない)。
ファイル構成(記事1本追加する際に触るもの)
_posts/YYYY-MM-DD-slug.md— 記事本体_data/destinations.yml— 検索・地図・予算計算用のマスターデータ(1件追加)_data/spots.yml— 記事内スポット地図用の座標データ(1件追加)_includes/custom-head.html— サイト共通CSS(_includes/head.htmlから明示的にincludeされている。テーマ本体のhead.htmlには含まれないので注意)
公開前チェックリスト
destinations.ymlに必要フィールドが揃っているか(visa・photo・photo_credit_url・en_name含む)- 予算見出しの泊数と旅程の泊数が一致しているか
recommended_nightsが「日程の現実性」ルールに沿っているかspots.ymlにこの記事のエントリがあるか(地図が表示されない原因の大半はここの欠落)- 写真のライセンス・出典URLを確認したか
- ビルド成功を GitHub Actions で確認し、本番URLで実際にCSS/JSが効いているか確認したか