ループエンジニアリング、やってみた— RAC

AI駆動開発【大阪支部 #14】with クラスメソッド
登壇資料

Transcript

1. ループエンジニアリング、 やってみた。 できたこと、できてないこと 安田 佳央 ／ Ryobi AlgoTech Capital EM
2. RAC | 02 はじめに ABOUT ME 安田 佳央 ／ Ryobi AlgoTech Capital EM 岡山で、両備システムズの子会社の エンジニアをやっています 趣味はマラソン。 大阪マラソンも申し込みました 今日は出張できました りくろーおじさんの チーズケーキをお土産に帰ります
3. RAC | 03 はじめに PRODUCT & TEAM こんなプロダクトを、こんな組織で作っています。 プロダクト AI×金融領域で、ノーコードの取引戦略構築プラットフ ォームを開発 チーム・進め方 PO・SMを含む5人 2025年からスクラム。AI駆動開発で全工程を AI と回している 開発の主力 Claude Code（サブスクリプション） 各自のローカルPCでの開発が主流
4. RAC | 04 はじめに AI駆動開発の中にも段階がある。 今日は、③ ハーネスエンジニアリングから④ ループエンジニアリングをやってみた、という話をします。 ④ ③ ② ① プロンプト エンジニアリング AI 活用 コンテキスト エンジニアリング ハーネス エンジニアリング AI 駆動開発（ AI 活用を内包） ループ エンジニアリング
5. RAC | 05 はじめに こんな感じで、ハーネスを整備してきました。 ローカルPC Claude Code → PR → マージ ルール層 ：基盤モデルに効く ローカル検証層 ：PR前に効く デプロイ → CI → 開発環境 → 本番環境 ・本番反映層 ：PR以降に効く ルール層 CLAUDE.md ／ skills ／ rules ／ permissions ローカル検証層 hook ／ pre-commit ／ pre-push CI・本番反映層 PR CI（自動テスト）／ dev E2E（定期実行）／ 本番反映確認 基本は、各自のセッションで skills を起動して回す。 手戻り なし 手戻り 小〜中 手戻り 大〜致命
6. はじめに Issueによって、人間の関わり方は3パターン。 パターン ① パターン ② パターン ③ 人間 AIへの委任 → 人間 ファーストワンマイル 人間 AIへの委任 → AI 初期から 委任できる 実装・検証 → AI 人間 AIへの委任 実装・検証 → → AI 実装・検証 人間 ラストワンマイル Issueの内容によって、人間が入る場所が変わる。 先に 設計判断が要る 後に 承認判断が要る RAC | 06
7. WHAT IS LOOP ENGINEERING AIが自分で仕事を見つけ、実行し、検証し、終わったら報告する。 人間が見張らなくても回る、ループそのものを設計すること。 PROMPT ENGINEERING HARNESS ENGINEERING LOOP ENGINEERING モデルに渡す仕事の説明を良くする AIが安全・再現性高く働ける環境を整える いつ繰り返し、何を根拠に止めるかを設計する
8. WHAT WE EXPECTED ハーネスを固めたから、 全部処理してくれると思っていた。
9. WHAT WE DID やってみた
10. RAC | 10 やってみた やりかた 入口は増やす。出口は1本にする。 人間 PostHog E2E 気づき・依頼・不具合報告 アプリのエラーを検知して起票 → ALL ROADS LEAD TO GitHub Issue デプロイ後の定期E2Eが赤になったら起票 入口は増やす。出口は Issue に1本化する 入口が違っても、Issueに落ちたら後は同じ処理に乗る 順番は priority 順に取るだけ 依存関係やコストの見積りはしない。賢くしない
11. RAC | 11 やってみた やりかた 大きな基盤は作らない。手元のマシンと shell で回す。 ループセッション（Claude Code / 手元のマシンで常駐） ↺ /loop で ループskills 自身を再投入。一定間隔でオーケストレーションのルールを注入して、回り続けさせる サブエージェント サブエージェント skills を起点にハーネスを処理 サブエージェント skills を起点にハーネスを処理 skills を起点にハーネスを処理 ↓ heartbeat・ログを追記 ファイル → shell のダッシュボード → 人間はここで見る 進捗を Claude Code に出力させるとトークンを食う。だから監視は shell に逃がす。
12. 実際に起きたのは、空回り。 RAC | 12 起きた問題 ハーネスを固めたから、全部処理してくれるはずだった。 Issue → AIが処理 ↓ 止まること自体は、正しい 判断が必要な地点で止まるのは、設計どおりだった → 「〜について要判断」とコメント → ループ終了 Issueがクローズされないまま、たまっていく 報告も、していた Issueのコメントに書いてあった。でも誰も読んでいない すぐに、AIが全部を判断まで持っていくのは難しそうだ。
13. RAC | 13 起きた問題 FIX AIの停止を、人間のアジェンダに変える。 01 AIが自分でラベルを付ける need-human-triage 「判断が必要」を、AI自身が機械の読める 形で申告する → 02 デイリーミーティングで リストアップされる ラベルの付いたIssueが、毎日の場に自動 で並ぶ → 03 その場で担当を割り、 人間が判断を下す 担当割りも判断もこの場で処理し、たまっ たIssueを少しずつ減らしていく コメントに書いてあるだけでは、誰にも届かない。AIが止まった地点を、人間のワー クフローの入口につないだ。
14. RAC | 14 できたこと・これから できたこと、できてないこと。 ハーネスエンジニアリングの頃と、ほぼ同じかもしれない。ただ、3パターンのうち①だけは人間の手を離れた。 パターン ① パターン ② パターン ③ への委任 → もともとAI 実装・検証 人間 ファーストワンマイル → 人間 AIへの委任 → もともとAI 実装・検証 人間 AIへの委任 → もともとAI 実装・検証 → 人間 ラストワンマイル 人間 AI ◦ できたこと ✓ パターン①が、まるごと人間の手を離れた ✓ AIが止まった地点が、人間のアジェンダに乗るようになった ✓ 修正量は、やや向上した × できてないこと ✓ まるごと人間の手を離れた 設計判断は残る 承認判断は残る 「ループを作ることが仕事」と言えるレベルには、まだ遠い ! AIが人間の判断を必要としがち 判断しなくていいことまで「要判断」で上がってくる ! PRテストをすり抜けて、E2Eでエラーになる 止められなかった分がラストワンマイルに流れてくる ! いちばんの収穫は、今の自分たちのループ・ハーネス・プロセスの限界を知れたこと。
15. 減らし方は、2方向ある。 ③ HARNESS ENGINEERING さらなるハーネスの整備 ファーストワンマイル・ラストワンマイルの対 象そのものを減らす RAC | 15 できたこと・これから ⇄ 互 い を 押 し 上 げ る ④ LOOP ENGINEERING ループエンジニアリングの 整備 人間に届く判断を本当に人間判断が必要なもの に絞る ④に来たら、③に戻る。段階は登り切るものではなく、行き来するもの。
16. Thank you 安田 佳央 ／ Ryobi AlgoTech Capital RAC（Ryobi AlgoTech Capital）の X アカウントを作成しました フォローをお願いします @RyobiAlgoTech