ツールへのゲートとしてのスキル：コンテキストの拡張

NanthAI:Edgeの技術事例研究です。

多くのAIエージェントは、規模の拡大のさせ方を誤っています。新しい機能のたびに、プロンプトの文章もツールのスキーマも増え、モデルが選択を誤る機会が増えます。NanthAI:Edgeでは、これは単なる理論ではありません。現在、表示対象のスキルカタログはメタデータで約5.1kトークンですが、表示対象のスキル本文をすべて合わせると約67kトークンです。基本レジストリが公開するツールは4つで、完全に展開したレジストリでは115です。これでタスクの成功率向上が証明されるわけではありませんが、提示するコンテキストの範囲が大幅に小さいことは証明できます。

要旨

ツールを使う大規模言語モデル（LLM）エージェントには、機能の幅広さとコンテキストの効率の間に構造的な緊張関係があります。ワークフローの指示やツールのスキーマをモデルのコンテキストに追加するたびに、トークンを消費し、遅延と費用が増え、ツール選択の信頼性が低下する可能性があります。本記事では、スキルをゲートとする段階的なツールアクセスという設計パターンを展開します。コンパクトでキャッシュが安定するスキルカタログが、必要時の指示読み込みと、実行可能なツールレジストリの段階的拡張の両方を仲介するものです。

スキルは、メタデータ、動作に関する詳細なガイダンス、必要なツールプロファイルの宣言を備えた、モジュール化され探索可能な指示パッケージとして扱います。すべてのスキルとツールを毎回のリクエストに入れる代わりに、まず軽量なスキルのメタデータを提示します。タスクがスキルに一致するとモデルがload_skillを呼び出し、読み込まれたスキルが詳細な指示を追加して、関連するツールプロファイルを有効化します。

本記事は、プロンプトの肥大化、関数呼び出しのスケーラビリティ、検索に基づくツール選択、プロンプトキャッシュ、段階的開示、モジュール型エージェントアーキテクチャに関する文献と対比して、このパターンを位置付けます。そのうえで、システムの作者から提供された実装の詳細を使い、具体的な事例としてNanthAI:Edgeを分析します。NanthAI:Edgeは、アカウントのプラン、スキル、実行可能なツールという3層で機能を構成しています。本記事では、このアーキテクチャの期待される利点、中心的なリスク、実装上のトレードオフを説明します。

スキルをゲートとするツールレジストリのワークフローの概要

1. はじめに

現代のエージェント型LLMシステムは、通常、システムの指示、ツールのスキーマ、会話の状態という3種類のコンテキストを各リクエストに組み合わせて構築します。エージェントの機能が増えると、各層も大きくなりがちです。新しいワークフローはプロンプトの指示を、新しい連携はツールのスキーマを、新しいユーザーの好みやメモリはコンテキストを増やします。システムは多機能になりますが、次第に重くなります。

ここには、関連する2つの問題があります。

1. プロンプトの肥大化は、動作の指示、ポリシー、ワークフローのガイダンス、例、メモリ、コンテキストに関するルールが、システムプロンプトに大量に蓄積するときに起きます。
2. ツールレジストリの肥大化は、現在のタスクに関連するかどうかにかかわらず、多数の実行可能なツールをモデルに提示するときに起きます。

どちらも高くつきます。入力トークンを消費し、遅延とプロバイダーの費用を増やし、プロンプトキャッシュを複雑にします。さらに、判断の質を下げる可能性があります。数十、数百のツールから選ぶモデルは、より多くの候補を比較し、より多くの説明に注意を向け、意味の重なりを解消しなければなりません。

検索で補強したツール選択に関する最近の研究は、この懸念を裏付けています。GanとSunのRAG-MCP研究は、すべてのスキーマを渡す代わりに関連するスキーマを検索することで、MCPBenchのあるWebSearch構成における選択精度が13.62%から43.13%に向上し、プロンプトのトークン数がほぼ半減したと報告しています。これらは特定のベンチマークの数値であり、無条件に一般化すべきではありません。しかし、すべてのツールを横並びで提示するのは、情報設計として適切でないことが多いという、根本的な問題を示しています。

本記事では、構造化された代替案として、スキルをゲートとする段階的なツールアクセスを検討します。

パターンは単純です。

