Agent Skills とは — 作業手順を AI に持たせる仕組みと、属人化させない共有設計

Agent Skills とは何か

結論から言うと、繰り返す作業の手順を書いておいて、必要なときに AI エージェントへ読み込ませる仕組み です。毎回同じ説明をプロンプトに書き直す必要がなくなります。

見方を変えると、AI 向けに書かれた作業手順書です。人向けの手順書と違うのは、読んで理解する相手が AI で、読んだあとに実際の作業まで進むところです。

導入の動機は 2 つに分かれます。1 つは手間の削減。もう 1 つは、担当者が違っても同じ手順で進むようにすることです。実務で効きやすいのは後者ですが、期待どおりに効かせるには前提があります。

毎回プロンプトに書くのと何が違うか

「同じことをプロンプトに書けばよいのでは」と思われることがあります。結果として動くところは同じです。違うのは、書いた内容がどこに残るかです。

方式	残る場所	内容の更新	他の人の利用
毎回プロンプトに書く	会話の中だけ	書いた人の記憶頼み	できない
手順として置いておく	決まった場所	直せば全員に効く	呼び出せば使える

差が出るのは 2 人目からです。 1 人で使っているあいだは、プロンプトに書いても手順にしても大差ありません。担当者が増えたとき、あるいは自分が半年後に同じ作業をするときに、書いた内容が残っているかどうかが効いてきます。

逆に言えば、1 人でしかやらない作業、二度とやらない作業を手順にする意味は薄いということです。ここを取り違えると、使われない手順ばかりが増えます。

効くのは判断が要らない作業

判断の軸は単純です。手順が決まっていて、毎回同じ順番で進む作業かどうか。 ここが分かれ目になります。

作業の性質	向き不向き	理由
決まった形式の成果物を作る	向く	手順が固定で、出力の形も決まる
決まったチェック項目を通す	向く	抜けが起きやすく、機械的に効く
状況によってやることが変わる	向かない	手順に落とすと判断が飛ばされる
前提の確認そのものが目的の作業	向かない	確認したことにされる危険がある

とくに 3 つ目と 4 つ目に注意が要ります。判断が要る部分を手順に包み込むと、判断していないのに判断したように見える状態 ができます。手順どおり動いた結果として出てきたものは、通してしまいがちです。

逆に言えば、判断を外に出せる作業なら効きます。作る前に、その作業から判断を切り離せるかを確認してください。

人向けの手順書との違い

「手順書ならもう社内にある」という場合もあります。ただ、人向けに書かれた手順書をそのまま渡しても、期待どおりには動きません。書き方の前提が違うためです。

観点	人向けの手順書	AI 向けの手順
前提の扱い	常識として省略される	省略すると埋められてしまう
判断の記述	「適宜」で通じる	条件を書かないと止まらない
背景の説明	納得のために要る	短いほうが確実に動く
曖昧さ	読み手が補完してくれる	補完の方向が制御できない

差が大きいのは 1 行目です。人向けの手順書は、社内の常識を書かないことで読みやすくなっています。 その常識は共有されていないので、書かなければ別のもので埋まります。

既存の手順書を流用する場合は、省略されている前提を書き足す作業が要ります。そのまま渡して期待どおりに動かないのは、内容が悪いのではなく、想定読者が違うからです。

属人化はどこから始まるか

Agent Skills には、放っておくと属人化する性質があります。原因は 2 つです。

1 つ目は、個人の手元に置いたまま使えてしまう こと。作った本人は困っていないので、共有する動機が生まれません。他の人はその存在すら知らないまま、同じ作業を毎回プロンプトで説明しています。

2 つ目は、更新されないまま残る こと。手順は前提が変われば古くなりますが、直す責任者が決まっていないと放置されます。古い手順が動き続けるのは、使われないより厄介です。

共有するなら 3 点を先に決める

チームで使うなら、作る前に次の 3 点を決めてください。順番も含めて、これが最小構成です。

1. 置き場所。個人の環境ではなく、チームが見える場所に置きます
2. 更新責任。誰が直すかを決めます。作った人でなくて構いませんが、空欄にはしません
3. 使わない条件。どういう作業には適用しないかを書きます。ここが無いと拡大解釈されます

