人が作ったスキルで「ここ直して」と頼んだら、その直しはどこに残すか ―「今回だけの対応」を使う側から考えてみた

こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。

---

先日、「Agent Skillsで「今回だけの対応」を残しすぎないようにしたい」という記事を書きました。エージェントに頼んだ一度きりの対応が、スキル本体に書き戻されて、次からの手順になってしまう。その問題について書いたものです。

tech.algomatic.jp

そうしたら、社内の方から質問をもらいました。その方は、ほかの人が作ったスキルを仕事で使っていて、自分でもスキルを作り始めているそうです。

記事は読んだけれど、使う側として自分の作業にどう当てはめればいいか分からなかった。

言われてみると、たしかにそうでした。前回の記事は、ファイルの分け方とか書き込み権限とか、作る側の話ばかりでした。使う側の人がその場で何をすればいいかは、ほとんど書いていません。

なので今回は、もらった質問に、使う側の立場で答えてみます。エンジニアかどうかは関係なく、人が作ったスキルを毎日の仕事で使っている人に向けて書いています。

もらった質問

ざっくりまとめると、こんな状況でした。

• ほかの人が作ったレビュー用のスキルを、毎日使っている。
• 使っていると、スキルに反映してほしい直しと、その回だけにしてほしい直しが出てくる。
• でも、頼んだ直しは全部スキルに追記されて、毎回「PRを作りますか？」と聞かれる。
• 反映していいのか、反映しないとほかの人が困るのか、毎回オーナーに聞くのも悪い気がする。そうやって迷っているうちに、確定しない変更がたまっていく。

そのうえで、3つ聞かれました。

1. 人が作ったスキルに直しを頼むとき、その直しをどう扱えばいいか
2. どんな仕事がスキルに向いているか（QAのテスト中の手伝いもスキルにしたほうがいいか）
3. エンジニアじゃない人がスキルを作るとき、最低限なにを押さえればいいか

順番に、自分の考えを書いていきます。

その前に、どこが書き換わっているのか

直しの扱い方の前に、「スキルに追記される」ときに何が起きているのかを見ておきます。ここがぼんやりしていると、反映するかどうかも決めにくいと思うので。

スキルの中心は SKILL.md というテキストファイルです。エージェントは作業のたびにこれを読んで、書いてある手順どおりに動きます。「スキルに追記する」というのは、このファイルに文章を足すことです。

ここで、手元のファイルと共有版を分けて考えたいです。

• 手元のファイル: 自分のパソコンや作業環境にあるスキルのファイル。エージェントが追記すると、まずここが書き換わります。
• 共有版: チームで使っている元のスキル。PRは、手元の変更を共有版に入れてもらうためのお願いです。

なので、PRを出していなくても、手元のファイルはもう書き換わっていることがあります。次もエージェントが手元のファイルを読む作りなら、PRを出す前から次の動きが変わってしまいます。

どのファイルが読まれるかは、スキルの配り方や更新のしかたで変わります。たまっている変更があるなら、まずこの2つを見るといいと思います。

• 手元のスキルのファイルは、もう書き換わっているか
• 次の作業で、エージェントはどっちの版を読むか

コマンドで見るのに慣れていなければ、エージェントに「このスキルのファイルで、まだ共有版に入っていない変更を一覧にして」と頼むのでも大丈夫です。

質問1: 頼んだ直しは3つに分けてみる

直しを頼むときに考えることは、「スキルに入れるか、入れないか」の二択じゃなくてもいいと思っています。前回の記事では、手順・設定・一時対応・記録・改善提案を別々に置く、という作りを書きました。これを使う側から見ると、3つに分けるくらいがちょうどいい気がしています。

分け方	例	使う側がすること
今回だけ	「今日はこの資料だけ対象にして」	今回の成果物にだけ反映する。スキルには入れない
自分・案件用	「この案件では毎回この形式で報告したい」	個人用・案件用の設定にできるか確認する。全員共通にはしない
改善メモ	ほかの人にも役立ちそう／判断がつかない	メモに残して、反映するかはオーナーと決める

迷ったら、改善メモに入れておけばいいです。使っている人が、その場で「みんなの手順にしていいか」まで決めなくて大丈夫です。

「反映しないと、ほかの人が同じところで困るかも」という心配もあると思います。これは、困ったことを伝えるのと、みんなの手順を変えるのを、別のことだと考えると少し楽になります。伝えるのはメモで足ります。みんなの手順を変えるかどうかは、ほかの場面でも困らないかを見てから決めれば間に合います。前回の記事で「共通の手順に入れる前に、別のケースで確かめる」と書いたのは、このあたりの話です。

