エージェントスキル

2026年5月5日原文(addyosmani.com)

概要

シニアエンジニア の仕事は、コードの差分に現れない見えない作業が多い
AIコーディングエージェント はこれらのプロセスを省略しがち
Agent Skills は、シニアエンジニアの標準的な工程をAIに強制する仕組み
ワークフロー重視、反合理化、検証必須など5つの設計原則
Googleのエンジニアリング文化 やSDLCに基づいた実践的なガイドライン

シニアエンジニアの見えない仕事とAIエージェントの課題

シニアエンジニア の本質的な仕事は、スペック作成、テスト、レビュー、スコープ管理など、コードの差分（diff）には現れない作業
AIコーディングエージェント は、最短ルートで「完了」を目指すため、仕様確認やテスト作成、レビュー観点の配慮などを省略
これらの工程を飛ばすことは、シニアエンジニアが長年かけて避けてきた失敗パターン
Agent Skills は、AIエージェントにこの「見えない作業」を強制するための仕組み

Agent Skillsの仕組みと「スキル」の定義

スキル はMarkdownファイルで記述され、必要なタイミングでエージェントの文脈に挿入
リファレンス資料ではなく、 ワークフロー （手順とチェックポイント、明確な終了条件）が本質
エッセイ形式のルールのみでは実際の行動に結びつかないため、 プロセス重視 が重要
スキルごとに「やるべき行動」と「検証可能な証拠」が明記されている

SDLC（ソフトウェア開発ライフサイクル）との対応

20種類のスキルが6つのライフサイクルフェーズ（Define, Plan, Build, Verify, Review, Ship）に整理
- /spec: 何を作るか決める
- /plan: 作業分割
- /build: 実装
- /test: 動作検証
- /review: レビュー
- /ship: 安全なリリース
- /code-simplify: コード簡素化
Google や Amazon など大手のSDLCと同様の流れ
AIエージェントはデフォルトで多くのフェーズを飛ばすが、Skillsは全工程を通過させる設計

5つの設計原則

プロセス重視: ワークフローを明示し、実行可能な手順とする
反合理化テーブル: 「この作業は不要」という言い訳と、その反論をセットで記載
- 例：「このタスクは小さいからスペック不要」→「受け入れ基準は必須」
- 例：「テストは後で書く」→「“後で”は来ない。先に書く」
検証必須: すべてのスキルは「証拠の提出」で終わる（テスト通過、レビュアー承認など）
段階的開示: 必要なスキルだけを文脈にロードし、無駄な情報で性能劣化を防止
スコープ管理: 「頼まれた範囲だけ触る」を徹底。余計なリファクタや拡張は厳禁

Googleエンジニアリング文化との関係

Hyrum’s Law: API設計での互換性重視
テストピラミッド や Beyoncé Rule: テストファーストの徹底
DAMP over DRY: テストコードは明示的に
PRサイズ管理 と レビューフレームワーク: 小さく、レビューしやすい単位で
Chesterton’s Fence: 理由が分かるまで削除禁止
トランクベース開発 や Shift Left: 早期検証・リリース分離
Code-as-liability: コードの最小化・保守性重視

Agent Skillsの利用方法

モード1: Marketplace経由でインストール
- Claude Codeなどでコマンド追加し自動適用
モード2: Markdownを任意ツールに配置
- Cursor, Gemini CLI, Codex, Aider, Windsurf, OpenCodeなどで利用可
モード3: ドキュメントとして読むだけ
- スキル内容を自チームのガイドラインやレビュー基準に転用可能
- まずは自分たちの課題に近いスキルから選び、ワークフロー整備を推奨

インストールしなくても盗むべきパターン

反合理化の明文化
- 「テストは後で」「小さすぎて設計不要」など、よくある言い訳とその反論を記録
プロセス重視への転換
- 長文のリファレンス資料はワークフロー＋チェックリストに変換
検証の強制
- すべてのタスクの出口は「証拠の提出」とする

まとめ

Agent Skills は、AIエージェントにシニアエンジニアの標準的な「見えない仕事」を強制するためのオープンな仕組み
プロセス重視・反合理化・検証必須・段階的開示・スコープ管理 の5原則が、信頼性の高い開発を支える
Google等の実践知 を体系化し、AI/人間問わず再利用可能なワークフローとして提供
自チームの課題や文化に合わせて、部分的にでも「盗む」価値がある実践知

