AIネイティブSDLCとは？作る速さが競争力にならない理由
この記事の概要
| 項目 | 内容 |
|---|---|
| 対象読者 | 従業員5〜100名の中小企業経営者、開発チームのリーダー |
| 対象テーマ | AIネイティブSDLCの中身と、中小企業での実践方法 |
| 想定読了時間 | 約10分 |
| 最終更新 | 2026年8月29日 |
| 出典基準 | Anthropic公式手引きと公開リポジトリを一次ソースとして確認。個人の生産量に関する数値は本人の公開情報に基づく自己申告値であり、一次記事が有料のため未確認である点を本文で明示 |
AIを入れたのに、なぜ速くならないのか
AIコーディングツールを導入したのに、開発のリードタイムが思ったほど縮まらない。 この相談が増えています。
原因を道具の性能に求めると、行き止まりになります。 実際に起きているのは、速くなった工程と、速くならなかった工程が同じ流れの中に同居している状態です。
Anthropicが公開した手引き「The AI-Native SDLC playbook」は、この状態を一文で説明しています[1]。
Build is no longer the constraint — the human-speed steps around it are.
（作ることはもう制約ではない。制約は、その周りにある人間の速さの工程だ）
同じ手引きには「Code is no longer the bottleneck」という見出しも置かれています[1]。
図1：作る工程だけが縮み、周囲の工程は縮まない。制約の位置が移動する
作る工程が数時間で終わるようになった一方、要件を決める会議、レビュー待ち、承認は数週間のまま残ります。 その差が、導入効果を打ち消しています。
| 観点 | 従来のSDLC | AIネイティブSDLC |
|---|---|---|
| 実装にかかる時間 | 数日から数週間 | 数時間 |
| 律速となる工程 | Build（実装） | Buildの前後にある人間の判断 |
| 会議と承認の設計 | 実装に数週間かかる前提 | 実装が数時間で終わる前提 |
| 改善の打ち手 | 実装を速くする | 判断を速く、かつ記録に残す |
この前提でSDLC（企画から運用までの開発工程）を組み直す考え方に、AIネイティブSDLCという名前が付いています。
中身は、文書のバトンリレー
進め方の中身は地味です。 各工程の終わりに、次の工程が読める文書を1枚残す。 これが骨格になります。
図2：文書を1枚ずつ受け渡し、そのつど人が承認する。運用で見つかった問題は最初に戻る
Anthropicの手引きでは、工程と成果物が次のように対応づけられています[1]。
| 文書 | 対応する工程 | 何を書くか | 主な書き手 |
|---|---|---|---|
| intent.md | Plan | 困りごと、望む結果、制約、「できた」と言える基準 | 発案者がAIと対話しながら |
| spec.md | Design | やることとやらないことの線引き | intentと社内規約を読んだAI |
| plan.md | Build | 変更する箇所、作業の順番、リスク、完成の証明方法 | specを読んだAI |
Build工程では、プロジェクト固有の規約を書いたCLAUDE.mdも併せて参照されます[1]。
それぞれの文書を人が承認して、はじめて次の工程に進みます。 承認の履歴はGit（変更管理システム）に残るため、誰がいつ何を決めたかを後から追えます。 運用中に見つかった問題は新しいintentになり、最初の工程へ戻ります。 一直線だった工程が、ループになります。
経営の観点で見ると、この進め方はAIへの丸投げの逆に位置します。 作業はAIに任せますが、次の判断はすべて人間の側に残ります。
| 段階 | 人間が下す判断 |
|---|---|
| intent承認 | この案件に着手するか |
| spec承認 | この範囲と、やらないことの線引きでよいか |
| plan承認 | この段取りで作らせてよいか |
| リリース判断 | 本番に出してよいか |
速くなるにもかかわらず、統制はむしろ効きやすくなる。 稟議書が増えるのではなく、判断の記録が作業の副産物として残る形です。
品質はどう守るのか
工程を速く回すほど、品質への不安は大きくなります。
この問いに対して、Cursorのエンジニアである Lauren Tan は「Agent Trust Curve」という考え方を示しています[3]。 AIをどこまで信頼するかは気持ちで決めるものではなく、検証の仕組みがどこまで整っているかで決まる、というものです。
図3：任せる範囲は、検証の仕組みが整った分だけ上がる。自動マージは最後に置かれる
順番があります。
| 段階 | やること | 次の段へ進む条件 |
|---|---|---|
| 1. 自己検証 | コードを書かせるだけでなく、アプリを起動させ画面を操作させ、実行結果やスクリーンショットという証拠を提出させてから人に見せる | 証拠が毎回そろって出てくる |
| 2. 並列化 | 同時に走らせる本数を増やす | 本数を増やしても品質が落ちない |
| 3. 範囲拡大 | 自動化する工程を広げる | 数値が安定して推移する |
| 4. 自動マージ | 人の確認を挟まずに本番へ取り込む | 曲線のいちばん最後に置く |
彼女が公開しているスキル集「pstack」には、この考え方が具体的な形で入っています[2]。 45本のスキルがMITライセンスで公開されており、誰でも中身を読めます。
もう一つ、運用として参考になる仕組みがあります。 AIが失敗したとき、その場で直して終わりにしない。 なぜ失敗したかを検討し、再発防止をルールとして書き残し、以後すべてのAIに配る。 同じ失敗が二度続いたら、ルールの文章を足すのではなく、機械的に止まる自動チェックに変える。 文字の注意書きは読み飛ばされることがあっても、自動チェックはAIの世代が変わっても働き続けるからです。
不良が出たときに作業者を責めるのではなく工程を直す、という製造業の発想と同じ形をしています。
一過性で終わらないと考える3つの理由
| 理由 | 根拠 |
|---|---|
| 必要な機能が標準装備 | 計画だけを立てるモード、規約を記憶させるファイル、AIによる事前レビューは主要ツールに搭載済み |
| 再現の材料が公開済み | pstackがMITライセンスで公開され、実物を読める[2] |
| 開発以外にも同じ型が効く | 提案資料、業務フロー改善、社内規程の改定にも転用できる |
第一に、必要な機能がすでに標準装備になっています。 実装前に計画だけを立てるモード、プロジェクトの決まりごとを記憶させるファイル、AIによる事前レビュー。 これらはClaude CodeやCursorといった主要なAIコーディングツールに最初から入っています。 特別な製品を買い足す話ではなく、手元の道具の使い方の話です。
第二に、先行者が再現の材料を公開しています。 pstackはGitHubのcursor/pluginsリポジトリで公開されており、MITライセンスのため商用利用も可能です[2]。 考え方の説明だけでなく実物が揃っている手法は、広がるのが速くなります。
第三に、開発以外の仕事にも同じ型が効きます。 先に意図を文書にする。 工程ごとに文書を残す。 「できた」の基準を先に決めて、感想ではなく基準で判定する。 この3点は提案資料の作成にも、業務フローの改善にも、社内規程の改定にも使えます。
実務で回してみて、いちばん効いたのは3枚目ではなく1枚目のintentでした。 AIは作業の途中で、最初の意図から少しずつずれていきます。 意図が文書で残っていれば、出来上がりを「最初に何がしたかったか」と見比べられます。 残っていなければ、「まあ、良さそう」としか言えません。 この差は、案件を重ねるほど開いていきます。
中小企業にこそ向いている
大企業向けの話に見えるかもしれませんが、実際は逆だと考えています。
| 観点 | 大企業 | 中小企業 |
|---|---|---|
| 承認の経路 | 委員会の日程調整に時間がかかる | 経営者と現場リーダーの2人で完結する |
| 導入までの期間 | 制度設計と合意形成が先に必要 | 次の案件から試せる |
| 文書が果たす役割 | 部門間の引き継ぎ | 兼務者にとって未来の自分への引き継ぎ書 |
| 属人化への備え | 交代要員を確保できる | 文書が唯一の備えになる |
第一に、承認の経路が短いためです。 intentからplanまでの承認者が経営者と現場リーダーの2人だけという会社であれば、この型は来週から回せます。 大企業が委員会の日程調整に使う時間を、そのまま省略できます。
第二に、兼務が多い会社ほど文書の型が効きます。 1人で企画も発注も検収も担当している場合、3枚の文書は未来の自分への引き継ぎ書になります。 担当者が退職しても、なぜその仕様にしたかが文書として残る。 属人化への備えとしても働きます。
費用については、一点だけ注意があります。 Lauren Tan はAI企業に所属しており、利用料をほぼ気にせず使える立場にあります。 同じ物量を再現する必要はありません。 考え方だけを借りて、エンジニアを1人採用する費用と、AIが良い仕事をできる環境を整える費用を比べるのが実態に合います。 検証の仕組みは一度作れば以後のすべての案件で使い回せるため、月々の利用料単価ではなく投資として見る対象です。
明日から始める3ステップ
大がかりな導入プロジェクトは要りません。
| 手順 | やること | 所要時間の目安 |
|---|---|---|
| 1 | AIに作らせる前にintentを書く。困りごと、望む結果、制約、「できた」の基準の4項目 | 10分 |
| 2 | intent、spec、planの3枚を残し、履歴が残る場所に置く。Gitでも共有フォルダでも構わない | 案件ごとに随時 |
| 3 | 「できた」の基準を先に決め、出来上がりはintentと見比べて判定する | 検収時 |
ありがちなつまずきも挙げておきます。
| つまずき | 何が起きるか | 処方 |
|---|---|---|
| とりあえず作らせて、出てきたものを見てから考える | 判定の基準がないため、手戻りが続く | intentに「できた」の基準を先に書く |
| 「あのサービスと同じものを」とだけ依頼する | なぜ作るか、どう売るかが決まらないまま完成する | intentに困りごとと望む結果を書く |
| AIと会話して満足し、意図を保存しない | 完成しても良し悪しを判定できない | 会話の結論をintentとして残す |
いずれも、intentを1枚書くだけで防げます。
まとめ
AIネイティブSDLCが広がると考える理由は、AIの性能ではありません。 人の判断を全部残したまま速くなる、という設計思想にあります。 経営者にとっては統制の話であり、開発者にとっては手戻りの話であり、どちらの立場から見ても損のない変更です。
まずは次の案件で、intentを1枚書くところから試してみてください。
AIに任せる範囲の決め方については、AIエージェントに任せられる仕事の4条件とループ設計で、任せられる仕事の見分け方を整理しています。 導入の伴走が必要な場合は、Claude Code 導入支援をご覧ください。
出典
- Anthropic「The AI-Native SDLC playbook」 claude.com/blog/the-ai-native-sdlc-playbook （2026年8月29日確認）
- pstack（cursor/plugins、MITライセンス） github.com/cursor/plugins （2026年8月29日確認）
- Lauren Tan（@poteto）の公開情報。「Agent Trust Curve」は本人の公開発信に基づく概念です。出典にあたる本人の記事は有料公開のため、本稿では内容を直接確認できていません
注記：本記事のうち公式資料に基づく記述は、工程と成果物の対応（intent.md / spec.md / plan.md）および引用文で、いずれも出典1によります。pstackの構成とライセンスは出典2のリポジトリで確認しました。「Agent Trust Curve」の運用手順と、中小企業への適用に関する記述は、かなうテック（屋号：Kanau Tech™）が実務で用いている整理と判断であり、公式に定義された方法論ではありません。図1から図3は本記事のために作成した概念図です。ツールの機能は変更されうるため、導入前に各公式ドキュメントでご確認ください。