自作の 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 にも同じ内容を掲載しています。