投稿者 投稿日: カテゴリー Claude
Agent Skills とは、AIに業務手順を覚えさせる標準ファイル形式のことです。
毎朝チャット欄に「あなたは楽天市場の運営担当です。商品名は半角255文字以内で……」から始まる同じ前置きを貼り直している。担当者が3人いれば3種類の前置きがあり、出てくる商品名の書式も微妙に違う。この状態を解消する仕組みが Agent Skills です。2025年12月18日にAnthropicが仕様とSDKを公開してオープン標準になり、いまでは26以上のプラットフォームが同じ SKILL.md 形式を読み込めます。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、EC業務の手順書をスキル化する手順をプロンプト4本つきで解説します。
プロンプトを貼り直す運用が限界を迎えた理由
結論として、プロンプトの使い回しでは業務の標準化はできません。理由は、プロンプトが「その場の入力」であって「組織の資産」にならないからです。3人の担当者がそれぞれ自分のメモ帳に前置きを持っている状態は、Excelのマクロが個人PCに散らばっているのと構造が同じです。
Anthropicが Agent Skills をオープン標準として公開したのが2025年12月18日でした。仕様はagentskills.ioで公開されており、Claude だけでなく OpenAI Codex、Gemini CLI、GitHub Copilot、Cursor、VS Code など26以上のツールが同じファイル形式を読み込めます（対応ツール数は公開情報ベース、詳細な最新数は要確認）。ここが重要な変化点です。特定のAIベンダーに手順書をロックインされる心配が薄れたため、社内の業務知識をファイルとして残す判断がしやすくなりました。
EC運営の現場に引き寄せて考えます。楽天RMSの商品登録画面に入力する商品名のルール、Amazon Seller Central の箇条書き5項目の書き分け、Shopify Admin のメタフィールド命名規則。これらはどの店舗にも必ず存在しますが、多くの場合は「ベテランの頭の中」か「更新が止まった社内Wiki」にあります。新人が入るたびに口頭で伝え、伝え漏れた部分がそのまま品質のばらつきになります。
現場で繰り返し見るのは、手順書そのものは存在するのに、AIに渡す形になっていないケースです。Wordで書かれた20ページのマニュアルは人間向けの構成で、AIに渡すと前提条件と例外処理が混ざって精度が落ちます。Agent Skills が解く問題は、この「人間向け手順書とAI向け指示のあいだの翻訳」を、ファイル1枚の形式に固定することです。
日本のEC事業者にとっての実利は3つあります。第一に、担当者が変わっても出力の書式が変わらないこと。第二に、モール規約の改定があったときに1ファイルを直せば全員に反映されること。第三に、ツールを乗り換えても手順書が持ち運べることです。3つ目は特に効きます。2026年に入ってからのモデル更新の速さを考えると、手順書がベンダー固有のカスタム指示欄に埋まっている状態はリスクでしかありません。
もう少し具体化します。楽天市場は年に何度か商品ページや検索まわりの仕様を更新し、Amazonも商品タイトルの扱いや出品資格の運用を随時変えています。こうした変更のたびに、担当者3人がそれぞれの手元プロンプトを直す運用では、必ず1人が直し忘れます。直し忘れた1人の出力だけが旧ルールのまま流れ、数か月後に「なぜこの商品だけ書式が違うのか」という調査コストが発生します。1ファイルに集約されていれば、更新は1回で済み、更新日も記録に残ります。
繁忙期を考えると効果はさらに大きくなります。年末商戦や大型セールの前は登録点数が平常月の数倍になり、外部スタッフを一時的に入れる店舗も多いはずです。手順書がファイルとして存在していれば、初日から一定の品質で作業に入ってもらえます。口頭引き継ぎに半日かけていた工程が、スキルの読み込みと数件のテスト出力で済むようになります。
SKILL.mdの構造を5分で理解する
結論から言えば、SKILL.md は「YAMLの見出し」と「マークダウンの本文」の2層構造だけです。フォルダを1つ作り、その中に SKILL.md を1枚置けば最小構成のスキルが完成します。
先頭の3本ハイフンで囲まれた部分が YAML フロントマターと呼ばれる領域で、ここに name（スキルの識別名）と description（何をするスキルか、いつ起動するか）を書きます。description が実質的な起動条件になります。AIはユーザーの発話とこの description を照合して、どのスキルを読み込むかを判断するためです。ここを「商品名を最適化するスキル」とだけ書くと発火せず、「楽天の商品名」「商品名を直して」「キャッチコピー」など、現場で実際に使う言い回しを並べておくと安定します。
本文側には、AIに守らせたい処理の手順を書きます。ここは人間向けマニュアルとは書き方を変える必要があります。守るべき順番を番号付きで示し、判断が分岐する箇所は条件を明示し、絶対にやってはいけないことは「禁止」と書き切ります。曖昧な形容詞（丁寧に、適切に、しっかりと）は精度を下げるので、数値と具体名に置き換えます。
分量が増えたら参照ファイルに分けます。SKILL.md 本体には要点だけを残し、詳細な仕様表や実例集は references フォルダに切り出して、本体から「詳細は references/xxx.md を参照」と書いておく形が扱いやすい構成です。AIは必要になった時点で参照ファイルを読むため、本体を軽く保つほど起動が速くなります。
うるチカラの運営元で実際に使っているスキルを例にすると、楽天の商品名最適化スキルは SKILL.md 本体に文字数上限とNGワードの原則だけを置き、ジャンル別の訴求語リストと過去の改善事例は参照ファイルに逃がしています。編集部で実際に運用しているプロンプトでは、この分割をしたあとに出力のばらつきが目に見えて減りました。
ファイルの置き場所はツールによって異なります。Claude Codeならプロジェクト直下の .claude/skills 配下、あるいはユーザー共通の領域に置きます。詳細な配置ルールは各ツールの公式ドキュメントに従ってください（ツールごとに差があるため要確認）。
もう1つ押さえておきたいのが、スキルとカスタム指示の役割分担です。ChatGPT のカスタム指示や Claude のプロジェクト設定は「常に効いている前提条件」を書く場所で、スキルは「特定の作業のときだけ呼び出される手順書」です。ここを混同して、常時読み込まれる設定欄に業務手順を全部詰め込むと、関係のない会話にまで手順が影響して出力が固くなります。会社の基本情報や文体の指定は常時側、商品名の作り方やレビュー返信の型はスキル側、と切り分けるのが実務的な線引きです。
書式面で1点だけ補足します。SKILL.md の本文で表組みを多用すると、参照ファイルに切り出したときに構造が崩れやすくなります。仕様の一覧のように表が自然な情報は表のまま残し、判断の手順は箇条書きと番号付きで書くほうが、AIの読み取り精度が安定する傾向があります。これは公式仕様の要件ではなく、運用上の経験則です。
EC業務をスキル化する4ステップ
ここからが実装です。既存の業務をスキルに落とし込む手順を4段階に分け、各段階で使えるプロンプトを4本用意しました。プロンプトは ChatGPT、Claude、Gemini のいずれでも動きます。
ステップ1：スキル化する業務を選ぶ
最初に選ぶべきは、頻度が高く、判断基準が言語化でき、出力の正解形が決まっている業務です。商品名の作成、レビュー返信、問い合わせの一次回答、セール企画の告知文、商品説明文のリライト。この5つはどの店舗でも候補になります。逆に、仕入れ先との価格交渉のように相手の反応で判断が変わる業務は、初手には向きません。
（用途タイトル：スキル化候補の洗い出し）
プロンプト1：EC業務のスキル化候補を洗い出す
あなたはEC運営の業務設計に詳しいコンサルタントです。
以下の店舗情報をもとに、Agent Skills（SKILL.md形式の手順書）に落とし込むべき業務を10個挙げ、優先順位を付けてください。
評価軸：
1. 月間の実施頻度（多いほど高評価）
2. 1回あたりの所要時間
3. 判断基準を文章で言語化できるか（できるほど高評価）
4. 出力の正解形が決まっているか
5. 担当者による品質のばらつきの大きさ
店舗情報：
- 出店モール：{楽天／Amazon／Yahoo!／Shopify}
- 商品ジャンル：{ジャンル}
- 月間新規登録点数：{点数}
- 運営人数：{人数}
- いま一番時間を取られている作業：{作業内容}
出力フォーマット：
順位／業務名／月間頻度／想定削減時間／スキル化の難易度（易・中・難）／最初に固めるべき判断基準を1行
ステップ2：暗黙知を条件文に変換する
選んだ業務について、ベテランの頭の中にある判断基準を条件文に書き出します。ここが最も手間のかかる工程で、実務では担当者へのヒアリングを1時間ほど行い、その記録をAIに整理させる進め方が効率的でした。
（用途タイトル：暗黙知の条件文化）
プロンプト2：業務の暗黙知を判断条件に分解する
あなたは業務手順書の設計者です。
以下のヒアリング記録から、AIが実行できる形の判断条件を抽出してください。
抽出のルール：
1. 「丁寧に」「適切に」「うまく」などの曖昧な形容詞は、数値または具体名に置き換える
2. 分岐がある箇所は「もし〜なら〜、そうでなければ〜」の形に書き直す
3. 禁止事項は「禁止」と明示し、理由を1行添える
4. 判断がつかない箇所は「要確認」とラベルを付けて残す（推測で埋めない）
5. 例外処理は本文から分離し、末尾にまとめる
ヒアリング記録：
{記録本文をそのまま貼り付け}
出力フォーマット：
A. 必ず守る原則（3〜5項目）
B. 手順（番号付き、各手順に判断条件を付記）
C. 禁止事項（理由付き）
D. 例外処理
E. 要確認リスト
ステップ3：SKILL.mdの形に整える
条件文が揃ったら、YAML フロントマターと本文の形式に整えます。description の書き方がスキルの成否を分けるので、ここは時間をかけます。
（用途タイトル：SKILL.md本体の生成）
プロンプト3：SKILL.md本体を生成する
あなたはAgent Skills（agentskills.io の SKILL.md 形式）に精通した設計者です。
以下の業務条件から、SKILL.md を1枚生成してください。
出力の要件：
1. 冒頭にYAMLフロントマターを置き、name と description を記述する
2. description には、このスキルが起動すべき日本語の発話例を6個以上含める（現場で実際に使う言い回しにする）
3. 本文は「概要」「最重要原則」「処理フロー（番号付き）」「出力フォーマット」「禁止事項」「エッジケース」の6章構成にする
4. 曖昧な形容詞は使わず、数値・画面名・フィールド名で書く
5. 本文が2,000字を超える場合は、詳細部分を references/ に切り出す前提で「詳細は references/xxx.md を参照」と記載する
業務条件：
{プロンプト2の出力A〜Eをそのまま貼り付け}
対象プラットフォーム：{楽天RMS／Amazon Seller Central／Shopify Admin／Yahoo!ストアクリエイターPro}
ステップ4：発火テストと調整
作ったスキルは必ず発火テストをします。実際に現場で使う言い回しを10通り投げて、狙ったスキルが読み込まれるかを確認する作業です。ここを飛ばすと、せっかく作ったのに誰も使わないスキルができあがります。
（用途タイトル：発火テストケースの作成）
プロンプト4：スキルの発火テストケースを作る
あなたはAIエージェントの品質評価担当です。
以下のSKILL.mdについて、発火テストのケースを作成してください。
作成するケース：
A. 発火すべき言い回し 10通り（現場担当者が実際に使いそうな日本語。略語・口語・タイプミスを含める）
B. 発火してはいけない紛らわしい言い回し 5通り（別業務と混同されそうなもの）
C. 各ケースの期待結果（このスキルが起動する／しない）
D. 発火しなかった場合に description のどこを直すかの指針
SKILL.md：
{プロンプト3の出力を貼り付け}
スキル化でつまずく3つのパターン
第一の失敗は、description を機能説明で書いてしまうことです。「商品名を最適化します」と書いても、現場の担当者は「楽天のタイトル直して」と言います。description には機能ではなく、起動させたい発話をそのまま並べます。ここを直すだけで発火率が改善したケースを複数見ています。
第二の失敗は、SKILL.md に情報を詰め込みすぎることです。ジャンル別の訴求語を数百行並べたスキルは、読み込みに時間がかかるうえ、AIが本文の後半を軽く扱う傾向が出ます。本体は要点に絞り、詳細は参照ファイルに切り出すのが定石です。
第三の失敗は、モール規約に触れる内容を検証せずに書き込むことです。楽天市場の店舗運営では、楽天R-Mail の本文に自社サイトやLINE公式など楽天市場外へのリンクを置くことはできません。スキルの手順に「メルマガから自社ブログへ誘導」と書いてしまうと、AIは忠実にそのとおりの原稿を作ります。規約に関わる部分は、スキルに書き込む前に公式マニュアルで確認する運用を挟んでください。Amazonでも、商品紹介コンテンツ内への外部URL掲載は原則として認められていません。
補足すると、この3つ目は「AIが間違えた」ではなく「手順書が間違っていた」事故です。スキルは指示に忠実なので、誤った前提を書けば誤った成果物が量産されます。人間の担当者なら「これは規約的にまずいのでは」と踏みとどまる場面でも、スキルは止まりません。だからこそ、規約に関わる記述には「この項目は年1回、公式マニュアルで再確認する」といった見直し周期を、スキル本文の末尾にメモとして残しておく運用をおすすめします。
スキルが10本を超えたときの管理設計
結論として、スキルは5本目あたりから管理設計が必要になります。理由は、description の守備範囲が重なり始め、意図しないスキルが起動するようになるからです。商品名スキルとキャッチコピースキルを別々に作ると、「タイトル直して」という一言でどちらが呼ばれるか読めなくなります。
対策は3つあります。1つ目は命名の統一で、スキル名をプラットフォーム＋業務の形（rakuten-item-name、amazon-bullet-point のような形）に揃えます。2つ目は description の重複チェックで、新しいスキルを追加するたびに既存スキルの description と発話例が衝突していないかを確認します。3つ目は相互参照の明記で、似た用途のスキルがある場合は description の末尾に「◯◯の場合は別スキル xxx を使う」と書いておきます。
アパレル系の単一店舗で試したケースでは、スキルが8本を超えたあたりで発火の取り違えが目立ち始め、命名規則を入れ直すのに半日ほどかかりました。最初から命名規則を決めておけば避けられた手戻りです。
管理の場所も決めておきます。1スキル1フォルダで共有ストレージに置き、更新履歴が残る形にします。バージョン管理ツールが社内にあるならそれが最善ですが、無い場合はクラウドストレージのバージョン履歴機能でも実用に耐えます。重要なのは、誰がいつ何を変えたかを後から追えることです。モール規約の改定に追随した記録が残っていないと、数か月後に「なぜこの手順になっているのか」が誰にも分からなくなります。
費用と工数の目安
費用面はシンプルです。Agent Skills 自体はファイル形式なので追加料金は発生しません。かかるのは実行環境の利用料だけです。Claude の有料プランは月額20米ドルから、API を直接使う場合は Claude Sonnet 5 が100万トークンあたり入力2米ドル・出力10米ドルの導入価格で提供されており、2026年8月31日を過ぎると入力3米ドル・出力15米ドルの通常価格に移行します。Claude Opus 5 は入力5米ドル・出力25米ドル、Claude Haiku 4.5 は入力1米ドル・出力5米ドルです。
工数の目安は、1つのスキルにつき初回3〜5時間というのが現場感覚です。内訳は、ヒアリングと条件文化に2時間、SKILL.md の作成に1時間、発火テストと調整に1〜2時間です。2本目以降は前のスキルの構造を流用できるため、1〜2時間程度に縮みます。
効果の測り方は、削減時間ではなく「ばらつきの縮小」で見ることをおすすめします。同じ業務を3人が実行した出力を並べ、書式が揃っているか、禁止表現が混入していないかを比較します。時間短縮は副次効果として後からついてきます。5,000社支援の中で何度も再現したパターンとして、時間削減を先に指標に置くと、担当者が「早く出す」方向に最適化して品質が落ちます。
指標として置きやすいのは次の3つです。第一に、修正率。スキルの出力をそのまま採用できた件数を分母に取り、人間が手直しした割合を出します。運用開始直後は5割前後になることが多く、description と本文を2〜3回調整すると2割前後まで下がるのが1つの目安です（店舗の業務内容によって差が出るため参考値）。第二に、禁止表現の混入件数。薬機法や景品表示法に触れる表現、モール規約で使えない最大級表現が出力に混ざった回数をゼロに寄せます。第三に、新任担当者が独力で出力できるまでの日数。属人化の解消が目的である以上、ここが縮まなければスキル化の意味は薄くなります。
導入初月の進め方としては、1本目のスキルを作って2週間運用し、修正率と混入件数を記録してから2本目に進む順序をおすすめします。いきなり5本作ると、どのスキルの調整が効いたのか判別できなくなります。
この先1年で起きること
競合の解説記事が触れていない論点を1つ挙げます。Agent Skills がオープン標準になったことで、これから起きるのは「スキルの流通」です。すでに公式ディレクトリとコミュニティ系のマーケットプレイスの両方が動き始めており、他社が作ったスキルを持ち込む選択肢が現実的になりました。
ここでEC事業者が注意すべきなのは、外部から持ち込んだスキルの中身を読まずに使うリスクです。SKILL.md は自然文で書かれた指示書なので、悪意ある指示を紛れ込ませることが技術的に容易です。AIエージェントに楽天RMSやSeller Centralの操作権限を渡している環境で、審査されていないスキルを読み込ませるのは危険です。導入前に SKILL.md 本文を人間が全文読む運用を、社内ルールとして先に決めておくべきでしょう。
具体的な運用ルールとしては、外部スキルの受け入れ手順を3段階で決めておくと機能します。まず SKILL.md 本文と参照ファイルを全文読み、権限を要求する記述や外部への送信を伴う記述がないかを確認します。次に、本番環境ではなく検証用の環境で1週間動かし、想定外の動作が出ないかを見ます。最後に、社内の命名規則に合わせて description を書き換えてから登録します。この3段階を通すだけで、持ち込みスキル由来の事故はかなり抑えられます。
もう1つの論点は、スキルとAIモデルの分離です。手順書がベンダー中立のファイルになったことで、モデルの乗り換えコストが下がりました。これは裏を返せば、モデル選定を業務単位で最適化できるということです。商品説明文の一括生成は安いモデル、規約チェックは上位モデル、といった使い分けを前提に、スキル側には「このスキルは高い精度が必要」といった注記を残しておくと、後の運用が楽になります。うるチカラではClaudeのモデル選び方やClaude Codeのサブエージェントとモデル指定でこのあたりを扱っています。
よくある質問
Agent Skills は無料で始められますか
はい、始められます。SKILL.md はテキストファイルなので作成に費用はかかりません。必要なのは実行環境で、Claude の有料プランなら月額20米ドルから、API 利用なら従量課金です。まず1本作って手元で試すだけなら、既存の契約の範囲で完結します。
プログラミングの知識は必要ですか
いいえ、必須ではありません。SKILL.md はマークダウンとYAMLで書かれた文書で、コードは含みません。ただしファイルを所定のフォルダに置く操作は発生するため、フォルダ構造を扱える程度のPC操作は必要です。
ChatGPT や Gemini でも同じスキルが使えますか
はい、使えます。Agent Skills はオープン標準として公開されており、OpenAI Codex、Gemini CLI、GitHub Copilot、Cursor など26以上のツールが同じ SKILL.md 形式に対応しています。ただし配置場所や読み込みの挙動はツールごとに差があるため、乗り換え時は各ツールの公式ドキュメントを確認してください。
1本目はどの業務から作るべきですか
レビュー返信か商品名作成のどちらかをおすすめします。両方とも頻度が高く、判断基準を言語化しやすく、出力の正解形がはっきりしているためです。逆に、価格設定や仕入判断のように外部要因で結論が変わる業務は、スキル化の練習には向きません。
外注しないと作れませんか
いいえ、社内で作れます。むしろ最初の数本は社内で作るほうが良い結果になります。スキルの本体は業務の判断基準であり、それを一番知っているのは現場の担当者だからです。外注が効くのは、スキルが10本を超えて管理設計が必要になった段階です。
楽天やAmazonの規約に抵触しませんか
スキルを作ること自体は規約に抵触しません。注意が必要なのは、スキルに書き込んだ手順の中身です。楽天R-Mail から楽天市場外へのリンク誘導、Amazonの商品紹介コンテンツへの外部URL掲載などは規約で認められていないため、これらを手順に含めないでください。規約に関わる箇所は公式マニュアルで確認してから書き込む運用が安全です。
作ったスキルはどう管理すればよいですか
社内の共有ストレージかバージョン管理ツールで、1スキル1フォルダの単位で管理します。更新履歴が残る場所に置くことが重要で、モール規約の改定に合わせて誰がいつ直したかを追えるようにしておきます。担当者の個人PCに置くのは、属人化を解消するという目的そのものに反します。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