頼んだ直しをそのまま追記し続けるとどうなるかは、近いことが研究でも報告されています。公開されている SKILL.md 約13.8万件を調べた Zhangらの研究（2026、プレプリント）では、共有されているスキルの多くが、一つのタスクやリポジトリ、会話から生まれたように見える、と書かれていました。調べたうちの91.8%に、なにかしらの欠陥が見つかったそうです。

arxiv.org

エージェントが自分でスキルを増やしていく仕組みでも、成果を見ずに積み上げ続けると、必要なスキルが見つけにくくなって、性能も伸びなくなる、という報告があります（Library Drift、2026、プレプリント）。

arxiv.org

どちらも、人が使っているスキルに直しを追記していく場面を、そのまま調べたものではありません。それでも、その場の事情が共通の手順に混ざっていく感じを考えるには、参考になると思いました。

改善メモは4つだけ

改善メモには、この4つがあれば十分だと思っています。

• 何をしていたか
• 何に困ったか
• どう直したか
• 今回だけの事情があったか

オーナーの負担が気になるなら、メモをためておいて、まとめて見てもらう形にもできます。直しを頼むたびに聞くより、オーナーも判断しやすいはずです。ただ、間違った結果がそのまま広がりそうなときなど、影響が大きいものはすぐ伝えてください。

確認の回数が増えすぎるのも、ちょっと気をつけたいところです。AIエージェントが出したPRを何度もレビューしている人を追った研究では、レビューを重ねるほど承認率が上がって、コードへのコメントは減っていました（Yuら、2026、プレプリント）。著者らは、作業が増える中で慣れていったのでは、と見ています。これはOSSのコードレビューの話で、「まとめて見るほうがいい」と示したものではありません。ただ、細かい確認を毎回お願いし続けると、確認がだんだん形だけになるかもしれない、とは思います。

arxiv.org

エージェントへの頼み方

直しを頼むときに、どこに反映してほしいかも一緒に書いておきます。たとえば、こんな感じです。

この直しは今回の成果物にだけ反映してください。
スキル本体は変更しないでください。
今後にも役立ちそうなら、困った状況・対応内容・適用条件を改善メモとして別にまとめてください。

ただ、これで書き換えを必ず止められるわけではないです。前回の記事でも書いたとおり、「書き換えないで」と頼むのは気持ちを伝えるだけで、書き換える力そのものを取り上げるわけではありません。エージェントに渡す文章の中で指示の出どころを区別しても、それだけでは強制できる境目にならず、外側で制限する仕組みが要る、という研究もあります（Leong、2026、プレプリント）。

arxiv.org

記録をスキルに取り込むときにも、注意が要ります。実行記録からスキルを自動で更新する仕組みを調べた研究では、同じような記録が何度か出てくると、それがスキルの指示として取り込まれやすいことが示されていました（Chenら、2026、プレプリント）。これは攻撃者がいる前提の実験なので、社内で頼む直しとは話が違います。それでも、「何回か出てきたから共通の手順に入れよう」と決めるのは、少し慎重になったほうがいいと思っています。

arxiv.org

直しを頼むたびにスキルへ追記して、PRを作るか聞いてくる動きは、スキルの作りで変えられるところです。たとえば、改善案は別のフォルダに書き出して、スキル本体には書かないようにもできます。使う側が毎回がんばって防ぐより、作る側で仕組みを直すほうが確実です。使っていて同じところでずっと迷うなら、そのこと自体を改善メモにしてオーナーに渡してもらえるといいと思います。

質問2: 向いているのは「毎回同じ説明をしている作業」

スキルにするかどうかは、自分は次の3つを目安にしています。

• 同じ説明を何度もエージェントにしている
• 進め方に、毎回だいたい同じところがある
• 結果がいいか悪いかを、自分で確かめられる

質問では、テスト仕様書の作成はもうスキルにしていて、テスト中の手伝い（手順の確認、結果の記録、不具合報告の下書きなど）は、その都度エージェントに聞きながら進めている、とのことでした。

こういう手伝いも、スキルにできると思います。ただ、いきなりテスト中の作業を全部まとめるのは、あまりおすすめしません。何度も説明している工程を一つ選んで、そこから試すほうが進めやすいです。

スキルの効果を測った研究にも、これに近い結果がありました。SkillsBench（Liら、2026、プレプリント）では、87のタスクで、人が整えたスキルを使うと、平均の通過率が33.9%から50.5%に上がっています。範囲を絞った小さなスキルのほうが、大きくて何でも入りのスキルより成績がよかった、とも書かれていました。

arxiv.org

一方で、ソフトウェア開発の課題で98件のスキルを調べた SWE-Skills-Bench（Hanら、2026、プレプリント）では、92件で統計的に意味のある効果が見られませんでした。効果があったのは、エージェントが自分では飛ばしてしまう手順を補うスキルだったそうです。

