--- title: "AIコーディングの前にUI/UXデザイナーを入れるべき理由｜手戻りを減らす開発手順" description: "AIコーディング前にUI/UXデザイナーを入れるべき理由を解説。設計先行で手戻り、不統一なUI、AIハルシネーション、開発コストを減らす方法。" canonical: https://itsupportintokyo.com/ja/blog/hire-ui-ux-designer-before-ai-coding language: ja-JP published: 2026-07-14T17:30:00.000Z modified: 2026-07-14T17:30:00.000Z author: "IT Support in Tokyo Team" keywords: "UI UX デザイン 依頼, AI コーディング, AI 開発 失敗, Webアプリ UI設計, アプリ UX設計, UIデザイナー 東京, AI ハルシネーション, システム開発 要件定義" image: https://itsupportintokyo.com/blog-ui-ux-design-before-ai-coding.png translation: https://itsupportintokyo.com/en/blog/hire-ui-ux-designer-before-ai-coding --- # AIコーディングの前にUI/UXデザイナーを入れるべき理由｜手戻りを減らす開発手順 > AIコーディング前にUI/UXデザイナーを入れるべき理由を解説。設計先行で手戻り、不統一なUI、AIハルシネーション、開発コストを減らす方法。 **結論：**顧客向けのWebアプリ、モバイルアプリ、EC、マーケットプレイス、業務システムを作るなら、AIにUIコードを書かせる前にUI/UXデザイナーを入れる方が、結果的に速く安くなるケースが多いです。デザイナーは「誰が、何を、どの順番で行い、どの状態になれば成功か」を整理します。その承認済みの設計をAIに渡せば、AIは実装を大幅に加速できます。設計がないまま生成すると、見た目はきれいでも課題を解決しない画面ができる可能性があります。 これはAIコーディングを否定する話ではありません。**人間がプロダクトを判断し、AIが実装を加速し、最後まで人間が検証する**。この順番で使う方がAIの強みを活かせる、という話です。 ## AIはビジネスを理解するより速くコードを書く コーディングAIは、ダッシュボード、決済画面、オンボーディング、モバイル画面を短時間で生成できます。構文が正しく、ビルドが通り、スクリーンショットが魅力的に見えることもあります。しかし、それだけでは顧客、業務ルール、ブランド、運用手順に合っているとは言えません。 AIは営業担当者と一緒に顧客の反応を見たり、フォーム離脱の理由を観察したり、サポートの電話を聞いたり、日本の購入担当者がどこで不安になるかを体験したりしません。重要な承認手順や現場ルールを明示しなければ、他のプロダクトでよく見られるパターンを使って空白を埋めます。その推測が便利な時もあれば、自信を持って間違う時もあります。 OpenAIはハルシネーションを「もっともらしいが誤った出力」と説明し、高性能なモデルでも自信のある誤りは残るとしています。UI開発では、ハルシネーションは誤った文章だけではありません。存在しない業務フロー、架空のAPI、間違った権限、実際の運用と合わない操作を作ることも同じ種類の問題です。 ## コードを書く前にUI/UXデザイナーが決めること 良いUI/UXデザイナーの仕事は、色を選んで画面をきれいにするだけではありません。曖昧なアイデアを、関係者が確認・テストできるプロダクト仕様に変えることです。 - **ユーザーの目的：**誰が使い、何を完了したいのか、どこで離脱するのか。 - **情報設計：**どの情報と操作をまとめ、ナビゲーションをどう構成するか。 - **ユーザー導線：**入口から購入、予約、申請、アップロード、問い合わせまでの手順。 - **ワイヤーフレームとプロトタイプ：**開発費が大きくなる前に構造を検証する方法。 - **状態設計：**読み込み中、データなし、エラー、成功、オフライン、入力不備、権限不足、復旧。 - **デザインシステム：**文字、余白、色、コントロール、コンポーネント、レスポンシブ、アクセシビリティ。 - **受け入れ条件：**完成した体験が何を満たすべきかという共通基準。これらが決まると、開発者にもAIにも安定したゴールができます。経営者、プロダクト担当、デザイナー、エンジニアが、予算を本番コードに使う前に同じ成果物を見て議論できます。 ## 「まず手作業でUIを作る」の本当の意味 手作業を優先するとは、すべてのページを人間だけでコーディングし、AIを使わないという意味ではありません。自動化で量産する前に、人間がプロダクトの基準を意図的に作り、承認するという意味です。 まず重要なユーザー導線を設計し、ナビゲーション、レイアウト、主要フォームや業務フロー、レスポンシブ動作、重要な状態を含む「基準となる1つの画面群」を本番品質で作ります。それがAI支援開発の見た目と動作の契約になります。 基準が信頼できれば、AIは関連ページの作成、繰り返しパターンの共通コンポーネント化、テスト追加、レスポンシブ対応、Storybookの下書き、仕様が明確なAPI接続、実装漏れの発見を支援できます。AIにプロダクトを発明させるのではなく、承認されたシステムを拡張させるのです。 ## AIがUIで起こしやすい7つのハルシネーション - **要件を勝手に追加する：**似たサービスにあるという理由で、依頼していない絞り込み、権限、設定、手順を作ります。 - **バックエンドを想像する：**実際には存在しないAPI、項目、決済状態、権限を前提にUIを作ります。 - **例外状態を忘れる：**正常系は完成していても、読み込み、空、エラー、タイムアウト、入力不備、復旧がありません。 - **コンポーネントが不統一になる：**別々のプロンプトで生成したページ間で、ボタン、余白、ダイアログ、文言、ブレークポイントがずれます。 - **アクセシビリティを過信する：**見た目は問題なくても、キーボード順序、フォーカス、コントラスト、タップ領域、ラベル、読み上げ対応が不十分です。 - **もっともらしい誤情報を書く：**会社が承認していない価格、保証、法的表現、機能を生成します。 - **日本語対応を誤る：**直訳で不自然になり、文字がボタンからはみ出し、英語中心の階層のまま重要画面を作ります。これらはコードレビューだけでは気づきにくい問題です。危険なものほど、一見すると自然で、実際の顧客、現場担当者、モバイル端末で使った時に初めて分かります。 ## デザインを先にすると総コストを下げやすい ワイヤーフレームの変更は低コストです。認証、アクセス解析、決済、データベース、複数のレスポンシブ画面につながったコンポーネントの変更は高コストです。デザイン先行は、重要な意見の違いを、まだ安く修正できる段階で見つけます。 プロンプトのやり直しも減ります。基準がないと「もっときれいに」「もっと高級に」「Appleのように」とAIへ何度も依頼し、生成するたびに新しい不整合を直すことになります。デザインシステムがあれば、主観的な依頼を具体的なルールに変えられます。このトークン、このコンポーネント、この状態、このブレークポイント、この承認済み導線、という形です。 Anthropicもコーディングエージェントについて、コードは自動テストで検証できる一方、より広いシステム要件と合っているかを確認するには人間のレビューが重要だと説明しています。デザイナーが承認したプロトタイプと基準UIは、その「広いプロダクト要件」を確認する物差しになります。 ## おすすめの「デザイン先行・AI支援」開発手順 - **ヒアリング：**関係者と代表ユーザーから、事業目標、制約、現場ルールを確認する。 - **導線設計：**主要タスク、判断、権限、失敗時、担当者間の引き継ぎを整理する。 - **ワイヤーフレーム：**見た目を作り込む前に、情報の優先順位と画面遷移を確認する。 - **操作プロトタイプ：**重要な導線をユーザーや現場担当者に試してもらう。 - **デザインシステム：**コンポーネント、トークン、状態、レスポンシブ、日英ルールを決める。 - **基準実装：**1つの主要導線を本番品質で手動実装し、実データに接続する。 - **AIで拡張：**確立したパターンの展開、テスト、ドキュメント、反復実装をAIで加速する。 - **検証：**PC、スマートフォン、アクセシビリティ、実データ、日本語、異常系を自動テストと人間のQAで確認する。NISTのAI Risk Management Frameworkは、人間の役割、対象範囲、テスト、評価、検証を明確にすることを重視しています。AI支援開発でも同じです。どの判断を人間が行い、AIに何を生成させ、公開前にどう確認するかを決めておく必要があります。 ## AIファーストでも問題ないケース すべてのアイデアにデザイナー主導の工程が必要なわけではありません。使い捨てのPoC、1日だけの社内デモ、成熟した既存デザインシステムを使う小さなツール、技術的に可能かだけを確認する実験なら、AIファーストは合理的です。 一方、一般公開する、会社のブランドを背負う、お金や個人情報を扱う、複数の権限がある、日本語と英語が必要、信頼が成果を左右する場合はリスクが上がります。速く作った混乱した試作品が、節約した時間以上の作り直しを生む可能性があります。 ## 日本向け・日英対応プロダクトで特に重要な理由 バイリンガルのプロダクトは、英語UIを作って後から日本語文字列を入れるだけでは完成しません。日本語は情報密度、改行、敬語、フォーム表現、情報の優先順位が異なります。会社情報、安心材料、個人情報の説明、問い合わせ方法、エラー復旧も、日本の顧客には見せ方を変える必要があります。 翻訳表だけではなく、コンポーネント単位で両言語を確認すべきです。ボタンに文字が収まるか、ナビゲーションが分かりやすいか、フォームの文言が自然か、Mobile Safariで動くか、日本語フォントが重すぎないか、タップ領域が十分か、長い住所が崩れないかを確認してから、AIに同じパターンを展開させます。 ## AIにコーディングを依頼する前の確認項目 - 最優先のユーザーは誰で、最も重要な成果は何か。 - 入口から完了までの承認済み導線はあるか。 - 実際のデータ、権限、業務ルールは定義されているか。 - 空、遅延、入力不備、障害、権限なしの時にどう動くか。 - 正しいコンポーネントとデザイントークンはどれか。 - スマートフォン、PC、日本語、英語でどう表示するか。 - 完成を証明する自動テストと人間の確認項目は何か。これらに答えられない場合、プロンプトを長くするだけでは解決しません。必要なのは追加のコードではなく、プロダクト設計です。 ## 作り直しに費用を使う前に、プロダクトを設計しませんか IT Support in Tokyoでは、ユーザー導線の整理、日英ワイヤーフレームとプロトタイプ、実用的なデザインシステム、本番用Next.js・React・iOS・Android実装まで支援します。AIは責任を持って活用し、重要な判断と品質確認は人間が行います。曖昧な試作品が高額な作り直しになる前に、[UI/UX設計・開発のご相談](/ja/contact)をお送りください。 ## 参考資料 - [OpenAI: Why language models hallucinate](https://openai.com/index/why-language-models-hallucinate/) - [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) - [NIST: AI Risk Management and Human-AI Interaction](https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/) - [Apple Human Interface Guidelines: Feedback](https://developer.apple.com/design/human-interface-guidelines/feedback) ## Source Canonical HTML: https://itsupportintokyo.com/ja/blog/hire-ui-ux-designer-before-ai-coding Other language: https://itsupportintokyo.com/en/blog/hire-ui-ux-designer-before-ai-coding