自作の Windows アプリ（測定系・Rust／Tauri＋React・クローズドβ・一人開発）を出す前の 10 日間に、自分で撤回した「盛り」が 6 件ありました。全部、実装と説明の下書きに AI を使った箇所です。何を盛っていたか、どう見つけたか、PR 番号つきで書きます。製品の式・閾値・価格は書きません。
同じ件を、問題・原因・対応・検証・やらなかったことの 9 項目で書いた実績詳細を置いています: https://sumitsuke.jp/via/qiita/works/cases/pre-ship-audit/
先に結論
- 「盛り」は 3 型に分かれた——①実装が伴わない表示（走らない補正を「対応」と書く）②根拠の無い数値（未確立なのに既定値を出す）③実態にない主張・機能（送信先の無いトグル・無い監査証跡・無い統計的根拠・実態より強い語）。
- 6 件とも、書いた本人（AI と私）は「正しく動く形」だと思っていた。見つけたのは、別の観点で読ませて、指摘を file:line で照合したとき。
- 直す方向は「盛りの逆」＝表示を実装に合わせる。実装を表示に合わせる（機能を急いで足す）はしなかった。
「盛り」の定義
出荷前チェックで「盛り」と呼んだのは、次のどれかに当たる文言・数値・UI です。
- 実装が伴わない表示——本番で走らないコードの効果を、ユーザーに約束している
- 根拠の無い数値——データが無い・未確立なのに、それらしい値が画面に出る
- 実態にない主張・機能——無い機能のトグル、無い証跡、無い統計的根拠、実態より強い語
誇張しようとして書いたものは 1 件も無い。全部「それらしい形」を AI と私が通してしまったものです。
数え方: 同じ原因・同じ修正判断で処理したものを 1 つの「撤回テーマ」と数えて 6 件です（3 番と 6 番は中に複数の修正がある）。修正の箇所数で数えれば 10 を超えます。
6 件
1. 走らない補正を「対応」と書いていた（PR #408・2026-06-01）
LP の FAQ に「中程度のジッター（レイテンシ補正で対応）」とありました。補正のクラスはある。ただし本番の経路に配線されていない。走らない補正をユーザーに約束していた。→ 文言を削除。実装を足す方向にはしない（β の範囲外）。型①。
2. 決まっていない価格を確定表示していた（PR #408）
構造化データ（JSON-LD の Offer）と利用規約に、まだ決めていない価格帯が数字で入っていた。→「β期間中に決定」に。型②（未確定を確定のように出す）。
3. 開示なしの偽数字（PR #502・2026-06-08）
- 連続日数（streak）が取れないときの既定値が 2（0 でなく）。チップにも出ていた → 0 に、チップは非表示に
- 「3 分前」を返す死にコードが残っていた → 削除
- 予測が未確立でも「これから」の予測帯を描いていた → 空状態に
- 予測グラフの「最適 window・推奨・最速マーカー」を、window が確立する前から出していた → 確立後だけに
→ 型②。共通するのは「データが無いときの見た目を、データがあるときと同じにしていた」こと。
4. 実態より強い語（PR #475・2026-06-04）
- 不確かさの表示「±N ms」→ 実態は相対値なので「±N（相対）」
- 「測定品質」→ 計算しているのは計算の品質なので「計算品質」
- 予測の「集中ピーク／peak probability」→ 実態は「推奨時間帯の中央／平均の運用率」
→ 型③（無い精度を語で作っていた）。表示と i18n だけの修正で、数理は触っていない。
5. 「統計的に意味のある精度」と書いていた（PR #512・2026-06-09）
マイルストーンの説明文に「統計的に意味ある精度」。実機構は体内リズムと校正の鮮度に基づく点予測で、その語が指す推定をしていない。→ 実機構の説明に置き換え。あわせて、grade の境界値の docstring に「合成スコア上の暫定ヒューリスティック境界であり、統計的有意水準ではない」と明記（境界の値は変えない）。型③。
6. 送信先の無い同意トグル（PR #529・2026-06-10。#502 の一部も同じ型）
「匿名の利用状況を送る」「診断情報を共有する」「クラッシュレポートを送る」の 3 トグルに、送信の実装が無かった。ON にしても何も送られない。開示ページには「〜へ送信」の文言と、無い監査証跡（sha256・audit trail）の記述。→ トグルを非表示（フラグは温存・既定 OFF 固定）、開示面を実装の実態（送信経路 3 本・トグル 3 つ）に同期、無い証跡の記述を削除、i18n の死にキー 15 × 2 言語を削除。型③。
どう見つけたか
6 件とも、書いた本人は気づいていない。見つけたのは 3 つの読み方でした。
- 別の観点で独立に読ませる（複数の監査を別々に走らせ、指摘を突き合わせる）。#408 は 4 観点の独立監査、#512 は 2 視点、#529 はセキュリティ観点のベンチマーク
- 指摘を file:line で照合する。「補正で対応」の指摘は、補正クラスが本番の経路に無いことをコードで確かめてから採用した
- 表示の語を、実装の語と突き合わせる。「測定品質」と書いてある箇所で、コードが測っているのは何か。「送信」と書いてある箇所に、送信のコードはあるか
1 人でやるなら、少なくとも 3 は自分でできる。画面の名詞と動詞を全部並べて、対応するコードを指させるか。指せないものが盛りです。
手順として
- 出荷前に、画面と LP と開示ページの名詞・動詞・数値を全部書き出す
- 各項目に、対応する実装の場所（file:line）を書く。書けないものが候補
- 候補を「①実装が伴わない表示 ②根拠の無い数値 ③実態にない主張・機能」に分ける
- 直す方向は表示を実装に合わせる。機能を足して表示に合わせるのは別の PR・別の判断
- 直したことを PR 本文に逐語で残す（この記事はその PR 本文から写している）
同じ件を「実績」の形で
問題・制約・調査・再現・原因・対応・検証・結果・やらなかったこと、の 9 項目で書いたものは Sumitsuke の実績詳細 → 出荷前に自分で撤回した「盛り」6 件。
AI の利用について
6 件の実装と説明文の下書きは AI（Claude）が書き、監査の指摘を人が照合して直しました。この記事は AI が下書きし、PR 本文からの転記・製品の式や閾値や価格を出していないことの確認・公開の判断は人間が行いました。製品名は出していません。
受託でも同じ手順で読んでいます
「AI に作らせたアプリの説明文が、本当にそう動くか分からない」——画面の語と実装を突き合わせる点検を、テキストだけで受けています。
▶ Sumitsuke ／ 生成 AI に書かせたコードの点検と修理
この記事は Zenn にも同じ内容を掲載しています。