前回は、京都観光のデザインカンプをCodexに渡して、HTMLコーディングを任せてみました。
細かく指示を出さなくても、写真や文章が配置され、アニメーションまで付いたサイトが完成。
元のデザインと違う部分はありましたが、たたき台としては十分に使えそうな仕上がりでした。
ただ、Web制作は初稿を作って終わりではありません。
むしろ、そこから始まるのがクライアントからの修正依頼です。
「写真をもう少し大きくしてください」
「スマホでは重ならないようにしたいです」
「やっぱり、ここに新しいコンテンツを追加できますか？」
ひとつずつなら難しくなくても、まとめて届くと、内容の整理だけでそれなりに時間がかかりますよね。
そこで今回は、前回作った京都観光のデモサイトに対して、架空のクライアントから修正指示が届いた、という設定で検証してみます。
修正指示は、A4のPDFにぎっしり1枚。全部で24項目です。
これをまとめて渡したら、Codexはどこまで対応してくれるのでしょうか。
今回は「作る力」より「直す力」を見てみたい
前回の制作については、JPGのデザインカンプから京都観光サイトを作った記事で紹介しています。
今回はそのサイトを複製して、修正前のページを残した状態で進めました。
見たいのは、色や文章の差し替えだけではありません。既存のデザインを読み取り、情報の順番を変え、必要な機能を追加して、スマホ表示まで整えてくれるのか。
制作現場でいう「初稿のあとの修正対応」に近い実験です。
結果からいうと、今回の24項目はすべて実装されました。ただし、「一発で」という言葉には補足があります。
追加の修正指示をこちらから出さずに任せた、という意味で、Codex自身による表示確認や再調整は含んでいます。最初に書き出したコードが無修正で完成した、という検証ではありません。
修正指示は、あえて種類を混ぜた24項目
修正指示書も、この実験のためにCodexと一緒に作りました。実在のクライアントから届いた資料ではなく、架空の案件を想定したA4・1ページのPDFです。
内容は「背景色を変える」「キャッチコピーを差し替える」といった軽い修正から、カードの詳細開閉、2種類のモデルコースのタブ切り替え、スマホ用メニュー、FAQの追加まで。見た目・情報整理・操作・スマホ対応を混ぜています。
たとえば写真は、PCでは重なりを残しつつ、スマホではメイン写真と小さな写真2枚を重ねずに配置する指定です。「どの画面でも同じように小さくする」だけでは済まない指示も入れました。
なお、PDFの内容を作ったのも修正を依頼したのも、同じチャットです。
Codexはそれまでのやり取りを参照できる状態でした。
初めて見るPDFだけを渡した場合の読み取り精度を、独立して測った実験ではありません。
Codexに渡す指示は、できるだけシンプルに
修正用にコピーしたページのURLを渡し、実際には次のように依頼しました。
ここに前回作ってもらったページをコピーしました。
これを修正して欲しい。さっきのPDFを見て。
こちらから項目ごとに実装方法を説明したり、CSSの書き方を指定したりはしていません。
細かな条件はPDFにまとめ、作業対象だけをはっきり伝える形です。
その後、Codex側でファイルを修正し、PC・タブレット・スマホの表示やボタンの動作を確認。
確認中に見つかったタブレットのコピーの折り返しも、自分で調整していました。
今回、私から追加の内容修正は出していません。
見た目だけで「できた」と判断しない
スクリーンショットがきれいでも、ボタンが動かなければ修正完了とは言えません。
今回の作業では、表示と操作の両方について、Codexがブラウザー上で確認した結果を残しました。
- 画面幅1440px・768px・375pxで表示を確認し、横方向にはみ出していないかをチェック。
- 5つの見どころカードで詳細を開閉。複数のカードを同時に開けることも確認。
- 2種類のモデルコースを切り替え、キーボードでも操作できるかを確認。
- スマホメニューをボタン・背景・Escキー・メニュー内リンクで閉じられるかを確認。
- FAQ3件の開閉と、スマホ下部の案内ボタンの表示・非表示を確認。
確認した範囲では、ブラウザーのコンソールエラーはありませんでした。
一方で、iPhone・Androidの実機、Safari、スクリーンリーダーでの確認までは行っていません。
動きを減らす設定への対応はコードに入っていますが、OS側の設定を切り替えての実動作確認は未実施です。
ここは、実装したことと、検証できたことを分けておきたいところです。
全項目を実装できたからといって、そのまま実案件の納品チェックを省略できるわけではありません。
検証結果：24項目のうち、どこまで反映できた？
修正前後を比べると、元の写真や京都らしい雰囲気を残しながら、ページの目的が整理されているのが分かります。大きな変化をまとめると、次のようになりました。
| 比較するところ | 修正前 | 修正後 |
|---|---|---|
| トップの案内 | 元のコピー・数値情報を配置 | コピーを差し替え、右側を「京都を楽しむ3つのヒント」に変更 |
| メインのボタン | 予約を促す案内 | 「モデルコースを見る」に統一 |
| 見どころカード | 詳細リンクが同じ移動先 | 5つのカードそれぞれで詳細を開閉 |
| モデルコース | 元のコース案内 | 「東山さんぽ」「伏見稲荷・宇治」の2タブに整理 |
| 情報の順番 | アクセス情報を早い位置に配置 | コースの後へ移動し、マナーとFAQも追加 |
| スマホ | 元の写真配置・ナビゲーション | 写真の重なりを解消し、開閉メニューと下部ボタンを整備 |
うまく反映できていたところ
まず、指示の種類が違っていても、まとめて対応できていた点です。配色や余白の変更と、タブ・アコーディオンの追加が、ひと続きの作業として進みました。
「見た目だけ整って、動作は仮のまま」という状態にはなっていません。
モデルコースは、東山エリアを歩くコースと、伏見稲荷から宇治へ向かうコースに分かれました。
切り替えると内容も変わります。
カードの「詳しく見る」も、それぞれの説明をその場で開く形になり、元の同じ場所へ移動するリンクから改善されています。
スマホでは、写真の並べ方が分かりやすい比較ポイントです。
下の画像は、どちらも幅375px・高さ1400pxで撮影しています。
PCの重なった写真の見せ方は残し、スマホでは別の並べ方にする。
こうした画面ごとの条件も反映されました。
下部のモデルコースボタンは、目的のコース部分が見えている間は隠れる仕組みになっています。
人の調整が必要だったところ
今回の実験では、実装を見てから私が「ここを直して」と追加で指示する場面はありませんでした。
ただし、Codex自身は確認中にタブレット表示の折り返しを見つけて修正しています。
人からの追加指示が不要だったことと、途中の調整が一切なかったことは別です。
人が引き続き見るべきなのは、クライアントの好みに合っているか、文章が自然か、写真の見せたい部分が適切に残っているか、といった判断です。
観光案内の正確さやコースの所要時間も、今回は架空の修正指示を反映したものなので、実際の案内として使うなら別途確認が必要です。
また、24項目には表示幅ごとの確認や報告も含めています。
「24個の機能を追加した」という意味ではありません。番号ごとの対応状況も、以下に残しておきます。
24項目の対応一覧を開く
- 配色・書体の整理：対応済み。
- 固定ナビとページ内移動の調整：対応済み。
- モデルコースへのボタンに統一：対応済み。
- スマホメニューの開閉：対応済み。
- キャッチコピーとリードの変更：対応済み。
- 説明文の短縮：対応済み。
- PCとスマホで写真配置を変更：対応済み。
- 過剰な演出を抑えた表示：対応済み。
- 数値情報を3つのヒントに変更：対応済み。
- アクセス情報をコースの後へ移動：対応済み。
- 見どころを5つのカードに整理：対応済み。
- 画像比率と画面幅ごとの列数を調整：対応済み。
- 各カードに詳細の開閉を追加：対応済み。
- 散策マナー3項目を追加：対応済み。
- 楽しみ方を3項目に整理：対応済み。
- 2種類のコースをタブで切り替え：対応済み。
- 東山さんぽのコース内容を反映：対応済み。
- 伏見稲荷・宇治のコース内容を反映：対応済み。
- スマホ下部ボタンとアクセス導線を追加：対応済み。
- FAQ3件を追加：対応済み。
- スマホの文字・行間・余白・操作領域を調整：対応済み。
- 代替テキスト・キーボード操作・動きを減らす設定に対応：実装済み。キーボード操作を確認。スクリーンリーダーとOSの動きを減らす設定での実機確認は未実施。
- タイトル・フッター・不要なページ表示を整理：対応済み。
- 3つの画面幅で確認し、対応結果を記録：対応済み。
修正指示の整理まで含めて任せられると、制作はどう変わる？
今回やってみて感じたのは、修正を1つずつチャットで渡すよりも、対象・変更内容・確認条件をまとめて渡す形が役立つ、ということです。
PDFには、スマホではどうするか、クリックすると何が起きるかまで書きました。
それが実装と確認の基準になっています。
もちろん、指示が曖昧でも必ず意図をくみ取ってくれる、とまでは言えません。
今回は1サイト・1つの指示書での結果です。
別のデザインや複雑なシステムで、同じように進むかは別の検証になります。
また、ご覧に
それでも、変更箇所を探して、コードを直して、画面を見て、動作を確かめるところまで任せられたのは、実務を考えるうえで手応えがありました。
人は修正作業の手数を減らし、そのぶん意図の整理や最終判断に時間を使えそうです。
まとめ
今回は、京都観光のデモサイトにA4・1枚、24項目の架空の修正指示を渡してみました。
結果は、追加の内容修正をこちらから出さずに、全項目の実装まで完了。
PC・タブレット・スマホの表示と、主要な操作も確認できました。
ただし、同じチャットで指示書を作った状態での実験であり、Codex自身による調整も含んでいます。
「PDFさえ渡せば、どんな案件でも完全に仕上がる」とまでは言いませんし、正直デザイナー目線ではもっと直すべき所は沢山あります。
とはいえ、100%完璧な修正ではなくとも、60～70%程度は対応可能だという事が分かりました。
まずは小さな修正案件で、直してほしい内容と完了条件をまとめて渡してみる。
今回の比較を見ると、その試し方には十分に価値がありそうです。
ぜひ下の2つのデモを開いて、見た目だけでなく、カードやコースの切り替えも触って比べてみてください。
READER SIGNALS
コメントを残す
記事を読んだ感想、実際に試した結果、補足情報や疑問点を気軽に共有してください。