TikHub APIトークンとAPI Helperスキル、AIエージェントで実際に試してみた

「tikhub api helper」で1位に表示されるClaude Codeスキルは、TikHubの製品ではありません。1人の開発者が個人のGitHubアカウントで管理しているコミュニティプロジェクトです。以下ではこれをコミュニティリポジトリAと呼びます。2026-11-06の未明（シンガポール時間、SGT、UTC+8）に、ファイルを1つずつ確認しました。エンドポイントのスナップショットには1,120件のパスがあり、そのうち288件（25.7%）は同日のTikHubドキュメントにすでに存在しません。SKILL.mdにある4つの呼び出し例のうち3つは、現行のドキュメントにないパラメータ名を使っています。スキルはTIKHUB_TOKENを設定するよう案内していますが、コードが読み取るのはTIKHUB_API_TOKENです。

さらに大きな問題はHTTPクライアントです。このスキルは、Python標準のurllibとデフォルトのUser-Agentでリクエストを送信します。SGTの00:20と00:25にシンガポールから2回テストしたところ、このデフォルトヘッダーでapi.tikhub.ioとapi.tikhub.devに送ったリクエストには、すべてHTTP 403と「error code: 1010」が返されました。

トークン不要のヘルスチェックでさえ失敗しました。同じTikTokまたはDouyinへの1,000リクエストあたり、TikHubの公開価格は$1.00です。EveryInfraでのライブ呼び出し3回はそれぞれ$0.000556だったため、1,000回では$0.556となり、TikHubの料金はその1.8倍です。TikHubが同水準になるのは、日次ボリューム割引の適用後、1つのエンドポイントを1日約117,900回呼び出した場合だけです。

この記事は、「tikhub api token」「tikhub api helper」「api tikhub io」で検索する人に向けて、焦点を絞った1つの疑問に答えます。トークンはすでに手元にあり、次はAIエージェントにエンドポイントを探させ、呼び出させ、エラーにも自力で対処させたい、という状況です。

トークンはどこに保管し、どのように管理すればよいのでしょうか。レート制限はどのように機能するのでしょうか。コミュニティ版のHelperはそのまま使えるのでしょうか。TikHub側については、公開資料（ドキュメント、APIファイル、料金ページ、公開GitHubリポジトリ）のみを使いました。

TikHubには新規登録していません。他人のトークンを使って有料エンドポイントを呼び出すこともしていません。EveryInfra側の数値はすべて同じ夜に行ったライブ呼び出しによるもので、本文には各閲覧と呼び出しの時刻を記載しています。

TikHub APIトークンの作成方法：権限、有効期限、ステータス

TikHubのトークンはユーザーセンターで作成します。ドキュメントサイトのREADME - Englishの末尾にある「Get API Token」セクションには、4つの手順が記載されています。新規登録してログインし、ユーザーセンターでAPIトークンのメニューを開いてトークンを作成します。

トークンをコピーしてリクエストヘッダーに設定します。トークンは秘密にし、ヘッダーでのみ使用します。中国語版READMEも同じ内容です。チュートリアルとFAQのページには、1ユーザーあたり最大100個のAPIキーを作成できるとあり、プロジェクトごとにキーを分けるのも簡単です。

ここまでは、記事TikHubのAPIキー、ドキュメント、GitHubを検証ですでに取り上げた内容と同じです。この記事ではもう一歩踏み込みます。トークンを作成した後、使えるエンドポイントを限定できるか。有効期限を設定できるか。一時的に無効化できるか。この3つの制御が、自律的に判断するAIエージェントにトークンを安全に渡せるかどうかを左右します。

TikHubの現行の公開ドキュメントでは、この3つの制御の手順は見つかりませんでした。現行のREADMEとapi.tikhub.ioのopenapi.json（2026-11-06 00:16 SGTに閲覧）では、ステータスコードの説明で触れられているだけです。401の6つの理由には「API token has expired」と「status is invalid or not activated」が含まれます。403の理由には「API token lacks required permissions」が含まれます。つまり3つの状態は存在しますが、設定方法はドキュメントに書かれていません。

設定方法の説明は古い資料で見つかりました。TikHub Python SDKのバージョン1.13.0は2024-12-05にリリースされ、そのPyPIページには、トークンにカスタムのScopesを指定し、Expire Dateを設定し、Statusを使って手動で無効化できると書かれています。また、対応するScopesを設定したトークンをプロジェクトごとに1つ使うことを強く推奨しており、そうしないと権限不足でリクエストが失敗するとしています。バージョン2.2.0（2026-10-03）では、このセクションがなくなっています。新しい説明は、ダッシュボードからAPIキーをコピーしてTIKHUB_API_KEYとして設定するよう述べているだけです。

TikHubのユーザーセンターにはログインしていないため、3つの制御が現在もダッシュボードにあるかは確認できていません。言えるのは次のことです。古いドキュメントには設定できると書かれていました。現行のドキュメントには設定方法が書かれていません。ステータスコードの説明には、今も3つの状態がすべて記載されています。

EveryInfraでは、3つの制御はすべて/docsのアカウントセクションに記載されています。コンソールの「APIキー → 権限」で、キーごとにプロダクトをオフにできます。オフにしたプロダクトを呼び出すと403 capability_deniedを返します。無効化したキーで呼び出すと401を返します。キー管理、アカウント設定、サポートチケットの3つの書き込み権限は、デフォルトでオフです。これらをオンにできるのは、コンソールを操作するユーザーだけです。

キーを使って別のキーを作成することもできますが、1日20個までです。一部の操作は常にコンソールでのみ行えます。たとえば、キー全体の表示やローテーション、権限とIP許可リストの変更、キーの再有効化、支払いです。これらは意図的な設計です。AIエージェントにキーを持たせる場合、最大のリスクは1回の誤った呼び出しではなく、エージェントがアカウントを変更したり、許可されていない支出を行ったりすることです。

以下の表で両者を比較します。TikHub側の「記載なし」は、現行の公開ドキュメントに設定手順が見つからなかったことを意味します。機能が存在しないという意味ではありません。

最も重要なのは2行目です。エンドポイントを自分で選ぶエージェントは、遅かれ早かれ想定外のエンドポイントを選びます。たとえば、TikTokのプロフィールを読ませたいのに、1回$0.02のDouyin Xingtuのエンドポイントを呼び出す、といったケースです。TikHubがまだScopesに対応しているなら、トークンの作成時に必要なプラットフォームだけを選択してください。

ダッシュボードにその設定項目がなくなっている場合、残る手段は2つです。エージェントごとに1つのトークンを使うことと、残高には必要な金額だけを入れておくことです。当社の製品単位のスイッチは、エンドポイント単位のスコープほど細かくは設定できません。その代わり、CAPTCHAの解決やプロキシなど、データ収集に関係のない製品を1つのスイッチでまるごと無効にできます。

レート制限：TikHubはエンドポイントごと・秒単位、当社はアカウントごと・分単位でカウント

トークンをエージェントに渡したあと、次によく問題になるのがレート制限です。エージェントは並列呼び出しを多用し、同時に12件ほどのリクエストを送るのは普通のことです。TikHubのopenapi.jsonの冒頭には「QPS: 10/Second」とあります。料金ページのFAQにはより詳しい説明があります。制限はアカウント単位ではなく、エンドポイント単位で適用されます。

デフォルトの毎秒10リクエストはAPIパスごとに個別に適用されるため、異なるエンドポイントは並列で呼び出せます。より高いレートが必要な場合は、RPSパネルでRPSプランを購入できます。これはリクエスト料金とは別の月額料金です。2024年のドキュメントは少し異なっていました。制限はトークン所有者のメールアドレスごと・エンドポイントごとに適用され、ほとんどの場合は毎秒5件とされていました。

ドキュメントには「default 10」とあります。各エンドポイントの実際の値は料金一覧エンドポイントで確認でき、トークンなしで読み取れます。SGT 00:18:13に、価格が設定された1,471件のエンドポイントを読み取り、rate_limitフィールドを集計しました。1,397件のエンドポイントでは、毎秒10リクエストが許可されています。

許可数が5のエンドポイントは47件、3は14件、1は10件です。20、4、2はそれぞれ1件ずつです。つまり、74件のエンドポイントがデフォルト値ではありません。デフォルトのレートで動くエージェントは、毎秒1件しか許可しないエンドポイントで429レスポンスを繰り返し受け取ることになります。

EveryInfraは、制限をエンドポイント単位ではなくアカウント単位でカウントします。料金ページに記載のとおり、デフォルトはアカウント内のすべてのキーの合計で毎分60リクエストです。キーを増やしても処理能力は増えません。さらに速度が必要な場合は、30日間有効のスピードパックを購入できます。毎分180件で$10、または毎分600件で$30です。

チャージの累計額が上がると、許可されるリクエスト数の上限も引き上げられます。制限を超えると429 rate_limitedが返され、待機すべき秒数を示すRetry-Afterヘッダーが付きます。429コードとRetry-AfterはRFC 6585の第4節で定められたもので、両サービスとも使っています。

どちらの方式にも長所と短所があります。TikHubのエンドポイント単位の制限では、多数のエンドポイントを同時に呼び出すと高い合計スループットが得られます。また、毎秒10件という値は当社のデフォルトである毎分60件よりはるかに速い設定です。当社のアカウント単位の制限なら、エージェントは1,471個の個別の制限を覚える必要がありません。把握すべき数値は1つだけです。

コミュニティ製のHelperについて、もう1点補足します。そのSKILL.mdには「QPS 10 per second per endpoint, timeout 30 to 60 seconds, up to 3 retries on errors」と書かれています。これはTikHubのopenapi.jsonの冒頭から取った記述です。しかし、Helperのクライアントにはリトライ処理のコードがありません。

タイムアウトは30秒に固定されています。429を受け取っても、モデルには「HTTP 429」を返すだけです。モデルはSKILL.mdを読んで、クライアントが代わりにリトライしてくれると思い込みます。

tikhub api helperは誰が作ったのか、中身はどうなっているのか

「tikhub api helper」で検索すると、上位に表示されるのはtikhub_api_skillという名前のGitHubリポジトリ（コミュニティリポジトリA）と、それを掲載しているスキルディレクトリのページです。例としてLobeHubのスキルマーケットプレイスやShyftがあります。リポジトリの所有者は個人アカウントで、TikHubのGitHub組織には属していません。リポジトリの説明ではTikHub API向けの「a Codex/Claude Code Agent Skill」とされていますが、TikHubが作ったとは書かれていません。

SGT 00:14の時点で、GitHub APIで確認したスター数は129で、ページ上で確認したフォーク数は17でした。リポジトリは2026-01-08に作成され、最終プッシュは2026-07-08で、ライセンスはありません。したがって正しくは、これはコミュニティプロジェクトであり、TikHubに「API Helper」というスキルは存在しません。TikHub自身の製品は、Claude Codeプラグインのtikhub-pluginです。最新リリースは2026-06-15のv1.1.0で、18個のスキルと7つのプラットフォーム向けのMCP設定を含みます。

Helperの構成はシンプルで、.claude/skills/tikhub-api-helper/の下に4つのファイルがあります。SKILL.mdは5,850バイトで、エンドポイントを検索し、そのパラメータを読んでから呼び出すようモデルに指示します。api_searcher.pyは、ローカルのopenapi.jsonをキーワードで検索します。api_client.pyはリクエストを送信します。openapi.jsonは、2,997,476バイトのエンドポイントのスナップショットです。

考え方自体は妥当です。TikHubのAPIファイルは約840,000トークンあるため、すべてをモデルに渡すことはできません。ローカルで検索し、一致した部分だけをモデルに渡せば、コンテキストを大きく節約できます。Claude Codeのスキルに関するドキュメントも同じ考え方です。スキルの本文は使うときにだけ読み込まれ、大きな参照ファイルはそれまでほとんどコンテキストを消費しません。問題は細部にあり、以降のセクションで1つずつ取り上げます。

コミュニティ製のスキルはこれだけではありません。TypingMindのスキルディレクトリには、別のコミュニティスキルであるtikhub-skill（コミュニティリポジトリB）も掲載されています。これはオープンソースプロジェクトOpenCompanyの一部で、仕組みが異なります。エンドポイントのスナップショットは持たず、代わりにTikHubのPython SDKのメソッドを1つのツールにまとめています。以下に3つの方式を並べて示します。

TikHub自身のプラグインは、記事TikHubのAPIキー、ドキュメント、GitHubを検証ですでに検証しました。この記事では、2つの理由からコミュニティ製のHelperを取り上げます。第1に、この検索で最も多く開かれる結果だからです。第2に、そのままコピーして使われているからです。後述のトークンのセクションで示すように、元のリポジトリで修正しても、すでに存在するコピーには反映されません。

エンドポイントのスナップショットは古く、1,120パスのうち288が消えている

Helperのopenapi.jsonは、作者が2026年1月にTikHubからダウンロードしたコピーです。その後の変更は5月の1回だけです。私たちはこれを、2026-11-06 SGT 00:16:44に取得したTikHubのopenapi.jsonとパスごとに比較しました。どちらのファイルもinfo.versionはV5.3.2なので、バージョン番号からは何も変わっていないように見えます。実際には、スナップショットの1,120パスのうち、現在のドキュメントに残っているのは832だけです。288パス（25.7%）が消えています。

逆方向の差分もあります。現在のファイルにある1,058パスのうち226（21.4%）はスナップショットに含まれていないため、Helperを使うエージェントはそれらを見つけられません。共通する832件のエンドポイントのうち、59件はクエリパラメータが異なります。たとえば、Kuaishouのユーザー検索ではpageがなくなり、pcursorと3つのフィルターが追加されました。

変更はいくつかのグループに集中しています。新しいグループには、インフルエンサーマーケティングや広告分析に携わる人が最も求めるエンドポイントが含まれています。

