事業用パスワードの作り方・管理 完全ガイド 2026｜SaaS・銀行・会計ソフトを安全に使う実務手順

① 法人化・開業直後にパスワードが爆増する

会社を作った直後、あるいは個人事業主として本格稼働を始めた直後に、ほとんどの人がぶつかるのが「ID・パスワードの管理が回らなくなる」問題です。事業を回すために最低限必要なアカウントを書き出すと、すぐに次のような規模になります。

• 金融系：法人口座（インターネットバンキング）、法人カード、証券口座、決済代行（Stripe / PayPay / Square 等）
• 会計・税務：会計ソフト（freee、マネーフォワード等）、e-Tax、eLTAX、年金ネット、健康保険組合
• 業務SaaS：Google Workspace / Microsoft 365、Slack / Discord、Notion、Zoom、グループウェア
• Web運営：ドメイン管理（お名前.com 等）、サーバー（さくら / Xserver / Cloudflare）、CMS、Google Search Console、Google アナリティクス
• マーケ・販売：ASP管理画面（A8、もしも、バリューコマース）、広告アカウント、SNS（X、Instagram、YouTube）、メルマガ配信（Mailchimp / 配配メール）
• その他：法務局オンライン申請、ハローワーク・労働基準監督署系、各種補助金電子申請

軽く数えても20〜50個。設計方針を決めずに「思いついた文字列を毎回入力」していると、半年後には「ログインできない・パスワード再発行のループ」が頻発します。本記事は、最初に決めておくべき強度・生成・保管・2FAの4つを順に整理します。

② パスワード強度の基本｜「エントロピー(ビット数)」で考える

パスワードの強度は、シャノンエントロピーと呼ばれるビット数で測れます。簡単に言えば「攻撃者が総当たりで当てるのに、平均どれくらいの試行が必要か」を表す数値です。

計算式は エントロピー = 長さ × log2(文字種数)。たとえば英大小+数字+記号（約94種）から12字なら、12 × log2(94) ≈ 約79ビットになります。

強度の目安

80ビットというのは「2の80乗 ≈ 1.2×10²⁴ 通り」のことです。ただし近年のGPUクラスタやクラウド計算資源（オフライン・ハッシュクラッキング想定）を踏まえると、80ビットは「最低ライン」であって余裕がある水準ではありません。事業用は90ビット、金銭が動くものは100ビット以上を実務的な安全圏として設計するのが現代の指針です。

また、米国NISTのパスワードガイドライン（SP 800-63B）でも、近年は「文字種の強制混在は推奨しない。長さを重視せよ」という方針に変わっています。後述するとおり、4種混在は「補助」であって主軸は長さです。

③ 強いパスワードの作り方｜守るべき4原則

十分なエントロピー（事業用なら90ビット前後）に乗せるためには、次の4つを守ります。重要なのは順番で、長さが最優先、文字種混在は補助です。

1. 長さは16字以上を基本：短いと文字種を増やしても追いつかない。NIST SP 800-63B も「長さ重視」を推奨
2. 文字種混在は補助：英大小+数字+記号を交ぜると同じ長さで強度が上がるが、必須ではない。長さで稼ぐ方が記憶・運用上も有利
3. 推測されない：誕生日・社名・電話番号・連番（123456）・キーボード列（qwerty）は避ける。漏洩済みパスワードリスト（HIBP等）に含まれるものも不可
4. サービスごとに独立：使い回しは禁止。1サービス1パスワード

人間が暗記する必要があるもの（パスワードマネージャーのマスター等）は、ランダムな短い文字列よりパスフレーズ（複数単語をつなげた長文）のほうが現実的です。後述します。

ありがちな失敗は「強い1つを作って全サービスで使う」運用です。これはクレデンシャルスタッフィング攻撃の格好の餌になります。どこか一社から漏洩した瞬間、同じID/パスワードで全サービスが連鎖陥落します。漏洩リストは闇市場で出回り、攻撃は完全自動化されているため、人気がなさそうな小さなSaaSでも対象になります。

④ 用途別のパスワード設計

すべてを同じ強度で作る必要はありません。金銭・機密の重さに応じて、長さと文字種を出し分けるのが実務的です。

