Steering とは？
Steering は .kiro/steering/ ディレクトリ内の markdown ファイルを通じて Kiro にプロジェクトの永続的な知識を提供します。Cursor の .cursorrules などの従来の方法が基本的な設定を提供するのとは異なり、Steering はより高度で複雑な AI アシスタントのコンテキスト管理方式を表しています。.cursorrules がシンプルなルールベースのガイダンスを提供する一方で、Steering はコードベースと共に進化する包括的で構造化された、コンテキスト化されたプロジェクト知識を提供します。
Steering と .cursorrules の比較：
- Cursor の .cursorrules：基本的なルールを持つシンプルな設定ファイル
- Kiro の Steering：条件付き読み込み、ファイル参照、構造化ドキュメントを備えた高度な markdown ベースの知識システム
毎回のチャットで規約を説明する必要がなく、steering ファイルは Kiro が常にあなたが確立したパターン、ライブラリ、標準に従うことを保証します。
主な利点
一貫したコード生成 - すべてのコンポーネント、API エンドポイント、テストがあなたのチームが確立したパターンと規約に従います。
重複の削減 - 毎回の会話でプロジェクト標準を説明する必要がありません。Kiro があなたの好みを記憶します。
チーム調整 - すべての開発者が同じ標準を使用し、プロジェクトの新参者でもベテランの貢献者でも関係ありません。
スケーラブルなプロジェクト知識 - コードベースの成長と共に進化するドキュメント、プロジェクトの進化過程での決定とパターンを捕捉します。
デフォルト Steering ファイル
Kiro は自動的に3つの基本ファイルを作成してコアプロジェクトコンテキストを確立します：
プロダクト概要 (product.md) - あなたのプロダクトの目的、対象ユーザー、主要機能、ビジネス目標を定義します。これは Kiro が技術的決定の背後にある「なぜ」を理解し、あなたのプロダクト目標と一致するソリューションを提案するのに役立ちます。
技術スタック (tech.md) - あなたが選択したフレームワーク、ライブラリ、開発ツール、技術的制約を記録します。Kiro が実装案を提案する際、代替案よりもあなたが確立した技術スタックを優先します。
プロジェクト構造 (structure.md) - ファイル組織、命名規約、インポートパターン、アーキテクチャ決定を概説します。これにより、生成されたコードが既存のコードベースにシームレスに統合されることを保証します。
これらの基本ファイルはデフォルトで毎回のインタラクションに含まれ、Kiro のプロジェクト理解のベースラインを形成します。
カスタム Steering ファイルの作成
あなたのプロジェクトの独特なニーズに合わせた専門的なガイダンスで Kiro の理解を拡張します：
- Kiro パネルの Steering セクションに移動
-
+ ボタンをクリックして新しい
.mdファイルを作成 - 説明的なファイル名を選択（例：
api-standards.md） - 標準的な markdown 構文を使用してガイダンスを記述
- 自然言語であなたのニーズを記述し、精錬 ボタンを選択すると、Kiro がコンテンツをフォーマットします
インクルードパターン
Steering ファイルは、あなたのニーズに応じて異なる時間に読み込まれるよう設定できます。この柔軟性はパフォーマンスを最適化し、必要な時に関連するコンテキストが提供されることを保証するのに役立ちます。
steering ファイルの先頭にフロントマターを追加してインクルードパターンを設定します。フロントマターは YAML 構文を使用し、ファイルの最初に配置し、3つのダッシュ（---）で囲む必要があります。
常にインクルード（デフォルト）
これらのファイルは自動的にすべての Kiro インタラクションに読み込まれます。すべてのコード生成と提案に影響を与えるべきコア標準にこのモードを使用します。例には、あなたの技術スタック、コーディング規約、基本的なアーキテクチャ原則が含まれます。
最適な用途：プロジェクト全体の標準、技術的好み、セキュリティポリシー、普遍的に適用可能なコーディング規約。
条件付きインクルード
ファイルは指定されたパターンにマッチするファイルを処理する際にのみ自動的にインクルードされます。これにより、必要な時にのみ専門的なガイダンスを読み込むことで、コンテキストの関連性を保ち、ノイズを減らします。
一般的なパターン：
-
"*.tsx"- React コンポーネントと JSX ファイル -
"app/api/**/*"- API ルートとバックエンドロジック -
"**/*.test.*"- テストファイルとテストツール -
"src/components/**/*"- コンポーネント固有のガイドライン -
"*.md"- ドキュメントファイル
最適な用途：コンポーネントパターン、API 設計ルール、テスト手法、特定のファイルタイプにのみ適用されるデプロイメント手順などの特定ドメイン標準。
手動インクルード
チャットメッセージで #steering-file-name を使用してファイルを参照することで、オンデマンドで提供されます。これにより、毎回のインタラクションを混乱させることなく、専門的なコンテキストが必要な時を正確に制御できます。
使用法：チャットで #troubleshooting-guide や #performance-optimization と入力して、現在の会話にその steering ファイルをインクルードします。
最適な用途：専門的なワークフロー、トラブルシューティングガイド、移行手順、または時々しか必要でないコンテキスト集約的なドキュメント。
ファイル参照
steering を最新に保つために、ライブプロジェクトファイルにリンクします：
例：
- API 仕様：
#[[file:api/openapi.yaml]] - コンポーネントパターン：
#[[file:components/ui/button.tsx]] - 設定テンプレート：
#[[file:.env.example]]
ベストプラクティス
ファイルを集中させる - 1ファイル1ドメイン - API 設計、テスト、またはデプロイメント手順。
明確な名前を使用
-
api-rest-conventions.md- REST API 標準 -
testing-unit-patterns.md- 単体テスト手法 -
components-form-validation.md- フォームコンポーネント標準
コンテキストを含める - 標準が何かだけでなく、なぜその決定が行われたかを説明します。
例を提供 - コードスニペットとビフォー・アフターの比較を使用して標準を実演します。
セキュリティファースト - API キー、パスワード、機密データを決して含めないでください。Steering ファイルはコードベースの一部です。
定期的なメンテナンス
- スプリント計画とアーキテクチャ変更時にレビュー
- リファクタリング後にファイル参照をテスト
- コード変更と同様に steering 変更を扱う - レビューが必要
一般的な Steering ファイル戦略
API 標準 (api-standards.md) - REST 規約、エラーレスポンス形式、認証フロー、バージョニング戦略を定義します。エンドポイント命名パターン、HTTP ステータスコードの使用、リクエスト/レスポンスの例を含みます。
テスト手法 (testing-standards.md) - 単体テストパターン、統合テスト戦略、モック手法、カバレッジ期待値を確立します。好ましいテストライブラリ、アサーションスタイル、テストファイル組織を記録します。
コードスタイル (code-conventions.md) - 命名パターン、ファイル組織、インポート順序、アーキテクチャ決定を指定します。好ましいコード構造、コンポーネントパターン、避けるべきアンチパターンの例を含みます。
セキュリティガイドライン (security-policies.md) - 認証要件、データ検証ルール、入力サニタイゼーション標準、脆弱性防止措置を記録します。あなたのアプリケーション固有のセキュアコーディング実践を含みます。
デプロイメントプロセス (deployment-workflow.md) - ビルド手順、環境設定、デプロイメントステップ、ロールバック戦略を概説します。CI/CD パイプラインの詳細と環境固有の要件を含みます。
ケーススタディ：言語設定の構成
これは Kiro に日本語で応答するよう設定する実際の例です：
ファイル：language-preferences.md
## コミュニケーションガイドライン
- Kiro は日本語で出力
- フロントエンドページコンテンツは英語を使用
- コードコメントは日本語を使用
実装ノート
この設定により、開発ワークフローの異なる側面で一貫した言語使用が保証され、各コンテキストに適切な言語選択が維持されます。