1. 利用可能なスキルのコンパクトなカタログを提示します。
2. モデルがload_skillで関連するスキルを読み込めるようにします。
3. 有効化した後にだけ、スキルの指示全文を入れます。
4. 読み込んだスキルが必要とするプロファイルを通じてのみ、有効なツールレジストリを拡張します。

この設計は、UXにおける段階的開示と、ソフトウェアアーキテクチャにおける情報隠蔽を、LLMのコンテキストウィンドウの経済性に応用します。詳細を人間のユーザーから隠すのではなく、タスク上、提示する理由ができるまでモデルから隠します。

このパターンを、アカウント機能の階層化、スキルの探索と読み込み、プロファイルをゲートとするツール拡張を実装した商用エージェントランタイム、NanthAI:Edgeを通じて分析します。本記事のNanthAI固有の詳細は、システムの作者が提供した事例研究用の実装情報です。

本記事の貢献は次のとおりです。

1. スキルを指示とツールへの段階的なゲートとして捉える概念的な枠組み。
2. NanthAI:Edgeの3層アーキテクチャの事例分析。
3. キャッシュの安定性、ルーティングの意図、プロファイルに基づくレジストリ拡張の考察。
4. スキル選択の誤りと読み込み漏れを重視したリスク一覧。

2. 背景：プロンプトの肥大化、ツールのスキーマ、エージェントによるツール利用

2.1 関数呼び出しとツールの提示

関数呼び出しAPIでは、名前、自然言語の説明、構造化されたパラメータのスキーマで、ツールをモデルに説明する必要があります。モデルは、ツールを呼ぶか、どのツールを呼ぶか、どの引数を渡すかを決めます。Berkeley Function Calling Leaderboardなどのベンチマークは、単一ターン、複数ターン、並列呼び出し、関連性を考慮した条件で、この能力を評価します。

ツールの利用は、1つの能力ではありません。複数に分かれます。

• ツールの選択：正しい関数を選ぶこと。
• 引数の構築：形式上有効で、意味も正しいパラメータを作ること。
• 呼び出しの順序付け：正しい順番でツールを呼ぶこと。
• 結果の解釈：ツールの出力を正しく使うこと。
• タスクの完了：ユーザーの実際の意図を満たすこと。

正しいツールを選んでも、引数を誤ることがあります。もっともらしいツールを呼んでも、タスクに失敗することがあります。一度成功しても、複数ターンの処理を通じて性能が低下する場合があります。エージェントシステムの評価に、最終回答の採点だけでは不十分なのはこのためです。

2.2 プロンプトの肥大化

プロンプトの肥大化は費用の問題として語られがちですが、より根本にあるのは焦点の問題です。長いプロンプトには、関連する情報、無関係な情報、古い指示、重複したポリシー、多数のツール定義が含まれることがあります。大きなコンテキストウィンドウなら収まりますが、情報が収まることと、確実に使えることは同じではありません。

「Lost in the Middle」などの長いコンテキストの研究は、情報がコンテキストのどこにあるかによって、モデルの利用の信頼性が下がる場合があることを示しています。ほかの長いコンテキストやツール呼び出しの研究も、コンテキストの長さ、ツールの数、複数ターンの蓄積が組み合わさると、不安定になる可能性を示唆しています。具体的なしきい値はモデルとタスクで異なるため、本記事は「ツールがN個を超えるとモデルは失敗する」といった主張を避けます。裏付けられる主張は、より限定的です。不要な指示や無関係なスキーマは、モデルが判断すべき範囲を広げ、ルーティングの条件を悪化させる可能性があります。

2.3 ツールレジストリの肥大化

ツールレジストリの肥大化は、プロンプトの肥大化のうち、ツールに固有のものです。大きな平坦なレジストリでは、どのタスクでも、すべての利用可能なツールが注意を奪い合います。複数の検索ツール、文書ツール、カレンダーツール、ワークスペースツール、連携ごとの類似ツールなど、意味が重なる場合に特に問題になります。

検索に基づくツール選択の研究は、この問題を直接扱います。RAG-MCPは、すべてのツールを提示せず、プロンプトを渡す前に関連するスキーマを検索します。Tool Attentionや動的なスキーマ読み込みも、有効な候補集合を減らすことを提唱しています。これらはスキルによるゲートの有効性を証明するものではありませんが、モデルに常にすべての実行可能な機能を見せる必要はない、というより広い考えを支持します。

2.4 ツールの説明の品質

