[セッションレポート]Kiro と Amazon の文化から学ぶ AI 駆動開発の型 (DVT324)

こんにちは！Koty-Mousa 矢坂幸太郎 です！
本日は、Kiro のセッション「Kiro と Amazon の文化から学ぶ AI 駆動開発の型」に参加してきましたので、そのレポートをお伝えします！

このセッションでは、AI がコードを書く時代における「ソフトウェアの所有責任」と、それを果たすための設計思想 Design for Evaluation（評価のための設計） が中心テーマでした。

アマゾン ウェブ サービス ジャパン合同会社・ソリューションアーキテクト の 高野 賢司さんによるセッションです。

コードを書く主体は AI になった

コーディングエージェントは、自律的に 探索 編集 テスト を実施し、十分な品質でタスクの一部を完遂できるようになっています。自動運転に例えると、レベル 3 くらいはあるのでは、と感じています。

コードを書く主体はすでに AI に移っていると言えます。
とはいえ、願望を伝えればなんでも叶えてくれるわけではないため、AI が書いたコードレビューや AI への意図の伝達を重視するようになっています。

Kiro を使った開発フローは、おおよそ以下のようになります。

1. Kiro IDE に要件を渡し、要求定義として解釈させる。わからないことはユーザーに確認する
2. ユーザーがレビューする
3. Kiro CLI で実装する
4. Kiro が仕様にそっているかを自律的に確認

※ CLI を利用しているのは好みです。IDE がお好みでしたらそちらでも可能です

Kiro はブラウザを操作して動作確認までしてくれます。仕組みが合っているか直接確認し、仕様で決めた条件が通っているかどうかの確認まで自動でしてくれます！

私、Koty も、業務の効率化のために簡単なソフトウェアを作成することがあります。
私の主業務は開発ではないため、あまりそれに時間をかけることはないのですが、このようなエージェントにより便利なソフトウェアを簡単につくることができ、日々の業務に役立てています。

そもそも、ソフトウェアの「本番環境」とはいつからか？

セッションでは、ソフトウェアが本番環境になる瞬間について問いかけがありました。例えば、以下のようなものがあるでしょう。

• 「本番」「prd」と名付けた
• ユーザーが生まれた
• 機密データが入力された
• 他のソフトウェアに依存された

Amazon の文化には、CTO ワーナー・ヴォゲルス氏の言葉があります。

「You build it, you own it」

AI がコードを書くからといって、責任を AI に押しつけることはできません。

ソフトウェアを所有することで発生する責任

ソフトウェアを所有するということは、以下の 3 つの責任を負うことを意味します。

• 正しく動く
• 安全である
• 変化に応え続けられる

では、どのようにしてこの所有責任を負えるのか。チームやプロセスのブロッカーを解除するには？ 開発力をどう転換できるのか？
セッションのキーワードは 「Design for Evaluation（評価のための設計）」 でした。

Design for Evaluation とは？

AI に渡す前に、評価可能かどうかを問い、評価のための設計を完了する型です。

これは、熟練エンジニアの思考や動きに含まれる叡智を内在化するための型でもあります。自分の外にある叡智を選んで適用し、学習者は型を反復して自分の中に取り込むことで把握できます。

この習得プロセスは、守・破・離 で説明されます。

• 守: 型を守るーー AI がタスクを評価可能か問う
• 破: よりよい型をみつける
• 離: とらわれない

AI にタスクを引き渡す前に「それが評価可能かどうか」を問い、新たな型や自分にあったものを模索していく姿勢が大切です。

正しく動くこと――仕様駆動開発

品質が良くても、振る舞いや構造特性がずれていると価値が出せません。

仕様駆動開発では、開発の前に要求定義と設計から行います。
Kiro は人間の指示を仕様に変換してくれますが、あいまいな指示ではあいまいな結果しか生まれません。

振る舞いを評価可能にするためのポイントは以下の通りです。

• ビジネスの言葉で表現できているか — AI が自律的に評価できるか
• 設計においても合意形成できているか — ソフトウェアの内部構造や特性を評価し、AI が自律的に評価できるか

なお、仕様はすべての合意のために使うのではなく、選択的に切り出すと良いとのことでした。評価基準も、エンジニアが判断できるようにならないといけません。

このほか、重要だと思った内容を下記に一部紹介します。

安全であること――Everything as Code

「AWS のすべてはセキュリティから始まる」とされています。
ソフトウェア全体が監査可能であること、Everything as Code の考え方が、セキュリティにおいても重要です。
環境間での違いをなくし、人間しか知らない情報をなくす。Kiro は AI 駆動開発とセキュリティの両方に効きます！

ソフトウェア構造評価

言語化されていても、曖昧な指示だと評価基準と手法がありません。評価可能化というポイントがあれば、AI が自分で評価できます。

具体的な設計の観点としては以下が挙げられていました。

• テスト容易性の設計
• 構造評価と制約
• 出力の生成と検査を分離する

AWS Security Agent と VPC Reachability Analyzer

AWS Security Agent は侵入テストを自動化してくれます。

VPC Reachability Analyzer は、ネットワークの到達可能性を設定情報のみで数学的に評価できるツールです。設計の段階で、待ちを可視化できます！

専門家を組み込んだエージェントが、こういった評価を自動化してくれる時代になってきています。

変化に応え続けられること――Working Backwards

Amazon の Working Backwards という考え方は「お客様に求められていないものを作らない」というものです。

Working Backwards と AI 駆動開発を組み合わせることで、プロトタイプを何度も作って仮説を洗練させることができます。

まとめ

今回のセッションを通じて、「AI がコードを書く時代だからこそ、評価可能な設計が重要になる」 ということをあらためて実感しました！

AI が自分で評価できるようにする設計が、Kiro を使う上で大事なのだと学びました。
とても大事ですが、私自身これまで意識したことがありませんでした。

https://x.com/i/status/2070043791130849614

今まで、このような AI を使う際、簡単なことまで自分で確認していたため、今後は AI による評価もあわせて活用して、効率化を進めたいです。

以上、Koty-Mousa 矢坂幸太郎 がお伝えしました！