【2026年】AIコーディングはなぜ失敗するのか？Human-in-the-loopで実装するUI開発とApp Builderの必然性
AIコーディングがUI開発でなぜ失敗しやすいのかを解説し、人間とAIが協働するHuman-in-the-loopの考え方と、App Builderを活用した品質向上の方法を紹介します。
こんにちは、Infragistics ソリューションコンサルタントの田上です。
生成AIやAIエージェントの進化により、ソフトウェア開発は「AIコーディング前提」の時代に入りました。特にUI開発では、プロンプトから画面を生成すること自体は、すでに実用レベルに到達しています。
しかし一方で、実務の現場では次のような問題が繰り返し報告されています。
- AIで画面は簡単に作れるが、最終成果物の品質が安定しない（AIコーディング・スキル）
- 最終調整に時間が掛かっており、結局人手が必要になっている（ヒューマンスキル）
- AIエージェントは、人間の持つ視覚的な品質基準を理解できていない（ヒューマンスキル）
これらは一見すると個別の問題に見えますが、本質的には同一の構造に起因しています。
本記事でいう「AIコーディングの失敗」の定義（スコープ）
本記事では、特に UI開発における「失敗」を次の状態として定義します。
- 見た目の品質が安定しない（余白・揃い・階層・強弱・統一感が毎回ぶれる）
- 局所修正が効かない（1箇所直すと別の箇所が崩れる／全体が再生成される）
- 修正回数（再試行）が増え、納期・工数が読めない
- 保守性が落ち、後工程で手戻りが増える
UI開発は、コードの機能実装よりも UIの見栄え・統一感（人の視覚的判断） に左右されやすいからです。
本記事では、AIコーディングだけではない、デザイン主体の開発プロセスについて整理します。
1. Human-in-the-loopとは何か ― AI前提時代の設計思想
AI活用の文脈において、近年重要視されている概念が Human-in-the-loop（HITL） です。HITLとは、AIの判断や生成プロセスに対して、人間が意図的に関与する設計思想を指します。
従来の発想では、
- AIで自動化する
- 人が手動で対応する
という二項対立で語られることが多くありました。
しかし実際の現場では、
- AIは高速に生成できるが、文脈理解が不完全
- 人間は判断できるが、スピードに限界がある
という特性の違いが存在します。
そのため現実的なアプローチは「AIと人間を組み合わせる“共創型モデル”」になります。
AIに「生成」を任せつつ、人間が「意図」と「品質」を担保する設計にすることで、実務で回る形に落とし込みやすくなります。
2. AIコーディング最大の課題は「プロンプトループ」
AIコーディングの中核は、プロンプトによる指示です。
このプロンプトインターフェースは非常に柔軟である一方、UI開発においては大きな課題を抱えています。
それが、修正が終わらない「プロンプトループ（Prompt Loop）」です。
近年のAIコーディング領域では、このような反復型の修正プロセスは、
- Prompt Loop
- Iterative Prompting（反復型プロンプティング）
として議論されています。
IBMも Iterative Prompting を、
- 「フィードバックループを通じて継続的に出力品質を改善する手法」
と説明しています。
本来、これはAI品質を高めるための有効なアプローチです。
しかしUI開発では、このプロンプトループが “終わりづらい” という構造的特徴があります。
ここから、2つの典型的な原因を整理します。
2-1. 課題①：自然言語と実数値のギャップが大きい
AIコーディングでは、自然言語によってUI修正を指示します。
例えば、
- 「ボタンを少し右へ移動してほしい」
- 「余白をもう少し広げてほしい」
- 「全体をもう少しモダンな印象にしたい」
といった指示です。
人間同士では成立する会話ですが、AIにとっては非常に曖昧です。例えば、
- 「少し」は何pxなのか
- 「やや広く」はどの程度なのか
- 「モダン」とはどのデザイン傾向なのか
が定義されていません。
この結果、
- 出力が毎回変わる
- 修正結果が安定しない
- 再試行の回数が増える
- プロンプトループが長期化する
という問題が発生します。
UIは特に「見た目の微差」が品質に直結するため、自然言語の曖昧さが、そのまま工数とばらつきに変換されやすい領域です。
2-2. 課題②：「部分修正したい」のに、AIは“描き直してしまう”
UI開発では、本来「一部分だけを少し直したい」場面が非常に多くあります。
例えば、
- ボタン位置を少しだけ調整したい
- 余白だけを微修正したい
- フォントサイズだけを変えたい
といったケースです。
人間の開発者の場合は、「必要な箇所だけを局所的に修正すること」ができます。
しかしAIコーディングの場合は、「画面全体を再解釈しながら再生成するケース」があります。
このときに起きるのが、いわゆる
- 直したい箇所は直ったが、別の箇所が崩れる
という現象です。
結果として、UIの品質を安定させるために再試行が増え、プロンプトループがさらに伸びていきます。
（具体例）UIのプロンプトループが“終わらない”典型パターン
ここで、UI開発でよく起きる流れを、あえて短く図式化します。
- プロンプト：「検索ボタンを少し右へ。全体をもう少しモダンに」
- AI出力：ボタンは動いたが、余白やフォント、カード角丸、影などが別の方向に変わる
- 追加プロンプト：「フォントは元に戻して。余白は広げすぎないで」
- AI出力：フォントは戻ったが、別のコンポーネントの行間が変わる／揃いが崩れる
- 再試行：「直したい箇所」より「崩れた箇所」の修正が増え、ループが継続
重要なのは、ここで起きている問題が「AIが賢くない」ではなく、UI品質の確定が“視覚的判断”に依存していることです。
3. なぜHuman-in-the-loop（HITL）が必要になるのか
この問題を解決する鍵が、Human-in-the-loop（HITL）です。HITLとは、AIの生成プロセスに対して、人間が意図的に介在する設計思想を指します。
ポイントは、単に「人が最後に確認する」という話ではありません。
プロセスとして人間が入る前提で設計することです。
言い換えると、「AIに任せきらない」ではなく、
- AIが得意なところ
- 人が得意なところ
を 工程として分離する 発想です。
- 人間が意図的にAIのプロンプトループを終わらせること
- ヒューマンスキルを持って開発プロセスへ介入すること
例えば、
- 人間の視覚的デザイン部分は「App Builder」で直接デザインする
- ページ単位・ユニット単位へ分割し、プロンプトループの粒度を小さくする
- AIは「構造生成」を担当し、人間は「品質調整」を担当する
このように、HITLとは「AIと人間のプロセスを明確に分ける」ための考え方になります。
4. UI開発プロセスには2つの進め方がある
UI開発プロセスは主に、2つの進め方があります。
A. 【CUI】コーディング主体プロセス（AIエージェント）
- まずコード（AIエージェントによる自動生成含む）で実装を進める
- UIデザインの合意（受入基準）が後ろ倒しになり、後工程で調整が発生する
- 微差（余白・揃い・強弱）をプロンプト入力で解消するアプローチ方法になり、プロンプトループ／手戻り（再実装・再生成・再レビュー）が増えて工数が膨らむ
このアプローチは、Character User Interface（文字列ユーザーインターフェース）であり、Copilot、Claude Code、CdexなどAIエージェントを中心に進めるアプローチになります。
B. 【GUI】デザイン主体プロセス（HITL＋App Builder）
- App Builder を上流工程から人間が調整し、UIデザインを見ながら仕様変更・見える化・合意・凍結する
- その確定した基準に沿って、App Builderからコード自動生成（本番コードのアーキテクチャ一式）を出力する
- 下流工程プロセス（AIエージェントによるコード自動生成／実装）へ進む
- 仕様の変更要求がデザイン主体で処理しやすくなり、プロンプトループ／手戻り工数が減少する
このアプローチは、Graphical User Interface（グラフィカルユーザーインターフェース）であり、App BuilderやFigmaなどローコードデザイナーを中心に進めるアプローチになります。
上記のA/Bは、プロジェクト特性（UI比重）や開発現場の体制によって向き不向きがあります。将来的なチームの人数やプロジェクト規模によって、自社にマッチしたアプローチ方法を採用することで、生産性向上や品質向上を期待できます。
5. 視覚的デザインを補う App Builder の必要性
ここまで見てきた通り、UI開発におけるAIコーディングは「生成」そのものは速い一方で、プロンプトループが発生しやすい という弱点があります。
そこで重要になるのが、視覚的に確実なフィードバックが返ってくる環境です。
App Builder は、AIが作ったたたき台を「プロンプトで直す」だけでなく、人間が画面を見ながら直接調整できるため、UI開発のプロンプトループを現実的な長さに抑えられます。
5-1. UI開発の「品質」は言語化しづらい
UI品質の調整は、文章の推敲と違い、次のような“非言語”の要素が大きいです。
- 余白のバランス（詰まって見える／間延びして見える）
- 配置の揃い（数pxのズレ）
- 視線誘導（どこから読ませたいか）
- 強弱（重要ボタンが埋もれていないか）
- 統一感（角丸・影・色・フォントが揃っているか）
これらを自然言語でAIに正確に伝えるのは難しく、結果として
「少し右に」「もう少し広く」「モダンに」 というプロンプトループに入りやすくなります。つまりUI開発では、品質調整を“言語”だけで完結させようとする設計が不利になる場合があります。
5-2. CUIプロンプトではなく“GUI（人の視覚的・感覚的）で調整する”
App Builder の価値は、「AIがUIを作れる」こと以上に、人間が「この品質でOK」を最終判断できるところにあります。
例えば次のような“微調整”は、プロンプトではなくGUIで終わらせた方が確実です。
- ボタンの左右位置を2〜6px調整
- 入力欄とラベルの間隔を整える
- カード内の余白を統一する
- 見出しのサイズ階層を整える
- テーブルの列幅を見やすくする
これらは「言語で伝える」より「目で見て直す」ほうが速く、再現性も高い。
この“終わらせ方”をプロセスに組み込めるのがHITLの強みです。
5-3. AIと人間の役割分担を“工程”として固定できる
HITLを現場で機能させるには、 人とAIの工程の分離 が必要です。
App Builder を前提にすると、例えば次のような分担が現実的になります。
- AI：画面の骨格（レイアウト／コンポーネント配置／主要導線）を高速生成
- 人間：視覚品質（余白／揃い／強弱／統一感）を短時間で確定
- AI：仕上げで必要になった“構造変更”のみを追加生成（局所的に）
この設計にすると、プロンプトループは「無限に回すもの」ではなく、**必要な時だけ回す“限定的な工程”**に変わります。
HITL工程テンプレ（1画面の最小運用）
- Step0：要件をUI要素に分解（入力／表示／状態／遷移）
- Step1：AIで骨格生成（レイアウト・導線・主要コンポーネント）
- Step2：App Builderで視覚品質を確定（余白・揃い・階層・強弱・統一感）
- Step3：構造変更が必要な箇所だけAIへ戻す（局所再生成）
- Step4：受入基準で完了判定（下のチェックリスト）
受入チェックリスト（Definition of Doneの例）
- 余白：一定ルール（例：8px系）で破綻していない
- 揃い：ラベル・入力・ボタンの基準線が揃っている
- 階層：見出しサイズと間隔が一貫している
- 強弱：主要アクションが視線誘導できている
- 統一感：角丸・影・色・フォントが揃っている
- 例外：エラー表示／空状態／ローディング状態が崩れない
5-4. 生成後の“保守しやすさ”まで含めて品質を担保する
さらに重要なのが、App Builder が生成するコードが Infragistics UIライブラリ をベースにできる点です。
単に「見た目がそれっぽいUI」ではなく、
- コンポーネントとしての整合性
- デザインの統一
- アクセシビリティや拡張性の担保
- 将来の保守（変更しやすさ）
まで含めて、品質の下限を上げやすくなります。
結論として、App Builder は
AIコーディング（生成）と、ヒューマンスキル（視覚品質）を接続するHITLの実装基盤
として機能します。
6. 読後のアクション：まずは「1画面」でHITLを検証する
ここまでの話を、明日からの現場で活かすなら、最初から大きくプロセスを変える必要はありません。おすすめは、1画面だけでHITLを再現し、効果を検証することです。
ポイントは「AIコーディングで作る」こと自体ではなく、UIの最終品質を短時間で確定できるかに焦点を当てることです。UI開発のボトルネックは、まさにこの“品質確定”に集中するからです。
App Builder とは（無料トライアルで検証してみよう）
App Builder は、Infragistics が提供するローコード開発プラットフォームです。UIデザインからプロダクションコードの自動生成まで、開発プロセスを一本化します。
特徴としては以下があります。
- デザイン機能の充実：ドラッグ＆ドロップでUI部品を自由にデザインできる
- 4つのフレームワークに対応：React, Angular, Blazor, Web Componentsを選択できる
- コード自動生成機能：プロダクションコードとしてそのままデプロイ可能
- デザイン効率化：デザイン設計（PC/モバイル）の二重管理を防止できる
- 開発効率化：フロントエンドの開発効率70％向上できる
- AI機能の充実：AIにプロンプト指示するとUIデザインを自動生成できる
その中でも、特にコード自動生成は、BtoB案件において大きな優位性をもたらします。従来のプラグインやコード生成ツールでは、静的なHTML/CSSしか出力できなかったり、プロトタイプ用のコードしか生成できなかったりしましたが、App Builder は動的なWebアプリケーションとしての完全なコードセットを出力可能です。
7. App Builder AI を理解して活用する
また、App Builder AIでは、AIプロンプトに文字を入力するだけで、3つの自動生成（①ビュー生成、②画像データ生成、③データソース生成）を備えており、開発スピードを大きく向上することができます。
- プロンプト入力からUIデザインのAI生成
- 画像（ラフスケッチ、既存システムのスクショ）からUIデザインのAI生成
- 部分的なUI部品に対するAI生成
AIと対話しながら、チャットボットアプリのUIデザインを自動生成する
よくある質問
Q. AIがもっと賢くなれば、HITLは不要では？
UI品質の多くは「数px」「揃い」「強弱」など視覚判断に依存します。性能が上がっても、最後の品質確定を“人が調整する仕組み”は依然として必要です。
Q. Figmaでデザインして実装すれば良いのでは？
もちろん有効です。ただし実務では「AI生成→実装→見た目調整→手戻り」が発生しがちです。HITLは AI生成と視覚品質確定を同一工程に接続し、ループを短くする設計です。
Q. 結局、人がやるならAIの価値は？
AIの価値は「コード生成の高速化」です。人がやるのは“最後の品質確定”に限定し、工程を分離することで 速さ（AI）と安定（人）を両立できます。
無料トライアルのご案内
こちらからトライアルへご参加できます。
- 【製品】無料トライアル
https://jp.infragistics.com/free-downloads
無料相談会のご案内
専門コンサルタントが直接ご質問にお答えし、貴社に最適な導入方法をご提案します。
- 【相談】無料相談会
https://jp.infragistics.com/free-consultation
