AWS re:Invent 2025

Nextscapeの太田です、日本のSIerで2つあるCoEチームの1つを率いております。
私たちNextscapeはラスベガスで開催されているAWSの年次大型イベント『re:Invent』に今年は5人で参加しております。
11月28日にラスベガス入りをし、土日で時差ボケを解消し万全の体調で取り組んでおります。

Keynote

今年のAWS CEO Matt Garman によるKeynote（基調演説）はAIについての言及がメインでした。これまで「Copilot」だったAIが今後は「Agent」として進化していくよ、といった内容です。
詳細については本レポートでは触れませんが、Youtubeに動画が公開されていますのでそちらを観てみて下さい。

AWS re:Invent 2025 - Keynote with CEO Matt Garman

日本のSIerから見たKeynote

ここからが本題です。クリティカルシンキング大好きな数十人のエンジニアチームのテックリードでシニアエンジニアでもある私がぶった斬ります。

AWS re:Invent 2025は、開発・運用の主体が人間からAIエージェントへと移行する「Agentic Shift」を明確にしました。新IDE「Amazon Kiro」や自律型「Frontier Agents」、そして独自シリコン「Trainium 3」による垂直統合は、生産性とコスト効率の劇的な向上を約束します。しかし、これは同時に「技術的負債のブラックボックス化」「ベンダーロックインの深化」「エンジニアのスキル空洞化」という重大な組織リスクを伴います。

本レポートでは、新技術の可能性を評価しつつ、CoEとして「盲目的な導入」に警鐘を鳴らし、長期的な組織健全性を守るためのガバナンス戦略を提言します。

Amazon Kiro：開発体験の革新とその影

Amazon Kiroは、自然言語による指示から自律的に実装を行う革新的なIDEですが、その導入には慎重な検討が必要です。

Kiroを使う事で得られる機能的価値は何でしょうか。Spec駆動開発という新しい開発手法によって我々人間はWhat（何を作るか）の定義に注力をすることで実装速度を向上させる事が可能になります。How（どう作るか）についてはAIに任せようという考え方です。人間の非稼働時間にソースコードを更新してバグの修正等を行ってくれるようになります。

果たして本当にそうでしょうか。

仕様定義というものは誰でも出来るものではありません、現状でもそうです。そもそもクライアント自身も何を作るかについては固まっていない事が多いです。仕様定義能力が欠如された状態で曖昧な指示でAIが作ったコードは誰が保守をするのでしょうか。「動いてはいるが理解不能」という技術的な負債が隠蔽されるリスクをはらんでいると思います。

レビュー不足のマージによるコンプライアンス違反や予期せぬ障害が発生した際に、「誰が承認したか」といったコンプライアンス上の説明責任が曖昧になります。
朝起きたら知らないコードがマージされテストまで終わっている、という事が果たして良い事なのでしょうか、統制する側からしたら悪夢のはじまりのような気がしてなりません。

Kiroだけではなく今後登場するであろうAIエージェントに任せるという事は短期的には生産性が向上されるでしょう、中長期的にはどうでしょうか、ジュニアエンジニアの成長パスは今後どうなっていくのでしょうか、プロンプト以前に「正確な仕様」を言語化するための設計力はどう培っていくのでしょうか、ここに向き合っていかないとITエンジニアの存在価値そのものが失われていく気がします。

Frontier Agents：運用自律化の功罪

セキュリティやDevOpsの「トイル（労苦）」をAIに委譲することは効率的ですが、過信は禁物です。

良い面だけを見れば、AIエージェントによって脆弱性の早期発見だったり、障害原因の迅速な特定が可能になるでしょう。
偽陰性や偽陽性といったAI特有の見逃しによるコード破壊、セキュリティ事故が発生した際に責任は誰が取るのでしょうか。
複雑な分散システムになればなるほどAIが相関と因果を誤認するリスクが増えていくと思います。

「トイル（労苦）」を「価値を生まない作業」という前提で切り捨てていますが、これはエンジニアの成長の源泉でもあります。ログを読む能力だったりシステム全体を俯瞰する思考力は地道な作業の中でこそ養われていきます。若手エンジニアが「Kiroに聞けば良い」「DevOps Agentが調べてくれる」という姿勢になれば、10年後にシステムを本当に理解している人間がいなくなります。

AIの判断ミスについて、クライアントと共に「最終的な責任を人間が負う」ルールを明確化しないと現場で使っていくのは難しいのではないでしょうか。

インフラ・モデル戦略：垂直統合とロックイン

AWSのTrainiumと呼ばれる独自シリコンとモデルへの傾倒は、コストメリットと引き換えに将来の選択肢を狭める可能性があります。

