TL;DR

Kiro や Mahavat Agent を触ってわかったのは、「AI エージェントが増えるほど“仕様・認可・Runbook”をエージェントの外に出さないと詰む」ということ
Cedar は「AI 時代の認可ロジックの最後の良心」になりうる
Iceberg v3 / Nova / FIS は、それぞれ「延命」「入り口」「壊し方」を支える技術ピースとして見えた

― AI エージェント時代を “実装する側の皮膚感覚” から眺めてみた ―

NEXTSCAPE のヤマモトと申します。CoE チーム内の Infra Forge というスキルアップチームを管理しながら、日々様々なお客様案件で貴重な経験を積ませていただいております。
昨日、 太田の Keynote レポート に続き、AWS re:Invent 2025現地参加組としては２本目の現地レポートをお送りいたします。

今は、現地時間12/03（水）の昼下がり。

AWS 様からお声がけいただき、10月にローンチしたてホヤホヤ、
Amazon Quick シリーズを再構成した Amazon Quick Suite のイベント に参加中で、グローバルエグゼクティブの皆さまと一緒に "NAISHOKU" しております。

早いもので明日からイベントも後半戦になってまいります。

太田が 「Agentic Shift と組織ガバナンス」 を俯瞰でバッサリいったので、
ワタクシはもう少し 手を動かす側・PoC を回す側の目線 で書きます。

テーマはざっくりいうと：

「AI エージェントが実装と運用に入り込んだとき、
現場エンジニアは何を“エージェントの外に出しておかないと”詰むのか？」

です。

1. Kiro で味わう Spec-Driven Development の「甘さ」と「後味」

Smart Clinical Documentation ワークショップ（ Kiro × AWS HealthScribe ）では、
Kiro で用意された Spec ファイル をベースに、
HealthScribe デモアプリをいじる体験をしました。

「仕様を書けば、あとは Kiro と AI が勝手に実装してくれる」
という世界観そのもので、思わず かわいい！！Kiroかわいい！！ です。

たとえば、ざっくり言うとこんな YAML で：

# pseudo spec for Kiro
endpoint: POST /conversations
summary: "患者と医師の会話から診療ノートを生成する"
input:
  audioUrl: string
output:
  noteId: string
  status: enum["pending", "completed", "failed"]
constraints:
  - "note must be linked to existing patient record"

この「what（何をしたいか）」を Kiro に渡すと、
裏で Lambda / API Gateway / DynamoDB まで一気に組み上げてくれるイメージです。

ところが実際にいじってみると、

“constraints が雑に書かれているところほど、挙動も雑になる”
「患者レコード未登録のときはどうするか？」みたいな部分がふわっとしたまま動いてしまう
ワークショップとしては成立しているけれど、本番コードとして「レビュー責任を持つには」情報が足りない

という “仕様の曖昧さがそのままエージェントの曖昧さになる” 感触が非常に強い印象。

✅ 学び１

Spec-Driven Development は「仕様を書く能力」を組織に要求する
仕様がふわっとしていると、そのまま ふわっとした実装が量産される
「Kiro に仕様を書かせて Sonnet に実装させる」みたいな夢を見がちだけど、
仕様の責任の所在はむしろクッキリ人間側に寄ってくる（それも足音を立てず、大量に）

2. PostgreSQL Incident の Agentic 対応は“９割最高 / １割怖い”

[DAT301-R] AI powered PostgreSQL: Incident detection & MCP integration のワークショップでは、
Mahavat Agent という IDR（Incident Detection & Response）エージェントを使い、

Aurora / RDS PostgreSQL の IOPS / ACU 利用率
CloudWatch アラーム
Bedrock Knowledge Base 上の Runbook
MCP でつながったログ・メトリクス

をまとめて “エージェントに喋らせる” 体験をしました。

たとえば、Aurora Serverless v2 の ACUUtilization 90% 超え を監視するアラームは、
こういう感じの設計で作れます：

{
  "AlarmName": "Aurora-ACU-High-90",
  "Namespace": "AWS/RDS",
  "MetricName": "ACUUtilization",
  "Dimensions": [
    { "Name": "DBClusterIdentifier", "Value": "your-cluster-id" }
  ],
  "Statistic": "Average",
  "Period": 300,
  "EvaluationPeriods": 2,
  "Threshold": 90,
  "ComparisonOperator": "GreaterThanThreshold",
  "TreatMissingData": "missing"
}

このアラーム発火をトリガーに、

Mahavat Agent が CloudWatch アラームを検知
Bedrock Knowledge Base から 該当 Runbook を検索
「 ACU が張り付いている理由」を RDS / OS メトリクスから推定
必要なら Aurora の min/max ACU 調整まで提案

という流れが、自然言語のやりとりだけで進んでいく。

ここまでは夢のようなんですが…

実際に触ってみて強く感じたのは：