ツールの提示範囲を減らすだけでは不十分です。残るツールやスキルには、明確な説明が必要です。ToolACEは、検証済みで高品質な関数呼び出しデータによる改善を報告しており、スキーマと説明の品質がツール利用の精度に影響することを示しています。APIドキュメントの研究も、不明確なパラメータの説明や複雑なインターフェースが、エラーを増やすことを示唆しています。

ここに、設計上の中心的な緊張関係があります。

• 詳細な指示とスキーマは、実行を改善します。
• 詳細な指示とスキーマをすべて一律に提示すると、肥大化します。

スキルをゲートとする段階的な提示は、探索用メタデータと実行の詳細を分けることで、この緊張関係に対処します。

2.5 プロンプトキャッシュ

プロンプトキャッシュは、安定したプレフィックスを再利用すると、遅延と費用を減らせます。ただし、キャッシュが有効になるには、プロンプトの構造が安定している必要があります。ツール一覧やシステムの指示を予測できない形で書き換えると、キャッシュの再利用が低下する可能性があります。

ここには、2つ目の設計上の緊張関係があります。

• 動的な読み込みは、無関係なコンテキストを減らします。
• 動的な挿入は、キャッシュの安定性を損なう場合があります。

そのため、実用的なスキルのゲート機構は、読み込んだ指示をどこに、どう表示するかを管理しなければなりません。後述するNanthAI:Edgeの方法では、基本プロンプトとカタログを安定させ、正規化した読み込み済みスキルのブロックを、予測可能な位置に追加します。

3. モジュール化された指示パッケージとしてのスキル

スキルは、名前を持ち、探索できる機能のパッケージです。単なるツールでも、単なるプロンプトの断片でもありません。ユーザーの意図と、実行可能な関数の間に位置します。

通常、スキルには次のものが含まれます。

• slug
• name
• summary
• runtimeMode
• ワークフローの指示全文
• 必要なツールID
• 必要なツールプロファイル
• 必要な連携
• 必要なアカウント機能
• ポリシー上の制約
• バージョン管理のメタデータ

ツールは実行可能な操作です。スキルはワークフロー単位の機能であり、ツールを使わない場合も、1つまたは多数使う場合もあります。

例えば、文書生成ツールは.docxファイルを作ります。「研究論文の執筆」スキルは、情報源の扱い、引用の規律、構成、統合の要件、文書生成に求める内容を定義し、文書、検索、分析のツールを有効化できます。

スキルをゲートとする段階的な提示には、3つの開示層があります。

この構造により、スキルはコンテキスト管理の基本要素になります。同時に、次の単位として機能します。

• 機能の単位。
• 指示の適用範囲の単位。
• ツールレジストリ拡張の単位。
• ガバナンスと可観測性の単位。

4. NanthAI:Edgeの事例研究

本節では、システムの作者が提供した事例研究用の実装情報をまとめます。独立した監査による証拠ではなく、アーキテクチャの説明として読むべきものです。

4.1 3層の機能モデル

NanthAI:Edgeは、3つの層で機能を構成します。

1. アカウントの機能とプラン
2. スキル
3. 実行可能なツール

アカウント層は、ユーザーがアクセスを許可される範囲を決めます。無料ユーザーには、モデルが呼び出せるツールレジストリのない通常のチャットを提供します。ツール対応モデルを使うProユーザーには、小さな基本レジストリを提供します。

スキル層には、メタデータと有効化ルールを備えた、モジュール化された指示パッケージがあります。

実行可能なツール層には、実際のツールのスキーマと実装があります。ただし、重いツール群はデフォルトでは提示しません。スキルが宣言するプロファイルで利用可能になります。

4.2 基本レジストリ

基本レジストリには、次のような軽量な汎用ツールがあります。

• load_skill
• list_skills
• search_chats
• fetch_image

鍵となるツールはload_skillです。ルーティングを、モデルの明示的な操作にします。モデルは最初からすべての指示を必要としません。より詳しい指示がいつ必要になるかを決められるだけのメタデータが必要なのです。

4.3 スキルのメタデータ

NanthAIのスキルには、構造化されたメタデータがあります。

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

このメタデータは、モデルによる探索と、ランタイムによるポリシー適用の両方を支えます。例えば、Slackが必要なスキルは、ユーザーがSlackを接続していなければ非表示にできます。Proの機能が必要なスキルは、無料ユーザーには提示しないようにできます。

