情シスは何を見る？脆弱性診断会社のAI検索設計

相見積もりの会議で、情シス担当者が複数社のページを並べても、診断対象、診断方式、費用単位、成果物、再診の項目がそろわないことがあります。「A社はWeb診断、B社はEDR運用、C社はインシデント対応まで可能」という説明だけでは、同じ土俵で比べられないからです。2026年10月現在、セキュリティ会社のLLMO対策は、AI検索向けの特別な裏技ではなく、これらの項目をサービス別・対象規模別に検証できる形で公開することから始まります。

Google Search CentralのAI最適化ガイドも、Google検索の生成AI機能への掲載に特別な構造化データやllms.txtは不要であり、通常のSEO、独自で有用な内容、クロール可能な技術構造が基礎だと説明しています。要件を満たしてもクロール、インデックス、表示は保証されません。2026年10月4日時点で公式情報を確認しました。したがって、LLMO対策の目的は「AIに必ず推薦させること」ではなく、情シスが尋ねる条件に対して、公開ページから正確な回答を組み立てられる状態をつくることです。

定義：セキュリティ会社のLLMO対策とは、脆弱性診断、監視・運用、EDR導入支援、教育、インシデント対応などをサービスごとに分け、対象資産、対象企業規模、診断・支援の方法、費用の決まり方、納品物、準拠基準、担当体制、更新日を公開し、AI検索と人の双方が比較・照合できるようにする情報設計です。実施してもAI回答への引用や掲載を保証するものではありません。

この記事は、セキュリティ会社や脆弱性診断会社のWeb担当者が、受注導線に必要なページと項目を決めるための実務ガイドです。AIクローラーの制御やログ解析ではなく、「脆弱性診断 会社 費用」「セキュリティ 診断 中小企業」「EDR 導入 支援」と尋ねる発注者に、何をどう示すかへ範囲を絞ります。

情シスの質問をページ単位の答えに変える

AI検索では、社名を知らない利用者が「ECサイトの脆弱性診断を頼める会社」「中小企業向けにEDRの選定から運用まで支援する会社」のように、課題と条件を一度に入力します。このときトップページに「サイバーセキュリティを総合支援」とだけ書いても、どの条件に合う会社か判断できません。

最初に、問い合わせ前に聞かれる質問と、回答を置くページを一対一に近づけます。1ページですべてを説明するのではなく、サービス詳細、料金、報告書サンプル、会社情報、事例、FAQをつなぎます。

重要なのは、「対応可能」という形容ではなく、対象と条件を名詞で置くことです。たとえば「幅広いクラウドに対応」ではなく、「AWS、Microsoft Azure、Google Cloudの設定診断。対象サービスは見積もり時に確定」と書きます。対応実績のない製品名や、契約上公開できない顧客名を足す必要はありません。

費用を一律公開できない場合も、空欄にする必要はありません。最低料金、1URL・1画面・1IP・1人日・1台などの課金単位、認証後画面やAPI追加時の扱い、緊急対応の有無を示します。詳しい設計は料金ページのAI検索設計で確認できます。

似ているサービスを同じ箱に入れない

「セキュリティ診断」という言葉は、簡易な自己診断からWebアプリの手動診断、ペネトレーションテスト、組織監査まで指し得ます。これらを1ページで「診断」と総称すると、検索者もAIも、対象、目的、成果物の違いを判断しにくくなります。

経済産業省の情報セキュリティサービス基準第4.1版では、情報セキュリティ監査、脆弱性診断、ペネトレーションテスト、デジタルフォレンジック、セキュリティ監視・運用、機器検証を区別しています。自社のメニュー名をこの名称へ無理に合わせる必要はありませんが、少なくとも異なる目的のサービスを分ける基準として使えます。

サービス一覧ページは、この分類を短く示すハブにします。各詳細ページでは「このサービスがすること」と同じ強さで「しないこと」も書きます。脆弱性診断ページなら、24時間監視を含むか、修正作業を含むか、インシデント発生中の緊急対応に切り替えられるかを明記します。

