社内向け資料の作成規範

読み手は成果物しか見ない。この一文がすべての土台になる。

併用する規範

• 日本語の文章そのもの：../japanese-tech-writing/SKILL.md
• 読ませる緩急：../cognitive-rhythm-writing/SKILL.md

この規範は、それらの上に「配られる資料」という条件を足したものである。

1. 作成経過と成果物の境界

最も繰り返し破られる規範なので先頭に置く。

読み手は次のどれも知らない。知らないまま読んで通じる文章になっているかを、常に確認する。

• 前の版がどうだったか
• 何を検証し、何を組み替えたか
• 依頼者とどんなやりとりがあったか
• 書き手がどの規範に従って書いたか

本文に書いてはならないもの

例外（残してよいもの）

• 出典と鮮度：「公式ドキュメントと Windows 11 上での動作確認に基づく。更新が速いので最新版を確認すること」。読み手が情報の信頼度を判断するために要る。
• 公式情報と実態の食い違い：「公式ドキュメントには未提供と書かれているが、実際には動作する」。読み手の意思決定に直結する。
• 未確定であることの明示：検討中の章で「いずれも未検証」と書く。読み手が鵜呑みにしないために要る。

判定は一つ。その文が更新するのは「読み手の世界」か、「この資料の来歴」か。 後者は削る。

2. 見出しはスタンスを取る

読み手は見出しで進むか止まるかを決める。見出しを読んで「で、何が？」と疑問だけが残る状態は、読み手の怠惰ではなく書き手の失敗である。

悪い見出しの型

直した形

• 「1 件目と 2 件目以降で、進め方が変わる」→ 「2 件目からは、ゼロから作らない」
• 「なぜこれが嬉しいのか」→ 「入れ子にすると、手作業が 4 つ消える」
• 「2 つの取り込み方」→ 「ソースコードが無くても取り込める」
• 「自分の仕事はどれに当たるか」→ 「仕事の種類で、使う型は決まる」

いずれも、見出しだけ拾い読みしても筋が通る。それが合格条件である。

書籍や読み物の規範では「見出しでオチを知らせない」とすることがある。配布資料では逆で、拾い読みされる前提なので見出しに結論を載せる。両方の規範を使うときは、成果物がどちらかで判断する。

資料タイトル（h1）だけは逆

章見出しはスタンスを取る。資料タイトルは対象を名指す。 役割が違う。

資料は単体では存在せず、社内の資料一覧に並ぶ。並んだときに「何についての資料か」で識別できなければならない。主張はサブタイトルに置く。

• ✗ 「Pencil で画面イメージをつくる 3 つの型」
• ⭕ h1「デザインツール：Pencil」／ h2「UI のデザイン・開発で使える基本的な手法」

中身の一部をタイトルにすると、中身が育った時点で嘘になる。「3 つの型」を掲げた資料に、付録・検討メモ・デザインシステムの話が入った時点で、タイトルが実態を指さなくなる。タイトルは対象物の名前にしておけば壊れない。

点検

書き上げたら見出しだけを抜き出して並べる。上から読んで資料の主張が追えなければ、追える見出しに書き換える。

3. 対象読者は職種と道具で定義する

「初心者向け」では設計できない。次の粒度まで下ろす。

• 職種と担当業務：社内システムの企画・改修担当
• 今使っている道具：PowerPoint、draw.io、Excel
• 既に持っている知識：CSS は少し読める
• 持っていない知識：デザインツール、レイヤーとグルーピングの概念

そのうえで次を守る。

• 既知の道具の言葉に翻訳する。 用語対応表（新概念／ひとことで言うと／既存ツールで言えば／既知の技術で言えば）を早い位置に置く。
• 未経験の概念は、既知の操作から橋渡しする。 レイヤーを説明するなら PowerPoint のグループ化（同じ Ctrl+G）から入る。
• その読み手が持っていない前提を、手順の入口にしない。 ソースコードを持たない相手に「コンポーネントのファイルを取り込む」から始めさせない。
• 実在しない相手を想定しない。 渡し先に「内製の開発担当」を書く前に、実際にその人がいるかを確認する。いなければ書かない。

