フロントエンド

リリース直後に「本棚が開けない」という問い合わせが届きました。本棚は購入済み作品の一覧を表示する画面です。リリース前から開いたままのタブで操作を続けたケースでした。ブラウザが読み込んでいるフロントエンドは古く、バックエンドだけが新しい状態です。 CDNのキャッシュはデプロイ時に削除済みです。それでも直りませんでした。 原因はキャッシュが1層ではなかったことです。CDNのパージが届かないキャッシュを、ブラウザ側に2種類残していました。加えて、フロントエンドとバックエンドのバージョンがそろわない状態への備えも足りていませんでした。 先に結論を3点書きます。 CDNのキャッシュ削除が消せるのはエッジまでで、各ユーザーのブラウザHTTPキャッシュには効かない 静的エクスポートしたHTMLにCache-Controlを付けないと、ブラウザが独自の基準でキャッシュする キャッシュ制御とバージョン不整合の検知は、片方だけ実装しても機能しない 前提とする構成 担当しているサービスのフロントエンドは、次の構成で動いています。 Next.js 13.4.7の静的エクスポート（TypeScript、Pages Router） 成果物をオブジェクトストレージ（Alibaba Cloud OSS）に配置し、CDNで配信 APIはGraphQL（graphql-requestと自動生成SDK） バックエンドはフロントエンドと別リポジトリで、デプロイも別 flowchart LR Build["ビルド<br/>next build → 静的エクスポート"] --> OSS["オブジェクトストレージ<br/>Alibaba Cloud OSS"] OSS --> CDN["CDN<br/>エッジキャッシュ"] CDN --> Browser["ブラウザ<br/>HTTPキャッシュ / sessionStorage"] Browser -->|"GraphQL + Client-Version"| API["バックエンド<br/>別リポジトリ・別デプロイ"] 重要なのは、HTMLとJavaScriptがサーバー側でレンダリングされない点です。ブラウザが取得したHTMLと、そこから読み込むJavaScriptチャンクの組み合わせが、そのユーザーにとっての「アプリのバージョン」です。この組み合わせが古いまま固定されると、リリース内容が届きません。 何が起きたか 報告された症状は3つです。 リリース前から開いていたタブで本棚を開くと、画面が壊れる ログアウトして再ログインするまで、リリース内容が反映されない 既存のタブから派生した別のタブで、前のバージョンのデータが表示される 3つには共通点がありました。全ユーザーには起きておらず、CDNのキャッシュを削除しても直りませんでした。そしてログアウトすると直りました。 CDNのキャッシュ削除で直らない事実は、原因の切り分けに使えます。CDNのパージはエッジのキャッシュを消す操作です。エッジを消しても直らないなら、原因はエッジより先、つまりクライアント側にあります。 ブラウザ側にもキャッシュが2種類あった 整理すると、キャッシュはCDNエッジだけではありません。ブラウザ側にも2種類あります。 層 主に保持するもの 消えるタイミング CDNのパージで消えるか CDNエッジ HTML・JavaScript・画像 TTL満了、またはパージ 消える ブラウザHTTPキャッシュ HTML・JavaScript Cache-Controlの指定次第 消えない sessionStorage 画面表示用のデータ タブを閉じる、または明示的な削除 消えない ブラウザHTTPキャッシュ側の問題は2つありました。 1つは、静的エクスポートしたHTMLにCache-Controlが付いていなかったことです。レスポンスに明示的な有効期限がない場合、ブラウザはヒューリスティックキャッシュを行います。つまりLast-Modifiedなどから独自に鮮度を推測して、一定時間は再取得しません。開発者が指定していないだけで、キャッシュしない設定にはなりません。 もう1つは、アップロード方法です。ossutil cp --updateは更新されたファイルを上書きしますが、以前のビルドで生成された古いチャンクを削除しません。結果として、古いHTMLをキャッシュしているブラウザは、そのHTMLが参照する古いJavaScriptチャンクをそのまま読み込み続けます。 ...

