review-mobile

MDX コンテンツをモバイル視認性・可読性の観点でレビューし、問題を検出・分類・修正提案する。

/check-mdx --rules syntax（構文チェック）やdesign-review（デザインシステム準拠）とは別レイヤーであり、**コンテンツの「読みやすさ・わかりやすさ」**に焦点を当てる。

引数

$ARGUMENTS — レビュー対象のファイルパスまたはディレクトリ
             （例: content/site/pe-comprehensive-management/pert-cpm/article.mdx）
             （例: content/site/pe-comprehensive-management/pert-cpm/）

• ファイルパス: 単一の MDX ファイルをチェック
• ディレクトリパス: 配下の全 MDX ファイルを一括チェック
• 省略時: git diff --name-only で変更された MDX ファイルを対象

重大度

レベル	定義	対応
HIGH	モバイルで表示が崩れる、または情報が読めなくなる	修正必須
MEDIUM	可読性が低下するが、情報は読める	修正推奨
LOW	改善の余地はあるが、実用上の問題は小さい	参考情報

チェック項目（5カテゴリ）

ルールIDの SSOT: 機械検知ルールの重大度・資格×種別の適用は config/content-rules.json、実装は .claude/scripts/lint-mdx-mobile.mjs が真実源。本スキルのカテゴリ番号（0〜5）は Claude 校正用の人間向けチェックリスト分類で、機械のルールID体系とは一部異なる（例: 数式＝スキル 3-x／機械 11-x、段落＝スキル 4-x／機械 15-x）。機械IDを参照する行は「機械: lint N-M」と明記する。全量ラチェット（npm run check-content-quality）は content-rules.json の fullScan ルール（表/入れ子リスト/段落長/見出し/文体）だけを追い、baseline 超過の新規違反を赤落ちさせる。

0. ファイル整合性

#	チェック	重大度	検出方法
0-1	改行コードの混在（CRLF + LF）がないか	HIGH	\r\n と単独 \n の共存判定

修正提案: スクリプトで MDX を書き込む場合は必ず .claude/scripts/lib/mdx-io.mjs の readMdxFile / writeMdxFile / transformMdxFile を経由する。直接 writeFileSync を使うと混在が発生する。詳細は CLAUDE.md の「MDXファイル書き込みの規約」を参照。

1. テーブルの適切性

