繰り返す作業をスキルにする

なぜ要るか

6章までで、ゲームは形になりました。ここからは作り方そのものをAIへ渡していきます。

まず気づいてほしいことがあります。同じ説明を何度もしていませんか。

• 「絵は背景を緑にして、細い毛束を描かないで」
• 「テストは vitest で、決まった作り方で」
• 「commitメッセージは何をなぜ変えたかを書いて」

僕は最初、これを毎回打っていました。そして毎回、少しずつ違う指示になっていました。 結果、出てくるものも毎回少し違いました。

これをスキルとして保存します。1-5で作った AGENTS.md の発展形です。

スキルというのは、手順を書いた1枚のテキストファイルです。決められた場所に置いておくと、AIが必要なときに自分でそれを読み、書いてある手順どおりに進めてくれます。プログラムではないので、書くのは日本語で構いません。

使う道具: なし（テキストファイルだけ）

AIプロンプト

この術の作業をAIへ任せるときは、これをそのまま貼ってください。

いまやった作業を、次から1コマンドで再現できるスキルにして。
name と description を付けて、手順と禁止事項を分けて書いて。
description には、僕が使いそうな呼び方を3通り入れて。

直前にやった作業のあとで貼ると、手順を書き出す手間がなくなります。

ルールとスキルは別物です

先に区別します。ここを混ぜると、どちらも使いにくくなります。

ルールは短く、スキルは詳しく。 ルールが長いと毎回の指示が重くなり、AIが全部を守れなくなります。

僕のいまの構成はこうなっています。

ルール  13本    常に効く決まり
スキル  45本    呼んだときだけ効く手順

ルールが13本しかないのが要点です。 増やしたくなるたびに「これは常に必要か、呼ぶときだけか」を考えて、後者はスキルへ回しています。

スキルは「読ませる手順書」です

中身は普通のMarkdownです。特別な形式は要りません。Markdownは、# で見出し、- で箇条書きを表すだけの文章の書き方です。専用のソフトは要らず、テキストエディタで書けます。

---
name: make-task
description: タスク作成、タスク票作成、タスク起票の依頼を扱うときに使う。
---

# タスク管理

タスク系の依頼を受けたら、以下の方針で進める。

## 必須ルール
- タスク定義には要点のみ記載する
- 詳細設計や実装方針をタスク本体へ二重記載しない
...

先頭で --- に挟まれている部分が、そのスキルの名札です。ここから下が本文になります。大事なのは先頭の2行だけです。

description が一番大事です。 ここが曖昧だと、必要なときに読まれません。

呼び方も特別ではありません。ふだんの言葉で「タスク票を作って」と頼めば、AIが description を見て「これはあのスキルの話だ」と判断し、自分で読んでくれます。こちらから「あのスキルを使って」と指定する必要はありません。

書くコツは、依頼者が使いそうな言葉を並べることです。上の例では「タスク作成」「タスク票作成」「タスク起票」と3通り書いています。呼び方が揺れても拾われるようにするためです。

いつスキルにするか

判断は簡単です。3回目で作ります。

1回目で作ると、まだ手順が固まっていないので作り直しになります。3回やると、変わらない部分と毎回変わる部分が分かります。 変わらない部分だけを書きます。

この講座の見本ゲームなら、声を足す作業（5-3）がこれに当たります。 台詞は場面ごとに1本ずつ足していくので、「最初に決めた同じ声で作る・2秒以内のmp3にする・assets/voice/ の場面ごとのフォルダへ置く・再生音量は0.9で鳴らす」までが毎回同じです。変わるのは台詞の中身だけなので、スキルに書くのはこの4つになります。禁止も1行足します。「口パクの秒数を手で書かない」。 5-3で書いたとおり、差し替えのたびに必ず忘れる場所だからです。

大きくなったら分けます

手順が育つと1本では収まりません。そのときは親と子に分けます。

僕の場合、大きいものはこうなっています。

modeling         親 + 子9本    キャラの3Dを作る（部位ごとに手順が違う）
publish          親 + 子8本    公開する（媒体ごとに手順が違う）
image-generator  親 + 子4本    絵を作る（透過や差分で手順が違う）
video-generator  親 + 子3本    動画を作る