arxiv.org

毎回同じ説明をしているのは、エージェントがその手順を自分では補えていないからなんだろう、と自分は考えています。どちらの研究もQAの手伝いを直接測ったわけではありません。それでも、範囲を絞って、エージェントに足りない手順を補うスキルから作る、という進め方の参考にはなると思います。

始めやすいのは、不具合報告の下書きだと思います。

• 渡すもの: 自分が実際に見たこと（操作、画面、メッセージ）
• 返してほしいもの: 再現手順、期待結果、実際の結果、環境、証跡
• 情報が足りないとき: 推測で埋めずに、「未確認」として聞いてもらう

QAで使うなら、決めておきたいことが2つあります。やっていないテストを「実施済み」と書かせないこと。それと、合否を誰が決めるか。下書きはエージェントに任せても、合否まで任せるかは別に決めたほうがいいと思います。

質問3: 作るときは、先に「合格の見本」を用意する

エンジニアかどうかで、最初にやることはあまり変わらないと思っています。手順を書き始める前に、よくできた出力の見本を一つ用意します。見本があると、何を目指して手順を書けばいいかがはっきりします。できたスキルを試すときも、見本と比べれば判断できます。

そのうえで、次の5つが言葉にできれば、作り始められます。

• いつ使うか、何を渡すか
• 何を、どんな形で返してほしいか
• 情報が足りないとき、何を聞いてほしいか
• してほしくないこと（推測で埋める、勝手に投稿する、など）
• よくできた出力の例

見本は、目指したい品質を伝えるためのものです。形まで細かく固めすぎないほうがいいです。SWE-Skills-Benchでは、成績を下げたスキルが、エージェントをスキルの中のテンプレートに引きずって、タスクで明示した指示を上書きさせていました。見本の形と、その回の頼みごとが食い違ったら、頼みごとのほうを優先する、と書いておくといいと思います。

作るときも直すときも、skill-creatorを使う

スキルを作るときと直すときは、Anthropicが公開している skill-creator を使うのがおすすめです。 新しく作るだけでなく、今あるスキルを直したり、評価したりすることも目的に入っています。

github.com

中身を読むと、この記事で書いてきたこととかなり重なっていました。

• 最初に聞いてくれる: 何ができるようにしたいか、どんなときに使うか、どんな形で出力してほしいかを聞きます。境目になるケースや入出力の形、サンプルファイル、何ができたら成功かも確認します。上の5つを先に考えておくと、ここで答えやすいです。
• テストを作って比べる: 現実的なテスト用の依頼を2〜3個作って、スキルありとスキルなしで同時に動かし、結果を比べます。既存のスキルを直すときは、直す前の版を残しておいて、それと比べます。
• 特定のケースに合わせすぎない: 直すときは、目の前の例だけに合わせすぎないようにして、なぜそうするのかを書く方針になっています。「必ず〜する」「絶対に〜しない」を多用するのは、注意が要るサインとして扱っています。

最後の点は、「今回だけの対応」を共通の手順に混ぜない、という今回の話そのものだと思いました。

ただ、使う場所によってできることが違います。Claude Code などでは、スキルあり・なしの比較や、スキルが呼ばれるべきときにちゃんと呼ばれるかの調整までやってくれます。一方、Claude.aiでは、スキルなしとの比較や、呼ばれ方の調整は省かれます。Claude.aiで作るときは、スキルなしでも同じ例を試すところを、自分でやっておくのがいいと思います。

それと、skill-creatorを使ったからといって、できたスキルがちゃんと動くとは限りません。前回の記事でも書いたとおり、名前だけで中身の安全さは判断できないので、どの版を使ったか、何を確かめたかは自分でも見ておきます。さっきの Zhangらの研究 でも、AIが作ったと書かれたスキルのほうが、安全面やほかの環境への持っていきやすさで問題が多かった、と報告されていました。

もう一つ、直すときは、ふだんの作業とは分けた「スキルを直す作業」としてskill-creatorを使うのがいいと思います。毎日の作業の途中でスキル本体を書き換えるのではなく、改善メモがある程度たまったら、skill-creatorでまとめて直して、直す前の版と比べてから反映する。質問1の改善メモは、このときの材料になります。

作ったら、3種類の例で試します。

• ふつうの例
• 情報が足りない例
• ちょっと変わった例

見るのは、「見本どおりにできたか」と「分からないことを聞けたか」の2つです。うまくいかなかったところを一つずつ直して、また同じ例で試します。