2026年10月1日最終更新のIPA「情報セキュリティサービス基準適合サービスリスト」は、登録台帳に載るサービスを種別ごとに公開し、ペネトレーションテストを脆弱性診断のオプションサービスとして扱っています。一方、同リストへの掲載はIPAによる事業者やサービスの保証ではないという免責も明記されています。自社が掲載対象ならサービス名と有効期間を正確に示し、掲載されていないのに「IPA認定」と誤認させる表現は避けます。

比較候補から外れやすい7つの失敗

1. すべてを「総合セキュリティ支援」でまとめる

診断、監視、EDR、教育、事故対応の目的が混ざり、検索者が必要なサービスを判断できません。サービス一覧で違いを示し、詳細ページを分けます。

2. 費用を「お問い合わせ」だけで終える

正式見積もりが個別でも、課金単位と変動要因は説明できます。最低発注条件や見積もりに必要な情報がなければ、予算に合うか判断できません。

3. 準拠基準の名前だけを並べる

OWASP、CVSS、CISなどを列挙しても、どの診断・報告に使うか不明です。版と適用範囲を書き、使っていない基準は載せません。

4. 報告書を「詳細」とだけ表現する

経営向け要約、技術的な再現情報、修正案、報告会、再診結果の有無を示します。匿名サンプルを公開し、機密情報は除きます。

5. EDRを「導入すれば安全」と説明する

EDRの導入は、すべての攻撃の検出や被害防止を保証しません。対象端末、設定、監視体制、アラート対応、隔離・復旧の分担を説明します。

6. 資格者数やツール数を品質の保証にする

資格やツールは判断材料の一部です。診断範囲、レビュー、誤検知確認、報告、再診という工程と結び付けます。人数を出す場合は基準日も必要です。

7. AI向けの特別記法だけを先に入れる

Googleは、Google検索の生成AI機能に特別な構造化データは不要と説明しています。まず通常検索でクロール・インデックス可能にし、人が比較に使える固有情報を整えます。実装要件を満たしても、同機能での表示は保証されません。

脆弱性診断ページは4軸で具体化する

脆弱性診断のページは、対象、方式、成果物、費用単位の4軸をそろえると比較しやすくなります。検索者が知りたいのは「高品質です」という自己評価ではなく、自社のシステムが対象に入り、必要な深さで調べてもらえ、社内で修正判断に使える報告が届くかです。

対象は資産名と数え方まで書く

「Webアプリケーション診断」に加え、公開画面、認証後画面、管理画面、API、サブドメイン、クラウド設定、IPアドレス、モバイルアプリなどを分けます。料金や工数を画面数、機能数、リクエスト数、IP数のどれで数えるかも説明します。

対象数を顧客が数えにくい場合は、「ログイン、検索、購入、ファイルアップロードをそれぞれ1機能として数える」など、見積もり前の数え方の例を置きます。実際の定義が案件ごとに異なるなら、その旨と確認手順を書けば十分です。

診断方式はツール名より人の確認範囲を書く

ツール診断、手動診断、両方を組み合わせるハイブリッド診断の違いを説明します。製品名の列挙だけでは、認証・認可、ビジネスロジック、権限昇格、誤検知の精査を人がどこまで行うのか分かりません。

「自動スキャン後に専門家がすべて確認」と書くなら、何を確認するか、例外は何かを続けます。診断中の負荷、テストデータ、送信メール、決済処理、本番環境への影響も、事前調整事項として示します。

費用は総額だけでなく変動要因を出す

公開できるのが「個別見積もり」だけでも、費用が変わる条件は公開できます。対象機能数、IP数、認証ユーザー数、API数、診断環境、本番・検証環境の別、実施時間帯、報告会、再診回数、特急対応が代表例です。

安価なプランと標準プランを並べる場合は、手動確認、報告書、報告会、再診の有無を同じ行順で比較します。価格改定日と税込・税別も明記します。古いPDFと現行HTMLで金額が違う状態は解消し、更新できない資料には対象時点を表示します。

納品物は受け取った後の行動まで示す

