SiteKensa
概要
SiteKensa はサイトとドメインの設定状態を診断し、次にやることを手順として提示する Web サービスです。診断して終わりにせず、利用中のメール基盤と DNS 管理事業者を判定し、どの管理画面のどこに何を追加するかまで案内します。2026年7月25日に開発を開始し、7月28日に公開しました。診断のほかに、事業者別ガイド 36 ページ、メール基盤別ガイド 24 ページ、解説記事 11 本を持ちます。入力したドメイン名はサーバーに保存しません。
解決したい課題
既存の診断ツールは結果の表示で止まり、DKIM のセレクタは利用者が知っている前提で入力を求めます。レコードをどこに追加するかは DNS 管理事業者側で決まるのに、その案内もありません。さらに、レコードを追加した直後は再帰リゾルバのキャッシュで「設定されていません」と返ることがあり、設定漏れと伝播待ちの区別が付かないままになります。
主な機能
- MX と SPF から利用中のメール基盤を判定し、そのサービスの既定 DKIM セレクタを自動で試す
- NS から DNS 管理事業者を判定し、管理画面のどこで設定するかと事業者固有のつまずきを案内
- SPF・DKIM・DMARC を横断して、単独では正常に見える相互矛盾を検出
- 権威ネームサーバーと再帰リゾルバを比較し、設定漏れと伝播待ちを区別
- SSL 証明書・HTTPS への統一・セキュリティヘッダー・robots.txt まで、サイト側の設定もあわせて診断
- SPF / DMARC / DKIM / MX の項目別ページと、9 事業者ぶんの実画面つき設定ガイドから入れる
- 判定できない値はプレースホルダのまま示し、推測した設定値を断定しない
技術スタック
アーキテクチャ
診断ロジックはランタイム非依存のコアと、Node 前提の実装（権威ネームサーバーへの直接問い合わせ、TLS 証明書、HTTP とセキュリティヘッダーの診断）に分離しています。DNS 解決は DoH で行い、Google と Cloudflare をフォールバック関係で使います。診断 API は Lambda の Function URL、サイトは Next.js の静的書き出しを S3 + CloudFront + ACM で配信し、インフラは AWS CDK で定義しています。データベースは持ちません。診断対象のドメインは保存せず、レート制限に使う接続元 IP はソルト付きハッシュで扱います。Function URL は AWS_IAM 認証にして CloudFront 経由だけを通し、Lambda の予約済み同時実行数を課金の上限として使っています。レート制限はリクエスト数ではなく外部通信量に比例した重みで数え、修正してから再診断する反復が制限に当たらないようにしています。
AIの役割と担当範囲
診断の判定に LLM は使いません。誤警告を 1 件も出さないことを基準に置いており、根拠を RFC の該当箇所と実ドメインでの実測に限る必要があるためです。推測で数値や事業者の挙動を書かない規約はリポジトリに明文化しています。AI が担うのは実装、記事構成の検討、レビューなど、制作プロセス側の作業です。判定ロジックには入りません。AI を外しても診断結果は変わらず、品質は診断コアの 280 件のテストと、新しい所見ごとに実ドメイン 20〜30 件で診断を実行する確認で担保しています。
評価・運用
公開直後のため検索流入はこれから積み上がる段階です。基準は誤警告を 1 件も出さないことに置いています。新しい所見を追加するたびに実ドメイン 20〜30 件で流して誤検知を確認し、見つけた誤警告は修正と回帰テストをセットで入れています。診断コアのテストは 280 件で、main への push は診断コア・フロントエンド・インフラの 3 つが揃って通ったときだけ配信され、配信後に本番の API と全 URL を叩いて確かめます。DKIM セレクタは実ドメインで実証できたサービスだけを断定に使い、根拠のない固定値を足すとテストが落ちるようにしています。自ドメインの設定も自分の診断で継続的に確認しています。