NDAで実績を隠す会社はAIの候補に載らない｜システム開発会社のAI検索対策

発注側の「開発会社探し」は、検索エンジンで一覧を眺める作業から、AIに相談して候補を絞ってもらう作業へ移りつつあります。「製造業の生産管理システムを刷新したい。おすすめの開発会社は？」とChatGPTやGeminiに聞けば、AIは条件に合いそうな会社を数社挙げ、理由まで添えて返します。

結論を先に言います。この場面でシステム開発会社・SIerが候補に挙がるかどうかを分けるのは、営業力でも広告費でもなく、「この会社は何が得意で、どんな開発をしてきたか」をAIが読み取れる形でサイトに書いてあるかです。NDA（秘密保持契約）を理由に実績をほぼ非公開にし、「あらゆる業種・あらゆる技術に対応します」とだけ書いてある会社は、人間の営業では戦えても、AIの回答生成では判断材料ゼロとして扱われます。AIは推薦文を書くとき、根拠にできる記述がない会社を挙げようがないからです。

この記事では、受託開発・SIerという業態に特化して、AI検索（ChatGPT検索・Google AI Overview・AIモード・Perplexityなど）で候補に挙がるための情報設計を、チェックリスト・判断表・失敗例つきで解説します。SaaS事業者（自社プロダクトを売る会社）の対策は業態が異なるため、BtoB SaaSのLLMO対策を参照してください。

システム開発会社のAI検索対策とは（定義）

システム開発会社のAI検索対策とは、「◯◯業向けのシステム開発が得意な会社は」「この要件を頼める開発会社は」といったAIへの相談に対して、自社が候補として名前と根拠つきで挙がる状態をつくるための情報設計のことです。 具体的には、(1) 開発実績を公開可能な粒度で構造化して掲載する、(2) 得意領域・技術スタック・開発体制を明文化する、(3) 会社情報を第三者ソースと一致させる、(4) AIクローラーがサイトを読める技術状態を保つ、という4領域の実装を指します。LLMO対策・AIO対策・GEO対策と呼ばれる施策群の、受託開発業態への適用版です。

LLMO対策全体の考え方は、ピラー記事のLLMO対策とはで整理しています。この記事はその業種別の各論です。

なぜ「発注先探し」がAI相談になっているのか

発注側の行動が変わった

システム開発の発注は典型的な高関与・低頻度の意思決定です。発注担当者の多くは開発会社選びの経験が少なく、比較軸すら持っていません。この「何を基準に選べばいいか分からない」状態は、AIチャットに丸ごと相談するのに最も向いた場面です。

• 「基幹システムのリプレイスを頼める会社の選び方を教えて」
• 「Laravelで社内業務システムを作れる、中堅規模の開発会社を挙げて」
• 「◯◯（社名）という開発会社の評判と得意領域は？」

1つ目は選定基準の相談、2つ目は候補出しの依頼、3つ目は指名検索の代替です。従来は「システム開発会社 おすすめ」で比較メディアを読んでいた行動が、対話に置き換わっています。そしてAIの回答には、比較メディアのように広告枠がありません。AIが参照できたテキストの質だけで、挙がる会社が決まります。

AI側の仕組みも「特別な裏技」を要求していない

Googleは公式ドキュメントで、AI Overview（AIによる概要）やAIモードに向けた特別な最適化・専用マークアップは不要であり、通常の検索と同じく、インデックス可能でスニペット表示が許可され、ページ品質の基本要件を満たすことが前提だと明記しています。同時に、要件を満たしても表示が保証されるわけではないことも明記されています。つまり「AI検索対策」の実体は魔法のタグ設置ではなく、AIが引用・要約しやすい形に自社情報を書き直すコンテンツ実装です。

ChatGPT側も同様で、OpenAIは検索用クローラー「OAI-SearchBot」を公開しており、robots.txtでこれを拒否したサイトはChatGPT検索の回答に表示されないと説明しています。学習用の「GPTBot」とは別のクローラーであり、「学習には使わせたくないがChatGPT検索には出たい」という制御も可能です。受託開発会社のコーポレートサイトなら、少なくともOAI-SearchBotは許可しておくのが基本線です（設定の詳細はrobots.txtのAIクローラー設定を参照）。