4. 構成は機能ではなく仕事で切る

ツールの機能一覧を並べ替えただけのものを「ワークフロー」と呼ばない。

• 読み手の実務で発生する仕事（要望を絵にする、改修案を示す、実装に渡す）から逆算して型を立てる。
• 一番多い仕事が抜けていないかを確認する。 ゼロから起こす作業が型のどこにも無ければ、そもそも使い始められない。
• 毎回やる作業（保存、記録、共有、資産への還元）は型と別に「締めの作法」として独立させる。型の中に埋めると飛ばされる。
• 型の数は 3 前後に抑える。技術的に可能な操作をすべて型に昇格させない。
• 時間軸で変わるなら、それも書く（1 件目はゼロから、2 件目以降は取り込んで改造）。読み手が初回の重さで離脱するのを防げる。

HTML化はタグ変換ではなく、情報設計まで行う

配布用HTMLを新規作成・変換するときは、最初にassets/html-document-wireframe.htmlをブラウザで開く。DOM構造、余白、意味別部品、目次の実装を起点にし、ゼロから別の骨格を作らない。

• 資料固有の接頭辞へidw-を置き換える
• 内容の役割に応じてカード、図、手順、callout、表を残す
• 使わない部品とplaceholder文を削除する
• 色だけをコピーせず、部・章・節と意味別部品の切り替えを維持する

Markdownの見出しをh2、箇条書きをul、表をtableへ置き換えただけでは、HTML資料を作ったことにならない。内容の役割を判定し、役割に合う表示形式へ再構成する。

変換前に全ブロックへ役割を付ける。同じpとulが続く箇所は、文章量を調整する前に表示形式を見直す。

✗ h2 + p + ul + table だけで全章を構成し、参考資料の色と目次だけを移す

⭕ 「前提」はカード、「信頼境界」は図、「デプロイworkflow」は手順、
  「失効」はcallout、「テスト方針」は表へ割り当てる

変換元を正本としても、違反をそのまま運ばない

「HTMLにする」という依頼は、明示的に逐語変換を指定されない限り、配布資料として成立させる編集を含む。変換元に次があれば、HTML側で直す。

• 作業履歴やレビュー反映記録
• 結論を示さない見出し
• 文章で表現された構造、手順、対比
• 同じ役割の長い箇条書き

逐語変換が指定された場合だけ本文を保持する。その場合も、読みやすさの問題を隠さず報告する。

5. 目的だけを書く

節の中身は、その節のタイトルが約束したことだけで構成する。タイトルとずれた話を例として盛り込まない。

三段で足りる

一節の完成形は、多くの場合この三段で終わる。

1. 結論：デザインツールは、画面を「1 枚の絵」ではなく部品の入れ子として持っている。
2. たとえ（1 つだけ）：PowerPoint の「グループ化」と似たもの。
3. 補足：違いは 2 つ。（箇条書き 2 行）

これで一節。これ以上は足さない。

たとえは 1 つ、1 行で止める

既知の道具にたとえるのは有効だが、たとえた先を説明し始めた時点で主題を失う。

✗ PowerPoint で図形をまとめて Ctrl+G するとグループになる。ドラッグすれば中身ごと動き、
  ダブルクリックすれば中だけ直せる。Pencil のレイヤーはこれの厳密版で、ショートカットまで同じ。

⭕ PowerPoint の「グループ化」と似たもの。

下は Pencil の話をしている。上は PowerPoint の操作説明であって、節の主題ではない。

削るもの

検討中・調査中の記述は、定義と箇条書きに割る

結論の出ていない話ほど、地の文で推論を書き連ねやすい。思考の道筋は書き手の頭の中のものであって、読み手には要らない。

型は 3 つに割る。

見出し
定義（1 行。何をするのか）
・根拠や効果（箇条書き）
補足：前提、制約、未解決の課題

