業務システムの保守や機能改修において、AIを活用してコードを生成する試みが広がっています。一方で、AIへの指示が増えるにつれて、開発者の端末でコンパイルやテストが重なり、作業が中断してしまうという新たなボトルネックも生じがちです。コードを書く作業だけでなく、それを動かして確かめる環境をどう整えるかが、AI活用の実効性を大きく左右します。
この課題に対して具体的な構成を示したのが、カナダのShopifyです。同社は2026年10月22日に公開した技術記事We gave AI agents a mobile dev environment (2026) - Shopifyにおいて、モバイルアプリ開発向けの遠隔実行環境「Remote Dev」の取り組みを発表しました。
手元端末の資源枯渇とLinux環境の制約
Shopifyでは、モバイルアプリ開発のタスクを並行して進めるエージェントワークフローを構築したものの、すぐに手元の開発端末の限界に直面したと報告されています。並行するワークフローが3〜4件に達しただけで、コンパイラーやシミュレーター、エミュレーターが資源を奪い合い、開発者のノートPCの限界に達してしまいました。また、端末のスリープによって処理が止まる事態も課題でした。
さらに、同社のRiverはLinux上で動作していたため、Swiftコードの編集自体は行えても、iOSアプリのビルドやテストを実行するには手元のノートPC環境に戻らざるを得ないという構造的な制約を抱えていました。AIに作業を委任する能力の拡大に、それを実際に実行・検証する環境の供給が追いつかなくなっていたのです。
遠隔MacとLinux VMを組み合わせた使い捨ての実行基盤
この制約を解消するために構築されたのが「Remote Dev」です。各Riverセッションに対して専用の独立した環境を割り当てる構成をとっています。
モバイル特有の事情として、iOSシミュレーターの実行にはmacOS環境が必要となる一方、クラウド上の仮想環境でAndroidエミュレーターを動かすにはネストされた仮想化が求められます。macOSではこの構成が標準で難しいため、Shopifyは開発環境とiOSシミュレーターを備えた遠隔のMac群を用意しつつ、ネスト仮想化を有効にした別のLinux仮想マシン上のAndroidエミュレーターへ接続するアプローチを採用しました。エージェントはMac側で両プラットフォーム向けにビルドを行い、同じSSHセッション内から双方のテストを実行します。
また、大規模なリポジトリにおける環境構築時間の長さに対処するため、最新のmainブランチの取得、ツールの導入、アプリのビルド、キャッシュの準備を事前に完了させたMacをプールとして待機させる運用をとっています。セッションが終了するとそのMacは破棄されて新しい代替マシンが準備され、待機中のマシンも定期的に最新コードで入れ替えられます。
実行処理と作業環境を切り離す「Aquifer」の設計思想
Remote Devのように作業環境を使い捨てとして扱う構成を理解するうえで、参考になるのがShopifyのエージェント基盤「Aquifer」の設計です。同社が2026年5月28日に公開した技術解説Under the River (2026) - Shopifyでは、Riverの背後にある抽象化設計が詳しく説明されています。
Aquiferでは、会話履歴を保持する「セッション」、モデルを呼び出して推論を行う「ハーネス（実行処理）」、そして実際にコードの変更やコマンドを実行する「サンドボックス（作業環境）」を明確に分離しています。「ハーネスはサンドボックスの外に置かれ、エージェントはコードが動く場所には住まない」という原則を徹底することで、作業環境が破棄されても会話コンテキストが失われない構成を実現しました。
セッションの作業履歴はプロセスのメモリではなくPostgresに保持されているため、プロセスが終了して次の対話で新たな実行セルが起動しても、過去の経緯をそのまま引き継ぐことができます。実行処理や作業環境が破棄されても会話の文脈を保つというこの考え方は、Remote DevでセッションごとにMacを破棄・交換する運用を理解するうえでも通底する設計思想と捉えられます。
修正前後の記録とブラウザからの「Live Preview」
コードがコンパイルを通過したからといって、意図通りに画面が動作しているとは限りません。Remote Devでは、エージェントがアプリ画面の要素を操作し、スクリーンショットや録画を取得する仕組みが組み込まれました。不具合の修正時には、問題を再現した修正前の動作を記録し、修正を適用した後に同じ操作手順を再実行して修正前後の状態を提示できます。
さらに、開発環境を持たないメンバーでも動作確認ができるよう「Live Preview」が導入されました。遠隔環境で起動しているiOSシミュレーターやAndroidエミュレーターの画面をWebSockets経由でブラウザに配信し、ブラウザ上でのタップや入力操作を遠隔側へ送り返す仕組みです。
各セッションには両OSのLive Previewが自動で用意され、リンクを共有すれば複数人が同じ動作中の画面を見て確認や共同作業を行えます。手元にビルド環境を持たないディレクターや担当者でも、専用ツールの準備なしにブラウザから動作中のアプリを操作できる環境が整えられました。
既存の社内Web業務システムに応用する視点
Shopifyの構成はモバイルアプリに特化した大規模な基盤ですが、その根底にある「コードの修正」「自動テストの実行」「人による動作確認」を分離するという発想は、国内の既存Web業務システムの改善にも応用できます。
例えば、国内卸売業における社内の受注管理システムで、注文検索画面の表示不具合を修正する場面を想定してみます。AIに改修を任せる際、本番環境や開発端末を直接触らせるのではなく、AIが変更したブランチごとに分離された検証環境を立ち上げ、テストデータを用いた検索操作を可能にする確認用リンクを発行するアプローチが考えられます。
このような仕組みを自社で検討する場合、いきなり大掛かりな遠隔インフラを構築するのではなく、次のような観点で段階的に整理することが有効です。
まずは、直近の改修作業において「環境の準備」「ビルドやテストの待ち時間」「関係者による確認作業」のどこに最も時間がかかっているのかを切り分けます。次に、本番データを直接参照せずに動作確認が行えるよう、検証対象とする画面と再現手順を絞り込みます。そのうえで、確認を行う業務担当者がどのような手段で画面にアクセスできるか、検証環境を破棄した後もコード差分やテスト結果、画面キャプチャの記録をどこに残しておくべきかを整理していきます。
実際のWebシステムでは、ホスティング環境やCIツールの仕様、既存の認証基盤とプレビュー環境との接続方式、テスト用データの作成手順など、システム固有の条件に応じた個別検討が必要になります。手元の開発環境を圧迫せずに、関係者が安全に挙動を確かめられる導線をどう作るかが鍵となります。
検証環境の整理とAI活用の進め方について
AIを活用した開発フローを実務に定着させるためには、コード生成ツールの導入だけでなく、周辺のテスト実行基盤や確認手順を含めた業務全体の設計が欠かせません。
株式会社デノフでは、デノフのサービス案内に記載の通り、Webサイトや業務システムの設計・開発・運用保守から、業務の整理、AIを活用する業務の選定、導入後の定着支援までを一貫して提供しています。
「AIを活用したいが、手元での確認やビルドの手間が減らない」「既存のWeb業務システムにおいて、担当者が安全にプレビュー確認できる環境を整えたい」といった課題をお持ちの際は、現行の改修フローの整理や試行範囲の選定からお手伝いいたします。具体的な連携方法や実装範囲のご相談は、デノフへの相談窓口よりお気軽にお問い合わせください。
