Agent First な公開データ Skills: タスクから MCP へ

要点: これは UnifAPI の Skills ファーストなブログクラスターの中心となる主張です。エージェントのタスクから始め、根拠が必要になったら MCP を接続し、APIs は公開データレイヤーとして保つ、という考え方です。

UnifAPI の最初のバージョンは、開発者向け製品のように見えていました。カタログ、エンドポイント、API キー、ドキュメント。そのサーフェスは作り手にとって今も必要ですが、ほとんどのエージェント運用者は自分の仕事をそう表現しません。彼らは朝起きて「Twitter のエンドポイントが欲しい」とは思いません。欲しいのは、KOL の料金算定ブリーフ、クリエイターのショートリスト、競合のローンチサマリー、Reddit のリサーチ一巡、あるいは信頼できる根拠付きのソーシャルリスニングレポートです。

だからこそ、UnifAPI のマーケティングサーフェスは Agent First な Skills へと移りました。Skill とは、エージェントが UnifAPI MCP を通じて実行できるタスク特化のワークフローです。API カタログはワークフローの下にある公開データレイヤーとして残り続けます。ただ、マーケターやリサーチャーに最初に理解してもらうものではなくなった、というだけです。

短い要約

ポイントは API を隠すことではありません。API を適切な抽象度に置くことです。開発者は今も /apis/twitter を呼んだり /openapi.json を読んだりできます。運用者は /skills/kol-pricing から始め、プロンプトを Codex や Claude Code に貼り付け、https://mcp.unifapi.com を接続し、必要なときにエージェントに根拠を取得させられるべきです。

何が Skill になるのか

Skill は、情報源ではなく成果から始まります。良い Skill 名は、人が割り当てる仕事のように聞こえます。KOL キャンペーンの料金を算定する、クリエイターのショートリストを作る、市場を監視する、競合を説明する、Reddit コミュニティをマッピングする。悪い Skill 名は実装の詳細のように聞こえます。Twitter 検索を呼び出す、Reddit のコメントを取得する、TikTok の動画を一覧する。

そのうえでページは、6 つの実践的な問いに答えるべきです。どんな結果が得られるのか。どんな入力を提供する必要があるのか。エージェントはどんな公開データを使えるのか。出力はどう見えるのか。このワークフローが知らないことは何か。最初の回答が役に立った場合、次に何を尋ねるべきか。

最後の問いが重要です。Skill はミニ SaaS アプリでもなければ、静的なテンプレートでもありません。会話型のワークフローです。エージェントは、欠けているキャンペーンの背景を尋ねたり、追加のプラットフォーム検索を実行したり、確信度を説明したり、2 人のクリエイターを比較したり、結果を別の市場に絞り込んだりできます。新しい GUI は必要ありません。

具体例: KOL の料金算定

KOL の料金算定は、最初の基準として象徴的な例です。エージェントのワークフローがうまく扱える形で「ぐちゃぐちゃ」だからです。公開データは、クリエイターのアイデンティティ、最近の投稿頻度、エンゲージメント、トピックの適合性、オーディエンスのシグナル、リスクの注記を示せます。一方で、クリエイターの実際の見積もり、パッケージ条件、利用権、独占性、過去の取引関係は知ることができません。

役に立つ Skill は、その両面を見えるように保ちます。単一の正確なスポンサー料金を知っているふりをするのではなく、エージェントに料金レンジ、確信度、根拠、前提、フォローアップの問いを返させます。それは、実際のバイヤーの仕事 — 交渉に備え、適切なクリエイターをショートリスト化し、どこにより深いアプローチをかける価値があるかを判断する — によりよく合致します。

なぜ MCP がオンボーディングを変えるのか

MCP 以前、運用者はしばしばデータベンダーを選び、API キーを作り、そのキーをアプリに渡し、別途 LLM プロバイダーを配線し、それから GUI が頭の中のワークフローと一致することを祈らなければなりませんでした。MCP はその順番を変えます。ユーザーは、すでに使っているエージェント製品の中のタスクから始められます。OAuth は、エージェントが UnifAPI のツールを呼び出したり、ワークスペースのクレジットを消費したりする必要があるときに開きます。

ホスト型の UnifAPI MCP サーバーは、エンドポイントごとに 1 ツールではなく、3 つのツールを通じてカタログを公開します。エージェントは list_operations で何が存在するかを発見し、get_operation でスキーマとサンプルを検査し、call_api で具体的な公開データの操作を実行します。これにより、HTTP API カタログが成長しても MCP サーフェスはコンパクトに保たれます。

これはまた、モデルの実行とデータアクセスを分離します。ユーザーのエージェントプランがモデルの推論を担い、UnifAPI がライブの公開データレコードを提供してレコードレイヤーで課金します。この分離により、Skill は製品コードになる前に試しやすくなります。

なぜ APIs は今も重要なのか

Skills には信頼できるデータが必要です。動いているワークフローを開発者が本番システムへと変えていくため、ライブの API カタログは今も可視で、検索可能で、ドキュメント化されています。変わるのは順番です。Skills が先、APIs が後。カタログはリリース済みの APIs だけを表示するので、エージェントがロードマップ上の項目を呼び出そうとすることはありません。

API レイヤーはまた、Skill を曖昧なプロンプトエンジニアリングから守ります。公開データの操作には、名前付きパス、パラメータスキーマ、ページネーションの挙動、レスポンスの形式、課金メタデータがあります。エージェントが悪い呼び出しをした場合、トレースを見れば、問題がプロンプトだったのか、操作の選択だったのか、プロバイダーの応答だったのか、リシェイプレイヤーだったのかが分かるはずです。

Skill ページに含めるべきもの

優れた Skill ページには、平易な言葉での仕事の説明、コピー可能な実行プロンプト、必須の入力、任意の入力、関与する公開データ APIs、期待される出力テンプレート、コストの見込み、確信度のルール、リスクの境界、関連する Skills を含めるべきです。ページはまた、別のエージェントが視覚レイアウトに依存せずワークフローを読めるよう、markdown の代替版も公開すべきです。

検索と AI 発見の形

検索について、Skills はユーザーがすでに使う言葉に一致します。KOL 料金算定エージェント、クリエイターリサーチエージェント、エージェント向けの公開データ Skills、マーケティングリサーチ向けの MCP Skills、競合インテリジェンスエージェントなどです。AI 検索とエージェントの検索について、同じ事実が HTML、markdown、構造化データ、llms.txt、内部リンクで利用できる必要があります。

ポイントは検索エンジンや AI の回答を欺くことではありません。ページをユーザーが実際にやろうとしている仕事に一致させ、同じ信頼できる事実を複数のクロール可能な形式で公開することです。それはサイトを正直にも保ちます。Skill ページがワークフローで何かができると書くなら、MCP カタログと API 契約がそれを裏付けているはずだからです。

出典メモ

本記事は 2026 年 6 月 2 日に、現行の UnifAPI 製品コンテキスト、ライブの Skills/API サーフェス、そして公式の Model Context Protocol の紹介 に照らして更新しました。Skills をワークフローのガイダンスとして、MCP を接続経路として意図的に扱っており、すべての API エンドポイントが個別の MCP ツールだと主張するものではありません。

次に読むべきもの

MCP で KOL 料金算定エージェントを動かす - Skills の位置づけを具体的なワークフローに落とし込みます。

最小実用エージェントスタック - 再現可能な公開データ Skill の背後にあるスタックを示します。

UnifAPI Skills を見る - 戦略からライブのタスクページへと移ります。