1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@aktsmm(やまぱん！)

まだ仕様になっていない困りごとを残す。intent.md から始める AI-native SDLC

1
Posted at

こんにちは、実装は速いのにレビュー待ちで一日が終わるアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

この記事は 2026/09/14 時点の公式情報です。きっかけは Anthropic の The AI-native SDLC playbook（Louis Claxton、2026/08/21）です。playbook は Anthropic の Applied AI チームの実践をまとめたもの、と原文にあります（著者の肩書きは LinkedIn では Member of Technical Staff）。

全訳ではなく、コーディングエージェントをすでに使っている人向けの読み解きです。一部機能は beta / research preview です。

Claude Code でも GitHub Copilot でも Codex でも、実装そのものは速くなりました。なのに開発全体は、同じ速度では進まない。その違和感を、長い公式 playbook が先に書いています。

タイトルにある intent.md は、仕様を書く前に「誰が、何に困っていて、どうなればよいか、どんな制約があるか」を残す短い文書です。エンジニア向けの実装指示ではなく、まだ仕様になっていない意図を次の担当者と AI に渡します。

TL;DR

  • 実装は時間単位まで縮み、計画・レビュー・デプロイが人間速度のまま残る。行単位の人手レビューはもう追いつかない
  • 各ステージは次が読める成果物を Git に残す。人はゲートで判断する
  • Spec Kit / Kiro の SDD と前半はほぼ同じ。違うのはリリースと運用まで入っていること
  • 知識を CLAUDE.md / skill / eval に置くと、モデルを替えても学びを失いにくくできる（Satya Nadella 氏の learning loop と重なる点）
  • Jira や変更管理は捨てない。成果物ごとに正本を 1 つ決める
  • 最初に置くのは 6 ステージ全部ではなく、意図・作業手順・検証・承認ゲート

何が変わったか

従来のソフトウェア開発ライフサイクル（以降は SDLC）は、コードを書くことが一番高くて遅かった前提で組まれています。要件定義、見積もり、セキュリティレビューは、「何週間もかかる実装」のあいだに揃えるための装置でした。

原文の主張はこうです。エージェントが実装を時間単位まで縮めたあと、ボトルネックは左右へ移る。計画、レビュー、テスト、デプロイです。ここが人間速度のままだと、実装が速くなっても開発全体は速くなりません。

セキュリティを例にします。レビューチームの人数は人間の出力に合わせて決まっています。エージェントが差分を何倍にもすると、キューが伸びるか、レビュー不足のまま出すかの二択になります。規制のある組織はどちらも取れません。だから実装だけでなく、左右の工程もエージェント前提に組み直す、というのが playbook の出発点です。

人を外す話ではありません。判断が要る決定の責任は人に残ります。人が見る対象が、全部の行から成果物とゲートに移るだけです。

実装だけが縮み、計画・レビュー・デプロイが人間速度のまま残る図

6 ステージを「成果物のリレー」として読む

原文は 6 つのステージを置きます。Plan / Design / Build / Test / Deploy / Maintain です。

ステージ名は覚えなくていいです。仕組みは 1 行で済みます。各ステージは成果物を 1 つ Git に置いて終わり、次のステージはそれを読んで始まる。これだけです。

6 つのステージが intent.md、spec.md、plan.md、テスト結果、PR、インシデント記録という成果物でつながり、最後の Maintain から次の intent.md として Plan へ戻るループ図

役割分担まで開くと、こうなります。AI は成果物の作成と機械的な確認を進め、人は意図・例外・リスクを判断します。

