Kiro PowersとSteeringの間でコンテキストをルーティングする方法 (2026年ガイド)

まず、Powersが解決するために作られた課題から始めましょう。Kiroのドキュメントには、次の2つの文でそれが説明されています。「フレームワークのコンテキストがないと、エージェントは推測に頼ることになる。」そして「コンテキストが多すぎると、エージェントの動作が遅くなる。」複数のMCPサーバーを接続するということは、作業を開始する前に、すべてのツール定義をあらかじめロードしておく必要があることを意味します。

Powersは「有効化（activation）」によってこの問題に対処します。「すべてのMCPツールを一度にロードする代わりに、会話内のキーワードに基づいてPowersが動的に有効化されます。」タスクが開始されると、Kiroは「タスクの説明を読み」、「インストールされているPowersをタスクに対して評価し」、「関連するPowersのみをコンテキストにロード」します。そして、これらは再びオフになります。Kiro自身の例では、決済処理からデータベースの作業に移行すると、「SupabaseのPowerが有効化され、Stripeは無効化されます。」

Powerはパッケージです。これはAgent Plugins仕様に準拠しており、必須の plugin.json マニフェストと、オプションの skills/、mcp.json、および「SteeringファイルなどのKiro固有の拡張機能」用の dev.kiro/ フォルダが含まれます。マニフェストの keywords フィールドがトリガーとなります。これは「有効化をトリガーする文字列の配列。開発者がそのツールについて話すときに使用する用語を指定します。」

Steeringの仕組みは異なります。Kiroはこれを、Markdownファイルを通じてエージェントに「プロジェクトに関する永続的な知識」を提供するものと説明しており、現在は4つのインクルージョン（含め方）モードをサポートしています。デフォルトは「常に含める（Always included）」で、「すべてのコード生成に影響を与えるべきコア基準」向けです。条件付きインクルージョン（Conditional inclusion）は、「指定されたパターンに一致するファイルを操作しているときのみ」ファイルをロードします。手動インクルージョン（Manual inclusion）は、チャットで参照したときにロードします。そして、自動インクルージョン（Auto inclusion）は「リクエストが説明に一致したとき」にロードされ、Kiroはこれが「Skillsと同様に機能する」と指摘しています。

したがって、どちらにも関連性がある場合のみロードする方法が存在します。Kiroのドキュメントでは、「How powers differ from skills and steering（PowersがSkillsやSteeringとどのように異なるか）」というセクションで、意図された役割分担を明確に説明しています。

「Powersは、MCPツール、Skills、および知識を1つのインストール可能なパッケージにまとめたプラグインです。これらはコンテキストに基づいて動的に有効化されます。ツールとガイダンスの両方が必要なインテグレーションに使用してください。」

「Steeringは、エージェントの動作を規定するKiro固有のコンテキストです。always、auto、fileMatch、manualモードをサポートしています。プロジェクトの標準や規約に使用してください。」

この比較では明示されていませんが、インストールページを見れば明らかな違いがもう1つあります。それは、それぞれが「どこに存在する（保存される）か」です。Steeringはリポジトリ内に存在します。「エージェントは、リポジトリのルートにある .kiro/steering/ フォルダ内のSteeringファイルを自動的に検索します。」一方、PowersはPowersパネルから、レジストリ、GitHubのURL、またはローカルフォルダを介してインストールされます。レガシー形式のPowerは、MCPサーバーを「~/.kiro/settings/mcp.json 設定ファイル」に登録し、Agent Plugins形式のPowerのサーバーは「Kiroによって内部的に管理」されます。いずれにせよ、Powerはリポジトリの一部ではなく、あなた個人の環境設定の一部です。

すべてを常時オンのSteeringに詰め込む。 これは機能はしますが、すべてのタスクでコストが発生します。READMEのタイポを修正している間にも、決済APIに関する長いメモがロードされてしまいます。コンテキストの量が多い素材に対するKiro自身の推奨は、より限定的なモードを使用することです。

チームの規約をPowerにする。 Powerは個人ごとにインストールされます。チームのエラーハンドリングルールが、あなたがインストールしたPowerの中にある場合、それをインストールしていない同僚はルールなしで作業することになり、リポジトリ上には何かが欠けているという兆候は一切現れません。

プロジェクトの事実にキーワードで依存する。 キーワードはインテグレーションに適しています。なぜなら、開発者はそれらを扱うときに自然と「Stripe」や「データベース」と口にするからです。しかし、プロジェクトの規約には、リクエストに確実に現れるような特定の単語が含まれていることはほとんどありません。

自動SteeringとPowersを同じものとして扱う。 どちらも関連性に基づいて有効化されます。しかし、MCPツールを伴うのは一方のみであり、リポジトリと一緒に移動するのも一方のみです。

