Claude CodeでJIS X 8341-3:2016の試験用チェック表を作る — 準拠と一部準拠の表記まで

JIS X 8341-3:2016の試験は、対象ページを選び、達成方法ごとに○×を付け、達成基準チェックリストにまとめ、最後に「準拠」「一部準拠」「配慮」のどれで表記できるかを決める流れです。このうち、表の雛形づくり、結果の転記と集計、表記の条件漏れの確認は、Claude Codeのスキルに任せられる作業です。○×の判定そのものは、試験環境で実際に確かめた人が記入します。

この記事では、ウェブアクセシビリティ基盤委員会(WAIC)の「試験実施ガイドライン」と「対応度表記ガイドライン」の記述に沿って、チェック表を回すスキルと集計スクリプトを組みます。

試験の骨格と、3種類の表の役割

試験実施ガイドラインは、JIS X 8341-3:2016の附属書JB(試験方法)を補足する文書です。JB.1は試験の対象、JB.2は手順、JB.3は結果の表示を扱います。作る表は3種類で、粒度が違います。

実装チェックリストは、達成方法とその検証方法を特定できる技術的根拠を示すための表です。ガイドラインには例(2020年12月版のxlsx)が付いていて、一から作る負担が大きいため既存の例を活用してかまいません。ただし実情に合わせたカスタマイズが前提です。

対象ページをどう選び、何ページ試験するか

ウェブサイト単位で試験するときは、JB.1.2の4方式から選びます。

併用の例として、ランダム25ページに代表15ページ、ランダム40ページに代表10ページ、ランダム25ページに代表35ページが挙がっています。代表ページが多くなる構成では、合計の目安に縛られず、ランダム側で表の「標準」以上を確保するのが望ましい構成です。

b)を使うときは、試験のたびにランダムに選び直します。1回の試験には修正箇所の再検証が含まれるので、直したページを入れ替えるのではなく、同じ試験の中で再確認します。

抽出はスクリプトにしておくと、あとで説明できます。乱数の種を出力に残すのが要点です。

# sample_pages.py: 全ページ一覧(1行1URL)からランダムに抽出する
import random, sys, time
 
urls = [u.strip() for u in open(sys.argv[1], encoding="utf-8") if u.strip()]
n = int(sys.argv[2])
seed = int(time.time())
random.seed(seed)
for u in random.sample(urls, min(n, len(urls))):
    print(u)
print(f"# seed={seed} total={len(urls)} sampled={n}", file=sys.stderr)

python3 sample_pages.py all-urls.txt 25 > random-pages.txt

all-urls.txt はsitemapやCMSの一覧から作ります。代表ページ(トップ、主要な入口、問い合わせや申込みのような主要な操作ページ)は人が選んで別ファイルに置き、ランダム側と合わせて試験対象一覧にします。

試験用スキルを置く

Claude Codeのスキルは、.claude/skills/<スキル名>/SKILL.md に置きます。プロジェクトに置いてコミットすれば、チームの全員が同じ手順で使えます。試験結果は公開物の根拠になるので、Claudeが自動で呼び出さないよう disable-model-invocation: true を付け、/ で明示的に起動する形にします。

.claude/skills/jis-8341-3-test/
├── SKILL.md
├── implementation-checklist.csv   # 実装チェックリストを書き出したもの
└── rollup.py                      # 達成基準チェックリストへの集約

implementation-checklist.csv は、WAICが配布する実装チェックリストの例(xlsx)から、目標の適合レベルに必要なシートを書き出して作ります。レベルAなら「レベルA」シート、レベルAAなら「レベルA」と「レベルAA」の両方です。列は次の形にそろえます。以下の達成方法IDは書式を示す例です。

達成基準,達成方法,適用,適合,注記
1.1.1,G94,○,○,
1.1.1,H37,○,×,alt欠落3件
1.2.1,G158,－,,音声のみのコンテンツなし
1.2.2,G93,－,,字幕が必要な動画なし
2.4.2,H25,○,○,
3.1.1,H57,○,,

