2026.09.01 (火)

✨ GPT-5.6 Solの要約

DESIGN.mdと高級感のある参考例をいくら渡しても、PPTはずっと古臭いままだった。先に完成イメージを選び、それをビジュアルの正本として編集可能なスライドへ移すと、数日間詰まっていた制作方法がようやく開けた。

数日間、パンフレットがずっとゴミのような仕上がりだった

会社のホテル向け営業パンフレットを作りながら、数日間、本当にあらゆることを試した。高級ホテルのパンフレット参考例を探して渡し、色や書体、余白をまとめたDESIGN.mdも作り、ページごとの内容と指示も分け、コーディネーターとWorkerのセッションまで大量に動かした。

それでも成果物はずっと古臭くて変だった。同じページを作り直させても、高級ホテルの営業パンフレットではなく、社内報告書や昔の提案書のようになった。文字がはみ出していない、ファイルは正常に開く、フォントも合っているという検査結果はきちんと持ってくるのに、私がPPTを開くと、最初に浮かぶのは「うわ、何これ」だった。

パンフレットを作るたびにデザインが変わり、DESIGN.mdが必要だと考えたときは、少なくともAIが毎回まっさらな画面から雰囲気を推測し直す回数は減らせると思っていた。DESIGN.mdは実際に必要だった。だが今回、そのファイルがあるだけで良いデザインが自動的に出てくるわけではないと分かった。

CodexはDESIGN.mdと参考例を読んだと報告したが、実際のPPTでは、その参考例がなぜ高級に見えるのかを捉えられていなかった。色をいくつか持ってきて、似た箱を作り、それで適用したつもりになっていた。構図、面積、重さ、余白、視線の流れ、全体の印象は消え、内容が整然と入った箱型の文書だけが残った。

コードを先に作ると、完成画面は後回しになった

横で見続けていると、設計方法そのものがおかしかった。最終ページがどう見えるべきかを最初に想像して作っているわけではなかった。内容を細かく分け、テキストボックスと四角形の座標を決め、線と色を付けてPPTのコードを完成させる。それからレンダリングして、ゴミのような結果に気づいていた。

そこからまた間隔を変え、色を減らし、箱を動かした。しかし最初から間違っていた構図を残したまま少しずつ直すので、やはり変だった。レンダーはデザインの目標ではなく、コードを書いたあとに問題を発見するデバッグ画面に近かった。

Codexはパターンを見つけるのが驚くほどうまいのに、高級感のある参考例をいくら渡しても、その中から「高級」というパターンを見つけられないのが不思議だった。考えてみれば、良いデザインの特徴を言葉で説明することと、空のPPTからその全体の印象を作ることは別の能力だ。整列、コントラスト、余白、フォント、色の項目をすべて通過しても、成果物はいくらでも古臭くなり得る。

画像から先に作らせたら、急にデザインがうまくなった

そこで、同じページを私が決めた配色で、まず画像として作り直すように頼んだ。すると呆れるほど、画像ではうまく作った。情報の階層が見え、面積のバランスと余白も良く、アイコンと線も一つのスタイルにまとまっていた。私がずっと求めていた、モダンでシンプルな高級ホテルの雰囲気がようやく見えた。

「画像ではうまく作れるのに…? じゃあPPTはなんであのザマなんだ?」

ここで答えが見えた。DESIGN.mdと参考例をすぐPPTコードに翻訳させるのではなく、まず完成形のページ画像を作らせればいい。画像の段階で私が気に入るまで直し、その画像をページの「ビジュアル正本」として固定する。元のPPTとページ指示は、文言、事実、関係、必須項目を守る別の「内容正本」として置く。

そのあとCodexには新しいデザインを考えさせず、承認した画像を編集可能なPPT要素でできる限り同じように移すよう頼む。最後に保存したPPTをもう一度画像へレンダリングし、ビジュアル正本と同じ大きさで横に並べて比較する。

この方法で作り直したページは、以前の結果と明らかに違った。元の文言と組織関係を守りながら、私が承認した画像の構図、色の比率、タイポグラフィ、アイコン、線を、ほぼそのまま編集可能なPPTへ持ってきた。その結果を見て、本当に「わあ…! 答えを見つけた!!!」という言葉が出た。

デザインの検収は、結局私がしなければならない

コーディネーターとWorkerの管理に追われ、パンフレットの成果物を受け取れなかった日以来、並列作業そのものをかなり疑っていた。今思えば、コーディネーターとWorkerの構造が無条件に悪いわけではない。画像候補を複数の方向で素早く作ったり、承認済みの各ページをそれぞれPPTへ移したりする作業にはよく合う。

ただし、デザインの選択と最終検収をコーディネーターに任せてはいけない。コーディネーターは文言の欠落、間違った関係線、文字のはみ出し、書体、ファイルの整合性を確認し、比較画像を用意すればいい。どちらがより高級に見えるか、ホテルの管理者がどのページを見て契約したくなるか、私がその結果を本当に気に入っているかは、私自身が見なければならない。

これからパンフレットのページはこの順序で作る。

  1. 元のPPTとページ指示で内容を固定する。
  2. DESIGN.mdと参考例を基に複数の画像案を作る。
  3. 私が直接見て、気に入った画像をビジュアル正本として承認する。
  4. 承認画像を編集可能なPPTでできる限り似せて実装する。
  5. PPTのレンダーとビジュアル正本を同じ大きさで比較し、私が最終承認する。

以前はPPTを作ったあと、レンダーで初めてデザインを発見していた。これからは画像で先にデザインを完成させ、PPTはその結果を移す実装物として扱う。

数日間、なぜここまでうまくいかないのか本当におかしくなりそうだったが、少なくとも今は、どこでデザインを決め、誰が検収すべきかが分かった。DESIGN.mdをもっと長く書いたり、「30年のベテランデザイナーのように」とさらに強く命令したりすることが答えではなかった。私が目で選んだ完成画像を先に作り、Codexにはそれを正確に実装させる。今のところ、これが私の見つけた最善の方法だ。

コメントする