はじめに

AI開発エージェントで手早くUIを構築できる時代に、逆張りでフロントエンドに興味がわいています。バックエンドの言語のカンファレンス参加が多かったので、今回初めて参加してみました。

今さら理解するウェブフォント2026

シンプルにフォントの裏側がどんな流れになっているのか知る機会として面白かったです。

日本語フォントは重いんだ！！初めて知りました笑
圧縮とサブセットが鍵となること。

対策やお作法もあり、聞いていて面白いセッションでした。

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

フロントエンドという観点でアプリケーションの監視をどう設計するか？という内容でした。実際にメリット・デメリットの訴求もあり勉強になりました。

発表内容がSRE的というのか.....フロントエンドの領域が組織を越境せざるをえない状況でリアリティがあっておもしろかったです。

SPAの時代では「HTML・CSS・JavaScriptなどの静的ファイル（ビルド成果物）をCDNなどのツールにアップロードするだけだったのが、SSRになり、サーバーとしてのみるべきものが増えた気がします。

Vercelなどのような（いわゆるPaaS）のツールをインフラで使っていれば、　PaaSにお任せしていればよいのですが実務というとそうはいかず、この辺りの知見は現場の話に近いなと思って聞いていました。

選択と集中で対応範囲を絞る

アラートでアプリケーションのエラーを通知させるも、対応が絞れない課題に直面。

Q1. 自分たちで修正可能か？（外部ツール、たとえばGoogleの拡張ツールの挙動とかではないか）
Q2. 壊れたら売り上げに影響がありそうか？

上記2点に基づいて、対応するかどうかを分けたのが本質的な印象を感じました。

優先度をタグつけしてチームで回せる仕組みを検討する

ただ、対応するといっても誰もやらなかった。（まあそうだよね〜。あんまり好んでやる人いないよね笑笑笑）

優先度をタグつけ（P1、P2....）してチームで進めたのもしかり、Runbook書いて属人性を排除していこうぜ！という動きもめちゃくちゃよかったです。

イベントベースでAIを駆使しながら対応のワークフローを組んでいったのも興味深かったです。（これ普通に組みたい！）

Runbookが肝になってくると感じました。
アラートの全量を出してから種別わけして、対応するものをよさそう

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

仕様の理解ってむずかしいけど、仕様書をかくまでではないきがしていて....回収がしやすいかしにくいか？を把握するって結構難しいきがしています。

ドメインモデリングをしていって手をいれやすくしようね！という話ですが、フロントエンドでモデリングという切り口が新鮮でした。

明日から仕様を変えよう！と思っていても、業務的に影響範囲が大きいとなかなか手を出しづらいなとも思いつつ...

フロントエンドのモデルとは何を決めているのか？「表示制御」という切り口で考えたのが面白かったです。

.ts

// 1. APIレスポンスの型（サーバーの都合で決まる形）

type OrderDetailResponse = {
  id: string;
  status: "PENDING_PICKING" | "PICKING" | "PACKED" | "SHIPPED" | "DELIVERED" | "CANCELLED";
  paymentStatus: "AUTHORIZED" | "AUTHORIZATION_FAILED" | "CAPTURED" | "REFUNDING" | "REFUNDED";
  totalPrice: number;
};

.ts

// 2. フロントエンドの概念型（ルールに必要なものだけ抽出）

type OrderStatus = 
  | "PENDING_PICKING" 
  | "PICKING" 
  | "PACKED" 
  | "SHIPPED" 
  | "DELIVERED" 
  | "CANCELLED";

type Order = {
  id: string;
  status: OrderStatus;
};

// 腐敗防止層：APIレスポンスを概念型に変換する
// ここが大事
const toOrder = (res: OrderDetailResponse): Order => ({
  id: res.id,
  status: res.status,
});

.ts

// 3. ルール（振る舞い）の定義：判定ロジック
type CancelReason = "fulfillmentStarted" | "alreadyCancelled";
type CancelDecision = 
  | { can: true }
  | { can: false; reason: CancelReason };

const decideCancel = (order: Order): CancelDecision => {
  switch (order.status) {
    case "PENDING_PICKING":
      return { can: true };
    case "PICKING":
    case "PACKED":
    case "SHIPPED":
    case "DELIVERED":
      return { can: false, reason: "fulfillmentStarted" };
    case "CANCELLED":
      return { can: false, reason: "alreadyCancelled" };
    default:
      const exhaustiveCheck: never = order.status;
      return exhaustiveCheck;
  }
};

.ts

// 4. Presentationalコンポーネント（見た目・UIの制御）
// statusの値やAPIのことは知らず、渡された判定結果（cancel）だけを元に表示する

type PresentationalProps = {
  cancel: CancelDecision;
  onCancel: () => void;
};

const reasonLabel: Record<CancelReason, string> = {
  fulfillmentStarted: "出荷準備が始まったため、キャンセルできません",
  alreadyCancelled: "この注文はすでにキャンセル済みです",
};

export const OrderDetailUI: React.FC<PresentationalProps> = ({ cancel, onCancel }) => {
  return (
    <section style={{ padding: '20px', border: '1px solid #ccc', borderRadius: '8px' }}>
      <h3>注文詳細</h3>
      
      {/* 判定結果に基づいてボタンの有効/無効を切り替える */}
      <button 
        disabled={!cancel.can} 
        onClick={onCancel}
        style={{ padding: '8px 16px', cursor: cancel.can ? 'pointer' : 'not-allowed' }}
      >
        注文をキャンセル
      </button>

      {/* キャンセル不可の場合の理由を表示 */}
      {!cancel.can && (
        <p style={{ color: 'red', marginTop: '8px' }}>
          {reasonLabel[cancel.reason]}
        </p>
      )}
    </section>
  );
};

.ts

// 5. Containerコンポーネント（データの取得と組み立て）
// （本来はここでAPIカスタムフックなどを呼ぶイメージ）
export const OrderDetailContainer: React.FC<{ orderId: string }> = ({ orderId }) => {
  // 仮のAPIレスポンス取得
  const mockApiResponse: OrderDetailResponse = {
    id: orderId,
    status: "PICKING", // ここを変えると状態ごとのUIの動きを確認できます
    paymentStatus: "CAPTURED",
    totalPrice: 5000,
  };

  // 1. 概念型に変換
  const order = toOrder(mockApiResponse);

  // 2. ロジック（判定）を適用
  const cancelDecision = decideCancel(order);

  // 3. アクションの定義
  const handleCancelOrder = () => {
    alert(`注文 ${order.id} のキャンセルAPIを叩きます`);
  };

  return (
    <OrderDetailUI 
      cancel={cancelDecision} 
      onCancel={handleCancelOrder} 
    />
  );
};

APIの生データをそのままコンポーネントのあちこちに散りばめて if 文を書くのではなくて、一度ドメインの概念（ルールの関数）に変換してから、スッキリした状態でUIに渡す。

コードの見通しは良くなった印象を感じました。鋭意ドメインエキスパートと調整が必要性ですが....

おわりに

AIの影響を受けながらも、フロントエンドの課題がフロントエンドとしての課題なのか？（SREが本来やる対応でもある？）を考えさせられるSessionが多かったです。

AI Basedで実装をやっていることもあり、コードをすべてよむことはないですが、これを機に読み返してみるもの良いなと思いました。