もう1点あります。消えた288パスのうち201は、価格付きで料金一覧にまだ載っています。TikHubのAPIキー、ドキュメント、GitHubを検証では、ドキュメントにない433パスが料金一覧にあることも確認しました。このことから、TikHubはエンドポイントをまずドキュメントから削除し、料金一覧には残しておくと考えられます。エージェントにとって、料金一覧に載っていることは、そのエンドポイントがまだ動作する証拠にはなりません。

SKILL.mdのプラットフォーム表にも、更新時期のずれが表れています。表ではXiaohongshu Webのエンドポイントは26件とされていますが、スナップショットには15件、現在のドキュメントには0件です。YouTube Webは16件とされていますが、現在は8件です。

TikTok Appは76件とされていますが、現在は58件です。表の数値は、同梱のスナップショットとも現在のドキュメントとも一致しません。

この表をもとに計画を立てるエージェントは、Xiaohongshu Webには多くのエンドポイントがあると考えます。ところが、検索で返ってくるのはすでに消えたパスだけです。

SKILL.mdどおりに検索：複数語のクエリが0件になりがちな理由

Helperのワークフローは、検索、詳細の確認、呼び出しの3ステップです。SGT 00:19に、そのapi_searcher.pyを自社のマシン上でオフライン実行しました。SKILL.mdに出てくる各クエリをそのまま実行し、さらに中国語や複数語のクエリを4つ追加しました。結果は下のグラフのとおりです。

「tiktok user profile」は、SKILL.mdにあるワークフロー例の最初のステップです。結果は1件で、それはパラメータを取らないデモ用エンドポイントです。「common use」セクションにある「fetch user profile tiktok」は0件です。「douyin video comments」も0件で、「Xiaohongshuのノート」を意味する中国語のクエリも0件でした。

原因は検索スクリプトにあります。スクリプトはクエリ全体を1つの部分文字列として扱います。そして「path + summary + description + operationId」を連結した文字列からその部分文字列を探し、20件で打ち切ります。複数語のクエリは、それらの語がその順序どおりに連続して現れる場合にしか一致しません。TikHubのsummaryは「Get user profile」のような形式なので、「tiktok user profile」の3語が連続して現れることはありません。

スクリプトにはキーワードマップを持つsuggest_api関数が含まれており、「user profile」をfetch_user_profileに展開できます。しかし、コマンドラインのエントリーポイントはこの関数を一度も呼び出しません。単語1つなら結果は見つかりますが、すぐに20件の枠が埋まり、スクリプトはファイル順でリストを打ち切ります。中国語の「ノート」で得られた20件のうち、8件はすでに消えています。また、上位の結果が目的のプラットフォームのものとは限りません。

2番目のステップ「詳細を読む」にも問題があります。SKILL.mdの例はdetail:tiktok_web_fetch_user_profile_getです。書かれたとおりに実行したところ、「No API found」が返りました。スナップショット内の実際のoperationIdはfetch_user_profile_api_v1_tiktok_web_fetch_user_profile_getです。この名前で実行すると、1,970バイトのパラメータ詳細が返りました。

最後のステップである呼び出しについては、SKILL.mdに4種類の呼び出し例があります。それぞれを現在のドキュメントのパラメータと比較しました。

これらの例から学んだエージェントは、最初のプロフィール取得の呼び出しでsec_user_idを送りますが、サーバーはこのパラメータを認識しません。TikHubのエンドポイントはFastAPIを使っています。現在のopenapi.jsonでは、973のエンドポイントが422バリデーションエラーを宣言しています。レスポンスボディには標準のフィールドloc、msg、typeが含まれ、どの必須パラメータが欠けているかはわかります。しかし、post_idをitemIdにすべきだとは教えてくれません。

プロフィールのエンドポイントでは、どちらのパラメータも任意です。サーバーは未知のパラメータを何も言わずに無視するのでしょうか。また、その呼び出しは課金されるのでしょうか。私たちはアカウントを持っていないためこれは検証しておらず、不明と記すしかありません。同じ間違いに対して当社のAPIがどう応答するかは、後述の「間違えたときに何が起きるか」のセクションで示します。

トークンの保存場所：3つの変数名とハードコードされたトークン

まずは最も単純な間違いである環境変数名から見ていきます。SKILL.mdの「Authentication」セクションはTIKHUB_TOKENを設定するよう指示しています。しかしapi_client.pyが読むのはTIKHUB_API_TOKENです。TikHubのPython SDKとTikHubのプラグインは3つ目の名前TIKHUB_API_KEYを使っており、この名前はプラグインの設定に83回登場します。

私たちのマシンではTIKHUB_TOKENだけを設定し、ほかの2つは未設定のままにしました。その状態でHelperのクライアントを作成すると、読み込まれたトークンの長さは0でした。リクエストヘッダーは、スキーム名とスペースの後に何も続かない形になりました。つまり、SKILL.mdのとおりに設定したユーザーは、すべてのリクエストをトークンなしで送ることになり、返ってくるのは401レスポンスだけです。

スクリーンショットの1つ目のティール色の枠には「API requests use a default token for development」とあります。この行はHelperの初期バージョンに由来します。初期バージョンでは、トークンがコードに直接書き込まれていました。

その後、別のコントリビューターが修正を送りました。トークンを環境変数からのみ読むようにコードを変更するもので、この変更はmainブランチにマージされました。修正自体は正しいものです。しかし、SKILL.mdは更新されませんでした。そのため現在も、SKILL.mdはリクエストにデフォルトのトークンを使うとモデルに伝えている一方、コードにはデフォルトがありません。この行を読んだモデルは、変数がなくても呼び出しが動くと考え、401レスポンスだけを受け取ることになります。

より大きな懸念はフォークです。GitHub APIを使って、リポジトリのフォークを1つずつ読みました。比較したのは文字列のハッシュだけで、値のコピーや検証はしていません。結論は一文で言えます。一部のフォークには初期のハードコードされたトークンがまだ残っており、作者にはトークンのローテーションをおすすめします。

トークンがまだ有効かどうかは検証しておらず、検証すべきでもありません。漏洩したトークンで呼び出せば、他人のお金を使うことになるからです。Helperのユーザーにとっての教訓はその裏返しです。フォークやコピーからインストールしたバージョンは、元のリポジトリで修正されたバージョンではない可能性があります。

GitHubのドキュメントは、このケースについて明確に述べています。パスワードやトークンなどの認証情報が漏洩した場合、最初にすべきことはそれを失効させるか、ローテーションすることです。失効させれば誰も使えなくなり、多くの場合、履歴を書き換える必要はありません。履歴を書き換えてforce pushするだけだと、古いコミットはどのクローンやフォークからでも引き続き取得できてしまいます。ハッシュを指定したGitHubのキャッシュビューや、それらのコミットを参照するプルリクエストからも取得できます。フォーク内のコピーを削除できるのはフォークの所有者だけです。

つまり、元のリポジトリでの修正が守れるのはこれから先だけです。すでに出回っているコピーまでは直せません。有効な手段は、トークンを失効させることです。

