Kiro WebのCollaborativeモードでGitHubリポジトリ解析から改善PR作成、/kiro fixでのレビュー対応まで試してみた
はじめに
Kiro Webは、ブラウザー上でGitHubリポジトリと連携しながらAIとコーディングできる開発環境です。2026年5月にパブリックプレビューとしてリリースされました。
いわささんの記事では、Kiro WebのセットアップとAutonomousモードでのREADME生成が紹介されています。今回はその続きとして、Collaborativeモード（Autonomous OFF）で既存リポジトリを解析し、改善PRを作成し、さらに /kiro fix でレビュー指摘を自動修正する流れを試しました。
検証したいポイントは以下の2点です。
- Collaborativeモードで「解析→改善提案→PR作成→レビュー対応」の流れをGitHub上で回せるか
- AIが生成した技術内容に誤りがあった場合、
/kiro fixで修正サイクルを回せるか
検証内容
今回の検証は、大きく2つのサイクルで構成されています。
使用するリポジトリ
今回は自分が管理する cm-suzuki-ryo/cloudwatch-logs-query-skill を使用しました。CloudWatch Logs Insightsのクエリ作成を支援するKiroスキルとナレッジベースで構成されています。スキルには言語選択ガイド・クエリパターン・Tips・注意点、ナレッジベースには3言語のコマンド・関数リファレンスが含まれます。
ファイル構成：
cloudwatch-logs-query-builder.skill.md— スキル本体（クエリ作成支援のルール・パターン集）cloudwatch-logs-query-languages-reference.md— ナレッジベース（QL/PPL/SQLのコマンド・関数リファレンス）readme.md/readme-jp.md— 利用方法
解析を依頼する
Kiro Webにリポジトリを接続し、Collaborativeモードで以下のように依頼しました。
現在のリポジトリ、CloudWatch Logs Insights のクエリ作成支援スキルです。スキルとナレッジベースを読んで、改善案があれば提案してください。
Kiroはリポジトリをクローンし、4ファイルすべてを読み込んだ上で改善提案を返してきました。所要時間は1分12秒、クレジット消費は0.23でした。
改善提案の内容
返ってきた提案は7項目で、優先度付きのテーブルとして整理されていました。
| 優先度 | # | 提案内容 |
|---|---|---|
| 高 | #3 | コマンドパイプライン順序ルールの明文化 |
| 高 | #2b | AI 生成アンチパターンの強化 |
| 中 | #5 | 不足構文例の追加 |
| 中 | #1 | IA 制約の明確化 |
| 中 | #4 | コスト最適化ガイド |
| 低 | #2a | ユースケース追加 |
| 低 | #7 | バージョン情報 |
提案の中から、高優先度の2項目（#3コマンド順序ルール、#2bアンチパターン強化）に加えて、低優先度ながらメンテナンス性向上に有用な #7バージョン情報を選び、改善の実施とPRの作成を依頼しました。
Sub-agent による多段実行
修正依頼を投入すると、Kiro WebはSub-agentを起動して実装を進めました。今回の実行ログで観測できた流れは以下のとおりです。
- planner: リポジトリ構造を把握し、タスク計画を作成
- coder（1回目）: 計画に基づいてスキルファイルにセクションを追加（コマンド順序ルール・アンチパターン・バージョン情報）
- Semantic Reviewer: 差分を解析し、5件のレビュー指摘を出力（冗長性、図の不完全性、修正案不備など）
- coder（2回目）: レビュー5件に対応して修正を実施
この一連のplanner → coder → Semantic Reviewer → coderの再修正は、PR作成前にKiro Web内部で完結していました。人間の介入なしに、自律的にレビューサイクルが回っている点が興味深いです。
PR 作成完了
Sub-agentの処理が完了すると、自動的にGitHubにPRが作成されました。所要時間は11分18秒、クレジット消費は3.78でした。
GitHub で PR を確認
作成されたPRの内容を確認します。
- ブランチ名：
improve/command-ordering-and-antipatterns - コミット数： 4（実装 + タスク状態管理）
- 作成者：
kiro-agent[bot]on behalf of @cm-suzuki-ryo - 差分： +419/-7行
PRの説明文には実装した改善内容のサマリが日本語で記載されていました。今回のコミット履歴には、内部レビューサイクル（FEAT-001実装 → Semantic Reviewer → FEAT-002レビュー対応）の痕跡も残っていました。
技術的正確性の検証
PRの内容が技術的に正しいか検証しました。今回は対象がナレッジベース（CloudWatch Logs Insightsのクエリ構文リファレンス）であり、事実誤認があると、AIが参照するナレッジベースに誤った情報を残してしまうため、別途検証を実施しました。
検証は以下の2段階で行いました。
- KB照合: PRの差分と既存のナレッジベースを突合し、主張の整合性を確認
- 実機検証: CloudWatch Logs Insightsで実際にクエリを実行し、動作を確認
結果、重大な事実誤認を1件発見しました。
PRは「filter は stats の後に置けない / Logs Insights QLにはHAVING相当がない」と主張していましたが、実機で以下のクエリを実行したところ正常に動作しました。
stats count(*) as c by @logStream | filter c > 3 | sort c desc
5グループ（count: 9, 3, 3, 3, 2）のうちcount > 3の1グループのみが返却されました。filter c > 3 が集計後のしきい値フィルタ（HAVING相当）として機能しています。
加えて以下の問題も確認しました。
filterIndexの「必ず先頭」記述： 今回試した範囲では先頭以外に置いても構文エラーにならず、ハードルールとしては不正確（ベストプラクティスとしての推奨が正しい）- ワークアラウンド2（chained statsで絞り込み）: 1行に集約されるだけで、グループ単位の絞り込みにはならない
AIが生成した改善提案にも事実誤認が含まれていました。PRを作成するだけでなく、人間による技術的正確性の検証が重要であることを改めて確認できました。
/kiro fix によるレビュー対応
検証結果をPRコメントとして投稿し、続けて /kiro fix を投稿しました。
/kiro fix を投稿すると、Kiro Webが自動的に新しいセッションを起動しました。セッションタイトルは「Addressing feedback on cm-suzuki-ryo/cloudwatch-logs-query-skill #1」。
今回の実行ログで観測できた /kiro fix の動作は以下のとおりです。
- PR コメントの自動取得: レビュー指摘の内容を取得し、3つの修正ポイントに構造化
- 守備範囲の制限: orchestrator_briefingで「Anti-patterns #2-#7は検証済み正確なので変更しない」と明示的に制限
- coder への委譲: 制限付きの修正指示でSub-agent: coderに委譲
修正された内容は以下の3点です。
- Anti-pattern #1（「filterはstats後に置けない」）を撤回。
stats ... by <group> | filter <agg> > NでHAVING相当が可能であることを正例として記載 - 「No HAVING Equivalent」セクションの全面改訂（ワークアラウンド群を削除し、後置filterを正規手段として提示）
filterIndexの「必ず先頭」を「先頭配置を推奨（スキャン削減のため）」に緩和
3分27秒・1.56クレジットで3点の修正が完了し、2コミットがPRに追加されました。
注目すべきは、守備範囲の制限が機能していた点です。今回は問題なしと判断したAnti-patterns #2〜#7には手を加えず、指摘された箇所のみを修正していました。レビューで指摘した範囲外への変更が混入しないのは、実用上重要なポイントです。
マージ
修正内容を確認し、PRをマージしました。最終的なコミット履歴には「PRコメント → /kiro fix → 追加コミット → マージ」の一連の流れが記録されています。
まとめ
Kiro WebのCollaborativeモードで、既存リポジトリの解析、改善PR作成、/kiro fix によるレビュー対応までを一通り試しました。対話的に改善方針を選べるため、「何を直すか」は人間が判断し、実装はKiroに任せる流れを作れます。
/kiro fix はPRコメントから修正サイクルを回せる点が便利でした。今回の検証では、指摘範囲に絞って追加修正され、不要な変更も混入しませんでした。
ただし、初回PRには「filter は stats の後に置けない」という事実誤認が含まれていました。実機検証では、集計後の filter がHAVING相当の絞り込みとして動作することを確認しています。PR作成の自動化と内容の正確性は別問題であり、AI出力には人間のレビューや実機検証が必要です。
Kiro Web上の実行分は合計5.57クレジット / 約16分でした。内訳は、解析・提案が0.23クレジット、改善実装＋PR作成が3.78クレジット、/kiro fix が1.56クレジットです。技術検証の時間やCloudWatch Logs Insightsのスキャン課金は含みません。
