数か月前、2025年10月に Kiroween というハッカソンの間に Kiro を始めました。KiroをIDEとして試してみて、この提案で AWS が何をしようとしているのかを理解するための出発点でした。私の目標は Kiro を試して、すでに使っていた他のツールとどこが異なるのかを確認することでした。
当時は Kiro に関するガイドも多くはありませんでした。したがって、私がしたことのほとんどは探索的なものでした：プロジェクトを開く、vibecoding を試す、仕様駆動開発について理解する、そして IDE がどのように反応するかを見てみる。
月日が経ち、Kiro のコミュニティにさらに深く関わるにつれて、IDE の背後に本当にある全てを発見し始めました。AI を搭載したエディタだけではありません。AI の文脈を管理する方法、IDE の挙動を設定する方法、そしてそれが行うことを統治する方法といった周囲には一連のシステムがあります。
そこから現れ始める概念としては:
- steerings
- hooks
- MCPs
- powers
- エージェント
- prompts
- skills
もしすでに Kiro を使っている、あるいは使おうと考えているが、これらのピースがどのように組み合わさるのかまだ分からない場合、この文章はあなたのためのものです。
TLDR: Kiro のインストール
まだ Kiro をインストールしていない場合、以下のリンクがあります：
これで数分で IDE を動作させることができるはずです。ここからが本当に面白くなる部分です。
Steerings
Steerings は、Kiro があなたのプロジェクトで作業する際に考慮してほしい指示、規約、または文脈を定義する、単なる Markdown ファイルです。
それらは指示を与えるだけでなく、あなたのプロジェクトに関する構造情報を含むこともあります。
例えば：
- リポジトリの構造と組織
- コードの命名規則
- プロジェクトのアーキテクチャ
- ドキュメントの生成方法
最も一般的なケースの一つは、Kiro に Foundational Steerings を生成してもらうことです。
これを行うと、Kiro はあなたのプロジェクトをスキャンし、Kiro の設定ディレクトリ内にいくつかのファイルを生成します。通常は次のものを含みます：
- プロダクト
- 構造
- tech
これらは、Kiro がリポジトリで検出する文脈を使って生成されます。AI がコードを扱う際の文書ベースの出発点として、良い基盤を提供します。
おすすめの Steerings
Foundational Steerings に加え、実際のプロジェクトに役立つ他のタイプもあります。
例えば：
プロジェクト作業のルール
そのリポジトリでチームがどのように作業するか、次のような内容を含むことがあります：
- 命名規則
- フォルダ構成
- プロジェクトのビジョンとミッション
これにより、Kiro がプロジェクトのスタイルから逸脱したものを生成するのを防ぐのに役立ちます。
ドキュメントのスタイル
コードをどのように文書化するか、どのセクションを表示すべきか、README の書き方などを定義できます。
アーキテクチャの規約
プロジェクトが特定のパターン（ヘキサゴナル、イベント駆動、クリーンアーキテクチャなど）に従う場合、それを steering で定義しておくことは、一貫性を保つのにかなり役立ちます。
プロジェクトの仕組みを Kiro により明確に伝えれば伝えるほど、より良い結果を得ることができます。
Hooks
Los Hooks は、Kiro の中でもかなり強力な要素の一つです。基本的には、イベントが発生した際に自動的に実行されるプロンプトです。
これらのイベントの例としては：
- ファイルが作成、変更、削除されるとき
- タスクを開始または終了するとき
- 手動で
かなりシンプルな例として、Markdown ファイルを編集している場合には、次のようなフックを持てます：
- リントを実行する
- Markdown を整形する
- リンク切れを検出する
別の例として、コードを変更している場合には、変更内容について自動的にドキュメントを生成するフックを持つことができます。
これにより、開発フローの多くを自動化する扉が開かれます。
Hooks の始め方
Hooks にはさまざまなトリガーの仕組みがあります：hook triggers
私のおすすめは、まず手動のフックから始めることです。
最初に、何をするのかを試し、結果が期待通りかを検証し、異常な挙動がないことを確認します。
結果に満足したら自動化を開始できます。
フックは Kiro でタスクを発生させるので、多くの自動化フックを持つとクレジットコストが高くなる可能性があります。これが私がフックから学んだ最初の教訓の一つでした。
MCPs
Los MCPs は、Kiro や AI 全般の中で重要な要素の一つです。
とても簡単に説明すると、MCP は AI がそれを使うための API のようなものです。MCP は AI を外部サービスと接続できるようにします。通常はプロジェクトの文脈の中には含まれていない情報やツールへアクセスを与えます。
一般的な例として：
- AWS のドキュメント
- 技術文書用 Context7
- Jira や Confluence などの Atlassian との統合
Kiro をドキュメント、外部ツール、チームの内部システムと接続して、AI がそれらすべてで作業できるようにすることができます。
Powers
MCPs のあまり良くない点は、AI セッション内に文脈を追加することです。MCPs を多く有効にすると、より多くの文脈を消費し、タスクのコストが高くなる可能性があります。
多くの場合、すべての MCPs を常時アクティブにしておく必要はありません。ここで Kiro の Powers の出番です。
Powers は、頻繁に繰り返されるタスクやドメインをカプセル化することを可能にします。MCPs を使うタスクも含みます。
Supabase のデータベースの MCP があるとします。しかしこのタスクではデータベースは必要ないとします。それを Power でカプセル化すれば、データベースが必要なときだけ Kiro がそれを呼び出し、使わないときにはその MCP が使用する文脈を解放します。
以前、私が最初の Power を作成したときの記事を書いたことがあります（英語版です、すみません）: Construyendo mi primer Kiro Power - Posthog Observability.
カスタマイズ可能なエージェント
今年の初め、Kiroはカスタマイズ可能なエージェント、すなわちサブエージェントを発表しました。エージェントはすでにKiroの中に存在しており、IDEでspec-driven developmentを行ったり、CLIのプランモードを使った場合にご覧になったはずです。どちらもKiro内にすでに定義されているエージェントを使用して、特定の種類のタスクを実行します。
エージェントは独自の構造とプロンプトを持っており、それによって指定された動作をします。
彼らがするのは、エージェントだけが表示される内部の構造とプロンプトを持っていることです。いくつかのツールが有効か無効かが設定されています。そしてモデルを選択していることもあります。
例えば、プランのエージェントは、与えられたタスクを計画するためのガイドのように機能し、タスクについて質問し、詳細な計画を作成します。このエージェントにはファイルの書き込み機能が無効になっています。なぜなら、あなたが行うのは計画だけで、実装を行うわけではないからです。
プランはKiroによってすでに事前定義されていたエージェントです。今、あなた自身のエージェントを作成できます。つまり、これを次のレベルへ、さらには4つのレベル先へと進めることができます。なぜ4つかというと、サブエージェントを使えば4つのエージェントを並列で動かすことができるからです。
私がカスタマイズ可能なエージェントを使う方法
私が常に使うエージェントは、プロジェクトで実際に行っていることに関連するエージェントです。
例えば、TypeScript のプロジェクトがある場合、TypeScriptの専門家であるエージェントがあります。TypeScriptの専門家です。TypeScriptの専門家として働く方法についての具体的なプロンプトを持っています。そして、書き込みと読み取りのツールを有効にします。
計画とアーキテクチャのためのLLMのアドバイス
私が持っているもうひとつの例は、計画、アーキテクチャ、および意思決定のタスクです。
通常、手元の最良のモデルに質問すると、かなり良い選択肢を与えてくれることが多いですが、理想的には複数の選択肢を持つべきです。AIは非決定論的で、幻覚を見せることがあるからです。
計画、アーキテクチャ、意思決定など、計画や設計を作ることが主で、実装は別という場面では、実務ではチームを集め、ブレインストーミングを行い、チームのさまざまな意見を得ます。
Kiroの中でこれをどう運用しますか？計画など、特定のプロンプトを持つカスタマイズ可能なエージェントがあります。カスタマイズ可能なエージェントでは、どのモデルを使っているかを指定でき、同じタイプのエージェントに異なるモデルを割り当てることができます。例えば、Opus、Sonnet、Haiku、Auto の4つのモデルです。
計画を作成する際、Kiroに私のエージェントのアドバイスを並行して使用するよう依頼します。Kiroはこの4つのモデルを並行して起動し、それぞれ独立した計画を作成します。終わると、デフォルトのエージェントがそれら4つの計画を統合し、それぞれのベストを取り出します。
これは計画を作成する方法を完全に変えるものです。複数のモデルでブレインストーミングを行い、常に最高のものを得られるようにします。たとえば1つのモデルが幻覚を起こすこともあるかもしれませんが、4つが同時に幻覚を起こすのはより難しいです。
仕様駆動開発
Kiroで私が最も関心を引かれた部分は、すでにIDEに組み込まれている仕様駆動開発です。
開発者にとっては、これは全く新しい概念ではなく、チケットを定義し、要件を与え、設計を作成し、異なるサブタスクに基づいてチケットを実装することに似ています。
Kiroの仕様モードは要件と設計を作成し、markdownファイル形式のタスクリストを生成します。これらを見直して、あなたのアプリケーションやリポジトリの文脈を把握することができます。
仕様駆動開発に焦点を当てた記事を書いてほしい場合は、関心をコメントで教えてください。
結論
本記事では、Steerings、Hooks、MCPs、Powers、およびカスタマイズ可能なエージェントについて、また仕様駆動開発を大まかに見てきました。
これらの機能はすべてKiro内でAIのコンテキストとして定義されます。Context-Driven Developmentについて聞いたことがあれば、それが指している文脈です。
この記事は、ここ数か月にわたり私が学んできた成果です。そして学習は継続中で、新しい機能に出会い続けています。例えば、スキルなどです。これらには言及していませんが、Kiroにも含まれており、最近非常に有名になっています。
もしKiroを使っていない場合は、IDEだけでなくコマンドラインツール、CLIの両方を試して、仕様駆動開発も試してみることをおすすめします。
Kiro、コンテキスト駆動開発、仕様駆動開発についてさらに知りたい場合や、Kiroについての経験を共有したい場合は、私にご連絡いただくか、コメント欄にご記入ください。
