はじめに
ある日突然、
「今までのやり方が通用しません」と言われたら、あなたはどうしますか？
それは決して小さな変更ではありません。業務というものは、無数の前提と常識の上に成り立っています。「これをこうしたら、こうなるはずだ」「この申請はこの書式で通る」「この確認手段であれば、担当者が通してくれる」——そんな“いつもの感覚”が静かに崩壊した瞬間、それは小さな業務でも大きなトラブルに変わるのです。
今回取り上げるのは、Ballot SC‑80 v3という、少々マニアックに見える技術的な変更です。CA/Bフォーラムという、世界中の証明書発行機関とブラウザベンダーが集まって運用ルールを決めている場で、「WHOISを使ったドメイン認証は、もう禁止にしよう」という方針が決まりました。言ってしまえば、「電話で本人確認するの、もうやめましょう。これからは全部、Webの自動システムで行きます」みたいな話です。
でもこれ、ただの仕様変更ではありませんでした。
私たちが普段、Webサービスやシステム公開のために利用している「SSL/TLS証明書」は、発行時にそのドメインの所有者であることを証明する必要があります。その一つの方法として、長年使われてきたのがWHOIS情報を使った認証、つまり「登録されているメールアドレスに確認メールを送り、それをクリックして証明完了」という手段でした。
この方法は多くの組織にとって“常識”であり、“前提”でもありました。「証明書更新する？ ああ、じゃあドメインに登録されているメールで認証かけて終わりね」——こうした流れが完全に染みついていたのです。
ところが、Ballot SC‑80 v3によりメールでの認証が突然使えなくなった。
しかも、変更の事前情報があまり共有されていなかった、
または見過ごされていたことで、業務上の混乱が生まれました。
実際、私たちのチームでもある朝、「証明書の更新をお願いします」といつもの申請をかけたら、「その認証方法はもう使えません」とあっさり拒否されました。まるで、毎朝行っているコーヒーショップが、突然「今日はうちは寿司専門店になりました」と言ってきたような衝撃です。
何が問題だったのかというと、変更そのものよりも、「その変更を前提としていなかった私たちの業務設計」でした。証明書の更新は、リリース工程の中でも最終段階。予定されたサービス公開日も迫っており、関係部署はスケジュール通りに進めている。でもそこで、認証方法が使えないと分かった瞬間、すべてがストップするのです。
しかも、「じゃあ代替方法でやり直します」となったところで、その代替方法がすぐに用意できるとは限りません。Ballot SC‑80 v3が推奨するDNS TXTレコードを使った認証は、DNS設定を即座に変えられる管理体制が前提です。でも、組織によってはDNSの権限を持つ部門が別だったり、外部ベンダーに依頼しなければならなかったりする。ここで数日から1週間のタイムロスが発生します。
結果として、証明書の再発行はも遅れ、サービスの停止も想定しなければならくなりました。
さらに関係者への説明と調整に時間を取られ、本当に目まぐるしい日々でした。
ある意味、この混乱は「仕様変更」そのものではなく、「その変更を前提にしていなかった私たちの無意識の前提依存」に起因していたのです。
この出来事を振り返ると、笑ってしまう部分もあります。
メールでの確認が通らず、焦ってサポートに問い合わせたら、「TXTレコードを設定して再申請してください」とさらっと言われ、「知らないよ！なにそれ？」と言いながら色々なところに問い合わせしながら対応しました。
しかしこれは、冗談では済まされない教訓でもあります。業務の中で“常識”だと思っていた手法や前提は、決定ひとつで簡単に変わる。特にインフラ系の仕組みは、表面上は静かに見えて、実は激しく流動している世界なのです。
そしてこの教訓は、今後さらに加速する「自動化」「ゼロトラスト」「分散認証」の時代において、一層重要になっていくはずです。
Ballot SC‑80 v3とは何か？
CA/Bフォーラムの概要
まず、「Ballot SC‑80 v3」の意味を理解するには、そもそもこれを策定した**CA/Bフォーラム（CA/Browser Forum）**について知っておく必要があります。
CA/Bフォーラムとは、インターネット上で使われるSSL/TLS証明書のルールや運用方針を定める国際的な業界団体です。「CA（Certificate Authority）」＝証明書を発行する認証局と、「Browser」＝ChromeやFirefox、Safariといったブラウザベンダーが参加しています。
このフォーラムでは、セキュリティに関わる重要な方針や技術仕様を、参加メンバーの投票によって決定しています。その投票を「Ballot（バロット）」と呼び、SC-80はそのうちの一つです。
つまりBallot SC‑80 v3は、「SSL/TLS証明書の発行プロセスにおいて、どのようにドメイン所有者の確認（Domain Control Validation, DCV）を行うべきか」というルールの改定案であり、投票によって正式に採択されたものです。
Ballot SC‑80 v3の主な内容と背景
このBallotが問題視したのは、WHOIS情報に基づいたドメイン認証手法の信頼性の低下です。従来、多くの証明書発行では、WHOISデータベースに登録されているドメイン所有者のメールアドレスに対して確認メールを送り、クリックされたら「所有者が確認した」とみなす方式が使われてきました。
ところが、近年この方法にいくつかの問題が生じていました。
- WHOISの情報精度が下がった（GDPRの影響で非公開が増加）
- メールアドレスが不正確またはスパム対策で届かないことがある
- WHOIS自体がセキュリティの観点から時代遅れになりつつある
これらの理由により、CA/Bフォーラムでは「WHOISに依存するのはやめよう」と議論されるようになり、最終的にBallot SC‑80として正式に廃止が決定されたようです。
（なお、v3とは第3版であり、内容調整を経た最新版の案という意味です。）
WHOISの終焉とDCV手法の転換
Ballot SC‑80 v3では、WHOISを使った以下のDCV方法を廃止することが明記されています
- WHOIS登録メールアドレス宛の確認メール送信
- WHOISに記載された電話番号・ファックス番号による確認
- WHOISに基づく郵送認証
代わりに推奨されているのが、より確実で自動化しやすいやり方で、以下の方法があります。
- DNS TXTレコードの設定
- 特定ファイルをWebサーバーに配置
- ACMEプロトコルなどの自動認証方式
この転換によって、証明書の申請・更新の仕組みが大きく変わることになりました。技術的な適応が必要となるのはもちろん、業務フロー全体を見直す必要が出てきた組織も少なくありません。
Ballot、以下のスケジュールで段階的に適用されます：
Ballot SC‑80 v3のスケジュール
2025年1月15日 WHOIS利用によるDCV方法の新規使用を制限
2025年7月15日 WHOISベースのDCV完全廃止
この記事を書いているのは７月３日。。。つまり、ギリギリまで対応していました。
教訓 ― 「いつものやり方」はもう武器にならない
「前と同じやり方で、今回はうまくいく」
この安心感に頼って、私たちは日々の業務を回しています。ルーティンを確立し、マニュアル化し、安定運用を実現してきた。それ自体は素晴らしいことです。けれども、それは前提が変わらなければという条件付きの安定に過ぎません。
Ballot SC‑80 v3の件は、それを見事に打ち砕いてくれました。「WHOISでドメイン認証できるはず」「あのメールに返信すれば証明書が発行される」——そうした“いつものやり方”が、ある日突然使えなくなったのです。
今や、業務は 「変化を前提に設計」しなければ脆弱なものになるという時代に突入しています。
「インフラの変更」は想像以上に深刻
インフラというと、ネットワークや電気、水道といったイメージが強いかもしれませんが、ここでの「インフラ」は業務を支える技術的・制度的な土台全体を指します。SSL/TLS証明書の取得に関する仕様も、まさにその一部です。
インフラの変更が深刻なのは、表面上は“変わっていないように見える”ことにあります。ドメインは同じ。申請画面も似ている。関係者も従来どおり。でも実際は、裏で動いている仕組みが根本的に変わっていて、「前と同じ操作」をした結果、思わぬエラーや遅延が起きるのです。
しかもその変更は、法改正のように一斉に大々的に発表されるわけではありません。静かに、でも確実に進行します。今回のように、CA/Bフォーラムの投票結果で仕様が変わり、半年後には実施。知っている者だけが対応でき、知らなかった者は現場で混乱する。これが、現実です。
“変化耐性”をどう育てるか
今回の一件で強く感じたのは、「マニュアル通りに動ける人材」だけでは変化に耐えられない という現実です。むしろ、そのマニュアルがなぜそうなっているのかを理解しようとせずに手順だけをなぞる人ほど、変化に弱く、組織にリスクをもたらすことがあります。
実際、証明書の更新作業においても「前回と同じ操作をすれば大丈夫」という思い込みが大きな混乱を招きました。マニュアル通りにやっているのに、突然エラーが出る。焦って問い合わせると「その手法はもう使えません」と言われ、手順の土台が変わっていたことに初めて気づく。これは決して他人事ではありません。
重要なのは、「マニュアルのどの部分が変化しうるのか」を見極める力です。たとえば、「この操作は外部のルールに依存しているから将来変更されるかもしれない」「この画面表示はシステムアップデートで変わるかもしれない」といった可能性を普段から意識する必要があります。
さらに、そもそもなぜそのマニュアルがそう設計されているのか、どのような前提や技術的背景があるのかを理解していなければ、変更が起きたときに自分で判断することができません。前提技術の推移や規格の変遷に対して、一定のアンテナを張る姿勢が求められます。
特に、年次や四半期ごとといった長周期の定型業務においては、手順が固定化されがちです。記憶やマニュアルへの依存が強くなり、「去年と同じようにやればいい」という発想に陥りやすい。しかし、まさにそのような場面こそ、柔軟性が求められます。「前提が変わっている可能性がある」「今の手順は本当に有効か？」と、立ち止まって検証する姿勢が、結果的に業務全体を救うのです。
変化に素早く対応するためには、日常的な情報収集が欠かせません。
しかし現実には、技術動向や業界規格の変更といった情報は分かりづらく、社内で共有されにくいという課題もあります。だからこそ、「自分の業務そのものに興味を持つこと」、そしてその背景となる仕組みやルールに好奇心を持って学び続けることが、変化に強い人材になるために重要なことではないかと強く感じる出来事でした。
要は、ただ「やり方を覚える」のではなく、「なぜそうするのか」を理解し、「どう変わる可能性があるか」を想定する力。そして、規格や技術革新があり、状況変化したときに自ら対応策を考え、最適な手順を再構成し、動ける力。それこそが、これからの業務に不可欠な“変化耐性”なのだと感じました。
今回の出来事は、そのことを身をもって感じさせてくれました。