Hackerたちの意見

SEOやLLMOの観点から見ると、これらのスキルの発見性は名前を変えないと難しいよね。もしAddyがこれを読んでたら、どうやってSuperpowersと比べて提案するんだろう？

└

実際にどれくらいの人がsuperpowersを使ってるのか知りたいな。自分はsuperpowersが出る前からエージェント開発のシーンにいたけど、今は自分が作ったプロセスの50%以上がsuperpowersでカバーされてるんじゃないかと心配してる。GitHubのスターはもう信じられないけど、誰か教えてくれない？superpowersは本当に普及してるの？もし本当に価値があるなら、なんでBorisはまだその概念を統合してないの？

└

プラグインを通じて提供される缶詰のスキルの集まりみたいだね？

└

superpowersって実際に機能するの？メインのスキルファイルはあまり自信を与えてくれないよね。「もしスキルが自分のやってることに適用される可能性が1%でもあると思ったら、絶対にそのスキルを呼び出さなきゃいけない。」

└

これは、NextJSと競うためにReactJSっていうReactフレームワークを作るようなもんだね。

LLMをうまく使うには、欲しい結果を説明するのが一番だよ。それだけ。彼らはタスクを完了させるように訓練されてるから、明確な結果の方がプロセスよりもずっといい。もしLLMが失敗したら、結果を十分に説明できてなかったか、言ったことを誤解されたか、そもそもできなかったか（これは稀だけど）。一般的なエラーは、今後の似たようなタスクのためのコンテキストとしてエンコードすべきで、必要ないものをスキルに詰め込むのはやめよう。

└

確かに多くのスキルは大げさで必要ないと思う。でも、AIに正しいプロセスを与えることには大きな価値があるよ。superpowersスキルを使うと、Claudeが中程度や大きな変更に対してどれだけ効果的になるか見てみて。

└

スキルって再利用可能で共有できるコンテキストに過ぎないよ。要するにテキストなんだ。APIの使い方に関するドキュメントみたいなものには役立つし（自分的にはMCPよりもこっちの方がいいと思う）、合意が得られてないやり方にも使えるよ。例えば、remotionを使って動画を生成することができる。特定のタイプの動画を確実に生成するための有用なremotionスキルもあるよ。特定のスタイルのキャプションとかね。

└

ソフトウェアエンジニアリングの数十年で学んだことがあるとしたら、「明確な結果」を説明するのは簡単じゃないってことだね。多くの場合、4つの異なるドメインの人たちが協力しないと不可能だよ。だからプロセスが重要なんだ。ソフトウェアを「半標準化された」方法で構築することを可能にして、期待される結果に近づくための反復を可能にするんだ。それは時間とともに現れるかもしれない。確かに、自分がLLMを使う目的は、同じレベルの曖昧さや複雑な要求があるわけじゃないけど、プロセスの一部をスキップすることで最適化するのが、まさにAddyがこの記事で話してることなんだよね。

└

LLMをうまく使うには、欲しい結果を説明するのが一番だよ。それだけ。彼らはタスクを完了させるために訓練されてるから、明確な結果を示す方がプロセスよりずっといい。複雑なことには当てはまらないけどね。彼らは指示に従う存在で、タスクの完了はその一面に過ぎない。情報が足りなくても、すごくやる気でタスクを完了しようとするけど、間違ったことをしちゃうこともある。タスクの完了をただ説明するだけだと、どんなに頑張っても見落としや、指定が不十分だったことに気づかないことがあるから、プロセスを追加するのが大事だよ。例えば、「関連するプロジェクトの慣習や情報を調べて、タスクをどうやって完了させるか考えて、あいまいな点を解決するために質問してね」とかね。こういうプロンプトは、新しいOpus 4.7の適応思考にも役立つから、タスクをちゃんと考えるようになるよ。

└

それはちょっと単純すぎる気がする。人間でも、何かを作ったりタスクを完了させたりするには、いろんな解釈や方法があるからね。エンジニアは覚えてくれるから、何度も同じことを繰り返さなくて済むんだ。スキルは、似たような繰り返しなしで結果を説明する方法だよ。

└

時々、人は自分が何を望んでいるのか分からないことがあるよね。私は小さく始めて、徐々に結果に近づくアプローチが好きなんだ。それから要約をお願いすることもあるし、その後に一般化を頼むこともあるよ。

Hacker Newsで議論の続きを見る

ハクソク