フォークやコピーからHelperをインストールした場合は、ローカルのコピーに長い文字列がハードコードされていないか検索してください。見つかったら削除し、トークンは環境変数から読むようにして、他人が残したトークンは決して使わないでください。当社のサービスでは、MCP設定で${EVERYINFRA_API_KEY}を参照し、それ以外の場所にはキーを書かないでください。Claude CodeのMCPドキュメントによると、.mcp.jsonはこの種の変数展開に対応しています。チームでキーを共有せずに設定ファイルを共有できます。

api tikhub ioとapi.tikhub.dev：Pythonのurllibが接続できない理由

「api tikhub io」で検索する人の多くは、コードやエラーメッセージでこのドメインを目にしています。api.tikhub.ioはTikHubのメインドメインです。ルートパスはSwaggerページになっており、トークンを入力してブラウザで呼び出しを試せます。api.tikhub.devというドメインもあり、Helperはこれを「ネットワーク制限を回避するための中国向けドメイン」と呼んでいます。

TikHubのREADMEは、ドメインと接続に関する注記で別のことを述べています。api.tikhub.ioを使い、遅くなることがあるapi.tikhub.devは避けるよう求めています。リクエストに30秒以上かかる場合は、自前のプロキシを用意するよう勧めています。

Helperをブロックしているのはドメインではなく、リクエストヘッダーです。Helperのapi_client.pyはPython標準のurllib.requestでリクエストを送り、User-Agentを設定していません。そのため、Pythonのドキュメントにあるデフォルト値、つまり「Python-urllib/」にバージョンを付けた値が使われます。SGTの00:20:21に、Helperをそのまま使って、トークン不要のヘルスチェックエンドポイント/api/v1/health/checkを呼び出したところ、「HTTP 403: Forbidden」が返りました。

次に、同じアドレスにヘッダーを変えてリクエストを送りました。結果は下の表とグラフのとおりです。403のボディはいずれも「error code: 1010」の1行で、レスポンスヘッダーはserver: cloudflareでした。

1010はCloudflareのエラーコードです。このエラーに関するCloudflareのページによると、サイト所有者がブラウザのシグネチャに基づいてアクセスをブロックしたことを示します。よくある原因の一覧には「the default Python urllib user agent」が挙げられています。CloudflareのBrowser Integrity Checkはデフォルトで有効で、User-Agentがないリクエストや一般的でないUser-Agentのリクエストをブロックします。Cloudflareが示す対処法は、「my-app/1.0」のように送信元を示すUser-Agentを送ることです。ブラウザを装う必要はありません。

この結果には限界があります。テストはシンガポールの1つのネットワークから、2回しか行っていません。TikHubは独自にCloudflareのルールを設定しているため、地域や時間によって結果が変わる可能性があります。ただし、2回とも、両ドメインで同じ結果でした。

AIエージェントにとって、この403は401よりも扱いにくいエラーです。HelperはJSONでないボディの403を受け取ると、{"error": "HTTP 403: Forbidden", "status_code": 403}だけを返します。肝心の手がかりである「1010」は失われます。SKILL.mdのエラー表には、401、429、接続エラー、パラメータの欠落の4つのケースしかなく、403の行はありません。

TikHubのREADMEは、403の理由として4つを挙げています。トークンにそのルートの権限がない、アカウントが停止されている、メールアドレスが未確認、トークンの権限が不足している、の4つです。ドキュメントを注意深く読むモデルは、この403をほぼ確実にトークンの問題として扱い、メールアドレスの確認や新しいトークンの作成を勧めるでしょう。実際の修正はヘッダーの1行だけです。_build_headersにUser-Agentの行を追加します。

# _build_headers in api_client.py: add only the User-Agent line, keep the rest
def _build_headers(self, content_type: str = "application/json"):
    return {
        "Authorization": f"Bearer {self.api_token}",
        "Content-Type": content_type,
        "User-Agent": "my-tikhub-agent/1.0",  # without this line, Cloudflare blocks the default urllib header with 1010
    }

EveryInfraでも同じPython-urllibヘッダーでテストしました。SGTの00:26:04にTikTokの機能カタログを読み込み、00:26:05にMCPのツール一覧をリクエストしたところ、どちらも200が返りました。同じ素のPythonコードが、一方では動き、もう一方ではブロックされます。エージェントが書くスクリプトの多くは、まさに追加ライブラリを使わないこの種のコードです。

1回の呼び出しに何ステップかかるか：Helper、TikHub MCP、EveryInfraのリモートMCP

ここまでの内容をまとめます。1つのTikTokアカウントのプロフィールデータをエージェントが取得する、というタスクを例に、各方法で何ステップかかるかを示します。Helperについては、変数名とヘッダーを修正した後の最良のケースを想定しています。TikHub MCPについては、MCPページにある設定を使っています。EveryInfraについては、同じ夜に実際に行った呼び出しを使っています。

TikHub MCPはプラットフォームごとに1つのサーバーを用意しています。プラットフォーム一覧はトークンなしで閲覧できます。ツール数はTikTokが163、Douyinが319、Instagramが93、Xiaohongshuが45です。エンドポイント1つが1ツールに対応するため、モデルは目的のツールを直接選べます。その代わり、Douyinのサーバーに接続すると319個のツール説明が読み込まれます。

TikHubの設定例では、npx mcp-remoteを使ってリモートのHTTPサーバーをローカルプロセスに変換しています。認証情報は--header引数で渡します。TikHubのプラグイン設定では、${TIKHUB_API_KEY}で環境変数を参照しています。以下に、TikHubの例（キーを変数参照に置き換えたもの）と当社の例を並べて示します。正確なフィールドは、お使いのクライアントのドキュメントで確認してください。

{
  "mcpServers": {
    "tikhub-tiktok": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.tikhub.io/tiktok/mcp",
               "--header", "Authorization: Bearer ${TIKHUB_API_KEY}"]
    },
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

当社のMCP接続先はhttps://api.everyinfra.com/mcpの1つだけです。00:21:08 SGTに、キーなしでツール一覧をリクエストしたところ、12個のツールが返され、レスポンスサイズは16,247バイトでした。さらに、全ツール用の/mcp/allにはアカウント用ツールが12個（利用状況、請求、キーなど）あり、合計24個です。詳しくは/mcp-serverを参照してください。データ機能ごとにツールを1つずつ用意しているわけではありません。すべての機能はeveryinfra_call_apiを経由し、platformとactionの2つのパラメータで機能を選択します。たとえばtiktok/profileです。

この設計の利点は、ツール一覧が小さく、新しい機能が追加されても設定を変更する必要がないことです。その代わり、モデルはaction名を知るために先にカタログを読む必要があります。カタログはキーなしで利用できます。GET /api/v1/social/catalog?platform=tiktok&compact=1はTikTokの分だけを返します。00:18:12 SGT時点で6,835バイトあり、すべてのTikTokの機能のパラメータ、料金、フィールド名が含まれていました。

