自治体・官公庁向けソリューション
自治体、官公庁、独立行政法人、そして自治体向けにサービスを提供する事業者の皆様。
行政のデジタル化が進むほど、システムの「遅延」は窓口業務の停滞を、「ダウンタイム」は行政サービスの停止を、そして自治体を騙る「なりすまし」は住民への直接の金銭被害を意味します。
Spelldataは、行政に求められる可用性・性能・セキュリティを、統計的品質管理と実測データで満たします。
各技術が「何を防ぎ、何を防がないか」を仕様の原典に基づいて明示し、その上で複数の層を組み合わせて全体の防御を構成するのが、私達の提案の特徴です。
ガイドラインと「三層の対策」の枠組みの中で
自治体の情報セキュリティ対策は、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」（年度ごとに改定）と、マイナンバー利用事務系・LGWAN接続系・インターネット接続系を分離する「三層の対策」を前提に構築されています。
私達の提案は、この枠組みを崩しません。
マイナンバー利用事務系とLGWAN接続系には触れず、インターネット接続系の公開資産（住民向けサイト、電子申請、予約システム）と、委託事業者・指定管理者との接続の統制に対象を絞ります。
Spelldataは、ご提案の際に、各ソリューションがガイドラインのどの対策項目（送信ドメイン認証、外部委託管理、可用性の確保、機器・ドメインの管理など）の裏付けになるかを整理してお示しします。
導入支援・技術サポートはすべて国内で内製し、再委託を行わないため、委託先管理の観点でも評価が容易です。
6つの防御層
メールの入口からネットワークの深部まで、6つの層で行政のデジタル基盤を防御します。
第1層：住民を狙うなりすましの遮断（DMARC / BIMI）
偽の給付金案内、偽の納税催告、偽の子育て支援の申請案内。
自治体を騙るメールの被害者は、行政からの連絡を疑わない住民そのものであり、高齢の方も多く含まれます。
「不審なメールにご注意ください」という広報だけでは、住民の資産は守れません。
技術的に「偽物を届かなくする」対策が必要です。
MailData (PowerDMARC)により、DMARCポリシーの「p=reject（拒否）」への移行を支援します。
DMARC（RFC 9989、2026年5月に旧RFC 7489を置き換えた最新仕様）は、貴団体の正規ドメインおよびそのサブドメインを直接騙るなりすましメールを認証で判別し、受信箱に届く前に排除します。
一方、仕様上、類似ドメイン（cousin domain）や表示名の偽装、SMSによるなりすまし（スミッシング）は電子メールの認証技術の対象外です。
lg.jpドメインだけでなく、事業ごとに取得された独自ドメインも含めた全ドメインの棚卸しと認証整備が、対策の土台になります。
第2層：TLS証明書「47日ルール」への対応（証明書管理の自動化）
TLS証明書の手動運用は、2029年に破綻します。
CA/Browser Forumの決定（Ballot SC-081）により、証明書の最大有効期間は2026年3月から200日、2027年3月から100日、2029年3月15日以降は47日へと段階的に短縮されます。
ドメイン認証情報の再利用期間も最終的に10日まで短縮されるため、47日時代には証明書1枚あたり年8回前後の更新が必要になります。
本庁サイト、電子申請、施設予約、観光・移住促進サイト、事業ごとの特設サイトと、自治体が管理する証明書は部署をまたいで散在しがちで、更新漏れの1枚が「申請ページの証明書エラー」として住民の手続きを直接妨げます。
世界標準のDigiCertにより、ACMEによる発行・更新の自動化と、棚卸し・期限監視を含む証明書ライフサイクル管理を導入し、単年度の担当者交代にも耐える運用体制を構築します。
証明書の透明性（Certificate Transparency）ログの監視と組み合わせることで、貴団体ドメインを対象とした証明書の不正発行も検知できます。
BIMIに必要なVMC（認証マーク証明書）の発行にも対応し、第1層のなりすまし対策と連動します。
第3層：電子申請・予約のピーク耐性とドメインの防御的管理
給付金の申請開始、ワクチンや健診の予約開始、入試や採用の出願期限。
行政のアクセスは締切と開始日に集中し、その瞬間に落ちれば、電話と窓口に住民が殺到します。
CloudflareとGcoreの大規模エッジネットワークで悪意あるトラフィックを吸収し、申請・予約のピークの最中でも受付を継続させます。
予約が殺到する場面には、Cloudflare Waiting Room（Businessプラン以上）で仮想待合室を設け、エラー画面の代わりに待ち状況を表示して、リロード連打による負荷増と住民の不安を抑えられます。
DNSSEC（RFC 4033～RFC 4035）によりDNS応答に電子署名を付与し、検証を行うリゾルバーを経由した名前解決で、応答の改ざんを検出できるようにします。
DNSSECが提供するのはDNSデータの出所認証と完全性保証であり、DoS対策や通信の秘匿は提供しません。
そして、忘れてはならないのがドメインの出口管理です。
事業終了後に手放された自治体のキャンペーンドメインが第三者に取得され、悪用される事案が繰り返されています。
事業ごとの独自ドメインは、終了後も登録を保持した上で、SPFの「-all」、DMARCの「p=reject」、null MXによる「送信しないドメインの防御」を設定し、なりすましへの悪用を技術的に封じることを提案します。
第4層：実ユーザー視点の品質監視（住民向けサイトと庁内・出先機関）
「サーバ室の監視モニターは正常だが、窓口からは繋がらない」。
このような乖離は、ISPやキャリア網の障害で頻繁に起こります。
SpeedDataは、全国7都市（札幌・仙台・新潟・東京・名古屋・大阪・福岡）の計測センターから、実際の住民が使う回線（NTT/KDDIの固定回線、4キャリアの5G回線）で24時間365日計測します。
サーバ内部からではなく、住民と同じ経路で観測するため、キャリア網やISPに起因する障害も検知できます。
監視の対象は、公開サイトだけではありません。
本庁と支所・出先機関・公共施設の間の通信も、拠点内に計測ノードを設置することで、経路・遅延・損失を常時計測できます。
業務システムへの拠点からのアクセス品質を定量化し、「支所から遅い」という現場の体感を、拠点側・回線・センター側のどこに原因があるのか実測データで切り分けます。
計測値は平均値ではなくパーセンタイルで管理し、遅延の分布と外れ値を統計的に分析することで、一時的な揺らぎと恒常的な品質劣化を切り分けます。
第三者検証可能な実測データは、委託事業者のSLA評価や、議会・住民への説明の裏付けとしても活用できます。
第5層：表示速度のSLA保証（Web高速化）
電子申請、施設予約、ごみの分別検索、防災情報。
行政サイトが遅ければ、住民はWebでの手続きを諦めて電話と窓口に戻り、行政側のコストと住民の負担が同時に増えます。
高齢の住民が多い地域ほど、「速くて迷わない」ことがデジタル化の定着率を左右します。
「速くなったはず」という感覚ではなく、計測データで保証された速度が必要です。
PerfDataは、サーバの計算処理、ネットワーク処理、フロントエンド処理まで包括し、全体最適化でWebサイトやWebアプリケーションを高速化します。
中核となるのは計算処理の高速化です。
計算量の削減、計算処理の並列化、処理順序の変更によって計算待ち時間そのものを減らすため、設定変更にとどまる一般的な高速化とは到達点が異なります。
表示開始0.5秒以内、表示完了1秒以内を98パーセンタイルで達成し、この品質を契約上のSLAとして保証します。
達成状況は第4層の実測データで継続的に検証するため、導入後の品質劣化も見逃しません。
第6層：委託事業者接続の統制と非公開システムの隠蔽化
行政システムの運用は、委託事業者・指定管理者による外部からのアクセスなしには成立しません。
そのアクセス経路が公開されたVPN機器であれば、そこが攻撃対象領域になります。
Tailscaleを導入し、インターネット接続系の管理系システムへの外部からのポート開放を不要にします。
認証されたデバイス以外からはサービスに到達できず、ポートスキャンでも発見されないため、攻撃対象領域を大幅に縮小します。
三層の対策の枠組みは崩さず、対象はインターネット接続系と委託事業者との接続に絞ります。
「どの事業者が、どのシステムに到達できるか」をACLで定義できるため、委託先ごとの過剰な到達性を解消します。
SSHも例外ではなく、Tailscale SSHによりSSHポートの公開と公開鍵の配布・管理を廃止し、tailnetのデバイス認証とアクセス制御に一元化できます。
Enterpriseプランでは、委託事業者によるリモート保守を含む特権アクセスのSSHセッションを録画して監査証跡として保存でき、外部委託管理の統制を、運用ルールへの依存ではなく技術で担保できます。
第3層のエッジ防御と組み合わせることで、「公開資産はエッジで吸収し、非公開資産は隠蔽する」という二層の防御を構成します。
公共分野での導入実績
Spelldataは、大手企業を中心に350社以上へサービスを提供してきました。
そのうち、自治体・官公庁・公的機関のご契約実績は5団体です（2026年8月10日時点）。
自治体向けにサービスを提供する事業者様の支援を通じた、間接的なお役立ちの実績も多数あります。
公共分野で一番ご導入頂いているサービスは、DMARC分析サービスの「MailData」です。
早期にp=rejectを達成し、BIMI・VMCの実装まで到達した支援実績を多数持つことが、弊社の強みです。
メール認証は「推奨」から「送信者要件」へ
給付金の案内、納税の通知、防災・広報のお知らせ。
住民への大量配信を行う自治体も、メール送信者要件の当事者です。
Gmailはメール送信者のガイドラインで、2024年2月1日以降、1日5,000件を超える送信者にSPF・DKIM両方の設定とDMARCの設定を必須化しました。
Outlookも2025年5月5日から、1日5,000通以上の送信者に同様の要件の適用を開始しています。
さらに総務省は「フィッシングメール対策の強化に関する要請」（2025年9月）で、電気通信事業者に対してDMARCポリシーに基づく処理（隔離・拒否）の設定を求めており、受信側のメールインフラは認証されないメールの排除へと動いています。
要件を満たさなければ、なりすまされる前に、まず貴団体の正規の通知が住民に届かなくなります。
BIMIでロゴを表示するには、DMARCを強制ポリシー（quarantineまたはreject）まで引き上げることが仕様上の要件であり、なりすましメールを受信箱に届けない実効性を持つのはp=rejectです。
DMARC分析は、DNSレコードと受信側から届くレポートの分析で完結します。
庁内システムには一切触れず、三層の対策にも影響しないため、単独の委託として調達できます。
まずはDMARC分析から、弊社の実力を確認してください。