イラストをアートから「アセット」へ：DesignOps 視点で挑む、生成 AI プロンプトの標準化と工程化

はじめに｜なぜ“AI × DesignOps”なのか？

プロダクトが成長すればするほど、ビジュアルアセットの需要は指数関数的に増えていきます。しかし、デザイナーの数は（悲しいことに）指数関数的には増えません。

従来のイラスト制作は個人のスキルに依存しやすく、結果として品質のバラツキや制作スピードが開発ベロシティを阻害する「デザイン負債（Design Debt）」を生み出していました。DesignOps の本質は、デザインを「一点物のマニュアルアート」から「再現可能なシステム」へと昇華させることにあります。

私たちは今回、AI を単なる「便利な魔法の筆」ではなく、一貫性のあるデザインシステムを支える「レンダリングエンジン」として再定義する検証を行いました。

DesignOpsとは？

「DesignOps（デザインオプス）」という言葉、デザイナー以外にはまだ少し耳慣れないかもしれません。

簡単に言うと、DesignOps は「デザイン版の DevOps」です。 属人的になりがちなデザイン業務をプロセスとして整理し、担当者が変わってもチームとして一定の品質をデプロイできる状態を目指す考え方です。

今回の取り組みでは、生成 AI を「クリエイティブな遊び」としてではなく、プロダクトのコードベースの一部のように運用できるかを検証しました。特にエンジニア主体の組織においては、デザインも「ロジックとして扱えるか」が、持続可能な運用の鍵になります。

プロジェクトの背景：Unlimited App で直面した「成長の痛み」

Unlimited App ではこれまで、プロダクトデザイナーがイラストの世界観設計から品質の最終調整まで、いわば「職人のこだわり」をもって一貫して担ってきました。しかし、プロダクトが成長し、機能追加やコンテンツ拡張が加速するなか、必要とされるイラストの量と展開範囲は、私たちの想像を超えるスピードで拡大していきました。
https://kinto-jp.com/unlimited/app/

その過程で、個人の努力だけではカバーしきれない「構造的なボトルネック」が浮き彫りになってきたのです。

• 工数の比例増加：表現を都度最適化する運用では、制作アセット数に比例して工数も積み上がっていく（まさに O(n) の世界です）。
• 再現性の設計難度：クオリティの判断が個人の経験値に依存しやすく、「なぜこれが正解なのか」という基準を仕組みとして残しづらい。
• 属人的なバランス調整：スピードと完成度のトレードオフを、常に個人の「さじ加減」で調整し続けなければならない。

これらは決して個人のスキルの問題ではなく、プロダクトが次のステージへ進むために解決すべき「システム上の課題」でした。

そこで生まれたのが、「イラスト制作を個のスキルに依存する形から、再現性のある設計へとリファクタリングできないか？」という問いです。私たちはこの問いに対し、生成 AI という強力なエンジンを DesignOps のプロセスに組み込むことで、持続可能な制作体制の構築に挑みました。

※ [ ちょこっと技術解説 ]：O(n) とは？

エンジニアがよく使う「計算量」を測る指標です。ここでは「描くイラストの枚数（n）」が増える分だけ、「制作時間」も正直に増えていくという線形の現実を指しています。

つまり、「単なる「魔法」ではなく、10 倍の依頼が来たら 10 倍の工数が必要になる」という、デザイナーにとっては少し切ない、そしてエンジニアにとっては「今すぐ最適化（リファクタリング）したい！」と血が騒ぐ状態のことです。

今回の検証アプローチ｜“AIに寄せる” vs “AIを寄せる”

AI を活用する際、戦略は大きく 2 つに分かれます：

• AI に寄せる（AI-Native Approach） AI が得意な表現（原生スタイル）をそのまま受け入れ、効率を最大化する。「AI っぽさ」を味方につける手法です。
• AI を寄せる（Brand-Centric Approach） 独自のブランドアイデンティティに基づき、AI の出力を厳格に制御する。

Unlimited App はすでに確立された世界観を持つプロダクトです。そのため、前提条件として「AI を寄せる」アプローチを選択しました。これは、プロンプトを単なる命令文ではなく、ブランドの「デザイン・トークン（Design Tokens）」として定義し、AI という不確実な実行環境において「決定論的な出力（Deterministic Output）」を目指す、エンジニアリング的な挑戦でもあります。

イラスト標準化の設計思想とプロンプトアーキテクチャ

「AI なら、プロンプトひとつで何でも描いてくれるのでは？」——そんな期待は、運用フェーズに入った瞬間に崩れ去ります。実用的な DesignOps において、プロンプトは単なる「魔法の呪文」ではありません。明確な設計意図を AI へ伝えるための、厳密な「インターフェース」であるべきです。

標準化プロセスの構築にあたり、筆者は下図のような 7つのステップを策定しました。ビジュアル定義の抽出（Step 1）からリファレンスの整理（Step 4）までは、いわば「視覚的な仕様書（Visual Spec）」を書き上げる、設計の根幹を支えるフェーズです。