はじめに こんにちは。and factory フロントエンドエンジニアの坂内です。 施策バナーなどの画像をFigmaから書き出す作業が、地味に手間だと感じていました。1枚ずつ選択してエクスポートし、書き出したPNGを別のツールでWebPに変換して圧縮する。作業自体は難しくありませんが、工程が分断されているぶん、都度の切り替えコストがかかります。 直近の施策では15枚ほどを書き出しました。枚数だけ見れば多くありませんが、1枚ごとに書き出しと変換を往復すると、それなりの時間を取られます。 きっかけは、会社で契約しているツールをもっと使い倒せないか、コーディングまわりをもう少し楽にできないか、と考えたことでした。調べるうちにFigmaのDev Mode MCPサーバーに行き着き、Claude Codeとつないで検証しています。この記事はその記録です。 やってみると、事前の想像と違う結果がいくつも出てきました。想定していたより権限のハードルが低かった一方、単発なら手動のほうが速いという結果も出ています。「圧縮したのにファイルが大きくなる」という予想外の挙動もありました。 注意： 本記事に登場するFigmaのレイヤー名とファイル名のうち、施策名や機能名を含むものは仮名に置き換えています。スクリーンショットでも該当箇所を伏せています。数値はすべて実測値です。 結論 先に結果を3点にまとめます。 指定する範囲が速度をほぼ決める。ページ全体に近い範囲を渡すと68点を一括で取得できたが、時間がかかった 1枚だけなら手動のほうが速い。AIを挟む価値は書き出し単体ではなく、書き出しから変換までを1つの指示で通せる点にある WebP変換は画像の種類で品質を分ける必要がある。70ファイルで合計38.2%削減できた一方、4点は逆にサイズが増えた 検証環境 項目 内容 実施時期 2026年7月 OS macOS Figma デスクトップアプリ（Dev Mode MCPサーバーはデスクトップ版のみ対応） Figmaのプラン 有料プラン AIクライアント Claude Code 変換ツール sharp 0.35.3（npx 経由で実行。Node 20.9以上が必要） Node.js v20.9.0以上（sharp 0.35.3の要件） 対象 ある施策ページのデザイン（最終的に70ファイルを取得） その前に：URLを渡すだけでは足りなかった MCPの設定を始める前に、claude.aiにFigmaのデザインURLをそのまま渡して画像を取得できないか試しました。結果は Site blocked the request (bot detection) でブロックされ、ページ自体を読み取れません。Figmaは認証が必要なサービスなので、汎用のWeb閲覧機能では中身に到達できないためです。 画像を扱うには専用の接続が要ると分かったので、MCPの設定に進みます。 権限は思ったより障害にならなかった 次に気にしていたのが権限です。Figma MCPサーバーのガイドには、デスクトップ版サーバーの利用にDev/Fullシートを含む有料プランが必要と書かれています。この記述を読んで、管理者にシートのアップグレードを相談する必要があるかもしれない、と身構えていました。 ところが実際に画面を開いてみると、特別な手続きなしでMCPサーバーを有効化できました。管理者への確認は不要でした。 調べ直すと、別ページのRate limits & accessに補足がありました。View / Collabシートにも月6回までのツール呼び出し枠が用意されており、有料プランでもこの上限が適用されます。アクセスはプランとシート種別の両方で決まります。View / Collabシートはプランに関わらず月6回で頭打ちです。一方、Dev / Fullシートの上限はプランで変わります（Starter・Professionalは1日200回、Organizationは1日600回）。 つまり、Dev/Fullシートでなければ一切使えない、というわけではありません。回数は多くないものの、検証や小さく試す段階であれば足ります。 同じところで足踏みしている方もいそうなので書いておくと、権限の相談より先に、自分の環境で有効化できるかを試すほうが早いです。シート種別はチームや組織の管理画面から確認できます。ただ、まず動かしてみたほうが話の早い場面もあります。仮に権限が足りなかった場合も、デザイナーの環境で有効化してもらい、そこへ接続する方法が残っています。 ...

