integration-review

ADK 統合ページレビュアー（integration-review）

このスキルでは、adk-docs リポジトリにある統合ドキュメントページを厳密にレビューする手順を説明します。統合ページは docs/integrations/ 以下にあり、サードパーティ製ツール、プラグイン、オブザーバビリティプラットフォーム、データストア、MCP サーバー、コネクタ、その他 ADK エージェントの拡張機能について説明します。

このレビューで正とする情報源は、次のとおりです。

1. リポジトリの CONTRIBUTING.md（「Integrations」セクションと、その受け入れ基準を参照してください）。
2. 既存の公開済み統合ページ。これらが実際のテンプレートです。必ず同じカテゴリのページを開いて比較してください。
   • MCP ツール：docs/integrations/github.md、docs/integrations/notion.md
   • オブザーバビリティ：docs/integrations/phoenix.md、docs/integrations/arize-ax.md
   • プラグイン：docs/integrations/daytona.md、docs/integrations/goodmem.md
3. カタログのレンダリングロジックである scripts/integrations.py。

メモ

統合ページまたは統合 PR のレビューを依頼された場合は、このスキルを読み、記載された手順に従ってください。

レビューワークフロー

ステップ 1：変更を確認する

• PR をレビューする場合は、gh で取得し、単一のコミットではなく累積差分全体を確認します。gh pr view <n> --repo google/adk-docs と gh pr diff <n> --repo google/adk-docs を使用してください。古くなった mkdocs.yml のエントリやアセットが、累積差分全体でしか表示されないファイルに含まれていることがあります。
• 「Allow edits from maintainers」が有効になっているか（maintainerCanModify）を確認します。後で依頼された場合に、修正を直接プッシュできます。
• CLA に署名済みか（google-cla ボット）を確認します。未署名の CLA は🔴重大な指摘事項であり、署名されるまでマージできません。
• ローカルファイルをレビューする場合は、git status と git diff を実行して変更を確認します。

ステップ 2：類似ページを探して読む