Step 1〜4：プロンプトを「エンジニアリング」するための前処理

• Step 1｜ビジュアル定義の抽出（Extracting Visual Tokens） 最初に取り組んだのは、デザインシステムとの整合性チェックです。2.5D の立体感、余白の持たせ方、低コントラストな配色……。これらを言語化する工程は、後に解説する 「Style Tokens（スタイル定数）」 の基盤となります。

• Step 2｜イラスト用途の分類（Defining the Scope） 生成 AI の活用範囲を「クリエイティブな表現」ではなく、「UX を補助するインフォグラフィック」 と定義しました。目的を限定することで、維持すべき「再現性」と、AI に任せるべき「表現幅」の境界線が明確になります。

• Step 3 & 4｜リファレンスの構造解体（Deconstructing References） 大量のリファレンスを収集し、「好き嫌い」という感性ではなく、構図や影の強度といった「Visual Spec（視覚仕様）」として分解・整理しました。「なんとなく似ている」を「仕様通りである」に変えるための、最も泥臭く、かつ重要なリサーチ工程です。

この Step 1〜4 の本質は、「AI に依存しない設計構造を人間側で作る」 ことにあります。

このプロセスで最もエキサイティングであり、かつ重要なのが Step 5 の「プロンプト作成」 です。ここを単なる「作文」にせず、エンジニアリング的に構造化された工程として設計しました。

具体的には、プロンプトを以下の 2 層構造（Layered Architecture） として定義しています：

Part 1：Style Tokens（スタイル定数層）

線画の太さ、立体感、陰影のルール、配色など、プロダクトの DNA を定義します。「何を描くか」に依存しない、再利用可能な Constant（定数）レイヤーです。

Part 2：Content Variables（コンテンツ変数層）

「車」「人物」「スマホを持つ手」など、画面ごとに差し替え可能な Dynamic Variable（動的変数）レイヤーです。

この 「スタイルとコンテンツの解耦（Decoupling）」 こそが、DesignOps 視点での解決策です。これにより、「何を描いても同じトーンで出力される」という、デザイナーにとっての聖杯（Holy Grail）を目指しました。

ツールごとに異なる「Prompt の最適解」

検証を進める中で面白いことが分かりました。AI ツールごとに「プロンプトの癖」が全く違うのです。以前は同一のプロンプトで比較していましたが、現在は「構造（Part 1 / Part 2）は共通、実装（実際の記述）は各ツールに最適化」という方針に切り替えました。 「プロンプトを共有する」のではなく、「プロンプトを設計するインターフェース（ルール）を共有する」。この方が、ツールの進化に柔軟に対応できる持続可能な仕組みになります。

徹底検証：生成 AI 3 社の「性格診断」—— イラスト標準化の最適解を探る

2025年10月時点の Midjourney 検証

まずは、2025年10月に行った Midjourney（V7）での検証結果です。

当時の出力は、視覚的な完成度が非常に高く、一枚絵としての魅力は群を抜いていました。

しかし、標準化という観点では、いくつかの課題が見えてきました。

• 装飾的な要素が多く、情報量がやや過剰
• 構図がダイナミックで、並べた際の統一感が出にくい
• ブランドトーンよりも「生成AIらしさ」が前面に出る傾向

つまり、創造性は高いが、制御性が低い。

この特性はクリエイティブ用途には適していますが、UI内で量産・運用するインフォグラフィック用途には不向きであると判断しました。

ChatGPT / Gemini へのシフト

Midjourney との比較を経て、検証の軸を「表現力」から「再現性」へとシフトしました。

同一のビジュアルリファレンスと構造化プロンプトを用い、ChatGPT および Gemini で出力を比較しました。

この時点で明確になったのは、

• ChatGPT は構図の安定性が高い
• Gemini はクリーンだが、再解釈が入る傾向がある

という違いでした。

最新検証：観点別比較

プロンプトの構造を定義したところで、次なるステップは「どの実行エンジン（AI モデル）が最も安定して仕様通りに動くか」のベンチマークテストです。私たちは、構図・人物・色彩・命令遵守性の 4 つの観点から、プロダクト運用への適性を評価しました。

① 構図の安定性—— UI に馴染むか？

インフォグラフィックにおいて、余白と主体のサイズ感は「UI の整合性」に直結します。

ChatGPT は視点・余白・被写体のバランスが安定しており、複数枚を並べた際の一貫性が高い結果となりました。

一方 Gemini は、微妙な視点変更や背景処理の差異が発生しやすく、量産時の揺らぎがやや大きい傾向が見られました。

② 人物表現の精度—— 意図が伝わるか？

「シートベルトを締める」「スマホを見る」といった具体的な動作の正確さを検証しました。

