現在、産業界の開発の焦点は、エージェントスキルを中核とした Openclaw などのフレームワークへと急速に収束しています。繰り返し発生する API 連鎖を実行可能なエージェントスキルとして記述することが、長期的なタスクにおける「コンテキストの爆発」を解決する唯一の道であるという点で合意が形成されました。しかし、理念が確立された後、真の実戦における深瀬が始まったばかりです。Openclaw の選択と構成に直面した際、おそらく以下の 4 つのアーキテクチャ上の問題で行き詰まるでしょう。
スキルの構築において、高価な強力モデル（例：Claude Opus 4.6）を用いて一度で問題を解決すべきか、それとも弱力モデルを大量に投入して試行錯誤を繰り返すべきか。その差は実際にどれほどなのか。
マルチエージェントはどのように連携すべきか。マルチエージェントの「ロブスター」チームを持つ場合、メインモデルとエッジモデルの役割をどう分担すべきか。
スキルツリーは全て習得させるべきか。複雑なネスト型呼び出しは LLM の能力限界を超えないか。その境界はどこにあり、本番環境で最も安定する解決策は何か。
汎用インターフェースとしてのエージェントスキルには、どれほどの隠れた認知的コストがかかるのか。エージェントはどのような状況でスキルを潔く諦め、直接底层 API を叩くべきなのか。
オックスフォード大学が最近発表した「SkillCraft」ベンチマークは、まさにこれら 4 つの具体的な痛点に対し、極めて正確な定量的な回答を提供するものです。
本稿では、空虚なマクロトレンド論を語るのではなく、同研究から抽出されたトークン請求書、エラーログ、呼び出し履歴を直接紐解き、スキル時代におけるマルチエージェント連携の基盤設計ロジックを明らかにします。
SkillCraft ベンチマークとテスト環境の構築
後述するすべてのアーキテクチャ提案のデータ信頼性を担保するため、まず研究者がどのようにテストサンドボックスと評価基準を構築したか精査する必要があります。これが、工学的価値に乏しい「スコア稼ぎのおもちゃ」を除外し、真に産業レベルのデータを入手する鍵となります。
既存ツールチェーン評価の体系的欠陥
現在のツール使用ベンチマーク（WebArena や AgentCompany など）は、デプロイ時にツールセットを固定し、単一インスタンスでの評価ロジックを採用するのが一般的です。つまり、与えられたツールを使用して、その単発のタスクをエージェントが解決できるかどうかをテストします。この単発テストは、長期的なタスクにおいて以下の 2 つの中核的な効率ボトルネックを露呈させます。
冗長な状態伝達：複雑なビジネスロジックが一連の原子的操作に分解されます。この過程で、中間結果（巨大な Web DOM ツリーや長大な JSON API レスポンスなど）が連続するツール呼び出しの間で繰り返しシリアライズされ、強制的にモデルのコンテキストに注入されるため、極めて高額なトークン I/O オーバーヘッドが発生します。
コンテキストウィンドウの飽和：長大なツール呼び出しシーケンスとその膨大な戻り値がコンテキスト容量の大部分を占有し、モデルは実行後期において初期情報を著しく見失い、場合によっては最初のシステム指示から完全に逸脱してしまいます。
タスクプールの構築と多次元拡張ロジック
研究者が構築した SkillCraft ベンチマークは、単一のタスク内に意図的に重複するサブ構造を埋め込み、限られたリソース予算内でエージェントにツール組み合わせの特定と再利用を何度も行わせるよう仕向けています。構築プロセスは、厳密な 3 段階のパイプラインによって完了されました。
第 1 段階および第 2 段階：既存のベンチマークからタスク設計原則を抽出し、実際の公開 Web API（GitLab、Open-Meteo、TVMaze など）とローカルデータセットに基づき、21 のシードタスクを構築しました。
第 3 段階（多次元拡張）：研究者は 2 つの直交する軸に沿ってシードタスクを拡張しました。量的拡張（例：「1 リポジトリの分析」から「5 リポジトリの分析」へ）と、複雑さの拡張（各サブエンティティに必要な底层 API 呼び出し回数の増加）です。
最終的に、SkillCraft は極めて標準化されたテストケースを確立しました。
6 大分野（エンターテインメント、参照、教育、開発者向け、科学、食品）にまたがる 126 の長期的タスクが含まれています。テストの難易度は 3 つの絶対基準で定量化されました。Easy レベル（3 エンティティ、1 エンティティあたり 3 回の API 呼び出し、計 9 回）、Medium レベル（4 エンティティ、計 16 回）、Hard レベル（5 エンティティ、1 エンティティあたり 5 回の API 呼び出し、計 25 回の複雑な呼び出し）です。
基盤インフラ：スキルモードプロトコルスタックとセキュリティ検証
テスト時にモデルへツール組み合わせの構築能力を付与するため、システムはエージェントのワークスペース内でローカルの skill_cache.json ファイルを維持します。エージェントは、以下の 4 つの MCP（Model Context Protocol）プリミティブを通じてのみ、これと対話することが厳格に制限されています。
save_skill：成功したワークフローを実行可能なコードマクロとして保存します。macro_name（一意の識別子）、script_code（Python スクリプトコード）、parameters（変数名リスト）、description（要約説明）の入力が必要です。execute_skill：保存済みのスキルを実行します。macro_nameと具体的な引数辞書argsを入力する必要があり、システムはステータス識別子と実行結果辞書を返します。list_skills：引数不要で、現在のセッションで利用可能なすべてのスキルを一覧表示し、モデルが意思決定を行う前に確認できるようにします。get_skill：対象スキルの完全なソースコードとパラメータ署名を取得し、複雑なシナリオ下でのデバッグや検証に使用します。
エージェントが生成したコードがシステムレベルの災害を招かないよう、研究者は 3 段階の防御メカニズムを備えたコード検証機能（Coding Verifier）を展開しました。
構文検証：
save_skillによる書き込み前に、底层で AST 解析を実行し、基礎的な構文エラーを阻止してモデルに具体的なエラー行番号とコード断片を返します。ランタイムエラー報告：
execute_skillがクラッシュした際、サンドボックスがシステム例外を傍受し、モデルに構造化されたトレースバックと入力パラメータを返して、パラメータバインドエラーの特定を支援します。実行後の品質検査：サイレントな失敗を防ぐため、出力辞書を強制的に検証します。フィールド内容の 50% 以上が Unknown、None、または 0 であれば、そのスクリプトは直接登録が拒否されます。
実験の境界条件として、研究者は苛烈な制約を課しました。各タスクは最大 150 回の対話ラウンド、タイムアウト時間 60 分に厳格制限。グローバルに累積消費できる入力トークンは最大 1M、出力トークンは 150K。モデルのサンプリングパラメータは出力の確実性を保証するため、 および
に完全固定されました。評価面では、ファイル生成、JSON 構造の有効性、データの完全性、フィールド単位の精度（総合得点 90% 以上）を同時に満たして初めて成功とみなされます。
中核的結論：弱モデルより強モデル
上記の一切の水分を含まないテスト環境を理解した上で、実戦において最も関心が高い問題、つまりコスト削減のために安価な弱モデルで何度も試行すべきか、高価な強モデルで一撃必中させるべきかを見てみましょう。データが示す答えは後者です。
トークン消費の指数関数的崩壊
実験では、スキルライブラリインターフェースを無効化したベースラインモードと、有効化したスキルモードを比較しました。データは明確に示しています。複雑な長期的呼び出しにおいて、強モデルはコード記述による内部ロジックの流转を実現することで、自身の高価格によってもたらされるコスト劣勢を大幅に相殺できるのです。
GPT-5.2：平均トークン消費量が 1.23M から 0.26M へと激減（79% 削減）し、1 タスクあたりの平均 API コストも 1.77 ドルから 0.43 ドルへと急落（75% 節約）しました。
Claude 4.5 Sonnet：ベースラインでの成功率はすでに 96% と高く、スキルモードでも 94% の高水準を維持しました。トークン消費量は 1.36M から 0.40M へ（71% 削減）、純粋な底层ツール呼び出し回数は 14.3 回から 9.2 回へと減少しました。
DeepSeek-V3.2-EXP：トークン消費量が 49% 減少（1.04M から 0.53M へ）し、コストは文字通り半減しました。
エージェントがスキルを照会・検証・キャッシュする際に、意思決定ラウンドをわずかに消費するものの（例：Gemini 3 Pro の平均対話ラウンド数は 13% 増加）、コードエンジンが膨大なデータクリーニングと仲介作業を直接引き受けることで、プロンプトへの無負荷注入を回避しているため、システム全体のトークン消費量は断崖絶壁のような落ち込みを見せています。
相関分析：コーディング能力こそがスキル能力
研究者による跨指標の相関分析により、システム動作の底层ロジックが明らかになりました。スキル実行の成功率とタスク最終成功率には強い正の相関（）があり、同時に効率向上効果とモデルのベースライン能力にも正の相関（
）が見られました。
これが、オープンソースの弱モデルがこのアーキテクチャにおいて抱える工学的死穴を説明しています。モデルがベースラインの Hard タスクでの成功率が 60% を下回ると、そのコード生成能力も同様に貧弱です。パラメータ化インターフェースをカプセル化する際、弱モデルは構文エラーや論理的デッドロックを含む低品質なコードを頻繁に生成し、その後システムにエラーとして阻止され、モデルは無限の「エラー検出 - 書き直し」の地獄絵図に陥ります。この過程で、計算リソースを節約するために導入されたフレームワークが、逆にコード修正のために大量のトークンを燃焼させる結果となります。
SkillCraft 結論 1：基礎的なスキルライブラリを構築する際、エージェントの数を積み上げて運試しをするように弱モデルを使用することは厳禁です。強モデルの単体コード生成正解率は、システム総コストにおいて絶対的な圧倒的優位性を持ちます。
マルチエージェントの跨モデル連携：創造者は実行者より重要
Openclaw などのマルチエージェント連携フレームワークでは、アーキテクトは通常タスクを分解して配布する必要があります。システム内の「メインモデル」と「エッジモデル」の役割をどう分担すべきか。論文の跨モデルテストデータが極めて明確なエンジニアリング指針を示しています。
跨難易度移行テスト（Cross-task Generalization）
スキルの汎用性を検証する際、研究者は厳格な静的移行テスト（複雑なタスクにおいて、単純なタスクで生成されたスキルコードを直接使用し、モデルによるコード修正を禁止する）を実施しました。データは、高品質なパラメータ化コードが極めて強い跨レベル互換性を持つことを証明しています。Claude 4.5 と Gemini 3 Pro は、Easy レベルで抽出したスキルを Hard レベルのタスクへシームレスに移転でき、いずれも 97%〜100% という極めて高い実行成功率を維持しました。Claude の Easy→Hard 移行では、成功率をベースラインの 95% から 100% まで引き上げると同時に、トークンを 1.92M から 1.56M へと圧縮しました。
跨モデル実行ヒートマップ解析
研究者は極めて苛烈な 16 組の交差テストを設計しました。Claude、Gemini、GLM、Minimax に 8 つの Hard レベルタスクでそれぞれスキルライブラリを作成させ、その後、これらの純粋な Python スクリプトを全モデルに交叉配布して純粋な実行のみを行わせました（修正権限は無効化）。
これら 2 枚のヒートマップのデータ対比は極めて強烈です！特に 1 枚目は、Claude が記述したコードが全モデルで実行され、すべて 100% の成功率を収めています。
高品質コードの下位互換の絶対性：Claude が作成したコードはロジックが緻密で、型チェックも完備されています。これらのスクリプトが、より軽量の Minimax、GLM、Gemini へ配布されて実行された際、全シリーズで 100% の満点通過率を記録し、すべての実行側モデルに 54% から 81% という巨額のトークン節約をもたらしました。
低品質コードの実行による逆効果：対照的に、Minimax が生成したコードは、内部状態の流转が混乱しパラメータインターフェース設計に欠陥があるため、Claude に実行させた場合でさえ高頻度で底层エラーを発生させました。これにより実行側のリトライメカニズムが頻繁に起動し、計算コストは低下するどころか、48% の増加からわずかな 18% の削減まで変動し、フレームワークによる効率化の趣旨を完全に破壊しました。
実行者の計算能力限界の補填：データ中の興味深い詳細として、Claude が Gemini 生成の瑕疵あるスキルライブラリを強制的に実行したところ、69.2% のトークン節約を実現しました。一方、Gemini が自らのスキルライブラリを実行した場合は、わずか 14.8% の節約にとどまりました。これは、トップクラスの大モデルは意図理解とパラメータ補完能力により、ある程度中品質のコード欠陥を「カバー」できることを示唆していますが、これは通常運転として頼るべきものではありません。
SkillCraft 結論 2：したがって、Openclaw などのエッジ・クラウド連携型マルチエージェントシステムを設計する際は、「創造者 ＞ 実行者」という原則を遵守すべきです。クラウド上のトップクラスの千億パラメータ大モデルを「スキルコンパイラ」として、少数の複雑なサンプルから高品質なビジネススクリプトを抽出・検証・カプセル化させます。エッジ側や低コストのプライベートモデルは「実行エンジン」としてのみ権限を与え、パラメータを受け取りキャッシュスクリプトを実行する役割に徹させるべきです。弱モデルによる公共スキルライブラリへのコード提出は絶対に禁止すべきです。
回避ガイド：深層ネストと抽象化の認知的税金
エンジニアはシステムアーキテクチャを設計する際、コードをモジュール化し階層的に呼び出す「オブジェクト指向」への執着を持ちがちです。論文中の微視的テストデータは、現在の LLM の能力が深いコード構造の前でいかに脆弱であるかを完全に露呈させました。
階層型モデル（Hierarchical Mode）の崩壊メカニズム
研究者は、スキルが他のスキルを呼び出すことを許可するイテレーションモード（最大ネスト深さを 10 に設定）を導入しました。理論的には、上位スキルがオーケストレーションを担当し、下位スキルが原子的操作を担当するため、極めて完璧に見えるはずです。
しかし、実際の実行ログ（Log Trajectories）は、絶望的なエラー伝播（Error propagation）のプロセスを示しました。
犬種百科事典を生成するタスクにおいて、底层のデータ取得スキル get_breed_profile が希少品種のデータに遭遇しました。API からの元のレスポンスに temperament フィールドが欠落しており、null を含む辞書を返しました。この底层の隠れた問題が上流へ伝播しました。
中間レイヤーの集約スキルが文字列操作 profile.temperament.split(',') を実行しようとした際、サンドボックスは致命的な TypeError: 'NoneType' has no attribute 'split' を直接スローしました。この 1 行の型エラーが呼び出しツリー全体を一瞬で貫通し、最上位のアセンブルタスクを完全にダウンさせ総崩れを招きました。
実測データは異常に悲惨なものでした。ネストモードに切り替えた途端、GPT-5.2 でさえもタスク成功率がフラットモードの 90% から 79% へ転落し、トークンオーバーヘッドも 0.26M から 0.60M へと悪化して跳ね上がりました。その理由は、ネスト型アーキテクチャが LLM に、その能力上限では到底到達できない「エッジケース処理」や「動的型チェック」を要求するからです。高額な故障追跡コストは、最初から原子的操作を一度実行し直すコストを遥かに上回ります。
SkillCraft 結論 3：産業界の環境でエージェントのツール呼び出しツリーを構築する際、複雑なスキル同士の相互呼び出しは捨て去るべきです。スキルアーキテクチャをフラット（Flat）に保ち、単一スクリプト内に完全な try-except エラー処理を含めることが、本番環境の安定性を保証する唯一の解決策です。
汎化の認知的計算力税と「抽象化しない」知恵
すべてのビジネスフローにおいて、すべてを汎用インターフェースとしてカプセル化することが常に最も効率的でしょうか。答えはやはりノーです。汎化そのものに、高額な「認知的計算力税」を支払う必要があるからです。
研究者は、再利用やパラメータインターフェースを放棄し、単回使用スクリプト内で数値を直接ハードコーディングするダイレクト実行（Direct Exec）モードをテストしました。48 のタスクサブセットにおけるデータ対比は極めて極端なものでした。
Claude 4.5 Sonnet は、Direct Exec モードにおいてトークン消費量をベースラインの 1.72M から驚異的な 0.16M まで絞り込み、対話回数はわずか 5.8 ラウンドでした。一方、将来の再利用を見据えた標準スキルモードでは、汎用的なパラメータプレースホルダーの設計や「保存して後で実行」という完全なプロセスが必要なため、0.34M トークンと 10.5 ラウンドの対話を要しました。
GPT-5.2 の表現も同様に極端で、Direct Exec により 1 タスクあたりのトークン燃焼量を 0.06M まで圧縮し、対話回数は 4.5 ラウンドへと激減しました。
元の呼び出し履歴（Trajectories）を参照することで、異なるレベルのモデルが持つエンジニアリング直感の差異を明確に見ることができます。
3 種類の猫に関する 9 回の単純なデータ取得という軽量タスクを処理する際、Claude は「汎用インターフェースを設計してコードをキャッシュする」という抽象化のオーバーヘッドが、直接 API を叩く利益を大きく上回ると鋭く判断しました。そして save_skill の呼び出しを潔く諦め、素直に 34 回の原子的操作を完遂し、約 76 万トークンを消費して無事に任務を完了させました。一方、5 種類のカクテルを分析し計 25 回の呼び出しを要する高複雑度タスクでは、Claude はわずか 1 回の試行で、5 つのデータ流转パスを含む完璧なマクロコード process_cocktail_complete を正確に記述。その後も連続して 5 回ループ呼び出しを行い、总计わずか 8 ステップの対話と極めて低い 21 万トークンで見事に完結させました。
対照的に、DeepSeek-V3.2 は実行中にシステムプロンプトに完全に縛られ、「指示の過学習」に陥りました。単純な猫タスクにおいて、強制的に process_cat_breed というスキルを車輪の再発明的に生成しました。しかしコード品質は憂慮すべきで、出力辞書から breed_facts フィールドがごっそりと欠落していました。これにより実行後に広範囲なデータ欠損が発生し、その後の長い修復期間を余儀なくされ、8 回もの部分的追記（Chunk write）などの応急処置を手動で実行。結果、単純なタスクでありながら荒唐無稽にも 150 万トークン以上を燃焼させてしまいました。複雑なカクテルタスクに至っては、スクリプト書き込みを 3 回（v1, v2, v3）連続して試みるも、unexpected token '}' at line 8 や 'return' is invalid outside function といった基礎的な構文エラーでことごとく断念。最終的には全量手動呼び出しへのダウングレードを余儀なくされ、タイムアウトとコンテキストの混乱の中でタスク失敗に至り、1.14M トークンを消費して何の成果も得られませんでした。
SkillCraft 結論 4：最高次元のエージェントフレームワーク設計とは、コード実行サンドボックスを提供するだけでなく、大モデルに「いつフレームワークを使用しないか」の自由と判断力を付与することです。低頻度で孤立したタスクを特定し、ハードコーディングによるワンタイムスクリプトを選択することで、パラメータバインドに起因する幻覚を回避することが、システムの徹底的なコスト削減の鍵となります。
結び
『SkillCraft』の詳細なデータは、エージェントアーキテクチャの評価と設計における私たちの視点を根本から変えました。複雑なエンタープライズレベルのビジネスフローにおいては、ベンチマークの精度（Accuracy）を単に追い求めることから、究極の計算リソースコスト制御へと視点を移す必要があります。
エージェントが真に実装され、商業的な堀を築くための鍵は、コードを中間メディアとして活用し「計算の圧縮（Token Compression）」を実現する能力にあります。以下の、まさに血と汗と涙（＝資金）で得られたアーキテクチャの法則を忘れないでください。最強の大モデルをコードコンパイラとして使い、エッジ側の小モデルを実行者とする。コードの深さを抑制し、フラット構造を堅持する。そしてフレームワークを設計する際は、モデルが抽象化を放棄し、直接力技で実行することを許すバイパスチャネルを常に用意しておくこと。これによってのみ、あなたのエージェントシステムはエンジニアリング的な堅牢性と商業的な実現可能性の両立を真に達成できるのです。
未来は既に到来しています。ご縁があれば、共に歩んでいきましょう！
（以上）