3 つ目が抜けがちです。便利な仕組みは適用範囲が広がるので、向かない作業にまで使われます。「判断が要る作業には使わない」と一行書いておく だけで、その拡大が止まります。

中身に何を書くか

手順そのものの書き方にも、効き目を左右する点があります。判断の軸は、書いた人がいなくても同じ結果になるか です。

書くべきなのは次の 3 つです。

• 何を作るのか。完成した状態を先に書く
• どういう順番で進めるか。飛ばしてよい手順があるなら、その条件も書く
• 終わったかどうかをどう判断するか。確認の項目を並べる

3 つ目を書いておくと、途中で止まったのか終わったのかが曖昧になりません。逆に、確認の項目が書かれていない手順は、動いたように見えて何も終わっていないことがあります。

書かなくてよいのは、背景や経緯です。人向けの手順書だと理解を助ける部分ですが、長くなるほど本題が薄まります。必要なのは、読んで動けることであって、納得できることではありません。

2 人目に試してもらう

作った直後は、書いた本人には使えて当たり前です。共有できる状態かどうかは、本人には判断できません。

確認は簡単で、その作業を知らない人に一度使ってもらう だけです。説明なしで期待どおりの結果になれば、手順として成立しています。途中で質問が出たら、その質問の答えが手順に書かれていない部分です。

この一手間を挟むかどうかで、置き場所に並んだあとに使われるかが決まります。使われない手順のほとんどは、書いた本人の前提が抜けたまま置かれています。

FIXIT

便利なら、どんどん作っていったほうがよくない？

Tsukasa

逆です。数が増えるほど、どれを使うか分からなくなって使われなくなります。

FIXIT

じゃあ、どこで線を引くの？

Tsukasa

判断の軸は使用頻度です。月に何度か使う作業だけ、で足ります。

作りすぎない

数を増やすほど価値が上がる仕組みではありません。増えるほど選べなくなり、結局どれも使われなくなります。

目安を 1 つ挙げるなら、実際に月に何度か使う作業だけを対象にする ことです。年に数回の作業は、その都度説明したほうが速く、保守の対象も増えません。

そして、使われていないものを定期的に消してください。作る運用だけがあって消す運用がないと、置き場所そのものが読まれなくなります。中身を把握できる量に保つのが、共有を成立させる条件です。

業務の標準化として見たとき

視点を上げると、この話は業務の標準化そのものです。手順を書いて共有し、誰がやっても同じ結果になるようにする。 昔から取り組まれてきたことと、目的は変わりません。

違うのは、書いた手順が実際に実行されるところです。人向けの手順書は、書いても読まれなければ何も起きません。読まれても、そのとおりに実行されるとは限りません。AI 向けの手順は、呼び出せばそのまま実行まで進みます。

このため、手順を書く動機が強くなります。 書けば実際に効くので、書くこと自体に見返りがあります。人向けの手順書が形骸化しやすかったのは、書いても効果が見えにくかったことが一因です。

ただし、標準化の落とし穴も同じです。

• 標準化しすぎると、例外への対応力が落ちる
• 手順が増えすぎると、誰も全体を把握できなくなる
• 標準に合わない仕事が「やりにくい仕事」として避けられる

3 つ目は、業務改善の文脈で昔から言われてきた話です。手順があることを理由に、手順に無い仕事を後回しにし始めたら、行き過ぎのサインです。

最初の 1 本は何にするか

これから始める場合、どの作業から手をつけるかで定着の速さが変わります。判断の軸は 3 つです。

1. 頻度が高い。月に何度も発生する作業から選びます
2. 手順が固まっている。やり方が人によって変わらないものにします
3. 失敗しても取り返せる。最初の 1 本で大きな事故が起きない領域を選びます

3 つ目を軽視しないでください。最初に選んだ作業で問題が起きると、仕組みそのものへの信用が下がります。技術的な難易度ではなく、失敗したときの影響で選ぶのが安全です。

具体的には、決まった形式の文書を作る、決まった観点で内容を点検する、といった作業が向いています。逆に、外部に出るものを直接生成する作業や、消えたら困るデータを扱う作業は、慣れてからにしてください。

