なぜAIへのUI指示は自然言語だと失敗するのか。JSXとMCP、React Grabで進化するClaude Code開発

AIに「一覧画面を作って」と指示を出す。

出力されたコードを実行する。

見た目は完璧だ。

でもボタンを押しても何も起きない。

状態管理が完全に壊れている。

これはAIが馬鹿なのではない。

僕らの指示の出し方が根本的に間違っている。

UIは見た目だけの単純なものではない。

自然言語でUIを指示すること自体が、そもそも無理ゲーだった。

今、AIコーディングの最前線は「モデルの賢さ」から「コンテキストの渡し方」へ完全にシフトしている。

ニュースの概要

最近のAI業界の動きを見ていると、明確なパラダイムシフトが起きている。

AIモデル自体の性能差は、もはや月単位ではなく週単位で縮まっている。

どのモデルを使っても、出力されるコードの質に決定的な差はなくなってきた。

フロンティアモデルが同月に3本もリリースされる異常事態だ。

性能差でツールを選ぶ時代は終わりつつある。

選定軸はエコシステムや価格、統合性に完全にシフトした。

じゃあ何で差がつくのか。

コンテキストをどう渡すかだ。

特にフロントエンド開発において、AIにUIの修正を依頼するのは地味に面倒だ。

「どのファイルの何行目か」を正確に伝える作業が、開発者の時間を奪っている。

一部のAIエディタは、組み込みブラウザを使って視覚的に要素を選択できる機能を提供し始めた。

Cursorは視覚的なエディタでブラウザ内の要素をクリックして指示を出せる。

TRAEも同様の組み込みブラウザを備えている。

確かに便利だ。

でも、それは特定のエディタに依存するワークフローになる。

エディタを乗り換えた瞬間、その便利さは失われる。

特定のツールにロックインされるリスクは計り知れない。

ここで注目されているのが、特定のエディタに依存しないアプローチだ。

ブラウザ上のUI要素からコンテキスト情報を取得し、標準プロトコル経由でAIに渡すツールが登場している。

React Grabのようなオープンソースライブラリがその代表格だ。

対象のコンポーネントのファイルパス、行番号、階層構造を一瞬で取得できる。

開発中のWebサイト上で任意の要素にホバーし、ショートカットキーを押すだけだ。

クリップボードを経由して、任意のAIエージェントに渡すことができる。

同時に、AIエージェントと外部ツールを繋ぐ規格であるMCPが爆発的に普及している。

月間SDKダウンロード数は9,700万を突破した。

対応サーバーは5,800を超えている。

わずか16ヶ月で4,750%という異常な成長率だ。

主要なAIプロバイダーはすべてMCP対応を完了した。

この規格はすでにAgentic AI Foundationに寄贈されている。

規格戦争はすでに終わっている。

これからは、特定のツールにロックインされるのではなく、MCPという共通レールの上で開発フローを構築する。

そしてもう一つ視点がある。

UIの「意味構造」だ。

生成AIにUIを作らせるとき、難しいのはHTMLやCSSを書くことではない。

UIの意味構造を崩さずにコードへ落とし込むことだ。

自然言語だけで指示すると、この意味構造が簡単に壊れる。

だからこそ、JSXのような半形式的に構造化された表現が、AIへの指示において極めて強力に機能する。

UI仕様を意味空間上の対象とみなし、それをJSXによる構造へ変換してからAIに渡す。

これが、実装を安定させるための最適解になりつつある。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者目線の解説

なぜ自然言語によるUI指示は失敗するのか。

理由はシンプルだ。

UIは極めて複合的な対象だ。

Webアプリの画面は、単なる静的な絵ではない。

以下のような要素が複雑に絡み合っている。

• 空間構造: コンポーネントの配置と階層
• 時間変化: アニメーションやトランジション
• 状態遷移: ユーザー操作による表示の切り替え
• 外部通信: APIからのデータ取得と反映
• イベント: クリックや入力のハンドリング

Webアプリの組み立ては、部品の作成からレイアウト、ロジック、画面遷移、状態管理まで多岐にわたる。

