画面のキャプチャから社内システムの操作マニュアルを作る

処理の起点を決める

1本分のキャプチャが撮り終わったときが起点です。フォルダ監視でもスケジュールでもありません。人が操作しなければ画像が生まれないためです。

運用としては、指定のフォルダに システム名_機能名_001.png のような連番で置き、20枚単位でまとめて渡します。最小構成なら、生成AIのチャット画面に順番に貼るだけで足ります。

改修の連絡が来た時点で、変更のあった画面だけを撮り直す運用にすると、改訂の負担が大きく下がります。全部を撮り直さないでください。

入力データを集める

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

撮影： Windows標準の Snipping Tool を使います。前述のとおり、ステップ記録ツールは非推奨になっており、Microsoftの案内では代替として Snipping Tool の画面録画が挙げられています。画面の一部を選んで録画し、確認してから共有できるとされています。録画してから必要なコマを静止画として切り出すやり方だと、撮り漏れが減ります。

画像の受け渡し： Claude API では、画像を base64 で埋め込む方法、URLで参照する方法、Files API にアップロードして file_id で参照する方法の3通りがあります。同じ画像を何度も使うなら、アップロードして参照するほうが、リクエストが小さくなります。

画像の制限： 公開ドキュメントに、次の制限が記載されています。実装前に必ず見てください。

最後の行が実務上いちばん効きます。手順書1本は20ステップを超えることがあるので、20枚ずつに区切って渡す設計にしておくと、制限を気にせずに済みます。

AIへ渡す前に整形する

1. 個人情報のマスキング … これが最優先です。第13章に詳しく書きますが、画面には患者名・職員名・口座・金額が写ります。 テスト環境でも、実データが入っていることがあります。塗りつぶすか、ダミーデータに置き換えます
2. 寸法の調整 … 各辺2000ピクセル以下にリサイズします。制限を避ける目的と、費用を抑える目的の両方があります
3. 連番の確認 … 抜けや重複があると、手順の順番が狂います。ファイル名の番号で機械的に確かめます
4. 不要なコマの削除 … 画面録画から切り出すと、遷移の途中や読み込み中の画面が混ざります。落とします
5. 順番のラベル付け … 公開ドキュメントでは、複数の画像を渡すときに、各画像の前に「Image 1:」のような短いラベルを付けることが推奨されています。後の指示で「3枚目の画面」と呼べるようになります

AIに処理させる

させないことも決めます。

• 画面に写っていない機能の説明 … 「この画面では◯◯もできます」と書かせません。写っていないものは書かない
• 業務上の判断 … 「この場合は却下を選びます」は業務のルールです。人が足します
• 数値や項目の意味づけ … 画面の数字が何を表すかは、画面からは分かりません
• ボタン名の言い換え … 画面に「登録」とあれば「登録」です。「保存」に直させない

最後の1つは軽く見られがちですが、手順書の文言が画面と1文字でも違うと、読む人は止まります。

公開ドキュメントには、精度に関する注意も書かれています。低品質・回転した画像・200ピクセル未満の小さい画像では誤ることがあること、数を正確に数えられないことがあることが明記されています。だからこそ、全件を人が確かめます。

指示内容を固定する

あなたは社内システムの操作手順書を作る担当者です。
連番のキャプチャ画像を見て、手順文の下書きを作ってください。

【厳守事項】
- 画像に写っている文字だけを使ってください。
  ボタン名・タブ名・項目名は、画面の表記をそのまま書いてください。
  言い換えたり、省略したりしないでください。
- 画像に写っていない機能・画面・操作を書かないでください。
- 業務上の判断（どの選択肢を選ぶべきか、どういう場合に却下するか）は
  書かないでください。judgment_needed に「人が補う箇所」として挙げてください。
- 画面の数値や項目の意味を説明しないでください。
- 文字が小さい、ぼやけている等で読み取れない画像は、推測で埋めず
  unreadable にその画像番号と理由を入れてください。
- 前の画像との差分から操作を推定した場合は、
  confidence を "low" にしてください。

【対象】
システム名: {system_name}
この手順で達成すること: {goal}
想定読者: {audience}

【用語集（画面の表記 → 現場での呼び方）】
{glossary}

【様式】
{format_rules}

【画像】
Image 1: ... Image 20:

「言い換えない」と「写っていないことを書かない」の2つが、この構成の要です。 画像から手順書を作らせると、それらしい一般的な説明が混ざります。混ざった時点で、その手順書は現物と一致しなくなります。

出力形式を固定する

{
  "title": "",
  "prerequisites": [],
  "sections": [
    {
      "heading": "",
      "steps": [
        {
          "image_no": 1,
          "screen_name": "",
          "action": "",
          "ui_label": "",
          "note": "",
          "confidence": "high | low"
        }
      ]
    }
  ],
  "judgment_needed": [],
  "pitfalls": [],
  "unreadable": [
    { "image_no": 0, "reason": "" }
  ]
}

項目と型を決めて返させます。Claude API には、返す形を指定して構造化された出力を得るための仕組みがあります。この形で受け取れば、既存のWordの様式へ機械的に流し込めます。 自由文で受け取ると、毎回体裁を整え直すことになり、削減効果が消えます。

unreadable と judgment_needed は、担当者が最初に見る場所です。ここが空でも、全件を確認します。

システムへ連携する

出来上がった手順書は、既存の置き場へ公開します。

手順書の置き場は変えないでください。 この構成が変えるのは作り方だけです。置き場を変えると、職員が探せなくなり、また電話がかかってきます。

改訂の場合は、変更のあった画面の番号だけを差し替える運用にします。全文を作り直すと、手直しした注意書きが消えます。

人が確認する

全件、人が確認します。段階的な自動化もしません。

理由は2つあります。第一に、手順書は、そのとおりに操作されるものだからです。誤った手順書は、誤った操作を全職員に配ることになります。第二に、画面の読み取りには誤りが残るためです。

確認の仕方が重要です。画面を見比べるのではなく、手順書のとおりに操作してください。

1. 出来上がった手順書を印刷するか、別画面で開く
2. テスト環境で、書いてあるとおりに1手順ずつ操作する
3. 止まった箇所、迷った箇所に印を付ける
4. 印の付いた箇所を直す

この「1回通す」を省くと、この構成は使えません。 画面と文章が一致していても、手順として成立していないことがあります。ボタンを押す前に別の条件を満たす必要があった、といった抜けは、操作してみないと分かりません。

所要時間は1本10分程度です。ここが、After の30分の内訳の大半になります。

例外に対処する

記録を残す

• キャプチャ画像の原本（マスキング後のもの）
• 生成AIが返した下書き（人が直す前の状態）
• 人が直した箇所と、修正前後の文言
• 対象システムの名称とバージョン、撮影した日
• 確認者と確認日

「人が直した箇所」が精度の実測値になります。ボタン名はそのまま通るが、前提条件はほぼ全件が書き足されている、と分かれば、前提条件は最初から人が書くほうが速いと判断できます。

対象システムのバージョンと撮影日は、手順書そのものにも残してください。画面が変わったときに、どの手順書を直すべきかが分かります。