フロントエンド

はじめに こんにちは。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問のヒアリングが返ってきて、設計が始まりました。 ...

はじめに こんにちは。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準拠 です。 ...