✗ ボタン、入力欄、カード、表、ダイアログ。これらが既知の定義に一致していれば、
  「AI が毎回それらしく作った独自パーツ」ではなくなり、実装への引き渡しも楽になる。
  ただし判定はそう単純ではない。
  shadcn/ui は Tailwind CSS を前提にしている。素の HTML と CSS で作る環境では、
  Tailwind のクラスを native CSS に変換したうえで載せることになる。つまりクラス名の
  一致では判定できない。変換後の構造と見た目で一致を見る必要がある。この「一致」を
  どう機械的に判定するかが、そのまま課題になる。

⭕ UIコンポーネント（ボタン、入力欄、表、ダイアログなど）をAIに生成させず、
  公開されているものの流用だけで構成する。
  ・AI生成だと、プロンプトで指定しきれないAI臭が残る
  ・公開デザインの流用なら、見た目が整い、実装への引き渡しも楽になる
  補足：shadcn/uiはTailwind前提。素のCSS環境ではクラス名が一致しないため、
       変換後の構造と見た目で判定する必要がある。

「ただし」「つまり」「逆に言うと」で節を繋いでいたら、推論を実況している合図。接続語ごと削り、結論を箇条書きに落とす。

同じ情報を 2 か所に書かない

対象読者、前提、費用のような属性は、置き場所を 1 つ決める。冒頭のラベル、リード文、本文のカードに同じことが分散すると、読み手は違いを探して読み比べることになる。

例の数は 2 つまで

3 つ以上並べたくなったら、表にするか、代表 1 つに絞る。

✗ 他社サービスのスクリーンショット、以前作った似た画面、現行システムの操作マニュアル、
  Excel で回している手作業の管理表。どれも「こういう感じ」を伝える材料になる。

⭕ 他社サービスのスクリーンショット、Excel で回している管理表など。

文体

• 敬体（です・ます）を使わない。常体か体言止めで言い切る。
• 一つの主張は一度だけ。
• 補足の説明文が本体より長くなったら、補足を消す。

✗ 離席前、会議前、大きく変える前。取り消し（Ctrl+Z）の効き方も一般的なツールより
  限定的なので、壊す前に保存しておくのが実質の保険になります。

⭕ 自動保存機能なし。終了時と Git コミット時は必ず手動保存すること

6. 緩急は文章量ではなく、粗密で作る

先に否定しておく。山は文章を足して作るものではない。 段落を増やす、説明を重ねる、言い換えを並べる。これは山ではなく、ただの冗長である。

「緩急をつけろ」と言われて分量を足すのは、指示の取り違えである。5 章で削るものを削り切った状態が前提で、そのうえで残った文章の見せ方を変えるのがこの章の話。

均一に短いのも、均一に長いのと同じく平坦である。読み手が泳ぎ切れないのは情報量ではなく、起伏の無さによる。そして HTML で書くなら、起伏の主たる手段は視覚の粗密であって、文字量ではない。文字量は据え置き、あるいは減らしたまま山を作れる。

使える軸

実装例

/* 山：段落間を詰め、字を起こし、幅を絞る。囲みは作らない */
.crest { display: flex; flex-direction: column; gap: 0.4rem; }
.crest p { font-size: var(--step-1); line-height: 1.7; max-width: 48ch; }
.crest p.hit {
  font-size: var(--step-2); font-weight: 700;
  line-height: 1.45; max-width: 30ch;
}

本文 16px、山の地 19px、決めの一文 23px。段落間は 20px から 6px へ。 これだけで、地の文を 5 段落から 3 段落に減らしながら山が強くなる。

余白は二重に効かせない

gap を使う容器の中で、既定のマージンを消し忘れると余白が倍になる。見出しと本文が離れ、全体がスカスカに見える。

h1, h2, h3, h4, p, ul, ol, figure, pre { margin: 0; }

実例：見出しと直後の本文の距離が 55px あった。内訳は gap 20px ＋ 見出しの既定下マージン 19px ＋ 段落の既定上マージン 16px。リセットを入れて 18px になった。目分量で判断せず、隣り合う要素の距離を実測する。

余白は要素単体ではなく、隣接する塊の合計で測る

マストヘッドのpadding-bottom、本文容器のgap、最初の大項目のmargin-topは、別々に妥当に見えても合算される。隣り合う塊の外接矩形を測り、見えている距離を基準にする。