受託開発・SIerがAI検索で不利になりやすい3つの構造要因

対策の前に、なぜこの業態が特に弱いのかを押さえます。原因が構造的だからこそ、直した会社との差がつきます。

要因1：NDAで実績が書けない（と思い込んでいる）

受託開発の成果物はクライアントの資産であり、社名も内容も出せない案件が多いのは事実です。その結果、実績ページが「大手製造業様 基幹システム開発」の一行だけ、あるいは実績ページ自体が存在しない会社が珍しくありません。

しかしAIの視点では、「実績が非公開」と「実績がない」は区別できません。書かれていないものは存在しないのと同じです。ここで重要なのは、NDAが禁じているのは通常「顧客を特定できる情報」であって、「案件の抽象度を上げた記述」まで一律に禁じているわけではないことです。「従業員500名規模の食品製造業向けに、生産計画と在庫管理を統合するシステムを再構築。レガシーなオンプレ環境からクラウドへ移行」という記述は、社名ゼロでもAIにとって十分な判断材料になります（掲載可否は必ず契約条項と顧客の意向を個別に確認してください。この線引きの考え方は後述の判断表にまとめます）。

要因2：「何でもできます」がAIには「何も言っていない」に変換される

SIerの営業戦略として、間口を広く見せるために「業種・規模を問わず対応」「要件定義から運用保守までワンストップ」と書くのは定石でした。人間の営業プロセスでは、間口を広げて商談に持ち込み、商談の中で得意領域を語れます。

AI検索にはこの二段構えがありません。AIが「製造業の生産管理に強い開発会社」を探すとき、照合するのはサイト上のテキストです。「全業種対応」としか書いていない会社は、どの業種の質問に対しても弱い一致しか示せず、「製造業×生産管理」と明記した会社に毎回負けます。総花的な記述は、すべての具体的な質問に対する候補落ちを意味します。

要因3：第三者ソースに情報が少ない

AIはコーポレートサイトだけを見て回答しているわけではありません。ChatGPTに社名を聞くと、公式サイトに加えて外部データベース、ニュース、口コミなど複数ソースを突き合わせて答えることが確認できます（自社の見え方の確認手順はChatGPTは御社をどう説明しているかで解説しています)。受託開発会社はBtoCブランドと違い、外部で言及される機会がもともと少ない。だからこそ、数少ない外部情報（登記情報系データベース、業界メディア、パートナー認定ページ、採用媒体）と自社サイトの記述が食い違っていると、AIは確信を持てず、その会社への言及自体を避ける方向に働きます。

実装の全体像：4領域チェックリスト

以下が受託開発・SIer向けの実装チェックリストです。上から順に効きます。

領域1：開発実績の構造化（最重要）

• 実績を「業種 × 業務領域 × 技術 × 規模感 × 成果」の粒度で1件ずつ独立したページまたはブロックにする
• 社名非公開案件は「従業員規模＋業種＋課題＋やったこと」の抽象記述で掲載する（契約確認のうえで）
• 実名公開の許可が取れる案件を年1〜2件でも積み上げる（1件の実名事例は10件の匿名事例より強い参照点になる）
• 実績一覧に「対応業種」「対応技術」の絞り込み軸をテキストとして持たせる（タグをJSで描画するだけでなく、HTML上に文字列として存在させる）
• 古い実績を放置しない。技術スタックが現在と乖離した実績は「当時の構成」と明記するか整理する

領域2：得意領域・体制・進め方の明文化

• 「得意領域」ページを独立させ、対応できる業種・業務・技術を優先順位つきで宣言する（全部並列にしない）
• 技術スタック（言語・フレームワーク・クラウド・DB）を一覧化し、それぞれの経験の厚みを言葉で補足する
• 開発体制（ラボ型/請負/準委任、チーム構成、PM体制）と進め方（アジャイル/ウォーターフォール、コミュニケーション頻度）を明文化する
• 契約形態と費用レンジの考え方を説明する。金額を出せないなら「見積もりの構成要素」だけでも書く（料金情報の設計は料金ページのAI検索設計が使えます）
• 「よくある質問」を発注担当者の実際の質問（最低契約期間、保守だけの依頼可否、途中参画の可否、瑕疵対応）で構成する

