■ 1. Agent Skillsのリリース概要
- リリース時期:
- 2025年10月16日にAgent Skills（
skills-2025-10-02beta）がClaude Developer Platformで公開- Skillsとは:
- Claudeの能力を拡張する新しい仕組み
- 指示、スクリプト、リソースを整理したフォルダで構成
- Claudeが特定タスクの実行時に動的に読み込む
- 初期リリースの内容:
- Anthropic管理のSkills: PowerPoint、Excel、Word、PDFを扱う既製Skill
- カスタムSkills: Skills API（
/v1/skills）経由で独自Skillをアップロード可能- ドメイン知識や組織のワークフローをパッケージ化できる
- 利用にはコード実行ツールの有効化が必要
■ 2. 発端となったトークン上限到達
- 土曜午後の異変:
- 1日に2回、Claude Maxのトークン上限に到達
- プロジェクト、ワークフロー、プロンプトはいつもと同じで原因が不明だった
- 得られた教訓:
- 原因は目の前に隠れていた
- ドキュメントが十分に伝えていないSkillsの本質的な性質を学ぶ契機になった
■ 3. 一貫したコードレビューの必要性
- Personal-Qの開発:
- crewAIベースのマルチエージェント管理システムで、フロントエンドはReact
- AI支援開発の時代に開発フローの全工程がどう感じられるかを試す個人プロジェクト
- Reactのスキルが鈍っていたため、ReactフロントエンドのレビューSkillを自作することにした
- 求めたもの:
- 網羅的で一貫したコードレビュー
- 質問の言い回しや会話スレッドに左右されない決定論的なレビュー
- 同じパターンを毎回同じ形で指摘し、重要事項を再説明しなくて済むこと
- 従来のAIレビューの問題:
- スロットマシンのように結果が安定しない
- 見落としへの鋭い指摘が得られることもあれば、些細な書式に注目し重大な再レンダリング問題を見逃すこともある
- 不安定さの原因（仮説）:
- コンテキストウィンドウ内での位置に依存する
- セッション序盤でコンテキストに余裕があれば良い結果が出る
- 気づかぬうちにコンテキストが圧縮されていると、LLMが方向性を見失い全く異なる結果になる
■ 4. frontend-reviewer Skillの構築
- 他社機能との違い:
- GeminiのGemsやChatGPTのカスタムGPTは、文脈や文書を与えて受動的に問い合わせる発想
- Skillsはそれらとは異なる
- Skillsの本質:
- 知識を事前に明文化することを強制する
- タスクを毎回予測可能な方法で遂行する手順をLLMに教える
- カスタム指示のような「一般的な好み」ではなく、網羅的で包括的な定義
- 特定領域に関する完全なメンタルモデルをClaudeに教えること
- Skillに定義した内容:
- React 19のパターン（hooks、コンポーネント合成、エコシステム全般）
- TypeScript strictモード（ジェネリクス、型安全性、適切な型推論）
- パフォーマンス基準（useMemo、useCallback、React.memo）
- アクセシビリティ要件（ARIA、キーボード操作、WCAG準拠）
- Tailwind CSS
- TanStack QueryとReact Hook Formによる状態管理
- 一貫したフィードバックのための決定論的分析モード
- 重大度レベル付きの構造化JSON出力形式
- Skillは好みの集合ではなく完全なナレッジベース
- 構築の難しさ:
- 構築と並行して、別のClaude CodeやGeminiのインスタンスで調査と要約が必要だった
- 定義は網羅的でなければならず、曖昧にごまかせない
- 「アクセシビリティの問題を確認する」では不十分で、LLMを予測可能にするには具体性が必要
- ジュニア開発者への指示との類似:
- 「良いコードを書け」と言うか、包括的なスタイルガイドや設計パターン文書、実例を渡すかの違い
- ただしAIはそれを一貫して実際に守る
- 使用モデル:
- レビューにはHaiku 4.5を指定
- 頻繁に実行するため速度とコスト効率を優先
■ 5. 予想外の成功
- レビューの高速化:
- Haikuの採用によりコードレビューが劇的に速くなった（想定どおり）
- 一貫性の向上:
- 最大の驚きは一貫性の改善
- コンポーネントAでラベル欠落が指摘されれば、後のコンポーネントBの同じパターンも同一に指摘される
- 会話文脈による変動やドリフト、注目点のぶれがない
- 決定論的動作の効果:
- レビューを再実行すべきか迷わなくなった
- 依頼の言い回しで結果が変わるかを気にしなくなった
- Skillが分析を定義し、Claudeはそれを一貫して実行するだけ
- 信頼の高まり:
- フィードバックが信頼できるため、Skillが検出済みの項目を手作業で再確認しなくなった
- レビューワークフローが加速した
- 開発パターンの無意識の変化:
- コード品質が向上し、変更をコミットする自信が増した
- コミットが増え、変更セットが小さく焦点の絞られたものになった
- レビューの摩擦が消えたため、より頻繁にコミットするようになった
- YOLOモードでの運用:
- Cursorのターミナルで
claude --dangerously-skip-permissionsを使って起動- Claude Codeの作業中に別の作業ができ、時間を倍増できたように感じた
- git worktreeによる並行作業は今後の記事で扱う予定
- しかし、その順調さは長く続かなかった
■ 6. トークン消費の爆発
- 消費の異常:
- 数時間前にアップグレードしたばかりのMaxプランで猛烈に消費していた
- 上限の高さを求めてMaxにしたのに、想定よりはるかに早く上限に達した
- 仮説1 Skillが冗長すぎる:
- Skillsはプログレッシブ・ディスクロージャーを採用しており、この仮説は誤り
- frontend-reviewer Skillは約500行だが、Reactコードのレビュー時にしか読み込まれない
- ドキュメント作成やデバッグ時には読み込まれない
- 不要時にコンテキストを圧迫しない点がSkillsの優れた特徴
- 仮説2 レビュー回数を覚えている以上に実行している:
- 可能性はあるが、実行量を劇的に増やした覚えはなかった
- 偶然Gmailのタブを開き、原因に気づいた
■ 7. あらゆる場所で動いていたレビュー
- 3か所でのClaude利用:
- ローカル開発
- GitHub ActionsのCIで全コミットに対する自動コードレビュー
- Terragonによるコードセキュリティレビュー
- コミット1回あたりの流れ:
- ローカルでコミット前にfrontend-reviewer Skillでレビュー
- コミットがCIを起動し、プロジェクト全体のClaudeコードレビューが走る
- 2週間前に設定して忘れていたTerragonが新規PRを検知し、レビューとセキュリティレビューを実行
- フィードバックループの形成:
- Skillが効果的すぎて行動が変わった
- 時間節約のために設定した自動化の実行頻度が上がった
- 結果としてトークン消費が倍増した
- Terragonは静かに、一貫して、コミットのたびにトークンを消費していた
- 頻度増加の連鎖:
- Skillにより自信と品質が向上し、コミット頻度が増えた
- コミットごとにCIが走り、そのたびにトークンを消費した
- ツールが優秀すぎて、どこで動いているかを意識しなくなった
- それは驚くべきことであると同時に危険でもある
■ 8. Skillsから学んだこと
- 見落とされがちな性質:
- Skillsの技術的詳細（プログレッシブ・ディスクロージャー、ファイルシステムベースの構成、組み合わせ可能性）は十分に文書化されている
- 実際に経験するまで気づきにくいのは、AIが効果的になりすぎて無自覚にあらゆる場所で使い始めること
- 従来のAIツールとの違い:
- 手動プロンプトでは、入力し、応答を得て、トークン数を見るため各やり取りを意識できる
- その摩擦が意識を生んでいた
- Skillsによる摩擦の除去:
- Skillsはインフラ、バックグラウンドプロセス、自動チェックになる
- 一度設定すれば確実に動き、存在を忘れる
- 自動化は見えなくあるべきで、それ自体は目標どおり
- 自動化のコスト:
- 自動化は無料ではなく資源を消費する
- ローカル開発、CIパイプライン、pre-commitフックなど複数箇所で同じSkillが動くとコストが倍増する
- 一貫性の両面性:
- 一貫性はSkillsの決定的な強み
- 同時に、その存在を忘れさせる原因でもある
- 一貫性のないツールは正しく動いたか常に確認が必要で注意を引く
- 一貫したツールは背景に溶け込み、Skillsは非常に一貫している
■ 9. より広い示唆
- 知識の事前明文化の強制:
- Claudeの汎用的な知性に意図を汲み取らせることには頼れない
- 網羅的、包括的、明示的である必要がある
- 大変な作業だが、信頼性という形で報われる
- 一貫性によるワークフローの変化:
- ツールを完全に信頼すると行動が変わる
- コミット頻度が上がり、自動チェックに頼り、手動検証をやめる
- ツールは支援からインフラへと変わる
- Skillの実行場所の把握:
- トークン予算だけの問題ではなく、自分のシステムを理解するという問題
- ローカル開発、CI、自動化などClaudeを組み込んだ全箇所が対象
- 呼び出し箇所が増えるほどコストと影響が倍増する
- YOLOモードには監視が必要:
- 自律的な運用は本当に生産的
- エージェントを走らせ、Skillに問題検出を任せ、素早くリリースできる
- ただし、何がどこでどれだけのコストで動いているかを把握する可観測性が必要
- AI支援の単位経済の変化:
- これまでLLMのコストはクエリ単位で考えてきた
- Skillsは単発のクエリではなく、開発ワークフロー全体で持続的に動く能力
- そのため運用コストが発生し、計算方法が変わる
■ 10. 現在の対応と今後
- 設定の見直し:
- ローカル開発では引き続きSkillを多用し、最も価値が高い領域と位置づける
- 独自のSkillsマーケットプレイスを公開し、
/plugin marketplace add eovidiu/agents-skillsでClaude Codeに取り込める- CIでの自動コードレビューを停止
- Terragonはリクエスト時のみ実行する設定に変更
- 全呼び出し箇所のトークン消費を追跡する監視の導入を検討中
- 本質的な教訓:
- 設定の調整ではなく、Skillsが象徴する変化にある
- その変化とは、一時的な支援から持続的な能力への移行
- 従来のプロンプトとSkillsの対比:
- 従来のプロンプトは会話的で、質問し、応答を得て、コンテキストが消える
- Skillsはインフラ的で、一度定義すれば継続的に動き、開発環境の一部になる
- 移行がもたらす新たな検討事項:
- 能力がどこに展開されているか
- 運用コストはどれだけか
- 基準の進化に合わせてどう保守するか
- AIとの関係の変化:
- ドキュメントはSkillsの定義と作り方を扱う
- 使って初めて分かるのは、AIとの関係が会話相手からOSへと変わること
- 移行が完全に成功すると、請求が来るまでバックグラウンドで動いていることを忘れる
■ 11. Skillsを試す人への推奨事項
- 一つの焦点領域から始める:
- frontend-reviewerが広範なのは、フロントエンドのレビュー自体が多くを含むため
- 最初のSkillで全てを網羅しようとしない
- 選んだ領域では可能な限り網羅的にする:
- 多くの領域を浅く扱うより、一つの領域を包括的に扱う方がよい
- 曖昧なSkillは不安定な結果を、包括的なSkillは信頼できる自動化を生む
- Skillの実行場所を追跡する:
- ローカル、CI、自動化などの各呼び出し箇所がトークンを消費し、コストを積み上げる
- skill-creatorツールの活用:
- 対話型のskill-creatorは導入時に非常に役立つ
- 適切な質問をして適切な構造を生成し、後から手作業で改善できる
- Skillのバージョン管理:
- Skillはコードであり進化するため、ソース管理に置く
- 履歴を残し、実験が失敗したときにロールバックできるようにする
- 呼び出し箇所別のトークン消費監視:
- 総使用量だけでなく、どこで消費されているかを把握する
- 成功した自動化が想定より速く拡大したときの驚きを防げる
- 最も重要な注意点:
- Skillがうまく機能しているときこそ注意を払う必要がある
- 成功は統合を、統合は複数の呼び出し箇所を、複数の呼び出し箇所はコストの倍増を意味する
- うまく機能するほど見えなくなり、それが約束でありリスクでもある
■ 12. 結び
- frontend-reviewer Skillの現状:
- 現在も稼働し、見落としを検出し、一貫したフィードバックで開発を加速させている
- ただし、どこでどれだけ動いているかを以前より意識している
- 完璧に機能するツールこそ、最も気づきにくい
- 提供状況:
- 執筆時点でClaude SkillsはPro、Max、Team、Enterpriseユーザーが利用可能
- 2025年10月中旬の公開直後のため、ツールやベストプラクティスの急速な進化が見込まれる
- 実装は特定のバージョンに固定し、更新は意図的に行うべき