Kiro WebのCollaborativeモードでGitHubリポジトリ解析から改善PR作成、/kiro fixでのレビュー対応まで試してみた

• URL: https://dev.classmethod.jp/articles/kiro-web-collaborative-github-pr-kiro-fix/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Kiro Web（2026年5月パブリックプレビュー）のCollaborativeモードを使い、GitHubリポジトリ解析→改善提案→PR作成→/kiro fixによるレビュー対応の一連フローを実証。内部でplanner→coder→Semantic Reviewer→coderの再修正サイクルが自律的に回る。ただし初回PRに事実誤認が含まれており、人間による技術検証が不可欠と結論。

詳細

Kiro Webの仕組み

• ブラウザ上でGitHubリポジトリと連携しながらAIコーディングできる開発環境
• Collaborativeモード（Autonomous OFF）: 対話的に改善方針を選択、実装はKiroが担当

Sub-agentの実行フロー（自動観測）

1. planner: リポジトリ構造把握・タスク計画
2. coder（1回目）: スキルファイルへのセクション追加
3. Semantic Reviewer: 差分解析、5件のレビュー指摘
4. coder（2回目）: レビュー5件への対応 → PR作成前に内部でレビューサイクルが自律的に完結

検証で発見した事実誤認 初回PRの主張「filterはstatsの後に置けない／HAVING相当機能なし」が誤り。 実機検証でstats count(*) as c by @logStream | filter c > 3が正常動作することを確認（HAVING相当として機能）

/kiro fixの動作

• PRコメントを自動取得して修正ポイントを構造化
• 守備範囲を明示的に制限（問題なし判断部分には手を付けない）
• 3分27秒・1.56クレジットで3点修正完了

コスト実績

• 全体合計: 5.57クレジット / 約16分
  • 解析・提案: 0.23クレジット
  • 実装+PR作成: 3.78クレジット
  • /kiro fix: 1.56クレジット

結論: PR作成の自動化と内容の正確性は別問題。ナレッジベース系コンテンツには人間の実機検証が必須