Kiroの使い方｜インストールから最初のプロジェクトまでの手順を公式ドキュメントで整理する

Kiroの使い方の全体像｜5段階で覚えると迷いません

まず、いちばん知りたいところからお答えします。

公式ドキュメントの「Your first project（Kiro 公式ドキュメント）」は、この4つを順に扱っています。

• プロジェクトを開く（Open your project）
• steeringファイルを用意する（Set up steering files）
• specで機能を作る（Build features with specs）
• hooksで作業を自動化する（Automate workflows with hooks）
• MCPで機能を広げる（Extend capabilities with MCP）

その前段にインストールとサインインがあるので、ここでは全体を「5段階」として扱います。

この順番のいいところは、あとの段ほど「自分の手を減らす」方向に効いてくることです。

steeringを書けばチャットでの説明が減り、specを作れば指示の往復が減り、hooksを書けば定型作業が消えます。

AIエージェントという道具そのものが初めての方は、AIエージェントとは何かの記事もあわせてどうぞ。

Kiroの使い方①｜動作環境を確認して、使うサーフェスを決める

Kiroは1つのアプリではなく、5つの入口があります。

公式の「Installation（Kiro 公式ドキュメント）」には、デスクトップIDE・CLI・Webアプリ・モバイルアプリ・Kiro Crewの5つが並んでいました。

公式は「複数を併用してよく、.kiro の設定はすべての入口で共有される」と書いています。

つまり、最初にどれか1つを選んでも、あとから増やして困ることはありません。

動作環境は次のとおり記載されていました。

入口	公式に記載された動作環境
IDE	macOS（Intel + Apple Silicon）、Windows 10/11（x64またはARM64）、Linux（Ubuntu 24+、Debian 13+、Fedora 40+、Arch、Mint 22+）
CLI	macOS、Windows 11（PowerShell）、Linux（glibc 2.34+ またはmusl版）
Web	最近のブラウザであれば可。ローカルへのインストールは不要
Mobile	iOS。早期アクセス中はApple TestFlight経由で配布
Crew	macOS、Linux（x86_64およびARM）、Windows。ソースからのインストールはPython 3.9+が必要

ふだんエディタで書く人はIDE、ターミナル中心の人はCLI、手元に何も入れたくない人はWeb、という分け方が素直です。

Web版については、公式FAQに「Kiro Pro、Pro+、Pro Max、Powerのユーザーが利用できる」と書かれている点に注意してください。

Kiroのインストール手順｜IDE版はダウンロードから5ステップ

IDE版のインストールは、公式ドキュメントに5つのステップで書かれていました。

更新については、Kiro IDEはバックグラウンドで自動的にアップデートを取得し、準備ができると再起動を促す通知が出ると書かれていました。

手動で確認したいときは、Kiroメニューから「Check for Updates…」を選びます。

WindowsとLinuxでは、コマンドパレット（Ctrl + Shift + P）を開いて「Kiro: Check for Updates」を実行する、という案内でした。

古いバージョンに戻したいときの手順も公式に載っています。

ダウンロードページのバージョン一覧から目的の版を展開してインストーラを取得し、現在のKiroをアンインストールしてから入れ直す流れです。

公式は「設定・拡張機能・サインイン状態は再インストールをまたいで保持される」と明記していました。

KiroのCLIを入れる｜1行のインストールと最初のセッション

ターミナル派なら、Kiro CLIのほうが立ち上がりは早いです。

公式トップページには、インストール用のコマンドがそのまま掲載されていました。

curl -fsSL https://cli.kiro.dev/install | bashという1行です。

インストールとブラウザでの認証が終わったら、プロジェクトのディレクトリへ移動して kiro-cli と打つと、ターミナルUIが開きます。

公式の「Setup & First Run」には、このターミナルUIがシンタックスハイライト、対話パネル、ツールの進捗表示を持つチャット画面だと説明がありました。

ここで覚えておくと効くのが、CLIに内蔵された案内役です。

セッションを開いて「/guide」と打つと、Kiro CLIそのものについて答えるGuideエージェントに切り替わります。

公式は、このGuideエージェントが自分のインストール済みバージョンに対応したドキュメントを参照していて、エージェント・プロンプト・steeringファイルなどの設定ファイルを会話の中から作ってくれる、と書いています。

元のエージェントに戻るときは Shift+Tab を押す、という案内でした。

KiroのCLIで押さえておきたい操作｜@・!・Shift+Tab

Kiro CLIの基本操作は、公式ドキュメントに記号つきで整理されていました。

操作	公式の説明
@（アットマーク）	ファイルを指定して参照させる。タブ補完が効く（例：Review @src/api/routes.ts for security issues）
!（エクスクラメーション）	エージェントを通さずにシェルコマンドを直接実行する（例：! npm run build）
Shift+Tab	Planモードに切り替える。変更を加える前に、何をするつもりかをKiroが先に示す
Shift+Enter	複数行のプロンプトを入力する
Esc	エージェントを中断する、またはパネルを閉じる
Ctrl+G	crewモニターを開き、並列で動くサブエージェントの様子を見る

