社内システムの改修に合わせて、操作マニュアルの画面のキャプチャと手順の文を新しい画面と照らし、ボタン名・項目名・手順の食い違いを拾う

処理の起点を決める

改修票のフォームが送信されたときに動かします。 フォームの回答が入るスプレッドシートに、インストール型のフォーム送信のトリガーを付けます。フォーム送信のトリガーには、フォームそのものに付けるものとスプレッドシートに付けるものの2種類があり、ここではスプレッドシートの側を使います。 回答の行に処理の状態を書き戻せるからです。

送信された時点では、まだ新しいキャプチャが撮られていないことがあります。 そこで、フォームに「キャプチャを置いた」というチェックの項目を設け、チェックの無い送信では処理を始めず、状態を「キャプチャ待ち」にします。 1時間おきの時間主導型のトリガーで「キャプチャ待ち」の行を見直し、フォルダに画面IDのファイルがそろったら処理を始めます。

リリースの日ではなく、検証環境で改修が固まった時点で動かします。 本番に出る前に指摘が出れば、マニュアルの改訂版をリリースと同じ日に配れます。リリースの後に動かすと、第3章の（d）の食い違いが本番で見つかることになります。

トリガーは作った人のアカウントで動くので、情報システム部の共有アカウントで作ります。

入力データを集める

質を決めるのは、いちばん下の画面IDの一覧です。 これが無いと、変わった画面がマニュアルのどこに写っているかを探すところから始まり、第3章の（a）がそのまま残ります。

一覧を作る最初の作業も、Gemini に手伝わせられます。 マニュアルのPDFを渡し、各ページのキャプチャがどの画面かを、画面のタイトルの文字から推定させて下書きを作ります。ただし確定は人が行い、以後はマニュアルのキャプチャの下に「画面ID：EX-120」のように書き込む運用にします。 書いてあれば、次からは推定ではなく文字で引けます。

改修票の「変更の内容」は、変更前と変更後の名前を対で書いてもらいます。 「［登録］→［保存］」の形です。この対が、意図した変更かどうかを分ける材料になります。

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

スクリプトは、画面IDの一覧から対象のページを引き、マニュアルのPDFからそのページだけを切り出したPDFを作ります。 450ページを毎回すべて渡すより、対象の節の前後1ページを含めた数ページに絞るほうが、照合の相手がはっきりし、トークンも少なく済みます。

手順が複数ページにまたがる節は、節の最初から最後までを切り出します。 途中のページだけを渡すと、「前のページで開いたメニュー」が分からず、写っていないボタンを「無い」と判断する原因になります。

新しいキャプチャは、ファイル名の画面IDで探します。1つの画面にタブやダイアログがある場合は、「EX-120_tab2」のように枝番で撮ってもらい、同じ画面IDの画像をすべて渡します。

AIへ渡す前に整形する

1. キャプチャのそろい具合の確認 … 改修票の画面IDすべてについて、新しいキャプチャがあるかを確かめます
2. 画像の形式と大きさの確認 … PNGかJPEGであること、リクエスト全体が20MBに収まることを確かめます。大きいものは縮小ではなく、ファイルのアップロードで渡します
3. 向きと鮮明さの確認 … 回転していないか、ぼやけていないかを確かめます。画面の録画から切り出した画像は、ぼやけていることが多いので使いません
4. 個人の情報の確認 … 検証環境でも、実在の社員名や取引先名が写っていることがあります。キャプチャの撮影には、決まった試験用のデータを使ってもらいます
5. ページの切り出し … 対象の節の最初から最後までを1つのPDFにします
6. 意図した変更の一覧化 … 改修票の「変更前→変更後」の対を、照合用の一覧にします
7. 前回の指摘との突き合わせ … 同じ節に前回の改修の指摘が残っていれば、それも渡します

4番目を省かないでください。 マニュアルは全社員が読むものです。キャプチャに実在の名前が写ったまま差し替えると、マニュアルを通じて広く配られます。 試験用のデータで撮る決まりは、この構成と関係なく必要です。

7番目は、前回直し忘れた箇所を拾うためです。 前回の指摘が「未対応」のまま残っていれば、今回の照合で同じ食い違いがもう一度出ます。二重に数えないよう、前回の指摘の番号を付けて返させます。

AIに処理させる

させるのは、手順の文とキャプチャに出てくる画面の要素を1つずつ新しい画面と照らし、食い違いを種類に分けて、場所と根拠を書き出すことです。

element_not_visible の扱いが、この構成でいちばん大事な区別です。 新しいキャプチャに［再計算］が写っていないとき、それはボタンが消えたのか、メニューを開かずに撮ったのか、画像だけでは決められません。 AIには「写っていない」までしか書かせず、消えたかどうかは改修の担当者に確かめます。

種類と別に、改修票との関係を付けます。 改修票の「変更前→変更後」の対に一致するものは expected、一致しないものは unexpected です。unexpected が、第5章の9番目で改修の担当者に回すものです。

4行目がいちばん起きやすい失敗です。 小さな文字の［確定］を、手順の文にある［決定］に寄せて「一致」と読むと、見つけたかった食い違いが消えます。 読みにくければ uncertain にさせます。

指示内容を固定する

あなたは社内システムの操作マニュアルを点検する立場です。
マニュアルのページ（古いキャプチャと手順の文）と、改修後の新しい画面のキャプチャを
見比べて、食い違いを書き出してください。マニュアルを書き直す必要はありません。

【見るもの】
- 手順の文に出てくるボタン名・項目名・メニュー名・タブ名
- 古いキャプチャに写っている要素
- 新しいキャプチャに写っている要素