4.4 利用可能なスキルのカタログ

利用可能と判定されたスキルは、システムプロンプト内の<available_skills> XMLブロックに出力します。このカタログに含むのは、指示全文ではなくコンパクトなメタデータです。

簡略化した例です。

<available_skills>
<skill slug="analytics_report">
<name>Analytics Report</name>
<summary>Use when the user needs data analysis, charts, or structured analytical output.</summary>
</skill>
<skill slug="document_drafting">
<name>Document Drafting</name>
<summary>Use when the user needs a structured document, proposal, memo, or generated file.</summary>
</skill>
</available_skills>

カタログは、ルーティングのためのインターフェースです。モデルにすべてのワークフローを丸ごと処理させず、どの機能が存在するかを伝えます。

4.5 スキルの状態

NanthAIは、4つのスコープを通じてスキルを解決します。

• アカウントの設定。
• ペルソナ。
• チャット。
• ターン単位の上書き。

各スキルには、3つの状態のいずれかを設定できます。

• always：毎ターン、指示全文を入れます。
• available：カタログに掲載し、必要に応じて読み込めます。
• never：完全に除外します。

これにより、細かなポリシー設定が可能になります。共通ルールは常に有効にし、専門的なワークフローは利用可能にし、許可されない機能や無関係な機能は隠せます。

4.6 load_skill

モデルがタスクとスキルが一致すると判断すると、スキルのslugを渡してload_skillを呼び出します。ランタイムは、指示全文とルーティングのメタデータを返します。

NanthAIは、生のツール結果の会話ログに頼らず、読み込んだ指示を、読み込み済みスキル専用のシステムメッセージに正規化します。これにより、有効な指示の状態が明確になり、雑多なツール呼び出しの履歴が蓄積するのを避けられます。

4.7 段階的なツールプロファイル

スキルはrequiredToolProfilesを宣言します。スキルを読み込むと、1つ以上のツールプロファイルを有効化できます。作者が提供したプロファイルには、次のものがあります。

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

例です。

• docsは、文書とファイルの生成・編集ツールを利用可能にします。
• analyticsは、Pythonとデータのツールを利用可能にします。
• workspaceは、ワークスペースのファイルと実行のツールを利用可能にします。
• 連携のプロファイルは、接続済みの場合に限り、アプリ固有のツールを利用可能にします。
• subagentsは、許可された場合に限り、サブエージェントの生成を利用可能にします。

したがって、レジストリはプラットフォーム全体の機能ではなく、有効化したスキルに応じて拡張されます。

4.8 ランタイムのガード

NanthAIには、利用できないツールをモデルが作り上げないよう指示するランタイムのガードがあります。ローカルファイルシステムへのアクセス、シェル、ブラウザ自動化、未設定のMCPサーバー、明示的なNanthAIツール以外での直接のネットワーク取得は行わないというものです。

このプロンプト上のガード自体は、セキュリティ境界ではありません。実際のセキュリティ境界は、ランタイムの認可とツールの許可リストで強制する必要があります。ただし、ガードは、有効な機能の範囲についてモデルの理解を補強します。

5. アーキテクチャの分析

5.1 トークン費用のモデル

一体型の設計では、ターンごとのプロンプトの費用は、おおよそ次のようになります。

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

スキルをゲートとする段階的な方式では、おおよそ次のようになります。

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

重要な違いは、プラットフォーム全体の機能に比例して何が増えるかです。一体型では、重い指示とスキーマの費用が、利用可能なすべての機能に比例して増えます。段階的な設計では、重い費用が有効化された機能に比例します。カタログ自体は増えますが、コンパクトなメタデータとしてだけです。

これが、このアーキテクチャの経済的な核心です。

5.2 キャッシュが安定するルーティング用カタログ

available_skillsブロックは、ユーザーの機能、ペルソナ、チャット設定、ターンの上書きが変わらない限り、ターンをまたいで安定することを意図しています。プロンプトキャッシュは再利用できるプレフィックスに依存するため、安定性が重要です。コンパクトで安定したカタログはキャッシュとの相性を保てる一方、スキル本文は必要になるまで読み込みを延期できます。

5.3 読み込み済みスキルのブロック

読み込んだスキルの指示を専用のシステムメッセージに正規化することには、2つの利点があります。