はじめに こんにちは。and factory フロントエンドエンジニアの坂内です。 前回はClaude Designを実案件で試した記事を書きました。ワイヤーフレームを作るならFigmaが候補に挙がりますが、普段はデザイン確認専用に使っていました。ディレクターへ共有するモックが必要になったとき、Figmaの使い方を調べながら進めるより手軽な方法を探していた、というのが前回の出発点です。 その後、同僚から「Google Stitchというツールがある」と教えてもらいました。同じくAIでUIを生成するツールですが、Googleが作っている点と無料で使える点が違います。前回とまったく同じお題を投げたら、出てくるものはどう変わるのか。 特にエンジニアとして受け取る側から見て、実装の手触りに差が出るのかを確かめたくなりました。それが今回の動機です。 調べ始めると、Stitch単体の話ではないと分かりました。v0・Lovable・Bolt.newといったツール群が「Vibe Design」という潮流を作っており、それぞれ狙っている領域が違います。この記事では、フロントエンドエンジニアとして「生成物を受け取る側」の視点から、Vibe Designツールの現在地と実務での使いどころを整理します。 注意： 本記事の内容は2026年7月時点の情報に基づいています。StitchはGoogle Labsの実験プロジェクトであり、機能・料金・UIの変更が頻繁に発生します。最新の情報は公式サイトを確認してください。 結論 先に持ち帰ってほしいポイントを3つに絞ります。 Vibe Designツールは「どれが最強か」ではなく「出口が何か」で選ぶ。デザイン案が欲しいのか、Reactコンポーネントが欲しいのか、動くアプリが欲しいのかで最適解が変わる Stitchはプロンプトをそのまま描かず、デザインシステムを立ててから解釈する。「ピンクのヘッダー」という指示が濃紺サイドバー + ピンクのアクセントに変換された理由が、生成されたDESIGN.mdに書かれていた DESIGN.mdによるDesign System as Codeの流れが本命。デザイン制約をMarkdownで記述してAIエージェントに読み込ませる発想は、デザイナーとエンジニアの連携そのものを変える可能性がある 「Vibe Design」とは何か 「Vibe Coding」という言葉を聞いたことがある方は多いはずです。元OpenAIのAndrej Karpathyが2025年初頭に提唱した概念で、コードの細部を自分で書かずに意図や雰囲気をAIへ伝えて生成させるスタイルを指します。 その波がデザイン領域にも来ました。Vibe Designとは、「こういう画面にしたい」という意図をプロンプトで伝え、レイアウト・配色・タイポグラフィまでAIに一括生成させる進め方です。ピクセル単位でUIを組み上げる従来の手順とは発想が異なります。 UX研究者のJakob Nielsenも、UIがハードコーディングされる時代から意図とコンテキストに基づいて生成される時代へ移行すると述べています。業界全体がその方向に動き始めています。 Vibe Designツールを「出口」で分類する ツールを比較するうえで最初に整理したいのが「出口」の違いです。何が手元に残るのかを揃えないと、比較がかみ合いません。 ツール 主な出口 バックエンド 主な対象 料金 Google Stitch UIデザイン案 + コード なし デザイナー・フロントエンドエンジニア 無料 v0 by Vercel Reactコンポーネント なし フロントエンドエンジニア 月額 $30〜 Lovable 動くフルスタックアプリ あり（Supabase） 非エンジニア〜フロントエンド 月額 $25〜 Bolt.new 動くフルスタックアプリ あり エンジニア寄り 有料プランあり Figma Make Figma上のインタラクション なし デザイナー Figmaプランに依存 大きく2カテゴリに分かれます。 ...