MCPの仕様はどちらの設計も認めています。2026-07-28版仕様の認可に関するセクションには、認可は任意であると記載されています。どちらのサービスもOAuthは使っていません。どちらもキーをリクエストヘッダーで送信しており、これはRFC 6750のBearerヘッダー形式に沿ったものです。

間違えたときに何が起きるか：400、422、did_you_meanを検証

エージェントの誤りで最も多いのは、別のサービスの命名規則を使ってしまうことです。そこで、直前までTikHubを使っていたエージェントの挙動を再現しました。00:21:08 SGTに、TikHub形式のactionであるfetch_user_profileとパラメータuniqueIdを指定したリクエストを1件送信しました。続いて、正しい機能名にHelperの例にあるパラメータsec_user_idを組み合わせた2件目のリクエストを送信しました。

1件目のリクエストでは、HTTP 400（unknown_capability）が返されました。did_you_meanはprofileで、allowedにはTikTokのデータ機能24個がすべて列挙されていました（前述のMCPツール24個とは別の24個です）。next_stepsには、profileで再送すること、そして課金は発生していないことが記載されていました。2件目のリクエストでは、HTTP 422（missing_param）が返されました。

そのnext_stepsには、必須のusernameを追加すること、そしてsec_user_idはここではパラメータではないことが記載されていました。また、そのまま実行できるexampleも含まれていました。どちらのリクエストにも費用はかかりませんでした。

TikHubと比較してみます。TikHubはトークンがない場合、まず認証をチェックします。00:20:40 SGTに、誤ったパラメータpost_idを指定し、トークンなしで投稿詳細エンドポイントを呼び出したところ、401が返されました。

ボディにはルートとパラメータがそのまま返されていましたが、誤ったパラメータの指摘はありませんでした。openapi.jsonによると、トークンがある場合、必須パラメータが不足しているとFastAPIの422が返されます。このレスポンスは不足しているフィールドの名前を示しますが、正しい名前は提案しません。

当社も、まず認証、次にパラメータのチェックという順序です。キーがなければ401が返るため、認証のないリクエストからAPIの構造を知ることはできません。キーがあれば、不明なパラメータや不正な値に対して、サポートされているパラメータ、許可されている値、did_you_meanを含む422が返ります。このルールの目的は、呼び出し側のAIが自分の誤りを自分で修正できるようにすることです。誤った呼び出しのたびに費用がかかるべきではありません。

APIを実際に3回呼び出す：MCP経由で1回、curlで2回

ここからは実際の呼び出しです。2つのプラットフォームにまたがる3つの機能を選び、2通りの方法で呼び出しました。料金はいずれも1回の呼び出しあたり$0.000556です。各呼び出しについて、SGTの時刻、取得件数、charged_usdを記録しました。

3回の呼び出しの費用は合計$0.001668でした。所要時間については正直にお伝えしておく必要があります。各呼び出しには30秒、38秒、19秒かかりました。これは同期処理の結果を待つ時間です。

この速度は、ページを見ながら待つ人よりも、バックグラウンドで動くエージェントに向いています。当社はTikHubのアカウントを持っていないため、TikHubの速度は測定できませんでした。TikHubのREADMEでは、タイムアウトを30〜60秒に設定するよう案内しています。

返されるフィールドは、カタログのresponse_fieldsで定義されています。profile機能はfollower_countやvideo_countなど16個のフィールドを返します。videos機能は30個以上のフィールドを返します。comments機能にはlike_count、reply_count、ip_location、次ページ取得用のnext_page_tokenが含まれます。以下は2回目の呼び出しのcurlリクエストです。キーは環境変数からのみ読み込みます。

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"tiktok","action":"user_videos","params":{"username":"tiktok"}}'
# returns count: 10, billing.charged_usd: 0.000556

料金比較：TikTokとDouyinで各1,000リクエスト

この料金のセクションはあえて短くしています。詳しい内訳はTikHubの料金体系を解説を参照してください。TikHubについては、00:18:13 SGTに取得した料金表と、00:16 SGTに閲覧した料金ページを使いました。当社の呼び出しに対応するエンドポイントは、TikTokのプロフィールfetch_user_profile、TikTokの動画fetch_user_post、Douyinのコメントfetch_video_commentsです。

いずれも1回の呼び出しあたり$0.001です。TikTokとDouyinには料金設定のあるエンドポイントが合計658個あり、そのうち529個は1回の呼び出しあたり$0.001です。EveryInfraについては、前述の実際の呼び出し3回で記録したcharged_usd（1回あたり$0.000556）を使いました。

1件あたりの数値について2点補足します。TikHubの動画エンドポイントではcountパラメータを増やせます。1ページあたりの件数が増えるほど1件あたりの料金は下がりますが、上限は検証できませんでした。当社のtiktok/user_videosは1回の呼び出しで10件を返すため、1件あたりの差は1.2倍にとどまります。

TikHubには1日の利用量に応じた割引もあります。あるエンドポイントでは、1日の最初の1,000回を超えると単価が$0.0009、$0.0008と段階的に下がり、30,000回を超えると$0.0005になります。この段階料金を、1日N回呼び出した場合の1,000回あたりの平均料金に換算しました。1日10,000回の場合、平均は$0.86です。

50,000回では$0.632です。1日約117,900回に達して初めて、当社の$0.556まで下がります。それを超えると、TikHubのほうが安くなります。

割引は、割引に対応したエンドポイントにのみ適用されます。$0.001のTikTokとDouyinのエンドポイント529個のうち、割引に対応しているのは52.0%です。たとえば、Douyinの単一動画エンドポイントfetch_one_videoは対象外です。

つまり、答えは利用量によって変わります。1つのエンドポイントで1日数千回から数万回呼び出すエージェントであれば、EveryInfraのほうが安く済みます。割引に対応したエンドポイント1つで1日約118,000回を超える場合は、TikHubの大口料金のほうが低くなります。当社の料金にも月間チャージ額に応じた割引レベルがあり、詳細は料金ページに記載しています。

TikHubの料金ページには、MCPやブラウザ拡張機能を経由した呼び出しも、APIを直接呼び出した場合と同じ料金であると記載されています。これは当社も同じです。MCP、SDK、curlのいずれでも課金されるcharged_usdは同じで、失敗した呼び出しや結果が空の場合は費用がかかりません。

AIエージェントにトークンを渡す前に確認すべき6つのポイント

ここまでの内容を1つのチェックリストにまとめます。TikHubとEveryInfraのどちらを選ぶ場合でも、エージェントが初めて実際の呼び出しを行う前に、以下の6項目を確認してください。各項目には確認方法も記載しています。

第1に、エージェントごとに専用のトークンを用意します。TikHubでは1ユーザーあたり最大100個まで作成できます。当社では、1つのキーから作成できるキーは1日最大20個です。コンソールで作成したキーはこの上限に含まれません。