銀行系では「紛らわしい文字を入れない」設定が便利です。電話口や紙でやり取りする可能性がある場合に、O（オー）と0（ゼロ）、l（エル）と1（イチ）の混同を防げます。

⑤ パスワードの生成方法を比較する

生成手段にも複数の選択肢があり、強度と手間の兼ね合いで使い分けます。

選択肢1：自分で考える

人間が思いつく文字列は、無意識に意味のある単語・年号・近い数字を含むため、エントロピーが大きく落ちます。さらに毎回考えるのが面倒なので使い回しが発生します。事業用途では非推奨です。

選択肢2：ブラウザの自動生成

Chrome、Safari、Edge、Firefox いずれもパスワード入力欄で「強力なパスワードを生成」を提案します。これらは内部でCSPRNGを使っており、強度は十分です。手早く済ませたい場面では選択肢に入ります。ただし生成された文字列はそのブラウザのパスワード保存機能に紐づくため、他端末・他ブラウザでの同期方法を意識する必要があります。

選択肢3：パスワードマネージャーの組み込み生成

1Password、Bitwarden、Dashlane などのパスワードマネージャーには生成機能が組み込まれており、生成と保管が一体になっています。事業用途で本気で運用するならこれが基本形です。

選択肢4：専用の生成ツール

「自分の指定条件で生成したい」「マネージャーに保存する前に強度を確認したい」「APIキーを手作業で発行したい」といった場面では、独立した生成ツールが便利です。ツールを選ぶときは、後述するCSPRNGを使っているかを必ず確認してください。

⑥ 暗号学的に安全な乱数(CSPRNG)とは

パスワード生成ツールを選ぶうえで、決定的に重要なのが「どの乱数を使っているか」です。

Math.random() は使ってはいけない

JavaScriptには Math.random() という関数があり、0〜1の乱数を返します。しかしこれは暗号用途には不適切です。

• 内部状態が比較的小さく、過去の出力から次の出力を統計的に推定できる
• 多くの実装で同一シードからは同一系列が再現される
• ブラウザ仕様で「暗号用途には使うな」と明記されている

「強そうに見える文字列」が出てくるのでつい使ってしまいがちですが、攻撃者から見るとパスワード空間を一気に狭められる致命的な実装ミスです。

使うべきは crypto.getRandomValues()

現代のブラウザにはcrypto.getRandomValues()という、CSPRNG（Cryptographically Secure Pseudo-Random Number Generator）が用意されています。

• OSのエントロピー源（マウス動作、ハードウェア乱数、割り込みタイミング等）を利用する
• 出力から内部状態を逆算できないよう設計されている
• W3C Web Crypto APIの仕様で暗号利用向けと位置付けられている

安全なツールの見分け方

残念ながら、世の中のパスワード生成ツールのなかには Math.random() をそのまま使っている実装が今も少なからず存在します。見分けるポイント：

• サイト説明やFAQに「crypto.getRandomValues / CSPRNG / 暗号学的乱数」と明記されているか
• 処理がブラウザ内で完結し、サーバーに送信されないか（送信されたら何を使っていても無意味）
• 運営者・コードの透明性（オープンソース、または運営情報が明示されている）

⑦ パスワード管理の3つの選択肢

生成したパスワードをどう保管するか。実務的には次の3つから選ぶことになります。

パスワードマネージャーの選び方

個人事業主・小規模法人の定番は 1Password と Bitwarden です。1Passwordは法人プランが整っており、メンバー追加・権限管理・監査ログが充実しています。Bitwardenはオープンソースで料金が安く、機能要件が小さい場合に向きます。Appleデバイスのみで完結するなら Apple Keychain（iCloudキーチェーン） も実用十分です。

マスターパスワードの扱い

パスワードマネージャーの心臓部がマスターパスワードです。ここが破られると全資産が一気に攻撃者の手に渡ります。一方、マスターを忘れるとサービス側も復旧してくれません（その設計こそが安全性の根拠）。

