> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w12-d2-observation-frontend-vitality-in-the-ai-wave/2026-d2-key-takeaways-review.md).
# 2026-D2の要点を振り返る
大会プログラム：
通常は約1か月後に公式からスライドが公開される。ライブ配信や録画の提供はない。
一日のうちに数十の講演が並行して行われるため、聞き逃す内容は必ず多くなる。私は専門分野で実力のある登壇者をいくつか選んだ。以下は私が参加し、振り返る価値があると思った講演に限る。
その前に、現在のJSエコシステムを紹介しておく。職業としてフロントエンドに携わる人でも、自分の言語のエコシステムをよく知らなかったり、入門時の認識で止まっていたりすることが少なくないと気づいたからだ。現在の主なプレイヤーはVercel、VoidZero、Bun、Biomeなど。ChatGPTにASCII図を作ってもらったところ、わかりやすかったので参考に載せる。
```
┌──────────────────────────────────────────────────────────────────────┐
│ JavaScript Ecosystem │
└──────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ Developers │
└──────┬───────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ ① AI / Coding Entry Layer │
│----------------------------------------------------------------------│
│ Cursor / Claude Code / Copilot / Windsurf / Zod │
│ │
│ 作用： │
│ - 代码生成 │
│ - agent 工作流 │
│ - IDE 内交互 │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ ② Framework / Application Layer │
│----------------------------------------------------------------------│
│ React / Vue / Svelte / Solid │
│ Next.js / Nuxt / Remix / Astro │
│ │
│ 代表公司 / 项目： │
│ - Vercel → Next.js │
│ - NuxtLabs → Nuxt │
│ - Vue / Evan You ecosystem │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ ③ Toolchain Layer ← 现在竞争最激烈 │
│----------------------------------------------------------------------│
│ Bundler / Dev Server / Compiler / Linter / Formatter / Test │
│ │
│ 主要玩家： │
│ - Vite / Rollup / Rolldown → VoidZero 阵营 │
│ - Turbopack → Vercel │
│ - Rspack → ByteDance │
│ - Webpack → 旧时代核心基础设施 │
│ - Biome → lint / format │
│ - esbuild → 高性能构建基础件 │
│ - SWC / OXC → 编译基础设施 │
│ │
│ 这里决定： │
│ - 本地开发体验 │
│ - 构建速度 │
│ - 配置模型 │
│ - AI 能否直接操作工程系统 │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ ④ Runtime Layer │
│----------------------------------------------------------------------│
│ Node.js / Bun / Deno / Browser / Edge Runtime │
│ │
│ 主要玩家： │
│ - Node.js Foundation / OpenJS │
│ - Bun │
│ - Deno │
│ - Vercel Edge Runtime │
│ - Cloudflare Workers │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ ⑤ Deploy / Cloud / Delivery Layer │
│----------------------------------------------------------------------│
│ Vercel / Netlify / Cloudflare / AWS / Azure / GCP │
│ │
│ 作用： │
│ - 部署 │
│ - 托管 │
│ - 边缘分发 │
│ - Serverless / AI App Runtime │
└──────────────────────────────────────────────────────────────────────┘
```
#### 一、**Vite+：統合JSツールチェーン――Evan You**
Rustによるフロントエンドツールチェーンの書き直しを引き続き進めている。フロントエンド基盤をRustで書くことは、ほぼ業界の共通認識になった。TSCは別だが。
| **ツールの種類** | **旧世代（JavaScript）** | **新世代（Rust）** |
| ---------- | -------------------------------- | ------------- |
| ひな型生成 | Vue Cli / Create React App | Vite 8 |
| バンドラー | Webpack（コンパイルはts-loader）/ Rollup | Rolldown |
| TSビルド | tsup（esbuildベース） | tsdown |
| コード検査 | ESLint | Oxlint |
| コード整形 | Prettier | Oxfmt |
| テストフレームワーク | Jest | Vitest |
Vite+は、ツールチェーンのさまざまな設定ファイルを一つにまとめ、設定作業を簡素化する。
彼の仕事はなぜ重要なのか。なぜAI時代には、統一された効率的なツールチェーンが必要なのか。
**中心となる考えは、コードを書くことがもはやボトルネックではない、という点だ。AIは自分のコードを繰り返し検査し、検証しなければならない。整理された効率的なツールチェーンをAIに提供できなければ、今後の大幅な生産性向上が妨げられる。**
最後に、VoidZeroがクローズドテスト中の製品にも少し触れた。主な機能は自動デプロイと、フルスタックのエンドツーエンドな型安全性だ。クラウドサービスに乗り出そうとしているようにも見え、Vercelと方向が重なる。
#### 二、\*\*Google A2UI - LLM Generated UI for Agents & A2A――\*\*Jennie
Googleの影響力が伝わる光景。
 