はじめに こんにちは。and factory フロントエンドエンジニアの坂内です。 ワイヤーフレームを作るとなればFigmaが候補に挙がりますが、普段はデザイン確認専用に使っていました。いざ自分で作るとなると使い方を調べながら進める必要があり、「もっと手軽に作れないか」と思っていました。ちょうど機能追加でディレクターへ共有するためのモックが必要になったタイミングで、AnthropicのAIデザインツール「Claude Design」を見つけ、試してみました。 あくまでワイヤーやモック用途での活用として、「ディレクターやデザイナーと連携するフロントエンドエンジニアにとって、どう使えるか」という観点で使いみちを探りました。 注意： Claude Designはリサーチプレビュー段階のツールです。UIや機能仕様は今後変更される可能性があります。本記事の内容は2026年6月時点の情報に基づいており、最新の状況と異なる場合があります。 結論 先に持ち帰ってほしいポイントを3つに絞ります。 スクリーンショット＋テキスト指示だけでデザイントーンに合ったワイヤーが生成できる（既存画面のピンク×サイドバー構成を再現） バリデーション・APIペイロードまで自発的に実装してくれるため、エンジニアへの引き継ぎ資料が副産物として得られる 「Claudeチャットで仕様を固めてからDesignに渡す」2段階フローが現実的。Claude Designは細かい修正の往復には向かない Claude Designとは Claude Designは2026年4月17日にAnthropicがリリースしたAIデザインツールです（Anthropic Labs製・リサーチプレビュー）。 claude.ai 内の専用ワークスペースとして動作し、左ペインのチャットで指示すると、右ペインのライブキャンバスへリアルタイムに反映される2画面構成が特徴です。なお、これは今回試したUIに基づく観察です。公式発表ではインラインコメント・直接編集・調整ノブなどのインタラクションが紹介されています。 項目 内容 リリース 2026年4月17日（Anthropic Labs製・リサーチプレビュー） 対象プラン Pro / Max / Team / Enterprise モデル Claude Opus 4.7（デフォルト） できること プロトタイプ・スライド・ワンページャー・HTML書き出し トークン 通常チャットとは別枠（プランにより異なる） アクセス方法 claude.ai にログイン後、左サイドバーの「Design」から起動できます。Pro / Max / Team / Enterpriseプランが対象です。 Notionコネクタを使う場合は事前設定が必要です。Settings → IntegrationsからNotionを接続しておくと、Design内でNotionのURLをそのまま渡して仕様ページを直接読み込めます。 実践：管理画面のワイヤーを作る 概要が掴めたところで、実際に試した内容を紹介します。 最初に渡したプロンプト 今回は自社サービスの管理画面に「施策管理ページ」を追加する想定でワイヤーを作成しました。最初のプロンプトはシンプルにしました。 1 2 3 4 5 6 7 XXXXXという管理画面の施策管理ページを作りたい。 - PC向け管理画面 - ピンク（#E91E8C）のヘッダー＋左サイドバー構成 - 施策一覧テーブル（ID・施策名・開始日・終了日・URL・ステータス） - 詳細ボタン → モーダルで編集 - モーダル内はアコーディオンで項目を折りたたむ - ステータスは「下書き / 公開 / 非公開」の3種 これだけでClaude Designから10問のヒアリングが返ってきて、設計が始まりました。 ...