インクルージョンモードがすべてのサーフェスで同じように動作すると仮定する。 KiroのSteeringに関するページには、現在2つの異なる記述があります。機能一覧表では「インクルージョンモード（always、fileMatch、manual）」がIDE、CLI、Web、モバイルでサポートされているとマークされています。しかし、同じページに「Kiro CLIでは、インクルージョンモードは現在サポートされていません。.kiro/steering/ ディレクトリ内のすべてのSteeringファイルが自動的にロードされます」という注記もあります。この2つの記述の整合性が取れるまでは、どちらかの記述を鵜呑みにせず、CLIでの動作を自分で検証してください。以前のIDEとCLIでKiroのSteeringを分割するに関するガイドは、後者の注記を前提に執筆されました。

ルーティングを決定するには、すべてのコンテキストについて次の2つの質問に答える必要があります。「このリポジトリで作業する全員がそれを必要とするか？」そして「何がそれをトリガーすべきか？」

ステップ 1: 対象者とトリガーで各コンテキストを分類する

Steeringファイルやプロンプトで繰り返し伝えている内容など、現在エージェントが知っていることをリストアップします。各項目について、次の2つの事項を書き出します。

対象者（Audience）：これはリポジトリで作業する全員に当てはまることですか、それとも一部の人が使用するツールに関するものですか？エラーハンドリングの規約、ディレクトリ構成、テストコマンドなどは「チームの事実」です。特定のベンダーのAPIを適切な冪等性パターンで呼び出す方法は「ツールの専門知識」です。

トリガー（Trigger）：いつロードすべきですか？常に、特定のファイルが開いているとき、リクエストが説明に一致したとき、あるいは誰かが明示的に要求したときだけですか？

これにより、シンプルなマトリクスが作成されます。どのようなトリガーであれ、チームの事実はSteeringに送られます。ツールを伴うツールの専門知識はPowerに送られます。ツールを伴わないツールの専門知識（例：ライブラリの使用方法のメモなど）はどちらにも配置できますが、通常は対象者の質問によって決定されます。

ステップ 2: チームの規約はSteeringに保持し、最も限定的なモードで実行する

各チームの事実について、それが適用される正確なタイミングでロードされるインクルージョンモードを選択します。

本当に普遍的な標準は「always」のままにします。Kiroのこのモードの例としては、「技術スタック、コーディング規約、および基本的なアーキテクチャ原則」が挙げられています。

コードベースの一部に関連付けられた規約には、ファイルパターンを使用した条件付きインクルージョンを適用します。これにより、コンポーネントファイルが操作されているときにのみコンポーネントルールがロードされます。

特定のリクエストにのみ関係する長めのガイダンスには、Kiroがマッチングできる name と description を指定して自動インクルージョン（auto）を適用します。Kiroが推奨する自動インクルージョンの用途は、「関連性がある場合のみロードすべき、コンテキスト量の多いガイダンス」です。

マイグレーションのチェックリストやトラブルシューティングガイドなど、たまにしか実行しない手順には手動インクルージョン（manual）を適用します。Kiroはこれを「専門的なワークフロー、トラブルシューティングガイド、移行手順、またはたまにしか必要とされないコンテキスト量の多いドキュメント」に推奨しています。

すべてのモードにおいて、1つの構造的なルールが重要です。「インクルージョン設定は、ファイルの最初のコンテンツでなければなりません。その前に空行やコンテンツを置いてはなりません。」空行の後に置かれたフロントマターブロックは、フロントマターブロックとして認識されません。

カスタムエージェントを使用している場合は、その設定も確認してください。Kiroは「カスタムエージェントを使用する場合、Steeringファイルは自動的には含まれません。Steeringコンテキストをロードするには、エージェントの resources 設定に明示的に追加する必要があります」と述べています。

ステップ 3: ツールの専門知識をPowersに移行し、キーワードを確認して、各サーフェスで検証する

インテグレーションについては、Steeringでそのガイダンスを再構築するのではなく、Powerをインストールしてください。チームがプライベートツールを使用している場合、Kiroは独自のPowerの構築をサポートしています。明確な description と keywords を含む plugin.json、Skills、およびオプションのMCP設定を用意します。

インストールするすべてのPowerのキーワードを確認してください。これらが有効化のタイミングを決定します。これらは開発者が通常そのツールについて話す方法に合わせて書かれているため、あなたのチームの用語と一致しない場合があります。

その後、検証を行います。Powerをトリガーするはずのタスクとそうでないタスクを開始し、ツールが表示されたり消えたりすることを確認します。条件付きで含まれる領域に触れるタスクを開始し、Steeringがロードされることを確認します。Steeringページに矛盾する注記があることを考慮し、IDEと（使用している場合は）CLIの両方でこれを行ってください。また、Powersがチームのワークフローの一部である場合は、新しい同僚が同じセットをインストールできるように、どのPowersを使用しているかを書き留めておきます。