トークンを分けておけば、どのエージェントがいくら使ったか、どのエージェントがレート制限に達したかを利用記録で確認できます。あるエージェントの設定ファイルを誤って公開リポジトリに入れてしまっても、無効にするのはそのトークン1つだけで済みます。確認するには、各トークンが1つのプロジェクトの環境にだけ設定されていることを確かめてください。

第2に、トークンは環境変数にだけ保存します。スキルファイルには書かず、設定ファイルにも平文で書かないでください。TikHubのプラグインも当社のプラグインも、設定内で${...}を使って変数を参照しており、これが正しいパターンです。Helperの履歴は、その逆の例を示しています。

初期バージョンでコードに書き込まれていたトークンは、後に元のリポジトリから削除されましたが、一部のフォークにはまだ残っています。確認するには、プロジェクトフォルダ内で「Bearer」とトークンの先頭数文字を検索してください。検索結果に表示されてよいのは変数名だけです。

第3に、実行中のコードが読み込む変数名を使います。当たり前に聞こえますが、Helperでは3つの異なる名前が使われています。SKILL.mdにはTIKHUB_TOKENとあり、コードはTIKHUB_API_TOKENを読み込み、TikHubのSDKとプラグインはTIKHUB_API_KEYを使っています。SKILL.mdの名前だけを設定すると、Bearerヘッダーが空のままリクエストが送信されます。

するとTikHubは401を返し、モデルはおそらくトークンが間違っていると判断して、新しいトークンを作るよう提案してきます。確認するには、呼び出しの前にトークンの値ではなく長さを出力してください。長さが0なら、変数名が間違っています。

第4に、まず無料のリクエストを1件実行します。TikHubのヘルスチェックと料金表はトークン不要です。EveryInfraのカタログとMCPのツール一覧はキー不要です。エージェントが使うのと同じHTTPクライアントで、リクエストを1件送信してください。これにより、ヘッダーのブロック（1010）、認証の失敗（401）、パラメータの誤り（422）という3種類の問題を切り分けられます。当社はこの手順で、urllibのデフォルトヘッダーではTikHubのどちらのドメインにも到達できず、curlとrequestsでは到達できることを確認しました。

第5に、レート制限をエージェントへの指示に含めます。TikHubは呼び出し回数をエンドポイント単位でカウントします。74個のエンドポイントにはデフォルトの毎秒10回とは異なる上限が設定されており、最低の上限は毎秒1回です。当社はアカウント単位でカウントし、デフォルトは毎分60回です。

エージェントはデフォルトで並列に動作するため、429を受け取ったら待機するよう明確に指示してください。当社のレスポンスにはRetry-Afterが含まれるため、エージェントはその秒数だけ待機します。TikHubの429の説明は「Request too fast」だけで、公開ドキュメントには待機時間が記載されていません。最初は1秒待ち、新たに429を受け取るたびに待機時間を2倍にすることをおすすめします。

第6に、残高に上限を設け、最も高額な呼び出しを先に把握しておきます。TikHubで料金設定のある1,471個のエンドポイントの大半は、1回の呼び出しあたり$0.001です。しかし、パスに「xingtu」を含むDouyin Xingtuのエンドポイント78個のうち、19個は1回の呼び出しあたり$0.02です。Douyinの総合検索v2は1回の呼び出しあたり$0.01です。

1つのトークンで、料金に20倍の差があることになります。当社では、各機能の料金がカタログに記載されており、エージェントは呼び出し前に確認できます。確認するには、呼び出す前にエンドポイントと料金の一覧をエージェントに作らせ、その一覧を承認してください。残高には、その実行に必要な分だけを入れておきます。

無料のデータ分析スキルとHelperは別物

「tikhub api helper」で検索する人の多くが求めているのは、スキルをインストールして、AIにデータを取得・分析させることです。ここで言うスキルには2種類あります。Helperは「APIの呼び出し方」のガイドです。エンドポイントの探し方とリクエストの組み立て方をモデルに伝えるもので、データの分析は行いません。

EveryInfraにもデータ分析スキルがあります。無料でダウンロードでき、お使いのAIツールとモデルで利用できます。2026-10-15にリリースされたv0.4.1には、EC商品分析、ソーシャルコンテンツのパフォーマンス、コンテンツのタグ付け、レビューインサイトの4つが含まれています。これらのスキルはデータを収集しません。データ収集にはEveryInfra APIを使い、呼び出しごとに課金されます。使い方は、当社の記事4つのAIツールで使える1つのSKILL.mdで紹介しています。

API連携機能は、当社のプラグインリポジトリで提供しています。v0.4.0は2026-10-21に公開され、設定では${EVERYINFRA_API_KEY}を参照しています。2026-11-01には、コマンドラインツールと料金見積もり機能を備えたPyPIのeveryinfra 0.3.0もリリースしました。

収集と分析を分けることは、トークン管理にも役立ちます。分析スキルにはキーがまったく必要ありません。キーが必要なのはAPIのステップだけです。分析はローカルで実行し、収集のステップには権限を絞ったキーを1つだけ渡せます。

TikHubのほうが適している場合

ここからは、TikHubが当社より優れている点です。第1に、エンドポイントのカバー範囲です。現在のドキュメントには1,058個のパスがあります。Douyin Xingtu、DOU+、Xiaohongshu Pugongying、Bilibili Huahuoなど、インフルエンサーマーケティングや広告プラットフォームのデータについて、詳細なエンドポイントが多数あります。こうしたマーケティング管理画面系のエンドポイントは、当社よりも充実しています。

第2に、大量利用時の料金です。割引が適用されるエンドポイント1つで1日あたり約118,000回を超えて呼び出す場合、同社の大口料金は当社より安くなります。第3に、導入コストです。同社の最低チャージ額は$5で当社の$10より低く、$0.05の無料クレジットには有効期限がありません。第4に、生のフィールドです。

TikHubはプラットフォーム独自のデータ構造をそのまま返します。たとえばTikHubのAPIキー、ドキュメント、GitHubを検証では、TikHubはTikTokのフォロワー数を正確な値で返しましたが、当社は丸めた数値を返します。第5に、キーの数です。1ユーザーあたり100個まで作成できるため、プロジェクト単位の費用管理が容易です。Python SDK 2.2.0の説明によると、このSDKは1,048個のエンドポイントに対応し、非同期クライアントも備えています。

前述のスナップショット比較からも、その方向性がわかります。新たに追加された226個のエンドポイントのほぼすべてが、インフルエンサーマーケティングと広告プラットフォーム向けです。ブランドのためにクリエイターを探し、料金表や広告データを読み解くことが目的なら、TikHubは当社よりはるかに深くカバーしています。これらのエンドポイントの多くは$0.001ではないため、料金を1つずつ確認してください。

すでにTikHubを使っていて今後も使い続けたい場合、この記事は3つの点で役立ちます。第1に、古くなったコミュニティ製HelperではなくTikHub公式のプラグインまたはSDKを使ってください。第2に、実行中のコードが読み取る変数名を設定してください。第3に、自作のPythonスクリプトにはUser-Agentを設定してください。

