【AWS】KAAをPJメンバーの1人のように活躍してもらう工夫【Kiro】

Last updated at 2026-04-05Posted at 2026-04-05

はじめに

前回の記事では Kiro Autonomous Agent (KAA) の基本機能を紹介しました。GitHub Issue でタスクを指示すると、リポジトリを分析し、実装して PR を作成するところまでを自動で行うフロンティアエージェントです。

本記事では、Kiro Autonomous Agent を「チームの一員」として開発ワークフローに組み込む方法を検証します。具体的には、Backlog の課題を自動で取得して実装させたり、完了報告を Slack に通知したりする一連のフローを、GitHub Actions と AWS API を活用して構築します。
今回は前回の記事でキャッチアップしたkiro autonomous agent の基本機能を使ってチームの一員として活躍してもらうにはどんな工夫ができるかをいろいろ検証しました。

前回の記事

【AWS】Kiro Autonomous Agent (Preview) の基本機能をキャッチアップ【FrontierAgents】

チームメンバーとしての Kiro

人間の開発者がチームで行っていることを、Kiro の機能でどこまで再現できるかを整理します。

チームメンバーの行動	Kiro での実現方法
課題管理ツールで課題を確認する	GitHub Actions で Backlog 課題を自動取得 → GitHub Issue 化
チームの規約に沿ってコードを書く	Steering ファイル + 永続コンテキスト
コードレビューのフィードバックに対応する	`/kiro all`、`/kiro fix`
完了報告をする	GitHub Actions で Slack Webhook 通知
フィードバックから学ぶ	コードレビューからの学習

本記事では、この中から「課題の取得 → 実装 → 完了報告」のフローを GitHub Actions で構築し、「規約の遵守」を Steering ファイルで実現します。

Kiro autonomation agent を含めたFrontierAgent活用のイメージ

準備

Step 1: Steering ファイルの作成

最初に、対象リポジトリのデフォルトブランチに Steering ファイルを作成します。Kiro Autonomous Agent はタスク開始時に .kiro/steering/ フォルダの Markdown ファイルを自動的に読み込みます。

ブランチ命名規約

.kiro/steering/branch-naming.md:

# ブランチ命名規約

ブランチ名は以下の形式で作成してください:

- 形式: `feature-{課題番号}-{課題の簡潔な説明}`
- 例: `feature-PROJ-123-add-search-function`
- 課題番号が GitHub Issue のタイトルや本文に含まれている場合はそれを使用してください
- 課題番号が不明な場合は、ブランチを作成する前にユーザーに課題番号を確認してください。課題番号なしでブランチを作成しないでください

コーディング規約

.kiro/steering/coding-standards.md:

# コーディング規約

## エラーハンドリング
- catch ブロックでは汎用的なエラーメッセージ（"Internal server error"）のみをレスポンスに返す
- 詳細なエラー情報は console.error で CloudWatch Logs にのみ記録する
- スタックトレースやエラーメッセージをレスポンスボディに含めない

## 入力バリデーション
- API エンドポイントの入力値は必ずバリデーションする
- 許可された値の列挙型（enum）を使用する

## 命名規則
- Lambda ハンドラーのファイル名はキャメルケース（例: createTodo.ts）
- 変数名・関数名はキャメルケース
- 定数は大文字スネークケース（例: TABLE_NAME）

アーキテクチャパターン

.kiro/steering/architecture.md:

# アーキテクチャパターン

## Lambda ハンドラーの構造
- 各エンドポイントに対応する個別の Lambda ハンドラーファイルを作成する
- ハンドラーは APIGatewayProxyEvent を受け取り、APIGatewayProxyResult を返す
- DynamoDB アクセスには @aws-sdk/lib-dynamodb の DynamoDBDocumentClient を使用する
- テーブル名は環境変数 TABLE_NAME から取得する

## CDK スタック
- インフラ定義は lib/todo-api-stack.ts に記述する
- Lambda 関数は NodejsFunction を使用する

これらのファイルをデフォルトブランチにコミット・プッシュします。

↓このようにプロジェクト直下に .kiro/steering フォルダを作成します

Step 2: Backlog に「Kiro」仮想ユーザーを作成

Backlog に Kiro 用の仮想ユーザーを作成します。チームメンバーが課題の担当者を「Kiro」に変更するだけで、自動的に Kiro Autonomous Agent にタスクが割り当てられる仕組みを作ります。

Step 3: GitHub Actions ワークフローの作成

Backlog 課題の自動取得 → GitHub Issue 作成

.github/workflows/sync-backlog.yml:

name: Sync Backlog to GitHub Issues
on:
  workflow_dispatch:  # まずは手動実行で動作確認
  # 動作確認後、以下のコメントを外して定期実行を有効化
  # schedule:
  #   - cron: '0 0 * * 1-5'   # 平日 朝9時（JST）= UTC 0:00
  #   - cron: '0 9 * * 1-5'   # 平日 夕方18時（JST）= UTC 9:00（課題が10件超の場合）

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Fetch Backlog issues assigned to Kiro
        env:
          BACKLOG_SPACE_ID: ${{ secrets.BACKLOG_SPACE_ID }}
          BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }}
          BACKLOG_PROJECT_ID: ${{ secrets.BACKLOG_PROJECT_ID }}
          BACKLOG_KIRO_USER_ID: ${{ secrets.BACKLOG_KIRO_USER_ID }}
          GH_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}  # GITHUB_TOKEN ではなく PAT を使用（理由は Step 4 参照）
          MAX_ISSUES: 10  # Kiro の同時実行上限に合わせる
        run: |
          TODAY=$(TZ=Asia/Tokyo date +%Y-%m-%d)

          # 担当者=Kiro、ステータス=未対応(1)、開始日=今日、優先度順で取得
          # 注意: Backlog の URL は .backlog.com と .backlog.jp の2種類があります
          # 注意: GitHub Actions のランナーは UTC で動作するため、日本時間に合わせて TZ=Asia/Tokyo を指定しています
          # ご自身の環境に合わせて変更してください
          ISSUES=$(curl -s "https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues?apiKey=${BACKLOG_API_KEY}&projectId[]=${BACKLOG_PROJECT_ID}&assigneeId[]=${BACKLOG_KIRO_USER_ID}&statusId[]=1&startDateSince=${TODAY}&startDateUntil=${TODAY}&sort=priority&order=asc&count=${MAX_ISSUES}")

          echo "$ISSUES" | jq -c '.[]' | while read -r ISSUE; do
            ISSUE_KEY=$(echo "$ISSUE" | jq -r '.issueKey')
            ISSUE_ID=$(echo "$ISSUE" | jq -r '.id')
            SUMMARY=$(echo "$ISSUE" | jq -r '.summary')
            DESCRIPTION=$(echo "$ISSUE" | jq -r '.description // ""')
            PRIORITY=$(echo "$ISSUE" | jq -r '.priority.name // "中"')

            # 既に同じ Issue が存在するかチェック
            EXISTING=$(gh issue list --search "$ISSUE_KEY" --json number --jq 'length')
            if [ "$EXISTING" -gt 0 ]; then
              echo "Skip: $ISSUE_KEY already exists"
              continue
            fi

            # GitHub Issue を作成
            gh issue create \
              --title "[$ISSUE_KEY] $SUMMARY" \
              --body "## Backlog 課題: $ISSUE_KEY

**優先度**: $PRIORITY

$DESCRIPTION

*Backlog から自動連携（開始日: ${TODAY}）*" \
              --label "kiro"

            # Backlog の課題ステータスを「処理中(2)」に更新
            curl -s -X PATCH \
              "https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues/${ISSUE_KEY}?apiKey=${BACKLOG_API_KEY}" \
              -H "Content-Type: application/x-www-form-urlencoded" \
              -d "statusId=2"

            echo "Created & updated: $ISSUE_KEY"
          done

ポイント:

statusId[]=1（未対応）でフィルタするため、既に処理中の課題は取得されない
GitHub Issue 作成後に Backlog の課題ステータスを「処理中(2)」に自動更新するため、次回の実行で同じ課題が重複取得されない
MAX_ISSUES: 10 は Kiro の同時実行上限に合わせた値。課題が10件を超える場合は、朝9時と夕方18時の2回実行で対応可能

PR 作成時の Slack 通知

Kiro Autonomous Agent が PR を作成すると、GitHub Actions が Slack に自動通知します。同時に、PR タイトルから Backlog の課題キー（例: FS-2）を抽出し、Backlog の課題ステータスを「処理済み」に更新します。課題にはコメント「PRを作成しました。レビューをお願いします。{PR URL}」が自動追加されます。

.github/workflows/notify-slack.yml:

name: Notify Slack on Kiro PR
on:
  pull_request:
    types: [opened]