NVIDIAのGPU一択からAWS独自技術への移行はAWSから見ると大きなメリットがあります。それはベンダーロックインです。AWS上では最適に動くでしょう、ではAzureやGCPではどうでしょうか、恐らく能力を発揮できないかそもそも動かないでしょう。これはマルチクラウド戦略に真っ向から対立します。

Trainiumを採用する際にはNVIDIAへの撤退も戦略に取り込む必要がありそうです。他にもコア領域以外はマルチクラウド性を維持する、といった事も考えると良いでしょう。
新半導体が出るとワクワクはしますがベンチマーク上のカタログスペックと実際に動かした時の性能差は乖離するものです、ここは慎重に進めていきたいです。

「Amazon Nova」についてはどうでしょうか、今回新しいNovaファミリーがいくつか追加されました。これはこれまでのAWSのAIに対する『中立性」からの放棄ではないでしょうか。
Forgeについては特に懐疑的です。独自データで特化型モデルを作れると言いますが、モデルの蒸留（Distillation）は元モデルの能力を必ず劣化させます。ドメインに特化したモデルが本当に必要なのかどうかは採用する前に議論が必要です。RAGやファインチューニングで十分なケースも多いのでは、というのがForgeに対する率直的な感想です。

その他アップデート：「できる」と「すべき」の混同

S3の50TBオブジェクトは誰が必要としているのでしょうか。科学技術計算データと書いていますが、50TBの単一オブジェクトを扱う設計は、そもそもアーキテクチャとして間違っている可能性が高いです。マルチパートアップロード、分割保存、ストリーミング処理が基本。単一巨大ファイルは障害時の復旧コストが甚大です。これは技術的制約の解放ではなく、悪い設計を助長するかもしれません。

Lambda Durable Functionsはステートフルが「推し」ですが、Lambdaの美点はステートレスなところではないでしょうか。ステートフルになった瞬間に複雑性が爆発的に増加します。そもそもStep Functionsという既存サービスがあるのに、なぜLambdaにステートフル機能を持たせるのか？という単純な疑問も湧きました。分散システムのステートフル処理は、ログを追うだけで膨大な時間がかかりますデバッグする事を考えただけで逃げたくなりますね。

RDSの256TB拡張これは悪手です。「できる」からといって「やるべき」かどうかの考え方を完全に放棄しています。これはレガシーシステムの延命装置であり、モダナイゼーションの先送りを助長します。正しい解は「シャーディング」「マイクロサービス化」「ポリグロット永続化」であり、単一巨大DBではありません。

CoE的な戦略提言：慎重な楽観主義に基づくアクション

我々は「AIの波に乗り遅れるな」という圧力に屈せず、組織の長期的な健全性を最優先する必要があります。

「AIリテラシー」の再定義

エンジニアに対し、AI出力を批判的に評価する「Adversarial Thinking（敵対的思考）」の習得を義務付ける必要があります。「AIに書かせたコードを説明できない」状態を許容しない文化を醸成することが大切です。

技術的負債の可視化とコントロール

Kiro導入前に、現在の技術的負債（コード複雑度、テストカバレッジ等）を定量化し、AI導入後もこれらの指標をモニタリングし、「負債の隠蔽」ではなく「解消」に向かっているかを監視する必要があります。AIに丸投げする前に人間が理解し優先順位をつけることは不可欠です。

スキル退化のモニタリング

AIへの依存度が高まる中で、エンジニアの「自力で問題を解決する能力」を維持できているかを定期的に測定・評価する仕組みを導入する必要があります。エンジニアが「AIに聞く」回数と「自力で解決する」回数を追跡し、後者が減少傾向にあれば警報を出す仕組みが必要です。

まとめ

AIエージェントは強力な「同僚」になり得ますが、それを使いこなすのはあくまで「人間」です。CoEとしては、技術の進化を歓迎しつつも、組織が「AIに使われる」状態に陥らないよう、厳格なガバナンスと人材育成を主導します。
「あのときAIに丸投げしたせいで、今は誰もシステムを理解していない」という事態にならないように切に願うばかりです。

雑記

日本のIT業界にとって、Amazon Kiroは「黒船」の再来です、第４の黒船と言えます。
ペリー、インターネット、インリン・オブ・ジョイトイ、Kiro。
特に業界の慣習でもあるSESビジネスにとっては死刑宣告に近いものを感じました。我々SIerはKiroを使う人材を育成すればSESを使っていく必要性が無くなるのです。
これまでの「社内にリソースがない」という言い訳はもう通用しないのです。Kiroに数日でプロトタイプを作らせクライアントに見せる事が可能なのです。

果たしてKiroは本当に「黒船」なのか、それとも「夜明けの鐘」なのか、我々を取り巻く日本のIT業界のビジネスモデルが今後どうなっていくのか、楽しみでなりません。