自作のデザインシステム @gunjo/ui（群青／gunjo.jp） を、群青を一度も見たことのない 予備知識ゼロのAI に170画面組ませてきた連載のまとめ第2弾。「そのコンポーネントを作るべきか？」の判断根拠は、実は3段階の強さに分かれます。 デザインシステム設計者の一番難しい判断「そのコンポーネント、本当に作るべきか？」デザインシステムを持つ人が毎週向き合う質問です。作りすぎると、種類が増えて使う人が迷子になり、作らなさすぎると、手組みが増えて一貫性が崩れます。ちょうど良いラインを探すのが仕事の半分です。170画面のコールドテストを回してきて分かったのは、「作るべき理...

📰 概要AIやコーディングエージェントが作った画面を、公開前に何をどの順番で確認すればいいか決まっていない方へ。本書は、現役フロントエンドエンジニアが、AI生成UIを実務品質へ直すときの確認手順を、20分で一周できる形にまとめた技術書です。5つの状態それぞれの判断基準から、状態を手元で再現するコード、コピーして使えるレビュー表、記入例、PRへ貼る共有文、エージェントへ渡す制約文までを扱います。正常データが入った画面だけを見て「ほぼ完成」と判断すると、0件・読込中・エラー・スマホ幅で修正が一気に増えます。本書は、その見落としを決まった順番で潰すことだけに絞っています。👫 対象とする読者・AIエージェントに実装させた画面を、これからレビューする方・自分で書いていないコードの差分を、限られた時間で判断する必要がある方・「どこまで見れば確認したと言えるのか」が決まっていない方・0件・読込中・エラーの画面を、手元で再現する方法を知りたい方・レビューした範囲と残るリスクを、チームへ引き継ぐ形にしたい方・レビュー観点を毎回思い出すのをやめて、再利用できる型にしたい方🚫 本書で扱わないこと・デザインの良し悪しの評価・WCAG適合の保証・パフォーマンス計測🛠 コードの確認環境掲載しているコードは、実際にパッケージを導入して動作と型を確認しています。・msw 2.15.0・@storybook/react 10.5.7・@axe-core/playwright 4.13.0 / @playwright/test 1.62.1・TypeScript 7.0.2（strict）Service Workerを通した実ブラウザでの統合動作までは検証していません。お使いの環境のバージョンに合わせてご確認ください。📖 無料で読める範囲Chapter 01・02は無料公開です。確認の順番と20分の時間配分は、無料部分だけで試せます。✍️ 執筆について本文の執筆にはAI（Claude）を使っています。Chapter 06の記入例は、レビュー表の使い方を示すために組み立てた架空の作例であり、特定のプロジェクトの記録ではありません。📰 更新情報2026/08/12: 公開しました

再現できない状態は、レビューされないコーディングエージェントに一覧画面を作ってもらった後、レビューで最初に詰まるのはここでした。0件やエラーの画面を、どうやって出すのか。本番のAPIが正常に動いている環境では、エラー画面は出せません。データが入っているアカウントでは、初回0件も再現できません。結果として、正常データが入った画面だけを見て「問題なさそう」と判断することになります。よくあるのは、見た目が整った一覧を先に見て「ほぼ完成」と感じたあと、0件表示に切り替えた時点で修正箇所が一気に増える流れです。表のヘッダーだけが残り、その下に何もない画面が出てくる、という形になりま...

みなさん、こんにちは！ペンギンエンジニアです！前回の010で、JSXの正体を突き止めました。JSXはHTMLではなくJSの構文拡張で、実体はオブジェクトを作る式、そしてブラウザに届く前に変換されている、ということを自分の目で確かめましたね。でも、正体が分かっただけでは、今の手元の画面はまだ固定の文字を出しているだけです。今日は予告どおり、JSXを自由に書くためのルールに入ります。{} で値を埋め込む書き方や、class ではなく className と書く理由など、最初につまずきやすいポイントを、まとめて片付けていきましょう。先に種明かしをすると、今日のルールは暗記リストで...

!この記事は ZENSHIN 技術ブログ で 2026-04-12 に公開した記事の転載です。元記事はこちら 👇https://tech.zenshin-inc.co.jp/blog/tech-selection/株式会社ZENSHINのCTOの高橋です。ZENSHINのホームページを Astro で構築しました。技術選定の経緯と、実際に使ってみた感想をご紹介します。https://astro.build なぜ Astro を選んだのか以前から Astro の存在は知っており、調べていくうちに良さそうだなとは感じていました。ホームページに必要な要件を整理してみたところ、A...

