投稿者 投稿日: カテゴリー AIニュース
ACPとは、任意のエディタと任意のAIコーディングエージェントをつなぐ共通規格です。
2026年6月2日、AIコーディングIDEのWindsurfが Devin Desktop へ名称と機能を刷新し、全ユーザーへ自動アップデートで配信されました。目玉は見た目の変更ではありません。ローカルで動くエージェントもクラウドで走るエージェントも、1枚のカンバンボードから束ねて指示できる「エージェントの司令塔」になった点です。その土台にあるのが Agent Client Protocol、通称 ACP という共通規格です。EC事業者にとっては、在庫連携スクリプトや商品データ変換の自動化を、どのAIツールに縛られることなく組める環境が整い始めたという話になります。この記事では、Devin Desktop と ACP の実態を一次情報ベースで整理し、自社ECの開発現場で今日から検証できる手順とプロンプトを示します。
Devin DesktopとACPはどんな変化点から生まれたのか
Devin Desktop は、Cognition が買収した Windsurf を母体にした後継IDEです。Cognition の発表によれば、旧 Windsurf の設定はそのまま引き継がれ、OTA（無線経由）アップデートで自動的に置き換わりました。単なるリブランドではなく、ローカル/クラウドの全エージェントを1つのカンバンビューで管理する司令塔機能が加わっています。編集中のファイルにインラインで補完させる作業と、バックグラウンドで長時間タスクを回す作業を、同じ画面で並行管理できるようになった、と理解すると近いです。
もう一つの軸が ACP です。Zed の解説では、ACP はエディタとコーディングエージェントの通信を標準化するオープン規格で、位置づけは「AIエージェント版のLSP（Language Server Protocol、エディタと言語解析ツールをつなぐ既存の共通規格）」と説明されています。LSPが登場する前は、補完や定義ジャンプの機能をエディタごとに作り直す必要がありました。ACPはそれと同じ発想で、エージェント側とエディタ側を一度つなげば、どの組み合わせでも動く状態を目指しています。実装仕様はGitHub上でオープンソース公開されています。
なぜこれがEC開発に効くのか。理由は乗り換えコストの構造にあります。これまでは「Aというツールで書いた自動化スクリプトは、Aのエコシステムに縛られる」状態が普通でした。ツールの値上げや仕様変更があっても、乗り換えには相応の作り直しが伴います。ACPが浸透すると、エディタとエージェントが疎結合になり、エージェントだけを差し替える選択肢が現実的になります。店舗運営の現場感覚では、特定ベンダーへの依存が薄まること自体が、中長期の運用リスクを下げる材料になります。
Devin Desktop の位置づけを補足すると、Cognition は同時期に Devin Local という軽量エージェントも投入しています。これは旧 Windsurf の Cascade エージェントを Rust で書き直したもので、公式説明では最大30%のトークン効率改善とサブエージェント対応を掲げています。トークン効率はそのままAPI利用料に響くため、コスト面でも見どころのある更新でした。ここは各社発表値であり、実利用でどの程度出るかは自社の処理内容で検証する前提の目安として捉えてください。
EC事業者の視点で、この変化を具体的な作業に落としてみます。たとえば毎月、楽天RMSの商品データCSVをダウンロードし、Amazon Seller Central の在庫レポートと突き合わせ、Shopify Admin の受注データと合わせて月次の売上サマリを作る、という定型作業があるとします。従来なら、この一連の処理を書くツールと、書いたコードを対話的に直すツールと、長時間バッチを回す場所が、それぞれ別々でした。Devin Desktop と ACP の組み合わせが目指すのは、これらを1つの環境の中で、タスクの性質に合わせて別々のエージェントに任せながら、進行状況を1画面で追える状態です。作業の全体像が視野に収まるだけで、どこで止まったかを探す手間が減ります。
ACPで複数エージェントを1画面に束ねる仕組み
ACPの実務的な威力が出るのが、エージェント選択の自由度です。Zed が公開した ACP レジストリには、実装を一度登録すればすべてのACP対応クライアントから使える仕組みが用意され、初期の登録済みエージェントには Claude Code、Codex CLI、GitHub Copilot CLI、OpenCode、Gemini CLI などが並びます。Devin Desktop 側も、Codex、Claude Agent、OpenCode といったACP互換エージェントをIDE内で動かせる形で出荷されました。
対応はDevinやZedに閉じていません。JetBrains もACPレジストリへの対応を進めており、IntelliJ系IDEからACP対応エージェントを呼び出せる方向に動いています。Neovim には CodeCompanion と avante.nvim という2つのプラグイン、Emacs には agent-shell という実装が登場し、コーディングエディタの主要どころが横並びで対応し始めた状況です。エディタもエージェントも複数の選択肢が生まれ、その掛け合わせが利用者側で選べるようになってきた、という理解が現時点では妥当です。
EC開発の文脈に落とすと、これは「タスクの性質でエージェントを使い分ける」運用が1つの環境で完結することを意味します。たとえば、対話しながら少しずつ直したい商品説明文の変換ロジックは手元で軽く回せるエージェントに、夜間バッチで長時間かかる大量CSVの突合は別のクラウド寄りエージェントに、といった振り分けです。従来はツールを行き来していた作業を、Devin Desktop のカンバン上で並べて眺められます。直近の支援案件で観測したのは、ツールの切り替え自体が地味に時間を食っていたという事実で、この摩擦が減る意味は現場では小さくありません。
レジストリという仕組みの意味も押さえておきます。エージェントの提供者が実装を一度登録すれば、対応クライアントの側は個別に接続設定を作り込まなくても、そのエージェントを候補として扱えるようになります。利用者から見ると、使いたいエージェントを一覧から選んでつなぐ、という体験に近づきます。プラグインを一つずつ手で設定していた時代と比べると、増えていくエージェントを管理する負荷が下がる方向です。ただし登録済みであることと、自社の用途で安定して動くことは別問題なので、選定後に実データで検証する工程は省けません。
ここで注意したいのは、ACPが標準化するのは「エディタとエージェントの通信」であって、「エージェント同士の決済や商取引」ではない点です。混同されやすいのですが、AIエージェントが商品を購入・決済する領域の規格は、Agentic Commerce Protocol や Universal Cart Protocol など別系統の話です。両者は名前が似ていても目的が違います。この違いは、ACP・UCP・Agentic Commerce の比較の記事で整理しているので、購買側のエージェント規格を調べたい場合はそちらを参照してください。本記事が扱うのは、あくまで開発現場でエージェントを束ねる側のACPです。
EC開発でDevin Desktop×ACPをどう使うか
ここからは実装寄りの話に入ります。自社EC・API連携・業務自動化の3領域で、Devin Desktop と ACP対応エージェントをどう使うかを、具体的な操作の流れとプロンプト3本で示します。プロンプトは ChatGPT、Claude、Gemini のいずれでも使える形にしてあります。使う前に、対象データから個人情報や決済情報を外し、テスト用の少量データで挙動を確認してから本番に回す手順を守ってください。
最初の設計段階では、いきなりコードを書かせるより、どのエージェントにどのタスクを割り振るかを言語化させると失敗が減ります。手元での軽い対話向きのタスクと、長時間バッチ向きのタスクを切り分ける設計プロンプトが1本目です。
（用途タイトル：エージェント振り分けの設計）
あなたはEC事業者の開発環境を設計するアーキテクトです。
以下の自動化タスク一覧を、「対話しながら短時間で直すタスク」と
「バックグラウンドで長時間回すバッチタスク」に分類し、
それぞれDevin Desktopのカンバン上でどう並べて管理すべきか、
運用手順を箇条書きで提案してください。
前提:
- 使えるエージェントはACP対応（例: Claude Code系、Codex系、OpenCode）
- 個人情報・決済情報を含むデータは対象外にする
- 失敗時に手動へ切り戻せる設計を優先する
タスク一覧:
- {タスク1（例: 在庫CSVの列名統一）}
- {タスク2（例: 楽天とAmazonの売上データ突合）}
- {タスク3（例: 商品説明文の一括リライト下書き）}
出力: 分類表ではなく、タスクごとに「担当エージェントの性質・理由・チェック観点」を文章で
2本目は、API連携の実装をエージェントに書かせるときの指示です。ECではモール各社のCSVフォーマットが微妙に異なるため、変換ロジックの仕様を先に固めさせると手戻りが減ります。楽天RMSの商品データ、Amazon Seller Central の在庫レポート、Shopify Admin のエクスポートなど、扱うファイルの実体を明示するのがコツです。
（用途タイトル：データ変換スクリプトの仕様固め）
あなたはEC運営に詳しいソフトウェアエンジニアです。
以下の入力ファイルを、指定の出力形式へ変換するスクリプトの
仕様書を、コードを書く前に日本語で作成してください。
入力:
- ファイル種別: {楽天RMS商品データCSV / Amazon在庫レポート など}
- 想定文字コード: {UTF-8 / Shift_JIS など、不明なら両対応を明記}
- 主なズレ要因: {列名の表記ゆれ、全角半角、空欄の扱い}
出力:
- {統合在庫マスタCSV / 月次レポート集計 など}
仕様書に必ず含める項目:
1. 入力の前提と欠損時のフォールバック
2. 変換ルール（列マッピング、型変換、丸め）
3. 異常データを検知したときの停止条件とログ出力
4. テスト用の少量データでの検証手順
仕様書の後に、実装コードを提示してください。
3本目は、複数エージェントの出力を突き合わせて品質を上げる使い方です。同じ処理を性質の違うエージェントに書かせ、差分をレビューさせると、片方だけでは気づきにくい抜けを拾えます。
（用途タイトル：エージェント出力のクロスレビュー）
あなたはコードレビューを担当するシニアエンジニアです。
同一の仕様に対して、2つのAIエージェントが生成した
スクリプトAとスクリプトBを比較レビューしてください。
観点:
1. 在庫数の計算やデータ突合にロジック差はないか
2. エラー処理・例外時の挙動の堅牢さはどちらが上か
3. 文字コードや空欄などECデータ特有の落とし穴への耐性
4. 保守しやすさ（可読性・命名）
出力:
- 差分の要点を文章で
- 本番採用すべき方の推奨と、その前に直すべき箇所
スクリプトA:
{貼り付け}
スクリプトB:
{貼り付け}
この3本を軸に、設計から実装、レビューまでを Devin Desktop のカンバン上で回すと、1つの画面で自動化の一連の流れが見通せます。エディタ側の操作は従来のWindsurfから大きく変わっていないため、旧環境からの移行そのもので詰まる人向けには、WindsurfからDevin Desktopへの移行ガイドに手順をまとめてあります。まず環境を移し終えてから、本記事のACP活用に進む順序がスムーズです。
導入でつまずくポイントと回避策
一つ目の失敗は、いきなり本番データで複数エージェントを回してしまうケースです。ACPで複数のエージェントを扱えるようになると、つい全タスクを一度に自動化したくなります。ところが在庫や受注のデータは、1桁の取り違えが欠品や過剰在庫に直結します。回避策は単純で、テスト用に切り出した少量データで挙動を固めてから本番へ広げる、この順序を崩さないことです。5,000社支援の中で何度も再現したパターンとして、最初の自動化ほど小さく始めた店舗のほうが定着率が高い傾向があります。
二つ目は、エージェントの選択に迷って前に進まないケースです。ACPで選択肢が増えた反動で、どのエージェントが最適かを比較しすぎて着手が遅れることがあります。開発ツールの優劣は処理内容で変わるため、机上比較で結論は出にくいのが実情です。対話的に直したい作業か、長時間のバッチ処理かという性質でまず割り振り、実データで小さく試すほうが早く答えが出ます。エージェント単体の比較検討で立ち止まっている場合は、CodexとClaude Codeの実務比較のように、EC業務の具体シーンで見た比較を出発点にすると判断が進みます。
三つ目は、生成されたスクリプトを検証せずに本番の定期実行へ載せてしまうケースです。AIが書いたコードは一見動いても、月末だけ発生する条件や、特定モールの仕様変更で静かに壊れることがあります。回避策は、異常データを検知したら停止してログを残す設計を最初から仕様に含めること、そして切り戻し手順を用意しておくことです。自動化は「止まらないこと」より「おかしいときに正しく止まること」のほうが実運用では効きます。
費用・工数の目安とKPI設計
費用面から見ます。AIコーディングエージェントの利用は、大きく分けてサブスク型と従量課金型があります。個人が対話的に使う範囲であれば、ChatGPT Plus、Claude Pro、Gemini の各有料プランはいずれも月額20米ドル前後が目安です（2026年7月時点、為替と各社改定で変動します）。バッチで大量に回す場合はAPI従量課金が中心になり、ここは処理するトークン量に比例します。Devin Local が掲げるトークン効率改善のような要素は、この従量分に直接効いてくるため、量が増える現場ほど効き幅が大きくなります。
工数の考え方は、削減できる作業時間で測るのが実務的です。たとえば毎月手作業で数時間かけていた複数モールの売上集計を自動化できれば、その時間がそのまま浮きます。KPIとしては、対象作業の月間工数の削減率、スクリプトが異常停止した際の平均復旧時間、自動化した処理の成功率（正しく完了した割合）あたりを置くと運用の健全度が見えます。CVRのような売上直結指標ではなく、まず運用の安定と工数削減を指標に据えるほうが、開発領域の自動化とは相性が良いと判断します。
投資対効果を測るときは、導入初期の学習コストも見込んでおきます。エージェントの挙動を理解し、プロンプトを自社の作業に合わせて整える立ち上げ期間は、一定の時間がかかります。ここを見込まずに即効を期待すると失望しがちです。3か月程度をならし運転期間として、その間に浮いた工数と、かかったAPI費用・学習時間を突き合わせて判断する構えが現実的でしょう。
もう一つ、複数エージェントを併用する構成では、生成物の品質のばらつきを管理指標に加えると運用が安定します。同じ仕様でもエージェントによって出てくるコードの堅牢さは変わるため、本番採用前のレビュー通過率や、稼働後の不具合発生件数を記録しておくと、どのタスクをどのエージェントに任せるべきかの判断材料が社内に貯まります。ある食品ジャンルの中規模店舗の事例では、最初の数か月でこうした記録を残した結果、定型処理の担当エージェントを固定でき、レビューにかける時間が目に見えて減りました。数字は店舗規模や処理内容で変わるため一般化はできませんが、記録を取る習慣そのものが効いてくる、という点は現場で繰り返し見る傾向です。
今後の展望と独自考察
ACPの本質は、エージェントとエディタの分離にあります。この分離が進むと、EC事業者にとっての「開発ツール選び」は、単一ベンダーへの片道の賭けではなくなります。エージェントを差し替え可能な部品として扱えるなら、値上げや仕様変更、あるいは特定モデルの一時的な提供停止といった事態への耐性が上がります。実際、2026年前半はフラッグシップモデルの提供状況が短期間で動く場面が続きました。OpenAI は次世代の GPT-5.6 系を限定提供で先行公開し、Anthropic は Claude Sonnet 5 を新たな既定モデルに据え、Google は Gemini 3.5 Pro の一般提供を調整しています。モデル側がこれだけ動くなら、開発環境はモデルに縛られない疎結合であるほど有利です。
競合メディアがまだ十分に書けていない論点は、この「疎結合が調達戦略になる」という視点だと考えます。多くの解説は、どのエージェントが賢いかという単体比較に寄りがちです。しかしEC運営で効いてくるのは、単体の賢さより、環境ごと乗り換えずにエージェントだけ入れ替えられる柔軟性のほうです。ACPは、その柔軟性をプロトコルの層で担保しようとしている点で、比較記事とは違う軸の価値を持ちます。
もう一段先を見ると、開発を束ねるACPと、購買を担うエージェント商取引の規格が、いずれ同じ店舗の中で隣り合う未来が見えてきます。開発側では複数エージェントを束ね、販売側ではAIエージェント経由の購入に対応する、という二正面の対応です。両者は別の規格系統ですが、店舗の実装としては地続きになります。この全体像を早めに把握しておくことが、2026年後半のEC事業者の準備として効いてくると見ています。ここは現時点の見立てであり、規格の普及度は今後の各社動向で要確認です。
実務への落とし込みとしては、まず開発側の自動化で小さな成功体験を作ることをおすすめします。ACPやDevin Desktopのような環境は、いきなり全社の開発を載せ替えるためのものではなく、これまで手が届かなかった定型作業を1つずつ自動化していくための土台と捉えるほうが現実的です。手作業の月次集計を1本自動化し、その工数削減を数字で確認できれば、次にどの作業へ広げるかの判断がしやすくなります。エージェントの選択肢が増えた今こそ、賢いツール探しに時間を溶かすより、自社の一番面倒な作業を1つ選んで小さく試す動きが、結果的に一番早く成果につながると考えます。
よくある質問
Devin Desktop は無料で使えますか
旧 Windsurf からの移行は自動アップデートで行われ、既存ユーザーはそのまま Devin Desktop に切り替わりました。料金体系は個人プランから組織向けまで段階があり、無料枠の範囲や制限は時期で変わります。最新の条件はCognition 公式の案内で確認してください。まずは小さなタスクで挙動を試し、費用対効果を見てから利用範囲を広げる進め方が無難です。
ACPに対応していれば、どのエディタでも同じエージェントが使えますか
考え方としてはその方向です。ACPレジストリに登録されたエージェントは、ACP対応クライアントから呼び出せる設計になっています。ただし対応状況はエディタ側・エージェント側の双方で進行中であり、機能の細部に差が残る場合があります。実際に使う組み合わせで一度動作を確認してから本運用に載せるのが安全です。
プログラミングの知識がなくても使えますか
日本語の指示でスクリプトを生成させること自体は、コードを書けない担当者でも可能です。ただし生成されたコードが正しく動くかの検証、異常時の切り戻し、定期実行の設定には一定の理解が要ります。最初は社内のエンジニアや外部支援と組み、小さな自動化から慣れていく進め方をおすすめします。
楽天やAmazonの規約に触れる心配はありませんか
Devin Desktop 自体は開発環境であり、規約に触れるのはそこで作った処理の中身です。たとえば楽天のデータを扱うスクリプトでも、楽天市場外への不適切な送客を組み込まなければ、開発ツールとして使うこと自体に問題はありません。API利用の可否や各社の規約は個別に確認し、モールのガイドラインに沿った処理だけを自動化してください。
複数のエージェントを使うと費用が跳ね上がりませんか
対話的に少量使う範囲であれば、各社の月額プラン内で収まることが多いです。費用が増えるのは、大量データをバッチで繰り返し処理する従量課金の部分です。ここはトークン量に比例するため、処理対象を絞る、頻度を最適化する、効率の良いエージェントを選ぶといった調整で抑えられます。まず小規模に始めて、量が増える段階でコストを見直す運用が現実的です。
今すぐ導入すべきですか、様子を見るべきですか
エージェント商取引が本格化する前に、開発側の自動化で足場を作っておく意味は大きいと考えます。ただし全面移行を急ぐ必要はありません。まず手作業で数時間かかっている定型処理を1つ選び、テストデータで自動化を試すところから始めれば、リスクを抑えつつ効果を体感できます。そこで手応えを確かめてから、対象を広げる判断をするのが堅実です。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
