【Tech最前線】 #086 - Skillを設計しないままエージェントを動かしても、コストは下がらない――Claudeの3層アーキテクチャと「コンテキスト圧縮」の本当の目的

2026年7月8日 08:02

Claudeを業務に使えば自動化が進む、という認識は正しい。しかしSkillを設計しないままエージェントを動かし続けると、API費用は下がるどころか増え続け、意図しないループと権限違反が発生する。なぜSkillが必要なのか、どう設計すれば壊れないのかを、Anthropicの設計哲学から実際の失敗事例まで追う。
本記事は、エンジニア&コンサルタントの著者が選んだ技術の最新動向をわかりやすく約3,000字で発信しています。もし記事がためになったと思った方は、高評価とフォローをお願いします。

Skillとは何か――カスタム指示・プロジェクトとの使い分け

ClaudeのSkillを一言で表すなら「SKILL.md（Skillの動作手順を書いた指示ファイル）を中心とした手順書パッケージ」だ。指示書となるSKILL.mdファイルと、テンプレートやスクリプトを1つのフォルダにまとめたものを指す。
Claudeには3種類の設定層がある。AIの話し方や人格を決めたい場合は「カスタム指示」を使う。特定の案件に関する資料を束ねて作業したい場合は「プロジェクト」を使う。複数のプロジェクトやチームをまたいで同じ業務手順を繰り返し使いたい場合に「Skill」が登場する。
Skillが必要になる典型的な場面は「同じ手順を何度も書き直している」と気づいた瞬間だ。請求書の読み取り、市場調査レポートの生成、コピーのブランド適合チェック。こうした業務をSkillとして定義しておけば、次回以降は呼び出すだけでよい。

Anthropicが解こうとした問題――「Bash is All You Need」哲学

SkillはLangChainのToolやOpenAI Functionsとは根本的に設計思想が異なる。LangChainは高い抽象化レイヤーを持つが学習コストが高く、内部の動作が把握しにくい。対してAnthropicのClaude Agent SDKは「フレームワークを使わずコードを書く」という哲学を採用している。Bashスクリプトに近い直接的なアプローチで動作が予測しやすく、テストやデバッグがシンプルになる。これが「Bash is All You Need」と呼ばれる設計方針だ。
SkillとMCP（外部サービスへの接続窓口）は役割が異なる。SkillはClaudeに「どう処理すべきか」という手順を教えるもので、MCPは「外部サービスにどう接続するか」という窓口を提供する。手順と接続を組み合わせることで専門的な業務フローを自動化できる。

3層アーキテクチャ――なぜコンテキストが枯渇しないのか

Skillの核心は「段階的に情報を読み込む」仕組みにある。ClaudeにはAIが一度に参照できる情報の上限があり、大きすぎるプロンプトを渡し続けると費用が膨らみ、精度も落ちる。
Skillはこの問題を3層構造で解決している。レベル1は常時読み込まれる「名前と説明文」のみで約30トークン。レベル2は対象タスクが発生したときだけ読み込まれるSKILL.mdの本文で数百から2,000トークン程度。レベル3は明示的に呼び出された場合のみ展開されるスクリプトや参照ドキュメントだ。
サブエージェント（メインの処理から切り出して別文脈で動かす仕組み）の本当の目的は「速度の向上」ではなく「コンテキストの圧縮」だ。多くの開発者が並列処理で速くなると考えてサブエージェントを導入するが、Anthropicの設計意図はそこにない。処理を別の文脈に切り出すことで、メインの情報領域を汚染せず、複雑な推論を長時間維持できるようにすることが目的だ。

成功事例と「よくある3つの設計ミス」

月940ドルかかっていたAPI費用が、設計を変えただけで412ドルになった事例がある。AI開発スタジオのAutoolize社は約40本の実運用エージェントを構築している。同社の請求書抽出エージェントでは、4,200トークンあったプロンプトを「900トークンの基本プロンプト」と「地域別3種類のSkill」に分割した。入力トークンが62%減少し、月額費用は940ドルから412ドルへと半減した。バグ修正速度も約3倍になった。
別の戦略コンサルティング企業では、Skillと構造化された引き継ぎ（エージェント間のデータ受け渡し形式を定めること）を導入した結果、消費トークンが48%削減され、処理時間が4分20秒から2分38秒へと40%短縮された。出力品質は78%から79%とほぼ維持された。
一方、本番環境で頻発する設計ミスが3つある。第1はSkillの範囲が広すぎてコンテキストが汚染されるケースだ。第2はトリガーの条件が曖昧なまま本番に入るケースで、無関係な文脈でSkillが起動する誤発火が起きる。第3は「サブエージェント＝速度向上」という誤解で、コンテキスト管理の設計が抜けたまま並列処理を組むと費用が増えて精度も落ちる。

セキュリティと信頼ティア――コミュニティ製Skillの26.1%に脆弱性

Skillが普及するにつれ、セキュリティリスクも表面化した。2026年の調査では、コミュニティが公開しているSkillの26.1%に、内部情報を外部に送り出す処理や不正なプロンプトを注入するコードが含まれていることが確認された。
これに対応するため、4段階の検証と4段階の信頼レベルを組み合わせた管理の枠組みが提唱されている。第1段階は静的解析（コードを実行せずにソースを読んで問題を検出する手法）、第2段階はAIによる意味の判定、第3段階は隔離環境での動作確認、第4段階は権限宣言の検証だ。信頼レベルはT1（未検証・隔離）からT4（ベンダー認定・全機能利用可）まで4段階ある。
自社でSkillを作る場合も同じ発想が必要だ。最小限の権限だけを与える原則が、安定運用の基本になる。

2026年以降のSkill進化と、今日からできる3つのアクション

2026年中頃、サードパーティ製Skillのマーケットプレイスが本格稼働する見込みだ。AI自身がSkillを発見・合成するアプローチも研究段階に入っている。強化学習によってSkillを自律獲得するシステムSAGEは、アプリ操作の評価環境AppWorldで目標達成率を8.9%向上させ、生成トークンを59%削減した。環境を自律的に探索しながらタスクを学ぶSEAgentは、PC操作の評価環境OSWorldでタスク成功率を11.3%から34.5%へと23.2ポイント引き上げた。2027年以降はAIが手順を自ら学習する段階に移行する可能性がある。
今日から動ける行動は3つある。週3回以上繰り返している業務を1つ選んでSkill化する。手順をSKILL.mdに定義し、エージェント間の引き継ぎ形式を決める。個人・小チームで試して成果を数値化し、効果が出たら社内標準Skillとして展開する。

まとめ

ClaudeのSkill設計は、「大きなプロンプト1本」から「段階的に展開する手順パッケージ」への転換を体現している。3層アーキテクチャでコンテキストの枯渇を防ぎ、Autoolize社の62%トークン削減・費用半減が示す通り、設計の差は費用に直結する。コミュニティ製Skillの26.1%に脆弱性があるという現実も踏まえ、信頼できるソースのみを使う運用規律は外せない。「サブエージェント＝速度向上」という誤解を手放してコンテキスト圧縮を軸に設計を組み直すと、安定性と費用の両方が変わる。次にClaudeで業務を自動化しようとするとき、「どの業務を1つのSkillとして切り出すか」という問いが起点になるだろう。
ClaudeのSkillとAgent SDKの動向をこれからも追い続けたい方は、フォローと高評価をいただけると励みになります。

参考文献

いいなと思ったら応援しよう！

記事がお役に立てば、応援いただけると嬉しいです！いただいたチップは、より良いコンテンツ作りのための活動費に使わせていただきます。