Claude Codeでアクセシビリティを自動修正｜3ステップ手順

自社サイトのアクセシビリティ、気になってはいるけれど後回しになっていませんか。「読み上げソフトに対応できていないかも」「色のコントラストが弱い気がする」と感じつつ、何から手をつければいいか分からないまま放置されがちなテーマです。

この記事では、Claude Codeを使ってサイトのアクセシビリティ問題をAIに検出・修正させる具体的な手順を、非エンジニアの方にも分かるように解説します。何を準備し、どの順番で進め、AIが出した修正をどう確認すればいいのか。つまずきやすいポイントや、AIに任せていい範囲と自分で確認すべき範囲の線引きまで、率直にお伝えします。

Contents / 目次

1. 結論。Claude Codeでのアクセシビリティ修正は「測る・直す・確かめる」の3ステップ
2. 具体的なやり方。検出から修正までの進め方
3. 取り組むとどう変わるか。期待できる成果
4. よくある失敗と、その防ぎ方
5. 使う側の落とし穴と妥協点
6. よくある質問

結論。Claude Codeでのアクセシビリティ修正は「測る・直す・確かめる」の3ステップ

先に答えをお伝えします。Claude Codeを使ったアクセシビリティ修正は、「①AIに現状を測らせる→②優先順位をつけて直させる→③人が実機で確かめる」という3つのステップで進めます。この順番を守ることが、遠回りに見えていちばんの近道です。

用語を整理しておきましょう。ウェブアクセシビリティとは、目が見えにくい人、耳が聞こえにくい人、マウスが使えない人など、さまざまな状況の人がサイトの情報や機能を支障なく使える状態のことです。かんたんに言うと、誰が来ても置いてけぼりにならないサイトにすることです。

Claude Codeとは、Anthropic社のAI「Claude」をターミナル（黒い画面）のほか、デスクトップアプリやブラウザからも使える開発ツールです。つまり、自然な日本語で「このページの問題を直して」と頼むと、AIがサイトのファイルを読み、問題箇所を見つけ、修正案を書き込んでくれる仕組みです。専門のエンジニアがやっていた作業の一部を、対話しながら肩代わりしてもらえると考えてください。

ここで大事なのは、修正のやり方には大きく3つの選択肢があり、それぞれ向き不向きがあるということです。違いを一覧で見てみましょう。

方法	やること	向いている場面	注意点
手作業で直す	人がコードを1つずつ確認・修正	ページ数が少ない、繊細な判断が必要	時間がかかり、見落としも出やすい
Claude Codeで直す	AIが検出から修正案まで作成し、自社で確認	ページ数が多い、定型的な問題を一気に潰したい	AIの修正を自社で検証する工程が必須
オーバーレイツール	JavaScriptで見た目を後から調整	すぐに見た目だけ良くしたい	根本解決にならず、かえって使いにくくなる場合も

結論として、ある程度の規模があるサイトなら、Claude Codeで定型的な問題をまとめて直し、判断が難しい部分だけ人が手をかける「ハイブリッド」が現実的です。AIは検出と下書きが得意、人は文脈の判断が得意という役割分担を最初に決めておくと、後の工程がぐっと楽になります。

押さえどころ。AIに全部任せて終わり、にしないこと。「測る・直す・確かめる」のうち、最後の「確かめる」を自社で行うからこそ、本当に使えるサイトになります。

具体的なやり方。検出から修正までの進め方

ここからは、実際に手を動かす手順を順番に説明します。Claude Code自体のインストールや初期ログインは公式ドキュメントに従えば完了するので、本記事では「動く状態になったあと、何を・どの順番で頼むか」という中身に絞ってお伝えします。

ステップ1。まず現状をAIに測らせる

最初にやるべきは、修正ではなく「いま何が問題なのか」を洗い出すことです。いきなり直し始めると、何を直したのか分からなくなります。Claude Codeに、アクセシビリティ検査の定番である「axe-core」というオープンソースの検査エンジンを使った診断をセットアップしてもらいましょう。 axe-coreとは、WCAGという国際基準に照らして問題箇所を機械的に見つけてくれるツールです。

