「せっかく作ったコマンド、ほとんど使っていないな」と、自分の設定フォルダを眺めていて思うことがあります。
Claude CodeのようなAIエージェントに仕事の手順を覚えさせる「スキル」という仕組みが、2026年に入って爆発的に流行っています。2026年9月1日のGitHubトレンドでは、上位リポジトリの半分ほどがこの種のツールでした（archifyは当時4万を超えるスターを獲得）。熱狂はまだ続いています。GitHub APIで確認し直すと、archifyは2026年9月25日時点で71,502★まで伸びていました。
配る側がこれだけ盛り上がるということは、裏を返せば「入れたのに回っていない人」も相当数いるのだろうと想像します。私自身がそうでした。
TL;DR: 私の設定フォルダは1年間で19スキル・85コマンドまで育ち、その間に7本のスキルと65個のコマンドを処分しました。1年回して効いたのは、作ることではなく、減らすことと、失敗を人間ではなく機械に塞ぐことでした。
※本記事の数値は、筆者のObsidian Vault（macOS・総1,411コミット）のgit履歴と実ファイル数を2026年9月1日に数え直した実測です。
118件を11スキルに減らしたら、当日中に挫折した
私の設定フォルダのgit履歴を遡ると、大きな転換点が2026年2月3日にあります。
その日私は、それまで118個あったコマンドファイルを、11個の「スキル」に全面的に統合しました。スキルというのは、AIに仕事の手順を書いた説明書のようなファイルで、「何を」「いつ」やるかを書いておくと、AIが自分でそれを取りに行ってくれる仕組みです。
ところがgitの記録をよく見ると、同じ日のうちに「必須コマンド6件のみ復元」というコミットが続いています。当日中に挫折して、一部を元に戻していたのです。
壊れたのは、日次のメモ整理や毎朝のノート作成のような、地味な定例作業でした。地味なものほど脆いのです。「今日の日付でノートを作る」程度の雑用は、手順書を取りに行くほうが面倒になる。しかもスキルは名前と説明をAIに常に記憶させておく仕組みなので、雑用まで同じ棚に置くと、探す手間のほうが大きくなります。
結果として、スキルは「どの手順書があるか」を示す目次、コマンドは実際の実装、という二層構造に落ち着きました。二層で足りました。読んでいて気になったのは、後から設計思想としてきれいに語れるものほど、実際には挫折の副産物であることが多い、ということです。
作りすぎた月、絞った月 — 1年の波形に「足す基準」が出ていた
1年分の追加履歴を月ごとに数え直すと、こんな波形になりました。
| 月 | スキル追加 | コマンド追加 |
|---|---|---|
| 2026-01 | 7 | 56 |
| 2026-02 | 14 | 59（大半はリセット後の再建） |
| 2026-03 | 2 | 16 |
| 2026-04〜05 | 3 | 3 |
| 2026-06 | 6 | 6 |
| 2026-08 | 11 | 7 |
ざっくりいうと、1〜2月に一気に作り、4〜5月に何も足さず、6月以降は必要なものだけが細く増えていく形です。
4〜5月に何も足さなかったのは、忙しかったからではありません。作りたい気持ちの矛先が、作ることから回すことへ移っていたのだと思います。作るより先に、直す。実際この2ヶ月、私は新しいコマンドを書く代わりに、既存のパイプラインがなぜ止まるかの調査に時間を使っていました。
短命だったものもあります。ブックマークを毎日まとめるスキルは、追加から2週間強で削除しました。「dashboard」や「misc（その他）」のような名前が曖昧なものも、3月に4本まとめて処分しました。名前は看板です。
生き残ったものには「特定の曜日・時間に必ず発生する仕事」という共通点がありました。毎朝のニュース収集、週1回の数値確認、日次の整理。逆に「いつか使うかもしれない」で作ったものは、すべて死にました。足す基準は頭の中で決めるより、削除記録を数えたほうが正直に出るのだなと感じました。
失敗は人間が塞ぐと抜ける。だから機械に塞いだ
2026年8月、週1回起動の無人パイプラインを止めて見直しました。このパイプラインは3週連続で失敗していたのに、誰にも通知されず、3週間気づきませんでした。原因は条件設定の小さなずれだったのですが、本当に問題だったのは原因ではなく、失敗しても何も起きない構造のほうでした。沈黙が一番怖いのです。
同じ頃、無人でAIニュースの収集を頼んだところ、たった2分で「成功」の報告が返ってきました。出来上がりを見ると、どの項目ももっともらしい見出しが付いているのに、リンク先がすべてサイトのトップページ。収集に失敗してもエラーで止まらず、それらしい見出しを作り直していたのです。所要時間が短すぎる成功は失敗のサインだと、このとき初めて知りました。
そこで運用を変えました。失敗しそうな箇所には、人間の確認ではなくコードの検証を置きます。ニュース収集には「記事のURLが含まれているか」を数えるバリデータを。WordPressへの投稿には「アイキャッチ画像が設定されているか」を確かめるゲートを。実はこのゲート自体、画像なしで1本公開した事故の後に足したもので、8月30日に再発しかけたのを止めてくれました。ゲートが仕事をしました。
人間の注意は必ず抜けます。だからルールは指示書に書くだけでなく、実行前に機械的に止まる場所に置くのが正解なのだろうと感じました。
自己改善ループは、証拠が足りないとき黙るべきだった
もう一つ、素直に失敗として書いておきたいことがあります。
X（旧Twitter）の投稿運用で、「どの投稿が反応されたか」をAIに学習させ、次の投稿に反映する仕組みを回していました。ところがこのループ、累計クリック2件という薄い証拠で「効く型」を判定し始めました。ランキングには常に1位がいるので、証拠が足りなくてもAIは何かを指示してしまうのです。
その結果、投稿が自分の作業報告に収束していき、表示回数の中央値は548から36まで落ちました。
2件の反応で「これが効く」と断定するのは、ちょうど私自身がこのブログで数値を追いすぎ、読む側を疲れさせていたのと同じ構造の失敗でした。今は「証拠が下限を超えないときは沈黙する」という決まりをループに組み込み、数値より先に「読んでいて気になったのは」を書ける状態を取り戻しています。
まとめ
最後に、自分の設定フォルダの指示書に「コマンド約60本・スキル14本」と書いてあるのを見つけました。実際に数え直すと85コマンド・19スキルでした。運用しているはずの数を、運用している本人が把握していなかったのです。これが「1年回した」ことの実態に一番近いのだと思います。
1年間を通じて効いたのは、結局この3つでした。
- 作ることより減らすこと — 二層構造と、7本のスキル処分で足す基準が決まった
- 心配より機械的なゲート — バリデータとアイキャッチ検査で、人の注意が抜けても止まる
- 数値より読者の気になり — 証拠が足りないときは黙る。エビデンスは足りてから語る
スキルを配る側のツールは今後もっと増えるでしょう。でも、配る側の便利さの半分は回し方の設計で決まります。今日できるのは、自分の棚の使っていないものを1本処分することくらいです。1年後に数え直したくなったら、また一緒に減らしましょう。
コメント