後編
2020〜2026年 標準機能の充実からAIの時代へ
CodeGrid 700号記念座談会・後編。IEのサポート終了とCSSの新機能、ブラウザが受け持つUI、Astro、Cloudflare Workersを経て、AIに作業を任せる時代へ。技術の役割がどう移り、人に何が残るのかを語ります。
目次
シェア
前編の振り返り
CodeGrid 700号記念座談会の後編です。前編では、創刊の2012年から2020年ごろまでを振り返り、jQueryやSass、CSS設計、webpack、Jamstackなどが担った役割が、今の開発にどうつながっているのかを見てきました。後編では2020年以降、標準機能の充実からAIの時代までをたどります。
座談会は前編と同じく、3名のエンジニアと2名の編集者で行いました。エンジニアの参加者は次のとおりです。
中村 享介（モダンフロントエンド・エンジニア、ピクセルグリッド代表）
矢倉 眞隆（フロントエンド・エンジニア）
渡辺 由（フロントエンド・エンジニア）
2020〜2024年（401〜600号）
2020〜2024年ごろは、ブラウザの標準機能が充実し、フレームワークやツールに任せることと、ブラウザ自身に任せることを見直す動きが広がった時期でした。また、2022年にはIE11のサポートが終了します。コロナ禍でリモートワークが広がるなど、働き方も、制作の前提となるブラウザ環境も、大きく変わりました。
CSS設計は、コンポーネントの中へ
前編では、2012〜2016年ごろにCSS設計やスタイルガイドに取り組んだ経験が、その後の部品の分け方にも残っているという話がありました。その後、コンポーネントごとにスタイルを管理し、影響範囲を限定する仕組みが広がっていきます。
すでに2017年の「いまどきのコンポーネント設計をめぐる座談会」にも、HTML/CSSとJavaScriptをまたいで部品をどう分け、扱うかという試行錯誤が表れています。
また、Tailwind CSSも、この時期に利用が広がっていきました。用意された小さなクラスを組み合わせて見た目を指定する作り方です。CodeGridでは2020年に「Tailwind CSSで始めるユーティリティファーストCSS」を扱っています。
2020〜2024年ごろを振り返ると、座談会参加者の間では「CSS設計という言葉を聞かなくなってきた」という実感が出てきます。
矢倉：フレームワークでは、コンポーネントごとにファイルを書くようになったので、最初から全体のCSS設計を考える必要が減った、というところがありますよね。というより、そうやって考えることができなくなるような作りになってしまったっていうのが、ありそうな気がしますね。
渡辺：コンポーネントのレイヤーを設計していて、CSSはその中に取り込まれた感じがしますよね。CSSのレイヤーをむき出しで設計している感じは、もうあまりないですよね。
矢倉：ないでしょうね。CSS設計、というよりは見た目の表現だけを考えるようになっていったのかな。今や、Tailwind CSSを使っている人のほうが多い気がしますし。
ただし、それによってUIの設計まで不要になったわけではないようです。どこを1つの部品にするか、何を共通化するかという判断は、コンポーネントの設計として続いています。
IEサポートが終了、新しい標準機能の使いどきへ
ブラウザ側の変化では、IE11のサポート終了が1つの区切りになりました。2022年6月、対象となるWindows 10環境でIE11デスクトップアプリのサポートが終了します。長く制作の前提だったIEへの対応を外せる現場が増え、新しい標準機能を使う条件も変わっていきました。
矢倉：この辺りでIEのサポート終了がありましたね。これがあったから、さらにWebでやれることが進んだという感じはあるのかなと思います。
中村：現場としては、「やっと終わってくれた」という感じもありましたよね。
CodeGridでも、サポート終了を前に2021年末から「IEとEdgeの関係とその違い」を連載しました。IE対応を外すことで不要になる互換性確保のためのコードや、使えるようになるHTML・CSS・JavaScript、ブラウザAPIを取り上げ、制作の前提を見直しています。
CSSでは、コンテナの大きさに応じてスタイルを変えるコンテナクエリーや、要素の関係を条件に指定できる:has()などが登場します。2023年のCSSの進展を見ると、レイアウトから色、セレクターまで、広い範囲で選択肢が増えたことがわかります。
もちろん、すべての機能が同時に、すべてのブラウザで使えるようになったわけではありません。ブラウザ間の互換性を改善する取り組みも、Compat 2021から、参加体制や対象範囲を広げたInterop 2022へと引き継がれました。2023年には対応状況を把握する目安となるBaselineが発表されました。
CodeGridにも「現場で使うCSS Grid」や「知っておきたい、CSS Nesting仕様」が並びます。古いブラウザでどう補うかに加え、標準の新機能をいつ、どこで使うかが、制作の判断になっていきました。
基本的なUIはブラウザが用意する時代へ
標準機能の充実は、CSSの表現力だけでなく、UIをどこまでブラウザが受け持つかという考え方にも及んでいます。前編では、Lightbox系のプラグインで作っていたUIの基本的な部分を、dialog要素などで実現できるようになった変化に触れました。座談会では、その背景にある標準化の方向性も話題になりました。
矢倉が振り返るのは、開発者が自由にUIを作るための基礎的な仕組みを整えようとした、Extensible Webという考え方です。さまざまなフレームワークやUIライブラリが必要とする機能を、ブラウザがすべて用意するのは難しい。それならば、それぞれが必要なものを作れる土台を提供しよう、という方向です。
ただ、その方向は、dialog要素のようにブラウザがUIそのものを用意する今の流れとは逆です。矢倉は、向きが変わった理由を次のように話します。
矢倉：当初は、みんなが作れるような基礎的な部品を作ろうとしたんです。でもアクセシビリティなんかを考えると、開発者が一から作るのはやっぱり大変なんです。なので、基礎的なUIはブラウザ側でもってほしい、という方向になってきたんですよね。
そうした取り組みの1つが、この時期に始まったOpen UIです。ブラウザベンダーの関係者も参加し、既存のHTML要素の機能を拡張したり、新たなUIの仕組みを検討したりしています。見た目のカスタマイズアビリティみたいなのを、かなり意識して作っていますね。
この流れは、その後のCodeGridの「ポップオーバーAPIを攻略する」や「セレクトボックスの現在とこれから 2025」、「CSS Anchor Positioning入門」といった記事にもつながっています。
一方で、共通のUIが標準で提供されるようになっても、独自の部品を作り、共有する必要は残ります。話はここで、Web Componentsの行方へと広がりました。
渡辺：今の話を聞いていて、Web Componentsもあるよなと思い出しました。
矢倉：デザインシステムをしっかり作り込んでいる人たちなど、今でもWeb Componentsに思いをもっている人は多いですね。コンポーネントというものは、まだ標準に溶け込んでいないんですよね。ボタンっていうものを、「オレオレナイスなボタン」として作ったとしても、HTML、CSS、JSをひとまとめにした単位として、そのコンポーネントをHTML側でインポートするとか、JavaScript側でインポートするっていう仕組みがない。だから、部品を配布しやすくしたいという要求もあります。
もう少し使いやすくなってくれたら、ということは多分みんな思っていますね。使いやすいとは何なのか、というところの合意が難しいんでしょうね。
ブラウザに共通の動作を任せることと、独自の部品を作って共有すること。その両方を使いやすくするための模索が、今も続いています。
静的なサイトを作るのにちょうどよいAstro
前編で触れたJamstackの話では、アプリ開発で得たよさを残しながら、Webサイトを軽く作ることが関心になっていました。その流れを受けて、座談会で名前が挙がったのがAstroです。2022年に1.0が公開され、CodeGridでも同年に「今すぐ始めるAstro入門」が始まりました。
Astroでは、基本となるHTMLに対して、操作が必要な部分だけを独立した「島」のように動かすアイランドアーキテクチャを採っています。基本は静的なHTMLとして出力し、JavaScriptが必要なコンポーネントだけを読み込んで動かします。コンポーネントで作ることと、ページ全体に多くのJavaScriptを配ることを切り離せる点が、コンテンツの表示を中心に、一部だけ動きや操作を加えたいという要件のサイト制作に合っていました。
中村：テンプレートベースのものは、いっぱいあったと思うんです。でも、ほかのフレームワークで作るようにコンポーネントを使えて、Webサイトを作るためにちょうどよい、Astroのようなポジションのものがなかったんですよね。アイランドで一部分だけJavaScriptを動かす、という作り方を広めたのはAstroだと思います。
矢倉：うまく、はまったんでしょうね。静的なサイトを作るなら、SPAのNext.jsは大掛かりでした。Gatsbyも静的なサイトを作れるけれど、ページ遷移はSPAのような作りで、データもGraphQLで扱う仕組みです。作りたいものに比べて仕組みが大掛かりで、作る側もそれに合わせてがんばっていたんですよね。みんながみんなNext.jsを使わなくてもいいし、Gatsbyまでがんばらなくてもいい、というところがあったのかなと。ちょうどいいと思える要件が、世の中にいっぱいあったんだろうなと思います。
中村：そうですよね。標準に寄っているところも、僕はAstroの好きなところです。
配信する場所で、処理も動かす
作るものに合わせて構成を選ぶ流れは、サーバー側にも広がりました。Jamstackの考え方を使い続けながら、ピクセルグリッドが利用する基盤は、Cloudflare中心へと移っていきます。
Cloudflare Workersは、Cloudflareのネットワーク上でコードを実行するための環境です。ファイルを利用者に届けるCDNに加え、そのネットワーク上でリクエストに応じた処理も動かす。中村は、V8のisolateを使う実行方式のように、ブラウザを支える技術でサーバー上のJavaScript実行環境を分ける仕組みや、CDNの基盤を生かしてエッジで動かせる点に、技術的なおもしろさがあったと振り返ります。
CodeGridでは2021年に「サーバーレス実行環境Cloudflare Workers」を扱っています。さらに時期を進めると、2026年には「Webサイトホスティングで使うCloudflare Workers」も登場します。補助的な処理を置く場所から、サイトやアプリケーションの基盤として使う場所へと、扱う範囲が広がっていきました。
外村（編集）：ピクセルグリッドの会社を表すキャッチコピーとして、「Jamstackの会社です」の後に、「エッジサーバーレス」という言葉も使っていましたよね。
中村：Cloudflareのプラットフォームでいろいろなものが作れるようになって、Jamstackの枠には収まらなくなった。それを何と呼べばいいんだろう、というところがありました。
矢倉：Cloudflareは最初はCDNの会社だったけれど、だんだんいろいろなことをするようになってきましたね。
コロナ禍で、リモートワークが身近になった
2020年からのコロナ禍はちょうどこの時期にあたり、世の中で会議や共同作業をオンラインで行う機会が増えました。以前からリモートワークを取り入れていたピクセルグリッドは「コロナ禍でも、会社の働き方はあまり変わらなかった」としつつも、周囲の理解や道具の変化を感じていたといいます。
「『打ち合わせはリモートでお願いします』という説明は、しやすくなりましたね。ZoomやMeetの機能も、ノイズキャンセリングとか、あの頃にすごく改善されたと思います（中村）」
CodeGridでも「コロナ禍でのリモートワーク」として、当時の状況を取り上げています。
2024〜2026年（601〜700号）とこれから
2024〜2026年ごろになると、いよいよAIが開発の現場に本格的に入り、開発のやり方そのものが変わり始めます。コードの補完や質問への回答に使う段階から、まとまった作業を任せる段階へと、AIの役割が広がっていきました。
補完から、作業を任せる相手へ
AIが普及し始めた当初はエディタでのコードの補完に利用していましたが、その後は作業を任せるまで、使い方が変わってきます。CodeGridでも、「Cursorで見るAIを用いたコーディング」といった記事から、「AIエージェントのススメ」や「Claude Codeの原則」など、実際の作業でどう使うかを扱うシリーズが続いていきます。記事内容の変化は、ピクセルグリッドでのAIの利用の変化でもありました。
矢倉：今年（2026年）2月に、享介さん（中村）が「人間がテキストを直接編集しない働き方を試す」という方針を社内向けに書いて、じゃあやってみよう、と。作業の仕方は、今年かなり変わった感じがしますね。
中村：そこから、編集チームでもAIを使ってみたんですよね。
外村（編集）：私はプルリクエストへのコメントも、AI経由で書くことが多いです。
技術がなくなるのではなく、使う人との距離が変わる
人が直接コードを書かなくなったとき、そのコードを支えるライブラリも不要になるのでしょうか。事前アンケートには、それとは違う変化を捉えた回答がありました。
CodeGridで「three.js入門」を執筆した小山田は、次のように回答しています。
スタッフ事前アンケートから：three.jsは専門家の道具からインフラへ
以前は、数学やシェーダーの知識があるWebエンジニアたちが、3D表現やかっこいい演出のために使っていました。今はAIに「ゲームを作って」と言うと、おそらく自動的に組み込まれるライブラリがthree.jsだと思います。専門知識がなくても、誰かのやりたいことを実現するための、いわばインフラになったと感じます。（フロントエンド・エンジニア 小山田 晃浩）
AIに任せる範囲が広がるなかで、人は何を受け持つのか。「AIと働く現場から」や「AI時代のプロフェッショナル」では、そのときどきのさまざまな考えや試行錯誤の様子がうかがえます。また、事前アンケートで大杉は、今後の役割を次のように考えていると回答しました。
スタッフ事前アンケートから：人間に残るのは線引きと判断
技術は、その時々で必要に迫られて使ってきました。個別の技術に強い思い入れがあるというより、必要なものを必要なだけ選んできた感覚です。AIによって、個別の技術を人間が直接扱う場面は減っていくと思います。人間に残るのは、何をどこまでAIに任せるのか、誰がどこで使うのか、結果をどう判断するのかといった線引きや考え方ではないでしょうか。（シニアディレクター 大杉 充）
前編で過去の技術としてMVCアーキテクチャを挙げた松竹も、AIの時代に設計の役割がなくなるとは考えていません。
スタッフ事前アンケートから：AIの時代こそアーキテクチャ
AIの時代になっても、アーキテクチャはより重視されていくと思います。（フロントエンド・エンジニア 松竹 誠）
700号分の技術を振り返ると、ブラウザの不足を補ったツール、複雑なコードを整理した仕組み、作業を人のがんばりから切り離そうとした工夫が見えてきます。その中で生まれたものは、その後、標準機能や別のツールに継承されていくこともありました。
その一方で、今ではあまり使われなくなったものもあります。しかし、その知識や考え方は、作り手の判断や、AIが使う基盤（ナレッジ）として、今も活きています。たとえば、「CSS設計」という言葉は今はあまり使われなくなりましたが、テクニカルディレクターの髙津戸は「画面設計上のUIの粒度などの勘どころが、そこ（CSS設計）から身についているのではないか」というコメント（前編）を述べています。
今の技術を選ぶときにも、当時と同じように、何を作り、どんな問題を解決したいのかが出発点になります。その問いに対する答えが、これからどんな形に変わっていくのか。次の100号、200号にも、その過程を残していきたいと思います。
付録：700号に寄せて執筆者コメント
CodeGrid 700号に寄せて、執筆者からのコメントです。
フロントエンド・エンジニア 坂巻 翔大郎
私が初めて記事を書いたのは、第76号（2013年10月31日発行）でした。そこから13年ほど（+624号）経っていることに驚いています。私にとってCodeGridは、いつでも引ける辞書みたいな感じです。
2026/10/07現在は記事数が一番多い著者となっており、多少なり読者の目に触れる機会が多かった著者かもしれません。AIを使った開発が当たり前になっていきますが、AIを使う側の知識はあって損はないでしょう。これからもHTMLやCSS、アクセシビリティなど私が得意とする分野の記事を書いていきますので、今後ともよろしくお願いします。
テクニカルディレクター 髙津戸 壮
いやーjQueryとかCoffeeScriptとか言っていた頃が懐かしいですね……。あの頃まだこんなにちっちゃかった子はもう……みたいな時間が経っていると思うとなんかスゴイですね……！
自分にとってのCodeGridでいうと、実務と、自分の考えを出すというループがよい循環になっているという感覚があります。使ってるツールとかライブラリとかそういうものは移り変わっていくものですけども、その中でも変わらない知識というのを書いていきたいなとあらためて思うなどします。
モダンフロントエンド・エンジニア 中野 祐人
創刊から実に14年半とのこと。よくもまぁこんな移り変わりの激しい業界の中やってますよね我々。みんなでみんなをほめたいです。
僕が初めて書いた記事は2020年のTailwind CSSの記事でした。今読んでも、内容以外にもたくさん書き方の指摘を受け、すごく時間をかけて考えて書いたなぁと思い出します。今ではそこまで意識せずに書くようになっているので、成長しているかもと思いました。これからも有益な情報を届けられるようがんばります。
フロントエンド・エンジニア 渡辺 由
いろいろな技術や考え方が出たり消えたりしても、開発者がよいと思ったものは何かの形で受け継がれてきているのかも？と、進化論みたいなことを連想しました。
著者になる前から読者だったので、いまでもけっこう読者の気持ちです。どの記事も、読むと何かしら発見があります。
フロントエンド・エンジニア 藤田 智朗
入社前、創刊当時から読者なのですが、髙津戸のjQuery deferredの記事（「deferredの基本 | jQuery deferredの使い方」）にものすごい感銘を受けたのを覚えています。
最近はAIによって以前より技術情報に対してアンテナを張る重要度は下がっているかもしれませんが、それでもAIを使いこなすうえで土台となる知識は重要だと思っています。そのための情報を提供し続けていければと思っています。
フロントエンド・エンジニア 山田 順久
創刊当時から購読を始め、入社後は書く側としてだけでなく、自社で開発と運用をしていくメディアサイトとしても多くのことを教わりました。会社を5年離れていた間も購読は続けていたので、こうして振り返ると積み重ねの大きさを感じます。
CodeGridには昔の記事もそのまま残っているので、いま見渡すと、技術そのものだけでなく「その頃は何を課題だと考えて、どう解決しようとしていたのか」まで含めたスナップショットになっているのがおもしろいです。これからはまた自分が仕事の中で考えたり試したりしたことを、CodeGridを通して返していけたらと思っています。
UIデザイナー 小原 司
サービス開始当初は、まさか700号という数字にたどり着くなんて、運営している私たち自身も想像していなかったのではないでしょうか。でも、ここまで来たからには、もう1000号を目指すしかありませんね！
フロントエンド・エンジニア 宇野 陽太
自分の昔の記事を読み返すと、技術だけではなく、そのときの考え方や判断の傾向が残っていて、アーカイブらしさが出てきたなぁと思います。あらためて読み返すと書き直したくなるような記事もありますが、CodeGridとともに自分も成長したということで……！
理解しているつもりのことも、記事という形で文字に起こそうとしてみると、うまく言語化できなかったり、間違って捉えていたりしていることに気づかされます。毎回少し身に染みますが、そのおかげでとても助かっています。
フロントエンド・エンジニア 小山田 晃浩
自分にとってCodeGridは、アウトプットでありインプット。わかっていたつもりで記事にしても、細部については実は知らなかった仕様や実装が出てくることもあり、書くことはアウトプットでもあり、理解度を深めるためのインプットです。
AIに書かれた出どころがよくわからない文章の氾濫によって情報全体の価値が薄れてきていると感じています。CodeGridでは著者と編集で書き上げ、安心して疑わずに読んでいただけるコンテンツを今後も作っていければと思っています。
フロントエンド・エンジニア 森 大典
プログラミングにも情報を整理しどう組み立てるかという側面がありますが、CodeGridでは同じことを、人に向けて言葉でやることになります。AIを使ってそれらしくまとめるのは簡単でも、本当に伝えたい内容を自問し、その骨子が浮かび上がるまで削っては足し、言葉を選び直すのは難しいと、書くたびに感じます。普段の仕事とは違う方向の力を鍛えてもらっている場所だと思っています。
シニアディレクター 大杉 充
700号のわりに自分の記事数、全然少なくてすみません！ できる・できないじゃねえ、やるか・やらないかだ（記事数少ない人間の言葉）。
フロントエンド・エンジニア 國仲 義則
標準機能だけでもできることが増えて便利になったなあと思います。トレンドの変遷であまり使われなくなった手法もありますが、それも歴史ですね。
CodeGridは、読む人のために説明しようと考えることで自分の理解も深まる、筆者と読者のためのメディア。基礎部分だったり、標準機能を使って何かするといったタイプの記事を多く書いていますが、お役に立てているのならば幸いです。