SKILL.mdには、ガイドラインの記入規則をそのまま手順として書きます。

---
name: jis-8341-3-test
description: JIS X 8341-3:2016の試験で、実装チェックリストの準備、結果の集約、対応度表記の条件確認を行う
disable-model-invocation: true
allowed-tools: Read Grep Bash(python3 rollup.py *)
---
 
目標の適合レベル: $ARGUMENTS
 
## 守る記入規則
 
- 実装チェックリストの行は削除しない。使わない達成方法は「適用」欄に
  「除外」と書き、理由を「注記」欄に書く
- 試験対象がページに含まれる行は適用「○」、含まれない行は「－」
- 適合は適用「○」の行だけに、人が確認した結果として「○」か「×」を書く
- 適合欄が空の行は、推測で埋めずに一覧にして人に返す
- 「×」の行には、どのページのどの箇所かを注記に残す
 
## 手順
 
1. 試験対象ページの一覧を読み、ページ数と選択方式(a〜d)を確認する
2. implementation-checklist.csv の未記入行を数え、人が記入する順に並べる
3. 記入が済んだら rollup.py で達成基準ごとに集約する
4. 集約結果から、表記(準拠/一部準拠/配慮)の候補と不足している公開物を挙げる

allowed-tools は、そのスキルが起動した1ターンだけ、列挙したツールを確認なしで使える設定です。ここではCSVの読み取りと集約スクリプトの実行だけを許可しています。スキルの説明に使えるフィールドには name、description、disable-model-invocation、allowed-tools があり、名前が1文字でも違うと、エラーにならずに無視されます。ここでは上の4つの綴りをそのまま写してください。

起動は、目標のレベルを引数にして行います。

/jis-8341-3-test AA

$ARGUMENTS に AA が入ります。SKILL.mdは500行以内に収め、詳しい資料は別ファイルに分けるのが公式の勧めです。この記事の例は、それに十分収まる大きさです。

実装チェックリストを現場に合わせて直す

ガイドラインが示すカスタマイズは5つです。Claudeに下書きさせる順に並べると、次のようになります。

制作側の方針が分からないときは、チェックリストの全項目を試験することになり、コストが大きくなります。ガイドラインは、試験する人が制作者と別のときこそ、制作者に確認してカスタマイズするよう勧めています。Claude Codeに任せやすいのは、手順3の除外候補の洗い出しです。サイトのソースを読ませて「この達成方法の対象になる要素(動画、フォーム、PDFなど)があるか」を判定させ、候補を注記つきで出させます。出た候補を採用するかどうかは、試験者が決めます。

達成基準チェックリストへの集約

実装チェックリストの結果から達成基準チェックリストを作る規則も、ガイドラインに書かれています。対応する達成方法がすべて適用なしなら、その達成基準は適用なし(－)です。一つでも適用ありがあれば適用あり(○)になり、適用ありの達成方法がすべて適合なら、その達成基準が適合(○)です。

この規則をスクリプトにします。適合欄が空の行は、○にも×にも寄せず「未記入」として表に出します。

# rollup.py: 実装チェックリスト(CSV)を達成基準ごとに集約する
import csv, sys
from collections import OrderedDict
 
rows = csv.DictReader(open(sys.argv[1], encoding="utf-8"))
groups = OrderedDict()
for r in rows:
    groups.setdefault(r["達成基準"], []).append(r)
 
w = csv.writer(sys.stdout)
w.writerow(["達成基準", "適用", "適合", "不適合の達成方法"])
for sc, items in groups.items():
    applied = [i for i in items if i["適用"] == "○"]
    if not applied:
        w.writerow([sc, "－", "", ""])
    elif any(i["適合"] not in ("○", "×") for i in applied):
        w.writerow([sc, "○", "未記入", ""])
    else:
        ng = [i["達成方法"] for i in applied if i["適合"] == "×"]
        w.writerow([sc, "○", "×" if ng else "○", " / ".join(ng)])