報告書、速報、報告会、再診結果が、いつ、どの形式で、誰向けに届くかを書きます。発見事項の一覧だけでなく、開発者が修正できる再現条件と推奨対策、経営者が優先順位を判断できる要約の有無が重要です。

中小企業向けは診断とEDRを分けて案内する

中小企業の担当者は、専任のセキュリティ人材がいない状態で「診断を頼むべきか、EDRを入れるべきか、監視を外注すべきか」を同時に検討することがあります。ここで全部を「セキュリティ対策パック」としてまとめると、何のリスクに何をするサービスか分かりません。

2026年9月30日に第4.0版へ更新されたIPA「中小企業の情報セキュリティ対策ガイドライン」は、個人事業主や小規模事業者を含む中小企業を対象とし、経営者向けの指針と実践手順を示しています。同版ではEDRを、端末に侵入したウイルスやランサムウェアなどの攻撃を検出し、管理者に通知する技術として説明しています。

EDRは継続的な検知・対応を支える技術であり、特定時点のWebアプリやネットワークの弱点を洗い出す脆弱性診断の代わりではありません。逆に、脆弱性診断を一度実施しても、その後の端末監視や事故対応体制が自動的に整うわけではありません。

中小企業向けページには、専門用語の定義に加え、「社内の誰が運用するか」を書きます。EDR製品を導入して終わりなのか、アラートの一次判定、端末隔離、調査、ベンダー連絡まで支援するのかで、必要な社内工数は大きく変わります。

また、最低契約台数、最低契約期間、初期費用、月額に含む問い合わせ回数、現地対応の有無を公開します。具体的な金額を出せない場合でも、見積もりに必要な「端末台数、OS、拠点、既存製品、監視時間、社内担当者の有無」をフォームの前に示せば、問い合わせの行き違いを減らせます。

報告書サンプルは安全なHTML要約も用意する

脆弱性診断会社の品質は、診断項目の多さだけでなく、発見事項を修正判断へ変換できるかで評価されます。ところが、報告書サンプルがダウンロードフォームの内側にだけあり、公開ページには「分かりやすい報告書を納品」としか書かれていないケースがあります。これではAI検索にも、初回比較中の情シスにも中身が伝わりません。

OWASP Web Security Testing Guide v4.2のReportingは、スコープ、制約、実施期間、経営向け要約、発見事項、修正方法などを報告書の構成要素として示しています。これは唯一の正解ではありませんが、公開サンプルの抜けを確認する基準になります。

経済産業省の情報セキュリティサービスにおける技術及び品質の確保に資する取組の例示では、脆弱性診断について、ツール出力を分析したうえで診断結果を報告書にまとめ、報告会を行う例を示しています。目的・対象範囲・制約、結果の根拠、影響と発生可能性、合理的かつ実現可能な推奨事項、読者別のセクションは、同資料のペネトレーションテスト向け試験実施報告書の項目です。脆弱性診断のサンプルへ応用するときは区分の違いを明記し、実際に提供する内容を優先します。

PDFを公開する場合も、同じ内容の要約をHTMLで置き、PDFの版、公開日、対象サービスを添えます。フォーム入力後にだけ渡す完全版と、誰でも読める匿名サンプルを分けても構いません。NDAで顧客名を出せないときの事例設計は、システム開発会社のAI検索対策の考え方も参考になります。

脆弱性の技術的な深刻度をCVSSで示す場合は、版と評価方法を明記します。FIRSTのCVSS v4.0仕様は、Base、Threat、Environmental、Supplementalの各指標を定義し、スコアとベクトル文字列を併記するよう求めています。CVSSは技術的な深刻度を伝える枠組みであり、顧客固有の事業影響や修正優先度を単独で決めるものではありません。報告書サンプルでも「CVSSが高い順に直せばよい」と単純化せず、資産の重要性、露出、悪用状況、代替策を別項目で説明します。

基準・資格・体制は照合できる形で示す

セキュリティ領域では、根拠のない「専門家集団」「世界最高水準」が信頼を下げます。法人情報、サービス品質、担当者の専門性、外部基準を別々に示し、読む側が出典を照合できるようにします。

