起動画面は公式の標準どおりに作り、
アプリは自分で「けんこう診断」する

🌅 起動画面は「自作しない」。世の中の標準どおりに作る

アプリを開いた直後に出る画像を起動画面（スプラッシュ）と呼びます。 世の中のアプリの起動画面は、たいてい普通にきちんと出ています。 それは各社が自作しているからではなく、逆に公式の標準どおりに作っているからです。

Capacitor には公式のアセット生成ツール @capacitor/assets があり、assets/ に元の画像を置くだけで、iPhone・Android・Webの全サイズを自動生成します。 ダークモード用も splash-dark.png という決まった名前を置けば公式が対応します。 ここに自前の生成処理を書き足す必要はありません。

公式に任せても、次の3つだけは自動で埋まりません。ここだけをキットが確認します。

npm run splash:check

★2026-08-24に方針を変えました。以前はこのキット自身が起動画面の画像を生成しており、 その自作部分が原因の不具合を、さらに自作の検査で見つける状態になっていました。 自作をやめて公式ツールに寄せ、約500行を削除しました。 残したのは上の3点だけです。

★この自動検査は設定と画像ファイルを確認します。端末ごとの色味や大きさの好みまでは判定できないため、 全部合格した後もiPhone・Android実機で最後に1回だけ目視します。

実際のアプリの起動画面（2026-08-27 実機で撮影・地色は実測）

「きちんと出ている起動画面」がどういうものかを、実機の画面録画から取り出しました。 地色は画像から実際に測った値です（推測ではありません）。 並べてみると、有名アプリほどやっていることは少ないと分かります。

★やってはいけないことも、この8本が示しています。 文字を詰め込む・地色と画像の色を食い違わせる・ロゴを画面いっぱいに広げる—— どれも1本もやっていません。「地色1色＋中央にロゴ」から外れたら、まず疑ってください。

★画像は見本であり、著作権は各社に帰属します。 設計の参考として実機の見え方を記録したものです。真似すべきは構図と情報量であって、 ロゴやデザインそのものではありません。

📁 使う前に：どこに置くか（これだけ守れば自動で繋がります）

このキットは1つの親フォルダの下に、プロジェクトを横に並べる形を前提にしています。 この形なら、検査は症状の定義も原因の索引も自分で見つけます（引数を渡す必要がありません）。

github/            ← 親フォルダ（名前は何でもよい）
  ├ ai-hub/         ← 原因の索引（index.json）★これが横に居ることが大事
  ├ web-ios-android/← このキット
  ├ your-app-a/     ← あなたのプロジェクト
  └ your-app-b/

探す場所は決め打ちしていません。下の順に見て、最初に見つかったものを使います。

別の場所に置きたいときは、場所を渡してください。

node templates/diagnostics/check-symptom-index.mjs \
  --symptoms path/to/symptoms.js \
  --index    path/to/index.json

★見つからなくても、勝手に「問題なし」にはしません。 症状の仕組みをまだ入れていなければ「まだありません（skip）」と入れ方を案内し、 症状はあるのに索引だけ見つからないときは 「測れませんでした」として区別します （＝入れたのに繋がっていない合図です）。

★検査そのものが「サボると赤くなるか」を確かめているか

2026-08-23、このキット自身が自分の掟を破っていることが分かりました。 診断3本に selftest が1つも無く、--selftest を渡しても 引数が無視されて「skip」で終了コード0を返していました。 ＝ 壊れていても緑に見える状態です。

3本に手で足すだけでは、次に4本目を作った人が忘れたら終わりです。 そこで check-selftest-coverage.mjs が selftest を持たない検査の数を機械が数え、増えたときだけ赤くします。 いまの本数を上限として固定してあるので、減らすのは自由です。

★名前だけを見ません。コメントを除いた実コードで 引数を実際に読んでいるかまで確かめます （コメントに書いただけで通る穴を塞ぐため）。

★「共有するほど不具合が減る」を成り立たせる1本