この講演はA2UIの紹介だった。ユーザー向けにUIを動的に生成することが対象であり、A2UI以外にも多くの方式がある。
| **観点** | **AG-UI** | **ChatKit** | **MCP UI** | **Vercel AI UI** | **Google A2UI** |
| ---------------- | ------------------- | ----------- | ----------------- | ---------------- | ----------------------- |
| **位置づけ** | フロントエンドの状態駆動 | OpenAI専用 | エージェントによるリモート描画 | 垂直スタック統合 | **宣言的な汎用プロトコル** |
| **中心となる仕組み** | クライアント状態の共有 | 独自コンポーネント群 | サンドボックス化されたiframe | Shadcn + SDK | **JSONによる描画記述** |
| **信号対雑音比** | 非常に高い（ネイティブ性能） | 中程度 | 中程度（クロスドメイン通信の負荷） | 高い（開発効率） | **非常に高い（スタイルの一貫性）** |
| **安全性** | 高い（フロントエンド側で制御） | 高い | 非常に高い（環境を隔離） | 高い | **非常に高い（コード実行を禁止）** |
| **クロスプラットフォーム性** | 弱い（フロントエンドの書き直しが必要） | 弱い | 強い（Web優先） | 弱い（Web優先） | **非常に強い（ネイティブ/Webに対応）** |
**Google A2UIの特徴は、UIを構造化データとして扱うことだ。**
サーバーからReactコンポーネントの断片、つまりコードを直接送るVercelとは異なり、A2UIはエージェントがコードを送らず、JSONの記述だけを送る方針を貫く。
* エージェントは、UIの意図を表す平坦なストリーミングJSONを出力する（例：`{type: "chart", data: [...]}`）。クライアントは受信後、事前に用意した信頼できるローカルのコンポーネント（Angular、Flutter、Litなど）を呼び出して描画する。
* この「データと描画の分離」という構造は、LLMが悪意あるスクリプト（XSS）を生成するリスクを根本から解消する。同時に、エージェントの応答を、スマートフォンのネイティブアプリでもWebページでも、完全に統一された見た目で表示できる。
AG-UIの基本的な考え方は、「エージェントは思考と意思決定だけを担い、UIロジックはフロントエンドに残すべきだ」というもの。
* 状態同期の仕組み（Shared State）：エージェントとフロントエンドの間に、リアルタイムで双方向に同期される状態オブジェクト（State Object）を設ける。エージェントは指示によって状態を直接変更できる（例：`state.selectedItems = [...]`）。フロントエンドのフレームワーク（React/Vue）は変更を検知し、ミリ秒単位でローカルのコンポーネントを更新する。
* アクションの起動（Action System）：フロントエンド開発者は、一連の「能力を提供する関数」（Actions）をエージェントに公開する。呼び出すタイミングはエージェントが決めるが、実行方法はすべてフロントエンドのコードが定義する。これにより業務ロジックの安全性を確保する。
MCP UIの基本的な考え方は、「UIもAPIのように標準化すべきだ。エージェントが行く先にはUIもついていく」というもの。
* リソースとしてのUI（UI as Resource）：MCPでは、UIはフロントエンドにあらかじめ書かれたコードではなく、エージェントが動的に提供する「リソース」となる。エージェントは`ui://`プロトコルでURIを返す（例：`ui://analytics-dashboard/v1`）。
* ホスト非依存（Host Agnostic）：MCP Serverを一つ書けば、それが提供するUIをClaude Desktop、ChatGPT、Cursor、さらには自作アプリでも直接描画できる。各プラットフォーム向けにフロントエンドを書き直す必要はない。（iframe）
#### \*\*三、Agentic Codingを構築する道のり：モデルからフレームワークへ――\*\*崔泽宇（麻油）、罗长伟（山果）
アリババ社内には多数のAI Codingツールがあり、各部門がそれぞれ開発している。本当に10年前のフロントエンドによく似ている。
私が聞いたのはQoderとQwen-Codeの2講演だけ。Qwen-Codeのほうが興味深かった。Gemini Cliをforkしたもので、にある。
記録した考えは二つだけ。ほかは製品の紹介だったので、興味があればリポジトリを読むか、ダウンロードして試すとよい。
Codingが重要なのは、本質的に「検証可能性が高い」タスクだからだ。多くのタスクでは、内容を生成するのは容易でも、正しさの検証は難しい。文章の執筆や主観的判断がそうだ。Codingは逆で、生成は比較的難しいものの、コンパイル、テストケース、評価システムなどによって結果を素早く検証できる。この「生成は難しいが検証は容易」という性質により、CodingはAIにとって最も適した最適化対象になる。タスクの価値と検証可能性が強く関係する理由もここにある。
モデルのCoding能力を高める中心的な道筋は「三つの規模拡大」だ。一つはデータ量（コードデータを高い比率で大量に用いること）、二つ目はコンテキストの規模（リポジトリ全体や長い処理の流れを理解できること。たとえば256K context）、三つ目は高品質なデータ（合成データによって訓練品質を継続的に高めること）。この三つを組み合わせることで、検証可能なフィードバックのループの中でモデルを進化させ続け、実際のエンジニアリングにおける複雑なタスクで質的な突破を実現できる。
#### 四、\*\*コンテキストエンジニアリングからHarness Engineeringへ――\*\*周晓
周晓は登壇者の中でも技術的な見識に優れ、第一原理から冷静に分析していた。
ByteDanceのWeb Infra公式アカウントが講演録を公開している。。
要旨は次のとおり。
AI Codingは「コードを書く」効率を一桁引き上げた。しかし納品は速くなっていない。コーディングは全体の30%にすぎず、残る70%はテスト、障害調査、リリース、コミュニケーションだからだ。コードを書くことだけの最適化は、典型的な局所最適である。コードが増え、検証の負担が増し、人はむしろ疲れる。
周晓はTransformerの自己回帰、KV Cache、Prompt Cache、ReActといった「物理的な現実」を土台に据える。コンテキストが長いほどPrefillのコストは高まり、注意が薄まり、ハルシネーションも増える。末尾への追加は安いが、途中の変更は高くつく。したがって、コンテキストエンジニアリングの本質は、情報をむやみに詰め込むことではなく、プレフィックスの安定性を守り、Promptの構造を丁寧に設計することだ。長い対話の過程をsnapshotやAGENTS.mdへ圧縮し、ファイルシステムに保存を任せる。一方的にコンテキストへ押し込むべきではない。
この前提のもとで、エンジニアの役割は「コードを書く人」から「環境とツールを設計する人」へ変わる必要がある。エージェントにとって読みやすく、低遅延で、出力が構造化され、失敗の痛みを伝えるフィードバックを備えたツールチェーンを作る。従来の人間向けGUI、ログ、グラフは、エージェントには大半が雑音になる。よいツールは、エージェントのためのAPIであるべきだ。MCPは原子的な操作を提供し、Skillは実証された手法をSOPとして固定して必要に応じて読み込む。Sub Agentは長いタスクを複数の独立したサンドボックスへ分け、構造化した要約で通信する。一つのコンテキスト内でエントロピーが増え、制御不能になるのを防ぐためだ。
フィードバックのループも、「AIが書いたら私がコードをReviewする」で止めてはいけない。エージェントをLSP、テスト、サンドボックスのCLIにつなぎ、自分で正しさを立証させる。そのうえで変更範囲、スクリーンショット、テスト方法を報告にまとめる。人は個々の操作を追跡するのではなく、成果物を審査する。Spec/Plan、人とAIの協働、どの時点でAskUserするかは、すべて無用な試行錯誤を減らし、人間の注意を目標の定義と結果の確認に残すためのものだ。
講演全体の中心的な結論は、モデルは物理的制約に従う関数であって、魔法ではないということだ。制約を理解すれば、エンジニアの本当の強みはコードの行数ではないとわかる。限られたコンテキストとツールの能力のもとで、エージェント群と少数の人間を、制御可能で、検証可能で、拡張可能なエンジニアリングシステムにする。よりよいHarnessを設計できることこそが強みになる。