JSDC 2025 講演レビュー：AIにフロントエンドを書かせて、私たちは未来を書く
ようやく終わりました！先週土曜日、JSDC 2025 で「AIにフロントエンドを書かせて、私たちは未来を書く」というテーマでお話しする機会をいただきました。 正直なところ、第1回 JSDC から登壇してもう10年以上経ちますが、これほど JavaScript らしくないテーマで話すのは初めてでした（笑）
AIブームに便乗するだけでなく、この講演で探りたかったのは、AIツールがますます強力になる今日、 私たちフロントエンドエンジニアがAIとどう協働し、「Vibe Coding」の罠を避けながら、AIの生産性を活かして開発効率と品質を向上させるかということです。
JSDC 2025について
JSDC（JavaScript Developer Conference）は台湾最大の JavaScript 年次技術カンファレンスです。2011年から複数の開発者コミュニティが共同で立ち上げ、台湾の中上級 JavaScript 技術者に世界最新の技術交流の場を提供し、独立開発者、企業、組織の技術力を統合することを目指しています。
今年の JSDC 2025 は11月29日に集思台大会議センターで開催され、テーマは「Code Compose Connect」。生成ツールとインテリジェント開発フローの発展に焦点を当て、開発者がコラボレーションを通じて創作の境界をどう再定義するかを探求しました。
今年の JSDC で最も感じたこと：AIは本当にどこにでもある。 私のセッションだけでなく、他の登壇者の話を聞いていても、皆がAIが開発フロー、ツールチェーン、さらにはプロダクト設計思考をどう変えているかについて語っていました。 この雰囲気から、AIはもはや「未来のトレンド」ではなく、「現在進行形」の現実だと深く感じました。
講演内容レビュー
講演の冒頭で、簡単なフィールド調査を行いました：「会場でAI支援開発を使っている人はどれくらいいますか？」
結果、目測で9割以上の人が手を挙げました。
この数字は実は驚きではありませんでしたが、実際に目の当たりにするとかなり衝撃的でした。AI支援開発は今や「使うかどうか」の問題ではなく、「どう使えば罠にはまらないか」の問題です。
Vibe Codingとは？
次に、あるシナリオを紹介しました：「3分でAIを使ってECサイトの商品ページを生成する」。 画面はとても綺麗に見えましたが、Consoleを開くと、エラーで真っ赤でした。
これがいわゆる Vibe Coding：感覚でコードを書くことです。ヘッドフォンをつけて、気分が乗って、コードが生成されて、画面が出て、綺麗に見える。 でもエンジニアの私たちは知っています、動いているように見えることと本番にデプロイできることの間には、巨大な溝があることを。表面上は時間を節約したように見えて、実際は技術的負債を埋め込んでいて、穴埋めが終わらない。
6つの開発フェーズにおけるAI協働の罠
フロントエンド開発を6つのフェーズに分け、各フェーズでVibe Codingが陥りやすい罠とその回避方法を分析しました：
| フェーズ | Vibe Codingの罠 | 解決策 |
|---|---|---|
| Phase 1: 要件分析 | AIはHappy Pathのみ処理、Edge Caseは人が考える必要 | Interface First：データ構造とコンポーネントインターフェースを先に定義 |
| Phase 2: ビジュアル実装 | AIが色、余白、角丸を勝手に推測し、「ビジュアル負債」を生む | Design Tokens：Tailwindに組み込み、AIが使える値を制限 |
| Phase 3: コンポーネント実装 | AIのハルシネーション（.valueの漏れ、API混用、古い構文） | Rulesファイル：.cursorrulesまたはCLAUDE.md |
| Phase 4: フロント・バック連携 | Happy Pathのみ、Loading/Error/Race Conditionを処理しない | OpenAPI + MCP：リアルタイム仕様とチェックリストの提供 |
| Phase 5: テストと品質 | テストがHappy Pathのみ、Mockが多すぎて意味がない | TDD思考：人がテストを書いて正しさを定義、AIが実装を書く |
| Phase 6: パフォーマンスとデプロイ | 「動く」≠「本番デプロイできる」 | Pre-deployment Checklist：Lighthouse、Bundle Size、機密情報チェック |
Prompt Engineeringは死んだ？Context Engineeringの時代！
講演の後半では、一つの視点を提示しました：重要なのは「どう聞くか」（Prompt Engineering）ではなく、「何を与えるか」（Context Engineering）です。
Context Engineeringとは？
Anthropicの定義によると、Contextとは「LLMをサンプリングする際に含まれるすべてのトークン」を指し、Context Engineeringとは「LLM固有の制限に対して、これらのトークンの効用を最適化すること」です。LangChainの記事ではより実践的な定義を示しています：
Context Engineeringとは、LLMがタスクを合理的に完了できるよう、正しい形式で正しい情報とツールを提供する動的システムを構築することです。
簡単に言えば、Prompt Engineeringは「どう聞くか」に注目し、言葉遣いやテクニックでAIの行動を調整します。Context Engineeringは「何を与えるか」に注目し、構造化された情報アーキテクチャでAIを導きます。
なぜContext Engineeringがより重要なのか？
ほとんどのAI Agentが失敗する原因は、モデルの能力不足ではなく、モデルに適切な背景情報を提供していないことにあります。
LLMには Context Rot という特性があります：Context Window内のトークン数が増えると、モデルが情報を思い出す精度が低下します。Contextは有限なリソースであり、多ければ多いほど良いわけではなく、「正しい情報」を的確に提供する必要があります。AIの知能はモデルに依存しますが、AIの精度はContextに依存します。
フロントエンド開発の4種類のContext
講演では、Context Engineeringをフロントエンド開発の4つのフェーズに対応させ、4種類のContextタイプに整理しました：
Data Context（データの形）
要件分析フェーズに対応。つまりTypeScriptのTypesとInterfacesです。
前述のことを覚えていますか？先にProductインターフェースを定義し、そこにstatusフィールドがあれば、AIは在庫切れ状態を処理すべきだと分かります。データの形がAIが処理すべきことを決定します。これが「方向は与えるが、答えは与えない」ということです。あなたが構造を定義し、AIが内容を埋める。
Visual Context（ビジュアルの境界）
ビジュアル実装フェーズに対応。つまりDesign Tokensです。
色、余白、角丸をすべて定義してTailwindに組み込めば、AIはその範囲内でしか選択できません。これは「選択範囲を制限する」という概念です。「#ff0000を使うな」とたくさん書くより、「使えるのはこの色だけ」と直接定義する方が良い。選択を制限することが、精度を高めることです。
Constraint Context（ルールと禁止事項）
コンポーネント実装フェーズに対応。つまり.cursorrulesやCLAUDE.mdです。
AIに伝える：NEVER use any、ALWAYS use Composition API、必ず.valueを付ける。明確な禁止事項と要件で、AIに境界がどこにあるか知らせます。ここでは「ルールを書くより例を示す方が効果的」です。たくさんのルールを書くより、Rulesファイルに標準的なコンポーネントの例をいくつか入れてAIに参照させる方が良い。
Knowledge Context（リアルタイムの仕様と知識）
フロント・バック連携フェーズに対応。ここには2つの側面があります：
一つは API仕様。OpenAPI (Swagger) specがあれば、AIは正しいAPI契約に基づいてClient Codeを生成でき、一つ一つのフィールドを説明する必要がありません。これがバックエンドとの協業の基礎です。
もう一つはリアルタイム知識。AIのトレーニングデータは1年前で止まっているかもしれず、Vue 3.5でpropsを分割代入できることを知りません。MCPを通じて、AIは最新のドキュメント、データベースSchemaをリアルタイムで照会し、正しい方法でコードを書けます。
まだMCPを導入していなくても大丈夫です。まずopenapi.yamlやschema.sqlをプロジェクトのdocs/フォルダに置き、ルールファイルでAIにそれを読むよう指示するのも良いスタートです。
なぜ「テクニック」ではなく「エンジニアリング」と呼ぶのか？これはシステマティックな方法だからです。AIが今回正しく書くかどうか賭けているのではなく、AIがその環境の中で正しく書くしかない環境を構築しているのです。
この4つのContextはちょうど前述の4つの開発フェーズに対応しています。これは偶然ではありません。 AI時代のフロントエンドアーキテクチャとは、実はAIのために高品質なContext環境を構築することなのです。
参加者Q&A補足
時間の関係で、会場ではQ&Aを行えなかったので、ここでSlidoを通じて参加者から寄せられた質問をいくつか整理します。
Q1: Design Tokenはデザイナーの仕事では？フロントエンドはどうすれば？
AIにフロントエンドの画面を書かせる際、design tokenや画面関連の仕様を定義するのはデザイナーの仕事のような気がします。フロントエンドエンジニアとして、自分で仕様をエスパーするか、デザイナーにどう仕様を要求すべきでしょうか？また、AIの出力を向上させるために、フロントエンドエンジニアが学ぶべきデザインコンセプトはありますか？
多くのフロントエンドが「これはデザイナーの仕事でしょ？」と思いがちですが、現実には、デザイナーがいなかったり、デザイナーが対応できないことも多いです。そんな時、フロントエンドが自分でTokenを定義することは、実は自分を救うことになります。
デザイナーがいる場合は、Design Tokenの概念を持って積極的に話し合い、これにより開発の一貫性が保たれ、変更も容易になると説明できます。多くのデザイナーはこのようなシステマティックなアプローチを歓迎しますが、どう始めればいいか分からないだけです。Figma自体にもDesign Tokenを定義できるVariables機能があります。
デザインカンプがすでに渡されている場合は、繰り返し使われている色、余白、角丸を自分で整理します。AIに分析を手伝ってもらうこともできます：「このデザインカンプから、よく使われる色、余白、フォントサイズを整理してください」。
また、基本的なデザインコンセプトを理解することをお勧めします：8px Grid System（余白は8の倍数を使用）、Typography Scale（フォントサイズに規則的な比率がある）、Color System（メインカラー、サブカラー、セマンティックカラー）。デザイナーになる必要はありませんが、これらの知識があればデザイナーとのコミュニケーションがスムーズになります。
自分でやりたくない場合、Tailwind自体のデフォルト値はすでに設計されたシステムです。text-lg、p-4、rounded-mdなどのクラスを直接使えば、値を勝手に推測するよりずっと良いです。
Q2: AIは異なるチームのコードを統合するのに役立ちますか？
あるウェブサイトに英語版と中国語版があり、それぞれ異なるチームが開発したとします。そのため、開発方法、初期定義のスタイル、コンポーネントモジュールはすべて別々に作られています。しかし後から、できるだけ統一して同期した仕様にしたいと考えています。レプリカを速めるための一貫した仕様をdesign tokenとして定義し、AIにレプリカを作らせることは可能でしょうか？
可能ですが、一気にやろうとしないでください。
私のお勧めのアプローチ：まずAIに両方のコードを読ませ、それぞれの命名規則、コンポーネント構造、スタイルの書き方を整理させます。このステップは「どこが違うか」を把握するためです。
次に、「どちらに統一するか」は人が決める必要があります。どちらの書き方がメンテナンスしやすい？どちらのチームが大きくて合わせる必要がある？第三のより良い方法はある？これらはAIには判断できません。
決まったら、統一したDesign Token、コンポーネントPropsインターフェース、Coding Styleを仕様書にまとめ、この文書がAIのContextになります。
最後は段階的なリファクタリングです。一度に全部変えようとせず、新機能から統一仕様を使い始め、古い部分は触る時に徐々に調整すれば良いです。
正直なところ、このようなチーム間の統合は、技術コストより調整コストの方が高いことが多いです。AIはコードを生成する手助けはできますが、「2つのチームに同じ仕様を使うことに同意してもらう」ことは、やはり人が調整する必要があります。
Q3: 実務ではすべてを実践するのは難しく、技術的負債が増え続けている場合は？
講演者の各原則や実行時の注意点は概念的には理解できますが、実務ではすべてを実践するのは難しいと感じています。特に現在のプロジェクトでは技術的負債が増え続けているように感じます。実務でどう克服するか、講演者の見解をお聞きしたいです。
話しているのは「理想的な状態」ですが、私自身も100%実践できていません（笑）。重要なのは完璧を追求することではなく、「新しい負債を積み上げ続けないこと」です。
現在のプロジェクトが混乱していても、一夜で良くなることはありません。私のやり方は「触ったコードは、来た時より少しきれいにして離れる」だけで良いです。 古い技術的負債はそのままにして、新機能からInterface First、Design Tokenなどを導入し、少なくとも新しい部分は負債を積み上げないようにします。
選ぶなら、ROIの高いものから。 Rulesファイル（.cursorrulesやCLAUDE.md）の作成のように、ルールをうまく書けば、一度書くだけでAIが毎回従うようになり、投資対効果は非常に高いです。 Design Tokenも同様で、一度作れば効果は累積的です。
また、技術的負債の多くは「チームにコンセンサスがない」ことから来ています。Code Reviewで問題を見つけるより、ルールをESLintに書き込み、AI Rulesに書き込み、ツールで自動化して制約する方が口約束より確実です。
さらに、AIは「すべてのvarをconstに変更」「Options APIをComposition APIに変更」などのリファクタリングがとても得意です。 MCPでAIに公式ドキュメントを読ませれば、古いコードを新しい標準にアップグレードしてくれ、最後は検収するだけで済みます。
こうすることで人力をより価値の高いところに集中でき、AIを作業員として使い、人はアーキテクチャの決定に専念すれば良いのです。
Q4: AIの出力後に必要だと気づくルールもある場合は？
仕様はAIが出力する前に明確に書くべきで、後からルールを追加するのは避けるべきですが、AIが出力してから「これは特定のルールや詳細に従ってほしかった」と気づく細部もあります。これは自分の要件を理解していない、またはすべての詳細を明確に表現できないということでしょうか？この状況をどう改善すればよいですか？
これは全く普通のことで、あまり焦る必要はありません。ルールは元々「イテレーション」で生まれるもので、最初からすべての詳細を考えることはできません。
私のやり方：AIがコードを出力し、「あれ、ここはこうすべきだった」と気づいたら、すぐにそのルールをRulesファイルに追加し、AIに新しいRulesを読ませて再出力させます。 このようにルールを蓄積し続ければ、AIが書くものはどんどんチームの要件に合うようになります。
「AIが踏んだ地雷」リストを作り、AIが何か間違えるたびに記録してルールにします。このリストはどんどん完成度が上がり、最終的にはあなたのチーム専用のBest Practiceになります。
実はこれは学習プロセスです：あなたのAIへの理解が深まり、AIのプロジェクトへの理解も（Rulesファイルを通じて）蓄積されます。最初の数回は大変ですが、後はどんどんスムーズになります。
「自分の要件を理解していない」と思わないでください。多くの詳細は元々やってみて初めて浮かび上がるもので、従来の開発も同じです。 書いている途中で「あ、ここはxxxの状況を処理する必要がある」と気づく。違いは、以前は自分で書いて自分で直していたのが、今はAIと協働しているだけです。
Q5: コードを書くことしかできないエンジニアは危険ですか？
AI codingで最も重要なのは、AIに要件、使いたいツール、目的を理解させることのようです。しかしそうなると、私たちエンジニアにとってcodingは最も重要ではなく、「明確化」が重要ということになります。「コードを書くことしかできない」エンジニアは将来危険なのか、また私たちはどのようなマインドセットを持つべきでしょうか？
この質問は分けて話したいと思います。
「コードが書ける」は基本スキルになり、価値のすべてではなくなる
「コードが書ける」を「Wordが使える」に例えるのは少し大げさに聞こえますが、言いたいのは：以前は「要件をコードに変換する」という翻訳プロセス自体が希少で価値がありました。今はAIがあり、「自然言語をコードに変える」という部分はどんどんツールで代替できるようになりましたが、「何を書くか、なぜそう書くか、システム全体をどうするか」はまだ人が決めています。
だからコードは「AIとコミュニケーションする言語」と「成果を検収するツール」になり、唯一のアウトプットではなくなります。しかし、コードが書けなくていいわけではありません。コードが書けなければ、基本的にAIが書いたものを「管理する」ことはできません。
本当の価値は「AIが苦手なこと」にある
問題の明確化 / 要件分析：AIは整理やブレインストーミングを手伝えますが、本当の要件はビジネス目標、制約、リスク、時間、予算から来ます。これらは「政治 + ビジネス + 人間性」の総合産物です。AIは既知のルールを記憶し推論できますが、「この要件に意味があるか？」と主体的にチャレンジしたり、「このKPIは正しく設定されているか？」と問うたり、「政治的結果の意識」や「長期的責任感」を持つことはありません。「私たちは結局何の問題を解いているのか？この機能をやらないとどうなる？」と明確に言える能力は非常に価値があります。
システム / アーキテクチャ設計：AIは「あるファイルのコードを渡す」のは得意ですが、「システム全体をいくつのサービスに分割する？データフローはどう流れる？将来変更しやすい？セキュリティは？拡張性は？」といった高次元のトレードオフは、チームの能力、既存システム、デプロイ環境、組織文化に関わります。このような「設計空間の意思決定」は、AIは選択肢を提示できますが、最終的に責任を取るのはあなたです。
品質管理：コードレビュー、テスト戦略、観察指標、リスク評価を含みます。AIはテストを書いたりコードを生成したりできますが、「テストは重要な点をテストしている？この変更は他のシステムに影響しない？この実装は高トラフィック、高エラー率の状況で耐えられる？」これらは経験 + システム的思考であり、単純な言語モデルだけでは対処できません。
コミュニケーション調整：AIは多くの「低レベル作業」を手伝えます。会議の要点を整理したり、技術説明をPMが理解できる言葉に翻訳したり、コミュニケーション素材としてpro/consをリストしたり。しかし本当に難しいのは：「今この場で本当のことを言うべきか、慰めバージョンを言うべきか」を判断すること、衝突の中で立場を調整すること、「今のやり方では爆発する、みんなで調整しませんか？」と進んで言うこと。このような「関係 + リスク + 誠実さ」に関することは、人に頼るしかありません。
重要な前提：そもそも十分なエンジニアリング基礎が必要
「みんなAIを管理する人になろう」という言葉には現実的な前提があります：AIを管理できるためには、コードを読めて、異常を見つけられて、何がコードの臭い（code smell）か分かって、基本的な設計、テスト、デプロイを理解している必要があります。そうでなければ、「AIを信じる」vs「もっとAIを信じる」の間で選択することになり、「それが正しいかどうか判断する」ことにはなりません。
もし誰かが「じゃあ、しっかりcodingを学ばなくてもいいんだ、どうせ将来AIが書いてくれる」と解釈したら、悲劇になります。より健全な理解は：コードを学ぶ目的が、「自分で一行一行書く」から「素早く理解、リファクタリング、組み合わせ、チェックできる」に変わったということです。
AIを恐れないでください。コードを書くのは得意だけど指導が必要なジュニアだと思えばいいのです。将来の勝敗を分けるのは：AIを使いこなして、高品質なシステムを書かせることができるかどうかです。
この講演の核心メッセージは：AIは強力なツールですが、ツールには使いこなす人が必要です。
Vibe Codingの問題はAIを使うことではなく、「何も考えずに使う」ことです。Interface、Design Token、Rulesファイルなどのコンテキストを構築すれば、AIの出力品質は大幅に向上します。
フロントエンドは死んでいない、死んだのは古い開発モードです。
チームによく言っています。AIがコードを書いてくれても、毎回のCommit、PRには自分の名前が付いていて、Git Blameで詰められる時に逃げ隠れはできません。
業界でResponsible AIが語られるとき、倫理、公平性、透明性について話しています。しかし私たち開発者にとって、「責任を持ってAIを使う」ことのより実際的な意味は：AIがあなたの代わりに書き、あなたがその出力の責任を取るということです。 使わないのではなく、分かった上で使う、確信を持って使う、最終的に本番にデプロイされるすべてのコードに責任を持つということです。
以前のフロントエンドでは、私たちは「デザインとバックエンドをつなぐ要石」だと強調していました。今のフロントエンドはAIの助けを借りて、その価値は「ページを作る」だけではなくなりました。パフォーマンスを極限まで追求すれば、ユーザーのリテンションは向上します。アニメーション、ビジュアライゼーション、没入型体験で感情をつなげば、ユーザーのブランドへの記憶は深まります。AIとプロダクトのインタラクションを自然に融合させれば、プロダクト全体に新しい成長空間が開けます。
今のフロントエンドエコシステムには、フレームワーク、ツール、AI支援があり、アイデアから本番デプロイまで信じられないほど速くできます。 イノベーションを深めたいなら、Edge Runtime、Streaming UI、AIネイティブアーキテクチャがあり、未知の領域で自分の金脈を掘り当てることができます。
私は AIとフロントエンドの交差点こそが、未来最大の機会 だと考えています。
これはAIと共存する最高の時代であり、アーキテクチャ能力が最も試される時代でもあります。
JSDC 2025からの招待と、会場のすべての参加者に感謝します。来年またお会いしましょう！
スライドリンク：
最後に予告です
12月には WebConf 2025 でも「AIはReactしか分からない？Vue.jsでもVibe Codingできる！」という講演があります。この講演は今回の延長として、Vue.jsエコシステムがAIとどう協働するか、Vue.js開発者が注意すべきAIの罠により焦点を当てる予定です。興味のある方はぜひお越しください！
そしてもう一つ予告 😏
