はじめに

DE-TEIUです。

2026/09/12(土)、福岡にて開催された最高のイベントフロントエンドカンファレンス福岡2026に参加してきました。感想を書いていきます。 ちなみに先日収集した公開済の発表資料一覧はこちら

会場とイベントの話

会場

会場は九州産業大学の12号館の1Fでした。 イベント前日にアクセス方法だけ確認して、大学の雰囲気とか大きさとかは特に調べずに行ったんですが、思ったよりデカくて一瞬迷いました。

正面に見えるのが12号館。

イベントについて

参加者は300人以上いたらしいです。多い。たぶん映画ちいかわの観客動員数ぐらいある。

全体としては、骨太なセッションしかないな！ という印象を受けました。 私が今まで参加したカンファレンスは、10～30分ぐらいのセッションや、5分のLTがたくさんある、という構成のものがほとんどでした。 しかし、今回はすべてのセッションが1本1時間で、内容も重厚なものばかりでした。 おまけに長めの昼休み的なものも無く、朝から夕方までほぼノンストップで濃い内容のセッションが聞けるというものでしたので、「何が何でも参加者に大量の情報をインプットして帰ってもらおう」という、運営の力強い意思を感じました。

参加した理由

ある日Twitterを眺めていたら、このイベントの情報が流れてきました。 去年の社員旅行で九州に行ってから、わりと福岡が好きになっていたので「ちょっと面白そうなセッションがあったら行くか」ぐらいの軽い気持ちで公式ページを見てみたら、どれも面白そうな内容だったので参加を決意。

特に「とほほのWWW入門」の杜甫々さんや、「リファクタリングとともに生きるラジオ」のlacolacoさんの話を直に聞いてみたかった。

ハッシュタグに投稿されるツイートについて

このイベントのハッシュタグは#fec_fukuokaでした。 このハッシュタグでイベントの前日～当日～翌日あたりのツイートを眺めていてふと思ったんですが、今回はあまり現地の飯とか観光してる様子のツイートが流れてきませんでした。 北海道のカンファレンスだと、わりと参加者がカンファレンスの前日や翌日に美味い飯食ったり軽く観光してる様子をハッシュタグつきでツイートしてるイメージがあるんですが、地域性の違いみたいなものがあるんですかね？

アーカイブ

イベントの後日、YouTubeにアーカイブが公開されました。これはたすかる。

• Room Aのアーカイブ
• Room Bのアーカイブ
• Room Cのアーカイブ

余談

当日Twitterのトレンドを見たら、なぜか他所のぬい活と混ざっていました。なしてさ。

ノベルティ

受付時や企業ブースを軽く見て回った際にノベルティを色々いただいたのですが、特にこの扇子が良かったですね。

9月の福岡はまだ全然暑かったので、これは普通に実用品として活躍しました。 そういえばテックカンファレンスのノベルティで扇子をもらったのは初めてな気がする。

特に刺さったセッション

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

「とほほのWWW入門」でおなじみ、杜甫々さんのセッションです。 Web黎明期から現在までのフロントエンド技術の変遷と、これからの話が怒涛の勢いで語られました。

歴史の話(特に気になったところのみ抜粋)

• 1997年頃、Unisys社がGIFの圧縮に関する特許を持っていたため、フリーのGIF画像連結ソフトなどの開発ができなかったらしい。 そういえば聞いたことある気がする。小学生か中学生ぐらいのとき、IrfanViewの使い方とか調べてるときに見たような。
• Yahoo!がディレクトリ型の検索サイトだった頃、おすすめのサイトには「クールマーク」がついていた。
• 2002年に出版されたとほほのHTMLハンドブック、なにやら現在プレミアがついて結構な値段になっているらしい。
• 2009年、とほほ死亡説が流れた（同じ地域で別の活動をしていた、別の「とほほ」さんの訃報だったらしい）

あと、とほほのサイトには珍しい苗字を調べに来るアクセスが多いらしいです。

スタイルシート論争

2000年頃、「見栄えと意味は分離すべき」というW3Cの理想に感化された人たちと、普通にCSSを使っている人たちとの間で喧嘩があったそうです。 その中で杜甫々さんは「仕様ばっかり先行して策定してないで、実装事例と歩調を合わせろ」と主張し、最終的にその意見が認められたとか。

「多少ルーズでもシンプルなものは普及しやすく、厳格で理想を求めすぎたものは普及しにくい（IPv6とか）。『広まりやすさ』も良い仕様の必須条件」という良い話を聞けました。

