本文へスキップ

開発・業務アプリ編：AIがコードと端末操作を任される現場

公開日 最終更新日 解説
share
開発・業務アプリ編：AIがコードと端末操作を任される現場

AIにコードを書かせる話は、もう珍しくなくなった。Apsara Conference 2026 の取材で撮った写真を見返して目に留まったのは、その先を扱う二つの展示だった。一つは无影 AgentBay の壁面で、AIが書いたコードを動かしたり、スマートフォンのアプリを操作したりするための「隔離された作業場」を掲げていた。もう一つは Qoder IDE の実機画面で、開発の仕事を「Quest」という単位でAIに渡していく様子が映っていた。

二枚の写真には、同じ問いが別の角度から写っている。AIに仕事を任せるとき、そのAIはどこで動くのか。人は何を渡し、どこで確かめるのか。以下、写真に写っているものを確かめ、公式ドキュメントでその意味を補ったうえで、日本の職場で何が変わりそうかを筆者の見立てとして書いていく。

写真1　无影 AgentBay の壁面

无影 AgentBay の展示壁面

写真1：无影 AgentBay の展示壁面（Apsara Conference 2026）。中央の画面は「一键解锁Agent超级应用场景（ボタン一つで、エージェントの多彩な活用場面を体験）」、その下に「按压桌面按钮体验不同场景（卓上のボタンを押して、さまざまな場面を体験）」とある。左上の画面は「AI Sandbox for Mobile Use Agents」、右上と右下の画面は「AI Sandbox for Code Execution Agents」と読める。左下の画面は、手前に立つ来場者に一部が隠れている。

写真から読み取れること

白い壁の上部に、光る文字で「无影AgentBay」とある。无影（Wuying）は、Alibaba Cloud がクラウドPCの製品群に使っている名前だ。その名前とAIエージェント向けの製品名が、一枚の看板に並んでいる。

中央の大きな画面の太字は「一键解锁Agent超级应用场景」。「超级应用场景」を字面どおりに訳すと大げさになるので、ここでは「ボタン一つで、エージェントの多彩な活用場面を体験できる」という呼びかけとして読んでおく。その下の細い帯には「按压桌面按钮体验不同场景」、卓上のボタンを押していろいろな場面を試してほしい、という案内がある。

中央の画面の右下の壁には「商品推荐（Product Recommendation、商品のおすすめ）」という小さな表示があり、その下に丸い枠で囲まれた部品が付いている。さらに下の説明文は字が小さく、写真では全文を読めない。これが案内にある卓上のボタンなのか、別の仕掛けなのかは、写真からは判断できない。押したあと画面がどう切り替わったのか、実演がうまく動いたのか、来場者がどう受け止めたのかも記録がないので、ここでは書かない。

中央の画面を、四つの画面が囲んでいる。左上は「AI Sandbox for Mobile Use Agents」、スマートフォンを操作するエージェントのためのAIサンドボックスだ。右上と右下は、どちらも「AI Sandbox for Code Execution Agents」、コードを実行するエージェントのためのAIサンドボックスとある。左下の画面は手前に立つ来場者に半分ほど隠れ、読めるのは「AI Sandbox」と「Code Executio」までだが、文字の配置は右側の二面と同じだ。写真で名前を確かめられる用途は、スマートフォンの操作とコードの実行の二つになる。

壁に「サンドボックス」と書いてあること

サンドボックスは、プログラムを周囲の環境から切り離した囲いの中で動かす仕組みだ。囲いの中からは、許されたファイルや通信にしか手が届かない。

展示の壁がこの言葉を大きく掲げていたのは、AIに実際の作業をさせるときの不安がそこにあるからだと思う。AIが生成したコードは、動かすまで何をするか読み切れない。AIがスマートフォンのアプリを操作するなら、どの画面で何を押すかを前もって全部決めておくこともできない。社員のPCや社内のサーバーでそのまま動かすと、ファイルを消したり、想定外の宛先と通信したり、ログイン済みのサービスで意図しない操作をしたりしても止めにくい。

AIに作業をさせる段階に入ると、何をさせるかと同じくらい、どこで動かすかが問われる。AgentBay の壁面は、その問いへの答えの一つを製品の形で出していた。人が使うクラウドPCを作ってきたブランドが、AIのための作業場を同じ看板の下に並べている。写真だけでそれ以上は言えないが、クラウドPCの利用者として人に加えてAIも数え始めた、と読むことはできる。ここまでは筆者の解釈である。