たたき台として、こんな短い依頼文（seed）から始めてみてください。完成形を作り込む必要はありません。あとはAIと対話しながら、自社の状況に合わせて詰めていけば大丈夫です。

あなたはWebアクセシビリティに詳しいエンジニアです。
このプロジェクトのトップページに対して、axe-coreで
アクセシビリティ検査を実行する設定を作ってください。
基準はWCAG 2.2のAAにしてください。
検出された問題は「深刻度」「該当箇所」「推奨される直し方」
の3つに整理して一覧にまとめてください。
対象URLは［ 自社サイトのURLを入力 ］です。

WCAG 2.2とは、W3Cが勧告しているウェブアクセシビリティの国際的なガイドラインの最新版で、国際規格ISO/IEC 40500:2025にもなっています。「AA」は、A・AA・AAAの3つある達成レベルの中間です。Claudeにこの基準を伝えておくと、出力のブレが小さくなります。

Claude Codeが用意してくれる検査の中身は、たとえば次のようなスクリプトになります。ブラウザ自動化ツール「Playwright」とaxe-coreを組み合わせた、たたき台として使える例です。

// 前提：Node.js 22以上が入っていること
// 初回のみ実行：npm install -D @playwright/test @axe-core/playwright
// 初回のみ実行（検査に使うブラウザの取得）：npx playwright install chromium
// 検査の実行：npx playwright test a11y.spec.js

const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

test('トップページのアクセシビリティ検査', async ({ page }) => {
  // ［ 自社サイトのURLに変更 ］
  await page.goto('https://example.com/');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa']) // WCAG 2.2のAAまでを対象
    .analyze();

  // 見つかった問題を一覧でコンソールに表示する
  console.log(JSON.stringify(results.violations, null, 2));

  // この行は最初は失敗する想定。違反ゼロが最終ゴールなので、まずは上のconsole.logで中身を把握する
  expect(results.violations).toEqual([]);
});

最初の実行では、まず問題がずらりと出てくるはずです。それで正解です。ここでの目的は合格することではなく、自社サイトの弱点を一覧にすることだからです。

ステップ2。優先順位をつけて直させる

洗い出した問題を、片っ端から直すのは非効率です。影響の大きい順に手をつけましょう。アクセシビリティの問題は、ざっくり次の優先順で対応すると効果が出やすいです。

• 画像の代替テキスト（alt属性）：画像が何を表すかを文章で説明する。読み上げソフトが頼りにする最重要項目
• 色のコントラスト：文字色と背景色の差が弱いと読めない。WCAGのAA基準では通常の文字で4.5対1以上が目安
• 見出しの構造：h1→h2→h3と階層が飛ばずに並んでいるか。読み上げ時の道しるべになる
• キーボード操作：マウスを使わずTabキーだけで全ての機能が使えるか
• フォームのラベル：入力欄に「何を入れる欄か」が機械にも伝わる形で結びついているか

この優先順位をClaude Codeに伝えたうえで、一つずつ修正を依頼します。たとえば「コントラスト不足の箇所を、デザインの印象を大きく変えずにWCAG 2.2のAA基準を満たす色に調整して。変更前後の色コードを一覧で見せて」と頼むと、AIは該当のCSSを探し、修正案と理由をセットで返してくれます。

alt属性の自動生成だけは特に注意が必要です。AIは画像を「犬が芝生にいる写真」のように説明できますが、その画像が記事の中でどんな意味を持つかまでは分かりません。装飾目的の画像なら空のalt（alt=””）が正解の場合もあります。生成された文章は必ず人が見て、文脈に合うか確認してください。

ステップ3。AIの修正を自分の目と手で確かめる

ここがいちばん価値の高い工程です。Claude Codeの修正は、機械的なチェックを通すことはできても、「実際に使いやすいか」までは保証できません。次のチェックリストで、人の目と手で確かめましょう。

