GitHubのアクセシビリティAIが見せる、Web制作副業の現実線

この記事は約 14 分で読めます

読み始める前に少しだけ。今回の話は「Copilot みたいに何でもこなす開発エージェント」ではなく、もっと地味で、もっと現場寄りの「アクセシビリティ専属エージェント」の試作公開です。私たちの副業や個人開発の話に意外と近いところで効いてくる、と私は感じています。

GitHub から、Copilot とは別軸の “a11y 専属エージェント” の話が出てきました

あなたもこのニュース、どこかで見かけたかもしれません。GitHub が 2026 年 5 月 15 日付で、社内パイロット中の「汎用アクセシビリティ・エージェント」について GitHub Blog で振り返り記事 を公開しました。

このエージェントが受け持つのは、ざっくり 2 つの仕事です。ひとつは Copilot CLI や VS Code 連携で「ここのフォーカス順、おかしくないですか」「この aria-label、不足してませんか」といったアクセシビリティの質問に答えること。もうひとつは、フロントエンドコードの変更があったときに、自動で監査して修正候補を投げ返すことです。

大事な前提を、最初にはっきり書いておきます。これは experimental pilot、つまり社内向けの実験的な試作です。記事執筆時点で、誰でも今すぐ ChatGPT のように呼び出せる一般機能にはなっていません。著者の Eric Bailey さんは将来のオープンソース化に前向きな書き方をしていますが、提供時期も価格も発表されていません。

ここが、これまでと違うところです

ここ、少し面白いところです。

これまで「アクセシビリティ自動チェック」と言えば、axe-core や Lighthouse、WAVE といった既存ツールが主役でした。Pull Request に linter として組み込み、CI で落とす。診断結果のレポートを見て、人間が直す。これが標準的なフローです。

今回の GitHub のエージェントが面白いのは、「検出だけでなく、修正候補のコードまで投げ返してくる」点と、「社内で人間が監査済みの問題を学習コーパスとして使っている」点だと私は感じています。記事では、リーダー役と実装役のサブエージェント構造、テンプレートスキーマで一貫性を担保する設計、線形順序で指示を実行する工夫などが触れられています。

ただし、ここは冷静に見たいです。記事自体も率直に書いていますが、エージェントが自動で扱えるのは WCAG 2.1 A/AA のうち 55 項目中 35 項目、およそ 64% だけです。残り 3 割強は人間が判断する領域として残されています。さらに、ドラッグ&ドロップ、トースト通知、リッチテキストエディタ、ツリービュー、データグリッドといった複雑な UI パターンは、最初から「高リスク」として除外されています。

副業を考えているあなたなら、まず狙うのは “a11y 改善提案の補助” という現実線

副業を考えているあなたなら、ピンと来るところがあるかもしれません。

私が Web 制作・コーディングまわりで副業を組み立てるなら、今回の発表をきっかけに 「a11y 診断と改善提案の補助」 をオプション商品として打ち出すところから入ります。GitHub のエージェント自体が日本でいつ・どう使えるかは分かりませんが、その周辺の “人間がやる” 部分は、今ある axe-core や Lighthouse、WAVE などのツールで十分立ち上げられるからです。

具体的な案件パターンとして、私はこの 3 つを想定しています。

• 納品時オプションとしての a11y 改善提案書: 既存ツールの自動検出結果を整理し、優先度と修正案をまとめた A4 5〜10 枚程度のレポートにする
• 運用フェーズの a11y スポット診断: 公開済みの企業サイト・LP に対して、トップ + 主要 3〜5 ページの a11y チェックと改善提案を行う
• キャンペーン LP の事前 a11y チェック: 公開前のステージング段階で、コントラスト・キーボード操作・スクリーンリーダー読み上げを人間が一通り見る

どれも、自動ツールの出力をそのまま納品するのではなく、優先度判断と読みやすいレポート化が価値の中心になります。「ツールを動かす」のと「クライアントが意思決定できる粒度に整える」のは、別の仕事です。後者のほうが、副業として値段がつきやすい領域だと私は感じています。

個人開発の視点で見ると、ここに小さな勝ち筋があります

個人開発の視点で見ると、面白いポジションが残っています。それは 「GitHub のエージェントが公開されるまでの隙間を、軽量ツールで埋める」 という立ち位置です。

たとえば、こんな構成が考えられます。axe-core API や Lighthouse CI を裏側で動かし、Pull Request の差分に対して「変更箇所近辺で a11y 違反が増えているか」を簡潔に表示する GitHub App。あるいは、特定ページに axe-core を実行して、検出結果を読み上げ確認の手順書とセットで PDF 化する Chrome 拡張。どちらも、ツールチェーンとしては枯れた部品の組み合わせで作れます。

ここで意識したいのは、GitHub のエージェントと正面から競合する設計にしないことです。あちらは社内コーパスで学習したサブエージェント構造を持つ、本格派です。あなたが個人で 1 〜 2 ヶ月かけて作るプロダクトでは、機能の真似はしないほうが安全です。「ローカルで動く、軽量で、自分の案件にすぐ組み込める a11y 補助ツール」というポジションのほうが、現実的だと思います。

