記事公開日
【AWS Kiro】 Steering設定のベストプラクティス
この記事のポイント
AI支援ツール「AWS Kiro」のSteering機能を最大限に活用するための設計指針を解説します。筆者が実際に検証した「正誤判定」の具体例を交え、AIの回答精度を向上させるためのドキュメント作成術と、陥りがちな3つのアンチパターンを詳しく紹介します。
- 1ファイル1定義による精度向上：
API標準やセキュリティなど役割ごとにファイルを分割することで、AIの混乱を防ぎます。公式ドキュメントでも推奨される「5つのファイル構成案」に基づいた構造化が、正確な回答（ハルシネーションの抑制）に直結します。 - 具体的制約と背景（Why）の記述：
「パスワード4文字以上」といった具体的な数値や、localStorage使用の背景など、実装の意図を明記することで、誰が指示しても一貫性のあるコード出力を実現します。 - 「正解・不正解」の提示による統制：
Markdownを活用し、推奨コードと非推奨コード（アンチパターン）を対比させて提示します。筆者の検証では、この定義によりKiroが既存コードのルール準拠を正確に判定できることを実証しました。
はじめに
こんにちは。DXソリューション営業本部の後藤です。
AWS KiroのSteeringを設定する上でのベストプラクティスについて説明したいと思います。
Steering機能についてどういった機能なのか知りたい方はこちらの記事をご覧ください。
※この記事の参考例は以下記事で作成したToDoリストアプリケーションを元に作成しています。
Steeringを設定する上でのベストプラクティス
ステアリングファイルは、AIが理解しやすい構造で定義することが重要です。
既存の設計書や企画書はあくまで人間が読みやすい形式で書かれているため、そのままではAIにとって解釈しづらい可能性があります。 そのため、以下の点を考慮して定義を設定してください。
1ファイルに対して１つの定義項目
どうしてもプロジェクトの概要を詳細に記載しようと思うと冗長的になってしまいます。いくらSteeringで定義していたとしても情報量が多ければそれだけAIは混乱してしまい回答の正確性を担保できません。
規約を1つの大きなファイルにまとめず、役割ごとにファイルを分割して作成しましょう。
参考例
一般的なステアリングファイル戦略として公式ドキュメントでは以下のファイル作成を推奨しています。
いくつかのファイルに分けることで、AIがその定義を判別しやすくより精度の高い回答を出力してくれます。
プロジェクト開始時にこれらを参考にステアリングファイルを作成してみてください。
・API標準（api-standards.md）
REST規約、エラーレスポンス形式、認証フロー、バージョン管理戦略を定義します。エンドポイントの命名パターン、HTTPステータスコードの使用方法、リクエスト/レスポンスの例などが含まれます。
・テストアプローチ（testing-standards.md）
単体テストパターン、統合テスト戦略、モックアプローチ、カバレッジの期待値を確立します。推奨されるテストライブラリ、アサーションスタイル、テストファイルの構成を文書化します。
・コードスタイル(code-conventions.md)
命名パターン、ファイル構成、インポート順序、アーキテクチャ上の決定を指定します。推奨されるコード構造、コンポーネントパターン、回避すべきアンチパターンの例を含めます。
・セキュリティガイドライン（security-policies.md）
ドキュメント認証要件、データ検証ルール、入力サニタイズ基準、脆弱性防止対策。アプリケーション固有の安全なコーディングプラクティスを含めます。
・デプロイメントプロセス（deployment-workflow.md）
ビルド手順、環境構成、デプロイメント手順、ロールバック戦略の概要を示します。CI/CDパイプラインの詳細と環境固有の要件を含めます。
●Steeringについての公式ドキュメントは以下をご参照ください。
ドキュメントの具体性の確保
KiroはSteeringのルールを元に回答を予測して生成します。定義には抽象的な言葉を使用せず必ず明示的に記載しましょう。
AIが正確な情報を回答するにはドキュメントを具体的に提示して、だれが指示を出しても一貫性のある回答を持たせるようにする必要があります。
参考例
ユーザーログインに関するスクリプト作成時に参照させるパスワードの制約事項を定義してみました。
ファイル名：「passwordrule.md」
--- inclusion: fileMatch fileMatch: ["script.js"] --- # 認証ロジックの具体的制約 ## 1. 入力バリデーション - **制約**: ユーザー名3文字以上、パスワード4文字以上の入力を必須とする。 - **アラート**: 条件を満たさない場合は、それぞれ「ユーザー名は3文字以上で入力してください」「パスワードは4文字以上で入力してください」と日本語で表示すること。 - **背景（メリット）**: 不正な形式のデータがlocalStorageに保存されるのを未然に防ぎ、データ整合性エラーによるアプリのクラッシュを防止するため。 ## 2. ログイン失敗時の挙動 - **条件**: ユーザー名が存在しない、またはパスワードが不一致の場合。 - **アクション**: 1. 「ユーザー名またはパスワードが間違っています」とアラートを表示。 2. パスワード入力欄（`loginPassword`）の値をクリアする。 3. `loginPassword` にフォーカスを移動させる。 - **背景（メリット）**: ユーザーに「何が間違っていたか」を明確に伝えつつ、即座に再入力できる状態にすることで、UX（操作性）を損なわないようにするため。 ## 3. セキュリティ：パスワードの取り扱い - **制約**: 登録・照合時には必ず `hashPassword` メソッドを通し、生パスワードのまま比較・保存を行わないこと。 - **背景（メリット）**: ステアリングのセキュリティポリシーに基づき、万が一localStorageのデータが閲覧された際でも、ユーザーのプライバシーを保護するため。
ポイント１：抽象的な表現は避ける
ポイント2：定義の背景を記載する
実装の背景を記載することにより、AIがこのプロジェクトの在り方や進め方、ルールを把握することができ回答の正確性を上げることができます。またチームで作業をする際に、プロジェクト定義の共有がしやすくなるメリットもあります。
例としてコードの「正解」と「不正解」を示す
Markdownの特性を活かし、具体的なコード例を提示してあげましょう。
この定義設定をすることでAIは正しい形式で出力しやすくなります。
これにより、AIがどのような回答を求めているのか判断しやすくなります。
参考例
ストレージキーの使用方法と保存方法について定義設定しました。
ファイル名：「storagekeyrule.md」
---
inclusion: fileMatch
fileMatch: ["script.js"]
---
### ストレージキーの命名規約 (`storage-key-conventions.md`)
マルチユーザー環境において、データの混同を防ぐための実装例です。
# ストレージ管理の正誤例
## 1. ユーザー固有のデータ分離
- **ルール**: localStorage のキーは、必ず `this.storageKeys` を介して取得し、末尾にユーザー名が付与されたものを使用すること。
### ✕ 不正解 (Negative Example)
```javascript
// 理由：固定のキー名を使用すると、他のユーザーと混ざってしまう
const data = localStorage.getItem('todoTasks');
```
### 〇 正解 (Positive Examples)
```javascript
// 推奨：AuthManagerで認証されたユーザーごとのキーを動的に使用する
this.storageKeys = {
tasks: `todoTasks_${username}`,
deletedTasks: `todoDeletedTasks_${username}`
};
// 呼び出し時
const savedTasks = localStorage.getItem(this.storageKeys.tasks);
ポイント1：コード例を明記する
正解・不正解のコードを提示してあげることにより、開発者の意図を汲んでスクリプト作成時にチェックしてくれるようになります。
作成したSteeringを実際に検証してみたブログは以下になります。こちらもぜひ確認してみてください！
回避すべきアンチパターン
続いてアンチパターンについても説明したいと思います。
以下のような設定をしてしまうと、AWS Kiroのパフォーマンスを最大限活かしきれず回答の不安定さに繋がってしまいます。
機密情報の混入
Steeringに機密データなどを直接記述するのはやめましょう。Steeringをベースにコードを作成する関係上、意図せず機密データが混入してしまうリスクもあります。
気づかないうちに情報漏洩してしまうというリスクを避け、重要なデータは必ず手動で入力するようにしましょう！
対策として、セキュリティポリシーのSteeringを作成して毎実行後にチェックしてもらうのも有効かと思います。
ステアリングと変動するタスクの混同
進行中のタスクの進捗や一時的な作業メモをステアリングに書き込まないようにしましょう！
ステアリングは「恒久的な制約」を記述する場所です。
変動するタスク情報はtasks.mdや仕様書（Specs）に分離し、AIが混乱するのを防ぎましょう。
Steeringを更新しない
開発が進むにつれて、当初決めていた設計やライブラリが変わることはよくあると思います。
ステアリングファイルの内容が古いまま（例えば、廃止された関数名や古い仕様が残っている状態）だと、AIが「古いルール」に基づいた間違ったコードを生成してしまい、思わぬエラーや先祖返りの原因になります。
そのため、定期的にSteeringを更新しておき常に最新の情報を記載するようにしましょう！
対策として、新機能の追加やリファクタリングを行った際、必ず関連するステアリングファイルも同時にレビューするようにしましょう。
例：以下のようなタイミングでチェック・更新する。
- スプリント計画とアーキテクチャの変更中にレビューする
- 再構築後のテストファイル参照
- ステアリングの変更をコードの変更と同様に扱い、レビューを必須とする
まとめ
いかがだったでしょうか。今回はAWS KiroのSteeringのベストプラクティスについて説明しました。
Steering機能はプロジェクト全体に一貫性を持たせるという意味では非常に便利な機能です。しかし定義設定を疎かにするとかえってプロジェクト全体での作業パフォーマンスを落としかねません。
Steeringの設定を行うときは、ベストプラクティスを意識し最大限Kiroの利点を活用していきましょう！
↓QESではKiroについて積極的に情報発信していきますので是非ご覧ください！
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