領域3：エンティティ（会社の同一性）情報の整合

• 会社概要ページに、社名・所在地・設立・資本金・代表者・従業員数・主要取引先区分・保有認証（ISMS、プライバシーマーク等）を明記する
• 外部データベース・パートナー認定ページ（クラウドベンダー認定等）・採用媒体の会社情報を自社サイトと一致させる
• 代表者・主要エンジニアの登壇、技術ブログ、OSS活動など「この会社に実在の技術者がいる」証拠を公式サイトから辿れるようにする
• AIが自社を間違って説明している場合の対処はAIが会社情報を間違えるときの直し方を参照

領域4：技術面の下ごしらえ

• robots.txtでOAI-SearchBot・Google拡張クローラーをブロックしていないか確認する
• 実績・サービスページがJS描画依存になっていないか、HTMLソースの段階でテキストが存在するか確認する
• 構造化データはページに表示されているテキストと一致する範囲で実装する（Googleは表示テキストとの一致を求めており、AI向けの特別なマークアップは不要と明言しています）
• 効果測定の土台として、AI経由流入をGA4でのAI検索流入計測の手順で分離しておく

判断表：NDA案件をどこまで書けるか

実績公開の可否は「全公開 or 全非公開」の二択ではありません。公開レベルを段階で設計します。

多くの受託開発会社は、レベル5または4に留まっています。目標は、全案件をレベル3まで引き上げ、年に数件をレベル1に押し上げることです。 レベル1の交渉は、検収完了直後や保守契約更新のタイミングが通りやすい、というのが実務上の定石です（成功を保証するものではありません）。

「得意領域の宣言」を書く手順

チェックリスト領域2の中核である得意領域ページは、次の3ステップで書けます。

ステップ1：過去3年の案件を棚卸しする。 業種・業務領域・技術・契約形態で分類し、件数と継続率が高いセグメントを特定します。感覚ではなく受注実績で決めるのがポイントです。

ステップ2：上位2〜3セグメントを「主戦場」として宣言する。 「当社は製造業・物流業の基幹業務システム、特に生産管理・在庫管理・WMS領域の開発を主力としています」のように、業種と業務領域を掛け合わせた一文で言い切ります。この一文は、AIが回答を組み立てる際にそのまま引用できる「自己定義文」として機能します。

ステップ3：主戦場以外を「対応可能」として区別して書く。 全部を主力と書かないことが、主力の記述を信じてもらう条件です。「上記以外の業種・領域もご相談いただけますが、主力領域では要件定義の初期段階から業務知識を持って参画できます」のように濃淡をつけます。

なお、発注者が最終的に見るのは複数社の比較です。自社サイト内に「開発会社を比較する際の観点」を表形式で提供しておくと、その表自体がAIの回答素材になりえます。表の設計方法はAIに引用される比較表の作り方で詳しく解説しています。

よくある失敗例

失敗例1：実績ページを作ったが、全部PDFやスライド画像

営業資料の流用で、実績を画像スライドやPDFダウンロードとして置いているケースです。AIクローラーが安定して読み取れるのはHTML上のテキストです。実績は必ずHTMLの本文として書き、PDFは補助資料の位置づけにします。

失敗例2：「DX支援」「伴走型」など抽象語で埋める

「DX推進を伴走型で支援」という記述は、どの業種のどんな相談に対しても決定打になりません。AIへの質問は「◯◯業の△△システムを頼めるか」という具体形で来ます。抽象的なスローガンは、具体的な業種・業務・技術の記述に置き換えるか、少なくとも併記します。

失敗例3：技術ブログはあるのに会社の得意領域と接続していない

エンジニア採用向けの技術ブログが活発でも、記事が個々の技術Tipsに閉じていて、「この会社は何の開発が得意か」という文脈に繋がっていないケースです。ブログ記事から関連する実績ページ・得意領域ページへ内部リンクを張り、著者情報（所属・役割）を明記するだけで、記事群が会社のエンティティ情報を補強する資産に変わります。

