自治体のホームページの更新原稿を、画像の代替テキスト・表の作り・リンクの文言・PDFだけの掲載といったアクセシビリティの観点で公開前に校正する

処理の起点を決める

15分ごとの時間主導型トリガーで、受付のフォルダを見ます。 Apps Script の時間主導型トリガーは、分単位の間隔を1・5・10・15・30から選ぶとされています。原稿は1日に十件前後で、届いてから15分以内に指摘が返れば、担当者はその日のうちに直せます。

「新しい原稿」は、点検台帳に無いファイル、または前回の点検より後に更新されたファイルとします。 点検台帳にファイルのIDと点検した日時を残し、ファイルの最終更新日時がそれより新しければ、もう一度点検します。 担当者が直して置き直した原稿も、同じ仕組みで拾えます。

担当者が書いている途中の原稿を拾わないように、置き場所を分けます。 下書きは各課のフォルダで書き、書き終えたら受付のフォルダに移す決まりにします。受付のフォルダに置いた原稿だけが点検の対象です。

入力データを集める

原稿の様式を1つに決めます。 冒頭に担当課・担当者のメールアドレス・公開の希望日の表を置き、その下に本文を書きます。スクリプトは冒頭の表から送り先を読むので、様式を崩すと指摘が届きません。共有ドライブ上ではファイルの持ち主が担当者とは限らないため、送り先は様式の欄で持ちます。

点検の手引は、市の言葉で書きます。 「リンクの文言は、リンク先の内容が分かる言葉にする（例：『申請書（PDF）』）」「表は見出しの行を1行目に置き、セルを結合しない」のように、各課の職員が読んで直せる書き方にします。生成AIの判定にも、指摘の文にも、この手引の言葉を使わせます。

データの取得方法を決める

リンクは、書式の区切りごとに拾います。 段落の文字列だけを取ると、どこからどこまでがリンクの文言かが分かりません。 書式の区切りの位置ごとにリンク先を取り、同じリンク先が続く範囲をリンクの文言とします。

// 段落からリンクの文言とリンク先を取り出す（同じリンク先が続く区間はつなぐ）
function collectLinks(paragraph) {
  const text = paragraph.editAsText();
  const s = text.getText();
  const idx = text.getTextAttributeIndices();
  const links = [];
  for (let i = 0; i < idx.length; i++) {
    const start = idx[i];
    const end = i + 1 < idx.length ? idx[i + 1] : s.length;
    const url = text.getLinkUrl(start);
    if (!url) continue;
    const last = links[links.length - 1];
    if (last && last.url === url && last.end === start) {
      last.text += s.substring(start, end); last.end = end;
    } else {
      links.push({ text: s.substring(start, end), url: url, start: start, end: end });
    }
  }
  return links;
}

同じリンク先の区間をつなぐのは、リンクの途中で太字などの書式が変わると区切りが分かれるためです。 つながないと、「申請書（PDF）」が「申請書（」と「PDF」と「）」の3つのリンクに見え、短い文言の指摘が誤って出ます。

画像は getBlob() で取り出し、PNG か JPEG にして送ります。 Claude API が受け付ける画像は JPEG・PNG・GIF・WebP で、API に直接送る場合は1枚あたり base64 で10MBまでとされています。原稿に貼られた写真が大きいときは、送る前に小さくします。送る画像は原稿の画像だけで、リンク先のファイルの中身は送りません。

PDF へのリンクは、リンク先の拡張子と、共有ドライブ上のファイルの種類で判定します。 リンク先が PDF で、本文にその PDF の内容の概要が書かれていないものを「PDFだけの掲載の疑い」とします。概要が書かれているかの判定は生成AIに任せます（後述）。

AIへ渡す前に整形する

1. 様式の確認 … 冒頭の表に担当者のメールアドレスがあるかを確かめます。無ければ点検せず、受付のフォルダの管理者に知らせます
2. 機械で決まる指摘を先に拾う … 代替テキストの題名と説明がともに空、セルの結合、リンクの文言が「こちら」「ここ」「詳細」だけ、字間の空白（「氏　名」のような文字の間の空白）
3. 画像の大きさをそろえる … 長い辺を一定の画素数に縮め、送る量を抑えます
4. 前後の文脈を切り出す … 画像とリンクのそれぞれについて、直前と直後の段落を添えます
5. 個人の名前が写る写真の扱い … 「イベントの様子」など人物の写った写真は、画像を送らずに代替テキストと前後の段落だけで判定する設定にできるようにします

2番目で拾った指摘は、生成AIの判定を待たずに「要修正」にします。 代替テキストが空の画像を生成AIに送って「空です」と言わせる必要はありません。機械の指摘はいつ動かしても同じ結果になり、担当者に説明しやすくなります。

5番目は、市の写真の扱いの決まりにあわせます。 広報に載せる前提で本人の了解を得た写真でも、外部のサービスに画像を送ってよいかは別の判断です。 情報政策の担当と決めた範囲で、画像を送る・送らないを切り替えます。

AIに処理させる

させるのは、画像・リンク・本文の判断の要る箇所について、市の点検の手引に照らして判定し、直し方の候補を出すことだけです。

2行目の「画像の中の文字」がいちばん効きます。 イベントのチラシを画像で貼り、代替テキストに「チラシ」とだけ書いた原稿は、日時・場所・申込み先が画像の中にしかありません。 生成AIが画像の文字を読み、本文と代替テキストのどちらにも無い情報を挙げれば、担当者は何を本文に書き足せばよいかがすぐ分かります。

代替テキストの文案は、あくまで候補です。 同じ公園の写真でも、イベントの案内なら「会場の〇〇公園の芝生広場」、工事のお知らせなら「工事で閉鎖する遊具の位置」と、伝えたいことによって代替テキストは変わります。 画像の目的を知っているのは原稿の担当者なので、候補は直すための手がかりとして出します。