✗ .masthead { padding-bottom: 4rem; }
  .content  { gap: 4rem; }
  .part     { margin-top: 5.5rem; }

⭕ .masthead { padding-bottom: 1rem; }
  .page     { gap: 4rem; }
  .part     { margin-top: 0; }

参考HTMLがある場合は、同じviewportで次の座標差を比較する。

• マストヘッド下端から最初の大項目上端
• 大項目下端から最初の章見出し上端
• 章見出し下端から最初の本文上端

参考との差が25%を超えたら、意図を説明できない限り余白設計の失敗とする。1440×1000のファーストビューも画像で並べ、空白が情報より強く見えていないか確認する。

強調は 1 段だけ

強調のサイズが見出しを超えると、階層が壊れる。段階を 2 つ作るのも誤り。

✗ 本文 16px ／ 強調の地 19px（＝節見出しと同じ）／ 決めの一文 23px（＝章見出しと同じ）
⭕ 本文 16px ／ 決めの一文 17px 太字（節見出し 19px より小さい）

強調の周囲は本文サイズに戻す。太さで差を付け、サイズは見出しの階層を侵さない範囲に収める。

波は構造にもある

文字組みだけの話ではない。同じ重さの章が 10 個並んでいる状態は、それ自体が平坦な海である。

章を大項目（部）でグルーピングし、章の下に節を持たせる。大 → 中 → 小の三層になって初めて、読み手は全体の中の現在位置を掴める。目次にインデントとして現れ、飛ばし読みの判断材料になる。

• 並列に見える章が 3 つ以上続いたら、上位のまとまりを疑う。
• 部の数は 3 前後。部の名前も対象を名指す（「Ⅱ 3 つの型で作る」）。
• 大項目を入れたら、章番号は通しのまま振る。部ごとにリセットしない。

原則

• 谷：表、図、手順リストには説明文を付けない。見出しと項目だけで置く。
• 山：因果の連鎖がある箇所（今こうしている → だからずれる → それが消える）だけ地の文にする。並列情報は表かカードに逃がす。
• 山は資料全体で 3〜4 箇所まで。それ以上は山でなくなる。
• 段落の文字数だけで拍を作らない。 9 文字の一文と 107 文字の段落が同じ余白・同じ字送りで並ぶと、拍ではなく浮いた断片に見える。文字数を振ったら、必ず CSS 側も振る。
• 冒頭で答えを一つ預け、対応する章で返す。ただし「ここで〜の話を返す」と宣言しない。内容で返す。宣言文は削っても山は弱くならない。

7. 図で示す

言葉より図が速いものは図にする。

• 構造（入れ子、階層）
• 時間軸（初回と 2 回目以降、蓄積されていくもの）
• 対比（今のやり方と新しいやり方）
• 全体像（章と章の関係）

実装上の条件。

• インライン SVG で書き、外部ファイルに依存させない。
• 色は CSS 変数で参照し、ライト／ダーク両対応にする。
• 図中のラベルは読み手の言語で書く。実データの英語名をそのまま貼らない。
• 意味の分からない記号（◧ など）を置かない。凡例が要るなら凡例を書く。
• 公開前に、全要素が viewBox 内に収まっているかを機械的に検査する。

図の中の文字を本文より大きくしない

viewBox を持つ SVG を width: 100% で置くと、容器が広いほど図全体が拡大される。図中の文字も一緒に拡大され、本文より大きくなる。

viewBox幅 760 ／ 図の文字 13px を 1216px の領域に置く
→ 倍率 1.6 → 図の文字が 20.8px（本文 16px より大きい）

拡大の上限を、図の文字が本文と一致する倍率で止める。

/* 図はviewBox幅760・文字13pxで組んである */
figure svg {
  width: 100%;
  max-width: calc(760px * 16 / 13);   /* 図の文字が本文16pxと一致する幅 */
  margin-inline: auto;
}

図中の文字サイズを上げて解決しようとすると、枠に収まらなくなる。倍率の側を止める。

囲みを増やさない

補足や注意を置くたびに枠線付きのボックスを足すのは、AI が生成した資料の典型的な見た目になる。 枠線は使わず、薄い地色と小さめの角丸だけで区別する。 意味ごとに色を変え、形は 1 種類に保つ。

