スキルと選択の仕組み
能力パックがモデルにどのように到達するか — 共有プラットフォームライブラリ、意図に基づく検索、手順とともに提供されるツール、そしてリクエストが曖昧な場合の再確認。
スキルは、パッケージ化された作業方法です。適用されるタイミングを示す短い行、完全な手順、そしてその手順に必要なツールから成ります。この行は毎ターンプロンプトに含まれますが、手順はスキルが選択された場合にのみ取得されます。この分離により、エージェントはすべてのメッセージに対してコストを支払うことなく、多くの機能を実行できます。
このページでは、最も難しい部分、つまり利用可能なものの中からどれが使用されるか、そして明らかに適合するものが何もない場合にどうなるかについて扱います。
2つのライブラリ、1つの空間
すべてのエージェントは、2つの場所からスキルを取得します。1つ目はエージェントに明示的に教える必要はありません。
- プラットフォームスキル — 一般的な作業方法（競合他社の調査、規制の読解、見込み客の評価）。すべてのエージェントにデフォルトで利用可能です。
- あなたのスキル — あなたが自社のビジネス用に記述し、各エージェントに紐付けたスキル。
これらは一緒に検索されます。空間を共有しても、あなたのスキルが不利になることはありません。193の一般的なスキルに混ぜられた18の真に業界固有のスキルで測定すると、業界固有のスキルの方がより確実に認識されました（86%対79%）。業界固有の用語（HSコード、輸出還付金、店舗のコンプライアンス）は、一般的な方法の用語から遠く離れているため、選び出すのは難しくなく、むしろ容易です。
検索、完全なリストでは機能しなくなるため
訪問者がそのように言った、その瞬間のメッセージ。
各スキルは、その説明および例文によってインデックス付けされます — 人がそれを依頼する際に使用する自然言語の表現です。1つの文を定義と照合するよりも、1つの文を別の文と照合する方がうまく機能します。
最も近い15件がモデルに表示され、それぞれにいくつかの例文が含まれます。ライブラリ全体ではありません：207のスキルをすべてリストした場合、モデルは**30%**の確率で正しく選択しました。15件に絞り込むと、**51%**となりました。
モデルが1つを選択します — または選択しない場合もあります。これは有効な結果であり、しばしば正しい選択です。
今になって初めて完全な手順が取得され、今になって初めてスキルの独自ツールが利用可能になります。
スキルが概ね8つ以下の場合、検索は行われません — 完全なリストが単純に表示されます。
スキルが概ね8つ以下の場合、これらは実行されません — 完全なリストが以前と同様に表示されます。その規模ではリストはすでに正確であり、検索は失敗する新たな方法をもたらすだけです：候補の絞り込みから正しいスキルが欠落し、モデルが自身の知識から回答し、ログにそれを示す何もない状態になります。
手順がツールに先立つ
スキルの独自ツールは、ターンの開始時には利用できません。スキルを読み込むことで、それらが利用可能になります。
この順序はプロンプトで要求するのではなく、コードで強制されます。その理由は測定結果によるものです。ある会社の競合他社を調査するよう求められ、手順とツールが一緒に渡された場合、モデルはウェブ検索を3回実行しましたが、手順を開くことはありませんでした。記憶から競合他社の名前を生成し、その捏造された名前で検索し、何も見つかりませんでした — それらは存在しませんでした — そしてそれを回答として書き上げました。手順のステップ1は「まずこの会社が実際に何を販売しているかを確立する」と述べていましたが、モデルはそれを読みませんでした。
任意の手順は読まれません。 エージェント自身が持つツールは影響を受けません：web_searchがエージェントにある場合、それは終始利用可能です。スキルによって到着するツールのみが、そのスキルの読み込みを待ちます。
一部のスキルは、開始前に材料を受け取る
空の机から始まる調査スキルが事実を得られる場所は一つしかありません。モデル自身の記憶です。そのため、それを宣言したスキルについては、プラットフォームがスキルの実行前に最初の調べ物を済ませます。訪問者の一文を検索クエリに変え、実行し、その結果を番号付きの事実表として渡します。回答はその表を出典として示すことが前提です。
幅はスキルごとに決めます。ただではないからです。いくらか、どんな制限があるか、自分のデータをどう持ち出すか——このように複数の問いが同時に入った質問は、二回の検索では答えられません。まさにその質問で計測したところ、狭い探索では 2,957 語に対して出典は 5 件、そこに書かれた価格はどれも、どの情報源にも存在しない具体的な数字でした。調査系スキルの探索を広げると、同じ質問が 17 件の出典を伴って返り、技術比較は 5.7 件から 11.7 件になりました。文章を書く・書き換える・計算するスキルは何も宣言せず、何も検索しません。
その同じスキルの手順には、平易な言葉で材料にない価格は決して書かないことと既に書いてありました。それでも書きました。プロンプトの中の規則は、お願いにすぎません。答えを変えたのは、十分な材料を渡したことです。
これに伴い、もう一つ変える必要がありました。最悪の組み合わせ——検索したのに本文を一ページも開いておらず、答えがスニペットからしか来ない——を見張る仕組みは既にありました。それが問うていたのは、 モデルが検索したかどうかでした。プラットフォームがスキルの代わりに検索したターンでは、モデルは何も呼び出していないため、この仕組みは本来最も働くべきターンで身を引いていました。今は、誰が実行したかに関わらず、このターンに検索結果があるかどうかを問います。
明らかに適合するものが何もない場合、尋ねる
一部の依頼は、真に1つのスキルを指していません。プラットフォームは、モデルに自信があるかどうかを尋ねるのではなく、検索スコアがどれほど密にクラスタ化されているかを見ることで、その状況にあることを認識できます。上位15件の候補がほとんど差がない場合、検索には意見がなく、それでも回答しようとするとコイン投げと同じです：その範囲では、正しいスキルが最初にランク付けされるのは**26%の時間だけであり、スコアが広がっている場合は85%**です。
したがって、その範囲内、そしてそこだけで、エージェントはまず1つの質問を行います — パラメータを要求するのではなく、2つまたは3つの自然なオプション（「現在の市場価格が必要ですか、それともこの特定の物件の評価が必要ですか？」）を提供します。最も難しい四分の一の依頼において、これは平均1.5回の質問で、精度を**36.7%から63.3%**に引き上げました。
モデルに自分で尋ねるかどうかを判断させることは機能しません：判断を求められた場合、**81.5%**のターンで尋ねました — 正解できたはずのすべてのターンも含みます。スコアの広がりに基づいて制限すると、**11%**のターンで尋ね、同じ恩恵をもたらします。
これは製品全体に通じる同じ原則です。機械は依頼の曖昧さを測定できますが、「確信がありますか？」とモデルに尋ねると、yesと答えます。メッセージが何を求めているかの決定を参照してください。
実務における意味
- エージェントは、構成されていなくても一般的な作業方法を知っており、それらを知っていることはメッセージごとにコストがかかりません。
- あなたのスキルはあなたのビジネスで勝つ — それが業界固有の用語の目的です。
- スキルは手順に従うか、実行されません。 ツールを掴んで即興で振る舞うことで、半分だけ従うことはできません。
- 調査系スキルは、記憶ではなく出典を机に置いた状態で始まります。 書かれる内容はその材料を出典として示し、材料が扱っていないことは「見つからなかった」と報告されます。
- 曖昧な依頼には推測ではなく質問が返ってくる — そしてその質問は、システムが真に判断できない限られた少数のターンで届きます。