Claude Skills260個運用、オプトと個人で分かれた明暗

「Skillsを増やせば増やすほど、Claudeは賢くなる」。そう信じて自分のSkillsフォルダにファイルを増やし続けている人を、僕は何人も見てきました。ところが実際には、増やした分だけ便利になる人と、途中から逆に手間が増える人に分かれています。

この分かれ目を象徴する2つの報告が、この夏そろって出てきました。1つは広告代理店オプトが2026年8月7日の日経クロストレンド報道で明らかにした、Claude Skills260個の量産事例です。もう1つは、個人エンジニアがQiitaで公開した、Skills50個を運用した時点で生産性がほぼ半減したという記録です。同じ「Skillsを増やす」という行為なのに、結果は正反対でした。

僕自身もClaude Codeで小さなSkillsを作って使っています。だからこそ、260個運用できる組織と50個で崩れる個人の違いがどこにあるのか、両方の一次情報を突き合わせて確かめたくなりました。今日はその境界線と、自分のSkillsフォルダを崩さないための3つのルールを整理します。

オプトが260個のClaude Skillsを量産できた理由

まず、何が起きたのかを時系列で押さえておきます。オプトは2026年5月18日、Anthropicの法人向け最上位プラン「Claude Enterprise Plan」を全社導入したと発表しました。あわせて、独自の広告運用プラットフォーム「OPT Ad Agent」を本格始動させました。基盤にはMCP(Model Context Protocol、AIと外部サービスを直接つなぐ標準規格)を採用しています。この仕組みを使い、Google・Meta・LINEヤフー・TikTokといった主要な広告媒体とClaudeを直接接続しました。データ収集・集計・レポート作成・異常値検知といった運用業務を、AIエージェントが24時間自律実行する体制に切り替えたと報じられています。従来は数週間かかっていたPDCAサイクルを、大幅に短縮する狙いです。

そして2026年8月7日、日経クロストレンドの連載「爆速『Claude』マーケティングの極意」第5回で、この体制の内側が報じられました。オプトは社内のトップレベルの運用知見を、Claudeの「Agent Skills」として260個体系化していたのです。Skillsとは、特定の作業手順や判断基準をテキストで定義しておき、Claudeがその場面で自動的に読み込んで再現する仕組みを指します。個人の経験値に依存することなく、担当者全員が同じ水準の運用品質を再現できる形に落とし込んだという点が、この報道の核心です。

ここで大事なのは、260個という数字そのものではありません。全社導入から量産までの間に、260個を管理する仕組みも同時に整えられていったと考えられます。OPT Ad AgentはGoogle・Meta・LINEヤフー・TikTokという複数の媒体をまたいで動く設計です。媒体ごとに異常値の定義もレポートの型も違うはずだと考えると、それを1つひとつSkillsに落とし込んでいけば数が数百に達するのは自然な流れだと推測できます。ここから先は僕の推測ですが、問題は数そのものより、その数百個を誰がどう管理し続けるかにあったはずです。

数百個という規模になると、もはや1人の担当者が全体を把握することはできません。オプトのように全社導入というタイミングで着手した場合、Skillsを作る段階から複数人が関わることになります。最初の設計思想として、個人の作業効率化ではなく組織のナレッジ基盤という位置づけだったからこそ、260個まで破綻せずに増やせたと見るのが自然です。

オプト側の運用設計として、公式リリースから確認できるのは体制の骨格部分です。Google・Meta・LINEヤフー・TikTokという媒体ごとにAIを直接接続したという内容でした。データ収集から異常値検知までを、24時間自律実行する体制へ移行しています。Agent Skillsという仕組み自体は、Anthropic公式の一般的な機構です。特定の作業手順を書いたテキストファイルを、Claudeが場面に応じて自動で読み込みます。たとえば「TikTok広告のCPA異常値をどう判定するか」という手順を1つのSkillsとして書いておくとします。担当者が誰であっても、同じ基準で異常検知が回るという使い方が想定できます。媒体数×判定項目数の掛け算で数が積み上がっていく構造自体は、この公式仕様から逆算できる自然な帰結です。

個人エンジニアが50個で直面した保守コストの壁

一方で、真逆の結果を報告している人もいます。個人エンジニアのnogataka氏はQiitaで、Claude Skillsを50個まで増やした運用記録を公開しました。最初の10個は明確に生産性を押し上げたものの、残り40個を積み上げていく過程で、保守コストがその効果の約3割を相殺してしまったといいます。

具体的には、Skillsによる作業削減効果が週3〜4時間だったのに対し、Skills自体のメンテナンス作業に週2時間を超える時間が取られるようになりました。結果として、正味の生産性向上はほぼ半減したとのことです。原因として挙げられていたのは、Claude Code自体のアップデートが月に2〜3回のペースで発生し、そのたびにSkillsの記述が古くなっていく点でした。