.callout { background: var(--pos-bg); border: none; border-radius: 4px; }  /* 補足 */
.callout.warn { background: var(--neg-bg); }                               /* 注意 */

8. AI が作った見た目にしない

読み手は中身を読む前に見た目で判断する。次の指摘は実在する反応である。

手抜きの AI がデザインしたウェブページを見るのにうんざりしている。見た瞬間に離脱するので、製品そのものを評価する機会がない。細い罫線だらけ、光る装飾、書体の不統一、モノスペースの多用。心当たりがあるだろう。

四つとも、放っておくと必ず出る。

参考資料からデザイン文法を抽出する

参考HTMLを渡されたら、色と書体を似せる前に、どの情報をどの部品で見せているかを数える。参考資料の表層だけを移し、本文を単調な見出し・段落・箇条書きのまま残してはならない。

比較表を作り、少なくとも次を両資料で数える。

実例：参考資料にカード・callout・手順・図が30個あり、作成物が0個なら、配色と目次が近くても「参考にした」とは判定しない。内容を意味別部品へ割り当て直す。

装飾用の文言を発明しない

英語のkicker、章ラベル、キャッチコピーは、参考資料の雰囲気を出すための飾りとして追加しない。読者の世界を更新しないためである。

✗ SERVICE INFRASTRUCTURE
  DEPRECATED DEPLOYMENT PATH

⭕ タイトルとサブタイトルだけで対象と主張を示す

kickerを置けるのは、文書種別、部署名、版、機密区分など、一覧性や取り扱い判断に必要な実データがある場合だけ。

モノスペースは「入力そのもの」だけ

コード、キー名、AI に打ち込む指示文。ここまで。 見出し、表のヘッダー、図のラベル、キャプション、章番号には使わない。

見出しがモノスペースの資料は、中身を読む前に「AI が作った」と判断される。書体は本文用と等幅の 2 系統に抑え、差は太さと大きさで付ける。

罫線は構造の境界にだけ

囲みを作るために線を引かない。カード、コードブロック、表の外枠、図の枠、キー表示は、罫線ではなく薄い地色で分ける。

✗ .card { background: var(--surface); border: 1px solid var(--rule); }
⭕ .card { background: var(--surface); border-radius: 4px; }

区切り線は見出しの下に置く

上に置くと「前の節の終わり」に見え、下に置くと「この見出しに属する範囲の始まり」になる。見出しと線が 1 つの塊として読める。

階層は線の太さと形で示す。大項目は左と下の L 型で太く、章は下線 1 本で細く。同じ太さの線が近接して 2 本並ぶと、どちらが区切りか読めない。

影と光彩は装飾に使わない

浮いている要素（フローティングパネルなど）に弱い影を 1 つだけ。それ以外に影を置かない。グラデーションの発光も使わない。

数えて確かめる

主観で判断しない。ブラウザで数える。

const monoRe = /Cascadia|ui-monospace|SFMono|Menlo|Consolas|monospace/i;
let mono = 0, borders = 0, shadow = 0;
document.querySelectorAll('#root *').forEach(el => {
  const cs = getComputedStyle(el);
  if (monoRe.test(cs.fontFamily)) mono++;
  ['Top','Right','Bottom','Left'].forEach(s => {
    if (parseFloat(cs['border'+s+'Width']) > 0 && cs['border'+s+'Style'] !== 'none') borders++;
  });
  if (cs.boxShadow !== 'none') shadow++;
});

実例：ある資料の初回計測は罫線 583 本、モノスペース 207 要素、影 1。 見出しと表ヘッダーと図ラベルを本文書体に戻し、囲みの罫線を地色に置き換えて、罫線 151 本、モノスペース 83 要素（残りはコード、キー名、指示文だけ）。

罫線が 3 桁後半、モノスペースが 3 桁なら、引きすぎ・使いすぎである。

9. 日本語の表記

英数字の前後に空白を入れない

日本語の文中で英数字を空けて書く流儀はあるが、業務資料では使わない。 編集のたびに空白の有無を判断することになり、書き手が増えるほど揺れる。

