【AWS re:invent 2025】 AmazonのチームはAIアシスタントをどう活用して開発を加速しているのか

こんにちは。SRE の @komtaki です。

今年は IVRy から３名が AWS re:invent に参加しています。私は初参加で、実は同じ時期に予定していた一人旅をキャンセルしての参加だったので、「来年に向けた実践的な学びを得て帰ろう」という気持ちで臨みました。

この記事では、特に注目した lv. 400 のセッション 「DEV403: How Amazon Teams Use AI Assistants to Accelerate Development」 を紹介します。

TL;DR

• Strands SOP (Standard Operating Procedures) は Amazon が 開発したマークダウン形式の標準化ワークフローのプロンプトセット
• MCP 連携で Claude Code や Cursor などの異なる AI ツールで利用可能し、チームを跨いで再利用可能なワークフローに変換する
• プロンプト駆動開発のデモでは、要件定義 → デザイン → 実装の流れを SOP で自動化する様子が紹介された

https://github.com/strands-agents/agent-sop

セッションを選んだ理由

IVRy のエンジニアは Cursor や Claude Code などの LLM 開発支援ツールを活用しています。

https://note.com/komtaki/n/n56279394e2cf

その結果、生産性は上がっているものの、まだまだ 2 ~ 3 倍にはなっておらず下記のような課題を抱えています。

• 各人の能力に依存している部分が多く非効率的で、AI Agent を使う場合のナレッジが十分に共有できていない。
• 細かい単発のタスクを自動化が中心で、業務フロー全体をまだまだ自動化できていない。
• ルール設定については共通のドキュメントを作成してシンボリックリンクから参照しているが、設定の管理が複雑化している。

そこで、社内での AI 活用をさらに加速するためのヒントを探して、このセッションに参加しました。

セッション

セッションでは、まず Strands SOP の概要から入り、Kiro cli を使ったデモを通して実装が行われました。Strands SOP は 11/20 に AWS のブログでも紹介された OSS です。

https://aws.amazon.com/jp/blogs/opensource/introducing-strands-agent-sops-natural-language-workflows-for-ai-agents/

その中でスピーカーが「僕は AI に実装させることは 懐疑的（skeptical） なんだけど、これはうまく動く」と何度も言っていたのが印象的でした。

Strands SOP が生まれた背景

Amazon では数万人の開発者が AI を積極的に活用しており、エージェント型 AI コーディングアシスタントの導入当初から様々な業務の自動化に取り組んでいます。しかし、導入が拡大するにつれて大きく２つの課題に直面したそうです。

1. 一貫性のない動作
   開発段階では完璧に動作していたエージェントが、現実世界のシナリオでは予測不可能な結果をもたらし、ユーザーの信頼を損なっている。

2. プロンプトエンジニアリングの複雑さ
   効果的なプロンプト作成には深い専門知識が必要で、チームは数週間を費やしても異なるモデルやユースケースに移行できない問題に悩まされていた。

この状況を解決するために、スピーカーが「決定論的(Determin-ish-tic)なスイートスポット」という面白い概念を紹介していました。これは、一貫した成果を保証できるほど構造化されながらも、AI エージェントの価値を高める知性を活用できるほど柔軟性のあるバランスを指します。

この洞察から、Amazon のコミュニティが信頼性と適応性のバランスを取りながら AI エージェントのワークフローを定義するための標準化されたマークダウン形式として Agent SOPs を開発したと説明されました。

現在では、コードレビューからインシデント対応まで様々なユースケースで数千もの SOP が活用されており、組織全体で AI の専門知識を民主化する強力な手段となっているとのことです。

Strands SOP とは何か

基本的なマークダウンの構造は下記のようになります。

# Code Assist

## Overview
This SOP guides the implementation of code tasks using test-driven development
principles, following a structured Explore, Plan, Code, Commit workflow.

## Parameters
- **task_description** (required): Description of the task to be implemented
- **mode** (optional, default: "interactive"): "interactive" or "fsc" (Full Self-Coding)