できれば、同じ例をスキルなしでも試して、比べてみてください。さっきの SkillsBench や SWE-Skills-Bench も、スキルあり・なしを比べて効果を測っています。企業のスキルを評価した ACES（Kevinら、2026、プレプリント）でも、文書をチェックするだけでは分からないことがあって、実際に動かして比べる必要がある、とされていました。スキルなしでも同じ結果になるなら、そのスキルはまだ効いていない、ということです。

arxiv.org

「情報が足りない例」を入れておくのにも、理由があります。ユーザーの好みが途中で変わる場面を調べた AcCoRD（Srinivasanら、2026、プレプリント）では、プロンプトで促すだけでは、モデルに「分かっていない」と気づかせられませんでした。スキルに「分からないことは聞いて」と書いても、ほんとうに聞いてくれるかは、試してみないと分かりません。

arxiv.org

ここで、質問1の話とつながってきます。自分で作ったスキルでも、直しを頼むたびに手順を書き足していくと、今回だけの事情が共通の手順に混ざっていきます。直すときは、どの例で失敗したのかを見て、ほかの例を壊さずに直せるかを試してから反映します。

エージェントが自分の手順を直す仕組みを調べた研究でも、近いことが報告されています。Self-Healing Harness（Tayebatiら、2026、プレプリント）では、却下された修正案383件のうち211件（55%）が、元の失敗は直せたのに、前はうまくいっていたケースを悪くしていました。一つの失敗に合わせた直しが、別のところを壊すことは、けっこうあるみたいです。

arxiv.org

まとめ

人が作ったスキルに直しを頼んだら、まずそれが「今回だけ」「自分・案件用」「改善メモ」のどれかを考えます。迷ったら改善メモに入れて、反映するかはオーナーと決めます。PRを出していなくても手元のファイルが書き換わっていることがあるので、たまっている変更は一度見ておきます。

スキルにする仕事は、毎回同じ説明をしている作業から一つ選びます。作るときは合格の見本を先に用意して、3種類の例で試します。できれば、スキルなしとも比べます。作るときも直すときも、skill-creatorを使うと進めやすいです。

ちなみに、人が作ったスキルを別の人が使うときの直しの分け方を、そのまま調べた研究は見つけられませんでした。3つの分け方は、前回の記事の考え方を使う側に当てはめてみた、自分の案です。

前回の記事は、作る側が「今回だけの対応」を共通の手順に混ぜないための話でした。今回は、使う側がその区別を毎日の作業でどう扱うかを書いてみました。使う側がこの区別を持っていると、作る側に渡す改善メモも具体的になると思います。

まずは手元のスキルに何が書き足されているかを見て、今回だけの対応が混ざっていないか、確かめるところからやってみてください。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI時代の企業OSを作る」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

recruiting.algomatic.jp

Sources

以下の記事・資料・論文は2026年11月5日に参照しています。論文はいずれもarXivで公開されているプレプリントです。記事に出てくる順に並べています。

• Algomatic Tech Blog「Agent Skillsで「今回だけの対応」を残しすぎないようにしたい」（2026）：https://tech.algomatic.jp/entry/2026/11/04/184845
• Zhangら「What Keeps Agent Skills from Being Reusable? Evidence from 138K SKILL.md Files」（2026、プレプリント）：https://arxiv.org/abs/2608.08453
• Zhangら「Library Drift: Diagnosing and Fixing a Silent Failure Mode in Self-Evolving LLM Skill Libraries」（2026、プレプリント）：https://arxiv.org/abs/2605.19576
• Yuら「Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code」（2026、プレプリント）：https://arxiv.org/abs/2606.22721
• Leong「Instruction Self-Arbitration Is Not a Trust Boundary: Configuration-Dependent Tool Calls and External Enforcement in LLM Agents」（2026、プレプリント）：https://arxiv.org/abs/2608.28502
• Chenら「When Experience Becomes Instruction: Trajectory Poisoning in Self-Evolving Agent Skill Systems」（2026、プレプリント）：https://arxiv.org/abs/2608.05563
• Liら「SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks」（2026、プレプリント）：https://arxiv.org/abs/2602.12670
• Hanら「SWE-Skills-Bench: Do Agent Skills Actually Help in Real-World Software Engineering?」（2026、プレプリント）：https://arxiv.org/abs/2603.15401
• Anthropic「skill-creator」：https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md
• Kevinら「Evaluating Skills, Not Just Agents: Agentic Continuous Evaluation of Skills」（2026、プレプリント）：https://arxiv.org/abs/2608.20614
• Srinivasanら「AcCoRD: Evaluating User-Agent Collaboration Under Realistic User Preference Dynamics」（2026、プレプリント）：https://arxiv.org/abs/2608.27818
• Tayebatiら「Self-Healing Harness for Runtime Oversight of Agent Self-Modification」（2026、プレプリント）：https://arxiv.org/abs/2609.24130