1. 第1に、指示の状態を整理できます。モデルは、読み込み済みスキルのガイダンスを、過去のツール結果ではなく有効なシステムコンテキストとして見ます。
2. 第2に、プロンプトキャッシュの構造を維持しやすくなります。安定した基本プロンプトとカタログの後にスキルを追加すれば、新たな有効化では安定したプレフィックスを書き換えずにコンテキストを拡張できます。

これはNanthAIの設計で特に重要なアーキテクチャ上の洞察です。動的な機能拡張とプロンプトキャッシュは、そのままでは両立しないため、メッセージ構造で明示的に調整しなければなりません。

5.4 プロファイルに基づくレジストリ拡張

ツールプロファイルは、スキルとツールの間に間接層を作ります。各スキルが個々のツールスキーマの長い一覧を直接所有するより望ましい方式です。

プロファイルによる間接化には、いくつかの利点があります。

• 複数のスキルでプロファイルを共有できます。
• 機能のまとまりとしてプロファイルをテストできます。
• 連携の利用可否を、プロファイルごとに一度確認できます。
• 関連ツールをまとめて提示できます。
• プロファイル単位でポリシーを適用できます。
• 有効なレジストリの構成を説明できます。

例えば、多くのスキルで文書生成が必要になるかもしれません。各スキルに文書ツールの一覧を重複させず、docsプロファイルを有効化できます。

5.5 ルーティングの意図

平坦なレジストリでは、意図は暗黙的です。モデルがツールを呼ぶと、技術者はその理由を推測しなければなりません。スキルをゲートとするシステムでは、ルーティングの意図が明示されます。

ユーザーのタスク → 読み込んだスキル → 有効化したプロファイル → 選んだツール

これにより可観測性が向上します。失敗を層ごとに分けて確認できます。

• 正しいスキルが表示されていましたか？
• 読み込まれましたか？
• 正しいプロファイルが有効になりましたか？
• 正しいツールが選ばれましたか？
• 引数は正しかったですか？
• 最終回答はタスクを満たしましたか？

これは、一体型のプロンプトに対する、評価上の大きな利点です。

6. 中心的な反論：メタデータによるルーティングは失敗し得ます

スキルをゲートとする段階的な方式への最も強い反論は、指示全文を隠すと、ルーティングを損なう可能性があることです。

モデルは、メタデータだけでは似たスキルを区別できないかもしれません。カタログの要約が短すぎたり、曖昧だったり、重なっていたりすると、モデルは次のような動作をする可能性があります。

• 間違ったスキルを読み込む。
• どのスキルも読み込まない。
• 多すぎるスキルを読み込む。
• 間違ったツールプロファイルを有効化する。
• もっともらしいものの、必要な具体性に欠ける回答を出す。

これは些細な例外ではなく、中心的なトレードオフです。段階的なゲートは、全体の肥大化という問題を、ルーティングの再現率と適合率という別の問題に置き換えます。

このアーキテクチャが最も力を発揮するのは、次の条件です。

• スキルカタログが適度な規模です。
• スキルの要約で違いを区別できます。
• スキル同士の重なりが大きくありません。
• 必要な場合に確認質問をできます。
• ルーティングの判断を記録し、評価します。
• 意味検索でカタログとの照合を補助できます。

最も弱いのは、次の条件です。

• 似たスキルが数千あります。
• 要約が一般的すぎます。
• タスクに微妙な区別が必要です。
• モデルが確認質問をしにくいように指示されています。
• スキルの読み込み漏れで、低品質でももっともらしい出力が、気付かれずに生成されます。

したがって、堅牢な実装では、モデルの判断に、決定的なチェック、検索、バージョン管理、評価を組み合わせるべきです。

7. リスクと失敗の形

R1：スキル選択の誤り

モデルが、似ているものの適切でないスキルを読み込みます。誤った指示が入り、無関係なツールが有効になる可能性があります。

対策：違いを区別できる要約、例、「使わない場合」の注記、オフラインのルーティングテスト、信頼度のしきい値。

R2：スキルの読み込み漏れ

モデルがスキルを読み込まずに進みます。出力が問題なく見えても、ワークフローの要件に反する可能性があるため危険です。

対策：読み込みの指示の強化、スキルの見落とし検出、事後の分類器、確認質問をする動作。

R3：古い指示

スキルを更新した後も、読み込み済みの古い指示が残る可能性があります。

