AI使えば3日でアプリ作れるらしいけど、そのあいだ人間のデザイナーは何やってんだ

以前、こんな記事を書いたことがあります。

忙しい人のための３行要約：

今年、これの最新版みたいなことをやる機会がありました。

地獄のAI漫画制作から3年。
AI技術は恐ろしいまでのスピードで進歩していき、様々なことが変わりました。きっと画像生成の技術も相当進歩したのでしょう。

あのときの苦労はもう、しなくていいんだ…！！
きっと…
きっと……！！！！！！

先日、Goodpatchの15周年サイトがリリースされました。春頃に話題になったClaude Code大号令（通称：CC令）で作られた社員のアプリのいくつかをここで実際に閲覧することができるようになりました。
私が作ったのはこれ👇️

制作にかかった期間は3日間。（3日まるまるやってるわけではないので、あくまで期間です）
その３日間、人間は空を見て暮らせたらよかったのですが、残念ながらしっかり苦しむ羽目になりました。

というより、作っている中で何度も
　「これでいいや」
▶「いや、これじゃだめだ」
という選択肢を選ぶことになった、というのが正しいかも知れません。後者を選ぶ限り、こだわりの実現と引き換えに、制作は終わらない。。。

つまり、「どこで降りるか」という、ちょっとしたチキンレースみたいな制作体験になっていたわけです。これは興味深い変化でした。

この記事では、ひとりのデザイナーが「どこでは降りなかったのか」「どこで、なぜ降りる判断をしたのか」という記録を書いていくことにします。

■まず、作ったものを簡単に紹介

職場での自分のキャラを、勇者や魔法使いといったジョブに当てはめてくれる診断です。全13ジョブ、診断結果はURLでシェアできます。

社内チャットに結果画面を貼ったりして、チームビルディングにラフに使えるお遊びツールとして使えたらいいなというイメージです。

工程はざっくり「仕様設計」「開発」「絵作り」の3つ。
順に振り返っていきます。

■仕様設計編

診断なので当然、診断ロジックを作らなければいけません。
まず浮かんだのは、「こういうめんどくさい計算こそAIが一瞬でやってくれたらいいよね！」という期待です。

実際、一番最初のプロンプトはこんなレベル。

## アプリの概要
6つの質問に4択で答えると、RPGのジョブに診断されるWebアプリ。 
チームビルディングの参考にもなる内容を返す。

## 診断の仕組み
質問への回答の組み合わせでジョブを判定するロジックをJavaScriptで実装する。
AIやAPIは使わない。

## 質問（6問・4択）
（※省略）

## 各ジョブの定義
（※省略）

まず素直にすごいなと思ったのが、このレベルの指示でも一応動くレベルまでは作れます。
しかしこれは「なんか知らんけど、Claudeがそれっぽい挙動にしてくれている」状態です。なぜこの結果になるの？という疑問に答えられる人がこの世にいないプロダクトが爆誕します。

▶「いや、これじゃだめだ」

結局、具体的なロジックは、壁打ちしながら固めていくことになります。

ロジックの土台を作ったら、バランス調整をしていきます。
日本人のMBTI分布を参考に、診断結果のばらつきが不自然な箇所を修正していきます。

AIにセルフチェックもしてもらって、いいバランスになった「らしい」状態が作れました。ですが、まだ

▶「いや、これじゃだめだ」

ですよね。

ここから先は「手触り感チェック」というやつです。
実際に触ってみると以下のような問題が見つかったので、設問を１つずつ振り返って潰していきます。

• 質問文が微妙。優等生的な回答があり「これを選ぶべき」と感じてしまうため、本音で診断しにくい
  　→単純な文言修正なので、人間がリライトする。

• 「こういう属性の人はこういう結果になってほしい」というイメージと、実際に出る結果が食い違っている
  　→これはロジック自体を修正する必要あり。影響範囲をAIと相談しながら作り直していく。

「診断結果って作者個人のバイアスがないほうが正確なんじゃないの？」と思う人もいるかもしれません。が、私はあえて「自分の感覚とズレていないか」をがっつりチェックし、可能な限り修正しました。

