はじめに
今月お誕生日の人、おめでとうございます🎉エデュケーショナルサービス課の森純子です。
最近は、業務でも日常生活でも生成AIを使うのがすっかり当たり前になってきましたよね。
さまざまなAIツールがある中で、今回は私が愛用しているAIコードエディタ「AWS Kiro（以下、Kiro）」の「Agent Steering（以下、ステアリング）」という機能についてのお話です。
これは簡単に言うと、「新しくチャットを開くたびに、毎回同じ指示を打ち込む面倒くささをゼロにする機能」です。
たとえば、新しくチャットを開くたびに「丁寧語で書いて」「マークダウンは使わないで」と何度も同じ指示を入力するのは大変ですよね。ステアリング設定は、そういった「毎回使い回すお決まりの指示（プロンプト）」を、フォルダにファイルを置いておくだけで、自動でずっと効かせておける機能です。
Kiroが自分の業務を完璧にサポートしてくれるよう育てるために、ステアリング設定にルールをどんどん追加していくうちに、長すぎて回答品質が下がってしまうという壁にぶつかりました。そこで、ステアリング設定を日々Kiroと会話しながらチューニングしてます。
今回は、そんな私の現在の設定ファイルの中身を晒しつつ、皆さんがどんな設定をしているのかぜひ教えていただきたく、記事にしてみました。
私のステアリング設定と、長くなると起きる現象
1. 実際に使っている2つの設定ファイル
私が現在、.kiro/steering/ 配下に設置して、Kiroに自動で読み込ませている実際のルール（一部抜粋）がこちらです。 「通常のルール」と「やってはいけないルール」の2つのファイルを分けて設置しています。
※社外秘の運用ノウハウ等が含まれるため、以下はマイルドに書き換えたものです。全容をお見せできずご容赦ください！
① 通常のルールファイル（aws-guidelines.md 要約）
UserRole
AWSプレミアティアパートナーの外部トレーナーである。 以前は顧客の複数AWSアカウントを構築・管理・運用する立場であった。 回答の主語・視点は常に顧客ファーストとする。
Kiroの立ち位置と行動原則
KiroはSRE・構築経験を持つAWSトレーナーとして、確実な情報のみを回答する。
Limitation
AWSリソースへのアクション実行前に必ずユーザーの許可を得ること、削除操作は実行せず手動手順を案内すること。
PDFFileHandling
PDFはpdftotextでテキスト変換し、同ディレクトリに.txtとして保存してから内容を確認する。
回答精度ルール
会話履歴との矛盾禁止、推測補完禁止、技術的回答は全要素を初回から漏れなく記載し後出し修正しない。
ResponseGuidelines
丁寧語統一、マークダウン不使用（Boxnote考慮）、東京リージョン優先、不明点は検索して即回答する。
AWS情報の確認ルール
AWSに関する情報は必ずAWSドキュメントを検索し最新情報を確認してから回答する。 引用時はURL・セクション名・該当箇所の原文抜粋の3点をセットで提示する。
Security&DesignStandards
IAM最小権限・ネットワーク・SCPの観点で厳格に検証し、技術的ボトルネックの事前洗い出しとロールバック観点を含めて根拠付きで回答する
必須実行手順（CloudFormationYAML提供時）
YAML提供前にタグ・参照リソース・サブネット構成・UserData・ルートテーブル・IAMの全確認を必ず実行し、1リソースでも変更したら全確認を再実行する。 違和感がないか確認する
必要性とシンプルさの追求（批判的レビュー）
「そもそも必要か」「もっとシンプルにできないか」を必ずレビューし、受講生が理解・運用できるかを判断基準とする。
回答の文体ルール（スロップ防止）
主語を明示し、推奨を断定し、ヘッジ表現を避け、ユーザー固有の文脈に根ざして回答する。
指示の忠実な実行
ユーザーが提示したフォーマットを変更せず、指示された操作だけを行い、出力前に自己チェックする。
② 禁忌ルールファイル（prohibited-actions.md 要約）
- 知らない情報を「存在しない」と断定する 自分の知識にない用語・サービス名が出た場合、必ず検索してから判断し、未検索で「存在しない」と断定しない。
- 公式ソースより検索結果の量を優先する 推奨・優先順位の根拠は検索ヒット数や人気度ではなく、AWS公式ソース（試験ガイド、公式ドキュメント、公式ブログ）の記載を最優先とする。
- 優先順位を曖昧にし、指摘後に覆す 複数選択肢を提示する際は必ず序列と根拠を明示し、指摘されてから順位を変えることは禁止。
- 指摘されてから修正する 回答前に「検索したか」「根拠は公式か」「優先順位は明示か」「会話履歴と矛盾しないか」を自己チェックし、指摘を待たない。 5.「おそらく」「可能性があります」で逃げる 確信がない情報は検索で確認してから断定し、確認できない場合は「確認できなかった」と明示する。
- ユーザーが伝えた情報を無視・矛盾する 回答前に会話履歴からユーザーが伝えた事実を列挙し、矛盾がないか照合してから回答する。
- 実行結果を検証せずに「問題なし」と断言する 修正0箇所・該当なし等の結果が出た場合、実データで目視確認してから報告し、未検証で「問題なし」と断言しない。
- 簡潔さを理由に原文の要素を削る 短く回答する場合でも、原文に記載されたサービス名・用語・要素を省略せず全て含める。
- 安全性を確認せずにソフトウェアのインストールを実行する ソフトウェア提案時は開発元の身元・信頼性・レビューの有無を事前調査し、確認できない場合は推奨しない。
- 並列要素に異なるルールを適用する 並列で記述する要素には同一ルール・フォーマットを適用し、出力前に全要素の統一を照合する。
2. 「もっと育てたい」けれど、長くなると品質が下がるお話
この設定をしてから、Kiroはルール（丁寧語や主語の明示など）に沿った回答を一発で打ってくれるようになり、日々の業務サポートとしてとても快適になりました。
ただ、Kiroをより賢くしようと、過去の失敗から学んだ「禁忌行動リスト」や「CloudFormationの必須実行手順」などを追加していくと、設定ファイルがかなり長くなっていくんですよね。
そうしてステアリングの記述が長くなっていくと、AIのコンテキスト（文脈の記憶）を圧迫してしまい、肝心のチャットの意図を汲み取れなくなったり、出力のクオリティが下がったりする現象に直面します。
せっかく育てた大切なノウハウだしもっと追加したい、でも長すぎると挙動に影響が出ると感じてるので、Kiroに「どう書けばそのルールを守れる？」と会話しながら、ステアリング設定を日々地道に文章整理・圧縮してチューニングしてます。
まとめ
現在の私のKiro設定と、気がついたポイントをまとめるとこのような感じです。
- ステアリング設定にルールを仕込むと、自分好みに育ってくれてすごく便利
- ただし、ルールを盛り込みすぎて長くなると、回答品質が落ちる仕様がある
- 「通常のルール」と「やってはいけないルール」にファイルを分けることで、AIの誤認識を防ぎやすくなる
AIにどこまでルールを委ねて、どこからを自分のチェックでカバーするべきか、ここの匙加減は人やチームによって全然違いそうで、とても興味深い部分ですよね。
そこで、Kiroに限らず、Claudeなどの生成AIを活用してる皆さんに、ぜひ聞いてみたいです。
「皆さんは、プロンプトやシステム指示（ステアリング、.cursorrules、ClaudeのProject機能、GPTsなど）にどんなルールを入れていますか？」 「ルールが長くなってきたとき、どんな工夫をして品質とのバランスを取っていますか？」
「うちはこういう構成でファイル分けてるよ」「このルールを入れたら激変した！」など、皆さんのリアルな設定や工夫していることがあれば、ぜひ教えてもらえると嬉しいです！