AIエージェントを初めてソーシャルデータにつなぐ場合は、ほかの点のほうが重要かもしれません。たとえば、エージェント自身が修正できるエラー、失敗時に課金されないこと、全プラットフォームで共通して使える1つのアドレスです。1日に数千〜数万回呼び出す場合のコストも重要です。その場合は、EveryInfraのほうがより簡単な選択肢です。

TikHubに関するほかの記事では、別の観点を扱っています。TikHubのAPIキー、ドキュメント、GitHubを検証では、キー、ドキュメントの規模、TikHub SDKの現状を取り上げています。TikHubの料金を解説では、1,000件を超える料金項目を分析しています。TikHubの代替サービスと/alternatives/tikhubでは、全体の比較を紹介しています。

業界ニュース

• 2026年10月22日、AnthropicはAgent Skills標準をAgentic AI Foundationに寄贈しました。同日のLinux Foundationの発表によると、Agent Skillsに対応するエージェントプラットフォームは70以上にのぼります。公開済みのスキルは1百万件、インストール数は約280百万回に達したとも報告されています。開発者にとっては、各SKILL.mdを読み込むツールが増えることを意味します。そのため、スキル内の変数名やエンドポイント名の誤りも、本記事で取り上げたコミュニティ製のHelperのように、フォークやコピーを通じてより広く拡散します。
• 2026年10月24日、Cloudflareは1010エラーのページを更新し、PythonのurllibのデフォルトUser-Agentを名指ししました。影響：追加ライブラリを使わないエージェントスクリプトでは、本番環境で使う前にUser-Agentを設定してください。
• 2026年10月27日、Google CloudはIAM Helperをリリースしました。IAM HelperはAgent SkillsとMCPツールを使い、エージェントが403エラーを調査したり、1時間の一時的なアクセスを申請したりできるようにします。権限を変更する前には人間の承認が入ります。影響：403に対して、エージェントがより多くのアクセス権を求める場面が増えます。その403が実際には1010のヘッダーブロックであれば、アクセス権を増やしても解決しません。まずレスポンスボディを読み、403の発生元を特定してください。
• 2026年10月28日、GitHubはAIによるシークレット検出をプッシュ保護に組み込みました。パブリックプレビュー中で、デフォルトでは無効です。影響：今後、ハードコードされたトークンを含むプッシュを阻止できますが、すでにフォーク内にあるコピーには対応できません。

FAQ

TikHubのAPIトークンはどこで作成しますか？

（出典：「tikhub api token」のGoogleオートコンプリート、2026年11月6日に確認）TikHubのユーザーセンターにログインします。APIトークンのメニューを開き、トークンを作成します。トークンはAuthorization: Bearerヘッダーに入れます。原文はドキュメントサイトのREADME末尾にある「Get API Token」セクションにあり、1ユーザーあたり最大100個まで作成できます。

以前のドキュメントには、スコープと有効期限を設定し、手動で有効／無効を切り替えられると書かれていました。現在の公開ドキュメントにはその方法が記載されておらず、これらは401と403の理由にのみ記載されています。AIエージェントには、エージェントごとに専用のトークンを発行してください。

TikHub API HelperはTikHubが作ったものですか？

（出典：「tikhub api helper」のGoogleオートコンプリート、2026年11月6日に確認）いいえ。検索上位のtikhub_api_skillは個人アカウントのもので、説明文にもTikHubが作ったとは書かれていません。TikHub自身の製品は、GitHubのTikHub Organizationにあるtikhub-plugin（v1.1.0、18スキル）とTikHub Python SDKです。コミュニティ製Helperのスナップショットは25.7%が失われており、デフォルトのurllibヘッダーはブロックされます。代わりにTikHubのプラグインを使うか、先に本記事の2つの修正を行ってください。

api.tikhub.ioが開かない、または403を返す場合はどうすればよいですか？

（出典：「api tikhub io」と「https api tikhub io」のGoogleオートコンプリート、2026年11月6日に確認）まずレスポンスボディを読んでください。「error code: 1010」と書かれていれば、Cloudflareがリクエストヘッダーをブロックしています。クライアントでUser-Agentを設定すれば、問題は解消します。トークンとは関係ありません。JSONボディに、トークンの権限不足やメールアドレスの未確認が書かれている場合は、アカウントの問題です。TikHubは、api.tikhub.ioを使うこと、またリクエストに30秒以上かかる場合は自前のプロキシを用意することを求めています。api.tikhub.devは遅くなることがあります。

TikHubのAPIキーとトークンは同じものですか？

（出典：「tikhub api key」と「tikhub api token」のGoogleオートコンプリート、2026年11月6日に確認）はい。TikHubは場所によって両方の呼び方を使っています。ドキュメントサイトでは「API Token」、チュートリアルページと新しいPython SDKでは「API key」と呼び、環境変数はTIKHUB_API_KEYです。

紛らわしいのは変数名です。コミュニティ製HelperのコードはTIKHUB_API_TOKENを読み取りますが、SKILL.mdにはTIKHUB_TOKENと書かれています。また、TikHubのAIエージェントサービスには別のキーがあり、データAPIでは使えません。

GitHubにあるTikHubのスキルはそのままインストールできますか？

（出典：「tikhub github」のGoogleオートコンプリート、2026年11月6日に確認）TikHubのtikhub-pluginはClaude Codeのプラグインとしてインストールでき、設定では${TIKHUB_API_KEY}を使います。コミュニティ製Helperもインストールできますが、先に3つの作業が必要です。第1に、正しい変数名を設定します。第2に、api_client.pyにUser-Agentを追加します。第3に、ローカルのコピーにハードコードされたトークンがないか検索します。フォークやコピーには初期にハードコードされたトークンが残っている場合があり、そのトークンは使ってはいけません。

TikHubのAI APIとは何ですか？同じキーを使いますか？

（出典：「tikhub ai api」のGoogleオートコンプリート、2026年11月6日に確認）TikHubには、テスト中の別のAIエージェントサービスがあります。TikHubのAPIキー、ドキュメント、GitHubを検証で引用したTikHub自身のドキュメントによると、別のサイトで新規登録し、別のキーを取得します。このキーはソーシャルデータAPIでは使えません。本記事で「トークン」と言う場合は、データAPIのトークンだけを指します。EveryInfraでは、1つのキーでデータ、検索、CAPTCHAの解決の各機能を呼び出せます。また、コンソールではキーごとに各プロダクトを無効にできます。

始め方

1. /docsを開いて新規登録し、コンソールでキーを作成します。キーを環境変数EVERYINFRA_API_KEYに設定します。チャージ前に使えるクレジットを得るには、/pricingの手順に従い、GitHubでスターを付けて$1のトライアルクレジットを受け取ってください。
2. キーなしでカタログを読み取ります（GET https://api.everyinfra.com/api/v1/social/catalog?platform=tiktok&compact=1）。カタログには、TikTokとDouyinの機能と料金が載っています。
3. AIツールにMCPを追加します。アドレスはhttps://api.everyinfra.com/mcpで、認証ヘッダーでは環境変数を参照します。設定方法は/mcp-serverを参照してください。
4. エージェントには、最初にeveryinfra_list_capabilitiesを呼び出すよう指示します。次に、エージェントはeveryinfra_call_apiでtiktok/profileなどの機能を呼び出します。間違えた場合は、レスポンスのdid_you_meanとexampleに従って修正し、課金はされません。