あなたなら、どこから手を付けますか。私だったら、まずは axe-core + GitHub Actions の組み合わせで、PR コメント自動投稿の小さなプロトタイプを 1 週間で作ります。プロダクト化の前に、自分の案件で 2〜3 回回してみる。そこで初めて、これが本当に副業の道具になるか、目利きできるようになります。

収益化を本気で考えるなら、私はこの 3 階建てを勧めます

収益化を本気で考えるなら、いきなり SaaS を作りに行くより、3 階建ての設計を勧めます。これは私の見立てです。

• 1 階: スポット診断 — 既存サイト 1 件あたり 5〜30 万円程度の単発案件。値付けの出発点として現実的な相場感の目安です
• 2 階: 月額レビューサブスク — 月額 5,000〜50,000 円で、サイト更新時に都度 a11y 観点でチェック&レポートを返す。スポットからの継続化として相性が良い
• 3 階: 教材・チェックリスト販売 — 「自分でやりたい」担当者向けに、チェック手順書・テンプレートを小口販売する。労働集約から抜けるための布石

大事なのは、3 階を最初に作らないことです。1 階で 3〜5 案件回し、そこで蓄積した「クライアントが本当に困っていた論点」を 2 階のレビュー観点に落とし、さらにそこから再現性のある手順だけを 3 階に切り出す。この順番だと、空想で書いた教材を出してしまう失敗を避けやすいと思います。

金額帯はあくまで参考の出発点で、現場・地域・対象業種で大きく変動します。pilot 段階の GitHub エージェントの話を前面に出して、大型契約をいきなり売り込むような組み立ては、私は勧めません。

始めるなら、最初の 30 日で押さえておきたい 3 つのこと

30 日というのは、副業を「やってみる」ところまで持っていく現実的な目安として、私が普段使っている時間軸です。

最初の 10 日で抑えたいのは WCAG 2.1 A/AA の主要項目 です。GitHub のエージェントですら自動で扱えるのは 64% 程度、と公表されています。逆に言うと、残り 3 割超は人間が読まないと判断できない。ここの土地勘がないと、ツールの出力を意味のあるレポートに翻訳できません。日本語訳の JIS X 8341-3 も併せて見ておくと、企業向けの説明で言葉が通じやすくなります。

次の 10 日は ツールの手触り です。axe DevTools、Lighthouse、WAVE のブラウザ拡張、できれば NVDA や macOS VoiceOver でのキーボード読み上げ確認まで、手元で触ってみてください。ツールごとに検出ロジックが微妙に違うので、3 ツールほど併用すると、見落としに気付きやすくなります。

最後の 10 日は サンプル案件で 1 件まとめる 期間です。知人の個人サイトや、自社サイトのトップを題材にして、A4 5〜10 枚程度の改善提案書を実際に書いてみる。私はこのフェーズで、報告書の “翻訳の難しさ” にいつも引っかかります。技術用語をそのまま並べると、決裁者が読めない。ここに時間を使えるかどうかで、副業として続くかどうかが変わると思います。

初期費用は、ブラウザ拡張ベースで始める分にはほぼゼロです。axe DevTools などの有償プランは、案件が安定してきてからで遅くないと思います。

始める前に、ここだけは見落とさないでほしい注意点

ここは注意したいところです。順番に書いておきます。

制度や規約は変わる可能性があります。最新情報は公式・専門家を確認するように、提案書にも一行入れておくのが安全です。

私は、この発表を “a11y 検証エージェント” の試作公開として面白いと感じています

これは私の見解です。

正直に言うと、ニュース自体は派手なものではありません。新しいモデルが出たわけでも、誰でもすぐ使える機能が公開されたわけでもない。GitHub の社内チームが、社内向けの a11y エージェントを動かしてみて、できたこと・できなかったことを淡々と書いた、いわば中間報告です。それでも私はこの発表に注目しました。理由は 2 つあります。

ひとつは、AI エージェントの議論が「何でもできる汎用エージェント」一辺倒だった流れに、「専門領域に特化した検証エージェント」 という別の選択肢を、有力企業が公の場で出してきたことです。Copilot のような汎用コーディング支援とは別軸で、a11y というニッチに専属で張り付くエージェント。この方向性は、今後ほかの領域 (パフォーマンス、セキュリティ、SEO など) にも波及する可能性があると、私は見ています。

もうひとつは、できなかったことを正直に書いている点です。35/55 の自動化率、高リスクパターンの除外、LLM がアンチパターンを生成しやすいという指摘。こうした弱点を開示してくれているおかげで、私たちは「どこで人間が必要か」を逆算しやすくなります。あなたが副業や個人開発を組み立てるとき、ここはそのまま価値設計のヒントになると思います。

私だったら、この記事を「来るべき変化の方向性」のサンプルとして手元に置いて、まずは既存ツールで小さく副業を立ち上げます。エージェント本体の一般提供を待つよりも、その前段にある「人間が担う a11y 判断」のスキルを今のうちに作っておくほうが、後で効いてくるのではないか。私はそう感じています。

参考にしたもの

記事中の数値 (3,535 PR、解決率 68%、WCAG A/AA の自動化 35/55) と高リスク UI パターンの除外方針、サブエージェント設計は、すべて上記 GitHub Blog の発表内容に依拠しています。本記事は要約 + 副業・個人開発・収益化への翻訳パートを私の見立てとして加えたもので、GitHub 公式の見解ではありません。