• マスターはパスフレーズ方式で作る（人間が暗記する都合上、ランダムな短い文字列より長いフレーズが向く）。DicewareやEFFのロングワードリストから無作為に5〜7単語を選び、区切り記号でつなぐ手法が定番（例：correct-horse-battery-staple-typhoon-glacier のような形式）。EFFリストの7語で約90ビット相当
• マスター自体にも2FAをかける
• マスターを紙にも書き、自宅金庫または貸金庫に保管（業務用PCの近くには置かない）

⑧ 2要素認証(2FA)の重要性

パスワードがどれだけ強くても、フィッシング・マルウェア・サーバー側漏洩で盗まれる可能性はゼロにはなりません。2要素認証（2FA / MFA）はその「もし盗まれたら」を救う最後の壁です。

2FAの3つの方式

最低限、銀行・会計ソフト・メイン業務SaaS・パスワードマネージャー本体にはTOTPアプリでの2FAを必ず有効化してください。物理キーは1本3,000〜8,000円ほどで、銀行や決済代行など重要口座にだけ追加で挿す運用が現実的です。

リカバリーコードを必ず保管する

2FAを有効化するときに表示されるリカバリーコード（バックアップコード）は、端末紛失時の唯一の救命綱です。マネージャーに保存しつつ、紙でも控えて金庫に入れておくのが安全です。

TOTPアプリの選び方（2026年版）

TOTPアプリは過去にAuthyが定番でしたが、Twilio Authy は2024年3月にデスクトップ版（Windows/Mac/Linux）を終了し、その後もユーザー層の絞り込み等で運用が大きく変化しました。新規に選ぶなら、現時点では以下が現実的な選択肢です。

パスワードマネージャー本体のTOTPを同じマネージャー内に保存することは推奨しません（マスター漏洩時にパスワードと2FAコードが同時に流出するため）。マネージャー本体の2FAだけは、別アプリ（Ente Auth等）または物理キーで管理してください。

⑨ パスキー（Passkey/WebAuthn）— パスワードを置き換える次世代認証

2024〜2026年にかけて急速に普及しているのがパスキー（Passkey）です。WebAuthn / FIDO2 という標準仕様に基づく仕組みで、パスワードを使わずにデバイスの生体認証（指紋・顔）またはPINでログインします。Google、Apple、Microsoft、freee、マネーフォワード、Mercari、各種SNSなど主要サービスが続々と対応しています。

パスキーの強みはフィッシング耐性が原理的に高いことです。鍵がドメインに紐づくため、偽サイトに送信されても認証が成立しません。秘密鍵はデバイス（またはiCloudキーチェーン/Googleパスワードマネージャー/1Password等）に保存され、サービス側にはパスワードそのものが存在しないため、サーバー側漏洩でも資格情報が流出しません。

現代の推奨ルールはシンプルです。「対応サービスではパスキーを優先、未対応サービスでは強パスワード+2FAでつなぐ」。法人アカウントの管理者ログインや、銀行・会計ソフトなど高リスク口座から順にパスキー化していくのが現実的な移行手順です。

⑩ 当サイトの「パスワード生成ツール」の使い方

Toolbox Portal のパスワード生成ツールは、本記事で説明した要件をすべて満たすよう設計しています。

• CSPRNG使用：ブラウザ標準の crypto.getRandomValues() で生成。Math.random()は一切使用しない
• 完全ブラウザ完結：生成条件・生成結果ともに外部送信なし。ネットワーク切断状態でも動作する
• 用途別プリセット：「銀行用（16字・記号厳しめ）」「一般SaaS（12字）」「APIキー（32字）」など、本記事の用途別設計をそのまま選べる
• 強度メーター：生成したパスワードのエントロピー（ビット数）と推定解読時間をその場で表示
• 一括生成：複数のサービスを同時に登録するときに、一度に10〜50件まとめて生成可能
• 紛らわしい文字の除外：0/O、1/l/Iなどを抜くオプション

法人化直後の方は、あわせて法人化したらまずやる10のことと会社設立ロードマップもご覧ください。会計ソフトの選定は会計ソフト比較 2026にまとめています。請求書・契約書を作る場面では請求書ジェネレーターと契約書ジェネレーターも同じくブラウザ完結で動きます。

よくある質問(FAQ)