※本記事は、Irene Marban Alvarez氏（AWS GenAI/ML Specialist SA）、Gareth Hastings氏（AWS Senior Solutions Architect）、John Kellett氏（AWS Principal CSM）、Stew Norriss氏（Flutter Entertainment Director of Engineering）による、第5回AWS AI and Data Conference 2026（2026年3月12日、アイルランド・キルケニーのLyrath Convention Centreにて収録）のセッション「Kiro: Enterprise Developer Productivity」の内容を基に作成されています。イベントの詳細情報は https://go.aws/events でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご視聴いただくことをお勧めいたします。
1. イントロダクション：エージェント型コーディングの課題とKiroの位置づけ
1.1 バイブコーディングの問題とセッションの目的
Gareth： 皆さん、こんにちは。まず最初に会場の皆さんに伺いたいのですが、日常的にエージェント型のコーディングツールを使っている方はどれくらいいらっしゃいますか。……ずいぶん多くの手が挙がりましたね。これは良い兆候だと思います。今日は私たちが開発しているKiroについてお話しできることを、大変嬉しく思っています。
Gareth： 私たちがエージェント型のコーディングツールを見ていて感じることの一つに、これらのツールは大量のコードを非常に速いスピードで生成することに長けている、という点があります。しかしその一方で、非常に苦手としていることがあります。それは、自分たちの組織がどのように動いているかを理解することです。コーディング規約はどうなっているのか、セキュリティのガイドラインはどうなっているのか。こうした組織固有の文脈を理解できないままコードを大量生成してしまうところに、いわゆる「バイブコーディング」という言葉が生まれる背景があります。人々はこれらのツールを使ってとにかく速くコードを生成し、PoCを立ち上げ、それをそのまま本番環境に持っていこうとしてしまうのです。
Gareth： そこで今日のセッションでは、Kiroを使ってどのように再現性のあるアウトプット、つまり自分たちの標準やガイドに沿ったアウトプットを得られるようにするかを、順を追ってご説明していきます。そして後半では、Flutterから実際の現場での活用事例についてお話を伺う予定です。物語としてはこういう流れになりがちです。まず、皆が新しいAIツールに胸を躍らせます。開発者たちは自分の生産性を10倍にできるチャンスを手にし、大量のコードをどんどん書いていきます。そして、こういうことが起きるのです。皆さんのコードベースは大量のコミットにさらされ、それをメンテナーやプロダクトマネージャー、プロダクトオーナーがすべてレビューしなければならなくなります。さらに重要なのは、セキュリティチームがすべての変更内容を確認し、セキュリティガイドラインに準拠しているかどうかをチェックしなければならないという点です。これは決して誇張ではなく、実際に私たちが現場でよく目にする問題です。
Gareth： では、エージェント型のIDEやツールをどのように活用すれば、こうした問題を緩和できるのでしょうか。ここでKiroの出番です。このセッションではKiroについて取り上げ、いくつかの主要な機能を見ていきながら、開発プロセスに対してもう少しコントロールを取り戻す方法を理解していきたいと思います。ここまでバイブコーディングという言葉を使ってきましたが、実際のところKiroは必要な場面でのバイブコーディングにも非常に優れています。ただし、この後Ereneが紹介するように、本当に力を発揮するのはスペック、つまり仕様に基づいた開発においてです。
1.2 Kiroとは何か
Gareth： さて、ここまで何度もKiroという名前を口にしてきましたが、そもそもKiroとは何なのか、というところからお話しします。Kiroは私たちのエージェント型のIDEであり、CLIでもあります。もし画面を見て見覚えがあるという方がいらっしゃれば、それはKiroがオープンソースソフトウェアをベースにしているからです。VS Codeなど、皆さんが普段使っているツールに近い見た目になっているはずです。つまり、既存の設定やお気に入りのプラグイン、テーマなどをそのままエージェントに持ち込むことができるということです。Kiroは個人のためにも、そしてエンタープライズのためにも作られたツールであり、非常に多くの機能を備えています。ダッシュボードやMCPのセキュリティコントロールなど、エンタープライズグレードのセキュリティ機能も組み込まれています。
Gareth： Kiroは非常に機能が豊富なIDEですが、今日はその中でも重要なものに絞ってご紹介します。まずはKiroを支えている土台、つまり基盤となるモデルについてお話しします。次にステアリングという機能、そしてフックと呼ばれる機能、最後にMCPサーバーについて取り上げます。そこから先は同僚のEreneにバトンタッチし、パワー、サブエージェント、そしてスペックについて説明してもらいます。そして最後に、Flutterから実際の現場での活用事例について聞いていきたいと思います。
2. Kiroを支えるモデルとステアリング機能
2.1 モデル選択とKiro Auto、Bedrockによるセキュリティ
Gareth： それでは、Kiroを支えているものについてお話しします。それは基盤となるモデルです。画面をご覧いただくと分かる通り、非常に豊富なモデルの選択肢が用意されています。Anthropicのモデル群がフルラインナップで揃っており、超高速かつ高性能なHaikuモデルから、複雑な推論に適した最大かつ最高性能のOpus 4.6モデルまでカバーしています。また、オープンウェイトのモデルも画面に表示されている通り用意しており、DeepSeek、MiniMax、Qwenといった選択肢もあります。これらは代替となるモデル群になります。そして画面をよく見ていただくと、それぞれのモデルには小さな倍率が付いています。これは、Kiroを使ってモデルを選ぶ際に、モデルによって利用コストが高くなったり低くなったりするためです。これは非常に重要な考慮点で、特に何百人もの開発者を横断的にマネジメントしなければならない大規模な顧客にとっては大切なポイントになります。異なる料金体系のモデルを選択肢として提供することで、皆さんご自身で選べるようになっています。
Gareth： その中でも私が最も重要だと思うのが、Kiro Autoです。これはKiro独自のモデルで、リクエストの内容に応じて最も適切なモデルへ自動的にルーティングする仕組みになっています。例えば、標準的な定型的コードを書いているような、比較的シンプルなタスクであれば、Haikuモデルにルーティングされるかもしれません。逆に、非常に複雑なタスクであれば、より大きなモデルに振り分けられるかもしれません。しかし、最終的にKiro Autoを使うことで得られるのは、予測可能なコストです。画面の右端にある1倍という倍率に注目していただきたいのですが、これがその象徴になっています。そして最後に、これらすべてのモデルはAmazon Bedrockを経由して実行されます。つまり、皆さんが期待する通りのエンタープライズグレードのセキュリティ、プライバシー、コンプライアンスが標準で組み込まれているということです。皆さんのコードがサードパーティのAPIプロバイダーなどに送信されることは一切ありません。すべてAWSのセキュリティ境界内に留まります。
2.2 ステアリングの活用方法
Gareth： 冒頭で申し上げた通り、エージェント型のIDEは皆さんの標準やセキュリティガイドライン、パターンなどを理解するのがあまり得意ではありません。そこで最初にご紹介する機能が、ステアリングです。ステアリングとは、エージェントにより多くの情報を提供するための仕組みです。この情報は本当に何でも構いません。コーディングガイドラインかもしれませんし、何らかの標準かもしれませんし、あるいはエージェントにどのようにコミュニケーションを取ってほしいかという指示かもしれません。例えば、簡潔に、そっけない言い方で、あまり冗長にしてほしくない、といった具合です。私自身の例を少しお見せすると、私はコーディングをする際に決まったディレクトリ構造を持たせるようにしています。そうすることで、すべてがどこに配置されるかを把握できるようにしているのです。こうした指示の重要な点は、エージェントにどう振る舞うべきかを伝えられるだけでなく、開発者としての皆さんのプロセスについても洞察を与えられるということです。プルリクエストはどのように行うのか、コードのコミットはどう行うのか、エージェントは何をすべきで、何をすべきではないのか。例えば、リモートのオリジンにコードをプッシュしてよいのか、プルリクエストをコミットしてよいのか、チケットを更新してよいのか、といったことです。もしこれらを伝えなければ、エージェントは自身が学習してきた内容に頼らざるを得ません。つまり、ステアリングは標準化されたアウトプットを得るための、非常に重要な最初のステップとしての役割を果たすのです。
Gareth： ステアリングを設定する際には、いくつかの異なる方法でデプロイすることができます。一つは、ワークスペースレベルでステアリングを設定するというやり方です。これは、指示に関するドキュメントがすべてリポジトリ内に格納されるということを意味します。つまり、これを何らかのソースコードリポジトリにコミットすれば、そのコードベースで作業する他の全員が同じステアリングルールを共有できるようになります。これは、例えばプロジェクトで使用する言語について合意した場合などに非常に有効です。例えば、Python 3.13を採用すると決めたとして、全員が同じバージョンを使うようにする必要があるとします。それをステアリングに書き込み、プロジェクトレベル、つまりワークスペースレベルに配置すれば、全員が同じステアリングドキュメントを得られるのです。しかし、すべてのプロジェクトを横断して適用したいステアリングやルールがある場合はどうすればよいでしょうか。例えばセキュリティガイドラインなどです。私個人の例で言えば、Webが関わるプロジェクトには必ずSSOを導入するようにしています。これは私にとってグローバルレベルで適用すべき事項です。グローバルなステアリングドキュメントを一つ持っておけば、Kiroを開くたびに、どのプロジェクトを開いていても、Webページを作成してほしいと頼めば、SSOが必要だということをエージェントが理解してくれるのです。さらに、これらを中央で保管し、MDMやWindowsであればグループポリシーといった仕組みを通じて配布することで、開発者たちが常に最新のコーディングガイドラインやセキュリティガイドラインなどを確実に手にできるようにすることも可能です。
Gareth： ステアリングに関するもう一つの重要な要素が、除外フラグです。これが重要な理由は、モデルにはコンテキストウィンドウという制限があるからです。コンテキストウィンドウをできる限り小さく保ち、その時点でエージェントが必要としない情報で埋め尽くさないようにすることが非常に重要になります。デフォルトでは、すべてが常に含まれる設定になっています。しかし、次の選択肢として手動という設定があります。これは、ステアリングドキュメントを作成し、そこにルールを盛り込んでおいて、それらが適用されるのはトリガーを引いたときだけ、という仕組みです。これは先ほどの動画にあったようなスラッシュコマンドを通じて行われる場合もあれば、皆さんが手動でそのファイルを参照する場合もあります。さらに、自動という設定も可能で、ステアリングファイルに説明文を付けておくと、エージェントがその説明をもとに、いつそのファイルを利用してコンテキストに含めるべきかを自ら判断してくれます。そして条件付きという設定もあり、これは特定のファイルやファイル名、ファイルタイプなどに紐づけることができます。最後に常時適用という設定があり、これはすべてのケースで常にステアリングが適用される仕組みになっています。
3. フック・MCP・パワー機能
3.1 フック機能
Gareth： 次にご紹介したい機能は、フックです。フックとは、開発者のワークフローやプロセス、複雑なタスクであれ単純なタスクであれ、それらを自動化するための仕組みです。自然言語でKiroに話しかけることで、あるトリガーに基づいてアクションを生成させることができる、というメカニズムを提供するものです。ここでの例では、ユーザーがエージェントにコードのコミットを行うよう依頼すると、そのタイミングでフックが実行され、READMEとチェンジログが自動的に生成される、という仕組みになっています。非常にシンプルな例ですが、フックにはいくつかの種類があります。まずファイルベースのフックです。これは、CRUD形式のイベント、つまりファイルの作成、読み取り、更新、削除といった操作をトリガーにしてアクションを実行するものです。次に、コンテキストベースのフックがあります。これは、エージェントが何らかの操作を行ったとき、例えば興味深いツール呼び出しを行ってレスポンスを得たときや、実行が完了したときに発動するものです。実行が完了するたびに何かを出力させたり、別の処理を行わせたりすることができます。そして最後に、手動フックがあります。これは文字通り、フックを作成しておいて、それを手動で実行するというものです。
3.2 MCPの仕組みと運用
Gareth： 今日ご紹介したい最後の機能が、MCP、すなわちModel Context Protocolです。MCPをご存じない方のために説明すると、これは要するに、エージェントに本来備わっていなかった何らかの操作を行わせるためのツールを与える仕組みです。例えば、GitHubやJira、Confluenceなどとやり取りするMCPがあるとします。Kiroにはネイティブでそうした機能は備わっていませんが、MCPサーバーを使うことでその機能を拡張することができます。これはKiroに直接組み込まれており、ステアリングと非常によく似た仕組みで、エージェントをデプロイする際に二つの異なるレベルで設定することができます。一つはプロジェクトレベル、あるいはワークスペースレベルです。もう一つはユーザー設定レベルです。ワークスペースレベルで考えると、例えば皆さんがアプリケーションを構築していて、Agent Coreを使っており、AWSが提供するAgent Core用のMCPサーバーを使っているとします。それをそのプロジェクトと一緒にまとめて保存しておけば、同じリポジトリを使う他の開発者も同じMCPサーバーを利用できるようになります。全員が作業を始める前にそれぞれインストールしておく必要があるかどうかを心配する必要はありません。ユーザー設定レベルについても同様です。こちらはグローバルな設定で、例えば皆さん自身がタスク管理にJiraを使っていたり、課題管理にGitHubを使っていたりする場合、それをグローバルにインストールしておけば、皆さんが使うすべてのKiroのインスタンスで常にアクセスできるようになります。
Gareth： 続いて、環境変数についてです。ここにはAPIキーなどを埋め込むことができます。変数展開も可能なので、キーそのものを直接書き込む必要はなく、参照する形で済みます。つまり、APIキーをソースコードに直接書き込んでしまう心配をせずに済むということです。そして最後に、Auto-approve機能があります。これは、安全だと判断できるコマンドについては自動承認と設定しておくことで、エージェントが毎回確認を求めることなく自動的に実行してくれるようになる機能です。さらに、認証が必要なMCPサーバーのためのOAuthサポートも用意されています。そして、KiroのWebサイト上には、ワンクリックでのサポート統合機能もあります。これは、よく使われるMCPサービスの一覧で、JSONファイルを直接いじる必要なく、ワンクリックでインストールできるようになっています。ただし、MCPサーバーはKiroに追加のツールや能力を与えてくれる非常に優れた仕組みである一方で、ステアリングと同様に、コンテキストに関する課題を抱えています。MCPサーバーを一つインストールするたびに、そこにはおそらく複数のツール、場合によっては数十個のツールが含まれています。そして、それぞれのツールには説明文が付いており、そのすべてがコンテキストに読み込まれてしまいます。もしツールの数が多すぎれば、実際には必要とされていない情報でコンテキストの多くが消費されてしまうことになります。もちろん、JSONファイルを編集して個々のツールをオン・オフすることもできますが、多数のツールに対してそれを行うのは非常に手間がかかります。しかも、エージェントに何かを依頼する前に有効化しておくことを覚えておかなければならず、プロセス全体が遅くなってしまいます。そこで登場するのが、パワーという機能です。ここからはEreneにバトンタッチして、この機能について説明してもらいたいと思います。
3.3 パワー機能
Erene： ありがとうございます、Gareth。ここまでMCP、ステアリングファイル、フックといった、素晴らしいツール群についてお話ししてきました。ですが、Garethが述べていた通り、私たちはもう一歩先に進みたいと考えました。そこで私たちは、次の二つの問いを自分たちに投げかけました。一つ目は、人間が介入することなく、Kiroがいつ、どのようにこれらのツールを使うべきかを、どうすれば理解させられるかということです。二つ目は、Kiroが実際にこれらのツールを使う際に、そのツールにおけるベストプラクティスを確実に守らせるには、どうすればよいかということです。これらの問いに答えるために生まれたのが、パワーという機能です。
Erene： パワーとは、Kiroが複数のツールを使いながら、ベストプラクティスやガイダンスに従い続けられるようにする仕組みです。私たちはPostman、Stripe、Figmaをはじめとする様々なISVパートナーと提携し、皆さんが正しいパワーを手にして、キュレーションされたベストプラクティスやガイドラインに沿った形で、これらのツールを実行できるようにしています。しかも、毎回人間がループの中に介入する必要はありません。パワーという言葉を使うとき、それはフックを含む場合もあれば、MCPを含む場合もあり、ステアリングファイルを含む場合もあります。それは本当にケースバイケースです。また、皆さん自身でパワーを作成し、チーム全体で共有することも可能です。これにより、組織全体で共有できる知見を作るための、非常にシンプルなアプローチが実現できます。
Erene： それでは、実際にこれがどのように動作するか見てみましょう。画面には様々なプロバイダーが表示されていますが、私たちは今もこのラインナップを拡張し続けています。画面の一番上をご覧いただくと、私たちAWS自身が提供するパワーもあります。それでは実際にKiroとチャットを始めて、エージェントであるStrandsとAgent Coreを使って天気アプリケーションのチャットを作成するよう依頼してみます。ここで注目していただきたいのは、私が事前にどのパワーを選択しているわけでもない、という点です。それにもかかわらず、Kiroは私のリクエストの内容から判断して、必要なパワーを自ら判断し、コンテキストに配置することができます。これは非常に画期的なことです。私たちはもはや、Kiroに対してどのようなツールを持っているかを理解させるために、すべてのMCPを常にコンテキストに載せておく必要がなくなりました。その代わりに、リクエストの内容に応じて、動的にそれらを読み込むことができるようになったのです。これによって、コンテキスト管理が格段に容易になります。
4. サブエージェントとスペック駆動開発
4.1 サブエージェントによる並列実行
Erene： 続いて二つ目の機能に移りたいと思います。最近リリースしたばかりの機能で、サブエージェントと呼んでいるものです。サブエージェントによって私たちが手にするのは、並列実行エンジンです。もはやKiroにタスクを逐次的に実行させるために待ち続ける必要はなく、Kiroは複数のタスクを並列に実行できるようになります。それぞれのサブエージェントは、それぞれ独自のコンテキストウィンドウを持ちます。これはコンテキスト管理という観点から見ても、まさに画期的な変化です。なぜなら、これによって私たちはもはや、一つのタスクと一つのエージェントが70%の進捗にまで達してしまい、そこでチャット履歴を要約しなければならなくなり、それまでKiroと話していた内容をもう一度繰り返さなければならなくなる、という状況に対処する必要がなくなるからです。おそらく皆さんも、こうした経験をされたことがあるのではないでしょうか。サブエージェントをうまく使いこなせば、こうした問題はもはや起こらなくなるかもしれません。
Erene： 例えば、フロントエンド用のサブエージェントを一つ、バックエンド用のサブエージェントを一つ、セキュリティ用のサブエージェントを一つ、といった形で用意することができます。そしてそれぞれが、独自のコンテキストウィンドウを持つことになります。最終的に、すべての結果が集約され、皆さんの手元に最終的なソリューションとして届けられる仕組みになっています。Kiro内では、先ほど申し上げた通り、皆さん自身の組み込みエージェントを持つことができます。画面にあるように、ツール、モデル、説明文、名前、そしていくつかの指示といったパラメータを記載したYAMLファイルを作成するだけで、これを実現できます。ただし、こうしたカスタムエージェントを一から作らなくても、Kiroにはすでにいくつかのデフォルトエージェントが用意されています。例えば、コンテキスト収集エージェントや、汎用的なデフォルトエージェントなどです。
4.2 スペック駆動開発の必要性
Erene： ここまでご紹介してきた機能は、いずれも素晴らしく、皆さんのAIジャーニーを大きく前進させてくれるものです。しかし、一つ重要なステップが欠けています。それは、たとえ100個のパワーを持っていようと、10個のMCPを持っていようと、7個のサブエージェントを持っていようと、それらすべてがきちんとキュレーションされていようと、もし皆さんがAIに対して曖昧なプロンプトを送ってしまえば、得られる結果もまた曖昧なものになってしまう、ということです。例えば、Kiroのチャットに「トリビアアプリを作って」とだけ入力したとしましょう。おそらくKiroは、そしてどのAIであっても、最善を尽くして何らかのアウトプットを生成しようとするでしょう。しかし、そこで下される決定事項の幅があまりにも広いため、そのアウトプットが皆さんの頭の中にあったイメージに近いものになる可能性は、非常に低くなってしまいます。結果として、例えばAngularで構築された巨大なコードリポジトリができあがってしまい、実は皆さんが本当に欲しかったのはNext.jsだった、というようなことが起こり得ます。そして皆さんは、その巨大なコードの塊を相手に、何度も反復修正を重ねなければならなくなるのです。
Erene： 私たちは、これをもっと良い形にできると考えました。そこで登場するのが、スペック駆動開発です。スペック駆動開発では、状況が大きく変わります。最初のステップは同じで、Kiroにプロンプトを送ります。しかし、Kiroはいきなりコードを組み立てるのではなく、まず私たちが「スペック」と呼ぶものを生成します。もし皆さんがソフトウェアエンジニアリングについて考えてみれば分かる通り、ソフトウェアエンジニアはプロダクトの要求を受け取って、いきなりコードを書き始めて組み立てるようなことはしません。まず計画を立て、設計を行い、それから実行に移ります。私たちはKiroにおいても、まさに同じプラクティスに従っているのです。
4.3 スペックの構成要素と作成パスの選択
Erene： スペックには、要件、設計、タスクが含まれますが、全体としては、皆さんが最終的な機能としてどのようなものを実現したいのかを記した文書だと言えます。つまり、私たちが得られるのは、巨大なコードベースを相手に反復修正を行う代わりに、スペックを相手に反復修正を行えるということです。これは、より少ないコンテキストで反復できるためスピードが向上するだけでなく、ソフトウェア開発における一般的なベストプラクティスを忠実に再現しているという点でも優れています。それでは、スペックの構造について見ていきましょう。スペックの最初のパートは要件です。要件とは、プロダクトの観点から見た皆さんの機能のスナップショットのようなものだと考えてください。ユーザーストーリー、受け入れ基準、成功指標、そしてエッジケースが含まれます。この文書は、まさにプロダクトマネージャーやデザイナー、ソフトウェア開発者たちが、自分たちにとって良い機能とはどのようなものかを考える場になります。要件に納得できたら、次にKiroは設計文書に進みます。設計文書は技術的な文書であり、アーキテクチャ図、技術スタックの選定、セキュリティ要件、テスト戦略、APIの契約仕様などが含まれます。構築されるアプリケーションに関わるあらゆる非機能要件が、要件を踏まえた形でこの設計文書にマッピングされていきます。そして最後に、タスク文書があります。タスク文書は実装ステップとなるものです。Kiroが最終的な成果物にたどり着くために行うべきことすべてが、ここに記されます。これはタスクとサブタスクに分解されるため、Kiroはすでに完了したタスクを理解しながら進めることができます。これは、事前に生成された要件と設計に基づいて作成され、すべてが同じコンテキストの上に構築されます。もちろん、どの段階でもフィードバックをもとに反復修正することが可能です。設計に進む前に要件を反復修正することもできますし、タスクの段階まで進んでいたとしても、必要であればいつでも前の段階に戻って反復修正することができます。
Erene： 最近発表した内容の一つに、Kiro内でスペック駆動開発を進めるための、複数の異なる方法があります。というのも、すべてのプロジェクトが同じではないことを私たちは理解しているからです。新しい機能を作成するのか、すでに存在するものを修正するのかによって、私たちはこの決定木を用意し、どのタイプのスペック駆動開発を選ぶべきかを分かりやすくしています。新しいものを作成するのであれば、おそらく機能スペックを選ぶことになるでしょう。すでに存在するものを修正するのであれば、バグスペックというパスに進むことになります。これは機能スペックと非常によく似ていますが、最初の文書がバグ修正文書となっており、要件文書とは少し異なる目的を持っています。機能スペックのパスの中でも、新しいものを作成する際には、さらに二つの異なるパスが存在します。一つは、要件優先のパスです。これは、アーキテクチャについてまだ柔軟性がある場合や、技術スタックについてまだ決定していない場合、あるいはプロダクト主導型の組織で作業している場合に理想的です。逆に、すでにアーキテクチャが定義されている場合や、従わなければならない非常に厳格な非機能要件がある場合には、設計優先のスペックというパスを選ぶことになります。これは実質的には順序を入れ替えるだけなのですが、最終的なタスクの結果を見ると、実はそれが大きな違いを生むのです。
4.4 良いスペックを書くための心得
Erene： スペックがどれだけ優れた仕組みであっても、ここで皆さんにお伝えしたいことがあります。それは、曖昧なスペックは結局のところバイブコーディングと変わらない、ということです。これはどういう意味でしょうか。もし私たちがスペックを作成する際に曖昧なプロンプトを与えてしまい、なおかつ自分たちが作成したスペックをレビューしなければ、Kiroは決して魔法のようなことはしてくれません。私たちは依然として、Kiroが作成しているものをレビューする必要がありますし、スペックを作成するためにKiroに送った最初のプロンプトが、意味のある、そして十分な情報を含んだものになっているかどうかを確認する必要があります。
Erene： 例えば、自分たちの組織における「チケット」とは何を意味するのか。「handle(処理)する」とはどういう意味なのか。それは誰かに何かを送ることを意味するのか、読むことを意味するのか、削除することを意味するのか。組織固有の様々な連携やセキュリティ統合とは、具体的にどのようなものなのか。Kiroはそうした情報をどこで見つけられるのか。こうした問いに対する答えはすべて、Kiroがスペックを作成する際に本当に良い仕事をしてくれるかどうかを左右する、最終的に非常に重要な要素になります。私自身、良いスペックや良いプロンプトについて考えるとき、それはまるで、チームに新しく加わったオンボーディング中のエンジニアにメッセージを送って、新しいタスクを依頼するような感覚だと捉えるようにしています。この新しく入ったエンジニアは、おそらく自分たちの会社の用語や、データがどこにあるのか、これまでどのように構築してきたのかについて、まったく文脈を持っていません。ですから、Kiroにプロンプトを送るときには、Kiroを新しくオンボーディングされたエンジニアだと考えて、皆さんの機能を成功させるために必要な情報をすべて持たせてあげることを意識していただきたいと思います。
5. Flutter事例：Kiro導入のきっかけ
5.1 Flutter社の紹介と課題設定
Erene： それでは、KiroがFlutterに与えた影響について、JohnとStuからお話を伺いたいと思います。ありがとうございました。
John： 皆さん、こんにちは。私はJohn Kellyです。AWSでプリンシパルCSMを務めております。本日は、Flutterから来てくれたStu Norrisと一緒にお話しさせていただきます。Stu、まずFlutterについて少し紹介してもらえますか。
Stu： はい、こんにちは。私はStu Norrisです。Flutter CEでディレクター・オブ・エンジニアリングを務めています。皆さんもご存じのブランドがいくつかあると思いますが、Paddy Power、Betfair、Tombolaといったブランドを展開しているほか、AjarbetやMaxBetのようなグローバルブランドも展開しています。今日は皆さんに一つの物語をお話ししたいと思います。これは決して洗練されたケーススタディではなく、実際に起きたことであり、その多くは計画されていたものではありませんでした。
Stu： 私たちはある課題から出発しました。Johnやそのチームとミーティングを持ったのですが、そこで話していたのは、エンジニアをトレーニングし、標準に引き上げ、それを定着させようとしているという話でした。私たちが検討していたことの一つが、そのトレーニングをどうやって本当に人々に根付かせるかということでした。どうすればそれが定着するのか。「これがコードです、こうやってコードを書くんです」と言うだけでは、定着しないのです。私たちはただそうした会話を重ねていました。どうすればハンズオンのツールを手に入れられるのか。そんなものは存在するのか。Amazonはこれを私たちに提供できるのか。それは長らく解決されていない課題でした。
5.2 30分デモから2時間の深掘りへ
Stu： そうしているうちに、たまたまJohnが私にKiroのデモをしに来てくれることになったのです。私はそれまでKiroを見たことがありませんでした。そこから話が展開していきました。
John： そうですね。あのセッションは30分間のセッションでした。今日皆さんにお見せしたのと同じように、概要を紹介するだけのものでした。Stuと、それからデリバリー担当のアソシエートディレクターであるClaireも同席していました。この二人はどちらも技術的な素養はあるものの、実際の開発経験はありませんでした。
John： その30分間で私がやろうとしたのは、モックアップを一つ提供することでした。Terraformの例、つまりFlutterにとって実際にある課題を取り上げ、Stuと一緒にスペック駆動開発を使ってモックアップを作り上げる、ということに取り組みました。そして実際にそれを達成できました。30分以内にモックアップができあがったのです。私はそれでミーティングは終わりだと思っていたのですが、Stuには別の考えがあったようですね。
Stu： そうなんです。念のため申し上げておくと、私にも一応ハンズオンのエンジニアリング経験はありました。ただし、それはずいぶん昔の、いわば「白黒の時代」の話で、今ではほとんど関係のないものです。しかし、その30分間のデモでKiroが何をできるのかを見て、私の中で本当に火がついたのです。それはスペック駆動という発想そのものでした。実際にやってみて分かったのは、私自身が非常に曖昧なスペックで作業していた、ということです。それは正直に認めます。そこから私は学び始めました。Kiroが質問を投げかけてくるので、それは私自身が本当の意味で明確に意図を伝えられていなかったからなのですが、それが逆に興味深い経験でした。というのも、私は自分が何をすべきかを、自然な言葉で話しながら理解できるようになっていったからです。そして2時間後には、私のような熱心な素人であっても、モックアップではなく、実際に使える本物のものにまでたどり着いていました。
Stu： それこそが、私を本当に興奮させたポイントでした。Kiroはただコードを書くだけではなく、その決定の理由を説明してくれたのです。それが、その後私がこれをチームに定着させ、私たちの優秀なチームがその恩恵を本当に受けられるようにしよう、と考えるようになった大きな転機でした。
John： そしてStu、あなたはそこで止まりませんでしたよね。
5.3 追加学習とデモ動画の内容
Stu： ええ、そうなんです。私はもっとやりたいと思いました。もっと学び、理解を深めたいと思ったのです。そこで、いくつかのものを追加していきました。スペック駆動開発について学んだのに加えて、AWSのMCPサービスを使ってリアルタイムのドキュメントを取得する方法も学びました。これによって、常に最新の情報を反映させることができ、単なるアイデアや「これで良さそうだ」という段階から、実際に使えるものへと変えることができました。常に最新版のドキュメントを取得し続けること、そしてスペック駆動開発を活用することで、新機能、セキュリティ機能、コスト最適化といったものを素早く追加できるようになりました。これは、単にコードを使うだけでなく、実際にリアルなアプリケーションを構築し始める際に考えなければならないことを、思考として促してくれるものでした。
Stu： そうしてできあがったのが、まさにこれです。言葉で説明するよりも、実際の動画をご覧いただいたほうが早いと思います。UIについては見た目のことは気にしないでください、私の専門ではありませんので。ただ、これは本当にハンズオンのツールなのです。人々に学びを与え、考えさせるためのものです。この中にはいくつもの例が含まれています。これらはすべて、私自身が「例を作ってほしい」「人々がクリックできるようなものを作ってほしい」と依頼して作られたものです。それによって、コードを生成する思考のきっかけを作ることができました。皆さんはこの中から好きな例を選ぶことができ、自然言語を使って追加の指示を加えることができます。これはエンジニアだけのためのものではありません。学びたいと思っている誰にとっても、それを民主化しようとする試みなのです。
Stu： そして実際に、そのコードを生成してくれます。もちろんこれはBedrockと連携しているので、きちんとしたコードが生成されます。ただし、本番環境に持っていくのであれば変更が必要な部分も当然出てきます。これはあくまで学習のためのツールです。ですから、ここで生成されたTerraformのコードについて、誰も批判しないでいただきたいと思います。むしろ狙いは、コメントを追加して、「本来はこういう見た目であるべきだ」ということを示すことでした。例えば、シークレットマネージャーを使うべきだとか、変数をハードコーディングしてはいけないといったアイデアです。そこからさらに、ドキュメントを見せてもらったり、「ハイレベルなアーキテクチャ図はどのようなものになるか」「どのような設定を考慮すべきか」「どのようなツールを使っているのか」「コストはどれくらいかかるのか」「どのように監視するのか」といった、実際の現場に即した説明を加えていきました。誰でもどこかのWebサイトからコードをコピー&ペーストすることはできます。しかし、それでは人々に何も教えたことにはなりません。スキルを身につけさせることにも、AWSと一緒に行っているトレーニングを組織に根付かせることにもならないのです。それこそが、この取り組みの本質でした。それは思考を促すためのものでした。しかし、これは私自身にとっても、Kiroに対する好奇心と強い関心を呼び起こすものになりました。
Stu： そして私は、これを私たちの非常に優秀なチームに渡したいと思うようになりました。私よりもはるかに上手くこれを使いこなせるだろうと分かっていたからです。こうして、Terraformの機能を実際に開発し、それを本番運用可能なレベルにまで持っていけることを、私、いや実際にはStu自身が証明した形になりました。では、それがFlutterにとってどのような助けになったのでしょうか。次の課題は、ソフトウェア開発ライフサイクルの中にAIを組み込むことでした。
6. Flutter事例：3日間イベントによる本格導入
6.1 決済チームでの実践
Stu： そこで私たちが行ったのは、3日間のイベントを開催することでした。ここでも、Flutterにとって実際に存在する課題を取り上げました。今回対象にしたのは決済チームです。彼らは数多くの決済プロバイダーとの統合作業を行っており、通常であればエンドツーエンドで2ヶ月ほどかかる作業です。私たちは二つのユースケースを取り上げました。一つはグリーンフィールド、つまりこれまで一度も統合したことのない新しい決済プロバイダーです。もう一つはブラウンフィールド、つまりすでに統合済みの決済プロバイダーに対して、多くの機能追加や変更を加えるというものです。この二つのユースケースにチームを分け、それぞれ二つのチームを編成しました。そして、文字通りの意味で「AIを、具体的にはKiroを、ソフトウェア開発ライフサイクルのあらゆる部分に組み込む」ことに取り組んだのです。決済統合には実際には50を超えるステップがあるのですが、大まかに言えば、私たちはプロジェクトのプロダクト要件から始めて、そこから作業を進めていきました。画面の上部にURLが表示されていますが、そこにアクセスすればステアリングファイルをすべて入手し、皆さん自身のKiro環境に取り込んで、ご自身のセッションで実行することができます。実行すると、まず数多くの質問が投げかけられるところから始まります。
Stu： 私たちがこの取り組みを通じて見出したのは、いくつかの驚くべき事実でした。一つは、あるエンジニアが数分でMermaid図を作成できることに非常に興奮していたことです。これは私たちがまったく想定していなかった反応でした。もう一つ見えてきたことは、二つのチームのうち一方は非常に良質なコードを得られ、すべてが順調に進んでいたのに対し、もう一方のチームはそうではなかった、ということです。そこで私たちは、なぜもう一方のチームが単に一般的で汎用的なアウトプットしか得られなかったのかを検証しました。その結果分かったのは、Garethが先ほど述べていたのとまさに同じで、最初のチームは最初に投げかけられた質問に対して、正しい情報を与えていたということでした。具体的には、Flutter固有の情報、つまりコーディング規約や命名規則、サービスの一覧といったものを入力していたのです。そのため、返ってくる答えもFlutterに特化したものになっていました。一方のチームは、とにかく早く進めることを優先してしまい、非常に一般的な答えしか得られていませんでした。ここから多くの気づきが得られ、そして良い成果も生まれました。
6.2 成果指標とチームの変化
John： それで、その成果はどのようなものだったのですか、Stu。
Stu： これが完了したのは、ちょうど今日からさかのぼって2週間前のことです。そして画面にあるように、通常であれば1週間から2週間かかる作業を、2日半の工数で完了させることができました。付け加えておくべき点として、これはチームにとってまったく初めて触るツールだったということです。したがって、その時間の多くはツール自体を学ぶ時間に費やされていました。それでもなお、これは本当に驚異的な効率向上でした。そして重要だったのは、チームが非常に強い関心を持ってこの取り組みに取り組んでくれたことです。当初は「これは自分たちにとって何を意味するのか」という若干のためらいがあったのですが、それが「この仕組みが何をしてくれるのか理解できた」という状態に変わっていきました。
Stu： これは本当に驚くべきことでした。そして、これは統合のタイムラインを短縮できるという話だけではありません。今朝の基調講演でも申し上げた通り、「スピードは選択の結果である」ということです。物事を速く進めることはできますが、それよりも、再現性があり、再利用可能で、コンプライアンスに準拠した形で、物事を正しく進めるほうが良いのです。そして、それこそがこの取り組みから得られたものでした。私が最も重視している指標は、まさに品質や再現性といったものです。私たちはこの取り組みを通じてプレイブックを手に入れましたし、本当に強い関心を持ったチームを得ることができました。それも素晴らしいことでした。これは単にエンジニアや開発者だけの話ではありません。プロダクト、テクノロジー、テスティングなど、チーム全体が一緒に取り組んだのです。
Stu： そして全員が、このツールで何ができるのかを実感していきました。あるメンバーは「これはもう私たちの日常のやり方そのものだ」と言っていました。Kiroはまるでチームの一員のような存在になったのです。私自身も、Confluenceでメンバーの誰かがどうしてもMermaid図を気に入ってしまい、そのためのアクセス権限を承認しなければならないという場面もありました。それくらい、人々が「これは本当に素晴らしい、新しいものだ」と言うようになっていったのです。そして、それこそが私にとって本当にワクワクする部分でした。チームが何かに興奮し、新しいアイデアを次々と生み出していく様子を見られたことが、何より嬉しかったのです。
7. 今後の展開とまとめの教訓
7.1 スケーリングの取り組み
John： それでは、これをFlutter全体にどうスケールさせていく予定ですか。今後もいくつかセッションが予定されていると思いますが、他に取り組んでいることはありますか。
Stu： 決済チームは、まさに先駆者としての役割を果たしてくれています。彼らはこの取り組みを他の人々に広め、すでに周囲に働きかけを始めています。実際、私のところにはすでに、Kiroへのアクセス申請がどんどん増えてきています。「自分たちも使いたい」「このチームでも使いたい」という声が寄せられているのです。決済チームのメンバーに「実際どうだった」と尋ねると、多くのフィードバックが返ってきました。「このコードベースを見て新しいドキュメントを作成する、といった使い方も常にできる」といった具合に、本当に様々なアイデアが出てくるようになりました。
Stu： そして、他の部門からも、私たちが何をしたのか、どうやったのか、どうすればコンプライアンスとセキュリティを保ちながら進められるのか、そしてどんなエキサイティングで革新的なことができるのか、といったことについて話し合う人たちが出てきています。これはまさに日々進化している最中の取り組みであり、私たちは自分たちの非常に優秀なチームとともに、その最前線に立ち続けたいと考えています。そのために、これをすべてのブランド、グループ全体、様々な国々に向けて発信し、私たちが何をしたのか、なぜそれをしたのか、そしてそれがどれほど成功したのかを、きちんと説明していきたいと思っています。
7.2 重要な教訓のまとめとセッションの締め
John： それでは、皆さんが得た重要な教訓は何でしょうか。
Stu： まず一つ目は、実際の課題から始めるということです。テクノロジーそのものから始めてはいけません。なぜなら、AIツールというものは、毎日毎日、何ヶ月にもわたって次々と選ぶことができてしまうからです。そういうことをしてはいけません。自分たちが抱えている課題は何かを見極めることが大切です。専門知識を組み込むためにツールが必要になるのであって、そこが本質なのです。それはチームの専門性そのものです。人々をそれに対して興奮させること。実際の課題から始めること。Terraformは一つの例に過ぎませんが、決済統合はまさに本物の課題でした。これは痛点であり、それをどう改善するかということだったのです。非常に速くプロトタイピングできるということも、非常に重要な点だと思います。
Stu： 物事を人々の目の前に提示することです。人々に実際に見てもらうこと。口頭で説明するのではなく、どこかのWikiに置かれて誰にも読まれずに終わっていくような文書に書き記すのでもなく、生きた、息づいているものを人々の前に提示することです。そうすればフィードバックが得られ始めます。私たちは皆、エンジニアリングチームやプロダクトチームと一緒に働いてきた経験があると思いますが、そうすれば必ずフィードバックが返ってきます。スペック駆動開発は、エンジニアだけにとどまらず、それを超えて広がっていくものです。これはエンジニアのためだけのツールではありません。これはビジネス全体、あらゆる人のためのツールなのです。非技術者であっても、開発ライフサイクル全体を通じて関与することができます。冒頭でJohnが私のことを「非技術者」と紹介してくれましたが、それは光栄なことでした。
Stu： 今もこうして関わり続けられることを、嬉しく思っています。しかし私が本当に伝えたいメッセージは、エンジニアリングチームやプロダクトチームを運営している皆さんに向けたものです。自分たちの取り組みを制限しないでください。これは本当にワクワクするようなツールです。無理に盛り上げようとしているわけでも、義務的な熱意でもありません。私は本気で、これが大きな違いを生み出すものだと思っています。もし特定の領域だけに限定してしまったり、「これは特定の人たちのためのものだ」としてしまったりすれば、あらゆる分野にわたる大きな恩恵を逃してしまうことになります。
Stu： そして、こうしたツールを使うことで、チームが一つにまとまっていくということも付け加えておきたいと思います。人々が一緒に働くようになるのです。バラバラに分散していたチーム同士の結束が生まれる、これも非常に大きな成果です。ですから私からのメッセージとしては、まず見てみること、そして人々に実際に使わせてフィードバックを得ること、そしてそこから、自分たちが本当に解決できる現実の課題に目を向けていくことです。そうすれば、皆さんは本当に大きな一歩を踏み出せるはずです。
John： Stu、今日は皆さんにお話をしていただき、本当にありがとうございました。そして、このセッションにお越しいただいた皆さん全員にも、感謝申し上げます。会場にQRコードが表示されていますので、このセッションを楽しんでいただけた方は、ぜひスキャンしてください。もし楽しめなかったという方も、それでもスキャンしていただければと思います。それでは、皆さん、本当にありがとうございました。