Runbook の書き方が雑だと、本当に 雑な提案 しか返ってこない
「本当にスケールアウトでよかったのか？」を判断するのは
結局 ダッシュボードを眺める人間
Incident の “根っこ” がアプリケーション設計にあるとき、
エージェントは “症状に対する忠実な対症療法” しかしてくれない

ということでした。

✅ 学び２

エージェントに渡す Runbook / KB の品質 = 運用の上限値
「エージェントに丸投げしたいなら、まず Runbook 写経大会から逃げられない」
AI は Incident を「運ぶ」のは得意だが、
運用設計そのものを改善するのはやっぱり人間の仕事

3. Cedar：認可をアプリから引き剥がす唯一の救い

これまでのセッションで “ワタクシ的に刺さった” のは

「Accelerate app authorization with the latest Cedar tools (OPN301-R1)」
の Cedar ワークショップでした。

内容はざっくりいうと：

Express / Spring Boot への Cedar 統合
Cedar Schema Generator
Cedar Analysis CLI（SMT による形式検証）

を使って、「認可ロジックをアプリから剥がす」 というもの。

たとえば、サンプルの PetStore API で

customer ロールは GET 系だけ
employee ロールは すべての操作

という権限を Cedar で書くと、こんな感じになります。

// customer can only view pets
permit (
    principal in PetStoreApp::UserGroup::"customer",
    action in [
        PetStoreApp::Action::"GET /pets",
        PetStoreApp::Action::"GET /pets/{petId}"
    ],
    resource
);

// employee can view and modify pets
permit (
    principal in PetStoreApp::UserGroup::"employee",
    action in [
        PetStoreApp::Action::"GET /pets",
        PetStoreApp::Action::"POST /pets",
        PetStoreApp::Action::"GET /pets/{petId}",
        PetStoreApp::Action::"POST /pets/{petId}/sale"
    ],
    resource
);

これを Express アプリとつなぐと、

コントローラ側では 「誰が何をしようとしているか」 だけ渡す
決定は Cedar のエンジンが行う
ポリシーの差分は JSON / ファイルとしてレビュー可能

という世界になります。

さらにヤバいのが Cedar Analysis CLI

ワークショップでは、Cedar Analysis を使って、

ポリシー変更前後で「意図せず権限が広がっていないか」 を検証
SMT ソルバで 「到達しうるすべてのケース」を機械的にチェック

というデモもありました。

要するに、

「ユニットテストで数ケース試す」のではなく、
「このポリシーセットだと、こういう人は絶対にこの操作に到達できません」
を数学的に保証する

という世界です。

✅ 学び３

AI エージェントがコードを書き始めるほど、認可は “アプリの外側” に逃がさないと詰む
Cedar は “仕様の最後の良心” になりうる
「AI に書かせた認可ロジック」をそのままマージするのは、もはやギャンブルに近い

4. Iceberg v3：Deletion Vector が教えてくれた“延命と進化”の線引き

「Storage optimization by Apache Iceberg V3's Deletion Vectors (OPN411)」 では、
Iceberg v3 の Deletion Vector 機能にフォーカスした話を聞きました。

雑にまとめると：

これまでは DELETE で行を消すと ファイルごと書き直し
v3 では 「消した行だけをビットマップで管理」 できる
.delete.puffin 的なサイドファイルが増えていく
Merge-on-Read / position delete の最適化……など

という話です。

ここで刺さったのは、

「技術的には延命できてしまうが、
それをやると将来マイグレーションが地獄になるライン」

が、まさに日本の 小売業や EC の DWH 文脈（「今は動いているからいいじゃないか」で積み上がってきたレガシー達）にガチ被りしてきます。

「消せないデータ」が山ほどあるレガシー DWH
それでもパフォーマンス要求は上がり続ける
Deletion Vector を雑に使うと
「消したつもりのデータがどこまでも引きずられる」 未来

をリアルに想像してしまいました。

✅ 学び４

Iceberg v3 の Deletion Vector は “延命装置” にも “進化のブリッジ” にもなりうる
どこで物理削除に切り替えるか の運用ルールを決めないと泥沼

💡「技術的にできる」ことと「やるべき」ことを分けるという意味では、太田の書いた RDS 256TB 批判と同じ匂い

5. Nova NTA307：NLP → SQL の“入り口だけキレイ問題”

「NLP to SQL: Data Access with Amazon Nova (NTA307)」 のセッションでは、複数のバックエンドシステム（注文管理・在庫・倉庫・カスタマーサポートなど）の上に自然言語インターフェース をかぶせるアーキテクチャが紹介されていました。

イメージとしては：

ユーザー：「昨日発送した A さんの注文で、まだ配達完了してないものある？」
Nova が NL を解析し、
- どのテーブルが関係しそうか
- どのキーで JOIN すべきか
これらを判断して SQL を生成
オーケストレーション MCP サーバーが複数 DB に投げる
結果を人間フレンドリーな文章に戻す

という流れ。

たとえば、かなり雑に書くと SQL はこうなるイメージです：

