Who：誰の立場で書くか
このサイトは、Cocoaというカップル向けアプリの開発・運営側が、現在の実装を確認しながら提供するガイドです。Cocoaにある機能だけを「正解」とせず、目的によっては他の種類のアプリ、何も使わない方法、人に相談する方法の方が向くことも明記します。
恋愛や関係性について、医療・心理療法・法律の専門家として診断や個別助言を行うサイトではありません。
How：どのように情報を確認するか
1. Cocoaの機能はProduct Fact SSOTへ戻る
記事を書く前に、Cocoaのアプリ側repositoryを確認し、機能を verified / partial / unverified / not_implemented / future_only に分けます。SEO側では `app-facts.md` を一次SSOTとし、記事ごとのclaim資料はそこから使える表現を派生させます。
たとえば現在の確認では、記念日の登録・日数計算、記念日前のプログラム、思い出ログ、成長プラン等はコードで確認できました。一方、二人のリアルタイム同期、思い出ログの写真添付、記念日のプッシュ通知、現在の料金や公開ストアURLは確認済みの機能・公開事実として扱っていません。
2. 検索意図は現在のSERPを見る
「需要がありそう」という内部推測だけで記事を作らず、現在の検索結果で、アプリ選択、比較、How-to、意思決定など、どの種類のページが必要とされているかを確認します。ただし、検索結果にページがあることを検索ボリュームの証明とは扱いません。
3. 変わる情報には確認日を持たせる
他社アプリの機能、Google Searchの仕様、料金、公開状況などは変わります。必要な記事では公式ページやストアページなどを確認し、記事本文・参考情報に確認時点が分かる形を残します。
4. AIは草稿・整理に使えても、根拠にはしない
文章整理や候補出しにAIを利用する場合でも、AIの出力自体を製品事実や外部事実の根拠にはしません。製品claimはコード、変わり得る外部claimは適切な外部情報へ戻って確認します。
Why：なぜこの内容を作るか
カップル向けの検索結果には、アイデアを大量に並べる記事、アプリの機能を多数紹介するページ、商品を並べるページが多くあります。それらが役立つ場面はありますが、「自分の場合は何を選べばいいか」が残ることもあります。
Cocoaガイドでは、予算・時間・共有の必要性・相手の好み・残したい情報・振り返りたい内容のような条件から候補を減らすことを重視します。既存SERPの要約だけで終わらせないためです。
強いclaimを避ける
次のような表現は、十分な根拠がない限り使用しません。
- 「必ず喜ぶ」「絶対にうまくいく」
- 「利用するだけで関係改善や長続きを保証する」と受け取れる表現
- 「相性がわかる」「心理状態を診断できる」
- 「完全に安全」「データは一切外部に出ない」
- 未確認の「無料」「○円から」「今すぐダウンロード」
記事を増やす基準
記事数はKPIにしません。候補は create / merge / defer / reject のいずれかに判断します。同じ検索意図の言い換え、性別や期間だけを差し替えるページ、地域名だけを差し替えるページは、独立したユーザー価値を確認できない限り増やしません。
更新・修正の考え方
- Cocoaの機能変更：Product Fact SSOTを再確認し、影響する記事claimを点検する。
- 検索結果の変化：owner intent自体がずれていないかを見る。
- Search Consoleで想定外queryが増えた：まず既存ownerへ追記できるか判断する。
- 複数ページが同じquery群に出る：新記事ではなくカニバリ監査を先に行う。
- 誤りを見つけた：事実を修正し、意味のある変更があった時だけ更新日を変える。
公開前と公開後を分ける
このrepositoryでSOURCE_READYになっても、そのままLIVE確認済みとは扱いません。Cocoaは公開hostをRelease Phaseで確定する `release_render_required` 構成です。公開直前に実hostと実公開日を入れた隔離release artifactを生成・再QAし、明示的な許可がある場合だけdeployします。
公開後はHTTP response、最終URL、canonical、robots、sitemap、rendered HTML、主要リソースを実hostで確認し、その後Search Consoleデータを蓄積して keep / rewrite / merge / remove / new-page を判断します。