Agent Skills は、AI agent に “開発の手順そのもの” を覚えさせる仕組み。単なる説明文ではなく、実行できる workflow にしているのがポイントAddy Osmani の記事「Agent Skills」は、AI coding agent に対するかなり重要な問題意識から始まります。
それは、AI agent は“完成”までの最短経路を選びがちだということです。
たとえば「この機能を作って」と頼むと、agent はすぐにコードを書きます。
でも普通の開発で本当に大事なのは、コードを書くことだけではありません。
人間の senior engineer は、むしろこの「コード以外の仕事」のほうに価値があることを知っています。
著者は、AI agent がそこをすっ飛ばしてしまうのを問題視していて、その“省略されがちな仕事”を強制的に戻す仕組みとして Agent Skills を作ったわけです。
これ、かなり本質的だと思います。
AI は賢いというより、雑に終わらせるのがうまい。だからこそ、開発の“面倒だけど大事な部分”をルール化しないと、すぐに事故る。そんな危機感がこの文章全体に流れています。
Agent Skills って何なのかここでいう skill は、単なる「知識メモ」ではありません。
記事では、frontmatter 付きの markdown ファイルとして説明されています。必要なタイミングで agent の context に読み込まれ、決まった workflow を実行させるためのものです。
つまり、これは：
ではなく、
のような、手順書です。
この違いはかなり大きいです。
長い説明文は、読むと“わかった気”になります。でも実際には動かない。
一方で workflow は、「次に何をすべきか」が明確なので、agent が行動しやすい。
個人的には、ここが記事のいちばん鋭いポイントだと思いました。
AI 向けのルールは、つい「何を知っておくべきか」を書きたくなるんですが、本当に必要なのは「何をどう進めるか」なんですよね。人間でも同じです。
記事では、20個の skill が開発ライフサイクル（SDLC）に沿って整理されています。
SDLC は簡単に言うと、ソフトウェアを作って出すまでの一連の流れのことです。
大きくは次のような段階です。
/spec）/plan）/build）/test）/review）/ship）さらに code-simplify のように、全体を横断する skill もあるそうです。
著者はこれを、Google の公開されている engineering practice と重ねています。
たとえば Google では、ざっくり言えば
という流れがあります。
名前は違っても、やっていることはほぼ同じです。
ここでの主張は明快です。
AI agent は、普通なら必ず通すはずの工程を飛ばしてしまう。だから、その工程を skills として埋め込む必要がある。
これは納得感があります。
なぜなら、事故ってから「やっぱり spec が必要だったね」と言うのは、人間のチームでも何度も見てきた光景だからです。AI ならなおさら、です。
この記事で特にユニークなのが、anti-rationalization tables です。
日本語にすると少し堅いですが、要するに 「手抜きしたくなったときの言い訳集」と、その反論集 です。
たとえば、こんな感じです。
これ、かなりうまい設計だと思います。
なぜなら LLM は、もっともらしい言い訳を作るのが得意だからです。
「今回は小さい変更なので review は不要です」とか、
「このコードは見た目はシンプルだから tests は省略できます」とか、
そういう“それっぽい話”を、AI は普通に生成してしまう。
だからこそ、先に反論を書いておく。
これは AI 対策であると同時に、人間のチームにもそのまま効く話です。
正直、ここはかなり好きです。
開発現場の崩れ方って、派手な失敗よりも、こういう「今回は大丈夫でしょ」が積み重なって起きることが多いんですよね。
その意味で、anti-rationalization tables はかなり実戦的です。
記事では、設計の背骨になる5つの原則が挙げられています。
長文の説明より、実行可能な手順。
これは AI に限らず、人間にも効きます。
マニュアルが分厚いと誰も読まないけれど、短い workflow なら使われる、という話です。
言い訳を先回りして潰す。
これがかなり独創的です。
“人はだいたいこうサボる”を知っている設計は強い。
「なんとなく合ってそう」はダメ。
テスト、build、runtime の確認、レビューなど、証拠が必要だと強調しています。
最初から全部読み込まない。必要な skill だけを、その都度使う。
AI の context には限界があるので、これはかなり現実的です。
「頼まれた範囲だけを触る」。
これ、地味だけど本当に大事です。
AI は勢い余って、頼まれていない周辺まで直そうとしがちだからです。
個人的には、scope discipline が一番“人間のレビュー地獄”を減らす力を持っていると思います。
PR がでかくなりすぎると、レビューする気力が消える。これは人間でもAIでも同じです。
著者はこの記事で、Google の engineering practices をかなり参照しています。
名前が出てくるものをざっくり言い換えると、こんな感じです。
どれも古典的な考え方ですが、記事の重要な主張は、AI agent はこういう原則を自然には守らないという点です。
モデルは「それっぽい答え」を出せても、開発文化そのものを自動で運ぶわけではない。そこを技能として注入する必要がある、というわけです。
これはかなり鋭い見方だと思います。
AI を使うと、つい「賢いから開発も上手いはず」と思いたくなるんですが、実際には逆で、賢いからこそ雑に近道を選んでしまうことがある。そこをどう抑えるかが勝負なんですね。
記事では、使い方が3段階で紹介されています。
Claude Code を使っているなら、plugin として導入できるようです。
/spec、/plan、/build、/test、/review、/ship などの slash commands が使えるとのこと。
Cursor、Gemini CLI、Aider、Windsurf、OpenCode など、system prompt を扱えるツールなら使える、と説明されています。
要するに、ツールより workflow が本体という考え方です。
これが著者のおすすめでもあるようです。
つまり、実装しなくても「良い AI 開発とは何か」の参考文書として読める。
個人的には、この3つ目がいちばん価値ある読み方だと思います。
ツールは流行で変わるけれど、良い開発習慣はあまり変わらないからです。
この話、実は AI agent の話に見えて、かなり広く使えます。
著者自身も、以下のようなパターンをチーム文化として取り入れられると言っています。
これって、普通の開発チームの品質改善そのものです。
AI がいようがいまいが、人間は都合のいい理屈で手を抜きがちなので、先に仕組みを作る価値があります。
個人的には、ここがこの記事の真の価値だと思いました。
表向きは「AI agent の skill 設計」ですが、実際には “どうすれば開発はちゃんとするのか” という普遍的な問いに答えようとしている。だから読んでいて面白いし、応用範囲も広いです。
Addy Osmani の「Agent Skills」は、AI coding agent をただ便利にする話ではありません。
むしろ、AI に“開発者としての振る舞い”を覚えさせるにはどうすればいいかを、かなり具体的に示した記事です。
特に印象的だったのは、次の2点です。
だから、必要なのは派手な魔法ではなく、
といった、地味だけど強い習慣です。
AI 時代のソフトウェア開発って、何かが全然新しくなるというより、昔から大事だったことを、もっとサボれない形で再実装する仕事なのかもしれません。
この記事は、その感覚をうまく言語化していると思います。
参考: Agent Skills