re:Invent 2025: Kiro powersによるエージェント開発の専門機能拡張とMCP統合
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - [NEW LAUNCH] Kiro powers: Empower agents with specialized expertise (DVT343)
この動画では、ArundeepとDanがKiro powersについて解説しています。Kiroは開発から本番環境までを対象としたagentic IDEで、EARS syntaxを使用した仕様作成からデザインアーティファクト、タスクへの展開を実現します。新機能のpowersは、MCPサーバー、ステアリングファイル、フックを含むパッケージで、Figma、Supabase、Stripe、Neon、Datadog、Netlifyなどのパートナーと協力して開発されました。powersはユースケースに特化したコンテキストを提供し、コンテキストの肥大化を防ぎながらベストプラクティスに沿った開発を可能にします。ライブデモでは、Neon powerを使用してNext.jsアプリケーションにバックエンドデータベースを追加し、Netlify powerでデプロイするまでの一連のワークフローが実演されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Kiroの紹介：AIがもたらすソフトウェア開発の進化とagentic IDEの登場
皆さん、こんにちは。本日最後のプレゼンテーションまでお付き合いいただき、本当にありがとうございます。私の名前はArundeepと申しまして、KiroのSenior Solutions Architect Managerを務めております。本日はKiro powersについてお話しさせていただきます。そして今日はDanも一緒に参加しております。皆さん、こんにちは。私の名前はDan Kiunaです。KiroチームのSpecialist Solutions Architectを務めております。それでは、始めていきましょう。
まず、Kiroとは何かについてお話しします。ちょっと手を挙げていただきたいのですが、Kiroについて聞いたことがある方はどれくらいいらっしゃいますか。素晴らしいですね。私が正しい場所でプレゼンテーションをしているか確認しているだけです。既存の状況と課題についてお話しし、その後Kiro powersとは何かについてお話しします。最後にライブデモで締めくくります。私たちはagenticな信念の飛躍を遂げており、今日デモがライブで動作することを願っています。
それでは、Kiroとは何かについてお話ししましょう。Kiroとは何かをお話しする前に、AIがソフトウェアをどのように変えてきたかについてお話ししましょう。 まだ3年しか経っていないとは信じられませんが、generative AIのエコシステムと状況全体において、非常に多くのイノベーションが起こるのを目の当たりにしてきました。私たちはオートコンプリートから始まりました。つまり、IDEで関数がオートコンプリートされることに最後に興奮したのはいつだったか、覚えていますか。これにより、開発者はより速くコードを書けるようになりました。
2024年には、エージェントアシスタンスの時代が到来し、エージェントがより大きなコードの塊を支援するようになりました。今では完全なモジュール、関数、SDKを持つことができ、チャットアシスタントと会話することで質問に答えることができるようになりました。そして2025年には、イノベーションがさらに一歩進み、エンドツーエンドで開発タスクを完了できるようになりました。ゼロからフルスタックアプリケーションを書いたり、プロジェクト全体の移行やモダナイゼーションを行ったりといった、より複雑なタスクを、常に人間をループに入れながら、エンドツーエンドで実行できるようになりました。
しかし、AIエージェントを完全に活用できるとしたら、完全な開発体験はどのようなものになるでしょうか。そこでKiroの登場です。Kiroは、開発から本番環境までを対象に構築されたagentic IDEです。Kiroのユニークな価値提案は、specsを作成できることです。これは、要件をmarkdown形式で展開するための仕様を作成することです。Easy Approach to Requirements Syntax、つまりEARS syntaxを使用しています。私はこの頭字語を何度も暗記してきましたが、EARS syntaxを使用して要件を提示し、その要件がデザインアーティファクトに変換され、その後、エージェントによって実装される必要があるすべてのタスクにscaffoldされます。
さて、なぜこれが重要なのでしょうか？エージェントは以前からコードの行数を書いて本番コードを作成できなかったのでしょうか？はい、できました。しかし、エージェントはエージェントループに入ってしまうんです。なぜなら、エージェントは別の方向に逸れていってしまうからです。エージェントによって作成されたコーディングには構造がありませんでした。そこで私たちは、最初のステップとしてソフトウェア開発ライフサイクルに向かうこと、そして過去にどのようにソフトウェアを作成し生産してきたか、そしてそれをどのようにエージェントに与えて構造化されたアプローチに従わせることができるかを考えました。それがKiroなんです。
Kiroの機能概要と専門的開発における課題：ジェネラリストからスペシャリストへ
機能の簡単なおさらいをさせてください。今週Kiroの複数のセッションに参加されていなくても、全く問題ありません。今日Kiro内に存在するすべての機能について簡単におさらいします。スクリーンショットの右側に、エージェントが見えます。これがエージェントとの主要なインタラクションモードです。これは別のサイドバーチャットです。vibeモードでエージェントとチャットすることでvibeプロンプティングやvibeコーディングができますし、specモードを使うこともできます。specモードでは自然言語でプロンプトを入力してspecを作成し、オーサリングできます。プロンプトを生成すると、Kiroフォルダに生成されたアーティファクトを確認できます。
左側のペインには、MCP設定もあります。ローカルMCPまたはリモートMCPと統合でき、OAuthを使用したMCP統合のための追加機能も追加しました。そして、エージェントが別の方向に進んでしまうことは珍しくなく、エージェントを特定の方向に導きたいと思うでしょう。そのためにステアリングルールがあります。ステアリングはマークダウンファイルのルールセットで、特定の動作のためにエージェントをガイドできます。例えば、Pythonプロジェクトで作業していて、テストに特定のフレームワークを使いたい場合、ステアリングファイルに行を追加して、常にpytestを使用する、常にこの形式で使用すると言えば、エージェントはそれを使うように導かれます。
それ以外に、エージェントフックがあります。これは本質的にはIDE内で発生するイベントに基づいて実行できる自動化に他なりません。例えば、TypeScriptプロジェクトでファイル保存があり、コンポーネントを更新していると言った場合、フックを実行してそのコンポーネントのreadmeを更新し、みんながreadmeを活用できるようにします。
これらがKiroに今日存在するすべての機能です。しかし、一歩下がって今日業界に存在するツールの既存の状況を見てみると、MCPサーバーはクライアント間のツール通信を接続するための標準を提供しています。つまり、MCPクライアントとMCPサーバーがあります。M掛けるN個の統合を作成する必要はありません。M足すNだけでいいんです。つまり、エージェントがN個のツールと対話している場合、50個の統合をデプロイする代わりに、対話するツールは10個だけで済むということです。
Claudeを使って作業する場合、Skillsというものがあります。これはAnthropicが導入した、エージェントを特定の動作に導くことができる指示やスクリプト、リソースのセットです。また、動的ツールハンドリングというものもあります。これは必要に応じてツールを発見してロードするもので、Anthropicのツールサーチに似ています。それから、CursorのようなIDEを見てみると、エージェントにカスタム統合や指示を提供する特定のルールセットがあります。これはKiroのステアリングルールと非常に似ています。しかしでは、問題に入っていきましょう。私たちが見てきたAIエージェントは、まだジェネラリストの動作をしています。スペシャリストではないんです。
一般的な開発タスクを見てみると、コード構造化、これは本当によくできます。コードレビュー、コードテスト、補完、そしてドキュメンテーション、READMEが正しいことを確認し、コードが変更されるたびに更新を実行します。しかし、専門的な開発タスクを見ると、ここで開発のエコシステム全体が関わってきます。UIデベロッパーを見てみると、UIデベロッパーはFigmaを使ったデザインからコンポーネント生成への作業に特別な要件があるかもしれません。APIデベロッパーを見てみると、APIデベロッパーはOpenAPIや、その開発者の環境に非常に特化したニッチなフレームワークとの統合があるかもしれません。データベースも同じです。データベースは巨大な獣であり、AIエージェント開発におけるバックエンド開発でもあります。では専門的な開発における課題は、今日のAIエージェントが専門化に苦労しているということです。
ドキュメンテーションの過負荷、コンテキストとして渡される複数のMCPサーバーやツールが存在し、開発者はこれらのエージェントをユースケースに導くために多くの時間を費やす必要があります。顧客から見てきた、これらの特定のユースケースに導かれ、調整された手書きのステアリングファイルがたくさんあります。そして、開発ツールに対する規範的なベストプラクティスがありません。ツールに接続できますが、意見を持ったガイダンスは限られています。それから、開発エキスパートのコラボレーションが非常に限られています。ドメインエキスパートの知識が体系化されておらず、専門知識を交換するメカニズムが限られているんです。そこで、私たちは問題提起をしました。AIエージェントは、ユースケーススペシャリストから収集された、カスタマイズされたコンテキストへの動的なアクセスが必要だということです。
Kiro powersの発表：共有可能なベストプラクティスでエージェントの機能を拡張
これは提供できますが、時間が経つにつれて、コンテキストの肥大化が起こります。なぜなら、IDEに設定されたすべてのMCPサーバーやツールのコンテキスト、IDEに設定されたすべてのステアリングファイルを渡しているからです。そこで、私たちはKiro powersという新しいコンセプトを打ち出しました。これは昨日ローンチしたもので、共有可能なベストプラクティスを通じてKiroエージェントの機能を拡張できるようになりました。すべて、特定のISVユースケース向けに私たちが作業してきたキュレーションされたpowersからです。そして、これらのユースケースを拡大していく予定です。
では、powerには何が含まれるのでしょうか？次のいずれか、またはすべてを含むことができます。MCPサーバー、ステアリングファイル、そしてアクション用のフックです。これのメリットは何でしょうか？開発からデプロイメントまでのユースケース、フルスタック開発、バックエンド開発、API開発、データベース開発、オブザーバビリティなど、何でも構いません。その特定のユースケースをターゲットにでき、エージェントによる高速な意思決定のためのターゲットを絞ったコンテキストが得られます。エージェントは、フルスタック開発のためにアクセスする必要があるツールが何かを把握するためにループに陥る必要がなくなります。そして、ISVからキュレーションされたベストプラクティス。Stripeを決済に統合したい場合、これまで遭遇した多数のベストプラクティスを把握したり、自分で手作業で作成したりする心配はありません。これはStripe自身がキュレーションしたものです。これはStripeが作成したpowerなんです。そうでしょう？
では、powerファイルの構造はどのようなものでしょうか？power.mdファイルはこのような形になります。これがSupabaseの名前で、こちらが表示名としてどのように見えるか、そして説明とその特定のドメインを識別できるキーワードです。
例えば、誰かが「データベースを構築したい、そしてデータベースと統合してフルスタックアプリケーションを構築したい、それはPostgresであるべきだ」とプロンプトを出した場合、Supabase powerにアクセスできるあなたのエージェントがそのpowerを起動し、オンデマンドでそのpowerのみを使用してそれを作成します。
はい、これらがローンチに向けて私たちが協力してきた特定のパートナーのリストです。これをさらに拡大していく予定ですが、正直なところ、Danがもうすぐお見せしますが、あなた自身の要件に合わせたpowerを作成することができ、それを組織内で共有することもできます。それがpowersの機能です。私たちはFigma、Supabase、Stripe、Neon、DatadogとDynatrace、そしてNetlify、Strandsとも協力してきました、そしてローンチに向けてPostmanとも協力しています。
Neon powerを使った実践デモ：フロントエンドからバックエンド、デプロイまでの完全ワークフロー
それでは、Danにライブデモをお願いします。Powersを素早くデモして、Powersが実際にどのように動作するかをお見せします。この新しいローンチで行ったことは、上部に新しいペインを追加し、Kiroに追加できるすべてのpowersを管理できるようにしました。そして、2つの主要なセクションがあります。インストール済みのpowersがすべて表示されるセクションと、すべてのパートナーとキュレーションされたpowersが表示される新しいセクションがあります。
この例では、私はバックエンド開発者だとしましょう、このシナリオでは、Neonでデータベースを作成するタスクを任されています。フロントエンド開発者がフロントエンドコードを共有してくれました、これは単純なNext.jsアプリケーションで、私はそれにバックエンドを追加して、フロントにデータを表示し始める必要があります。そこで、ここに来てNeon powerを見つけてインストールすることができます。
そして数秒以内に、Kiroエージェントによってアクティベートできる状態になります。Neon powerに含まれているものについて少しお話しすると、エージェントが対話できるMCPサーバーと、ベストプラクティスや特定のシナリオへの対処方法について説明する一連のステアリングファイルが含まれています。
では、エージェントに単純にプロンプトを入力することから始めます。「フロントエンドアプリケーション用のバックエンドデータベースを追加して」と言ってみます。このシンプルなプロンプトだけで、エージェントは確認を行い、これをNeon powerとして識別するはずです。ご覧のように、アクティベートされて、そのpowerを使い始めています。このアクティベーションが起こる前は、もし私が手動でMCPサーバーやステアリングファイルを含めていた場合に含まれていたであろうすべてのコンテキストが含まれていたわけですが、今エージェントがpowerを使って進めていく中で、このツールを信頼するかどうか聞いてきているので、承認します。
エージェントが処理を進める中で、それが取り込まれています。これはコンテキストの肥大化を防ぐことや、ベストプラクティスに沿うことに役立ちます。では、プロジェクトのリストを承認します。今、私のNeonアカウントに存在する可能性のあるプロジェクトをチェックしています。これが自動的に動作している理由は、事前にこれをセットアップしていたためで、MCPサーバーはすでにOAuthを通じて私のアカウントで認証されています。もしこれが初めての場合は、認証してMCPをNeonアカウントに接続するよう促す小さなポップアップが表示されます。
では、初期化を行い、いくつかのバックエンドファイルを作成し、現在のフロントエンドファイルを編集し、統合をセットアップして、その概要を示してくれます。次のステップとしてNeonデータベースのURLを追加するように言われているので、エージェントにそれをやってもらえばいいはずです。データベースURLをENVファイルに追加しましょう。そうすると、それをセットアップし始めます。さらにいくつかのMCP呼び出しを行いますが、これらは動的に取り込まれているため、コンテキストウィンドウを可能な限り最小限に保つのに役立っています。
私が持っているプロジェクトをチェックして、その接続文字列を取得しようとします。新しいプロジェクトを作成したい場合は、もちろんその方向にプロンプトを出すこともできます。でも、すでに既存のデータベースがあるので、その既存の接続文字列を使わせます。ENVファイル内のシークレット変数を変更しようとしているので、変更を承認します。そして、「追加のセットアップは必要ですか？」と聞いてみます。
エージェントは今、私のプロジェクトをもう一度分析して、Neonのパワーと再確認しながら、他に必要なものがあるか、またはすべてが完了しているかをダブルチェックできるようになりました。そうすれば、私はローカルでアプリケーションを実行できます。どうやらテーブルを作成するか、テーブルをチェックして、MCPツールを使用してSQLコマンドを実行する必要があるようですので、それを承認します。エージェントがそのツールを呼び出して、私のために呼び出しを行います。まだ同じコマンドを実行しているようです。これの良いところは、IDEを離れてNeonに行って何かをセットアップする必要がなかったことです。エージェントとパワーが一緒に動作して、私のためにそれを行ってくれるので、私はIDE自体にすべての注意を集中できます。
さあ、進めていきます。ここで少しループに入っていますね。オーケー、データベーススキーマが作成されて、アプリケーションの準備ができたと言っています。それでは、アプリケーションのローカル開発サーバーを実行するようにプロンプトを出します。この段階でも、コンテキストを管理しながらこれを実行します。予想通りエラーが出るかもしれません。なぜなら、もう1つやるべきステップがあるからです。それは依存関係のインストールです。それでは進めていきます。ああ、そうだ、依存関係のインストールを忘れていました。エージェントが私のためにインストールコマンドを実行してくれます。この後、ローカル開発サーバーを実行できるはずで、アプリケーションとのやり取りを始められます。
また、もう1つクールなことに気づきました。Kiro内でどれだけのコンテキストが使用されたかを確認できるようになりました。下部のインジケーターが見えるかどうかわかりませんが。でも、これは現在のセッションで、エージェントがどれだけのコンテキストを使用したかを示すクールな小さなインジケーターです。完全に緑色になったら、コンテキスト全体が消費されたことを意味します。その通りです。はい、パワーなしでは、そして自分でテストできますが、パワーなしではもっと早く埋まってしまうかもしれませんが、パワーを使用することで、そのコンテキストをはるかにうまく管理できます。ローカル開発サーバーを実行すると、今ローカルで実行されています。データは表示されないはずです。それでは、これをリフレッシュします。データがないことがわかります。ここで私ができることは、バックエンドにサンプルデータを追加することです。
Neonパワーとやり取りして、MCPツールを利用してダミーデータを追加します。いくつかの製品を挿入するSQLコマンドを実行します。繰り返しますが、実際にデータが表示されなかった理由は、データベースにデータがなかったからです。テーブルは新しく作成されたので、UIに何かを追加して製品ページを表示するような偽装はしていません。はい、これはすべてライブです、その通りです。はい、そしてもう1つクールなことは、私のプロンプトのどこにも製品について何も言及していないことです。そのコンテキストはすべて、すでにフロントエンドアプリケーションにありました。フロントエンドアプリケーションには、これは製品を持つeコマースウェブサイト用であるというメタデータがありました。そこから直接推論することで、データベーステーブルと、ローカル開発サーバーに必要な製品を作成できるのです。
さらにいくつかのSQLコマンドを実行して、製品を挿入し続けます。それが完了したら、フロントエンドアプリケーションに戻ることができます。6つの製品が追加されました。ここでリフレッシュすると、ハードリフレッシュが必要かもしれません。パワーを使用することで挿入された6つの製品が表示されました。Neonが提供するもう1つのクールな機能は、バックエンドをブランチする機能です。もし私が何らかのデータとやり取りしていて、テーブルやスキーマなどを変更したい場合、Neonにはブランチを作成できる機能があり、そうすることでテーブルに影響を与えずに変更を加えることができます。ここからそれを行うことができます。
例えば、エージェントに対してプロンプトを入力して、データベースを変更したいのでブランチを作成してください、と言うことができます。ここからバックエンド、つまりNeonテーブルにリクエストを送り、そして既存プロジェクトに関するメタデータを取得し、ブランチを作成します。そうすると、エージェントから直接そのブランチとやり取りできるようになります。スキーマを変更したり、ローカルで必要な製品や変更を加えたりして、変更内容に満足したら、ブランチをメインにマージできます。つまりdevブランチをmainブランチにマージするわけです。では、これが完了するのを待ちましょう。Dan、これってバックエンド開発者の視点からすると素晴らしいですよね?では、このアプリケーションをホストしたい、あるいはデプロイしたい場合はどうでしょうか?それは良い質問ですね。例えば、必要な変更をすべて完了して、これをどこかにデプロイしたいとしましょう。
例えば、Netlifyを使っている場合、Netlifyのpowerもありますので、ここに来てそのpowerをインストールできます。まだインストールされていなければ、新しいセッションを開始して、基本的にはエージェントに、そのpowerをデプロイしたいとお願いするだけです。つまり、アプリケーションをデプロイしてください、と言えば、アプリケーションをデプロイしたいということと、Netlifyのpowerが利用可能であることを検知して、Netlify用のpowerをアクティベートし、Netlifyのバックエンドとやり取りしてくれます。
NetlifyのCLIコマンドを利用するため、Netlifyを動作させるにはまだいくつかのステップが必要です。認証やその他のセットアップを行う必要がありますが、実際にデプロイできるように必要なセットアップについても案内してくれます。しかし数秒後、いや数分後と言った方がいいですね、私は以前これをやったことがあるので、すべての異なるデプロイメントが出力されます。そうすると、これをコピーして、アプリケーションは一致しないかもしれませんが、もちろん有効な製品とともにどこかにデプロイされたものが手に入ります。
これがpowersのパワーの源なんです。つまり、ワークフローを効率化し、必要なことをより速く達成できるようにしてくれるということです。ステアリングファイルのセットアップに1時間、あるいは数時間かけて、適切なMCPサーバーは何か、ベストプラクティスは何かを考えることもできましたが、powersを使うことで、フロントエンドアプリケーションの骨組みだけの状態から、完全にデプロイされたアプリケーションまで、すぐに到達することができました。素晴らしいですね。本日のトークは以上となります。ご参加いただき誠にありがとうございました。ステージを降りてからご質問をお受けいたします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion