はじめに

こんにちは。技術開発室の井上です。

2026年9月12日（土）、福岡にて開催されたフロントエンドカンファレンス福岡2026に参加しました。本記事では、イベントの概要と、特に印象に残ったセッションの内容をご紹介します。

会場とイベントの概要

会場

会場は九州産業大学 12号館の1階でした。キャンパスは想像していたよりも広くて軽く迷いました。

九州産業大学

正面に見えるのが会場の12号館です。

イベントの特徴

参加者は300名以上にのぼったとのことです。

全体を通して、非常に内容の濃いセッションが揃ったイベントという印象を受けました。私がこれまで参加してきたカンファレンスは、10〜30分程度のセッションや5分間のLTを数多く並べる構成が大半でした。一方で本イベントは、すべてのセッションが1本1時間で、いずれも重厚な内容でした。長い昼休憩も設けられておらず、朝から夕方までほぼ途切れることなくセッションが続く構成で、参加者にできる限り多くの知見を持ち帰ってもらおうという運営の強い意志が感じられました。気骨がありますね。

参加の経緯

本イベントはSNSで知りました。昨年の社員旅行で九州を訪れて以来、「そろそろまた福岡行きたい」と思っていたこともあり公式サイトを確認したところ、興味深いセッションが多数予定されていたため参加を決めました。

特に、「とほほのWWW入門」で知られる杜甫々さん、そしてポッドキャスト「リファクタリングとともに生きるラジオ」のlacolacoさんのお話を直接聞いてみたいと思ってました。

アーカイブ配信

各ルームのセッションがYouTubeでアーカイブ公開されています。当日参加できなかった方もぜひご覧ください。

ノベルティ

受付や企業ブースでさまざまなノベルティをいただきましたが、特にありがたかったのがこちらの扇子です。

9月の福岡はまだ暑さが厳しく、実用品として大いに活躍しました。そういえば、技術カンファレンスのノベルティで扇子をいただいたのは初めてかもしれません。

特に印象に残ったセッション

杜甫々が語るフロントエンド開発技術の歴史と今後

「とほほのWWW入門」でおなじみの杜甫々さまによるセッションです。Web黎明期から現在に至るフロントエンド技術の変遷と、今後の展望が語られました。

歴史のお話（一部抜粋）

Yahoo!がディレクトリ型の検索サイトだった頃、おすすめのサイトには「クールマーク」が付いていた。
2002年に出版された『とほほのHTMLハンドブック』は、現在プレミア価格で取引されている。
とほほのWWW入門には、珍しい苗字を調べる目的でのアクセスが多い。

スタイルシート論争

2000年頃、「見た目と意味は分離すべき」というW3Cの理想を重視する立場と、実用的にCSSを使う立場との間で論争があったそうです。その中で杜甫々さんは「仕様だけを先行して策定するのではなく、実装事例と歩調を合わせるべきだ」と主張し、最終的にその意見が受け入れられたとのことでした。

「多少ルーズでもシンプルなものは普及しやすく、厳格で理想を追い求めすぎたものは普及しにくい。広まりやすさも良い仕様の必須条件である」というお話は、仕様や設計を考えるうえで示唆に富むものでした。

杜甫々さんのお気に入りのことわざ

セッションの最後には、杜甫々さんお気に入りのことわざが紹介されました。

覆水ディスククラッシュ
一寸のバグにも五分のデバッグ
一行入魂
人間、笑った回数だけ幸せになる

なぜテストを書くか？

lacolaco（@laco2net）さまのセッションです。発表資料はこちらで公開されています。

「フロントエンドは変更が多いため、テストを書いてもすぐに壊れてしまい費用対効果が低い」という意見はよく耳にします。これに対し、まずロバート・C・マーチン氏の次の言葉が引用されました。

ソフトウェアはソフトになるように考案されたものだ。簡単に変更できないものはハードウェアと呼ぶべきだ。

つまり、ソフトウェアの本質的な価値は「変更が容易であること」にあります。そして、フロントエンドに変更が多いのは変更しやすいと思われているからであり、だからこそ実際に変更しやすい構造を作らなければならない、というのがセッションの出発点でした。

そこから、以下のような論点へと展開されていきました。

心理的な変更容易性と物理的な変更容易性を両立する（参考：変更容易性の2層モデル | lacolaco’s marginalia）
最も起こりうる仕様変更を予測し、それに備える。すべての機能を常に拡張可能にしておくことは不可能である
テストは設計上の問題に気付くための「炭鉱のカナリア」である
型によるテスト駆動開発（型を参照するコードを書く → エラーが解消されるよう型を調整 → 設計を調整）
守りたいパターンを強制するルールをlinterで定義する

途中で紹介された、次の言葉も印象的でした。

水の上を歩くのは、仕様書から開発するのと同じぐらい簡単だ。凍結されているならな

そして最も心に残ったのが、締めくくりのお話です。人間はこれまで、変更容易性の大切さを疲労や苦痛として身をもって感じてきました。しかしAIはその痛みを知らないため、それを取り除こうとする動機を持ちません。だからこそ人間がより鋭い感覚を持ち、代わりに苦しむ必要がある、人間の仕事は苦しむことである、というメッセージでした。生成AIが多くの作業を担うようになった今、人間に残される仕事の性質について改めて考えさせられる内容でした。

フロントエンドUIフレームワークのこれまでとこれから