公式ドキュメントが説明する AgentBay

AgentBay は何をする製品なのか。Alibaba Cloud の英語ヘルプの製品概要は、AgentBay を「AIエージェントのためのクラウドネイティブな実行基盤」と説明し、エージェントが操作する環境を四つ挙げている。クラウド上のブラウザを操作する Browser Use、Windows や Linux のデスクトップを操作する Computer Use、開発用の道具をそろえたクラウドの開発環境 Code Space、クラウド上の Android 環境である Mobile Use だ。中国語の製品ページも、ブラウザの自動操作、コード実行、デスクトップアプリの操作、モバイルアプリの自動化という同じ四つを挙げている。

写真1の「Mobile Use」は、四つ目とそのまま名前が合う。右側の二面にあった「Code Execution」は、中国語の製品ページが挙げる「代码执行（コード実行）」と同じ言葉で、英語ヘルプの区分でいえば Code Space に近い用途だろう。ただ、展示の画面と公式ドキュメントの製品区分が一対一で対応すると確かめたわけではない。確かなのは名前が重なっていることまでだ。

AgentBay は大会に合わせて出てきた新製品でもない。Alibaba Cloud の英語ブログには、2025年11月の日付で AgentBay を紹介する記事がある。すでに公開されている製品を、ボタンで試せる展示に仕立てたと見るのが自然だろう。

四つの環境を日本の職場の仕事に当てはめると、使い分けが見えてくる。Browser Use は、Webサイトからの情報収集、社内のWebシステムへの入力、画面のテストなど、ブラウザの中で完結する作業向けだ。Computer Use は、ブラウザでは動かない業務用のデスクトップアプリや、Windows 上の作業を想定している。Code Space は、AIが書いたコードを動かして結果を確かめる場所になる。Mobile Use では、スマートフォンのアプリを開き、画面を押し、表示を確かめる。

どの環境も、人が画面の前でやってきた作業を、クラウドの中の使い捨ての画面に移すものだ。人のPCやスマートフォンを借りずに、AI専用の画面を別に用意する。壁面が「サンドボックス」という言葉を前に出していたのは、この点を伝えたかったからだろう、と筆者は受け取った。

開発者向けの入口も公開されている。Alibaba Cloud は GitHub に AgentBay の公式 SDK（wuying-agentbay-sdk）を置いていて、README は「AIエージェントのために作られたクラウドサンドボックス」と説明する。使い方は単純で、環境の種類を指定して「セッション」を作り、その中でコードを実行したりブラウザを操作したりして、終わったらセッションを削除する。README のコード例も、セッションを作り、Python を一行実行し、セッションを消す、という三段で書かれている。製品概要は、SDK のほかに MCP（エージェントに道具を提供するための標準的な接続方式）での接続にも対応するとしている。

消える環境と、残す保存先

AgentBay のドキュメントを読むとき、最初に整理しておきたいのはデータの行方だ。

セッションそのものは使い捨てとして説明されている。製品概要は、セッションごとに資源とデータを隔離した独立のサンドボックスで動くと書く。中国語の製品ページには「会话级资源隔离，超时自动销毁」とあり、セッション単位で資源を隔離し、時間切れになれば自動で破棄するという意味だ。FAQ も、セッションが終わるたびに環境は初期化され、データは残らないと説明している。

とはいえ、毎回まっさらな環境では困る作業もある。社内のWebシステムに毎回ログインし直すのは手間だし、多要素認証があれば自動化はそこで止まる。そのためドキュメントは、ブラウザの状態を「コンテキスト」という保存先に残す仕組みを用意している。Cookie やブラウザの保存領域、設定、導入した拡張機能をコンテキストに書き戻し、次のセッションで同じコンテキストを指定すれば、ログインした状態から作業を再開できる、という説明だ。

環境は毎回消え、残したいものは明示的に作った保存先にだけ残る。AIに作業場を貸すときの基本の形として、筆者はこれを筋がよいと考えている。人のPCは使い続けるうちに、ログイン状態も一時ファイルもどこに何があるか分からなくなる。AIの作業場を使い捨てにすれば、前の作業の残りが次の作業に紛れ込むことは起きにくい。