症状が起きたとき、アプリは 症状ID（例 panel-black）を出します。 その言葉で過去の原因の索引を引ければ、次に同じ症状を見た人は 調べ直す往復が要りません。これが「共有するほど減る」の中身です。

ところが実測すると、症状ID 7件で索引を引いて ヒット率は 0% でした。索引には245件の登録があるのに、 症状の言葉と索引の言葉が別々だったためです。

check-symptom-index.mjs が 索引に無い症状の数を数えます。上の run.mjs を回せば一緒に走ります（症状定義と索引の場所は自動で探します）。原因が分かった症状を索引に足すと 緑になります（実演で 0% → 100% を確認済み）。 ＝ 正しい方向にだけ報われる形にしてあります。

★「登録して」と頼む仕組みにはしません。頼む形（オプトイン）は このキットで3ヶ月で登録1件のまま死んだ実績があります。 ★この検査は索引の中身が正しいかは判定しません（正しさは人が確かめます）。

🔒 出荷前に「セキュリティ診断で満点」を内部確認＋本体実測する

セキュリティ診断サービス（malwarecheck.siteなど）に自分のWebサイトを投げると、 セキュリティヘッダーの設定漏れや .env ファイルの公開放置などで 減点されることがあります。そこで、内部の先取り検査で直す場所を見つけ、 最後に malwarecheck.site 本体でも実測する2段階の検査にしています。

★外部サービスへ送るのは公開URLだけです。秘密情報やローカルファイルは送りません。 SQLi/XSSの実注入テストやポートスキャン、パスワードの総当たりも一切行いません。 100点は外部から見える簡易診断の満点であり、「絶対安全」を意味しないことも 検査結果に毎回明記されます。

📱 レスポンシブ設計を抜け漏れなくチェックする

スマホ・タブレット・PCなど画面サイズが違うだけで、横スクロールが出たり 文字が読めないほど小さくなったりすることがあります。崩れやすい書き方を コードのまま先に見つけ、最後に実際のブラウザで見た目を確認する 2段階の検査にしています。

★「実際にどう見えるか」の判定は自前で再実装しません。ブラウザのレイアウト 計算をコードで完全再現するのは車輪の再発明であり、必ずズレます。 静的解析は「固定px幅」「viewportタグの欠如」「メディアクエリの不在」といった 崩れやすい既知パターンの先取りゲートに留め、正式な判定は実ブラウザでの 実測（375px・768px・1024px・1440pxで実際に開いて横スクロール・見切れを確認） に委ねています。

見ていないときは止まります。画面が隠れているあいだは測定を停止するので、 電池もCPUも食いません。「ずっと動く」と「ずっと重い」は別です。

読む間隔は「書く側の間隔」で決めます。 「1秒でも遅れたら困る」といった感覚で決めると、人によって答えが変わり、根拠が残りません。 データを書いている側が何秒ごとに更新するか——これだけが動かない事実なので、そこから決めます。

コピーには「いつの値か」を必ず入れます。 30秒前の数字を「今の状態」として読むと誤診になります。 判定も正常／注意／異常／まだ測れていないの4つに分け、 「測れていない」を「正常」に混ぜません。

症状の出ている画面では測らない。重い画面をさらに操作すると、測ること自体が症状を悪化させます。 別のブラウザ窓に出荷物だけを読ませて、そこで測ります。

必要なのは「実データ」ではなく「実規模」。 たとえば「参加者857人」で崩れるなら、857個ぶんの部品を合成すれば再現できます。 本物の配信を待つ必要はありません。

「効いているはずの対策」の実文を読む。 実例では「25個目から小さくする」という対策が入っていましたが、実際の指定を読むと 小さくするだけで、個数は1個も減らしていませんでした。思い込みはここで壊れます。

この台帳は「間違った数字を書いたときだけ赤くなる」設計です。 「毎回書かないと赤くなる」ようにはしていません。書くこと自体を強制すると、 面倒なときにとりあえずの嘘の数字が入ってしまい、台帳の信頼が一度で崩れるためです。 記録を忘れた版は「悪化」ではなく「まだ測っていません」という別の扱いになり、 忘れたことに後から気づける形にしてあります。