本記事では、PlaywrightのE2Eテストで globalSetup と storageState を使い、ログイン状態を一度だけ取得して各テストで再利用する仕組みを解説します。 この方式により、ログインが必要なページのテストでも毎回ログイン操作を繰り返さずに済み、テスト全体を高速かつ安定的に実行できます。 この記事で得られること globalSetup＋storageStateでログインを1回だけ実行し、全テストで再利用する実装 httpOnly Cookieを含むログイン状態が保存・注入されるしくみ 実際にログインするテストとログイン済み状態から開始するテストの使い分け globalSetup内で成功・失敗それぞれのトレースを記録するデバッグ手法 背景と課題 これまで、ログインが必要な画面のリグレッション確認を、リリースのたびに手動で実施していました。 対象画面が十数件にのぼり、毎回30分以上の確認工数がかかっていたうえ、ログインを伴う操作フローは手動では見落としが起きやすく、リリース後に不具合に気づくケースもありました。 機能追加のペースが上がり、確認対象もさらに増えてきたことをきっかけに、これらの確認をE2Eテストで自動化し、リグレッションを継続的に担保することにしました。 E2Eテストを導入するうえで課題になるのが認証の扱いです。 テストごとにログイン操作を繰り返すと、テスト数に比例して実行時間が増え、さらにログイン処理自体の不安定さがテスト全体の信頼性を下げます。 そこで、ログインを一度だけ実行してセッション情報を保存し、各テストで再利用する仕組みを globalSetup と storageState で構築しました。本記事はその構成と運用方法をまとめたものです。 前提環境 本記事は以下の環境で動作を確認しています。お使いの環境に合わせて読み替えてください。 ツール バージョン Node.js 20.18.0 (LTS) @playwright/test 1.49.1 Nuxt 3.14.0 TypeScript 5.6.3 実行OS macOS 14 / Ubuntu 22.04 (CI) ファイル構成 E2E専用の構成として、関連ファイルは次のように配置します。 1 2 3 4 5 6 7 8 9 10 11 src/ ├── package.json # test:e2e スクリプトを追加 ├── playwright.e2e.config.ts # E2E専用Playwright設定 ├── .env.e2e # 認証情報（gitignore済み・各自作成） ├── playwright/ │ └── .auth/ │ └── user.json # ログイン済みCookie（gitignore対象・テスト実行時に自動生成） └── tests/ └── e2e/ ├── global-setup.ts # ログイン・storageState保存 └── auth.spec.ts # 認証フローのテスト E2E専用の設定ファイルを分ける理由 E2Eテストは実APIを呼び出し、実際にログインしてセッションを取得します。スナップショット比較やユニットテストなど他の種類のテストとは、API・認証・実行タイミングの要件が異なります。 ...

はじめに こんにちは。and factory フロントエンドエンジニアの青木です。 現在関わっているプロジェクトのフロントエンドで採用している、OpenAPI を Single Source of Truth とした型安全 API 統合パターン を紹介します。 Orvalでやっていることを並べると次のとおりです。 バックエンドの make openapi で生成されたYAMLをフロント側にコピー 1コマンドで 型定義 / TanStack Query Hook / Zodスキーマ / MSWモック までを一括生成 公開APIと認証APIで operationId 単位に mutator を切り替え、誤用を生成時点で防ぐ Zodの 二段防御 (coerce × transform) で unknown をコンポーネント層に到達させない 前提: Single Source of Truth とは Single Source of Truth (SSoT) は、ある情報の 「正しい定義を置く場所を 1 箇所に固定する」 設計原則です。日本語では「信頼できる唯一の情報源」と訳されます。 例えばAPIの「リクエスト/レスポンスの形」をプロジェクトのあちこちに書いていると、以下の問題が起きます。 バックエンドが型を変えたのにフロントのTypeScript型が古いまま動いてしまう ドキュメントとコードがズレて、新規参画者がどちらを信じればよいか分からなくなる 同じ情報を複数箇所で手書きするため、変更時の修正漏れが必ず発生する これを防ぐため、「APIの形」を openapi.yaml という1つのファイルに集約 しています。フロントの型・Hook・Zod・MSWモックは、すべてそこから自動生成する運用です。 flowchart TD A["openapi.yaml<br/>（唯一の「真実」）"]:::source A --> B[TypeScript 型] A --> C[TanStack Query Hook] A --> D[Zod 検証スキーマ] A --> E[MSW モックハンドラ] classDef source fill:#0ea5e9,color:#fff,stroke:#0369a1,stroke-width:2px これが「OpenAPIをSingle Source of Truthにする」の意味です。openapi.yaml を更新して pnpm run generate:api を実行すれば、全派生物が機械的に再生成されます。手作業の同期は不要です。 ...

