Perplexityが示すAgent Skillsの設計・評価・保守原則

Perplexity Researchは、Perplexity Computerなどで使うAgent Skillsの社内設計・レビュー指針を公開しました。スキルを人向け手順書のように書くのではなく、モデルが必要な知識を適切な場面だけで読み込む仕組みとして評価する内容です。

要点

• スキルを作る前に、スキルなしの代表的な依頼で本当に失敗するかを確認します。
• descriptionは機能説明ではなく、エージェントがスキルを読み込む条件を表すルーティング指示です。
• 全スキルの索引、SKILL.md本文、補助ファイルの三段階で文脈費用を管理します。
• 本文を書く前に、読み込むべき依頼と読み込むべきでない依頼の評価例を用意します。
• 保守では失敗事例を追加し、特にdescription変更による他スキルへの影響を再評価します。

今回のブログ記事で語られていること

PerplexityはAgent Skillを、単独のSKILL.mdではなく、スクリプト、参照資料、テンプレート、初回設定を含められるディレクトリーとして説明します。複雑な米国税務スキルでは、内国歳入法典の1,945セクションを一つの階層へ置くと、スキルを読み込まない場合より性能が下がったとしています。そこで分野を複数段階に整理し、早見表や検索手段を用意しました。重要なのは資料を増やすことではなく、モデルが必要な情報へ迷わず到達できる構造を人が設計することです。

スキルのnameとdescriptionは、利用者向けの紹介文ではありません。特にdescriptionは、いつスキルを読み込むかをモデルへ伝えるルーティング条件です。Perplexityは「このスキルは何をするか」ではなく「このような依頼が来たときに読み込む」と書き、50語以下を目安に実際の利用者の意図を表すよう勧めます。範囲が広すぎれば無関係な依頼で読み込まれ、狭すぎれば必要な場面で使われません。スキルを一つ追加するだけでも他のスキルの選択精度を下げ得るため、ルーティングの副作用を重視しています。

文脈費用は三段階です。全スキルの名前と説明を並べる索引は、スキルごとに約100トークンを毎セッション支払います。選択されたSKILL.md本文は約5,000トークンを目安とし、会話が圧縮されるまで文脈を使い続けます。scripts/、references/、assets/などは必要になったときだけ読み込む領域で、条件分岐が多い情報や重い資料を置きます。この段階的な開示により、常に必要な判断と、特定条件でだけ必要な詳細を分けます。

スキルが必要かどうかは、設計者の直感だけでは決めません。まずスキルなしで代表的な依頼を実行し、モデルが特別な文脈なしでは間違えるか、実行ごとに結果が不安定かを確認します。モデルがすでに知っているGitコマンド列、ほとんどの依頼に共通する方針、保守できない速度で変化する外部ツール情報は、スキルに入れない例です。各文について「この指示がなければモデルは間違えるか」を問い、不要な文章を文脈への課税として扱います。

作成手順では本文より評価を先に置きます。実際の利用者依頼、過去の失敗、近い別領域と混同しやすい依頼を集め、読み込むべき例と読み込まない例を用意します。否定例は、過剰なルーティングを防ぐうえで特に重要です。その後にdescription、本文、補助階層を作り、複数回の評価を経て公開します。本文ではコマンドを細かく固定するより、守るべき意図、例外、失敗しやすい点を記します。保守時は新しい失敗事例を蓄積し、短い文言変更でもルーティング評価をやり直します。

今回のブログ記事が関係する人

社内業務をAIエージェントへ委任する開発者、CodexやClaudeなどへ再利用可能な手順を追加する基盤担当、複数スキルの選択精度を管理する人、エージェント評価とレビュー工程を整備するチームに関係します。

結局、今回のブログ記事をどう読むべきか

スキルの価値をファイル数や説明量で測らず、必要な依頼でだけ読み込まれ、スキルなしでは難しい判断を改善できるかで測る提案です。導入チームは、本文作成より先に基準となる失敗と評価例を集め、ルーティング、文脈費用、他スキルへの影響を継続的に検証する必要があります。