AI Coding Agent Enablement - エージェントを自走させよう

by Yuku Kotani

Slide 1

Slide 1 text

AI Coding Agent Enablement ~エージェントをさせよう~ 自走 @yukukotani 2025/04/08 - AI Coding Meetup #1

Slide 2

Slide 2 text

自己紹介 Yuku Kotani VP of Technology @ Ubie, Inc. @yukukotani @yukukotani

Slide 3

Slide 3 text

今日の趣旨コーディングエージェントをイネーブリングして自走させたい！ベースとなる考え方と、具体的なアプローチを紹介します

Slide 4

Slide 4 text

自走ってなんだろう？

Slide 5

Slide 5 text

自走 = Human-in-the-Loop をなるべくやらない Copilot時代はスニペット単位でHuman-in-the-Loopを回していた Agent時代にはできるだけ自律的に判断させて1ループの作業単位を大きくしたい

Slide 6

Slide 6 text

auto-run (Yolo) mode で自走完了ではない auto-run は検証をスキップしてくれる機能であって、本質的に必要な検証を行ってくれる機能ではない

Slide 7

Slide 7 text

デフォルトの解空間は大きすぎるデフォルトでは「文法に適合するコード(=パーサー検証)」程度の制約しかなく、極めて広い解空間でエージェントが動く → 精度が低い解空間生成対象の言語のSyntax全体

Slide 8

Slide 8 text

基本方針：可能な限り解空間を絞る会社・プロジェクト固有の解空間は本来もっと狭いはず解空間会社・プロジェクト固有の  アーキテクチャ・規約・デザインなど

Slide 9

Slide 9 text

どうやって？

Slide 10

Slide 10 text

(1) 機械的検査

Slide 11

Slide 11 text

機械的検査で定義した解空間に押し戻す LLMの出力を機械的に受け入れ検査し、NGの場合はフィードバックする解空間機械的にフィードバックを与えて解空間へ押し戻す

Slide 12

Slide 12 text

古典的な静的解析・自動テストエージェントにLinterや型チェック、自動テストを実行させその結果をもとに自律改善して、passするまで勝手にルーr まずは既存Linterを使ってコーディング規約的な部分を整備するのが簡G その上でプロジェクト固有の具体的なLintルールが伸び9 Ubieの~ モジュラモノリスのモジュールを超えたDBアクセスを禁$ 特定ファイル以外でのLocalStorage読み書きを禁$ etc...

Slide 13

Slide 13 text

なぜ古典的手法？ 7 LLM-as-a-judgeのように先進的な評価手法もあるが、  コーディングエージェントへのフィードバックには銀の弾丸ではなB 7 非決定論的であり、真の意味で”保証”できなB 7 実行速度が遅く、エージェントのPDCAのボトルネックになる → 古典的な静的解析・自動テストが有効

Slide 14

Slide 14 text

古典的手法でもやり方はアップデートできそう PRレビュー内容からLintルールを自動作成して漸進的に育てR PdMやQAEとの協働したテストファースト実装 w/ コーディングエージェン0 etc...

Slide 15

Slide 15 text

参考(ちょっと古い) https://zenn.dev/ubie_dev/articles/7bade4112054c8

Slide 16

Slide 16 text

(2) コンテキスト注入

Slide 17

Slide 17 text

解空間の定義をLLMに与える何らかの方法でLLMに「解空間の定義」を与える代表的には Cursor Rules / Cline Rules など解空間会社・プロジェクト固有の  アーキテクチャ・規約・デザインなど

Slide 18

Slide 18 text

例：デザインシステム(Ubie Vitals)のMCP化ユーザーはFigmaのURLを入力する

Slide 19

Slide 19 text

例：デザインシステム(Ubie Vitals)のMCP化 Figma MCP でデザインデータを取得 Ubie Vitals MCP で必要なコンポーネント、トークンを取得

Slide 20

Slide 20 text

例：デザインシステム(Ubie Vitals)のMCP化デザインシステムの資産を参照して完成度の高い実装ができる MCP実装は超ナイーブで、コンポーネント実装(Reactコード)を返すだけ

Slide 21

Slide 21 text

参考 https://zenn.dev/ubie_dev/articles/f927aaff02d618

Slide 22

Slide 22 text

なんでMCP？ Rulesじゃダメ？ u MCPとRulesの違 u MCPはオンデマンドに情報を取ってきてコンテキストに入れ2 u Rulesは事前にすべての情報をコンテキストに入れてお0 u Figma MCPは動的な外部リソースをフェッチするのでMCPがマッチす2 u Ubie Vitals MCPは静的コンテンツなので本質的にはRulesで良いはず

Slide 23

Slide 23 text

なんでMCP？ Rulesじゃダメ？ C 単に現行モデルやエージェントの性能特性として、MCPの方がうまくいったので  Ubie VitalsではMCPを使ってい C 事前に全てをRulesに入れるとぼやけてしまい、使ってほしい情報を使わなかっ C ただし、ロングコンテキストの性能改善が著しいので、近いうちにこういうMCP の使い方はなくなるかもともかく、コンテキストへの入力方法は瑣末な問題で、入力するに値する情報（ドキュメント、デザインシステム、etc...）の整備が重要

Slide 24

Slide 24 text

ところで開発の”loop”ってコーディングだけ？

Slide 25

Slide 25 text

DevOps全部やってほしい！

Slide 26

Slide 26 text

DevOps全部やってほしい！

Slide 27

Slide 27 text

CursorにPdM機能も持たせる次のようなデータソースを MCP or CLI で繋げB ユーザーログ、メトリクス (BigQuery, Lightdash 事業戦略、OKR (Notion チケット (Jira Why/Whatの探索からAC設定まで壁打e 最後に「じゃあこれで」と実装開始

Slide 28

Slide 28 text

参考 https://note.com/guchey/n/n773a2efd78cf

Slide 29

Slide 29 text

DevOps全部やってほしい！メトリクスから次のPBIへの示唆を自動的に抽出ユーザーログなど参考に探索的テストシステムメトリクス、ユーザーログなどから問題検出して切り戻しまだやれてないことが無限に

Slide 30

Slide 30 text

まとめ ' エージェントを自走させるためにはEnablingが必3 ' ジュニアエンジニアのアナロジーで課題を拾いやす@ ' ソリューションは古典的手法を活かしつつも、  人間ではなくLLMの特性からゼロベースで考えU ' そしてコーディングエージェントからフルサイクル開発エージェントへ

Slide 31

Slide 31 text

ありがとうございました