はじめに

2026年6月、AnthropicがClaude Codeのスキル運用に関する社内知見を公開した(Thariq Shihipar, "Lessons from building Claude Code: How we use skills", Claude Blog, 2026-06-03)。社内で数百のアクティブなスキルを運用した結果を目録化し、9つのカテゴリに整理したという内容だ。

この記事の面白さは、カテゴリの数そのものではなく、冒頭で提示される定義の転換にある。

スキルは「ただのMarkdownファイル」ではない。スクリプト、アセット、データを含むフォルダであり、エージェントはその中身を発見し、探索し、操作できる。

スキルをプロンプトの断片ではなく、エージェントが使う道具一式(フォルダ構造 + 設定フック) として捉え直す。この視点に立つと、「どんなスキルを作る価値があるのか」「どう構造化するか」という問いに工学的な答えが出せるようになる——というのがAnthropicの主張だ。

ただし、この知見はコーディングエージェントの文脈で書かれている。我々が開発しているTechHive Agents(THA)は、コードを書くエージェントではなく、採用業務や経理業務そのものを実行する業務エージェントだ。9分類のフレームワークを業務ドメインに適用したとき、何がそのまま使えて、何が変質するのか。

実際にマッピングしてみた結果、一つの結論に行き着いた。業務エージェントにおいて、Gotchas(落とし穴の知識)こそが業務知識の最小単位であり、スキル化とは組織の暗黙知を資産化する行為である。本稿ではその過程を追う。

前提: THAのスキル体系

本題に入る前に、THAのスキル構造を最小限だけ説明しておく(詳細は過去記事を参照されたい)。

THAのエージェントは2層のスキル構造を持つ。

Tier 1(system prompt): ペルソナのワークフロー定義。「採用アシスタントとして応募者対応を行う」といった役割と手順の骨格
Tier 2(Custom Skills): 業務知識のMarkdown群。求人媒体の操作手順、顧客企業固有の業務ルール、外部システムの仕様など

Tier 2はまさにAnthropicのいう「スキル」に相当する。そしてTHAでは、このTier 2の品質がエージェントの業務遂行品質を直接決める。コーディングエージェントにとってのスキルが「あると便利な拡張」だとすれば、業務エージェントにとってのスキルは「業務知識そのもの」であり、存在しなければ業務が成立しない。

この非対称性が、後述する結論につながっていく。

9分類を業務ドメインにマッピングする

Anthropicの9分類は、説明型、検証型、データ・監視接続型、自動化オーケストレーション型、コードスキャフォールディング型、コード品質・レビュー補助型、異常調査型、日常保守・ガードレール型、そしてベストプラクティス反復型(全カテゴリ横断の方法論)からなる。

全カテゴリを業務ドメインに逐一対応させることもできるが、冗長になるだけなので、ここでは業務エージェントにとって特に本質的な3つに絞る。説明型・検証型・ガードレール型だ。この3つを選んだ理由は後述するが、先に言ってしまうと、この3つが「業務エージェントの三本柱」だと考えているからだ。

説明型: 外部システムの仕様とGotchas

Anthropicの説明型スキルは、特定のライブラリやCLI、SDKの正しい使い方を教えるものだ。参考コードスニペットと、避けるべき落とし穴(Gotchas)のガイドが含まれる。

原文で挙げられているGotchasの例が秀逸なので紹介したい。

「サブスクリプションテーブルは追記のみ(append-only)で更新されない。欲しい行はcreated_atが最新の行ではなく、versionが最大の行である」

これを読んだとき、既視感があった。THAの応募者管理では、応募者の同一性をexternal_ids(外部媒体ごとのID)で管理し、アプリケーション層で「最新行をfetchする」パターンを採用している。DBのUNIQUE制約に依存しない設計判断だ。つまり我々のADRに書かれているアーキテクチャ決定事項は、エージェント視点ではそのままGotchasになる。

「応募者テーブルはappend-onlyなので、応募者の現在状態はexternal_idsで最新行を引くこと」——この一文を知らないエージェントは、古い選考ステータスを見て応募者に誤った連絡をする。コーディングエージェントの「versionが最大の行を使え」と、構造的に完全に同型だ。