なぜかというと私の経験上、「第三者のレビューのほうが正確〝かもしれない〟とき」に、自分の違和感を無視して「この人の言ってることにとりあえず乗っかろう！」という判断をするとロクなことがないからです。笑
絶対にどこかで、「ユーザーの素朴な疑問に制作者が回答できない（〇〇さんが言ったから…の他責になる）」という最悪な形で、作り手の思考停止が露見します。自分が気づくような違和感は、他の誰かも必ず気づくのです。

仮に提案してくれたものが正確なのだとしても、「それがなぜ正確なのか」をオーナーがわかっていないといけない。そして納得できなければ、反論をしなくてはいけません。
これは相手がAIだろうと人間だろうと同じこと。ただの丸投げでなく「信頼による委託」をするために必要なプロセスだと思っています。

ということでバランスには延々といちゃもんを付けましたが、具体的な調整方法の提示と実行についてはAIに自主性を持って（？）やってもらいました。人間はレビューを投げるだけなので、作業としてはシンプルです。
そして最終的に、「各診断結果のペルソナを自分に憑依させて手動でテストする」という力技でデバッグを行い、ようやく

　▶「これがいい」

のラインが見えて、この作業は終了しました。

■開発編

細かい技術的な話はこの記事ではほぼ割愛しますが、前提として、私はどちらかというと上流寄りのデザイナーです。開発に強いわけではなく、優秀なプログラマー・エンジニアの説明力に助けられて生きてきたタイプです。

「この人の言ってることにとりあえず乗っかろう！」という判断をするとロクなことがない という話を前項でしましたが、このフェーズは逆説的にそれを実感します。
Claudeが提案してくれる開発プロセスについて、私自身に「それがいいか」をレビューする力がありません。つまり「とりあえず乗っかる」以外の選択肢がありません。これはまずい。特にセキュリティ周りをミスったり、変なツールをインストールしたりすると大変！

結局、ある程度の学習コストは避けられないと理解しました。

まず簡単にできる方法として、AI自身に死ぬほど丁寧に解説してもらいます。優秀なプログラマー・エンジニアの説明力に助けられて生きてきた私、AIにもやはりその振る舞いを要求することに。

これだけでもだいぶ違います。
AIはすぐ「進めていいですか？」と聞いてきますが、「待って！！中学生でもわかるようにもう一度説明して」と何度でも食いつきました。同僚に聞くのがさすがに憚られるレベルの質問は、ひとまずこの方法で一掃します。

とはいえ、自分が最終判断できないのですから、最終的には「分かる人に聞く」になります。
今回の施策はありがたいことに、最後にエンジニアがレビューしてくれる体制になっていました。そして私は作品の特性上、そもそもセキュリティリスクが低かったのもあり、自力で作った構成で問題なかったとのことで無事着地。

▶「これでいい」
のコマンドを自分以外に頼まざるを得ないケースでした。
こういう場合でも、「判断の意図は理解・納得できている」ことは大事にしました。

■絵作り編（地獄）

今回はAI技術を学ぶ目的もあったので、画像生成もAIでやってみることに。当時激アツだったNano Banana 2を使って、診断結果画面にジョブごとのキャラクターイラストを用意することにしました。

さて、ここでもう一度過去の記事を引用しておきます。

地獄だった作業の一つが、絵柄を揃えてたくさんの差分を出力することです。当時の結論としては「無理。人間が描いたほうが早い」でした。
今回作るキャラクターは全部で13体。当然、「同じ絵柄のアートワークをたくさん作れるのか？」という壁に再びぶつかります。

前回の反省から、「こういう感じの絵が欲しい」と言葉で指示するのがいかに不安定かは身をもって理解していました。そこでまず、「絵柄をぶらさずに10個くらいのキャラクターを生成するにはどういうプロンプトがいいのか」をNano Banana自身に相談しました。

返ってきた提案はこうです。

1. 画風の指定：ここが最重要。全キャラ共通の指示にする

2. 色とライティング：色使いや光の加減を統一する。これも共通

3. キャラクターの要素：ジョブごとの特徴。ここだけキャラごとに変える

この構成に沿って、まず1と2の共通プロンプトを固めます。

AIにポップな絵を頼むと海外コミックっぽいテイストになりやすいのが弱点です。それを安定して回避できる方向性として、今回は「3Dフィギュア風」を採用しました。それに追加で、白背景にカラフルなキャラ・柔らかい影付きですっきり配置されていて…みたいな雰囲気を指定します。

これが1と２にあたる、画風と色表現の指定用プロンプトです。

cute 3D plastic toy style, high-quality detailed miniature figure,
soft and rounded shapes, gloss finish, vibrant and clean color palette,
studio lighting with soft shadows, minimalist white background

次に3、ジョブごとのキャラクター設定。
作りたいジョブを一覧にして送り、まずステレオタイプなイメージで外見の特徴を出してもらいます。これをもとに男女比や要素を調整して、英訳してプロンプト化してもらいました。例えば勇者はこんな感じです。

a classic young man hero, noble and righteous look,
wearing a blue cape and a golden crown,
holding a glowing legendary holy sword

 できあがったプロンプトで試作したのがこちら。

▶「いや、これじゃだめだ」

絵として成り立っていないわけではない。でも思ってた数倍キモい。
日本人好みの独特なデフォルメ感がなく、必要以上の精巧さが絵に残ると、「AIから出しっぱなしの臭い」がしてしまいます。

しかし、このくらいは想定内です。 「もっとかわいくして！！！」と怒ったりはしません。大人なので。
かわいらしくデフォルメするために、質感を「プラスチック」から「粘土」に変更してみます。

粘土に変えたことで、キモめのディテールが物理的に再現できなくなっています。顔のデフォルメ感や頭身が気に入ったので、これをスタイルの基準として量産に入ります。

ここまではまだ順調でした。

6〜7つ目あたりから、別のキャラに出した指示が他のキャラに混ざる現象が起き始めました。「遊び人」を作り終えて「次は盗賊を作りましょう」と言ったら、遊び人と全く同じポーズの盗賊が生成されたり。

困ったのが、一度思った通りの結果が出ないと、そこから「前のものに戻して」がなかなか効かないことです。 70点から80点にするための作業で、40点に戻ってしまう。

私はだんだんイラついてきます。
すると、Nano Bananaが「誠に申し訳ございません」「心からお詫び申し上げます」「私の力不足でした」を繰り返すようになってしまいました。これではパワハラ上司です。

あまりに混乱しているようなので、Nano Bananaが何をしようとしているのかを一旦確認します。 現状把握している指示をプロンプトとして翻訳してもらったところ、最初に私が投げたものの3倍くらいの指示が入ったプロンプトが出てきました。

チャットの流れを汲み取りすぎて、いらない指示が溜まりまくってしまったようです。こうなるともうダメです。
このチャットを脱出して新しいチャットを立て、記憶を失ったNano Bananaくんに引き継いでもらうしかありません。転生先に前世の情報を伝え、行き詰まったキャラクターの生成から再開していきます。

結局、これを5〜6チャットぶんくらい繰り返す羽目になりました。

さらに厄介だったのが、作業を続けるうちにアートスタイルがじんわりズレてきていたことです。

比べると、初期に作ったキャラが「粘土すぎる」のがわかりやすいと思います。

13体もいるのでその差がかなり顕著です。
例えば、7番目に作ったキャラと10番目に作ったキャラの差はそんなに気にならないのですが、1番目に作ったキャラと13番目に作ったキャラとでは大違いになってしまいました。漫画の「1巻と13巻で絵が全然違う現象」みたいなものです。

▶「いや、これじゃだめだ」

漫画であれば読む方にも時間差が発生するのでグラデーションで見てくれますが、１つのプロダクトの中にバラバラな絵柄のものを混在させるわけにはいきません。後半に作ったものの方がよりイメージに近かったので、序盤に作ったキャラはそちらに合わせて作り直しました。

しかし、やはり限界があるとも感じ、諦めどころも見えてきました。

言ってしまえば「Claudeを使って技術に慣れてね」が目的の施策なので、これ以上アートに時間をかけるのはちょっと…となってきます。無限に思える絵の作業に終わりを与えるのは、いつだって「締め切り」という概念です。

7-8割程度満足のいくものができたところでNano Bananaでの作業には
▶「これでいいや」
の判断をすることになりました。

ではこれで終わりかと言うと、そうではありません。
私の根気がもつ範囲で人力レタッチしていきます。頭身、背景色、影のコントラスト、光り物の反射のしかたなど、あまりにも気になる部分には修正を入れました。

