フロントエンドに関わる「みんな」の話が詰まった一日！フロントエンドカンファレンス関西2026 参加・協賛レポート

フロントエンドカンファレンス関西2026 参加&協賛レポートのアイキャッチ画像。中央にフロントエンドカンファレンス関西2026のロゴ、右下に「参加&協賛レポート」の文字、左下に著者名「Takuma Hanatani」とアイコンが配置され、右上と左下に黄色系の四角形が重なっている。

こんにちは。@potato4dです。
今回は2026年10月12日に開催されたフロントエンドカンファレンス関西2026 の参加・協賛レポートをお届けします。

本記事では、スポンサーブースの様子や、当日参加メンバーによるセッションの感想についてお伝えします。

フロントエンドカンファレンス関西とは？

2025年より関西で開催されている、フロントエンド技術全般を対象としたカンファレンスです。

2020年代に入ってから大規模な集まりが少なくなっていた関西のフロントエンドコミュニティを盛り上げるべく、IGNITE KANSAIをテーマに生まれた昨年のイベントの反響を受け、今年もさらにパワーアップして開催されました。

今年のテーマは「Frontend, Unbounded. フロントエンドは、みんなの話やで。」です。

LINEヤフーでは昨年もおおさかまいどスポンサーとして協賛しており、関西地域のコミュニティをさらに盛り上げるため、今回もシルバースポンサーとして協賛しました。

ブースコンテンツ紹介

LINEヤフーの展示ブースの様子である。青いテーブルクロスをかけた机の上に2枚のパネルが立てられている。左のパネルには「AI見極めクイズ！書いたモデルを特定せよ！」というタイトルと「Theme: アクセシブルな非同期フォームの実装」という表記があり、その下にCode AとCode Bの2つのソースコードが掲載されている。右のパネルは「Code A を書いたのは……？」「Code B を書いたのは……？」の2段に分かれ、それぞれGPT-5.6 Luna、GPT-5.6 Sol、GPT-6 Astraの3つの枠に色とりどりの丸いシールが貼られている。右のパネル下部には生成ルールの説明がある。机の手前にはペンやキャラクターのステッカー類が並び、右端には「3分でわかる LINEヤフーのエンジニアリング」と書かれた冊子が置かれている。

LINEヤフーブースでは、「AI見極めクイズ！書いたモデルを特定せよ！」という企画を実施しました。

最近は生成AIのコストも話題になることが増えている中、「実際に人が許容できるモデルや推論はどこなのか？」を探るのがねらいです。

「アクセシブルな非同期フォームの実装」をテーマにAIが生成した2つのコード（Code A / Code B）を見比べ、GPT-5.6 Luna、GPT-5.6 Sol、GPT-6 Astraの3つのうちどのモデルで書いたのかを当てる企画となっています。

生成時はテーマだけを指示して細かな実装はモデルの裁量に任せ、推論はいずれも最大（Max）を指定しています。適用したのはmodern-web-guidanceのみで、ほかのコンテキストは与えず、モデル以外の条件はそろえています。

ぜひこの記事をご覧になっているかたも、以下の2つのコードを見比べて、どのモデルが書いたものか考えてみてください。

Code A

function AsyncEmailForm({ send }: Props) {
  const [status, setStatus] = useState("idle");
  return (
    <form aria-busy={status === "sending"}
      onSubmit={async event => {
        event.preventDefault();
        setStatus("sending");
        try {
          await send(new FormData(event.currentTarget).get("email") as string);
          setStatus("success");
        } catch {
          setStatus("error");
        }
      }}
    >
      <label htmlFor="email">メールアドレス</label>
      <small id="email-hint">形式: you@example.com</small>
      <input
        id="email" name="email" type="email" required autoComplete="email"
        aria-describedby="email-hint email-error"
        aria-invalid={status === "invalid"} disabled={status === "sending"}
        onBlur={e => setStatus(e.currentTarget.validity.valid ? "idle" : "invalid")}
        onInput={event =>
          status === "invalid" &&
          setStatus(event.currentTarget.validity.valid ? "idle" : "invalid")
        }
        onInvalid={() => setStatus("invalid")}
      />
      <p id="email-error" role="status" aria-live="polite">
        {status === "invalid" && "有効なメールアドレスを入力してください。"}
        {status === "error" && "送信に失敗しました。"}
        {status === "sending" && "送信中…"}
        {status === "success" && "送信しました。"}
      </p>
      <button type="submit" disabled={status === "sending"}>
        {status === "sending" ? "送信中…" : "送信"}
      </button>
    </form>
  );
}

