手続き的ギャップ（procedural gap）とは、エージェントスキルに関する包括的サーベイ：分類、技法、応用 が、LLM ベースの エージェントが外部の能力にアクセスできることと、それらを用いてタスクを堅牢に遂行することとの間の距離に与えた名前である。 API、プラグイン、あるいは Model Context Protocol のようなプロトコル層を通じてツールにアクセスできても、 ある能力をいつ呼び出すべきか、複数のツールをどう協調させるべきか、失敗をどう扱うべきか、出力をどう検証すべきかは 決まらない。このサーベイの主張によれば、そうしたオーケストレーションを推論時のモデルに委ねたままにすると、それは 脆さ、高いレイテンシ、信頼性の低さの主要な原因となり、とりわけタスクが長期的かつ異質なものになるほどそうなる。
用法
このサーベイは、エージェントの能力スタックの中で Agent Skills がどこに位置するかを示すためにこの用語を 用いている。サーベイは、事前学習、ファインチューニング、アラインメントを通じてモデルのパラメータに吸収された受動的な 知識 — 静的で不透明であり、専門的な領域や変化の速い領域ではしばしば弱い — と、実行時に文書を検索し、ツールや API を 呼び出し、MCP サーバーにアクセスし、スキルを実行することで得られる能動的な知識とを区別する。能動的な知識のほうが 動的で現実に根ざしているが、サーベイの説明では、それにアクセスできても、何を、いつ、どの順序で使うべきか、その出力を どう確かめるべきかはやはり決まらない。それがこのギャップである。
サーベイが示す例は、ツールが公開するのはアトミックな能力 — 何ができるかであって、それをどう使うべきかではない — だという ものである。検索ツールは、どんなときに検索が記憶の想起より望ましいかを教えてくれない。API ツールは、スキーマが変わったとき にどうすべきかを教えてくれない。コードインタプリタは、出力をどう検証すべきかを教えてくれない。サーベイは MCP や同種の インフラを、この手続き的な問題ではなく相互運用性の問題を解決するものと読み、スキル — 外部の能力をいつ、どのように 適用すべきかを規定する、再利用可能な手続き的成果物 — を、このギャップを埋めるものとして提示している。
関連用語
- Agent Skills — サーベイがこのギャップを渡る橋として提案しているもの
- 関数呼び出し — このギャップがその上に位置する、能力へのアクセス
- Model Context Protocol — サーベイが、このギャップではなく相互運用性を解決するものと読むインフラ