人物の顔パーツ・視線・身体バランスにおいて、ChatGPT は安定したクオリティを維持しました。

Gemini は柔らかいトーンで描写される一方、表情や骨格の一貫性に若干のばらつきが見られました。

③ 用色とブランド整合性

ChatGPT は指定した色調レンジを忠実に守る傾向が強く、ブランドトーンとの整合性が高い結果となりました。

Gemini は自然なグラデーション処理を行う反面、色相・彩度が微妙に変化するケースがあり、厳密なトーン統制には追加調整が必要でした。

④ 命令遵守性（Instruction Following）—— 仕様書通りに動くか？

最も大きな差はここでした。

ChatGPT はプロンプト構造（Part 1 / Part 2）をほぼそのまま出力に反映する傾向が強く、設計思想と出力結果の対応関係が明確でした。

Gemini は意図を解釈し、最適解を“再構成”する挙動が見られ、創造性は高いものの、決定論的制御はやや難しいという印象です。

※ 正密に Gemini が過度な再解釈を試みるからこそ、私たちは Part 1（定数層）において、より厳密なビジュアルのガードレールを定義し、封鎖（Lockdown）する必要があるのです。

各ツールの本性：創作のパートナーか、信頼の実行エンジンか

Midjourney：気分屋な天才アーティスト

2025 年 10 月時点の検証では、Midjourney は圧倒的な「映え」を誇りました。一枚絵としての完成度は素晴らしいのですが、標準化という観点では少し「個性が強すぎ」ました。

• 情報量が多すぎて UI の邪魔をしてしまう。
• 構図がダイナミックすぎて、並べた時に統一感が出にくい。
• つまり、「クリエイティブな爆発力はあるが、規律を守るのが苦手なタイプ」です。

Gemini：再解釈を試みるクリエイティブ・ディレクター

Gemini 3 Flash などの最新検証では、非常にクリーンな UI イラストを生成してくれますが、時折「自分の色」を出したがる傾向があります。

• 構図や余白が毎回少しずつズレる「自由奔放さ」。
• プロンプトを忠実に守るというより、「意図を汲み取ってリミックスしてしまう」挙動が見られました。これは創作には良いですが、量産プロセスでは「予測可能性」を下げる要因になります。

ChatGPT (DALL-E)：仕様書通りに動くシニアエンジニア

対照的に ChatGPT は、プロンプトの構造をそのまま出力に反映する能力（Instruction Following）が極めて高いことが分かりました。

• 構図が安定し、用色も保守的でルール化しやすい。
• まさに DesignOps における 「信頼できる実行エンジン」 です。
• 「イラストを作る（Make）」ツールではなく、「運用する（Ops）」ツールとしての適性が最も高いと判断し、現在は ChatGPT を中心に検証を進めています。

※ もちろん、表現の幅や偶発的なひらめきという点では、Midjourney や Gemini に軍配が上がる場面もあります。

実装結果：Unlimited App で何が変わったのか？

確立した標準スタイルは、現在 Unlimited App 内の「車種別イラスト」や「レベル選択カード」などで試験的に運用されています。「AI で 8 割のベースを生成し、人間が最後の 2 割を整える」というフローにより、制作スピードと一貫性が（ついに！）両立し始めました。

しかし、この取り組みは Unlimited App という「実験場」だけで完結するものではありません。私たちが構築したプロンプトの 2 層構造は、いわばデザインの「共通プロトコル」です。将来的には、「スタイル定数（Part 1）」というコンフィグを各ブランドの DNA に合わせて差し替えるだけで、社内のあらゆるプロダクトやサービスへこの仕組みを横展開（スケール）させていくことを目見据えています。プロダクトを跨いで「一貫性のあるビジュアルを即座にデプロイできる」状態——これこそが、私たちが目指す真の DesignOps の姿です。

やってみて分かった課題

数ヶ月の検証で分かったのは、プロンプトには「賞味期限（Prompt Rot）」があるということです。ツールのアップデートにより、昨日まで動いていた魔法の言葉が、今日には効かなくなる。

そのため、プロンプトを一度作って終わりにするのではなく、継続的にリファクタリングしていく前提の設計が必要です。今後は、これらのメンテナンスを自動化する「AI Agent 的なアプローチ」も視野に入れています。

まとめ：AI × DesignOps は何を変えうるのか

今回の検証を通じて確信したのは、生成 AI は単なる「魔法」ではなく、DesignOps を再設計するための強力なトリガーであるということです。

標準化とは、自由を奪うことではありません。むしろ、「どこを固定し（Constants）、どこを柔軟にするか（Variables）」を定義することで、変化の激しいプロダクト開発においてクリエイティブな安定走行を可能にする行為です。

DesignOps は、デザインを「属人的な手癖」から「再現可能なプロセス」へと拡張します。この取り組みが、皆さんのプロダクトにおけるクリエイティブ運用のヒントになれば幸いです。