• キーボードだけで操作：マウスから手を離し、Tabキーとエンターキーだけでメニュー・リンク・フォームをひと通り操作できるか
• 読み上げで確認：WindowsならNVDA（無料）、MacならVoiceOver（標準搭載）で、ページを上から読ませて意味が通るか
• alt文の妥当性：AIが付けた代替テキストが、画像の「見た目」ではなく「役割」を説明できているか
• 見た目の崩れ：色やマークアップを変えたことで、デザインが意図せず崩れていないか
• 変更箇所の記録：どのファイルの何を変えたか、Claude Codeに変更内容の要約を出させて保存したか

初動の3ステップ。まずトップページ1枚だけをaxe-coreで検査する→出てきた問題のうち「画像のalt」と「コントラスト」の2つだけ直す→NVDAかVoiceOverで実際に読み上げて確かめる。この小さな1周を体験すると、全体像が一気につかめます。

画像のalt属性とコントラストの自動補正の進め方はCursorで画像のalt属性とコントラストを一括点検・補正する手順でも具体的に触れています。あわせて読むと、AIエディタごとの使い分けが見えてきます。

取り組むとどう変わるか。期待できる成果

アクセシビリティ対応は「やさしさ」の話だけではありません。事業面でもはっきりした効果があります。結論から言えば、対応工数の削減・法的リスクの低減・サイト品質の底上げという3つの変化が見込めます。

まず工数です。これまで人が1ページずつ目視で確認していた検出作業を、AIが一気に肩代わりします。とくにページ数の多いコーポレートサイトやオウンドメディアでは、検出と修正案づくりの初動が速くなり、人は判断が必要な部分に集中できます。ただし削減できる時間はサイトの規模や状態で大きく変わるため、「何時間減る」と一律には言えません。まずは1ページで試し、自社のペースを測ってから全体に広げるのが堅実です。

次に法的な観点です。日本では2024年4月に改正障害者差別解消法が施行され、民間事業者にも障害のある人への「合理的配慮の提供」が義務づけられました。 ウェブサイトそのものを完璧に対応させることが直ちに法律で強制されるわけではありませんが、社会全体でアクセシビリティへの期待値が上がっているのは確かです。早めに着手しておくことが、企業としての姿勢を示すことにつながります。

AIが生成したものをそのまま使えば自動でアクセシブルになる、というわけではない点を理解しておくと、過度な期待による失敗を避けられます。

そして見落とされがちなのが、品質面の副次効果です。GoogleはSEOスターターガイドで、適切な代替テキストは、画像が何を表しているかや画像とページの関係を検索エンジンが理解する助けになると説明しています。一方、見出しを意味の順に並べることは、スクリーンリーダーには大切ですが、Google検索では順番どおりでなくても問題ないとしています。代替テキストを書いても、検索順位が上がると保証されるわけではありません。

よくある失敗と、その防ぎ方

起こりやすい失敗を、防ぎ方とセットで紹介します。先に知っておくだけで、無駄なやり直しをかなり減らせます。

失敗1。AIに丸投げして的外れな代替テキストが大量にできる

「全画像にalt属性をつけて」と一言で頼むと、AIは画像を機械的に説明した文章を量産します。一見すると対応済みに見えますが、読み上げソフトのユーザーには「グラフの画像」「写真」のような中身のない説明が延々と読み上げられ、かえって使いにくくなります。

防ぐには、AIに画像の役割を判断する材料を渡すことです。「この画像は記事の何を説明しているか、周辺の文章も読んだうえでalt文を提案して。装飾目的だと判断したものは空のaltにして」と頼み、出てきた候補を人が一つずつ確認します。手間に見えますが、ここを省くと対応の意味が薄れます。

失敗2。オーバーレイで見た目だけ取り繕い、根本解決にならない