ステップ1により、どのアージェント、サーフェス、またはプラグインがロードされているかに関係なく当てはまる、チームの事実のリストが作成されます。MemoryLakeは、特定のツールのフォルダレイアウトやインクルージョンモードに依存しないように、そのリストを保持しておく場所です。

エントリーはあなた自身が自分の言葉で記述します。.kiro/steering、インストールされたPowers、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。

ステップ 1: APIキーを作成する

サインインし、ダッシュボードからキーを生成します。このキーにより、Kiroやチーム内の他のツールで、エージェントがあなたが作成したエントリーを読み取ることができるようになります。

ステップ 2: 最初のメモリをアップロードする

ステップ1のチームの事実を、各規約が存在する理由とともに、1つのエントリーにつき1つずつ追加します。理由を書いておくことで、後でそのルールを移動すべきか、変更すべきか、あるいはそのまま維持すべきかを判断できるようになります。

ステップ 3: AIとエージェントを接続する

エージェントをワークスペースに向けます。これにより、チームメイトがどのサーフェスやプラグインセットを使用していようとも、同じ規約を利用できるようになります。

最初の違いは、ベースラインが小さくなることです。Powerと一緒にロードされるインテグレーションガイダンスは、すべてのタスクで無駄なコストを支払う必要がありません。より広い視点で見れば、コンテキストウィンドウが大きくなっても、そこに収まるものが変わるだけで、そこに置くべき価値があるものが変わるわけではないという点です。これは、なぜ長いコンテキストはメモリではないのかの背景にある考え方と同じです。

2つ目は、チームの知識がチーム内に留まることです。Steering内の規約はリポジトリに存在し、レビューされ、共有されます。一方、Powersは各個人の設定に留まります。これはツールにとっては適切ですが、全員が従うべきルールにとっては不適切です。

3つ目は、コンテキストコストが可視化されることです。常時オンのSteeringに普遍的な事実のみが保持されている場合、すべてのリクエストの固定部分は小さく、把握しやすいものになります。メモリがどのようにトークン使用量を削減するかを追跡しているチームは、通常、毎回送信するのをやめたものから節約効果を得ています。この点は、トークンコストの削減はどこから生まれるかでも指摘されています。

4つ目は、長いセッションに対する回復力です。オンデマンドでロードされるコンテキストは、セッションが圧縮（コンパクション）されたときに脱落する可能性もあります。どの事実を残すべきかを知ることは、Kiroのコンパクションを生き残るものを決定するにおける重要な問いです。

まず対象者でルーティングする。 リポジトリ内の全員がそれを必要とする場合は、Steeringに属します。一部の人が使用するツールに付随するものである場合は、Powerに属します。

実行される最も限定的なインクルージョンモードを使用する。 普遍的な標準にはalways、特定の領域のルールにはファイルパターン、重いガイダンスにはauto、たまに行う手順にはmanualを使用します。

フロントマターを最初に配置する。 インクルージョン設定は、ファイルの最初のコンテンツとして配置された場合のみ機能します。

すべてのPowerのキーワードを確認する。 これらが有効化を決定します。これらはあなたのチームの語彙ではなく、一般的な開発者向けに書かれています。

チームが依存しているPowersのリストを保持する。 あるマシンにインストールされたPowerは、リポジトリや、次にそれをクローンする人からは見えません。

各サーフェスで検証する。 Kiro'sのSteeringページには現在、CLIでのインクルージョンモードについて2つの異なる記述があります。想定で済ませずテストを行ってください。また、MCPサーバーも同じ全体像の一部として扱ってください。MCPは失われたメモリレイヤーであると言えるのは、ツールの背後にある事実もどこかに保持されている場合のみです。将来的にツールを移行する場合は、KiroからCodexへの移行がどの部分を移行できるかを示しています。

KiroのPowersとSteeringは、関連する課題を異なる場所で解決します。Powersはインテグレーションのツールとガイダンスをまとめ、会話に応じてそれらをオン・オフします。Steeringはリポジトリ独自の標準を保持し、各ファイルがいつロードされるかを制御する4つのインクルージョンモードを提供します。

Kiroのドキュメントはこの区分を直接的に述べています。Powersは「ツールとガイダンスの両方が必要なインテグレーション向け」、Steeringは「プロジェクトの標準や規約向け」です。インストールページから補足すべき点として、Steeringはリポジトリとともに移動し、Powersは個人とともに移動するということがあります。

すべてのコンテキストを対象者とトリガーで分類し、チームの事実は実行される最も限定的なモードでSteeringに保持し、ツールの専門知識はPowersに持たせ、使用するすべてのサーフェスで検証を行ってください。そして、それらのメカニズムのいずれにも依存しない場所に、チームの規約を書き留めておきましょう。