Agent SkillsをClaude Codeに入れた、GoogleエンジニアAddy Osmaniの19のスキル全解説

はじめまして、もるふぉです。

エンジニアをやりながら、今はほぼコードを書かない開発スタイルに移行しました。

「書けないから書かない」じゃなくて、「書けるから書かなくていい」という話です。

実案件ベースで気づいたことだけ書いています。

よければXもフォローしてもらえると嬉しいです → X(@morphox_ai)

Claude Codeに「これ作って」と投げて、出てきたコードをそのままマージしたら本番で動かなかった。

そんな経験、ありませんか。

自分は何度もあります。

見た目は完璧、テストも通る。

でもエッジケースが全部スキップされてて、APIの返り値も楽観的すぎて、レビューで赤くなるやつです。

Googleのソフトウェアエンジニア、Addy OsmaniがAIコーディングエージェント向けに公開した「Agent Skills」は、この問題を正面から解決しようとしたOSSです。

19のエンジニアリングスキルと7つのスラッシュコマンドをエージェントのワークフローに直接組み込む仕組みで、Claude Codeに対応しています。

今回はこのAgent Skillsを実際にClaude Codeに入れて使ってみたので、中身と感想をまとめます。

AIエージェントのコード品質問題——"完成に見えて壊れてる"を量産する理由

AIコーディングエージェントを業務で使い始めると、ある共通パターンに気づきます。

エージェントが「一応動くコード」を素早く出してくるんですが、プロダクション品質には程遠いんですよね。

これ、地味にストレスたまりませんか。

レビューで跳ね返されるのが分かってるのに、毎回同じ指摘をしなきゃいけない。

エージェントが手を抜く言い訳パターンあるある

具体的にはこういう言い訳をしてくるわけです。

• 「テストは後で追加します」
• 「エラーハンドリングは簡略化しています」
• 「パフォーマンスの最適化は次のステップで」
• 「セキュリティ面は別途検討が必要です」

見覚えありすぎませんか。

人間のジュニアエンジニアと同じ言い訳なんですよね。

しかも厄介なのは、エージェントはこれを「合理的な判断」として堂々と出してくるところです。

「そういうもんか」で受け入れてしまうと、技術的負債がどんどん積み上がっていく。

Anti-Rationalization Tableとは何か

Addy OsmaniのAgent Skillsには、「Anti-Rationalization Table」という仕組みが組み込まれています。

これ、すごくいいアイデアだなと思いました。

各スキルに対して「エージェントがよくする言い訳」と「なぜそれがダメか」が対になって定義されています。

たとえばこんな感じです。

これ、人間のコードレビューで毎回言ってることをそのままAgent Skillsとして構造化したものなんですよ。

エージェントが「合理的な言い訳」をしようとしたとき、スキルが自動的にそれをブロックする。

ここが単なるプロンプト集との決定的な違いです。

次は、このAgent Skillsを作ったのが何者なのかを見ていきます。

Addy OsmaniとAgent Skillsとは

GoogleのエンジニアリングマネージャーがOSSを作った背景

GitHub - addyosmani/agent-skills: Production-grade engineering skills for AI coding agents. · GitHub

github.com

Addy Osmaniは、GoogleでChrome開発チームのエンジニアリングマネージャーを経て、現在はGoogle Cloud AIのDirectorを務めている人物です。

Web開発界隈では超有名で、「Learning JavaScript Design Patterns」の著者としても知られています。

そのAddy Osmaniが、AIコーディングエージェント向けに「Agent Skills」をオープンソースで公開しました。

これは19のエンジニアリングスキルと7つのスラッシュコマンドを、エージェントのワークフローに直接組み込むプロジェクトです。

ポイントは、単にプロンプトを集めたものではないということ。

Googleのエンジニアリング文化——Hyrum's LawやChesterton's Fenceといった原則——を、AIエージェントが実際の開発で守れるように構造化しているところが本質です。

2.7kスター、約280フォークが示すもの

GitHubで2.7kスター、約280フォークという数字は、開発者ツール系のOSSとしてはかなり注目されている部類に入ります。

MITライセンスなので、自分のプロジェクトに自由に取り込めます。

このスター数が意味しているのは「みんな同じ問題で困ってた」ということなんですよね。

