これはWalkersが自社メディア「AI支援.com」のサイドバーバナーを、生成AIを活用して1日で制作した当時の実務記録です。文字のないキービジュアルの生成、レイアウトの試作、コード実装と工程ごとに役割の異なるAIを分担させました。人が担ったのは、途中で止まった作業を別のAIへ引き継ぐ判断や、数字の見せ方を最後に却下する判断でした。本稿ではAIの役割分担、発生した問題と対処、画像上の制約と静的実測値、そして人が判断した境界線を当時の検証条件とともに記録しています。
生成AIで作ったもの
制作対象は「HP Answer」「FDE-NOAH」という2つのサービスのサイドバーバナーです。制作当時、CSSだけで組んでいたバナーカードの視認性や訴求力が十分でないと判断されたことが、ゼロからの制作の起点でした。Walkersでは、AI支援.comの記事執筆の仕組みと同様に、バナー制作でも工程ごとにAIの持ち場を分けて進行しました。
制作した規格は2種類です。PCサイドバー用の縦型バナー（CSS設計基準幅300×400px、高解像度ディスプレイ向けに2倍描画した600×800pxのPNG・WebP）を各サービス1枚ずつ、モバイル表示を想定した横長バナー（基準幅640×213px・アスペクト比約3:1、2倍描画で1280×426px）を各サービス1枚ずつ、合計4枚を出力しました。
掲載場所はサイドバー領域で、当時のレイアウト仕様として画面幅959px以下では横長画像を、960px以上のPC表示では縦型画像をメディアクエリで出し分ける構成をとりました。当初は縦型のみをリンクタグで配置していましたが、横長版の追加に合わせて画面幅に応じた切り替え記述へ更新しています（※現在のメディア掲載状況やレイアウト仕様とは異なる場合があります）。
工程と担当
素材収集からキービジュアルの生成、レイアウトの試作、外部のコーディングAIによる最終制作、修正、本番反映、検証まで、担当を分けながら1日で通した工程は次のとおりです。
| 工程 | 内容 | 担当 |
|---|---|---|
| 起点 | 現行バナーが「CSSだけのカードで貧弱」と評価され、ゼロからの再制作を承認 | 発注側の判断 |
| 素材収集 | ロゴSVG・OG画像・実際の画面など既存素材を収集 | 司令塔のAI |
| キービジュアル生成 | 文字のないキービジュアルを4枚生成 | 画像生成AI（OpenAIの画像生成API） |
| キービジュアルの採否 | 生成した4枚のうち1枚を不採用に指定 | 司令塔のAI |
| レイアウト案 | 1回目は実装を任せたAIが2回、完了しないまま止まった。2回目は別のAIが各サービスA/B案、計4案の候補を生成 | コーディングAI |
| 最終制作への切り替え | 候補の完成度に満足せず、外部のコーディングAIへの切り替えを指示 | 発注側の判断 |
| 最終制作・自己確認 | 既存スクリプトを土台に縦型バナーを全面的に作り直し、生成後は自分で画像を開いて文字切れ・重なり・コントラスト不足がないか確認 | 外部のコーディングAI |
| 修正・横長版の追加 | 数字の見せ方の修正を反映し、スマホ用の横長バナー2枚を追加 | 発注側の承認＋外部のコーディングAI |
| 本番反映・検証 | サイドバーウィジェットを画像に差し替え、PC・スマホそれぞれの実表示とリンク先を確認 | 司令塔のAI |
起きた問題と対処
作業は1日のうちに進みましたが、途中でいくつも問題が起きています。記録に残っている事実をそのまま書きます。
- レイアウト案づくりの1回目で、実装を任せたAIが2回、処理を完了しないまま停止しました。原因の詳細は社内記録に残っていないため中断の事実のみを留保しますが、作業が停滞したため、同一タスクを別のコーディングAIに引き継ぐ判断を行いました。
- 訴求として提案された「専用構築 1:1」という数字強調は、発注側の確認で却下されました。理由の追記はなく表現の見直しとして、「担当エンジニアが業務に入り込み伴走する」「1顧客につき1つの専用環境を用意する」という事実2行と、当時の制作仕様に基づく初期構築費0円の強調、および制度バッジを組み合わせた構成へ差し替えました（※記載の費用や制度表現は制作当時のバナー内表記の記録です）。
- 制作環境のヘッドレスブラウザ（Chromium）がmacOSの権限制限で起動できなかったため、外部コーディングAIは実ブラウザ描画のキャプチャを断念し、Pythonの画像処理ライブラリであるPillowを用いて2倍座標系で静的画像を直接レンダリングする検証方法へ切り替えました。この手法により画像ファイル単体としてのピクセル配置や文字色コントラストを機械的に計算したものの（※コントラスト等の具体的な測定手法は記録上未確認）、ブラウザ上での縮小挙動やタップ操作の同等検証ではない点には留意が必要です。
- スマホ用の横長バナー追加時、CMSの画像遅延読み込み（lazyload）スクリプトが画像タグの画像参照先（src属性）を一時的にdata形式のプレースホルダーへ書き換えていたため、特定のファイル名を参照条件にしていたCSSセレクタ（スタイルを適用する対象要素を指定する構文規則）が一致しなくなりました。原因特定後、セレクタの指定を見直して修正を行いました（※親要素の指定変更など具体的な実装の詳細は未確認です）。
- この検証過程で、以前の「サイドバーはPCでしか表示されない」という認識自体が誤りだったと判明しました。スマホ画面でも本文最下部にサイドバー領域が展開されている事実が分かったため、PCだけでなくモバイル表示も含めて確認する形へ改めています（※確認に用いた具体的な手法や以後の継続運用の詳細は未確認です）。
AIに任せる作業を分けても、こうした「途中で止まる」「思っていたのと違う挙動をする」という失敗が消えるわけではありません。同じような失敗への備え方は、AI活用でつまずきやすい失敗パターンにも整理しています。作業結果をそのまま受け入れず客観的に確かめる基準は、AIの完了報告を信じずに検収するルールに記しています。
AIに渡した制約
バナーの内容や見た目について、AIには次の制約を渡しています。
- 載せてよい事実は各サービスの公式ページに明記されている情報に限定し、未検証の数値・実績・受賞・導入社数は記載しない
- 公的な支援制度の金額・採択条件を断定する表現、効果の保証、旧ブランド名表記を用いない
- 縦型バナー（設計基準幅300×400px）は、基準幅換算で最小文字サイズ11px以上、主要コピー20px以上とし、サービス名は1行に収めて縦400px枠からはみ出さないこと
- 横長バナー（設計基準幅640×213px）は、基準幅換算で最小文字サイズ12px以上（実出力の1280px画像上では24px以上）、主要コピー20px以上とする
- 奥行きのある背景を用い、ロゴ配置と余白を確保すること。外周の角丸は画像データには埋め込まず、Webサイト側のCSSで付与する
- フォント指定は日本語にHiragino Sans、欧文にInterまたはHelvetica Neueを用い、文字欠け・豆腐（文字化け）を発生させない
- 制作スクリプトの作業範囲は指定ディレクトリ内に限定し、git操作は禁止。外部通信はOpenAIの画像生成API呼び出しのみに限定し、描画・レイアウト処理はすべてローカル環境内で完結させる
- キービジュアル生成時は画像内にテキストを一切描画させず、生成枚数は最大4枚までとする
これらの制約のうち、事実の限定や表記ルールは全工程のAIに共通して適用し、サイズ・描画・通信環境に関するルールはコーディングを担当したAIのプロンプトおよびスクリプト実行条件として厳密に設定しました。
検証の数値
検証は、スクリプトから生成された静的画像単体での機械的測定と、サイト反映後の表示確認の2段階で実施しました。以下は生成直後の画像ファイルに対して実測した当時の測定値です。
| 項目 | 縦型（HP Answer） | 縦型（FDE-NOAH） | 横長（HP Answer） | 横長（FDE-NOAH） |
|---|---|---|---|---|
| 出力解像度（2倍描画実寸） | 600×800px | 600×800px | 1280×426px | 1280×426px |
| 画像内バウンディングボックスの重なり・文字切れ | 0件（生成画像内判定） | 0件（生成画像内判定） | 0件（生成画像内判定） | 0件（生成画像内判定） |
| 最小文字サイズ（※測定条件は未確認） | 11px | 11px | 14px | 16px |
| 最小コントラスト比（※算出方法・対象背景は未確認） | 6.2:1 | 5.63:1 | 7.399:1 | 7.152:1 |
| WebPとPNGの展開後ピクセル差分 | 完全一致（※保存設定等は未確認） | 完全一致（※保存設定等は未確認） | 完全一致（※保存設定等は未確認） | 完全一致（※保存設定等は未確認） |
※最小文字サイズ（11〜16px）について、設計基準幅換算値か実画像上のサイズかといった具体的な測定条件は記録上未確認です。最小コントラスト比についても、測定対象とした背景領域の指定や最小値の具体的な算出方法は社内記録上未確認であり、当時の記録値として記載しています。また横長バナーが閲覧端末の画面幅（例: 375px幅のスマートフォン等）に合わせて縮小表示された場合、画面上の絶対文字サイズも比例して小さくなるため、あらゆる実機画面での可読性を恒久的に保証するものではありません。WebPとPNGのピクセル差分についても保存設定などの前提は未確認です。なお本番反映時には、万一のレイアウト崩れに備えてウィジェット設定の退避ファイルを保存したうえで切り替えを行いました。検証では目視の印象だけに頼らず、当時の記録に残る解像度・文字境界・コントラスト比・ピクセル差分の数値指標を機械的に確認しています（※各測定条件の確認範囲には上述の留保を含みます）。
人に残った判断
機械的な検証を通っても、最後に人が決めた部分は残ります。記録に残っている判断のうち、代表的なものは次のとおりです。
- 現行バナーを「貧弱」と評価し、ゼロからの再制作を承認したこと
- レイアウト案の完成度に満足せず、外部のコーディングAIへの切り替えを指示したこと
- 「専用構築 1:1」という数字の見せ方を却下したこと
- スマホ用の横長バナーの追加制作を承認したこと
いずれも、AIの提案をそのまま採用するのではなく、要否や見せ方を人が判断してから先に進めています。
中小企業が生成AIでバナーを作る前に決めること
自社の広告物や素材づくりにAIを使う場合、Walkersの事例から取り出せる手順は次のとおりです。
まず、載せてよい事実と、書いてはいけない表現をあらかじめ言語化しておくことです。バナー制作の指示書には、使ってよい数値と禁止事項を先に列挙してから作業を始めています。次に、文字はAIの生成画像に直接描かせず、レイアウトを組む段階で別途配置することです。文字を画像生成に任せると、後から修正するたびに全体を作り直すことになりやすいためです。
また、途中で処理が止まったときの対応もあらかじめ決めておくと動きやすくなります。今回も、最初に任せたAIが完了しないまま止まった際、原因を追うより先に別のAIへ引き継ぐ判断をしています。最後に、公開前には人が実際の画面を見て、数字の見せ方や表現に問題がないかを確認する工程を残すことです。どのAIを使うかよりも、この確認の順番を先に決めておくことが重要です。
最初からWalkersと同じ規模で仕組みを作る必要はありません。まずは1種類のバナーやサイズから始め、載せてよい事実の一覧と確認の手順だけを先に決めておけば十分です。定型のノーコードツールとAI駆動開発の違いについては、ノーコードとAI駆動開発の比較でも解説しています。
よくある質問
バナーの文字はAIに生成させたのですか
いいえ。画像生成AIが作ったのは文字のないキービジュアルだけで、コピーや価格などの文字はレイアウトを組む段階でコーディングAIが配置しています。
複数のAIを使い分けたのはなぜですか
キービジュアルの生成、レイアウトの試作、最終的な仕上げでは求められる精度が異なるためです。試作段階で完了しなかった作業は、別のAIに引き継いで仕上げています。
AIが作った数字の見せ方は、そのまま採用されたのですか
いいえ。「専用構築 1:1」という数字の見せ方は、発注側の確認で却下されました。代わりに、事実を並べた説明とひとつの数字だけを強調する構成に直しています。
中小企業がバナー制作でAIを使う場合、何に気をつければよいですか
載せてよい事実と禁止事項を先に言語化し、文字サイズやコントラストの下限を数値で決めておくことです。最後は人が実際の画面を見て確認する工程を残してください。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせてAIを組み込む伴走支援については、FDE型AI導入支援で相談を受け付けています。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
