はじめに
「生成AIで開発が楽になる」「バイブコーディングで生産性が爆上がりした」
そんな話を聞くたびに、こう思ったことはないでしょうか。
「いや、そこまで楽になってないが？むしろ忙しくなった」
実際、生成AIでコーディング作業が削れた代わりに、別のコストが前面に出てきました。
たとえば、こんなやつです。
- 評価コスト：出力の良し悪しを判断し続ける（レビュー地獄がまさにこれ）
- 前提共有コスト：背景・制約・文脈を毎回説明する
- 会話運用コスト：ラリーが増えるほど文脈が肥大化し疲弊（同じ説明の繰り返しも含む）
- 統合作業コスト：部分的に良いアウトプットを最終成果物として整形・接続するのが面倒
- 責任コスト：最後は人間が責任を持つので、結局「確認」が省略できない
つまり、生成AIは“手を動かす部分”は削ってくれる一方で、判断と整理の負荷をこちら側に寄せてきます。
これが「確かに速くはなったが、思ったほど楽ではない」の正体だと思っています。
私は業務で Claude Code を使い込み、確かに今までよりは楽になったと感じているものの、同時にこういう違和感も強くなりました。
“うまく使える人と使えない人の差が、以前にも増して露骨に見えるようになった”
この差を生む要因はいくつかありますが、特に厄介なのが「会話運用コスト」です。
会話ベースでAIを運用している限り、手順も判断も毎回揺れます。結果、属人化するんですよね。
そこで効いてくるのが、Claude の Skills という仕組み。
Skills は、うまいプロンプトや会話力で頑張る方向ではなく、
判断基準と手順を“設計物として固定し、再利用可能にする” 方向に寄せることができます。
この記事では、
- なぜ生成AI時代にエンジニアが依然として大変なのか
- なぜ Skills がその一部を構造的に解決しうるのか
を、私自身の学びベースで整理してみます。
ちなみに、今回紹介するClaude Skillsは、先日Anthropic社が公式に公開した Claude Skills構築完全ガイド を読むと全体像が掴みやすいです
教訓1：「言語化できる人だけが得をする」は事実
生成AIは、
言語で世界を切り取れる人の思考を増幅する装置
です。
これは能力差を生みます。
- 感覚で分かっているが説明できない人
- 判断基準を持っているが言葉にできない人
こうした人は、 AI時代になって逆に苦しくなってきているように感じます。
教訓2：生成AIは「判断の軸を教えてくれない」
生成AIは賢い。
しかし、判断の軸そのものを示してくれるわけではありません。
- 何が問題か
- 何を正解と見なすか
- どこまでやれば十分か
これを決めるのは、常に人間です。
プロンプトが長くなるほど疲弊するのは、
実は「説明が大変」なのではなく、
判断基準が整理されていないまま投げているからなのかもしれません。
「もっと綺麗に」「より端的に」「一般的に」
といった言葉を足し続けているとき、
実は 自分の中での合格ラインが決まっていない ことが多いのではないでしょうか・・？
生成AIはその曖昧さを察してくれますが、代わりに毎回違う方向に最適化してしまいます。
教訓3：Skillsは「個人スキル」に依存しない
Claude Skills が本質的に優れている点は、「うまいプロンプトを書く人」や「会話が得意な人」を前提にしていないところにあります。
通常の生成AI活用では、
- どう頼めば意図が伝わるか
- どこまで説明すれば誤解されないか
- 出力がズレたとき、どう軌道修正するか
といった 会話能力 が暗に要求されます。
一方、Skillsが求めるのは
「その場でうまく伝えること」ではありません。
必要なのは、
判断基準を一度だけ決め、それを手順として固定すること
です。
私の場合、
- コードレビュー時の観点
- 設計方針の優先順位
- 日報のフォーマット
などを Skillsで定義してみたところ、ラリー回数が激減し、体感倍くらい作業が楽になりました。
Skillsとは、 人間の判断を “一時的な会話” から “再利用可能な設計物”として保存する仕組みなのだと思います。
ちなみに、独自スキル はClaude Codeで対話しながら簡単に作ることができます！
cloneしたanthropics/skillsでClaude Codeを立ち上げ、指示をするだけ。
教訓4：仕事は「会話」で回すな。「仕組み」で回せ。
プロンプト運用が破綻する理由は明確です。
それは、仕事を「会話」で回そうとしているからです。
会話ベースの運用では、
- 手順が毎回変わり
- 判断が場当たりになり
- 結果に再現性が生まれません
Skills はこれを、
- YAMLでいつ使うかを定義し
- Markdownで手順を固定し
- scriptsで曖昧さを排除する
という形で解決してくれます。
これは仕事の技術ではなく、仕事をどう設計するかという話です。
脱線トーク（ここは興味がある人だけ読んでください）
Progressive Disclosure（段階的ロード）
Skillsで個人的に最も「設計思想として美しい」と感じたのが、 Progressive Disclosure（段階的ロード） という考え方です。スキル定義ファイル(SKILL.md)の冒頭には、YAMLフロントマターと呼ばれる軽量なメタ情報だけを置き、Claude はまず「そのスキルが存在すること」だけを認識します。そのあと、必要に応じてスキル本体を読みに行きます。
流れ
Lv. 1: まずはYAMLフロントマター（SKILL.mdの冒頭部分）で存在だけを知らせる
Lv. 2: 本当に必要になったときだけ詳細（SKILL.mdのBody）を読み込む
Lv. 3: 重い資料や複雑な手順はさらに必要なときだけ後段で参照する
この構造によって、トークン効率と専門性を同時に成立させているのです。
おわりに
生成AIが広まっても、エンジニアの仕事は楽になった実感がない。
それはおそらく、コードを書くことや調べごとが減った代わりに、
判断する・考える仕事が前面に出てきたからだと思います。
ですが、Skills を使えば、少しはそのような仕事の比重が減るはずです。
- 同じ説明を何度もする
- 人によって結果が変わる
- 属人化に疲れている
そう感じたとき、
AIとの会話を続けるか、Skills に落とすか
ぜひ、Skills、試してみてください！