はじめに
「WCAG 2.2 AA 準拠のアクセシビリティを確保してください」。私が GPT-6 Luna に渡した条件は、この一文だけでした。対象は、connpass のイベント活動記録を表示する Web サイトです。
2026 年 9 月 28 日（JST）に、その実装をブラウザーで確認しました。ここでは実際に残した監査ログの範囲を共有し、その一度の観察から私が考えたことを記します。
これは GPT-6 Luna についての一度の個人的な観察です。モデルの一般的な能力や内部で何を理解していたかを示すものではありません。WCAG 2.2 AA は実装・確認の目標であり、このログは第三者による適合性評価でも、すべての達成基準への適合宣言でもありません。🧭
「準拠」という目標と、今回確認した範囲
WCAG（Web Content Accessibility Guidelines）は、Web コンテンツのアクセシビリティに関するガイドラインです。WCAG 2.2 の AA 適合を主張するには、レベル A と AA の達成基準に加えて、適合要件を満たす必要があります。今回の確認は、対象を絞った自動監査と手動チェックであり、そのような適合性評価ではありません。
— W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — Conformance Requirements
今回の監査対象は、初回同期前と、テストイベントをブラウザーのメモリー内だけに読み込んだ状態です。connpass の実データを使った確認ではありません。記録したチェックを、状態ごとにまとめます。
| 確認対象 | 実際に確認したこと |
|---|---|
| 初回同期前 | API キー未設定時の表示を確認しました。同期済みでイベントが 0 件の状態とは区別して扱われていました。 |
| 構造・名前 | ブラウザーのアクセシビリティツリーで header / main / contentinfo、見出しと H1・H2・H3 の階層を確認し、問題は見つかりませんでした。フィルターボタンの名前と aria-pressed、名前付きフィルターグループ、検索・並べ替えの可視ラベルも確認しました。 |
| フォーカス | Tab を 1 回押し、スキップリンクが最初にフォーカスされることを確認しました。:focus-visible のスタイルも実装にありました。リンクや操作項目を通した Tab 順序全体は未確認です。 |
| 状態通知 | ステータス・エラー・空状態の領域に role="status" と aria-live="polite" が実装されていることを確認しました。 |
| 色・コントラスト | 実装色から相対輝度で計算した値は、本文 14.73:1、補助テキスト 7.25:1、入力プレースホルダー 6.41:1、主催者ラベル 12.23:1、登壇者ラベル 10.07:1、リンク 10.57:1、選択中ボタンの文字 16.02:1 でした。記録した文字色は、通常テキストの AA 基準 4.5:1 を満たしました（WCAG 2.2 達成基準 1.4.3）。 |
| 幅 320 CSS px | 文書幅は 320 px で横スクロールはなく、フィルターボタン・検索欄・セレクトは高さ 44 px で表示されました。この幅で確認した範囲に限ります。 |
| テストイベント | 年と活動ラベル、活動フィルター、検索、昇順・降順の並べ替えを確認しました。HTML 風の説明文がテキストとして安全に表示されることも確認しました。テストデータは合成データで、ブラウザーのメモリー内だけにあり、リポジトリや公開ページには含まれません。 |
これは、WCAG の全達成基準を網羅したチェックリストではありません。たとえば、コントラスト値も記録した色の組み合わせについての結果であり、あらゆる背景や状態を監査したという意味ではありません。
実装ファイル上で確認した箇所も記録しておきます。
-
public/index.html: スキップリンク、ランドマーク、見出し、フィルター状態、検索・並べ替えラベル、ライブステータス。 -
public/styles.css: 44 px のコントロール、フォーカス表示、レスポンシブレイアウト、動きを減らす設定。 -
public/app.js: イベント状態の通知、活動ラベル、外部リンクの新しいタブに関する通知。
ファイルの実装確認は、それらすべての利用環境での動作を保証するものではありません。
自動監査で見えたこと
Chrome DevTools の Lighthouse Snapshot 監査を、ローカルページのデスクトップと幅 320 px のモバイルで実行しました。この監査ログでは、両方の状態で Accessibility、Best Practices、SEO、Agentic Browsing がすべて 100 点でした。各 Snapshot は 35 項目を監査し、失敗は 0 件でした。
この数値は、今回のローカルページと監査時点の状態に限った結果です。Lighthouse の 100 点や失敗 0 件は、WCAG 2.2 AA への適合を証明しません。Lighthouse はページ状態を監査する手段の一つであり、Playwright の公式ガイドも、自動テストで検出できるのは一部の問題で、多くは手動評価も必要だと説明しています。
また、実装ファイルを確認した Impeccable の検出では、アクセシビリティ違反は報告されませんでした。一方、DESIGN.md の文字サイズスケールと CSS の値が一致しないという別件の助言がありました。これはアクセシビリティ違反の指摘とは分けて扱っています。
手動で確かめたこと
自動監査とは別に、表の項目をブラウザーで表示・操作して確かめ、実装色から相対輝度も計算しました。確認は対象の画面状態と操作に限られ、支援技術を使った評価や全操作のキーボード検証ではありません。
未確認の範囲と次の確認
未確認の項目
- NVDA / JAWS / VoiceOver を使った実機確認、すべてのリンクや操作を通る Tab 順序、フォーカス復帰、スクリーンリーダーとの組み合わせ。
- 文字サイズ 200% での表示、OS の「視差効果を減らす」設定を有効にした状態、Windows の強制カラー表示。
- 本番環境での connpass API の実データとホスティング環境。
次の確認
ローカルでページを配信し、デスクトップと幅 320 CSS px のそれぞれで Lighthouse Snapshot を再実行します。実データでの確認には、README の手順で準備し、GitHub Actions の CONNPASS_API_KEY シークレットを設定して、日次更新ワークフローを実行する必要があります。API キーとホスティングを設定した後の最終確認は、まだ保留中です。実データを使ったら、監査日、ビューポート、UI 状態、失敗件数をログに追記します。スクリーンリーダー、キーボード操作、拡大表示、OS の表示設定も、それぞれ未確認の範囲を実際に確かめる必要があります。
W3C は、評価ツールだけに頼らず、利用者の実体験に目を向ける必要があると説明しています。今回のように自動監査と限定的な手動確認を組み合わせても、未確認の環境や操作は残ります。
— W3C WAI, Selecting Web Accessibility Evaluation Tools
GPT-6 の公式プロンプトガイドと、今回の依頼
ここまでの確認結果を踏まえ、今回の依頼を OpenAI の公式ガイドと照らして考えます。ここで参照する公式資料の範囲では、GPT-6 Luna だけを対象にした独立の詳細なプロンプトガイドは見つかりませんでした。2026 年 9 月 28 日時点で確認したのは GPT-6 ファミリー向けのガイドで、GPT-6 Astra、Sol、Luna が同じファミリーとして扱われています。一方で、プロンプトのベストプラクティスは、Astra で観察された挙動をもとにした出発点であり、選んだモデルと用途で評価するよう明記されています。
“Use the following prompts as a starting point across the GPT-6 model family. They address behavior observed with GPT-6 Astra; evaluate them with your chosen model and workload.”
このガイドは、作業を始める前に完了条件を明確にする例を挙げています。また、最初の回答を超えて調べてほしい場合に、何を調べ、どこで止めるかを伝える例も示しています。より一般的な OpenAI の Prompting ガイドは、全体のトーンや役割を system message に、タスク固有の詳細や例を user message に置くよう案内しています。また、few-shot の例は簡潔な YAML 形式または箇条書きで整理し、プロンプトを公開するたびにテストと評価を実行するよう勧めています。
さらに、GPT-6 Astra を扱う別の公式記事は、より能力の高いモデルでは手取り足取りの指示が少なくて済む場合があると述べています。また、スキルに長い行程表やレシピのような手順を詰め込むと、かえって妨げになることがあるとも説明しています。同記事は、作業を続けてほしい場合には完了条件を定め、さらに探索してほしい場合には対象と停止点を示すよう勧めています。ただし、これは GPT-6 Astra を対象とした説明であり、スキルや作業指示の文脈も含みます。あらゆる依頼で手順を省くべきだという一般則ではありません。
公式資料の助言を「結果や完了条件、必要な制約を明確にし、手順は目的に応じて指定する」とまとめるのは、私の解釈です。OpenAI がこの表現をそのまま使っているわけでも、手順を指定しないよう一律に勧めているわけでもありません。
監査結果だけから依頼文の効果は判断できませんが、今回の依頼を公式ガイドと照らして整理します。依頼ログに残っているのは、「WCAG 2.2 AA 準拠のアクセシビリティを確保してください」という条件だけです。この一文が示したのは達成したい目標であり、確認範囲や完了判定、使うツール、確認の順番、具体的な検査項目は指定していません。今回の記録には、この依頼のもとで使われた検証手段と、複数の確認項目が記されています。公式資料は、この一文が今回のツール選択を引き起こしたことや、GPT-6 Luna が一般に同じ方法を取ることを示してはいません。ここでの比較は、今回の作業記録と、Astra の観察をもとにしたファミリー向けガイドを重ねて見た私の解釈であり、Luna 固有の動作原理についての結論ではありません。
この一度の観察から考えたこと
この一度の作業で私が観察したのは、GPT-6 Luna が画面状態を限定し、ブラウザーのアクセシビリティツリー、操作確認、色のコントラスト計算、Lighthouse Snapshot などを組み合わせて検証していたことです。初回同期前の表示とテストイベントの状態を分けた点も、ひとつの「空画面」として済ませず、状態ごとに確かめる進め方として有用でした。
ここで私が「確認を重ねた」と書くのは、初回同期前とテストイベントの状態を分け、操作を確かめ、デスクトップと幅 320 CSS px で Snapshot 監査をしたログの範囲を指します。ログには、特定の指摘を受けて修正し、同じ項目を再検査した順序までは記録されていません。
ただし、このログだけでは、モデルがどの順番で確認したのか、未確認の課題をどう判断したのか、あるいは別の課題でも同じ進め方をするのかまでは分かりません。モデルの学習方法や能力全般についての結論にも広げられません。あくまで一度の作業記録から、広い品質目標を複数の観察可能な確認に分け、状態や操作を変えてそれぞれ確かめる進め方が実務上役立つと感じた、という範囲の話です。
アクセシビリティは、単発の監査結果だけで終わるものではありません。自動監査を確認の足場にしながら、未確認の操作や環境を一つずつ埋めていく。今回の結果を「準拠の証明」と取り違えず、次の検証につなげたいと思います。♿