特に状態管理は独立した工程ではなく、すべての要素を横断する心臓部だ。

ボタンという部品があり、それを配置し、イベントを紐付け、状態に応じて表示を切り替える。

これらを自然言語で「いい感じにして」と伝えるのは、情報量が圧倒的に足りない。

AIは足りない情報を過剰に補完しようとする。

結果として、局所的には正しいが、全体としては破綻したコードが生成される。

これが「意味ずれ」の正体だ。

しんたろー：
Claude Codeに「モーダル出して」って雑に投げたときの挙動が気になる。
Z-indexが崩壊した謎のコンポーネントが錬成されそうで怖い。横着すると痛い目を見る。

ここでJSXの出番になる。

JSXは単なるReactの文法ではない。

UIの仕様を木構造として半形式化する、強力な構造化表現だ。

コンポーネントの階層、プロパティの受け渡し、イベントハンドラのマッピング。

JSXを使うことで、UIの意図が明確な構造として定義される。

自然言語の曖昧さを排除し、意味を保存したままAIに意図を伝えられる。

AIにとって、これほど分かりやすい仕様書はない。

構造化とは、生成AIの探索空間を減らすことだ。

意味ずれを起こしやすい自由度だけを減らし、AIを正しい方向へ導く。

そして、この構造化されたコンテキストをどうやってAIに届けるか。

ここでMCPが決定的な役割を果たす。

今まで僕らは、手動でファイルを指定したり、コードをコピペしたりしていた。

あるいは、特定のエディタの独自機能に依存していた。

でも、MCPを使えばその必要はなくなる。

React GrabのようなツールがMCPサーバーとして動作する。

ブラウザ上のUI要素を選択するだけで、その要素のJSX構造やファイルパスが抽出される。

それがMCP経由で直接AIエージェントに渡される。

クリップボードすら経由しない。

完全にシームレスなパイプラインだ。

公式サイトによると、これにより最大3倍の速度向上と精度改善が見込める。

このアーキテクチャの最大の強みは、モデル非依存であることだ。

裏側で動くAIモデルが何であれ、エディタが何であれ関係ない。

MCPという共通規格を通すことで、どの環境でも同じワークフローが実現できる。

AIモデルの進化は早すぎる。

先月まで最強だったモデルが、今週には時代遅れになる。

そんな状況で、特定のエディタやモデルにワークフローを依存させるのはリスクが高すぎる。

特定の企業が提供する閉じたエコシステムに依存するのは、開発者として致命傷になりかねない。

しんたろー：
フロントエンドのコンポーネントが肥大化してくると、コンテキストを渡すのが限界になってくると思う。
MCP経由でピンポイントに構造だけ渡せるアプローチはかなり気になる。

僕がClaude Codeを推している理由もここにある。

Claude Codeはターミナルで動くCLIツールであり、MCPにネイティブ対応している。

エディタのUIに縛られることなく、MCP経由で様々なツールと連携できる。

ブラウザでUIを確認し、問題の要素を特定する。

その構造化されたコンテキストがMCP経由でClaude Codeに飛ぶ。

Claude Codeがターミナル上で直接ファイルシステムにアクセスし、コードを修正する。

この身軽さと拡張性こそが、これからの開発スタイルの標準になる。

最近の資金調達の動向を見ても、業界の方向性は明らかだ。

2月のスタートアップ資金調達は史上最高の1,890億ドルを記録した。

AI関連のメガディールが市場を席巻している。

その資金は、単なるモデルの学習だけでなく、エコシステムの構築に流れている。

標準化されたインフラの上で、いかに効率的なワークフローを組むか。

そこが主戦場になっている。

実務への影響

じゃあ、僕ら開発者は明日からどう動くか。

結論から言うと、プロンプトの書き方とツールの選び方を根本から変える。

まず、AIにUIの修正を依頼するとき、自然言語で長々と説明するのをやめる。

「このボタンを青くして、角を丸くして、押したらローディング状態にして」

こういう形容詞だらけの指示は失敗の元だ。

AIに推測の余地を与えてはいけない。