業務ドメインの説明型スキルには、もう一つ重要な対象がある。外部システムの操作仕様だ。THAはPlaywrightによるブラウザ自動化で求人媒体を操作するが、各媒体には文書化されていない挙動が無数にある。「この画面は保存ボタンを押しても非同期処理が完了するまで遷移してはいけない」「この検索フォームは全角スペースで区切らないとヒットしない」。これらはすべてGotchasであり、site_schemaと組み合わせてスキルに蓄積される。

検証型: 「1週間かけて磨く価値がある」の意味

Anthropicは9分類の中で、検証型スキルについてだけ、明確に投資判断を示している。

検証スキルは、社内でClaudeの出力品質に対して最も測定可能なインパクトを持った。エンジニアが1週間かけて検証スキルを徹底的に磨くことには価値がある。

具体例として挙げられているsignup-flow-driver(ヘッドレスブラウザで登録→メール確認→オンボーディングを実行し、各ステップで状態をアサートする)は、THAのアーキテクチャを知る人なら気づくと思うが、我々がMode A(自律実行ワーカー)でやっていることそのものだ。応募者対応フローの各ステップでsession_contextsに状態を記録し、期待状態とのアサーションを行う。

前回の記事で「スキルテストは回帰管理である」と書いた。LLMという非決定的ランタイムを業務に組み込む以上、出力の検証は品質保証の中核になる。Anthropicが出力のビデオ録画やステップごとのプログラム的アサーションといった手法を挙げているのは、コーディングエージェントでも同じ結論に達したということだろう。

そして、Anthropicの関連調査ではさらに踏み込んだ指摘がある。ボトルネックはコードの生成から、生成されたものが正しいかの判断(verification)にシフトしている、と。業務エージェントではこの傾向がより顕著だ。「応募者への返信文面が生成できるか」はもはや問題ではない。「この文面がこの顧客企業の基準で送ってよいものか」を判定できるかが問題であり、その判定基準こそが検証スキルに書かれるべき内容になる。

ここで気づくべきことがある。検証基準は、ほとんどの場合、顧客組織の暗黙知である。「営業時間外に応募者へ連絡しない」「この職種の応募者には必ず勤務地確認を先に行う」。どの業務マニュアルにも書かれていないが、その組織の担当者なら全員知っている。検証スキルを書くという行為は、この暗黙知を明文化する行為に他ならない。

ガードレール型: Risk Tierとの合流

Anthropicのガードレール型スキルは、破壊的操作を伴うプロセスに強い保護を敷くものだ。面白いのはセッション内フックという実装で、例えば/carefulというスキルはrm -rf、DROP TABLE、force-push、kubectl deleteをインターセプトする。呼び出し時にのみ有効化され、セッション内でのみ持続する。

THAではこの問題をRisk Tierとして設計してきた。T1(読み取り・承認不要)からT4(不可逆操作・常時承認+二重確認)までの4段階で、MCPカスタムツールの実行時に判定する。前々回の記事で書いたとおり、権限設計の主軸はデータの機密性ではなく操作の不可逆性というのがTHAの設計思想だ。

コーディングの/carefulがrm -rfを止めるのと、業務のT4が「応募者への不採用通知送信」を止めるのは、同じ思想の異なる実装だ。どちらも「取り返しのつかない操作の前に人間を挟む」。ただし実装レイヤーが異なる。Anthropicのフックはエージェント側(セッション内)の制御であり、THAのRisk TierはMCPサーバー側(ツール実行時)の制御だ。

この違いは示唆的だ。THAは現在、Layer 1(Anthropic管理ツールのpermission_policy)とLayer 2(MCP Risk Tier)の2層でガードレールを敷いているが、スキル付属のセッション内フックはその中間、「このスキルを使う業務のときだけ有効になる一時的ガードレール」 という第3の選択肢になり得る。例えば「給与計算スキル」の呼び出し中だけ、外部送信系ツールを全てインターセプトする、といった制御だ。恒常的なルールにするには過剰だが、特定業務の実行中には妥当——そういう粒度の安全制御が、スキルという単位に紐づけられる。

業務のGotchasは暗黙知である — 本稿の核心