スラッシュコマンドも、よく使うものが表にまとまっています。

/help は全コマンドの検索パネル、/context は文脈に入っているファイルとトークン使用量、/model はモデルの切り替え、/agent はエージェントの切り替え、/chat new は新しい会話の開始です。

権限まわりの操作も押さえておくと、作業が止まりにくくなります。

公式には、コマンドを1回だけ承認する方法と、パターンごと信頼する方法（たとえば npm run 系すべて）があると書かれていました。

ツール単位なら /tools trust <name> で事前承認し、/tools untrust <name> で毎回確認に戻し、/tools reset で実行時の権限をすべてクリアできます。

うまく動かないときは kiro-cli doctor を実行する、という案内も公式に載っていました。

Kiroへのサインイン｜5つの認証方法と、リモート環境での入り方

サインインの方法は、公式の「Authentication」ページに表で整理されています。

プロバイダ	IDE	CLI	Web	Mobile
GitHub	✓	✓	✓	✓
Google	✓	✓	✓	✓
AWS Builder ID	✓	✓	✓	✓
AWS IAM Identity Center	✓	✓	✓	✓
外部IDプロバイダ	✓	✓	✓	✓
APIキー（CI／ヘッドレス）	—	✓	—	—

サインインはどの方法でもブラウザで完了する形で、GitHubの場合は認可するアプリが「kirodotdev」として表示される、と書かれていました。

SSH越しやコンテナの中など、ブラウザを開けない環境向けにはdevice flow（デバイスフロー）が用意されています。

公式の手順は、kiro-cli login を実行してサインイン方法を選ぶと、CLIがURLとワンタイムコードを表示する、というものでした。

そのURLを手元のパソコンやスマートフォンのブラウザで開いてコードを入れると、CLIがログイン成功を自動で検知します。

ポートフォワードは不要だと明記されていました。

CI/CDパイプラインや自動化スクリプトからは、APIキーを使う方法もあります。

KIRO_API_KEY という環境変数にキーを入れ、kiro-cli chat –no-interactive を叩く形です。

ただしAPIキー認証はKiro Pro、Pro+、Pro Max、Powerの加入者のみが使えると注記されていました。

いま何で認証しているか分からなくなったら、kiro-cli whoami で確認できます。

Kiroでプロジェクトを開く｜最初にさわる3か所

IDE版でプロジェクトを開く方法は3つ書かれていました。

• File > Open Folder からプロジェクトのディレクトリを選ぶ
• プロジェクトのフォルダをKiroにドラッグ＆ドロップする
• プロジェクトのディレクトリで kiro . を実行する

開いたら、左のアクティビティバーにある「Kiro Ghost」アイコンをクリックしてKiroパネルを出します。

このパネルが、Kiroの機能すべてへの入口になります。

チャットペインは既定で開いている、と公式に書かれていました。

最初のうちは、このチャットで「このプロジェクトのアーキテクチャを説明して」のように聞くところから始めるのが分かりやすいです。

公式ドキュメントも、CLIの最初のセッションの例として「Explain the architecture of this project」「Write a unit test for the auth module」といった文を挙げていました。

Kiroのsteeringファイルを作る｜3つの基盤ファイルから

Kiroの使い方で、いちばん効き目が大きいのがsteeringです。

公式ドキュメントの「Steering（Kiro 公式ドキュメント）」には、マークダウンファイルでプロジェクトの永続的な知識をKiroに与える仕組みだと書かれていました。

IDEでの作り方は、Kiroパネルのステアリングの項目から「Generate Steering Docs」を選ぶだけです。

Kiroがリポジトリを解析して、3つの基盤ファイルを .kiro/steering/ に作ります。

ファイル	公式の説明
product.md	プロダクトの目的、対象ユーザー、主要な機能、ビジネス上の目標
tech.md	採用しているフレームワーク、ライブラリ、開発ツール、技術的な制約
structure.md	ファイル構成、命名規則、インポートのパターン、アーキテクチャ上の決定

この3つは、既定ですべてのやり取りに読み込まれると書かれていました。

CLIから始めるなら、手で作っても構いません。

公式のCLIガイドには、mkdir -p .kiro/steering でディレクトリを作り、.kiro/steering/project.md に規約を書く例が載っていました。

例として挙げられていたのは「Next.js 15を使うTypeScriptプロジェクト」「パッケージ管理はpnpm」「既存のコードスタイル（Prettier + ESLint）に従う」「テストはVitestで書く」といった箇条書きです。

難しく考えず、チームの申し送りをそのまま書けばよい、という形になっています。

