成果物の確認は手放さない、でも楽はしたい。

AI自走軸じゃない人間の認知負荷から考えるloop設計。AIに成果物のチェックは任せない、その上で実践している、loop の取り組みを PR レビュー の取り組みを例にLT

1. 成果物の確認は⼿放さない（in the loop でも楽はしたい（on the loop ── AI⾃⾛軸じゃない、⼈間の認知負荷から考えるloop 設計 ⼭⽥ 智博 ∕ CTO室 開発推進エンジニア 2026.08.31 © Findy Inc. 1
2. ⾃⼰紹介と、本⽇のお話 ⼭⽥ 智博 ファインディ株式会社 CTO室 開発推進エンジニア ファインディ の カンファレンスサービスの開発チームで、フルスタックの開発に従事。 あわせて、チームの AI 推進役を担っています。 本⽇のお話 AIに成果物のチェックは任せない、 その上で実践している、loop の取り組みを PR レビュー の取り組みを例に発表します © Findy Inc. 2
3. （まずはじめに）私は成果物には絶対に⽬を通したい 「エラー消しといて」とお願いすると、「消しました！」と元気よくプログラムごと削除します。 あと結果に責任を取ってくれないから成果物には、当然ながら⽬を通したい。 「エラー消しといて」 「消しました！」 ▶ loop を適切に設計するには AIは責任とれないので、AI成果物のチェックを任せない事を前提に考えてます。 © Findy Inc. 19
4. その上で in the loop と on the loop を以下の区別で取り組んでます loopエンジニアリングを意識してやっていることは、承認する⼈間の認知負荷削減と、承認するべき成果物の可能な限りの⾃動化です。 ⼈介在のチェックポイントを減らす思考より、チェックポイントの認知負荷を下げる取り組みを第⼀に考えてます。 ⼈間が確認するところの設計（in the loop） ⾃動化するところの設計（on the loop） 成果物の確認は妥協しない 徹底的に⾃動化する － 成果物は基本的に、⼈が⾒る（※品質は下げない） － 成果物は基本的にAIに作らせる － ⼈の認知負荷を徹底的に下げる取り組みを頑張る － AIが良い成果物を出してくれるよう頑張る © Findy Inc. 3
5. コードレビューに、この in the loop と on the loop の取り組みを当てはめると、、 CI上のレビューでこの 3 つを徹底してます in the loop 側 ①無駄を省く②認知負荷減らし⼈の認知負荷を下げる。on the loop 側 ③⼿作業減らして楽をします。 ① 無駄を省く ② 認知負荷を減らす ③ ⼿作業を無くす トリーアージ：PRの分類、実影響がないも 要約：PRの認知負荷を下げる。AI が要約 ⾃動化：PRの動作検証をAI にやってもらう のを選別し、⼈レビューを任意にする し、判定し、レビューもする ▶ 具体、①②③ 何してる？ © Findy Inc. 4
6. ① 無駄を省く トリアージ ... レビュー不要なものはレビュー不要にする ここは認知負荷を減らすことが⽬的ではなく、明らかに冗⻑、儀式的な作業を排除するための⼯程です。具体として以下 実影響がないもの 実影響があるもの レビューは任意 レビューは絶対に⼊れる － docs、コメント、フォーマット、テスト追加だけ － ロジック変更、新しい画⾯、機能、リファクタ、etc ... － ただし、AI の⼀次レビューは必ず通す － 判断がつかないものも含め、基本レビューする － 低リスク判定かつ指摘ゼロなら、そのままマージ ここのとりあえずトリアージは出来るだけレビュー負荷を減らしたいマインドで⾏うのではなく、 全てにクロスチェックは不要という前提で、複眼を設ける必要がない儀式的な作業を減らすという匙加減。（間違えると品質影響が出る） © Findy Inc. 5
7. ② 認知負荷を減らす 次に要約と⼀次レビュ ... ⼈の認知負荷と⼿間を下げる 出てきた成果物を「チェックする」ための仕組みとしてCI 上にこれだけ仕掛けています。成果物の確認は譲りません、でも楽をしたいを叶えます。 01 PR 要約を書かせる issue と差分から AI が書く。⼈の認知負荷を徹底して下げる 02 リスク度を判定させる 作業の性質から AI が判定する。1 万円の稟議か、1 億円の稟議か 03 AI に⼀次レビューさせる ⾃分たちの規約を読ませたうえで、AI が⼀次レビューする 04 AI に⾃動 QA させる ラベル 1 つで環境が⽴ち、AI が画⾯を触ってスクショまで返す 05 ⼈の⼆次レビュー 要件‧設計‧意図に沿うか、最終チェック。ここだけは、⼈が⾒る © Findy Inc. 6
8. ③ ⼿作業を無くす 次に動作検証 ... ⼤変ですよね PRの作者も、実際の挙動を確認することもあるレビュアーも、動作検証に⾼いコストを払っています。 01 PR を⽤意する 02 環境を⽴ち上げる 03 操作して検証する 04 スクショを貼る ▶ ここが on the loop 技術や仕組みで解決すべきポイント © Findy Inc. 7
9. ラベル 1 つで動作環境が⽴ち上がり、AI がスクショまでを実装 仕組み PR Openをフックに github Codespaces で環境⽴ち上げ ▶ Playwright で操作させ ▶ スクショを残し ▶ GitHub のコメントに返す。 ⼈はそれをみて動作検証結果を担保。約10分、コスト100円未満 AIにやらせていることはシンプルに3 つだけ － 検証項⽬を認識 ── PR 要約から、QA項⽬をAIが認識する － 操作し結果を判断する ── OK/NG/検証不可の判定をする。 － 証跡を残す ── スクショも残す（鵜呑みにしない） ▶ Codespacesは 環境のorgスコープとコストの使い勝⼿からの技術選定 © Findy Inc. 8
10. loop を回すために、AIの認知負荷も下げるのが⼤事 1 PR ＝ 最⼩単位の TDD（テスト + 実装、層ごと）。このPR単位だからAI に渡せて品質の良いQAが出来てます。（モデルは Haiku） 検証項⽬が 5 件に収まる どこを触れば確かめたことになるか、 決められない ▶ loop を適切に設計するには AIの作業単位を伸ばすことだけでなく、⼈の認知負荷にAI設計が⼤事。 © Findy Inc. 9
11. TAKEAWAY 作業単位を⼩さくするほど、 ⼈間の認知負荷も⼩さくなる。 繰り返している作業は、常に AI に代替できないかを検討する。 タスクのコンテキストを最⼩化して、1 つの作⽤を単純にすることを徹底する。 loop 設計の軸は品質を下げないことを前提に、認知負荷を下げること。 © Findy Inc. 10