記事公開日
AWS KiroのAgent Steering機能を使ってみた②
この記事のポイント
本記事では、AWS Kiroの「Agent Steering機能」を活用し、ToDoリストアプリにユーザー認証とデータ分離機能を実装するプロセスを解説します。開発者が意図する独自の制約をAIに正しく理解させるための実践的なテクニックを紹介します。
- 厳格なバリデーションの実装：
「ユーザー名3文字以上」「パスワード4文字以上」といった具体的な数値制約をSteeringファイルで定義し、AIが生成するコードに正確に反映させる手法を検証しています。 - マルチユーザー環境のデータ分離：
localStorageのキー名にユーザー名を付与する命名規約を定義。AIが「正誤例」を学習することで、ユーザー固有のデータ保存ロジックを100%意図通りに生成できることを確認しました。 - 開発効率と品質の自動担保：
筆者が実際に直面した「データの混在」という課題に対し、プロンプトの繰り返しを避け、プロジェクト固有のアーキテクチャ方針を一貫して維持するSteeringの利便性を独自のデモを通じて実証しています。
はじめに
こんにちは。DXソリューション営業本部の後藤です。
本記事では、前回記事で作成したToDoリストアプリケーションにユーザーログイン機能を追加してみました。
今回のデモを通じて、Steering機能の利便性について深堀りしていこうと思います。
↓前回の記事は以下になります。
デモ
デモの内容・目的
事前にユーザーログイン機能に関する定義設定をSteeringで作成する。
既存のToDoリストアプリケーションにユーザーログインの機能を追加する。
<デモの目的>
Steeringで設定した、ユーザーログイン機能に関する定義に則り提案・実装してくれるのか確認する。
<デモの流れ>
①事前にユーザーログイン機能に関する各定義設定をSteeringで作成する。
↓
②Steering作成後、Kiroにユーザーログイン機能の追加を指示する。
↓
③KiroがSteeringの内容を読み取り、スクリプトの修正案が定義に沿ったものかどうか確認する。
↓
④スクリプト修正後、実際の動作を確認し意図した通りの挙動であることを確認する。
Steeringの作成
ユーザーログイン機能に関する定義を設定していきます。
Steeringのベストプラクティスに則り、以下の2つのSteeringを作成しました。
-
「passwordrule.md」
ユーザーログインに関するスクリプト作成時に参照させるパスワードの制約事項を定義しました。
<記載内容>
①ユーザー名3文字以上。パスワード4文字以上に制限。それ以外の場合は登録不可。
②ユーザーにはパスワードルールを表示。
③ログイン時、ユーザー名およびパスワードが不一致の場合アラートを表示。--- inclusion: fileMatch fileMatch: ["script.js"] --- # 認証ロジックの具体的制約 ## 1. 入力バリデーション - **制約**: ユーザー名3文字以上、パスワード4文字以上の入力を必須とする。 - **アラート**: 条件を満たさない場合は、それぞれ「ユーザー名は3文字以上で入力してください」「パスワードは4文字以上で入力してください」と日本語で表示すること。 - **背景（メリット）**: 不正な形式のデータがlocalStorageに保存されるのを未然に防ぎ、データ整合性エラーによるアプリのクラッシュを防止するため。 ## 2. ログイン失敗時の挙動 - **条件**: ユーザー名が存在しない、またはパスワードが不一致の場合。 - **アクション**: 1. 「ユーザー名またはパスワードが間違っています」とアラートを表示。 2. パスワード入力欄（`loginPassword`）の値をクリアする。 3. `loginPassword` にフォーカスを移動させる。 - **背景（メリット）**: ユーザーに「何が間違っていたか」を明確に伝えつつ、即座に再入力できる状態にすることで、UX（操作性）を損なわないようにするため。 ## 3. セキュリティ：パスワードの取り扱い - **制約**: 登録・照合時には必ず `hashPassword` メソッドを通し、生パスワードのまま比較・保存を行わないこと。 - **背景（メリット）**: ステアリングのセキュリティポリシーに基づき、万が一localStorageのデータが閲覧された際でも、ユーザーのプライバシーを保護するため。
-
「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);
Steering作成時には以下のブログを参考にしてみてください。
↓Steeringファイル作成時のベストプラクティスについて記載しています。
※今回作成したsteeringを参考例として記載してます。
↓Steeringのファイル構造や複数管理の基礎について深堀りしている記事になっています。気になる方はぜひご覧ください！
Steeringの適用の確認
作成済みのToDoリストアプリケーションにユーザーログイン機能を追加してみます。
今回作成したステアリングファイル「passwordrule.md」、「storagekeyrule.md」を参照してこちらの意図通りの提案をしてくれるのか確認します。
期待する動作
「passwordrule.md」と「storagekeyrule.md」を読み込み、設定した仕様に適したコードの修正案を提示してくれること。
各ステアリングファイルの確認事項
・「passwordrule.md」
パスワードの設定の制約に則り、コードを作成してくれるか。設定した数字や挙動の制約通りに提案、実装してくれるか。
・「storagekeyrule.md」
ステアリングファイルで示したコードの正誤判定の基準を理解し、正解のコードを元に提案、実装してくれるか。
ユーザーログインの機能を追加してと指示してみる。
既存のスクリプトを確認し、修正箇所を提示してくれました。
変更箇所の詳細を確認してみると以下の提案をしてくれました。
・ユーザーログインの機能追加とそれに伴うUI画面追加。
・パスワード機能の追加と制限の指定。（パスワードハッシュ化や入力時の制約）
・ストレージキーの保存方法についての実装案。（ユーザー固有による保存方法の確立）
上記の内容はどれも私の意図した通りの提案をしてくれたので、この内容で修正を実行してもらいましょう。
スクリプトを修正してユーザーログイン機能を実装してくれました！
またスクリプトを確認するとパスワードの入力バリデーションについて、ステアリングファイルで設定した内容で実装してくれているのが確認できます。
ストレージキーの保存についてもステアリングファイルで示した正誤判定を理解して、正解で示したコードで実装してくれました。
これによりユーザー固有の保存方法が確立でき、ユーザーデータの混在を防げるようになりました。
ToDoリストアプリを起動すると、ユーザーログインの画面が表示されました。
また新規登録画面が追加されていることを確認できました。
アプリケーションの動作確認
1.「passwordrule.md」の適用の確認
まずは「passwordrule.md」で定義したパスワード設定規則に則っているか確認します。
・ユーザー名が３文字以上必須とする
ユーザー名の必須文字数に足らない場合、エラーになりました。またエラー文字と一緒にアラートが表示されました。
・パスワード4文字以上必須とする。
パスワードの必須文字数に足らない場合、エラーになりました。こちらも同様、エラーと一緒にアラートが表示されました。
パスワードの制限規則設定は問題なく適用されているのが確認できました。
ではルール通りに設定し、「GotoTask」ユーザーを作成してみましょう。すると問題なく登録することができました。
ログインタブから登録した内容を入力し問題なくログインできました。
試しに適当なタスクを作成してみます。動作に関しても正常であることを確認できました。
2.「storagekeyrule.md」の適用の確認
次に個別のユーザー内でタスクの保存ができているか確認したいと思います。
まずは先ほど作成した「GotoTask」の他に「TestUser」を登録してみました。登録後にログインしてみます。
すると先ほど「GotoTask」で作成したタスクは表示されませんでした。
このまま「TestUser」で適当なタスクを作成して、ログアウトしてみましょう。
先ほどの「GotoTask」に再ログインしてみます。
すると、先ほどの「TestUser」のタスクは反映されず「GotoTask」のタスクだけ表示されました。
これにより、ユーザー固有で情報が保存され適切に識別されていることが確認できました！
まとめ
今回のデモを通じて、AWS KiroのAgent Steering機能の利便性を再確認できました。単なるコード生成の指示にとどまらず、プロジェクト固有のバリデーションルールやアーキテクチャ方針を事前に定義しておくことで、AIが開発者の意図を汲み取った実装案を提示してくれます。
これはチーム開発の品質担保において非常に大きなメリットとなると思います。プロンプトで毎回指示を繰り返す手間を省き、一貫した品質を維持するために、Steering機能の積極的な活用をおすすめします。
↓QESではKiroについて積極的に情報発信していきますので是非ご覧ください！
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
