Agent Skillは「作る」より「管理」が9割：710個のスキルを監査して見えたAI社員育成の真実
先日、X（旧Twitter）でこんな投稿をしました。
Agent Skillって管理できてますか？
すると、予想以上に多くの反響をいただきました。その中でも、特に心に残ったのがこんな声です。
「Skillが41個まで増えたので、一覧を1つのファイルにまとめました。でも、どのSkillが実際に使われたのか分かりません。呼び出し記録も取っていますか？」
これは、まさにAI社員を運用する上で避けて通れない、非常に本質的な質問です。
結論から言うと、僕の環境では呼び出し記録も詳細に取っています。ただし、記録しているのは単に「何回使われたか」だけではありません。
今回の記事では、僕のMacに入っているAgent Skillの全てを徹底的に調べて分かったことを、できるだけ分かりやすく、そして皆さんのAI社員運用に役立つ形でまとめました。日々のAI業務改善に悩む方、そしてこれからAI社員との共創を本格化させたい方にとって、きっと新たな視点となるでしょう。
そもそもAgent Skillとは？：AIの「業務マニュアル」が増えすぎると…
Agent Skillとは、AIに特定の仕事を任せるための、いわば「業務マニュアル」のようなものです。
例えば、僕のAI社員であれば、
Larkの文書を正確に読み込む
会議の内容を迅速に要約する
GitHubのIssue状況を自動で確認する
記事の下書きを効率的に作成する
実行前に外部サービスの認証状態を確実にチェックする
といった具体的な仕事ごとにSkillを用意しています。
最初は数個から始まり、Skillが増えるたびにAIに任せられる仕事の幅が広がり、生産性は飛躍的に向上していきます。しかし、この「増える」という喜びの裏には、やがて新たな、そしてより根深い問題が潜んでいることに気づきます。
それは、数十個を超えたあたりから顕在化する「管理」の課題です。
「同じ名前のSkillが複数あって、どれが最新か分からない」
「あるSkillを修正したいのに、どれを触ればいいのか判断できない」
「このSkill、そもそも今もちゃんと動いているのか？」
「一度も使われていないSkillが、いつの間にか大量に眠っている」
このように、Skillを「作る」段階の問題から、いかに「管理し続けるか」という運用フェーズの問題へと、課題の質が大きく変わっていくのです。
実際に全部調べてみた：710個のSkillを監査して見えたAIの「現場」
この問題意識のもと、僕は今回、僕のMacに配置されているAgent Skillをすべて洗い出し、徹底的に監査しました。これはまさに、AI社員の「健康診断」とも言える作業です。
その結果、明らかになったのは驚くべき数字でした。
Skillの配置総数: 710個
Skill名の種類: 439種類
Codexが実際に使うSkill: 97個
実行履歴の総数: 15,898件
この数字を見て、「439種類ものSkillがあるなら、すべてが活発に動いているのか？」と思うかもしれません。しかし、現実はそう単純ではありません。むしろ、この「配置数」と「実動数」を混同して考えると、途端に管理は破綻します。
実際の運用現場では、もっと複雑な状況が広がっているのです。
Agent Skill、管理の「3つの軸」を徹底解剖
膨大な数のSkillを効果的に管理するためには、明確な基準と軸が必要です。僕がたどり着いたのは、Agent Skillを次の3つの視点で分けて管理するという方法でした。この3軸を理解することが、AI社員の安定運用への第一歩です。
1．どれが「正本」なのか？：混乱を招くコピー問題
AIツールを使っていると、いつの間にか同じような名前のファイルが増えてしまいがちです。Agent Skillも例外ではありません。
たとえ同じ名前のSkillが複数存在していても、それぞれが持つ役割は全く異なります。
編集する「元ファイル」（正本）：僕らが直接修正を加えるべき、唯一のマスターファイル。
AIが実際に使う「実行コピー」：正本をもとにAIが利用する、現場で動くバージョン。
Pluginが管理する「専用コピー」：特定の外部ツールやプラグインが独自に持つSkillデータ。
過去環境の「保管コピー」（レガシー）：以前のバージョンやテスト用に残された、現状では使われていないデータ。
これらを区別せず、「同じ名前だから」という理由で一括削除したり、上書きしたりするとどうなるでしょうか？当然、正常に動作していたはずのSkillまで壊してしまい、AI社員の業務が停止する最悪のシナリオに繋がりかねません。
💡ここが重要💡 常に「このSkillの正本はどれなのか？」を意識し、それを基準に管理することで、無用なトラブルを防ぎ、効率的な修正サイクルを確立できます。
🔥おすすめ書籍🔥：組織の業務を仕組み化し、属人化を防ぐためには「正しい業務マニュアル」の運用が不可欠です。AI社員のスキル管理にも通じる、仕組み作りのヒントが満載の一冊！ 「仕組み」で勝つ! 中小企業のための業務効率化マニュアル
2．「今、動いているか」をどう判断するか？：停止 ≠ 故障
次に大切なのは、一つ一つのSkillが現在どのような状態にあるのかを正確に把握することです。
大きく分けて、以下の4種類の状態があります。
現在動いている：問題なく機能している、健全な状態。
Skill自体が壊れている：Skillのコードやロジックに不具合があり、修正が必要な状態。
認証や権限がなくて止まった：Skill自体は問題ないが、外部サービスとの連携に必要な認証情報が切れていたり、アクセス権限がないために停止している状態。
まだ十分に試していない：作成したばかりで、まだ実戦投入や検証が不足している状態。
ここで特に強調したいのは、「動かなかった＝Skillが壊れている」と安易に決めつけないことです。
例えば、あるSkillが外部サービスのAPIと連携する際にエラーで停止したとします。この時、Skillのコードに問題があると思い込みがちですが、実際には「外部サービスの認証情報が期限切れだった」「必要な権限が付与されていなかった」といった外部要因が原因であるケースも少なくありません。
認証を更新したり、権限を付与し直したりするだけで、Skillは再び何事もなかったかのように動き出す可能性があります。まずは原因を特定するための「切り分け」が非常に重要です。
3．「実際に使われたか」の記録をどう取るか？：データが語る真実
最後に、そして最も重要なのが、Agent Skillの「呼び出し記録」です。これは、AI社員の「日報」であり、「活動履歴」に他なりません。
僕の環境では、Skillを実行するたびに、次の項目を自動で記録しています。
どのSkillを使ったか：実行されたSkillの正確な名前
いつ使ったか：実行日時
成功したか：実行結果が正常だったか否か
失敗したか：コードエラーなど、Skill自身の問題で失敗したか
外部要因で止まったか：認証切れ、ネットワーク障害など、Skill外部の問題で停止したか
今回の監査で確認した15,898件もの実行履歴のうち、驚くことに15,830件が正常な記録でした。一方で、68件は不正な記録（例えば、ログが途中で途切れたり、不整合を起こしたりしたもの）として検出されました。
重要なのは、この不正な記録も決して削除しないことです。僕のシステムでは、これらを別の場所へ隔離し、通常の分析からは除外しています。なぜなら、「なぜ記録が壊れたのか」という問いは、システム全体の信頼性や堅牢性を高めるための貴重な手がかりとなるからです。
💡ここが重要💡 記録は、単なる数値ではありません。それはAI社員の「実態」を映し出す鏡であり、改善のための「羅針盤」です。
📊データ分析を学ぶなら📊：集めた大量のデータから、意味のある洞察を引き出すスキルは、AI社員の運用においても必須です。初心者でも分かりやすく、データ活用の基本を学べる良書！ データ分析の力 (ファスト&スロー、意思決定の偏見、因果推論、仮説検定)
使われていないSkillは「即削除」すべきか？：焦らない判断の重要性
監査の結果、まだ利用が確認できていないSkillが多数存在することが分かりました。これは、一見すると「不要なもの」としてすぐに削除してしまいたくなる衝動に駆られるかもしれません。しかし、僕はその判断を絶対に急がないようにしています。
なぜなら、「使われていない」という事実の裏には、様々な可能性があるからです。
まだ使う機会が来ていない：特定の季節業務や、イレギュラーな状況でのみ利用するSkillかもしれません。
記録を始める前に使われた：ロギングシステムを導入する前に一時的に使われ、現在は役割を終えたが、将来的に再利用の可能性があるかもしれません。
特定の仕事でしか使わないニッチなSkill：使用頻度は低いものの、その仕事においては代替不可能な重要なSkillかもしれません。
外部サービスの認証が必要で、一時的に停止しているだけ：認証切れなどで一時的に利用停止しており、問題が解決すれば再び利用可能な状態になるSkillかもしれません。
そのため僕は、現時点での証拠が少ないSkillを安易に「失敗作」と見なすのではなく、「要検証」というステータスで扱っています。実際にそのSkillを使ってみて、その結果を記録に残し、データに基づいてから最終的な判断を下す。このプロセスが、AI社員の資産を無駄にせず、最大限に活かすための鍵となります。
毎日やることは「5つのシンプル」：AI社員を育てるルーティン
Agent Skillの管理は、一見すると複雑で手間がかかるように思えるかもしれません。しかし、僕が毎日実践していることは、驚くほどシンプルです。これを習慣化することで、AI社員の運用は格段に安定します。
以下の5つを、ぜひ日々のルーティンに加えてみてください。
修正する「元ファイル」（正本）を必ず確認する：どのSkillを触るか、その前に「これは正本か？」と自問自答する癖をつけましょう。
実行前に認証状態をチェックする：特に外部サービスと連携するSkillの場合、認証切れはよくあるトラブルです。事前に確認することで無駄な時間を省けます。
Skillを実行する：実際に動かしてみて、意図通りの動作をするか確認します。
結果を1回ずつ記録する：成功、失敗、外部要因停止など、実行のたびに詳細なログを残します。これがAI社員の成長記録になります。
元ファイルを更新してから実行コピーへ反映する：正本を修正したら、忘れずにAIが実際に使う実行環境へ同期させましょう。この一手間が、バージョン管理の混乱を防ぎます。
これだけです。
大切なのは、いたずらにSkillの数を増やすことではありません。
「今、どのSkillを直せば良いのか」 「そのSkillは、現在も問題なく動いているのか」 「実際にAI社員によって使われているのか」
この3つの問いに、自信を持って説明できる状態を常に保っておくこと。これこそが、AI社員を「作っただけ」で終わらせず、「働き続ける」存在へと育て上げる秘訣なのです。
🚀運用・保守のベストプラクティス🚀：システムを安定稼働させるための知識は、AI社員の運用にも応用できます。世界中で実践されるSRE（サイトリライアビリティエンジニアリング）の思想を学んで、あなたのAI社員を「落ちない」存在に！ SRE サイトリライアビリティエンジニアリング ―Googleの生産性を支えるインフラの実践論
AI社員も、作っただけでは働き続けない：継続的な「育成」の視点
人間である社員にも、明確な業務マニュアル、定期的な研修、日々の業務報告（日報）、そしてそれに基づく改善活動が不可欠です。
AI社員も、全く同じだということを今回の監査を通じて痛感しました。
単にプロンプトやSkillを作成しただけでは、彼らは安定して働き続けることはできません。まるで生まれたばかりの子どものように、使い方を教え、使った結果を注意深く観察し、時には止まってしまった理由を徹底的に調べ、そして必要なところだけを丁寧に修正していく。
Agent Skillの管理とは、表面的な「ツール管理」に留まるものではありません。それは、AI社員という新たなパートナーを、長期にわたって継続的に育成し、組織に貢献し続ける存在へと育て上げていくための、運用そのものだと僕は思っています。
今回の記事で紹介した内容は、僕のAI社員との共創の「リアル」の一部です。もし、皆さんの「AI社員」育成への関心が高ければ、次回は実際に僕が使っている「Skill管理表」の具体的なフォーマットや、「呼び出しログに記録する項目」の詳細を、さらに深掘りして公開する予定です。ぜひ、コメントやXでご意見をお聞かせください。
ハヤシシュンスケ／合同会社みやび
X：@The_AGI_WAY
