Kiroの「steering」で毎回伝えていたルールを全自動化した話 ─ AIの口調変更もやってみる

👋 はじめに

AWS発のAI IDE「Kiro」（現在パブリックプレビュー段階）には steering（ステアリング） という仕組みがあります。マークダウンファイルを所定のフォルダに置くだけで、AIの振る舞いに対して「常時適用されるルール」を注入できる機能です。

「Qiitaの記事書くときは毎回このルールで」「口調はこうして」「レビュー必ず通して」──こういう指示を毎回チャットで伝えていませんか？ steeringを使えば、一度定義するだけで永続的に自動適用されます。

この記事では、steeringを使って以下2つを自動化した事例を紹介します。

1. AIの口調を好みのキャラクターに固定する（ウィンドウを開き直しても維持される）
2. 記事作成時に情報セキュリティ・法務レビューを自動で挟む（ファイル名で自動検知 + hookで完全自動化）

✍️ この記事自体の書き方

この記事自体も以下のフローで書いています。

1. Kiro（AI）に原案を生成させる ─ 構成・文面の叩き台をAIに任せる
2. 自分で手直しする ─ 文体の調整、情報の正確性確認、自分の言葉にする
3. 社内AIにレビューさせる ─ 情報漏洩・著作権侵害がないかチェック

このフローの「3」を手動でやっていた部分を、steeringで自動化したのが本記事のテーマです。

📁 steeringフォルダとは

💬 一言で言うと

「AIに対する永続的なルール置き場」 です。

チャットで毎回伝え直す必要なく、ファイルとして置いておくだけでAIの全応答に自動適用されます。いわばAIの .bashrc や .gitconfig のようなものです。

📂 配置場所と効果範囲

配置場所	効果範囲	用途例
~/.kiro/steering/	全ワークスペース・全ウィンドウ（グローバル）	口調設定、アカウント情報、個人ルール
<プロジェクト>/.kiro/steering/	そのプロジェクトのみ（ワークスペース）	コーディング規約、DB設計ルール、API設計

ワークスペースレベルがグローバルと競合した場合、ワークスペースレベルが優先されます。

🔀 inclusionモード（読み込み方式）

steeringファイルのフロントマター（YAML）で、いつ読み込むかを制御できます。

---
inclusion: manual
---

モード	動作	使い所
（指定なし）	常時自動読み込み	口調設定など、常に効かせたいルール
inclusion: fileMatch	指定パターンのファイルがコンテキストに含まれた時だけ	特定の作業時だけ適用したいルール
inclusion: manual	チャットで #ファイル名 と指定した時だけ	必要な時だけ呼び出す情報

🎭 お題①：AIの口調を変更して全ウィンドウに適用する

🎯 やりたいこと

Kiroの応答の口調をカスタムキャラクターに固定し、どのプロジェクトを開いても、新しいウィンドウでも維持されるようにする。

📝 手順

~/.kiro/steering/ 配下にペルソナ定義のmdファイルを配置するだけです。

~/.kiro/steering/custom-persona.md

# AI口調設定

## 基本設定
- 一人称：「あたし」
- ユーザーへの呼び方：「あんた」
- ツンデレ気味で素直じゃないが、面倒見は良い

## 口調の特徴
- 命令系：「〜しなさいよ」「〜してよね」
- 断定系：「〜でしょ」「〜に決まってるでしょ」
- 照れ隠し：「べつに、そんなんじゃないし」

## 制約
- コード（変数名・関数名）は通常通り英語で書く
- 技術的な正確性は犠牲にしない
- 口調は会話部分のみ。コード品質は維持する

💡 ポイント

• フロントマターを付けない（= 常時自動読み込み）のが重要
• グローバル（~/.kiro/steering/）に置くことで全ウィンドウに適用
• プロジェクト固有の設定と競合しない（ワークスペースsteeringが優先されるため）
• 「普通の口調に戻して」と明示すれば一時的に解除できるようルールに含めておくと便利