ステージ AI がすること 人がすること 次へ渡すもの
Plan 会話から問題、期待する結果、制約、未決事項を整理し、intent.md の下書きを作る 言い出した人が背景を説明して誤解を直し、プロダクトオーナーが採用するか決める 承認済み intent.md
Design intent.md と組織の方針を読み、要件と設計を spec.md にまとめ、矛盾や懸念を挙げる プロダクトオーナーが意図とのずれを直し、必要ならセキュリティや UX の責任者と懸念を解消して承認する 承認済み spec.md
Build intent.md と spec.md から変更箇所、順序、リスク、テストを含む plan.md を作り、承認後に実装する エンジニアが計画を問い直して修正し、通常変更を承認する。高リスク変更はテックリードも確認する plan.md、コード差分、テスト
Test テスト、ビルド、lint、必要なら画面比較を繰り返し、失敗を直す。エージェント設定の変更には eval も回す エンジニアが合格条件を先に決め、コードオーナーがテストを弱めていないかと証拠を確認する テスト結果、ビルドログ、画面差分
Deploy spec.md、plan.md、テスト結果に照らして PR をレビューし、指摘への修正や CI の失敗原因調査を進める コードオーナーが意図とリスクを確認し、リリース責任者が本番投入を承認する 承認済み PR、レビュー・リリース記録
Maintain 監視のしきい値超過やチケットを受けて診断し、小さな修正は PR を提案し、大きな問題は次の intent.md として起票する サービスオーナーやオンコール担当が、今直す、後で直す、棄却するを判断する インシデント記録、PR、次の intent.md

ここで人が毎回ゼロから資料を書くわけではありません。AI が作った成果物を、人がそのステージの責任に合わせて直し、通すか止めるかを決めます。一方、テストや監視のしきい値のように機械で判定できる部分は、人の感覚ではなくコードに寄せます。

前半 3 つは Markdown です。

  • intent.md — やりたいことを、言い出した人の言葉で書いたもの。困っていること、よくなった状態、影響範囲、制約、未決
  • spec.md — その意図から起こした要件と設計。方針どうしが矛盾するなら、ここで表に出す
  • plan.md — 実装計画。変えるファイル、作業の順番、何をもって証明するか

Build から先は、コードとその記録が成果物になります。Build はコード差分、Test はテスト結果、Deploy は承認の付いた PR とレビュー記録、Maintain はインシデント記録です。

前半が Markdown なのは、プロダクトオーナーもエージェントも同じファイルを読めるからです。仕様を見るために別のツールを開かなくていい。

そして最後が最初に戻ります。本番で異常を検知したら、それが次の intent.md になる。だから原文はこれを工程表ではなくループと呼びます。agentic SDLC や AI SDLC と呼ばれているものも、同じ動きの別名だと書いてあります。

チェーンが残ると、コミット列がそのまま監査証跡になります。誰が頼んで、エージェントが何を出して、誰が承認したか。

なお intent.md も spec.md も plan.md も、Claude Code の必須ファイルではありません。playbook が提案している運用上の置き方です。

「これ SDD と同じでは？」に先に答える

ここまでで、GitHub Spec Kit や Kiro を触ったことがある人はこう思うはずです。それ Spec-Driven Development（SDD）では？

どちらも、実装の前に仕様・設計・タスクを作らせる、AI コーディング向けの SDD 系ツールです。

半分は同じです。

観点 GitHub Spec Kit Kiro AI-native SDLC playbook
実装前に文章を固める /speckit.specify → /speckit.plan → /speckit.tasks requirements.md → design.md → tasks.md intent.md → spec.md → plan.md
置き場所 specs/<feature>/ .kiro/specs/ リポジトリの成果物チェーン
人のレビュー フェーズごとに確認 フェーズごとに承認 ステージごとのゲート
本番の結果を次へ戻すか 仕様へ反映すると methodology に記載 spec 単位が中心 Maintain が次の intent.md を書く

「what と why を先に書き、how を分けて、Git に置き、人が確認する」。実装前半の考え方は、この 3 つでほぼ同じことを言っています。成果物チェーンを見て SDD を連想するのは、正しい反応です。

違うのはスコープです。

  • Spec Kit と Kiro は、機能や修正 1 個を作り切るワークフロー。コマンドとテンプレートがあり、tasks.md まで落ちたら実装に入ります
  • playbook は組織のプロセス。Deploy と Maintain、つまり承認ゲート、本番リリース、インシデント対応、定期スキャンまでが 6 ステージに入っています

大きな違いは、仕様の前に intent.md があること

Spec Kit の /speckit.specify も、自然言語で説明した機能から spec.md を作れます。ただし、中心的な成果物として独立した intent.md はありません。

playbook は spec.md の手前に、エンジニアではない人が自分の言葉で書く 1 枚を置きました。困っていること、よくなった状態、影響を受ける人やシステム、制約、まだ答えが出ていない質問を intent.md に残します。プロダクトオーナーは、それを仕様へ進めるか、ここで止めるかを判断します。