JavaScriptを後から差し込んで、ボタン一つでコントラストや文字サイズを切り替えられるようにする「オーバーレイ」という手法があります。手軽に見えますが、これは問題を覆い隠しているだけで、サイトの構造そのものは直っていません。支援技術との相性が悪く、かえって操作を妨げてしまうこともあります。

防ぐには、修正はコードのレベルで行うと決めることです。Claude Codeの強みは、まさにこのコードレベルの修正を対話で進められる点にあります。表面的なごまかしではなく、HTMLやCSSの中身を修正していきましょう。

失敗3。自動チェックを通過したら完璧だと思い込む

axe-coreやLighthouseのような自動ツールで「問題ゼロ」になると安心しがちですが、自動チェックで見つけられるのは問題全体の一部にすぎません。たとえば「リンクの文章がそのリンク先を表しているか」「操作の順番が自然か」といった、文脈の判断が必要な部分は機械では判定しきれないのです。

防ぐには、必ず実機での確認を1工程として組み込むことです。キーボードだけの操作と、無料の読み上げソフトでの確認。この2つを習慣にするだけで、自動チェックの穴を大きく埋められます。

失敗4。一度直して終わりにして、また元に戻る

せっかく直しても、その後ページを更新したり新しいコンテンツを追加したりするうちに、いつの間にか問題が再発します。担当者が変わって、対応したこと自体が忘れられることもあります。

防ぐには、検査を仕組みに組み込むことです。サイトを更新するたびに自動でaxe-coreの検査が走るように設定しておけば、新しく入った問題をその場で気づけます。リンク切れを自動で見つけて直す発想はClaude Codeでリンク切れを一括検出し差し替え先まで自動提案でも紹介していますが、アクセシビリティ検査も同じように「定期的に回り続ける仕組み」にしておくのがおすすめです。

使う側の落とし穴と妥協点

ここまで前向きな話をしてきましたが、実際に取り組むと見えてくる「限界」と「割り切りどころ」も率直にお伝えします。ここを知らずに始めると、途中で「思っていたのと違う」となりがちです。

まず、Claude Codeはエンジニアの専門知識を完全に置き換えるものではありません。AIは一般的な問題のパターンを素早く見つけて直せますが、「このフォームの入力エラーを、目が見えない人にどう伝えるべきか」といった設計レベルの判断は、やはり知識のある人の関与が要ります。AIを入れれば人手がゼロになる、という期待は持たないほうがいいです。AIは作業を速くするツールで、判断まで肩代わりするものではありません。

次に、実機テストのコストは見落とされがちです。読み上げソフトを使った確認は、慣れていないと最初は時間がかかります。NVDAやVoiceOverの基本操作を覚える学習コストも発生します。ここを「ついでにできる」と甘く見積もると、対応が中途半端で止まります。最初の数回は、確認に時間がかかる前提でスケジュールを組んでください。

内製と外注の切り分けも悩みどころです。定型的な検出と一次修正はClaude Codeで内製化しやすい一方、複雑なアプリケーションや、法的な要件を厳密に満たす必要がある場合は、専門家のレビューを入れたほうが安全です。「定型的な検出と一次修正は内製、判断が要る部分は専門家」という線引きが、コストと品質のバランスを取りやすい目安です。

最後に、向き不向きです。ページ数が少なく、更新頻度も低いサイトなら、わざわざ仕組みを組むより人が丁寧に直したほうが早いこともあります。Claude Codeでの自動化が効いてくるのは、ページ数が多い、更新が頻繁、複数人で運用しているといった「人手では追いきれない」状況です。自社がどちらに当てはまるかを、最初に見極めておきましょう。社内のデータをAIに渡すときの線引きはAIに入力してはいけない個人情報と社内ルールの作り方の記事も参考になります。あわせて押さえておくと安心です。

よくある質問

読み上げやキー操作への対応も含めて、サイトのリニューアルを検討している方は、コレットラボのホームページ制作・LP制作をご覧ください。事業・顧客・掲載情報を確認し、原稿とページ構成、デザインを作成します。読み上げやキー操作への対応をご希望の場合は初回のご相談で伺います。