#	チェック	重大度	検出方法
1-1	表セル内にKaTeX数式（$...$）が含まれていないか	HIGH	表行内の $ を検出
1-2	計算手順を表で表現していないか	HIGH	表セル内に =, +, −, ×, / 等の演算記号が含まれ、かつ数値結果がある
1-3	4列以上の表がないか	MEDIUM	セパレーター行の `
1-4	3列以上の表で、セル内テキストが15文字超のものがないか	MEDIUM	表パース→各セルの文字数
1-5	キーバリュー表（項目/内容、正式名称/目的等）がないか	HIGH	表ヘッダーが「項目」「内容」のパターン、または第1列が法律メタデータ（正式名称、目的、所管、施行等）
1-6	2列テーブルで各行が独立した定義になっていないか	MEDIUM	2列テーブルのうち、行間に比較関係がなく、各行を - **term**: desc で自然に表現できるもの
1-7	壊れた表（ヘッダー＋セパレータのみで本文行ゼロ）がないか	HIGH	表パース→本文行ゼロを検出。lint-mdx-mobile.mjs 1-7 と pre-commit checkBrokenTables の両方でブロック

修正提案パターン:

• KaTeX入り表 → 箇条書き + テキスト数式に分離（例: - **性能稼働率** = 基準CT × 数量 / 稼働時間）
• 計算手順の表 → 番号付きリストに変換
• 4列以上 → 横スクロールで延命せず、表以外へ変換（分野別 H3＋箇条書き / <SpecSheetList> / 年度キーのフラット箇条書き）。早見表は content-authoring.md の「表 → 非表 変換パターンカタログ」
• 長いセル → セル内容の短縮、または備考を括弧表記に統合
• キーバリュー表（1-5） → 冒頭散文に統合。表を削除し、情報を既存段落に追記
• 独立定義表（1-6） → 箇条書き + 太字ターム: - **用語**: 説明
• 壊れた表（1-7） → 残骸のヘッダー＋区切り行を削除／キャプションは **表 X** 太字行に／空フォームは記載項目を箇条書き化（§4）

2. 解説の簡潔性

#	チェック	重大度	検出方法
2-1	不要な絵文字（❌✅💡🔑📌⚠️等）がないか	HIGH	Unicode絵文字範囲（U+2600-U+27BF, U+1F300-U+1F9FF等）の検出
2-2	同じ情報が繰り返されていないか	MEDIUM	選択肢ごとの判定 + 末尾まとめなど、同内容の重複パターン
2-3	過剰な強調がないか	LOW	1段落内の **...** が3箇所以上

修正提案パターン:

• 絵文字 → 削除
• 情報の重複 → 末尾まとめを削除し、選択肢ごとの判定のみ残す
• 過剰な強調 → 最も重要な1箇所のみ太字に絞る

3. 数式の可読性

#	チェック	重大度	検出方法
3-1	ブロック数式（$$...$$）の前後に空行があるか	HIGH	$$ の前後行が空行かチェック
3-2	インライン数式が長すぎないか（30文字超）	MEDIUM	$...$ 内の文字数カウント

4. 段落構成

#	チェック	重大度	検出方法
4-1	連続する長い段落（空行なしで4行以上）がないか	MEDIUM	連続非空行カウント（コードブロック・表・リスト内は除外）
4-2	箇条書きが10項目以上連続していないか	LOW	リスト項目カウント
4-3	入れ子リスト（2階層以上）がないか	MEDIUM	機械: lint-mdx-mobile 3-1。太字リード＋フラット1階層 or <SpecSheetList> へ
4-4	1段落が300字（目安200字）を超えていないか	MEDIUM	機械: lint-mdx-mobile 15-3。2〜3文で改段（note は〜120字で別系統）

修正提案パターン:

• 入れ子リスト（4-3） → 親項目を太字リードの見出し的な独立行にし、子項目をフラットな1階層へ。仕様的な列挙は <SpecSheetList>
• 長い段落（4-4） → 論点ごとに改段。表・年度マトリクスを段落に詰め込まない（content-authoring.md の表→非表 変換カタログ参照）

5. コンポーネント使用

#	チェック	重大度	検出方法
5-1	::: 記法が <details> と同一ファイルで混在していないか	HIGH	::: と <details> の共存チェック（パーサー誤動作の原因）
5-2	<Callout> が1記事に5個以上ないか	LOW	コンポーネント出現数カウント
5-3	<ExamPoint> が概要セクション（〜とは）の直後に配置されていないか	MEDIUM	「とは」を含む見出しの直後にExamPointがあるか

出力形式

=== review-mobile: <ファイルパス> ===

[HIGH] L29-33: 表セル内にKaTeX数式が含まれています — モバイルで横スクロールが発生します
  → 修正案: 箇条書き + テキスト数式に分離
  現在: | 性能稼働率 | $\frac{...}{...}$ | 設備が... |
  推奨: - **性能稼働率** = 基準CT × 加工数量 / 稼働時間（本来の能力で動いた割合）

[MEDIUM] L43-50: 3列テーブルの「備考」列にモバイルで折り返しが発生する可能性があります
  → 修正案: 備考を値の後に括弧で追記し、箇条書きに変換

Summary: HIGH 1 / MEDIUM 1 / LOW 0

6. 導入文の有無

#	チェック	重大度	検出方法
6-1	表の直前行が見出し行（## / ###）のみで、導入文がない	MEDIUM	機械検知（lint-mdx-mobile 6-1、全記事）。見出しの次の非空行が |
6-2	見出し直下にいきなり箇条書き（- / * / 1. ）で導入文がない	MEDIUM	機械検知（lint-mdx-mobile 6-2、group: guide 限定）
6-3	見出し直下にいきなり図（<ArticleImage> / <img> / ![]）で導入文がない	MEDIUM	機械検知（lint-mdx-mobile 6-3、group: guide 限定）
6-4	見出し直下にいきなり <SpecSheetList> で導入文がない	MEDIUM	機械検知（lint-mdx-mobile 6-4、group: guide 限定）
6-5	見出し直下にいきなり <Callout>（試験のポイント予告も含む）で導入文がない	MEDIUM	機械検知（lint-mdx-mobile 6-5、group: guide 限定、§5「見出しと Callout を直結しない」）
6-6	記事冒頭がリード散文なしで構造物（Callout/見出し/表/箇条書き/画像/コンポーネント）直始まり	MEDIUM	機械検知（lint-mdx-mobile 6-6、group: guide/secondary/textbook、過去問除外）
9-14	<Callout> が連続（間に地の文なし。faq 同士は除外）	MEDIUM	機械検知（lint-mdx-mobile 9-14、§7.1-5、過去問除外）
9-15	例題・計算例タイトルの <Callout>（本文の Callout 化）	MEDIUM	機械検知（lint-mdx-mobile 9-15、§7.1-1、過去問除外）
9-16	<Callout> 密度超過（guide/pillar >12・その他 >3）	MEDIUM	機械検知（lint-mdx-mobile 9-16、§5/§7、過去問除外）

スコープ注: 6-2/6-3/6-4/6-5 は §2/§8/§17-2/§5 の機械強制で group: guide 限定（である調のキーワードページは許容度が異なり全件強制するとノイズになるためエージェント目視に委ねる）。過去問アーカイブも除外。6-6（冒頭リード）は guide/secondary/textbook、9-14〜16（Callout 運用）は全 group（いずれも過去問除外）。<Callout> を見出しの直後に地の文なしで置くのは 6-5 が検出（旧「§5 例外で対象外」は 2026-07-15 に方針転換＝試験のポイント予告も 1〜2 文リードを挟む）。<ExamPoint> の位置は 9-2 / 9-5 が担当。

修正提案パターン:

• 見出しと表/リスト/図の間に、1〜2文の導入文を追加するよう提案する
• 導入文の例: 「以下の表は〜を整理したものである」「〜の観点から、以下の項目が重要となる」

8. リンクの配置

#	チェック	重大度	検出方法
8-1	末尾に 関連キーワード: [A]、[B] の列挙行がないか	MEDIUM	正規表現 ^関連キーワード[:：]
8-2	法令条文「◯◯法第◯条」が e-Gov インラインリンクになっているか	LOW	正規表現 `(◯◯法

修正提案パターン（8-1 末尾リスト）:

• 末尾の列挙行を削除し、各キーワードを「総合技術監理における位置づけ」本文の自然な流れの中にインラインリンクとして埋め込む
• 本文に溶け込ませにくいキーワードは、関連性が弱いので含めない判断も可
• 過去問MDXでの <RelatedKeywords> コンポーネント使用はこのルールの対象外（過去問→キーワードの双方向紐付けで正当な用途）

修正提案パターン（8-2 法令条文リンク）:

• 法令条文を [**法律名第◯条**](https://laws.e-gov.go.jp/law/{法令番号}#Mp-At_{条番号}) 形式でリンク化する
• 太字はリンクテキスト内に置く（MDX は **[text](url)** を正しくパースしないため）
• 同一ファイル内で同じ条文が複数回登場する場合は、初出のみリンクし2回目以降はテキストのままで可
• 一般論として法律名のみ言及する場合（条番号なし）は対象外
• 建設業法の片務的契約の禁止（第18条） のように法律名と条番号が離れているケースは lint で検出されない場合があるので、手動で確認する

既知の法令番号（e-Gov ID 形式 YYYAC0000000NNN = 元号年＋法律番号）:

• 独占禁止法: 322AC0000000054
• 建設業法: 324AC0000000100
• 特許法: 334AC0000000121
• 著作権法: 345AC0000000048
• 民法: 129AC0000000089
• 環境基本法: 405AC0000000091

7. 必須セクションの有無

keyword-page スキルのテンプレートで定義された必須セクションが存在するかをチェックする。

#	チェック	重大度	検出方法
7-1	## 参考資料 セクションが存在するか	HIGH	## 参考資料 見出しの有無
7-2	参考資料に最低1件のリンクがあるか	HIGH	## 参考資料 直後に - [ で始まる行があるか

9. コンポーネント原則（content-principles.md §5・§9 機械化）

技術士総合技術監理キーワードページ向け。過去問MDX（r*-primary, h*-primary, r*-secondary）は除外される。

#	チェック	重大度	検出方法
9-1	<ExamPoint> が3個以上ないか	HIGH	開始タグの出現回数
9-2	総括 <ExamPoint>（最後のExamPoint）が記事の60%地点以降にあるか	MEDIUM	行番号 / 総行数
9-3	<ExamPoint> の summary/items に「誤り選択肢」「代表的な誤り」等を含まないか	HIGH	ExamPointブロック内の正規表現
9-4	## 参考資料 の外部リンクが2件以上 かつ 公的（go.jp/ac.jp/or.jp）と民間の両方を含むか	MEDIUM	URL抽出→ドメイン分類
9-5	「とは」H2 の直下（最初のH3より前）に <ExamPoint> がないか	LOW	H2セクション内のH3前領域スキャン
9-6	本文に「正答：」「❌」「✅」「代表的な誤り」が出現しないか	HIGH	過去問判定記号の検出

修正提案パターン:

• 9-1: ExamPoint を統合 or 削除し1〜2個に。総括ExamPoint 1個（記事末尾）を必須とする
• 9-3: 「誤り選択肢パターン」は過去問MDXの <details> 解説ブロックに移管。ExamPoint は概念総括型に書き換え
• 9-4: WebSearch→WebFetch で民間記事（Wikipedia/技術ブログ/note等）を1件追加
• 9-6: ❌✅などの記号を削除し、解説的な文言に書き換え

ルール根拠: .claude/knowledge/reference/content-principles.md §5「ExamPointは文脈の後に配置」・§9「参考資料の構成」 | 7-3 | ## 過去問での出題 セクションが存在するか | MEDIUM | ## 過去問 見出しの有無 | | 7-4 | ## 総合技術監理における位置づけ セクションが存在するか | MEDIUM | 見出しの有無 |

修正提案パターン:

• 参考資料がない → WebSearch で官公庁資料を検索し、セクションを追加するよう提案
• 過去問セクションがない → 「（なし）」でもセクション自体は設けるよう提案

10. SVG 追加候補の検出（プロンプトベース・常に実行）

技術士総合技術監理キーワードページ向け。過去問 MDX（r*-primary, h*-primary, r*-secondary）は除外する。

記事構造を走査し、図示価値の高いパターンで未カバーの概念を 推奨情報 としてレポートする。ブロックはしない（重大度 LOW 固定）が、毎回必ず実行し、検出 0 件でもその旨を出力する。

Step A: 既存図のインベントリ

1. content/site/{slug}/img/ を確認（SVG ファイルの有無・命名）
2. MDX 内の <ArticleImage> タグから alt 属性を抽出
3. 各 SVG 冒頭の <!-- source: --> コメントの概念キーワードを補完参照
4. これらから「既にカバー済みの概念」リストを作成

Step B: 構造パターン検出

記事の H2/H3 セクション単位で走査し、以下の図示価値の高いパターンを検出する:

#	パターン	検出手掛かり
10-A	分類・階層（ツリー／マトリクス）	「〜は A と B に大別される」「〜に分類される」「〜の体系」＋太字分類ラベルのネスト or 3 項目以上の並列記述
10-B	時系列・プロセス（フロー）	「段階」「ステップ」「Phase」「PDCA」＋番号付きリスト（3 ステップ以上）
10-C	2 軸対比	「vs」「対して」「一方」「違い」＋2 概念の特徴が 3 観点以上で対比記述されている
10-D	定量関係・曲線	バスタブカーブ・S カーブ・学習曲線等の曲線概念＋「〜期」「〜段階」等の区分語
10-E	サイクル・循環	「サイクル」「繰り返し」「ループ」＋3 ステップ以上の循環記述

Step C: 除外条件

以下の場合は検出しても 報告しない:

• Step A で既にカバー済み（alt 属性・SVG 出典コメントに概念キーワードが一致）
• H3 見出しだけで分岐表現が完結し、本文が 3 行未満で情報量が少ない
• 他のキーワード記事に同概念の図があり、内部リンクで参照済み（例: バスタブカーブは /docs/pe-comprehensive-management-bathtub-curve を参照している場合）
• 該当セクションが単純な 2 項目列挙のみ（「A と B」で終わる構造は図示価値が低い）

Step D: レポート書式

[LOW] L{start}-L{end}: 「### {見出し名}」に{パターン名}の図示候補あり
  パターン: 10-{A〜E}
  検出根拠: {該当する記述の要点、1〜2 行}
  推奨アクション: /illustrate-concept {path} で Web 素材の有無を確認

検出 0 件の場合もサマリーを出力 する（False-negative 検証用）:

Category 10: SVG 追加候補検出 — 0 件（既存図でカバー済み、または図示価値の高いパターンなし）

修正提案パターン:

• 検出された候補は LOW 重大度 でユーザーに提示する。自動修正は行わない
• ユーザーが SVG 化を希望した場合は /illustrate-concept {path} を別途起動する運用（本スキルは検出のみ担当）

12. 散文密度・末尾コンポーネント塊化（content-principles.md §17・§18 機械化）

技術士総合技術監理キーワードページ向け。過去問 MDX（r*-primary, h*-primary, r*-secondary）は除外される。

#	チェック	重大度	検出方法
12-1	全体散文密度が低い（散文行 / 総コンテンツ行 < 0.5）	LOW	## 参考資料 を除く本文で、表行・箇条書き行・コードブロック・JSX タグ単独行以外を散文行として比率算出
12-2	H2 セクション内に散文 0 行（表または箇条書きのみで構成）	LOW	各 H2 セクション（参考資料を除く）で散文行が 0 のものを検出
12-3	<SeeAlso> <ExamPoint> <RelatedKeywords> が連続 3 件以上で末尾塊化	MEDIUM	コンポーネント開始タグの間が空行のみで 3 件以上連続

修正提案パターン:

• 12-1（散文密度低）: 教材『総監標準テキスト』（content/sources/textbook/技術士（総監）/テキスト/総監標準テキスト/）の対応章を読み、各 H2 セクションに散文 1 段落以上を追加する。表・箇条書きを散文に書き換える、または散文の補足として後置する
• 12-2（H2 セクション散文ゼロ）: 該当 H2 直下に 1〜2 文の導入散文を追加する（§2「表の前に文脈」と同方針）
• 12-3（末尾塊化）: <SeeAlso> を本文中（関連トピックを言及した直後）に移動する。それでも解消しなければ本文の散文を厚くして、コンポーネントが「総括」として機能する位置関係を作る

目視補完チェック（機械化困難な定性判断）:

• 教材ベンチマーク（散文 60〜65%）と比較して、散文の質が「概念の文脈・なぜそうなるか」を伝えているか
• タイプ A 反例（pdca-cycle/article.mdx、four-m-of-production/article.mdx）と類似していないか
• タイプ B 模範（business-continuity-plan/article.mdx、cash-flow-statement/article.mdx）の段落構成と比較

ルール根拠: .claude/knowledge/reference/content-principles.md §17「散文中心・表と図は補足」・§18「末尾コンポーネント塊化の禁止」

15. 文体: 1 文の長さ・文末の単調回避（content-principles.md §24 機械化）

地の文（散文）のみ対象。見出し・表・箇条書き・JSX コンポーネント・コード・数式は除外する。過去問の公式問題の逐語（問題見出しから <details>・「### 解説」まで）も原文を保持するので対象外（判定は scripts/lib/official-question-text.mjs の 1 か所・content-principles.md §24）。

#	チェック	重大度	検出方法
15-1	丁寧体の同一文末（です／ます／ました）が3文以上連続していないか	MEDIUM	散文を句点で分割→文末の連続判定。である調（〜である。〜する。〜た。）は学術文として許容され対象外
15-2	1文が長すぎないか（句点区切りで140字超）	LOW	散文を句点で分割→各文の実質字数。目安は60〜80字、定義文の正当な長文を避けるため閾値は140字

修正提案パターン:

• 15-1（文末の単調） → 語尾に変化をつける（「〜です」「〜ます」「〜でしょう」「体言止め」を混ぜる）。ですます調のガイドが主対象
• 15-2（長文） → 句点で自然に切れる箇所で2文に分割する。法令・技術概念の定義文は100字前後まで許容

ルール根拠: .claude/knowledge/reference/content-principles.md §24「文体: 1 文の長さと文末の単調回避」

手順

Step 1: 機械チェック（必須・省略不可）

まず以下のスクリプトを実行して、機械判定可能な違反を網羅的に検出する。このステップを省略して目視判定だけで済ませてはならない。

node .claude/scripts/lint-mdx-mobile.mjs <target>

• 引数: ファイルパス・ディレクトリ・省略（git diff 対象）
• 検出ルール（抜粋）: 1-1（長いKaTeX混入）/ 1-3（4列以上）/ 1-4（3列表でセル15字超）/ 1-5（キーバリュー表）/ 1-7（壊れた表・HIGH）/ 6-1（表の前に導入文なし）/ 6-2〜6-5（見出し直下のいきなり箇条書き・図・SpecSheetList・Callout、group:guide限定）/ 6-6（冒頭リード欠如）/ 9-14〜16（Callout 連続・例題化・密度）/ 12-1〜12-3（散文密度・末尾塊化）/ 15-1〜15-2（文体: 文末の単調・長文）
• 終了コード: HIGH ありで 1、それ以外で 0

出力の HIGH / MEDIUM 違反を全て記録し、Step 4 の結果出力に統合する。

Step 2: 対象ファイルの特定

引数に基づいて対象ファイルを特定する。省略時は git diff --name-only で変更MDXファイルを取得。

Step 3: ファイル読み込み

各MDXファイルを Read で読み込む。frontmatter以降の本文を対象とする。

Step 4: 目視チェック（機械チェックを補完する項目のみ）

Step 1 で検出できない項目（解説の簡潔性・段落構成・コンポーネント配置・絵文字など）をチェックする。問題を検出したら行番号・重大度・修正案を記録する。

Step 1 で HIGH/MEDIUM ゼロでも Step 4 は必須。機械チェックは表中心で、文章の冗長さ・重複・絵文字などは判定できない。

カテゴリ 10「SVG 追加候補の検出」は Claude の構造判定に依存するため、毎回必ず実施する（検出 0 件でもサマリーを出力）。

チェック時の注意：

• コードブロック（```）内は全チェックの対象外とする
• <details> 内のコンテンツもチェック対象に含める

Step 5: 結果出力

ファイル別に、重大度の高い順（HIGH → MEDIUM → LOW）で問題を一覧表示する。末尾にサマリー行を出力。

HIGHが1件以上ある場合は修正を促すメッセージを追加する。

Step 6: 修正実行（ユーザー確認後）

ユーザーが同意した修正案を Edit ツールで適用する。修正後に再度 node .claude/scripts/lint-mdx-mobile.mjs を実行し、違反ゼロを確認してから /check-mdx --rules syntax で構文チェックを実行する。

アンチパターン（やってはいけない）

過去に実際に発生した失敗から得た禁止事項。

• 「3列だからOK」と列数だけで判定する — 列数と関係なく、3列以上の表は必ずセル文字数を計測せよ。lint-mdx-mobile.mjs の 1-4 ルールで機械判定できる
• lint スクリプトの実行をスキップして主観判定だけで済ませる — 表の字数は必ず機械チェックに委ねる。目視は補完にとどめる
• $\alpha$ のような短い記号を理由に表の数式を見落とす — 短い数式は許容だが、3列以上の表で長い説明セルに混入した数式は別ルール（1-4）で引っかかる
• keyword-page スキル経由で編集したから review-mobile は不要、と省略する — keyword-page の Step 5 は /review-mobile を連続実行するよう明記されている。両者は併用必須

参照

• .claude/knowledge/reference/content-principles.md — ペルソナ定義、コンテンツ原則（7項目）
• .claude/knowledge/reference/content-authoring.md — MDX 作成詳細ルール（モバイル視認性セクション）
• .claude/skills/authoring/keyword-page/SKILL.md — モバイル視認性ルール、コンポーネント使用ガイドライン
• .claude/skills/quality/check-mdx/SKILL.md — MDX 検査統合スキル（本スキルとは別レイヤー、--rules syntax で構文チェック）