はじめに
前回（Part 1）では、GitHub SpecKitを使用して、ゼロからAWSサーバーレス構成（Lambda + DynamoDB）のAPIを立ち上げ、「作成(Create)」と「取得(Read)」機能を実装しました。
今回はその続きとして、残る「更新(Update)」と「削除(Delete)」機能を追加し、完全なCRUD APIとして完成させていきます。
PART1はこちら blog.serverworks.co.jp
1.仕様の追加定義(/speckit.specify)
前回同様、/speckit.specifyコマンドを使用してAIに対して「何を追加したいか」を伝えます。
前回作成した仕様書（spec.md）が存在する状態で、以下の内容を自然言語で伝えました。
指示した主な内容： 目的: 既存APIへの PUT / DELETE 機能追加 ベース: 現在の spec.md と books_handler.py を使用 制約: 既存の BooksTable とAPI Gatewayリソースを流用（破壊せず拡張）すること
実行すると、SpecKitは自動的に新しいトピックブランチ（001-books-update-delete）を作成し、仕様書にUpdate/Deleteの要件を追記しました。
自動で作業ブランチ作成まで行い、その配下で作業をしてくれるのは安心できますね。
実際に実行したプロンプト、生成されたファイル
2. 追加機能の実装計画の作成(/speckit.plan)
こちらも前回どほぼ同じ。ただし、指示の内容をただコードを書かせるのではなく、「既存環境との共存」を意識した計画を立てるよう意識して指示してみました。
指示した主な内容 差分更新（Incremental Update）の徹底: BooksTable などのステートフルなリソースは維持し、ステートレスなコンポーネントのみを拡張する。 工程の段階化: 実装ステップを「ロジック実装（Lambda）」と「インターフェース定義（API Gateway）」に分割し、依存関係順に計画する。
AIが生成した計画書（plan.md）を確認すると、DynamoDBの再作成などは含まれず、「既存のLambdaコードへの関数追加」や「API Gatewayへの put-method コマンド追加」だけが綺麗にリストアップされていました。
実際に実行したプロンプト、生成されたファイル
3. いざ実装とデプロイ(/speckit.implement)
こちらも前回同様。計画をタスク化（/speckit.tasks）した後、実装コマンドを実行します。
AIは計画通り、以下の手順をCLIで実行していきました。
- Lambdaコード修正: books_handler.py に update_book と delete_book 関数を追加し、ルーティングロジックを更新。
- コード更新: aws lambda update-function-code でデプロイ。
- API Gateway設定: aws apigateway put-method を実行し、PUT と DELETE メソッドを既存リソースに追加。
自分で行う作業としては、提示されるコマンドを確認し、「Allow」を押していくだけです。
生成されたファイル
4. 動作検証: 実際に叩いてみる
実装が完了したので、実際に curl コマンドを叩いて検証します。
① 追加 (POST) まずは書籍データを登録します。
# 実行コマンド
curl -sS -X POST "$BASE/books" -H 'Content-Type: application/json' \
-d '{"title":"実践ドメイン駆動設計","author":"Vernon","status":"未読","publishedDate":"2013-09-01"}'
② 取得 (GET) 作成されたIDでデータを取得します。
# 実行コマンド curl -sS "$BASE/books/$BOOK_ID" | jq -c
ここまではPart1で実装した機能なので、デグレが起きていないことの確認ができた。
③ 更新 (PUT) ここが新機能です。ステータスを「読了」に変更し、タイトルも短縮形として「実践DDD」に更新してみます。
# 実行コマンド
curl -sS -X PUT "$BASE/books/$BOOK_ID" \
-H 'Content-Type: application/json' \
-d '{"status":"読了","title":"実践DDD","publishedDate":"2014-02-01"}'
Status, title, publishedDateがそれぞれ更新されていることが確認できる。
④ 削除 (DELETE) 最後にデータを削除できるかの確認を実施
# 削除
curl -sS -X DELETE "$BASE/books/$BOOK_ID" | jq -c
# 削除後４０４確認
curl -sS -o /dev/null -w '%{http_code}\n' "$BASE/books/$BOOK_ID"
削除成功後、再度GETリクエストを送ると 404 Not Found が返ってくることが確認できた。
まとめ
Part 1、Part 2を通して、GitHub SpecKitの強みが見えてきました。
単発のスクリプト生成ならChatGPTなどの生成AIでも可能ですが、SpecKitは「以前の状態（Context）」を理解した上で、「整合性を保ったまま拡張（Evolution）」する能力に長けています。
特に下記のような特徴があります。
- 仕様書 (Spec) が常に最新の状態に保たれる。
- 計画 (Plan) によって、既存リソースへの影響範囲を事前に確認できる。
- 実装 (Implement) はCLIベースで実行許可を求められるため、透明性が高い。
「ドキュメントとコードが乖離しない開発」を、AIが強力にサポートしてくれる未来を感じました！ 普通のAIだと、「このコード書いて」って言ってもその場限りの対応になりがちですよね。でもSpecKitは、プロジェクトの履歴をちゃんと分かってくれてました。いちいち大量のファイルを読み込ませなくても、「昨日のアレ、ちょっと拡張しといて」みたいな雰囲気で通じる凄さがありました！ これからの開発は「書く」よりも「定義して、レビューする」スタイルが主流になっていきそうですね！