はじめに こんにちは。and factory フロントエンドエンジニアの坂内です。 4月の個人テーマとして、Webアクセシビリティ（WCAG・WAI-ARIA）の基礎を調べ、自社プロダクトで計測まで試したので共有します。 「アクセシビリティは大事」と聞くものの、何から手をつければよいか分からないと感じるエンジニアは多いはずです。本記事はフロントエンドの実装視点で、まず押さえておきたい範囲に絞ってまとめました。 結論 先に持ち帰ってほしいポイントを3つに絞ります。 実務の目標ラインはAAレベル準拠（JIS X 8341-3:2016もWCAG 2.0と同内容のため、AAが事実上のスタンダード） 大原則は「No ARIA is better than Bad ARIA」で、<button> を使えばロール・キーボード操作・フォーカスがすべて自動で揃う 自社プロダクト4ページの横断計測の平均は93点（自動検査の範囲）で、指摘はselectのラベル不足とコントラスト比不足が中心、修正コストも小さい 詳細を順番に説明します。 調査の背景 私が担当しているプロダクトは占いコンテンツのWebサービスです。複数ページで同じ <select> やドロップダウンが繰り返し登場するため、共通コンポーネント越しにUIを組み立てる構成です。 フロントエンドの実装では、<div> や <span> だけでUIを組む場面が増えました。Reactなどのライブラリでカスタムコンポーネントを作る場合、見た目はモーダルやドロップダウンに見えても、HTML上は意味を持たないただの箱になりがちです。 この状態では、スクリーンリーダーや支援技術を使うユーザーから見ると、機能の伝わらないコンポーネントが増えていきます。 現状把握として、ChromeのLighthouseでトップページを計測したところ、Accessibilityスコアは86点でした。検出された指摘は <select> のラベル不足やコントラスト比不足など、共通コンポーネントとデザイントークン由来の項目が中心です。共通部品の不備は複数ページに波及します。改修へ進む前段階として、まず基礎を押さえておきたいと判断しました。 以前からアクセシビリティは気になっていたテーマでもあり、チームでSEOやUI品質について話し合う機会が増えたことも後押しになりました。そこで4月の個人テーマとして、WCAG・WAI-ARIAの基礎調査と自社プロダクトの横断計測を据えました。次の章からWCAG・WAI-ARIAの順に整理し、最後に自社プロダクトの計測結果へつなげます。 WCAGとは WCAG（Web Content Accessibility Guidelines）は、W3Cが策定したWebアクセシビリティの国際ガイドラインです。障害のある人や高齢者を含むあらゆるユーザーが、Webコンテンツを利用できるようにするための指針です。 4つの原則（POUR） すべての達成基準は、次の4つの原則に分類できます。 原則 内容 例 Perceivable（知覚可能） 情報がユーザーに認識できる 画像のalt、字幕 Operable（操作可能） UIが操作できる キーボード操作対応 Understandable（理解可能） 内容や操作方法が理解できる エラー表示の分かりやすさ Robust（堅牢） 多様な環境で動く 正しいHTML構造 3段階の適合レベル レベル 位置づけ 具体例 A 最低限。これがないと使えない人が出る キーボード操作可能、画像にalt属性 AA 一般的に目指すべき標準 コントラスト比4.5:1以上、200%拡大対応 AAA 最高レベル。完全準拠は現実的に困難 コントラスト比7:1以上、手話付き動画 日本ではJIS X 8341-3:2016がWCAG 2.0と同内容のため、公的機関でも参照されています。実務で目標とする標準ラインは AA準拠 です。 ...