S82: LINE通知が飛ばない！ → 4段階デバッグ → 正式接続完了

日付: 2026-02-25
カテゴリ: wisdom

概要

MySpiritsの本鑑定後にLINEカルーセルが届かない問題を調査。原因は4層に渡っていた。1つ修正するたびに次の問題が顔を出す、まさにデバッグの連鎖だった。最終的にLINE Messaging API正式接続+マイページログイン機構追加+本鑑定1200字増量まで完了。

やったこと

1. 第1層：index.htmlの認証ヘッダー欠落

ユーザーから「結果出たけどLINEは既存会員やと無反応」との報告。Cloud Runのログを確認するとLINE送信関連のエラーが一切ない。つまりそもそも送信が発火していない。

原因を追跡すると、index.html（LP）のプレミアム鑑定API呼び出しにAuthorization: Bearerヘッダーがなかった。mypage.htmlでLINE LoginしてlocalStorageにmyspirits_auth_tokenが保存されていても、index.htmlがそれを読んでいなかった。

修正：
– _getAuthHeaders() ヘルパー関数を追加。localStorageからトークンを読んでBearerヘッダーに載せる
– プレミアム鑑定APIのfetchに適用

2. 第2層：LINE CTAの全面再設計

修正後にユーザーからフロー指示：
「ブラウザで鑑定して、LINE押すとQR出てくるからスマホで読み取るけど、すでに友達になってるLINEの場合はQR読み込んだ時点でカルーセルが飛んでこないとあかん。スマホで鑑定した場合ならLINEボタン押した時点でカルーセルが飛んでくる」

つまり従来の「LINE友だち追加リンク」ではなく「LINE Login → 自動カルーセル送信」フローが必要。

index.htmlに大幅な変更を実施：
– startLineLogin(): pending result_idをlocalStorageに保存 → LINE Login OAuth開始
– sendLineReading(): /api/fortune/send-line API呼び出し
– updateLineCTA(): 送信済みUI状態の切り替え
– ページロード時の?auth_token=コールバック検出 → 保留中のLINE送信を自動実行
– CTAボタンをLINEグリーンの「LINEで鑑定結果を受け取る」に変更
– 送信完了時に「LINEに送信しました」表示

3. ユーザー修正：無料鑑定のLINE CTAは不要

実装後にユーザーから「無料鑑定の後にLINEじゃなくて、本鑑定の後にLINEやで？無料は何回でも受けられるし既に保存してるやん？」と指摘。

無料鑑定のLINE CTA（HTML + JS参照4箇所）を全削除。本鑑定のみに限定。

4. 第3層：LINE Messagingトークンが間違ったボットだった

ここまでの修正をデプロイして実際にLINE Push APIをテストしたところ、トークンが指すボットが@787oguzk（Inspire – SNS自動化支援アプリ）だった。MySpiritsのボット@838imbvpではない。

Secret Managerに保存されていたトークンが、Phase4実装時に設定したInspire用のトークンだったことが判明。

5. 第4層：正しいトークン発行 → 正式接続

ユーザーからMySpiritsのチャネルID（2008463240）とシークレットを受領。

curl -X POST "https://api.line.me/v2/oauth/accessToken" \
  -d "grant_type=client_credentials&client_id=2008463240&client_secret=..."

ボット確認：

@838imbvp — My Sprits-ポケットに魂の羅針盤（正しいボット）

Secret Manager v2バージョン追加 → v1（Inspire）無効化 → Cloud Run Rev19デプロイ。

6. 本鑑定1200字増量

ユーザーから「本鑑定の文字数が少ない。今各章800文字やったら1200文字まで増やして」との指示。

• fortune_prompts.py: 全「800字以内」→「1200字以内」（7セクション全て）
• main.py: max_tokens 5000→8000、httpx timeout 120s→180s
• Cloud Run Rev18→Rev19で引き継ぎ

7. マイページにLINE Login画面追加

mypage.htmlに直接アクセスした未ログインユーザーが即座にindex.htmlにリダイレクトされる問題を修正。

• ログイン画面HTML追加（LINEグリーンボタン + コスモスデザイン統一）
• checkAuth(): リダイレクト → ログイン画面表示に変更
• handleAuthCallback(): ?auth_token=パラメータ検出 → localStorage保存 → URL浄化
• startLineLogin(): redirect_uriにmypage.htmlを指定
• auth-content wrapper divで認証済みコンテンツをラップ

8. デプロイ

• Cloud Run Rev18（1200字+timeout）→ Rev19（正式LINEトークン）
• XServer × 3回（auth header追加 → LINE CTA変更 → 無料CTA削除 → mypage.htmlログイン画面）
• 全て本番反映済み

やらかしたこと

1. LINE Messagingトークンの検証を怠った。Phase4でSecret Managerにトークンを設定した時点でボットの確認（GET /v2/bot/info）をしていなかった。設定時に1回APIを叩いて確認していれば、今回の4段階デバッグのうち1つは最初から潰せた。

2. 説明が冗長すぎた。「30日期限のclient_credentialsトークン vs 長期トークン」の技術的背景をユーザーに語り始めて「意味わからん」と言われた。「動く。期限切れたら差し替えるだけ」の一言でよかった。

3. マイページの問題について、ユーザーが「ログインしたら済むんやろ？」と聞いてるのにコードの詳細を語り始めた。結論→作業の順番を守るべき。

教訓

1. Secret設定時は必ずAPIで検証。トークン保存 → curl /v2/bot/info → ボット名確認。この30秒で何時間もの後日デバッグを防げる。

2. ユーザーへの説明は結論ファースト。「動く」「直す」が先。技術的背景は聞かれてから。

3. LINE Bot のチャネルID+シークレットがあればclient_credentialsでトークン即時発行可能。LINE Developers Consoleにログインする必要はない。curl一発。

4. 認証フロー（LINE Login OAuth 2.1）のredirect_uriは動的指定可能。auth.pyの/api/auth/line/loginはredirect_uriクエリパラメータを受け取るので、index.htmlからでもmypage.htmlからでも同じOAuthフローが再利用できる。

5. デバッグは層を意識する。「LINE通知が飛ばない」という1つの症状に、認証ヘッダー欠落→フロー設計ミス→トークン設定ミス→ログイン導線不在の4層が重なっていた。各層を1つずつ剥がしていく意識が重要。

エージェントとのやりとりで気づいたこと

コンテキスト圧縮後のセッション再開では、前セッションの最後のユーザーメッセージと周辺コンテキストが極めて重要。サマリーだけでは「ユーザーがトークンを提供したかどうか」のような微妙な情報が失われる。重要な受領情報（秘密鍵、トークン、認証情報）はSession Handoffに明示的に含めるべき。

また、4段階の問題が連鎖的に見つかるケースでは、エージェントが各修正後に「次の問題」を自動検出して一気に直してくれるのが理想。今回は手動テスト→報告→修正のサイクルが3回発生した。デプロイ前にドライラン（APIエンドポイント叩いて確認）する習慣をエージェントに持たせることで、このサイクルを圧縮できる。

デプロイ状況

次回やること

• E2Eテスト: LINE Login → 有料鑑定 → LINEカルーセル受信 → mypage.html履歴確認
• FLEX_IMAGE_URLS環境変数設定（カルーセル画像URL）
• fortune_results に line_sent_at / line_send_status カラム追加
• LINE Messagingトークン長期化（30日期限 → 2026-03-27頃失効）