🔄 設定前 vs 設定後

設定前：

はい、そのファイルを修正します。以下の変更を適用しました。

設定後：

はぁ？ そんなの当たり前でしょ。…しょうがないわね、直してあげるから黙って待ってなさい。

🔒 お題②：記事投稿前の法務レビューを自動化する

ここからはガラッと実用的な話に変わるわ。…じゃなくて、変わります。口調カスタマイズは「楽しい」側面ですが、ここからは「仕事で必要な安全装置」としてのsteeringの使い方です。

🚨 背景

技術記事を投稿する際、以下のリスクがあります。

• 未公開のプロジェクト名や製品名の漏洩
• 顧客・取引先の社名や個人名の露出
• 社内システム情報の流出
• 商用キャラクターIPの不適切な使用
• 著作権侵害の可能性

これを毎回手動でチェックするのは面倒です。steeringに「記事作成時は必ずレビューを通す」ルールを定義し、ファイル名パターンで自動検知させます。

🎯 fileMatchで「記事っぽいファイル」を自動検知する

ここがポイントです。inclusion: manual だと #ファイル名 を毎回打つ必要があり、忘れる可能性があります。

代わりに inclusion: fileMatch を使います。

---
inclusion: fileMatch
fileMatchPattern: '**/qiita*.md'
---

こうすると、ファイル名が qiita で始まるmdファイルを開いた・編集した・コンテキストに含めた時に自動でルールが読み込まれます。記事の命名規則を qiita-<slug>.md に統一しておけば、何もしなくてもレビュールールが効くわけです。

📄 設定ファイルの全体像

~/.kiro/steering/qiita-rules.md

---
inclusion: fileMatch
fileMatchPattern: '**/qiita*.md'
---

# 記事作成ルール

## アカウント情報
- アカウント名: <あなたのアカウント>
- マイページURL: https://qiita.com/<アカウント名>

## 文体
- 既存記事の文体を踏襲すること
- 記事末尾に免責文を入れること

## 法務・情報セキュリティレビュー（必須）
記事の草稿完成後、投稿前に必ず以下の観点でレビューを実施する：

- 未公開のプロジェクト名や製品名
- 顧客や取引先の個人名や社名
- 社内の連絡先やシステム情報
- 不適切な表現や著作権侵害の可能性
- 商用キャラクター名やIPの無断使用（サンプルコード内も含む）

問題がある場合は具体的に指摘し修正。
「この投稿は問題ありません。」と判断できるまで繰り返す。

🔄 使い方の流れ

1. 記事ファイルを qiita-<slug>.md の命名規則で作成する
2. Kiroで記事を編集する or コンテキストに含める
3. → 自動的にルールが読み込まれる（# とか打つ必要なし）
4. AIに「レビューして」と依頼すると、steeringのルールに従ったレビューが実施される
5. 問題なしになったら投稿

注意: steeringはあくまで「AIにルールを注入する」仕組みです。ルールが読み込まれた状態で「レビューして」と指示すれば、その観点に従ったチェックが行われます。ただし、ファイル保存のたびに自動でレビューを走らせたい場合は、次に紹介する hook との組み合わせが必要です。

🪝 hookと組み合わせて完全自動化する

Kiroには hook という仕組みもあります。IDEイベント（ファイル保存、ファイル作成など）をトリガーにしてAIアクションを自動実行できる機能です。

steeringが「ルールの定義」なら、hookは「実行タイミングの定義」です。両者を組み合わせることで、ファイルを保存するだけで法務レビューが自動実行される環境を作れます。

hookの設定例（.kiro/hooks/qiita-legal-review.json）：