## Steps
### 1. Setup
Initialize the project environment and create necessary directory structures.

**Constraints:**
- You MUST validate and create the documentation directory structure
- You MUST discover existing instruction files using find commands
- You MUST NOT proceed if directory creation fails

### 2. Explore Phase
[Additional steps with specific constraints...]

RFC 2119 制約による構造化ステップ

各ワークフローステップでは、 MUST、SHOULD、MAY などの RFC 2119 キーワード を使って、厳格なスクリプトなしでエージェントの動作を正確に制御し、エージェントの推論能力を維持しながら信頼性の高い実行を保証する仕組みです。

**Constraints:**
- You MUST validate and create the documentation directory structure
- You MUST discover existing instruction files using find commands
- You MUST NOT proceed if directory creation fails

パラメータ化された入力

SOP は特定の値をハードコーディングするのではなく、異なるプロジェクト、チーム、または要件に合わせて動作をカスタマイズするパラメータを受け入れます。これにより、単発的なプロンプトが一貫性を維持しながら幅広く適用できる柔軟なテンプレートになります。

## Parameters

- **task_description** (required): Description of the task to be implemented
- **mode** (optional, default: "interactive"): "interactive" or "fsc" (Full Self-Coding)

進捗状況の追跡と再開

エージェント SOP はエージェントに作業中の進捗状況を記録するよう指示できるため、状況の把握が容易になり、何か問題が発生した場合でも再開できます。この透明性は、デバッグプロンプトの提示と AI 自動化に対する開発者の信頼構築に不可欠だったそうです。

SOP で実践するプロンプト駆動開発のデモ

セッションの最後には、プロンプト駆動開発の SOP を使ってデモが行われました。Kiro のような構造で、要件定義をして、デザインに落とし込んで、成果物をちゃんと出力して実装に進んでいきます。

残念ながらアプリケーションが完全に動くところまでは時間が足りませんでしたが、将来性を感じました。

https://github.com/strands-agents/agent-sop/blob/main/agent-sops/pdd.sop.md

claude code で実践

以下の手順で claude code でも動かせます。

$ brew install strands-agents-sops
$ claude mcp add --transport stdio strands-agents-sops strands-agents-sops
$ claude > /strands-agents-sops:code-summary 日本語で

考察

今回のセッションを聞いて、「まだまだ荒削りだが、これは使えそうだ」と思いました。

考えてみれば AWS の Kiro の３段階の Requirement -> Design -> Implement のステップも、GitHub の Spec kitも標準化プロセスの一種です。これらのワークフローは非常に重厚で新規機能開発では刺さっても、既存のアプリケーションの改修においては、牛刀を持って鶏を割くようなオーバーキルになるケースがあります。

ですが SOP を使えば、**柔軟にワークフローを定義して MCP 経由で他のツールで標準実装プロセスを簡単に横展開できます。

人間にとってもわかりやすいマークダウンの記述で拡張がしやすく、チーム内での知識共有や改善において大きなメリットになると感じました。社内用の SOP を作成して標準開発プロセスをプロダクトやチームごとに育てていくのが良さそうです。また Agent Core で社内 MCP サーバーとしてホスティングできると、各人の開発環境で設定の更新が減らせそうです。

さらに、Claude Code だけでなく Cursor の Integration を強化する PR #21 も出ているので、より使いやすくなることが期待できます。私も基本は Cursor を使っているのでありがたいです。

社内で試してみて、うまくいったらまた記事で紹介します。

We are hiring!

IVRy では、イベントや最新ニュース、募集ポジションなどの情報をお届けするカジュアルなつながり「キャリア登録」をご用意しています。IVRy に少しでもご興味をお持ちいただいた方は、以下の URL よりぜひご登録ください。

https://herp.careers/v1/ivry/wmZiOSAmZ4SQ

参考

• https://github.com/aws-samples/sample-riv2025-dev403