Claudeで社内の操作マニュアルをスクリーンショットから起こす手順
操作画面のスクリーンショットを順番どおりに渡し、手順文と注意書きをClaudeに起こさせる流れです。個人情報の映り込みを先に処理する手順と、読み違いの確かめ方も載せます。
VPNの接続、経費精算システムの申請、複合機のスキャン設定。社内の操作マニュアルは、担当者が画面を見ながら手で書き起こすのが定番です。画面キャプチャをClaudeに渡せば、手順文の下書きまでは短時間で出せます。ただし、キャプチャには社員名やメールアドレス、社内URLが映り込みます。起こす作業より先に、映り込みの処理を済ませるのがこの流れの肝です。
ここでは、キャプチャの下ごしらえ、アップロード、指示文、出力の検証の順に、手を動かせる形で説明します。
先に決めること: Claudeに渡す前にキャプチャを加工する
Claudeに「個人情報が映っていないか確認して」と頼む方法もありますが、それはすでに画像を渡したあとの確認です。渡す前にこちらで隠すほうが、確実に手前で止められます。
映り込みやすい場所は、画面の種類ごとにほぼ決まっています。
| 画面 | 映り込みやすいもの |
|---|---|
| ブラウザの業務システム | 映り込みやすいものアドレスバーのURL、右上のログイン名、通知バッジ |
| メール・チャット | 映り込みやすいもの差出人名、件名、受信トレイの一覧 |
| 管理コンソール | 映り込みやすいものユーザー一覧、メールアドレス、IPアドレス |
| 設定画面 | 映り込みやすいもの端末名、シリアル番号、ライセンスキー |
| 画面全体のキャプチャ | 映り込みやすいものタスクバーの通知、別ウィンドウのタイトル |
手順としては、次の順で処理します。
アップロード前の下ごしらえ
- 1
撮る範囲を絞る
画面全体ではなく、操作に関係するウィンドウだけを撮ります。通知や別ウィンドウの映り込みはこれで大半が消えます。
- 2
テスト用アカウントとダミーデータで撮る
本番アカウントで撮ると、実在の社員名や取引先名が残ります。ダミーのユーザーで撮り直せるなら、マスクの手間ごと省けます。
- 3
残った情報を塗りつぶす
ぼかしではなく、黒で塗りつぶします。文字の判読が残る弱いぼかしは避けます。
- 4
ファイル名に連番を振る
01_login.png、02_menu.pngのように、操作の順に番号を付けます。この番号が、あとで指示文の中の参照名になります。
塗りつぶしたあとは、PNGで保存し直します。JPEGで何度も再圧縮すると、細かい文字が読みにくくなります。圧縮の影響は画像の読み取り精度に出ると、Claude APIのビジョン機能の解説にも書かれています。
アップロードの前提: 形式・枚数・サイズ
Claudeが扱える画像形式はJPEG、PNG、GIF、WebPです。チャットへのアップロードは1ファイル500MBまで、1チャットで最大20ファイル、画像の寸法は8000×8000ピクセルまでと、ヘルプセンターに載っています。claude.aiでは1メッセージあたりの画像も20枚が上限です。
つまり、20ステップを超える操作手順は、1回では渡し切れません。章ごとに分けて渡す設計にします。たとえば「ログイン」「申請の入力」「承認依頼」のように、1章を10枚以内に収めておくと、後で差し替えるときも楽です。
画面の大きさにも注意が要ります。ヘルプセンターは1000×1000ピクセル以上の画像を勧めています。一方でビジョン機能の解説には、200ピクセル未満の小さい画像や低品質、回転した画像では読み違いや作り話が出うると書かれています。ボタンのラベルが小さく映る画面は、その部分を拡大して撮り直すか、別のキャプチャとして追加します。
長辺が大きすぎる画像は、処理の前に縮小される点も知っておくと便利です。縮小の上限はモデルごとに異なるため、超高解像度で撮るより、必要な範囲を適度な大きさで撮るほうが文字は読みやすくなります。
# macOS標準のsipsで、長辺を1600pxに揃える(元ファイルは上書きされる)
sips -Z 1600 *.pngWordに貼ったキャプチャは読まれない
既存のマニュアルを作り直すとき、Word(DOCX)に画像を貼った文書をそのまま渡したくなります。ここに落とし穴があります。PDF以外の文書では、Claudeはテキストだけを抽出し、埋め込まれた画像は読み取れないと、ヘルプセンターに明記されています。
落とし穴
DOCXに貼ったスクリーンショットは中身が伝わらない
文書は読めても、貼られた画面の中身は読まれません。旧マニュアルを素材にするなら、画像を別ファイルで取り出して渡すか、PDFに書き出して渡します。PDFは100ページ以下なら、テキストに加えて画像や図表も解析されます。101〜1000ページでは、テキストのみになります。
Projectsのファイルについても注意があります。Projectの知識に置くファイルは、テキスト抽出が基本で、画像まで解析されるのはマルチモーダルPDFだけです。スクリーンショット自体は、チャットに直接添付するほうが確実です。Projectには、後述する文体ルールのような文章だけを置きます。
指示文の組み立て: 画像1枚ごとに役割を与える
画像をまとめて貼って「マニュアルにして」と頼むと、手順の抜けや、画面にない操作の補完が起きやすくなります。1枚ずつ「何の画面か」と「そこで何をするか」を人間側が添えると、Claudeが推測で埋める量が減ります。
ビジョン機能の解説は、複数の画像を渡すときに Image 1: のような短いラベルを付けると、あとの指示や追加の質問で名前で呼べると説明しています。claude.aiのチャットでも、ファイル名の連番と指示文の番号を一致させておけば、同じ使い方ができます。
次の指示文は、そのままコピーして使える雛形です。
添付の画像は、経費精算システムの申請手順を撮ったスクリーンショットです。
ファイル名の番号が操作の順番です。
画像ごとの補足:
01_login: ログイン画面。社員番号とパスワードを入力する
02_menu: 申請メニュー。「新規申請」を押す
03_form: 入力フォーム。金額と日付を入れる
読者は入社1年目の事務職員です。次の形式で手順書の下書きを作ってください。
- 手順は番号付きで、1手順につき操作を1つだけ書く
- ボタン名・項目名は、画像に表示されている文字をそのまま「」で囲む
- 画像から読み取れない操作は補わず、末尾に「要確認」として列挙する
- つまずきやすい点があれば、手順の直後に「注意」として1行で添える
- 画像に個人名・メールアドレス・社内URLが読み取れた場合は、手順文には書かず、
該当する画像番号だけを先頭に挙げる最後の項目が、映り込みの二重チェックです。ただし、これは「渡したあとでの検出」にすぎません。前節のマスクを済ませたうえで、取りこぼしを拾う保険として入れます。
社内の文体ルールはProjectsに置く
何本もマニュアルを作るなら、表記や文体のルールを毎回貼るのは手間です。Projectsを使い、ルールだけを文章としてProjectに置きます。たとえば、次のような内容です。
# マニュアルの書き方
- 文末は「〜します」で統一する
- ボタン・メニュー名は「」で囲む
- 1手順に操作は1つ
- 用語は「ログイン」(「サインイン」は使わない)
- 注意書きは手順の直後に「注意:」で始める
- 画面にない操作は書かず、「要確認」に回す士業事務所の業務マニュアルを共有して職員の質問に答えさせる使い方は、Claudeで士業事務所の業務マニュアルを共有する記事が詳しいです。こちらは逆に、マニュアルを新しく起こす側のルールを置く使い方になります。
出力の検証: 画面と1行ずつ突き合わせる
Claudeは画面の中の文字は読めますが、位置関係の出力は近似です。ビジョン機能の解説も、座標や位置の出力はおおまかで、使う前に確認するよう述べています。「右上のボタン」「左のメニュー」といった位置の表現は、そのまま採用せず、画面と見比べます。
チェックは次の3点に絞ると、短時間で済みます。
- ラベルの一致: 手順に出てくる「」の文字が、画面の表記と一字一句同じか
- 順番の一致: 手順の番号とファイル名の連番がずれていないか
- 補完の混入: 画像にない操作や、画面に無い設定項目が書かれていないか
特に3点目は、入力フォームの項目名で起きやすくなります。画面に見えている項目だけを書かせるよう、指示文に「要確認へ回す」と書いておくと、補完を見つけやすくなります。
差し戻すときは、全文を再生成させるより、箇所を指定します。
手順4の「送信」は画面では「申請する」です。手順4だけ直してください。
他の手順は変えないでください。最終的には、そのシステムを普段使わない人に、完成した手順どおりに操作してもらいます。ここで引っかかった箇所が、キャプチャと文章のずれです。
画面が変わったときの更新: 差分だけを渡す
システムの画面は、アップデートで見た目が変わります。マニュアル全体を作り直さず、変わった画面だけを更新するときは、旧手順の本文と新しいキャプチャを一緒に渡します。
添付は、手順書の旧版と、画面が変わった箇所の新しいキャプチャ(05_form_new)です。
手順5だけを新しい画面に合わせて書き直してください。
旧版との差分は、変更前・変更後の2列の表にまとめてください。差分の表を出させておくと、レビューする人は変わった箇所だけを見れば済みます。旧版に無かった項目が新画面に現れたときも、表の「変更後」の列で気づけます。ここでも、画面と文言を突き合わせる最終確認は人間が持ちます。
画面操作そのものを任せる場合との違い
ここまでは、撮影済みの静止画をClaudeが読む方式です。一方、Coworkなどの画面操作機能は、Claudeが実際の画面を撮りながら操作を進めます。見える範囲が広く、許可したアプリの画面に映るものが丸ごと対象になります。この性質はCoworkのスクリーンショットに映る個人情報で整理されています。
マニュアル作りで静止画を選ぶ利点は、渡す画像を人間が先に選べる点です。映り込みの処理を済ませた画像だけを渡せるので、見せる範囲を自分で決められます。
社内に展開する前の確認
マニュアルの下書きが整ったら、公開前に次を確認します。
- 社内のAI利用ルールで、業務画面の画像を外部サービスに渡してよい範囲が決まっているか。方針づくりは社内のAI利用方針をClaudeで作成する手順にまとめています
- 完成したマニュアルの画像が差し替え前の画面のままになっていないか。システムの更新後は、変わった画面のキャプチャだけ撮り直して、該当の章だけ起こし直します
- 画像のaltテキストは別途整える。生成の流れはClaudeでaltテキストを画像から一括生成する手順に書いています
まとめ
画面キャプチャからの手順書づくりは、Claudeに任せる部分と人間が持つ部分がはっきり分かれます。映り込みの処理と、画面との突き合わせは人間の仕事です。手順文の整形と、注意書きの下書きがClaudeの仕事です。
運用が安定してくると、表記ルールをProjectに置き、毎回はキャプチャと画像ごとの補足だけを渡す形に落ち着きます。社内報のように定期的に文章を起こす業務にも、同じ型が使えます。Claudeで社内報・ニュースレターを自動作成する方法も、素材を渡して下書きを起こす型の一例です。