re:Growth 2025 福岡 で Werner 最後のキーノートについて登壇しました。 #AWSreInvent #regrowth_fukuoka
こんばんは。
クラスメソッド株式会社製造ビジネステクノロジー部の田中孝明です。
re:Growth 2025 福岡で登壇したときに壇上で投影していたブログになります。
冒頭のネタスライド
※NotebookLM で生成したものなので鵜呑みにしないでください。
改めて自己紹介
クラスメソッド株式会社
製造ビジネステクノロジー部
スマートファクトリーチーム
田中孝明
福岡オフィス所属・1月から日比谷オフィスに異動
Youtube
ルネサンス・デベロッパー
今の状況をルネサンス期と照らし合わせられてました。
AI 時代を生き抜くエンジニアとして、「ルネサンス・デベロッパー」として進化することが極めて重要であると、Werner Vogels 氏は提唱しています。
AI の出現は、一部のタスクを自動化し、一部のスキルを時代遅れにするかもしれませんが、エンジニア自身を時代遅れにすることはありません。
ただし、進化し続けることが条件。
AI はあくまでツールであり、仕事そのものは開発者自身のものである。
「仕事はあなたのものです。ツールの仕事ではありません」という認識が不可欠。
この新しい時代において成功するために、ルネサンス・デベロッパーが持つべき資質として、以下の5つが挙げられています。
1. 好奇心と学び続ける意欲（Curiosity & Experimentation）
変化の速い世界で、好奇心は唯一のエンジンです。
すべての開発者は、何かを分解して仕組みを理解したいという本能を持っていますが、この本能を守り抜くことが求めらている。
- 失敗を恐れない実験
- 新しい発明には実験が必要であり、うまく実験するには失敗を厭わない姿勢が不可欠。
- 結果がすでにわかっている行為は実験とは呼べない。
- 実践を通じた学習
- ドキュメントを読むこと、聞くことには限界があり、リアルな学習は実際に取り組んだときやプレッシャーがあるときに結果が伴う。
- 社会的な学習
- 学びは認知的なものだけでなく、社会的なもの。
- いつもの環境から出て、ユーザーグループに参加したり、友人とシステムについて話したりするなど、「モノを作っている他の人たちのそばにいること」が感覚を鋭く保つ最良の方法。
2. システム思考（Think in Systems）
システムを孤立した部分ではなく、全体として捉える能力が必要です。
システムは相互に接続されており、一つの変化（例えば、リトライポリシーの変更やキャッシュの追加）が、負荷やトラフィックフローを変え、新しいパターンを生み出します。
- フィードバックループの理解
- システムは変化を増幅する強化ループ（ポジティブループ）や、平衡状態に戻すバランシングループ（ネガティブループ）といったフィードバックループによって形作られている。
- 全体への影響の把握
- 部分最適ではなく相互作用を含めた全体を俯瞰し、小さな適切な変更がシステム全体の振る舞いをどのように変えるかを見抜くことが重要。
この辺りを理解するために以下の論文をみろと宿題が課せられてます。
3. 明確なコミュニケーション（Communicate with Precision）
考えを明確に表現する能力は、考えること自体と同じくらい重要、エンジニアや技術リーダーがキャリアのために磨くべき最も重要なことの一つ。
- ビジネスとの共通言語
- システムの重要度を Tier 1（必須）や Tier 2（重要）のように分類することは、技術的な設計だけでなくビジネス側と可用性のコストやトレードオフを議論するための重要なコミュニケーションツールになる。
- 対AIの精度
- AI 支援コーディングでは、曖昧な自然言語で指示を出すため、その曖昧さを排除し意図を正確に伝えるためのメカニズムが必要。
- 仕様駆動開発（Spec-driven Development）
- AI とのコミュニケーションにおける曖昧さを減らすのが仕様（Specifications）。
- Kiro IDE ではいきなりコードを生成させるのではなく、要件、設計、タスクの3つのドキュメントを通じて仕様を確定し、AIとより正確にコミュニケーションを図ることで、品質の劇的な向上と開発期間の短縮が実現している。
4. オーナーシップと品質への責任（Be an Owner）
AI がコードを生成するようになっても、ソフトウェアの品質に対する責任は開発者自身にあります。
規制要件に違反するコードが AI によって作られたとしても、「AI がやった」と規制当局に言うことはできません。
仕事はあなたのものであり、ツールの仕事ではない。
- 役割の変化
- AI 時代には、書くコードは減り、レビューするコードが増えます,。
- 検証負債（Verification Depth）
- AI は人間が理解できるよりも速くコードを生成するため、コードは瞬時に作られても理解が追いつかないという検証負債が生じます。
- このギャップにより、「誰も中身を理解していないコード」が本番環境に投入されるリスクが高まります。
- メカニズムの導入
- 誰もが「良いコードを作りたい」という善意を持っていますが、それだけでは一貫した成果は得られません。
- メカニズムは、善意を一貫した結果へと変換するものです（例：Amazon の Endon Cord や S3 チームの耐久性レビュー）。
- コードレビューの重要性
- AI駆動の世界において、コードレビューはバランスを取り戻すための制御ポイントであり、人間の判断をループに戻す極めて重要なメカニズム。
- シニアとジュニアのエンジニアが共同でコードをレビューすることは、知識を伝達し次世代のビルダーを育てる最も効果的な学習メカニズムの一つ。
5. 博学者（ポリマス）になる（Become a Polymath）
AI 時代には、一つの領域に深く、しかし幅広い知識も持つT字型（T-shaped）の開発者が理想とされます。
- 専門性の深さ（I型）
- 特定のドメインで深く専門性を養うこと。
- 知識の幅（T字型）
- 専門分野を超えて、ビジネス、他の技術分野、人々の理解など幅広い知識を培うこと。
深い専門性と幅広い知識を組み合わせることでトレードオフを理解し、自分の仕事がシステム全体をどのように形作るかを見通すことができるため、より良いアーキテクチャの選択が可能になる。
Kiro について
Kiro IDE は、AI 時代における開発の課題を解決するための「仕様駆動開発（Spec-driven Development）」というアプローチを導入したツール。
Kiro IDEの概要と開発の背景
AI 支援コーディングの世界では、人間は曖昧な自然言語でマシンとコミュニケーションを取るようになっていると指摘。
これに対し、意図を正確に伝えるためのメカニズムとして「仕様（Specifications）」が重要であるとし、Kiro チームのシニアプリンシパルデベロッパーである Clare Liguori 氏が登壇し、Kiro IDE の開発と機能について説明されてました。
「Vibe coding（雰囲気でのコーディング）」からフラストレーションを感じたことが Kiro IDE の着想につながったとのこと。
- Vibe Coding の課題
- AI に何を望むかを説明するのに多くの時間を費やし、コードの品質は良くても最終的なソフトウェアは意図したものと異なりました。
- 短いプロンプト（例：「ウェブトリビアゲームを作ってくれ」）から数百万通りの結果が生まれる可能性があり、AI が最善の推測でコードを生成するためコードに対して反復作業をすることになり、元々意図していた内容の洗練ができない。
- 仕様駆動開発の着想
- AI に正確に伝えるために、次第に長く詳細なプロンプトを Markdown などで書き始め、本質的に仕様書を作成していることに気づいた。
- 歴史上 Apollo Guidance System などの多くのシステムが仕様書に基づいて構築されたように、仕様書こそがコーディングアシスタントとのやり取りに欠けていたものだと感じた。
Kiro IDE における仕様駆動開発ワークフロー
Kiro IDE は仕様書をプロンプトとして利用する仕様駆動開発（Spec-driven Development）仕様を確定させることを重視。
Kiro IDE のワークフローでは、フローを以下の3つのドキュメントに分けている。
- 要件（Requirements）
- 設計（Designs）
- タスク（Tasks）
開発者は曖昧なタスク（例：ウェブトリビアゲームを作ってくれ）を Kiro IDE に与えても、Kiro はすぐにコーディングせず、まずこれらの要件、設計、タスクを生成。
これらのドキュメントが開発者の意図と一致しない場合、開発者は Kiro に変更と洗練を依頼する機会がある。
これにより、spec を通じてより正確に意図を伝えることができる。
開発プロセスの改善と効果
Kiro IDE の開発は、ラピッドプロトタイピングによって進められた。
- プロトタイピングの迅速化
- AI はソフトウェアのラピッドプロトタイピングを根本的に可能に。
- 以前は単一のアイデアのコーディングに数ヶ月かかっていた作業が、今では数分で動作するプロトタイプをユーザーに提供し、フィードバックを得られるようになった。
- Kiro による Kiro の構築
- Kiro IDE の最初のプロトタイプ以降、Kiro IDE 自体を使って Kiro IDE のコードを生成できるようになったとのこと。
- これにより、spec 駆動開発がどのように機能するかについて、多くのアイデアを反復することが可能に。
- 異なる仕様アプローチの試行
- 初期には TDD（テスト駆動開発）の技術にインスパイアされたテストベースの仕様や、Apollo Guidance System のような伝統的な技術仕様を試しましたが、これらはリアルなプロジェクトではニュアンスの捕捉や長さの点で課題がありました,。
実例：システム通知機能の実装
Kiro IDE 内で実際に構築されたシステム通知機能の実例が紹介されました。
- 問題の認識
- エージェントがコーディング作業中にユーザーからの入力を必要としたり、作業を完了したりしてもユーザーが他のアプリに切り替えている間に気づかないという問題があった。
- 仕様の生成
- Kiro に spec を生成させた結果、要件ドキュメントがどのエージェントアクションが通知をトリガーすべきかなどの詳細を考える助けになる。
- 設計段階での修正
- Kiro は当初、エージェントコード内に通知システム全体を構築するという過剰に複雑な設計を提案しました。
- しかし spec プロセスのおかげで、これが大きなプロジェクトであることにすぐに気づき、設計ドキュメントの段階で、IDE の基盤コード（Code OSS）に Electron のネイティブ通知 API を使用して通知システムを構築する方針に修正しました,。
- 結果
- Kiro IDE は 10 年の開発期間と 200 万行のコードを持つ複雑なコードベース（Code OSS）に基づいていますが、spec ワークフローが変更箇所を探索し理解するのに役立つ。
- この機能は、Vibe Coding で行った場合と比較して約半分の時間で出荷されました。
Kiro IDE はラピッドプロトタイプを通じたユーザーとのコミュニケーションと、spec を通じた AI とのコミュニケーションの両方において「自然言語に精度をもたらす」ことで、AI 時代の開発に貢献していると言われてます。
目に見えない仕事への誇り
最後に伝えられたこと。
開発者が構築するシステムのほとんどは顧客の目に触れることはありません。
夜通し稼働し続けるシステムや、誰も気づかないロールバックなど、目に見えない仕事に対するプロフェッショナルとしての誇りこそが、最高のビルダーを定義するものです。
最高のビルダーは、誰も見ていないときでさえ物事を適切に行う。