ssssota（@ssssotaro）さまのセッションです。発表資料はこちらで公開されています。

2004年のGoogle Maps登場がもたらした変革など、Webの歴史を振り返りながら、UIフレームワークの変遷をたどる内容でした。

jQueryは2006年から存在している
かつてKnockoutという宣言的UIライブラリが存在した
Reactはバンドルサイズが大きい
それでもReactが広く使われ続けているのは、周辺ライブラリのエコシステムが圧倒的に充実しているため。React Foundationが設立され、MetaやVercelが支援している

個人的には、Asynchronous SvelteやSignalsなど、まだ触れたことのない技術についても知るきっかけとなりました。

今後のUIフレームワークは、宣言的に記述できる範囲やフレームワークが担う範囲がさらに拡大していくとのことです。また、すべての話題にサンプルコードが用意されており、非常に理解しやすい発表でした。

Webの地図

古川陽介（@yosuke_furukawa）さまのセッションです。発表資料はこちらで公開されています。

「fetchはECMAScriptでは定義されていない」という話題から始まり、Webの仕様を誰が策定しているのかを、大陸に見立てた地図を用いて解説する内容でした。

おおまかな流れは以下のとおりです。

ティム・バーナーズ＝リーがWebを作り始め、まずHTML・HTTP・URLが生まれる。当初は特に枠組みが存在しなかった
HTTPとURLはIETFが管理するようになる
JavaScriptは約1週間で開発された。MicrosoftはInternet ExplorerにJScriptを搭載したが、APIが異なっていた
JavaScriptの作者はW3Cに仕様策定を依頼したが受け入れられず、別団体（Ecma International）で管理されることになった
HTMLはWHATWG、CSSはW3Cが策定している
XMLHttpRequestはHTTPとJavaScriptの両方にまたがり、複数の団体が関わっていた。一時W3Cが管理し、その後WHATWGに引き継がれた

冒頭のfetchについては、ECMAScriptはJavaScriptのコア機能のみを定義しており、fetchは実行環境から外部的に提供されるオブジェクトとして扱われているとのことでした。クロスオリジンやCookieとも関わるため、ブラウザの仕様を策定する団体が管理するほうが自然だという説明には納得感がありました。

「一社がブラウザを独占してしまうと産業は発展しない。競争は促したいが、独占は避けたい」。仕様は今も昔も、強者による独占を防ぐための枠組みとして機能してきた、というお話が印象的でした。

誰がどの仕様を決めているのかを知らなくても、日々の開発で困る場面は多くありません。しかし、背景を知ることで技術への理解が深まることを実感したセッションでした。

安心して変更できるWebフロントエンドのつくり方

穴井宏幸（@pirosikick）さまのセッションです。

自動テストがなければ安心して変更はできません。テストを書くべき理由を整理したうえで、実際に取り組んでみた結果どうだったのか、という実践のお話が中心でした。

テストファイルやテストケースの数は大きく増えたものの、体感としては満足できる状態には至っておらず、特に変更に不安を感じるページほどテストの導入が進んでいないという課題があったそうです。

「早く成果を出したい」というプレッシャーの影響もありますが、何らかのプレッシャーは常に存在します。そのうえで、書けたテストと書けなかったテストの違いは何だったのかを、ソフトウェアのテスト容易性の観点に当てはめて分析したところ、

単純性：実装がシンプルかどうか
理解容易性：仕様がシンプルかどうか

に違いがあったとのことです。

構造をシンプルにするリファクタリングにはテストが必要である一方、コードが複雑なためにテストが書けない、というジレンマがあります。これに対しては、

ユニットテストを増やし、小さな改善を地道に積み重ねる
思い切って先にコードを整理する（AIの支援を受けることでミスを抑えやすい）
手動でのQAとコードレビューを徹底する

といった選択肢が挙げられましたが、いずれもドメインへの深い理解が前提になるとのことでした。

また、手間がかかるためにテストが書かれない、という現実的な課題にも触れられました。その対策として、UIの状態を確認しやすくする関数、UI操作用のヘルパー関数、共通で利用できるモックデータなど、手間をかけずにテストを書ける仕組みを整備することが提案されていました。

AI時代で何が変わったか

現在では、指示を出せばAIがコードやテストを書いてくれるのは当然となり、UIのテストも特に指示しなくても生成してくれるようになりました。ただし、次のような注意点が挙げられていました。

AIはモックを多用する傾向がある。 モックが散在するのを避けるため、テスト用のFakeコンポーネントを基盤として提供するとよい
テストケースが仕様ではなく実装に寄りがちになる。AIが自ら書いたコードの動作確認のためのテストになってしまう

そのため、AIが書くのは基本的にユニットテストであると考え、結合テストは人がドメインを理解したうえで書くべき、というのがセッションの結論でした。

lacolacoさんの「人間の仕事は苦しむこと」というお話と同様に、ドメインを理解し設計に責任を持つのは人間の役割である、という結論に行き着いていた点が印象的でした。

懇親会

懇親会では、大量の料理が振る舞われました。このカンファレンスは情報量だけじゃなく飯も多い。

懇親会の料理

鯛の姿造り

もつ鍋

お話ししてみたかった方々とも交流でき、大変有意義な時間となりました。

おわりに

テックカンファレンスは何回参加しても良いですね。

お知らせ・ブログ