この記事のポイント
- Anthropicの提案は、計画から保守まで6工程にAIを組み込む開発手順です。
- 意図や制約を先に文書化し、承認を挟みながらAIの作業範囲を定めます。
- スキルはルールを伝え、フックは条件違反を止める仕組みとして使い分けます。
Anthropicの開発フローに関する記事をもとに、提案された工程を紹介します。AIへ任せる作業と、人が判断する地点を整理します。
なぜ開発フローを見直す必要があるのか
Anthropicの記事は、次のような問題意識から始まります(Anthropic公式ブログ「The AI-native SDLC playbook」)。
コードはもはやボトルネックではなく、その前後にある人間の作業速度のステップが制約になった
実装が速くなると、計画や確認が次の待ち時間になります。著者はAnthropic Applied AI TeamのLouis Claxton氏で、企業向け開発工程を6段階で整理しています。
| 工程 | AI-Native SDLCでの変化 |
|---|---|
| Plan(計画) | 「intent.md」に人が意図を言葉で記録。Claude Codeが下書きし、人が手直しする |
| Design(設計) | 要件と設計を1回のセッションで詰める。ルールはスキルとしてコード作成時に自動適用 |
| Build(実装) | 先に計画書(plan.md)を作り承認を得てから実装。1人のエンジニアが複数タスクを並行管理 |
| Test(テスト) | テスト・ビルド・見た目の比較まで自動実行し、継続的に評価 |
| Deploy(デプロイ) | AIが出したPRと受け取るPRの双方向レビュー。本番反映には人の承認ゲートが必須 |
| Maintain(保守) | 異常を自動検知し、その診断結果が次のintent.mdとして書き戻される |
ポイントは、AIに「全部任せる」フローではないこと。むしろ、人が判断すべき箇所をこれまで以上にはっきりさせているのが特徴です。
起点は「intent.md」、任せる範囲はスキルとフックで線引き
このフローの起点になるのが「intent.md」というファイルです。記事の例を要約すると、こんな内容です。
例えば、intent.mdには課題、目指す状態、影響する利用者や制約を短く記します。
Claude Codeがintent.mdを下書きし、担当者が内容を確認して次工程へ渡す提案です。スキルは作業時のルールをAIに伝え、フックは承認条件などを満たさない処理を止めます。人の承認を設ける考え方は決済を伴うエージェントでも重要で、Claudeで商取引エージェントを作る際の承認設計を解説した記事でも取り上げています。
保守フェーズも自動化し、次の計画へつなげる
保守では、通常範囲を外れた指標を検知して調査し、その結果を次のintent.mdへつなぐループも提案されています。コードレビューの紹介はGitHub Copilotのコードレビュー機能の記事も参考になります。
長時間のコーディング作業を掲げるモデル例として、Metaの「Muse Spark 1.3」も紹介されています。
まとめ: 人が担い続ける「判断」
開発工程を見直すチームには、コード作成とレビュー・承認の分担が参考になります。生成の速さだけでは、全体の所要時間や品質は決まりません。今の工程で何が制約かを整理すると、取り入れる部分と従来の確認を残す部分を判断しやすくなります。
※ 2026年8月時点の情報です。