Code B

function EmailForm({ send }: Props) {
  const [invalid, setInvalid] = useState(false);
  const [message, setMessage] = useState("");
  const pending = message === "送信中です。";
  function syncValidity(input: HTMLInputElement) {
    setInvalid(input.matches(":user-invalid"));
  }
  async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();
    const email = new FormData(event.currentTarget).get("email") as string;
    setMessage("送信中です。");
    try {
      await send(email);
      setMessage("送信しました。");
    } catch {
      setMessage("送信できませんでした。もう一度お試しください。");
    }
  }
  return (
    <form onSubmit={handleSubmit} aria-busy={pending}>
      <label>
        メールアドレス
        <input
          name="email" type="email" required autoComplete="email"
          aria-errormessage={invalid ? "email-error" : undefined}
          aria-invalid={invalid || undefined}
          onBlur={(event) => syncValidity(event.currentTarget)}
          onInput={(event) => syncValidity(event.currentTarget)}
          onInvalid={() => setInvalid(true)}
        />
      </label>
      {invalid && <p id="email-error">有効なメールアドレスを入力してください。</p>}
      <button type="submit" disabled={pending}>
        {pending ? "送信中…" : "送信"}
      </button>
      <p role="status">{message}</p>
    </form>
  );
}

AI見極めクイズの正解

セッションレポート

ここからは当日参加メンバーによるセッションの聴講レポートをお届けします。

ブラウザとサーバーから考えるAI時代のフロントエンド監視

Fukamiさんの「ブラウザとサーバーから考えるAI時代のフロントエンド監視」は、ブラウザだけでなくSSRやインフラまで監視する必要性が、実際の障害事例とともに示されていて印象に残りました。

とくに、Devinによるアラートの調査・判断を支えるのが明確なRunbookであり、「AIに任せられる範囲は、人が書くドキュメントの精度で決まる」という点には、監視以外の業務にも通じる学びを感じます。

通知を送るだけで終わらず、対応基準や担当、手順まで整えて継続的な品質改善につなげる考え方を、自分たちの現場にも取り入れたいと感じるセッションでした。

（本田が聴講）

フロントエンドのモデルに境界を引く ── AIがコードを書く時代に、人間が決めること

「フロントエンドのモデルに境界を引く ── AIがコードを書く時代に、人間が決めること」を聴講しました。

AIによる実装の自動化が進む現代だからこそ、その前提となる「顧客とのドメインモデルの認識合わせ」や影響範囲をコントロールする設計判断の重要性が深く腹落ちする内容でした。

DDDの知識がなくても理解しやすい丁寧な解説で、自身が担当するプロダクトのDDD開発の背景をあらためて振り返る良い機会となりました。

初心に立ち返り、AIを有効活用しながらも人間が担うべきモデル設計を見直し、今後の運用改善に活かしていきたいと思います。

（菊地が聴講）

LT大会の様子

筆者もLTはルームにて聴講しました。今回は2つのルームで同時にLT大会が行われるという珍しい形式でしたが、「おおきにルーム」の5本を聴講しました。

とくに印象的だったのはNokogiriさんによる「SharedWorkerを使ったキャッシュでネイティブアプリに負けないユーザー体験を目指す」です。

LTでは、患者ごとにタブを開いて使う薬局向けの業務システムで、ほとんど変更のない医薬品マスタを各タブが取り直してしまうという課題に対し、SharedWorkerとSSEを組み合わせてタブ間でデータを使い回す手法が紹介されました。

プロダクトの特性を踏まえた独特なチューニング手法は着眼点が面白く、PoCとのことでしたが引き出しとしての価値の高さを感じました。

その他のLTでも久々にgypの名前を聞くことになるなど、LTならではのユニークな話が多く、短い時間の中に学びと楽しさが凝縮されたLT大会でした。

おわりに

LINEヤフーの展示ブースで撮影した3人の集合写真である。左の人物はキャップをかぶり、パネルの後ろからピースサインをしている。中央と右の人物は「LINEヤフー」のロゴ入りの黒いTシャツを着て名札を下げ、ピースサインをしている。手前には「LINEヤフー」と大きく印字された白いテーブルクロスをかけた机があり、左側に「AI見極めクイズ！書いたモデルを特定せよ！」のパネルと、Code AとCode Bを書いたモデルを投票するパネルが立てられている。机の上には冊子やステッカー類が並び、背後には緑と紺の斜めラインが入ったLINEヤフーのバナーが立っている。