AIコーディングの作法はどう変わってきたか──バイブコーディングから仕様駆動、そしてSkillsへ¶
対象: AIコーディングツールを日常的に使っている開発者
この記事のポイント¶
18ヶ月で4段階の変遷
バイブコーディング → 仕様駆動 → CLAUDE.md → Skills
仕様駆動の功罪
Kiroは正しかったが重い。小〜中規模タスクでオーバーヘッドが逆転した
Skillsの本質
コード生成品質の競争からナレッジ構造化の競争への転換
2025年から2026年にかけて、AIを使った開発の「正しいやり方」は目まぐるしく変わった。最初は「とにかく作らせればいい」だった。次に「ちゃんと仕様を書いてから作らせよう」になった。そして今、また揺り戻しが来ている。
この記事では、AIコーディングの作法がどう変遷してきたかを振り返りながら、今どこにいて、何が論点として残っているのかを整理してみたい。
バイブコーディングの時代──「作って」で作れた、でも壊れた¶
始まりはシンプルだった。「電卓を作ってください」と言えば電卓ができる。ChatGPTやClaude、Cursorといったツールの進化で、コードを書かなくてもアプリが出来上がる世界が現実になった。いわゆる「バイブコーディング」の時代だ。
問題は、その次に起きた。
「じゃあ関数電卓の機能もつけてください」と言った瞬間、さっき作ったコードが全部作り直しになる。なぜかというと、最初の電卓は「最短距離で動くコード」として生成されているから。将来の拡張なんて考慮されていない。演算子の優先順位を扱うAST（抽象構文木）もなければ、演算を抽象化するインターフェースもない。追加要求のたびに、コードはスパゲッティ化していく。
これはAIが悪いわけではない。「電卓を作って」という指示には「将来こういう拡張をする予定です」という情報が含まれていないのだから、AIはその場で成立する最短の実装を返す。当然の振る舞いだ。
もうひとつ厄介だったのは、要求変更が「差分」ではなく「矛盾」としてコードに残ることだった。「やっぱりこうして」「前のは忘れて」を繰り返すと、人間の開発者なら暗黙的に古い仕様を無視できるが、AIはコンテキスト内の矛盾を律儀に埋めようとする。結果として例外処理、条件分岐、フラグが増殖し、誰にも読めないコードが出来上がる。
仕様駆動の揺り戻し──Kiroの登場と「まず要件を決めましょう」¶
この問題に対する回答として登場したのが、AWS発のコーディングエージェント「Kiro」だった。2025年7月にプレビュー公開されたこのツールは「Spec-Driven Development（仕様駆動開発）」を前面に打ち出した。
思想はシンプルだ。いきなりコードを書かせるのではなく、まず3つの成果物を作る。Requirements（要件定義）、Design（設計ドキュメント）、Tasks（タスク分解とテスト計画）。電卓を作るなら、「今後どういう機能を拡張する予定か」「どんなテストケースが必要か」を先にAIと一緒に整理してから開発に入る。バイブコーディングの失敗を「構造化で解決しよう」というアプローチだった。
なお、Kiro自体はバイブコーディングモードとspec-drivenモードの両方を提供しており、起動時に「Vibe or Spec?」と選択肢が表示される。仕様駆動を強制するのではなく、プロトタイピングから段階的に仕様化へ移行できる設計だ。アジャイルとウォーターフォール双方の視点を持つこの柔軟性は評価に値する。
Kiroが突きつけた仕様駆動の課題¶
では、仕様駆動アプローチそのものはどう受け止められたのか。
報道によれば、Amazon側は「2026年1月時点でソフトウェアエンジニアの約70%が少なくとも1回はKiroを使用した」と述べている。ただしこの数字は、社内ツールとしてデフォルトに近い形で展開されていることを考えると、「普及」よりも「露出」の指標と見るべきだろう。1回使った人の継続率がどの程度かは明らかにされていない。
一方、2026年2月のBusiness Insiderの報道では、Amazon社内フォーラムで約1,500人のエンジニアがClaude Codeの正式採用を支持する声を上げたという。Amazonのエンジニア総数は数万人規模とされるから、1,500人は少数派と見ることもできるし、社内フォーラムでわざわざ声を上げるほどの不満の強さと見ることもできる。数字だけでは判断できないが、少なくとも「全社的にKiroで満足している」とは言い難い空気があった。
社外でも同様のフィードバックがあった。Hacker Newsでは「小さなヘルパーツールを作りたかっただけなのに、仕様駆動のワークフローが開発を遅くした」という報告が上がり、InfoQの記事でもspec-drivenアプローチの重さに対する不満が取り上げられた。仕様書とコードとプロンプトの使い分けは、開発現場の中心的な論点になっていた。
この反応が示しているのは、「仕様駆動がダメだった」ということではない。むしろ、仕様を作る工程と開発を実行する工程が分離していることへの摩擦だ。Requirements → Design → Tasks というファイルを作成し、それに基づいて開発するという二段構えのワークフローは、エージェントの速度感と噛み合わないケースがあった。特に小〜中規模のタスクでは、仕様策定のオーバーヘッドが実装そのものより重くなる逆転現象が起きる。
仕様を書く行為そのものが悪いのではない。「いつ、どの粒度で仕様を書くか」が問題だった。
計画と実行が溶け合う──Claude CodeのPlanとCLAUDE.md¶
ここから、仕様駆動の「思想は正しいが、やり方が重い」という課題に対して、別のアプローチが台頭してくる。
ほぼ同時期の2025年6月頃、Claude CodeにはPlan機能が搭載された。Shift+Tabで切り替えるこのモードは、読み取り専用の環境でコードベースを分析し、計画を立て、ユーザーの承認を得てから実装に移るという流れを提供する。Kiroとの違いは、計画と実行が同一のコンテキスト内で連続する点だ。「こういう方針で進めます」→承認→実装が一息で行われる。独立したファイルに仕様を書き出す必要がない。
もちろん、Plan機能は網羅的な仕様書を生成するわけではないので、大規模プロジェクトや複数チーム間の合意形成にはKiroのようなドキュメント生成型のほうが適している。万能ではないが、「仕様の重さ」を開発フロー内で吸収するという発想は新しかった。
そしてもうひとつ、同じ文脈で注目すべき動きがあった。CLAUDE.mdやCursorの.cursorrulesのような「プロジェクトルールファイル」の台頭だ。
これらは仕様書でもなければ、プロンプトでもない。プロジェクトのルート直下に置かれた、AIへの「前提共有」ファイルだ。コーディング規約、アーキテクチャの方針、使っていいライブラリ、避けるべきパターン。要するに、人間のチームメンバーにオンボーディングで伝えるような情報を、AIにも渡す。
Kiroとの決定的な違いは、このファイルが「開発の外側」ではなく「開発の内側」にあることだ。コードと同じリポジトリに、同じバージョン管理の下で存在し、AIはそれを毎回のコンテキストとして自動的に読み込む。開発者が意識的に「読み込ませる」必要がない。
これは仕様駆動の思想を捨てたわけではない。むしろ、仕様を「ドキュメント」から「環境」に変えたと言える。仕様を書くのではなく、仕様の中で開発する。CLAUDE.mdの書き方ひとつでエージェントの出力品質が劇的に変わるのは、この仕組みが効いているからだ。
Skillsの爆発──「プロジェクトのルール」から「仕事の型」へ¶
CLAUDE.mdが「プロジェクト全体のルール」だとすれば、その発展形として今急速に広がっているのが「Skills」だ。
Skillsとは、特定のタスクに対する手順・ベストプラクティス・成果物のテンプレートをまとめたものだ。Word文書の生成ルール、PowerPointのレイアウト規約、PDF処理の手順、スプレッドシートのフォーマット基準──それぞれが独立したSkillファイルとして管理され、AIはタスクに応じて必要なものだけを読み込んで、そのレシピ通りに動く。
CLAUDE.mdとの使い分けはこう考えるとわかりやすい。CLAUDE.mdは「チームの憲法」だ。「TypeScriptを使う」「テストはvitestで書く」「APIエラーはRFC 7807準拠」といったプロジェクト横断の方針を定める。一方、Skillsは「業務マニュアル」だ。「PowerPointを作るならpython-pptxで16:9、フォント最低14pt」のように、特定タスクを再現可能にする手順を定める。
ひとつのCLAUDE.mdにすべてを詰め込むと肥大化してノイズになる。Skillsはこの問題を「タスク単位で分割された知識ベース」として解決する。プログラミングで言えば、モノリシックな設定ファイルをモジュール化したようなものだ。
これが面白いのは、コーディングに限定されない点だ。ドキュメント生成、データ分析、スプレッドシート作成、PDF処理──プログラミングとは直接関係ないタスクにもSkillsは適用される。「AIコーディングの作法」だったものが、「AIに仕事をさせる作法」へと領域を広げている。
Skillsが解決するナレッジの問題¶
もうひとつ重要なのは、Skillsが「チームの暗黙知を形式知に変える装置」として機能し始めていることだ。ベテランエンジニアが「うちのプロジェクトではこうやるんだよ」と後輩に教えていたノウハウを、Skillファイルとして書き下ろす。するとAIがそのノウハウを再現できるようになる。属人的だった技術が、チーム資産になる。
これは見方を変えれば、ナレッジマネジメントの問題がAIコーディングの文脈で再発見されたとも言える。Confluenceに書いても誰も読まなかったドキュメントが、Skillsとして書けばAIが確実に読んで実行してくれる。皮肉な話だが、ドキュメントの「読み手」がAIになったことで、ドキュメントを書くインセンティブが初めて機能し始めている。
現在地──選択肢は増えた、でも解決していない問題がある¶
ここまでの流れを整理すると、AIへの指示方法は一方向に「進化」してきたというより、選択肢が増えてきたと見るほうが正確だ。
| フェーズ | アプローチ | 適した場面 |
|---|---|---|
| バイブコーディング | 指示なし。AIが自由に判断 | プロトタイプや小規模ツール |
| 仕様駆動（Kiro） | 事前に網羅的な仕様を作成 | 大規模プロジェクト、合意形成が必要な場面 |
| ルールファイル（CLAUDE.md） | プロジェクト方針をコードと共に管理 | 中規模の継続的開発 |
| Skills | タスク別手順をモジュール化 | 反復的タスクの品質安定化 |
つまり「何も教えない」から「全部教える」に振れた振り子が、「必要なことを、必要なタイミングで教える」に落ち着きつつある。これはソフトウェア設計で言うところの「関心の分離」そのものだ。
ただし、この収束の中でも解決していない論点がある。しかもそれらはレイヤーの異なる問題であり、単一のアプローチでは対処できない。
技術的制約：コンテキストの上限問題。 AIが扱えるコンテキストウィンドウは拡大し続けている──Claude Opus 4.6は条件付きで100万トークンに到達した。それでもプロジェクト全体を一度に把握させることはできない。大規模なコードベースでは「AIにどの範囲を見せるか」という判断自体が、新たなスキルとして求められている。Skillsのモジュール化はこの制約への現実的な対応だが、根本的な解決には至っていない。
方法論の課題：テストとの関係。 AIが書いたコードをAIがテストする。この構造には同じモデルが同じ盲点を共有するという根本的な問題がある。人間がテストケースの「意図」を定義し、AIが実装するというパターンが主流になりつつあるが、まだ発展途上だ。「テストの意図を定義するSkill」と「テストを実装するSkill」を分離し、異なるモデルに担当させるといったアプローチが今後試みられるかもしれない。
組織・文化の課題：「直せない問題」の深刻化。 バイブコーディングで作ったプロトタイプが、そのまま本番に残るケースが増えている。動いているから直さない。しかし誰もコードの中身を理解していない。このまま規模が拡大すれば、「AIが作ったレガシーコード」という新しいカテゴリの技術的負債が生まれる。これは作法やツールでは解決できない──組織としてどう向き合うかの問題だ。
この3つは独立した課題に見えるが、根は繋がっている。コンテキストの制約があるからこそAIは全体像を見落とし、全体像を見落とすからこそテストに穴が生まれ、テストに穴があるからこそ「動いているから触れない」コードが蓄積する。レイヤーが違うだけで、構造は連鎖している。
この先に見えるもの¶
Skillsの自動生成はすでに始まっている。Anthropic公式のskillsリポジトリにはskill-creatorというSkillが提供されており、「このタスク用のSkillを作って」と指示すればSkillファイルそのものをAIが生成してくれる。コミュニティでもSkillの共有・流通が進みつつある。
次のステップとして見えているのは二つある。ひとつは、開発者とAIの協働履歴からSkillが自動的に抽出・蓄積される世界だ。「先週あなたがやったデプロイ作業、Skillにまとめておきました」とAIが提案してくる。ナレッジの蓄積が開発の副産物として自然に起きるようになる。
もうひとつは、Skills同士の組み合わせ最適化だ。「フロントエンドのSkill」と「テストのSkill」と「デプロイのSkill」を連鎖的に適用して、ひとつの機能追加を端から端まで一気に実行する。個別のタスク自動化から、ワークフロー全体の自動化への移行だ。
しかし、ここで楽観的すぎる未来を描く前に立ち止まるべき問いがある。Skillsが蓄積され、当たり前のインフラになったとき、次に来る問題は何か。
おそらく「Skillの腐敗」だ。ライブラリがアップデートされ、アーキテクチャが変わり、チームの方針が変わる。しかしSkillファイルは放置される。実態と乖離したSkillをAIが律儀に守り続け、かえって品質を下げる。ドキュメントの陳腐化という古典的な問題が、AIが忠実に従うからこそ、より深刻な形で再来する。
あるいは「Skill同士の矛盾」。セキュリティのSkillが「すべての入力をサニタイズせよ」と言い、パフォーマンスのSkillが「不要な処理を挟むな」と言う。人間なら文脈で優先順位を判断できるが、AIにとってこれは解決困難なコンフリクトになりうる。Skillsが増えるほど、矛盾の管理コストも増える。
結局のところ、Skillsもまた銀の弾丸ではない。問題を一段階抽象化しただけであり、「知識をどう管理するか」という根本的な課題は形を変えて残り続ける。
まとめ──作法は変わり続ける、でも原則は変わらない¶
バイブコーディング → 仕様駆動 → ルールファイル → Skills。この流れを振り返ると、結局のところ古典的なソフトウェア工学の教訓が形を変えて繰り返されていることに気づく。
「何を作るか決めてから作れ」──これはウォーターフォールの時代から言われてきたことだ。アジャイルはそれを「小さく決めて小さく作れ」に変えた。AIコーディングの文脈では、それがさらに「方針を共有して、判断はAIに委ねろ」に進化しつつある。そしてSkillsは、「共有すべき方針を、再利用可能な形で蓄積しろ」というその次のステップだ。
変わったのは手段であって、原則ではない。そしておそらく、次に来る変化もまた、この原則の別の表現形になるだろう。
ツールは変わる。作法も変わる。でも「意図を明確にしたほうが良いものができる」という、当たり前すぎる事実だけは変わらない。AIコーディングの進化は、その「当たり前」をどこまで自動化・省力化できるかの挑戦だと言い換えてもいいかもしれない。