失敗例4：比較メディアへの掲載だけで満足する

「システム開発会社 おすすめ」系の比較メディアに掲載料を払って載る施策自体は否定しません。ただしAIは複数ソースを突き合わせるため、比較メディアに載っている情報と自社サイトの情報が薄い・古い・食い違う状態だと、掲載効果は減衰します。第三者ソースの露出は、自社サイトの一次情報が整っていて初めて効きます。引用元としてのソース設計はAI検索における引用の仕組みも参照してください。

失敗例5：効果測定をせず「問い合わせが増えた気がする」で終わる

AI検索対策は、従来の順位計測だけでは効果が見えません。最低限、(1) GA4でChatGPT・Perplexity等からの参照流入を分離する、(2) 主要な想定質問（「◯◯業 システム開発 会社」等）を月次で複数のAIに投げ、自社が挙がるか・どう説明されるかを記録する、の2点を運用に組み込みます。問い合わせフォームに「何で当社を知ったか」の選択肢として「ChatGPTなどのAI」を加えるのも、簡単ですが有効な計測手段です。

FAQ：システム開発会社のAI検索対策でよくある質問

対策をすれば必ずAIの回答に載りますか

載りません。Googleも、要件を満たしてもAI機能への表示は保証されないと明言しています。AI検索対策は「候補に挙がる確率を上げるための情報整備」であり、掲載を保証する施策は存在しません。「必ず引用される」と約束する業者には注意してください。

NDAが厳しく、匿名でも実績を書けない場合はどうすればいいですか

実績の代わりに「得意領域の宣言」「技術スタックと経験の厚みの記述」「開発プロセスの詳細な説明」「技術ブログと著者情報」でエンティティを補強します。また、新規契約時に事例公開条項（匿名レベルでの公開可否）を織り込む交渉を営業プロセスに組み込むと、時間はかかりますが資産が貯まり始めます。

SEOで上位表示できていれば、AI検索対策は不要ですか

前提は共通ですが、十分ではありません。従来SEOはページ単位の順位を競いますが、AI検索では「会社としての説明可能性」（何が得意で、何をしてきた会社か）が問われます。順位が高くても総花的な記述の会社は、具体的な相談への回答では候補落ちします。両者の違いはSEOとLLMOの違いで整理しています。

自社プロダクト（SaaS）も持っている場合はどちらの対策をすべきですか

両方ですが、ページを分けてください。受託開発は「相談相手として選ばれる」情報設計、SaaSは「製品カテゴリで比較される」情報設計で、必要なコンテンツが異なります。1つのページに混ぜると両方の文脈が薄まります。SaaS側はBtoB SaaSのLLMO対策を参照してください。

効果が出るまでどのくらいかかりますか

案件の状況（既存サイトの状態、実績公開の交渉スピード、外部ソースの整合状況）に依存するため、一律の期間は示せません。確実に言えるのは、実績の構造化とクローラー許可の確認は着手した時点から参照可能性が生まれる一方、AIの回答への反映タイミングは各プラットフォームのクロール・更新に依存し、コントロールできないということです。

まとめ：AIに「紹介する理由」を渡せているか

システム開発会社のAI検索対策は、突き詰めると1つの問いに集約されます。「AIが御社を発注候補として紹介するとき、その根拠になる文章がサイト上に存在するか」です。

• 実績は、匿名でも「業種×業務×技術×規模」の粒度で書かれているか
• 得意領域は、全方位ではなく優先順位つきで宣言されているか
• 会社情報は、外部ソースと矛盾していないか
• AIクローラーは、そもそもサイトを読めるか

この4点を自社で点検するだけでも現在地は把握できます。「AIに自社がどう説明されているか」「競合と比べてどこが弱いか」を第三者視点で確認したい場合は、LLMO診断で現状の可視化から始めることもできます。発注先探しがAI相談に置き換わる流れは、受託開発の営業構造をゆっくり、しかし確実に変えていきます。実績を「隠す資産」から「語れる資産」に変える作業は、早く始めた会社ほど積み上げが効きます。