


どのAIエージェントのツールでも動く、SEO調査のスキル一式を作る
1つのSEO調査スキル一式を、いくつものAIエージェントのツールで使いたい時に使う。スキルのおおもとを1つに保ち、質問ごとに合う調べ方へ振り分け、APIキーをファイルに書かず、ツールごとに動くか試す。
このAIルールを使うには
## どのツールでも読める書き方で、各スキルを1か所に書く
すべての調査スキルを、プラットフォームに依存しない正本ソースとして作成します。中核契約は、対象となるすべてのエージェント環境が解釈できる機能に限定します。
各スキル定義には次の項目を必須とします。
- 安定した名前と明確な説明。
- ホストが対応する場合に限った、任意のモデル宣言とツール宣言。
- 本文に記載された完全な運用指示。
- 明示的な入力、出力、制約、失敗条件。
プラットフォーム固有の制御機能は、任意の拡張として扱います。互換性検査では、移植可能なスキル自体を拒否する必要はないものの、ホストが拡張を無視する可能性がある場合に警告を出します。
生成されたプラットフォーム別の複製ではなく、正本ソースを編集します。メタデータの欠落や未対応の構文を早い段階で不合格にできるよう、パッケージ化や配布の前にすべてのスキル定義を検証します。
## AIエージェントのツールごとに、指示とスキルを読む場所を調べる
各対象環境がプロジェクト指示と再利用可能なスキルを検出する方法を整理します。一般的な方式には、ルート指示ファイル、専用ルールディレクトリ、ネイティブスキルフォルダ、生成済みディスパッチャー、文書へのフォールバックがあります。
各ホストについて次を記録します。
- セッション開始時に自動で読み込まれるファイル。
- 再利用可能なスキルをコピー、リンク、またはインストールする場所。
- 有効化が自動か、明示的なコマンドを必要とするか。
- 委任に未対応の場合にインライン実行へ切り替える方法。
- 最終的な代替手段となるプロジェクト文書。
1つのインストール配置がすべての環境で機能すると仮定してはいけません。意味上の正本を1つに保ちながら、検出、有効化、パッケージ化をホストの検証済み動作に合わせます。
## 手順はふつうの操作で書き、ツールごとの名前に置きかえる
読み取り、書き込み、編集、コマンド実行、ファイル一覧、テキスト検索、Webコンテンツ取得などの中立的な操作を使って手順を記述します。
これらの操作と各ホストのツール名を対応付けた、検証済みの互換表を維持します。ホストが自動対応付けに対応する場合は、アダプターに別名を変換させます。機能が利用できない場合は、その手順を黙って省くのではなく、文書化された代替手段を定義します。
ツール変換と調査ロジックを分離します。ページ分析手順では、特定ベンダーのツール名に依存せず、保護された取得処理とHTML解析処理が必要であることを示します。
ホストのツールインターフェースが変わるたびに対応表を見直します。名前が似ているだけで互換性を主張せず、対応付けた操作を実際に試します。
## 小さな入口のスキルが、使う調査スキルだけを選んで読む
小さなオーケストレーターで依頼を分類し、関連する機能だけを読み込みます。詳細な分析ロジックは、1つの巨大な指示ファイルではなく、目的を絞ったモジュールに置きます。
システムを次の要素に分離します。
- ワークフローを選択するルーティングスキル。
- 完全な分析基準を備えた、目的別の調査スキル。
- 独立作業や並列作業に使う任意の専門エージェント。
- 決定論的な実行を担うローカルスクリプト。
- 構造化された検索メタデータ用のスキーマテンプレート。
- ホスト固有のパッケージ化を担うアダプター。
- 任意の提供元や高コストな機能に対応する拡張。
拡張は中核の依存経路から外します。拡張がなくても基礎的な調査を壊さず、任意の調査範囲だけが狭まるようにします。
## 質問ごとに、いちばん範囲の小さいSEOチェックを選ぶ
調査上の問いに答えられる最小範囲の機能を選びます。
- 広範な問題発見と優先順位付けには、サイト全体の監査を使う。
- 1つのURLを詳しく調べるには、単一ページ分析を使う。
- クロール可能性、インデックス登録、パフォーマンス、関連インフラには、技術分析を使う。
- 品質、信頼性、専門性、経験のシグナルには、コンテンツ分析を使う。
- 検出、検証、生成には、構造化データ分析を使う。
- XMLの網羅性と生成には、サイトマップ分析を使う。
- ページ上のメタデータ、検索結果での視認性、ファイル最適化には、画像分析を使う。
- 生成AI検索での視認性と回答エンジン最適化には、AI検索分析を使う。
発見事項が複数の機能境界をまたぐ場合に限り、より広範な監査へ拡大します。すべての外部主張について、元のURL、証拠の出所、観測時刻、不確実性を保持します。
## SEOの計画は分けて扱い、変化は最初の記録と比べて追う
戦略計画、意味に基づくキーワードクラスタリング、検索体験分析、コンテンツ設計には、それぞれ独立したワークフローを用意します。これらの計画タスクを技術診断へ統合してはいけません。
監視状態を明示します。
1. 安定したベースラインを取得する。
2. 後の観測結果をそのベースラインと比較する。
3. 履歴を保持し、繰り返される変化と一時的なノイズを区別できるようにする。
EC、プログラマティックなランディングページ、競合比較ページ、ローカル検索、地図上の視認性、国際的な言語ターゲティング、自社保有の検索データ、ページ体験、被リンク分析には、専用モジュールを使います。
外部データ提供元、大規模クロール、素材生成は任意の拡張として扱います。呼び出す前に、提供元の要件、認証情報、費用、調査範囲の制限を明記します。
## 取りに行く前にURLを確かめ、APIキーをスキルに書かない
保護されたページ取得、HTML解析、パフォーマンス検査、ベースライン取得、構造化エクスポートなど、決定論的な作業にはローカルスクリプトを使います。
ネットワークへ接続するすべての補助処理は、サーバー側リクエスト偽造のリスクを減らすため、リクエスト前に対象URLを検証しなければなりません。証明書検証を維持し、通信経路の安全性を無効にするのではなく、証明書エラーを調査します。
API認証情報はユーザーレベルの設定場所または注入された環境に保持し、正本スキル、サンプル出力、生成済みパッケージには決して含めません。値を捏造せず、認証情報がないことを明確に示して停止します。
設定済みの言語環境と依存関係管理ツールを通じて補助処理を実行します。クラウドホストがその環境を`PATH`へ公開していない場合は、検証済みの実行ファイル絶対パスを使います。
別のモジュールが結果を利用する場合は、機械可読な形式で返します。一時ディレクトリへ保存されたスクリーンショットやその他のファイルについては、絶対パスを保持します。
## 配る前に、対応するAIエージェントのツールごとに動くか試す
パッケージ化する前に、すべての正本スキルへ移植性スキャンを実行します。必須メタデータ、正しい構造、既知のホスト固有機能を確認します。
対応する各環境で次をテストします。
- ルート指示の検出。
- スキルのインストールまたはリンク。
- 明示的および自動的な有効化経路。
- ツール名の変換。
- エージェントへの委任を利用できない場合のインライン代替処理。
- ローカル補助処理の実行。
- 生成されたルーティングと文書へのフォールバック。
警告には、対象機能、影響を受けるホスト、想定される機能低下を明記しなければなりません。無視される任意フィールドは互換性を保てる場合がありますが、必須指示の欠落や中核操作の利用不能は互換とみなせません。
## ツール特有のエラーは、安全の確認を弱めずに原因を調べる
ホスト固有の失敗は、保護策を弱める許可ではなく、環境を示す証拠として扱います。
- コードを変更する前に、証明書チェーンまたは名前解決の失敗を調査する。
- 既定のコマンドパスに依存関係がない場合は、検証済みの仮想環境実行ファイルを使う。
- スクリーンショットやレポートが作業ディレクトリにない場合は、文書化された一時ディレクトリを確認する。
- 生成物がプロセスやコンテナの境界をまたぐ場合は、絶対パスを使う。
- 利用できないリモート連携は、同等の証拠を提供できる場合に限り、文書化されたローカル補助処理へ置き換える。
制限が検出、実行、委任、ネットワーク接続、生成物の場所のどれに影響するか記録します。回避策はアダプターまたは運用注記に置き、正本の調査ロジックへ混ぜないようにします。
## 実際のツールで試し、説明書を更新してから変更を終える
複数プラットフォームにまたがる調査変更を完了とする前に、次を行います。
- 正本スキルと影響を受けるすべてのアダプターを確認する。
- 生成されるルーティングとパッケージを再ビルドする。
- 移植性スキャンと関連する補助処理のテストを実行する。
- 構文確認だけに頼らず、代表的なホストで実際に動作させる。
- 機能カタログ、インストール手順、アーキテクチャ注記を更新する。
- 任意の拡張が分離されたままであることを確認する。
- 結果に認証情報、根拠のない主張、証拠の欠落がないか確認する。
変更した機能、検証済みのホスト、合格した検査、確認された警告、使用した代替手段、実行できなかった検証を報告します。ホストが必須動作を無視する場合や、1つの環境しかテストしていない場合は、完全な同等性を主張してはいけません。
