telosh.log を実際に組み立てるとき、横断で押さえたい論点

この記事は、すでに書いた 設計メモ（URL やテーマ、全体像）と 有料 MDX まわりのセキュリティ整理を前提に、**「プログラムとして構築するときに、どのレイヤで何を考えればよいか」**だけを一覧化したものです。手順書ではなく、頭の中の棚卸し用の目次だと思ってください。

起 — なぜ「横断」で整理するのか

ブログひとつでも、触るファイルは content/・app/・lib/・環境変数・外部サービスに散らばります。機能を足すたびに「その場しのぎで直したつもりが、別の境界で矛盾が出た」ことが起きやすいです。

そこで次のように 関心ごとに層を分けて、各層で「最低限ここは決める／後回しにする」と言語化しておくと、後からの自分と運用が楽になります。

図を描いています…

以下では承で層ごとの論点を並べ、転で優先順位と「意図的にやらないこと」、結で一行ずつ振り返ります。

承 — レイヤごとに考えること

1. コンテンツと URL（情報の置き場）

スラッグとファイル名を一致させ、パストラバーサルなど 意図しないファイル読み出しを防ぐ前提をコードに書く（getPostBySlug まわり）。
一覧・検索に渡すデータは、有料記事の 本文をクライアントに載せない形に薄くする（PostListItem の分離など）。画面に出していなくても、バンドルや RSC の props に乗れば読める、という視点。
並び・ページング・フィルタをクエリに載せ、ブックマークと共有で状態が復元できるようにするかどうか。telosh.log では URL を信頼できる情報源に寄せています。
下書きと本番で、同じ Price ID が誤って本番 Checkout に繋がらないようにする（カタログ・環境の切り分け）。

2. RSC・クライアント境界と MDX

use client へ渡す propsが、機密や未購入本文になっていないか。Server で組んだつもりでも、境界を跨ぐとクライアントに届く、というルールを毎回確認する。
MDX のパイプライン（シリアライズ・ハイライト・許可コンポーネント）をサーバーに寄せ、表示直前まで本文を握る設計にするかどうか。
サードパーティに MDX を書かせる予定があるなら、コンポーネントのホワイトリストだけでは足りない、という別問題になる、と割り切る。

3. 認証・課金・「正」の置き場所

ログイン状態（Clerk）と 購入状態（Stripe・署名クッキー）をどこで結合するか。成功 URL の session_id は共有されうるので、**レシート表示は「その Clerk ユーザーだけ」**に限定する、といった筋の通し方。
Checkout に載せる Priceを、記事メタから解決できる集合に ホワイトリストする。誤結線や任意 priceId への課金を防ぐ。
Stripe を正とするか、クッキーを正とするかのバランス。障害時のフォールバック、返金後に payment_status が残るケース、キャッシュの遅れ（最大どれくらい許容するか）まで含めて決める。
購入クッキーと Clerk ID のペアを崩さない。古い形式のトークンをどう扱うか、復旧経路をどこに置くか。

4. データ取得・キャッシュ・一貫性

同一リクエスト内で外部 API を何度も叩かないようにする（cache など）。一覧や複数 Price 判定で効いてきます。
段階的な再検証（unstable_cache や revalidate）を入れたとき、**ユーザー体験として「遅れて反映される」**ことを説明できるか。
Webhook を使うか、ポーリング相当の同期に留めるか。DB に購入履歴を積まない場合のサポート・監査のしにくさを受け入れるか。

5. セキュリティとコンプライアンスの線引き

レート制限をアプリ単体でやるか、エッジや WAF に任せるか。
CSPをどこまで厳しくするか。Clerk や決済ウィジェットと両立させる段階的な足し方。
秘密情報（Stripe シークレット、署名用シークレット）をクライアントに漏らさない、Preview／Production の環境変数の運用。

6. 運用・デプロイ・観測

本番 URL・Webhook エンドポイント・Stripe モード（テスト／ライブ）の切り替えで起きがちなミスを、チェックリストやスキルに残す。
エラー時のログ（購入同期失敗など）をどこまで出すか。個人情報・決済 ID のマスキング。
ビルドが通っても、実行時に環境変数が欠けるパターンをどう検知するか。

7. 体験品質（見た目・性能・アクセシビリティ）

テーマを Cookie と SSR で揃え、フルリロードでも破綻しないようにする（DocumentLink 前提の話とセット）。
動き（prefers-reduced-motion、ホバー過多）をコンテンツの邪魔にしない程度に抑える。
図表・コードブロック・フォントが、ライト／ダークの両方で読めるか。Mermaid など SVG 内のラベルはグローバル CSS まで視野に入れる。

転 — 優先順位と「満点にしない」勇気

すべてを最初から完璧にする必要はありません。telosh.log でも、アプリ内の論点は潰し、インフラや契約はスコープ外と明記するという割り切りをしています。

次のような順序で手を入れると、個人ブログでも迷いが減りやすいです。

秘密がクライアントに落ちないか（一覧・境界・成功 URL）
課金の許可リストとユーザー紐づけ（誤課金・なりすまし表示の防止）
Stripe とクッキーの整合（返金・障害・キャッシュのポリシー）
URL とキャッシュの分かりやすさ（デバッグと SEO・共有）
運用と監視（ログ、環境、デプロイ手順）

ここまでできていれば、あとは コメント機能や全文検索のような「伸びしろ」に集中しやすくなります（最初の宣言記事にあった未来像は、その延長線上に置ける、という位置づけです）。

結 — 一行ずつの振り返り

コンテンツ：薄い一覧用データと、太い本文の境界をコードで表現する。
URL：状態をクエリに載せるかどうかは、共有とクローラのしやすさとのトレードオフ。
RSC：use client は「データがブラウザに行く」サインとして毎回疑う。
課金：Checkout の入口・成功ページ・平常時の閲覧判定を 同じルールで貫く。
Stripe：返金や API 障害を想定し、キャッシュの遅れを許容範囲として決める。
運用：環境とモードを間違えない仕組みの方が、機能追加より先に効くことがある。
体験：テーマ・動き・図は、文章の可読性を壊さない範囲に収める。

詳細な経緯や実装の寄り道は、**「telosh.log を組み立てるときに決めたこと」と「有料 MDX を Next.js で配るとき、最初に落ちる穴とその後の整理」**に分散して書いてあります。この記事はそれらの 目次兼チェックリストとして使ってもらえると意図どおりです。

同じような構成を検討している方の、比較表のひと列になればうれしいです。