Kiro WebのCollaborativeモードでGitHubリポジトリ解析から改善PR作成、/kiro fixでのレビュー対応まで試してみた
はじめに
Kiro Webは、ブラウザー上でGitHubリポジトリと連携しながらAIとコーディングできる開発環境です。2026年5月にパブリックプレビューとしてリリースされました。
いわささんの記事では、Kiro WebのセットアップとAutonomousモードでのREADME生成が紹介されています。今回はその続きとして、Collaborativeモード（Autonomous OFF）で既存リポジトリを解析し、改善PRを作成し、さらに /kiro fix でレビュー指摘を自動修正する流れを試しました。
検証したいポイントは以下の3点です。
- Collaborativeモードで「解析→改善提案→PR作成→レビュー対応」の流れをGitHub上で回せるか
- AIが生成した技術内容に誤りがあった場合、
/kiro fixで修正サイクルを回せるか - Kiro WebにPRレビューを依頼した場合、どの程度の品質で返ってくるか
検証内容
今回の検証は、大きく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 に PR レビューを依頼する
PR #1のマージ後、JOIN/サブクエリ構文を追加するPR #2を作成しました。このPRに対して、Kiro Web上でレビューを依頼してみました。
レビュー依頼
Kiro Webに以下のように依頼しました。
このリポジトリの PR #2 をレビューしてください。
レビュー観点として6点を指定しました。
- 正確性（AWS公式ドキュメントとの整合）
- 網羅性（パラメータ・制約・挙動の説明漏れ）
- サンプルクエリの品質（構文の正しさ、limit付与等のベストプラクティス）
- スキルファイルとの整合性（reference.mdとskill.md間の矛盾）
- 言語選択ガイドの妥当性（3言語すべてでJOIN/サブクエリが使える現状の反映）
- 既存コンテンツとの一貫性（表記・フォーマット・粒度の統一）
レビュー結果
Kiro WebはSub-agent: Semantic Reviewerを起動し、5件の指摘を構造化して返しました。所要時間は5分51秒、クレジット消費は1.82でした。
| 重要度 | 指摘内容 |
|---|---|
| ● 重要 | where節とSOURCEの順序がAWS公式と異なる可能性 |
| 🟡 中 | Left joinサンプルにlimitが欠落（skill.mdのベストプラクティスと矛盾） |
| 🟡 中 | サブクエリ内fields終端の必須性（単一フィールド制約）が未記載 |
| 🟡 中 | Right側フィールドの絞り込み方法が未説明 |
| ⚪ 低 | サブクエリ結果の最大行数制限の可能性（要公式確認） |
観点別の評価サマリも付いており、正確性◯・網羅性△・サンプル品質△・整合性◯・言語選択ガイド◎・一貫性◯という結果でした。指摘は具体的で、対象箇所・理由・推奨対応がセットで記載されています。
制約: PRコメントの投稿ができない
レビュー結果をPRコメントとして投稿するよう依頼したところ、現在のKiro Webにはコメント投稿機能がないことがわかりました。Kiroが確認した制約は以下のとおりです。
- GitHub Powerツール: 読み取り専用（
get_comments,list_pr_commentsのみ） - GitHub CLI (
gh): 未インストール - GitHub API直接呼び出し: ネットワークモードが「Repository access only」でブロック
- ゲートウェイ: Git操作専用でREST APIに非対応
この投稿試行に1分51秒・1.00クレジットを消費しましたが、結果的にコメントは投稿できませんでした。レビュー結果はチャット上にMarkdown形式で出力されるため、人間が手動でPRページに貼り付ける必要があります。
Kiro CLI との連携で改善サイクルを回す
Kiro Web単体ではレビュー結果をPRに書き込めないため、ここからはローカルのKiro CLIと連携してサイクルを回しました。フローは以下のとおりです。
- Kiro Webのレビュー結果を人間がPRコメントとして転記（
gh pr commentで投稿） - Kiro CLIにレビュー内容を伝え、対応方針を相談
- Kiro CLIが各指摘を判断し、実機検証が必要なものをus-east-1で検証
- 検証結果に基づいて修正をコミット・プッシュ
- Kiro Webに再レビューを依頼 → Approve
- Kiro CLIでマージ
Kiro CLIが出した判断テーブルは以下のとおりです。
| # | 指摘 | 判断 | 根拠 |
|---|---|---|---|
| 1 | where/SOURCE順序 | 対応不要 | 公式ドキュメントと同一順序。動作確認済み |
| 2 | left joinにlimit欠落 | ✅ 修正 | 明らかな漏れ。自身のBest Practicesと矛盾 |
| 3 | サブクエリ単一フィールド制約 | ✅ 追記 | 実証: MalformedQueryException: must produce exactly one output column |
| 4 | right側フィールド絞り込み | ✅ 制限として追記 | 実証: JOIN right source cannot contain pipe operations in Phase 1 |
| 5 | サブクエリ行数制限 | 対応不要 | 公式ドキュメントに記載なし。推測で制約を書くべきでない |
指摘5件のうち、対応が必要と判断した3件についてはCLI上で実機検証を実施しました。テスト用ロググループを作成し、実際にクエリを実行してエラーメッセージを確認した上で制約を追記しています。対応不要とした2件も「なぜ対応しないか」の根拠をコミットメッセージとPRコメントに記録しました。
修正をプッシュした後、Kiro Webに再レビューを依頼したところ、5件すべての対応を確認した上で「マージ可能」の判定が返りました。最終的にKiro CLIからsquash mergeを実行してPR #2をクローズしています。
三者連携の構図
今回のPR #2で実現したのは、以下のような役割分担です。
| 役割 | 担当 |
|---|---|
| レビュー（指摘の発見） | Kiro Web |
| 判断（対応要否の決定） | 人間 + Kiro CLI |
| 検証・修正（実機確認と実装） | Kiro CLI |
| 再レビュー（修正の承認） | Kiro Web |
| 中継（コピペ・投稿・マージ） | 人間 |
人間の役割は「判断」と「中継」です。Kiro Webがコメントを書けない現状では人間がコピペで橋渡しする必要がありますが、その分レビュー内容を目視確認してから次のステップに進められるため、AIの指摘を盲目的に適用することを防げます。
PR #1の /kiro fix がKiro Web内で完結するサイクルだったのに対し、PR #2は「Kiro Web × 人間 × Kiro CLI」の三者でレビュー→検証→修正→再レビューのサイクルを回した形になります。
まとめ
Kiro WebのCollaborativeモードで、既存リポジトリの解析、改善PR作成、/kiro fix によるレビュー対応、さらにPRレビューの依頼までを試しました。対話的に改善方針を選べるため、「何を直すか」は人間が判断し、実装はKiroに任せる流れを作れます。
/kiro fix はPRコメントから修正サイクルを回せる点が便利でした。今回の検証では、指摘範囲に絞って追加修正され、不要な変更も混入しませんでした。
PRレビューの依頼では、レビュー観点を指定すると構造化された指摘が返ってきます。ただし現時点ではPRコメントの投稿機能がなく、レビュー結果を人間が手動で転記する必要があります。この制約をKiro CLIとの連携でカバーし、「Kiro Web（レビュー）→ 人間（判断・中継）→ Kiro CLI（検証・修正）→ Kiro Web（再レビュー）」の改善サイクルを回せることを確認しました。人間がコピペで橋渡しする手間はありますが、レビュー内容を目視確認してから次に進められるため、AIの指摘を盲目的に適用するリスクを減らせます。
初回PRには「filter は stats の後に置けない」という事実誤認が含まれていました。実機検証では、集計後の filter がHAVING相当の絞り込みとして動作することを確認しています。PR作成の自動化と内容の正確性は別問題であり、AI出力には人間のレビューや実機検証が必要です。
Kiro Web上の実行分は合計8.39クレジット / 約25分でした。内訳は以下のとおりです。
| 操作 | クレジット | 所要時間 |
|---|---|---|
| 解析・提案 | 0.23 | 1分12秒 |
| 改善実装＋PR作成 | 3.78 | 11分18秒 |
/kiro fix |
1.56 | 3分27秒 |
| PRレビュー | 1.82 | 5分51秒 |
| PRコメント投稿試行（失敗） | 1.00 | 1分51秒 |
技術検証の時間やCloudWatch Logs Insightsのスキャン課金は含みません。