AIエージェントの品質問題を体系的に解決するフレームワークが、ようやく出てきた、という感覚です。

では実際にどんな構造になっているのか、全体像を見ていきましょう。

Agent Skillsの19スキル×6フェーズの全体像

Agent Skillsは、ソフトウェア開発の全工程を6つのフェーズに分け、合計19のスキルを配置しています。

この構造が非常によくできていて、「どのフェーズでエージェントがサボりやすいか」が一目でわかります。

Define（定義）— アイデア洗練と仕様作成

• idea-refine: アイデアを具体的な要件に落とし込む
• spec-driven-development: 仕様を先に書き、コードを後に

この段階でスキルが入っているのが大きいです。

エージェントに「これ作って」と言うと、いきなりコードを書き始めがちですが、Defineフェーズのスキルが「まず仕様を定義しろ」とブレーキをかけてくれます。

Plan（計画）— タスク分解

• planning-and-task-breakdown: 大きなタスクを小さな原子的タスクに分解

「全部一気に実装しようとする」というエージェントの悪癖を防ぎます。

ここが効くんですよね。

一度に全部やろうとするから品質が下がる。

小さく分割して一つずつ確実に、というのはGoogleのSWEカルチャーそのものです。

タスクの粒度が細かくなるほど、実装後の検証も容易になり、手戻りが劇的に減ります。

Build（実装）— コンテキストエンジニアリングとAPI設計

• incremental-implementation: 一度にワンスライスずつ段階的にビルド
• context-engineering: エージェントのコンテキストを適切に管理
• frontend-ui-engineering: フロントエンド実装のベストプラクティス
• api-and-interface-design: API設計の原則（Hyrum's Law対応）

4スキルで最もボリュームがあるフェーズです。

context-engineeringが入っているのが実務的に嬉しいポイントで、エージェントに渡す情報の量と質を制御する考え方がスキルとして体系化されています。

つまり、「何をエージェントに教えるか」という上流の設計まで面倒を見てくれるんです。

Verify（検証）— TDDとブラウザテスト

• test-driven-development: テスト駆動開発の実践
• browser-testing-with-devtools: ブラウザDevToolsを使ったテスト
• debugging-and-error-recovery: デバッグとエラー回復

「テストは後で」を許さないフェーズです。

自分はもともとテスト駆動でAIを制御するスタイルなので、ここの設計には共感しかなかったですね。

3スキルそれぞれが独立して機能するため、TDDだけ使う、デバッグ強化だけ使う、という部分適用もできます。

Review（レビュー）— コード品質とセキュリティ

• code-review-and-quality: コードレビューの観点
• code-simplification: 複雑さの削減（Chesterton's Fence対応）
• security-and-hardening: セキュリティ強化
• performance-optimization: パフォーマンス最適化

4スキルで、ここもBuildと並んで厚いフェーズです。

security-and-hardeningが独立したスキルとして存在するのは、エージェントが生成するコードのセキュリティ問題を意識しているからでしょう。

実際、エージェントはSQLインジェクション対策やCSRF対策をスキップしがちです。

code-review-and-qualityにはシニアスタッフエンジニア視点のチェックリストが組み込まれており、マージ前の品質ゲートとして機能します。

Ship（リリース）— gitワークフローとCI/CD

• git-workflow-and-versioning: gitのブランチ戦略とバージョニング
• ci-cd-and-automation: CI/CDパイプラインの自動化
• deprecation-and-migration: 非推奨化とマイグレーション戦略
• documentation-and-adrs: ドキュメントとアーキテクチャ決定記録
• shipping-and-launch: 本番リリースの手順

5スキルで最多です。

ここにdeprecation-and-migrationが入っているのが渋い。

「コードは資産ではなく負債」というGoogle的な思想が反映されていて、不要になったコードを適切に削除・移行する手順までスキル化しています。

構造が分かったところで、次はAgent Skillsの真髄——Googleのエンジニアリング原則がどう組み込まれているかを見ていきます。

ここが正直、一番面白いところです。

Googleのエンジニアリング原則がAgent SkillsのAIエージェントに組み込まれている

Agent Skillsの最大の価値は、Googleのエンジニアリング原則が随所に組み込まれている点です。

これは単なるプロンプト集では絶対に出てこない深さです。

Hyrum's Law——APIの暗黙の依存が危険な理由

「十分な数のAPIユーザーがいれば、契約に何を約束しようと関係ない。システムの観察可能な振る舞いすべてが誰かに依存される」

api-and-interface-designスキルにこの原則が組み込まれていて、エージェントがAPI設計をするとき、暗黙の契約（ドキュメント化されていない振る舞い）にも注意を払うようになります。

具体的には、レスポンスのフィールド順序やnull/undefinedの扱い、エラーメッセージの文言まで、ユーザーが依存しうるすべての側面を意識した設計をエージェントに要求します。

「仕様書に書いてないから大丈夫」が通用しない、というやつですね。

Chesterton's Fence——理由を知らずにコードを消すな

「フェンスがなぜ建てられたかを理解するまで、そのフェンスを壊すな」

code-simplificationスキルに組み込まれている原則です。

いわば「謎の古いコードにも存在理由がある」という思想です。

エージェントはよく「このコードは不要なので削除しました」と言ってきますが、そのコードがなぜ存在するのかを理解せずに消すのは危険です。

Agent Skillsを入れると、エージェントが既存コードを削除・変更する前に「このコードが存在する理由」を確認するステップが入ります。

これ、実案件で何度も助けられました。

Beyonce Rule & Shift Left——テストと品質を前倒しにする

「If you liked it, then you shoulda put a test on it（気に入ったならテストを書け）」

これがGoogleのBeyonce Ruleです。

テスト駆動開発のスキルにこの原則が入っていて、「テストされていない機能は存在しないのと同じ」という厳しい基準がエージェントに適用されます。

さらにTest Pyramidの考え方も組み込まれていて、ユニットテスト80%、統合テスト15%、E2Eテスト5%というバランスを意識した提案をしてくるようになります。

Shift Left原則は、品質検証を開発サイクルの早い段階に持ってくるという考え方で、CI/CDスキルに組み込まれています。

「本番で見つかるバグは、設計段階で防げたはず」という発想ですね。

原則が分かったところで、次は実際の使い方です。

7つのスラッシュコマンドを覚えれば、日常の開発フローに自然に溶け込みます。

Agent Skillsの7つのスラッシュコマンドの使い方

19スキルを実際の開発フローで使うためのインターフェースが、7つのスラッシュコマンドです。

/spec と /plan——コードを書く前にやること

/spec は仕様を定義するコマンドです。

何を作るのか、どんな制約があるのか、受け入れ条件は何かをエージェントに先に考えさせます。

「Spec first, code later」というアプローチです。

/plan は実装計画を立てるコマンドです。

大きなタスクを小さな原子的タスクに分解して、実装順序を決めます。

この2つを最初にやるだけで、エージェントの出力品質が明確に変わります。

いきなりコードを書き始めるのと、仕様と計画を先に固めるのとでは、最終的なコード品質に大きな差が出ます。

/build と /test——実装と検証のサイクル

/build は段階的にコードをビルドするコマンドです。

一度に一つのスライスだけを実装する、というルールが効いています。

「全部一気に」ではなく「薄い一枚ずつ」。

/test は実装した機能の動作を証明するコマンドです。

テストがエビデンスになるという考え方で、「動いたと思います」ではなく「テストが通って証明されています」という状態を作ります。

/review, /code-simplify, /ship——品質ゲートからリリースまで

/review はマージ前の品質チェックです。

シニアスタッフエンジニアの視点でコードの健全性を評価します。

Agent Skillsには3つの専門エージェントペルソナ（code-reviewer、test-engineer、security-auditor）が用意されていて、それぞれの専門視点からレビューが走ります。

つまり、マージ前に「コードレビュー担当」「テストエンジニア」「セキュリティ監査役」の3人に同時に見てもらえる、みたいなイメージです。

/code-simplify は複雑さを削減するコマンドです。

「Clarity over cleverness（明確さは巧みさに勝る）」という原則に基づいて、不要な抽象化やover-engineeringを指摘してくれます。

/ship は本番デプロイのコマンドです。

「速くリリースするほど安全」というGoogleの思想が反映されていて、デプロイに必要なチェックリストを自動生成します。

コマンドが揃ったところで、次は実際に使ってみた感想を正直に話します。

実際に使ってみた感想（もるふぉ視点）

/specで仕様を先に出させた結果

自分が一番変化を感じたのは/specコマンドです。

普段Claude Codeで開発するとき、自分は「こういう機能を作って」と投げがちだったんですが、/specを使うと先に仕様書が出てきます。

受け入れ条件、エッジケース、制約事項が明文化されるので、「ああ、ここ考慮してなかった」と自分が気づけるんですよ。

エージェントに仕様を書かせることで、実装前の抜け漏れチェックが自動的に入る。

これは地味だけど確実に効果がありました。

品質が上がったと感じた場面

テストの質が明らかに変わりました。

Agent Skillsを入れる前は、エージェントが書くテストはハッピーパスだけのことが多かったんですが、入れた後はエッジケースやエラーケースまでカバーするようになりました。

あと、コードレビューの指摘が減りました。

自分が見つける前にエージェント自身が問題を検出して修正してくれるケースが増えた印象です。

特にセキュリティ系——SQLインジェクション対策やパラメータのサニタイズ——を最初から意識したコードが出てくるようになったのは大きかったですね。

注意点・合わなかった点

正直に言うと、デメリットもあります。

コンテキストウィンドウの消費は増えます。

19スキル分のプロンプトが常に読み込まれるので、長いコンテキストのやりとりでは影響が出る場合があります。

また、小さな修正や単発のバグフィックスには、ワークフローが重すぎると感じることもありました。

/specから始めて/planして/buildして......という流れは、ある程度の規模の機能開発には最適ですが、1行修正のhotfixには過剰です。

使い分けが大事ですね。

全部のコマンドを毎回使う必要はないです。

Claude CodeへのAgent Skillsインストール手順

プラグインマーケットプレイス経由（推奨）

Claude Codeのセッション内でスラッシュコマンドとして実行するだけです。

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

これだけで19スキルと7スラッシュコマンドが使えるようになります。

git cloneによるローカル配置

マーケットプレイスが利用できない環境や、スキルの中身をカスタマイズしたい場合はこちらが便利です。

git clone https://github.com/addyosmani/agent-skills.git

クローン後、各スキルのSKILL.mdファイルをエージェントのコンテキストに読み込ませることで動作します。

自分のプロジェクトのルートにコピーしてCLAUDE.mdから参照するか、プロジェクト固有にカスタマイズしたい場合はこの方法が使いやすいです。

Cursor/Windsurf/GitHub Copilotへの対応

Claude Code以外のエージェントでも使えます。

Cursorの場合は、SKILL.mdを.cursor/rules/ディレクトリにコピーするだけです。

cp SKILL.md .cursor/rules/agent-skills.md

WindsurfやGitHub Copilotの場合は、それぞれの設定ファイルにスキルの内容を追加します。

基本的にMarkdownを受け付けるエージェントであれば、どれでも使えるのがAgent Skillsの設計のうまいところです。

まとめ——Googleのエンジニアリングが、エージェントの"雑さ"を直す

Addy OsmaniのAgent Skillsは、「AIエージェントに人間のシニアエンジニアの判断基準を持たせる」という試みです。

19スキル×6フェーズの構造設計、Anti-Rationalization Table、Googleのエンジニアリング原則の組み込み。

どれも「プロンプトを貼っておしまい」では絶対に到達しない深さがあります。

自分が特に価値を感じたのは3つです。

• /specで仕様を先に固める習慣がついたこと
• テストの質が上がり、レビュー指摘が減ったこと
• Chesterton's Fenceのおかげで、既存コードを安易に消さなくなったこと

AIコーディングエージェントを使っていて「品質が微妙だな」と感じているエンジニアは、一度Agent Skillsを試してみる価値があると思います。

インストールは数分で終わるし、合わなければ外せばいいだけです。

リスクゼロで始められます。

Googleのエンジニアリング文化を、自分のエージェントに組み込む。

それがAgent Skillsの本質です。

今日のセッションが終わったら、まず /plugin marketplace add addyosmani/agent-skills を一度叩いてみてください。

3分あれば環境が整います。