参考文献

1. 「README - English」（API Token Introduction、HTTP Status Codes）、TikHubドキュメント、2026-11-06閲覧、https://docs.tikhub.io/4592766m0
2. 「README - Chinese」、TikHubドキュメント、2026-11-06閲覧、https://docs.tikhub.io/4579297m0
3. 「llms.txt」（ドキュメントサイトのインデックス）、TikHub、2026-11-06閲覧、https://docs.tikhub.io/llms.txt
4. TikHub APIのSwaggerページ、TikHub、2026-11-06閲覧、https://api.tikhub.io/
5. 「openapi.json」（V5.3.2、1,058パス）、TikHub、2026-11-06 00:16 SGT閲覧、https://api.tikhub.io/openapi.json
6. get_all_endpoints_infoの料金一覧（料金設定のあるエンドポイント1,471件、rate_limitフィールド）、TikHub、2026-11-06 00:18 SGT閲覧、https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
7. health/checkエンドポイント、TikHub、2026-11-06 00:20〜00:26 SGTにリクエスト、https://api.tikhub.io/api/v1/health/check
8. 「Pricing」（ボリュームディスカウント、RPSプラン、最低チャージ額）、TikHub、2026-11-06閲覧、https://tikhub.io/pricing
9. 「Tutorials & FAQ」（1ユーザーあたり最大100キー、ステータスコード）、TikHub、2026-11-06閲覧、https://tikhub.io/tutorials
10. 「Getting Started」、TikHub、2026-11-06閲覧、https://tikhub.io/getting-started
11. 「MCP Integration Guide」、TikHub、2026-11-06閲覧、https://tikhub.io/mcp
12. 「MCP platforms」（プラットフォームごとのツール数）、TikHub、2026-11-06閲覧、https://mcp.tikhub.io/platforms
13. 「llms.txt」（メインサイト）、TikHub、2026-11-06閲覧、https://tikhub.io/llms.txt
14. tikhub 2.2.0、PyPI、2026-10-03公開、https://pypi.org/project/tikhub/
15. tikhub 1.13.0（Scopes、Expire Date、Statusの記載）、PyPI、2024-12-05公開、https://pypi.org/project/tikhub/1.13.0/
16. TikHub-API-Python-SDK、GitHub（TikHub）、2026-11-06閲覧、https://github.com/TikHub/TikHub-API-Python-SDK
17. tikhub-plugin（v1.1.0）、GitHub（TikHub）、2026-06-15公開、https://github.com/TikHub/tikhub-plugin
18. tikhub-plugin .mcp.json、GitHub（TikHub）、2026-11-06閲覧、https://github.com/TikHub/tikhub-plugin/blob/main/.mcp.json
19. tikhub_api_skillリポジトリ、GitHub（liangdabiao）、2026-11-06閲覧、https://github.com/liangdabiao/tikhub_api_skill
20. SKILL.md（95b2a10）、GitHub（liangdabiao）、2026-07-08版、https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/SKILL.md
21. api_client.py（95b2a10）、GitHub（liangdabiao）、2026-07-08版、https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/api_client.py
22. api_searcher.py（95b2a10）、GitHub（liangdabiao）、2026-07-08版、https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/api_searcher.py
23. tikhub-api-helper、LobeHub Skills Marketplace、2026-11-06閲覧、https://lobehub.com/skills/liangdabiao-tikhub_api_skill-tikhub-api-helper
24. 「TikHub API Skill」、Shyft、2026-11-06閲覧、https://shyft.ai/skills/tikhub-api-skill
25. 「Tikhub Skill by zeenie-ai」、TypingMind、2026-11-06閲覧、https://www.typingmind.com/skills/zeenie-ai-tikhub-skill
26. OpenCompanyのtikhub-skillソース、GitHub（zeenie-ai）、2026-11-06閲覧、https://github.com/zeenie-ai/OpenCompany/tree/main/server/skills/web_agent/tikhub-skill
27. 「Extend Claude with skills」、Claude Codeドキュメント、2026-11-06閲覧、https://code.claude.com/docs/en/skills
28. 「Connect Claude Code to tools via MCP」、Claude Codeドキュメント、2026-11-06閲覧、https://code.claude.com/docs/en/mcp
29. 「Donating Agent Skills to the Agentic AI Foundation」、Anthropic、2026-10-22、https://www.anthropic.com/news/donating-agent-skills-to-the-agentic-ai-foundation
30. 「Agentic AI Foundation Announces Four New Projects」、Linux Foundation、2026-10-22、https://www.linuxfoundation.org/press/agentic-ai-foundation-announces-four-new-projects-agent-skills-open-responses-openenv-and-opensandbox
31. 「Authorization」（2026-07-28版）、Model Context Protocol仕様、2026-11-06閲覧、https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
32. 「RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage」、IETF、2012-10、https://datatracker.ietf.org/doc/html/rfc6750
33. 「RFC 6585 Additional HTTP Status Codes」（429）、IETF、2012-04、https://datatracker.ietf.org/doc/html/rfc6585
34. 「Error 1010」、Cloudflareドキュメント、2026-10-24更新、https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1010/
35. 「Browser Integrity Check」、Cloudflareドキュメント、2026-11-06閲覧、https://developers.cloudflare.com/waf/tools/browser-integrity-check/
36. 「urllib.request」、Pythonドキュメント、2026-11-06閲覧、https://docs.python.org/3/library/urllib.request.html
37. 「Removing sensitive data from a repository」、GitHubドキュメント、2026-11-06閲覧、https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
38. 定義済みのシークレットパターン以外にも対応するプッシュ保護、GitHub Changelog、2026-10-28、https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns/
39. 「Scale agents securely with IAM Helper Agent Skills and MCP Tools」、Google Cloud、2026-10-27、https://cloud.google.com/blog/products/identity-security/scale-agents-securely-with-iam-helper-agent-skills-and-mcp-tools
40. EveryInfra機能カタログ（TikTok、compact）、EveryInfra、2026-11-06 00:18 SGT閲覧、https://api.everyinfra.com/api/v1/social/catalog?platform=tiktok&compact=1
41. EveryInfra llms.txt、EveryInfra、2026-11-06閲覧、https://api.everyinfra.com/llms.txt
42. everyinfra-agent-plugins（v0.4.0）、GitHub（everyinfra）、2026-10-21公開、https://github.com/everyinfra/everyinfra-agent-plugins
43. analysis-skills v0.4.1、GitHub（everyinfra）、2026-10-15公開、https://github.com/everyinfra/analysis-skills/releases/tag/v0.4.1
44. everyinfra 0.3.0、PyPI、2026-11-01公開、https://pypi.org/project/everyinfra/