✗ 3 つの型で作る ／ Pencil は PC に入れて使う ／ 所要 30 分
⭕ 3つの型で作る ／ PencilはPCに入れて使う ／ 所要30分

英単語どうしの空白（pen.dev Documentation）、コード、キー名は当然そのまま。 一括で直すときは、片側が日本語・もう片側が英数字の空白だけを対象にする。タグをまたいだ前後の実文字で判定し、コードブロックとキー表記は除外する。

ソースの改行は空白になる

HTML では改行が半角スペースとして描画される。日本語の段落をソース上で折り返すと、文中に空白が生まれる。

<!-- ソース -->
<p>
  できることは2つ。
  言葉で指示するとAIが画面を作る。
</p>

<!-- 表示 -->
できることは2つ。 言葉で指示するとAIが画面を作る。

段落は 1 行で書く。読みやすさのために折り返すなら、英数字の境界だけにする。

折り返し位置を制御する

ソースが 1 行でも、ブラウザは日本語を文字単位で折り返す。単語の途中で改行され、AIが画／面を作る のように割れる。

body {
  word-break: auto-phrase;      /* 文節の切れ目で折り返す */
  line-break: strict;           /* 禁則処理を厳格に */
  overflow-wrap: break-word;    /* 長い URL のはみ出しだけ許可 */
}

ソースを直しただけで確認を終えない。 折り返しはソースには現れず、表示して初めて分かる。

同じものを 2 通りに書かない

本文の章番号が 00、目次が 0. のように表記が割れると、読み手は同じものだと判断するのに一手余計に使う。番号、単位、用語、記号の形は文書内で 1 つに固定する。

10. ナビゲーション

長い資料では、読み手が現在地と全体像を常に確認できることが要件になる。

• 目次は常時表示。 スクロールしても見える位置に置く。冒頭にだけ置くと、途中で全体像を確認したくなったとき先頭まで戻ることになる。
• 今読んでいる項目を示す。 どこまで来たか、あと何が残っているかが読み手の判断材料になる。
• 階層をインデントで示す。 1 行 1 項目。折り返しで複数項目が同じ行に並ぶと目次として読めない。
• 本文中の相互参照は必ずリンクにする。 「〇章に書いた」と書いておいてリンクが無いと、読み手は先頭に戻って目次を開き、該当箇所を探し、また戻る操作を強いられる。
• 付録・参考資料も目次に載せる。 <footer> に置くとナビゲーションの対象から外れる。本文と同じ構造の節にする。
• 表示形式を選べるようにする。 本文に重ねる（既定）か、右端に固定して本文を縮めるか。固定したまま非表示にしたら、本文は幅いっぱいに戻す。

11. 事実を確認してから書く

• 手順は入口まで実機で確認する。 「作業フォルダに .pen を作る」は誤りで、正しくは「アプリ左上の新規作成から作る（エクスプローラーでは作れない）」。この差が読み手を止める。
• 公式ドキュメントと実機が食い違うときは実機を優先し、食い違いの事実を本文に書く。
• 検証していない手順を、検証したかのような断定で書かない。未検証なら未検証と書く。
• 数字を盛らない。「2 時間かかっていた作業が 10 分に」と書く前に、その 2 時間に根拠があるかを確認する。

12. 埋め込み先で壊れないようにする

HTML の資料は、単体のファイルとして開かれるとは限らない。チャットアプリや社内ポータルの中で描画されると、ホスト側の DOM と同じ土俵に載る。

• id は必ず接頭辞を付ける。 read map close content のような汎用名は、ホスト側の要素と衝突する。衝突すると #map が別の要素を指し、ページ内ジャンプが黙って壊れる。pgw-map のように資料固有の接頭辞を付ける。
• ページ内ジャンプはブラウザ任せにしない。 クリックを捕まえ、自分の容器の中から対象を探して scrollIntoView する。これならホスト側に同名の id があっても正しく動く。
• スクロール位置の判定に window.scrollY を使わない。 ホストが独自のスクロール容器を持つと値が取れない。getBoundingClientRect() の画面座標で判定する。
• 素の要素セレクタ（body h1 p table a）はホスト側を巻き添えにする。 資料の外枠に id を振り、その配下に限定するのが安全。
• クラス名も card page content のような一般名は、ホストの CSS に上書きされうる。