類似ページを 5 つ以上見つけ、全文を読みます。catalog_tags をスキャンして（grep catalog_tags docs/integrations/*.md）、レビュー対象のタグ（例：mcp、observability）に合う候補を一度に特定し、製品分野、構造テンプレート、言語サポートなどの要素も参考にして対象を広げます（すべてがまったく同じカテゴリである必要はありません）。テンプレートだけで判断するのではなく、ページ全体を読むことで、実際に公開されている例やリポジトリの慣習に基づいたレビューができます。

ステップ 3：チェックリストを実施する

以下のレビュー用チェックリストのすべての項目を確認します。

ステップ 4：コード、パッケージ、リンクを検証する

表面的に読むだけでなく、実際に検証します（「詳細な検証」を参照してください）。

ステップ 5：開発者にとっての価値と成熟度を調査する

プロジェクトの成熟度、採用状況、ADK と実際に統合されているかについて、客観的な根拠を集めます（「開発者にとっての価値と成熟度」を参照してください）。評価は印象や PR 自身の宣伝ではなく、検証可能な事実に基づけます。

ステップ 6：報告し、判断して、終了する

優先順位を付けた報告を作成し（「報告形式」を参照）、続けて「レビューの判断と回答」に記載されている 3 つの出力を提示します。トップレベルのレビュー回答、判断（承認、変更依頼、PR をクローズ）、行番号を指定したコメント案です。デフォルトではファイルを編集したり、GitHub に投稿したり、問題の修正を申し出たりしないでください。修正を求める明示的な指示があるまで待ちます。

ステップ 7（依頼された場合のみ）：修正を適用する

ユーザーから指摘事項の修正を明示的に依頼された場合に限り、的確に編集します。可能な限り投稿者の表現を残し、特に指示がない限り、ADK 側が所有する問題だけを修正します（ベンダー SDK のバグは投稿者に任せます）。可能であれば mkdocs serve で検証します。

レビューチェックリスト

1. フロントマター（カタログのメタデータ）

すべてのページは、次の4つの YAML フィールドだけで始まります。

---
catalog_title: <Display Name>
catalog_description: <short verb-led phrase>
catalog_icon: /integrations/assets/<slug>.png
catalog_tags: ["<tag>", "<tag>"]
---

• catalog_title：カードに表示する、読みやすい製品名です。
• catalog_description：短く、動詞から始め、45～75文字程度（約6～11語）にします。約80文字を超える場合は、カード上で不自然に折り返される可能性が高いため、フラグを付けます。製品名を繰り返してはいけません（タイトルにすでに表示されています）。技術の詳細なリストは避け、連携によって何ができるかを説明します。過大な主張は避けます。
• catalog_icon：/integrations/assets/<slug>.png（または .svg や .jpg）です。参照するアセットファイルは docs/integrations/assets/ に実在し、本物の画像である必要があります。
• catalog_tags：小文字のタグを並べた JSON 配列です。**カタログにすでに存在するタグだけを使用し、新しいタグを作成してはいけません。**タグは組み合わせて使用できます（例：["data", "mcp"]）。本文で MCP を使用するページには、mcp タグを付ける必要があります。grep catalog_tags docs/integrations/*.md を実行して、有効なタグを一度にすべて列挙します。

2. 構成と必須要素

• H1 は # <Product> <type> for ADK の形式にします。<type> はカテゴリに合致するものにします（例：# GitHub MCP tool for ADK、# AgentOps observability for ADK、# Daytona plugin for ADK）。

• H1 の直後に、言語サポートタグを HTML として配置します（太字の Markdown は不可）。

  <div class="language-support-tag">
    <span class="lst-supported">Supported in ADK</span><span class="lst-python">Python</span><span class="lst-typescript">TypeScript</span>
  </div>
  

  • Python 専用の連携では、TypeScript の span を削除します。
  • span は1行にまとめてください。 複数行に分割してはいけません。
  • この div の代わりに通常の太字 Markdown を使用するのは不備です。

• セクションの順序は、次の3つのカテゴリテンプレートのいずれかに合わせます。

  • MCP ツール：## Use cases → ## Prerequisites → ## Use with agent（Python／TypeScript のタブ）→ ## Available tools → ## Configuration（任意）→ ## Additional resources
  • オブザーバビリティ：導入文 → ## Overview → ## Installation → ## Setup → ## Observe → ## Support and Resources
  • プラグイン：## Use cases → ## Prerequisites → ## Installation → ## Use with agent → ## Available tools → ## Configuration（任意）→ ## Additional resources

• セクション名：## Usage や冗長な ## Example: ... 見出しより、## Use with agent を優先します。インストール手順には ## Installation を推奨します。単なる ## API より、具体的な Available tools や Available methods などの名前を優先します。

• 内容が乏しいセクションや細分化されすぎたセクションにフラグを付けます（コードブロックが1つだけの H2 が多数ある場合など）。番号付き手順を含む ## Setup にまとめることを推奨します。セットアップと監視を分割するより、コピーしてそのまま実行できるエンドツーエンドのコードブロックを1つ掲載するほうが、ユーザーにとって適切な場合もあります。

3. コードの正確性

• サンプルコードのモデル文字列には、特定バージョンのモデル文字列ではなく、gemini-flash-latest、gemini-pro-latest、または有効な *-latest エイリアスを使用します。新しいモデルバージョンのリリース時に必要となるメンテナンスを軽減できます。
• 標準のインポート文は from google.adk.agents import Agent（短縮形式）です。MCP では from google.adk.tools.mcp_tool import McpToolset を使用します。
• エージェント変数には、Python では root_agent、TypeScript では rootAgent を使用します。TypeScript ファイルの末尾には export { rootAgent }; を記述します。
• MCP の例では、MkDocs Material のタブを使用します（=== "Python"／=== "TypeScript"。必要に応じて、=== "Local MCP Server" などのサブタブをネストします）。タブ内のアドモニションは8つのスペースでインデントします。
• コードは完全で実行可能なものとし、実際の ADK およびベンダーの API に準拠させます（「詳細な検証」を参照）。

4. スタイルと表記

• ダッシュなど、AI 生成コンテンツで多用される表現は、ほとんど使わないでください。 **用語** — 定義 形式の箇条書きでは、ダッシュをコロンに置き換えてください。本文では、2 つの文に分けるか、読点や括弧を使ってください。サードパーティが所有するコンテンツの場合は、指摘したうえで著者に委ねてください。編集するコンテンツでは、ダッシュを削除してください。
• 本文およびコードコメントでは、Agent Development Kit を「ADK」と表記してください。「Google ADK」や「The ADK」とは表記しないでください。
• 文をインラインコードの語句で始めないでください。 言い換えてください（例：「package-name ライブラリは…を追加します」のようにし、「package-name は…」とはしないでください）。
• マーケティング的な偏りをなくしてください。 これは ADK のドキュメントです。マーケティング的な表現や、広範な主張にあたる記述は削除してください。

5. リンクとアセット

• ADK ドキュメント内のリンクは、絶対 URL の https://adk.dev/... や旧形式の https://google.github.io/... ではなく、サイト相対パス（例：/sessions/memory/）にしてください。相対リンクは PR プレビューで正しく解決され、ドメイン変更後も機能し、リンクチェッカーで検出できます。ベンダーが所有するページでは軽微な指摘にとどめますが、通常は修正してください。
• docs/integrations/ 内のページから画像を参照する場合は、画像が実際に docs/assets/ にあるのでない限り、../assets/... ではなく assets/<img>.png を使用してください。同じ階層のページで実際に使われているパスを確認し、憶測で判断しないでください。
• 外部リンクが有効であること（HTTP 200）を確認してください。存在しないリポジトリ、サンプル、ドキュメントへの架空のリンクを探してください。見つかった場合は、削除を提案するか、実際のリンク先を著者に確認してください。推測で補わないでください。

6. カタログの仕組み

• 統合ページは docs/integrations/index.md 内の render_catalog('integrations/*.md') によって自動検出されます。mkdocs.yml に nav エントリーを追加する必要はありません。追加すると誤りになります。
• カードはファイル名のアルファベット順に並びます。適切な順序になるファイル名を選び、パッケージ名の接頭辞を削除してください（例：mongodb-mcp-server.md ではなく mongodb.md を使用します。先頭に並ぶ adk- 接頭辞も避けてください）。
• mkdocs.yml にリダイレクトを追加するのは、既存 URL のページを改名または移動する場合に限ります。リダイレクト先は最終的なリンク先に直接指定し、リダイレクトを連鎖させないでください。
• 新しい統合を追加するには、適切な frontmatter を含む .md ファイルと assets/ 内のアイコンアセットのみが必要です。

詳細な検証

コードサンプルはすべて、実際の API とライブラリコードに照らして検証してください。正規のソースリポジトリは docs/community/contributing-guide.md に記載されています。

• パッケージの実在確認：PyPI（または npm）にパッケージが存在すること、および記載されたバージョンと Python の要件が本文と一致することを確認してください。
• ADK API：コードサンプルで使われている ADK のシンボルとパターンをすべて、該当する言語 SDK の正規ソースリポジトリ（docs/community/contributing-guide.md に記載）と照らして確認してください（例：Runner、run_async、create_session、append_event、save_artifact、セッション／アーティファクトサービス URI、adk web／adk run CLI フラグ、genai 型）。ローカルのチェックアウトがあるとは限りません。gh または git を使ってソースを取得するか、ローカルにクローンが存在する場合はそれを使い、main ブランチがリリースより先行または遅れている可能性を考慮して、ドキュメントが対象とするリリース済みバージョンを確認してください。検証したバージョンを記録し、不一致があれば指摘してください。
• ベンダー SDK：ベンダー SDK のソースまたはドキュメントに照らして、ベンダーのクラス、メソッド、引数を確認してください。
• バグの所有者：ADK が所有する問題と、ベンダー SDK が所有する問題を区別してください。ベンダー SDK が所有する問題は指摘し、著者に委ねてください。
• 可能な場合は手動でテストしてください。実際の ADK エージェントでサンプルを実行するか、少なくとも mkdocs serve を実行して、カードが表示され、アイコンが読み込まれることを確認してください。

開発者価値と成熟度

統合ページは ADK の公式ドキュメントであるため、統合を掲載するには、実証された実質的な価値を開発者に提供する必要があります。ここでの目的は、その統合が、実用性と実績があり、実際に採用されている確立済みプラットフォーム向けなのか、それとも実質的な内容に乏しく、誕生したばかりか採用実績の少ないプロジェクト向けなのかを調査して判断することです。調査を行い、根拠を報告してください。PR 自体の説明やマーケティングから価値を推測してはいけません。

客観的に検証できる指標を集め、それぞれに出典を明記してください。

• パッケージの実在性と公開時期：実際に公開済みのパッケージが存在することを確認します。PyPI JSON API（https://pypi.org/pypi/<pkg>/json）または npm レジストリ（https://registry.npmjs.org/<pkg>）を照会し、初回リリース日、リリース数、最新バージョンを確認し、ダウンロード数（pypistats または npm downloads API）も確認します。パッケージが存在しない場合や、PR と同じ日に公開された場合は、強い否定的シグナルです。
• ソースリポジトリの指標：gh api repos/<owner>/<repo> を使って、created_at、スター数、フォーク数、コントリビューター数、コミット数、リリース、ライセンス、最終コミット日を確認します。ここ数週間以内に作成され、コミットがわずかで、作者が1人だけであるか、ライセンスがないリポジトリは、否定的シグナルです。
• 採用状況と実績：検証可能な指標から実際の利用状況を評価します。パッケージのダウンロード数（上記参照）、リポジトリのスター数、フォーク数、依存プロジェクト数に加え、ウェブ検索で見つかった、実運用での導入事例、ケーススタディ、独立した第三者による報道などを確認し、製品がどれほど長く運用されているかも調べます。広く使われていることを検証できれば肯定的なシグナルです。すべての情報源を通じて採用実績が確認できない場合は、否定的なシグナルです。
• 真の ADK 統合：依存関係（google-genai など）にパッチを当てたり、REST API を単純な関数でラップして ADK 統合として提示したりするのではなく、プロジェクトが実際に ADK の拡張ポイント（コールバック、プラグイン、ツールセット、MCP）を使っていることを確認します（「詳細な検証」と以下のスコープ判定の条件を照合してください）。
• ウェブサイトの稼働状況：リンク先のサイトが、パーキングドメインやプレースホルダーではなく、実際に稼働している製品サイトであることを確認します。

根拠の評価方法。 新しいプロジェクトだからといって、自動的に価値が低いとは限りません。確立されたベンダーが新しいパッケージを公開した場合や、明確な実用性に加えて、実在するソースリポジトリ、テスト、ライセンスがあるプロジェクトは、信頼に値するため、価値に関する懸念として扱うべきではありません。本当に懸念すべきなのは、否定的なシグナルが積み重なっている場合です。たとえば、誕生したばかりで未公開、採用実績も運用実績もない、ソースやライセンスがない、ADK の拡張機能を実際に使っていない、ページ上の主張を検証で確認できない、といった場合です。根拠がまちまちであれば、コントリビューターに有利に判断し、事実を整理したうえで、断定的な結論ではなく、メンテナーの判断事項としてクローズを提案してください。報告は中立的かつ事実に基づいたものにしてください。

承認と却下

却下の条件（PR をクローズ）：

• 未リリース、未マージ、または架空の API を記載している。まだ存在しない機能はドキュメント化できません。
• 既存のページと重複している（ベンダー固有の機能はベンダー独自のドキュメントに記載し、既存の ADK ページからは最大でも 1 行のリンクを掲載します）。
• 実際の ADK またはベンダー API と一致しないコード。
• 壊れたリンク、または捏造されたリンク。
• CLA が未署名。
• 開発者にとっての価値または成熟度が不十分：新設されたばかりのリポジトリ、未公開または公開当日のパッケージ、採用実績や導入実績がない、ソースリポジトリやライセンスがない場合です。「開発者にとっての価値と成熟度」の証拠を根拠として判断し、自動的な判定ではなく、メンテナーの判断として扱ってください。
• 統合の実態を誤って表現している：ADK の拡張ポイントを無視した手動コードでありながら、ADK と統合していると主張している。
• 対象範囲外：ADK 固有の成果物を伴わない、汎用的な「REST API を関数ツールとしてラップする」ページ。ADK のドキュメントは API ディレクトリではありません。
• スパムの兆候（どちらのプロジェクトとも関係がない、ADK 固有の機能がない、コントリビューショングラフの水増し、利用が少ないごく新しい統合）。

良いページ： 4 フィールドすべてを埋めたフロントマターに、動詞で始まる簡潔な説明と有効な既存タグがあること。正しい H1 と、1 行の言語サポート用 div があること。固有の内容を含み、細分化されていないセクションを備えた適切なカテゴリーテンプレートを使っていること。gemini-flash-latest（または有効な *-latest エイリアス）と正規のインポートを使用した、完全で実行可能な、手動テスト済みのコードがあること（MCP の場合は Python と TypeScript のタブも含む）。内部リンクは相対パスで、外部リンクは機能し、アイコンのアセットも有効であること。冗長な AI 生成風の表現がなく、「ADK」を正しく使用していること。誇張やマーケティング上の偏りがないこと。ナビゲーションの編集を行わず、自動検出されること。

レポート形式

優先度別に分類した Markdown レポートを作成し、各指摘に正確な file:line と文脈を記載してください。行番号は、行番号付きで読み込んだファイル、grep -n、または diff のハンクヘッダーを使って、レビュー対象のファイル（ローカルページ、または gh pr diff で取得した PR の差分や取得したコピー）から特定してください。推測による行番号は使わないでください（~ も使用不可）。必ず 4 つの優先度すべてを順番どおりに記載し、指摘がない優先度の下には None と記載してください。これにより、Critical の問題がないことを明示し、単なる暗示にとどめません。実際に対応するかどうかを選べると考える指摘は、🔵 Nits に分類してください。🔴、🟠、🟡 はマージ前に必ず修正が必要な項目に限ります。

• 🔴 Critical：架空または未リリースの API、動作しないコード、壊れたリンクまたは捏造されたリンク、未署名の CLA、誤った出力先ディレクトリ、重複ページ。
• 🟠 Quality：構成やテンプレートの不一致、セクションの欠落や誤った名称、誇張、ベンダーまたは ADK API の詳細の誤り。
• 🟡 Style：冗長な AI 生成風の表現、「ADK」の不適切な使用、文頭のインラインコード、語句の選択、モデル文字列、インポート、説明の長さ、マーケティング調の表現。
• 🔵 Nits：タグのカンマ周りのスペース、ベンダー所有ページでの ADK リンクの絶対パスと相対パスの違い、画像サイズ、見出しの大文字・小文字の表記揺れ。

ここに記載した各指摘について、出力 3 に少なくとも 1 つの行アンカー付きコメントを付けてください（複数箇所にまたがる指摘には、箇所ごとに 1 つコメントを付けます）。レポートとコメントで扱う項目は同じにしてください。

優先度別のレポートの後に、短い 開発者にとっての価値と成熟度 の説明段落を追加してください。「開発者にとっての価値と成熟度を調査する」手順で得た証拠（パッケージの公開からの期間、採用実績と導入実績、リポジトリの兆候、ADK 拡張の実際の利用）を要約し、それぞれの兆候に出典リンクを付けたうえで、暫定的な見解を最後に記載してください。調査の結果、価値または成熟度が不十分と判断した場合は、「judgment call」とタグ付けした 🔴 Critical の指摘としても記録し、承認ゲートとの整合性を保ってください。

優先度別レポートの後に、以下の「レビュー判断と回答」の出力を作成してください。

レビューの判断と回答

優先順位付きレポートの後に、以下の3つの出力を順番に提示してください。GitHub の PR レビュー（レビュー本文＋判断＋インラインコメント）に対応します。ここに示す内容はすべて草案です。ユーザーから明示的に依頼されない限り、GitHub に投稿したり、gh を実行したり、ファイルを編集したりしないでください。

1. レビュー全体への回答

GitHub の PR レビュー概要に貼り付けられる、数文程度の短いレビュー本文を作成します。どのような統合なのか、全体的な評価、主な理由、次に必要な対応を述べてください。以下の「フィードバックのトーン」に従い、簡潔で率直かつ配慮のある、実行可能な内容にします。PR をクローズする場合は、「却下の回答テンプレート」にある該当する文面を使用し、具体的な根拠を記入してください。

2. 判断

上記のレポートにある具体的な指摘を引用し、判断を1つだけ選んでください。「受け入れと却下」の基準を相互参照し、判断に一貫性を持たせてください。

• Approve：レポートに🔴、🟠、🟡の指摘がなく（3つとも None）、🔵の軽微な指摘のみが残り、ページが「良いページ」の基準を満たしている場合です。
• Request changes（通常のケース）：修正可能なページに🔴／🟠／🟡の指摘があり、マージ前に修正が必要な場合です。必須の修正項目を列挙してください。
• Close PR：「受け入れと却下」の却下トリガーに該当する場合です（捏造または未リリースの API、重複ページ、実際の ADK またはベンダー API と一致しないコード、リンク切れまたは架空のリンク、CLA の未署名、統合内容の誤表示、スコープ外、価値または成熟度の不足、スパムの兆候）。PR のクローズを推奨し、その理由を記録してください（該当する場合は、代替となるドキュメントまたは PR へのリンクを記載します）。開発者にとっての価値または成熟度の不足だけが懸念事項で（コード自体は動作する場合）、自動的な必須ブロッカーとしてではなく、「開発者にとっての価値と成熟度」の説明を根拠とする、メンテナーの判断に委ねられる明示的な推奨として提示してください。

強い根拠があり、上記3つのいずれにも本当に判断できない場合を除き、判断なしの「comment」は選ばないでください。

3. 行に紐付いたコメント

メンテナーが差分に追加できる、コピーしてそのまま使えるインライン PR コメントの一覧を作成します。4つすべての重要度（🔴 🟠 🟡 🔵）にわたるレポート内の指摘をすべて網羅してください。重要度で除外したり、コメントする価値がないカテゴリがあると判断したりしないでください。些細な指摘も含め、挙げられた項目すべてにコメントし、見落としがないようにします。

• 各コメントは、GitHub のインラインコメントとしてそのまま貼り付けられる形式にします。file:line（または file:start-end）の位置情報と重要度の絵文字を別々の行に記載し、その後に1～2文の提案をブロック引用として記載してください。コピーしやすい形式にします。例：

  docs/integrations/weave.md:76 🟡 Style

  固定バージョンの model="gemini-2.5-flash" ではなく、 model="gemini-flash-latest" を使用してください。リポジトリの慣例に沿い、 モデルのバージョン変更に伴う更新の手間を避けられます。

• レポート内の指摘箇所から、正確な file:line を使用してください。確認対象のファイル（ローカルのページまたは PR の差分）の行番号を用い、概算しないでください（~ は不可）。行に紐付けられない指摘（セクションの欠落や、価値と成熟度に関する判断など）の場合に限り、ページ全体またはフロントマターへのコメントを使用し、その旨を明記してください。

• コメントはレポートと同じ順序で、重要度ごとにまとめてください。

• 1つの指摘から複数のコメントを作成することもできます。同じ問題が Python と TypeScript のサンプルなど、複数の箇所にある場合は、それぞれの箇所にコメントを付けてください。

• 完成前に照合してください。レポート内のすべての指摘に、少なくとも1つのコメントがあることを確認してください（コメント数は指摘数と同じか、それ以上にします）。コメントのない指摘があれば、不完全な一覧を提出せず、コメントを追加してください。

これらは草案にすぎず、投稿しないでください。

この3つの出力を提示したら、そこで終了してください。ユーザーから明示的に依頼されない限り、ファイルを変更しないでください。

フィードバックのトーン（作成するPRコメント向け）

• 短く、要点を直接伝えます。各項目は2文程度にします。
• 配慮を示しつつ、実行可能な提案をします。投稿者が対応を見送れる余地も残してください（例：「リポジトリにサンプルエージェントはありますか？ なければ、このリンクを削除して、このページをサンプルとして使えます。」）。
• 正確で、実行可能な用語を使います（例：frontmatterのフィールドには「ページ名を変更」ではなく「カタログのタイトルを変更」とします）。手順を詳しく説明しすぎず、作業方法についてはコントリビューションガイドを参照してください。

却下時の回答テンプレート

Close PR と判断した場合は、以下の該当するテンプレートをトップレベルのレビュー回答に合わせて調整してください。これらはメンテナーが確立した文体に沿ったものです。短くまとめ、すべての「[角括弧]」を、このPRで確認済みの具体的な根拠に置き換えてください。受け入れ基準（https://github.com/google/adk-docs/blob/main/CONTRIBUTING.md#acceptance-criteria）へのリンクを含めてください。複数該当する場合は、該当する段落を組み合わせてください。

• 開発者にとっての価値：「PRをありがとうございます。受け入れ基準に照らして確認した結果、現時点ではこのインテグレーションを受け入れることができません。開発者にとっての価値： ADKを使ってエージェントを構築する開発者に、明確で実証された価値を提供するインテグレーションを求めています。プロジェクトの成熟度、アクティブユーザー数、実績などの要素を評価します。[根拠：例：関連リポジトリの作成からまだ数週間しか経っておらず、インテグレーション対象となる公開パッケージがなく、このプロジェクトには、私たちが求めるコミュニティでの普及や実績がまだありません。]」
• 完全性とテスト可能性：「PRをありがとうございます。受け入れ基準に照らして確認した結果、現時点ではこのインテグレーションを受け入れることができません。完全性とテスト可能性： ドキュメント内のコード例は、開発者が実行できるものでなければなりません。[根拠：例：参照されているADKのインポートやクラスが存在しない／<pkg>パッケージが公開されていない／マージされていないPRからインポートしている。]」
• 公開可能性：「PRをありがとうございます。ただし、このインテグレーションを受け入れることはできません。受け入れ基準に基づき、技術的保護手段の回避、利用規約違反、または無許可でのサービスへのアクセスにつながるおそれのあるインテグレーションは公開できません。[根拠]」
• 対象範囲外：「PRをありがとうございます。ただし、このインテグレーションページはADKのドキュメントの対象範囲外です。インテグレーションページは、ADKを拡張する、または緊密に連携するサードパーティ機能（ツール、プラグイン、ツールセット、MCP サーバー、オブザーバビリティプラットフォーム）を対象としています。[根拠：例：これはREST APIを呼び出す単純な関数を定義しているだけで、一般的な「REST APIを関数ツールとしてラップする」パターンです。このパターンはすでにドキュメントにあり、あらゆるAPIに適用できます。ADKのドキュメントはAPIディレクトリではありません。]」
• 重複／置き換え済み：「PRをありがとうございます。これは #<N> に置き換えられています／既存の [<page>] と重複しています。[任意：ベンダー固有の機能については、ベンダー自身のドキュメントに記載し、既存のADKページからのリンクは1行までにしてください。]」