こんにちは。小学生向けのニュースサイト、こどもニュースをつくっています。このサイトには縦書きの表示モードがあり、本文が横方向にスクロールします。ある環境で、本文の最下行にスクロールバーが重なって読めなくなりました。 オーバーレイスクロールバーとはスクロールバーには 2 種類の描画のされ方があります。レイアウトの領域を取るもの（コンテンツの幅が、その分だけ狭くなる）コンテンツの上に重ねて描かれるもの（オーバーレイ）後者は、OS やブラウザの設定によって切り替わります。使っていないときは自動的に消える挙動と組み合わさることが多いです。見た目がすっきりするので好まれますが、...

3行まとめ画像上の色をスポイトで選んで透過するブラウザ完結ツールを作った。AIは使わず、各ピクセルと選択色の RGBユークリッド距離 で透過するかを決めるだけ0〜50のスライダー1本を3次元の色距離に載せるため、閾値に √3 を掛けて「1チャンネルあたりの許容差」 に読み替える透明化のしきい値と、そこから先の ぼかし用しきい値の2段にして、境界を一気に切らず線形に半透明へフェードさせる青や緑のスクリーンで撮った写真から被写体を抜く、ロゴの背景色を透過PNGにする——「特定の色だけ消したい」場面はデザイン作業でよくある。AI背景除去は被写体を賢く判定してくれるが、単色に近...

AIに「この営業資料からLPを作って」と頼むと、数分でそれらしい画面が出てきます。しかし、修正を頼むたびに別の場所が崩れたり、スマートフォンで読みにくかったりして、結局人が作るより時間がかかることがあります。原因は、AIの性能だけではありません。AIに渡す前に固定すべき判断が、まだ人の頭の中に残っているからです。この記事では、AIを使ってLPを1〜3日で仕上げるために、最初に固定しておきたい5項目と、実務で使える進め方をまとめます。 先に結論短期間で作りやすいのは、次の条件を満たすLPです。目的が1つ（問い合わせ、予約、資料請求など）既存のブランドカラーやロゴがある掲載...

AIエージェントが「実装完了。テストも通りました」と報告する。そこで仕事が終わったように感じるのが、Vibe codingの危ないところだ。まだ、どの成果物を本番へ出すのか特定できていない。テストしたコードとdeployするコードが同じかも分からない。依存パッケージ、実行時の権限、戻し先まで含めると、チャット上の完了報告はrelease判断としてずいぶん弱い。必要なのは、もっと長いプロンプトではない。生成物を本番へ渡す条件を、リポジトリとCIに残る小さな契約へ変えることだ。ここではそれを「昇格マニフェスト」と呼ぶ。 エージェントが賢くなるほど、handoffが難しくなるGoog...

まとめgetBoundingClientRect() が数式どおりの座標を返しても、そのピクセルがそこに描かれている保証はない。位置合わせ系のUIバグを箱の座標で検証するのは偽陽性の温床だったAIエージェントは数式もテストハーネスも即座に書くが、期待値モデルが間違っていることを検知する手段を持っていない。テストが通った瞬間に自信だけが増える対策として、レイアウト層・描画層・切り分け層の3層で検証するプロトコルを導入した。導入後は誤差0.5px以内で1回で決着した 背景見積もりフォームのスライダーの下に目盛りを並べた。つまみと目盛りの中心が数px〜10pxほどズレて...

AIに業務画面を1枚組ませると、だいたい形にはなります。難しいのはその次で、それを出していいかどうかを、誰が何を根拠に決めるのかが決まっていません。UI裁判は、そこに物差しを1本置いて、AIが生成したUIを1画面ずつ検品していく連載です。本編は UIXHERO のサイトにあり、この記事はZenn向けの入口として、判定の結果よりも、どういう物差しで測っているかのほうを厚めに書きます。本編（全文） → AIが作った施工写真台帳を、出す前に検品した 題材：AIが1枚で組んだ施工写真台帳デザインシステム @gunjo/ui（群青）のコールドテスト #175「施工写真台帳」。群青を一度も...

はじめにAIにサイトを作らせると、スマホ表示が毎回おなじ所で崩れる。そのたびに私が「ここ横スクロール出てる」「ここ直して」と、おなじ指摘をClaudeに繰り返す。正直、その繰り返しにちょっとうんざりしてました。横スクロールが出てる、中間の幅でハンバーガーに切り替わらない、開いたメニューがはみ出してる……。毎回おなじ崩れなのに、目視で全ページ・全幅を探して指摘するのは地味に手間。そして目視チェックは、どれだけ気をつけても取りこぼしが出る。人の目でやる限り、そこは避けられません。なので、この「毎回おなじ崩れ」だけを Playwright で機械的に検出して、Claude Code ...