Kiroのsteeringを使い分ける｜4つのinclusionモード

steeringファイルは、いつ読み込むかを指定できます。

ファイルの先頭にYAML形式のフロントマターを置く形で、公式は4つのモードを挙げていました。

フロントマターはファイルの先頭でなければならず、前に空行や本文を置けない、という注記もありました。

ただしKiro CLIではinclusionモードは現時点で未対応で、.kiro/steering/ 配下のsteeringファイルはすべて自動的に読み込まれる、と公式に書かれています。

ここはIDEとCLIで挙動が違う数少ない部分なので、覚えておくと混乱しません。

また、KiroはAGENTS.mdという標準にも対応しています。

AGENTS.mdはinclusionモードを持たず常に読み込まれ、ワークスペースのサブディレクトリに置いたものも拾われると書かれていました。

公式が挙げていた注意として、steeringファイルはコードベースの一部になるので、APIキーやパスワードを書かないこと、というものがあります。

Kiroでspecを作る｜要件・設計・タスクの3フェーズ

ここからがKiroの本体と言える部分です。

公式の手順は、Kiroペインのspecの項目にある「+」を押すか、チャットペインから「Spec」を選ぶところから始まります。

するとKiroが「機能を作るのか、バグを直すのか」を聞いてきます。

機能を選んだ場合は、機能の説明を書いたうえで、Requirements-FirstとDesign-Firstのどちらで進めるかを選びます。

バグを選んだ場合は、バグの内容を説明します。

機能の説明の例として公式が挙げていたのは「Add a user authentication system with login, logout, and password reset functionality（ログイン・ログアウト・パスワードリセットを備えたユーザー認証の仕組みを追加する）」でした。

そこからの流れは3フェーズです。

フェーズ	作られるもの	公式の説明
Requirements	requirements.md	受け入れ基準つきのユーザーストーリー。KiroがEARS記法で構造化する
Design	design.md	技術アーキテクチャとコンポーネント設計、シーケンス図とデータフロー、エラー処理とテスト戦略
Tasks	tasks.md	個別に追跡できる実装タスク。リアルタイムで状態が更新される

内容がはっきりしている機能なら、承認ゲートを挟まずに3つを一度に作るQuick Specも選べます。

設計に進む前に要件の矛盾や抜けを見つけたいときは、Analyze Requirementsという機能が用意されていました。

Kiroでspecのタスクを実行する｜1つずつと、まとめて

specができたら、次はタスクの実行です。

公式の手順は3つでした。

• tasks.md に生成されたタスクを確認する
• 個々のタスク項目をクリックして実行する
• タスクが自動で「In Progress」「Done」に変わるので進捗を追う

まとめて実行することもできます。

specのタスクを「すべて実行」すると、Kiroは依存関係を解析して、独立したタスクを同時に走らせます。

そのまとまりを公式は「wave（波）」と呼んでいて、Wave 1は依存の無いタスク、Wave 2はWave 1で依存が満たされたタスク、という順に進みます。

波は順番に実行され、波の中のタスクは同時に実行される、という整理でした。

公式は「ほとんどの機能specでは、この仕組みが設定なしで実行時間をかなり短くする」と書いています。

Kiroのhooksで自動化する｜トリガーとJSONの書き方

同じ作業を何度もやっているなら、hooksの出番です。

公式ドキュメントの「Hooks（Kiro 公式ドキュメント）」には、セッション中に特定のイベントが起きたときにシェルコマンドやプロンプトを自動実行する仕組みだと書かれていました。

IDEでの作り方は、Kiroパネルの「Agent Hooks」から「+」を押して、自動化したい内容を自然言語で書くところから始まります。

公式が挙げていた例は「エージェントがReactコンポーネントのファイルを保存したら、対応するテストファイルを自動で作成または更新する」でした。

設定の実体は .kiro/hooks/ 配下のJSONファイルで、トリガー・matcher（正規表現）・action の3つを書きます。

公式が挙げていたトリガーを整理します。

トリガー	いつ動くか	処理を止められるか
Prompt Submit	エージェントにメッセージを送ったとき	できる
Agent Stop	エージェントが応答を終えたとき	できない
Pre Tool Use	ツールが実行される直前	できる
Post Tool Use	ツールが実行された後	できない
File Create / File Save / File Delete	エージェントがファイルを作成・保存・削除した後	できない
Pre Task Execution	specのタスクが始まる前	できる
Post Task Execution	specのタスクが完了した後	できない

大事な注記として、ファイル系のトリガーはエージェントが行った変更にだけ反応し、自分でエディタ上で保存・作成・削除しても発火しません。

actionは2種類で、シェルコマンドを実行する「command」と、会話にプロンプトを差し込む「agent」です。

コマンドのタイムアウトは既定で60秒、0を指定すると無効になる、と書かれていました。

