2026年5月27日、InfoQ が Azure Logic Apps Adds Sandboxed Code Interpreters to Agent Workflows（InfoQ 2026-05-27） を報じました。Microsoft が Azure Logic Apps に サンドボックス化されたコードインタープリタ を追加し、統合ワークフロー内のエージェントが Python / JavaScript / C# / PowerShell を Hyper-V 隔離セッション で生成・実行できるようになったという内容です。アーキテクトはモデルや実行を細かく制御でき、生成コードを保護された境界の中で動かせます。これは単なる機能追加ではなく、「業務自動化フローに AI を安全に差し込める」分水嶺 だと考えています。なぜなら、これまでエージェントに任意コードを実行させることは情シスにとって最大の懸念であり、その隔離が iPaaS にビルトインされた意味は大きいからです。
私たちは中小〜中堅企業向けに、AI 導入・業務システム連携・Web 制作を受託しています。今回はその中でも iPaaS（Azure Logic Apps 等）に AI エージェントを組み込み、基幹・SaaS・メール・承認といった既存業務を安全に自動化する受託サービス の立場から、この発表をどう実務に落とすかを整理します。エージェントを業務システムに組み込む全体設計は Mastra で AI エージェントを業務システムに統合する受託 で、既存システムをエージェントから扱う接続設計は 既存 API を MCP サーバー化する設計パターン でも扱っています。
なぜ「サンドボックス実行が分水嶺」なのか
従来の自動化は「あらかじめ決めた手順をなぞる」ものでした。エージェントワークフローは「状況を判断して、必要ならコードを書いて実行する」ものです。後者の障壁は常に 安全性 でしたが、Hyper-V 隔離付きのコードインタープリタがそこを下げました。
| 観点 | 従来のノーコードフロー / RPA | サンドボックス付きエージェントワークフロー |
|---|---|---|
| 柔軟性 | 事前定義した分岐のみ。例外で停止 | 状況に応じてコード生成・実行で対応 |
| 安全性（隔離） | スクリプトはフロー権限で直接実行 | Hyper-V 隔離セッションで実行し境界を分離 |
| 可観測性 | 実行ログは取れるが意図は追えない | 生成コード・入出力・実行結果を監査可能 |
| 保守性 | 画面 GUI 依存で属人化しやすい | コード化＋IaC で再現性が高い |
| 対応業務範囲 | 定型・構造化データ中心 | 半構造・非構造データや判断業務まで拡張 |
ポイントは、「柔軟性を上げると安全性が下がる」というトレードオフを隔離で緩和した ことです。情シスが AI 自動化に首を縦に振らなかった最大の理由は「何を実行するか事前に分からない」点でしたが、隔離された実行環境と監査ログがあれば話が変わります。
受託案件で活きる 3 つの構造変化
構造 1: 固定フローから「エージェントが判断する」フローへ
これまでは要件を聞いて分岐をすべて図に起こしていました。今後は 「判断はエージェント、実行はサンドボックス、確定は人間の承認」 という役割分担を設計します。受託の価値は「どこをエージェントに任せ、どこを人間のゲートにするか」の線引きにあります。判断ロジックの組み立て方は 業務システムへの AI エージェント統合の受託設計 の考え方が下敷きになります。
構造 2: 野良スクリプトから隔離実行・監査へ
現場には Excel マクロや個人の PowerShell スクリプトが散在しています。これらを Logic Apps のサンドボックス実行に集約 すれば、誰が・いつ・どのコードを実行したかが記録され、属人化と統制不全を同時に解消できます。既存資産をエージェントから安全に呼び出す接続層は 既存 API を MCP サーバー化する設計パターン と同じ発想で整理できます。
構造 3: 単発自動化から継続運用へ
エージェントは判断するため、扱うデータや業務が変わると挙動も変わります。「作って終わり」ではなく、精度・コスト・例外を見ながら継続調整する運用 が前提です。記憶や文脈の継続管理は エージェントの永続記憶を業務システムに組み込む受託 の論点とつながり、受託の主戦場は構築から運用へ移ります。
受託で提供する「AI 業務自動化（iPaaS × エージェント）」5 フェーズ
フェーズ 1: 現状診断
- 対象部門の業務棚卸しと、手作業・転記・確認待ちの可視化
- 自動化候補の選定（頻度 × 工数 × 標準化しやすさでスコアリング）
- データの所在（M365 / 基幹 / SaaS）とアクセス権の整理
フェーズ 2: PoC
- 候補 1〜2 業務でエージェントワークフローを試作
- サンドボックスでのコード生成・実行を限定スコープで検証
- 精度・例外発生率・実行コストの初期計測
フェーズ 3: 設計
- Logic Apps + エージェント + コネクタ（M365 / SaaS / 基幹）の全体設計
- サンドボックス権限・実行境界・監査ログの設計
- ガードレール（禁止操作・承認ゲート・上限値）の定義
フェーズ 4: 構築・展開
- 本番ワークフロー構築と、人間の承認ステップ組み込み
- IaC（Bicep / ARM）による再現可能なデプロイ
- 段階的な全社展開とエラー時のフォールバック整備
フェーズ 5: 運用レビュー（継続）
- 月次で精度・コスト・例外・監査ログをレビュー
- プロンプト/ガードレール/対象業務の調整
- 自動化範囲の段階拡大と効果の再計測
受託向け技術スタック標準セット
| レイヤ | 推奨 | 代替 |
|---|---|---|
| iPaaS | Azure Logic Apps（Standard） | Power Automate（軽量用途） |
| エージェント / LLM | Azure OpenAI Service | 他クラウドのマネージド LLM |
| コードサンドボックス | Logic Apps のサンドボックス（Hyper-V 隔離） | コンテナ隔離の自前実行環境 |
| コネクタ | M365 / Dataverse / 基幹 API コネクタ | カスタムコネクタ・MCP サーバー化 |
| 可観測性・監査 | Azure Monitor / Application Insights | 集約ログ基盤 + 監査保管 |
| ID / 権限 | Microsoft Entra ID（最小権限） | 既存 IdP 連携 |
既存の社内 API をエージェントから扱う必要がある場合は、無理に直結せず接続層を一枚かませる方が安全で、その設計は 既存 API を MCP サーバー化する設計パターン の通りです。
どの案件に必要か / 不要か
| 向いている案件 | 見送るべき案件 |
|---|---|
| Microsoft 365 / Azure をすでに業務利用している | 標準化されていない属人作業が大半で前提が崩れる |
| 部門横断でデータ転記・確認待ちが多い | 自動化対象の業務頻度が極端に低い |
| 監査・統制を効かせつつ自動化したい | コードやログを残せない（残してはいけない）業務 |
| 例外判断を含む半定型業務を効率化したい | 完全定型で既存 RPA だけで十分に回る |
「AI を入れたいから入れる」案件は最初に止めます。自動化の費用対効果が立つ業務量があるか が線引きの基準です。
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| スコープと判断範囲 | エージェントに任せる判断と人間の承認範囲を明記 | 「どこまで自動で確定するか」の境界 |
| サンドボックス権限 | 実行可能な操作・到達できるリソースの上限 | 過剰権限が付いていないか |
| 監査・ログ保持 | 生成コード・入出力・実行結果の記録と保持期間 | 監査要件・保持年数を満たすか |
| データ取り扱い | 学習利用の有無・保管場所・越境移転 | 個人情報・機微データの扱い |
| コストと従量課金 | 実行課金・トークン課金の上限とアラート | 月額上限とアラート通知の有無 |
| 運用・SLA | 障害時対応・調整頻度・撤退時の引き継ぎ | ベンダーロックと移行手段 |
特に サンドボックス権限と監査ログ は、AI 自動化特有の論点なので口頭ではなく契約に落とすことを推奨します。
価格モデル — AI 業務自動化パッケージ
| メニュー | 内容 | 価格レンジ（税別） |
|---|---|---|
| 診断 / PoC | 現状診断 + 1〜2 業務の試作・効果検証 | 80〜180 万円 |
| Lite（月額） | 1〜2 ワークフローの運用・小規模調整 | 月 12〜25 万円 |
| Standard（月額） | 複数部門・継続調整・監査レビュー込み | 月 30〜70 万円 |
| Enterprise（月額） | 全社展開・SLA・統制レビュー込み | 月 80〜180 万円 |
| 初期構築（一括） | 本番ワークフロー構築・IaC・展開設計 | 250〜800 万円 |
クラウド利用料（Logic Apps 実行課金・Azure OpenAI のトークン課金）は別途実費です。運用フェーズを軽視した一括見積りは破綻しやすい ため、構築と運用を分けて提示します。
顧客側 ROI 試算
| 指標 | 改善イメージ |
|---|---|
| 手作業工数削減 | 対象業務で月 40〜120 時間の削減 |
| エラー率低減 | 転記・確認ミスを 50〜80% 削減 |
| 処理リードタイム短縮 | 承認待ち・転記待ちで 1/2〜1/3 に短縮 |
| 属人化解消 | 野良スクリプトを集約し担当者依存を解消 |
たとえば月 80 時間の手作業を削減でき、対象業務の人件費を時給 3,000 円換算とすると、月 24 万円相当の効果です。Standard（月 30〜70 万円）の場合、複数業務を束ねれば 半年〜1 年程度での回収 が現実的な目安になります。工数・効果は業務によって振れるため、必ず PoC の実測値で再計算します。
ハマりやすい 5 つの落とし穴
落とし穴 1: いきなり全業務を自動化しようとする
範囲を広げすぎると精度も統制も崩れます。頻度 × 工数の高い 1〜2 業務 から始めます。
落とし穴 2: サンドボックス権限を絞らない
「とりあえず動かす」ために広い権限を付けると、隔離の意味が薄れます。最小権限と到達リソースの上限 を最初に決めます。
落とし穴 3: 可観測性・監査ログを後回しにする
生成コードや実行結果を残していないと、障害も説明責任も果たせません。監査ログは初期設計に含める のが鉄則です。
落とし穴 4: 人間の承認ゲートを省く
判断を全部エージェントに渡すと、誤実行が即本番に流れます。確定操作の前に承認ステップ を置きます。
落とし穴 5: コスト（実行課金・トークン）の見積りを甘くする
エージェントは状況次第で実行回数が増えます。上限値とコストアラート を設定し、月額の振れ幅を可視化します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| 1〜2 週 | 対象部門の業務棚卸しと自動化候補のスコアリング |
| 3〜4 週 | データ所在・権限の整理、PoC 対象業務の確定 |
| 5〜7 週 | PoC 構築（サンドボックス実行・例外計測・コスト試算） |
| 8〜9 週 | 全体設計（コネクタ・権限・監査・ガードレール） |
| 10〜11 週 | 本番ワークフロー構築と承認ゲート・IaC 整備 |
| 12〜13 週 | 段階展開・効果計測・運用レビュー体制の確立 |
まとめ
Azure Logic Apps のサンドボックス化コードインタープリタは、AI 自動化の最後の壁だった 「任意コード実行の安全性」 を iPaaS 側で吸収する一手です。これにより、判断はエージェント・実行は隔離環境・確定は人間という役割分担が、現実的な統制レベルで組めるようになりました。ただし価値が出るかどうかは、対象業務の選定・権限と監査の設計・継続運用にかかっています。私たちは現状診断から PoC、設計・構築、運用レビューまでを一気通貫で受託します。自社の業務でどこから自動化できそうか壁打ちしたい方は、お問い合わせフォーム からお気軽にご相談ください。