気をつけたいのは、ログイン済みの Cookie がそれ自体、誰として操作するかを証明する資格情報だという点だ。コンテキストにログイン状態を残せば、業務システムの鍵をクラウドの保存先に置くことになる。今回参照したブラウザ永続化の説明ページには、その保存データをどう暗号化し、誰が使えるのかという記述が見当たらなかった。使う側は、残すアカウントの権限を最初から絞っておくことになる。

製品ページが掲げる企業向けの管理

中国語の製品ページには、企業での利用を想定した管理の方針も書かれている。社内のID基盤（SSO、LDAP、OAuth）と連携し、役割に基づくアクセス制御で、エージェントや道具、サンドボックスの資源に必要最小限の権限だけを与える。機密の資格情報は暗号化した管理サービスに保管し、実行時に必要な分だけ一時的な資格情報を取り出す。操作とアクセスの記録は追記のみの形で残し、改ざんできないようにする。さらに、社内の標準作業手順を非公開の「Skill」としてまとめ、必要に応じてサンドボックスに組み込めるという。

いずれも製品ページが掲げる方針で、設定手順や仕組みの詳細を説明した技術文書は、今回の調査では確認できていない。それでも向かっている先は読み取れる。AIの作業場を貸すサービスは、場所だけでなく、誰の権限で入り、何を持ち込み、何を記録するかまでまとめて引き受けようとしている。

写真2　Qoder IDE の実機画面

Qoder IDE の展示画面

写真2：Qoder IDE の展示（Apsara Conference 2026）。壁の表示は「编程Qoder IDE（プログラミング用の Qoder IDE）」。画面左に「+ New Quest」と Quest の一覧が並ぶ。手前の小さな案内板には「Qoder IDE，每个开发者的标配（すべての開発者の標準装備）」とある。画面右側と右端は一部を塗りつぶしている。画面には会場の人影が映り込んでいる。

画面に並んでいた仕事

写真1がAIの動く場所を扱った展示なら、写真2はAIに何を渡すかを扱った展示だ。

壁には「编程Qoder IDE」、プログラミング用の Qoder IDE とある。IDE は統合開発環境のことで、コードを書き、動かし、直すための作業画面を指す。画面の左上に「+ New Quest」のボタンがあり、その下に「Quests」という見出しと一覧が続く。一覧はフォルダーごとにまとまっていて、写真から読める項目は次のとおりだ。

「qtech-doc」というフォルダーの下に「ai coding ux review」。この行には「now」の表示と、進行中を示すような円形の印があり、マウスのカーソルが重なっている。次の「qoder」フォルダーの下には「Add Kanban Session List」「Canvas storage and workspace」「Canvas HMR Remount and DevT」（末尾は切れている）、「Vitest RTL component testing」「Review MR 434a2725」が並ぶ。一番下には「qoder-cli」というフォルダー名が見える。

画面の右半分は文章の出力らしき領域で、「review this mont」「workspaces). su」といった途中で切れた英文、「Bolt/Replit ai」で始まる箇条書き、「Emerg」「Patt」などの見出しの断片がある。写真の右端を塗りつぶしているうえ画面自体も切れているので、何の出力なのかは分からない。

一覧の項目を日本語で読む

項目名を、開発の仕事として読み直してみる。

「ai coding ux review」は、AIコーディングの使い勝手（UX）の見直し。「Add Kanban Session List」は、カンバン形式の画面にセッションの一覧を加える作業。「Canvas storage and workspace」は、Canvas と呼ばれる画面の保存と作業領域の実装だろう。「Canvas HMR Remount and DevT…」の HMR はホットモジュールリプレースメントの略で、ブラウザを再読み込みせずに、変更した部品だけを差し替える開発の仕組みを指す。末尾の「DevT」は切れていて、何のことかは決められない。「Vitest RTL component testing」は、テストの道具 Vitest と React Testing Library で画面部品のテストを書く作業。「Review MR 434a2725」は、434a2725 という識別子の付いたマージリクエスト（変更の取り込み依頼）のレビューである。

並べると、どれも関数を一つ書くより大きく、開発チームならチケット一枚で扱うくらいの仕事だ。調査、機能の追加、テストの作成、他人の変更のレビューが、同じ一覧に同じ形式で並んでいる。フォルダー名に「qoder」「qoder-cli」があるので、Qoder 自身の開発の作業名にも見えるが、展示用に用意したデータかもしれず、どちらとも言えない。各 Quest が成功したのか、生成されたコードの質がどうだったのかも、写真からは分からない。