13. 公開前の点検

1. 境界テスト：本文を上から読み、資料の来歴・検証・書き方の指針に触れた文を全部削る。例外（出典、公式との食い違い、未確定の明示）だけ残す。
2. 見出しテスト：見出しだけ抜き出して並べる。それだけで主張が追えるか。「で、何？」が残る見出しを書き換える。
3. 敬体テスト：ます。 ません。 ください。 を検索し、0 件にする。
4. 主題テスト：節ごとに、タイトルが約束したこと以外を書いていないか。比較対象の解説、心情、予告、訓示を探して削る。
5. 谷テスト：表・図・手順リストに不要な導入文が付いていないか。
6. 山テスト：地の文が 3 段落以上続く箇所を数える。因果を運んでいるなら残す。並列の羅列なら表に変える。
7. 余白テスト：短い拍を置いた箇所で、段落間隔が長文と同じになっていないか。見出しと直後の本文の距離を実測し、gap と既定マージンが二重に効いていないか確認する。
8. 階層テスト：大項目 > 章 > 節 > 本文 ≧ 強調、の順にサイズが並んでいるか実測する。強調が見出しを超えていたら下げる。図中の文字も、描画倍率を掛けた実表示サイズで本文と比べる。
9. レンダリング検査：横スクロールの発生、要素のはみ出し、目次のリンク切れ、図の枠外要素を機械的に確認する。
10. 目視確認：数値検査を通っても壊れていることがある。必ずページを表示して見る。
    • ソースの検査だけで済ませない。折り返し位置、要素の重なり、階層の見え方はソースに現れない。
    • 狭い領域で文字が 1 行 1 文字に縦積みされていた事故は、position や幅の数値検査を通過していた。
    • 文字列を置換したら、置換後の表示を見る。ソースが正しくても表示が直っているとは限らない。
11. 埋め込み検査：id が全部接頭辞付きか。ジャンプが JavaScript 経由になっているか。
12. AI 見た目テスト：罫線とモノスペース要素を数える。囲みのための罫線、見出しのモノスペース、装飾の影を消す。
13. 表記テスト：日本語と英数字のあいだの空白を全走査して 0 にする。同じものが 2 通りに書かれていないか確認する。
14. ナビゲーションテスト：目次が常時見えるか。現在地が出るか。本文中の「〇章」がすべてリンクになっているか。
15. 意味別部品テスト：全章がh2 + p + ulの反復になっていないか。前提、手順、構造、注意を適切なカード、手順、図、calloutへ割り当てたか。
16. 参考差分テスト：参考資料と作成物で、意味別部品の個数、主要な座標差、ファーストビューを並べる。色が近いことを一致と数えない。
17. ファーストビューテスト：デスクトップと狭幅の画像を保存して並べる。大きな空白、目次による本文遮蔽、タイトルだけで画面を使い切る状態を直す。

14. 点検は全章に等しくかける

規範を書いても、適用しなければ資料は直らない。適用漏れは、章の性格を理由に例外を作ったときに起きる。

• 手順の章だけを点検し、検討メモ・付録・まえがきを対象外にしない。
• 規範を追加したら、その時点で既存の全章に遡ってかける。追加以降に書く章だけに効かせない。
• 点検は章を 1 つずつ、上から順に。まとめて眺めて済ませない。

「これは手順ではないから」「これはメモだから」は、点検を飛ばす理由にならない。読み手にとっては同じ資料の一部である。

15. この規範の更新

資料作成について指摘を受けたら、その場の修正で終わらせず、この規範に反映する。反映するのは次に同じ判断をするときに効く形であって、やりとりの記録ではない。

• 指摘 → 一般化した規範 → 悪い例と直した例、の順で追記する。
• 既存の項目と重なるなら、新項目を足さずにその項目を強くする。
• 具体例は、実際に指摘された文言をそのまま使う。抽象化した作例より効く。