企業の AI エージェント活用で考える「実行環境」の考え方（ローカル vs リモート）

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、企業の AI 活用や AI の最新情報について紹介しています。

最近、AI エージェントという言葉がすっかり定着してきました。以前は AI 活用というと、チャット画面で質問して回答をもらう、文章を要約する、資料を作成する、といった使い方が中心でしたが、現在は AI が人間と協業して作業する方向に進んでいます。

各社「どのモデルで動かすか」「どのようなプロンプトやハーネスでエージェントを動かすか」を考えながらエージェントの導入を進めていると思うのですが、今回は「その AI エージェントをどこで動かすのか」という観点についてご紹介します。

より自律的に作業を進めるためには、自分の PC を閉じている時にも作業を継続させる必要があり、リモートで動かすエージェントも広がってきています。

ローカル PC、クラウド上の隔離環境、社内ネットワークに近い環境、オンプレミスや専用 VPC など、実行環境によって、扱える情報やセキュリティ、コストが大きく変わります。

ローカル上で動かす場合

開発者の PC や社内端末、ローカル環境上で動く AI エージェントです。

最も有名なのは Claude Code や Cowork, Codex や GitHub Copilot などのように、エディタやターミナルから AI に指示し、現在の作業ディレクトリのファイルを読ませたり、コードを書き換えたり、テストを実行させたりするものです。

ローカル環境には、開発者の SSH キー、クラウド認証情報、.env ファイル、ブラウザのログイン状態、社内 VPN、ローカル DB など、重要な情報が集まっていることがあります。

AI エージェントがどのフォルダを読めるのか、どのコマンドを実行できるのか、ネットワークへ出られるのかを決めないまま使うと、思わぬ情報にアクセスできてしまう可能性があります。

リモート / クラウド上で動かす場合

一方で、リモートエージェントやクラウドエージェントは、クラウド上の環境で AI が作業する形です。

GitHub Copilot cloud agent のように GitHub Actions ベースの一時的な開発環境で動くものもあれば、Devin のように、専用の仮想環境を持って作業するものもあります。

Devin の公式ドキュメント では、Devin の環境は、

• リポジトリがクローンされている
• ツールがインストールされている
• 依存関係が解決されている
• 設定が適用されている

という条件の Linux ベースの仮想マシンであり、開発者のノート PC に相当するものだと説明されています。また、その環境設定はスナップショットとして保存され、各セッションがその既知の状態から開始されるとされています。

リモートエージェントの良いところは、人間が作業していない（PC を開いていない）間にもタスクを進められることです。チケットを渡しておき、AI が調査し、変更案を作り、テストを実行し、Pull Request として提出する。人間はその結果をレビューする。こうしたワークフローに向いています。

クラウド上で動くため、複数のエージェントに別々のタスクを任せる、長時間の処理を任せる、決まった環境で再現性を持って実行する、といったこともしやすくなります。

リモートで動かすエージェントには、クラウド上の環境にリポジトリや依存関係、テストデータ、API キーやパスワードなどの秘密情報、社内ネットワークへの接続をどう渡すのかを設計する必要があります。

導入にあたって気をつけるべきポイント

リモートでの AI エージェント導入では、最初に決めておきたいポイントを整理して 3 つ紹介します。基本的にはローカルで動かす場合と同じなのですが、クラウド上に環境を用意すること、より自律的に AI を使うことになることから、一段階深く考えると良いです。

1) どのデータを AI に見せるのか

リポジトリ、設計書、仕様書、社内ドキュメント、問い合わせ履歴、顧客情報、ログ、営業資料、契約書、議事録など、企業にはさまざまな情報があります。

AI に見せてもよい情報と、見せてはいけない情報を分けずに導入すると、後から複雑になってしまった権限管理を見直したり、情報漏えいリスクを抱えることになります。

特に RAG や社内ナレッジ検索では、どの情報が正本なのか、どの部署が見てよいのか、古い情報をどう削除するのかが重要です。

2) 誰の権限で実行するのか

AI エージェントに人間の個人アカウント（Google アカウント、M365 アカウントなど）をそのまま使わせるのは、あまり良い設計ではありません。誰が操作したのか分かりにくくなり、権限の棚卸しやログ監査も難しくなります。

AI 用のアカウントを作り、必要最小限の権限を付与し、ログを追えるようにする。これだけでも、AI 活用の安全性と説明可能性は大きく変わります。

3) 成果物をどうレビューするのか

AI エージェントがコードを書いたり、資料を作成したり、ドキュメントを更新したりする場合、その成果物を人間がどう確認するのか、「ここまでは AI で勝手に進めて良い」という境界はどこかを決めておくと良いです。

よくあるパターンは、Pull Request を作成するところまでは AI で、そのレビューは人間が行うという境界です。これを決めておくと気持ち的にも楽になります。

例えば GitHub Copilot cloud agent も、作業内容を Pull Request として作成し、人間が確認できる形にすることが前提の機能です。

まとめ

ローカルで動かすのか、クラウドで動かすのか。どのデータを見せるのか。どのネットワークに接続するのか。誰の権限で作業するのか。成果物をどうレビューするのか。社内ナレッジをどう接続するのか。考えることが多くあり、なかなか導入に踏み切れません。

まずは安全な AI 系のサービスを導入するところから始めていき、企業全体のナレッジを AI でうまく安全に扱っていけるような方向へ向かっていくのが良いと思います。

GMOプライム・ストラテジーではつい先日、GMO AI RAG をリリースしました。

こちらは私も開発をお手伝いしており、企業用の RAG の基盤としておすすめできるサービスです。ぜひご活用いただき、AI 活用のきっかけにしてみてください。

GMOプライム・ストラテジーでは、こうした AI 活用の基盤づくりから運用までを支援するサービスを提供しています。ぜひご活用いただき、AI 導入のきっかけにしてみてください。

• MAGATAMA Stack（セキュアで高性能な汎用 RAG 製品。オンプレミスやクラウドに構築可能。パイロット版リリースを目指す開発段階）
• AI ソリューション（業務課題の整理から PoC 開発・運用まで一貫支援）