レガシーコードに対する loop engineering的なAI開発プロセス導入について

2026年11月4日(水)に実施された「AI駆動開発のループに人はどう関わるか ― 開発フローに落とし込んだ3社の現在地 ―」での発表資料です。
イベントページ：https://algomatic.connpass.com/event/406439/
登壇者：株式会社kubell 執行役員CTO 田中佑樹

Transcript

1. レガシーコードに対する loop engineering的なAI開発プロセス導入について AI駆動開発のループに人はどう関わるか ― 開発フローに落とし込んだ3社の現在地 ― 株式会社kubell 執行役員CTO 田中佑樹 2026年11月4日
2. 01 | 自己紹介
3. 自己紹介 名前 田中 佑樹（たなか ゆうき） 誰？ 株式会社kubell 執行役員 CTO 兼 プロダクトディビジョン 副ディビジョン長 お仕事 エンジニア組織に関する管掌。 技術的な意思決定や組織開発など。 経歴 エンジニア ⇢ EM⇢ CTO • • • • 2013年入社（現在14年目） もともとサーバーサイドやフロントエンドの エンジニアとして入社 その後、複数の部門でのEMを経験し、今に至る 現在は全社横断した技術戦略の策定、技術的な意思決定、 エンジニア組織づくりがお仕事の中心 3
4. 02 | kubell / Chatworkの紹介
5. 事業概要 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は100.3万社*2を突破 • 圧倒的な顧客基盤のあるプラットフォームを背景に、チャット経由で業務を請け負いDXを推進するBPaaS「タクシタ」を展開 ビジネスチャット「Chatwork」 BPaaS「タクシタ」 チャット経由で業務を請け負いDXを推進 業務代行 • 国内利用者数No.1*1 有料ユーザーの97%が中小企業ユーザー • 日本の1/5を占める導入社数100.3万社以上*2 823万ユーザー • 全業界・全職種の方が日常的に使うプラットフォーム AI・SaaSを徹底活用 経理・会計 採用 労務 営業事務 経理・総務・事務な ど幅広い業務に対応 人事・労務など専門 性の高い業務に対応 *1 Nielsen NetView Customized Report 2025年7月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKSを含む44サービスを株式会社kubellにて選定。 *2 2026年6月末時点 5
6. Chatworkの状況 2011年のリリースから15周年を迎え、そのぶん巨大になり、技術的負債も溜まっている。 以下はChatworkのメインのリポジトリ（巨大なモノリス）の状況。 PHP コード行数 101.7万行 （9,741ファイル） テーブル数 コミット総数 620テーブル 約10万コミット 歴史 15年8ヶ月 2011-02-15から現在まで 総APIエンドポイント数 528 6
7. 03 | なぜloop engineeringか？
8. Chatworkの課題 • 巨大で、しかもモノリスであるため、認知負荷がとてつもなく大きい • ビジネスチャット特有の高いスループットなど、非機能要件の水準が高く複雑 • 複数のチームが同じリポジトリを触らざるを得ず、コミュニケーションコストが高い • 複雑なため、すべてを理解している人がいない（複数人での合議が必要） このような課題にずっと取り組んでいる。プロダクトのロードマップの達成の他にも、リファ クタリングやモノリスの解消にも取り組んでいく必要があり、AIを用いて一人ひとりの生産性 を劇的に向上させていきたい。 その一つの取り組みがloop engineering。 8
9. そもそもloop engineeringとは？ 人間がAIに毎回指示を出すのではなく、AIが自分で実行・検証・修正を繰り返して目標を達成 する仕組み（ループ）を設計する手法。 完了の判定がテストなどで自動化され、人が離れても進むものをループと呼ぶ。 AI 1. タスク指示 設計 実装  人間 レビュー 2. 判断を仰ぐ  ハーネスに準拠 図：ループエンジニアリング 9
10. 04 | 各チームの取り組み
11. 今日紹介する事例 全チームにおいて開発プロセスのAI化、それに伴うloop化を取り組んでいる状況。 本日は4つのチームの事例を紹介。 事例 チーム名 対象 状況 Chatwork本体 サーバーサイドチーム PHPモノリス（101.7万行） のリファクタリング 検証の仕組みを作り、PoCを実施 Androidアプリ Androidチーム View→Jetpack Composeへ の画面移行 人の確認待ちで止まるループを回 している API Gateway層 Facade（ファサード）チーム GraphQL APIへの移行PJ レビューの負荷を下げる仕組みの 導入 認証サービス 認証チーム 認証チームの開発チケット全 般 判断まで任せて、チケット消化数 が伸びた それぞれのチームにより状況も違えばプロセスも異なる。そのため、各チームで取り組んでい る内容と各チームごとのAIの成熟度も異なる。今回はそれぞれのチームの現在地点の紹介。 11
12. 事例1: Chatworkサーバーサイドの事例
13. 事例1: 作ったもの 1チーム（5名）、4営業日の短期集中でPoCを実施した。 「AIの出力が正しいか」を、人手でなく機械で判定するための部品づくりに集中した。 作ったもの 詳細説明 ループエンジン 用意した品質チェックを使ってゴールまで自走し、例外のときだけ人に引き継ぐよう、ループ全体を監視する仕 組み。 テスト環境用のDBスナップ ショット これまでテスト用のseedは1種類だけだったが、状態のパターンごとにテストデータを用意した。 あわせて、AIが使いやすく生成しやすいseederを作った（DBを直接見なくてもテストのパターンを把握できる データ群）。 リファクタリングのガード レール 外側から見たAPIの挙動が変わっていないことを保証するE2Eテスト群。 修正後に実行し、挙動が変わったかを検知する。 レガシーな層の外側から挙動を固定した。 性能ガードレール 内部の挙動を変えたことで、性能が落ちていないかをチェックする仕組み。 修正した範囲のSQLクエリをプロファイリングする。 Open APIの整備 レガシーなAPIの入出力をすべてOpenAPIで定義。E2Eテストの整備などで、AIに渡す仕様書として使う。 ユースケース別のテストシナ リオ環境（BDD） GherkinでWeb UIのE2Eテスト環境を整備。ユースケースごとにテストシナリオを用意。 13
14. 事例1: 実証できたこと • ためしに、運用改善のバックログから無作為に選んだチケット5件で実行した • 機械的な差し戻しは0件で、全体がマージできる水準のPRまで作れた • 後日、別のメンバーが同じチケットで「このチケットで作って」と指示すると、変更ファ イルは完全に同じで、中心の方針も一致した • あわせて、タスクごとにモデルを使い分け、品質をほぼ変えずにトークンコストを約1/4 にした 結論：いけそうな手応えは感じられた。 ただし、まだ自動マージまで任せきるには至っていない。 14
15. 事例2: Androidチームの事例
16. 事例2: Androidチームの紹介 ChatworkのAndroidアプリケーションの改善・保守運用を担当するチーム。 現在、全View層のJetpack Compose化を進めている。 16
17. 事例2: Androidチームの事例 View→Jetpack Composeの画面移行を対応中。担当者が画面を機能ごとにAIへ渡し、AIは Draft PRとCI対応まで進めて、人の確認待ちで止まる仕組みを整備。 仕組み 内容 正解の決め方 移行前の画面を正解とするスクリーンショット比較。 事例1と同じ「既存挙動が正解」という考え方に基づいて判断。 AIが動ける範囲 Jiraに設けたAI専用の列（AI To Do〜確認待ち）。確認待ちで止まり、人の判定はJiraのス テータスの変更として残るように整備。 ガードレール git add -A、強制push、draftでないPRの作成など7つの操作を、hook（決まった時点で自動 で動く仕組み）で機械的に止める。 検証 書いたAIとは別のエージェントが、差分の中のバグ・差分の外の古い記述・要件とPR本文の3 つに分けてレビューする仕組み。 止まる条件 検証は最大5周、CI対応は最大3回。上限に達したら確認待ちに置いて報告し人間が判断。 17
18. 事例2: 実績と広げ方 AI専用の列を通ったチケット数（月別） • AIに任せるチケット数は、月ごとに増加傾向 ◦ 37件 40件 • これに応じてマージ数も増加 ループを回している担当エンジニアは3名 ◦ ループの作り方は各自で異なる ◦ 「確認待ちに渡す」「Draft PRのあとで人が 判定する」の2点だけはルールとして固定 19件 • 各自の工夫はスキルカタログで配る ◦ 23の部品を「こんなときに使う」の目安つき で載せている 8月 9月 10月 （※月中の数値） ◦ ループが上限で止まると、症状に合う部品が 候補として出てくる 18
19. 事例3: Facadeチームの事例
20. 事例3: Facade（ファサード）チームの紹介 Chatworkのクライアントとサーバーサイドの仲介役。いわゆるAPI Gateway層。 クライアントたちにとっての窓口（Facade）の役割を持ち、GraphQLサーバーとして動いて いる。現在、既存APIからこちらのAPIに移行を段階的に進めている最中。 20
21. 事例3: レビュー負荷削減のために実施している施策一例 AIが書くPRを、人が読み切れる大きさに抑える仕組みを導入 • ReviewDebtスコア（PRのレビュー負荷の点数）の可視化 • ReviewDebtに合わせてPRを分割 • 13体のAIエージェントが並列レビュー 21
22. 事例3: ReviewDebtスコアでレビュー負荷を可視化 ReviewDebtスコア（PRのレビュー負荷の点数） • CIがPRごとにレビュー負荷を0〜100点で計算し、PRコメントに書き出す • eBayが公開しているReviewDebtの考え方のもと、チーム独自で設計（変更行数等） OKの例 NGの例 22
23. 事例3: ReviewDebtスコアに合わせてPRを分割 ReviewDebtスコアに合わせてPR分割 スコアの帯（PR コメントに表示） • AI 自身に、1 PR が 50 点未満に収まるよう変更 0〜24 点 レビュー負荷がとても低い を分けさせる • 50点以上であれば、根拠の提示またはPR分割と 25〜49 点 中程度のレビュー負荷 いうルールをチームに持たせる • レビュー負荷を少しでも軽減できるように仕組 50〜74 点 作者に根拠の提供を求める み化 75〜100 点 PR の分割か、詳しい文脈の 提供を求める 23
24. 事例3: ReviewDebt スコアに合わせてPRを分割 | 成果 1 PR あたりの変更行数が激減 PR Ready → マージ まで 所要時間が短縮 24
25. 事例3: 観点ごとに独立したエージェントがレビューする仕組み化 レビュー自体もできるだけAIに委譲。複数観点からのレビューにより多角的なレビューを自動 的に実施。その結果を人間でみて最終確認。 観点エージェント 13 体（並列に起動） 本番影響・波及 リグレッション コードの正確さ 複雑さ・責務 公開 I/F の設計 コメントの品質 エラー処理・ログ N+1・性能 設計 既存API の規約 起点 /pr-review SKILL化したレビュープ ロセスをチーム内で共通 的なプロセスとして実施 できるように仕組み化 → スキーマの一貫性 機能公開の判定 集約 → 選別してレビュー結果 を投稿 既知の指摘パターンをナレッジ化・独自の知識でのレビュー 25
26. 事例3: 観点ごとに独立したエージェントがレビューする仕組み化 GitHub Actions の結果ページに実行サマリーを掲示 • ブラックボックス化しやすい GitHub Actions 上 での Claude Code の挙動を可視化、蓄積 • 上手く動いていないことがあれば AI / 人間が サマリーを読んでプロンプトを調整 人間が行ったレビューを収集、自動でプロンプト改善 • 人間のレビューを収集 → 観点に分類 → プロンプトを自動改善するワークフローを 毎晩自動で実行 • 開発を進めれば進めるほど AI レビューが賢くなる 仕掛けをシステムとして実装 26
27. 事例4: 認証チームの事例
28. 事例4: 認証チームの紹介 認証チームはChatworkの認証認可と、メインで利用しているIDaaSのAuth0の活用・運用を担 当しているチーム。今後の認証認可基盤をChatworkから切り出し、独立した認証基盤にする ことを目指す。 28
29. 事例4: 認証チームの事例 認証チームでの開発プロセス改善の施策まとめ。チケットの消化数は、人の役割が変わったと きに伸びた。自動実行を入れても人の役割が同じだったD期は、横ばいだった。 期 人の役割 主な施策 人がやること チケットの消化数 A — AI導入前 — — B 実装の依頼とテスト 各自がClaude Codeを使 う。モブプログラミングで AIに書かせる 計画を立てる、テストシナリオ （Gherkin）を書く、実装を頼む、テ ストする、PRをレビューする C 計画の承認と成果物 のレビュー 知識ベース、チームのプラ グイン、テスト実施の自動 化 チケット処理のコマンドを呼ぶ、計画 を承認する、テストシナリオをレ ビューする、PRをレビューする D 計画の承認と成果物 のレビュー チケットを人の操作なしで 進める自動実行 自動実行に回す、計画を承認する、テ ストシナリオをレビューする、PRを レビューする E 完了条件の定義と結 果の品質判断 別のAIによる審査、レ ビュー結果とテスト結果の レポート 完了条件とWhyを決める、自動実行に 回す、レポートを見て問題がなければ リリースする （ほぼ同じ） （あがった） （ほぼ同じ） （大幅にあがった） 29
30. 事例4: どんな改善を重ねてきたか 一人あたりの PR と変更行数の推移に、主な改善を重ねる ① 2025年8月 コマンドの共有 ② 2025年10月 プラグイン化 ③ 2026年1月 知識ベースを作る ④ 2026年4月 テストの自動化 ⑤ 2026年5月 自動実行の基盤 ⑥ 2026年7月 別のエージェントによるレビュー ⑦ 2026年8月 「AI自走レーン」 ⑧ 2026年9月〜 判断を助ける仕組み PR が大きく伸びたのは、人の手を離して任せてから 30
31. 事例4: 自動実行と審査の効果 自動実行を入れただけでは伸びず、マージの手前までAIに任せてから消化数が伸びた。 • • 自動実行を入れた直後（D期） ◦ 人が張り付かなくても、チケットが進むようになった ◦ ただ、うまくいく割合が低く、結果の確認に人の手がかかった マージの手前までAIに任せた後（E期） ◦ 別のAIエージェントが審査し、レビュー結果とテスト結果をレポートにまとめる ◦ 人はレポートを見て、問題がなければリリースする ◦ ここで、1人あたりの消化数が劇的に伸びた 31
32. 05 | 学んだこと
33. ループの成立には、完了判定の自動化が重要 要するに、AIに判断（レビュー等）まで任せられるか。これができるかできないかでスルー プットは大きく異なる。AIが確かめて直すところまで任せても、完了を人が決めているうち は、人が離れると止まる。完了の判定をテストなどで自動化して、はじめてループになる。 回し方 確かめるのは 完了を決めるのは 人が席を外すと ①人が回す 人が読む 人 止まる ②確認の手順をAIに渡す AI（テストや手順をAIが走ら せる） 人（AIの「できました」を受け入 れるか判断する） 止まる ③ループ テストや、作業役とは別の評 価役 テストの結果（人が先に書いた完 了の条件） 条件を満たすか、人に回すと ころまで進む ここの投資が重要 33
34. テストとルールはチームで揃え、ループの回し方は個人に任せる テストやルールはリポジトリに置けば、誰がどの回し方を使っても同じものを使える。 ループの回し方は、Claude Codeの /goal やチームで自作した自動実行など選択肢が多く、入 れ替わりも早い。作業の仕方も人によって違うので、揃えない。 層 役割 裁量 品質ハーネス AIの出力を客観的に確かめる （テスト・静的解析・型チェックなど） チームで揃える ガイドライン ループが参照するルールや手順 （確かめ方、禁止事項、触ってはいけないもの） チームで揃える ループエンジン ループの回し方そのもの （止める、記憶を保つ、人に引き継ぐ） 個人の自由 品質の基準 = 結果の基準 仕事の進め方 = 道具（How）の選択 （これはチームで揃えるもの） （これは個人の自由） 34
35. 06 | まとめ
36. まとめ • AIに書かせるだけでは、開発速度は劇的に速くはならない ◦ チケットの消化数が伸びたのは、確かめる仕組みを入れて、ループに任せ切ってか ら • チームで揃えるのは「品質の基準」で、回し方は個人に任せる ◦ 品質ハーネスとガイドラインをチームで揃え、ループエンジン（ループの回し方） は自由にする • 次の課題は人の判断をどうスケールさせるか ◦ 自動マージまでの委譲など、AIに任せられる範囲をさらに広げてスループット向上 を狙う ◦ そのための品質保証の仕組みも強化していく 36
37. 働くをもっと楽しく、創造的に