台帳を作っても、手で書く数字は書き忘れた瞬間に死にます。 実例では、台帳を入れて8日後に調べたところ—— 10種類のうち自動で記録される2種類しか動いていませんでした。 その間に診断の所要時間は29.3秒→0.019秒と1,500倍も良くなっていたのに、 記録は1件も残っていませんでした。 つまり台帳は「改善している」と表示しながら、ほとんど何も測っていませんでした。

「測れている数 / 全体」を常に出します。 放置されている数字は名前と「何版前か」を添えて見せます。 ただし書くことは強制しません——強制すると、面倒なときに 「とりあえず埋める」で嘘の数字が入るからです。

動かなかったものは、何も言いません。 「無言だった」ことは、それ自身には分かりません（動いていないのだから）。 だから外側に記録を置き、必ず前へ進むもの（更新の履歴）と照らし合わせます。

検査がちゃんと通ったときにだけ印が残る形にしてあります。 赤で止まっていれば印は残らないので、放置するほど差が開き、やがて知らせが出ます。

知らせは「調べていません」であって「悪くなりました」ではありません。 ここを赤にすると、とりあえず印だけ付けて黙らせる動機を作ってしまうためです （台帳を無理に書かせると嘘の数字が入るのと、まったく同じ理由）。

Git追跡ファイルとGitが表示する未追跡ファイルを全件数え、Gitの全コミット件名、現在の変更、 指示書、設計・事故の記録、数字の進化台帳を1枚にします。 各項目には元のファイルと行番号・hashが付くため、AIが要約だけで断定せず原文へ戻れます。

confirmed（証拠があり次回も守る）、rejected（実測で却下し、 もう繰り返さない）、pending（まだ仮説）を混ぜません。 確定と却下は証拠が無いと台帳へ書けないので、推測がいつの間にか仕様になる事故を防ぎます。

https://<アプリ本体のドメイン>/check-shindan-version/ です。

たとえば soushin-suggest.link なら /check-shindan-version/、app.reply-suggest.link でも 同じ /check-shindan-version/ が本体の一部として作られます。

soushin-suggest.link の本体LPを具体例にします。

導入後は、利用者が知りたい短い更新情報を本体LPへ、詳しい動作確認を /check-shindan-version/ へ、同じ情報から同時に反映します。

進み具合は、必要な確認がいくつ終わったかを表します。 現在の状態は、確認済み／確認中／問題あり／まだ未確認の4つです。 そのため「まだ確認していない」を問題なしにせず、何が残っているかと次にすることまで分かります。

同じ期間に見つかった本物の不具合5件の内訳です。

・使っている本人の報告…3件（「反応が悪い」「クリックで入らない」）
・アプリ自身が書き出した記録…2件（一覧が真っ白になる症状。数字から原因が確定）

重いテストが見つけたものは、0件でした。

記録は症状が出たときに書かれます。すると、

・本当に何も起きなかった
・記録する仕組みそのものが動いていなかった

この2つがまったく同じ見た目（無言）になります。 実際にある製品では、起動直後の異常が記録の仕組みを一度も通らず、 ログに何も残らないことが確かめられています。

症状が無くても、一定間隔で1行だけ書く。それだけです。 こうすると最後の心拍から「いつ動かなくなったか」が分かり、 無言と正常をようやく区別できます。 これを見るのが check-heartbeat-present です。

確認・再現・記録・修正・再確認は、すべてAIがPC上で完結させます。 ユーザーに「触ってみてください」と依頼しません。

不具合の有無はAIが自分で確認します。コードを読んで「動くはず」で済ませず、 実際に動かして確認してから報告します（「完膚なきまでの裏取り」の実行）。 「見た」「直したつもり」で終わらせず、修正後は同じ手順で再確認し、 比較用の証拠（before/after）も残します。