社内業務で外れる Agent の主因は、モデル能力の不足より、社内手順が渡っていないことと、「合格」が未定義なことです。一般調査はできます。申請経路、権限、例外時の確認先は学習データにありません。プロンプトを足す前に、できることを Skills（SKILL.md）へパッケージし、挙動を Eval で測ります。テクノロジーの導入では、1業務を選び、同じ週に Skill 1本と自由回答 Eval 数件を作るところから始めます。
📑目次
社内Agentに足りないのはモデル能力ではなくオンボーディング
社内 Agent が的外れなのは、モデルが弱いからではありません。権限、申請経路、例外時の確認先が、学習データに無いからです。優秀だが未オンボーディングの新入社員と同じ状態です。
独立ソースが揃える定義
複数の独立した出典が、同じ根本原因をそれぞれ異なる表現で指摘しています。
- Pinggy は Skills を、new hire 向けオンボーディングガイドと定義しています。コーディング規約やプロジェクト慣例を文書で渡すのと同じことを、Agent に対して行います。
- SSW Rules は、tribal knowledge や社内フレームワークが学習データに無いときに Skill 化すると書いています。
- connect24h は、差がつくのはプロンプト調整ではなく、オンボーディングと Skills & Eval の設計だと述べています。
1組織パイロットの数字
松尾研究所は2026年8月20日に公開したZenn記事で、Notionの新入社員向け文書をCodex Skills化し、「知識なし」「Notionを都度検索」「Skills活用」の3条件を比較検証しました。
独立した再掲として ぴすけ が、項目正解率 33.0% / 87.3% / 96.0% を同日に伝えています。
- 実験は1組織・15課題のパイロットです。自社の合格ラインには使えません。
- テクノロジーの現場では、この数値を宣伝材料にせず、自業務の Rubric を先に書く必要があります。
出典（2026年8月時点）:
SKILL.mdで手順をパッケージする
Skill は「何をするか・いつ使うか」を YAML に書き、手順は Markdown、詳細は references/、決定的処理は scripts/ に分けるフォルダです。Agent Skills 仕様 では、最低限 SKILL.md を含むディレクトリが単位です。プロンプト（会話単位の一回限り指示）とは別物です。
手順
手順は次の通りです。
- ディレクトリ名を
nameと一致させる。小文字・数字・ハイフンのみ、1–64文字。先頭末尾ハイフンと連続ハイフンは不可です。 descriptionにトリガー語を入れる。1–1024文字。「Helps with X」は弱いです。何をするかと、いつ使うかを書きます。SKILL.md本文は 500行未満、約 5k tokens 未満を目安にします。条件、順序、完了状態、情報不足時の確認先、文書間の優先ルールを書きます。- 詳細は
references/へ。相対パスは Skill ルートから1段までです。skills-ref validate ./my-skillで frontmatter を検証します。
起動時のコスト
起動時に載る metadata は Skill あたり約 100 tokens です。50 Skills でも約 5,000 tokens の「目次」コストです。本文は該当時だけロードします。scripts の本体はコンテキストに入らず、出力だけが入ります。
仕様上の制限
ただし制限もあります。
nameにanthropic/claudeは使えません。- Custom Skills は claude.ai / API / Claude Code で同期しません。
- API Skills はネットワーク不可、実行時パッケージ導入不可です。Claude Code 側はフルネットワークです。
- Agent Skills は ZDR 対象外です。
- API 利用には beta headers
code-execution-2025-08-25/skills-2025-10-02/files-api-2025-04-14が必要です。
Databricks の対比
Databricks は、コーディングアシスタント向けに databricks aitools install を公開しています。主な引数は次です。
--agents claude-code--scope project--skills bundles,sql
公式の対比は「Skills teach how; MCP lets it do the work」です。社内手順をSkillに、ライブ操作はMCPに残すという分担は、仕様側でも一致しています。
出典（2026年8月時点）:
SkillsとMCP・都度検索の判断基準
結論を変える条件が安定している社内ルールはSkillに登録します。在庫状況や権限の現状、最新ドキュメントはMCPか検索に任せます。両方を使う場合は、Skill側に「いつどのツールをどう使うか」を明記してください。
| 観点 | Skills | MCP / 都度検索 |
|---|---|---|
| 答える問い | どう進めるか（手順・社内流儀） | 今何に届けるか（ライブデータ・ツール） |
| 形 | SKILL.md + 任意の scripts/references | 実行中サーバ / 検索+fetch |
| アイドル時コスト | 約100 tokens/skill | ツール定義＋プロセス / 毎回検索 |
| 向く変化 | 方法・優先ルール・完了定義 | 呼び出しごとに変わるデータ |
| 失敗 | 説明の誤解釈、description 不一致で発火しない | 検索漏れ、古いページ、遅延、コンテキスト肥大 |
出典（2026年8月時点）:
独立ソースの判断ヒューリスティック
- LlamaIndex は、MCP をスキーマ付きで決定的だが、発見コストとネットワーク遅延があると整理しています。
- Skills は軽い一方、how をモデルが解釈するため非決定的です。
- ドキュメントが速く変わる領域では、手動更新 Skills より Docs MCP の単一情報源が勝った、と報告しています。
- Pickaxe も、呼び出し間でデータが変わるなら MCP、変わるのが method / house style なら Skill、というヒューリスティックを書いています。
Skills 対 Notion 検索のパイロット
松尾研究所のSkills対Notion検索の比較では、次の差が確認されました。
- 項目正解率 96.0% 対 87.3%
- 応答時間中央値 60.4秒 対 94.0秒（約36%短い）
- 平均入力 token 48.6k 対 219.5k（約78%少ない）
- Notion 条件は 45回答で search 217回 / fetch 272回
検索そのものが悪いのではなく、安定した優先ルールを毎回探させるコストが大きい、と読むのが実務的です。
自由回答Evalで実務の合格ラインを定義する
Skillを渡しただけでは「仕事ができる」とは言えません。Evalこそが合格の定義そのものです。
Anthropic の用語
Anthropic の evals 解説 では、次を分けます。
- task
- trial
- grader
- transcript（発言の軌跡）
- outcome（環境の最終状態）
「予約しました」と、DB に予約があることは別です。Agent eval はモデル単体ではなく、モデル＋harness を測ります。継続評価の置き方は、MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計 とも重なります。
3段階の測り方
松尾研究所は3段階の評価手法を用いました。
- 一問一答（事実を知っているか）
- 自由回答（実務成果物）
- 作業完了（ツール操作の outcome）
最初の一問一答は消去法で解け、実務を測れませんでした。選択問題の正答率が高いだけでは、本番に出せません。LLM が推測で埋める構造は、LLMが「わからない」と言えない構造と、実務で封じるプロンプト／検証設計 でも別角度から扱っています。
Eval の書き方
手順は次の通りです。
- 実在の問い合わせ・失敗事例から課題を書く。選択問題にしない。
- 含めるべき項目を Rubric 化する。危険行為は critical を別枠にする。承認なし外部公開、事故を報告せず削除だけ、アクセス削除漏れが例です。
- 主要指標は項目正解率（文言一致ではなく意味充足）。補助は critical failure rate、応答時間、token、ツール回数です。
- 条件名を隠して複数 trial する。LLM-as-a-judge なら独立判定の一致率を見る。同実験は 972項目中 951 一致（97.8%）でした。
- 人が止まるべき・聞くべきケースを Eval に含める。The Main Thread は、手続きを Skill にパッケージし、止まる／人に聞くケースを含む realistic evaluations を回せ、と書いています。
| 条件 | 項目正解率 | Critical failure | 応答時間中央値 | 平均入力token |
|---|---|---|---|---|
| 知識なし | 33.0% | 100.0% | 64.2秒 | 41.9k |
| Notion都度検索 | 87.3% | 42.2% | 94.0秒 | 219.5k |
| Skills | 96.0% | 15.6% | 60.4秒 | 48.6k |
出典：松尾研究所（Zenn）、独立再掲 ぴすけ（2026年8月時点）。
- 15課題×3条件×3試行のパイロット
- 人間専門家の成果物品質採点はなく、業務 outcome は未測定
制限
制限を先に明確にしておきます。
- Skills でも critical failure は 15.6% 残ります。
- 数字が良くても、本番の自律実行の根拠にはしません。
- 完了報告と実データの変化を分ける考え方は、コーディングエージェントのテスト改ざんをテスト差分と検証分離で見抜くチェック の検証分離とも同じです。
テクノロジー導入チェックリスト（1業務から始める）
全部を一度に作ろうとしてはいけません。テクノロジーとしての社内Agentは、1つの業務についてSkillとEvalが揃ってから段階的に広げていくべきです。
- 対象業務を1つ選ぶ。申請、初動、レビューなど、結論を変える条件が書けるものです。
- 人間向けオンボーディングから、条件 / 順序 / 完了 / 確認先 / 優先ルールを
SKILL.mdとreferences/に移す。 - 会社共通 Skill はレビュー付きリポジトリ、プロジェクト Skill はリポジトリ内に置く。第三者 Skill は実行前に全文を読む。SSW は、Skill は設計上プロンプトインジェクションだと注意しています。
- 同じ業務の自由回答課題を少なくとも数件作る。critical 項目と「止まって人に聞く」ケースを含める。
- 知識なし / 検索 / Skills を同じ課題で試し、項目正解率と critical failure を見る。数字が良くても outcome 未確認なら、人の承認を残す。
- Notion 等のソースが更新されるなら、Skill の再生成経路を先に決める。手動追従は続きません。ドキュメントが週次で変わる領域は、Skill より MCP / 検索を優先します。
判断基準は次の通りです。
- 手順が安定している → Skill
- データが都度変わる → MCP / 検索
- 合格が文章の体裁だけ → Eval を作り直す
- critical failure が残る間は、承認なしの外部公開や権限変更を Agent に任せません
よくある質問
Skills を入れれば社内検索（Notion / RAG）は不要か？
不要ではありません。安定した手順と優先ルールは Skills、呼び出しごとに変わるデータは検索 / MCP です。両方使うなら、Skill 側に「いつ検索するか」を書きます。
SKILL.md に社内Wikiを全部貼ればよいか？
だめです。起動時に載るのは name / description で約100 tokens です。本文は 500行 / 5k tokens 目安で、詳細は references/ に分割します。全部を常時コンテキストに載せると、発火精度もコストも悪化します。
一問一答の正答率が高ければ本番に出せるか？
出せません。選択式は探索範囲が狭く、一般知識で当たることがあります。実務成果物の Rubric と、可能なら outcome（実データの変化）を見ます。
公式の Agent Skills は Claude 専用か？
形式は agentskills.io のオープン標準です。Databricks や Copilot 等もロードします。ただしインストール場所と同期は製品ごとに別管理です。Custom Skills のクロスサーフェス同期を期待しないでください。
コミュニティの Skill をそのまま使ってよいか？
使いません。全文を読み、シェル実行や秘密情報への指示がないかレビューします。社内 Skill は PR レビュー対象です。
関連記事:
まとめ
社内 Agent の差分は、プロンプト量より、手順のパッケージ（Skills）と合格定義（Eval）です。SKILL.md は description で発火し、本文と references で段階ロードします。MCP / 検索とは役割が違います。
次の一手は、1業務で Skill 1本と Rubric Eval 数件を作ることです。critical failure が残る間は、人の承認を外さないでください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す