Kiro IDE の Steering で既存コードからルールを起こし、AI を「プロジェクト理解状態」にしてみた

はじめに

この記事では、既存のプロジェクトコードをもとに Kiro IDE の Steering 機能を活用し、AI に対する指示の精度を高めた取り組みを紹介します。

AI コーディング支援では「プロンプトの書き方」が重要だと言われています。
Kiro ではさらに一歩進んで、プロジェクト自体を AI に理解させる仕組み（Steering） が提供されています。

今回は Kiro IDE を使い、開発途中の自作プロダクトに対して Steering を生成しました。
それをベースにルールを整備することで、AI の出力品質を改善してみました。

背景・課題

vibe コーディングをしていると、次のような課題を感じることが多いのではないでしょうか。

• AI に毎回プロジェクトの前提を説明する必要がある
• 既存の構成や技術スタックを無視した提案が出る
• コードの配置や設計方針がブレる

つまり、次のような状態です。

AI がプロジェクトを知らないまま、毎回ゼロから動いている

アプローチ

1. Steering の自動生成

Kiro IDE の「Generate Steering Docs」を使い、既存のコードベースから次のファイルを自動生成しました。

• product.md（プロダクト概要）
• tech.md（技術スタック）
• structure.md（プロジェクト構成）

驚いたのは、Spec モードのチャットで対話しながら作ったプロダクトでも、プロジェクトの前提情報を AI がまとめて定義として書き起こしてくれる ことです。
これにより、プロジェクトの前提が AI と共有された状態になります。

2. リバースエンジニアリングとして捉える

このステップの本質は、次の変換にあります。

既存コード → 暗黙知 → 明示的なルール（Steering）

つまり、Steering の生成は単なるドキュメント作成ではありません。
コードに埋もれた設計思想を抽出し、暗黙的なルールを言語化する リバースエンジニアリング と捉えることができます。

プロジェクトの前提情報を AI がリバースエンジニアリングし、暗黙知をドキュメントとして再構築してくれます。

3. Steering の補強（重要）

自動生成された内容は、あくまで「現状の観測結果」です。
そのため、次のような観点で追記・修正する必要があると思います。

• なぜその構成なのか（Why）
• コーディング規約
• API 設計ルール
• 禁止事項・アンチパターン

また、用途ごとにカスタム Steering ファイルを追加すれば、さらに精度を高められそうです（今回は未実施です）。

例として、次のようなファイルが考えられます。

• code-conventions.md
• api-standards.md
• testing-guidelines.md

期待できる効果

Steering を導入すると、AI の挙動に次のような変化が期待できます。

1. プロジェクトの前提を踏まえた提案

• 既存の技術スタックに沿った実装を提案してくれる
• 不要なライブラリの提案が減る

2. コード配置の精度向上

• 適切なディレクトリにファイルを生成してくれる
• 既存の構造との整合性が高まる

3. 指示コストの削減

• 毎回の前提説明が不要になる
• プロンプトが簡潔になる

気づき

今回の取り組みで得られた、重要な学びは次の 2 点です。

Steering = AI の長期記憶

Steering は単なる設定ファイルではありません。
次のように、AI にとっての知識ベースとして機能することが期待できます。

AI にとっての、プロジェクト知識ベース

重要なのは To-Be の定義

自動生成された Steering は As-Is（現状）です。
本来重要なのは、次の 2 点を Steering として定義することです。

• 将来どうあるべきか（To-Be）
• チームとして守りたい規約

まとめ

Kiro の Steering 機能を活用することで、次のような開発スタイルが実現できました。

• 既存コードからルールを抽出する（リバースエンジニアリング）
• AI にプロジェクトを理解させる
• 指示の精度を向上させる

AI を活用するうえで重要なのは「良いプロンプト」だけではありません。
「良いコンテキストを与えること」 であり、Steering はその中核になる仕組みだと感じています。

Kiro IDE を使っている方は、Steering の活用を検討してみてはいかがでしょうか。

要点（短く伝えるなら）

• Steering は、AI にプロジェクトを理解させる仕組みです。
• Generate を使えば、既存コードから自動で抽出できます。
• そこに「理想のルール」を追記するのがポイントです。

付録: 自動生成された tech.md の例

参考として、自動生成された tech.md の例を掲載します。
題材は、記事管理を行う Web アプリです。

# 技術スタック

## フレームワーク & ランタイム

- **Next.js 16**: App Router を使用（Pages Router は不使用）
- **React 19**: デフォルトで Server Components
- **TypeScript 5**: strict モード有効

## バックエンドサービス

- **DynamoDB**: プライマリデータベース（`@aws-sdk/client-dynamodb` + `@aws-sdk/lib-dynamodb` 経由）
- **S3**: ファイル添付ストレージ（`@aws-sdk/client-s3` 経由）。ローカルでは MinIO を S3 互換の代替として使用
- **JWT**: 認証トークン。サーバーサイドは `jsonwebtoken`、Edge / middleware は `jose` を使用
- **bcryptjs**: パスワードハッシュ化

## 主要ライブラリ

| ライブラリ | 用途 |
|-----------|------|
| `react-markdown` | Markdown 記事コンテンツのレンダリング |
| `uuid` | ユニーク ID 生成 |
| `fast-check` | プロパティベーステスト（開発用） |

## ローカル開発インフラ

`docker-compose.yml` で定義:

- **DynamoDB Local**: ポート 8000
- **MinIO**（S3 互換）: ポート 9000（API）/ 9001（コンソール）

`USE_LOCAL_DB` と `USE_LOCAL_S3` の環境変数で制御します（デフォルトはローカル）。

## よく使うコマンド

```bash
# ローカルインフラ起動 (DynamoDB Local + MinIO)
docker-compose up -d

# 開発サーバー起動 (http://localhost:3000)
npm run dev

# プロダクションビルド
npm run build

# プロダクションサーバー起動
npm start

# Lint 実行
npm run lint
```

## TypeScript 設定

- パスエイリアス: `@/*` はプロジェクトルート（`./`）にマッピング
- モジュール解決: bundler
- ターゲット: ES2017
- strict モード有効