ヒアリングで希望を吸い上げ、3 案の画像で合意し、選んだ画像をそのまま編集可能な LP にする。この製品の約束はそこにあると受け取っています。1 案件を通して見えたのは、部品は揃っているのに、採用した画像を「ゴール」として扱う仕組みが後半に無いことでした。この資料は、既にある部品をゴールに向けて噛み合わせるための提案です。
採用の前と後で、守り方がはっきり変わります。採用まではファイルに記録し、script が遷移を検査し、記入後に画像が変わっていないかまで見る。採用の後は、手順は細かく書かれているのに、成果物の形も合格線も遷移条件も無い。下の表は各ステップを「ゴール (原画) を参照するか」「成果物」「次へ進む条件」の 3 つで見たものです。
| ステップ | ゴール (原画) を参照するか | 成果物 | 次へ進む条件 |
|---|---|---|---|
| 3 案を作るproposals | まだ原画は無い。brief と形式が基準 形式固定を検査 | copy.md / proposal-directions.md / 3 画像 / format-review.json | 各案が目視 pass + sha256 一致 |
| 本人が選ぶadopt | ここで原画が決まる 本人 | proposal-selection.json / selected-reference/ | 案を一意に指す返答 + check |
| 原画を測るdesign-map | 原画を見る。ただし何を記録するかは列挙のみ 散文章の帯・座標・換算係数・目標高さを型で記録 設計図 | design-map.md (自由形式)design-map.json (script が形を検査) | なし 誰も読まない台帳 measured |
| 素材を分けるasset-manifest | 原画を入力にした文字除去が手順にある 散文入力が原画そのものか、出力寸法が同じかを検査 同一性 | asset-manifest.json (operation は自由文)operation を 4 種に固定、解像度の下限 | なし台帳 separated |
| HTML/CSS を組むdelivery | 「原画が優先」と書くが数値は余白表だけ 散文design-map の座標と節 ID を設計図として参照 設計図 | delivery/ (構造は終端で script)変更なし | なし 比較との順序も自由台帳 built |
| 原画と並べて比べるfidelity | 「同じ幅で比較する」のみ。合格線が無い 散文節ごとの高さ比と全体比を数値で。並置画像を証拠に 尺度 | 名前のある成果物なしfidelity.json + 並置画像 | なし台帳 compared 判定は別席 |
| 検収するreview | R1〜R12 は汎用。案件の基準や原画の節と結びつかない 散文 記入の完全性は format-review全節に行、案件基準 ID を参照、差分票の形 基準 ID | review.md (自由形式) / format-review.jsonreview.json | 重大欠陥 0 (自己判定)台帳 reviewed 判定は別席 |
| 納品するaudit_delivery | 構造のみ (節数・CTA・相対参照) | qa/static.json / delivery.zip | passed でのみ ZIP |
見えたこと。 採用で決まった原画は、その直後に sha256 で固定されたきり、納品まで一度も script に読まれない。原画と実装を比べる工程は「やれ」と書かれているが、成果物の名前も合格線も無い。だから作り手 (モデル) は「見た、概ね合っている」以外の結論を出しようがない。
部品はどれも良くできています。噛み合っていないのは「何と何が」の話なので、対にして書きます。
新しい思想を足すのではなく、1 枚の型を工程ごとに回します。「何を参照して、何を測り、どこがずれ、どう直し、直した結果どうなったか」が、工程が進むたびに見えていく形です。型は同じで、参照先と測るものだけが工程ごとに変わります。
許容差内なら次の工程へ。残るなら round を進めて観測へ戻る。2 round 同じずれが残ったら人へ返す。
| 工程 | あるべき (参照先) | 観測するもの | ずれの単位 | 次へ進む条件 |
|---|---|---|---|---|
| 測る | 採用原画 | 章の帯・各要素の座標・素材の出所。推定か実測かを分ける | 節 ID | 全節が隙間なく並び、換算係数と目標高さがある |
| 分ける | 原画 + 設計図 | 各素材の出所 (原画の sha256)・操作の種類・解像度 | 素材 ID | 操作が 4 種のいずれか、文字除去の入力が原画そのもの、解像度が表示幅の 1.5 倍以上 |
| 組む | 設計図 + 原稿 + 素材 | section の id と順序、CTA、相対参照 (現行の静的検査) | 節 ID | 静的検査 passed、節 ID が設計図と一致 |
| 比べる | 採用原画 | 同幅の並置画像、節ごとの高さ比、全体の高さ比 | 節 ID + 比率 | 全節が許容差内 (既定 ±20%、案件で理由付き上書き可)。判定は別席 |
| 検収する | 案件基準 (ID 付き) + 原画 | PC と 360/390/430 の実表示、hero、境界、R1〜R12 | 節 ID × 基準 ID | 全節に行、必須の基準 ID が評価済み、重大欠陥 0。判定は別席 |
この形の利点。 ユーザーから見ると「採用した画像に対して、どの章がどれだけ近づいたか」が round ごとに読める。作り手から見ると「何を見て何を直せば次に進めるか」が毎回同じ形で分かる。作者から見ると、飛ばされた工程は台帳の穴として残るので、再現性の評価 (quality-gate の「継続評価」) に使える。
上位モデルで回す前提では、手順の中身を script で縛ると裁量を奪って品質が落ちます。固めるのは各工程の「終わり」だけ。中身は今の references のまま、モデルの判断に残します。
既存の検査は 1 つも誤動作していません。検査していない区間で起きたことが、検査している区間を素通りしただけです。足す 3 つの入口 (測る・分ける・比べる) のどれか 1 つでも、この案件は止まっていました。
design-map と asset-manifest にテンプレートと検査を付け、比較結果に名前と許容差を与え、採用後の台帳を足す。すべて format_check と selection_state の型の再利用で、references の本文は変えなくてよい。
ヒアリング出力に ID 付きの基準表を加え、散文 4 か所を 1 か所へ寄せる。検収の行がその ID を指す。ここだけヒアリングツール側の変更が要る。
比較と検収の判定を、並置画像と判定表だけを渡す軽い呼び出しに分ける。「一つの担当」の方針に例外を 2 つ設ける形。まず 1 案件で、飛ばしの検出と誤検出の両方を記録する。
順番は 1 → 2 → 3。1 だけでも、初回案件のずれは 3 か所で止まります。2 と 3 は「ユーザーが想定した以上のもの」に近づけるための段で、ゴールに対する距離が round ごとに読めるようになると、直す方向の議論が「好みの微調整」に寄っていきます。それがこの製品が目指している状態だと理解しています。
根拠にした実体: スキル本体 (SKILL.md、references 01〜17、scripts 5 本、release.json)、初回案件フォルダー (制作セット、提案回、選択記録、design-map、asset-manifest、review、format-review、静的検査、同幅比較の実測)、実行ログの集計。製品に無い判断は「提案」と表記しました。ヒアリングツール本体の内部は未確認です。