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

2026年10月26日(月)に実施された「エンジニアイベント🍣寿司LT - 鮮度抜群のAI駆動開発ネタ、入ってます」での発表資料です。

イベントページ：https://youtrust.jp/events/19842c39ec5348898d192b908ca0f521

登壇者：株式会社kubell 執行役員CTO　田中 佑樹

Transcript

1. レガシーコードに対する loop engineering的なAI開発プロセス導入について 株式会社kubell 執行役員CTO 田中佑樹 2026年10月26日
2. 注：まだ実践投入前の PoC的な立ち位置のお話です 期待させてしまってごめんなさい
3. 01 | 自己紹介
4. 自己紹介 名前 田中 佑樹（たなか ゆうき） 誰？ 株式会社kubell 執行役員 CTO 兼 プロダクトディビジョン 副ディビジョン長 お仕事 エンジニア組織に関する管掌。 技術的な意思決定や組織開発など。 経歴 エンジニア ⇢ EM⇢ CTO • • • • 2013年入社（現在14年目） もともとサーバーサイドやフロントエンドの エンジニアとして入社 その後、複数の部門でのEMを経験し、今に至る 現在は全社横断した技術戦略の策定、技術的な意思決定、 エンジニア組織づくりがお仕事の中心 4
5. 02 | kubell / Chatworkの紹介
6. 事業概要 • 国内最大級のビジネスチャット「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月末時点 6
7. Chatworkの状況 2011年にリリースし、15周年を迎える。それだけ巨大で、技術的負債も溜まっている。 以下、Chatworkのメインのリポジトリの状況（巨大なモノリスなシステムとなっている）。 PHP コード行数 101.7万行 （9,741ファイル） テーブル数 コミット総数 620テーブル 約10万コミット 歴史 15年8ヶ月 2011-02-15〜から現在まで 総APIエンドポイント数 528 7
8. 03 | なぜloop engineeringか？
9. Chatworkの課題 • 巨大すぎる、かつモノリスがゆえに、認知負荷がとてつもなく大きい • ビジネスチャット特有のスループットの高さなど、非機能要件も高く複雑性が高い • 複数のチームで同じリポジトリを触ることを強いられるため、コミュニケーションコスト が高い • 複雑性が大きいがゆえに、すべてを理解している人がいない（複数人での合議が必要） このような課題にずっと取り組んでいます。 この状況に対して、loop engineeringはもしかして相性がよいのでは？という仮説。 現状のリファクタリングの難易度が高く、加えてその価値が非常に高い。リファクタリングは 正解が既存挙動なので、機械で判定できる。トークンを投資して投資した分だけリファクタし てくれたら、ROI的に合いそう。 9
10. そもそもloop engineeringとは？ 人間がAIに毎回指示を出すのではなく、AIが自分で実行・検証・修正を繰り返して目標を達成 する仕組み（ループ）を設計する手法。 ※ledger（永続記録） やったことの全記録。JSONLで永続化され、暴走フラグの自動判定と評価役の判断基準となる。 10
11. 04 | やったこと
12. 今回注力したポイント 特に今回は、検証部分に特にフォーカス。この検証の部分さえ担保できていれば、loopは自律 して判断し、目的達成まで動いてくれる。 ※ledger（永続記録） やったことの全記録。JSONLで永続化され、暴走フラグの自動判定と評価役の判断基準となる。 12
13. 1チーム（5名）、4営業日で短期集中PoC 短期集中的に実施。 「AI の出力が正しいか」を人手でなく機械で判定するための部品を作成に集中。 作ったもの 詳細説明 loop engine 用意した各品質保証のチェックの体制と、ゴールまで自走して例外時のみ人間のフォールバックする、loop全体 を監視する仕組み。 テスト環境用のDBスナップ ショット 現状、テストに対して1種類のseedのみだが、状態パターンに応じての全テストデータを用意。 かつ、AIが使いやすく、生成しやすいようなseederを生成。（DBを直接見なくてもテストパターンが把握でき るようなデータ群） リファクタリングのガード レール APIベースで、外側からみた挙動が変わってないことを保証するe2eテスト群。 修正したあとに実行することで、挙動の変化があったかどうかを検知するための仕組み。 レガシー層の外側から挙動を固定した。 性能ガードレール 内部挙動が変更されたことにより、性能が後退していないかをチェックするための仕組み。 修正した範囲でのSQLクエリプロファイリングを実施。 Open APIの整備 レガシーなAPIの全IOをOpenAPIベースにて定義。各e2eの整備等でAIに情報を渡すためのSpecとして使用。 BDDベースのユースケース別 テストシナリオ作成の環境 GherkinにてWebUIのe2eテスト環境の整備。ユースケースごとにテストシナリオを用意。 13
14. 実証できたこと • ためしに、運用改善のバックログの無作為なチケットを5件テスト実行 • 結果、機械的な差し戻しは0件、全体がマージできるレベルのPRの生成までできた • また、後日、別メンバーが同じチケットに対して「このチケットで作って」と指示 → 変更ファイルは完全同一、中心方針も一致 結論：いけそうな手応えは感じられた 14
15. 今後の課題 • このPRをマージしていいかどうかの判断 ◦ • 人間がこれをマージした時に、どう責任を取るか？という設計 チーム展開 ◦ 開発プロセスのAI導入でもっとも難しいのはチーム展開 ◦ 特に私たちのようなモノリスなシステムでは、様々なチームが同じリポジトリを 触っている ◦ この状況のとき、技術的な難しさよりも組織的な行動の難しさのほうが上回る ◦ トップダウン的なアプローチでないと時間がかかる これらを、どうしよう？というのが今後の課題。 ここをクリアできると、かなり早く開発プロセスが回せそうというのは掴み取れた。 15
16. その他、やったこと • トークンを多く消費するため、トークンマネジメントの考え方も整備 • 各タスクに対して適切なモデルを使用することでトークンを節約 • ◦ Fable：基本は使ってない（はじめのループの計画の時と評価器に使用） ◦ Opus：loopの監視 ◦ Sonnet：実装・各ハーネスの動作検証 ◦ Haiku：より単純なタスクの場合 これらを評価するための評価器を作成 ◦ どれだけハルシネーションを起こしたかを計測 ◦ ツールの使用ログ、セッションログ、プロンプトに対しての最終的な指示内容を評 価（これはFableにて評価、記録・評価の流れをSkill化） • 基本はHaikuで試し、性能が悪ければSonnetを採用 • 結果、ほぼ品質は変わらずにトークンコストが約1/4程度に（実測値-76％） 16
17. 05 | まとめ
18. まとめ • loop engineeringのプロセス整備により、実践で使えそうな感覚は掴み取れた • 同時に課題も見えた ◦ 人間の説明責任の取り方（ちゃんとPRレビューしよう以外のアプローチの模索） ◦ チームへの浸透（技術的な課題よりも、組織的な課題） 18
19. 働くをもっと楽しく、創造的に