はじめに
最近知り合いのつてで Kiro Autonomous Agent のPreview版のアクセスが可能になりました。
Kiro Autonomous Agent は、開発タスクを自律的に実行する AWS のフロンティアエージェントです。GitHub Issue でタスクを指示すると、コードベースを分析し、計画を立て、実装して PR を作成するところまでを自動で行います。
本記事では、Kiro Autonomous Agent の概要と基本的な使い方を、スクリーンショット付きで解説します。
関連記事
以前の記事では、AWS の別のフロンティアエージェントである Security Agent と DevOps Agent を紹介しました。
- 【AWS】AWS Security Agent & DevOps Agent セットアップガイド【FrontierAgents】
- 【AWS】FrontierAgentsで実現するAIOps【FrontierAgent】
今回紹介する Kiro Autonomous Agent は、これらのエージェントと同じ「フロンティアエージェント」に分類されるサービスで、開発フェーズを担当します。今後の記事では、3つのフロンティアエージェントを組み合わせた連携を検証する予定です。
Kiro Autonomous Agent とは
フロンティアエージェント
AWS は「フロンティアエージェント」と呼ばれる、高度な自律性を持つ AI エージェントのカテゴリを提供しています。従来の AI アシスタントとは異なり、以下の3つの特徴があります。
- 自律的: ゴールを指示すれば、達成方法をエージェント自身が判断する
- スケーラブル: 複数のタスクを同時に実行し、サブエージェントに作業を分散できる
- 独立稼働: 数時間〜数日間、人の介入なしに動作できる
現在、AWS は3つのフロンティアエージェントを提供しています。
| エージェント | 担当フェーズ | 役割 |
|---|---|---|
| Kiro Autonomous Agent | 開発 | 開発タスクの自律実行（機能実装、バグ修正、テスト作成） |
| AWS Security Agent | 開発〜デプロイ | セキュリティレビュー・ペネトレーションテスト |
| AWS DevOps Agent | デプロイ〜運用 | インシデント対応・予防レコメンデーション |
本記事では、開発フェーズを担当する Kiro Autonomous Agent を紹介します。
Kiro Autonomous Agent の概要
Kiro Autonomous Agent は、開発タスクを独立して遂行するフロンティアエージェントです。機能実装からバグ修正まで、隔離されたサンドボックス環境で非同期に動作します。
現在プレビュー版として、Kiro Pro、Pro+、Power ユーザーに段階的にロールアウト中です。
主な特徴:
- タスクの自律実行: GitHub Issue や Kiro UI からタスクを割り当てると、リポジトリを分析し、計画を立て、実装して PR を作成する
- マルチリポジトリ対応: 単一タスクで複数リポジトリにまたがる変更が可能。それぞれに PR を作成する
- 永続的コンテキスト: セッションをまたいでコンテキストを維持し、コードレビューのフィードバックから継続的に学習する
-
GitHub 統合: GitHub Issue から
/kiroコマンドやkiroラベルでタスクを開始できる。PR へのフィードバックコマンド（/kiro all、/kiro fix）も用意されている - チャット機能: タスク作成前にアプローチを相談したり、タスク実行中にステアリング（方向修正）が可能。1チャットにつき1タスクの制約あり
- チームツール連携: GitHub、Jira、Slack などのチームツールに接続可能
-
Steering ファイル:
.kiro/steering/にチームの標準・規約・アーキテクチャパターンを定義し、エージェントの出力品質を向上させる
タスクの作成方法
Kiro Autonomous Agent にタスクを割り当てる方法は主に2つあります。
セットアップ（初回のみ）
タスクを作成する前に、GitHub アカウントの連携が必要です。
app.kiro.dev/agent にアクセスしてKiroアカウントでログイン
Settings から「Connect GitHub」を選択
Kiro Agent GitHub App を認可
アクセスを許可するリポジトリを選択
リポジトリが表示される条件は以下の両方を満たす場合です:
- Kiro Agent GitHub App がそのリポジトリにインストール・認可されている
- 自分の GitHub アカウントがそのリポジトリにアクセス権を持っている
注意: リポジトリ選択時は信頼できるリポジトリのみを選択してください。特にパブリックとプライベートのリポジトリを混在させる場合、エージェントはリポジトリ内のコードの指示に従うため、悪意あるコードが含まれていると影響を受ける可能性があります。
↓完了するとこのような表示になります
↓GitHubの画面でも「Installed GitHub Apps」にKiroが確認できます
方法1: Kiro UI からタスク作成
Kiro のウェブインターフェースからタスクを直接作成できます。
マルチリポジトリのタスクも可能です:
- 「バックエンドサービスに新しい API エンドポイントを追加し、フロントエンドクライアントも更新して」
方法2: GitHub Issue から作成
GitHub Issue を使ってタスクを割り当てることもできます。開発者にとっては普段のワークフローから離れずにエージェントを活用できるため、こちらの方が自然かもしれません。
/kiro コマンドで開始
GitHub Issue のコメントに /kiro と書くと、エージェントがタスクとして受け取ります。
kiro ラベルで開始
GitHub Issue に kiro ラベルを追加することでもタスクを開始できます。ラベルを追加すると、エージェントは Issue の全コメントをコンテキスト・フィードバックとして活用します。
↓issueを発行するとKiroが実装を開始
↓ KiroのWeb画面でもタスクが実行されていることを確認できます
注意:
/kiroコマンドを使用する場合、GitHub アカウントが Kiro に登録されている必要があります。未登録の場合はサインアップの案内が表示されます。また、対象リポジトリに Kiro Agent GitHub App がインストールされている必要があります。
チャット機能
タスクの作成前後で、エージェントとチャットで対話できます。
タスク作成前
- 実装アプローチの相談
- 要件や制約の確認
- 技術的な判断についてエージェントの意見を聞く
エージェントは Web 検索、過去のコードレビューからの学習、他のタスクのコンテキストを活用して回答します。
タスク実行中
タスクが作成された後もチャットを続けて、以下のことができます:
- 実装アプローチのステアリング（方向修正）
- 追加の要件や制約の提供
- 初期結果を確認した後の追加作業の依頼
追加のコメントやステアリングは、現在のタスクのスコープを更新します。1つのチャットで2つ目のタスクを作成することはできません。別のタスクに取り組む場合は、新しいチャットを開始してください。
タスク実行の流れ
エージェントにタスクが割り当てられると、以下の構造化されたプロセスで動作します。
① 環境セットアップ
サンドボックスの起動、MCP サーバーのロード
↓
② リポジトリ分析
リポジトリのクローンとコードベースの分析
↓
③ 計画 → 実行（一気に進行）
計画の立案、サブエージェントへの作業分散、
変更の検証を繰り返しながら実装
※不明点がある場合のみ一時停止して質問
↓
④ 完了
PR の作成、フィードバックや CI の結果を監視
注目すべき点として、③の計画から実行、④の PR 作成まで一気に進みます。途中で計画の承認を求められることはありません。エージェントが判断に迷った場合のみ「Needs attention」状態になり、質問を投げてきます。
実際にタスクを実行して、各ステップを追ってみます。
題材
今回は、前回の記事シリーズで使用した TODO アプリ（API Gateway + Lambda + DynamoDB + Cognito の CDK 構成）に対して、「優先度（priority）機能を追加する」というタスクをエージェントに依頼します。
既存の TODO アプリは以下の CRUD API を持っています:
| メソッド | パス | 説明 |
|---|---|---|
| POST | /todos | TODO を作成 |
| GET | /todos | 自分の TODO 一覧を取得 |
| GET | /todos/{id} | TODO の詳細を取得 |
| PUT | /todos/{id} | TODO を更新 |
| DELETE | /todos/{id} | TODO を削除 |
現在の TODO のデータモデルは id、userId、title、description、completed、createdAt、updatedAt のフィールドで構成されています。ここに priority（high / medium / low）フィールドを追加し、一覧取得時に優先度でフィルタリングできるようにするタスクを依頼します。
このタスクを選んだ理由:
- 既存のコードパターン（Lambda ハンドラーの構造、DynamoDB アクセスパターン）を理解して一貫性のある実装ができるかを評価できる
- 複数ファイルにまたがる変更（createTodo、getTodos、updateTodo + CDK スタック定義）が必要なので、エージェントの計画能力を見られる
- 複雑すぎず、記事の題材としてちょうどいいスコープ
エージェントに依頼するタスクの内容
GitHub Issue または Kiro UI で以下のように依頼します:
TODO アプリに優先度（priority）機能を追加してください。
要件:
- TODO に priority フィールド（high / medium / low）を追加する
- TODO 作成時に priority を指定できるようにする（デフォルトは medium）
- TODO 更新時に priority を変更できるようにする
- GET /todos で priority パラメータによるフィルタリングを追加する
- 既存のコードパターン（Lambda ハンドラーの構造、エラーハンドリング）に合わせて実装する
Step 1: 環境セットアップ
タスクを受け取ると、エージェントはまず隔離されたサンドボックス環境を起動します。リポジトリのクローン、依存関係のインストール、MCP サーバーのロードなどが自動的に行われます。
Step 2: リポジトリ分析
エージェントがコードベースを分析し、プロジェクトの構造、使用している技術スタック、既存のパターンを理解します。
Step 3: 計画 → 実行 → PR 作成
分析結果に基づいて、エージェントが内部的に計画を立て、そのまま実装に進みます。
↓実装が終わると変更点をまとめて説明してくれる
↓PR作成まで行われ、GitHubのURLが渡される
↓「Give feedback」はプレビュー版サービスに関するフィードバックでした
↓GitHubの画面
エージェントは内部的に計画を立てた上で実装を進めます。計画の段階で一時停止して承認を待つわけではなく、計画 → 実行 → PR 作成まで一気に進みます。不明点がある場合のみ「Needs attention」状態になり、質問を投げてきます。
つまり、開発者が介入するタイミングは主に PR が作成された後です。PR の内容を確認し、修正が必要であれば /kiro all や /kiro fix コマンドでフィードバックを送ることで、エージェントが修正をコミットします。
タスクの内容を明確に書くほど、エージェントが意図通りに実装してくれる可能性が高まります。事前にチャットでアプローチを相談してからタスクを作成するのも有効です。
実装が完了すると、エージェントが GitHub に PR を作成します。PR には変更内容の説明、実装アプローチ、検討したトレードオフなどが含まれます。コミットにはタスク作成者とエージェントの両方が共著者として記録されます。
PR へのフィードバック
PR に対してフィードバックを送る方法は複数あります。
app.kiro.dev/agent からのフィードバック
タスクビューからもフィードバックを提供できます。
GitHub Actions のフィードバック（自動チェック、テスト、セキュリティスキャン）は、ユーザーがフィードバックを提供した際に自動的に対応されます。
フィードバックを提供すると、タスクは Queued → In progress に遷移し、エージェントが修正作業を開始します。
↓GitHubの画面での確認
GitHub 上でのフィードバックコマンド
-
/kiro all: 全レビュアーの全コメントに一括対応 -
/kiro fix: 特定の会話スレッドのコメントに対応
対応させたくないコメントがある場合は、コマンドを使う前にそのコメントを削除するか、自分の見解を返信してください。
↓ /kiro fix があるコメントにはすぐに「既読」スタンプが付いた
↓ KiroのWeb画面で改修が開始されたことを確認
↓改修が終わると作成したプルリクエストを案内してくれる
↓GitHub上でもKiroの作業を確認できる
タスクのライフサイクル
タスクは以下の状態を遷移します。
| 状態 | 説明 |
|---|---|
| Queued | 同時実行上限（10タスク）に達した場合、待機状態 |
| In progress | エージェントがアクティブに作業中 |
| Needs attention | ユーザーの入力や確認が必要 |
| Completed | 作業完了、PR 作成済み。フィードバックで再作業も可能 |
| Cancelled | キャンセル済み。再開不可 |
「Needs attention」状態は、エージェントが判断に迷った場合や、追加の情報が必要な場合に遷移します。質問に回答すると、エージェントが作業を再開します。
「Completed」状態でも、PR に対してフィードバックを送ることで再作業を依頼できます。
永続コンテキストと学習
Kiro Autonomous Agent の特徴的な機能の1つが、永続的コンテキストと継続学習です。
永続的コンテキスト
エージェントはセッションをまたいでコンテキストを維持します。1回目のタスクで得たコードベースの理解は、2回目以降のタスクでも活用されます。
コードレビューからの学習
PR に対してコードレビューのフィードバックを送ると、エージェントはそのフィードバックから学習します。「うちのチームではこういう書き方をする」「このパターンは避けてほしい」といったフィードバックが、次回以降のタスクに反映されます。
重要なポイントとして、学習に影響するのはタスク作成者（自分）のフィードバックのみです。他のレビュアーのコメントはエージェントの学習には影響しません。
Steering ファイルの活用
コードレビューのフィードバックに加えて、.kiro/steering/ ディレクトリに Steering ファイルを配置することで、チームの標準・規約・アーキテクチャパターンをエージェントに事前に伝えることもできます。
.kiro/
└── steering/
├── coding-standards.md # コーディング規約
├── architecture.md # アーキテクチャパターン
└── testing.md # テスト方針
Steering ファイルを定義しておくと、エージェントが最初のタスクからチームの規約に沿ったコードを生成しやすくなります。公式ドキュメントでは、以下の用途が特に有効とされています:
- コーディング規約
- アーキテクチャパターン
- 技術スタックの選好
- テストアプローチ
さいごに
Kiro Autonomous Agent は、GitHub Issue でタスクを指示するだけで、リポジトリ分析 → 計画 → 実装 → PR 作成までを自律的に実行するフロンティアエージェントです。
今回は既存の TODO アプリに対する機能改修をKiro Autonomous Agent に依頼しました。
今までのKiroは仕様作成から確認と承認後、実装が始まりましたが、今回の検証では人が要求を伝えた後に一気にPR作成まで行われました。
Kiroがより自律的に動いてくれるので人の手離れが良い一方で、より正確に最初の要求と仕様を伝える必要がありそうです。
まだプレビュー版なのでGA後にどのようになるかはまだわかりませんが、KiroをはじめとするFrontierAgentと人が協調して良いものを作っていく未来が今から楽しみです。
英語版記事はこちら
[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]
参考
Kiro autonomous agent
Setup
Using the agent
Creating tasks
Chatting with the agent
GitHub Integration
Agent Sandbox
Amazon launches frontier AI agents