法人情報をページ間で一致させる

正式社名、所在地、代表者、問い合わせ先、プライバシーポリシー、サービス提供主体を、会社概要、フッター、サービスページ、構造化データで一致させます。グループ会社が販売し、別法人が診断する場合は、契約主体と実施主体を分けて書きます。

会社情報が複数ページで食い違う場合は、まず元データを決めて修正します。点検項目はChatGPT検索で会社情報を正しく伝えるためのサイト整備チェックリストにも整理しています。

資格は保有者数より役割との関係を書く

資格名、人数、基準日を正確に出せる場合は有用ですが、資格の保有だけで個別サービスの品質を保証するものではありません。「診断責任者がレビューする」「重大な発見事項は別担当者が再現確認する」など、品質管理の工程と結び付けます。

担当者紹介では、得意領域、実務上の役割、執筆・登壇・コミュニティ活動、確認できる外部プロフィールを載せます。顧客名や脆弱性の詳細を無断で公開せず、公開許諾を得た情報だけを使います。

準拠基準は版と適用範囲を書く

「OWASP準拠」とだけ書かず、どの文書・版を、診断項目、報告、開発助言のどこに使うか説明します。CVSS、OWASP WSTG、OWASP ASVS、CIS Benchmarks、各クラウド事業者のベストプラクティスなどは目的が異なります。

認証、認定、登録、準拠、参照は同じ意味ではありません。公的リストや第三者認証への掲載を示すときは、正式名称、サービス名、登録番号、有効期限、確認先URLを記載します。審査対象が法人全体ではなく特定サービスなら、その範囲を明記します。

更新責任者と基準日を出す

セキュリティ基準や製品対応OSは変わります。料金、対象、対応製品、基準、資格者数、受付時間には更新日を設け、変更履歴を残します。「2026年対応」のような年号だけでなく、何を確認し、何が変わったかを短く記載します。

よくある質問

脆弱性診断会社を選ぶときは何を比較すべきですか？

対象資産、手動・自動の範囲、費用単位、報告書、再診、対象外、担当体制を同じ順番で比較します。会社規模や有名さだけでなく、自社のWeb、API、クラウド、ネットワークが診断範囲に入るかを先に確認してください。

脆弱性診断の費用をサイトに出せない場合はどう書きますか？

最低料金を出せない場合も、画面数、機能数、IP数、人日などの見積もり単位と、料金が変わる条件を公開します。見積もりに必要な資料、標準で含む報告会や再診、追加料金になる項目も示すと、問い合わせ前に条件をそろえられます。

中小企業向けページには何が必要ですか？

専門用語の説明に加え、最低契約規模、社内担当者に必要な作業、初期設定後の運用分担、問い合わせ先を示します。脆弱性診断、EDR、監視、インシデント対応を別サービスとして説明し、何から始めるか迷う企業向けには現状評価の入口を用意します。

脆弱性診断とEDR導入支援はどう違いますか？

脆弱性診断は、Webアプリやサーバーなどの弱点を一定の範囲・時点で調べるサービスです。EDRは端末上の挙動を継続的に検知し、調査・対応につなげる仕組みです。目的が異なるため、片方を導入すればもう片方が不要になるとは限りません。

報告書サンプルを公開すると危険ではありませんか？

実在顧客のURL、IP、認証情報、未修正の脆弱性、個人情報を除いた匿名サンプルなら、構成と説明品質を示せます。完全版を公開する必要はなく、目的、スコープ、制約、発見事項の書式、修正案、再診結果の表し方を架空例で見せる方法があります。

サービス詳細から問い合わせまでをつなぐ

良いページがあっても、孤立していれば比較中の読者は必要情報へ移れません。サービス一覧を入口にし、診断対象、料金、報告書、事例、会社情報、FAQ、問い合わせを往復できるようにします。

おすすめの基本構造は次の通りです。