対策：スキルのバージョンID、キャッシュの無効化、再読み込みのルール、互換性テスト。

R4：隠れた結合

スキルとプロファイルにずれが生じる可能性があります。スキルが、プロファイルに実際にはないツールを前提にする場合があります。

対策：requiredToolProfiles、requiredToolIds、プロファイルのテスト、依存関係の静的検査。

R5：遅延の追加

load_skillによって、作業開始前にツール呼び出しが1往復増えます。

対策：頻度の高いワークフローをalwaysにする、先行読み込みをする、基本レジストリを併用する。

R6：キャッシュの無効化

動的な内容を早い位置に挿入すると、キャッシュを再利用できなくなる場合があります。

対策：安定したプレフィックスを守る、読み込み済みスキルのブロックを追記専用にする、キャッシュのテスト。

R7：プロンプトインジェクション

ユーザーが作成したスキルに、安全でない指示が含まれる可能性があります。

対策：スキルのレビュー、ポリシーの静的検査、サンドボックス化、権限スコープ、ランタイムによる強制。

R8：モデルの判断への過度な依存

曖昧な状況では、モデルのルーティングが不適切になる場合があります。

対策：検索によるルーティングの補助、決定的なポリシーのゲート、ユーザーへの確認、テレメトリー。

8. 考察

スキルをゲートとする段階的な方式は、ツール登録を機能アーキテクチャとして捉え直します。平坦なツール一覧ではなく、エージェントランタイムを階層化します。

アカウントのポリシー → スキルカタログ → スキルの読み込み → プロファイルの有効化 → ツールの実行

ここから、いくつかの示唆が得られます。

1. スキルがガバナンスの主要単位になります。プラン別のアクセス、連携の状態、ツールプロファイル、ランタイムモードを、すべてスキルのメタデータで表せます。
2. ルーティングを検査できます。load_skillイベントを記録、測定、評価できます。
3. マーケットプレイスを扱いやすくなります。ユーザー作成のスキルが要件を宣言し、機能の範囲を限定したうえで受け入れられます。
4. おそらく最適なのは併用型の設計です。小さな共通ツールは基本レジストリに残すべきです。専門的、高リスク、高費用、使用頻度の低いツールにはゲートを設けるべきです。alwaysのスキルは少数にし、専門的なワークフローはavailableをデフォルトにします。neverで、許可されない機能を抑止します。
5. スキルカタログの品質が、製品の重要な接点になります。カタログの要約は内部ラベルではなく、モデル向けのルーティングインターフェースです。APIドキュメントと同じ規律が必要です。

これがNanthAI:Edgeで私たちが進めている方向です。機能は常時プロンプトに入れずとも発見できるべきであり、強力なツールは、有効なワークフローに必要な理由があるときにだけ現れるべきです。

9. 静的なアーキテクチャの測定

動作全体の検証にはベンチマーク一式が必要ですが、一部の主張は現在のNanthAI:Edgeの実装から直接評価できます。特にコードベースから、スキルカタログと段階的なツールレジストリが提示するコンテキストの範囲を測定できます。

これらの測定は、コンテキストの効率に関する主張を定量化します。すべてのスキル本文とツールスキーマを最初から入れる代わりに、コンパクトなスキルのメタデータと小さな基本レジストリを提示することで、プロンプトとツールスキーマの情報をどれだけ減らせるかです。

9.1 スキルカタログの圧縮

現在のNanthAI:Edgeのシステムカタログには、表示対象のスキルが55個、非表示または表示対象外のスキルが11個あります。表示対象のスキルは、モデル向けのavailable_skillsカタログに、スキル名、要約、要件のヒントという軽量なメタデータとして出力されます。指示本文の全体は、スキルを明示的に読み込むまで渡しません。

現在の表示対象カタログで測定した結果です。

つまり、デフォルトのスキル探索用情報は、表示対象のスキルの指示全体の約13分の1です。モデルは機能の存在を知ることができますが、タスクで実際に必要になるまで、指示全体の費用はかかりません。

これは、アーキテクチャの第1のコンテキスト効率の主張を裏付けます。スキルを広く発見可能にしながら、指示の有効化は選択的に保てます。

9.2 ツールレジストリの圧縮

ツールレジストリの効果は、さらに顕著です。現在の段階的なレジストリでは、基本ツール群が提示するのは、次の4つの汎用ツールだけです。