【type の選び方】
- label_changed ......... 名前が新しい画面では別の名前になっている
- element_not_visible ... 手順の要素が新しいキャプチャに写っていない
- new_element ........... 新しい画面に手順で触れていない項目・ボタンがある
- order_changed ......... 並びが変わり、手順の順番と合わない
- screenshot_outdated ... 文は合っているが、キャプチャが前の画面のまま
- ok .................... 食い違いが無い

【厳守事項】
- 写っていない要素を「削除された」と書かないでください。
  element_not_visible とし、「新しいキャプチャには写っていない」とだけ書いてください。
- 読みにくい文字を、手順の文にある似た名前に寄せて読まないでください。
  自信が無ければ confidence を low にしてください。
- 新しい画面の名前は、画面に表示されている文字をそのまま写してください。
- 改修の内容の一覧に一致する食い違いは relation を expected、
  一致しないものは unexpected にしてください。
- 不具合かどうか、意図した変更かどうかは判断しないでください。
- 場所は新しいキャプチャの上の枠として、0〜1000 に正規化した座標で返してください。
  写っていない要素には枠を付けないでください。
- キャプチャに写っている人名・取引先名を書き出さないでください。
- マニュアルの修正の文案は suggestion に1文だけ書いてください。

【改修の内容】{change_pairs}
【前回の未対応の指摘】{open_findings}
【マニュアルのページ】{manual_pdf}
【新しいキャプチャ】{new_screens}

「写っていない要素を削除されたと書かない」を明記しないと、AIは自然に「［再計算］ボタンは廃止されました」と書きます。その一文が手順の削除につながり、まだあるボタンの説明がマニュアルから消えます。

「似た名前に寄せて読まない」も同じ理由です。 照らし合わせの目的は1語の違いを見つけることで、似ているものを同じと見なす親切さは、この点検では害になります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "change_ticket_id": "",
  "screen_id": "",
  "manual_section": "",
  "manual_pages": [0],
  "findings": [
    {
      "type": "label_changed | element_not_visible | new_element | order_changed | screenshot_outdated | ok",
      "relation": "expected | unexpected",
      "manual_text": "",
      "new_screen_text": "",
      "box_2d": [0, 0, 0, 0],
      "new_screen_file": "",
      "confidence": "high | low",
      "previous_finding_id": "",
      "suggestion": ""
    }
  ]
}

1つ目の理由は、type と relation を enum で固定できることです。 構造化出力では値を決まった選択肢に限れるので、一覧の絞り込みで「unexpected だけ」「label_changed だけ」をそのまま使えます。

2つ目は、manual_text と new_screen_text を並べられることです。 担当者は画像を開く前に、「［登録］→［保存］」のように何が何に変わったかを一覧で読めます。

3つ目は、box_2d で場所を示せることです。 スクリプトがこの座標で新しいキャプチャに枠を描いた画像を作り、一覧から開けるようにします。element_not_visible には枠が無いので、枠の有無でも種類の取り違えを検知できます。

ただし、値はスクリプトの側で確かめます。 構造化出力は文法として正しいJSONを返しますが、値の中身が正しいことまでは保証されないので、アプリケーションで検証するよう案内されています。relation が改修票の対と本当に一致しているか、manual_text が切り出したページの文字に実在するかを、スクリプトが文字列で照らします。

システムへ連携する

マニュアルの原稿には書き込みません。 第6章のとおり、出すのは指摘までです。

画面IDの一覧も読むだけです。 新しい画面が増えたとき、一覧への追加は担当者が行います。AIが推定した画面IDを一覧に書き足すと、誤った対応がそのまま次の点検の土台になります。

人が確認する

マニュアルの担当者は、次の順で一覧を見ます。

1. unexpected を先に見る … 改修票に無い食い違いです。改修の担当者に「意図した変更か」を確かめます
2. element_not_visible を確かめる … 検証環境で実際に画面を開き、要素が消えたのか、写っていないだけかを見ます
3. label_changed と screenshot_outdated を直す … 原稿の名前を直し、キャプチャを差し替えます
4. confidence が low のものを確かめる … 枠の画像を開いて、文字を目で読みます
5. 指摘を覆したら記録する … 誤った指摘の種類と理由を残します

2番目を省かないでください。 element_not_visible を「消えた」と読んで手順を削ると、まだあるボタンの説明がマニュアルから消えます。 確かめるのは検証環境で画面を開く数十秒です。

目標は、120節をならして1節4分です。 指摘の無い節は一覧で流し見て数秒、指摘のある節は原稿を直すので数分です。指摘が多い月は、改修票の書き方か、キャプチャの撮り方に問題があります。

例外に対処する

上から5行目までが大半を占めます。 どれもAIの問題ではなく、キャプチャの撮り方と、画面IDの一覧の整備の問題です。 撮り方の決まり（試験用のデータ、ファイル名、枝番）を1枚の紙にして改修の担当者に渡すほうが、照合の精度を上げるより効きます。

記録を残す

• 改修票の番号と、そのとき対象にした画面IDと節
• 切り出したマニュアルのページと、渡した新しいキャプチャ
• Gemini API の応答のJSONと、スクリプトの検証の結果
• 枠を描いたキャプチャの画像
• 担当者が指摘を覆した記録（種類と理由）
• unexpected について、改修の担当者が答えた内容

最後の行は、改修の側の改善の材料になります。 unexpected のうち「意図した変更だったが改修票に書き忘れた」が多ければ、改修票の書き方を直します。「意図しない変更だった」が出たら、それはマニュアルの点検がシステムの不具合を拾ったということです。

指摘を覆した記録は、指示の直しどころを教えてくれます。 element_not_visible が多すぎるなら撮り方、label_changed の誤りが多いなら解像度の設定を見直します。