AIに「仕事のやり方」を教える ── コーディングエージェントのSkillsという考え方

なぜ、いま注目されているのか

コーディングエージェントは、この1〜2年で「試す」段階を明確に超えた。そして実務に入った途端、多くの現場が同じ壁にぶつかっている。毎回、同じ前提を説明し直しているという壁である。

結果として、成果は「指示のうまさ」に左右される。効率化のために導入したはずが、属人化が別の形で再発する。ならば常時読ませる指示書にすべて書けばいい──そう考えるのは自然だが、これは長続きしない。書くほど長くなり、重要な指示が埋もれ、処理も遅く高くなる。足し算では解けない問題なのだ。

Skillsとは何か、どう使うのか

実体は拍子抜けするほど単純で、フォルダに置かれた一枚のテキストファイルである。特別な開発も専用のシステムも要らない。

---
name: proposal-writer
description: 顧客向けの提案書を作るときに使う。
---

# 提案書の作成手順

## 構成（この順番を守る）
1. 課題の整理  ── 顧客の言葉をそのまま引用する
2. 打ち手の提案 ── 必ず2案以上、比較表をつける
3. 費用        ── 内訳を必ず開示する

## 迷ったときの判断
- 専門用語は使わない。使うなら初出時に一行で説明する
- 金額は「〜万円程度」ではなく、上限と下限を書く
- 納期を確約する表現（必ず・保証します）は使わない

見てのとおり、プログラムではなく日本語の業務マニュアルだ。だからエンジニアではなく、その業務を最もよく知っている人が書ける。

最も重要なのは冒頭の説明文（description）である。AIはこの一文だけを見て、いま自分に必要かを判断する。いわばマニュアルの背表紙にあたる。

肝は2番目だ。利用者が「このスキルを使って」と指定する必要はない。AIが自分で判断して開く。だから10個あっても100個あっても、普段のやりとりは重くならない。

どのように管理されるのか

Skillsの本当の強みは、機能よりも管理のしやすさにある。実体がただのファイルであるため、既存の文書管理の仕組みにそのまま乗る。

プロジェクト/
└─ .claude/skills/
    ├─ proposal-writer/
    │   ├─ SKILL.md      ← 手順の本体
    │   └─ template.md   ← 添付する雛形
    └─ estimate-rules/
        ├─ SKILL.md
        └─ calc.py       ← 計算用プログラム

そして置き場所が、そのまま公開範囲になる。自分の環境に置けば自分だけ、プロジェクトに同梱すればチーム全員、全社配布すれば部署をまたいで共有される。

さらにテキストファイルであるため、通常のバージョン管理に乗る。いつ誰が手順を変えたかが残り、反映前にレビューでき、まずければ元に戻せる。AIへの指示に品質保証をかけられる、ということでもある。

なぜ、いま実現できたのか

「手順書を置いておけばAIが読んで動く」。言葉にすれば単純だが、この仕組みは3年前には成立しなかった。四つの条件が揃って、はじめて成り立つものだからである。

整理すると、変化の本質は「たくさん指示できるようになった」ことではない。指示を出し入れできるようになったことにある。この制御が効くようになったからこそ、手順書を何十枚も抱えておくという形が現実的になった。

どんな使い方ができるのか

用途は職種を問わない。いずれも「ベテランなら当然やっている確認」を文章にしたもの、つまり暗黙知の言語化である。

こうして並べると、うまくいく業務には共通の型があることが見えてくる。判断基準のある、反復業務である。

原則と、作り時

スキルは書けば効くというものではない。運用してみると、効くものと効かないものの差は、はっきりした原則に集約される。

• 1.
  1つのスキルに、1つの仕事
  「文書関連まとめ」のような大きな束にすると、AIは使いどころを判断できなくなる。迷ったら細かすぎるほうがまだよい。
• 2.
  説明文が命
  開かれるかどうかは説明文だけで決まる。「文書を作る」では広すぎる。いつ使い、いつ使わないかまで書く。
• 3.
  「何をするか」より「どう判断するか」
  手順の羅列はAIが自力でこなせる部分が多い。価値があるのは迷ったときの基準のほうだ。
• 4.
  使われないものは、消す
  更新されない手順書は、古い間違いを正確に再現する装置になる。増やすことより棚卸しのほうが難しい。
• 5.
  秘匿情報は、書かない
  共有・配布されるファイルである。鍵や個人情報は置かず、参照先を書くにとどめる。

では、いつ作るか。次の5問のうちYesが2つ以上あれば、作る価値がある。

• 同じ説明を、3回以上しているか
• 人によって、成果物のばらつきが大きいか
• 判断の基準を、言葉にできるか
• 手順が変わったとき、全員に反映したいか
• 新しい人が入るたびに、同じことを教えているか

結論

エージェントが十分に賢くなったいま、成果を分けるのはAIの性能ではない。AIに渡している情報の質である。Skillsは、これまで個人の中に消えていたその情報を、共有され、改訂され、積み上がるものに変える仕組みだ。

前回の記事では、AI活用には「作る（自社開発する）」か「使う（既製品で済ませる）」かの線引きが要る、と書いた。Skillsは、その二択の間にある第三の道にあたる。コードを書くのではなく、業務のやり方を書く。しかも書き手は、その仕事を最もよく知っている人でいい。