• load_skill
• list_skills
• search_chats
• fetch_image

すべてのツールプロファイルを展開すると、レジストリには115個のツールが入ります。スキーマのトークン数には、大きな差があります。

これは、第2のコンテキスト効率の主張を裏付けます。モデルがデフォルトで実行できる操作の範囲は、プラットフォーム全体の機能の範囲より、はるかに小さくなります。

一体型の設計では、ツールを利用できるすべてのターンで、モデルがレジストリ全体を見ます。段階的なレジストリ拡張では、読み込んだスキルが1つ以上のプロファイルを有効化するまで、基本ツールだけを見ます。

9.3 有効なプロファイルの費用の例

ワークフローによって、有効になるツールプロファイルは異なります。したがって、削減量はタスクに依存します。限定的な分析ワークフローで提示するツールは、文書生成ワークフローよりはるかに少なく、どちらも完全に展開したレジストリよりはるかに少なくなります。

これらの例は、プロファイルを介した間接化が重要な理由を示します。データ分析には、カレンダー、Slack、文書編集、スケジュールジョブ、ペルソナ管理のツールは必要ありません。Slackの作業には、Python実行や文書生成のツールは必要ありません。文書の作業には比較的重いdocsプロファイルが必要かもしれませんが、明示的に必要とされない限り、ほとんどの連携ツールとランタイムツールを省けます。

したがって、システムはツールスキーマの費用を、「ユーザーが利用できるすべてのもの」から、「現在有効なワークフローで必要な理由があるすべてのもの」へ移します。

9.4 解釈

これらの測定が検証するのは、このアーキテクチャのコンテキスト削減という前提であり、動作面の期待全体ではありません。

NanthAI:Edgeの段階的な設計が、次のものを実質的に減らすことを示しています。

• デフォルトで提示するスキルの指示。
• デフォルトで提示するツールのスキーマ。
• モデルが扱う操作空間の大きさ。
• キャッシュのために安定させる必要のあるプロンプトの情報。
• タスク固有の有効化前に現れる、無関係なツール候補。

ただし、モデルのルーティングが改善すること、より正確にツールを選ぶこと、タスクの成功率が上がることは証明していません。それらには動作の評価が必要です。

静的な測定は、次の1つの問いに答えます。

この実装で、スキルをゲートとする段階的な方式は、実際に提示するコンテキストとスキーマを減らしていますか？

答えは、はいです。現在の実装では削減幅は大きく、全体を提示する場合と比べて、スキルの指示では約92.5%、基本ツールレジストリでは約**97.7%**です。

10. 結論

エージェント型AIシステムは、拡大する情報設計の問題に直面しています。ツール、連携、ワークフロー、ポリシーが増えるにつれ、一体型のプロンプトとツールレジストリの設計は、費用も評価の難しさも増していきます。大きなコンテキストウィンドウは容量を補いますが、関連性、ルーティング、キャッシュの安定性、ガバナンスは解決しません。

スキルをゲートとする段階的なツールアクセスは、原則に基づく代替案です。コンパクトなスキルカタログは発見可能性を、load_skillは明示的な有効化を、読み込んだスキルの指示はタスク固有のガイダンスを、ツールプロファイルは範囲を限定したレジストリ拡張を提供します。ランタイムの認可とガードは、機能の境界を維持します。

NanthAI:Edgeの事例は、アカウントのプラン、階層化したスキルの状態、利用可能なスキルのカタログ、正規化した読み込み済みスキルのメッセージ、プロファイルをゲートとするレジストリ、ランタイムのガードで、このパターンをどう実装できるかを示しています。プラットフォーム全体の機能ではなく、有効化された機能にコンテキストの費用を対応させる点で、このアーキテクチャは有望です。

中心的な未解決の問いは、実証に関するものです。メタデータを先に提示してスキルを選ぶことで加わるルーティングの負担は、プロンプトとレジストリの肥大化を減らす利点を上回るでしょうか。答えは、カタログの規模、スキルの重なり、モデルの系統、タスクの分布、実装の品質によって異なります。

エージェントプラットフォームは、機能を段階的に提示し、ルーティングを観測可能にし、タスク上の理由がある場合にだけツールを有効化するべきです。

参考文献

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• NanthAI:Edgeのアーキテクチャの説明。作者提供の事例研究資料。独立した検証は行われていません。

こちらにも掲載： LinkedIn.