大きいのは、AI が自然言語を読めることではありません。まだ仕様になっていない困りごと自体を、レビュー可能な成果物として残すことです。従来なら、言い出した人の話をプロダクト担当が聞き、チケットやユーザーストーリーへ書き直していました。intent.md があれば、元の問題意識を次の担当者とエージェントが同じ場所から読めます。

ひとつ注意があります。原文は自分を SDD と呼んでいません。取得した本文に spec-driven development という語は出てきませんでした（2026/09/14 時点）。呼び名は AI-native SDLC、または agentic SDLC です。SDD の一種として読むかどうかは、読み手の整理になります。私は「SDD の考え方を、リリースと運用まで伸ばしたもの」として読みました。

現場で回らないところ

ただし、呼び名を整理しても、導入で詰まる場所は別にあります。原文も「レガシーを捨てろ」とは書いていません。詰まるのは、だいたい次の 4 箇所です。

正本が二つある

既存の SDLC は、すでに成果物を持っています。作業項目は Jira、要件はトレーサビリティ付きのツール、デザインは Figma、変更承認は変更管理です。監査がそこを正本にしているなら、Markdown だけ増やしても回りません。

原文の最低ラインは、成果物ごとに正本を 1 つ決めることです。リポジトリを正本にしてレガシー側はコミットへのリンクでもよい。Jira を正本にして Markdown は作業コピーでもよい。移行の最初は、レコード ID とコミット SHA を相互に書く「紐づけ」でもよい、とあります。怖いのは、どちらが正本か決まっていない状態です。

レビューが行単位のまま

実装が速くなると、最初に壊れるのはレビューです。人が差分の全行を読む前提は、人間が書いていた時代のものです。原文は、エージェントによるレビューを先に走らせ、人は意図とリスクを見る、と書きます。書いたエージェントが自分の PR を承認できない、という分離も残します。

skill は助言、必須は hook か CI

組織の方針を skill に書くのは有効です。ただし skill は助言です。セッションが必ず従う保証はありません。例外なく守らせたい方針には、操作を止める hook か、PR で再確認する決定論的なチェックが要ります。原文も「skill で違反を減らし、hook でほぼ不可能にする」と分けています。

本番ゲートなしの auto は危ない

Claude Code の auto は、計画を承認したあと、編集ごとの確認を減らすモードです。公式 Docs でも安全保証ではなく、Team / Enterprise では管理者が無効化できます。ガードレール（短い作業手順、方針、hook、テスト）が薄い状態で、本番まで自動で通す話ではありません。原文も、エージェントは本番ゲートの手前まで動き、ゲートは人が残す、と書いています。

Claude 用語を他ツールに翻訳する

ここからが対応表です。1 対 1 ではありません。名前が似ていても、置き場所もイベント名も違います。公式名が無い欄は「近いもの / 公式未確認」のまま残します。

以降、GitHub Copilot は VS Code 上のエージェント利用を中心に書きます。Codex は OpenAI のコーディングエージェントです。

作業手順と skill、hook

playbook / Claude Code GitHub Copilot / VS Code の近いもの Codex の近いもの 注意
CLAUDE.md custom instructions（.github/copilot-instructions.md、AGENTS.md）。VS Code は CLAUDE.md も読む AGENTS.md 常時オンの作業手順。権限や hook の代わりではない
skill（SKILL.md） Agent Skills Agent skills オープンな SKILL.md に近い。必須ポリシーの強制力はない
hook VS Code の Agent hooks（Preview）、GitHub の Copilot hooks Hooks 形式は近い。イベント名は一致しない。VS Code は Claude の matcher を無視する

方針を文章で渡す層と、操作を止める層は、どのツールでも分けた方がよい、というのが対応表から見える共通点です。

計画とレビュー

playbook / Claude Code GitHub Copilot / VS Code の近いもの Codex の近いもの 注意
plan mode（permission modes の plan） VS Code の Plan agent（/plan）、Visual Studio の Plan agent 公式の同名モードは未確認。experimental の $create-plan skill がある Claude の「編集できない計画モード」そのものではない
auto mode 公式の同名モードは未確認 公式の同名モードは未確認 agent のツール承認とは別物として扱う
Code Review（research preview） Copilot code review AGENTS.md の Code Review Rules など 別製品。書いた側が承認できない分離は残す