月2〜3回のアップデートという頻度が具体的に何を引き起こすかは、記事内で個別事例までは詳述されていませんが、一般論として想像しやすい構造です。たとえばコマンド名やオプションの記法が変わったのに、古いSkillsだけが以前の書き方のまま残っているとします。Claudeはそれを正しい手順だと信じて、実行し続けてしまいます。エラーで止まってくれるならまだ気づけますが、部分的に動いてしまう場合はさらに厄介です。出力が微妙にずれていることに、しばらく気づけないという事態が起こり得ます。

この報告でもっとも重要なのは、原因の分析部分です。nogataka氏は、問題の本質はSkillsの数そのものではないと述べています。100個のファイルからなるコードであれば、テストやCI(継続的インテグレーション、変更のたびに自動でチェックを走らせる仕組み)を使って管理できます。ところがSkillsには、それに相当する管理の仕組みが標準では用意されていません。数が増えるほど、どれが最新で、どれが重複していて、どれがもう使われていないのかを、人間の記憶だけで把握しなければならなくなるのです。

この気づきを踏まえて、nogataka氏はその後の記事で、Skillsに対してもCIやテストに相当する品質管理の仕組みを自作したと報告しています。個人開発であっても、数が一定量を超えた時点で、組織と同じような管理の発想が必要になるということです。裏を返せば、50個という規模は、個人が場当たり的な管理から抜け出さなければならない分岐点だったと言えます。

ここまでの2つの事例を並べると、答えはすでに見えています。260個と50個を分けたのは、数の大小ではなく管理設計の有無です。次の章で、その差を具体的に比較します。

項目	オプト(組織・260個)	個人エンジニア(50個)
命名・分類ルール	複数人が共有する前提で最初から統一	ルールなしで個人が思いつきで追加
保守にかかる時間	体制として組み込み済み(数字は非公表)	週2時間超、削減効果の約3割を相殺
数が増えた結果	均一な運用品質を維持	正味の生産性向上がほぼ半減

260個と50個、明暗を分けたのは数ではなく仕組みだった

オプトの260個と、個人エンジニアの50個。上の表で比較した通り、明暗を分けた要因は数の大小ではなく、Skillsを管理するための仕組みがあったかどうかです。

オプトの事例では、全社導入というタイミングで、複数の担当者がSkillsを共有・参照する前提の体制が最初から組まれていました。組織で使う以上、命名や分類のルールを決めないままでは運用が回りません。ある担当者が作ったSkillsを、別の担当者が探して使えるようにする必要があるからです。個人が思いつきで増やしていくのとは、最初から設計の出発点が違います。

対して個人エンジニアの運用は、自分1人が使うために始めたSkillsが、気づけば50個に膨らんでいたというパターンです。1人で使う分には、多少の重複や陳腐化があっても目をつぶって使い続けられます。ですが、その「目をつぶる」の積み重ねが、週2時間を超える保守作業として跳ね返ってきました。個人開発は身軽な分、管理の仕組みを後回しにしやすいという弱点があります。

この構図は、以前「MCPは増やすほど賢くなる」は誤解で扱ったMCP接続数の話とも重なります。あちらは接続する外部サービスの数、こちらは自作するSkillsの数という違いがあります。ですが「増やせば増やすほど良くなる」という単純な思い込みが崩れる構造は同じです。AIエージェントを拡張する機能は、増やす作業そのものより、増やした後の管理設計に成否がかかっています。

言い換えると、Skillsを何個まで増やせるかは、ツール側の限界ではなく運用側の設計力で決まるということです。260個という数字だけを見て「うちの規模では無理だ」と諦める必要はありません。逆に「50個で崩れた」という報告だけを見て、Skillsそのものを敬遠する必要もないはずです。大事なのは、自分やチームが今どちらの状況に近いかを見極めることです。

属人化を防ぐ運用と、個人の身軽さを両立させる考え方

とはいえ、個人がオプトのように専任の管理体制を組むのは現実的ではありません。ここで気になるのが、組織規模でなくても実践できる工夫はないのか、という点です。

答えは、管理の仕組みを最初から重装備にしないことにあります。オプトのケースは260個という規模だからこそ体系的な管理が必要でしたが、個人や小さなチームであれば、もっと軽い運用ルールで十分に効果が出ます。ポイントは3つです。命名規則を統一すること、索引を1か所にまとめること、そして定期的に棚卸しする予定をあらかじめ決めておくことです。3つに共通しているのは、Skillsの状態把握を「自分の記憶」に頼るのをやめて、外部の何か(ファイル名・索引・カレンダー)に肩代わりさせるという発想です。nogataka氏が直面した壁も、結局は記憶だけで50個を管理しようとしたことが原因でした。

この3つは、いきなり全部そろえる必要はありません。時間軸で考えると導入しやすくなります。今週やることは、命名規則を1つ決めて、次に作るSkillsから適用することです。過去分をすべて書き直す必要はありません。今月中にやることは、既存のSkillsをREADME.mdなどに索引化し、名前と用途を1行ずつ書き出すことです。ここまでで重複や陳腐化に気づける状態が整います。そして3か月後にやることは、最初の棚卸しです。nogataka氏の報告にあったとおり、Claude Code自体が月に数回アップデートされる前提で考える必要があります。使っていないSkillsを削除し、記述が古くなっているものを更新する時間を、あらかじめカレンダーに入れておくやり方が現実的です。思い立ったときにやろうとすると、後回しになったまま数が積み上がっていきます。AI活用の現場では、こうした「作って終わり」を防ぐ設計そのものが定着の鍵になります。この点はAI導入がPoCで止まる88%の壁でも扱いました。Skillsの棚卸しは、その縮図だといえます。

