はじめに
前回の入門編記事では、Kiro CLIの全体像とsteeringファイルの基本的な使い方を紹介しました。
今回は中級編として、steeringをより実践的に活用するテクニックと、繰り返し業務を自動化する「スキル」の使い方を紹介します。コーディングに限らず、資料作成や調査、運用報告といった日常業務にも使える考え方です。
この記事で扱う内容：
- steeringの精度を上げるための書き方
- steeringの階層設計
- スキルによる業務の定型化
steeringで精度を上げる
steeringはいつ読み込まれるのか
前回の入門編では「steeringはチャット開始時に読み込まれる」と説明しました。より正確には、steeringの内容はユーザーが毎回プロンプトを投げたタイミングで同時にAIへ渡されています。
公式ブログでは、steeringは「persistent AI context（永続的なAIコンテキスト）」であり「you write it once in a steering file, and the AI reads it automatically as it starts working on your requests（一度ファイルに書けば、AIがリクエストに取り掛かる際に自動で読み取る）」と説明されています。
つまり、構造としては以下のようになっています。
[steering の内容] ← リクエストのたびに含まれる
[ユーザーのメッセージ]
[AIの応答]
会話履歴が長くなっても steeringは常に最新のメッセージと一緒に渡されるため、ルールが反映されやすいです。
ただし、LLMは一度に処理できる情報量の上限（コンテキストウィンドウ）があるため、steeringが長くなりすぎないように注意が必要です。
steeringには何を書くと効果的か
steeringには、何を書くべきでしょうか。公式ドキュメントやベストプラクティスを調べると、ツールごとに少しずつ観点が異なります。
| ソース | 書くべきもの | 書かなくてよいもの |
|---|---|---|
| Kiro公式ドキュメント | プロダクトの目的とユーザー像、技術スタック、ファイル構成と命名規則、意思決定の理由 | （明示なし） |
| Kiro公式ブログ | 「どう働くか」の定義：コーディングスタイル、テスト方針、セキュリティ要件、ドキュメント基準 | APIキー、DB認証情報、顧客データ、頻繁に変わる情報 |
| Claude Code公式 | AIが推測できないコマンド、デフォルトと異なるルール、環境のクセ、よくあるハマりどころ | コードを読めばわかること、言語の標準的な慣例、長い説明やチュートリアル、自明な指示 |
| Efficient Token Usage on Kiro | always: 基本ルール。fileMatch: ドメイン別ルール。manual: 稀に見るリファレンス | 全部をalwaysに入れること（context rotが起きる） |
それぞれの観点を整理すると、3つのカテゴリに集約できます。
- プロジェクトの文脈 — 何のために、誰のために作っているか。技術スタック、アーキテクチャの方針
- チームの取り決め — デフォルトから外れるルール、命名規約、ワークフロー、レビュー基準
- 環境の固有情報 — パス、コマンド、エイリアス、ハマりどころ
逆に、どのソースにも共通して記載すべきでないとされる内容は次の2点です。
- AIがコードや一般知識から推測できる情報（長い説明、チュートリアル的な記述）
- 機密情報（steeringはプレーンテキストで、Git管理することが推奨されているため）
また、先述した通りsteeringに情報を詰め込みすぎると「context rot（コンテキストの腐敗）」と呼ばれる現象が起きるため、記載する情報は最小限にすることを意識しましょう。
steeringの階層設計 — プロジェクトとタスクの情報を両方渡す
AIによる応答精度を上げるポイント
前章で「AIが知らない固有情報を書く」と述べましたが、固有情報にも粒度があります。
- プロジェクトの背景 — 技術スタック、アーキテクチャ方針、チームの規約など。プロジェクト内で共通
- タスクの背景 — 今やっている作業の要件、制約、進め方。タスクごとに異なる
この2つを両方渡せると、AIの応答精度は大きく上がります。しかし、Kiroが読み込めるsteeringは「グローバル（~/.kiro/steering/）」と「起動フォルダ（.kiro/steering/）」の2箇所のみです。プロジェクトルートでkiroを起動すればプロジェクト背景は渡せますがタスク背景は渡せず、また逆も然りです。
解決策：3層構造 + シンボリックリンク
上記の課題に対し、steeringを3つの層に分け、タスクフォルダで起動する運用方法を紹介します。
Layer 1: ~/.kiro/steering/ グローバル（全プロジェクト共通）
Layer 2: my-project/.kiro/steering/ プロジェクトレベル
Layer 3: my-project/tasks/task-a/.kiro/steering/ タスクレベル
| 層 | 置く情報 | 例 |
|---|---|---|
| Layer 1 | 全プロジェクト共通のルール | （例）日本語応対、コーディング規約 |
| Layer 2 | プロジェクト固有の共通情報 | （例）プロジェクト概要、技術スタック |
| Layer 3 | タスク固有の指示 | （例）要件、制約、作業の進め方 |
基本的な運用方法としては、取り組みたいタスクのディレクトリで kiro-cli を起動します。そうすると Layer 1（グローバル）と Layer 3（そのフォルダ内の steering）が読み込まれ、タスクの文脈を理解した状態でAIが応答してくれます。
プロジェクト共通情報をシンボリックリンクで引き込む
ここで問題になるのが Layer 2（プロジェクト共通情報）です。タスクフォルダでkiroを起動した場合、上位ディレクトリのsteeringは自動では読み込まれません。この問題についてはシンボリックリンクで解決します。
シンボリックリンクとは、別の場所にあるファイルへの「ショートカット」です。ファイルをコピーせず、元ファイルへの参照を作ります。リンクを開くと元の内容が読まれるため、実体は1箇所で管理しつつ複数の場所から参照できます。
# タスクフォルダにsteering用ディレクトリを作成
mkdir -p my-project/tasks/task-a/.kiro/steering/
# プロジェクト概要へのシンボリックリンクを作成
ln -s /home/user/my-project/.kiro/steering/project-overview.md \
my-project/tasks/task-a/.kiro/steering/project-overview.md
コピーではなくリンクを使う理由は、steeringの実体ファイルを1箇所で管理するためです。プロジェクト概要を更新すれば、全タスクに即座に反映されます。コピーの場合、更新漏れや内容の乖離が起きやすくなるため、シンボリックによる運用を推奨します。
最終的なタスクフォルダのsteeringの構成は以下のようになります。
my-project/tasks/task-a/.kiro/steering/
├── task-a-steering.md ← タスク固有（実体ファイル）
└── project-overview.md ← プロジェクト共通（シンボリックリンク）
この状態で task-a/ フォルダから kiro-cli を起動すると、Layer 1（グローバル）に加えて、タスク固有の情報とプロジェクト共通の情報が両方読み込まれます。必要な情報だけが過不足なく渡るので、AIの回答精度が上がります。
また運用のポイントとして、毎回上記のコマンドを打つのは大変なので、新しいタスクを始めるときは、決まったフォルダ構成＋シンボリックリンクを含む.kiroフォルダを自動作成するスキルを作成することをおすすめします。スキルについては次の章で紹介します。
スキルで定型業務を自動化する
スキルとは
スキルは、繰り返し行う作業の手順をMarkdownで定義し、AIに再現させる仕組みです。入門編で概要を紹介しましたが、ここでは実際にスキルを作って使う方法を掘り下げます。
スキルの本質は「自分の仕事のやり方をドキュメント化して、AIに毎回同じ品質で実行させる」ことです。一度作れば、同じ種類の業務が発生するたびにAIが手順に沿って作業してくれます。
スキルの仕組み
チャットを開始すると、Kiroは ~/.kiro/skills/ と .kiro/skills/ に配置されたスキルの名前と説明文を読み取ります。ユーザーのリクエストがスキルの説明文にマッチすると、Kiroがそのスキルを自動的に読み込んで手順に従います。
スキルは以下のフォルダ構造で作成します。
~/.kiro/skills/my-skill/
├── SKILL.md # 必須：手順と説明
└── references/ # 任意：補足資料
└── template.md
SKILL.md のフォーマットは以下のようになります。
---
name: my-skill
description: このスキルが何をするか、どんなときに使うか。
---
## 手順
1. ○○を確認する
2. △△を実行する
3. 結果を□□の形式で出力する
フロントマターの name と description が必須です。description にはスキルが発動すべき場面を具体的に書きます。Kiroはこの説明文をもとに、ユーザーのリクエストとマッチングを行います。
スキル作成の流れ
スキル作成は以下のステップ1~4をAIと伴走しながら作業を進めましょう。会話履歴や出力ファイルのパスをAIに渡し、「スキルを作成して」と指示することで簡単に作ることができます。
| ステップ | やること | ポイント |
|---|---|---|
| 1. 実践 | まず手動で業務を1回やってみる | スキル化は実際にやった後。先に手順を把握する |
| 2. 標準化 | 出力形式・判断基準を固める | 「次も同じ形で出せるか」を基準にする |
| 3. スキル作成 | SKILL.mdに手順と出力例を書く | 抽象的な説明より具体例を入れる |
| 4. 改善 | 使いながらスキルを更新する | 最初から完璧を目指さなくてよい |
実例
例えば、私が実際に利用しているスキルの一つに、インフラ運用の月次報告資料作成スキルがあります。実施してくれることは以下の通りです。
- Cost Explorerから、複数のAWSアカウントのコスト情報を取得
- 前月比を算出して表形式で整理
- 大きな増減があるサービスを検出し、原因の調査方針を提示
- Security Hubから、アカウント内のセキュリティ状況を調査し、詳細を報告
以前は手作業で各アカウントのコンソールへアクセスし、情報を集計していました。スキルを作ってからは「今月の運用報告準備して」と伝えるだけで、データ収集から差分分析まで進みます。最終的な報告資料への記載と確認は人間が行いますが、そこに至るまでの作業時間は大きく短縮できました。
公開スキルの活用
スキルは自作するだけでなく、公開されているものを取り込むこともできます。
例えば、Vercelが公開しているReact Best Practices（https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices） は、React/Next.jsのパフォーマンス最適化ガイドラインをスキル化したものです。コードを書くときやレビューするときに、ベストプラクティスを踏まえた応答が返ってくるようになります。
Kiro-CLIにおける公開スキルの使い方は以下の通りです。
- GitHubからスキルフォルダをダウンロード
-
~/.kiro/skills/に配置 -
SKILL.mdのフロントマター（nameとdescription）が記載されていることを確認
スキルは Agent Skills というオープン仕様に準拠しているため、対応しているツール間で使い回すことができます。
まとめ
共通するポイントは「AIにプロジェクト固有の文脈を渡すほど、出力の精度が上がる」ということです。逆に言えば、文脈を渡さなければ汎用的な回答しか返ってきません。steeringとスキルは、AIを自分の業務に特化させるための仕組みです。
次回の上級編では、エージェントとMCPを使って開発環境をさらに拡張する方法を紹介予定です。