補完から依頼へ

写真2で目を引くのは、AIがコードの続きを提案する画面になっていないところだ。

これまでのAIコーディング支援は、人が一行ずつ書く横でAIが続きを提案する「補完」が中心だった。提案を採るかどうかは人が一行ずつ決め、実行するのも人だった。写真2の画面では、作業そのものが Quest という単位で並ぶ。画面の前の人の役目は、仕事を切り出して渡し、戻ってきた結果を確かめることに移っている。

公式の説明もこの方向を打ち出している。2026年6月に Alibaba Cloud のブログで公開された Qoder 1.0 の紹介記事は、作業画面を二つに分けている。エージェントと一緒にコードを書く Editor Window と、エージェントにコードを書かせる Quest Window だ。後者は、タスクの定義、状態の追跡、成果物の確認、知識の検索をまとめた「エージェントの指令所」と説明されている。同じ記事は人の役割を三つにまとめる。タスクと方向と受け入れ条件を決める「定義」、エージェントを管理し、資源と境界を決める「舵取り」、結果を確かめて取捨選択し、方向を直す「判断」である。

Quest の利用者向けドキュメントの標語は「Define the goal. Review the result.」、目標を決めて結果を確かめる、だ。写真2の一覧は、この標語をそのまま画面にしたように見える。

任せ方を調整する仕組み

任せるといっても、白紙で丸投げする作りにはなっていない。Qoder のドキュメントには、任せ方を調整する仕組みがいくつか書かれている。

まず、担い手の数を選ぶ。Quest を始めるとき、一つのエージェントが要件の確認から実装・検証まで進める Agent mode と、複数のエージェントが並行して協働する Experts mode のどちらかを選ぶ。この選択は開始時に決め、途中では変えられない。

コードを書く前に方向を確かめる手段もある。複雑なタスクでは、エージェントがまずプロジェクトの文脈を読み、仕様書（Spec）を作ってから実装に入る方式を選べる。人はコードができる前に方向が合っているかを見られる。試作のように速さを優先するときは、仕様書を飛ばしてもよい。

作業させる場所も選べる。今の作業ディレクトリでそのまま動かす Local と、Git の worktree（一つのリポジトリから別の作業ツリーを取り出して並行作業する機能）に分けて動かす Worktree だ。ドキュメントは Worktree を、変更を隔離してメインのブランチを安全に保つ方法として、規模の大きい作業に勧めている。実行中に作業領域を元に戻す Revert もあるが、Experts mode では使えないとある。

端末のコマンドをどこで止めるかも決まっている。Terminal and Sandbox の説明によると、依存パッケージの導入やテストの実行のような日常のコマンドはそのまま実行される。ファイルの削除、ディスクの操作、権限の管理、ネットワークの設定といった危険の分類に当たるコマンドや、利用者が禁止の一覧に入れたコマンドは、Agent mode では実行前に止まって人の承認を求める。Experts mode では、危険の可能性があるコマンドを確認なしでサンドボックスの中で実行し、そこで済まなければ権限の引き上げを人に求めることがあるという。サンドボックスの中からは作業ディレクトリにしか書き込めず、SSHの鍵を置く場所のような機密の場所は見えない、とも書かれている。ネットワークは今のところオンかオフの切り替えだけで、ドメイン単位の細かい制限は予定とされている。

通して見ると、Qoder がどこに線を引いているかが分かる。開発者のPCの中で、作業ツリーとコマンドの単位で線を引き、危険な操作の手前で人を呼ぶ。人の出番は、目標と受け入れ条件を書くとき、仕様書を確かめるとき、危険なコマンドの前、差分を取り込むかどうか決めるときに集まる。

この仕組みが守っているのは作業ディレクトリの外と機密の場所で、作業ディレクトリの中は守備範囲に入らない。作業ディレクトリに本番のAPIキーを書いた設定ファイルがあれば、サンドボックスはそれを守らない。ネットワークを許可すれば、宛先は絞れない。ドキュメント自身も、コンテナの中で動かす場合などは隔離が限られると書いている。任せる前に作業場を片付けておくのは、人の側に残る仕事だ。

一覧の一行を任せてみる

写真2の一覧にあった「Vitest RTL component testing」に近い仕事を例に、公式ドキュメントで確認できた仕組みだけで任せる流れを組み立ててみる。以下は説明のための仮の場面で、展示の実演を再現したものではない。

