はじめに
AIエージェントツールではClaude CodeやCursorなどがメジャーになっていますが、Kiro CLIを使っている、もしくは気になっている人も多いのではないでしょうか。
私もKiro CLIを実際に使い込んでおり、便利さを実感しています。インフラエンジニアである私の目線から、実際に役立った場面をいくつか挙げてみます。
- AWS環境のリソース情報を整理して、構成図やIaCコードまでを自動生成してくれた
- 日々の業務やプロジェクトの背景を覚えさせることで、成果物の品質が目に見えて向上した
- タスクが終わると次にやるべきことを自ら提案してくれるようになった
- 要件を伝えただけで仕様書とTodoが出力され、アプリ開発未経験の私でも簡単なアプリが作れた
上記のような効果を実現するポイントは、自分のプロジェクトのルールや背景情報、仕事のやり方を覚えさせ、自分なりのAIを”育てる”ところにあります。様々な情報をコンテキストとしてインプットさせることでAIが賢くなり、アウトプットの精度も上がっていきます。
この記事では、Kiro CLIの全体像と最初に試してほしい機能を紹介します。さらに、今後はその他機能やその活用方法についても紹介予定です。Kiro CLIを使っているけどまだ使いこなせていない方、興味がある方の参考になれば幸いです。
Kiro CLIとは
Kiro CLIは、AWSが提供するAIコーディングアシスタントのCLI版です。
イメージとしては、自分が利用するローカルPCの中にAIエージェントが入り込み、自然言語で会話しながらファイル操作やコマンド実行、コード生成などを行えます。内部ではAnthropicのClaudeモデル（Opus / Sonnet / Haiku）が使われており、用途に応じてモデルを切り替えることもできます。
本記事の環境は以下のとおりです。
| 項目 | 内容 |
|---|---|
| OS | Windows 11（WSL2 / Ubuntu） |
| エディタ | VSCode（WSL接続） |
| Node.js | v20.20.0 |
| Kiro CLI | 1.27.2 |
インストール方法は 公式ドキュメント を参照してください。セットアップが完了したら、以下のコマンドでチャットを開始できます。
kiro-cli
起動すると上記のようなチャット画面が開き、自然言語で指示を出せます。「このファイルを読んで」「テストを実行して」「READMEを作って」といった依頼を、会話の中でそのまま実行してくれます。ファイルの読み書き、bashコマンドの実行、Web検索、さらにはAWSのリソース操作まで、ターミナルから離れずに行えるのが特徴です。
Kiroを「育てる」4つの仕組み
Kiroには、開発や業務を効率化し、自分の仕事のやり方を学習させるための仕組みが4つあります。ここではそれぞれの概要を紹介します。
steering — ルールを教える
steeringは、プロジェクトのルールや背景をKiroに教えるためのMarkdownファイルです。Claude CodeのCLAUDE.mdに相当する機能です。
.kiro/steering/ ディレクトリにファイルを置いておくと、チャットを開始するたびにKiroが自動的に読み込みます。「コミットメッセージは日本語で」「AWSリージョンは東京リージョン」「セキュリティグループは最小権限で」といったルールを書いておけば、毎回説明しなくてもKiroがそのルールに従って動きます。
開発ルールだけでなく、「日本語で応対する」「提案するときは根拠を示す」のような作業スタイルの指定にも使えます。ファイルベースで管理できるので、チームで共有したりバージョン管理したりするのも簡単です。
スキル — 手順を覚えさせる
スキルは、繰り返し行う作業の手順書です。
たとえば「見積もり資料を作るときはこのフォルダ構成で、この手順で進める」「レビューはこの観点でチェックする」といったワークフローを定義しておくと、該当する場面でKiroが自動的にその手順に従います。
一度作ったスキルは何度でも再利用できるので、作業のたびに手順を思い出したり、説明し直したりする必要がなくなります。
エージェント — 役割を分ける
エージェントは、目的に応じてAIの役割を切り替える仕組みです。
たとえば「調査専門のエージェント」「コードレビュー専門のエージェント」「チケット管理専門のエージェント」を作っておくと、タスクに応じて最適なエージェントを使い分けられます。それぞれのエージェントに異なるツールや権限を持たせることもできます。
さらに、メインのエージェントからサブエージェントを呼び出す連携も可能です。「この部分は調査エージェントに任せて」といった分業ができます。
MCP — 外部ツールと繋げる
MCP（Model Context Protocol）は、外部サービスとKiroを連携させる仕組みです。Claude Codeでも同じMCPの仕組みが使えます。
BacklogやGitHubなどのプロジェクト管理ツール、AWSのドキュメント検索、料金計算ツールなど、さまざまなサービスをKiroから直接操作できるようになります。たとえばBacklogのMCPを設定すれば、「このチケットのコメントを取得して」「レビュー結果を投稿して」といった操作がチャットの中で完結します。
この記事では、最も基本的なsteeringを実際に設定してみます。スキル・エージェント・MCPについては、中級編・上級編で紹介予定です。
まず試してみよう：steeringファイルを作る
steeringファイルの置き場所
steeringファイルの配置場所は2つあります。
~ はホームディレクトリを意味します。WSLの場合は /home/ユーザー名、macOSの場合は /Users/ユーザー名 に展開されます。VSCodeのターミナルで pwd と打つと確認できます。
1つ目はグローバル（全プロジェクト共通）です。ホームディレクトリ直下の .kiro/steering/ に置きます。
~（ホームディレクトリ）
└── .kiro/
└── steering/
└── global_steering.md ← 全プロジェクト共通のルール
ここには「日本語で応対する」「コミットメッセージは日本語」のような、どのプロジェクトでも共通のルールを置きます。グローバルのsteeringは、どのフォルダで kiro-cli を起動しても自動的に読み込まれます。
2つ目はワークスペース（プロジェクト固有）です。 kiro-cli を起動するプロジェクトフォルダの中に .kiro/steering/ を作ります。
~/projects/my-app/ ← このフォルダでkiro-cliを起動
└── .kiro/
└── steering/
└── local_steering.md ← このプロジェクト固有のルール
ここには「このプロジェクトはCDKで構築」「デプロイ先はAWSの東京リージョン」のような、プロジェクト固有の情報を置きます。
両方にファイルがある場合は、両方とも読み込まれます。ワークスペースの設定がグローバルより優先されるので、プロジェクトごとに上書きしたいルールがあればワークスペース側に書けばOKです。
最初のsteeringファイルを作る
まずはグローバルのsteeringファイルを作ってみましょう。
mkdir -p ~/.kiro/steering
~/.kiro/steering/global_steering.md を以下の内容で作成します。
---
inclusion: always
---
# 基本方針
- 必ず日本語で応対してください
- ユーザーは開発初心者です。専門用語には補足を入れて、丁寧に解説してください
- 提案をするときはWeb検索などで根拠を確認してから返答してください
- レスポンスやファイルの分量はできるだけ簡潔にまとめてください
- ファイル出力する際、絵文字（⭐🔴💡等）は使わず文字で表現してください
# 開発環境
- AWSリージョンは東京リージョン（ap-northeast-1）を使用
- コミットメッセージは1行の日本語でシンプルに
- 機密情報を含むファイルは必ず .gitignore に追加
先頭の --- で囲まれた部分はフロントマターです。 inclusion: always と書くと「毎回読み込む」という指定になります。他にも trigger （特定の条件で読み込む）などの指定がありますが、まずは always だけ覚えておけば十分です。
続いて、ワークスペースのsteeringも作ってみましょう。任意のプロジェクトフォルダの中に配置します。
mkdir -p {プロジェクトフォルダ}/.kiro/steering
グローバルと同様に、フロントマターに inclusion: always を付けます。
---
inclusion: always
---
# プロジェクト概要
- AWS環境の構築・運用プロジェクト
- IaCはCDKを使用
- 環境: 本番(prd) / 検証(stg) / 開発(dev) の3面構成
# 作業ルール
- リソース名は「プロジェクト名-環境名-リソース種別」で統一
- セキュリティグループは最小権限の原則に従う
- 変更作業前に必ず現状の設定を確認する
ワークスペースのsteeringを読み込ませるには、そのプロジェクトフォルダで kiro-cli を起動する必要があります。
cd {プロジェクトフォルダ}
kiro-cli
こうすると、グローバルとワークスペースの両方のsteeringが自動的に読み込まれます。
試してみよう
先ほど作ったグローバルsteeringには、日本語応対や初心者向け解説といったルールを書きました。これだけでもKiroの振る舞いは変わりますが、効果をよりわかりやすく体感するために、1行追加してみましょう。
global_steering.md の「基本方針」に以下を追加してください。
- 関西弁で応対してください
追加したら kiro-cli を起動して、「EC2とは何ですか」と聞いてみてください。いつもと違う口調で返ってくるはずです。効果が確認できたら、この行は削除して元に戻しましょう。
steeringに書いた内容がKiroの振る舞いにどう反映されるか、ぜひ自分の目で確認してみてください。この記事を参考に、自分の仕事に合ったsteeringファイルを作ってみましょう。
管理のコツ
steeringは毎回のチャットで全文が読み込まれます。長く書きすぎるとKiroの処理能力（コンテキストウィンドウ）を圧迫するので、簡潔に要点だけを書きましょう。
「AIが既に知っていることは書かない」のが基本です。たとえば「Pythonのvenvの使い方」や「git commitの方法」はAIが一般知識として持っているので、steeringに書く必要はありません。書くべきなのは「自分の環境固有の情報」だけです。環境のパス、チーム独自のルール、プロジェクト固有の制約など、AIが知りようのない情報に絞りましょう。
グローバルとワークスペースの使い分けも重要です。たとえば複数のプロジェクトの情報を全部グローバルに入れてしまうと、プロジェクトAの作業中にプロジェクトBの情報まで毎回読み込まれます。関係ない情報が増えるほどKiroの判断にノイズが入り、結果的に回答精度が落ちます。
また、プロジェクトごとにルールが異なるケースもあります。「コメントは日本語」のプロジェクトと「コメントは英語」のプロジェクトが混在する場合、グローバルに両方書くと矛盾してしまいます。ワークスペースに分けておけば、プロジェクトごとに違うルールを持てます。
| 置き場所 | 書くこと | 書かないこと |
|---|---|---|
| グローバル | 言語設定、コーディング規約など全プロジェクト共通のルール | プロジェクト固有の技術スタックや制約 |
| ワークスペース | プロジェクト概要、技術スタック、デプロイ先など | 他のプロジェクトでも使う共通ルール |
迷ったら「このルールは別のプロジェクトでも使うか？」で判断すればOKです。
まとめ
Kiro CLIは、自分の仕事のやり方を覚えさせて育てていくツールです。開発だけでなく、資料作成やタスク管理といった業務にも活用できます。
今回紹介したsteeringファイルは、Kiroを育てる第一歩です。グローバルに共通ルールを、ワークスペースにプロジェクト固有の情報を置くだけで、毎回のやり取りがスムーズになります。まずは数行のsteeringを書いて、Kiroの振る舞いが変わることを体験してみてください。
次回の中級編では、steeringの実践的な管理テクニックと、繰り返し作業を自動化する「スキル」について紹介予定です。