自社AI診断ツールを実装監査して見つけた13箇所の数値不一致と修正記録

なぜ自社ツールを実装監査したのか

ローンチして1週間が経った頃、SEGOの診断結果に小さな違和感を覚えるようになりました。最初は「PSIの計測が不安定なのかな」と思っていたのですが、よく観察すると同じURLを診断しても結果がわずかに変わるケースがあることに気付きました。

数値の振れ幅自体は大きくありません。総合スコアで2〜3点、カテゴリ別スコアで5点程度の差です。しかし、SEOコンサルティングの根拠データとして使うツールが、再現性に問題を抱えているのは致命的です。クライアントに「先週のスコアと今週のスコアが違うのはなぜですか」と聞かれた時、明確に答えられなければ信頼を失います。

この違和感を放置すれば、ユーザーはいずれ気付きます。ユーザーから指摘される前に、自分で気付いて直す。これが開発者としての最低限の責任だと考えました。AI時代だからこそ、ツールが出す数値の根拠を説明できることが、コンサルタントとして信頼される条件だと感じています。

監査は grep でコードベースを調査することから始めました。「同じURLで結果が変わるなら、評価ロジックのどこかに矛盾があるはずだ」という仮説で、重み配分やスコア計算の関連ファイルを横断的に検索しました。
すると、想定以上に深い構造的な問題が見えてきました。

発見した3つの構造的負債

監査の結果、3つの構造的な問題が見つかりました。いずれも単純なバグではなく、設計時の判断が時間と共に技術的負債として顕在化したものでした。

課題1：重みの二重管理問題

SEGOは複数のサイトタイプ（コーポレート・メディア・ECなど）に応じて、評価の重み配分を変えています。サイトタイプ × 評価カテゴリのマトリクスで重み定義を持っていたのですが、この重みが2つのファイルで別々に定義されていました。

本来であれば「重みの定義は1箇所に集約する」のが正しい設計です。しかし、ローンチを急ぐ過程で、評価ロジックと総合スコア計算が別々のファイルで実装され、それぞれが独自に重み定義を持つ状態になっていました。当然ながら、2つのファイルの値は微妙に違っていました。

grep で確認したところ、サイトタイプ × カテゴリのマトリクスのうち13箇所で値の不一致が発生していました。これが「同じURLで結果が変わる」原因でした。診断のたびにどちらのファイルの値が使われるかが微妙に異なるため、結果に揺らぎが出ていたのです。

課題2：PSI失敗時の偽データ問題

UXカテゴリの評価には、Google PageSpeed Insights API（以下PSI）を使っています。ところが、PSIは比較的失敗しやすいAPIで、サイトの構成によっては計測に失敗することがあります。

監査前のSEGOは、PSI計測に失敗した場合、UXスコアを「0点」として扱っていました。これは技術的には「データがないから0」というロジックですが、ユーザーから見れば「あなたのサイトのUXは0点です」と表示されるのと同じことです。実際は計測できなかっただけなのに、サイトが致命的に悪いという誤解を生む表示でした。

さらに業界比較画面では「あなたのUX 0点 vs 業界平均 32.8点」のように表示されていました。計測失敗を「サイトの欠陥」と読み替えて表示してしまう、これは誠実なツール開発の対極にあります。

課題3：業界比較での誤解を招く表示

業界比較画面には「7項目中X項目で業界平均を上回る」というサマリー表示があります。ところが、PSI失敗で計測できなかった項目も、自動的に「平均を下回る」項目としてカウントされていました。

例えばPSIが失敗してUXが0点になっていた場合、本来は「計測失敗」とすべきところを「UXは平均を下回る」と評価していました。計測できなかった項目を不利に扱う設計は、ユーザーへの説明責任を欠いた状態でした。

Single Source of Truth化という解決策

3つの課題のうち、最も根が深かったのは「重みの二重管理」でした。これを解決するために採用した設計思想が、Single Source of Truth（信頼できる唯一の情報源）です。

Single Source of Truth は、データの定義を1箇所だけに集約し、そのデータを必要とする全てのコードがその1箇所を参照するようにする設計思想です。データの整合性を技術的に強制できるため、人為的なミスを防げます。

具体的には、共通の定数ファイルを新規作成し、サイトタイプ別の重み配分を全てそこに定義しました。評価ロジック側と総合スコア計算側は、両方ともこの共通ファイルから値を import するようにしました。これで「重みを変えたいときは1箇所だけ書き換えればよい」という状態になり、不一致が構造的に発生しなくなりました。

さらに、合計値が必ず100になることを検証する関数も併せて実装しました。誤って合計が99や101になった場合は、ビルド時に検出できる仕組みです。SEGOの診断ロジック全体についてはSEGOの診断スコアはどう計算されるのかで解説しています。

「計測失敗」を誠実に表示する設計

PSI失敗時の偽データ問題は、技術的な修正だけでなくUI設計の判断でもありました。「データがないときに何を表示するか」は、ツールの誠実さが現れる部分です。

修正後の設計では、PSI計測に失敗した場合は「N/A」「計測失敗」「再診断推奨」と明確に表示するようにしました。「あなたのサイトは0点」という誤解を生む表示を完全に廃止し、ユーザーに状況を正しく伝えるUIにしました。

さらに、業界比較サマリーの計算からも計測失敗項目を除外しました。「7項目中X項目で業界平均を上回る」というサマリーは、計測できた項目のみで分母を再計算するようにしました。これで「計測できなかったから不利になる」という不公平を解消できました。

診断ツールにとって「データがない」と「データが悪い」は本質的に違うものです。この区別をUIで明確に伝えることが、ユーザーへの説明責任の第一歩だと考えています。

