技術者向け：セキュリティは「実装」の前に「判断の単位」を揃える
この記事が想定する読者：実装・運用を担う技術者で、何を揃えれば経営層の決め事と噛み合うか知りたい方。
判断を誤るとどうなるか：ツールや実装から入ると、決め事と実装がずれ、何を優先したか説明できない。先にログ・権限・復旧・交通ルールの4単位を経営層の決め事と1対1で対応させてから選定・実装すると失敗しにくい。
経営層が「5つの決め事」を決めたあと、技術者がやるべきこと
「何を実装すればいいか、優先順位が付かない」
経営層向けの記事では、何を決めるか（二重確認・復旧・直す順番・交通ルール・事故時の役割）が整理されています。
では、実装・運用を担う技術者は、そのあと何を揃えればよいか。
この記事では、技術の羅列ではなく、「判断の単位」を揃えるという考え方を置きます。
単位が揃うと、ツール選定も実装も、経営層の決め事と1対1で対応し、ぶれにくくなります。
前提：経営層の「5つの決め事」と技術者の「4つの単位」
経営者向け記事で書いた5つは、次のとおりです。
- 重要手続きの二重確認を義務化する
- 復旧を強くする（鍵より復旧）
- 直す順番を決める（期限・担当・例外）
- 大量アクセスへの交通ルールを決める
- 事故のとき誰が何をするかを決めておく
技術者側では、これらを実装で支える単位を4つに切ると、判断しやすくなります。
- ログ：何を残すか（誰が・いつ・何をしたか、復旧・権限変更・失敗試行）
- 権限：どこで切るか（誰が復旧できるか、誰が権限変更できるか、二重確認の「2人目」は誰か）
- 復旧：条件と履歴（復旧の条件、復旧した記録が残るか）
- 交通ルール：どのレイヤーで置くか（ログイン試行・フォーム送信・APIのレート制限）
「この機能は、どの決め事のどの単位を満たすか」を1文で言えるようにしておくと、実装の優先順位と経営層の期待が噛み合います。
単位1：ログ——「何を残すか」を決める
事故のとき困るのは、何が起きたか分からない状態です。
技術者が最初に揃えるのは、何をログに残すかという判断の単位です。
- 重要手続きの実行：誰が・いつ・どの操作をしたか（送金・権限変更・アカウント復旧など）
- 認証の失敗：ログイン失敗・パスワードリセット要求・多段階認証の結果
- 異常なアクセス：短時間の大量リクエスト・同一IPからの連続試行
「全部残す」はコストとノイズで破綻するので、経営層が「事故のとき誰が何をするか」で必要だと決めたものから逆算して、最低限の項目をリストにします。
このリストが、ツール選定時の「ログ要件」になります。
単位2：権限——「どこで切るか」を決める
二重確認・復旧の「誰がやるか」は、権限の切り方で実装されます。
- 復旧できる人：人数を絞り、条件（本人確認の手順）とセットで実装する
- 権限変更できる人：変更履歴が残る設計にする
- 二重確認の「2人目」：役割または指名で固定し、システム上も「1人目だけでは完了しない」ようにする
「とりあえず管理者に全部権限を渡す」は、決め事と実装が噛み合っていない状態です。
「決め事2（復旧を強くする）」「決め事1（二重確認）」に対応する権限の切り口を、一覧にしておくと、実装とレビューが楽になります。
単位3：復旧——条件と履歴を実装する
「鍵より復旧」は、復旧の条件と復旧した履歴を実装で担保することです。
- 復旧の条件：本人確認を何でするか（メール＋別チャネル、二人承認など）、条件を満たしたときだけ復旧可能にする
- 復旧の履歴：誰が・いつ・どのアカウントを復旧したかが残る設計
ここが弱いと、経営層が「復旧を強くする」と決めても、実装が追いつかず、だましの入口のままになります。
技術者は「復旧フロー」を1本、条件と履歴込みで設計し、それに沿って実装・ツールを選ぶと判断が揃います。
単位4：交通ルール——どのレイヤーで置くか
「大量アクセスへの交通ルール」は、どのレイヤーで制限を置くかという判断の単位です。
- アプリケーション層：ログイン試行回数・フォーム送信頻度・セッション数
- API層：レート制限・キー単位のしきい値
- インフラ層：DDoS対策・WAF
「全部やる」ではなく、経営層が「直す順番」で決めた重要入口から、どこに交通ルールを置くかを決めます。
重要入口ほど厳しく、それ以外は段階的に、という方針を1文で書いておくと、実装と運用の判断がぶれません。
ツール選定：「何を満たせば採用か」を決め事に対応させる
ツールを選ぶとき、機能一覧で選ぶと、経営層の決め事と噛み合わないことがあります。
代わりに、「何を満たせば採用か」を、5つの決め事と4つの単位に対応する形でチェックリストにします。
例（抜粋）：
- 決め事1（二重確認）：権限の「2人目」を強制できるか／ログに残るか
- 決め事2（復旧）：復旧の条件を設定できるか／復旧履歴が残るか
- 決め事4（交通ルール）：ログイン試行・レート制限を設定できるか
- 決め事5（事故時）：必要なログが取得できるか／誰が何をしたか追えるか
このチェックリストがあると、「このツールは決め事のどれを満たすか／満たさないか」がはっきりし、導入の優先順位と例外（今はやらない）の理由を説明しやすくなります。
よくある誤解：ツールを入れたら終わりと思いがち
「セキュリティツールを入れたから安心」と止まると、決め事と実装がずれたままになります。
実際に効くのは、決め事と、ログ・権限・復旧・交通ルールの実装が対応しているときだけです。
実装前に、「この機能はどの決め事のどの単位を満たすか」を1行で言えるようにしておくと、抜け漏れと過剰実装の両方を減らせます。
判断の土台として押さえておくこと
- 経営層の5つの決め事と技術者の4単位を1対1で対応させる：二重確認・復旧・直す順番・交通ルール・事故時の役割を、ログ・権限・復旧・交通ルールで支える。
- ツール選定は「何を満たせば採用か」を決め事に対応させて書く：機能一覧で選ばず、決め事と実装が噛み合うかで判断する。
- 「ツールを入れたら終わり」にしない：効くのは決め事と4単位の実装が対応しているときだけ。実装前に「この機能はどの決め事を満たすか」を1行で言えるようにする。
次の一手：セキュリティを判断の切り口で整理する／攻撃者の目的と手法を判断の切り口にする／セキュリティ判断ハブ
まとめ：技術者の仕事は「決め事を実装の単位に翻訳すること」
経営層の「5つの決め事」を、技術者側では4つの単位（ログ・権限・復旧・交通ルール）に翻訳し、
「何をログに残すか」「どこで権限を切るか」「復旧の条件と履歴をどう実装するか」「交通ルールをどのレイヤーに置くか」を明文化します。
単位が揃うと、ツール選定も実装も、判断の根拠が「経営層の決め事」とつながり、
「何を優先するか」「何を後回しにするか」を説明しやすくなります。
次に読む（学習パス）
- セキュリティを判断の軸で整理する（読み方・記事一覧）：セキュリティ関連の記事・ツールの入口
- 専門用語ゼロでわかる：Webの安全は「カギ」じゃなく「手続き」で決まる：前提となる「3つの穴」とたとえ話での整理
- 経営者向け：セキュリティは「技術」ではなく「損失の期待値」を下げる投資である：費用対効果で優先順位を決める方法
- セキュリティを「判断の切り口」で整理する：入口・手続き・運用の3軸で切る考え方
- セキュリティ棚卸し＆優先順位：最大損失×起こりやすさで直す順番を出し、TOP10をCSV出力
- セキュリティ自己診断：入口と対策の棚卸しを無料で行う
- 進め方（Method）：前提設計→仮説→予算→判断ログ→1枚資料まで、判断の循環を体験する