Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AI に確かめさせる | Kiro と学ぶハーネスエンジニアリング 05

AI に確かめさせる | Kiro と学ぶハーネスエンジニアリング 05

AI のレビューを観点ごとのレビュー役 (Kiro のカスタムエージェント) に分け、取りまとめ役が、レビュー役をサブエージェントとして同時に動かして答えを集める方法を説明する配布資料です。出す前に変更を読み直させて、指摘を 1 回で全部出させる決まりも書いています。例題の PR (会議室の予約の取り消し) を Kiro IDE でレビューした画面と、出た指摘を載せています。止める指摘 (その PR で直すまで merge しない指摘) を「場所、根拠、起きる条件、結果」の 4 つがそろうものだけにする決まりと、直すたびに仕組みが増えるときに振り返って仕組みを減らす方法も扱います。シリーズ「Kiro と学ぶハーネスエンジニアリング」の 05 (確かめる) です。

Avatar for Riku INADA

Riku INADA PRO

November 09, 2026

More Decks by Riku INADA

Other Decks in Technology

Transcript

  1. Kiro と学ぶハーネスエンジニアリング 確かめる AI に確かめさせる 役ごとのレビュー役と、 ⽌める指摘の決め⽅ 05 2026-11 時点

    2026 年 11 ⽉ 稲⽥ ⼤陸 アマゾン ウェブ サービス ジャパン + Kiro + Harness Engineering © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1
  2. はじめに ⾃⼰紹介 稲⽥ ⼤陸 いなだ りく (いなりく) アマゾン ウェブ サービス

    ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中⼼に⽀援 最近の取り組み AI 駆動開発ライフサイクルの推進 Kiro と AWS Amplify の情報発信 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. X @inada_riku Speaker Deck speakerdeck.com/inariku Zenn zenn.dev/inariku GitHub github.com/inariku 2
  3. はじめに シリーズの中の位置 いまは 05 AI に確かめさせる、次は 06 できることを囲う、07 CI に載せる

    考え⽅ 01 導く 01 ハーネスエンジニアリング⼊⾨ 02–03 確かめる 前に読む 決まりと 02 地図を渡す 04 機械で確かめる 意図を 05 AI に確かめさせる 03 仕様で渡す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 04–05 囲う 06 回す 次に読む 06 できることを囲う 07–08 次に読む 07 CI に載せる ハーネスを 08 育てる 3
  4. はじめに この資料で分かること AI のレビューは役を分け、1 回でまとめて出させ、⽌める指摘の決まりを先に決める 1 AI の確かめ (AI のレビュー)

    が⾒られることと、⾒られないこと。 2 観点ごとにレビュー役を作り、並べて流して 1 つの表にまとめる⽅法。 3 ⽌める指摘の決め⽅と、直すたびに仕組みが増えるのを⽌める⽅法。 前に読むとよい資料: 04 機械で確かめる。カスタムエージェントの作り⽅は ⽬指せ Kiro マスター 08 Skill とカスタムエージェント 「ブログ」は kiro.dev のブログ「Keeping a software factory stable at 1,000 PRs a week」(2026-10-26) のこと 例は会議室の予約アプリ (⽬指せ Kiro マスターと同じもの)。画⾯は Kiro IDE 1.4.121 で撮った 図の⾊: 紫は要点と⼈が決める所、⻘は Kiro の動き、緑は通ったもの © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
  5. 考え⽅ AI の確かめ 意味を⾒る確かめは AI に任せられるが、遅く、⾼くつき、毎回同じ答えとは限らない 機械の確かめ (資料 04) AI

    の確かめ (この資料) 動かすもの CPU 動かすもの GPU (モデル) 意味を⾒るので、⼀部は⾒られる 速さ ミリ秒〜秒 速さ 遅く、⾼くつく 意味が同じで書き⽅が違うコード 答え 毎回同じ 答え 揺れる ⼒ずくの直し 例 テスト、型、lint どちらも確実には捕まえない 要らないテスト 作りすぎ 原因の⾒⽴て違い、頼んでいない機能、指⽰の取り違え 頼んだことが書いていなければ、正しさはどちらの確かめでも確かめられない AI の確かめはコミットのたびには流さない。強い、向いたモデルで使うと信頼しやすい (Böckeler) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5
  6. レビュー役を作る レビュー役を作る カスタムエージェントに 1 つの観点だけを持たせ、書く道具は渡さない 1 description 2 tools 3

    permissions の allow 4 permissions の deny 5 resources と本⽂ (画⾯の下) 名前で頼まないとき、親がこれを読んで相⼿を選ぶ write は渡さない。shell は次の許可で絞る git の読む操作 (diff、log、show) は聞かずに通す 親から呼ぶときは、親にも同じ allow が要る (A2) 消す、commit、push は拒む。ほかは親の決まりに従う 共通の決まりを読み、観点 1 つ分の問いを 2 つ書く .kiro/agents/design-reviewer.md の 2〜12 ⾏⽬ (Markdown の頭に設定、本⽂に指⽰)。信頼したワークスペースでだけ読み込まれる。作り⽅は ⽬指せ Kiro マ スター 08。設定の要点は付録 A1、A2 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
  7. レビュー役を作る 役で分ける 1 つのレビュー役で全部を⾒ると浅くなる。観点ごとに役を分ける 設計 根本原因 利⽤者の体験 書く道具なし 書く道具なし 書く道具なし

    今の作りに合うか 根本の原因を直しているか 画⾯から使えるか もっと簡単な作り⽅はないか 利⽤者に本当に要るか 応答とエラーの⽂がそろうか design-reviewer first-principles-reviewer ux-reviewer 1 つのレビュー役に全部を⾒せると、深くまで⾒ない。観点ごとに役を分け、ほかの役の観点は⾒ないと書く ブログのチームは、別の系統のモデルのレビュー役にも⾒せる (書いたモデルと同じ系統は、同じ所を⾒落としやすい) 役ごとのモデルは、設定の model の項⽬で選べる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
  8. レビュー役を作る 1 回でまとめて出させる ⼩出しの指摘は、直すたびに新しい指摘を呼ぶ。何度か読み直させ、1 回で全部出させる ⼩出しの レビュー 5件 直す 新しく

    4 件 直す また 3 件 … 変更の⼤きさ 直すたびにコードが増え、増えた所にも指摘が付く 1 回で全部 何度か読み直し、前に出した 出すレビュー ものは⾶ばして全部出す 直すのは 1 回 通る 遅くても全部出すレビュー役のほうが、何回にも分けて出す役より安くつく (ブログ) 例題では、決まりのファイルに「出す前に変更をもう 1 度読み直す」と書いた (付録 A1) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
  9. ⽌める指摘の決まり ⽌める指摘の決まり 場所、根拠、起きる条件、結果の 4 つがそろうものだけを、⽌める指摘にする 1 つの指摘 4 つがそろう 場所

    ファイルと⾏ 根拠 そのコードの引⽤ 起きる条件 どんな⼊⼒や操作で 結果 設計の懸念 何が壊れるか ⽌める指摘 どれかが⾔えない 助⾔ 扱いは PR を書いた⼈が決める あとで戻せない選択 (one-way door。例: 保存するデータの形) のときだけ⽌める。戻せる選択なら助⾔ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
  10. ⽌める指摘の決まり 重さで分ける ⽌める指摘はその PR で直す。助⾔の扱いは PR を書いた⼈が決める ⽌める指摘 この PR

    で直す 直し⽅は、PR の⽬的を果たす⼀番⼩さい変更。それより⼤きい作り直しは issue に分ける 指摘 助⾔、⼩さな指摘、書き⽅ この PR で直す、issue に回す、直さないを、書いた⼈が決める 例外: 利⽤者の操作で起きる落ち⽅、セキュリティの⽳、データが消えることは、直しが⼤きくてもこの PR で直す この決まりは例題の .kiro/review/blocking-rules.md に書き、どのレビュー役にも resources で読ませた (付録 A1) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
  11. 例題 例題: 予約の取り消しの PR ⽬指せ Kiro マスター 10 の Workflow

    が作った PR を、取りまとめ役と 3 つの役で⾒る 設計 PR: 予約の取り消し DELETE /api/reservations/:id 4 ファイル、+97 −1 ⾏ 取り消しの API とテスト 画⾯は変えていない 1 つの表 取りまとめ役 review-lead 根本原因 同時に頼む ⽌める 助⾔ 利⽤者の体験 ⽬指せ Kiro マスター 10 の Workflow (段ごとに流す機能) が作った サブエージェント (⾃分の⽂脈で動き、答えを親に返すエージェント) として読み、答えだけを返す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
  12. 例題 並べて流す 取りまとめ役が 3 つのレビュー役をサブエージェントとして同時に動かし、答えを集める エージェントを review-lead に切り替え、「main と cancel-reservation

    の差分をレビューして」と頼んだ。左は 3 つの 役のうち ux-reviewer が動いているところ。 サブエージェントは Steering、MCP、許可を親と分け合い、会話と⽂脈は⾃分だけで持つ。IDE と CLI V3 では、道具を使うたびに親とレビュー役の両⽅の許 可で確かめ、厳しいほうが勝つ。親の決まりに無い読むコマンド (git grep、sed -n、head) は、右のように 1 つずつ聞かれた (例題では Allow を押した)。 headless では聞けないので拒まれる (CI は資料 07)。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12
  13. 例題 例題で出た指摘 ⽌める指摘は 1 件。4 つがそろわない⽌める指摘は、取りまとめ役が助⾔に下げた 3 つの役の指摘 取りまとめ 7件

    ⽌める 誰の予約でも、id だけで物理削除できる 1件 (根本原因が⽌める。設計と利⽤者の体験は助⾔) ⽌める → 助⾔ 要件の「対象外」と⾷い違う (起きる条件と結果が⾔えない) 2件 画⾯に取り消しの操作がない (場所と根拠が⾔えない) 助⾔ 失敗の⽂が合わない、消した予約の全項⽬を返す 4件 deleteById は 1 ⽂の SQL で書ける、空⾏ 直し⽅の案は 2 つ。予約者の名前が合うときだけ消す、または論理削除にして戻せるようにする どちらにするか、認証なしが意図どおりかは、要件と合わせて⼈が決める (取りまとめ役も⼈に残した) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
  14. 作りすぎ 作りすぎに気づいて引く 直すたびに仕組みが増えるときは、振り返って引く 直すたびに仕組みが増える 振り返る 同じ所を何度も直したら、変更が 収まらず育っていないかを⾒る (⽬安は 3 回⽬。この資料のすすめ)

    指摘 指摘 打ち切る 指摘 戻す もっと簡単に たいていは、要らなくなった仕組みを引くことから。 10 ⾏の直し 仕組みを⾜す また⾜す 5 回後 指摘が正しくても、求める直しが⼤きすぎることがある めったに起きない場合の指摘に、仕組みで答え続ける ブログのチームは、振り返りを PR を整える Skill と CI に⼊れている © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
  15. まとめ まとめ AI のレビューは役を分け、1 回でまとめて出させ、⽌める指摘の決まりを先に決める 1 AI の確かめは意味を⾒られるが、遅く揺れる。機械で⾒られるものは機械 (04) に

    任せる。 2 レビュー役は観点ごとに作り、書く道具を渡さない。取りまとめ役が並べて流し、 1 回で全部出させる。 3 ⽌める指摘は 4 つ (場所、根拠、起きる条件、結果) がそろうものだけ。ほかの扱いは 書いた⼈が決め、育つ直しは引く。 明⽇からの 1 ⼿: ⽌める指摘の決まりを 1 つのファイルに書き、いま使っているレビューの指⽰に読ませる (付録 A1) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15
  16. まとめ 次に読む資料 外れたときの被害を⼩さくするなら 06、レビュー役を PR ごとに流すなら 07 このシリーズ 06 このシリーズ

    07 ⽬指せ Kiro マスター 08 できることを囲う CI に載せる Skill とカスタムエージェント 外れたときの被害を⼩さく レビュー役を PR ごとに流す カスタムエージェントの作り⽅ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
  17. 付録 A1 例題のレビュー役の設定と決まり .kiro/agents/design-reviewer.md (頭の設定) name: design-reviewer description: 設計のレビュー役。(略) 読むだけ

    tools: ["read", "shell"] permissions: rules: - capability: shell match: ["git diff", "git diff *", "git log *", "git show *"] effect: allow - capability: shell match: ["rm *", "git commit *", "git push *"] effect: deny resources: - file://.kiro/review/blocking-rules.md - file://README.md .kiro/review/blocking-rules.md (要点) ## 1 回で全部出す - 気づいたことは、この 1 回で全部出す - 出す前に変更をもう 1 度読み直す ## ⽌める指摘と助⾔ - ⽌める指摘は 4 つがそろうものだけ: 場所、根拠 (引⽤)、起きる条件、結果 - どれかが⾔えないものは助⾔ - 設計の懸念は、戻せない選択のときだけ⽌める - 利⽤者の操作で起きる落ち⽅、⽳、 データが消えることは必ず⽌める ## 直し⽅の⼤きさ - PR の⽬的を果たす⼀番⼩さい変更。⼤きい 直しは issue。ただし上の 3 つは、この PR で 直す (⽂書に書くだけでは直したことにしない) ## 出し⽅: 表で、⽌める指摘を先に。書き換えない ほかの 2 つの役は、name、description、本⽂の観点だけが違う。本⽂と取りまとめ役は付録 A2。例題のコードは公開していない。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17
  18. 付録 A2 例題の取りまとめ役と、レビュー役の本⽂ .kiro/agents/review-lead.md (頭の設定。description は略) name: review-lead tools: ["read",

    "subagent"] permissions: rules: - capability: subagent match: ["design-reviewer", "first-principles-reviewer", "ux-reviewer"] effect: allow - capability: shell match: ["git diff", "git diff *", "git log *", "git show *", "git status", "git branch --show-current", "grep *", "ls *"] effect: allow resources: [file://.kiro/review/blocking-rules.md] 本⽂ (要点) 取りまとめ役: 3 つの役に同時に頼む。 答えがそろったら 1 つの表にまとめる - ⽌める指摘を先に。どの役の指摘かを書く - 同じ指摘は 1 つにまとめる - 4 つがそろわない⽌める指摘は、 助⾔に下げて理由を書く - ⾃分では指摘を⾜さない design-reviewer (設計) の本⽂: 1. 今の作りに合っているか 2. ずっと簡単な作り⽅でできないか 原因と利⽤者の体験は、ほかの役が⾒る ので⾒ない 決まりは blocking-rules.md に従う tools の subagent は、どの役でも起こせる。permissions に書いた 3 つの役は聞かれずに起き、ほかの役は聞かれる。shell の許可は、レビュー役の道具を通 すために書いた (取りまとめ役の tools に shell は無い)。本⽂の最後は、この PR で直すもの (⽌める指摘) と、あとの issue の候補 (助⾔) を分けて書かせる。助 ⾔をどうするかは PR を書いた⼈が決める。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18
  19. 付録 A3 ⽤語 ⽤語 AI の確かめ レビュー役 ⽌める指摘 助⾔ 戻せない選択

    振り返り 意味 モデルが意味を⾒る 確かめ (AI のレビュー) 観点を 1 つに絞った カスタムエージェント その PR で直す指摘 (直すまで merge しない) 扱いを PR を書いた⼈が 決める指摘 あとで変えられない 決め (one-way door) 直しの履歴を⾒て、打ち切る、 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 戻す、簡単にする ⽤語 サブエージェント 取りまとめ役 description resources permissions deny 意味 ⾃分の⽂脈で動き、答えを親に 返すエージェント レビュー役に頼み、答えを 1 つにまとめる役 名前で頼まないとき、役を 選ぶのに読まれる説明 役が初めから読むファイル 道具ごとに許す、聞く、 拒むの決まり どこに書いても、許すより強い 19
  20. 付録 A4 出典と参考 kiro.dev のブログ「Keeping a software factory stable at

    1,000 PRs a week」(2026-10-26) https://kiro.dev/blog/software-factory-stability/ Birgitta Böckeler「Harness engineering for coding agent users」(martinfowler.com、2026-04-02) https://martinfowler.com/articles/harness-engineering.html kiro.dev のドキュメント (2026-11-09 に .md 版を読んだ): Custom agents、Creating custom agents、Agent configuration reference、Invoking as sub-agents、 Agent examples、Permissions https://kiro.dev/docs/custom-agents/ 画⾯: Kiro IDE 1.4.121 (2026-11-09 に撮った)。例題は ⽬指せ Kiro マスターの会議室の予約アプリの写しで、公開していない。 例題の PR は、⽬指せ Kiro マスター 10 の Workflow が作った予約の取り消し (API とテスト) の変更。 例題の指摘の数は、この 1 回のレビューのもの。同じ頼みでも、流すたびに変わる。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20