--- title: "GEO分析ツールでE-E-A-Tを再現可能にスコア化する方法" locale: ja category: ai_data category_name: "AIデータ" translation_status: reviewed license: cc_by author: "Injoys 編集部" source_url: https://injoys.com/ja/articles/geo-eeat-scoring-system-design published_at: 2026-08-26T15:49:11+09:00 --- # GEO分析ツールでE-E-A-Tを再現可能にスコア化する方法 > E-E-A-Tは、Googleが提供する公式スコアでも、生成AIが公開している引用公式でもない。GEO分析ツールでは、LLMにスコアを恣意的に決定させるのではなく、同一のWebスナップショットから検証可能なシグナルを抽出し、ルールとバージョンを固定したコードでスコアと信頼度を計算する必要がある。 ## Key Points - 同一の入力から同一の結果を得るには、Webページのスナップショット、評価ルール、重み、データソースのバージョンをすべて固定する必要がある。 - Experience、Expertise、Authoritativeness、Trustworthinessは、それぞれ異なる証拠に基づいて評価し、特に自己主張と外部検証を分ける必要がある。 - LLMは最終スコアの計算者ではなく、抽出された証拠とコードが算出した結果を説明するという限定的な役割に適している。 - E-E-A-TスコアとAI引用可能性スコアは関連しているものの同一ではないため、別々のモジュールで計算する必要がある。 - スコアだけを公開するのではなく、根拠URL、抽出した文、判定ルール、欠測状態、評価の信頼度も併せて提供する必要がある。 GEO（Generative Engine Optimization）は、ChatGPT、Geminiのような生成AI環境でコンテンツが発見され、回答の根拠として活用される可能性を改善・分析しようとする実務上の概念である。ただし、生成AIサービスが情報源を選択する完全な公式を公開しているわけではなく、GEOに共通して用いられる単一の標準スコアも存在しない。 GoogleのE-E-A-TはExperience、Expertise、Authoritativeness、Trustworthinessを意味するが、GoogleがWebページごとに公開する公式な数値ではない。したがって、分析ツールが表示する「E-E-A-T 78点」はGoogleの判定ではなく、そのツールが定義した観測指標であることを明確に示さなければならない。 ## LLMに直接採点を任せてはいけない理由 Webページ全体をLLMに入力し、経験・専門性・権威性・信頼性をそれぞれ100点満点で評価させれば、素早くプロトタイプを作成できる。しかし、運用向けの測定システムとしては次の問題が生じる。 - 同じコンテンツとプロンプトでも、実行するたびにスコアが変わる可能性がある。 - モデルまたはプロバイダーが変わると、過去のスコアと比較しにくくなる。 - ページに記載されていない経歴、資格、評判を推論するハルシネーションが発生する可能性がある。 - スコアに影響を与えた文章やルールを監査しにくい。 - 外部検証をせずに、サイトの自己紹介を事実として受け入れる可能性がある。 - 長い文書が途中で切れたり、抽出順序が変わったりすると、評価結果も変化する可能性がある。 推奨構成は次のとおりである。 ```text Webサイト → 単一時点のスナップショットを収集 → 本文・メタデータ・エンティティ・主張を抽出 → 外部資料とクロスチェック → バージョンを固定したルールでスコアを計算 → スコア・根拠・信頼度を保存 → LLMが結果を自然言語で説明 ``` LLMを一切使用してはならないという意味ではない。文章分類、主張候補の抽出、名前の表記揺れの探索などに活用できるが、結果を原文の根拠と結び付けてキャッシュする必要がある。最終的な算術計算と上限・減点ルールはコードが担うほうが、再現性と監査可能性を高められる。 ## 最初に定義すべき評価対象と範囲 スコアを計算する前に、何を評価するのかを固定しなければならない。サイト全体、組織、著者、個別文書のシグナルは互いに代替できない。 | 評価単位 | 主な質問 | 代表的な証拠 | |---|---|---| | 文書 | この記事の主張と作成プロセスは信頼できるか？ | 本文、引用、作成日、更新日、実験資料 | | 著者 | このテーマを扱う経験や専門性が確認できるか？ | 著者ページ、資格、経歴、研究・著作歴 | | 組織 | 発行主体が特定され、責任体制があるか？ | 会社概要、連絡先、編集ポリシー、Organizationデータ | | ドメイン | 外部からそのテーマの情報源として認められているか？ | 独立機関による引用、関連バックリンク、報道・学術資料 | | 技術面 | クローラーがコンテンツと出典情報を読み取れるか？ | ステータスコード、robotsポリシー、canonical、HTML、構造化データ | テーマも併せて分類する必要がある。医療・金融・法律のように、誤情報による被害が大きい分野と、個人的な趣味のレビューとでは、求められる専門性および信頼性の証拠が異なる。1つの固定ウェイトをすべての分野に適用すると、スコアの意味が薄れる。 ## 同一のWebスナップショットを収集する方法 分析ツールは、一度保存したスナップショットを共有しなければならない。本文は午前10時、JSON-LDは10時5分、著者ページは10時10分にそれぞれ再リクエストすると、変更後の状態が混在する可能性がある。 スナップショットには、可能であれば次の項目を保存する。 - 最終URL、リダイレクト経路、HTTPステータスコードおよびレスポンスヘッダー - 元のHTMLと、必要な場合はレンダリング済みHTML - 抽出した本文、タイトル、説明、canonicalおよび言語情報 - 著者、公開日、更新日、発行組織 - 内部・外部リンクとアンカーテキスト - JSON-LD、Microdataなどの構造化データ - robots指示、sitemapで確認した関連URL - 収集時刻、収集ツールのバージョン、コンテンツハッシュ 複数のページを探索する際は、ホームページだけに依存しない。sitemap.xmlと内部リンクを利用し、About、Company、Team、Author、Profile、Editorial Policy、Contact、Privacy、Termsのような候補を、制限した深さで探索する。個人情報や利用制限のあるページを無理に収集してはならず、robotsポリシー、利用規約、適用法令も確認する必要がある。 ## オンサイト証拠とオフサイト証拠の分離 オンサイトデータは、そのサイトが直接公開した情報である。著者紹介、製品説明、顧客事例、編集ポリシー、連絡先、Person・Organization構造化データなどがこれに該当する。 オフサイトデータは、独立した外部情報源が著者や組織をどのように確認しているかを示す。政府・公的機関の資料、学術機関、専門団体、信頼できる報道機関、業界資料、外部プロフィール、関連バックリンクと引用などが該当する。 2種類の証拠は、スコア上で区別しなければならない。 - 「業界最高」のような自己宣伝文句は、Authorityの独立した証拠ではない。 - 外部記事であっても、プレスリリースをそのまま転載した資料は独立性が低い。 - 異なるURLに同じ記事が複製されている場合、情報源の数を重複計上しない。 - 同名の別人や別組織の実績を結び付けないよう、エンティティを確認する。 - sameAsリンクはエンティティ候補を結び付ける手がかりであり、その経歴が真実であることを自動的に保証するものではない。 ## Experience：直接経験を証拠に変える Experienceは、著者が製品を使用したり、場所を訪問したり、手順を実行したり、実験を運用したりした直接経験を評価する。Expertiseとは別である。ノートパソコンを長期間使用した購入者は、実際の使用経験が豊富である可能性はあるが、バッテリー工学の専門家とは限らない。 ### 検出すべきシグナル - 直接使用・購入・訪問・設置・運用・比較したという表現 - 使用期間、試験回数、サンプル数、環境と機器 - 実施手順、失敗の過程、制約条件および例外 - 自ら撮影した画像、ログ、元データ、再現手順 - 測定前後の結果と測定方法 「実際に使ってみた」という一文だけで高いスコアを付けると、簡単に操作される。具体的な数値も、それ自体で事実を証明するものではない。測定方法、期間、元データ、文脈が互いに一致する場合に、より強い証拠として扱う必要がある。 経験スコアは、次のように階層化できる。 | レベル | 例 | 処理原則 | |---|---|---| | 弱い | 使用したという宣言のみ存在 | 低い基本スコア | | 普通 | 期間・環境・手順が具体的 | 具体性スコアを追加 | | 強い | 元データ・写真・ログ・比較基準を提供 | 検証可能性スコアを追加 | | 検証済み | 独立資料または再現試験と一致 | クロスチェックのウェイトを適用 | ## Expertise：確認可能な専門性の評価 Expertiseは、そのテーマを正確に扱うための知識と能力があるかを見る。名前の横に「専門家」と表示しただけでは十分ではない。 分析候補は次のとおりである。 - 関連する役職、所属、業務分野および経験年数 - 学位、公認資格、免許と発行機関 - 関連する研究、論文、著書、講義、プロジェクト - テーマと結び付く実際の職務経験 - 専門的な説明の正確性、範囲、限界および出典 - 専門家のレビュアーとレビュー日 著者の値が`admin`、`administrator`、`管理者`、`運営者`、`運営チーム`、`editor`のような役割名である場合、実在する人物として確定しない。Person構造化データがあっても、画面に表示された著者情報と一致するかを確認する。 専門性には、テーマとの適合性を反映しなければならない。弁護士資格は法律コンテンツでは強いシグナルになり得るが、あらゆる医療・技術テーマに関する専門性を自動的に証明するものではない。資格検証が必要な分野では、発行機関または公式の照会資料に結び付けられる場合に検証レベルを高める。 ## Authoritativeness：外部からの評価とエンティティの一致 Authoritativenessは、特定のテーマにおいて、人・組織・サイトが外部からどの程度認められているかを評価する。単純な言及数よりも、情報源の品質、テーマとの関連性、独立性、多様性が重要である。 権威性分析ツールは、次の手順に従うことができる。 1. 組織名、著者名、ドメイン、ブランドの標準エンティティを作成する。 2. 旧名称、英語名、略称のような確認済みの別名を結び付ける。 3. 外部文書内で同一エンティティかどうかを判別する。 4. 情報源の独立性・品質・テーマとの関連性・最新性を評価する。 5. プレスリリースの再配信と同一文書の複製をまとめる。 6. 引用・言及が肯定的な評価なのか、単なる列挙または批判なのかを区別する。 韓国語Webを分析する際に、Wikipedia、Wikidata、Redditと英語圏の報道機関だけを使用すると、韓国内の機関や企業の権威が過小評価される可能性がある。評価対象の市場に応じて、政府・公的機関、公共データ、学術データベース、専門団体、主要報道機関および業界専門メディアをソースレジストリに含める必要がある。反対に、特定の国のポータルに掲載されているというだけで、世界的な権威があると断定してもならない。 ソースレジストリには、管轄地域、発行主体、テーマ範囲、独立性、一次情報源かどうか、更新周期とアクセス条件を記録することが望ましい。国別の情報源を追加する場合でも、スコアルールと選定基準は公開されなければならない。 ## Trustworthiness：最も広範で重要な安全性の軸 Trustworthinessは、残りの3要素を支える。直接経験と資格があっても、虚偽の主張、利益相反の隠蔽、出典の改ざんが確認された場合は、全体評価に上限を適用できる。 信頼性モジュールで確認する項目は次のとおりである。 ### 発行主体と説明責任 - 運営組織と著者が明確に表示されているか - 連絡方法とカスタマーサポート情報が実際のページに存在するか - 編集・監修・訂正ポリシーを確認できるか - 広告、スポンサー、アフィリエイト、利益相反を区別しているか ### 主張と根拠 - 重要な事実に一次情報源または適切な根拠が結び付けられているか - 引用文と統計が原文の趣旨に沿っているか - 公開日・更新日と実際のコンテンツ変更が一致しているか - 事実、意見、広告的な主張が明確に区別されているか - 不確実性、適用範囲、例外と限界を明示しているか ### 取引と安全性 - プライバシーポリシーと利用条件がサービスの性質に合わせて提供されているか - 決済・返金・配送条件が必要なサイトで明確に示されているか - HTTPS、悪意のあるリダイレクト、破損した証明書のような技術的リスクがないか - 健康・金融・法律情報で、危険な断定や保証表現を使用していないか HTTPSやプライバシーポリシーがあるという事実だけで、コンテンツが正確になるわけではない。これらは基本的な安全シグナルであり、主張レベルの信頼性は別途検証しなければならない。 ## 構造化データとエンティティ検証 PersonとOrganizationの構造化データは、名前、所属、役職、公式URL、外部プロフィールとの関係を機械が理解しやすい形で提供する。Articleのauthor、publisher、datePublished、dateModifiedも、文書の出典構造を表現するうえで有用である。 ただし、Schemaマークアップは次の原則に基づいて評価しなければならない。 - 構造化データが画面に表示されるコンテンツと一致するか確認する。 - 存在するという理由だけで、資格・受賞・評判を事実として確定しない。 - Person、Organization、Article間の識別子と関係が一貫しているかを見る。 - sameAsのリンク先が実際の公式プロフィールか確認する。 - 構文エラーと必須・推奨プロパティの欠落を分ける。 - 過剰または無関係なSchemaタイプの使用を加点対象としない。 構造化データは、理解と抽出を支援する表現レイヤーである。検索順位の上昇や生成AIによる引用を保証するものではない。 ## 再現可能なスコア公式の設計 各シグナルを単純に「あり・なし」だけで処理すると、品質の違いを見逃す。次のように値を分ければ、根拠を追跡しやすい。 - `presence`：シグナルの有無または充足度 - `verification`：独立して検証された度合い - `relevance`：評価テーマとの関連性 - `source_quality`：根拠となる情報源の品質と独立性 - `freshness`：最新性が必要なシグナルの有効性 - `weight`：バージョン管理するシグナルの重要度 公式の例は次のとおりである。 ```text シグナル寄与度 = weight × presence × verification × relevance × source_quality × freshness ディメンションスコア = 100 × 寄与度の合計 ÷ 適用可能なweightの合計 ``` この公式は設計例であり、公式のE-E-A-T算式ではない。各係数は0から1の間に正規化できる。論理的に適用されない項目だけを`N/A`として除外し、必要な証拠が見つからなかった状態は0点と区別して`missing`として保存する。 ### スコアとは別に信頼度を表示 78点という結果であっても、必須ページの半分を収集できなかった場合は信頼しにくい。したがって、評価信頼度または証拠カバレッジを別途計算しなければならない。 ```text 評価信頼度 = 収集カバレッジ × エンティティ一致度 × 検証可能な証拠の割合 ``` 結果画面には、少なくとも次の項目を併せて表示する。 - ディメンション別スコアと総合スコア - 評価信頼度 - 確認済み・未確認・不一致・適用除外の状態 - 根拠URLと原文の一部 - 収集時刻とスナップショットハッシュ - ルール・ウェイト・ソースレジストリのバージョン ## GEO総合スコアとE-E-A-Tを分離する E-E-A-Tが高くても、必ずAIの回答で引用されるとは限らない。回答システムは、質問への適合性、情報の抽出しやすさ、最新性、クロール可能性、文書形式なども考慮する可能性があり、具体的な選択方法はサービスごとに異なる。 GEOツールは、次のモジュールを分離するほうがよい。 | モジュール | 分析対象 | |---|---| | コンテンツE-E-A-T | 経験、専門性、外部での権威、信頼性 | | AI引用準備度 | 独立して理解できる文章、質問への適合性、根拠との結び付き、要約可能性 | | ブランド権威 | 外部機関による独立した評価とエンティティの一致 | | 技術的アクセシビリティ | クロール、ステータスコード、canonical、レンダリング、本文へのアクセス | | Schema品質 | 構文、表示コンテンツとの一致、エンティティ関係 | 例えば、AI引用準備度30%、ブランド権威20%、コンテンツE-E-A-T 20%、技術的アクセシビリティ20%、Schema 10%のように構成できる。この比率はあくまでも製品ポリシーの一例である。実際のウェイトは、テーマ別の検証データで補正し、バージョンを表示しなければならない。 AI引用準備度では、短い文章だけを無条件に優先してはならない。重要な主張が独立して理解でき、根拠と条件が近くにあり、表・リスト・見出しの構造が意味を保持しているかを評価する。検索エンジンやAIを欺くための隠しテキスト、反復表現、根拠のない大量のページは、減点またはリスクシグナルとして扱う。 ## モジュール間のエラー伝播を防ぐ構造 各分析ツールが別の分析ツールの結論をそのまま入力として受け取ると、初期エラーが増幅される可能性がある。共有すべきなのは、結論よりも元のスナップショットと正規化された証拠である。 ```text Snapshot Store ├─ Content / Claim Analyzer ├─ Author / Expertise Analyzer ├─ Entity / Authority Analyzer ├─ Trust Analyzer ├─ Technical Analyzer └─ Schema Analyzer ↓ Evidence Store → Deterministic Scorer → Explanation LLM ``` すべての判定レコードには、`claim_id`、`evidence_id`、原文位置、判定ルール、モジュールバージョンを含めることが望ましい。LLMには、計算済みのJSONと許可された根拠文のみを渡し、新たな資格や外部での評判を補足して記述しないよう制約を設ける。 ## 見落とされがちな問題：不確実性と敵対的操作 多くのGEO分析はシグナルの検出に集中するが、サイトが分析ツールを欺こうとする状況には十分に対処していない。この問題は、独立した品質・セキュリティレイヤーとして運用しなければならない。 - 見えない領域に経歴やキーワードを繰り返し挿入できる。 - 偽の著者とPerson構造化データを生成できる。 - 同一のプレスリリースを複数のドメインに配信し、外部からの言及数を水増しできる。 - 存在しない研究、資格、数値を引用できる。 - 更新日だけを更新し、古い記事を最新コンテンツのように表示できる。 - 同姓同名の人物や類似ブランドの権威を誤って結び付けるよう誘導できる。 対処方法には、画面表示内容とマークアップの比較、一次情報源のクラスタリング、資格発行元の検証、コンテンツハッシュに基づく変更検知、エンティティ属性のクロスチェック、異常なリンクパターンの検出がある。重大な不一致が見つかった場合は、単純な減点よりも、全体スコアの上限や手動レビュー状態を適用するほうが安全である。 ## 評価モデルを検証する方法 スコア公式が決定論的であっても、評価の妥当性が自動的に生じるわけではない。次の試験が必要である。 1. **反復性試験：** 同じスナップショットとバージョンで、ビット単位で同一の結果が出るか確認する。 2. **専門家基準セット：** 分野の専門家が独立して示した証拠とシステムの結果を比較する。 3. **評価者間一致度：** 人間の評価者同士でも合意が難しい項目を特定し、ルールを修正する。 4. **攪乱試験：** 著者名、日付、Schemaまたは根拠リンクを削除した際、予想した方向に変化するかを見る。 5. **操作耐性試験：** 隠し文言、偽プロフィール、重複したプレスリリースがスコアを過度に高めないか確認する。 6. **地域バイアス試験：** 言語・国ごとに、同等品質のエンティティが体系的に不利になっていないか測定する。 7. **結果の補正：** 実際の引用観測データを使用する場合は、質問、時点、モデル、位置を併せて記録する。 生成AIの引用結果は、質問の表現やサービスのアップデートによって変わる可能性がある。したがって、実際の引用率を絶対的な正解として使用するよりも、時点が明記された外部検証指標として扱うことが適切である。 ## 運用結果に含めるデータ仕様 人と他のシステムが結果を再検証できるよう、次の構造を提供できる。 ```json { "snapshot_id": "sha256:...", "collected_at": "ISO-8601 timestamp", "scoring_version": "eeat-1.3.0", "scope": "document", "topic_class": "software-review", "scores": { "experience": 72, "expertise": 61, "authoritativeness": 54, "trustworthiness": 80 }, "confidence": 0.74, "evidence": [ { "dimension": "experience", "status": "verified", "source_url": "https://example.invalid/page", "rule_id": "EXP-METHOD-02" } ], "missing": ["independent_author_profile"] } ``` 上記URLは、データ構造を示すための無効なサンプル文字列である。実際の結果には、収集した根拠URLと原文位置を入れなければならない。原文全体を再配布する権利がない場合は、必要な範囲の短い証拠とハッシュ、位置情報のみを保存する。 ## 実装チェックリスト - 評価単位を文書・著者・組織・ドメインに区分する。 - 同じ時点のスナップショットをすべての分析ツールに提供する。 - 自己主張と独立した外部検証を分離する。 - 経験と専門性を別のディメンションとして計算する。 - 国・言語別のAuthorityソースレジストリを管理する。 - 構造化データと画面表示内容の一致を検査する。 - 欠測、不一致、適用除外を異なる状態として保存する。 - スコアと評価信頼度を併せて公開する。 - ウェイトとルールを変更した際はバージョンを上げる。 - LLMによる説明に、根拠外の事実を追加できないよう制限する。 - 操作検出と手動レビューの経路を用意する。 - 実際のAI引用結果を観測する際は、モデル・質問・時点を記録する。 重要なのは、E-E-A-Tを1つの曖昧な印象スコアに圧縮しないことである。検証可能な証拠、適用したルール、不確実性、情報源の系譜を併せて提供してこそ、GEO分析結果が運用上の意思決定と長期比較に使用できるデータとなる。 ## FAQ ### E-E-A-TスコアはGoogleが提供する公式指標ですか？ いいえ。GoogleはE-E-A-Tをコンテンツ品質を理解するための概念として説明していますが、ウェブページごとの公式スコアは公開していません。分析ツールのE-E-A-Tスコアは、そのツールが定義したシグナル、重み、データ範囲に基づく独自の指標です。 ### LLMのtemperatureを0に設定すれば、スコアリングを直接任せてもよいですか？ ばらつきを減らすことはできますが、完全な再現性と事実性を保証するものではありません。モデルのバージョン、入力の切り詰め、システム設定が異なる場合があり、ページにない事実を推論するリスクもあるため、最終的な計算はバージョンを固定したコードで行う方が安全です。 ### ExperienceとExpertiseはなぜ別々に評価する必要があるのですか？ Experienceは実際に使用・訪問・試験・運用した経験であり、Expertiseは関連する知識、経歴、資格、研究能力です。実際の使用経験が豊富なレビュアーが必ずしも技術の専門家であるとは限らず、専門資格を持っていても、その製品を実際に使用したとは限りません。 ### 執筆者が実際に使用したと書いていれば、Experienceスコアを高くしてもよいですか？ 自己申告だけの場合は、弱いシグナルとして扱うのが望ましいです。期間、環境、実施手順、測定方法、生データや自ら作成した資料など、具体的で検証可能な証拠が伴う場合に、より高い重みを適用すべきです。 ### Wikipediaや報道記事がなければ、Authorityは低いのですか？ 必ずしもそうではありません。国や業界によって重要な外部資料は異なります。政府・公共機関、学術機関、専門団体、業界メディアなど、地域や分野に適した独立した情報源も併せて評価する必要があり、プレスリリースの転載は重複を排除しなければなりません。 ### Schemaを多く追加すれば、GEOスコアは高くなりますか？ Schemaの量よりも、正確性と表示されるコンテンツとの整合性が重要です。構造化データはエンティティと文書の関係を理解するのに役立ちますが、検索結果への表示やAIによる引用を保証するものではなく、虚偽または無関係なマークアップは信頼性を損なうリスクがあります。 ### E-E-A-Tが高ければ、ChatGPTやGeminiに必ず引用されますか？ いいえ。各サービスの情報源の選定方法は完全には公開されておらず、質問との適合性、最新性、アクセシビリティ、表現構造など、さまざまな要素が影響する可能性があります。E-E-A-TとAI引用への対応度には関連性がある可能性がありますが、別個のスコアとして管理する必要があります。 ### スコアが同じなら、分析結果の品質も同じだと考えてよいですか？ いいえ。十分な数のページを収集した80点と、資料の半分が欠落した80点とでは意味が異なります。スコアと併せて、収集カバレッジ、エンティティの一致度、検証済みの証拠の割合を反映した評価の信頼度を表示する必要があります。 ### GEOスコアの重みはどのように決めればよいですか？ 初期の重みは明示的な製品ポリシーとして設定しつつ、専門家による基準セット、交絡テスト、操作耐性テスト、実際の観測データによって補正する必要があります。医療、金融、製品レビューのように、トピックのリスクとユーザーの意図が異なる分野には、それぞれ異なるプロファイルが必要です。 ### LLMはGEO分析システムにおいて、どのような役割に適していますか？ 主張の候補の抽出、文の分類、名前の表記揺れの探索、コードが計算した結果の自然言語による説明に活用できます。ただし、すべての結果を原文の証拠に紐付け、最終スコアの計算と上限・減点ルールは決定論的なコードが担うのが望ましいです。 ## Sources - [有用で信頼性の高い、ユーザー第一のコンテンツの作成](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) - [AI機能とウェブサイト](https://developers.google.com/search/docs/appearance/ai-features) - [Google 検索における構造化データ マークアップの概要](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - [サイトマップについて](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview) - [Schema.org Person](https://schema.org/Person) - [Schema.org Organization](https://schema.org/Organization) - [PROV-O：PROVオントロジー](https://www.w3.org/TR/prov-o/) - [GEO：生成エンジン最適化](https://arxiv.org/abs/2311.09735) ## Images ![オフィスで大型タッチスクリーンの分析ダッシュボードを操作する女性](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTIwOTYsInB1ciI6ImJsb2JfaWQifX0=--085c51ba6ec88e1b1f3d7efa109fae3f43e51b14/ai-9f49d198.webp) ![ウェブページのデータを安全なサーバーと4つの評価モジュールで処理し、スコア画面へ送るフロー図](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTIxMDIsInB1ciI6ImJsb2JfaWQifX0=--899ddbc79483c66a1ff40af5062b06b2fc48617a/ai-79b1d31e.webp)