計画を先に文章で固める、という運用自体は移植できます。モード名まで揃える必要はありません。

成果物と、埋めない欄

playbook / Claude Code GitHub Copilot / VS Code Codex 注意
intent.md / spec.md / plan.md 公式の必須ファイルではない 公式の必須ファイルではない 運用上の成果物。ツール固有の入力形式ではない
evals（エージェント設定の回帰） 公式製品名は未確認 公式製品名は未確認 CI で非対話実行する、という実践
managed settings org instructions や enterprise policies は近いが、キー一式の対応は未確認 同名の対応は未確認 埋めない
sandbox / worktrees（同名） 同名機能は未確認 同名機能は未確認 埋めない

対応表で大事なのは「同じファイル名を置け」ではありません。次の人が、次のエージェントが、同じ成果物を読めることです。

最初に置く最小セット

6 ステージを一度に導入しなくてよい、と原文も書いています。依存のない play から始めてよい。現場向けに削ると、最初のセットはこれで足ります。

  1. 意図の 1 ファイル
    問題、よくなった状態、影響範囲、制約、未決。書いた人の言葉でよい。ツール必須のファイル名ではない。
  2. リポジトリの作業手順
    ビルド、テスト、lint、やってはいけないこと。1 ページ以内。Claude Code なら CLAUDE.md、Copilot なら instructions / AGENTS.md、Codex なら AGENTS.md。
  3. 検証コマンド
    セッションが自分で回せる 1 本。失敗したらコードを直し、テストを弱めない。
  4. 人が残る承認ゲート
    本番、保護パス、変更管理が残る操作。助言の skill ではなく、止める hook かブランチ保護。

ここまで揃うと、エージェントを増やす前に「何を残して、どこで人を挟むか」が見えます。並列セッションや本番監視の閉じたループは、そのあとでよいです。

モデルを替えたとき、何が残るか

モデルを替えるたびに、チームで積み上げた知識までリセットされたら困ります。この問題は、Satya Nadella 氏の論考 A frontier without an ecosystem is not stable にある learning loop とつながります。

そこでは、企業が育てるものを 2 つに分けていました。人の知識と判断が human capital、企業が自ら構築して所有する AI の実行能力が token capital。この 2 つを往復させて育てるのが learning loop で、一般的なモデルを交換しても「会社のベテラン」の知識を失わない状態かがコントロールのテストになる、という話でした。

playbook は、同じテストを開発プロセスの側で具体化しています。

  • 組織の知識は CLAUDE.md と skill に置き、バージョン管理してコードと同じようにレビューする
  • その設定が変わったら eval が回る
  • 原文はこう書いています。新しいモデルに差し替えたときやプロンプトを書き換えたとき、eval スイートが「エージェントは同じ水準で仕事をしているか」を答える

知識を自分側に置き、失われていないことを機械で確かめる。論考が「そうあるべき」と言っているところに、playbook は「どのファイルに置き、どこで検査するか」を書いています。

ただし Anthropic は token capital という言葉を使っていません。論考のほうは経済やエコシステム、国の話まで含みます。重なるのは中心の 1 点、学びを自分側に残して、モデル交代に耐えさせるところだけです。対応づけは私の読みです。

learning loop 側は前に 1 本書いたので、詳しくはそちらへ。AI を使うほど強くなる企業は何が違うのか？ 「トークン資本」と Learning Loop で育てる知の基盤

まとめ

コードが速くなった話は、もう出尽くしています。足りないのは、その左右です。ボトルネックは実装ではなく、人間速度の計画とレビューとデプロイ。見るべきはステージ名ではなく、次が読める成果物と、人が残るゲートです。

SDD をすでに回しているなら、前半はもう持っています。足すならリリースと運用側です。まだなら、エージェントを増やす前に成果物チェーンを 1 本置くところから。そこを残しておけば、モデルを替えても学びは手元に残ります。私は次に、自分のリポジトリでそこを試します。

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?