Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI Coding Agent Enablement - エージェントを自走させよう
Search
Yuku Kotani
April 08, 2025
Programming
14
7.7k
AI Coding Agent Enablement - エージェントを自走させよう
AI Coding Meetup #1
https://layerx.connpass.com/event/347094/
https://youtu.be/Q783txBWcOM?t=1339
Yuku Kotani
April 08, 2025
Tweet
Share
More Decks by Yuku Kotani
See All by Yuku Kotani
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
5
1.6k
Scale out your Claude Code ~自社専用Agentで10xする開発プロセス~
yukukotani
9
3.2k
AI Coding Agent Enablement in TypeScript
yukukotani
20
12k
Expoによるアプリ開発の現在地とReact Server Componentsが切り開く未来
yukukotani
3
600
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
870
僕が思い描くTypeScriptの未来を勝手に先取りする
yukukotani
12
3.3k
Web技術を駆使してユーザーの画面を「録画」する
yukukotani
14
7.8k
Capacitor製のWebViewアプリからReact Native製のハイブリッドアプリへ
yukukotani
5
1.7k
Real World Type Puzzle and Code Generation
yukukotani
4
960
Other Decks in Programming
See All in Programming
The Past, Present, and Future of Enterprise Java with ASF in the Middle
ivargrimstad
0
400
「社内LT会」を1年続けてみた! / Our Year-Long Journey of Internal Lightning Talks
mackey0225
1
110
Things You Thought You Didn’t Need To Care About That Have a Big Impact On Your Job
hollycummins
0
180
メモリ不足との戦い〜大量データを扱うアプリでの実践例〜
kwzr
1
360
Playwrightはどのようにクロスブラウザをサポートしているのか
yotahada3
7
2k
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
570
Local Peer-to-Peer APIはどのように使われていくのか?
hal_spidernight
2
330
CSC509 Lecture 01
javiergs
PRO
1
420
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
a_okui
0
180
まだ世にないサービスをAIと創る話 〜 失敗から学ぶフルスタック開発への挑戦 〜
katayamatg
0
140
クラシルを支える技術と組織
rakutek
0
140
Can AI Take Over Frontend QA? - Navigating the Paradigm Shift: A Developer's Mindset for the Future - #layerx_frontend
teyamagu
PRO
6
2k
Featured
See All Featured
Building Applications with DynamoDB
mza
96
6.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Faster Mobile Websites
deanohume
310
31k
Visualization
eitanlees
148
16k
Navigating Team Friction
lara
189
15k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
600
It's Worth the Effort
3n
187
28k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Designing Experiences People Love
moore
142
24k
Transcript
AI Coding Agent Enablement ~エージェントを させよう~ 自走 @yukukotani 2025/04/08 -
AI Coding Meetup #1
自己紹介 Yuku Kotani VP of Technology @ Ubie, Inc. @yukukotani
@yukukotani
今日の趣旨 コーディングエージェントをイネーブリングして自走させたい! ベースとなる考え方と、具体的なアプローチを紹介します
自走ってなんだろう?
自走 = Human-in-the-Loop をなるべくやらない Copilot時代はスニペット単位でHuman-in-the-Loopを回していた Agent時代にはできるだけ自律的に判断させて1ループの作業単位を大きくしたい
auto-run (Yolo) mode で自走完了ではない auto-run は検証をスキップしてくれる機能であって、 本質的に必要な検証を行ってくれる機能ではない
デフォルトの解空間は大きすぎる デフォルトでは「文法に適合するコード(=パーサー検証)」程度の制約しかなく、 極めて広い解空間でエージェントが動く → 精度が低い 解空間 生成対象の言語のSyntax全体
基本方針:可能な限り解空間を絞る 会社・プロジェクト固有の解空間は本来もっと狭いはず 解空間 会社・プロジェクト固有の アーキテクチャ・規約・デザインなど
どうやって?
(1) 機械的検査
機械的検査で定義した解空間に押し戻す LLMの出力を機械的に受け入れ検査し、NGの場合はフィードバックする 解空間 機械的にフィードバックを与えて 解空間へ押し戻す
古典的な静的解析・自動テスト エージェントにLinterや型チェック、自動テストを実行させ その結果をもとに自律改善して、passするまで勝手にルーr まずは既存Linterを使ってコーディング規約的な部分を整備するのが簡G その上でプロジェクト固有の具体的なLintルールが伸び9
Ubieの~ モジュラモノリスのモジュールを超えたDBアクセスを禁$ 特定ファイル以外でのLocalStorage読み書きを禁$ etc...
なぜ古典的手法? 7 LLM-as-a-judgeのように先進的な評価手法もあるが、 コーディングエージェントへのフィードバックには銀の弾丸ではなB 7 非決定論的であり、真の意味で”保証”できなB 7 実行速度が遅く、エージェントのPDCAのボトルネックになる → 古典的な静的解析・自動テストが有効
古典的手法でもやり方はアップデートできそう PRレビュー内容からLintルールを自動作成して漸進的に育てR PdMやQAEとの協働したテストファースト実装 w/ コーディングエージェン0 etc...
参考(ちょっと古い) https://zenn.dev/ubie_dev/articles/7bade4112054c8
(2) コンテキスト注入
解空間の定義をLLMに与える 何らかの方法でLLMに「解空間の定義」を与える 代表的には Cursor Rules / Cline Rules など 解空間
会社・プロジェクト固有の アーキテクチャ・規約・デザインなど
例:デザインシステム(Ubie Vitals)のMCP化 ユーザーはFigmaのURLを入力する
例:デザインシステム(Ubie Vitals)のMCP化 Figma MCP でデザインデータを取得 Ubie Vitals MCP で必要なコンポーネント、トークンを取得
例:デザインシステム(Ubie Vitals)のMCP化 デザインシステムの資産を参照して 完成度の高い実装ができる MCP実装は超ナイーブで、 コンポーネント実装(Reactコード)を返すだけ
参考 https://zenn.dev/ubie_dev/articles/f927aaff02d618
なんでMCP? Rulesじゃダメ? u MCPとRulesの違 u MCPはオンデマンドに情報を取ってきてコンテキストに入れ2 u Rulesは事前にすべての情報をコンテキストに入れてお0 u Figma
MCPは動的な外部リソースをフェッチするのでMCPがマッチす2 u Ubie Vitals MCPは静的コンテンツなので本質的にはRulesで良いはず
なんでMCP? Rulesじゃダメ? C 単に現行モデルやエージェントの性能特性として、MCPの方がうまくいったので Ubie VitalsではMCPを使ってい C 事前に全てをRulesに入れるとぼやけてしまい、使ってほしい情報を使わなかっ C ただし、ロングコンテキストの性能改善が著しいので、近いうちにこういうMCP
の使い方はなくなるかも ともかく、コンテキストへの入力方法は瑣末な問題で、 入力するに値する情報(ドキュメント、デザインシステム、etc...)の整備が重要
ところで開発の”loop”って コーディングだけ?
DevOps全部やってほしい!
DevOps全部やってほしい!
CursorにPdM機能も持たせる 次のようなデータソースを MCP or CLI で繋げB ユーザーログ、メトリクス (BigQuery,
Lightdash 事業戦略、OKR (Notion チケット (Jira Why/Whatの探索からAC設定まで壁打e 最後に「じゃあこれで」と実装開始
参考 https://note.com/guchey/n/n773a2efd78cf
DevOps全部やってほしい! メトリクスから次のPBIへの 示唆を自動的に抽出 ユーザーログなど参考に 探索的テスト システムメトリクス、ユーザーログなどから 問題検出して切り戻し まだやれてないことが無限に
まとめ ' エージェントを自走させるためにはEnablingが必3 ' ジュニアエンジニアのアナロジーで課題を拾いやす@ ' ソリューションは古典的手法を活かしつつも、 人間ではなくLLMの特性からゼロベースで考えU ' そしてコーディングエージェントからフルサイクル開発エージェントへ
ありがとうございました