最近の話とこれからの話

後半は最近のWeb標準の新機能が大量に紹介されました。

• selectedcontent要素が追加された
• geolocationやusermediaといったタグが議論中。Chromeでは先行サポートしている。JSで頑張って呼び出しを実装しなくて良くなる？
• 2026/06に、新たなHTTPメソッド QUERY が生えた。GETだけどbodyを持てる
• CSSでネストできる、変数が使える、if文が書ける…ということで、SCSSがあんまり要らなくなってきた
  • ちなみにCSSに継承が無いのは、設計思想的にNGだかららしい
• JSのクラス内で、デストラクタっぽいものが書ける（using / await using）
• Prompt API で、JSからローカルLLM（Gemini Nano）を呼べる。マジ？？？？？？

そしてTemporalの話も出てきました。どのフロントエンドカンファレンスに行っても必ずTemporalの話が出るなぁ。流行りものかな。

AIとの付き合い方

「仕事だと管理業務ばかりなので、定年退職後は細々とプログラミングの仕事がしたいと思っていたら、AIが出てきた。そして完敗した。」とのこと。

あと Copilotとは喧嘩別れ中 だそうです。 Wikipediaのリンクを貼ってくれと何回言ってもやってくれなくて文句を言うだけ言って使うのを止めようとしたら、最後にAIが 「黙って去るのではなく理由を言葉にしてくれたのが嬉しかった」みたいなことを言い始めて、ちょっと許しそうになったとか。わかる。

杜甫々さんのすきなことわざ

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

ナルホドね たしかに良いわこれ

なぜテストを書くか？

lacolaco(@laco2net)さんのセッション。発表資料はこちらにあります。

「フロントエンドは変更が多いから、テストを書いても壊れやすい。なのでコスパが悪い」…って言われがちですよね。そのイメージあるなぁ。

これに対して、まずボブおじさん（ロバート・C・マーチン）の言葉が引用されます。

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

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

ここから

• 心理的な変更容易性と物理的な変更容易性を両立する（参考：変更容易性の2層モデル | lacolaco’s marginalia）
• 最も可能性の高い仕様変更を予想して、それに備えておく。すべての機能を常に拡張可能にするのは不可能
• テストは、設計の怪しさに気付ける炭鉱のカナリア
• 型によるテスト駆動開発（型を参照するコードを書く→エラーが無くなるように型を調整→設計を調整）
• 満たしたいパターンを矯正するルールをlinterで書く

と、話が展開されていきます。開放閉鎖原則も出てきました。リファラジでめっちゃ聞いたやつだ。

途中で紹介された

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

という言葉がとても良かった。

そして最後の話がとても印象に残りました。 人間は変更容易性の大切さを、体で（疲れや痛みとして）感じてきた。しかしAIはその痛みを知らないから、それを取り除きたいという欲求がない。 だから人間がより強い嗅覚を持って、代わりに苦しむしかない。人間の仕事は苦しむこと。

実際、最近は生成AIが人間の楽しいタスクを奪っているせいで、人間の手元にはわりとめんどくさいタスクしか残ってないことありますよね。根回しとか。

余談

lacolacoさん、話の最中にフィラーが全然出てなかった気がする。ゆるコンピュータ科学ラジオの堀元さんみたいに意図的に消してるんだろうか。 あとセッションのちょうど半分ぐらいでチャイムが鳴ってました。

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

ssssota(@ssssotaro)さんのセッション。発表資料はこちら。

Webの歴史（2004年にGoogle Mapsが出て革命が起きた話とか）から始まり、UIフレームワークの変遷をたどっていく内容でした。

• jQueryって2006年からあったのか。そんなに古いか
• Knockoutという宣言的UIライブラリがあったらしい。通ってない。うっすら（だいぶうっっすら）Svelteっぽい？
• Reactのバンドルサイズはデカい。そうらしい
• それでも今なおReactがめっちゃ使われているのは、圧倒的な周辺ライブラリがあるから。React Foundationという組織ができて、MetaやVercelが支えている

Asynchronous Svelte、知らなかった。まだ実験的機能？あとで調べよう。 そういえばSignalsも実はまだ使ったことない。

これからのUIフレームワークは、宣言やフレームワークが担う範囲が拡大していくとのこと。 UIフレームワークの宣言が拡大していったら、テストももっと書きやすくなったりするのかな。そうでもない？

あと、何の話をするにしても常にサンプルコードが用意されていて素晴らしかったです。

Webの地図

