発注も実装もAIだったSTUDIO案件｜なぜ納品後に抜け漏れが見つかったのか

ノーコードツール「STUDIO」でのサイト実装を納品した数日後、お客さんから連絡が届きました。「ここがまだできていません」。

指摘リストを読んで気づいたのは、発注側の仕様書もAIで作られ、こちらの実装もAIで進めていたという事実です。両側にAIが入った現場で、何が抜け落ちたのかを記録しておきます。

AIで書かれた仕様書が届いた

案件はランサーズ経由の外部案件で、コーポレートサイト全11ページをSTUDIOで実装するというものでした。届いた資料の中心は、A4で数十ページ分の「STUDIO実装仕様書」です。

読み始めてすぐ、これは人が手で書いたものではないと分かりました。デザイントークンの章に「style.css 実測」と明記されていたからです。

数値がすべて実測値で並んでいた

仕様書には、たとえばボタンについてこう書かれていました。

完成済みのHTMLプロトタイプが「唯一の正」とされ、Figmaは参考閲覧のみ。デザインから実装を起こすのではなく、コードからコードへ移植する発注でした。

専門用語に必ず注釈が付いていた

もうひとつAIの気配を感じたのは、用語の扱いです。「レスポンシブ＝画面幅に応じてレイアウトが変わる仕組み」「検収＝発注側が完成品を確認して合格を出すこと」といった注釈が、初出のたびに丁寧に添えられていました。

章の頭には「この章だけで、作業の全体像をつかんでいただけます」という案内文まで付いています。読み手に配慮した構成が、全11章で一切崩れませんでした。

こちらの納品も、AIで進めた

実装側もAIです。Claude Code から surf-cli 経由でSTUDIOエディタを機械操作し、Figmaからの取り込みプラグインで下地を作ってから細部を詰めていきました。

特徴的だったのは検証方法です。目視ではなく、ライブプレビュー上でJavaScriptを実行し、getComputedStyle で余白・高さ・枠線を実測して仕様値と突き合わせました。

エディタの数値は信じられなかった

途中で分かったのは、STUDIOエディタのキャンバスには拡大縮小の倍率がかかっているという点です。デザイン幅1320pxを実ビューポート1280pxで表示していると、倍率は約0.909倍になります。

この状態で枠線の太さを測ると、1pxが1pxとして返ってきません。実測はエディタではなくプレビュー側で行う、というのがこの案件で得た一番地味で一番使える発見でした。

結果として、全11ページのボタンの余白は「11px 30px」に、高さは「49px」に揃いました。ピクセル単位では、確かに仕様書どおりでした。

それでも「ここがまだできていません」と言われた

納品後、お客さんは自社側でパスを切り替えて新デザインを公開しました。そして公開後の確認を進めるなかで、修正依頼が届きます。

公開後の確認を進めるなかで、いくつか修正をお願いしたい点がございましたので、まとめてご連絡いたします。（お客さんからの修正依頼メールより・要約）

丁寧な文面でしたが、中身は構造的な指摘でした。1件ずつ振り返ります。

1. 見た目は同じでも、CMSにつながっていなかった

お知らせ一覧とトップページの最新5件が、STUDIOのCMSと連携せず、テキストで直接置かれた状態になっていました。各行のリンク先も、作業用に切っていた存在しないパスを指したままです。

お客さん側で、公開時に404が出ないようリンク設定を一時的に外してくれていました。こちらが気づく前に、お客さんが対処してくれていたわけです。

2. 記事詳細を「通常ページ」で作ってしまった

記事詳細ページを、CMSに紐づく動的ページではなく通常ページとして作っていました。STUDIOの仕様上、通常ページをあとから動的ページへ変換することはできません。

つまり作り直しです。仕様書には「/news/{slug} ＝ CMS動的テンプレート」とはっきり書いてあり、こちらが読み落としたわけでもありません。

「見た目を再現するタスク」として処理した結果、ページの種別という構造の指定だけが落ちました。できあがった画面は、正解とまったく同じ見た目をしていました。

3. 仕様書に無い320pxで、表が見切れた

事業詳細ページの比較表が、右端の列で親要素からはみ出していました。発生したのはタブレット幅768px、スマホ幅390px、そして320pxです。

仕様書の検収基準は「全11ページ×3幅（1280 / 768 / 390）が参照スクリーンショットと一致していること」でした。320pxは、仕様書のどこにも書かれていません。

だからこちらも320pxを確認していません。実機で画面を縮めて最初にそれを見たのは、お客さん本人でした。

4. 作業用の仮パスが、そのまま本番に出た

スマホ用メニューのモーダルページが、下書きフォルダ用に切ったパスのまま公開されていました。動作そのものには問題がありません。

ただ、本番のURLとしては仮のままです。AIは「指定されたパス以外を触らない」というガードは正確に守りますが、「このパスは自分の作業都合で付けた仮の名前だ」という文脈は持ちません。

AIが測ったもの、測らなかったもの

指摘を並べ直すと、境界線がはっきりします。AI実装が完璧に合わせたのは、すべて数値で測れるものでした。

合っていたこと	抜けていたこと
余白・高さ・枠線・角丸	CMSとつながっているか
フォントサイズ・行間	ページの種別（動的か通常か）
配色（完全モノトーン）	リンク先が実在するか
1280 / 768 / 390px の見た目	320pxで収まるか
罫線の階層（黒と#DDD）	公開用のパスに直っているか

右の列に並ぶのは、見た目としては差が出ないものばかりです。

AIは測れるものを完璧にします。ただし「何を測るか」を決めているのは人間です。

発注も納品もAIになると、「間」を見る人がいなくなる

今回の受け渡しを図にすると、AIが3回入っています。発注側が仕様書を生成し、こちらが実装し、こちらがその仕様書どおりに自己検収しました。

問題は、この3つがすべて同じ仕様書を正としていたことです。同じ資料を参照していれば、同じ盲点を共有します。

むしろ基準が精密であるほど、基準の外側を見なくなります。「3幅で一致していれば合格」と書かれていれば、4つ目の幅を疑う理由がなくなるからです。

まとめ：AIに測らせる前に、何を測るかを人が決める

今回の反省を、次の案件で使える形に落とし込みました。次にSTUDIO実装を受けるときは、実装を始める前にこの4項目を別のチェックリストとして切り出します。

発注も納品もAIになるほど、人間の仕事は「作ること」から「何を確認するかを決めること」へ移っていきます。

今回の指摘は、そのことを実案件を通して教えてくれました。次はもう少し早く、自分で気づけるようにしたいと思います。