監査前後で変わった3つのこと

4日間で8件のコミットによる修正を経て、SEGOは大きく3つの点で変わりました。

1つ目は同じURLで安定した結果が出るようになったことです。重みの不一致がなくなったため、診断のたびに微妙に値が変わる現象が解消されました。SEOコンサルティングの根拠データとして使うときも、「先週と今週で違うのはなぜ」と説明する必要がなくなりました。

2つ目は「測れなかった項目」を堂々と表示できるようになったことです。PSI失敗時に「N/A」「計測失敗」と表示することで、ユーザーは状況を正しく理解できます。コンサルティングの場面でも「ここは現時点で計測できていないので、別の方法で確認しましょう」と次のアクションを提案できます。

3つ目はコンサル契約の根拠データとして説明可能になったことです。クライアントに診断結果を見せながら「この数値はこういうロジックで算出されており、計測できなかった項目はこのように扱っています」と説明できる状態になりました。診断結果の活用についてはSEGOの使い方で詳しく解説しています。

AI時代のツール開発で大切にしていること

監査を通じて改めて感じたのは、「動くこと」と「正しいこと」は別物だということです。SEGOはローンチ時点で確かに「動いて」いました。診断結果は表示され、ユーザーはツールを使えていました。しかし「正しい」とは言い切れない部分が残っていました。

AI/SaaS の世界では、ローンチを急ぐためにこの違いが見過ごされがちです。とにかく動くものをリリースして、後から改善する。アジャイル開発の文脈では正しいアプローチですが、数値を出力するツールの場合、その数値の正確性に責任を負う必要があります。誤った数値が出続けると、ユーザーは知らないうちに誤った判断をすることになります。

ユーザーへの説明責任とは、「ツールが何をしているか、ユーザーに正確に伝える義務」です。これは派手な機能追加よりも地味な作業ですが、信頼の基盤になります。AI検索時代では、ツールの透明性そのものが差別化要素になります。SEGO独自の調査では、Web運営者74名のうち43.8%が「効果予測や根拠の提示」を求めていることが明らかになっています。詳細はWeb運営者74名調査を参照してください。

AIツールの多くがここまで踏み込まないのは、「不一致を見つけても、ユーザーが気付かない範囲なら直さなくていい」という判断が働くからかもしれません。しかし、ツールを開発する側の私たちは「気付かれていない問題」こそ最も誠実に向き合うべきだと考えています。
ユーザーから指摘される前に直す。これが結果としてツールの信頼性を高め、長期的なユーザーの維持につながります。

自社AIツールを実装監査するときのポイントまとめ

自社のAIツールやSaaSを開発している方が、同様の実装監査を行うときのポイントを整理します。

• 違和感を放置しない：ローンチ後の小さな違和感は、構造的な問題のサインであることが多い
• grepで横断調査：仮説を立てて、コードベース全体で関連する箇所を洗い出す
• Single Source of Truth化：同じデータが複数箇所で定義されている状態は、必ず不一致を生む
• 「データがない」と「データが悪い」を区別する：UI設計で明確に伝える
• 整合性チェックを自動化する：人手では再発する。コードで検証する仕組みを作る
• 修正の経緯を記録する：コミットメッセージや本記事のような形で残しておく

監査は派手な仕事ではありませんが、ツールの長期的な信頼性を支える根幹の作業です。AI/SaaS 開発者の方は、ローンチして1〜2週間経った頃に意識的に時間を取って実装監査をすることを推奨します。

AIツールの実装監査に関するよくある質問

なぜlaunch直後にこれだけの不一致が見つかったのですか

ローンチを急ぐ過程で、評価ロジックと総合スコア計算が並行して実装され、それぞれが独自にデータ定義を持つ状態になっていたためです。設計レビューを経ずに統合された結果、データの一元管理が失われていました。多くのSaaS開発で起こりがちなパターンであり、特に少人数で開発するスタートアップでは構造的な問題として顕在化しやすいと考えています。

ユーザーから指摘される前に気付けた理由は何ですか

自分でツールを使っていたためです。SEGOを開発者として作るだけでなく、SEOコンサルタントとして実際にクライアントワークで使っていました。「同じURLで結果が違う」という違和感は、開発時のテスト環境では気付きにくく、実際の運用の中で発見されました。「自分で使うツールを作る」ことの重要性を改めて認識した経験です。

他のSEOツールも同様の問題を抱えているのでしょうか

個別のツールを評価する立場にはありませんが、AI診断系のツール一般に言えるのは、評価ロジックの透明性を公開しているツールは少ないということです。SEGOがこうした実装監査の記録を公開することで、業界全体の透明性向上に少しでも貢献できればと考えています。ツール選定時は、診断ロジックや改善履歴を公開しているかどうかを参考にすることを推奨します。

監査をどのくらいの頻度で行うべきですか

SaaSプロダクトの場合、ローンチ後1〜2週間で1回目の監査を実施することを推奨します。ローンチ時には気付かない構造的な問題が、実際の利用データから見えてきます。その後は四半期に1回、または重要な機能追加の前後で監査を行うのが目安です。SEGOでも今後、定期的な実装監査を継続していく予定です。

このような取り組みは、ユーザーにどう伝わりますか

診断ツールの信頼性は、表面的な機能の数や派手なUIではなく、出力する数値の正確性で決まります。実装監査の記録を公開することで、ツールの品質に対する誠実な姿勢が伝わります。SEGOでは継続的に診断ロジックの改善を行っており、その過程を本ブログで公開していく予定です。診断ロジックの全体像についてはSEGOの診断スコアはどう計算されるのかを参照してください。

SEGOで無料診断を試す