⚙️ Vault運用
2026-06-17_作業ログ
最終更新 2026年06月23日 / 90_Meta/Claude作業ログ/2026-06-17_作業ログ.md
作業ログ 2026-06-17
13:47 - SCALE CRM v11.5.82 根本解決: スライディングセッション(本番LIVE・実測検証済)
メンバーFB(大串経由)
「CRMの架電リストが重いのか開けない状態です。先日からも少し重くなっていたりした」+ 失敗UIスクショ(架電リストの読み込みに失敗しました)
→ 「復旧して」「急ぎじゃなくていいから根本」(3回強調)
調査(推測でなく経路を実測)
- 大串(admin)は全API 200・基準点v81のまま(別セッション変更なし)→ 全体障害でなく特定メンバー個別
- 本番で人工署名トークン(AUTH_SECRETでHMAC自作)3経路を実測:
| 経路 | 結果 |
|---|---|
| [A] 名簿実在の有効メンバーcookie | calls 200(名簿照合バグ無し) |
| [B] 期限切れcookie | 401 DATA_AUTH_DENIED ← メンバーの失敗の正体 |
| [C] 名簿不在cookie | 401 MEMBER_REVOKED(正しい遮断) |
真因
セッションcookieが「発行から固定TTLで絶対失効」する設計。毎日使っても発行日からの経過で必ず切れる。v81以前発行の短命cookie(14〜30日)が6月中旬に順次失効(6/12は14日cookieが生きてて見れ、6/17に失効=FBと完全一致)。v81でTTLを180日に延ばしても「既存の短命cookieを持つ人」は順次失効し続けるため、延長だけでは止まらなかった。
根本解決=スライディングセッション
slideSession(_middleware.ts)+ me.ts: 有効セッション+名簿実在のデータAPIアクセス時、残り寿命 < TTL/2(90日) なら新180日cookieを自動再発行(既存 withGraceCookie と同型の Response 再構築 + Set-Cookie append)- → アクティブメンバーは使い続ける限り永久に切れない / 退職者は名簿照合(v81)で即遮断 / 90日放置の離脱者だけ自然失効
- 再発行は残90日を切った後の最初の1アクセスのみ(再発行でexp+180日されまた90日発行ゼロ)→ 8秒pollでも毎回発行にならず軽量。失敗は握り潰し
本番実測検証
| テスト | 結果 |
|---|---|
| 残10日トークン → /api/calls | Set-Cookie で残180日に更新 YES |
| 残170日トークン → /api/calls | 再発行 no(閾値ロジック正常・無駄打ちしない) |
| 残10日トークン → /api/v2/auth/me | 残180日に更新 YES |
現メンバーの即時復旧
既に切れたcookieはサーバから延命不可(クライアント保持・署名済み)→ 一度だけ再ログインが必要(失敗UIの「再ログイン(画面更新)」ボタン→名前+PW)。以後はスライディングで二度と期限切れUIを見ない。
退化リスク
- slideSession は validSession 成功時のみ呼ぶ → MEMBER_REVOKED / 期限切れ経路は無変更(退化なし)
- members 一斉消失系事故(D5/v9.221対策済み)が起きると全員401になりうる → members 縮小防御が引き続き生命線
- backup: scale-lead-2026-06-17-1347-post-deploy.tar.gz
学び
- 固定TTLのセッションは「いつか必ず全員が踏む時限爆弾」。「TTLを延ばす」は対症療法、「アクセスのたびに延びる(スライディング)」が根治
- 「重い/開けない」系FBは推測で対策せず、人工トークンで認証経路を実測すると一発で正体が割れる([A][B][C])
- スライディング + 失効時の名簿/DB照合 をセットにするのがステートレス認証の定石
14:51 - /handoff 実行
対象システム
TERASUコラム制作フロー(/column-flow コマンド強化)+ デザイン型の組み込み。※本番デプロイ無し(コマンド編集+Vault記録セッション)
セッション背景
前セッションで「TERASUコラム記事の完成テンプレート(型)」を確定(1本目=ホームページ制作の費用相場は?)。今セッションは大串FB「毎回今回のようなデザインの型でデザイン面で修正いらないようにしたい/そうなるようにコマンド修正してね」を受け、型を /column-flow コマンドに焼き込む作業。
完了タスク(詳細)
~/.claude/commands/column-flow.mdに 内蔵ルールC「デザイン型(完成テンプレート・厳守・毎回機械適用)」 を新設。型本体(~/dev/_terasu-column-template/)+全デザイン仕様(本物チロム/モノクロ/YakuHanJP+palt/StockSun式目次/右下追従CTA/フッター無し)+「適用はStep6でbuild_column.pyを回すだけ=デザイン修正は発生しない」を明文化。- 古いデザイン前提(黒背景・暖色ゴールド・Cormorant Garamond・末尾CTA)を全撤去(
grepで残ゼロ確認済み)。 - Step 6(公開フロー)を「手作業HTML作成」→「build_column.py で型を機械適用」に書換。必要アセット同梱・困ったら見本と見比べる、まで記載。
- Step 2 CTA を型の「右下追従ボタン(無料で相談する)」に統一。本文中オレンジCTA帯/サイドCTAは型が自動削除=置かない、と明記。
- description / 設計思想 にデザイン型内蔵を明記。内蔵ルール見出しを「2大→3大ルール」に更新。
~/Obsidian/SCALE-Brain/22_AI運用ルール/コマンド集/column-flow/learning.mdを新規作成し、今回FBを恒久ルールAとして記録。
編集ファイル
~/.claude/commands/column-flow.md- 内蔵ルールC追加・Step6/Step2書換・古いデザイン前提撤去・見出し更新~/Obsidian/SCALE-Brain/22_AI運用ルール/コマンド集/column-flow/learning.md- 新規作成+FB記録
デプロイ・バックアップ
なし(本番デプロイ禁止セッション。大串明示「本番公開はまだまだ先だから、やらないでね」)。
試したこと・学び
- 型を「文章で説明」ではなく「build_column.py で機械適用」に寄せることで、毎回のデザイン判断・手戻りをゼロにできる構造にした。
- コマンドのデザイン前提が古いまま(黒背景/ゴールド/Cormorant)だと、完成した型(モノクロ/palt)と食い違い毎回修正が必要になっていた → 撤去で根治。
ユーザーFB(重要)
- 「毎回今回のようなデザインの型でデザイン面で修正いらないようにしたい。コマンド修正して」→ 対応済(内蔵ルールC+Step6機械適用)。
- 「本番公開はまだまだ先だから、やらないでね」→ 本番デプロイ禁止(継続・最重要)。型・記事はローカルプレビューのみ。
- 「コラムのコマンドはこのHPのセッションの方が事故らないか?」→ Yes(文脈が生きている+1システム1セッション原則)と回答。最初の実戦1〜2本はこのセッション系統で回すのが安全。
注意ポイント・退化リスク
- TERASU公式HP 本番デプロイ禁止(大串明示)。公開はまだ先。型・記事はローカル(8780プレビュー)のみ。
- 型を変えるなら
~/dev/_terasu-column-template/(build_column.py + assets + README)と コマンドの内蔵ルールC を更新(全記事に伝播する一次ソース)。 - フッターはローカルでは付けない。本物cm-fは単体ページで描画不可(単体だと1983px/CONTACT200px/MV921pxに化ける)。本番terasu-hp組込時にテーマ標準フッターが自動付与。
- プレビュー: 8780=ホスト常駐(ユーザー閲覧可)/8781=Claude_Preview MCP(自分の検証専用・ユーザーブラウザからは開けない)。参照 feedback_preview_server_nohup。
次のセッションで取り得る選択肢
- 2本目のコラムを
/column-flowで実際に作り、型が自動適用されデザイン修正ゼロで出るか実戦テスト。 - column-flow のコンテンツ面(構成テンプレ/文字数=StockSun基準/SEO/内部リンク)をさらに強化。
- 型の本番組込手順(terasu-hp/column/
/ へのアセット同梱+フッター自動付与)を build_column.py 側で半自動化。
引き継ぎファイル
/tmp/handoff_20260617_145145.txt