python3 rollup.py implementation-checklist.csv

上の例のCSVに通すと、次の出力になります。

達成基準,適用,適合,不適合の達成方法
1.1.1,○,×,H37
1.2.1,－,,
1.2.2,－,,
2.4.2,○,○,
3.1.1,○,未記入,

1.1.1はH37が×なので不適合、1.2.1と1.2.2は適用なし、3.1.1は適合欄が空なので「未記入」です。「未記入」が一つでも残っている間は、表記の判断に進めません。

「準拠」「一部準拠」「配慮」を名乗る条件

対応度の表記は、WAICの「対応度表記ガイドライン」が定めています。試験を実施するのは「準拠」と「一部準拠」で、「配慮」は試験の有無や結果を問いません。

条件はほかにもあります。

• レベルAAに一部準拠と書くには、レベルAに準拠していることが前提です。レベルAAAも同様に、AAへの準拠が前提になります
• 表記を使うときは、このガイドラインに基づく表記だと明記します。ウェブページなら、ガイドラインのURLを明記するかリンクを張ります
• 「表示」は、ウェブサイトなら公開すること、納品物なら納品書類に明記することを指します
• 表記例は「JIS X 8341-3:2016の適合レベルAAに準拠」の形です

スキルには、集約結果を読んだあとの確認として、この条件を点検させます。Claudeが出すのは「候補」と「不足している公開物」の一覧で、例えば次のような形です。

候補: 一部準拠(適合レベルAA)。2.4.7 が×(レベルAの達成基準はすべて○)
不足: 今後の対応方針(一部準拠で必須)
不足: ウェブアクセシビリティ方針の公開ページのURL
未確認: レベルAの試験結果が全て○で公開されているか(AAの一部準拠の前提)

表記を公開する前に、この一覧をすべて人が確かめます。

試験で踏みやすい落とし穴

もう一つ、「適合」と「準拠」を混ぜないことです。対応度表記ガイドラインによれば、JIS X 8341-3:2016はJISマーク表示制度の対象規格ではなく、適合したものにJISマークを付ける行為はできません。「準拠」は、適合の表明が難しい場合でも5.1の適合要件を満たしていることを示せるよう、委員会が独自に定めた表記です。Claudeに公開文を書かせるときは、スキルの注意書きに「JISマークは使わない」「表記はガイドラインの定義に合わせる」を入れておきます。

支援技術での読み上げのように、試験環境で実際に操作して確かめる項目は、ツールの出力だけでは判定できません。axeのような自動検査の結果を実装チェックリストの根拠に使うなら、機械判定できる範囲と人が確かめる範囲の分担を注記に残します。自動検査をCIに組み込む方法はClaude CodeでPlaywrightとaxeのアクセシビリティ検査をPRで落とすに、プラグインで対話的に回す方法はClaude CodeのAxe Accessibilityプラグインでアクセシビリティ検査を回すにあります。

条項を表に起こす作業との違い

規格の条項から要求事項を抜き出して適合チェック表を作る一般的な手順は、ClaudeでJIS規格の適合チェック表を作るで扱っています。JIS X 8341-3の試験は、チェック表の行がすでにWAICの例で用意されている点が違います。作業の中心は、行を起こすことよりも、除外の理由と○×の根拠を残し、表記の条件を満たしているかを詰めることです。WCAG 2.1 AAを基準にしたデザイン側の監査は、Claudeのaccessibility-reviewスキルでWCAG 2.1 AA監査を回すが別の入口になります。

まとめ

Claude Codeに任せると効果が大きいのは、除外候補の洗い出し、未記入行の検出、達成基準への集約、表記の条件漏れの点検です。逆に、○×の記入と公開する表記の最終決定は、人の側に残しておくと、後から経緯を説明できます。スキルに「行を削除しない」「空欄を推測で埋めない」の2行を入れるだけで、試験記録の信頼性は大きく変わります。