ラスベガスで開催された UiPath FUSION 2026 に参加してきたのでレポを書いていきます。今回は製品基調講演「Innovation Across the UiPath Platform: What's New, What's Next」編、その後編です。
前編はこちら
【UiPath FUSION 2026】製品基調講演レポ 前編：「最難問は AI モデル選びじゃない」Cartographer GA と、coding agent が1時間で組んだ Maestro Case！！
https://qiita.com/Hash1mo/items/10135455f6131fdacf4b
- UiPath Solutions：事前構築済みの Map で「午後半日の設定」から始める話と、Source-to-Pay のデモ（Martijn Wijffelaars）
- パートナーの声：Accenture の Shekhar との対話
- coding agent 時代のテスト：「品質の負債」という問題設定（Raghu）
- Test Cloud の Dark Testing Factory：テストが勝手に走る工場（Ingo Philipp）。プライベートプレビュー中
- AI ネイティブな発見：ユースケースを見つけてくれるエージェントが Cartographer に載る
- 締め：プラットフォーム全体像とパートナーエコシステム
目次
- UiPath Solutions：「午後半日の設定」で始めるってどういうこと？
- Source-to-Pay デモ：「開発者用にラップトップ5台」と頼むだけ！！
- パートナーの声：Accenture「エージェントは数日、プロセスは3か月」
- coding agent 時代のテスト：「品質の負債」が積み上がる
- Dark Testing Factory：テストが「あなたのために走る」！！
- AI ネイティブな発見：ユースケースがまだ無い？それなら
- 締め：一つのプラットフォームと、エコシステム
- 前後編を通した発表機能まとめ
- おわりに
UiPath Solutions：「午後半日の設定」で始めるってどういうこと？
前編で Raghu は「Map の始め方は3つ」と言っていました。Prebuilt maps with UiPath Solutions、Process Atlas、Build your own map。後編はその1つ目、UiPath Solutions から。
Raghu の説明はシンプルでした。
- UiPath Solutions は UiPath プラットフォームの上に組まれていて、構築も管理も改善も UiPath がやる
- Map は完全に事前構築済み。自動化の部品も全部配線済み。業務ユーザー向けの体験も付いてくる
- お客さんが持ち込むのはビジネスルールとポリシーだけ。「それは皆さんが所有すべきものだから」
「私たちの目標は、開発者と何か月もかけて Map を作るのではなく、それぞれを『午後半日の設定作業』にすることです」（Raghu）
スライドのコピーが「An afternoon of configuration. Not a quarter of code.」。コードを書く四半期じゃなくて、設定の午後半日。うまいこと言いますね。
お客さんが設定するのは3つだけ。承認階層（Your tiers：5,000 ドル以下はコストセンター管理者、25,000 ドル以下は部長を追加、100,000 ドル超は CFO を追加）、ポリシー文書（Your policy：PRO-002 Rev 7 を入れると 18 ルールが稼働）、そして人が判断に入る線（Your line：「提案」と「決定」の間のスライダー）。下には「Built by us. Maintained by us. Improved by us. You manage your business and we'll manage the rest.」とありました。
Source-to-Pay デモ：「開発者用にラップトップ5台」と頼むだけ！！
デモはプロダクトマネジメントのリーダー、Martijn Wijffelaars。題材は前編と同じ架空企業 Cobalt Ridge の Source-to-Pay（購買から支払いまで）です。
導入前の Cobalt Ridge は「完全にめちゃくちゃ」。統制外の購買（maverick spend）が手に負えず、みんなシステムを迂回して買い物して、交渉済みの契約は使われない。その結果、買掛チームは請求書に埋もれて、しかもその請求書は例外だらけ。問題の大半はプロセスの最初、購買依頼の受付で起きてた、という設定。
Martijn が Raghu に「購買依頼、作ったことあります？」と聞いて、Raghu が「残念ながら何度か。あまり楽しい日ではありませんでしたね」と返す。レガシー SaaS の購買システムで起票した経験がある人、全員うなずいたと思います。
デモ1：購買依頼
Cobalt Ridge のマネージャーとして「開発者向けにラップトップが5台欲しい」と打つだけ。
- AI Assistant が Policy check → Catalog search → Suggested pick の3段で動く
- 裏ではビジネスオントロジーを使って、Cobalt Ridge のシステム（SAP、Coupa、Workday）からデータを集める
- 購買ポリシーと照合して、この状況で買っていい製品だけを表示（画面の条件は「Non-Standard Laptop、単価 5,000 ドル未満」）
- 最適候補として **Microsoft Surface Laptop 6（1,399 ドル）**を提示
- 配送先を確認して完了。ここからは Maestro が承認プロセスを回して、Teams や Slack など「ユーザーがいる場所」に出向いていく
Raghu が「見た目は受け入れやすいけど、裏では何が起きてるの？」と突っ込むと、Martijn の答えは「どの UiPath Solution もそうだけど、Source-to-Pay には完全に事前構築された Map of Work が付いてくる」。ケースプラン、ビジネスオントロジー、ルールとポリシーが初日から揃ってて、UX もエージェントもペルソナ別ダッシュボードも付属。業務チームがやるのは「ラストワンマイル」、つまり自社固有のルールとポリシーの設定だけ、ってことです。
デモ2：30ページのポリシー文書が、ルール6本になる
プロセスオーナーとして Martijn がやったのは、購買ポリシー文書（口頭では 30 ページ、画面は 28 ページ表示）をアップロードすることだけ。ソリューションが Source-to-Pay の原則をすでに理解しているので、文章を決定論的なルールに翻訳できる、というのがミソ。
画面には「Procurement and sourcing SOP」から生成された 6 つのルール（Approved laptop eligibility、Existing coverage first、On-contract price adherence、Competitive price、Payment-term consistency、Supplier detail consistency）が並んでいて、各ルールは元文書の条項（6.1.6 とか）に紐づいてました。
「このルールを 100 回実行すれば、100 回とも同じ結果が返ります」（Martijn）
ここ、地味に大事です。LLM に毎回判断させるんじゃなくて、文書からルールを一度生成して、実行は決定論。前編の「Deterministic ＋ Agentic」の思想がそのまま出てる。
デモ3：買掛側。88% がストレートスルー
以前は請求書に圧倒されてた買掛チームが「コントロールを取り戻した」状態として、請求書の 88% が完全にストレートスルー（人手なし）で処理されている画面。さっき注文したラップトップの請求書は、情報抽出 → システム照合 → 検証チェックを通ってそのまま先へ。
一方でブロックされた請求書も1件登場。発注書（PO）が無くて、依頼者も文書に書いてない、というやつ。ここでエージェントがオントロジーを使って「Kate が以前に似たリクエストをしているので、彼女が依頼者かも」と推定して、「専門家（category manager）に聞く」か「Kate に直接行く」かの選択肢を出してくる。Martijn が Kate 直行を選ぶと、Maestro が Teams で Kate を追いかけ始める。
デモ4：Decision Ledger で「もう私を煩わせないで」
前編の保証対応と同じく、UiPath Solutions でも Decision Ledger で継続的に改善する、という流れ。画面は Exception「Non-PO invoice with an unknown requester」で、提案アクションの採用率は 42%（過去1か月で 19 回実行）。
Ledger の提案は「エージェントはほとんど常に請求履歴から正しい人を見つけているのに、ルールが全ケースを category manager 経由にしている。候補が1人だけなら直接その人に行く分岐を追加せよ」。Martijn の言い方だと、
「ありそうな依頼者が一人しかいないなら、その人に直接行こう。もう私を煩わせないで」
デモ5：気になる数字の話
Raghu の「作ったものの価値をどう示すの？」に対する答えは、標準搭載の KPI。財務担当 VP 視点のダッシュボードがこれ。
| KPI | 値 | 補足 |
|---|---|---|
| Maverick spend（統制外購買） | 12か月平均 13.0% | 目標 15%。月次は 10.5〜15.8% |
| Touchless rate | 88.4% | 目標 85%。人手ゼロで通った請求書の割合 |
| Savings | 309,570 ドル | 過去 12 か月 |
| Invoice cycle time | 3.2 日 | 受付から最終承認までの中央値 |
| Invoices processed | 103,190 件 | 2025年10月〜2026年9月 |
「この Source-to-Pay ソリューションで、Cobalt Ridge は数か月ではなく数日で始めることができました。重要な成果とともに、ROI を素早く実現できたのです」（Martijn）
パートナーの声：Accenture「エージェントは数日、プロセスは3か月」
続いて Raghu が Accenture の Shekhar をステージに招きました。冒頭で Raghu が「Agentic Leadership Partner of the Year」の受賞（賞の正式名称は聞き取り不明）を祝って、Shekhar が Map of Work と Cartographer の GA を祝い返す、という始まり。
Shekhar が語った Accenture の戦略は「80 万人の人材、自社のアセットとプラットフォーム、そして UiPath のようなパートナーと共に、クライアントのビジネスプロセスを再発明する」。そのうえで、大規模な agentic 変革でお客さんが「最初の一回で正しくできてない」課題を挙げました（「3つ」と前置きして、詳しく話したのは2つでした）。
- 正しいユースケースを選ぶ：agentic AI を決定論的なプロセスに使うのか、確率的なプロセスに使うのか。「これはシンプル。知識があればできる」
- プロセスを agentification できる状態にする：「今日ではエージェントを作ること自体は簡単になった」。でも「エージェントを作るのに数日、プロセス側はまだ3か月かかる」。ビジネスリーダーは「メディアで聞く話と IT の皆さんがやっていることの間に、なぜこのギャップがあるのか」と問う。ギャップの本質は、整理されたデータが無くて、知識が AI エージェントの追いかけられる形でコード化されていないこと
これ、日本の現場でも完全に同じ話じゃないですか。エージェント作るのは早い。プロセス側の整備が追いつかない。
Cartographer と Map of Work については、Accenture の「3D フレームワーク」で説明。Data（データ）、Digitalization / Documents（デジタル化と文書）、そして「これまでの理屈全体で欠けていた三つ目」が Decisions（意思決定）。どこにも記録されていない人間の意思決定が取り組みを遅くしていて、それを埋めるのが Decision Ledger だ、という位置づけです。
利点は3つ。AI 時代のプロセス発見のスピード向上（「RPA の世界ではプロセスインテリジェンスでやったけど、今はまったく異なるメカニズム」）、プログラムの成功確度の向上（「パイロットが失敗するのは知識が無いから。ビジネスと IT の責任のなすり合いが起きる」）、そして両方合わせて AI プログラムの ROI 向上。
coding agent 時代のテスト：「品質の負債」が積み上がる
録音3本目は、Raghu によるテストの問題設定から。
「皆さんもご存じのとおり、コーディングエージェントによって、自動化、コード、業務アプリケーションが提供される量が劇的に加速しています。しかしこれは、技術的負債、品質の負債、テストの負債を増やしています」（Raghu）
テストチームは追いつけず、そのギャップがアプリの品質に現れる。スライド「The pressure gap? We feel it every day.」は、2022 年から 2027 年にかけてテストの供給能力（赤）と需要（青）の差が「THE GAP」として開いていく図。
前編で coding agent が「1時間で 10 ステージ 41 タスク 76 ルール」を組んだ直後にこれを見せられると、めちゃくちゃ実感ありますよね。作る側が 12 倍速くなったら、テストする側も 12 倍速くならないと詰む。
Dark Testing Factory：テストが「あなたのために走る」！！
Raghu が「Test Cloud のプロダクト担当 VP」として招いたのは Ingo Philipp。
「ソフトウェア開発はスピードアップしている。しかし、出荷するものをテストする私たちの能力は、そうなっていない」（Ingo）
Ingo が紹介したのが、この課題のために目的特化で作った Dark Testing Factory。定義は「ソフトウェアテストが『あなたが実行するもの』であることをやめ、『あなたのために走るもの』になる場所」。ダークファクトリー、つまり「明かりを消しても動く工場」のメタファーです。
なんで「自律」に向かうの？
Ingo の論理展開はこう。
- テストは一つの作業じゃない。設計、自動化、実行、その間の全部。多くの組織ではまだ手作業か、せいぜい従来のルールベース自動化
- ルールベース自動化は役に立つけど、テストの全部を固定ルールに還元できるわけじゃない。そこでエージェント（Autopilot や Delegate みたいな会話型エージェント）が登場
- でも「ここにエージェント一つ、あそこにエージェント一つ」では切り離された知性の小島にすぎない。ソフトウェア開発と歩調を合わせられない
- 本当のシフトは、それらをガバナンスの効いた自律的なフローにつないだときに起きる。テスト環境を立ち上げては片付け、ステージをまたいでテストを実行し、結果を分析する。全部自律的に、人間は統制を保ったまま
「明かりはすでに暗くなり始めている（the lights are already dimming）」という言い方で、お客さんがすでにこの道を歩んでいることも強調。スライドの5段階がこれ。
| 段階 | 人と機械の役割 | Speed Gain |
|---|---|---|
| 1. Manual Testing | 全工程を人が手で実行 | - |
| 2. Automated Testing | 人がスクリプトを書き、機械が実行 | 1x |
| 3. AI-Augmented Testing | 人が AI に頼み、AI が導く | 3x |
| 4. Autonomous Testing | 人がレーンを引き、AI が実行 | 6x |
| 5. Dark Testing Factory | 人がゴールを置き、テストが自走 | 12x |
Ingo はこれを「自律テストのステロイド版」と呼んで、「自律テストはもはやポイントソリューションじゃなく、オペレーティングシステムになる」と言ってました。
デモ：Cobalt Ridge の SAP S/4HANA 工場
デモは UiPath Test Cloud 上で、Cobalt Ridge の SAP S/4HANA 向けに設計された工場（factory）を見せる形。
- Factory Manager：工場を動かす自律エージェント（画面は v8.2、トリガー5、ツール8）。「工場を動かすのはあなたではない。工場は自分で動く」
- トリガー：SAP に入る新しいトランスポート、Jira でクローズされるユーザーストーリー、開発パイプラインからのコミット（画面は SAP Transport、Jira、GitHub、CI/CD、Manual test runs）。変更が入ると工場が引き継いで、テスト計画を作り、作業項目に分解して、使えるツールに配分する
- Risk Assessor：ツールの一つ。「単一のエージェントでも単一の自動化でもなく、agentic なループ」。入ってくる変更のビジネスリスクを特定して、工場のリスクモデルと突き合わせて優先順位を決める。「ここでの自律性は、常にリスク駆動」。実行中の様子はライブで見えて、「工場が考え、働いているのをリアルタイムで見られる」
- Inbox と Memory：適切なタイミングでエージェントか人間がレビュー・承認に入る。人は Inbox で、足りない知識を提供したり、例外を明確にしたり、トレードオフを判断したり。「人は工場を動かすのではなく、工場に教える」。教えるたびに、それから自分の失敗からも、工場の記憶が改善される。「時間とともに、少し賢く、少し自律的に、少し『暗く』なっていくシステム」
Governance：どこまで自走させるかは人が決める
Raghu が「人間が依然として責任者。統治とコスト管理ができないと」と念を押すと、Ingo の返しは、
「統制なき自律は、賢明ではありません」（Ingo）
Dark Testing Factory はプラットフォームに深く統合されているだけじゃなく、AI Trust Layer にも組み込まれていて、工場と各構成要素に与える自律性の量、コストと予算の統制、運用ポリシーを設定できる。
画面の Governance がけっこう細かくて、Factory mode（Manual、Semi-autonomous、Autonomous、Custom の4択）、6つのステージゲート（Signal ingestion、Intake judgement、Work item dispatch、Artefact promotion、External write-back、Memory promotion）ごとの Auto / Notify / Approve の設定、ツール単位で月間トークン上限を置く Budget タブ、決定の記録を見る Ledger タブ。「全自動か手動か」の二択じゃなくて、段階ごとにどこで人が止めるかを選べる設計です。これは日本のお客さんに説明しやすい。
そしてゴールは自律そのものじゃない、と Ingo は締めます。
「本当に大事なのは、私たち全員が答えなければならない一つの問い。『このアプリケーションを出荷する準備はできているのか、否か』。Dark Testing Factory はその問いに証拠で答えるのを助けます。勘でもなく、直感でもなく、事実で」（Ingo）
「品質を置き去りにせず、速く安全に出荷する自信」が結論。提供状況はプライベートプレビュー中で、参加したい人は UiPath ブースへ、とのこと。
デモ全体の総括：3.5x、88%、12x
録音4本目は総括スライドから。「UiPath が Cobalt Ridge を AI ネイティブ企業に変えた」として、前後編のデモを3つの数字でまとめたもの。
| プロセス | 数字 | 何を使ったか |
|---|---|---|
| Warranty resolution（前編） | 3.5x（問い合わせからクローズまでの日数、11.2 日から短縮） | Process Atlas の Map の上に構築 |
| Source-to-Pay（後編） | 88% ストレートスルー処理 | 既存の UiPath Solution を Cobalt Ridge のシステムに設定 |
| Software testing（後編） | 12x 速いリリースを品質そのままで | Dark Testing Factory |
「皆さんが心配している、考えている、最も重大な（consequential）ビジネスプロセスを思い浮かべてください。そして、それを私たちと一緒に作ってください」（Raghu）
AI ネイティブな発見：ユースケースがまだ無い？それなら
次に Raghu が取り上げたのが「ユースケースが無い場合、あるいは自動化機会はいろいろあるけど優先順位が付けられない場合」。
「皆さんは自動化の可能性を発見するためのマイニング技術をご存じでしょう。私たちは、最も重大な自動化機会を発想（ideate）し優先順位付けするには、現代の AI ネイティブなソリューションが必要だと考えています」（Raghu）
そのために UiPath Cartographer に AI ネイティブな発見（discovery）の能力を載せる、というのが発表。このエージェントは Cartographer（人）の「スパーリングパートナー」として、システムログ、自動化ログ、タスクログにつながって、業務チームの録画も取り込んで、統合・蓄積して、存在し得る機会の自動化ポテンシャルを定義するのを助ける。
スライド「Process Discovery with UiPath Cartographer / What if you don't have a use case yet?」には、発見の手段として RPA scan、System logs、Documents、Recordings、Interviews、Ask a person の6つが並んでて、その下に保険業務（Distribution、Underwriting、Servicing、Claims、Finance）のプロセス一覧が価値の順位付きで出てました。提供状況は、デザインパートナーをオンボーディング中で、プライベートプレビューは数週間以内。
プロセスマイニングの導入に踏み切れなかったお客さんに、ログと録画とインタビューから始める別の入口ができる、ってことです。これは追いたい。
締め：一つのプラットフォームと、エコシステム
最後に Raghu がプラットフォーム全体像を一枚で。前編冒頭の「Foundation / Task / Process」の3層図に、今回の発表を全部重ねたやつです。
- Foundation：Data & Documents、Trust、Observability、Interoperability、Extensibility、Deployment Flexibility（Cloud、On-premises、Dedicated）
- System of Action：Task（API、RPA、Functions）、Process（Process Orchestration、Case Management、Business Rules）、Experience（Enterprise Apps）の3層。左が決定論的能力、右が認知的能力（Task Agents、Computer Use、Self Healing、Case Agent、Multi-agent Orchestration、Cowork、HITL）
- Process Context：Map of Work（Structured Knowledge、Operating Knowledge、Decision Ledger、Prebuilt Maps / SME-attested Maps）
- 最上段：Coding Agents で Build、Test、Deploy、Operate、Improve、Govern
「各層は決定論的に、つまりトークンなしで走ることができます。正確さ、低レイテンシ、低コストが理由です。しかし同時に、各層で認知的な能力もサポートします。この線が『選択』を表している。どこに線を置くかは、皆さんが選べる」（Raghu）
締めはエコシステム。スライドは「The Map of Work is only as complete as the ecosystem it supports.（Map of Work は、それが支えるエコシステムの完全さまでしか完全にならない）」で、SAP、Oracle、Snowflake、Databricks、Microsoft、Google Cloud、AWS、Anthropic、OpenAI、NVIDIA、Salesforce、ServiceNow など約 80 社のロゴがずらり。
「私たちは拡張性を約束しました。その約束は、皆さんと共にあるあらゆるパートナーと深く組む、ということを意味します。それが私たちの強みです。それによって、私たちが一番得意だと信じている一つのことに深く入り込める。それは、エンタープライズを統制し、どこにも負けない最高のビジネスオーケストレーション・自動化プラットフォームであることです」（Raghu、原文は "the enterprise controlling and the best business orchestration and automation platform anywhere"）
前後編を通した発表機能まとめ
| 機能 | 何をするものか | 提供状況（講演内の表現） | 前編/後編 |
|---|---|---|---|
| Map of Work | プロセスコンテキストを Structured Knowledge、Operating Knowledge、Decision Ledger の3要素で構造化した、ライブで顧客所有でガバナンスされた資産 | 概念・成果物。Cartographer の GA とともに利用可能 | 前編 |
| UiPath Cartographer | Map of Work を構築・維持する製品。ゴール指向エージェント、文書からの as-is 文書化と矛盾検出、SME への Teams 引き渡し、赤線での書き戻し | GA（9月23日） | 前編 |
| Process Atlas | 専門家の検証を受けた業界プロセスの Map 集。ばらつきの大きいプロセスの初期実装として使う | 発表（100+ processes mapped。Insurance は Coming Soon） | 前編 |
| UiPath for Coding Agents | Codex、Claude、Windsurf など好みの coding agent から、プラットフォーム全体を構築・運用・管理・ガバナンス・改善 | GA（9月23日、プラットフォーム全体） | 前編 |
| Decision Ledger と改善提案 | 人の判断と理由を記録し、エージェントが新ルール・新プロンプト・新自動化を提案。適用時に評価を自動実行 | Cartographer 内で動作。全体像スライドでは Decision Ledger にロードマップ印（*）あり | 前編・後編 |
| UiPath Solutions（Prebuilt maps） | 業界共通プロセスの Map、自動化成果物、ペルソナ別 UX、標準 KPI を事前構築。顧客はルールとポリシーの「ラストワンマイル」を設定 | 提供中。Source-to-Pay のほか、Healthcare、Financial Services、Manufacturing & CPG、Retail、Office of the CFO の各サミットで個別セッション | 後編 |
| Test Cloud：Dark Testing Factory | 変更を検知して計画・分解・配分し、リスク駆動でテストを自走させる工場。Factory Manager、Risk Assessor、Inbox、Memory、Governance（4モード、6ゲート、予算） | プライベートプレビュー中 | 後編 |
| AI ネイティブな発見（Cartographer） | ログ・録画・文書・インタビューから自動化機会を発見し、価値で順位付けするエージェント | デザインパートナー受付中。プライベートプレビューは数週間以内 | 後編 |
| プラットフォーム全体像 | 各層で決定論的能力（トークンなし）と認知的能力（エージェント）を選べる。Deployment は Cloud、On-premises、Dedicated | 全体像スライドとして提示 | 後編 |
おわりに
というわけで、製品基調講演の後編でした。最後に、少しだけ自分の話をさせてください。
マネしたいのは「AI のブラッシュアップを定期作業にする」こと
後編で一番持ち帰りたかったのは、Decision Ledger まわりの考え方です。人の判断を日常業務の中で記録して、それを元にエージェントが改善案を出して、人が承認して Map に書き戻す。AI のブラッシュアップを「気が向いたらやる」ではなく、定期作業として運用に組み込んでいる。ここは素直にマネしたい。
正直に言うと、ここには自分の失敗があります。エージェントをリリースした後に、どうやって改善していくのか、どんな頻度で見直すのか。現場の意見を尊重した結果、チームごとにやり方も頻度もバラバラになって、結局まとめきれなかった。今日、その答えが見つかった気がしています。
「ライフサイクルが速くなる」を手放しで喜べていなかった、という告白
前後編を通してのメッセージは「Map を描いて、coding agent が組んで、Maestro が回して、テストも自走する。ライフサイクル全体が速くなります」でした。これは本当だと思います。デモの数字を割り引いても、方向は疑っていない。
でも私は、これを手放しで喜べていませんでした。ここで告白しておきます。
Agent 化して空いた時間を、我々は何に使えばいいんだろう？
考え方は2軸あると思っています。
- X 軸（量）：自動化のバリエーションを増やす。今まで手が回らなかった業務にも横展開して、本数を積み上げる
- Y 軸（質）：期間やテクニカルな理由で踏み込めなかった領域に、腰を据えて踏み込む。1本の自動化を、もう一段深いところまで持っていく
面積で考えるなら、X も Y も伸ばして、一番広い長方形を作るのが正解です。どちらを先に伸ばすかは、そのお客さんが導入のどのフェーズにいるかで変わる。それは分かっています。
そのうえで、私は質の選択肢を取りたい。
なんでかって？ 一番質を高めた自動化は、いつかインフラに変わるからです。できているのが当たり前になって、止まったときだけ気づかれて、誰からも感謝されなくなっていく。電気や水道と同じ。
ひねくれた見方かもしれません。でも、自動化のあるべき姿の究極系って、これなんじゃないかなと思っています。「すごい」と言われる自動化より、「あるのを忘れられる」自動化。coding agent で作る速度が上がった今こそ、空いた時間をそこに注ぎ込みたい。
前後編で製品基調講演は完結です。FUSION 2026 の他のセッションも順次書いていきますので、お楽しみに！