リアルな陰影・質感のミニキャラに、↑の杖の宝石の輝きのような、「現実では絶対ありえないファンタジーの光」を入れた絵にしたかったんです。

ここでようやく
▶「これがいい」
のコマンドを選ぶことができ、キャラ生成の作業は完了としました。

ちなみにUIデザインは、普通に人間がFigmaとAdobeで作りました。

当時のClaudeで作るとこんな感じだったからです。笑

　「これでいいや」
　「いや、これじゃだめだ」
▶「貸せ！！！ワシがやる！！！！！」

一般的なWebサービスを使いやすくUIデザインする用途においては、今のClaudeはかなり精度が高いです。が！
「他とは違う楽しいデザインにしたい！」という気持ちがある場合、作画は素直に人間がやって、インタラクションの工夫をAIと相談するのが一番手っ取り早いんじゃないかと思いました。作画作業からシームレスに動きをプレビューできたり、「こんな動きをつけたい」という指示を雑に自然言語で投げられるのが良かったですね。

■ふりかえり

結局、AIチキンレース（？）を振り返ってみると、明確に「降りる」判断をしたところはありませんでした。

100〜120点を目指したのかと言われるとぶっちゃけそこまでの時間はかけられませんでしたが、それはあくまで、締め切り／プロダクトの重要度／クオリティのバランス調整の話。「人に見せられるクオリティラインを超えているか」という自分なりの判断を「これでいいや」でスルーした箇所は無かったと思います。

実はこの作業が終わった後、Claude自身に「どうだった？」とふりかえりをお願いしました。
すると、ロジック調整に死ぬほど時間がかかったことに苦言を呈されつつ、

という、ちょっと良いコメントをくれました。私も全く同意です。
人間の仕事は、「これがいい」を考えること。
そう思います。

実は先日、ReDesignerで「The Designers' Turn 2026」という企画をリリースしまして、そこで私もAIと人間の関わりについてじっくり考える機会がありました。
（ちなみにこのLPのデザインは私！）

「AIが業務プロセスに入ってから、デザインが少し楽しくなくなってきた」
「AIを使うことが偉い、という風潮に少し疲れてしまった」
「AIをうまく使えていないことに少し焦りを感じている」

やっぱり私の周りでも、こういう声は聞こえます。
変化に前向きに食らいつこうと頑張っている人ほど、自分の中に生まれている不安に戸惑っているのかもしれないなと思いました。

自分も当事者であるし、何かアドバイスできるような立場ではないけれど。
実際に業務でAIを活用しているうちに、「自分がやったほうが良いことまでわざわざAIに手放す必要はない」ということについては、少しずつ実感が湧いてきています。

そして、その筆頭が「これがいい」を決めることなんじゃないかと思います。「これがいい」を実現するために人間の手が必要なら、そこは人間がちゃんと技術をふるうべきだと思うのです。
そして、その境界線を自ら引けるのは、デザイナーの特権です。

ただ、実際にAIといっしょにものを作ってみるまで、「どの作業は自分がやったほうがいいのか」がわかりませんでした。しかもこのライン引きは日々更新されており、継続した学習が必要です。

今回の制作プロセスではかなり人間がでしゃばりましたが、このような「こだわり」の時間を捻出するために、AIの使いどころは他でいくらでも見つかるはずです。（超地味ですが、最近の私は、死ぬほどアンカーポイントが多いベクター素材をClaudeに修正して助けてもらったりしました）

人間の手と頭をいつどうやって入れるかの塩梅はまだまだ難しいです。ただ、効率だけでなく、「いいものをつくるために一番いいワークフローはなんなのか」という視点は忘れずにいたいですね。 まだまだたくさん失敗しながら、学んでいきたいと思います。

診断アプリ、よかったら遊んでみてください！

ただしSupabaseが無料版なので、タイミングが悪いとたまに保存に失敗します😇

開発とデザインに力を注いでも、頼るべき外部サービスにかけるお金をケチるといい体験は作れない…という学びも得ることができました。笑

おわり

おしらせ：
Xのアカウントをお仕事用に取り直しました！
デザインの話や発信系のお知らせは今後こちらでやっていこうと思うので、よければフォローよろしくお願いします！