直したサイトと、直してほしかったサイト

www.eurekapu.com の記事OG画像が403で表示されない問題を Claude Code に修理させた。 前セッションで403は実測済みだったので、再調査はさせず、署名まわりの確認から入らせた。 修理は通った。 「一旦これで修復全部完了ってことですよね」と言った直後に、あれ、と思った。 直してほしかったのは eurekapu-nuxt4（info-accounting.com）のOGP、記事を共有したときの表示のほうではなかったか。 聞くと、前セッションからの引き継ぎ指示が www.eurekapu.com の修理で、直っていたのはそちらだった。 www の403も実害だから修理は無駄ではない。 ただ、本命は手つかずのままだった。

www.eurekapu.com のOG画像403の修理

Worker側（mdx-playground）とサイト側（wordpress-migration）の署名ロジックを読み比べさせ、対照実験として log.eurekapu.com のOG URLが通るかも確かめさせた。 シークレット自体は設定されている。 それでも403が出る。 デプロイ履歴を調べさせると、最終デプロイは2026-08-02、macOS移行日と重なっていた。 7月27日の稼働確認のあとに何かが変わった可能性が高い、という推定になった。

復元は、値を画面に出さないやり方でやらせた。 抽出スクリプトからパイプで wrangler に直接流す。 問題のURLは 200 + image/png を返すようになり、画像にはロゴ、記事タイトル、著者名がそろって描画されていた。 他の記事2本と log 側も通って、修理は完了した。

本命だった eurekapu-nuxt4 のOGP設定

eurekapu-nuxt4 側はそもそも未設定で、修理ではなく配線からやることになった。 runtimeConfig に ogSecret を足し、署名ユーティリティとコンポーザブルを作らせ、app.vue にサイト共通のデフォルトを置く。 ホストごとの扱いは分けた。 takken は R2 上に記事別の静的OG画像が実在したので、維持して key 化と twitter:card の追加だけにした。 cashflow はツール固定タイトル、fs-textbook は章タイトルで動的生成。 トップページは title が未設定だったので、ブランド共通の「動く図解で学ぶ会計・簿記」の文言でデフォルト画像を Worker に生成させた。

本番反映は、Worker の再デプロイ、Pages のシークレット設定、サイトのデプロイと対外操作が3つ続くので、実行前に確認を取らせて進めた。 Worker の再デプロイで info-accounting.com のルートが有効になり、www と log に影響が出ていないことも点検させた。

デプロイ後の検証で、/lessons/* が軒並み403を返した。 最初は有料コンテンツのアクセス制御かと疑ったが、無料ページも403。 追いかけると、108ページが共通のコンポーザブル（useContentMeta）を使っていて、そこを直せば一括で整合すると分かった。 zeimu ホストは中央修正で足り、独自実装だった bookkeeping ホストだけ個別に直した。 直したのは合計3ファイル。 再デプロイして、本番の動的OG画像そのものを取得し、描画まで確認した。

Mac側がクローンしたときに気づける導線

セッションを閉じる前に積み残しを聞くと、2リポジトリの変更が未コミットだと返ってきた。 学習ゲートはスキップを指示し、理由付きの LEARN_SKIP=1 でコミットさせた。 もうひとつ頼んだのは、Mac側の Claude Code がクローンしたときにチェックできる仕組みだ。 git追跡される導線として .claude/issues/ とプロジェクト CLAUDE.md に記録させ、eurekapu-nuxt4 の CLAUDE.md にはOG画像の恒久ドキュメントを足してもらった。 コミット前には2台運用のルールどおり、origin との差分も確認させている。

push したら Dependabot 警告25件が届いた

push 時に GitHub から、eurekapu-nuxt4 の依存パッケージに Dependabot 警告25件（critical 1件、high 16件）が出ているという通知が来た。 今回の変更とは無関係の既存アラートだが、出ているものは気になる。 棚卸しを指示した。

critical の cryptography は、講座教材のスナップショット内の lockfile にあり、サイト本体では未使用だった。 本体の pnpm 依存を更新すると nuxt が 4.5.2 に上がり、ここから玉突きが始まる。

まずテストが13件落ちた。 更新前の状態では38件すべて合格したから、原因は依存更新だと確定した。 nuxt 4.5 で $fetch の解決方法が変わったらしく、vi.stubGlobal('$fetch') で立てていたスタブが死んでいた。 mockNuxtImport に置き換えて解決し、同じ死んだスタブを持つテストにも横展開させた。

次はビルドが JSON パースエラーで落ちた。 rolldown のエラーはモジュール名を出さないので、@nuxtjs/i18n と vite 8 の既知の非互換を GitHub issue で当たらせた。 修正は上流の unplugin-vue-i18n に入っていたが、@nuxtjs/i18n 9.x の依存レンジでは届かない。 10.x に上げ、v10 で削除されたオプションを使っている箇所がないことも調べさせた。

ビルドは2.3分で通った。 vite 8 と rolldown への移行で、従来の6.5分から縮んだ、はずだった。 ところが Worker バンドルの計測CSVに今回の行がない。 dist/_worker.js の中身が空で、ビルドは実際には失敗していた。 失敗が deploy.ps1 の判定をすり抜けて、built と表示されていた。 raw ログからエラー本文を掘らせると、app 側から相対パスで shared/ を import している箇所が原因だった。 直して再ビルドするとクリーンに通った。 deploy.ps1 の誤報告は issue に残させた。

表示確認では、途中で pnpm dev | head -40 の既知の罠（head がパイプを閉じてサーバーごと落とす）を踏んだが、1回目のサーバーは生きていた。 ホームの左上が空白に見えたのはフォントの読込タイミングで、見出しは DOM に存在していた。 /en の404も既存仕様だった。 SVG は行数ではなく出現数で数え直させ、図の SSR も更新前の本番ビルドと比較した。

並行セッションと譲り合いながら28件を閉じる

修正した12ファイルをコミットして push し、本番デプロイまで通した。 push で25件中22件が閉じ、lockfile の再スキャンで、元の25件に無かった3件（sharp / esbuild ×2）が新たに表面化した。 3件とも dev ツール経由の推移的依存で、レンジ外のパッチだったので overrides で対応する。

検証中に、デフォルトOG画像が404を返しているのを見つけた。 R2 への302までは設計どおりだったが、リダイレクト先に実体が無かった。 これは並行セッションの作業途中分がデプロイに乗ったものだった。 OGまわりは向こうで進行中なので、手を出さずに待った。 掴んでいるエラーの内容は別セッションに渡したかったので、そのまま貼れる引き継ぎプロンプトを出させた。 overrides の変更は検証済みのままローカルに置き、コミットは保留。

別セッションが終わったのを見て再開した。 差分が overrides の3行だけであることを確かめてから、コミットして push した。 GitHub の未解決アラートは0件になった。 当初の25件と再スキャンで出た3件、計28件を解消した。 最後に、28件の内訳と overrides を外すときの注意をまとめたメモを memo/2026-08-16/dependabot-25-alerts-fix.md に残させた。

学び

• 「シークレットが設定されている」ことと「値が合っている」ことは別。デプロイ履歴の日付（macOS移行日）との突き合わせが原因推定の足がかりになった
• 依存更新でテストが落ちたら、まず更新前の状態で全緑を確かめる。ベースラインが取れれば原因は一発で確定する
• built の表示を信じない。成果物（dist/_worker.js）の実体まで見る
• 同じリポジトリを触る並行セッションがいるときは、待って、引き継いで、自分の差分だけをコミットする