指示内容を固定する

あなたは市のホームページの原稿を、公開前にアクセシビリティの観点で
点検する立場です。添付の点検の手引に従って判定してください。

【判定する対象】
これから渡すのは、原稿の中の画像またはリンク1つと、その前後の段落です。

【画像の場合】
- 代替テキストが、前後の段落の流れの中で、画像の目的を伝えているか。
- 画像の中に文字（日時、場所、金額、問い合わせ先など）がある場合、
  その内容が本文か代替テキストに書かれているか。書かれていない内容を挙げる。
- 飾りの画像で、代替テキストを空にすべきものか。

【リンクの場合】
- リンクの文言と前後の文から、リンク先の内容が分かるか。
- リンク先が PDF の場合、前後の本文に PDF の内容の概要があるか。

【本文の場合】
- 色だけで情報を区別している表現があるか。

【厳守事項】
- 判定は ok / needs_fix / needs_review のいずれかにしてください。
  迷ったときは needs_review にしてください。
- 根拠として、手引の項目番号を必ず付けてください。
- 画像に写る人物の名前を推し量らないでください。
- 原稿の日付・金額・内容の正しさは判定しないでください。
- 直し方の候補は、手引の言い換えの例にならって短く書いてください。
- 画像が小さい・ぼやけているなどで読み取れない場合は、
  読み取れたふりをせず needs_review にしてください。

この指示は、画像やリンク1つごとに送ります。 原稿全体をまとめて送ると、どの指摘がどの画像のものかの対応がずれます。 1つずつ送れば、出力の位置の情報をスクリプトの側で持てます。

「読み取れたふりをしない」を入れているのは、小さな画像のためです。 Claude のドキュメントは、低品質・回転した画像や200画素未満の非常に小さな画像では、誤った解釈をすることがあるとしています。チラシの縮小画像では文字が読めないことがあり、そのときは人に回します。

出力形式を固定する

Claude API の構造化出力で、次の JSON を受け取ります。 構造化出力は、リクエストの output_config.format に type: "json_schema" とスキーマを指定する形とされています。

{
  "target": "image | link | text",
  "location": "画像3（見出し「会場」の下）",
  "verdict": "ok | needs_fix | needs_review",
  "findings": [
    { "check": "image_text_missing",
      "detail": "画像の中の『申込み締切 11月15日』が本文にない",
      "guideline_ref": "手引 2.3",
      "suggestion": "本文に申込みの締切日を書き足す" }
  ]
}

1つ目の理由は、verdict で人に回すものを分けられることです。 needs_fix は担当者に直接返し、needs_review は点検台帳でウェブの担当の確認待ちにします。スクリプトは verdict を読むだけで、行き先を決められます。

2つ目は、guideline_ref で指摘の説明がそろうことです。 担当者へのメールには、手引の項目の説明文をスクリプトが添えます。同じ種類の指摘には、毎回同じ説明が付きます。

点検台帳の1行は、指摘1件です。 列は、点検日時、ファイル名、担当課、対象、位置、判定（要修正／要確認）、指摘の内容、手引の項目、直し方の候補、指摘の出どころ（機械／AI）、対応の状態です。出どころの列があると、機械の指摘とAIの指摘の当たり外れを分けて数えられます。

システムへ連携する

原稿には書き込みません。 Apps Script には代替テキストを設定する機能（setAltDescription()）もありますが、使いません。AIの候補が原稿に入ると、担当者は自分で画像の目的を考えなくなります。

API のキーは、スクリプトのプロパティに置き、コードに書きません。 スクリプトの編集の権限は、広報課のウェブの担当に絞ります。

人が確認する

1. 要確認の指摘を見る … 点検台帳で「要確認」を絞り込み、原稿の該当箇所を開いて判断します
2. 要修正のうちAIの指摘を見る … 機械の指摘はそのまま返して構いませんが、AIの needs_fix は外れがないかを流し見ます
3. 直った原稿を見る … 置き直された原稿の点検結果で、指摘が消えているかを確かめます
4. CMS に入力した後のページを見る … CMS に入力するときに代替テキストや表の見出しが原稿どおりに入ったかを確かめます

4番目は、この構成の外にある確認です。 原稿で直っていても、CMS に入力するときに代替テキストを写し忘れると、公開されたページには反映されません。 入力の手順に「代替テキストの欄を埋めたか」の確認を入れておきます。

目標は、1件あたり5分です。 要確認の指摘を見るのに2分、AIの要修正を流し見るのに1分、指摘を返し直した原稿の確認に2分という配分です。

例外に対処する

5行目は、機械の指摘を先に返すことで影響を小さくします。 AIの判定が遅れても、代替テキストの空やセルの結合は必ず返ります。 2段に分けた設計が、障害のときにも効きます。

記録を残す

• 点検台帳（指摘1件1行。点検日時、ファイル、位置、判定、出どころ、対応の状態）
• Claude API に送った内容の概要（画像を送ったか、前後の段落の文字数）と返ってきた JSON
• ウェブの担当が覆した判定 … どの指摘を、要修正から取り下げたか、要確認から要修正にしたか
• 課ごとの指摘の件数の推移
• 点検の手引の版と変更の履歴

4つ目の推移は、研修の材料になります。 「こちら」のリンクの指摘が多い課、PDFだけの掲載が多い課が分かれば、その課に向けて短い説明をするほうが、全庁の研修より効きます。

3つ目の覆した記録は、指示と手引を直す材料です。 装飾の画像を「代替テキストが足りない」と出し続けるなら、手引に装飾の画像の例を足します。