古川陽介(@yosuke_furukawa)さんのセッション。発表資料はこちら。

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

ざっくりこんな流れ。

• ティム・バーナーズ＝リーがWebを作り始め、とりあえずHTMLとHTTPとURLが作られる。その頃は何の枠組みもない
• HTTPとURLはIETFが握る
• JavaScriptは1週間で開発された（Gitみたいだな）。MicrosoftはIEにJScriptを同梱したが、APIが違う
• JavaScriptの作者がW3Cに仕様策定を頼んだが断られ、しぶしぶ別団体（ECMA）で管理することに
• HTMLはWHATWG、CSSはW3C
• XMLHttpRequestはHTTPでもありJavaScriptでもあり、色んな団体が絡んでいた。いったんW3C持ちになり、その後WHATWGに引き継がれる

で、冒頭のfetchの話に戻ると、ECMAScriptはJavaScriptのコアな機能だけを決めていて、fetchは「実行環境として外側から注入されるオブジェクト」という扱いになっている。クロスオリジンやCookieの話も絡むし、ブラウザの仕様を決める団体が持つほうが違和感がない、ということでした。なるほど。

「一社の企業にブラウザが独占されてしまうと産業が発展しない。競争はしてほしいが、独占は避けたい。」 今も昔も、仕様は独占されないように強者を縛る鎖だった、という話が良かったです。

あと、杜甫々さんのキーノートに続いて「文書の構造と装飾表現は分離されるべき」という話がまた出てきました。

こういう「誰がどの仕様を決めているのか」という話は、知らなくても開発で困ることはあまりないけど、知ってたら技術に対する解像度が上がって面白いですよね。

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

穴井宏幸(@pirosikick)さんのセッション。

自動テストがないと安心して変更できない。それはそう。 テストを書いた方が良い理由を一通り挙げたうえで、「実際に実践してみてどうだったか」という話がメインでした。

テストファイルやケース数はかなり増えた。しかし体感では満足できていない。変更に恐怖を感じるページへのテスト導入が進んでいない。なしてさ。

「早く成果を出したい」という圧に負けた、というのはある。でも何かしらの圧は常にあるわけで、その状態で書けたテストと書けなかったテストの違いは何か。 それをソフトウェアテストの容易性（7つあるやつ）に当てはめて考えてみたら、

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

が違った、とのこと。「それはそう」って感じだなぁ。

リファクタリングして構造をシンプルにするにはテストが必要。しかしコードが複雑でテストが書けない。デッドロックやんけ。 これに対しては、

• UnitTestを増やして小さな改善を地道にやる（めっちゃ我慢が必要）
• 思い切って先にコードの整理をやっちゃう（AIにサポートさせればミスは起きにくい）
• 手動でQAとコードレビューをめっちゃ頑張る

といった選択肢があるが、どれをやるにしてもドメイン理解が浅いとできない。

あと単純にめんどくさがってテストを書けなかった、というのもあるそうです。わかる。 ということで、怠惰でも書ける仕組み（UIの観測を楽にする関数、UI操作用のヘルパー関数、共通で使えるモックデータの充実など）を用意しよう、という話でした。

AI時代で何が変わったか

指示を出せばコードもテストも書いてくれるのは当然として、UIのテストも特に指示せずとも勝手に書いてくれるようになった。 ただし、

• AI、めっちゃモックする。 モックがそこら中に散らばるのが良くないので、テスト用のFakeコンポーネントを基盤として提供すると良さそう
• テストケースが仕様じゃなくて実装に寄りがち。AIが「自分が入れたコードの動作確認」のために書いたテスト、という感じになる

ということで、AIは基本的にUnitTestしか書かないと思ったほうがいい。IntegrationTestは人がちゃんとドメインを理解して書きましょう、とのことでした。

lacolacoさんの「人間の仕事は苦しむこと」に続いて、ここでも「ドメインを理解する」「設計の責任を持つ」のは人間の仕事、という結論になっていたのが面白かったです。

懇親会

このイベント、情報量だけじゃなくてメシも多かった。すばらしい。

話してみたかった方々ともお話できたので満足。

ところで、今回のイベントの参加者の中に、フロントエンド&PHPカンファレンス北海道2026のTシャツを着ていた方がいて、「これ俺も着るべきやったな」と反省。 確かに着てた方がちょっとした話題作りに使えるなぁ。

おわりに

次回も行きたい。まず福岡がメシも美味くて楽しい。

余談

せっかくモツ鍋を食ったので、それをテーマにしたゲームを作りました。

---