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

はじめに

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

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

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

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

この記事自体の書き方

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

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 設定後

設定前：

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

設定後：

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

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

背景

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

• 未公開のプロジェクト名や製品名の漏洩
• 顧客・取引先の社名や個人名の露出
• 社内システム情報の流出
• 商用キャラクター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が草稿完成後に自動でレビューを実施
5. 問題なしになったら投稿

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）
プロジェクト固有ルール	<project>/.kiro/steering/ に配置
特定ファイル編集時だけ適用	inclusion: fileMatch + パターン
ウィンドウ間でのリセット防止	steeringに置けば永続化

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

参考

• Kiro公式サイト

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