jobs:
  notify:
    if: contains(github.event.pull_request.body, '@kiro-agent')
    runs-on: ubuntu-latest
    steps:
      - name: Send Slack notification and update Backlog
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          BACKLOG_SPACE_ID: ${{ secrets.BACKLOG_SPACE_ID }}
          BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }}
        run: |
          PR_TITLE="${{ github.event.pull_request.title }}"
          PR_URL="${{ github.event.pull_request.html_url }}"

          # Slack に通知
          curl -X POST "$SLACK_WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -d "{\"text\": \"🤖 Kiro が PR を作成しました\n*${PR_TITLE}*\n${PR_URL}\"}"

          # PR タイトルから Backlog 課題キーを抽出（例: [FS-2] or (FS-2) → FS-2）
          ISSUE_KEY=$(echo "$PR_TITLE" | grep -oP '[(\[]([A-Z]+-\d+)[)\]]' | tr -d '[]()' | head -1)

          if [ -n "$ISSUE_KEY" ]; then
            # Backlog の課題ステータスを「処理済み(3)」に更新し、コメントを追加
            curl -s -X PATCH \
              "https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues/${ISSUE_KEY}?apiKey=${BACKLOG_API_KEY}" \
              -H "Content-Type: application/x-www-form-urlencoded" \
              -d "statusId=3&comment=PRを作成しました。レビューをお願いします。%0A${PR_URL}"
          fi

ポイント:

Kiro が作成する PR の本文には This pull request was generated by @kiro-agent が含まれるため、これを if 条件で判定して Kiro の PR だけを通知対象にフィルタ
PR タイトルから課題キーを抽出し、Backlog のステータスを「処理済み」に自動更新
Backlog の課題にコメントとして PR の URL を追加

Step 4: GitHub Secrets の登録

以下のシークレットを GitHub リポジトリの Settings → Secrets and variables → Actions に登録します。

シークレット名	内容	取得方法
BACKLOG_SPACE_ID	Backlog のスペース ID	Backlog の URL `https://xxxxx.backlog.jp` の `xxxxx` 部分
BACKLOG_API_KEY	Backlog の API キー	Backlog → 個人設定 → API → 「新しいAPIキーを発行」
BACKLOG_PROJECT_ID	対象プロジェクトの数値 ID	Backlog API `https://{spaceId}.backlog.jp/api/v2/projects?apiKey={apiKey}` で確認
BACKLOG_KIRO_USER_ID	Kiro ユーザーの数値 ID	Backlog API `https://{spaceId}.backlog.jp/api/v2/users?apiKey={apiKey}` で確認
SLACK_WEBHOOK_URL	Slack の Incoming Webhook URL	Slack → アプリ管理 → Incoming Webhooks → 「Add New Webhook to Workspace」
PERSONAL_ACCESS_TOKEN	GitHub の Personal Access Token	GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens で生成。`Issues: Read and write` 権限が必要

★今回はRepository secretsに設定しています

BACKLOG_PROJECT_ID と BACKLOG_KIRO_USER_ID は数値の ID が必要です。Backlog の画面上では直接見えないことがあるので、ブラウザで上記の API URL にアクセスして JSON から確認するのが確実です。

なぜ Personal Access Token が必要か

GitHub Actions のデフォルトトークン（GITHUB_TOKEN）は github-actions[bot] という仮想アカウントとして動作します。Kiro Autonomous Agent は /kiro コマンドを受け付ける際に、コメントの投稿者が Kiro に登録済みの GitHub ユーザーであることを確認します。bot アカウントは Kiro に登録できないため、GITHUB_TOKEN からの /kiro コメントは無視されます。

Personal Access Token を使うことで、コメントがあなた自身のアカウントから投稿され、Kiro が /kiro コマンドを認識してタスクを開始します。

Step 5: GitHub ラベルの作成

GitHub Actions ワークフローが Issue 作成時に付与するラベルを事前に作成しておきます。GitHub リポジトリの Issues → Labels → New label から以下のラベルを作成します。

ラベル名	説明	用途
`kiro`	Kiro Autonomous Agent にタスクを割り当てる	Kiro が自動的にタスクを開始する

シナリオ1: Backlog の課題を Kiro に実装させる

準備が完了したら、実際にフローを動かしてみます。

↓ イメージ

課題の登録と担当者の変更

スプリントプランニングで課題を整理し、Kiro に任せる課題の担当者を「Kiro」に変更します。開始日を設定しておくことで、その日の朝に自動で GitHub Issue に変換されます。

↓開始日を指定して課題を作成

↓担当者をKiroに設定した

GitHub Actions で Issue を作成

平日の朝9時（または手動実行）に GitHub Actions が Backlog API を呼び出し、今日開始の Kiro 担当課題を優先度順に取得して GitHub Issue に変換します。Issue には kiro ラベルが付与されるため、Kiro Autonomous Agent が自動的にタスクを開始します。

↓今回は手動で実行して確認します

↓ Issuesが作成されたことを確認

1日あたりの取得上限は Kiro の同時実行上限に合わせて10件です。課題が10件を超える場合は、朝9時と夕方18時の2回実行で対応できます。

取得した課題は Backlog 上で自動的に「処理中」に更新されるため、次回の実行で重複取得されることはありません。

Kiro が実装して PR を作成

Kiro Autonomous Agent がリポジトリを分析し、Steering ファイルの規約に従って実装を進めます。

↓PRが作成されることを確認　ブランチ名も指定した形式で作成されていることを確認しました

PRに対してSecurityAgentが自動的にコードレビューを行う

課題の順序依存に関する注意

Kiro Autonomous Agent の各タスクは独立したサンドボックスで実行され、他のタスクの状態を参照できません。同じ開始日の課題は並列実行されるため、「課題Aが完了してから課題Bを開始する」という順序制御はできません。

順序依存がある課題を Kiro に任せる場合は、以下の方法で対応します:

開始日をずらす: 依存関係のある課題は開始日を1日ずつずらしてプランニングする（課題A: 月曜、課題B: 火曜）。GitHub Actions は開始日が今日の課題のみ取得するため、自然に順序が制御される
1つの課題にまとめる: 依存関係のある作業を1つの課題として記述し、Kiro に一括で実装させる。Kiro のマルチリポジトリ対応を活かせば、複数リポジトリにまたがる変更も1タスクで対応可能

Kiro に任せる課題は互いに独立したものを選び、依存関係のある作業は上記の方法で整理しておくのがスムーズです。

Slack に自動通知、Backlogの課題のアップデート

PR が作成されると、GitHub Actions が Slack に自動通知します。

↓ Backlog課題のステータスが「処理済み」になったこと確認

↓ Backlog課題にPRレビューを依頼するコメントが追加されたことを確認

シナリオ2: DevOps Agent の Agent-ready spec を Kiro に実装させる

DevOps Agent の予防レコメンデーションには「Agent-ready specification」が含まれることがあります。これはコーディングエージェント向けに構造化されたドキュメントで、そのまま Kiro への指示として使えます。

↓ イメージ

Agent-ready spec を GitHub Issue にコピー

DevOps Agent の Web App でレコメンデーションの詳細を開き、Agent-ready spec の内容をコピーして GitHub Issue に貼り付けます。

「予防」画面にある「エージェント対応スペック」

「インシデントレスポンス」画面にある「エージェント対応仕様」

Agent-ready spec には以下が含まれています:

問題の概要と根本原因
推奨アプローチの概要
変更が必要なリポジトリ
具体的なコード変更内容（ファイルパス、実装の考慮事項）
テスト要件
段階的な実装計画

この構造化された内容がそのまま Kiro への指示になるため、人間が要件を書き直す手間が省けます。

↓ ラベルでkiroを指定すればKiroが対応を始める

検証結果

PR作成が行われました

Kiro は Agent-ready spec の構造化された内容を正確に理解し、包括的な実装を行いました:

テストインフラの導入: Jest、ts-jest、ESLint、aws-sdk-client-mock を devDependencies に追加
24テストケース: 5つの Lambda ハンドラーに対するユニットテスト。2026-03-29 インシデントの回帰テスト（pathParameters が undefined のケース）を含む
3ステージの CI/CD パイプライン: build（TypeScript コンパイル + ESLint）→ test（Jest + 85%カバレッジ閾値）→ deploy（main ブランチのみ CDK デプロイ）
README ドキュメント: CI/CD パイプラインの概要、テストコマンド、コントリビューティングワークフローを追加

特に注目すべき点は、Agent-ready spec に含まれていたインシデントの背景（PR #4 によるリグレッション）を正しく理解し、その正確なシナリオを再現する回帰テストを含めていたことです。Agent-ready spec の構造化された情報がそのまま Kiro への指示として機能することが確認できました。

学習のフィードバックループ

Kiro Autonomous Agent はコードレビューのフィードバックから学習します。この学習を Steering ファイルとして明文化し、チーム全体で共有する方法を検証します。

コードレビューでフィードバック

Kiro が作成した PR に対してコードレビューでフィードバックを送ります。
重要なポイントとして、学習に影響するのはタスク作成者（自分）のフィードバックのみです。

シナリオ２のPRにはいくつかのSecurityAgentからの指摘がありましたので、今回はこの指摘内容を改修してKiro autonomous agentに学習してもらいます。

自分からのフィードバックにするために「/kiro all」とコメントし、SecurityAgentからのすべての指摘をKiroに修正してもらいます

↓「/kiro all」をコメントに入力

↓ Kiro autonomous agent がレビュー内容の修正を始める

学んだパターンを Steering ファイルに出力

Kiro に以下の Issue を作成して kiro タグを付けて依頼します:

タイトル:

コードレビューから学んだパターンを Steering ファイルにまとめる

詳細:

これまでのコードレビューのフィードバックから学んだパターンを
.kiro/steering/learned-patterns.md にまとめてください。

過去のタスクで受けたフィードバックや、コードレビューで指摘された内容から、
今後のタスクで自動的に考慮すべきパターンを整理してください。

↓ Issue作成画面のキャプチャ

Kiro autonomous agentからのPRを確認すると、以下のようにレビュー内容を反映したSteeringが作成されました
↓ PR内容

↓ Steeringの内容(コードレビューから学んだパターンが記載されている)

検証結果

Kiro は過去の PR 履歴を分析し、コードレビューで指摘されたパターンを体系的にまとめた Steering ファイルを作成しました。生成された learned-patterns.md には以下のカテゴリが含まれていました:

認証・認可: userId のガード、オーナーシップチェック（IDOR 防止）、API Gateway の認証設定
入力バリデーション: pathParameters の undefined チェック、JSON.parse のクラッシュ対策、XSS 対策
エラーハンドリング: スタックトレースの非露出、情報漏洩を防ぐレスポンス順序
DynamoDB 操作: UpdateCommand の upsert 防止
テスト: 脆弱性が存在しないことのアサーション方法
変更スコープ: Issue で要求された範囲のみ変更する

特に注目すべき点は、各パターンに具体的な PR 番号（#3, #4, #5, #34 など）が参照されており、Security Agent の指摘内容（IDOR、XSS、スタックトレース漏洩）も含まれていたことです。

公式ドキュメントでは「タスク作成者のフィードバックのみが学習に影響する」と記載されていますが、Kiro はリポジトリの PR 履歴全体を分析して情報を取得できるようです。「永続的な学習」と「PR 履歴の参照」は異なる仕組みと考えられます。

今回の検証で、以下のフィードバックループが実際に回ることを確認できました:

Kiro がタスクを実行 → PR を作成
Security Agent がコードレビューでセキュリティ指摘 → /kiro all で Kiro が修正
Kiro に「学んだパターンを Steering ファイルにまとめて」と依頼 → PR で追加
チームメンバーがレビューして承認 → 暗黙知が明文化されてチーム全体で共有

現時点のKiro autonomous agent を含む Frontier agentsの制約

Slack → Kiro への直接指示はできない（Slack → GitHub Issue → Kiro の間接フロー）
Security Agent の設計レビュー「開始」は Web App での手動操作が必要（アップロードまでは API で自動化可能）
DevOps Agent の Agent-ready spec は Web App から手動コピーが必要（API リファレンス未公開）
Kiro の学習内容を明示的にエクスポートする機能はない（Steering ファイル作成を依頼する間接的な方法で要検証）

さいごに

GitHub Actions と AWS API を活用することで、Kiro Autonomous Agent を「チームの一員」に近づけることができました。

Backlog の課題取得から実装、Security Agent によるレビュー、Slack 通知、Backlog のステータス更新まで、人間の開発者と同じワークフローを Kiro が辿る構成を構築できました。Steering ファイルでチームの規約を教えておけば、最初のタスクから「チームの一員らしい」コードを書いてくれます。

また、DevOps Agent の Agent-ready spec をそのまま Kiro への指示として使えること、過去の PR 履歴から学んだパターンを Steering ファイルとして出力できることも確認できました。

現時点では GitHub Issue を介した間接連携が中心ですが、Frontier Agents のエコシステムが進化するにつれて、エージェント間の直接連携や自動化の幅はさらに広がっていくかもしれません。

英語版記事はこちら

[AWS] Strategies to make KAA work like a member of the project team [Kiro]

参考

Kiro autonomous agent

Creating tasks

AddArtifact API - AWS Security Agent

BatchGetFindings API - AWS Security Agent

Backlog API

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up