開発者は新しい Quest を作り、目標と受け入れ条件を書く。「カンバン画面のセッション一覧の部品に、Vitest と React Testing Library でテストを加える。一覧が空のとき、十件あるとき、読み込み中のときの三つの状態を確かめること」。小さな仕事なので Agent mode を選び、作業場所は Worktree にして、変更をメインのブランチから切り離しておく。仕様書を先に作る設定にすれば、エージェントはまずテストの方針をまとめて出してくる。開発者はここで、既存のテストの書き方と合っているかを見る。

エージェントは依存パッケージを入れ、テストを書き、走らせる。ここまでは日常のコマンドとして確認なしで進む。途中で一時ファイルをまとめて削除しようとすれば、ファイル削除の分類に当たるので、実行の手前で止まって承認を求めてくる。テストが通ったら、開発者は差分を見て取り込むかどうかを決める。方向が違っていれば、作業領域を元に戻してやり直す。

この流れで人が判断するのは、目標と受け入れ条件を書くとき、方針を確かめるとき、危険なコマンドの手前、最後の取り込みの四か所になる。最初が公式ブログの言う「定義」、真ん中の二つが「舵取り」、最後が「判断」にほぼ当たる。この四か所で判断できる人がいなければ、Quest はAIに投げた仕事を並べただけの一覧になってしまう。

人が席を外している時間

一覧の「ai coding ux review」に付いた「now」は、その Quest が動いている最中だという表示に見える。長い仕事を任せれば、承認を求められたときに開発者が席にいるとは限らない。

Qoder のドキュメントは、これに二つの手段を用意している。一つは Remote Control で、スマートフォンの Qoder Mobile から、PCで動いている Quest の進み具合を見て、承認し、判断が要る場面で指示を返せる。ただし、PCで Qoder IDE が起動したままで、スリープしないことが条件になっている。もう一つはコマンドラインの Qoder CLI にある Cloud Mode で、タスクを Qoder が管理するクラウドの仮想マシンで動かす。手元の端末を閉じてもタスクは続き、GitHub のリポジトリへの権限を Qoder に与えて使う。コミットしていない手元の変更は読めない、とも書かれている。

二つを比べると、同じ「席を外している間も動かす」でも、使う権限の出どころが違う。Remote Control では、エージェントは開発者のPCの上で開発者の権限のまま動き続ける。Cloud Mode では、Qoder のクラウドで、Qoder に渡したリポジトリの権限で動く。どちらが安全とは一概に言えないが、誰にどの権限を渡しているかは別物になる。選ぶ側はこの違いを分かったうえで決めたい。

コードの外へ広がる Qoder

Qoder の公式ドキュメントを読むと、製品の範囲は開発の画面にとどまらない。製品の一覧には IDE と CLI のほかに、API でエージェントに仕事を任せる Cloud Agents や、日常の業務を任せるためのデスクトップアプリ QoderWork が並ぶ。QoderWork の説明ページは、文書や表計算、資料の読み書き、ブラウザでのサイト操作やフォーム入力、デスクトップアプリの操作までを任せる対象に挙げている。触れるのは利用者が明示的に許可した作業フォルダーだけで、それ以外に触れる必要があるときは先に許可を求める、とも書いている。

記事の題にある「業務アプリ」との接点はここだ。仕事を切り出して渡し、結果を確かめるという開発者向けの形が、コードの外の事務作業にも持ち込まれようとしている。写真2の展示は開発の画面だったが、その考え方は開発部門の中だけで終わりそうにない。

二枚の写真を並べて見えること

写真1と写真2は別々の製品で、本稿でも両者を組み合わせた製品としては扱わない。展示でも公式ドキュメントでも、Qoder から AgentBay の環境を呼び出す構成は示されていない。

それでも二枚を並べると、共通する前提がある。AIは書いたあと、実行し、操作し、人がその場にいない時間も動き続ける。そうなると、隔離された作業場と、誰の権限で動くかの切り分けは、あれば便利な機能の域を出て、任せるための前提条件になる。

