  |
はてなキーワード:uiとは
ダイヤモンドの↓の記事が盛りすぎでブクマカが釣られまくっているので、ちょっと落ち着けという意味で少し解説する
普通の人が「フリック入力を発明」というフレーズを見たら、どっちを想像する？
普通は1を想像するよね。でも、上の記事の「発明」は2の意味。8割くらいのブクマカはここを勘違いしてコメントしてるように見える
同じ発明家氏の記事でも3ヶ月前の東洋経済のほうは、「フリック入力を発明」という釣りフレーズこそ使っているものの本文を良く読めば発明のキモの部分が2であり1では特許を取れなかったことがそれなりに分かるように書いてある
「フリック入力」を発明しMicrosoftに売却した彼の"逆転"人生。元・売れないミュージシャン兼フリーター、家賃３万のボロアパートでひらめく
https://b.hatena.ne.jp/entry/s/toyokeizai.net/articles/-/889631
もちろん2の意味の発明もスゴイし重要なんだけど、釣りは良くないよね
そもそも世の中のほとんどの技術は様々な発明やアイデアの集合体である。歴史の積み重ねであり、最終形がいきなり湧いて出るわけではない。もちろん「フリック入力」にも歴史の積み重ねがある。それを少し紐解いてみよう（なお、下記の「年」は引用可能な特許や論文が出た時期であり、実際にはそれよりもっと前にソフトウェアがリリースされていたりアイデアがメーリングリストに投稿されていたりすることもある）
ttps://dl.acm.org/doi/10.1145/57167.57182 (論文)
放射状に選択肢を並べるUIのアイデアは1960年代から見られるが、接地点からの移動方向情報を用いた入力手法の祖としてはとりあえずこれを挙げることができるだろう。これは文字入力に特化したものではなく、一般的なメニュー選択のための手法である
ttps://dl.acm.org/doi/10.1145/191666.191761 (論文)
pie menuを文字入力に応用したもの。論文の著者はAppleの人。英語用。広義の『「フリック入力」の元祖』に最も該当するのは、おそらくこれだろう
ttps://rvm.jp/ptt/arc/227/227.html
ttp://www.pitecan.com/presentations/KtaiSympo2004/page65.html
T-cubeを日本語に応用したもの。広義の『日本語版「フリック入力」の元祖』の候補
https://web.archive.org/web/20080925035238/http://www.j-tokkyo.com/2000/G06F/JP2000-112636.shtml (特許)
https://newtonjapan.com/hanabi/
AppleNewton (PDA)用に実装された文字入力技術。「中央が『あ』、上下左右方向が『いうえお』」に対応する見慣れた形のフリック入力がここで登場する。『現在よく見る形の日本語版「フリック入力」の元祖』である。なお、開発者が特許を申請したものの審査を請求しておらず、特許としては成立していない
この頃、Human-Computer Interaction分野でT-cubeやHanabiの発展としての文字入力手法の研究が活発になり、特に国内学会で多くの手法が発表された。情報系の学生の卒論や修論のテーマとして手頃だったからだろう。PDA製品に実装されて広まった例もあり、SHARPZaurus用のHandSKKや、少し時代が下ってATOKのフラワータッチ等もこの系譜である
なお、この頃までの技術は指での入力ではなくペン（スタイラス）による入力を想定したものが主である（iPhoneの登場以前はキーボードレスのモバイル端末といえばPDAやタブレットPCなどスタイラス入力を前提としたデバイスが主流だった）
『スマートフォン上の「フリック入力」の元祖』であり『予測変換機能を備えた「フリック入力」の元祖』である。日本語フリック入力の効率を考える上で予測変換の占めるウェイトは大きく、「実用的なフリック入力」を実現するには予測変換との組み合わせは外せない。2006年にAppleに招聘されてiPhoneのフリック入力機能を開発した増井俊之氏は元々予測変換のPOBox（1998年 - ttps://dl.acm.org/doi/10.1145/274644.274690 ）の開発者として知られる研究者であり、Appleへの招聘もその経験を買われてのものだろう。入力にフリック操作を用いること自体は特筆すべきものではなく、当時の流行を考えれば自然な選択だったと思われる
なお、前述のHanabiの開発者氏がiPhoneのフリック入力を見て
と言っている一方、増井氏はHanabiに対して
知らんがな
と言っている。この分野の研究をしていて知らんことあるか？とも思うが、電話用テンキーの上に五十音かなのフリック入力を実装すると誰が作っても概ねHanabiのような外観になると思われるので、本当に知らなかったとしても齟齬はない
ttps://www.j-platpat.inpit.go.jp/c1801/PU/JP-2008-282380/11/ja (特許)
『画面表示は絶対座標＋移動判定は相対座標で行うことで「フリック入力」の入力効率を向上させる手法の特許』である（詳しい仕組みは上記の東洋経済の記事に書いてある）。ペン先と比べて指先は太いため指によるタッチでは厳密な操作が難しく（fat finger問題）、「実用的なフリック入力」を実現するにはこのような工夫も必須になる。小川氏の凄いところは、スマホの日本語UIをリリースするならどのメーカーも必ず実装するであろうこの工夫を、日本語版iPhoneのリリース直前、Apple社としては引き返せないであろうタイミングで特許申請したところだ。機を見るに敏すぎる。特許庁に2回も拒絶された特許を不服審判で認めさせているところも本人が弁理士だからこそできる強さだと思われる
なお、氏の記事を読むと「フリック入力」自体を氏が考案したように思えてしまうが、ここまでに述べた通りそれは誤りである。「フリック入力に関連する重要な特許の公報に『発明者』として掲載されている」ことは疑いない事実なので「フリック入力の発明者」と称するのはギリギリ誤りではないと言えないこともないが、「フリック入力を発明した」はやはりダメだろう。上述の通りフリック入力自体は90年代に既に登場しており00年代の前半にはタッチスクリーン上のかな入力手法の一角を占めるに至っていたので、iPhoneに実装されたことは不思議でもなんでもなく、
このあたりは荒唐無稽な邪推すぎて、ソフトバンクから名誉棄損で訴えられたら危ないのでは
まとめると、さすがに小川氏の記事はモリモリに盛りすぎである。書籍の宣伝にしても酷すぎる。価値の高い特許を取った発明家であることは事実なのに、なぜこういう胡散臭いムーブをしてしまうのか
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。従来の「あ段→い段→う段→え段→お段」とキーのプッシュを繰り返して表示・入力する方式（トグル入力）に比べ、素早い入力が可能になる。その入力効率の高さから、2010年頃にはキーボード離れが加速している[1]。
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」[2]が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。日本におけるフリック入力は、発明家でシンガーソングライターの小川コータがiPhone上陸以前に考案し2007年から2015年にかけて特許出願した[3]ものであり、取得した権利はマイクロソフトに譲渡された[4]。
ただ、これはおそらく関係者の自作自演等というわけではなく、日本におけるフリック入力関連特許が小川氏のものばかりであることからボランティア編集者が勘違いしてこのような記述にしてしまったのではないか。フリック入力は前述のように地道な技術の差分の積み重ねなので、個々の差分の開発者が「特許」を取ろうという気にならないのは良く分かる。その点でも、自ら弁理士として特許を量産した小川氏の強さが際立っている（が、やはり盛りすぎは良くないと思う）
漫画読めるサイトでもよくあるビューワーより、漫画の１話～最終話まで（※単行本単位にも切り替えられるようにする。表紙とかそういうのは該当話の後につけて、おまけは独立）、右側か左側の話数一覧から、PCなら話の表紙とかのプレビューをマウスカーソルで表示させて、なんならページ数のジャンプもボタン置いておいて全部１キーで出来るとか、それくらいのを、画像縦並びとかにして、こういう感じのを一元管理すれば絶対殺到すると思ってる
１話から最終話まで読みやすい形で、例えばあの話は何話だったか～みたいなのを、いちいち単行本とかごとに切り替えて表示したり、画面から漫画が表示されてるエリアを見失ってまで話数探したりするっていう検索性の悪さだと、単行本をひっくり返して話探してるのと一緒なんだよね
提供して欲しいのは「見たい話を簡単に読みやすく読める」、例えばアニメでああいう話あったけどあれは何話かなとなったときに探す手間を少しでも省けるようにしてあると、絶対読みやすくなるというか
そういう形で一気に読めるようにするっていうのは、単行本だとあり得ない検索性の良さっていうア上位体験、アドバンテージになるんだと思ってる
もう一つ言うと絶版漫画とかみたいに、物理書籍でもう手に入らない漫画をサブスクで読めるようになるかとか、キャラクターブックとかそういうファンは読めるけど電子書籍とかであんまり読めなさそうな話だとか、まとめて読めるかどうかっていうのが大きいと思うわ
---
日本の教育現場では、児童・生徒がスマホ・SNSを利用することでいじめ・犯罪・自傷リスクが増大。
高齢者や中年世代も、スマホOSの変化により操作が困難で、生活に必要な情報アクセスに課題。
端末・OS・アプリが海外企業中心で、国民全体の生活基盤としての安全性・安定性が不十分。
政府アプリ（マイナポータル）の普及により、国民が行政デジタルサービスに依存する状況が増加。
デジタル機器利用がほとんど**「米や野菜の次元」まで多用されていることを鑑み、教育端末・高齢者端末を国産基盤で統一し、安全・安心な情報圏を確立**する必要がある。
---
デジタル機器利用がほとんど「米や野菜の次元」まで多用されていることを鑑みて、OS／端末を国民に広く浸透させ、生活の基礎インフラとして安定供給する。
Google等の海外情報収集・広告モデルに政府が深く依存する状態を是正し、国内企業の技術・サービスを活用する。
LINE等国内企業製アプリのUI・UXを参考に、教育・高齢者向け端末の基本操作形態に転用。
マイナポータルと教育ポータルを連携させ、市役所・役場などの行政サービスへ安全にアクセスできる統一窓口を実現する。
いじめの「撮影→SNS拡散」を技術的に抑止し、第二次性徴期における心理的打撃を未然に検知・介入できる体制を作る。
中年・高齢者が既に慣れた操作感（ケータイ的操作）と、子どもの学習ニーズの双方を満たすUI/UXを提供する。
ネット遮断下でも安否確認・避難情報が機能する極小OSモードを整備し、国家レベルの迅速な対応を可能にする。
NECやLINE、国内スタートアップを連携させ、端末・OS・アプリの内製化・雇用創出を促進する。
情報利用の透明性（誰がいつ見たかの監査ログ）と、プライバシー・人権を尊重する利用ルールを制度的に確立する。
---
操作方法は「トーク画面・アイコン・通知方式」を教育・高齢者向けに最適化
3-2.ターゲット端末
---
LINE等国内製アプリUIを基本形として、教育・高齢者端末の操作性を最適化
TRON派生極小OS（Life-TRON）に移植する際もUI/UXの操作感を維持
互換レイヤーを用いて、Androidアプリも政府OS上で動作可能
4-2. サブフェーズ
OS設計・仕様確定政府OS基盤設計TRON系極小OSに国内UIを組み込み、教育・高齢者端末向け軽量UI・操作性を設計IPA、TRON協会、NEC、LINE
移行用互換レイヤー開発Androidアプリ継続利用 現行学習・連絡帳・SNSアプリを互換環境で動作。API/ID連携を政府OS標準に統合スタートアップ、NEC
教育端末・高齢者端末実証 実運用テストUI操作性、災害モード、ログ管理を確認教育委員会・自治体
ポータル・アプリ移行データ統合教育ポータル・学習アプリ・SNS・行政サービスを政府OSネイティブ化IPA、NEC、LINE、スタートアップ
全国展開・定着 完全移行Android端末は段階的にフェーズアウト。全国学校・高齢者施設で展開文科省・総務省・自治体
4. 段階的にネイティブ化・全国展開
---
5. 実行体制
大手企業（NEC・LINE）：端末製造・クラウド提供・UI転用
---
6. 次のステップ
/* 400 (Regular) */@font-face { font-family: "SiteSans"; /* ページで使う一意の名前 */ font-style:normal; font-weight: 400; font-display:swap;src: /* まず Noto のローカル名を列挙（見つかればそれを優先）*/ local("Noto SansJP"), local("NotoSansJP"), local("Noto Sans"), local("NotoSans"), /* 次にApple のヒラギノ系ローカル名を列挙（Mac/iPhone にあることが多い）*/ local("Hiragino Kaku Gothic ProN"), local("Hiragino Kaku Gothic Pro"), local("ヒラギノ角ゴ ProN"), local("ヒラギノ角ゴ Pro"), /*最後にサーバー上の woff2（フォールバック） */url("/fonts/NotoSansJP-Regular.woff2") format("woff2");}/* 700 (Bold) */@font-face { font-family: "SiteSans"; font-style:normal; font-weight: 700; font-display:swap;src: /* Noto Bold のローカル名 */ local("Noto SansJP Bold"), local("NotoSansJP-Bold"), local("Noto Sans Bold"), local("NotoSans-Bold"), /*ヒラギノ Bold のローカル名（Macに存在する場合）*/ local("Hiragino Kaku Gothic ProN W6"), local("Hiragino Kaku Gothic Pro W6"), local("ヒラギノ角ゴ ProN W6"), local("ヒラギノ角ゴ Pro W6"), /*サーバーフォールバック（woff2） */url("/fonts/NotoSansJP-Bold.woff2") format("woff2");}使用例html,body { font-family: "SiteSans", system-ui, -apple-system, "Hiragino Kaku Gothic ProN", "メイリオ", "Yu Gothic", "YuGothic", "YuGothicUI", "Noto SansJP", sans-serif; font-weight: 400;}ふといならstrong{font-weight: 700;}
→ Noto ローカルで軽くて綺麗
▼ 古いWindows / ほか
→Webフォントで補完。もはや必要あるのか？游ゴだかメイリオでいいのかも
KVはともかく、本文とか見出し、これ良くないですか？
複雑なものをシンプルにする能力は、日本のWebサービス、特にインターフェイス設計（APIとUIの両方）において、しばしば課題として指摘される点だと思います。
ユーザー体験（UX）を損なう「使いにくさ」は、単なる実装力の問題ではなく、設計思想と要件定義の段階で、いかに「シンプルさ」を優先できるかにかかっています。
ご指摘の証券会社の例のように、ユーザーのニーズや行動よりも、企業の内部的な都合（例：部門間の連携、既存システムとの兼ね合い、法的な制約の過剰な解釈）が優先され、インターフェイスにそのまま反映されてしまうことがあります。
「銀行口座の同時開設」：これは、サービス提供側の都合で「ついでに登録させてしまおう」という発想、あるいは内部的なプロセスをユーザーに押し付けている典型例かもしれません。ユーザーにとっての最適な体験は、「必要な時に、必要なものだけを、わかりやすい手順で」提供されることです。
国産SNSの例で言われているWeb版実装の難しさは、まさにAPIインターフェイス設計の破綻を示唆している可能性が高いです。
これは、内部のシステムがモノリシック（巨大で密結合な一つの塊）になっており、データやロジックが明確なインターフェイス（API）を介して提供されていないことを意味します。
本来、アプリ版とWeb版は、同じバックエンドロジックとデータに共通のAPIを通じてアクセスするべきです。
それができないということは、アプリ版の実装がアドホック（場当たり的）で、APIではなく内部の構造に深く依存してしまっている証拠かもしれません。
「複雑なごちゃごちゃしたものを作れる能力」はあるという評価は、「機能の足し算」に長けている開発文化を指しているのかもしれません。
新しい要件やリクエストがあるたびに、既存のシステムに「機能を付け加える」ことには長けているが、「本質的でないものを削ぎ落とす」「複雑なものを抽象化して整理する」という「引き算」や「構造化」のスキルが欠けている。
「シンプルさ」とは、単に機能が少ないことではなく、「複雑な内部構造をユーザーから隠蔽し、必要な情報だけを整理して見せる」という高度な抽象化の成果です。
ご意見の通り、日本のWeb系で求められているのは、「複雑なものを実装する能力」のさらに上にある、「複雑なものをシンプルに設計し直す能力」、すなわち「本質を見抜く力」と「構造化・抽象化の思考」なのかもしれません。
いや、まずさ、某証券会社のインターフェイス。使いにくすぎるんだよね
なんで登録時に証券口座だけじゃなく、銀行口座を同時に2つも作らされるのかよくわからないし (オプトアウトするもんなのかもわからんし)
んで、某国産SNS。普通、RESTでも何でも良いけど、APIインターフェイスがはっきりしてたらアプリ版のあとにWeb版を実装するなんてのは簡単な話なのよ
要するに、インターフェイス(APIもUIも含む)の設計がクソなんだよね
複雑なごちゃごちゃしたものを作れる能力があるから、自頭は良いし実装力はあるんだろう
環境：2006年式国産中古ガソリン直4ターボ270馬力＋ディスプレイオーディオ＋AppleCarPlay
試してみたのはYahoo!カーナビ、TOYOTAモビリンク。
先に結論。近所の慣れてる道を走るだけなら大同小異。どれ使ってもたいして変わらん。
まずUI。CarPlay 側の制約とかレギュレーションがあるのか何か知らんが、びっくりするほどUIやアイコンデザインが似ている。ドライブの途中で別のアプリに切り替えても、助手席に座ってる人は（注意深い人や詳しい系の人でなければ）気づかないだろう。なのでアプリの乗り換えはかんたんだと思う。
目的地検索はGoogle Maps が圧倒的に賢い。チェーン系のショッピングセンターをチェーン名だけで検索するとGoogle Maps は現在地から一番近い支店がちゃんとヒットしたが、ほかのはとんでもない遠距離にある支店しか出てこなかった。
曲がるタイミングの案内は、Yahoo!カーナビ、TOYOTAモビリンクはとても適正でゆとりを持って右左折の準備ができた。Google Maps は気持～ち遅い気がする（けど、使ってるうちに慣れて無意識に引き算するようになる）。
これ以上のことはもっと長距離で様々な条件下を走ってみないと何とも言えない。高速道路のちょっと複雑なジャンクションとかで差がつくかな。Google Maps はネズミ捕り情報や事故処理情報がけっこうリアルタイムで共有されてくるのでそういうところも実力の差が出る部分かもしれない。
ただ、自分はこのままGoogle Maps を使い続けると思う。Yahoo!カーナビ もTOYOTAモビリンク も、CarPlay の操作パネル上から「音声案内のON/OFF」を切り替えられないという私にとっては致命的な短所があったからだ。音量やON/OFFを切り替えるにはスマホ側を操作する必要がある（たぶん）。Google Maps はというと常時パネル上にスピーカーアイコンがあって、押せば音声案内は黙る。多くの人にとってはたいして重要な条件ではないかもしれないけどね。
ポケモンは、もはや「不敗」ではない。
いや——勝っているように見えるだけだ。
1990年代に築かれた“神話”を、令和の今も延命し続ける。その姿は、まるで第二次大戦前のフランスが築いた「マジノ線」のようだ。
しかしドイツは、誰もが「通れない」と信じた森を抜け、フランスを電撃的に制圧した。
ポケモンもまた、「かつての勝利」を再利用することでしか戦えない。
「捕まえる・育てる・戦わせる」——それ以外の発想を、20年以上も拒絶してきた。
それでもファンは買う。任天堂は笑う。だが、その笑顔の下には確実に「亀裂」が走っている。
■“安定”という名の退廃
マジノ線の地下で兵士たちは、ワインを飲み、快適なベッドで眠ったという。
ポケモンも同じだ。
ぬるま湯のブランド戦略の中で、彼らは自己満足の夢を見ている。
AIもメタバースも創発的プレイも——全部「関係ない」と言わんばかりだ。
だが、それこそが滅びのサインだ。
ポケモンはもはや攻めない。
その姿は、もはや「戦う」でも「進化する」でもなく、
Switch世代の子どもたちは、TikTokで笑い、原神で世界を旅し、フォートナイトで創造する。
その自由な風の前に、ポケモンの世界はもはや「息苦しい箱庭」だ。
なぜか？ 戦争の“形”が変わったのに、心が変われなかったからだ。
いつかふと、誰もポケモンを語らなくなる日が来る。
それは炎上でも、批判でもなく——ただの「無関心」という名の死だ。
そして殻の中で、静かに朽ちていく。
だが、その向こうに未来はなかった。
最近、SNS上では「BLは性的消費なのにフェミは男性の性的表現を叩くのはダブスタじゃないか？」というスレッドがトレンド入りしていた。
だがこの議論、よく見るとアーキテクチャの層が違う。つまり、話しているプロトコルが合っていない。
オタク文化圏では、「女性が描くBL」と「男性が描く女性向け性表現」を同一のAPIとして扱う傾向がある。
しかし実際には、両者は別レイヤーで動いているアプリケーションだ。
フェミニズムの文脈で語られる「性的表象の問題」は、主に「社会的リソースの不均衡」や「ジェンダー権力の構造」についての議論であって、単なる「表現内容」の良し悪しを審査しているわけではない。
つまり、BLを「性的に描いてるからフェミ的にアウト」と言うのは、仕様書を読まずにバグ報告を出すようなものなのだ。
歴史的に男性中心に最適化されてきた社会システムに、女性視点のパッチをあてて再コンパイルする運動と言える。
だから、「男性と女性を同じように扱うべき」という一般論をそのまま適用しようとすると、互換性エラーが出る。
たとえば「女性の性的表象は抑制されるべきだが、BLはOK」とされるのは、「権力構造上の対称性が存在しない」という前提で最適化されているからだ。
一方、「普通の女性はフェミと違う」「まともな女はそんな主張しない」という定番フレーズが出てくる。
だがそれは多くの場合、ユーザーの気分を和らげるためのUX的演出にすぎない。
実際、ほとんどの人間は制度的優遇（レディースデー、女性専用車両、離婚時の親権バイアスなど）という「プリインストールされた特権OS」の上で動いている。
たとえ本人が「私はフェミじゃない」と言っても、使っているAPIがすでにフェミ思想ベースで動作しているのだ。
つまり、「私は違う」という自己申告は、ただのUIレイヤー上の装飾にすぎない。
平等を掲げるなら、優遇措置をアンインストールする覚悟が必要になる。
だが現実には、多くの人が「平等という概念を口では支持しつつ、既得権のキャッシュを維持」している。
これはエンジニアリング的に言えば、「レガシーコードをリファクタリングすると言いながら結局コメントアウトで誤魔化している状態」だ。
男女平等を“動作保証付き”で実装しようとするなら、既存の社会制度をルート権限で書き換える必要がある。
だが、ほとんどの人はroot権限を持つどころか、ユーザーレベルの設定すらいじる気がない。
もっと根本的に言えば、日本社会の多くの仕組みは、女性優遇をデフォルト設定としてビルドされている。
その構造はあまりにも自然化されていて、誰もコードレビューをしようとしない。
アンチフェミを自称する男性すら、「女性は守るべき対象」という社会的テンプレートを内面化していることが多く、それが構造の永続化を促している。
結果として、「BLは性的消費」「フェミはダブスタ」という批判は、異なるフレームワーク間の非互換問題にすぎない。
BLは「個人の妄想の自由」をレンダリングするローカルアプリだが、フェミニズムは「社会構造の更新」を目指すサーバーサイドのシステム。
同じメソッド名を呼んでいるように見えても、実行される関数の意味がまったく違う。
つまり、「BL＝性的消費」「フェミ＝ダブスタ」という批判構造は、コードのバージョンが違うままマージしようとしている状態に近い。
根本的にAPI設計思想が違うのだから、いくら議論を積み重ねても互換性は取れない。
必要なのは、「どの層で話しているのか」「どの権力構造を前提にしているのか」を明示することだ。
これは半分は正しくて半分は間違ってる。
チャットボットが最強のUIになる、という話は、ChatGPTができるよりずっと前から言われてきている事ではある。
曰く、いくら使いやすいGUIを作った所で、操作法を全く覚えようとせず人に頼んでやらせようとする人も、チャットボット型UIなら自分でできるようになる、と。
ただ、人には向き不向きがあって、会話が得意な人、会話ならできるという人も相当数いるけど、会話が苦手で、でもコンピュータの操作ならできるという人だって、それなりの数いるわけで。
はてななんかだとよく、「動画でやり方説明されるなら文書で読みたい（その方が早い）」という不満が良く見られるけども、動画で説明された方がわかりやすい人も、文書で説明してもらった方がわかりやすい人も、それぞれいるという話。
それと同じことがUIにも言えて、チャットボット型のUIは、従来コンピュータを使ってこなかった、もしくは人にやらせていた人向けのUIというだけで、そちらの方がボリュームゾーンとしては大きいから、より商売にはなるだろうけど、これまで普通にコンピュータを使えていて、チャットボット型UIに、わざわざやりたい事を言語化して伝えるのは面倒だという人も相当数残る筈で、そういう人向けに従来型のUIを作る仕事も残り続けるのよね。
（ただ、動画と文書の関係と同様、ボリュームゾーンが多い方がニーズが大きいので、少ない側がないがしろにされがちではあるのだけども。）
増田の投稿をChatGPTに聞いたら、次のような答えが返ってきたよ。
----------
この投稿はインパクト重視の論調で書かれていますが、内容にはかなりの誇張と誤解が混ざっています。
確かに「Apps in ChatGPT」のような機能は、ユーザー体験の一部を「チャットUI」に統合する可能性を持っています。しかし、それが「フロントエンドエンジニア＝不要」という結論にはなりません。
人間が情報に触れるには、必ず何らかの「インターフェース」が必要です。AIが自動生成しようが、それを心地よく見せ、操作しやすくするための設計原理（アクセシビリティ、情報設計、心理的デザイン）は残ります。AIがHTMLを生成するようになっても、「どのような体験を提供すべきか」を定義するのは依然として人間です。
次に、Apps in ChatGPT＝Webの終焉という見方も現実的ではありません。
これは「一部のユーザー行動の置き換え」にすぎません。人々がすべての行動をチャット上で完結させたいとは限らず、ビジュアル的な体験（ゲーム、ECのUI、SNS、動画編集、ダッシュボード操作など）は、テキストUIよりも視覚的UIの方が圧倒的に優れています。Spotifyの例にしても、ChatGPT上で曲を探すことはできても、音楽体験そのものはSpotifyアプリ内のインターフェースで完結したほうが豊かです。
さらに言えば、「AIがUIを描く」時代は「フロントエンドの再定義」の時代です。
Reactコンポーネントを手書きする仕事は減るかもしれませんが、「AIに指示してUIを生成し、それを調整する」役割は残ります。人がHTMLを書かなくても、ユーザー体験を設計する力・AIが生成したUIを検証する力・アクセシビリティやブランド整合性を担保する力が求められるようになります。
一方で、この投稿が指摘している**「構造を設計できる人の重要性」**は確かに的を射ています。
API設計、データスキーマ、セキュリティ、AIと連携するバックエンド構造への理解はますます価値を増します。UIの自動生成が進むほど、裏側の整合性・信頼性を支えるエンジニアリングが中心的になるのは確かです。
要するに、フロントエンドは「消滅」ではなく「変質」していく段階に入っています。コードを書く職種から、AIを使って体験を設計・制御する職種に移行していくというのが、現実的な見立てです。
この一言に尽きる。
ChatGPTの新機能「Apps in ChatGPT」が登場した瞬間、フロントエンドという職種の地盤は音を立てて崩れた。
これまでは、Webアプリやサービスは「フロントエンドでUIを作り、バックエンドでデータを返す」
という分業構造の上に成り立っていた。
だがApps in ChatGPTは、その構造をぶち壊す。
ChatGPTのチャット画面内でSpotifyを操作し、Zillowで物件を探しEtsyで買い物をする。
あなたが書いてきたReactコンポーネントもボタンもフォームもすべてAIに吸収される。
もはやユーザーはブラウザを必要としない。URLをコピペすることも無くなるだろう。
「このホテル予約して」と言うだけでAIがAPIを呼び、レスポンスをカルーセル形式で提示する。
ReactもNext.jsも「人間が画面を操作する前提」で存在していた。
でもその前提はもう終わった。
AIがデータを直接受け取り、AI自身が人間に見せるUIを自動生成する。
あなたが設計した美しいフォームもAIにとってはただの "action": "submit" という構造情報にすぎない。
Apps in ChatGPT以降の世界では、
これらが新しいUIだ。
だからこれから必要なのは「見た目を作る人」ではなく、AIが読み取れる形式で世界を記述できる人 だ。
バックエンドに戻れ。
Apps in ChatGPTが意味するのは、
今後必要なのは、AIが扱いやすいデータスキーマを定義する力や認証・権限・トランザクションを安全に扱う力やMCPやWebAPIをAIが使いやすい形に整える力だ。
これは警告だ。猶予は短い。
Apps in ChatGPTの登場は、「AIがUIを直接扱い始めた」という歴史的転換点だ。
あなたがフロントにしがみつく間に、AIはすでにあなたの代わりにUIを描いている。
5年後にはブラウザから色んなサイトにアクセスするという行為は一部のマニアだけ行うものになっているだろう。
もう時間はないぞ。急げ
Permalink |記事への反応(17) | 09:37
アメリカMicrosoftでXboxシニアプロダクトマネージャーリードを務めるドミニク・ゴードン氏は「ボトムアップでゼロからハードウェアとソフトウェアを考え直した」と5年に及ぶ共同開発を振り返る。
まず「Xboxフルスクリーンエクスペリエンス」により、電源投入後にXboxコンソール風UIが即座に起動する。ゲームに不要なWindowsプロセスを停止して約2GBのメモリを削減。専用Xboxボタンから画面録画やチャットにワンタッチでアクセスでき、長押しすれば起動中のアプリを瞬時に切り替えられる。
外部ストアとの統合について説明するMicrosoftのドミニク・ゴードン氏（筆者撮影）
さらにMicrosoftがこだわったのは外部ストアとの統合だ。「何千もあるストアのゲーム、Xboxコンソールで遊んでいるゲームもすぐにROGXBOXALLYで保存して遊べる」（ゴードン氏）。Steam、Epic Games Store、GOG.comなど競合他社のゲームストアで購入したタイトルも、XboxUIの中で一元管理できる。つまり、Steamで購入した『エルデンリング』も、Epic Gamesで無料配布された『GTA5』も、すべて同じ画面から起動できる。ゲームの起動自体は各ストアのランチャーを経由するが、ユーザーはXboxの画面だけ見ていればいい。
考えただけでもめんどくさそう
そら5年かかるわ
最近、ヤフーニュースに、ページ下に行くとページが伸びるUIが実装されたのに気づいた。
次のページ、次のページ・・・と自動的に表示されるが、ボトムにあるページ番号ボタンの選択状態はそのままだから、
次のページへ行こうとボタンを押すと前のページに戻ってしまう。
変なUIだなーと思った。
そして最近匿名ダイヤリーのトップページにも似たような無限スクロールのUIが実装されているのに気づいた。
これはページボトムにある「人気エントリ」「注目エントリ」を見ようと思っても無限スクロールが発動して画面外に押し出されてしまうという不便さがある。
同じく、変なUIだなーと思った。
