PHP拡張からApp Builderへ：Adobeが変換をAIエージェントに委ねる

Magentoのリプラットフォーム検討は、最後に必ず同じ壁に突き当たります。拡張モジュールです。10年続いたストアは、内製・購入・改修を重ねた数十のPHPモジュールを抱えており、それらはコアの処理そのものの中で動いています。SaaS版であるAdobe Commerce as a Cloud Serviceが受け入れなくなったのは、まさにこのコードです。あらゆるカスタマイズは、App Builder上で外側に書き直さなければなりません。これまでこの変換はモジュールごとに手作業で見積もられ、多くの場合、そこで計画が頓挫していました。Adobeはこの工事に道具を揃えることを決めました。ホスト型の移行エージェントと、チームがすでに使っているコーディングアシスタント向けの公式スキルという、補完し合う2つの部品です。

承認済みの設計図で動くエージェント

Commerce Developer AgentはAdobeがホストするツールで、Adobeアカウントでサインインしてアクセスでき、2つのシナリオをカバーします。App Builderアプリケーションを白紙から作ること、そして既存のCommerce拡張を変換することです。意思決定者に直結する特徴は、検証済みの計画なしには何も生成しないという点です。エージェントはまずブループリント、つまり段階に分かれたアーキテクチャ計画を作成し、開発者がそれを読み、修正し、承認してから初めてコードが書かれます。生成は公式のApp Builderスキャフォールドに基づきます。Commerceイベントの購読、Webhook、マーチャント向け設定画面、データ永続化です。成果物はアーカイブとして書き出され、そのままリポジトリとデリバリーの流れに載せられます。

ドキュメントは限界についても同じくらい率直で、そこは評価に値します。生成されたコードはすべて、本番に近づける前にレビューしなければなりません。Adobe自身がこのエージェントを、自律的な開発者ではなく出発点の生成器と位置づけています。継続的インテグレーションもローカル環境もAPI Meshの配線も作りませんし、1セッションで扱えるのは1プロジェクトのみ、1回の生成には5分ほどかかることがあります。

自前のアシスタントに入れられるオープンなスキル

2つ目の部品は、すでに体制の整ったチームにとってはより興味深いものかもしれません。Adobeは公式スキルを公開しています。これはコーディングアシスタントに正しいApp Builderのパターンを教える実行可能な手順書で、アプリケーションの初期化、イベント購読、Webhookの設置、マーチャント設定・永続化・管理画面の作成、既存プロジェクトの変換までを扱います。オープン標準agentskills.ioに従い、コマンド1つ（npx skills add adobe/skills）でClaude Code、Cursor、VS Code Copilot、Gemini CLIに導入できます。Apache 2.0ライセンスの公開リポジトリadobe/skillsには、CommerceだけでなくAEM、Analytics、Workfrontも含めて、すでに数十のスキルが揃っています。

この違いは戦略的です。ホスト型エージェントはあなたをAdobeのツールの中へ連れて行き、スキルはAdobeの知識をあなたのツールの中へ連れて来ます。レビューの規律、規約、パイプラインをすでに持つチームなら、後者はデリバリーを何も変えずに採用でき、ポータルのロードマップに依存することもありません。

移行の検討資料で何が変わるか

見積もりの性質が変わります。 正しい問いは、全部を書き直すのに何日かかるかではなく、自社のモジュールのうち何件が対象パターンに収まるかです。イベント、Webhook、設定、ストレージ、管理画面。これらは速く、予測可能なコストで変換できます。一方、コア内部の注文処理を変更するものは、依然として本物のアーキテクチャプロジェクトです。
レビューが最大のコスト項目になります。 コードは速く届きますが、一行残らず読まなければなりません。シニア開発者の役割は書き手からレビュアーに移ります。受け入れテスト、継続的インテグレーション、レビューなしでは決して本番に出さないという鉄則。この堅固なレビュー関門がなければ、生成器は負債をより速く量産するだけです。
ベンダーロックインは部品ごとに秤にかけます。 スキルはオープン標準に従い、好きなアシスタントで動きます。しかし生成先のコードはApp Builder、つまりAdobeのインフラです。変換はプラットフォームへのコミットメントであり、ツールの便利さではなくプラットフォームのために決断すべきです。

どこから始めるか

拡張の棚卸しをして、上記パターンで賄えるものと、コアの処理に根を張ったものの2列に仕分けます。後者の列こそが、SaaSまでの本当の距離を測ります。
中程度の複雑さの拡張1件でパイロットを行います。ブループリント、生成、そしてレビューと仕上げにかかった時間の正直な計測。それが変換の単価であり、それを掛け算する方がどんな机上の見積もりにも勝ります。
加速する前にガードレールを敷きます。 重要な購買動線の再実行可能なテスト、必須レビュー、人の目を通さないコードは本番に出さないこと。生成の速さは、品質管理の確かさの分しか価値を持ちません。

このエージェントは春のSummitで発表され、9月末に一般提供が始まりました。App ManagementはCommerce管理画面に専用の入口を持つようになりました。2027年に向けたAdobeのメッセージは明快です。拡張の書き直しはもう決断を先送りする理由にならない、作業者はベンダーが用意する、と。残るのは、生成できない唯一のもの、すなわち現場監督を用意することです。