1. サービス一覧：診断、監視、教育、インシデント対応の違いを示す
2. サービス詳細：対象、方式、成果物、制約を示す
3. 料金：課金単位、変動要因、含むものを示す
4. 報告書サンプル：受領後に判断できる内容を示す
5. 事例：対象規模、課題、範囲、成果物を匿名化して示す
6. 会社・担当体制：法人、責任者、品質管理、外部基準を示す
7. FAQ：問い合わせ前の条件を一問一答で示す
8. 問い合わせ：見積もりに必要な項目と安全な連絡方法を示す

事例は「大手企業の診断を支援」だけでは足りません。業種を公開できなくても、従業員規模、対象資産、診断機能数、実施環境、支援範囲、納品物、公開可能な学びを示せます。導入事例ページの書き方と構造を使い、実在案件の事実と架空の説明例を混ぜないようにします。

問い合わせフォームでは、脆弱性の詳細や認証情報を書かせません。希望サービス、対象資産の種類、おおよその規模、希望時期、NDA要否、返信先までにとどめ、機密情報の受け渡し方法は受付後に案内します。緊急インシデント用の窓口がある場合は、通常見積もりのフォームと分けます。

AI検索向けだからといって、同じ説明を地域名や製品名だけ変えて大量に複製する必要はありません。サービスごとの元ページを決め、重複ページは統合します。検索意図ごとにページを分ける場合も、それぞれに固有の対象、判断表、事例、FAQがあるかを確認します。

実装前後に確認するチェックリスト

以下は、セキュリティ会社のサイトを公開前または更新時に点検する項目です。すべてを一度に増やすのではなく、事実を確認できるページから整えます。

サービスと対象

• 診断、ペネトレーションテスト、監視、EDR、教育、インシデント対応を分けた
• 各サービスに対象資産と対象外を記載した
• 対象規模を画面数、機能数、IP数、端末数などで説明した
• 本番・検証環境、認証後画面、APIの扱いを書いた
• サービス間の代替関係と併用関係を説明した

費用と成果物

• 最低料金または見積もり単位を示した
• 税区分、価格基準日、追加費用の条件を示した
• 速報、報告書、報告会、再診の有無を示した
• 報告書サンプルをHTMLで要約した
• 再診の期限、回数、追加料金、対象を示した

根拠と安全性

• 参照基準の正式名称、版、適用範囲を示した
• 認証・登録・認定・準拠を区別した
• 担当者の役割と品質レビュー工程を示した
• 顧客名、診断結果、脆弱性情報の公開許諾を確認した
• サンプルからURL、IP、認証情報、個人情報を除いた

AI検索と通常検索の基礎

• 重要情報を画像やPDFだけに閉じずHTMLにも置いた
• ページがHTTP 200で公開され、noindexや認証で遮断されていないことを確認した
• titleとH1がページ内容を正確に表している
• 会社情報とサービス提供主体が全ページで一致している
• 更新日を自動で変えるのではなく、変更内容と合わせて更新した
• サービス詳細、料金、報告書、事例、FAQ、問い合わせを内部リンクで接続した

技術実装だけを点検したい場合は、LLMO診断チェックリストも使えます。ただし、構造化データやllms.txtだけを追加しても、対象、費用、報告書、根拠が欠けたサービスページの説明不足は解消しません。

結論

セキュリティ会社のLLMO対策は、技術用語を増やすことではありません。診断、監視、EDR、教育、インシデント対応を分け、各サービスの対象、規模、方式、費用単位、成果物、制約、根拠を、情シスが照合できる形で公開することが中心です。

最初に直すなら、脆弱性診断ページへ「対象・方式・費用の決まり方・報告書・再診」の5項目を追加し、料金、サンプル、会社情報、FAQへ内部リンクをつなぎます。そのうえでクロール可否、ページ間の矛盾、古いPDF、問い合わせ導線を確認します。

自社サイトのどこで説明が途切れているか判断しにくい場合は、LLMO診断・AI検索診断で、サービス分類、比較項目、会社情報、内部リンク、更新状態をまとめて点検できます。AI回答への掲載を約束するものではなく、まずは公開情報の欠落と矛盾を特定するための診断です。