代わりに、JSXの構造を使って意図を伝える。

修正したいコンポーネントの構造を明示し、どこを変更するかを構造的に指示する。

AIを「推論器」として使うのではなく、構造を変換する「複写器」として使うイメージだ。

プロンプトから曖昧な言葉を徹底的に排除する。

ただし、JSXをそのまま仕様書に書くと、AIはそれを完成済みの実装断片とみなしてしまう。

具体化しすぎると推論の余地を潰してしまう。

業務アプリのような定型UIを大量に生成したい場合は、JSXより一段抽象化した表現を挟む。

人間は意味構造を記述し、実装のベストプラクティスはAIに提案させる。

違和感があれば補正する。

この流れが、これからの開発の基本になる。

次に、開発環境の構築方針を見直す。

特定のエディタの「便利機能」に飛びつくのは危険だ。

そのエディタがオワコンになった瞬間、あなたの開発スピードも落ちる。

エコシステムにロックインされることは、技術的負債を抱え込むことと同義だ。

目指すのは、モデル非依存のアーキテクチャだ。

コンテキストの取得からAIへの伝達までを、標準化されたプロトコルで繋ぐ。

その中核になるのがMCPだ。

MCPに対応していないツールは、これからの選択肢から外す。

「いつやるか」のフェーズはもう終わった。

今は「どう組み込むか」を考える段階だ。

MCPサーバーを書けるエンジニアの市場価値は、間違いなく上がっていく。

React Grabのようなツールは、まだ発展途上だ。

でも、この「ブラウザから直接コンテキストをぶっこ抜いてMCPで渡す」というアプローチは間違いなく主流になる。

フロントエンド開発の最大のボトルネックだった「コンテキストの特定」が、これで解決する。

試してみたい技術の筆頭だ。

しんたろー：
新しいツールが出たからといってすぐ飛びつくのはリスキーだ。
でもMCP対応しているかどうかは、ツール選定の基準としてかなり気になっている。

開発者の価値は、「どのAIツールを使えるか」ではなくなる。

「いかに正確なコンテキストを抽出し、AIに渡すパイプラインを構築できるか」にシフトする。

UIの複合的な意味を理解し、それを構造化データに変換するスキル。

これこそが、AI時代に生き残るフロントエンドエンジニアの必須条件だ。

AIは魔法ではない。

ただの強力な関数だ。

入力される引数であるコンテキストがゴミなら、出力もゴミになる。

僕らの仕事は、この引数を最高品質に磨き上げることだ。

そのための武器が、JSXであり、MCPだ。

FAQ

Q1: React Grabは本番環境のパフォーマンスに影響を与えますか？

与えない。

開発環境でのみ読み込まれる設計になっている。

本番ビルドには一切含まれない。

バンドルサイズが増えることも、パフォーマンスが落ちることもない。

環境変数の判定で完全に切り離される。

安心してプロジェクトに導入できる。

Q2: AIにUIの修正を依頼する際、自然言語よりもJSXを使った方が良いのはなぜですか？

UIは複合的な意味構造を持っている。

見た目、状態遷移、イベント、コンポーネントの階層。

これらを自然言語で表現すると必ず曖昧さが生まれる。

AIが誤った解釈を起こし、意味ずれが発生する。

JSXのような構造化された形式を使えば、意図が正確に伝わる。

期待通りのコードが生成される確率が跳ね上がる。

Q3: MCPに対応するメリットは何ですか？

特定のAIモデルやエディタに依存しなくなることだ。

様々なAIツール間で、共通のコンテキストをやり取りできる。

クリップボードすら不要になる。

ブラウザのUIコンテキストを、直接Claude Codeなどのエージェントに渡せる。

将来別のAIツールに乗り換えるときも、ワークフローを変えずに済む。

開発環境のポータビリティが劇的に向上する。

まとめ

UI開発の主戦場は「コンテキストの構造化」と「標準プロトコルでの伝達」に移った。

これからはMCPを軸にしたモデル非依存の環境構築が必須になる。

👉 ThreadPostでSNS運用を自動化する