ラスベガスで開催された UiPath FUSION 2026 に参加してきたのでレポを書いていきます。今回はブレイクアウト「Transformation at the speed of AI: how UiPath for Coding Agents allows you to do more, better, faster」編です。
登壇は UiPath の Senior Director, Product Management、Alexandru Roman。coding agents 製品を担当している PM 本人で、午前の製品基調講演で Raghu Malpani が発表した UiPath for Coding Agents の GA を、担当者目線で 40 分かけて掘り下げるセッションでした。
私は Claude Code のヘビーユーザなので、このセッションは今回の FUSION で一番聞きたかったやつ。製品セッションなので中身は正確に、所感は最後に 1 節だけ書きます(Q&A で質問もしてきました)。
目次
- 開始 30 秒で GA 宣言！！
- 顧客の実測：88 時間が 39 時間、工数 56% 減！！
- 「実装は仕事の小さい部分」
- More, better, faster って何それ？！
- 速く作れるようになったら、正午に帰る？
- 同じライフサイクル、全部の段階が速くなる
- エージェントに何を渡せばいいの？
- coding agents はプラットフォーム全体に届く
- デモ：注文遅延メールの対応を、プロンプト 4 段落から
- 持ち帰り課題：実践的なパイロット
- Q&A が濃かった
- 発表された事実まとめ
- 所感：質問できるのが現地の醍醐味。coding agents と同じだった
- おわりに
開始 30 秒で GA 宣言！！
挨拶のあと、いきなりこれ。
「UiPath for Coding Agents は一般提供(GA)になりました。今日から使い始められる、試せる、本番に持ち込める、ということです」
前置きゼロ。アジェンダは 8 項目(Results / From an idea to a working automation / More, better, faster / The platform, and the lifecycle / One process, end to end, in Flow / A practical pilot / RSVP / Q&A)で、この順番どおりに進みました。
顧客の実測：88 時間が 39 時間、工数 56% 減！！
最初に出てきたのが顧客側の計測値です。
| 項目 | 値 | 出所 |
|---|---|---|
| 工数削減 | 56% less effort(88 時間 → 39 時間) | 米国の保険会社の自社計測 |
| フェーズ別 | Solution design 67% 減、Dispatcher 50% 減、Performer 55% 減 | 同上。「全フェーズが半分以下」 |
| ビルダー評価 | 9 割近くが 5 段階で 4 か 5、平均未満はゼロ | UiPath 社内のビルダー調査 |
| 典型的な実装 | 工数 2〜3 分の 1(ライフサイクル全体) | スライド |
Alexandru が繰り返していたのは「これは私たちではなく 顧客自身の計測」ということ。あと、削減が構築だけじゃなくて ソリューション設計 でも起きている点。そう、「作るのが速くなる」だけじゃないんですよね。DevConTokyoで私も同じようなことを話しました。
スライドに載っていた顧客の声はこの 3 つ。
- 「数百人分の患者のモックデータ作成は人手では不可能。coding agent なら数時間の仕事」。これまで 予算がなくて諦めていた 大規模テストの例
- 「このユースケースなら 2〜3 週間かかるはずが、1 日 でできた」
- 「React も TypeScript も未経験、Python も少しだけ。これはゲームチェンジャー」。Coded Apps を数分で作った例
もう 1 枚が、UiPath の forward deployed engineer の事例。顧客で本番稼働させたのが エージェント 2 つ、RPA ワークフロー 9 本、API ワークフロー 11 本、Coded App 1 つ。全部 coding agent が構築して、本人のコメントが「私はテストをしただけ」。
Alexandru の補足がちゃんとしていて、「楽しい部分は残る。coding agents がやったことが自分のユースケースで動くかの検証は依然として必要」。ここは後の Q&A でも何度も出てくる話です。
「実装は仕事の小さい部分」
「What it takes」のスライドが地味に良かった。自動化を本番に入れるまで(Designing / Implementing / Validating / Deploying)と、その後も役立つ状態を保つこと(Operating / Investigating failures / Adapting it when the business changes)を並べて、結論が一行。
「Implementing it is the smaller part of the job.(実装は仕事の小さい部分)」
RPA やってる人、全員うなずくやつじゃないですか。で、coding agents はこの全段階にツールを用意している、というのがセッション全体の主張です。
- 設計：ユーザーやビジネスアナリストと話してプロセスを理解する段階。基調講演の Map of Work と Cartographer も coding agents の技術を使っている
- 実装：UiPath が提供するベストプラクティスに従う。良いセレクター(複数技術の組み合わせ、アンカー、静的な ID)を 人が作る必要がなくなる。既存自動化のセレクター改善に使っている顧客もいる
- 運用：Orchestrator の運用、マシン割り当て、エージェントや API 用の環境作成、接続作成なんかも coding agents で速くなる
More, better, faster って何それ？！
セッションタイトルの 3 語は、coding agents を使うときの 「成功の定義」 として説明されました。
| 語 | 意味 | 数えるもの |
|---|---|---|
| More | 人が実際にやっている仕事のより多くを自動化でカバー。構築の障壁が下がるから | 使われている プロセス、完了したトランザクション。「作るために作る」自動化は数えない |
| Better | 要件を満たし、想定した例外を処理し、保守する人に理解できる。スキルが例外処理・リトライ・ネガティブシナリオを組み込む | 人はビジネスとニーズの理解に時間を使える |
| Faster | 承認された要求から有用な成果まで、問題発見から検証済み修正までの時間が短い | 経過時間 |
直前のスライドには「Building faster does not get it into production sooner.(速く作っても、本番に早く入るとは限らない)」。
そしてここで警告が入ります。これが今回一番刺さった 2 行。
「レビューできる量より多く生成すれば、待ち行列を動かしただけ。ボトルネックが構築からレビューに移る」
「速く作っても例外処理を後回しにすれば、コストを動かしただけ。結局、勝ちではなく負けになる」
製品 PM が自分の製品のセッションで「生成しすぎるとレビューが詰まる」って先に言うの、誠実だなと思いました。対策として挙げていたのは、ベストプラクティスに従う UiPath 提供のスキルを使うこと(RPA だけじゃなく Maestro、エージェントの構築にも)。
速く作れるようになったら、正午に帰る？
計測すべきは 3 つ。
- 受け入れられ、使われている自動化：作ったものではなく、人が動かしているものと完了したトランザクション
- 成果と、その裏の工数：ビジネス成果と、それを出し続けるための保守工数をセットで
- アイデアから本番までの経過時間：承認された要求からビジネスが受け入れる実行まで。手作業の工数とは 分けて 計測する
「新しい話じゃない。手作業の自動化でも見るべき KPI。でも、なぜ自動化するのかを思い出させてくれる」と Alexandru。
で、ここで会場がちょっと笑ったのがこれ。
「冒頭で見たとおり少なくとも 2 倍。私の予想では数か月のうちに 3 倍、4 倍、5 倍になる。でも低めに 2 倍から始めるとしましょう。正午に一日を終えて、家に帰ってハッピーになる、というのもあります」
もちろん現実的な答えは バックログの見直し。ROI が合わなくて手を付けなかった案件が、コストが下がった今はやる価値のあるものに変わる。「工数を理由に却下した案件が、やる価値のあるものに変わる」ってスライドにも書いてありました。皆さんのバックログにも眠ってるでしょ？いつかやるタスク
同じライフサイクル、全部の段階が速くなる
スライド「Plan, build, test, operate」のサブタイトルがまた良くて、「At each one, you can see what the agent did, not what it says it did.(各段階で、エージェントが 『やったと言っていること』ではなく『やったこと』 を見られる)」。coding agent 使ってる人はこの一文の重みが分かると思います。
| 段階 | 従来(数か月) | 現代(数時間〜数日) |
|---|---|---|
| Plan | 数日〜数週 | 数時間〜数日 |
| Build | 数週〜数か月 | 数時間〜数日 |
| Test | 数日〜数週 | 数時間 |
| Deploy | 数日 | 数分 |
| Operate | インシデントあたり数時間 | インシデントあたり 数分 |
| 中心 | Review | Human review |
口頭では「非常に楽観的に言えば数時間か数日。現実には大きなプロセスなら数か月かかることもある」とちゃんと幅を持たせていました。
壊れるのは、自動化が間違っていたからじゃない
運用段階の話が具体的でした。
「自動化は壊れる。自動化が間違っていたからではなく、外部システムが変わるから。今日 Daniel も言っていた。外部システムは失敗し、それが自動化に波及する」
今はサポートチームが監視して、調査して、修正して、テストしてる。そこに トラブルシューティング専用のスキル を用意した、と。ログを読むアナリスト、あるいは開発者として振る舞い、原因を調べて推奨を出す。外部システムの障害ならベンダー連絡か回避策、自分のコードの問題なら編集用のスキルで修正に進む。運用の人、これ欲しいでしょ。
エージェントに何を渡せばいいの？
| 段階 | 必要なもの |
|---|---|
| Plan | 仕事の明確な記述。何が入り、何が起きるべきで、何が出て、どの例外が重要か。社内のベストプラクティスと規約 |
| Build | プロジェクトとプラットフォームのコンテキスト。コードの言語だけでなく「このチームがどう作るか」 |
| Test | 実行したチェックと実行結果からのフィードバック、デプロイ先の環境とアクセス権。入力と出力を教えておけば ループで自己修正 する |
| Operate | ジョブ、キュー、設定、ログ。許可されたスコープの中で 検査する。それが何を変えるかを決める証拠になる |
「これは新しいことではない。今日でも仕事をするためにやらなければならなかったデューデリジェンス。正しくやればエージェントに渡せる」
要件定義をちゃんとやれって話なんですが、「ちゃんとやった分がそのままエージェントのコンテキストになる」ので、やる動機が変わるんですよね。ライセンス割り当て、Orchestrator でのマシン作成、Admin でのユーザー作成やロール付与みたいな「簡単だけど時間を食う」作業は、coding agent でも Autopilot でも余裕でできる、とのこと。
coding agents はプラットフォーム全体に届く
このセッションで一番情報量が多いスライド。入口は 4 つ(任意の coding agent / Autopilot / uip CLI / オープンなスキル)で、その下にプラットフォームの全レイヤーが並びます。
| レイヤー | 対象 |
|---|---|
| Map of Work(業務コンテキスト) | Cartographer、Automation Hub |
| Experience(人に仕事を見せる) | Coded Apps、Human-in-the-loop、Tasks |
| Process(仕事を端から端まで調整) | Maestro Flow、Maestro BPMN、Maestro Case、Agents |
| Task(実際の仕事) | API Workflow、RPA、IXP、Functions |
| Foundation(動かし、統治し、動き続けさせる) | Admin、Platform、Solution、Connector Builder、Governance、Automation Ops、Insights、Test、Troubleshoot、Feedback |
用語の説明は潔かった。
- スキル：「エージェントが従うレシピのようなもの。知っておくべきことはそれだけ」
- CLI：「自分のマシンにインストールするアプリケーションで、エージェントが呼び出す。やることはプラットフォームへの接続」
ゴールは「Map of Work から始めてプロセスを 完全に生成 できること」。何週間も続くプロセスや複雑なケース管理も、coding agents が Maestro Case を操作できるので対象、と。午前の基調講演で Maestro Case を 1 時間で生成してたデモ、あれの延長線です。
デモ：注文遅延メールの対応を、プロンプト 4 段落から
シナリオ
顧客から「注文が遅れてる」メールが届く。人間なら複数システムを回って理由を調べ、返信を作り、監視する。これを自動化する。プロセス図は Customer email → Read the email(AGENT) → Look up the order(SAP・API) → Apply the policy(BUSINESS RULE) → Update the order(SAP・API or RPA) → Decision recorded。
スライドの注記が「None of this exists yet. Everything on this slide gets built from an empty project, live.」。空のプロジェクトから、ライブで。
プロンプト
プロンプトは 4 段落、UiPath 固有の構文ゼロ。要旨はこう。
注文例外プロセスを作って。顧客は注文遅延時に Outlook のサービス用メールボックスにメールする。メッセージを読み、注文番号と要望を取り出す。SAP で注文を調べ、ポリシーに従って補償額を算出し、SAP の注文に書き戻す。今はメインパスだけ。チェックとエラー処理を足す前に全体の形を見たい。
「本番なら Map of Work や PDD を入力にする。今日はデモなので楽しみましょう」と前置きしてました。
使った環境と、対応する coding agents
- Studio Desktop(Mac 版！)のターミナル統合で Claude Code を使用
- スキルと互換性は「人気のある coding agent ならどれでも」。テスト済みとして挙げたのは Codex、Kiro(Amazon)、Antigravity(Google)、OpenCode(オープンソース)。対応一覧はドキュメントに
- 組織が Claude Code や Codex を許可していない場合は Autopilot。「皆さんはすでに、知らないうちに coding agent を一つ持っている」。この 1 年で Autopilot を coding agent として再構築して、独自のハーネスでスキルと CLI を使えるようにした。VS Code 用の Autopilot もリリース済み
「組織が Claude Code を許可してない」問題、日本の現場では超あるやつなので、Autopilot がその受け皿になってるのは大事なポイントだと思います。
エージェントは推測せずに聞いてくる
会場のネットワークが不安定で待ち時間が発生したんですが、その間に coding agent は計画を立てて、足りない情報を 質問してきました。
- SAP への到達方法：API か、UI か。Alexandru は API と答えかけて、「Flow の隣に RPA プロジェクトが作られるのを見たいので GUI で」と変更
- 補償ポリシーの中身：ポリシーを提供するか、ポリシーが書かれたドキュメントを渡して抽出させるか、プレースホルダーで続けるか。デモではプレースホルダー
「十分なコンテキストを与えなかったので、推測する代わりに追加情報を求めてきた」
Maestro Flow / RPA / API / エージェント(コード化・ローコード)のどれで作るべきかというツール選択も助けてくれる、とも。UiPath は選択肢が多いので、ここは正直ありがたい。
生成結果
「空白の画面を見つめるのは面白くない」ので、今朝実行しておいた結果を表示。
| 生成物 | 内容 |
|---|---|
| Maestro Flow(OrderExceptionFlow) | Order email received → Extract order number(エージェント) → Get SAP order → Compute compensation → Write outcome to SAP order → Done |
| Flow 内のエージェント | システムプロンプト付き。モデルは Claude Haiku 4.5(temperature 0)。「単純な分類なので安価で速いモデルで十分」 |
| RPA プロジェクト 2 つ | SapGetOrder(SAP GUI にログオンし VA03 で受注を表示して読む)、SapWriteOrderNote(結果を書き戻す)。いずれもクロスプラットフォーム |
| 補償ポリシー(プレースホルダー) | 1〜3 日遅延で正味額の 5%、4〜7 日で 10% |
| パッケージ | 1 つの .uipx に 3 プロジェクト |
| ドキュメント | 動作を説明するノート(Purpose / Solution structure)を coding agent が残した |
自己評価は「中程度の複雑さのソリューション」。モデル選択で Haiku を勝手に選んでるのが、個人的には一番「分かってる」感がありました。
ポリシー変更を Autopilot と Codex で
続いて例外を組み込みます。Studio 内の Autopilot に「ポリシー変更：注文が 500 を超えたらマネージャー承認を取る」と入力。モデルは Anthropic 製(画面上は Claude Opus 4.8)。Autopilot は .flow ファイルと判定して Maestro Flow のスキルをロードし、Flow を読んで、ノード・エッジ・変数・レイアウトを把握してから編集に入りました。
同じ変更を Codex でやる画面も(OpenAI Codex v0.146.1、モデル gpt-6-astra)。プロンプトは「補償 50 ユーロ以上はマネージャーの事前承認が必要。50 未満は変更なし」。Codex はまず Flow を読んで、承認ノードがすでに無いか確認して、uip maestro flow registry search approval を叩いてテナントで使える human-in-the-loop のノード(quick-form)を見つけてから追加。
「あるものを探してから作る」を coding agent が自分でやってるのが、この画面の見どころです。
デモが示したこと
スライド「What that showed」の 3 点。
- Plain English, no syntax：プロンプトは仕事と触るシステムを名指ししただけ。UiPath 固有のものは何もない
- The policy moved in one edit：ルールはプロセスの中にあるので、4 つの自動化にまたがって直すのではなく 1 か所の変更 で済んだ
- It knew the platform：すでに存在するものを検索し、実在するプラットフォームのノード種別を使い、止まる前に検証した
「ビジネスが言うとおりの言い方でポリシーを記述すれば、coding agent が変更を行う」
持ち帰り課題：実践的なパイロット
会社に戻ってやることとして、6 ステップのパイロットが提示されました。
| # | ステップ |
|---|---|
| 01 | チームが理解しているプロセスを選ぶ。明確なオーナーと区切られたスコープ(プロセス理解じゃなく coding agents の理解に時間を使うため) |
| 02 | 成功すべき入力と、失敗すべき入力の 両方 を用意する。例外が存在し、文書化されていること |
| 03 | 「完了」の定義を先に書く。期待する振る舞い、必要な検証、動く場所 |
| 04 | 手作業の工数と経過時間を 分けて 計測する。両方の数字が要る |
| 05 | レビューと手戻りを記録する。リリース後は運用工数も追う |
| 06 | それから変更を入れる。ルールの改定で 「2 版目のコスト」 が分かる |
「手作業でやる場合との比較も勧める。経営層に 2 倍、3 倍、5 倍と証明できれば、採用しない理由はない」
最後のスライド「My ask is simple」は一点だけ。明確なオーナーと計測可能な成果があるバックログ項目を 1 つ選び、最後まで追い、それから要件を変えてみる。 06 の「2 版目のコスト」まで含めてパイロットにしてるのが、この提案のいいところだと思います。作るのは速くなるけど、変更のコストこそ知りたいですもんね。
Q&A が濃かった
約 11 分で 10 問。製品セッションの Q&A としてはかなり密度が高かったので、表にまとめます。
| 質問 | 回答の要旨 |
|---|---|
| インテーク(要件受付)で、手作業のときと違って気に留めることは？ | coding agents は 明確なスコープと境界 を定義したときにうまく動く。以前は 1 か月かけて作る間に学べたが、coding agent では 実装前にできるだけ学ぶ。それが Map of Work と Cartographer を導入する理由 |
| スキルはどれを使うか自分で指定する必要がある？ | 不要。セッション開始時にマシン上のスキルを説明付きでロードし、既定で選べる。確実に RPA を作りたいなら「このスキルで」と指示するのは誤選択を減らす最適化。通常は誤っても自分で気づいて別のスキルに移る |
| VS Code 以外で動く？ Studio でも？ | デモ全体が Studio(Desktop)で行われた |
| 本番サポートチームはどのインターフェースを使う？ Healing Agent との関係は？ | Healing Agent は単独で動き、回復できなければ詳細なログをジョブに同梱する。トラブルシューティングのスキルは Healing Agent のログも読む よう指示されている。Studio からでもターミナルからでも可。Orchestrator にも Autopilot が入る予定(近く提供)で、失敗ジョブを開いて「なぜ失敗したか調査して」と頼める |
| coding agents を使うときのマインドセットは？ ヘビーユーザーだが周りに最初の一歩を踏み出させるのに苦労している(私の質問です。日本語で書いてその場で翻訳し、会場スタッフが代読してくれました) | UiPath 社内も 1 年前に始め、最初は Claude Code に飛び乗ったのは早期採用者だけだった。彼らが速く良く出荷するのを見て他の開発者も「使わなければ遅れる」と理解した。手本として先導し、成功するパイロットで「これは本物で全員のもの」と示す。「地下室で働いて出てきたがらない一人の賢い人だけのものではない」 |
| デモで Haiku を選んだが、後で別の LLM に変えたら不整合が出る？ | 質問を「タスクに対するモデル選択」と読み替えて回答。タスクは単純な分類でどの LLM でもできる。最良のモデルは高コストとレイテンシーが伴うので、仕事に最適なモデルとツールを使う。この場合は Haiku が良いツールだった |
| ライセンスとトークン管理は？ | coding agents 自体は 課金なし、プラットフォームの一部。ただし Claude Code を使うならその料金は自分で払う。coding agent がなければ Autopilot。Autopilot は全開発者ライセンスに制限付きで付帯、月次クォータがあり、超えたらプラットフォームユニットでリセット。ドキュメントの例では含まれるクォータで 中程度の複雑さのプロセスを 10〜15 本 構築できる(プロンプトと複雑さ次第) |
| Basic ライセンスでも使える？ | Autopilot と Delegate は Basic、Plus、Pro すべてに含まれる。違いはクォータで、Plus は Basic の 7 倍か 10 倍(「間違っていなければ」と前置き) |
| ガバナンス(Workflow Analyzer、REFramework の強制)は？ | CLI が Studio の振る舞いを再現し、検証と Workflow Analyzer を実行できる。設定にルールがあればそれも適用し、エラーがあれば戻って修正する |
| カスタムスキルは追加できる？ | できる。自分の Markdown を追加する。カスタマイズはエージェント一般向けの AGENTS.md、グローバル/ローカルのメモリ、UiPath のスキルの利用または自作スキル、の複数経路 |
「coding agents 自体は無償、ただし Claude Code の料金は自分で」と「Workflow Analyzer のルールも CLI が適用して自分で直す」の 2 つは、日本の現場で真っ先に聞かれるところだと思うので、ここで答えが取れたのは収穫でした。
発表された事実まとめ
| 項目 | 内容 | 状態(講演内の表現) |
|---|---|---|
| UiPath for Coding Agents | 任意の coding agent(Claude Code、Codex、Kiro、Antigravity、OpenCode など)からスキルと uip CLI でプラットフォーム全体を構築・運用 | GA |
| Autopilot(coding agent 版) | 独自ハーネスでスキルと CLI を使う。Studio、Studio Web、VS Code。全開発者ライセンスに付帯、月次クォータ | 提供中 |
| Autopilot in Orchestrator | 失敗ジョブの原因調査を依頼できる | 近く提供(incoming) |
| Studio Desktop for Mac | デモは Mac 上の Studio Desktop で実施 | 提供中(デモで使用) |
| Maestro Flow in Studio Desktop | 開発者向けの新しい提供物 Flow を Studio Desktop にも搭載 | 提供中(デモで使用) |
| トラブルシューティング スキル | ログを読み原因を調べ推奨を出す。Healing Agent のログも読む | 提供中 |
| 顧客実測 | 工数 56% 減(88 → 39 時間)、フェーズ別 67/50/55% 減、ビルダー評価 9 割近くが 4 か 5 | 米国保険会社の自社計測、UiPath 社内調査 |
| 料金 | coding agents 自体は無償。外部 coding agent のライセンスは自己負担。Autopilot は付帯クォータで中程度プロセス 10〜15 本、Plus は Basic の 7〜10 倍 | Q&A での回答 |
所感：質問できるのが現地の醍醐味。coding agents と同じだった
このセッションで一番持ち帰ったのは、実は製品の話じゃなくて、質問した という体験そのものでした。
Q&A の「ヘビーユーザーだけど、周りに最初の一歩を踏み出させるのに苦労してる」という質問、私が投げたやつ です。やり方は簡単で、日本語で書いた質問をその場で翻訳して、スタッフに読んでもらっただけ。英語なんて話せる必要ない。
それで、製品を作っている PM 本人が、こっちの状況を聞いて、その場で考えて、「UiPath 社内ですら最初は Claude Code に飛び乗ったのは早期採用者だけだった」と自分たちの話で返してくる。動画で見る講演と、自分の質問に答えてもらう 40 分は、同じセッションでも 別物 です。
正直に言うと、この良さは FUSION に来るまで分かりませんでした。参加前は「基調講演は後で動画が出るし、資料も回ってくるし」と思っていたんですが、質問できる、その回答が自分の課題に向いている、というのは現地でしか手に入らない。
で、書いていて気づいたんですが、これ Alexandru が言っていたことと 完全に同じ構造 なんですよね。
「試した人は、誰でもすぐにその力を認識する。でも最初の一歩を踏み出させるのが難しい」
coding agents の良さは触るまで分からない。FUSION の良さは来るまで分からない。だから Alexandru の答えは「手本として先導せよ、成功するパイロットで示せ」だったし、私がこの記事を書いている理由もそれです。自分が一歩踏み出したら、その様子を見せる。 来年の FUSION、迷っている人は来た方がいいです。英語力はいりません。質問を 1 個、日本語でいいので用意してきてください。
おわりに
というわけで、UiPath for Coding Agents の GA セッションでした。
「速く作れる」の話は正直もう聞き慣れてるんですが、このセッションが良かったのは 「速く作ると何が詰まるか」を先に言ってくれた ところです。待ち行列を動かしただけ、コストを動かしただけ。だから計測はこう、パイロットはこう、と一本の線でつながってました。
日本の現場に持ち帰るならこの 3 つ。
- 組織が Claude Code を許可してなくても Autopilot がある：coding agent として再構築済みで、開発者ライセンスに付帯。「まず試す」の入口はここ
- バックログ項目を 1 つ選んで、最後まで追って、それから変える：Alexandru の「My ask is simple」。2 版目のコストまで測って初めてパイロット
- 生成しすぎるとレビューが詰まる：スキル(ベストプラクティス)に乗せる、例外を最初から入れる、レビュー自体も coding agents に手伝わせる
FUSION記事はまだまだ続きます。お楽しみに！