体感スピードの速い通販サイトはどう作ればよいか。アイデアマンズがこれまでの改善案件で積み上げてきた設計と実装のプラクティスを、体系立てて紹介します。この記事は新規に立ち上げるサイトや、大幅なリニューアルを前提としています。既存サイトの手直しにはあまり向かないので、あらかじめご了承ください。最新の技術は登場しません。汎用的で実績のあるプラクティスだけに絞っています。 通販サイトは複合的なサイト通販サイトはメディアサイトより設計の難易度が高いサイトです。求められる性質が複合的だからです。読み物としての側面: ユーザーはまず商品探しや情報収集をするダイナミックな側面: 在庫や...

3行まとめCSVとJSONを相互変換するブラウザ完結ツールを作った。CSV→JSONはヘッダー有無で [{列名:値}] かオブジェクトなしの [[...]] に出力形が変わるCSV→JSON側はパースを papaparse に任せてRFC 4180の面倒を回避、JSON→CSV側は 先頭要素の形からオブジェクト配列か2次元配列かを推論してヘッダーを組み立てる、という非対称な作り双方向変換には型が保存されないという原理的な限界がある。数値も日付もCSVを経由すると文字列になる。ここは正直に割り切るREST APIのJSONレスポンスをExcelで見たい、逆にスプレッドシー...

はじめに前回 #1-28 では、関数は「値」の一種であることを確認しました。数値や文字列と同じように変数へ代入でき、他の関数に渡すこともできる。その代入形が「関数式」でした。const greet = function () { console.log("こんにちは");};ところが実際のコードを開くと、この書き方すらほとんど見かけません。現代のJavaScriptでは、圧倒的にこちらです。const greet = () => { console.log("こんにちは");};function が消えて => が現れました。これが今回のテーマ アロ...

車やバイクの燃費は、走行距離と使用した燃料量が分かれば計算できます。計算式そのものは単純ですが、Webツールとして実装する場合は、入力値の扱い0除算の防止小数の表示km/L と L/100km の変換入力変更時の自動再計算なども考える必要があります。今回は、実燃費を計算する基本ロジックと、ブラウザ上の計算ツールとして実装するときに考えた点を整理します。 実燃費の基本的な計算式日本で一般的に使われる燃費の単位は km/L です。計算式は次のとおりです。燃費（km/L） = 走行距離（km） ÷ 使用燃料量（L）たとえば、走行距離：420km使用燃料量：...

AIエージェントにブラウザ操作を渡せば、フロントエンドのデバッグも自動化できそうに見える。ところが、壊れた購入画面を開いてみると、DOMにはdisabledなボタンがあり、consoleにエラーはなく、APIは200を返している。それでも購入できない。在庫キャッシュが失効したのかもしれないし、セッション更新が競合した可能性もある。optimistic updateがrollbackされた結果かもしれない。画面を詳しく読んでも、どれが原因かは分からない。DOMが記録しているのはレンダリング結果だ。そこへ至った因果までは残っていない。画像認識の性能を上げる前に、アプリが実行時の意味を説明...

こんにちは。小学生向けのニュースサイト、こどもニュースをつくっています。このサイトには、記事を縦書きで読む切り替えがあります。新聞や教科書は縦書きなので、子どもにとってはそちらのほうが自然な場面もあります。国語のテストや入試の問題文も、多くは縦書きです。一方で、インターネット上の文章はほとんどが横書きです。子どもが日常的に画面で読むものに縦書きはめったに出てきません。読み慣れないまま、縦書きで出題されるテストに向き合うことになります。つまり、日常的に読める縦書きの文章そのものが、いまはかなり貴重な資源です。毎日更新される記事を縦書きで読めるようにしておく価値は、そこにあると考えていま...

3行まとめ画像に著作権表示などのテキストを1か所、または「SAMPLE」等の透かしを全面タイル状に入れるブラウザ完結ツールを作った。Canvas 2D の fillText だけで実装できる6か所の位置決めは、テキスト幅を測らず textAlign / textBaseline を切り替えてブラウザに揃えさせる。アンカー座標を渡すだけで左寄せ/中央/右寄せが決まる回転した透かしを敷き詰めるとき、ctx.rotate 後は描画すべき範囲が広がる。対角線長 √(w²+h²) を基準にキャンバスより広くループして塗り残しを防ぐ写真に著作権表示（© 名前）を入れる、資料に「社外...

概要Movable Type 9（以下MTまたはMT9）ではエディタ周りも改修され、フォーマット形式に「GitHub Flavored Markdown」（以下GFM）が選択できるようになりました（他に「CommonMark」も選択できるようになっています）本記事では、GFMのMTでの挙動と留意点などについて解説しています。!以降の掲載順は以下GitHubのMarkdown記述に関するドキュメント（とく日本語訳）を参照し、掲載タイトルや順番もこちらに合わせています。また、いくつかのGitHub専用の記述や使用頻度が低いと個人的に判断した記述は本記事には記載していません。あらか...