はじめに
GitHubが2026年3月12日、アクセシビリティに関するユーザーフィードバックをAIで自動処理する内部ワークフローの詳細を公開しました。本稿では、GitHub Actions・GitHub Copilot・GitHub Modelsを組み合わせた同システムの仕組みと、実際の改善効果について解説します。
参考記事
- タイトル: Continuous AI for accessibility: How GitHub transforms feedback into inclusion
- 著者: Carie Fisher
- 発行元: GitHub Blog
- 発行日: 2026年3月12日
- URL: https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/
要点
- GitHubは、GitHub Actions・GitHub Copilot・GitHub Modelsを組み合わせた7ステップのアクセシビリティフィードバック処理ワークフローを構築した
- Copilotがイシューのメタデータの約80%（40以上のデータポイント）を自動入力し、WCAGマッピング・重大度・担当チームの推奨を行う
- 導入後、90日以内のイシュー解決率が21%から89%に向上し、平均解決日数は118日から45日に短縮された
- 30日以内解決件数は前年比で1,150%増加し、直近の四半期では全イシューが60日以内に解決された
- AIは繰り返し作業を担当し、人間が修正内容の検証とユーザーへのフォローアップに専念できる設計になっている
詳細解説
アクセシビリティフィードバックが抱えていた課題
GitHubでは長年、アクセシビリティに関するフィードバックの行き先が定まっていませんでした。スクリーンリーダー利用者が報告するナビゲーションの不具合、キーボード操作のトラップ、配色コントラストの問題は、いずれも複数のチームにまたがる問題であり、特定のチームが単独で所有することができません。その結果、報告が各チームのバックログに散在し、300日以上未解決のまま放置されるケースも珍しくありませんでした。
アクセシビリティの問題は、製品全体に横断的に影響するため、従来の製品フィードバック管理の仕組みとは相性が悪いと考えられます。この構造的な課題を解消するため、GitHubはまずフィードバックの集約・テンプレート整備・バックログ整理という基盤整備を進めたうえで、AIを活用した自動化を導入しました。
7ステップのフィードバックワークフロー
構築されたワークフローは、イベント駆動型のアーキテクチャ（各処理ステップが次のGitHub Actionを自動的に起動する仕組み）で動作します。
① フィードバックの受付（Intake）
フィードバックの約90%は、GitHubのアクセシビリティ専用ディスカッションボードを経由して集まります。公開フォーラムであるため、他のユーザーが問題を補足したり回避策を提案したりすることも多く、サポートチケットより詳細な情報が得られやすい構造です。どの経路からの報告も、5営業日以内に確認応答が行われます。担当者がカスタムイシューテンプレートを使って追跡イシューを作成すると、GitHub Actionが自動的に起動します。
② Copilotによる分析（Copilot Analysis）
イシューが作成されると、GitHub Models APIを経由してGitHub Copilotが内容を分析します。ポイントは、モデルのファインチューニング（追加学習）ではなく、カスタムインストラクションファイルとプロンプトファイルを使う設計にある点です。AIの動作を変更したい場合は、専門的なML知識がなくてもプルリクエストで対応できます。
Copilotはイシューのメタデータの約80%を自動入力します。具体的には、問題の種類・対象ユーザーセグメント・影響を受けるコンポーネント・WCAGの違反基準候補・深刻度（sev1〜sev4）・推奨担当チームなど40以上のデータポイントが自動で埋められます。残り20%は担当者が手動で入力します。分析結果はイシューへのコメントとして投稿され、続く別のActionがそのコメントを解析してラベル付けとプロジェクトボードへの登録を行います。
③ 提出者レビュー（Submitter Review）
CopilotのチェックリストをもとにCommunityマネージャーやサポート担当者が問題を実際に再現します。チェック項目にはキーボード操作でのページ移動・画像のalt属性確認・スクリーンリーダーでのインタラクティブ要素の読み上げ検証などが含まれ、アクセシビリティの専門知識がなくても手順を追えるよう設計されています。再現できない場合はユーザーに追加情報を求め、情報が揃ったらCopilotの分析を再実行できます。
④ アクセシビリティチームレビュー（Accessibility Team Review）
提出者レビューが完了するとイシューがアクセシビリティチームに移行し、エンジニアや設計担当者がCopilotの分析内容（重大度・WCAGマッピング・カテゴリーラベル）を検証して必要に応じて修正します。不一致があった場合は人間の判断を優先し、その差異をプロンプトファイルの改善に活かします。解決方針（ドキュメント更新・直接修正・別チームへの引き継ぎ）が決まると、提出者経由でユーザーに対応方針が伝えられます。
⑤ 監査との連携（Link Audits）
報告されたイシューの75〜80%は、内部監査ですでに把握済みの問題と重複しています。この場合は新たなイシューを作成せず、既存の監査イシューにラベルを付与して実際の影響度に基づく優先順位付けを行います。複数ユーザーから報告されている問題は、技術的な深刻度とは別に優先度を引き上げる仕組みです。
⑥ クローズドループ（Close Loop）
ユーザーが修正を確認して初めてイシューを閉じる、という方針がこのワークフローの重要な特徴です。修正がリリースされると提出者が対応したユーザーに連絡し、動作確認を依頼します。ディスカッションボード発の報告は同ボードでも公開回答が投稿されます。修正が不十分な場合はアクセシビリティチームレビューに戻ります。
⑦ 継続的改善（Continuous Improvement）
ワークフローはイシューのクローズで終わりません。Copilotの分析に誤りが見つかった場合、専用の報告イシューを開くリンクがすべてのCopilotコメントに含まれており、修正内容がプロンプトファイルへのプルリクエストとして反映されます。また、別のGitHub Actionがアクセシビリティガイドリポジトリを週次でスキャンし、新しいガイダンスをCopilotのカスタムインストラクションに自動反映します。四半期ごとに精度指標を確認し、解決時間・WCAG違反パターン・フィードバック件数のトレンドをレポートにまとめています。
導入後の定量的成果
GitHubによれば、導入前は全フィードバックの約半数が300日以上未解決でした。現在はそのバックログは解消されており、主な改善指標は以下の通りです。
- 90日以内解決率：21% → 89%
- 平均解決日数：118日 → 45日（62%短縮）
- 管理作業時間：70%削減
- 30日以内解決件数：前年比1,150%増（4件 → 50件）
- 重大度sev1イシュー：50%削減
- 直近四半期：全イシューが60日以内に解決
これらの指標はGitHub Actionsが自動生成する週次・四半期レポートで継続的に追跡されています。定量的な改善を可視化する仕組みを最初から組み込んでいる点は、同様のシステムを検討する際に参考になると思います。
AIと人間の役割分担
本ワークフローで注目したいのは、AIが「繰り返し作業を引き受けることで人間が本来の判断に集中できる」という設計思想です。Copilotの分析に誤りがあれば人間が修正し、その差異が次の精度改善に使われます。ファインチューニングではなくカスタムインストラクションを採用したことで、アクセシビリティ基準の変更をMLの専門知識なしにワークフローへ反映できる点も、実運用での維持管理を考えると重要な判断と言えます。
まとめ
GitHubのアクセシビリティワークフローは、AI・自動化・人間のレビューを組み合わせることで、散在していたフィードバックを確実に解決へとつなげる仕組みです。数値面での改善も明確であり、オープンソースリポジトリから企業プロジェクトまで応用できる実践的なモデルとして注目されます。アクセシビリティ対応にAIを取り入れる際の参考事例として今後の展開を注視したいと思います。
