Windows・Microsoft 365・Google・NASで共通して使えるパスワードの文字 — バッチで使えない3記号も含めて
- 第1回：バッチでパスワードを変更したらOutlookとTeamsの認証が消えた
- 第2回：非エンジニアにバッチを配って一斉実行してもらうときの落とし穴
- 第3回：Windows・Microsoft 365・Google・NASで共通して使えるパスワードの文字（この記事）
- 第4回：LanDiskのCSV一括登録で既存ユーザーのパスワードを更新する
1つのパスワードを、WindowsログインとMicrosoft 365、Googleアカウント、NAS（LanDisk）で使い回したい——。利用者にとっては覚えるパスワードが1つで済む、ありがちな運用だ。
ところが各サービスの文字種・桁数の制約は一致しない。緩いサービスに合わせて決めると、別のサービスで弾かれる。さらに今回は、決めたパスワードをバッチファイルに埋め込んで配るので、cmd（コマンドプロンプト）の特殊文字という第5の制約まで効いてくる。
この記事では各サービスの実際の要件を整理し、すべてで通る共通ルールを導く。結論を先に置く。
共通ルール：15〜20文字／大文字・小文字・数字・記号のうち3種以上／半角ASCIIのみ／記号 ! % " は使わない。
記号は # を1種混ぜておけば、全サービスで設定できることを実機で確認済み。
サービスごとの制約を並べる
「一番狭い制約が全体を決める」ので、まず各サービスの要件を一覧にする。
| サービス | 桁数 | 文字種の要件 | 使える文字 |
|---|---|---|---|
| Windows ローカルアカウント | 実質127文字まで | なし（縛りなし） | 幅広い（今回は半角ASCIIに限定） |
| Microsoft 365（Entra ID） | 256文字まで | 4種中3種以上が必須 | 半角英数字・記号 |
| Google アカウント（個人） | 8〜100文字 | なし（推奨のみ） | 半角ASCII。先頭・末尾の空白は不可 |
| NAS（LanDisk） | 20文字まで | なし | 半角英数字・記号。空白・全角は不可 |
桁数の上限はLanDiskの20文字が最も厳しく、これが全体の上限になる。文字種の要件はMicrosoft 365の「4種中3種以上」だけが必須で、これが全体の下限を決める。
Microsoft 365：文字種「4種中3種以上」は管理者でも緩められない
Microsoft 365（Entra ID のクラウドユーザー）は、英大文字・英小文字・数字・記号の4種類のうち3種類以上を含むことを必須にしている。これはMicrosoft側の仕様で、テナント管理者でも緩和できない。
管理センターの「アクティブなユーザー」からパスワードをリセットするとき、たとえば数字だけ・英字だけのパスワードはエラーで弾かれる。「文字種の縛りなし」で決めた人のうち、3種未満の人だけ後から弾かれて手戻りになる。最初から3種以上を要件に含めておくのが安全だ。
桁数について。Microsoft 365にはかつて16文字の上限があったが、これは2020年に撤廃され、現在は256文字まで設定できる。ネット上には古い「16文字まで」の情報が残っているので注意。ただし、古い契約やテナント設定で制限が残っている可能性はゼロではないので、テスト用アカウントで20文字を実際に設定してみるのが確実だ。
Google アカウント：会社管理（Workspace）か個人かで前提が変わる
Googleは前提の取り違えに注意がいる。会社が管理する Google Workspace（管理者がポリシーを設定できる）と、各自が自分で管理する個人Googleアカウント（会社のメールアドレスで登録しただけ）は別物だ。
個人Googleアカウントの場合、必須の文字種要件はなく（推奨はあるが強制ではない）、8〜100文字、半角ASCIIで、先頭・末尾の空白が不可という程度。15〜20文字のパスワードは問題なく設定できる。
各自が変更画面で操作する際、英小文字だけ等だとGoogleの強度判定で「弱い」と警告が出ることはあるが、警告が出ても設定自体は可能だ。今回の共通ルール（3種以上）を守っていれば、この警告も基本的に出ない。
NAS（LanDisk）：上限20文字、記号 # はOK
今回いちばん効いてくる制約。LanDiskはパスワードが20文字までで、これが共通ルールの上限を決める。実機テストで、20文字のパスワードと記号 # が問題なく設定できることを確認した。空白や全角文字は使えない。
機種・ファームウェアによって細かな差があり得るので、ここもテスト用アカウントで記号入り・20文字を一度試すのが堅い。LanDiskへのCSV一括登録の話は第4回で詳しく扱う。
第5の制約：バッチに埋め込むと壊れる記号がある
ここからが見落としやすい。決めたパスワードをバッチファイルに set "NEW_PASSWORD=..." の形で埋め込むので、cmd（コマンドプロンプト）が特別扱いする記号が混ざると、パスワードが意図せず別物になる。
本番と同じ構造のバッチで記号を1つずつ検証したところ、はっきり使ってはいけない3記号が出た。
| 記号 | 何が起きるか |
|---|---|
! | setlocal enabledelayedexpansion（遅延展開）が有効だと、! が変数展開の記号として食われて消える |
% | cmdの即時展開で % が変数記号として解釈され、消える・化ける |
" | set "NEW_PASSWORD=..." の引用符の対応を壊し、パスワードがそこで切れる |
厄介なのは、これらを含んでもパスワード変更コマンド自体は「成功」を返してしまうことがある点だ。コマンドはエラーを出さないのに、実際には ! や % が消えたパスワードが設定されている。後でログインできなくなって初めて気づく、最悪のパターンになる。だから「コマンドが成功した」ではなく「意図した文字列が本当に設定されたか」で判断する必要がある。
逆に、次の29種の記号はバッチ内でも問題なく使えることを確認した（本番と同一構造でのテスト結果）。
# @ $ ^ & * - _ + = . ? ~ ( ) { } [ ] / : ; < > , ' \ | ` とスペース。
ただし & < > ' \ ` はcmdで意味を持つ文字でもあり、別の文脈では悪さをしうるので、安全側に倒すなら避け、無難な # や @ $ - _ あたりに絞るのがおすすめだ。
「見ればわかる」全角混入は、ツールで弾く
パスワードを一覧管理していると、8dBRbqRR8BpKdTd日本語 のような全角文字や、半角に紛れた全角スペースが混ざることがある。全角スペースは目視ではまず気づけない。
形式チェックは「禁止文字が入っていないか」ではなく、「許可された文字だけで構成されているか」（ホワイトリスト方式）で組むと、この手の混入を一網打尽にできる。具体的には、各文字のコードポイントが32〜126（半角の印刷可能ASCII）の範囲内かを判定すればよい。範囲外の全角文字・全角スペース・制御文字をすべて検出できる。
Excelで全角・禁止文字を弾くチェックの考え方
1文字ずつコードポイント（VBAなら AscW()）を取り出し、32以上126以下に収まらない文字が1つでもあればNGにする。これで全角・全角スペース・制御文字を一括検出できる。
そのうえで、印刷可能ASCIIの範囲内であっても、前述の ! % " を含むものは別途NGにする。「ASCII範囲チェック」＋「バッチ禁止文字チェック」＋「文字数（15〜20）」＋「文字種3種以上」の4段で判定すると、入口でほぼすべての事故を止められる。バッチ生成時にも同じ判定を通し、NGがあれば生成自体を中止する二重構えにしておくとなお安全だ。
導かれる共通ルール
すべての制約の重なりを取ると、共通ルールはこうなる。
- 文字数：15〜20文字。 上限はLanDiskの20文字。下限はセキュリティ方針しだいだが、長め（15文字以上）にすると文字種の要件も自然に満たしやすい。
- 文字種：大文字・小文字・数字・記号のうち3種以上。 Microsoft 365に合わせる。
- 文字：半角ASCIIのみ。 全角・全角スペース・先頭末尾の空白は不可。
- 記号：
!%"は使わない。 バッチに埋め込むと壊れる。記号を入れるなら#が全サービスで確認済みで無難。
このルールで作ったパスワードは、Windowsログイン・Microsoft 365・Googleアカウント・LanDisk・バッチ生成のすべてを通過する。「緩いサービスに合わせて決めて、後で厳しいサービスに弾かれる」という手戻りを、設計段階で消せる。
確認は実機・テストアカウントで
仕様は変わるし、テナントや機種で差が出る。最終的にはテスト用アカウントで一度ずつ設定してみるのが確実だ。最低限、次の2点だけでも実機確認しておくと安心できる。
- Microsoft 365 管理センターで、テスト用アカウントに20文字のパスワードを設定できるか（古い16文字上限が残っていないか）。
- LanDiskの管理画面で、テスト用アカウントに記号入り・20文字のパスワードを設定できるか。
まとめ
1つのパスワードを複数サービスで使い回すなら、一番狭い制約が全体を決める。今回はLanDiskの20文字上限とMicrosoft 365の「3種以上」、そしてバッチに埋め込むと壊れる ! % " が効いた。
これらの重なりに収めた「15〜20文字・3種以上・半角ASCII・!%" 禁止」を共通ルールにすれば、各サービスでの手戻りも、バッチでの文字化けも避けられる。仕様は変わるので、最後はテストアカウントでの実機確認を一手間かけておきたい。