継続的AIによるアクセシビリティ：GitHubがフィードバックをインクルージョンに変える方法

長年にわたり、GitHub におけるアクセシビリティに関するフィードバックには明確な受け入れ先がありませんでした。 一般的な製品フィードバックとは異なり、アクセシビリティの問題は特定のチームに属するものではありません。それらはエコシステム全体に横断的に存在します。例えば、スクリーンリーダーユーザーが報告する破綻したワークフローは、ナビゲーション、認証、設定など複数の領域にまたがる可能性があります。キーボードのみで操作するユーザーは、数十ページにわたって共有されているコンポーネント内のトラップ（罠）に遭遇することがあります。低視力ユーザーは、共有デザイン要素を使用するすべての表面に影響を与える色コントラストの問題を指摘します。これらの問題のいずれも単一のチームが所有していませんが、すべてが実際のユーザーの行動を阻害しています。 これらの報告には、既存のプロセスでは当初想定されていなかった調整が必要です。フィードバックはしばばバックログに散在し、バグは所有者不明のまま放置され、ユーザーからの追跡連絡は無視される傾向がありました。改善策は、ほとんど実現しない神話的な「フェーズ 2」で約束されることが多かったです。 私たちはこの状況を変える必要があると知っていました。しかし、より良い仕組みを構築する前に、まず土台を築く必要がありました。散在する報告の一元化、テンプレートの作成、そして何年にもわたるバックログのトリアージです。その基盤が整って初めて、「AI はどのようにしてこれを容易にできるのか？」という問いを立てることが可能になります。 答えは、GitHub Actions、GitHub Copilot、そして GitHub Models を活用した社内ワークフローでした。これにより、ユーザーや顧客からのあらゆるフィードバックが追跡可能な優先度付きの課題として管理され、対応されるようになります。誰かがアクセシビリティの障壁を報告した場合、そのフィードバックは収集・レビューされ、解決されるまで追跡されます。私たちは AI が人間の判断を代替することを望んではいませんでした。むしろ、反復作業を AI に任せることで、人間がソフトウェアの修正に集中できる環境を作りたかったのです。 これが、混沌とした状態から、すべてのアクセシビリティに関するフィードバックが追跡され、優先順位付けされ、即座に対応されるシステムへと変化したプロセスです。最終的にではなく、継続的にです。 生きたシステムとしてのアクセシビリティ アクセシビリティのための継続的 AI は、インクルージョンをソフトウェア開発の基盤に織り込みます。これは単一の製品や一度きりの監査ではありません。自動化、人工知能（AI: Artificial Intelligence）、そして人間の専門知識を組み合わせた、生きたメソドロジーなのです。 この哲学は、2025 年のグローバル・アクセシビリティ・アウェアネス・デー（GAAD）への誓約に対する私たちの支援と直接結びついています。それは、ユーザーや顧客からのフィードバックが適切なチームへルーティングされ、意味のあるプラットフォーム改善へと翻訳されることを通じて、オープンソース・エコシステム全体におけるアクセシビリティを強化するというものです。 最も重要なブレークスルーは、コードスキャナから来ることはめったにありません。それは、実際の人間に耳を傾けることから生まれます。しかし、大規模な範囲で耳を傾けるのは困難です。そのため、これらの声を増幅させるためにテクノロジーが必要でした。私たちは、静的なチケット管理システムというよりはむしろ動的なエンジンとして機能するフィードバックワークフローを構築しました。GitHub の製品を活用して、ユーザーや顧客からのフィードバックを明確化し、構造化し、追跡することで、実装可能なソリューションへと変換しています。 まず人々のために設計する 解決策に飛び込む前に、このシステムが誰のために機能すべきかを理解するために一歩引いて考えました。 課題提出者：コミュニティマネージャー、サポートエージェント、営業担当者がユーザーや顧客に代わって課題を提出します。彼らは必ずしもアクセシビリティの専門家ではないため、作業の流れの中で彼らを導き、アクセシビリティの概念を教えるシステムが必要です。 アクセシビリティおよびサービスチーム：修正を担当するエンジニアやデザイナーには、構造化された実用的なデータ—再現可能な手順、WCAG（Web Content Accessibility Guidelines）マッピング、深刻度スコア、明確な所有権—が必要です。 プログラムおよびプロダクトマネージャー：リーダーシップ層は、カテゴリ別、トレンド別、時間経過に伴う進捗状況における課題点を可視化し、戦略的にリソースを配分する必要があります。 これらのペルソナ（人物像）を念頭に置き、私たちは 1) フィードバックをパイプラインを通じて流れるデータとして扱うこと、2) 私たちと共に進化できるシステムを構築することを目指しました。 フィードバックの流れ その基盤を確立した上で、イベント駆動型パターンを中心としたアーキテクチャを構築しました。各ステップは GitHub Action をトリガーして次の手順を調整し、フィードバックの発生源がどこであれ一貫した処理を実現します。このシステムは 2024 年半ばから主に手作業で構築されました。現在では Agentic Workflows のようなツールにより、自然言語を使って GitHub Actions を作成できるようになりました—つまり、同様のシステムを従来よりもはるかに短い時間で構築することが可能になっています。 ワークフローは主要なイベントに応じて反応します：Issue の作成は GitHub Models API を介して GitHub Copilot による分析を開始し、ステータスの変更はチーム間の引き継ぎをトリガーし、解決は利用者へのフォローアップを提出者に促します。すべての Action は必要に応じて手動でトリガーしたり再実行したりすることも可能です—自動化が一般的なフローをカバーする一方、人間はいつでも介入できます。 フィードバックは単に収集されるだけでなく、適切なチャネルを通じて継続的に流れ、各段階において可視性、構造化、そして実行可能性を提供します。 *画像をクリックして拡大してください。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?resize=1395%2C244) 1. 受入アクション フィードバックはあらゆる場所から寄せられます——サポートチケット、ソーシャルメディアの投稿、メール、直接の連絡など—but 多くのユーザーが GitHub のアクセシビリティディスカッションボードを選択します。そこでは、共通の経験に基づいて協力し、コミュニティを築くことができます。現在、アクセシビリティに関するフィードバックの 90% がこの単一のチャネルを通じて流れています。投稿は公開されているため、他のユーザーが問題を確認したり、文脈を追加したり、回避策を提案したりできます——そのため、問題にはサポートチケットでは決して得られないほど詳細な情報が付随して届くことが多いのです。出所に関わらず、すべてのフィードバックは 5 営業日以内にAcknowledged（承認）され、対応できないフィードバックについても、役立つリソースへの案内を含む回答が返されます。 フィードバックに内部チームによるアクションが必要な場合、メンバーが手動でカスタムアクセシビリティフィードバック用Issueテンプレートを使用して追跡用のIssueを作成します。Issueテンプレートは、新しいIssueを開く際に情報を収集する方法を標準化する事前定義されたフォームです。このテンプレートでは、初期の文脈——ユーザーが報告した内容、その出所、関与するコンポーネント——を記録するため、受付からトリアージまでの間に情報が失われることはありません。 ここから自動化が始まります。Issueを作成するとGitHub Actionがトリガーされ、GitHub Copilot が連携します。また、別のActionがそのIssueをプロジェクトボードに追加し、現在のステータスの一元化されたビューを提供し、トレンドを浮き彫りにし、新たなニーズの特定を支援します。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?resize=1393%2C580) 2. GitHub Copilot の分析 追跡用イシューが作成されると、GitHub Action ワークフローがプログラムを通じて GitHub Models API を呼び出し、レポートを分析します。モデルのファインチューニングではなく保存されたプロンプトを採用したのは、チームの誰でもプルリクエストを通じて AI の動作を更新できるようにするためです。再トレーニングパイプラインは不要で、専門的な機械学習の知識も必要ありません。 GitHub Copilot は、アクセシビリティの専門家が策定したカスタム指示を使用して設定されています。私たちのプロンプトには 2 つの役割があります。1 つ目はトライアージ分析で、WCAG の違反内容、深刻度、影響を受けるユーザーグループに基づいてイシューを分類します。2 つ目はアクセシビティコーチングで、GitHub Copilot が専門家の役割を果たし、チームがアクセシブルなコードを書き、レビューするのを支援します。 これらの指示ファイルは、私たちのアクセシビリティポリシー、コンポーネントライブラリ、そして WCAG の成功基準をどのように解釈し適用するかを詳細に記した内部ドキュメントを参照しています。基準が進化した場合、チームはプルリクエストを通じて markdown ファイルと指示ファイルを更新します。AI の動作は次のトレーニングサイクルではなく、次の実行時に即座に変更されます。このアプローチの詳細な手順については、アクセシビリティのための GitHub Copilot カスタム指示の最適化に関するガイドをご覧ください。 自動化は2つのステップで行われます。まず、Issue が作成された際に Action が発火し、GitHub Copilot にレポートの分析をトリガーします。GitHub Copilot は、Issue のタイプ、ユーザーセグメント、元のソース、影響を受けるコンポーネント、およびユーザー体験を理解するための十分な文脈など、40 以上のデータポイントを含む Issue メタデータの約 80% を自動的に記入します。残りの 20% は、チームメンバーによる手動入力が必要です。その後、GitHub Copilot は以下の内容を含むコメントを Issue に投稿します。 問題とユーザーへの影響の要約 潜在的な違反に対する WCAG（Web Content Accessibility Guidelines）の成功基準の提案 深刻度レベル（sev1 から sev4 まで。sev1 が最優先事項） 影響を受けるユーザーグループ（スクリーンリーダー利用者、キーボード操作利用者、低視力利用者など） 推奨されるチームへの割り当て（デザイン、エンジニアリング、またはその両方） 提出者が Issue を検証できるようにするための、ハードルの低いアクセシビリティテストのチェックリスト 次に、そのコメントに対して第 2 の Action が発火し、回答を解析して、GitHub Copilot が割り当てた深刻度に基づいてラベルを付与し、プロジェクトボード上の Issue のステータスを更新し、レビューのために提出者に割り当てます。 GitHub Copilot の分析が不正確に見える場合、誰でも問題のある箇所とその修正内容を記述した Issue を作成してフラグを立てることができます。これは継続的な改善プロセスに直接フィードバックされます。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?resize=1392%2C405) 3. 提出者のレビュー GitHub Copilot の推奨事項を実行する前に、2 つの層のレビューが行われます。まず最初の段階は、問題を投稿した本人によるものです。 投稿者は、ユーザーが報告した問題を再現しようと試みます。GitHub Copilot がコメントで提供するチェックリストは、コミュニティマネージャー、サポートエージェント、営業担当者を専門レベルのテスト手順へと導きます。アクセシビリティに関する専門知識は不要です。各項目には平易な言葉による説明、ステップバイステップの手順、およびツールやドキュメントへのリンクが含まれています。 例として挙げられる質問は以下の通りです: キーボードのみでページを操作できますか？「Tab」キーを押してインタラクティブな要素間を移動してください。すべてのボタン、リンク、フォームフィールドに到達できますか？常にフォーカスの位置を確認できますか？ 画像には説明的な代替テキスト（alt text）がありますか？画像を右クリックして「Inspect（検証）」を選択し、マークアップを表示します。alt 属性は画像の目的を説明していますか、それとも一般的なファイル名ですか？ インタラクティブな要素は明確にラベル付けされていますか？スクリーンリーダーを使用して、ボタンまたはリンクへ移動します。その目的が明確に読み上げられますか？あるいは、ブラウザの開発者ツールにあるアクセシビリティツリー（accessibility tree）を確認し、要素が支援技術に対してどのように公開されているかを検査することもできます。 問題の再現が可能であれば、提出者はその課題をレビュー済みとしてマークし、次の GitHub Action がトリガーされます。再現できない場合は、ユーザーに連絡して詳細情報を求めます。新しい情報が届くと、提出者は手動で Actions タブからアクションを実行するか、関連するラベルを一時的に削除して再追加することで自動的に起動させることで、GitHub Copilot の分析を再度実行できます。AI が草案を作成しますが、検証は人間が行います。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?resize=1394%2C196) 4. アクセシビリティチームによるレビュー 提出者が課題をレビュー済みとしてマークすると、GitHub Action がワークフロープロジェクトボード上のそのステータスを更新し、別のアクセシビリティファーストレスポンダーボードに追加します。これにより、エンジニア、デザイナー、チャンピオン、テストベンダー、マネージャーで構成されるアクセシビリティチームに対して、GitHub Copilot の分析がレビューの準備ができていることが通知されます。 チームは GitHub Copilot の分析を検証し、深刻度のレベル、WCAG（Web Content Accessibility Guidelines）のマッピング、およびカテゴリラベルを確認して、AI が誤った部分を修正します。不一致がある場合は、人間の判断を正解とみなします。これらの修正内容は記録され、プロンプトファイルの改善に活用されて、将来の精度が向上します。 検証が完了すると、チームは解決策の方針を決定します： ドキュメントまたは設定の更新：ユーザーに対して直接解決策を提供する。 アクセシビリティチームによるコード修正：プルリクエストを直接作成する。 サービスチームの割り当て：該当するサービスチームに課題を割り当て、解決まで追跡します。 進捗経路が確定すると、チームは課題を「トリアージ済み」としてマークします。その後、アクションによって提出者に再割り当てされ、提出者がユーザーへ計画を伝達し、何が行われ、何を期待すべきかを知らせます。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?resize=1390%2C195) 5. 監査へのリンク レビュープロセスの一環として、チームはユーザーおよび顧客からのフィードバックを公式なアクセシビリティ監査システムに紐付けます。 約75〜80%のケースでは、報告された課題は内部監査ですでに把握している事象に対応しています。重複を作成するのではなく、既存の内部監査課題を見つけ、「顧客報告」ラベルを追加します。これにより、実際の影響に基づいて優先順位を決定できます。例えば、技術的には Sev1 よりも Sev2 の方が重要度が低いと見なされる場合でも、複数のユーザーから報告があれば、その優先度を上げます。 フィードバックによって新たな事象が明らかになった場合は、新しい監査課題を作成し、追跡用課題にリンクします。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?resize=1392%2C183) 6. 情報のループ完了 これは信頼構築において最も重要なステップです。アクセシビリティの障壁を報告するために時間を割いてくれたユーザーには、そのフィードバックが具体的な行動につながったことを知る権利があります。 解決策の道筋が決まると、提出者は元のユーザーに連絡し、計画の内容（何が修正され、何を期待すべきか）を伝えます。修正がリリースされると、提出者は再度フォローアップを行い、ユーザーにテストを依頼します。ほとんどの問題はコミュニティディスカッションボードから発生するため、確認メッセージはそこで全員が見られるように投稿されます。 ユーザーが修正が機能していると確認すれば、追跡用イシューはクローズされます。しかし、修正が問題を完全に解決していない場合は、提出者がさらに詳細情報を収集し、プロセスはアクセシビリティチームによるレビューの段階に戻ります。ユーザーが自分にとって修正が機能すると確認するまで、イシューをクローズすることはありません。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?resize=1389%2C172) 7. 継続的な改善 イシューがクローズされた時点でワークフローが終わるわけではありません。それは自己フィードバックする仕組みとなっています。 提出者やアクセシビリティチームのメンバーが、GitHub Copilot の出力に不正確な点を見つけた場合、結果の見直しを要求する新しいイシューを開きます。すべての GitHub Copilot 分析コメントには、このイシューを作成するためのリンクが下部に含まれており、フィードバックループはワークフローそのものに組み込まれています。チームはその不正確性をレビューし、修正内容は前述のカスタムインストラクションおよびプロンプトファイルへのプルリクエストとして反映されます。 また、新しいアクセシビリティガイダンスの統合も自動化されています。専用の GitHub Action が内部のアクセシビリティガイドリポジトリを毎週スキャンし、変更点を自動的に GitHub Copilot のカスタムインストラクションに取り込みます。 目標は完璧さではなく、継続的な改善です。四半期ごとに精度指標を見直し、指示を洗練させています。これらの見直しは、解決までの時間、WCAG（Web Content Accessibility Guidelines）の失敗パターン、およびフィードバック量の傾向を追跡する四半期報告書と年度報告書に反映され、リーダーシップに対して進捗と依然として残る課題の両方に対する可視性を提供します。このシステムは時間の経過とともに賢くなり、その成果を示すデータも既に揃っています。 ![image](https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?resize=1393%2C199) 数値で見るインパクト 1 年前、アクセシビリティに関するフィードバックのほぼ半分が 300 日以上未解決のまま放置されていました。現在では、その backlog（滞留分）は単に縮小しただけではなく、完全に解消されています。そして改善はこれだけで終わるものではありません。 89% の課題が 90 日以内にクローズされるようになりました（前年比 21% から上昇） 平均解決時間が 62% 短縮されました（118 日 → 45 日） 手動の管理業務に要する時間が 70% 削減されました 30 日以内に解決された課題が 1,150% 増加しました（前年比 4 件 → 50 件） 重大度レベル 1 のクリティカルな課題が 50% 減少しました 直近の四半期では、全課題が 60 日以内にクローズされました これらの進捗は、GitHub Actions（GitHub Actions）によって生成された自動化された週次および四半期レポートを通じて追跡されており、最も頻繁に失敗する WCAG の基準や、解決時間の推移傾向を明確に示しています。 数値の向こう側で James という名前のユーザーから、GitHub Copilot CLI（GitHub Copilot コマンドラインインターフェース）がアクセシビリティに対応していないとのメールが届きました。装飾的な書式設定がスクリーンリーダーにとってノイズとなり、対話型要素を操作することが不可能でした。 チームメンバーが追跡用イシューを作成しました。数分後、GitHub Copilot がそのレポートを分析し、ジェームズの説明を特定の技術概念にマッピングし、内部ドキュメントへのリンクを提供するとともに、提出者がジェームズと同じように製品を体験できる再現手順を示しました。 この文脈から、チームメンバーはエンジニアリングチームが今年早些にすでにアクセシビリティ対応の CLI 更新（CLI: コマンドラインインターフェース）をリリースしていたことに気づきました。ジェームズは単にその事実を知りませんでした。 彼らは即座に返信しました。その返答とは？「–screen-reader モード（スクリーンリーダーモード）に言及していただきありがとうございます。これは非常に役立つと確信しています。」 AI ワークフローが問題を正しく特定したおかげ、私たちは数時間で不満を解決へと転換できました。 しかし、最もやりがいを感じる結果は速度そのものではなく、ユーザーからのフィードバックです。単に私たちが対応したというだけでなく、修正が実際に彼らの役に立ったという点です： 「高コントラストテーマ（high contrast theme: 高コントラストテーマ）における貢献グラフの更新をチームに心から感謝します。グリッドエッジ周囲へのボーダー追加は小さな変更ですが、意味のある改善です。続けてください！」 「GitHub を活用したワークフローのために複数のラベルを作成したい場合を考えましょう：バグ、機能強化、依存関係の更新など…。しかし、もしあなたが視覚障害者ならどうでしょうか？以前はランダムに与えられた 16 進数コード（hex codes: 16 進数コード）しかありませんでした… しかし今は修正され、これらの色には意味のある英語名が付けられました。よくやった、GitHub！」 「これはあまりプロフェッショナルではないかもしれませんが、私は実際に叫んでしまいました！この修正のおかげで一日が明るくなりました… これまでは妻に GitHub のイシューを管理してもらっていましたが、今では自分でナビゲートできるようになりました。これにより少し自立できるようになったことは非常に意味があり、改めて感謝申し上げます。」 その自立こそが目的です。すべてのワークフロー、すべての自動化、すべてのレビューは、このような瞬間が例外ではなく当然の期待となるために存在しています。 より大きな視点 こうした物語は、なぜ基盤が重要なのかを思い出させてくれます。デザイン注釈、コードスキャナ、アクセシビティの推進者、障害を持つ人々とのテスト—これらは AI によって置き換えられるものではありません。むしろ、AI を活用したワークフローを効果的なものにする要素です。その人的な基盤がなければ、AI は単に要点を見失うためのより速い手段に過ぎません。 私たちはまだ学びの最中にあり、システムも進化し続けています。しかし、フィードバックのすべてから何かを学び、その知識は現在、私たちのチームやユーザー、そして構築するツールへと継続的に還元されています。 リポジトリを維持している方なら—大規模なエンタープライズプロジェクトでも週末に開発するオープンソースライブラリーでも—今日からこのようなシステムを構築できます。小さく始めてください。アクセシビティ用のイシューテンプレートを作成し、チームのアクセシビリティ基準を記した .github/copilot-instructions.md ファイルを追加してください。AI にトリアージとフォーマット処理を任せることで、チームは本当に重要なこと—より包括的なコードを書くことに集中できます。 GitHub を利用中にアクセシビリティの障壁に直面した場合は、ぜひフィードバックをお寄せください。その意見は単なるバックログとして埋もれることはありません。私たちは耳を傾けており、今やそれを実現するためのシステムを整えています。 「Continuous AI for accessibility: How GitHub transforms feedback into inclusion」という記事は、The GitHub Blog で最初に公開されました。

継続的AIによるアクセシビリティ：GitHubがフィードバックをインクルージョンに変える方法

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト