はじめに

この記事では、既存のプロジェクトコードをもとに 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 モード有効