違いもはっきりしている。Qoder は開発者のPCの中に線を引き、コマンドごとに人の承認を挟む。AgentBay は作業場そのものをクラウドに出し、セッションごとに作っては消す。人の承認の仕組みがドキュメントにはっきり書かれているのは Qoder のほうで、AgentBay で確認できたのは、ブラウザの動きをリアルタイムで見る機能とセッションの録画までだった。AgentBay がエージェントに操作の「場所」を貸す基盤だと考えれば、これは不思議ではない。どの操作の手前で止めるかは、その場所を呼び出すエージェントの側で決める。AgentBay を使う開発者は、たとえば送信ボタンを押す前に画面を人に見せて承認を得る段を、自分のエージェントに組み込むことになる。

鍵の置き場所も違う。Qoder をPCの上で使えば、エージェントが使うのは開発者のPCの権限で、Cloud Mode なら Qoder に渡したリポジトリの権限になる。AgentBay では、作業場を呼び出すためのAPIキーと、コンテキストに残したログイン状態の二つが鍵になる。どの形でも、AIに仕事を任せれば誰かの鍵をAIに預けることになる。展示の写真は鍵の話を正面からは扱っていないが、二枚を並べると、その置き場所の設計の違いが見えてくる。写真1は任せる場所を、写真2は任せ方を見せていた、とまとめてもいいだろう。

ここからの見立て

ここからは、展示と公式ドキュメントを踏まえた筆者の見解と、条件付きの予測である。確定した事実ではないので、どんな条件がそろえばそうなるかを添えておく。

依頼を書く力と受け入れ条件

写真2のような Quest の一覧が日常の画面になれば、開発者の仕事の重心は、コードを書くことから、仕事を切り出し、受け入れ条件を書き、結果を確かめることへ寄っていくだろう。

条件は二つある。受け入れ条件を具体的に書けるチームであること。そして自動テストがそろっていて、AIが作った変更を機械的に確かめられることだ。「いい感じに直しておいて」としか書けない依頼や、テストのないコードベースでは、AIに渡した仕事の結果を人が一行ずつ読み直すことになり、任せた意味が薄れる。AIへの依頼が広まるほど、テストと仕様を整えてきたチームとそうでないチームの差は開くと筆者は見ている。

同じことは開発の外にも及びそうだ。Qoder は QoderWork で事務作業へ、AgentBay はブラウザやデスクトップの操作へと範囲を広げている。開発者がAIに仕事を渡す形と、事務の担当者がAIに仕事を渡す形は、仕事を切り出し、作業場を用意し、止める場所を決め、結果を確かめるという同じ手順に近づいていくと考えている。ただし開発にはテストという確かめ方があるのに対し、事務作業には、何をもって完了とするかが担当者の頭の中にしかない仕事が多い。その基準を文章にする習慣が根づかなければ、AIに任せられる事務は、手順が完全に決まった一部の定型作業にとどまるだろう。

作業場は借りて使い捨てる資源に

写真1のように、クラウドPCの事業者がAI用の作業場を製品として並べ始めた。AIを動かす場所が、社員のPCやその場しのぎのサーバーから、借りて使い捨てる資源へ移っていく兆しだと筆者は読んでいる。

この流れが広がるには、少なくとも二つの条件が要る。一つは、データの置き場所と提供地域が、使う企業の規程に合うこと。もう一つは、費用を見積もれることだ。公式ドキュメントによると、AgentBay の課金は同時に使うセッションの数や通信量、保存容量など複数の要素の組み合わせで決まる。セッションが時間切れで自動破棄されるまでの時間や、提供段階と提供地域の一覧は、今回参照した文書からは読み取れなかった。日本の企業が本番の業務で使うなら、ここは事業者に直接確かめることになる。

最初に使われる場面としては、スマートフォンのアプリの検証を挙げておきたい。日本の企業でも顧客との接点の多くはアプリにあるが、画面の数も端末の種類も多く、動作確認は人手に頼る部分が大きい。クラウドの Android 環境でAIがアプリを操作できるなら、リリース前の動作確認や画面の巡回のような繰り返しの多い作業から変わっていくと見ている。そのためには、対象のアプリがクラウドの環境で問題なく動くこと、AIの操作が失敗したときに録画や記録で何が起きたかを追えることが条件になる。本番の顧客アカウントでの操作をAIに任せるのは、さらにその先だろう。

詰まるのは承認の設計

AIに任せる範囲が広がるほど、止める場所の設計は難しくなる。何でも人に確認させれば任せた意味がなくなり、何も確認させなければ事故を止められない。

