1. 今日の相談
「公開前ページへパスワードを付けたいです。サーバーのアクセス制限をそのまま有効にしてよいでしょうか」
設定前に、目的、対象範囲、利用者、認証方法、影響先、テスト端末、解除条件、戻し方へ分けます。
2. 大丈夫です
ほー先輩:制限する場所が一段ずれたら、公開中のページまで閉じることがあるで。
AIには確認表の型だけを頼みます。実際の設定項目、認証方式、対象ディレクトリ、解除操作は、公式手順を確認できる管理者が行います。
3. 今日使うAI・道具
使うのはChatGPTと架空のサイト構成です。実URL、サーバー名、ユーザー名、パスワード、設定ファイル、IP、管理画面URLはAIへ渡しません。
AIに安全な認証方法、設定値、対象範囲、遮断成功、解除完了を判断させません。
4. 実際にやってみる
1. 制限の目的と期間を書く
公開前確認、関係者限定共有など目的を一つにし、開始と解除の条件を決めます。
2. 対象と影響先を確認する
対象URLだけでなく、画像、CSS、フォーム、API、検索エンジン、監視サービスへの影響を確認します。
3. テストと戻し方を先に決める
ログイン済み端末だけで確認せず、別ブラウザ、スマホ、対象外ページ、解除後の表示を確認する順番を決めます。
4. AIへ確認表の型を頼む
次の架空の条件だけを使い、Webアクセス制限の設定前確認表を作ってください。
「目的」「対象範囲」「利用者」「認証方法の確認先」「影響先」「テスト端末」「入れる確認」「入れない確認」「解除条件」「戻し方」「要確認」に分けてください。
正しい設定値、対象範囲、認証成功、遮断成功、解除完了を推測しないでください。
実URL、ユーザー名、パスワード、IP、設定ファイルを入力する欄は作らないでください。
【架空の条件】
(書く)
5. 公式手順で小さく試す
バックアップと現行設定を承認場所へ残し、管理者が小さい対象で設定し、対象内外と解除を別々に確認します。
5. 完成例
【目的】架空の新ページを関係者だけで確認
【対象範囲】対象URLを公式画面で要確認
【利用者】承認された確認担当者
【認証方法の確認先】サーバー公式手順
【影響先】画像・フォーム・検索・監視を確認
【テスト端末】ログイン状態のない別端末
【入れる確認】担当者が実測
【入れない確認】対象外の人・検索から実測
【解除条件】公開担当者の承認後
【戻し方】現行設定の保管場所を記録
設定値をAIが作らず、管理者が公式画面で確認する場所を残しています。
6. 使うときの注意
簡易なアクセス制限だけで、機密情報を安全に共有できるとは限りません。扱う情報の種類とサービスの仕様を確認し、必要なら承認された別の共有方法を使います。
検索エンジンの除外とアクセス制限は別です。公開前ページを検索に出さない設定も、公式仕様とサイト全体の方針から確認します。
7. 今日できたこと
- 制限する対象と期間を小さくできた。
- 入れる確認と入れない確認を分けられた。
- 設定前に解除条件と戻し方を残せた。
8. ほー先輩の一言
ほー先輩:鍵を付けた画面だけ見ず、公開中の入口が開いたままかも確かめよな。
契約更新は利用サイトと移行余裕を確認する方法、認証の復旧は二段階認証導入前の確認方法へ進めます。
やさしいAI仕事術