# Monaka — 開発者向けメモ **最終更新: 2026-08-03** ## ⚠️ 作業ルール（最優先） **修正を実施する前に、修正内容に間違いが無いかユーザーに確認をする。** **UTAGE取り込み関連の作業を行う前に [`docs/Convert_utage_to_monaka.md`](docs/Convert_utage_to_monaka.md) を必ず全て読むこと。** **🚨 UTAGE取り込み修正は「全UTAGEページに汎用対応」で作ること。特定URLや特定ページだけに効く実装は絶対禁止。詳細は [`docs/Convert_utage_to_monaka.md`](docs/Convert_utage_to_monaka.md) の冒頭を参照。** ## ドキュメント - **引き継ぎ（作業サイクル・検査の現在地・すぐ再開する手順・落とし穴・宿題）: [`docs/HANDOFF-audit-20260804.md`](docs/HANDOFF-audit-20260804.md)** —— 新しく入る人はまずこれ - **修正の判断基準（何を直し、何を直さないか）: [`docs/degradation-policy.md`](docs/degradation-policy.md)** - 索引: ルート [`SPEC.md`](SPEC.md)、詳細なファイル説明 [`docs/README.md`](docs/README.md) - ファネル・管理機能の技術仕様: [`docs/funnel-spec.md`](docs/funnel-spec.md) - 運用手順: [`docs/manual.md`](docs/manual.md) ## 環境 - Laravel。環境変数の名前は [`.env.example`](.env.example) を参照。**値はリポジトリに書かない。** - DB 型・カラムは推測せずマイグレーションおよび Eloquent モデルで確認する。 ## Recent Implementation Log 日付は作業日（追記は新しいほど上）。 ### 2026-08-12 - **マージ後監査（PR#81）: 公開側の送信経路を棚卸しし、受講者ログインに総当たりの上限が無かったのを修正**: 引き継ぎ資料が次に挙げていた**公開側の送信経路**に移った。**認証の要らない送信（POST/PUT/PATCH/DELETE）を全部並べて上限の有無を見る**形にしたところ、**最初の走査は291本**出て、`contract/*` など明らかに認証必須のものが「公開」に混ざっていた —— **私の走査のバグ**で、`route:list --json` の middleware は**別名ではなくクラス名**で返る（`auth` → `App\Http\Middleware\Authenticate`、`throttle:20,1` → `Illuminate\Routing\Middleware\ThrottleRequests:20,1`）。2026-08-02 に `gatherMiddleware()` で**逆方向**（別名で返るのにクラス名で照合）を踏んでおり、同じ場所で2度転んだ形。直すと **17本**、うち上限が無いのは3本だった。**LINE webhook 2本は対象外と判断** —— `X-Line-Signature` を検証してから動くので勝手に走らせられず、上限を付けると提供元の再送を落とす。**残る1本が不具合** —— **受講者ログイン（`member/{slug}/login`）だけ総当たりの上限が無かった**。管理画面は `hasTooManyLoginAttempts`、パートナーは `throttle:10,1` で止めているのに受講者は何も無く、**誤ったパスワードを60回続けても弾かれず、直後に正解でログインできた**（実測・`last_login_at` が入ることまで確認して素通りでないことを確かめた）。見ているのは利用者ではなく**その顧客**で、破られると**お金を払っていない人が有料の教材を見られる**。**止め方はアカウント単位を主にした**（`サイトのスラッグ + メール` で10回/分。相手が回線を変えても効く）。**IP 単位は緩く**した（60回/分）—— ここが今回の要点で、**パートナーと同じ `throttle:10,1`（IP だけで数える形）にすると、社内の共有回線から大勢が入る場面で30人中20人が締め出される**（実測）。**上限を足すときは「止めたい形」と「巻き添えになる形」を両方測る**。**ここでも自分の測定が一度空回りした** —— 巻き添えを見るプローブが**セッションに CSRF トークンを入れておらず30件すべて 419**で、コントローラにすら届いていなかった。「429 でない＝通った」と数えていたため**上限を外しても付けても同じ結果**に見えた。**成立した印**（`last_login_at`）で数え直して確定させた。**自分のテストの誤りも1件** —— `SiteMember` に `status` を渡していたが、`membership_site_members` に**その列は存在しない**（`$fillable` と実列は一致しており形4の穴ではない。受講者の閲覧可否は `member_bundle_grants` だけで決まる）。テスト中のみ有効な `preventSilentlyDiscardingAttributes` が捕まえた。**変異2件で検知を確認**（上限を丸ごと外す＝修正前の形／アカウント単位をやめ IP の緩い上限だけ残す）。**素通り防止**として「同じ回線から30人が全員ログインできること」を同時に見る（上の2件が「全部弾かれているから緑」になるのを防ぐ）。検証: **MySQL 8.0 で 650 passed**（時刻を3パターンに固定しても同数）。 ### 2026-08-11 - **マージ後監査（PR#80）: 形6「二重に走る」を再棚卸しし、二重送信を3件修正**: 引き継ぎ資料が次に挙げていた**形6の再棚卸し**に移った。2026-08-02 は**定期実行だけ**を見ており、**キューのジョブ**と**シナリオリマインダ**が抜けていた。**3件とも実測で確定させた**。**①メール一斉送信** —— `processNextChunk()` が**チャンクを送り切ってから** `dispatch_cursor` を進めていた。ジョブは `tries = 3` で再試行するので、途中で worker が落ちると位置が戻ったまま拾い直され、**チャンクまるごと再送**になる（実測: 12人・チャンク5 で **合計15通・2回届いた宛先5件**）。**1件送るごとに位置を進める**ようにした（送った直後・記録前に落ちる隙間は残るが、そこは**1人ぶんが上限**）。**②LINE一斉送信も同じ形**だったので同時に直した（別サービスなので**検査も独立に**用意した。LINE は同じ通知が2回鳴るぶん、届き方の印象はメールより悪い）。**③シナリオリマインダ** —— 対象の絞り込みは「まだ送っていないもの」を**読んで**選ぶが、送信済みの印が付くのは**送った後**。実行が重なると両方が「まだ送っていない」と読んで**同じ人へ2通届く**（実測: **5人全員が2通**）。**`reserved` は絞り込みに使えない** —— `syncScenarioReservations()` が**未来ぶんの予約も** `reserved` で書くので、除外すると通常の配信が丸ごと止まる。ステップ配信と同じ**対象ごとの `Cache::lock`** で止め、**ロックの中でもう一度**決着済みかを読み直す形にした。**`withoutOverlapping()` は答えにならない**と分かったのが今回の要点 —— 守るのは**スケジューラの経路だけ**で、1回の実行が有効期限を超えればロックが切れるし、手元から直に流せば効かない。**ロックだけでも足りない** —— 非ブロッキングで取るため後発は**別の対象**ならロックを取れてしまい、**再確認を外す変異では4人が2通**受け取った（＝ロック内の読み直しは飾りではない）。**自分のテストの誤りも1件見つけて直した** —— 一斉送信の再送テストで、**チャンクを全部送り切ってから**位置を巻き戻していたため、落ちた後の読者まで「届いた」と数えて**常に3件重複**していた。`sendOne()` は例外を自分で捕まえて**失敗として記録する**ので送信イベントから例外を投げても「落ちた」にはならない、と確かめたうえで、**届いたのは落ちた時点まで**とみなす形に直した。**変異5件で検知を確認**（メールの位置更新をまとめる／LINE の位置更新をまとめる／リマインダのロックを外す／ロック内の再確認を外す、＋素通り防止として重なりが無ければ全員に1通ずつ届くこと）。検証: **MySQL 8.0 で 647 passed**（時刻を4パターンに固定しても同数）。 - **マージ後監査（PR#79）: 前サイクルで直したのと同じ形が、会員サイトにも残っていた**: 引き継ぎ資料が次に挙げていた**会員サイトの量**に移った。前回**公開ページのコメント**を直したので、**同じ形（訪問者・受講者が増やすコメント）が他の画面に無いか**を探したところ、**レッスンのコメント**（`MembershipSiteLessonCommentService::visibleForLesson`）が同じく**上限なしで全件読んでいた**。実測（1件300文字）: **5,000件=応答 6.7MB**、**20,000件=応答 26.7MB・リクエストのメモリ 61.5MB**。見ているのは**受講者**（利用者の顧客）なので影響は公開ページと同じ性質。公開ページと同じ方針で修正 —— **ブロック（レッスン）ごとに最新200件**、**新しい方を残す**、**表示は古い順**、**件数を画面に出す**。結果、**件数によらず 277KB**。**上限に達していないときは総数を数えない**ようにして、通常のレッスンで問い合わせを増やさない（検査で固定）。**ここでも自分の測定が一度空回りした** —— 最初の実測は件数を増やしても 9.1KB のまま平坦で、原因は `course_settings`（cast が `array`）に**JSON 文字列を渡していた**ため二重エンコードされ、`is_array()` が false になって**コメント機能が無効のまま**測っていたこと。配列で渡し直して確定させた（この落とし穴も資料に追記）。**変異3件で検知を確認**（上限を外す／古い方を残す／コメント機能を止める＝素通り防止）。検証: **MySQL 8.0 で 642 passed**（時刻を固定しても同数）。 - **マージ後監査（PR#78）: 公開ページの量的な上限を走査し、2件修正（うち1件は公開ページが 500 になる）**: 引き継ぎ資料が次に挙げていた**公開ページの量**に移った。管理画面は 2026-08-04 に実測済みだが、公開側は未測定で、**見ているのが利用者ではなくその顧客**なので影響が大きい。コメントブロックを 0〜20,000件で実測したところ**2件見つかった**。**①`layout` が無いと公開ページが 500** —— 判定が `in_array($el['layout'] ?? 'list', [...]) ? $el['layout'] : 'list'` と書かれており、**キーが無いと `in_array` は true になるのに ternary の側で `$el['layout']` を読んで** `Undefined array key` で落ちていた。**防御のつもりの `??` が防御になっていない**形で、周りは全部 `?? 'list'` 形式で書かれているので意図は「欠けても耐える」だった。先に取り出してから判定するよう修正。**②コメントに上限が無く青天井** —— 1件300文字で **5,000件=応答 8.8MB・ピーク 93MB**、**20,000件=応答 35MB・ピーク 265MB**（`memory_limit` 128M を超えて全訪問者に 500）。コメントは**訪問者が増やす**ので、ページの持ち主には量を抑えられないのが管理画面との違い。ブロックごとに**最新200件**へ制限し、**黙って打ち切らず**「全〇件のうち最新200件を表示しています」と出す。**新しい方を残す**（古い方を残すと投稿した本人が自分のコメントを見つけられない）が、**並びは古い順**に戻す（会話の流れ）。**ブロックごとに引く** —— ページ全体で1回引いて上限をかけると、投稿の多いブロックが枠を食い潰して**静かなブロックのコメントが丸ごと消える**（この落とし穴も検査で固定した）。結果、**件数によらず応答 374KB・7問い合わせ・リクエストのメモリ増分ほぼ0**。**測り方の誤りも自分で見つけた** —— 最初ピークメモリが件数とともに増えて見えたが、**プローブ自身が2万件の配列を組んでいた**ぶんだった。リクエスト前後の `memory_get_usage()` の差で測り直して確定させた。**変異3件で検知を確認**（`layout` の修正を戻す／上限を外す／古い方を残す）。**あわせて前回の LINE プレビューを実ブラウザで確認**（画像のサムネイルが描画される・Flex の見出し/本文/ボタン文字と代替テキストが出る・横にはみ出さない・JSエラーなし）。検証: **MySQL 8.0 で 638 passed**（時刻を固定しても同数）。 - **マージ後監査（PR#77）: 送信側に足した画像・動画・Flex が、一括プレビューでは「空の吹き出し」に見えていた**: 引き継ぎ資料が次に挙げていた **LINE 配信の中身**に移った。**3点を実測** —— ①**テキストの差し込みは効いていた**（`%name%` → `山田太郎`。実際に送って送信JSONを読んで確認）②**Flex の代替テキスト・JSON の中身は置き換わらない**（送信側が `message_text` にしか `StepMailMergeService` を通していない）③**一括プレビューが画像・動画・Flex を一切出さない** —— 画像URLも代替テキストも Flex の中身も、種別バッジすら無く、**空の吹き出しが並ぶだけ**だった。**③は自分の取り残し** —— 2026-08-05（PR#74）で送信側に種別を足したのに、**プレビュー側の更新を忘れていた**。docblock も「画像・動画・Flex は送信側に機能が無いのでここでも出さない」と書いたままで、**嘘になっていた**。パネルの約束は「実際に届く形」なので、内容を確認できない状態だった。種別ごとに描き分けるよう修正（画像・動画は**サムネイル＋元URL**、Flex は**中の文字＋代替テキスト**）。Flex は入れ子の JSON をそのまま見せても何が届くか分からないので、`LineMessagePayload::flexPreviewTexts()` で**読者の目に入る文字だけ**を抜き出す（`text` / `label` / `altText` を上から順に。**20行で頭打ち**にしてパネルが開かなくなるのを防ぐ）。**②は対象外と判断** —— 画面の置き換え文字チップは**本文の textarea にしか挿入しない**ので、Flex での差し込みは**画面が約束していない**。後から善意で広げると Flex JSON の構造を壊す差し込みが起き得るため、理由を仕様書に明記して据え置いた。**変異2件で検知を確認**（プレビューを修正前の形＝本文だけ描くに戻す／Flex の文字抽出が常に空を返す）。検証: **MySQL 8.0 で 634 passed**（時刻を固定しても同数）。 - **マージ後監査（PR#76）: 未検査だった「届くメールの中身」を実際に送って突き合わせた（不具合0件）**: まず**前回の修正で CI が緑に戻り、止まっていた本番デプロイが流れたこと**を GitHub Actions の実ランで確認した。今回入ったのは自分のコミットのみだったので、引き継ぎ資料が次に挙げていた**配信の「中身」**に移った。落ちないこと（例外・cron 停止）は走査済みだが、**送った中身が正しいか**は一度も見ていなかった。この repo は「保存はされるが送信処理が読んでいない」（形4）が繰り返し起きている領域（LINE一斉送信のカスタム送信者・シナリオのデフォルト件名/ヘッダー/フッター）なので、`MailDeliveryContentTest` で**送信を実行して送られたメッセージそのものを読む**形にした。**走査の結果は不具合0件** —— ①差し込み文字が**件名と本文の両方**で置き換わる（片方だけだと「件名に %name% がそのまま出る」メールが届く）②テキスト形式でも差し込みは効き、**HTML の共通ヘッダーは付かない**③**読者名に HTML が入っていても本文には生で入らない**（HTML本文は `e()` を通す）が、**件名はエスケープしない**（`<` が文字として見えるため）④差出人は**ステップ → シナリオ既定 → アカウント**の順⑤**一斉送信でも同じ**（ステップ配信とは別サービスなので独立に確認）。**LINE 側の非対称も確認したが問題なし** —— `pushMessage()` は `pushText()` と違って `$sender` 引数を持たないので画像・動画・Flex でカスタム送信者が落ちるのではと疑ったが、`LineMessagePayload::build()` が**全種別に** `sender` を載せていた（疑ってから読む、の実例）。**変異4件で検知を確認**（件名の差し込みを掛けない／HTML本文をエスケープせず差し込む／差出人の優先順位を崩す／一斉送信が composer を通らない）。**新しい検査が時刻依存でないことも確認**（`FAKE_NOW` で 03:00・23:58 に固定しても同数）。**製品コードの変更なし**。検証: **MySQL 8.0 で 629 passed**。 - **CI が赤く本番デプロイが止まっていた。原因は自分が入れた「時刻依存の検査」だった（マージ後監査）**: 基準線を取った時点で **main が赤**（`LineMediaMessageDeliveryTest` の3件）。**GitHub Actions の実ランを確認したところ、PR#75 のマージで走った 08:54 JST の実行が failure**、それ以前（16:31 JST 等）は success —— つまり**実行した時刻で結果が変わっていた**。**原因は自分が PR#74 で書いた fixture** で、`schedule_mode => 'immediately'`・`existing_reader_policy => 'send_all'` という**ドメインに実在しない値**を使っていた（正しくは `registration_immediate` / `schedule_all_readers`）。実在しない値は `ScenarioLineStepDispatchService::scheduledSendAt()` の `match` の **`default` に落ち**、`delay_time` が空なので**「登録日の 9:00」**として扱われる。その結果、**09:00 JST より前に走らせると1通も送られず**落ちる。**時刻を振って実測**して確定させた（JST 08:30→0通・09:30→2通・13:00→1通・23:30→1通）。**値を直すだけでは「いま通る」ことしか示せない**ので、**時刻を6つ振って送られること**を見る検査（`test_step_delivery_does_not_depend_on_the_time_of_day`）を足した。**変異2件で検知を確認**（実在しない値に戻す／送信処理を止める）。**他に時限爆弾が無いかも全件で走査** —— `FAKE_NOW` で時刻を固定して流せるようにし（環境変数が無ければ何もしない）、**00:05 / 03:00 / 08:59 / 23:58 / 年末 23:50 の5つで 624 passed** を確認。**別担当の3コミット（v0.4.53〜v0.4.55）も監査して問題なし** —— ①フォント設定に `!important` を付ける変更は**ブロックで明示的にフォントを選んだときだけ**に限定されており、`Noto Serif JP` は公開ページ・エディタの両方で**実際に読み込まれている**ことを確認（読み込んでいなければ効かない変更になる） ②Gemini の `responseModalities` 追加は応答の**読み取り側を変えていない**ので既存の検査は有効なまま ③失敗理由に**提供元のテキストを画面へ出す**ようになったが、エディタ・アカウント設定とも `textContent` で描いており、マークアップは注入されない。検証: **MySQL 8.0 で 624 passed**（時刻4パターンでも同数）。 ### 2026-08-10 - **別担当が入れた AI 画像編集を監査し、課金の発生する経路の回数制限漏れを1件修正＋未記載だった仕様を文書化**: 前回のセッションから間が空き、その間に **PR#68〜#74 と別担当の v0.4.33〜v0.4.52**（初期設定の説明改善・**アカウント設定画面と AI 画像編集**）が入っていた。まず**現状把握を実測からやり直した** —— 手元の sqlite では3件落ちるが、これは**引き継ぎ資料 §4-0 のとおり環境の問題**（新しい `ai_provider_credentials` 等が古い sqlite に無い）で、**MySQL では全件緑**であることを確認してから監査に入った。**AI 画像編集は総じて堅く作られていた** — APIキーは `EncryptedSecret` で暗号化・`text` 列・`(user_id, provider)` unique・FK なし（手動作成テーブル混在の本番に配慮）、外部呼び出しに timeout、元画像は自サーバの `/storage` 配下のみ、テストも2ファイルあり、既存の自動走査（画面186・送信303）が新ルートを自動で拾っていた。**見つけた1件** — **接続テストだけ回数制限が無かった**。この接続テストは「無料枠ではキーは通るが画像編集は使えない」を見抜くために**実際に画像を1枚生成する**ので、**1クリックが利用者の請求**になる。画像編集側には `throttle:20,1` があるのに確認側は無制限という非対称で、連打や JS の繰り返しで請求が膨らむ。`throttle:10,1` を入れた。**対象外と判断したもの（理由つき）** — ①**他契約の画像を `source` に渡せる**が、`storage/app/public` は**元から誰でも URL で取得できる**領域なので新たな開示は起きない（渡すには相手のランダムなファイル名を知っている必要がある）。所有者チェックを足すとメディア以外の経路で置かれた画像の編集を巻き添えで塞ぐおそれがある ②**提供元の応答サイズに上限が無い**が、`BoundedResponseBody` は**利用者が貼り付けた URL** 用の仕組みで、ここは固定の信頼できるホストしか叩かない（実測でも応答8MB相当でピーク増分は約4MB）。**ここでも二重防御で変異が検知されなかった（3度目）** — `/storage` 配下の判定を丸ごと外しても、`../` を含む書き方は **Flysystem 側でも弾かれる**ため検知できなかった。**その層だけが効く入力**（ディスク上に実在するが `/storage/` で始まらないパス）を渡す形を足して、判定が単独で効いていることを確かめた。**変異4件で検知を確認**（接続テストの上限を外す／画像編集の上限を外す／`/storage` 判定を外す／キーの暗号化を外す）。**あわせてドキュメントの陳腐化を6件是正** — アカウント設定・AI画像編集が**仕様書にもマニュアルにも無かった**ので `funnel-spec.md` §15 と `manual.md` §6 を新設（対象外と判断した2件の理由も明記）、引き継ぎ資料の数字（609→621・141→142件）と直近サイクル表・落とし穴・次の宿題を更新、`docs/README.md` の「6つの形」を実態（7つ＋別枠）に是正。検証: **MySQL 8.0 で 621 passed**。 ### 2026-08-05 - **LINEの画像・動画・Flex 配信を実装（利用者の必須要望・機能追加）**: 前日の調査で「LINE送信は全経路テキストのみ（`LineMessagingPushService` の公開メソッドが `pushText` の1つだけ・DB にも画像/動画/Flex の列が無い）」と確定していたため、**LINEステップ配信**と**LINE一斉送信**に画像・動画・Flex を追加した。**組み立てと検証の正本は `App\Support\Line\LineMessagePayload` の1クラス**にまとめ、ステップ配信・一斉送信・画面がすべてこれを通る形にした（別々に組むと「プレビューには出るのに届かない」という新しいずれを作るため）。**DB**: `2026_08_05_100000` で両テーブルに `message_type`（既定 `text`）・`media_original_url`・`media_preview_url`・`flex_alt_text`・`flex_json` を追加。**既存行は既定 `text` で従来どおり**動き、本文列（NOT NULL）には触れていない。**送信側**: `LineMessagingPushService::pushMessage()` を新設（`pushText` は互換のため残し、内部で `pushMessage` を呼ぶ）。**URLは https のみ**（LINE は http を受け付けない）で、メディアから選んだ `/storage/...` は **`APP_URL` 基準の絶対URLへ自動変換**して保存する（相対のままだと LINE から取得できない）。**Flex JSON は `bubble`/`carousel` でも、Flex Simulator が書き出す `{"type":"flex",...}` のメッセージ全体でも受け付ける**（貼り方が2通りあるため）。**保存時に送れる形かを検証**し、満たさなければ画面でエラーにする（保存できたのに届かない、を防ぐ）。送信時にも再確認し、送らずに理由を `last_error` に残す。**画面**は共通 partial `_line_message_fields` を2画面で共有（片方だけ直したときのずれを防ぐ）。**検査は「実際に LINE へ送られる JSON を読む」形**にした（DB や画面の値だけ見ても形4「保存はされるが送信処理が読んでいない」を拾えない）—— `Http::fake()` で捕まえて `messages[0]` を突合。**変異2件で検知を確認**（`build()` が常にテキストを返す＝機能が繋がっていない状態／https 検証を外す）。**未対応**: LINEチャット（手動送信）と LINE自動応答は従来どおりテキストのみ（別テーブルのため今回は対象外・仕様書に明記）。検証: 空DBから **migrate 142件完走**、全体 **608 passed**。 ### 2026-08-04 - **配信まわりの全経路調査（利用者の依頼: フレックス・動画・画像などLINE特有の配信を含む）＋定期実行コマンドの異常系（不具合0件）**: 「ステップ配信・シナリオ配信・メール配信・LINE配信を全部調べて」というご依頼を、ソース・DB・マイグレーション・資料の事実で確認した。**LINEの配信形式は全経路テキストのみ**と確定 —— `LineMessagingPushService` の公開メソッドは **`pushText` の1つだけ**で、組み立てる messages は `'type' => 'text'` のみ。DB にも画像・動画・Flex の列は無い（`scenario_line_steps.message_text` / `scenario_line_broadcasts.message_text` / `line_chat_outbound_messages.body_text` / `scenario_line_auto_replies.message_body`。画像があるのは `scenario_line_rich_menus.image_url` だけで、これはリッチメニューの別機能）。**画面もそれらを提供していない**ので「出荷したが動かない」（形2）ではなく**そもそも未実装**であり、コード側にも明記がある（`ScenarioLineStepController::preview()` の docblock「LINE ステップはテキストのみ（送信側が `pushText` しか持たない）なので、画像・動画・Flex は出さない」）。自動応答の**「テンプレートを送信」は LINE のテンプレート/Flex ではなく**、画面に「暫定: テンプレ本文をテキスト返信」と明記されていて実装もそのとおり。資料（`funnel-spec` / `manual`）も画像・動画・Flex 配信を謳っていないため**文書と実装の食い違いは無し**。**機能フラグの漏れも0件**（Kernel が参照する7つの `config('putage.*')` がすべて `.env.example` にある）。あわせて**定期実行の配信コマンド5本を壊れた状態で実際に動かす** `DeliveryCommandRobustnessTest` を新設（何もデータが無い／アカウントがアーカイブ済み／LINEトークンが空／送信用アカウントを消した孤児シナリオ）。**不具合0件**。**ここでも自分のテストが空回りしていた** —— `putage:event-reminders` は設定 `event_reminders_enabled` が既定 false で**配信ロジックを一度も通らずに SUCCESS を返す**（しかもこのコマンドだけ `--force` を持たない）。`config()` で有効化し、**ゲートが開いていること自体を assert** する形に直した。**変異2件で検知を確認**（リマインダで例外／LINEステップ配信サービスの `run()` で例外 → コマンドが異常終了して落ちる）。**製品コードの変更なし**。検証: **603 passed**。 - **マージ後監査（PR#71）: キューのジョブを異常な引数で実際に動かすようにした（不具合0件）**: 今回も入ったのは自分のコミットのみだったので、資料が次に挙げていた**キューのジョブ**に移った。**`ProcessScenarioBroadcastChunkJob` / `ProcessScenarioLineBroadcastChunkJob` に触れるテストは0件**で、**ジョブ本体は一度も実行されていなかった**（画面と送信経路しか見ていなかった）。ジョブは利用者の目に触れないところで動くため、ここで落ちると「配信したのに何も起きない・理由も分からない」になる。`BroadcastJobRobustnessTest` で **`handle()` を直接動かす**5形（存在しない id・0・負数／行を消してから／親シナリオが消えた孤児／アーカイブ済みアカウント／送信経路が無い）を走査し、**不具合0件**。**DB の事実を確認して分かった非対称** —— `scenario_broadcasts.scenario_id` には **`cascadeOnDelete` の外部キーがある**が、`scenario_line_broadcasts` には**外部キーが無い**（`information_schema` と作成マイグレーションの両方で確認）。そのためシナリオを消すと**メールの配信行は一緒に消え、LINE の配信行は孤児として残る**。孤児は画面に出ず、拾ったジョブも `failBroadcast()` で理由を残して止まるため**対象外と判断**（直すには移行が必要でそちらの方が危険）。この非対称はテストで固定したので、どちらかが変われば落ちる。**最初のテストは前提を間違えていた** —— 「親を消すとメールの配信も孤児になる」と考えて書いたが、`refresh()` が `ModelNotFoundException` で落ち、**外部キーを確認して cascade だと判明**した（推測せず DB を見る、の実例）。**変異3件で検知を確認**（メールジョブの「行が無ければ return」を `findOrFail` にする／LINE の「シナリオが見つかりません」の記録を無言 return に変える／メールの送信経路チェックを常に true にする）。**製品コードの変更なし**。検証: **598 passed**。 - **マージ後監査（PR#70）: パートナー側の「他契約のデータが見える」を走査し、3つのガードすべてを網羅した（不具合0件）**: 今回も入ったのは自分のコミットのみだったので、最後に残っていた **`partner` ガード**に移った。既存の `PartnerPortalTest::test_portal_shows_only_own_data` は**同じ契約の中の別パートナー**しか見ておらず、**別契約**は走査していなかった（`profile` 画面は一度も確認されていなかった）。`PartnerCrossTenantAccessTest` を新設し、**走査の結果は不具合0件**。ポータルのルートは**引数を取らない**（自分のデータは認証情報から引く）ため「id を差し替える」形が無いので、契約を2つ作って**他契約だけが持つ目印が応答に出てこないこと**を全画面で確かめる形にした。更新（プロフィール・パスワード）は**状態で見る**（他契約の行が変わらないこと）。**ここでも変異が検知されず、原因は目印の選び方だった** —— 最初 `customer_name` を目印にしたが、**成果履歴の画面はその列を描いておらず**、金額も `number_format` で「777,777」になるため生の値では一致せず、`partner_id` の絞り込みを外しても**検知できなかった**（実測）。**画面が実際に描いている項目**（パートナー名・紹介コード・案件名・整形後の金額・口座番号）に直したところ、**変異3件すべてで検知**するようになった（成果履歴の絞り込みを外す／支払明細の絞り込みを外す／登録情報を他人のパートナーで描く）。**素通り防止**として「自分の目印が必ず出ていること」も同時に確かめる（画面がログインへ転送されているだけで緑になるのを防ぐ）。これで **`web`・`site_member`・`partner` の3ガードすべてに他テナント走査が入った**。**製品コードの変更なし**。検証: **593 passed**。 - **マージ後監査（PR#69）: 受講者側の「他サイトへ書き込める」も全経路で見張るようにした（不具合0件）**: 今回も入ったのは自分のコミットのみだったので、前回の続きで**未走査だった会員側の送信経路**（コメント投稿・受講完了・テスト解答・視聴記録）に移った。**応答ではなく状態で見る**（302 では「認可で弾かれた」「バリデーションで弾かれた」「通ってしまった」を区別できない）ため、**全テーブルの件数**を前後で突き合わせ**1行でも増えたら不合格**とした。3つの入り方 × 4種の送信＝**12経路を走査して不具合0件**。**空回り防止に「正の対照」を必ず入れた** —— 自分の正当な道筋への受講完了で**実際に行が増える**ことを先に確かめる（これが無いと、送信が別の理由で常に弾かれているだけの「何も書き込まないから緑」になる）。**ここでも二重・三重防御のせいで変異が検知されなかった** —— 書き込み経路は `authorizeCourse()`（サイト・受講権）・`assertLessonOnCourse()`（親子の対応）・`lessonIsUnlockedForMember()`（解放条件）の**三重**で守られており、`assertLessonOnCourse` を丸ごと無効化しても他が拾って**検知できなかった**（実測）。読み取り側と同じく**受講権の行が他サイトの結合を指している**状態を作って受講権検査を通過させ、**サイト検査が単独で書き込みを止めている**ことを確かめる形を足した。**変異で検知を実測**（サイト検査を外すと他サイトのレッスンに `member_lesson_completions` が 0→1 で記録されて落ちる）。**製品コードの変更なし**。検証: **591 passed**。 - **マージ後監査（PR#68）: 受講者側の「他サイトの教材が見える」を全経路で見張るようにした（不具合0件）**: 今回入ったのは自分のドキュメント修正のみだったので、**未走査のまま残っていた領域**に移った。`CrossTenantAccessTest` は**管理画面（`web` ガード）だけ**で、**受講者（`site_member`）は一度も走査していなかった**。ここが破れると「お金を払っていない人が他サイトの教材を見られる」ため、`MemberCrossTenantAccessTest` を新設。**走査の結果は不具合0件**。**入り方を4つ試す**のが要点 —— ミドルウェア `EnsureMemberBelongsToSlugSite` は**スラッグと会員の所属しか見ない**ので、①他サイトのスラッグ+他サイトのid（ミドルウェアが弾く）だけでなく、②**自分のスラッグ+他サイトのid**（素通りするのでコントローラが弾く必要がある）を必ず見る。さらに**変異で検知を確かめる過程で、前半2つでは不十分**だと分かった —— `authorizeCourse()` は「サイトが違う→404」と「受講権が無い→403」の**二重**で守っているため、**サイト検査を外しても受講権検査が拾って検知できない**。そこで③**受講権の行が他サイトの結合を指している**状態を作り、サイト検査が単独で効いていることを確かめる形を足した。同様に、他サイトのidで揃えた形だけでは**親子の対応検査（レッスンがそのグループのものか）を外しても検知できなかった**ので、④**自分の正当な道筋にレッスンだけ他サイト**を混ぜる形を足した。**変異3件すべてで検知することを実測**（サイト検査を外す／ミドルウェアの所属検査を外す／レッスンと親の対応検査を外す）。**fixture の落とし穴も踏んだ** —— 結合（`course_bundles`）に**コースを入れ忘れる**と `hasGrantForCourse()` が false になり、受講権を与えたつもりでも 403 で止まって**変異を検知できない**（`course_bundle_items` の紐づけが必須）。**走査自身の誤検知も1件自分で見つけた** —— 他サイトidを含まない画面（自分のお知らせ）まで対象にしていて 200 で誤検知していた（資料の落とし穴「走査系はまず自分を疑う」どおり）。**製品コードの変更なし**。検証: **589 passed**。 - **引き継ぎ資料の「すぐ再開する手順」が新しい環境で通らなかったので実測どおりに訂正（PR#68）**: 引き継ぎを受けて手順をそのまま実行したところ、**テスト全件が `Connection refused` で落ちた**（製品の不具合に見える形）。原因は3つ重なっていた —— ①**テストの接続先は `.env`**（`phpunit.xml` の sqlite 指定はコメントアウト済み）で、`.env` は `.gitignore` なので新しい環境に無い ②**sqlite ではスキーマを作れない**（ドライバ分岐のない MySQL 専用の生SQL が3件あり `migrate` が止まる。これは `degradation-policy.md` 形5 の「必ず本番と同じ MySQL で確かめる」判断の結果で**意図的**。資料の「開発DBは sqlite」で使われていた sqlite は**移行から作り直せない過去の遺物**だった） ③**MySQL 自体が未インストール**。さらに資料の `mysqld ... &` は**親シェルが終わると落ちる**ことも実測（`setsid` が必要）。§4 に「0) 環境を用意する」を新設し、`composer install` → `.env` 作成 → MySQL 導入・起動 → `migrate --force` までを**実際に通したコマンド**で記載。§3・§8 の sqlite の記述も訂正し、**ローカル PHP と CI(8.2)・composer(^8.1) が一致せず 8.2 以降の構文を手元でも CI でも検出できない**点を注意として追記。**資料の数値も監査した** —— 最初ルート単位で数えて「送信273→256」等と食い違い「資料が古い」と読みかけたが、**検査本体は verb ごとに数えている**（`AdminSubmitSmokeTest` の `foreach ($methods as $method) { $checked++; }`）ためで、合わせると**送信273・更新171・削除63・引数なし46 がすべて一致**。資料の数値は正しく修正不要だった（落とし穴「走査系はまず自分を疑う」を自分で踏んだ形）。 - **マージ後監査（PR#66）＋引き継ぎ文書の整備**: 前回入れた `CrossTenantAccessTest` には**明記した限界**があった —— 更新（POST/PUT/PATCH）は「認可で弾かれたのか、バリデーションで弾かれたのか」を応答から区別できないため対象外にしていた。今回それを**状態で見る形**で埋めた（対象の行の全カラム＋全テーブルの件数を前後で突き合わせ、**書き換わった／行が増えたら不合格**）。**171経路を走査して不具合0件**。**ここで検査自身の弱点も見つけた** — 最初の変異（`saveMemo` の認可を外す）が**検知されなかった**。空の送信は `admin_memo` を null にするが、fixture の値も元から null なので**差が出ない**（同じ値を書く操作は見えない）。fixture に**空の送信で消える値**をあらかじめ入れて再確認し、検知することを実測した（変異を戻すと 0 件に戻ることも確認）。この限界はクラスの docblock に明記。**あわせて引き継ぎ文書 `docs/HANDOFF-audit-20260804.md` を新設** —— 作業サイクル（マージ→監査→実測→変異確認→PR）、曲げないルール10件、7つの形と対応する自動検査の対応表、検査の網の数字（管理186画面・送信303経路・他契約 読138/書171/削63）、**すぐ再開するためのコマンド**（基準線の取り方・MySQL の立て方・実ブラウザの動かし方・応答量の測り方）、**落とし穴10件**（ルート1本の裏に63画面／走査系スクリプトのバグをまず疑う／上限は抑える軸を間違えやすい／応答が小さくてもメモリは増える 等）、残っている宿題、次に手を付けるとよい4領域を1枚にまとめた。`SPEC.md`・`docs/README.md`・`CLAUDE.md` の索引から辿れるようにした。検証: **585 passed**。 - **マージ後監査（PR#65）: 「他契約のデータが見える・消える」を全経路で機械的に見張るようにした（不具合0件）**: 今回は自分のコミット1本だけのマージで、そこに追加の欠陥は見つからなかったため、**未検査のまま残っていた領域**に目を向けた。**多テナントの分離**は、この repo で起こり得る不具合のなかで最も重い（他社のデータが見える／消える）のに、**全経路をまとめて見張る検査が無かった**。実際に3件見つかっている（ABテストのページ・パターンの所属・パートナーの他契約403・シナリオ一括プレビューの `ids[]`）が、いずれも個別対応だった。契約Bに一式のデータを作り**契約Aでログインして**叩く `CrossTenantAccessTest` を追加 — **管理画面（GET・idあり）75本＋ワークスペースの中の画面63枚**は 200 が返ったら不合格、**削除（DELETE）63本**は**対象の行が消えたら不合格**。削除を応答で見ないのは、消したうえで 302 を返す実装があり得るため（**状態で見る**）。**走査の結果は不具合0件** — 認可は全経路で正しく効いていた。**「0件で緑」を信じる前に変異3件で検知を確認**（ファネル詳細の認可を外す→該当画面が 200 で検知／シナリオワークスペースの認可を外す→60画面で検知／ファネル削除の認可を外す→実際に行が消えて検知）。**fixture の登録簿（約57モデル）は `Tests\Support\MakesAdminFixtures` に切り出して `AdminSubmitSmokeTest` と共有**（別々に持つと片方だけモデルを足したときにずれる）。ついでに登録簿の穴も塞いだ（`ScenarioBroadcast`・`ScenarioLineBroadcast` が無く、その2経路は**一度も叩かれないまま緑**だった）。素通り防止つき（解決できないパラメータがあれば落とす・拾えた画面数が少なすぎれば落とす）。**限界も明記** — 空の入力で叩くので、更新（PUT/PATCH）が認可で弾かれたのかバリデーションで弾かれたのかは区別しない。検証: sqlite・MySQL 8.0 の両方で **584 passed**。 - **マージ後監査（PR#64）: 別担当が入れた「まず〇〇を設定して」案内が、設定する場所そのもので出て堂々巡りになっていたのを修正**: 今回は自分の変更に加えて**別担当のコミット13本**（初期設定まわりの UX 改善・v0.4.20〜v0.4.32）が同時にマージされたので、そちらを重点的に見た。新規の `App\Support\FeatureSetupGate` は `layouts/app` に入っており**すべての管理画面**を通る（＝取り違えると影響が全画面に出る）。**見つけた1件** — **送信用アカウントの画面（`/account`・`/account/create`）で「まず『メール設定 または LINE設定』の設定を実施してください」と出て、「設定する」を押すと同じ画面に戻る**。`/account/create` に至っては**まさにその設定を作っている最中**に「先に作ってください」と言われる。初期設定フローからの流入（`?setup_channel=mail|line`）だけ除外していたため、**左メニューから来ると素通り**していた。しかも**会社情報だけ済ませた状態**（初期設定の順序どおりに進めた途中）でしか再現しないため、何も設定していない状態で見ると気づけない（最初の走査では「なし」と出て、状態を作り直して発見した）。`account.*` では配信設定を求めないようにした（会社情報は別の設定なので従来どおり案内する）。**問題なかったもの** — ダッシュボードの開始案内は「初期設定を1つでも行っていれば出さない」で誤警報なし（`||` の短絡評価で設定済みユーザーは1問い合わせ）。案内の追加問い合わせは機能ページのみ2本（`/funnel` 全体で4本）。オペレーターは `operator_identities` ログインが `Auth::login($owner)` なのでオーナーの設定で正しく判定される。`route()` が絶対URLな点は**ビュー全体の慣習**（相対は765件中3件）なのでここだけ直すのは筋が悪いと判断。**用語集アコーディオンは実ブラウザで確認**（既定は閉じる・クリックで開く・用語5件・各項目が展開・JSエラーなし）。**検査を新設**（`FeatureSetupNoticeTest` 5件）— 引数の要らない管理画面すべてを走査して**案内先が「いま開いている画面」でないこと**を見張る（素通り防止つき: 1画面も案内が出ていなければ落とす）。**変異2件で検知を確認**（修正前の形に戻す／案内を丸ごと止める）。検証: **582 passed**。 - **マージ後監査（PR#63）: 前回入れた上限が「抑える軸を間違えていた」ことを実測で発見（2回目の取り違え）**: 前回シナリオ数を 20 に制限したが、**枠の数はシナリオ数 × 通数**なので、1シナリオの通数が多ければ意味が無かった。実測（20シナリオ・メール+LINE）: **50通/シナリオ=3.5MB → 100通=7.0MB → 200通=14.1MB・ピークメモリ 88MB**（`memory_limit=128M` の目前）。**抑える軸はシナリオ数ではなく「描くステップ枠の総数」**だった。`StepPreviewBodyBudget` を **`StepPreviewBudget`** に改め、**通数（既定2000）と本文の合計文字数（既定200万字）を同じ器**で持たせた（別々に持つと片方だけ直したときにずれる。どちらもシナリオをまたいで合計で数える）。**さらにメモリだけが増える経路も見つけた** — 通数の上限は応答を抑えるが、**行は全部読んでから捨てて**いたため、20シナリオ × 500通で応答 3.5MB のまま**ピークメモリ 109MB**だった。`stepCountsByScenario()` で**行を読む前に通数だけ数え**、読む対象のシナリオを決めるようにした（読む行は「上限ぶん＋最後の1シナリオぶん」で頭打ち）。**結果、選んだ数・通数によらず 3.5MB・ピーク 43MB・9問い合わせ**（20×500 でも同じ）。通常規模（20シナリオ × 20通）は 1.43MB・ピーク 36MB で**従来と変わらない**。**シナリオ内のプレビューも同じ器を通す**ようにし、見出しには**実際の通数**を出す（描いた数だけ見せると規模を見誤る）。**変異4件で検知を確認**（一覧側の上限を外す／シナリオ内の上限を外す／予算の共有をやめる／行を読む前に数える処理を外す —— 最後の1件は応答が小さいままなので**読んだシナリオ数**で見張るテストを別に用意した）。**あわせて画面の量的な棚卸しも実施** — 管理14画面を1件→200件→2000件で実測し、**危険域に入るものは無し**（読者一覧はページ送りあり。シナリオ一覧 2000件=4.98MB・ピーク53MB、ページ一覧 2000件=5.08MB・ピーク61MB で、いずれも開く）。**ドキュメントの陳腐化はゲートが検知した**（クラス名を変えた結果 `DocFileReferenceTest` が赤くなり、`docs/funnel-spec.md`・`CLAUDE.md` の古い参照を是正）。検証: sqlite・MySQL 8.0 の両方で **576 passed**。 - **マージ後監査（PR#62）: 一覧プレビューが「すべて選択」で青天井になっていたのを実測で発見し、上限・まとめ取得・読み取り専用化の3件を修正**: 前回入れたシナリオ一覧の一括プレビューを、**推測せず実測**した。**利用者操作は実ブラウザで確認済み** — チェックボックスを押しても行のリンクへ遷移しない（行クリックの導線に `input` の除外がある）・ボタンの有効化と件数表示・**すべて選択**・選択を変えると取り直すこと、いずれも正常だった。**問題は規模だった** — シナリオ一覧は**ページ送りが無く**（`globalIndex` は全件取得）、**すべて選択が1クリックで全シナリオを選ぶ**のに、応答の大きさも問い合わせ本数も**選んだ数に比例して青天井**だった。実測（1シナリオ20ステップ換算）: **10件=1.7MB/55問い合わせ・30件=5.2MB/155・100件=11.2MB/505・ピークメモリ 82.5MB**（PHP 既定の `memory_limit=128M` に届くとパネルが開かない＝形1「画面が開かない」）。前回入れた本文の上限（`App\Support\StepPreviewBudget`・当時の名前は `StepPreviewBodyBudget`）は**本文だけ**を抑えるもので、番号・タイミング・差出人・件名の枠は必ず描くため、**通数そのものが増えると効かない**（＝上限を入れたつもりで抜けていた）。**①一度に描くシナリオ数の上限** `ScenarioController::PREVIEW_MAX_SCENARIOS = 20` を入れ、**黙って落とさず**「残り〇件は表示していません」と件数を画面に出す。**②まとめ取得** — ステップ・カスタム送信者・拡張設定を `whereIn` で1回ずつ引くようにし、シナリオごとの問い合わせを廃止。**③プレビューは読むだけにした** — 拡張設定は `ensureForScenario()`（無ければ作る）を使っており、**見るだけの操作で選んだ数だけ INSERT** が走っていた。読み取りのみに変え、未作成なら `null` のまま渡す（`ScenarioMailComposer` も画面も `null` を受け取れることを確認）。**結果、選択数によらず 3.45MB・9問い合わせ**（100件選んでも同じ）。**変異3件で検知を確認**（上限を外す／シナリオごとに引く形に戻す／`ensureForScenario` に戻す）。検証: sqlite・MySQL 8.0 の両方で **570 passed**。 - **シナリオ一覧から「選んでプレビュー」できるようにした（利用者の要望）**: 「中に入らないと見れないのだと、どのシナリオが何かをすぐにチェックできない」というご指摘。各行に**チェックボックス**を置き、ツールバーの **選んだシナリオをプレビュー** で、選んだシナリオの**メール・LINE両方**の配信内容を1つのパネルに並べるようにした（`scenario.global.preview`）。**描画はシナリオ内の一括プレビューと同じ partial** を通す（別に組むと片方だけ直したときに食い違う）。**所有権はサーバ側で必ず確認** — `ids[]` は画面から書き換えられるので送信用アカウントの `user_id` で絞り、**出せなかった件数は画面に出す**（黙って減らすと理由が分からない）。**本文の合計量の上限は `App\Support\StepPreviewBudget`（当時の名前は `StepPreviewBodyBudget`）に切り出して共有** — シナリオごとに上限を持つと10個選べば10倍になりパネルが開かなくなるため、選択したシナリオ**全体**で数える（シナリオ内プレビューも同じ部品を使うようリファクタし、上限ロジックの二重管理を解消）。未紐づけのチャネルは「メールは紐づいていません」と明示（黙って空白にしない）。**実機で確認** — チェック0件ではボタンが押せない・1件選ぶと有効になり件数が出る・選択を変えると中身を取り直す・すべて選択で2シナリオ並ぶ・JSエラーなし。**変異2件で検知を確認**（所有権チェックを外す／予算をシナリオごとに持つ）。検証: 全体 **567 passed**。 - **「プレビューボタンがどこにもない」の原因は導線の欠落だった（利用者からの指摘）**: シナリオ一覧の画面を見ながらのご指摘。調べたところ**2つの原因**があった。①**LINEステップ配信が左メニューに無かった** — メールの「ステップ配信」は `layouts/app.blade.php` にあるのに、LINE側だけ抜けており、**シナリオ概要のタイルからしか行けない**状態。お客様のシナリオは**メール未設定・LINE設定済**で、その場合メール管理のセクションは丸ごと隠れる設計なので、**メニューのどこにも「ステップ配信」が出てこない**（実機で左メニュー18項目を列挙して確認）。2026-07-27 の LINEステップ配信実装時のサイドバー追加漏れ＝形3「出荷したが到達できない」。②**ステップ0件だとボタンを隠していた**（私の設計判断）— 「機能そのものが無い」と読まれるので、0件でも出すようにした（パネル側は「ステップがありません」と出す）。**検査の素通りも自分で発見** — 到達性テストをページ全体で書いたら、**概要ページのタイルに一致して素通り**した（サイドバーのリンクを消しても緑）。`sidebarHtml()` で**左メニューの範囲だけ**を切り出して見るように直し、変異2件（サイドバーからリンクを削除／0件でボタンを隠す）で検知を確認。検証: 全体 **560 passed**。 - **マージ後監査（PR#61）: プレビューを実ブラウザで検証し4件修正／LINE自動応答のエラーが画面に出ていなかったのを修正**: ご指摘の観点（画像・動画・リンク・LINEエラーの取り込み）を**推測せず Chromium で実測**した。**動いていたもの**: 画像は表示（`sandbox` は画像を妨げない）・本文のCSSは iframe 内で有効・共通ヘッダー/フッターも描画・`