Qoder は、危険なコマンドの分類、利用者が足せる禁止の一覧、AIによる意味の判断を組み合わせて止める場所を決めている。現実的なやり方だと思うが、AIの判断が入る以上、どのコマンドで止まるかを前もって完全には予測できない。AgentBay では、止める段そのものを利用者が作る。どちらでも、自社として必ず止めたい操作は何かを先に言葉にできる組織ほど、任せる範囲を安心して広げられるはずだ。今後一、二年のAI導入で差がつくのは、モデルの性能よりこの承認の設計だろうと筆者は予想している。ただし、製品側の承認機能が大きく進み、業種ごとの標準の設定が整ってくれば、この差は縮む。

日本の職場にとっての意味

ここまでの話を、日本企業の仕事に引き寄せてみる。

受託開発や、システム開発を外部に委託している企業では、誰がコードを書いたかより、どの条件で受け入れたかが重くなる。AIが Quest としてテストを書き、変更を作り、レビューまで下書きするようになると、検収の基準が曖昧なままではAIの成果物も人の成果物も確かめようがない。受け入れ条件と自動テストを契約や社内規程の側から整えておくことが、AI活用の前提になっていく。

情報システム部門には、AIの作業場の管理という仕事が増える。社員が手元のPCでAIに端末操作を任せれば、そのAIは社員と同じ権限を持つ。クラウドのサンドボックスを使えば作業場の中身は切り離せるが、ログイン状態やAPIキーといった鍵の置き場所が増える。どちらにしても、AIにどの鍵を持たせるかを棚卸しし、権限を絞ったAI専用のアカウントを用意する地道な作業が要る。

業務の現場では、社内のWebシステムからの定型的な出力や、アプリの動作確認のように、手順がはっきりしていて繰り返しの多い作業から任せ始めるのが現実的だろう。たとえば次のような流れが考えられる。以下は説明のための仮の場面で、実在の導入例ではない。

ある会社の情報システム部門が、社内の受発注システムについて、閲覧と帳票出力だけができるAI用のアカウントを作る。初回だけ人がそのアカウントでログインし、ログイン状態をクラウドの保存先に残す。毎朝、エージェントは使い捨ての作業場を立ち上げてその保存先を読み込み、前日の未処理の注文一覧を書き出して、作業場を消す。注文の取り消しのような書き込みを伴う操作は、画面を人に見せて承認を得てから実行する。この承認の段はAI側のプログラムに組み込む。毎回の操作は録画で残し、あとから確かめられるようにする。

この場面で手間がかかるのは、技術の部分より準備のほうだ。アカウントの権限を最初から絞ること、止める場所を先に決めること、記録を残すこと。どれも展示の写真には写っていないが、展示が示す方向へ進むなら避けて通れない。

検討を始める前に確かめたいこと

今回参照した公式ドキュメントからは読み取れなかったものの、日本の企業が検討を始めるなら確かめておきたい点がある。

AgentBay のようなクラウドの作業場なら、まず提供段階と提供地域だ。どの地域のデータセンターで作業場が動き、コンテキストに残したログイン状態や作業の記録がどこに保存されるのか。個人情報や取引先の情報を扱う業務では、選定の入口でここを確かめる必要がある。次に、セッションが時間切れで自動破棄されるまでの時間。長い作業を任せるなら、途中で作業場が消えたときにどこからやり直すかを、あらかじめ設計に入れておきたい。それから、人が途中で操作を引き継げるかどうか。ドキュメントで確認できたのはライブ表示と録画までで、AIが迷ったときに人が代わって操作を続けられるかは、今回の調査では分からなかった。

Qoder のような開発の道具なら、作業ディレクトリの中に何が置かれているかの点検が出発点になる。サンドボックスは作業ディレクトリの外を守る仕組みなので、中にある秘密は守らない。本番環境への接続、パッケージの公開、履歴の強制的な書き換えのように、自社として必ず止めたいコマンドを禁止の一覧に入れられるかも確かめたい。スマートフォンから承認する機能を使うなら、そのスマートフォンのアカウントをPCと同じ水準で守れるかも問われる。

どれも製品の欠点を探す作業ではない。どの製品でも、ドキュメントに書かれていないことを確かめてから任せる、という普通の手順である。展示がよくできているほど、この手順は飛ばしたくなるものだ。

AIに開発と業務操作を任せるための当社の考え方

最後に、この取材を踏まえた当社（Metelix）の考え方を記しておく。