もう 1 点、最初の 1 本は完成度を求めないでください。 使いながら足りない部分が見えてくるので、そこで直すほうが早く仕上がります。最初から完全なものを書こうとすると、書き上がる前に手が止まります。

目安としては、自分が 1 回使えた時点で共有して構いません。 2 人目が使って出てきた質問が、そのまま次に書き足す内容になります。

前提が変わったときに気づく方法

属人化の 2 つ目の原因、「更新されないまま残る」への対処も書いておきます。放置される理由は、古くなったことに気づく機会が無い ことです。

有効なのは、次の 2 つです。

1 つは、使った人が違和感を報告する経路を作ること。手順どおりに進めて結果がおかしければ、それが古くなった合図です。報告先が決まっていないと、その人が個別に対処して終わります。

もう 1 つは、前提を変える側からたどれるようにすること。手順が依存している対象を変更するとき、その手順も直す必要があると分かる状態にしておきます。手順の側に「何に依存しているか」を書いておくだけでも違います。

依存先の例	変わったときに起きること
社内の書式・様式	古い形式で出力され続ける
参照している資料	存在しない場所を見に行く
判断基準・ルール	古い基準で通してしまう

3 行目が最も危険です。基準が変わったのに手順が古いままだと、間違った結果が正しい手順で出てきます。 動いているように見えるぶん、発見が遅れます。

効いているかをどう見るか

導入したあと、効果を測ろうとして凝った指標を作る必要はありません。見るべきは 2 つです。

1 つは 使われた回数。置いてあるだけで呼び出されていない手順は、存在していないのと同じです。もう 1 つは 同じ質問が減ったか。特定の作業について毎回同じことを聞かれていたなら、その質問が来なくなったかどうかが分かりやすい変化になります。

逆に、作った数を成果として数えるのはやめたほうがよいです。数は増やそうと思えばいくらでも増やせますが、増やすほど選べなくなるという逆向きの効果があります。数えるなら、作った数ではなく使われた数です。

厳密に計測する必要もありません。四半期に一度、チームに「どれを使っているか」を聞くだけで十分に分かります。名前が挙がらない手順は、使われていないと考えて構いません。 数字を集める仕組みを作る手間のほうが、得られるものより大きくなりがちです。

半年に一度でよいので、置き場所を一覧で眺めて、使われていないものを消す時間を取ってください。判断は「直近で使ったか」だけで足ります。迷ったら消して構いません。必要ならまた作れます。

この見直しは、担当者を決めておかないと実施されません。消す作業には誰の得もないので、意識して時間を取らないかぎり後回しになります。 更新責任を決めるときに、見直しの担当も一緒に決めておくのが実務的です。

チーム全体への広げ方は Claude Code を現場に定着させる進め方 に、全社規模での展開は Claude Code 全社導入 完全ガイド にまとめています。

導入の判断はいつ下すか

最後に、そもそも導入すべきかの判断軸を置いておきます。結論から言うと、同じ説明を 3 回書いたら作る で足ります。

3 回という数字に厳密な根拠はありませんが、目安として扱いやすい水準です。1 回目は例外かもしれない。2 回目は偶然かもしれない。3 回目は繰り返しです。

逆に、次の状態なら急ぐ必要はありません。

状態	判断
まだ 1 人でしか使っていない	型が固まるまで待つ
手順そのものが固まっていない	先に手順を決める
使うのが年に数回	都度説明するほうが安い
判断が中心の作業	対象にしない

2 行目が重要です。手順が決まっていないものを手順にはできません。 書こうとして書けないなら、それは仕組みの問題ではなく、業務がまだ定まっていないということです。その場合は、書く作業そのものが業務を整理する機会になります。

まとめ

• Agent Skills は、繰り返す作業の手順を AI に読み込ませる仕組み
• 効くのは判断が要らない定型作業。判断を包み込むと危険な状態になる
• 属人化の原因は「個人の手元」と「更新されないまま」の 2 つ
• 共有するなら、置き場所・更新責任・使わない条件を先に決める
• 使用頻度で線を引き、使われていないものは消す。作りすぎない
• 同じ説明を 3 回書いたら作る。手順が固まっていないものは、先に業務を整理する