AIに申し込みフォームを作らせたとき、出てきたのは見た目の整ったものでした。色も余白もそろっていて、そのまま使えそうな見た目です。
ところが、そのフォームに実際に文字を打ち込み始めると、「お名前」「メールアドレス」といった項目名が消えてしまうことがあります。入力欄の中に薄い文字で項目名が書いてあるだけで、打ち始めた瞬間にその文字が消えるからです。何を入力していたのか、途中で分からなくなります。
今回は、同じ申し込みフォームを2通り作って比べました。片方はデザインの基準を足さずに、もう片方はデジタル庁が公開しているデザインの基準を先にAIに読ませて。色・余白・影・角丸・文字の設定は両方とも同じで、できあがったフォームを比べると、構造と操作まわりに差が出ました。
この記事の持ち帰りは3つです。①基準をAIに読ませる手順 ②プログラミング未経験でも自分の画面を点検できる5つの観点 ③使うときのライセンス上の注意。
見た目がきれいだと、それだけで「できている」と思ってしまいます。私もそう思っていました。今回はそこを、基準と数字で確かめた記録です。
AIが作ったフォーム、入力し始めると項目名が消えていませんか
まず、自分の申し込みフォームや問い合わせフォームを開いてみてください。
入力欄に「お名前」「メールアドレス」といった薄いグレーの文字が入っているでしょうか。その状態で1文字打ち込むと、薄い文字が消えて自分の打った文字だけが残る。そうなったら、その欄は項目名を「プレースホルダー」（入力欄の中に薄く表示される見本の文字）だけで表しています。
今回の比較でも同じでした。基準を読ませずに作った側は、項目名を欄の外のラベルに置かず、プレースホルダーだけで済ませていました。項目が5つも6つも並ぶと、いま何を入力しているのかを画面から確かめられなくなります。
見た目がすっきりするぶん、「入力を始めた瞬間に項目名が消える」という副作用には、作った本人ほど気づきにくいところだと感じています。
自分のフォームで一度試してみてください。打ち始めて項目名が消えるなら、この記事の話はそのまま自分の画面の話になります。
見た目はきれいでした。だから気づけなかった
2つのフォームは、色も余白も影も角丸も文字の大きさも同じ値に固定しました。並べて眺めても、パッと見の印象はほとんど変わりません。
それでも差は出ました。出たのは、構造と操作まわりです。項目名の置き方、必須と任意の見せ方、キーボードで操作したときに今どこにいるかの分かりやすさ、押せる部分の大きさ。どれも、眺めているだけでは見えない場所でした。
見た目で判断すると外すのは、以前にも書きました。AIに記事を丸投げしたときも文章はきれいで、だから中身の薄さに気づくのが遅れました（AIブログ丸投げで失敗｜未経験が気づいた残る記事の作り方）。整っているように見えるものほど、確かめる手が止まります。
「きれいに見える」は、確認をやめる合図になりやすいと感じています。ここが一番あぶないところでした。
デジタル庁が「AIに読ませる用」の基準を公開しています
デジタル庁は「デジタル庁デザインシステム」を公開しています。アクセシビリティ（年齢や障害にかかわらず使えること）を最優先事項として作られている、と公式に書かれています。現時点ではβ版で、仕様は今後変わりうる位置づけです。
この基準は、ドキュメント一式が Markdown（マークダウン。文字だけで書かれたファイル形式）で公開されていて、公式自身が「主にAI参照用途」だと明記しています。AIに読ませることを想定して配られている、ということです。
ファイル数は全部で125です。今回はその中から必要なものを選んで22ファイルを取り込みました。全部を読ませたわけではありません。取得に費用はかかりませんでした（2026年7月時点）。
本記事はshinlaboの独自検証であり、デジタル庁の制作・監修・推奨を受けたものではありません。 検証に使ったのは2026年7月15日版（β版）です。その後も更新されているため、実際に使うときは公式サイトから最新版を取得してください。
出典：デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/
前の記事では、文章を教材と採点で改善しました。今回はフォームを、政府の基準と px・コントラストで点検します（【検証】教材MDをAIに読ませてブログ3記事リライトしたら採点+43点向上した話）。同じ「基準をAIに読ませる」でも、直す対象と測り方が違います。
誰でも取りに行けて、しかも公式がAIに読ませる前提で配っている。ここに気づけたのが今回の出発点でした。
同じフォームを「基準なし」「基準あり」で作り比べました
作ったのは「AI副業の個別相談 申し込みフォーム」です。2026年7月18日に Claude Fable 5（Claude Code のFableセッション）に実装させました。渡した基準は、先ほどの22ファイルです。
差が出た部分を並べます。
| 見る場所 | 基準なし版 | 基準あり版 |
|---|---|---|
| 項目名 | プレースホルダーのみ（入力すると消える） | 欄の外にラベルを表示 |
| 必須と任意 | 区別なし | 「※必須」ラベルあり |
| 補助説明・エラー文 | 設計なし | サポートテキスト・エラーテキストの配置を定義 |
| ボタンの高さ | 40px | 48px |
| キーボード操作中の現在地 | 標準の枠を消し、枠線の色が少し変わるだけ | 黄色と濃紺の二重の枠で囲む |
ボタンには、押せる範囲を縦横44px以上を確保するという考え方があります。基準なし版の40pxはそこに届いていません。8pxの差です。
キーボード操作中の現在地も差が出ました。基準なし版は、ブラウザ標準の枠を消したうえで入力欄の枠線の色を変えるだけの作りです。枠が無いわけではないものの、色が少し変わるだけなので、Tabキーで移動すると今どこにいるのか追いにくくなります。
どれも派手な違いではありません。だからこそ、言われないと気づけない場所だと思いました。
AIが作った”基準あり版”の初稿に、2箇所の見落としがありました
22ファイルを渡して作らせた「基準あり版」ですが、AIが最初に出してきた初稿の時点で、コントラスト比が3:1を下回る箇所が2箇所ありました。色の組み合わせを1組ずつ機械で計算して見つけ、そのあと直しています。公開している比較ファイルは修正後のものなので、いま見ても当時の2箇所は再現できません。
基準を渡しても、渡された側が守り切れるとは限らない。だから最後は機械で測る。ここまでが前半です。
修正後の版で、色の組み合わせ10組すべてを計算し直しました。10組のうち8組は、計算結果が3:1以上でした。残る2組は、キーボード操作中の現在地を示す黄色い枠の、内側の色です。この色だけを取り出すと、白い背景に対して1.67:1、ページ背景に対して1.60:1で、数字だけ見れば3:1に届きません。
ところが、この二重の枠は外側が濃紺で、白い背景に対して14.68:1あります。黄色と濃紺のあいだも8.79:1です。二重の枠を「内側の色だけで数えるのか、枠全体で数えるのか」は、基準の原文には書かれていませんでした。数え方が決まらない以上、ここを「違反」と言い切ることはできません。
機械で測ったら、次はその基準の原文を読む。
数字だけを見て、合格しているものを不合格と判定しかけました。測るのは有効ですが、測った数字の意味は原文に戻らないと確定しません。
なお、これは1つのAI（Claude Fable 5）に1回作らせた結果で、そのとき渡した指示文そのものは記録が残っていません。ここで出た差が、基準の有無によるものか、作るたびに出るブレなのかは切り分けられていない状態です。「AIは基準を渡しても守らない」と一般化できるだけの回数も試していません。今回のフォームではそうだった、というところまでです。
AIを疑う話ではなく、AI＝下書き担当／基準＝確認の物差し／最後の確認＝人間、という役割分担の話だと考えています。
素人目でも点検できる、5つの観点
ここからが持ち帰りです。プログラミングの知識がなくても、自分の画面をこの5つで見られます。AIに何と言えば直るかも並べました。
| # | 観点 | 見るところ | AIへの言い方の例 |
|---|---|---|---|
| 1 | ラベル | 入力し始めても項目名が残るか | 「項目名は入力欄の外にラベルとして表示してください。プレースホルダーだけで済ませないでください」 |
| 2 | 必須と任意 | どれが必須か画面で分かるか | 「必須項目に『※必須』を表示し、任意項目と見分けられるようにしてください」 |
| 3 | 現在地の見え方 | Tabキーで移動したとき今どこか分かるか | 「フォーカス時の枠を消さず、背景や隣接する色との間で3:1以上のコントラストが出る枠で示してください」 |
| 4 | 押せる大きさ | ボタンが指で押しやすい大きさか | 「ボタンの押せる範囲を縦横44px以上にしてください」 |
| 5 | エラー文 | 何をどう直せばいいか書いてあるか | 「エラー文には、具体的なエラー内容と訂正方法を書いてください」 |
3番のTabキーは、マウスを使わずに入力欄を順番に移動できるキーです。押して、今どこが選ばれているか一目で分かるかを見てください。5番のエラー文は、空欄のまま送信ボタンを押すと確かめられます（基準でも、エラーは送信ボタンを押した時に出すのが望ましいとされます）。何も出ないか「入力に誤りがあります」とだけ出るなら、直す余地があります。
作ったものを別の目で確かめる考え方自体は、LP制作でも同じことをしました（Claude Code×3つのAI連携｜プログラミング未経験のLP制作）。人の目だけでは足りない部分を、別のAIや機械の計測に回す。今回はその対象がフォームの中身でした。
全部を一度に直そうとしなくていいと思います。1番のラベルだけでも、入力の途中で項目名が消えることはなくなります。
自分でやる手順と、使っていい範囲
手順は4段階です。
①公式からドキュメント一式を取得する。 デジタル庁デザインシステムの公式サイトから、Markdownのファイル一式を取得します。β版のため、内容は今後も更新されていく前提です。私が取り込んだのは2026年7月15日版で、その後の版も出ています。取りに行くときは公式サイトで最新版を確認してください。
②作るものに必要なファイルだけ選ぶ。 ここが分かれ目です。ドキュメントは全部で125ファイルあり、今回私が取り込んだのは選別した22ファイルでした。そのうちDADS本体のドキュメント21ファイルだけで、合計319KB・約15万字あります。21ファイルをまとめて渡す方法は実測していません。約15万字あるので、本記事では必要なファイルだけを選ぶ手順にしています。
申し込みフォームを作るなら、入力欄・ボタン・色の3ファイル程度から始めるのが現実的です。この3ファイルで110KB・約5万字でした。
③AIに添付して読ませる。 ブラウザで使うAIチャットでも、Markdownファイルを添付して基準として読ませることはできました。添付したファイルの中身を出典つきで正しく引用させることも確認しています。
この確認は、1ファイル・冒頭抜粋739バイトで行ったものです。推奨している3ファイル110KBをまとめて渡した場合の動作は、まだ実測していません。 大きなファイルでどうなるかは実測していないので、まずは1ファイルから試して、読めているか質問して確かめる進め方をおすすめします。
指示文は、たとえばこう書きます。「添付したファイルはデジタル庁デザインシステムの基準です。この基準に沿って、問い合わせフォームのHTMLとCSSを書いてください。項目名はラベルで表示し、必須表示・エラー文・フォーカス時の見え方も基準どおりにしてください」。
④出典を書く。 デジタル庁のコンテンツを利用するときは、出典の記載が求められています。表記例は「出典：デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/ 」です。編集・加工して使った場合は、編集・加工を行ったことと、その主体（誰が加工したか）もあわせて書きます。
公式の禁止事項には「編集・加工した情報を、あたかも国又は府省等が作成した未加工のままであるかのような態様で公表・利用してはいけません」と書かれています。デジタル庁が作ったように見せる使い方は避けてください。
コントラストを測る手段。 色の組み合わせは、日本語で使える無料ツールで確かめられます。DigrArt カラーコントラストチェッカー（https://tools.digrart.jp/contrast-checker/ ）なら、登録なしで色コード（#から始まる6桁の英数字）を直接入れて判定できました。ただし、このツールのFAQに「コントラスト比の計算補助ツール」と書かれているとおり、これだけで基準への準拠が証明されるわけではありません。
ひとつ読み替えが要ります。判定は「AA通常テキスト4.5:1／AA大きなテキスト3:1」という文字向けの枠で表示されます。枠線やフォーカスに求められる3:1は、しきい値が同じなので、「AA 大きなテキスト（3:1）」の合否表示を読み替えて判断してください。
デジタル庁デザインシステムを読ませたからといって、LPの売り方や雰囲気まで決まるわけではありません。ここで扱っているのは、入力しやすさや操作のしやすさの部分です。
まず1ファイルで読めているか確かめてから、必要なファイルを少しずつ増やす。この進め方が安心だと感じています。
まとめ：基準を渡し、機械で測って、原文まで確認する
持ち帰りをまとめます。
1. 基準をAIに読ませる手順：公式からMarkdown一式を取得 → 作るものに必要な3ファイル程度を選ぶ → 添付して読ませる → 出典を書く
2. 自分の画面を点検する5つの観点：ラベル／必須と任意／現在地の見え方／ボタンの押せる大きさ44×44px／エラー文
3. ライセンス上の注意：出典の記載が求められる。加工した場合はその旨と主体も書く。デジタル庁が作ったように見せる使い方はしない
今回いちばん残ったのは、この形です。AI＝下書き担当／基準＝確認の物差し／最後の確認＝人間。今回は、基準を渡した側のほうが、下書きの段階で押さえられている項目が多くなりました。それでも初稿には見落としが残っていて、機械で測ったことでそこに気づけました。さらに、数字だけでは判断できない箇所もあったので、最後は基準の原文まで確認しています。
AIの出力は、最後に人が確認してから公開してください。 本記事の内容も、2026年7月時点で私が試した範囲の記録です。デジタル庁デザインシステムはβ版で仕様が変わりうるため、実際に使うときは公式サイトの最新情報を確認してください。
フォームやサイトを作る環境がまだない方へは、手元にブログを立てる手順を【実演】Claude Code×ConoHa WINGで副業ブログを立ち上げる手順にまとめています。
AIに毎回同じ説明をしなくて済むように、基準や手順を「持たせておく」やり方は、noteの記事（無料）で扱っています → 「また同じ指示…」を減らすClaude Codeスキル＆Hooksの作り方（無料note）
見た目はOK。中身は？ この一言を自分の画面に向けられるようになったのが、今回いちばんの収穫でした。
コメント