コンピュータを操作するAIエージェントでは、画面のスクリーンショットを解析し、クリックする位置を判断してマウスやキーボードを操作する手法が広く使われている。しかし、この方法は画面を頻繁に撮影してマルチモーダルモデルに入力する必要があり、大量のトークンを消費する。例えば、1920×1080ピクセルの画面を毎ステップ解析する場合、表計算ソフトの特定のセルを変更するだけでも、メニューの選択や画面遷移に何度も操作が必要になる。描画の遅延やわずかな座標のずれによって、作業が失敗することもある。
一方、シェルコマンドやスクリプトだけでは、画面上のレイアウト調整や、動的に変化する描画キャンバスの編集には対応しにくい。そのため、従来はGUI操作とコード実行を組み合わせるために、外部のルーターや複数の専門エージェントを用いる構成が試みられてきた。ただし、こうした仕組みはモデル間の呼び出しや情報の受け渡しが増えるため、処理の遅延や文脈の引き継ぎが課題になる。
Microsoftの研究チームが公開した「Mage-VL-Cowork」は、この問題に対して異なるアプローチを採用した。40億パラメータ（4B）の比較的小型なビジョン言語モデル（VLM）に、画面操作とターミナル操作の両方を学習させ、状況に応じて使うツールをモデル自身が判断する仕組みだ。モデルの重みはHugging Faceで公開されており、ライセンスはApache-2.0となっている。AIモデルの公開状況を追跡するAI Trackerは、米国東部夏時間の2026年10月30日午前8時20分に公開重みを検知したと記録している。ただし、これは外部サービスによる検知時刻であり、Microsoftが正式に発表した時刻を示すものではない。
今回の研究で重要なのは、小型モデルに2種類の操作手段を与えたことだけではない。どちらのツールをいつ使うべきかを学習させる方法や、学習データを生成する環境の設計によって、操作の成功率と効率を大きく改善したと報告している点だ。
GUI操作とシェル実行を単一モデルが使い分ける仕組み
Mage-VL-Coworkの最大の特徴は、グラフィカルユーザーインターフェース（GUI）とコマンドラインインターフェース（CLI）の使い分けを、外部の複数エージェントに任せず、単一モデルの判断で行うことだ。モデルは作業内容に応じて、画面を直接操作するcomputer_useと、シェルコマンドを実行するbashの2つのチャンネルを選択する。視覚的な判断が必要な場合はGUIを使い、ファイルの直接編集や正確な検証に適した処理ではターミナルを利用する。
| チャンネル | 主な操作・処理 | 実行結果として受け取る情報 | 主な用途 |
|---|---|---|---|
computer_use |
クリック、ダブルクリック、トリプルクリック、マウス移動、ドラッグ、文字入力、キー押下、スクロール、待機、画面キャプチャ、終了（計11種類） | 操作後のスクリーンショット | 画面の配置確認、キャンバス編集、動的なUI操作 |
bash |
任意のシェルコマンド、Pythonスクリプト、openpyxlやpandasなどのライブラリの実行 |
標準出力（stdout）と標準エラー出力（stderr）をまとめたテキスト | 文書・表計算ファイルの編集、計算、結果の検証 |
GUI操作には11種類の基本アクションが用意されている。クリックやドラッグなどの操作に使う座標は、縦横ともに0〜999の範囲に正規化されており、実行環境が1920×1080などの実際の画面解像度に変換する。操作が終わると次のスクリーンショットが返され、モデルは画面の変化を確認して次の行動を決める。
これに対してbashチャンネルでは、作業用ディレクトリ内でシェルコマンドやPythonスクリプトを実行できる。結果は標準出力と標準エラー出力をまとめたテキストとして返されるため、画面全体を画像として解析する必要がない。ファイル内容の確認、一括置換、ライブラリによる計算、プロセスの監視などを、GUI操作を介さずに処理できる。
Microsoftは、視覚的な配置の確認やグラフィックソフトのキャンバス編集、アプリケーションの動的な表示状態の把握にはGUIが適していると説明する。一方、スプレッドシートや文書、プレゼンテーションファイルの構造的な変更には、Pythonライブラリを使った直接編集が効率的だという。変更後のファイルが正しい内容になっているかをプログラムで検証できることも、ターミナルを利用する利点となる。
例えば、表計算ファイルの特定のセルを結合し、見出しを設定する作業を考える。GUIだけを使うエージェントは、LibreOffice Calcを起動して画面が表示されるのを待ち、対象セルを選択して書式設定を変更する必要がある。途中でツールバーの配置が変わったり、予期しないポップアップが表示されたりすると、操作に失敗する可能性もある。これに対し、Mage-VL-Coworkはファイルを直接編集できると判断すれば、bashからopenpyxlを呼び出すPythonスクリプトを実行し、GUIを操作せずに変更を保存できる。画面遷移を待つ必要がなく、操作手順も減らせる。
この設計の狙いは、すべての操作をGUIで再現するのではなく、コンピュータが備えるプログラムからの操作手段を積極的に利用することにある。ただし、モデルに2種類のツールを与えるだけで、適切に使い分けられるようになるわけではない。小型VLMでは、誤った場面でシェルを呼び出したり、必要以上にGUIとターミナルを行き来したりする可能性がある。Microsoftは、この問題をモデルの学習方法と訓練環境の設計によって解決しようとした。
5段階の学習と教師モデルの環境改善が成功率を左右
MicrosoftがMage-VL-Coworkの開発で重視したのは、モデルのアーキテクチャだけでなく、訓練データの生成方法と学習の順序だ。ベースには、40億パラメータの中間チェックポイント「Mage-VL」を使用している。最初からGUIとターミナルの両方を扱わせるのではなく、それぞれの能力を身につけてから統合する「Specialize-then-Unify」という5段階の学習カリキュラムを採用した。
| 学習段階 | カリキュラム | 主な学習内容 | 計算量 |
|---|---|---|---|
| Stage 1 | GUI-Oriented Midtraining | 視覚的な位置特定、推論過程、ツール形式への準拠 | 1.18 ZFLOPs |
| Stage 2 | GUI Agent SFT | マウスとキーボードによる複数ステップの画面操作 | 1.55 ZFLOPs |
| Stage 3 | Coding & Terminal SFT | ソフトウェア開発、スクリプトによるファイル・システム操作 | 0.27 ZFLOPs |
| Stage 4 | Hybrid CUA SFT | computer_useとbashをターンごとに使い分ける能力 |
2.17 ZFLOPs |
| Stage 5 | Online Hybrid RL | 検証可能な報酬を用いたGRPOによる成功率と操作効率の最適化 | 2.62 ZFLOPs |
第1段階では、OSWorld-GやScreenSpot-v2などを使って、画面上の要素とテキスト指示を正しく対応させる基礎能力を学習する。第2段階では、スクリーンショットを見ながらマウスやキーボードを操作する、複数ステップのデスクトップ操作やWeb操作を教師あり微調整（SFT）で習得する。第3段階では、ソフトウェア開発やプログラムによるファイル操作を中心に、ターミナルを利用する能力を学習させる。続く第4段階で初めてGUIとターミナルを統合し、各ターンでどちらのチャンネルを使うべきかを判断する訓練を行う。最後の第5段階では、検証可能な報酬を用いるオンライン強化学習（RL）によって、操作回数を減らしながら成功率を高める。
この学習に必要なデータを効率的に生成するため、研究チームは「Mage-CUA-Forge」という環境生成エンジンも開発した。従来のように、タスクを生成するたびにAIエージェントを自由に動かして試行錯誤させる方法では、大量のトークンと計算資源が必要になる。そこでMage-CUA-Forgeでは、個々の操作を再利用可能な基本スキルとして整理し、タスク生成用のスクリプトと環境の準備手順をあらかじめ定義した。
Microsoftによると、この仕組みによって1タスク当たりのトークン消費量は127万6000トークンから8万5000トークンへと93.3%減少した。タスクの反復生成コストも0.906ドルから0.158ドルへと82.6%削減されたという。最終的には6915種類の基本スキルを利用して29万3806件のタスクを合成し、31万8837件の検証済みハイブリッド操作軌跡を収集した。
さらに注目されるのが、教師モデルに与えるツール環境の違いが、学習後の小型モデルの性能に大きく影響したという結果だ。Microsoftは、大規模な教師モデル「GPT-5.4」から知識を蒸留する際、ツールの構成が異なる2種類の実行環境を比較した。
一方の環境（）では、教師モデルにGUI操作、コード実行、アクセシビリティツリーなど、多数の情報やツールを与えた。もう一方の環境（）では、アクセシビリティツリーやxdotoolなどの重複する操作手段を取り除き、代わりにopenpyxlやpandasといった実用的なライブラリをあらかじめ導入した。672件の複合タスクで比較したところ、教師モデル自身の成功率は89.6%から92.0%へ上昇し、平均操作ステップ数は35.33回から25.00回へと29.2%減少した。
教師モデル自身の成功率の差は2.4ポイントだったが、その操作履歴を学習した小型モデルでは、より大きな違いが生じた。ツールが多く複雑な環境で生成されたデータを学習したモデルの成功率は25.1%、平均操作ステップ数は39.40回だった。一方、整理されたツール環境で生成されたデータを学習したモデルは、成功率37.6%、平均30.91回を記録した。成功率には12.5ポイントの差が生じている。
この結果は、小型モデルに多くのツールを与えることよりも、教師モデルが効率的かつ一貫した方法でツールを使える環境を整えることが重要である可能性を示している。ただし、これらはMicrosoftの実験環境で得られた結果だ。異なる教師モデルやデータセットを使った場合にも、ツール環境の整理によって同程度の改善が得られるかは、今後の検証を待つ必要がある。
OSWorld-Verifiedで成功率66.0%、大型モデルを上回る結果も
Mage-VL-Coworkが注目される理由の一つが、デスクトップ操作のベンチマーク「OSWorld-Verified」で66.0%という成功率を記録したことだ。40億パラメータという比較的小さなモデルながら、多くの大型モデルを上回る結果をMicrosoftは報告している。ただし、この数値を評価する際には、タスクの構成や操作回数の上限など、測定条件にも注意が必要だ。
Microsoftが公表した成功率は正確には66.04%で、Google Drive関連のタスクを除外した361件を対象としている。各タスクの操作回数は最大50ステップに制限され、独立した2回の実行で得られた65.33%と66.75%の平均値が報告された。評価には専用のエージェント実行環境「MAGEHybridAgent」を使用し、直近の操作履歴と3枚のスクリーンショットを保持している。画面解像度は1920×1080、サンプリング温度は0.7、top_pは0.8、最大生成トークン数は4096という設定だった。
データを表で見る
| 成功率 (%) | |
|---|---|
| ScaleCUA-9B | 68.7 |
| Mage-VL-Cowork-4B | 66 |
| Muse Glimmer-30B | 65.9 |
| Qwen3.6-27B | 63.9 |
| EvoCUA-32B | 56.7 |
| ComputerRL-9B | 48 |
| OpenCUA-72B | 44.9 |
| Fara1.5-4B | 13.9 |
Microsoftが示した比較では、Mage-VL-Coworkは重みが公開され、パラメータ規模も明らかなモデルの中で高い成功率を記録している。特に、同じ4B規模のGUI特化型モデル「Fara1.5-4B」の13.9%を大きく上回った。ただし、オープンウェイトモデル全体で首位になったわけではない。「ScaleCUA-Qwen3.5-9B」は、最大50ステップという条件で68.7%を記録している。
また、Mage-VL-Coworkの66.0%は、Muse Glimmer-30Bの65.9%やQwen3.6-27Bの63.9%を上回っているものの、Microsoftの比較表には、これら大型モデルのステップ数上限などの詳細な評価条件が記載されていない。すべてのモデルが完全に同じ条件で評価されたとは限らないため、パラメータ数が少ないモデルほど優れていると単純に結論づけることはできない。
一方、Mage-VL-Cowork自身の学習段階ごとの比較からは、オンライン強化学習による改善効果が読み取れる。Microsoftは、GUI操作に特化したSFTモデル、GUIとターミナルを統合したSFTモデル、強化学習まで実施した最終モデルの成功率と推論コストを比較している。
| 開発段階・参照モデル | OSWorld-Verified成功率（%） | 平均モデル呼び出し回数／タスク | 平均出力トークン数／タスク | 平均思考トークン数／タスク |
|---|---|---|---|---|
| Stage 2: GUI Agent SFT | 45.56 | 25.36 | 6,401 | 4,549 |
| Stage 4: Hybrid CUA SFT | 55.84 | 21.57 | 7,374 | 3,328 |
| Stage 5: Online Hybrid RL（Mage-VL-Cowork） | 66.04 | 18.77 | 5,499 | 2,482 |
| 参考：GPT-5.4-mini（xhigh） | 69.57 | 18.24 | 12,397 | 11,631 |
GUIとターミナルを統合したStage 4の成功率は55.84%だったが、オンライン強化学習を経たStage 5では66.04%に上昇した。改善幅は10.20ポイントで、平均モデル呼び出し回数も21.57回から18.77回へと約13.0%減少している。さらに、タスク当たりの平均出力トークン数は7374から5499へと約25.4%削減された。モデルが推論過程を記述する<think>タグ内の思考トークンも3328から2482へ減少しており、操作の成功率を高めながら推論に必要なトークンを減らしたことが分かる。
Microsoftのプロジェクトページでは、Qwen3.6-27Bとの実行時間を比較するデモも紹介されている。LibreOffice Calcを使う特定の作業で、GUI操作に特化したQwen3.6-27Bが39ステップ、9分56秒を要したのに対し、Mage-VL-CoworkはPythonによるファイルの直接編集を選び、6ステップ、39秒で完了したという。処理時間は約15.3倍の差となり、GUIとターミナルを使い分ける利点が分かりやすく表れた例だ。ただし、これは特定のタスクを取り上げた実演であり、すべての作業で同程度の高速化が得られるわけではない。
公開モデルの動作要件とメモリ使用量
Mage-VL-Coworkの重みは公開されているが、実際に動かすにはモデルの構造や推論環境に関する条件を満たす必要がある。リポジトリでは、bfloat16精度の重みが2つのsafetensorsファイルに分割されており、ファイルサイズの合計は9.48GBとなっている。ただし、この容量だけを根拠に、家庭用PCやスマートフォン、エッジデバイスで容易に実行できると判断することはできない。
推論時にはモデルの重みを展開するためのメモリに加え、KVキャッシュ、高解像度画像を処理するビジョンエンコーダーの作業領域、実行環境やOSが使用するメモリも必要になる。そのため、実際のメモリ使用量は重みファイルの容量より大きくなる。小型デバイスでの動作可能性を判断するには、量子化によるメモリ削減効果や、実際の推論処理全体で消費するメモリ量を測定する必要がある。
モデルのアーキテクチャにも注意が必要だ。Mage-VL-Coworkはllava_onevision2と呼ばれるカスタムマルチモーダルアーキテクチャを採用しており、モデル構造はリポジトリに同梱されたPythonコードで定義されている。そのため、Hugging FaceのTransformersなどで読み込む際には、trust_remote_code=Trueを指定する必要がある。標準的なQwen3-VLの実装に重みだけを差し替えて動かせる構成ではない。また、この設定ではリポジトリ側のPythonコードの実行を許可するため、コードの信頼性も確認する必要がある。
学習と推論で使用されるコンテキスト長は32,768トークンに設定されている。アーキテクチャ上は最大262,144トークンに対応するとされるが、公開された構成で評価された動作条件とは区別すべきだ。長いタスクを処理する際のコンテキスト消費を抑えるため、Mage-VL-Coworkは「非対称ワーキングメモリ」と呼ばれる履歴圧縮方式も採用している。
| 履歴の種類 | 対象ステップ | 保持する情報 | 目的 |
|---|---|---|---|
| 圧縮履歴領域 | 過去のターン（ステップ1〜$t-4$） | モデルが出力した1行の操作要約（Action:行）を集約 |
古い履歴によるトークン消費を抑える |
| アクティブ作業領域 | 直近のターン（ステップ$t-3$〜$t$） | 直近3枚のスクリーンショットと、直近4ターン分の完全なアシスタント応答 | 操作直後の画面変化や実行結果を確認する |
この方式では、直近3枚のスクリーンショットと4ターン分のアシスタント応答をそのまま保持する。これにより、直前のクリックが成功したか、画面の状態がどう変わったかを確認できる。一方、それ以前の履歴はモデル自身が出力したAction:行だけに圧縮し、システムプロンプトの直後にまとめる。古いスクリーンショットや詳細な応答を保持し続けないことで、長時間の操作でもコンテキストの消費を抑える設計だ。
推論環境について、Microsoftは公式Dockerイメージを使ったSGLangランタイムの構築を推奨している。推奨環境はSGLang 0.5.2、PyTorch 2.8.0+cu128、Transformers 5.7.0、FlashInfer 0.3.1を組み合わせたGPU環境だ。また、デスクトップ画面の細かな文字やアイコンを正しく認識するため、環境変数SGLANG_MAX_PIXELS=4000000を設定し、1920×1080の解像度を維持して処理する構成が示されている。モデルカードにはtransformers>=4.57.3というインストール条件も記載されているが、ベンチマークの再現性を重視する場合は、Microsoftが指定するDocker環境を基準にするのが適切だ。
リポジトリのosworld_evalディレクトリには、エージェントの定義やSGLangの起動スクリプトなど、評価に必要な最小限の参照実装が含まれている。ただし、完全なベンチマーク評価パイプラインを動かすには、公式GitHubリポジトリのmage_vl_coworkディレクトリにあるスクリプト群との連携が必要になる。
このように、66.0%という成功率はモデルの重みだけで得られたものではなく、専用のエージェント実行環境、履歴の保持方法、操作回数の制限、サンプリング設定などを組み合わせた結果だ。小型モデルの実力を評価するうえでは、パラメータ数や重みファイルの容量だけでなく、実際の操作を支えるシステム全体の設計も重要になる。今後は、別の推論エンジンやエージェントフレームワークへ移した場合にも、同程度の成功率を維持できるかが検証課題となる。
任意のシェル実行がもたらすセキュリティ上の課題
Mage-VL-Coworkの実用性を考えるうえで、性能と同じくらい重要なのがセキュリティだ。GUI操作とシェル実行を組み合わせることで作業の幅は広がるが、モデルが実行できる操作の権限も大きくなる。特にbashチャンネルでは、AIが任意のシェルコマンドを生成して実行できるため、誤った判断や外部からの悪意ある指示が、ファイルの破壊や情報の漏洩につながる可能性がある。
GUI専用のエージェントでも、アプリケーションを通じて重要な設定やデータを変更する危険はある。しかし、シェルを利用できる場合は、GUIを介さずにファイルシステムやプロセス、ネットワークなどを直接操作できる。実行環境に過剰な権限が与えられていれば、意図しないコマンドの影響が広範囲に及ぶおそれがある。
Microsoftは公式GitHubリポジトリで、このモデル群を「研究目的専用（for research purposes only）」と位置づけている。商用製品や本番サービスへの配備を想定したものではないという。モデルカードに記載された安全運用のガイドラインでも、普段使用しているPC上で無制限に動かすのではなく、使い捨て可能なDockerコンテナや、スナップショットから復元できる仮想マシンなど、隔離された環境での研究・評価を前提としている。
Microsoftは、評価環境からホストのファイルシステムやローカルネットワーク、個人の環境変数へアクセスできないようにすることを推奨している。SSH秘密鍵、クラウドサービスのアクセストークン、ブラウザーのCookieなどの認証情報も、作業環境へ不用意に渡すべきではない。検証のために認証情報が必要な場合でも、一時的なサンドボックス専用のものに限定することが求められる。
さらに、外部へのデータ送信、アカウント認証、金銭の移動、権限の変更など、重大な影響を及ぼす操作については、実行前に人間の明示的な承認を得る運用が必要になる。外部のWebページや文書を読み込む際には、悪意ある指示を埋め込む間接的なプロンプトインジェクションにも注意しなければならない。意図しないコマンド実行や情報送信を防ぐため、通信先を許可されたアドレスに限定する制御も推奨されている。
Webブラウザー操作では専用モデルに及ばない結果も
Mage-VL-Coworkはデスクトップ全般の操作を想定したモデルだが、すべての作業で専用モデルを上回るわけではない。Webブラウザーの操作性能を測るオフラインベンチマーク「WebVoyager-Static」では、Microsoftは強化学習前のチェックポイント「Mage-VL-Cowork-SFT」について、成功率58.6%と報告している。以下は、Microsoftが示した比較結果をまとめたものだ。
| モデル | パラメータ数 | 対象分野 | WebVoyager-Static成功率（%） | 各社報告のライブ環境成功率（%） | ライブ環境との差（ポイント） |
|---|---|---|---|---|---|
| Fara1.5-4B | 4B | Webブラウザー特化 | 68.0 | 80.8 | −12.8 |
| Mage-VL-Cowork-SFT | 4B | デスクトップ全般・Webブラウザー | 58.6 | 未公表 | 未公表 |
| Qwen3-VL-8B-Thinking | 8B | 汎用VLM | 53.7 | 未公表 | 未公表 |
| Qwen3.5-9B | 9B | 汎用VLM | 53.3 | 未公表 | 未公表 |
| Qwen3-VL-4B-Thinking | 4B | 汎用VLM | 49.6 | 未公表 | 未公表 |
| OpenWebRL-4B | 4B | Webブラウザー特化 | 47.1 | 74.1 | −27.0 |
| MolmoWeb-8B | 8B | Webブラウザー特化 | 46.8 | 78.2 | −31.4 |
Mage-VL-Cowork-SFTの58.6%は、Webブラウザー操作に特化したFara1.5-4Bの68.0%には及ばない。一方、Fara1.5-4BのOSWorld-Verifiedでの成功率は13.9%にとどまっており、Webブラウザーに特化したモデルと、デスクトップ全般を扱うモデルでは得意分野が異なることが分かる。ただし、WebVoyager-Staticの58.6%は強化学習前のSFTモデルによる結果であり、最終モデルがOSWorld-Verifiedで記録した66.0%とは測定対象もモデルの学習段階も異なる。両者を直接比較して、Web操作とデスクトップ操作の性能差を判断することはできない。
代表的なモデルについて、操作できる範囲と評価条件の違いを整理すると、次のようになる。
| モデル | パラメータ数 | 操作できる範囲 | 主なベンチマーク結果 | 評価条件と注意点 | 出典 |
|---|---|---|---|---|---|
| Mage-VL-Cowork | 4B | GUI操作11種類とbashを組み合わせたハイブリッド方式 |
OSWorld-Verified：66.0% | 最大50ステップ、2回の平均、MAGEHybridAgent使用、Google Drive関連を除外 | Microsoftモデルカード |
| ScaleCUA-Qwen3.5-9B | 9B | GUIと各種ツール | OSWorld-Verified：68.7% | 最大50ステップ、オープンウェイトモデルの上位記録 | Microsoft公表比較表 |
| Qwen3.6-27B | 27B | GUI操作 | OSWorld-Verified：63.9% | Microsoftの比較表にステップ数上限の明記がなく、直接比較には注意が必要 | Microsoft公表比較表 |
| Fara1.5-4B | 4B | Webブラウザー操作（DOM・スクリーンショット） | OSWorld-Verified：13.9%、WebVoyager-Static：68.0% | デスクトップ全般とWebブラウザー操作で成功率が大きく異なる | Microsoft公表比較表 |
こうした結果を踏まえると、Mage-VL-Coworkの特徴は、特定の操作で最高性能を発揮することよりも、GUIとコード実行を組み合わせて幅広い作業に対応できる点にある。特に、スプレッドシートの集計、レポートの生成、ファイル形式の一括変換など、プログラムによる直接操作が効果的な作業では、bashチャンネルの利点を生かしやすい。ただし、Microsoftが示す安全運用の条件を考えると、こうした用途であっても、まずは本番データや外部ネットワークから隔離した評価環境で検証するのが適切だ。使い捨て可能なコンテナや仮想マシンを利用し、ファイルへのアクセス権限や通信先を制限することで、シェル実行に伴うリスクを抑えられる。
また、Apache-2.0ライセンスで重みが公開されていることと、Microsoftが研究目的での利用を想定していることは区別する必要がある。Apache-2.0は比較的制約の少ないライセンスだが、モデルを本番環境で安全に運用できることまで保証するものではない。外部の研究者や開発者が独立した環境で評価し、異なるタスクや実行基盤でも高い成功率を再現できるかが、今後の重要な判断材料となる。
Mage-VL-Coworkの研究が示したのは、コンピュータを操作するAIエージェントの性能が、モデルの規模だけで決まるわけではないということだ。GUIとターミナルを適切に使い分ける学習方法、質の高い教師データ、効率的な履歴管理を組み合わせることで、40億パラメータのモデルでも複雑なデスクトップ操作に対応できる可能性が示された。一方、任意のシェルコマンドを実行できる仕組みには、厳格な権限管理とサンドボックスによる隔離が欠かせない。独立した環境での性能再現と安全性の検証が進むかどうかが、小型ハイブリッドエージェントの実用化を左右することになる。