こんにちは！ラフル・シャーと申します。
ネパール出身のエンジニアで、Media Fusion Co. Ltd.にてMicrosoft 365およびPower Platform（Power Apps/Automate/BI）のビルダー兼シニアフロントエンドエンジニアとして勤務しています。
AI時代におけるフロントエンド開発やユーザー体験の変化に関心を持ち、実務を通じて得た知見や経験をご紹介していきたいと考えています。
「AI時代のフロントエンド開発：開発者・開発プロセス・ユーザー体験はどう変わるのか」シリーズ
▼Part 1：AIで変わるフロントエンド開発チーム
開発者の役割はどう変わるのか第2回：AIは開発者を置き換えるのではなく加速させるもの（本記事）
はじめに
第1回では、AIの登場によってフロントエンド開発者の役割が変わり始めていることを紹介しました。
本記事では、その変化をさらに掘り下げます。
「具体的に何が変わるのか」「発注者やプロジェクト担当者は、何を基準にエンジニアの仕事を見ればよいのか」を整理します。
なぜ「コードが書けること」は差別化にならなくなったのか
生成AIの普及により、画面のたたき台やコードは、誰でも短時間で作成できるようになりました。
そのため、これからのフロントエンド開発では、「コードが書けるかどうか」では差がつかなくなります。
差がつくのは、次の3つを判断する力です。
- 誤操作を防ぐ設計になっているか
- 利用者にとって分かりやすい画面になっているか
- 将来の改修に耐えられる設計になっているか
これらは、これまで「コーダー」に求められていた仕事ではなく、「UI/UXデザイナー」に求められてきた仕事です。
AI時代のフロントエンド開発者には、単にコードを実装するだけでなく、UI/UXデザイナーのように利用者視点で画面を考える力が、これまで以上に求められています。
表1：従来のフロントエンド開発者とAI時代に求められるフロントエンド開発者の比較
| 従来のフロントエンド開発者 | AI時代に求められるフロントエンド開発者 |
| 画面を実装すること | AIが作成した画面を判断・改善すること |
| 早く正確に実装できるかで評価される | 使いやすく、安全で、将来性のある設計ができるかで評価される |
| プログラミング言語・フレームワークの知識 | 利用者視点での画面設計力、業務理解力、AIへの指示・評価力 |
良いエンジニアが持つ3つの設計能力
AI時代のフロントエンド開発者に求められる役割を、実際の画面設計の例で具体的に見ていきます。
① 誤操作を防ぐ設計能力
利用者の操作ミスを防ぐ設計は、業務システムにおいて特に重要です。例えば、次のような配慮が求められます。
- 削除ボタンを目立たせすぎない
- 保存前に確認画面を表示する
- 重要な操作のボタンは色を変えて区別する
- 元に戻す操作を用意する
こうした配慮がないと、誤操作による業務トラブルや問い合わせ対応など、目に見えないコストが発生します。
② 分かりやすい画面設計能力
画面のボタン名や項目名が業務の流れに沿っていないと、利用者は迷い、教育コストや問い合わせが増えます。
表2：画面のボタン名・項目名・エラー表示における悪い例と良い例
| 悪い例 | 良い例 |
| 登録／変更／更新／修正 （どれを押せばよいか分かりにくい） | 新規登録／内容を変更／保存 （操作の目的が明確） |
| 検索／フィルタ／絞り込み が画面ごとに使い分けられている （同じ操作なのに呼び方が違う） | システム全体で用語を統一する （同じ操作は同じ言葉で表現する） |
| 必須項目に印がなく、送信して 初めてエラーで気づく | 必須項目に「必須」ラベルを付け、 入力前から分かるようにする |
| 「エラーが発生しました」など 原因も対処法も分からない表示 | 「メールアドレスの形式が正しく ありません」など具体的な表示 |
| アイコンのみのボタンが並び、 意味を推測させる | アイコンに短い文字ラベルを添え、 迷わせない |
| 入力項目が20個以上、区切りなく 1画面に並んでいる | 「基本情報」「連絡先」のように 項目をグループごとに分ける |
操作の目的が一目で分かる画面は、利用者の教育コストを大きく下げます。
良い画面設計には、ボタン名の付け方以外にも、次のような観点が関わってきます。
- 用語の統一：同じ操作・同じ項目には、画面が変わっても同じ言葉を使う
- 入力項目のグルーピング：関連する項目をまとめ、画面の情報量を一目で把握できるようにする
- エラーメッセージの具体性：「何が」「なぜ」「どうすればよいか」が分かる文言にする
- 視線の流れを意識した配置：利用者が上から下、左から右へ迷わず読み進められる並びにする
- フィードバックの明示：保存・送信・削除などの操作結果を、画面上で分かりやすく伝える
これら一つひとつは小さな配慮ですが、積み重なることで「使いやすいシステム」と「使いにくいシステム」の差になります。
③ 将来の改修を考える設計能力
その場しのぎの設計は、短期的には早く作れても、将来の仕様変更のたびに個別の改修が必要になり、開発コストが積み重なっていきます。
- 電話番号1／電話番号2／電話番号3のように項目を個別に用意するのではなく、「連絡先テーブル」として設計する
- 社員用・学生用・講師用の画面をそれぞれ個別に作るのではなく、「共通画面＋権限制御」で設計する
将来を見据えた設計は、初期の実装スピードでは劣って見えても、中長期的には開発コストと納期の両方を抑えます。
この設計能力は、どのように身につけるのか
3つの設計能力は、プログラミングの知識だけでは身につきません。次の力を、日々の開発を通じて身につけることが重要です。
- 業務理解力（ヒアリング力）：利用者がどのような業務の流れで、何に困っているかを理解する力です。要件書だけを見るのではなく、実際にシステムを利用する担当者へのヒアリングや業務フローの確認を通じて、背景にある目的まで理解することが求められます。
- ユーザー操作をイメージする力：実際に利用者がどのように画面を操作するかを具体的に想像する力です。実際の業務フローを確認し、「利用者が次に何をするか」「どこで迷うか」「操作を間違えた場合に何が起こるか」を考える習慣を身につけることが重要です。
- 設計意図を正確な言葉にする力：設計者の意図を、エンジニアが誤解なく理解できる言葉で伝える力です。目的や条件を具体的に言語化することが重要です。
さらにエンジニアには、これらの内容を正しく理解し、AIへの具体的な指示（プロンプト）に変換する力も求められます。
設計者の意図が曖昧なままでは、AIを使って開発を速めても、使いやすく質の高いシステムにはつながりません。
発注者・プロジェクト担当者が確認しておきたいチェックポイント
AIを活用する開発チームを評価する際は、次のような点を確認するとよいでしょう。
- 誤操作を防ぐ設計になっているか（削除・重要操作への配慮）
- 画面のボタンや項目名は、利用者の業務の流れに沿っているか
- 将来の仕様変更を見据えた設計になっているか（項目の持ち方、画面の共通化）
これらは、AIを使っているかどうかではなく、エンジニアがAIの出力をどう判断しているかを見るためのポイントです。
まとめ
AIによって、画面やコードを「作ること」自体は、誰にでもできるようになりました。
だからこそ、これからのフロントエンド開発者に求められるのは、次の3つを兼ね備えた、UI/UXデザイナー的な視点です。
- 誤操作を防ぐ設計力
- 分かりやすい画面を設計する力
- 将来の改修を見据えて設計する力
AIが効率化するのは「作業のスピード」であり、「設計の質」を決めるのは、これからも人の役割です。
AIによる効率化の目的は、単に開発時間を短縮することではありません。
実装にかかる時間を減らし、その分を設計や品質向上に使うことで、これまで以上に使いやすく、改修しやすいシステムを実現することが重要です。
AI Codingが一般化すれば、「AIを使えること」そのものは差別化になりません。
AIによって生まれた時間を、どれだけ品質向上に使えるか。そこがエンジニアの新しい競争力になります。
参考文献
GitHub Copilot Documentation
https://docs.github.com/en/copilot
OpenAI Documentation
https://platform.openai.com/docs
Anthropic Engineering Blog
https://www.anthropic.com/engineering
Google Cloud Documentation（Gemini Code Assist）
https://cloud.google.com/gemini/docs/codeassist/overview
Microsoft Learn − AI-assisted development
次回予告
次回は Part2：「AIで変わるフロントエンド開発プロセス」 をお届けします。
第1回：プロトタイピングとアイデア検証の高速化
AIを活用した試作づくりと、アイデア検証の新しい進め方を紹介します。
第2回：コンポーネント生成と再利用可能なUIパターン
AI時代の画面部品設計と、効率的なフロントエンド開発について解説します。