消したくないけれど一時的に止めたいときは、enabled を false にすれば飛ばせます。

KiroにMCPサーバーをつなぐ｜設定と確認の手順

外部のツールやAPIをKiroから使いたいときは、MCP（Model Context Protocol）を設定します。

IDEでの手順は3ステップで書かれていました。

• 1. 設定を開く：コマンドパレット（MacはCmd + Shift + P、Windows／LinuxはCtrl + Shift + P）で「Kiro: Open workspace MCP config (JSON)」または「Kiro: Open user MCP config (JSON)」を探す
• 2. サーバー設定を書く：mcpServers の下に、command と args、必要なら env を書く
• 3. 保存して確認：保存するとサーバーは自動で再接続する。Kiroパネルの「MCP servers」タブで接続を確認する

Kiroには既定でfetch MCPサーバーが同梱されていて、disabled を false にすれば接続できる、と公式ガイドに書かれていました。

ローカル（stdio）のMCPサーバーとリモート（HTTP/SSE）のMCPサーバーのどちらにも対応していて、IDE・CLI・Webで使えます。

チャットからの使い方は、普通に質問する方法と、#MCPというコンテキストプロバイダで特定のツールを名指しする方法の2つが挙げられていました。

公式は「信頼できる提供元のMCPサーバーだけをインストールすること」と警告しています。

うまくつながらないときは、Kiroパネルの「Output」タブで「Kiro – MCP Logs」を選ぶとログが読めます。

Kiroのモデルを切り替える｜Autoから始めるのが基本

Kiroは使うAIモデルを選べます。

切り替えは、チャット画面のモデル用ドロップダウンからで、選んだモデルはその会話の以降のメッセージすべてに適用されると書かれていました。

CLIなら /model です。

公式のベストプラクティスは、はっきりしています。

「ほとんどの作業はAutoから始める。Autoが品質とコストの両方を自動で最適化する」という書き方です。

そのうえで、難しい問題で行き詰まったときや、複数ファイルにまたがる作業を続けたいときにOpus 5へ切り替える、と案内されていました。

速さやクレジットの節約を優先したいときはHaiku、という整理です。

推論の深さ（reasoning effort）も調整できます。

IDEならモデル選択画面の「Effort」パネル、CLIなら /effort か起動時の –effort フラグで設定します。

公式は、effortを上げると内部で使うトークンが増えるので、同じ倍率のモデルでも消費クレジットが増えると注記していました。

ほかのAIコーディングツールとの比較を見たい方は、Windsurfの使い方の記事もあわせてどうぞ。

Kiroの使い方でつまずきやすいところ

公式ドキュメントを読んでいて、先に知っておくと詰まらずに済む点をまとめます。

ひとつ目は、カスタムエージェントを使うときのsteeringの扱いです。

公式には「カスタムエージェントを使うとき、steeringファイルは自動では読み込まれない」と書かれていました。

読ませたい場合は、エージェントの設定の resources に file://.kiro/steering/**/*.md を明示的に足す必要があります。

ふたつ目は、ブラウザでのサインインとプロキシの関係です。

公式は、サインイン時に開くブラウザの通信はOSのネットワークスタックを使うため、IDE側のプロキシ設定は通らないと注記していました。

3つ目は、MCPツールの名前です。

ツール名が64文字を超える、使える文字の条件を満たさない、説明が空、のいずれかに当たると、そのツールは検証エラーで除外されます。

この場合は、MCPサーバーの提供者に修正を依頼することになる、と書かれていました。

Kiroの使い方に関するよくある質問

まとめ｜Kiroの使い方は「steeringを置いてからspecを作る」

最後に、この記事で確認できたことを並べておきます。

• 手順はインストール → サインイン → プロジェクトを開く → steering → specの5段
• CLIのインストールはcurl -fsSL https://cli.kiro.dev/install | bashの1行
• サインインはGitHub・Google・AWS Builder ID・IAM Identity Center・外部IdPから選ぶ
• ブラウザが開けない環境はデバイスフロー、CI/CDはKIRO_API_KEY
• steeringの基盤はproduct.md・tech.md・structure.mdの3ファイル
• 読み込み方はalways・fileMatch・manual・autoの4モード（CLIは全件自動読み込み）
• specはrequirements.md → design.md → tasks.mdの3フェーズ
• タスクはwave単位で並列実行され、hooksは.kiro/hooks/ のJSONで定義する

最初の一歩としては、steeringファイルを1枚だけ書いてから、小さな機能でspecを1本作ってみるのが分かりやすいです。

手順の全体像は公式の「Kiro 公式ドキュメント」、specの詳細は「Specs」にまとまっています。

この記事の内容は2026年9月16日にKiroの公式サイトと公式ドキュメントで確認したものです。仕様や画面の名前は変わりますので、最新の情報は公式ページでご確認ください。