WordPressの作業を記事に残したい。でも、スクリーンショットに何が写っているかを全部確認するのは、意外と気を使います。
僕のブログでは、撮影した原本と公開用の画像を分けています。2026年10月24日の記事公開でも、PCとスマホで管理ツールバーの範囲を確認し、本文を残した公開用画像を別に保存しました。
結論:隠す情報を確認してから、読者が理解するための画面を残す。撮れた画像をそのままアップロードせず、「原本」と「確認済みの公開用」を分けて扱います。
この記事は、当ブログで実際に使った確認ルールと公開画面の例です。特定の画像編集アプリの操作解説や、あらゆる情報流出を防げるという保証ではありません。
隠すものと、説明のために残すものを分ける
WordPressの上部には、投稿の編集やプロフィールへ進む管理ツールバーがあります。公式資料でも、右側にユーザー表示とプロフィールなどへのリンクがあることが説明されています。
公開ページを見ているつもりでも、ログイン中の自分の画面には管理用の表示が含まれることがあります。僕は本文だけでなく、画面の四隅と上部も確認しています。
| 写っている内容 | 当ブログでの扱い |
|---|---|
| 公開済みの記事タイトル・見出し・説明文 | 記事の説明に必要なら残す |
| ユーザー名・メールアドレス・ログインID | 公開用画像では隠す |
| 管理画面のURLや、個人情報を含むファイル名 | 不要な部分を除く。本文に必要なら該当箇所をマスク |
| 設定項目名・操作ボタン・保存結果 | 手順が分かるように残す |
| パスワード・APIキー・認証コード・決済情報 | 撮影対象にしない。表示したまま作業証跡を撮らない |
| 他のタブ・通知・背景の別作業 | 目的の画面に不要なら撮影範囲から外す |
注意:秘密の値を含む画面を「あとで隠せばよい」と撮る運用にはしません。すでに写してしまった場合も、原本を記事や公開の画像加工サービスへ送らず、取り扱いを確認します。
この表は当ブログの運用基準です。公開済みの自サイトURLを一律に秘密扱いしているわけではありません。誰の情報か、公開する必要があるか、そこに認証情報が含まれないかで判断します。
実例:管理バーだけを除き、本文の文脈は残した
直近の公開作業では、公開結果を見るPC画面とスマホ画面を、それぞれ原本と公開用で保存しました。
| 今回の画面 | 公開用にした範囲 |
|---|---|
| PCの公開結果確認 | 上端32pxの管理ツールバーを除外 |
| 390px幅のスマホ確認 | 上端46pxの管理ツールバーを除外 |
| WordPressの編集画面 | 原本を作業用に保存。公開用には採用しないものもある |
32px・46pxは、今回の画面で確認した値です。どのサイトでも同じ高さを切れば安全、という意味ではありません。別の場所に名前やメールが出ていれば、その箇所も確認が必要です。
下は、既存記事へ案内リンクを追加した後の公開画面です。管理バーは除きましたが、見出し、説明、新しいリンク、チェック項目は残しています。

「個人情報を隠すために、説明したい場所まで大きく切り取る」と、何を確認した画面なのか分かりにくくなります。隠すべき部分が本文の中にある場合は、その部分だけを不透明に覆った公開用ファイルを作り、書き出した画像を開き直して確認する方針です。
今回は、本文中の値を塗りつぶす作業はしていません。実際に行ったのは管理バーの範囲除外と、保存した公開用画像の目視確認です。
原本のrawと、公開用のredactedを別フォルダーにする
当ブログの画像ログでは、未加工の原本を raw、公開前の確認を終えた画像を redacted というフォルダーに分けています。ここでいうrawはカメラのRAW形式ではなく、「作業用の原本」という意味です。
screenshot/
└── 2026-10-24/
├── raw/
│ └── 011_publish_checklist_incoming_raw.png
└── redacted/
└── 011_publish_checklist_incoming_redacted.png
連番をそろえると、どの原本に対応する公開用画像なのか追えます。ただし、ファイル名に redacted と付けただけで処理や確認が終わるわけではありません。
作業ログには、何が写っていたか、どこを除いたか、公開用を作ったかを残します。公開用がない画像は、必要になっても原本で代用しません。
原本の保存先も、公開リポジトリや共有フォルダーへ自動で送られない場所かを確認します。フォルダー名で分けることと、アクセスを制限することは別です。
公開前の確認を3ステップにする
僕が続けたいのは、画像加工を複雑にすることより、確認する順番を固定することです。
秘密の値や別作業の通知がないか確認します。説明に必要な画面だけを撮り、高リスク情報が表示中なら撮影を止めます。
原本を残し、隠す情報だけを除くかマスクします。見出し・設定項目・操作結果など、説明に必要な部分は残します。
公開用ファイルを開き直し、隠し残しを確認します。WordPressでは公開用だけを選び、PC・スマホのプレビューで読めるかも確かめます。
アップロードを選ぶときは、似た名前の原本をつかまないように、選択元のフォルダーも見ます。記事を下書きにしていることを、画像が保護されている根拠にはしません。
参考として、WordPress.comの公式ヘルプには、パスワード保護した記事内の画像やメディアへ、ファイルのURLから直接アクセスできるという注意があります。当ブログはセルフホストのWordPressで、すべての構成のアクセス制御を検証したわけではありません。だからこそ、公開設定に頼って未処理画像を置かず、アップロード前に確認する方針です。
マスクの確認と、スマホで読めるかの確認は別
個人情報が見えなくても、肝心の操作結果が小さすぎる画像では、読者の助けになりません。逆に、スマホできれいに見えていても、原寸で開くと隠し残しがあるかもしれません。
僕は「公開してよい内容か」と「説明が読めるか」を別々に見ます。下は390px幅で確認した記事の実画面です。ステップの見出しと説明が残る位置で撮り、上部の管理バーだけを除いています。

画像にはaltテキストと短い説明も付けます。altへ個人情報を書き戻したり、マスクで隠した内容をキャプションで再掲したりしないようにします。
公開直前は、次の4点を見直します。
- 公開用ファイルを原寸で開き、隠し残しがないか確認したか
- WordPressへ入れたのは公開用で、原本ではないか
- 何を確認する画像か、前後の本文とキャプションで分かるか
- スマホで見切れず、画像がなくても要点は本文で読めるか
まとめ:隠す範囲と、残す意味をセットで確認する
スクリーンショットは、実際に操作したことを伝える材料になります。ただ、撮影できたことと、そのまま公開できることは同じではありません。
今回の僕の作業では、管理バーだけを除いた公開用ファイルを別に保存し、本文の見出しや結果は残しました。未加工の原本は公開に使わず、処理内容をログから追えるようにしています。
次に画像を1枚アップロードする前に、「このファイルは公開用として確認済みか」を確かめてみてください。画像以外も含めた確認順はブログ記事公開後のチェックリスト、今回の画面の元になった作業は公開記事数を自動表示へ直した実録で確認できます。
公式の参考資料
公式資料・実画面の確認日:2026年10月24日。本文のファイル運用は当ブログの実践方針です。