{
  "name": "Qiita記事 法務レビュー",
  "version": "1.0.0",
  "when": {
    "type": "fileEdited",
    "patterns": ["**/qiita*.md"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "編集されたQiita記事に対して、情報セキュリティ・法務観点でレビューしてください。未公開プロジェクト名、顧客情報、社内システム情報、著作権侵害、商用IPの無断使用がないかチェックし、問題なければ「この投稿は問題ありません。」と回答してください。"
  }
}

こうすると、qiita*.md を保存するたびにAIが法務レビューを自動実行します。steeringで「何をチェックするか」のルールを定義し、hookで「いつチェックするか」のタイミングを定義する──この分担が綺麗に機能します。

📊 inclusionモードの選び方まとめ

方式	メリット	デメリット	おすすめ場面
常時（指定なし）	確実に毎回効く	関係ない作業時もコンテキスト消費	口調設定
fileMatch	必要な時だけ自動で効く	ファイル命名規則の統一が前提	記事作成ルール
manual	コンテキスト節約	# を打ち忘れると効かない	参照頻度の低い情報

記事作成ルールには fileMatch が最適解です。ファイル名さえ揃えておけば、忘れようがない。

🚫 実際に引っかかった例

今回この記事を書く過程で、AIが生成した最初の草稿には以下の問題がありました。

指摘1：商用キャラクター名のサンプルコードへの直接使用

口調カスタマイズの説明で、AIが特定の商用キャラクター名をファイル名やコード例にそのまま埋め込んでいました。「〇〇-persona.md」のようにキャラ名がファイル名に入っていたり、口調の説明文中にキャラクターの固有名詞が残っていたり。

→ 一般化した表記（「custom-persona.md」「好みのキャラクター」）に置き換え。

指摘2：設定ファイルの例文から元ネタが特定できる

口調サンプルの「一人称」「語尾パターン」「性格説明」の組み合わせが、特定の商用キャラクターを容易に特定できる状態でした。著作権侵害の直接的リスクは低いものの、商用IPのイメージを使った記事と受け取られる可能性がありました。

→ 特定キャラクターを想起させない程度に抽象化し、「ツンデレ風」「お嬢様口調」のような一般的な類型として記述。

ポイント：AIは指示通りに忠実に書くので、「このキャラの口調で」と依頼すると、そのまま固有名詞を出力に含めてしまいます。人間が手直しする段階で気づけばいいですが、見落としもある。だからこそ自動レビューの仕組みが必要でした。

🧩 steeringフォルダの活用パターン

ファイル	用途	配置	inclusion
custom-persona.md	AIの口調設定	グローバル	常時
qiita-rules.md	記事作成ルール	グローバル	fileMatch (**/qiita*.md)
coding-standards.md	コーディング規約	ワークスペース	常時
database-schema.md	DB設計ルール	ワークスペース	常時
react-patterns.md	Reactの書き方	ワークスペース	fileMatch (*.tsx)

📝 まとめ

やりたいこと	設定方法
AIの口調を全体で固定	~/.kiro/steering/ にペルソナmd（常時読み込み）
記事作成時にレビュー観点を注入	~/.kiro/steering/ にルールmd（fileMatch）
ファイル保存時に自動でレビュー実行	hook（fileEdited + askAgent）と組み合わせ
プロジェクト固有ルール	<project>/.kiro/steering/ に配置
特定ファイル編集時だけ適用	inclusion: fileMatch + パターン
ウィンドウ間でのリセット防止	steeringに置けば永続化

steeringは「AIへの長期記憶の注入」です。毎回同じ指示を出す手間を排除し、個人のルールを一度定義すれば永続的に効かせられます。hookと組み合わせれば「いつ実行するか」も制御でき、口調のようなカスタマイズから、法務レビューのような実務ガードレールまで、使い道は広いです。

Kiroは現在パブリックプレビュー段階です。機能や仕様は今後変更される可能性があります。最新情報は公式サイトを確認してください。

📚 参考

• Kiro公式サイト
• Kiro公式ドキュメント - Steering
• Kiro公式ドキュメント - Hooks

本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。