3つのカテゴリを歩いてきて、すべての道が同じ場所に通じていることに気づく。

Anthropicは「スキル内で最も情報密度が高いのはGotchasセクションであり、Claudeが実際につまずいた失敗点から積み上げ、継続的に更新すべきだ」と述べている。ここに業務ドメイン特有の変質が一つある。

コーディングのGotchasは技術的制約の知識だが、業務のGotchasは組織の暗黙知である。

コーディングのGotchas——「このAPIは60req/分でレート制限される」「ステージングはwebhook未処理でも200を返す」——は、システムの挙動という客観的事実だ。原理的には、ドキュメントに書かれ得たが書かれなかった情報である。

一方、業務のGotchasはどうか。

「この顧客企業では、応募者への初回連絡は営業時間内のみ」
「この媒体経由の応募者には、スカウト返信とみなされないよう文面冒頭で応募への言及を必ず入れる」
「この職種は現場責任者の事前確認なしに面接日程を確定してはいけない」

これらは客観的事実ではなく、組織の運用判断の堆積だ。誰かが過去に失敗し、修正され、以後「そういうもの」として引き継がれてきた。文書化されず、担当者の頭の中と、せいぜい引き継ぎメモの断片に存在する。組織論でいう暗黙知(tacit knowledge)そのものだ。

ここから、本稿の中心的な主張が導かれる。

業務エージェントにおけるスキル化とは、暗黙知の資産化である。

BPOの世界では長らく、業務品質は「良い担当者に当たるかどうか」に依存してきた。良い担当者とは、その業務のGotchasを大量に頭に入れている人だ。担当者が辞めれば知識は消える。引き継ぎ資料は書いた瞬間から陳腐化する。

スキルという形式は、この構造を変える。Gotchasがスキルファイルに書かれた瞬間、それは特定の人間から切り離された組織の資産になる。エージェントが失敗するたびにGotchasが追記され、スキルは成長する。Anthropicが「優れたスキルは少数の行から始まり、エッジケースに遭遇するたびに拡張される」と述べているのは、コーディングの文脈では開発効率の話だが、業務の文脈ではナレッジマネジメントの実装の話になる。

そしてこれは、スキルの管理基盤に要件を課す。暗黙知は運用の中で発見され続けるので、スキルは頻繁に更新される。更新には検証が要る(誤ったGotchasは誤った業務を量産する)。THAでスキルの昇格パイプライン——submitted → scanning → pending_approval → approved → active という状態機械と、バージョン管理されたskill_manifests——を設計しているのは、スキルを「書いたら終わりのドキュメント」ではなく「継続的にデプロイされる業務知識」として扱うためだ。Anthropicの社内配布モデル(サンドボックスに置く→Slackで共有→トラクションが出たら昇格)と構造が一致しているのは、偶然ではないと思っている。

おわりに: エージェントの上限を決めるもの

Anthropicは6月16日、もう一つの調査レポート "Agentic coding and persistent returns to expertise" を公開している。2025年10月から2026年4月までの約40万セッション(約23.5万ユーザー)を分析したものだ。

発見は明快だった。典型的なセッションでは、人間が計画的意思決定(何をするか)の大半を担い、Claudeが実行的意思決定(どうやるか)の大半を担う。そしてコーディングタスクの成功率は、ソフトウェアエンジニアと他職業でほとんど差がない。成功を左右するのはコーディング能力ではなく、解こうとしている問題へのドメイン理解だった。

エージェントが実行を担うようになった世界では、「何をすべきか」「何が正しい結果か」を知っていることが決定的な変数になる。そしてその知識の実体は、本稿で見てきたとおり、Gotchasという形で蓄積される暗黙知だ。

業務エージェントの競争力は、モデルの賢さでもブラウザ自動化の器用さでもなく、どれだけ質の高い業務知識をスキルとして資産化できているかで決まっていく。モデルは各社共通のコモディティになり、実行技術はいずれ追いつかれる。追いつかれないのは、顧客の現場で一つずつ拾い上げたGotchasの蓄積だけだ。

スキルとは、単なるMarkdownファイルではない。組織の暗黙知が、初めて複利で増える資産になったものだ。

参考文献