僕が自分のSkillsフォルダで試してみたこと

この2つの事例を読んでから、自分のSkillsフォルダを見直してみました。記事の構成チェックや、タイトルの文字数確認といった、毎回同じ手順を繰り返している作業をいくつかSkills化していました。ですが名前も適当につけていたため、似たような用途のものが2つ紛れていることに気づきました。

たとえば「タイトルの文字数と表示上限を確認する」Skillsと、「SEOタイトルのルールに沿っているか確認する」Skillsが別々に存在していました。用途が近すぎて、どちらを呼び出せばいいのか自分でも一瞬迷う場面があったほどです。作った当初はそれぞれ別の目的のつもりだったのですが、時間が経つと境界があいまいになっていたのです。これはまさに、nogataka氏が指摘していた「重複に気づきにくい」という状態そのものでした。

今回、2つのSkillsを1つに統合し、「動詞+対象」の命名規則に沿って名前を付け直しました。あわせて、手元のメモ代わりに使っていたファイルに、Skills名と用途を一覧で書き出しておくことにしました。作業自体は30分もかかりませんでしたが、これを怠っていたら、数か月後には自分でも把握しきれない状態になっていたはずです。数個の段階で違和感に気づけたのは、今回2つの事例を読んで確認する機会があったからこそだと思います。

今週から始める、Skillsフォルダの棚卸しチェックリスト

ここまでの内容を、実際に手を動かせる形に落とし込みます。今週中に確認してほしいのは次の5つです。

1つ目は、今使っているSkillsを全て書き出すことです。Claude Codeのフォルダを開けば一覧できます。思っていたより数が多いことに気づく人も少なくないはずです。書き出す作業自体が、自分のSkills運用を客観視する最初の一歩になります。

2つ目は、同じ用途のSkillsが重複していないかを確認することです。似た名前のファイルが複数ある場合、どちらか一方に統合できないかを検討してください。作った時期が離れていると、同じ目的で2つ作ってしまっていることに意外と気づきにくいものです。

3つ目は、命名規則を1つに決めることです。すでに複数の流派が混ざっている場合、無理に全部を書き直す必要はありません。次に作るものから統一していけば十分です。過去の資産を犠牲にしてまで統一する必要はなく、これから増える分を制御できれば効果は出ます。

4つ目は、README.mdに索引表を作ることです。ファイル名と用途を1行ずつ書き出すだけで、後から見返す負担が大きく減ります。索引がある状態とない状態では、10個を超えたあたりから体感の差がはっきり出てきます。

5つ目は、3か月後の棚卸し予定をカレンダーに入れることです。この予定を今のうちに確保しておかないと、nogataka氏が直面したような保守コストの積み上がりを、同じように後から実感することになります。予定を先に確保しておけば、忙しさを理由に先送りする余地がなくなります。

まとめ

Claude Skillsは、増やせば増やすほど便利になる機能ではありません。オプトの260個運用と、個人エンジニアの50個で生産性が半減した記録を並べると、その違いが管理の仕組みの有無にあることがはっきりします。

• オプト:2026年5月18日にClaude Enterprise Plan全社導入、8月7日の日経クロストレンド報道でSkills260個の体系化が判明
• 個人エンジニア:Skills50個で保守コストが効果の約3割を相殺、正味の生産性向上がほぼ半減(Qiita、nogataka氏)
• 明暗を分けた要因:数の大小ではなく、命名規則・索引・棚卸しという管理の仕組みの有無
• 今週の1手:Skillsの棚卸し、重複確認、命名規則の統一、README索引の作成、3か月後の棚卸し予定の確保

Skillsを1個作って満足するのではなく、10個、50個と増えていく前提で、今のうちに軽い管理ルールを決めておいてください。数が増えてから慌てて整理するより、はるかに少ない手間で済みます。

僕自身、たった数個のSkillsでも重複や名前のあいまいさに気づけました。数百個運用するオプトの規模には及びませんが、命名規則と索引という発想そのものは、規模に関係なく効きます。今日フォルダを開いて、まず1個目の重複がないか確認するところから始めてみてください。

今回の記事で参照した一次情報は次の4つです。オプトの全社導入と体制については、同社の公式リリースを参照しました。260個体系化の報道は、日経クロストレンド連載「爆速『Claude』マーケティングの極意」第5回(2026年8月7日)です。個人エンジニアの運用記録は、Qiita(nogataka氏)の2本の記事によります。オプトの体制部分は公式発表、260個という数字と体系化の経緯は報道ベースであることを、あわせて明記しておきます。