SELECT o.order_id, o.order_date, s.status
FROM orders o
JOIN shipments s ON o.order_id = s.order_id
JOIN customers c ON o.customer_id = c.customer_id
WHERE c.name = 'A さん'
  AND o.order_date >= CURRENT_DATE - INTERVAL '1 day'
  AND s.status <> 'DELIVERED';

“NLP → SQL” そのものは、もう技術的にはほぼ解けている と感じます。怖いのはむしろ、

テナント分離（Row Level Security）をどう担保するか
監査ログをどう残すか
「AI が生成した SQL を人間がどこまでレビューするか」

といった **“ガバナンス側の話”**でした。

✅ 学び５

自然言語インターフェースは 「問い合わせの入り口問題」を華麗に解決してくれる
しかし、マルチテナント / 監査 / コンテキスト制御 を雑にやると一発で事故る
ここでも結局 認可（Cedar など）との連携が肝 になる

6. Chaos Engineering：レジリエンスは“みんなの仕事”に戻ってきた

「Chaos engineering workshop」 では AWS Fault Injection Service（FIS）を使って、Pet Adoptions アプリに対して

EC2 / ECS / EKS への負荷注入
AZ レベル障害のシミュレーション
Lambda エラー注入
マルチリージョン構成の接続断

などを試すワークショップでした。

印象的だったのは、最後に紹介された “レジリエンスライフサイクル” の考え方。

設計
実装
テスト（カオス実験）
モニタリング
学び・改善

という一連の流れを 「継続的なプロセスとして回し続ける」 という話は、AI エージェントが何をやろうが 関係なく残る 仕事だと改めて感じました。

✅ 学び６

AI が運用自動化を進めるほど、「どこまで壊してよいか」「どこから先は壊してはいけないか」 を決める仕事が人間の側に戻ってくる
レジリエンスはやっぱり “Chaos Engineer 部門だけのものではない” アプリ、インフラ、SRE、ビジネス、全部巻き込んだ継続テーマ

7. まとめ：AI エージェント時代の「外出し候補」たち

ラスベガスに来てから今日まで、
AI まわりのセッションやワークショップをつまみ食いして感じたのは、

AI エージェントが強くなればなるほど、
“エージェントの外に出しておいたほうがいいもの” がハッキリしてきた

ということでした。

特に、今の自分の頭の中に残っているリストはこんな感じです：

仕様（Spec）
- Kiro の体験を通じて、「仕様がふわっとしたまま AI に投げると、ふわっとした負債が大量生産される」
- Spec-Driven は 「仕様を書く力」 を鍛える話だと腹落ち
認可（Authorization）
- Cedar は “エージェント時代の最後の良心” になりうる
- AI にコードを書かせるほど、認可ロジックは アプリから剥がすべき
運用 Runbook / Incident 知識
- Mahavat Agent / IDR を使うほど、Runbook の品質が運用の上限になる
- 「とりあえずエージェントにやらせてみるか」の前にRunbook を人間がちゃんと書いておく儀式 が必要
データレイアウトと“延命装置”の線引き
- Iceberg v3 の Deletion Vector のような機能は、延命・進化の両方に使える
- 「どこまで延命に使ってよいか」をチームで決める必要あり
レジリエンスの責任範囲
- Chaos Engineering / FIS は「AI がいるからやらなくていい」のではなく、むしろ逆
- 自動化が進むほど、「どこまで壊していいかを決める人間の責任」 は重くなる

8. おまけ：ラップトップの天板にステッカーを貼る

現地では

魅力的なインプットを前にいろいろと頭をこねくり回すわけですが、
しかめ面ばかりしていては疲れちゃうってことで、
今回は私物のラップトップも持ち込み、天板に現地で出会った企業のノベルティステッカーを貼って楽しもう、と思っておりました

実際にステッカーキャンペーンを始めると

案外すぐにステッカーだらけのラップトップとなっております

初日が終わった後のラップトップ

今現在のラップトップ

Expo（日本でもある展示会のデカい版）を未だ半分しか見ていないので、もっとステッカーが手に入ったときにどうなることやら。

参考にしたセッション / ワークショップ

本文で触れた内容は、主に以下のセッション・ワークショップで得た知見をベースにしています。

[DAT301-R] AI powered PostgreSQL: Incident detection & MCP integration
Building .NET AI Applications with Semantic Kernel and Amazon Bedrock (DEV302)
Build Real-time Streaming Applications with Bedrock APIs
Storage optimization by Apache Iceberg V3's Deletion Vectors (OPN411)
Smart Clinical Documentation: Kiro & AWS HealthScribe
Chaos engineering workshop
Accelerate app authorization with the latest Cedar tools [REPEAT] (OPN301-R1)
NLP to SQL: Data Access with Amazon Nova (NTA307)

以上、ラスベガスより、ヤマモトがお送りしました。
他メンバーの現地レポートも続きます。ぜひ NEXTSCAPE Advent Calendar 2025 をフォローしてご覧ください！！

その後にのぼらせてもらった、ストラトスフィアタワー展望台からの景色です。