親は「どの子を使うか決める」だけにします。 4-1で使った透過処理も、この形の子スキルです。

分ける基準は判断の分岐です。「絵を作る」の中に「透過する場合」「差分を作る場合」があるなら、そこが子の境界です。

原本を1つに決めます

ここが実務でいちばん事故が起きるところです。

スキルは使う場所に配られていることがあります。プロジェクトの中、ホームの設定、複数のリポジトリ。同じ内容のファイルが複数の場所にある状態です。

僕はこれで一度失敗しました。配られた側を直して、次の配布で上書きされました。

だから決めます。

原本   1箇所だけ。ここしか編集しない
配布先 原本からコピーする。直接編集しない

配布は1コマンドにしておきます。原本から配布先へコピーする小さなスクリプトを1本用意して、更新のたびにそれを実行するだけにする、ということです。手でコピーすると、いつか片方だけ古くなります。

これは6-1で「同じ意味のものを2箇所に置かない」と書いたのと同じ話です。データでもファイルでも、正は1つ。

やってみる

1. 同じ説明を3回した作業を1つ選ぶ

   思い出せない場合は、過去のやり取りを検索してください。 同じ単語で何度も頼んでいる作業が見つかります。

2. 手順を書き出す

   ---
   name: game-shot
   description: ゲーム画面のスクリーンショットを撮るときに使う。図解用の画像を作る依頼で使う。
   ---
   
   # ゲーム画面の撮影
   
   ## 撮り方
   1. 760x900 で開く
   2. アニメーションはピーク位置で止める
   3. キャラの表情は素の顔にする
   4. jpeg 品質92で保存する
   
   ## 禁止
   - 撮影用のコードを index.html へ残さない
   

   「禁止」を書くのが効きます。 やってほしいことより、やってほしくないことの方が、放っておくと起きます。

3. AIに書かせてもいい

   自分で書くのが面倒なら、やらせた方が早いです。

   claude -p "いまやった作業を、次から1コマンドで再現できるスキルにして。
   name と description を付けて、手順と禁止事項を分けて書いて。
   description には、僕が使いそうな呼び方を3通り入れて。"
   

   「呼び方を3通り」を指定するのが要点です。 ここが弱いと、作ったのに読まれません。

4. 次に同じ作業が来たら、呼ぶだけにする

   ここで判定します。説明を足さずに済んだら成功です。

   足したくなったら、その内容をスキルへ書き戻します。スキルは1回で完成しません。 使うたびに育てます。

5. 保存する

   git add .
   git commit -m "ゲーム画面の撮影手順をスキルにした"
   git push
   

つまずきどころ

作ったのに使われない

description が弱いです。依頼で実際に使う言葉が入っているかを見てください。「撮影」しか書いていないのに「スクショ」と頼んでいる、というズレがよく起きます。

スキルが長くなりすぎた

判断の分岐で子へ分けてください。目安として、1本で1画面に収まらなくなったら分ける時期です。

内容が古くなって、間違った手順で進んだ

これが一番危ないです。スキルは強く効くので、古い手順もそのまま実行されます。

対策は「時点を書く」ことです。

- 2026年7月時点の手順。道具が変わったら書き直す

4-1で道具の推奨に時点を付けたのと同じ考え方です。

ルールに何でも書きたくなる

ルールは常に読まれるので、増やすと全部が薄くなります。「呼ぶときだけ必要か」を毎回聞いてください。 答えがイエスならスキルです。

同じスキルが2つできた

原本の場所を決めていないからです。編集する前に「原本はどこか」を確認する習慣にしてください。僕はこれを守れず1回やり直しました。

Windows の場合

ファイルを置く場所が違うだけで、中身は同じです。パスの区切りが \ になる点だけ注意してください。

次の一歩

今日やった作業を1つ、スキルにしてください。

完璧でなくていいです。5行でも構いません。 次に同じ作業が来たとき、それを呼んで、足りない部分を書き足す。この繰り返しで育ちます。

作業を渡せるようになりました。次はテストを書かせて、壊れたら気づける形にします！