当社は、世界で生まれている技術と日本の現場が持つ業務の知見を、実際に仕事を任せられる形へつなぐことを目指している。写真1と写真2からは、AIに仕事を任せるための部品がそろい始めていることが分かる。ただ、部品がそろうことと、ある会社のある業務で安心して任せられることの間には、まだ距離がある。当社が担おうとしているのは、その距離を詰める仕事である。

入口になるのは評価と選定だ。AIの作業場や開発支援の製品は、国内外で次々に出てくる。同じ「サンドボックス」という言葉でも、何を隔離し、何を守らないかは製品ごとに違う。本稿でしたように、公式ドキュメントに書かれていることと書かれていないことを分けて読み、提供地域や提供段階、データの行方を確かめたうえで、目的に合うものを選ぶことが、最初の一歩になる。

選んだあとには、業務への接続がある。AIに渡す仕事を切り出し、受け入れ条件を書き、どの操作の手前で人が確かめるかを決める。AI用のアカウントの権限をどこまで絞るかを、既存のシステムと業務手順に照らして設計する。前の節で「依頼を書く力」と「承認の設計」として書いた準備を、顧客の業務に合わせて一緒に進めることを目指している。

導入してからも仕事は続く。業務の手順が変われば止める場所も変わり、製品の仕様が変われば設計を見直すことになる。記録を見ながら任せる範囲を少しずつ広げていく、継続的な見直しも、この仕事に含まれると考えている。

もう一つ考えているのが、現場の知見の再利用である。ある業務でAIに任せる手順や、止めるべき操作の一覧がうまく定まれば、似た業務を持つ別の現場でも役に立つ。AgentBay の製品ページが、社内の標準作業手順を「Skill」としてまとめる考え方を掲げていたように、現場の知見を再利用できる形に整えることは、この領域全体が向かっている方向でもある。当社も、顧客との取り組みから生まれた知見を、顧客の了解と権利の範囲で、次の取り組みに生かせる形へ整えていくことを目指している。

進め方としては、手順が決まっていて、失敗しても影響が小さく、結果を確かめやすい業務を一つ選ぶところから始める。その業務で、AIに渡す依頼の書き方、止める場所、残す記録を決め、実際に動かし、人が確かめた結果を次の設計に戻す。この往復を小さく重ねていくのが、展示で見た技術を自社の仕事に移すための現実的な道筋だと考えている。

むすび

无影 AgentBay の壁面は、AIが働くための作業場を、人のためのクラウドPCと同じ看板の下に掲げていた。Qoder IDE の画面には、開発の仕事を一つずつAIに渡していく一覧が映っていた。どちらの写真にも、AIが仕事をやり遂げた場面は写っていない。写っているのは、任せるための場所と、任せるための画面だ。

AIがコードと端末操作を任される現場は、展示の上ではすでに形になりつつある。そこで問われるのは、AIの賢さと同じくらい、人が何を渡し、どこで止め、どの鍵を預けるかを決められるかどうかだろう。展示で見た部品を自分の職場の仕事につなぐには、まずその三つを自社の言葉で書き出すところから始めることになる。

参考資料

本文で参照した公開文書は次のとおり。いずれも2026年9月27日時点で参照した。製品の仕様や提供条件は変わりうるため、導入の検討にあたっては最新の原文を確認されたい。展示の記述は、筆者が取材で撮影した写真1・写真2に基づく。

記事情報

取材・執筆・編集株式会社Metelix
公開日
最終更新日
分類解説（Apsara 2026・AI開発・業務アプリ）
利害関係本記事は、Apsara Conference 2026の展示と公開文書をMetelixが取材・編集した技術解説です。数値は特に断りのない限りベンダー提示値であり、Metelixによる測定値ではありません。
検証方法公開文書の記述は、2026年9月25日（日本時間）に公式サイト・公式ヘルプから取得し、製品名・機能名・数値などの主要な記述が公開文書に含まれることを確認しました。展示の記述は2026年9月の現地取材で確認した提示内容で、測定条件は示されていません。
評価時点展示の取材は2026年9月（杭州・現地）。公開文書の閲覧日は2026年9月25日（日本時間）。内容と提供段階は閲覧時点のもので、今後変わる可能性があります。

関連記事

改訂履歴

初版公開
写真説明を更新
share

AIトランスフォーメーション

AIに任せる仕事の整理から始めませんか。

任せる仕事の整理を相談するAIトランスフォーメーション
コラム一覧へ