データ API と LLM で被リンクの候補を探す方法：kie.ai と evolink.ai の調査

API Hop を運営する中で、私たちはある具体的な疑問に答えたいと考えました。他の AI API サイトが利用している被リンク元のうち、調べてみる価値があるのはどこでしょうか。

kie.ai と evolink.ai を選び、それぞれ被リンクレコードの最初のページを 100 件ずつ取得しました。この記事では、トラフィック、キーワード、サイト全体の順位は調査していません。実用的な被リンクの一覧を得ることだけを目的にしました。

主な結果は次のとおりです。元の 200 件からリンク切れの 5 件を除くと、195 件が残りました。参照元ホスト名でまとめると、異なる参照元はわずか 29 件でした。evolink.ai の 100 件のうち 95 件は GitHub からで、参照元ページは 9 ページだけでした。

この記事では、このデータセットを使って、レコードの収集、集計、AI による整理、次の行動の判断をどのように進めたかを説明します。

1. 被リンクレコードが 100 件あっても、被リンクが 100 本あるとは限らない

同じパラメータで 2 つのサイトから何が返されたか

2. この 2 つのデータセットをどうリクエストしたか

使用したエンドポイント

最初に API Hop の SimilarwebAPI ドキュメントを読みました。

リクエストの形式は次のとおりです。

curl --fail-with-body --max-time 90 --get \
  'https://api.apihop.ai/v1/similarweb/websites/backlinks' \
  --header "Authorization: Bearer ${APIHOP_API_KEY}" \
  --data-urlencode 'Key=kie.ai' \
  --data-urlencode 'Page=1' \
  --data-urlencode 'PageSize=100' \
  --data-urlencode 'Status=Active' \
  --data-urlencode 'FollowType=All' \
  --data-urlencode 'sort=DomainScore' \
  --data-urlencode 'asc=false'

成功したレスポンスの実際の構造

kie.ai のレスポンスの最上位構造を以下に示します。読みやすくするため、最初のレコードの一部のフィールドだけを残し、他のレコードは省略しています。

{
  "TotalRecords": 42009,
  "Records": [
    {
      "UrlFrom": "https://github.com/yitao2020/Vue-AI-web-game-asset-generator",
      "UrlTo": "https://kie.ai/",
      "Anchor": "KIE.ai",
      "DomainScore": 89,
      "IsLost": false,
      "IsBroken": false
    }
  ],
  "Page": 1,
  "PageSize": 100
}

3. 200 件のレコードを調査対象の参照元にどう整理したか

最初にコードで重複を除き、集計する

次の順序で処理しました。

1. サービスが返したすべてのフィールドを保持し、2 つの元の JSON ファイルを保存する。
2. 元の各行に ID を付ける。kie.ai は K001、evolink.ai は E001 から始める。
3. 有効なレコードを残し、除外フラグも CSV に保持する。
4. 競合ごとに UrlFrom + UrlTo が完全一致する重複を除く。
5. 正規化した参照元ホスト名でレコードをまとめ、異なる UrlFrom ページ数を数える。
6. 2 つのサンプルのホスト名を統合し、異なる参照元 29 件を得る。

これらの手順はすべて AI に支援を頼めます。データ分析には Claude Opus5.5 と ChatGPT Astra をおすすめします。

最も明確な違いは参照元の集中度だった

evolink.ai の GitHub レコードは kie.ai よりはるかに多くありました。これが気になって詳しく調べると、95 件のリンクは 9 ページから来ていました。参照元パスには EvoLinkAI、Evolink-AI、evolinkai など、ブランド名に近いアカウント名が含まれていました。オープンソースプロジェクトからの被リンクは、大部分がこの 9 プロジェクトに集中していたことが分かります。

kie.ai の SaaSHub からの 26 件のリンクは、24 ページから来ていました。

整理後の 2 つのサンプルに共通するホスト名は GitHub だけでした。開発者が主な対象ユーザーの一つである両サイトの位置づけによく合っています。この種類の被リンクは試す価値があると考えています。

4. 有用な結果を得るために、AI に適切な材料をどう渡すか

数字はコードに、分類と分析はモデルに任せる

この手順を独自の自動化に組み込む場合は、整理済みの CSV を JSON に変換し、次のプロンプトを使えます。

We are researching backlink sources for an AI API product.
The input contains actual backlink samples for kie.ai and evolink.ai.

Use only the input to organize up to 15 source hostnames:
- source_hostname
- evidence_ids: must come from the input
- source_urls: must come from the input; keep the original URLs
- target_sites: kie.ai, evolink.ai, or both
- category: developer project / product directory / tutorial / community / editorial article / other
- observation: include only facts supported by the input
- suggested_action: keep suggestions separate from facts
- verification_needed: current page status, relevance, account ownership, submission page, pricing terms
- status: always use "Needs verification"

Group by source_hostname.
Do not invent domains, titles, submission pages, or prices.
Do not describe a brand's own repositories as third-party recommendations.
Do not claim that anything is free, guarantees a listing, brings traffic, or improves rankings.
When there is not enough evidence, write "Cannot determine".

実際のレコードから被リンクを 10 件選んだ

以下の表の分類と優先順位は、どの被リンクに取り組む価値があるかについての私たちの初期判断を表しています。

6. 合計でいくらかかったか

今回は、上記で説明したネイティブサービスを通じて、被リンク API の呼び出しが 2 回成功しました。API Hop から同じリクエストをこの標準価格で行う場合、次のように予算を見積もれます。

7. まとめ

私たちが重視したのは、API Hop を使って漠然とした疑問を再現可能なタスクに変えることでした。2 回のクエリで実際のレコードを 200 件取得し、整理して参照元ホスト名でまとめ、さらに調べる価値のある URL を 10 件選びます。 データ API が手がかりを提供し、コードが集計の再現性を担保し、AI が文章の整理を助けます。そして、行動するかどうかを決める最終確認は私たち自身が行います。