社外に出す資料や採用ページの原稿を、読み上げソフトでも読める形にしたい。けれど、見出しの付け方や画像の代替テキストを一つずつ確かめる余裕はない。そうした場面で、Google Docs やスライドの中で問題を指摘し、その場で直してくれるアドオンがあれば便利です。
GitHub の googleworkspace の組織に、そのためのアドオン「Accessibility Checker」（リポジトリ名 ws-a11y-checker）が公開されています。Apps Script で動き、Google Workspace の管理コンソールから社内の全員や特定の組織部門へ配る手順も用意されています。
ただし、配るのは管理者です。このアドオンを社内向けに配布すると、利用者の Gmail を含む14の権限を求める状態で全員に届きます。この記事では、2026年10月29日にリポジトリ（2026年8月27日のコミット d11c325）を取得して読んだ内容をもとに、配る前に確かめたい点を整理します。
何ができるアドオンか
README によると、対象は Google ドキュメント、スライド、スプレッドシート、フォーム、Gmail（作成中の下書きと、開いたメール）です。WCAG 2.1 のレベル AA にそろえる観点で、次のような項目を確かめます。
- 文字と背景のコントラスト（通常の文字は 4.5:1 以上、18pt 以上の大きな文字は 3:1 以上）
- 見出しの階層の飛び、見た目だけを見出しのようにした段落
- 空の段落を重ねた余白、見出しの行が区別されていない表
- 「click here」「learn more」のような、行き先が分からないリンクの文字（README の例。URLをそのまま貼った文字も対象）
- 画像の代替テキストの不足
- 両端揃え、1.15倍未満の行間、「Section」「Details」のような中身の分からない見出し
- スライドの読み上げの順番（並べ替えの画面がある）
コントラスト、見出し、表、両端揃え、行間などは、ボタン1つで直す機能があります。リンクの文字、代替テキスト、中身の分からない見出しは、利用者が直す扱いです。表示言語として、README は英語・スペイン語・フランス語・ドイツ語・日本語を挙げています。
ライセンスは Apache 2.0 です。Google の製品としての提供や保守を約束する記述は、README と配布の手順書（DEPLOYMENT.md）には見当たりませんでした。2026年10月29日の時点で、Google Workspace Updates ブログにこのアドオンの告知はなく、Google Workspace Marketplace にも公開の掲載はありません。Marketplace で「Accessibility Checker」と検索すると「Accessibility Checker for Docs」などが出てきますが、提供元は Lovely API などの別の会社で、このリポジトリのアドオンとは別物です。社内に配るのは、自社の Google Cloud プロジェクトと Apps Script のプロジェクトに組み込んだ、自社が管理するアドオンになります。
配布の流れと、管理者が持つもの
手順書が示す配布の流れは、次のとおりです。
- リポジトリを取得し、ビルドして、自社の Apps Script のプロジェクトに送る
- 自社の Google Cloud のプロジェクトを作り、Apps Script のプロジェクトと結び付ける
- OAuth の同意画面を「内部」（自社のドメインの利用者だけ）で作り、14のスコープを登録する
- Google Workspace Marketplace SDK で、公開範囲を「非公開」（自社のドメインに限る）にして公開する
- 管理コンソールから、全員または特定の組織部門・グループにインストールする
更新するときは、Apps Script の同じデプロイの版を上げれば、管理コンソールで入れ直さなくても Marketplace の掲載が更新される、と手順書は説明しています。言い換えると、Apps Script のプロジェクトに書き込める人は、全員に配られているアドオンの中身を変えられます。プロジェクトの編集者を誰にするかは、配る前に決めておく必要があります。
14のスコープを読む
appsscript.json に書かれたスコープは14個です。図のように3つに分けると、性格の違いが見えます。
ドキュメント・スライド・スプレッドシート・フォーム（4つ） は、いずれも名前に currentonly が付く種類です。Apps Script API の資料では、forms.currentonly は「このアプリがインストールされたフォームの表示と管理」と説明されています。ドキュメント・スライド・スプレッドシートの3つも同じ currentonly の名前で、利用者のファイル全体を対象にする documents や drive（同じ資料では「すべての Google ドキュメントの表示・編集・作成・削除」「すべての Google ドライブのファイルの表示・編集・作成・削除」）とは別のスコープです。
Gmail（8つ） には、アドオンの実行中や操作中に限る種類（gmail.addons.current.*）に加えて、範囲の広いものが含まれます。Gmail API の資料（ディスカバリ文書）の説明は次のとおりです。
https://mail.google.com/：Gmail のすべてのメールの読み取り・作成・送信・完全な削除gmail.modify：Gmail のアカウントのメールの読み取り・作成・送信gmail.readonly：メールと設定の表示gmail.compose：下書きの管理とメールの送信
README は、マニフェストを「最小権限」の構成と説明しています。ドキュメント側はそのとおりですが、Gmail については、アドオンを開いたときだけでなく、メールボックス全体に及ぶ権限まで求める構成です。コードを読むと、下書きの一覧の取得、下書きの書き換え、Gmail API でのメール本文と添付画像の取得を行っており、これらに使われていると考えられます。ただし、どのスコープを外すと動かなくなるかは、編集部では試していません。
Apps Script（2つ） は script.container.ui と script.external_request です。後者は、インターネット上の他のホストと通信するサービス（URL Fetch、UrlFetchApp）を使うのに必要なスコープです（Apps Script のリファレンスの UrlFetchApp のページによる）。
外部への通信は、コードではどうなっているか
README と手順書は、「機関の Apps Script と Google Cloud のプロジェクトの中で動き、外部の第三者によるデータ処理はない」と説明しています。コミット d11c325 のバックエンドのコードで外部への通信（UrlFetchApp.fetch）を探すと、見つかったのは2か所で、どちらも gmail.googleapis.com（Gmail API）への要求でした。メールに埋め込まれた画像を取り出すためのものです。
一方、リポジトリには cloud_function というフォルダがあり、画像を Vertex AI の Gemini（gemini-1.5-flash-002、us-central1）に送って代替テキストを作る Cloud Functions のコードと、それを配備するスクリプトが入っています。このスクリプトは --allow-unauthenticated（認証なしで呼べる）で配備し、応答には Access-Control-Allow-Origin: * を付ける設定です。同じコミットのバックエンドと画面のコードからは、この関数を呼ぶ箇所は見つかりませんでした。代替テキストの候補は、コードの中の規則（決まった前置きの削除や、URL から名前を作る処理）で作られています。
ここから言えるのは、次の2点です。
- 手順書のとおりアドオンだけを配る場合、コードで確認できた送信先は Gmail API だけだった
cloud_functionを配備すると、メールや文書の画像を Vertex AI に送る経路が加わる。配備スクリプトのままでは、URL を知っていれば誰でも呼べる状態になる
script.external_request が付いている以上、今後の更新で送信先が増えることはあり得ます。送信先は、マニフェストの urlFetchWhitelist（スクリプトの作者が宣言する URL の許可リスト）で固定できます。Apps Script のドキュメントは、この項目を「テスト用のデプロイでは任意、バージョンを付けたデプロイでは必須」としていますが、コミット d11c325 の appsscript.json には書かれていません。手順書のとおりにデプロイしたときにどう扱われるかは確かめていないため、配る前に、コードが呼ぶ Gmail API の URL を書き足して試すのが確実です。
なお、管理者が組織全体に強制する許可リスト（管理コンソールの「URLからのインポートと取得」）は別の設定です。こちらはGASが社外のどこへ通信しているかで扱いました。
Gmailの自動修正で気を付けること
Gmail の「まとめて直す」処理は、修正した本文で下書きを書き換えます。コードでは、対象の下書きの ID が取れない場合、GmailApp.getDrafts() の最初の下書きを対象にする実装になっていました（resolveDraftContent と rpcApplyAllGmailFixes）。下書きをたくさん持つ利用者で、意図しない下書きが書き換わる可能性がないかは、配る前に試験用のアカウントで確かめておきたい点です。編集部は Workspace の環境での動作は確かめていません。
また、テスト用の文書を作る機能は、開いている文書の末尾に検証用の内容を追加し、Gmail では件名「Accessibility Audit Demo Draft (WCAG Test Suite)」の下書きを作ります。本番の資料で試さないよう、利用者への案内に入れておくと安全です。
ログの扱いも確認します。マニフェストは例外のログを Cloud Logging に送る設定（exceptionLogging: STACKDRIVER）で、コードにはメールの ID や画像の情報を出力するデバッグ用のログが多く残っています。ログを見られる人の範囲は、Google Cloud のプロジェクトの権限で決まります。
配る前に決めておくこと
ここまでの内容から、編集部として次の順番を提案します。
- 配る範囲を絞る: 全員ではなく、資料を外に出す部署の組織部門やグループから始める。手順書も、組織部門やグループを指定する方法を示している
- Gmail の機能が要るかを決める: 文書だけで足りるなら、Gmail のスコープとマニフェストの
gmailの設定を外した版を自社で作る選択肢がある。外した場合の動作は自社で確かめる - 送信先を固定する: マニフェストに
urlFetchWhitelistを加え、cloud_functionを使わないなら配備しない。使うなら、認証を付けて配備する - 更新の担当を決める: Apps Script のプロジェクトの編集者と、上流のリポジトリの変更を取り込むときの確認者を決める
- 試験用のアカウントで確かめる: 下書きが複数ある状態での Gmail の自動修正、ボタン1つの修正で文書の内容が変わらないこと
アドオンや連携アプリの棚卸しは、Google Workspace セキュリティ設定チェックリストの項目とあわせて見直すと、許可の基準をそろえやすくなります。
確認した範囲
2026年10月29日に、GitHub の
googleworkspace/ws-a11y-checker（コミットd11c325、2026年8月27日）を取得し、README・DEPLOYMENT.md・appsscript.json・バックエンドとCloud Functionsのコードを読みました（資料調査）。スコープの説明は、Gmail API と Apps Script API のディスカバリ文書と、Google の OAuth スコープの一覧で確認しました。同じ日に、Apps Script のドキュメント（UrlFetchApp、マニフェスト、URL の許可リスト）、管理者ヘルプの Marketplace アプリのインストールの手順、Google Workspace Updates ブログ、Marketplace の検索結果も確認しました。リポジトリのテストやビルドは実行しておらず、Google Workspace の環境へのインストールと動作も確かめていません。
社内に配るアドオンの権限の見直しや、Google Workspace の管理の設計は、IT・Google Workspace 無料相談からお問い合わせください。
