—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
Copilot Coworkの「作業実行」モデルは、指示文（プロンプト）から実行レイヤーへと企業の統制を移します。承認、アイデンティティ境界、可観測性が「許されること」を決めるのです。
AIが下書きをする段階から、委任して実務を進める段階へ移る瞬間、リスクの性質はモデルの品質ではなく、プロセス管理の問題へと切り替わります。Copilot Coworkの前提――エンタープライズの業務システム内で複数ステップの作業を担えるエージェント型アシスタント――は、次の一点を否応なく具体化します。組織は「実行」を、便利な機能ではなく統治されたサブシステムとして扱う必要がある、ということです。だからこそ「サンドボックス化、承認、ガバナンス境界」が、単なるソフトウェア実装の細部ではなく、専門的な業務フロー設計の新しい言語になるのです（techradar.com
変化は微妙ですが、決定的です。従来の生産性環境では、人間は結果を「あとから」レビューできますでした。しかしエージェント型の実行では、エージェントが途中段階の判断を下します。どのツールを呼び出すのか、どの文書に触れるのか、エスカレーションするのか、いつ待つのか。これらは実行レイヤーでの判断です。下書きが出てからチェックリストだけを作り直しても、より大きな失敗の形を見落とします。つまり、誰かが結果を見つける前に、システムが誤った経路をたどってしまう可能性です。
この記事が強調したい編集上の論点はそこにあります。私たちは「AIがタスクをこなせるか」を問うているのではありません。問いは次の一点です。委任された作業が、価値を生むと同時に説明責任も果たせるようにするには、企業はどこに人間の判断、ログ、そして承認ゲートを置くべきなのか。特に、エージェントがアイデンティティのスコープ、文書ストア、業務システムをまたいで動く場合です。
従来のワークフローとは、人間同士の手渡しの集合です。依頼 → 下書き → レビュー → 承認 → 提供、という流れが典型です。エージェント型の実行は、この時間構造を圧縮します。エージェントは「下書き」を生成し、文書を振り分け、アプリをまたいで迅速に修正案を提示することさえあります。そして人間は、重要な節目のいくつかでのみループに入ります。
Microsoft自身の、AIエージェントに関するガバナンスの指針は、はっきりと「すべてのエージェントのアクションは監査可能である必要がある」とし、監査可能性を可観測性のためのツールやアイデンティティの構成と結び付けています（learn.microsoft.com
実務として求められるのは、ワークフロー設計を「明示的な統制ポイント（control points）」の周りで書き直すことです。Microsoftは「ゾーン型ガバナンス」を、環境を論理的に分節化し、エージェントの目的やリスク水準に応じて異なるガバナンス方針を適用する考え方として説明しています。要するに、環境をデータ、セキュリティロール、ライフサイクル分離の境界を定義するコンテナとして扱うわけです（learn.microsoft.com
もう一つの変化は、承認を“飾り”ではなく“構造”にすることです。MicrosoftのCopilot Studioは「AI承認」を、事前に定義されたビジネスルールに照らして依頼を評価し、重要な判断では人間が制御を維持するためのAIによる意思決定ステージとして説明しています（microsoft.com
複数ツールのワークフローでは、認可は後付けではいけません。それは、エージェントの実行領域（execution universe）を定義する条件であり、最初から境界として設計されるべきです。Microsoftは、エージェントのアクションに認可を織り込むアーキテクチャを、アイデンティティを起点とするパターンとして提示し、Copilot Studio、Power Automate、Microsoft Entra ID、Microsoft Graphを用いて、エージェントが依頼した利用者の権限の範囲内でのみ実行するよう担保することを示しています（techcommunity.microsoft.com
これが重要なのは、プロの仕事が“純粋な閲覧”で終わることは稀だからです。カレンダー管理は稼働可能性に触れます。リサーチからスライドへのパイプラインは、出典や物語の主張に関わります。文書の生成はファイルの状態を変え、場合によっては下流の配布にも影響します。エージェントが、依頼者のアイデンティティ境界の下で動くとき、企業は予測可能なガバナンスモデルを得ます。委任されたワークフローは、本人になりきった“従業員の動き”のように振る舞うからです。
ただし「アイデンティティ境界」は、権限だけの話ではありません。ライフサイクル上の状態に応じて、エージェントの役割を分離（segregation）することでもあります。Microsoftのエージェントガバナンス指針はEntraに基づくアイデンティティ分離を強調し、組織が本番、開発、テストのエージェントを区別でき、説明責任をそれらのアイデンティティに紐づけられるようにすることを求めています（learn.microsoft.com
編集上の結論は明快です。企業は「エージェントのアクセス」をグローバルな設定のように扱うべきではありません。各ステップの認可を、最小権限で、明示的に、そしてアイデンティティ境界に紐づけられる形で設計し直すべきです。境界は、ログイン済み利用者のスコープであっても、狭いスコープのアプリケーションや、さらに限定されたエージェントのアイデンティティであってもよいのです。
実行レイヤーが“決定が下される場所”であるなら、可観測性は“決定が読める場所”です。Copilot Studioに関する管理者ログ（admin logging）のドキュメントは、アクティビティ収集とPurview、そして監査ログの関係を説明し、Microsoft Purviewを通じて監査ソリューションをキャプチャしてレビューできることにも触れています（learn.microsoft.com
とはいえ、生態系の中には編集上の警告も含まれています。ログは、単なる法令対応の記録として整っていればよいのではありません。根本原因分析（root-cause analysis）を支えるだけの完全性が必要です。Datadog Security LabsはCopilot Studioにおける「ログのギャップ」を調査したとし、再テストの過程で特定のイベントの生成が一貫しない可能性などを論じています。Microsoftはテナント上で管理アクティビティがデフォルトで有効であるとも述べています（securitylabs.datadoghq.com
実行レイヤー設計における可観測性は、ワークフローの機能になります。
・責任を、アイデンティティと環境に結び付けて割り当てる
・承認を、判断の根拠や決定結果とともに検査可能にする
・インシデント対応を、どのツール呼び出しが行われ、どの文書に触れられ、どのゲートが発火したか追跡できる形にする
言い換えれば、「監査可能性／可観測性」は書類ではありません。システムの記憶です。ワークフロー設計者は、システムが“覚えていること”――タイムスタンプ、判断の根拠、ツール呼び出しの来歴――を、必要なワークフロー契約の一部として扱うべきです。
エージェント型の実行は、運用上の制約の影響を受けます。とりわけメッセージ／キャパシティ（capacity）の強制が効いてくるため、企業はワークフローのスループットをどう見積もるべきかが変わります。MicrosoftのCopilot容量パック（capacity packs）のドキュメントでは、各パックはテナントライセンスであり、月あたり25,000 Copilotクレジットを含むとされています（learn.microsoft.com
キャパシティ管理はCopilot Studioのガイダンスにも現れています。管理者はPower Platform管理センターでCopilot Studioクレジットのキャパシティを管理し、各Copilot Studioエージェントの月次消費上限を定義できます（learn.microsoft.com
実務で「測れる」形にするなら、「キャパシティ枯渇（capacity exhaustion）」を主要な失敗モードとして扱うのが一つの方法です。チームは、どのエージェントのワークフローでも次のように定義するべきです。
このようにして、キャパシティは調達の細目ではなく“ガバナンス”になります。
規制の時間軸もまた重要です。EUの人工知能法（Artificial Intelligence Act）は、透明性義務を定めており、一定のシステムに関して記録と透明性に関する義務を含みます。AI Act Service Deskの説明は、第50条の透明性義務を要約し、規則（EU）2024/1689の公式版を参照しています（ai-act-service-desk.ec.europa.eu
最後に、Microsoft自身の位置づけも監査の姿勢を補強します。Microsoftは、エージェントのアクションは監査可能でなければならず、Agent 365によるエージェントの可観測性と、Entra Agent Identityによるアイデンティティを通じた設計を推奨しています（learn.microsoft.com
実行レイヤーの発想を具体化した例として、MicrosoftのCopilot Studioにおける「AI承認」があります。これは、事前に定義された基準に基づいて依頼を自動的に承認または却下できる承認ステージであり、重要な判断では人間が制御を維持できるようにするものです（learn.microsoft.com
「人間が出力をチェックする」という構図ではなく、ワークフローの中に意思決定のサブルーチンが組み込まれるのです。Microsoftのドキュメントは、AI承認を「根拠とともに“承認（Approved）”または“却下（Rejected）”の判断を返す評価メカニズム」として位置づけ、請求書処理の承認などのユースケースも挙げています（learn.microsoft.com
編集上は、これが実行レイヤーのガバナンス・テンプレートを示していると言えます。
このパターンは、企業が直面するワークフロー再設計の問いに直接答えます。人間はどこにいるべきか？例外、高コストの意思決定、政策が細部までカバーしきれないあいまいなケースを表す閾値にこそ、人間の判断が置かれるべきです。実行レイヤーは、承認をワークフローのグラフに組み込むことで、その運用を可能にします。
Copilot Studioの「ゾーン型ガバナンス」ガイダンスにも、別の具体的な設計が示されています。ゾーン型ガバナンスとは、環境を分節化し、エージェントの目的やリスク水準に応じて異なるガバナンス方針を適用する考え方であり、セキュリティロールの分離、データポリシー、ライフサイクル分離などが含まれます（learn.microsoft.com
これは単なるアーキテクチャ用語にとどまりません。ワークフローの再設計原則です。たとえば定型のスケジューリング、調査の要約、配布権を伴う文書の草案作成――こうしたワークフローの“種類”ごとに、別のガバナンスゾーンに属させるのです。そのゾーンが、エージェントがアクセスできる範囲、求められる承認、そして可観測性データがどこに保存され、どうレビューされるかを決めます。
「分節化」を具体化するには、**ゾーン・マトリクス（zone matrix）**を定義するのがよいでしょう。これは、ワークフローの各ステップ（またはツール権限）に対して、(a) 実行されるゾーン、(b) そのゾーンでエージェントが実行してよい最大アクション、(c) その上限を超える必要が出た場合の承認またはエスカレーション経路を対応づける表です。例えば「低リスクのアシスタント」ゾーンは読み取り専用の検索と草案作成に制限し、「高信頼の出版（publishing）」ゾーンだけが配布権を実際に付与される場所になる――といった設計があり得ます。編集上の成果は大きく、ガバナンス境界が“雰囲気”ではなく、強制可能なルーティング判断として説明しやすくなることです。
編集上の成果はさらに続きます。研究からスライドへのパイプラインが「低リスクのアシスタント」ゾーンに置かれるなら、承認ゲートのチューニングは「高信頼の文書出版」ゾーンとは異なるべきです。単一のグローバルルールで何もかもを管理しようとするのではなく、分節化によってリスクを“段取り”できるようになります。
鍵になるのは運用上の検証です。企業は、ワークフローがリトライ、複数ステップのツール連鎖、例外的なデータ処理などを通じて、意図したゾーンから“逃げ出せない”ことを確かめる必要があります。実務としては、ネガティブテスト（低いゾーンのアイデンティティで実行した際に、保護されたストアへ書き込めないことを証明する）を設計し、監査イベントにゾーン文脈が含まれていることを確認して、インシデント対応側が「誤動作（misbehavior）」と「誤ルーティング（misrouting）」を区別できるようにします。
3つ目はベンダーの新機能ロールアウトではなく、セキュリティテストから得られた運用上の学びです。Datadog Security LabsはCopilot Studioにおける「ログのギャップ」について、特定のイベントを生成しようとした取り組みや、再テスト時にイベント生成が一貫していなかった可能性を含む調査結果を公開しています（securitylabs.datadoghq.com
実行レイヤー型のワークフローを導入する企業は、**監査可能性の受け入れテスト（auditability acceptance testing）**を実施すべきです。これはガバナンス部門でも“必須の工程”としては扱われにくい、実務的なステップです。例えば次を確認してください。
このケースは、「監査可能性／可観測性」というキーワードを現実に固定します。ログは“企業ツールを使えば得られるもの”ではなく、成果物（deliverable）なのです。
実行レイヤーの再設計は、Microsoft中心の物語にとどまりません。各国がAIガバナンスの準備状況や分野別ルールをどう定義するかとも交差します。
インドネシアでは、UNESCOと情報通信省（KOMINFO）がUNESCOのRAM手法を用いた「AI準備状況評価（AI Readiness Assessment）」を完了し、2024年10月9日に報告しています（unesco.org
分野別の方向性としては、PwCインドネシアの「Digital Trust」ニュースフラッシュが、2025年4月29日にOJKが「インドネシアの銀行向け人工知能ガバナンス（Artificial Intelligence Governance for Indonesian Banking）」を導入したことに言及しています（pwc.com
より深い編集上の論点は、「ローカルなガバナンス」がどのように“ワークフロー設計の要件”へ変換されるかです。監督とエビデンスを規制当局が求める状況では、モデルが何をしたかについて“事後の物語”に頼ることはできません。必要なのは、誰が何を承認したか、どのアイデンティティの下で行われたか、どのデータ境界が有効だったか、そしてアクションの瞬間にどんなログが残ったか、というワークフローによって生成される成果物です。だからこそ実行レイヤーの統制――承認ゲート、ゾーン制限の権限、そして監査可能性の検証――は、法域をまたいでも持ち運べるコンプライアンスの基本部品になるのです。
ここで、取り上げた専門的なワークフロー類型――カレンダー管理、リサーチからスライドへのパイプライン、文書生成フロー――に具体的に落とし込みます。
カレンダーワークフローは、結果が「単に予定を入れるだけ」に見えるため、つい全自動化したくなります。しかし実行レイヤーが効いてくるのは、スケジューリングが会議や社内コミットメント、そして外部の利害関係者のコミットメントを連鎖的に発動し得るからです。したがって：
承認ゲートは、非定型の変更に対して発火させるべきです。外部の招待者、保護された予定との競合、または組織ポリシーを越えるような場合が該当します。人間の判断が置かれるべき場所は、“ビジネス文脈”が宿るところにあります。
リサーチからスライドへの仕事は、プロの判断が“創造性”に見える領域です。しかし実行レイヤーの言葉に直すと、判断とは検証です。エージェントはスピーディにスライド草案を作れますが、幹部は出所、社内の整合性、そして明確な出典境界を必要とします。
ワークフロー再設計には、次を組み込むべきです。
これは、Microsoftがエージェントのアクションに求める「監査可能性／可観測性」の枠組みに直結します（learn.microsoft.com
文書生成は、しばしば草案作りの問題として扱われます。しかし実行レイヤーの設計は、それを権利と配布の問題として再定義します。誰が作成でき、誰が公開でき、そしてレビュー後に誰がバージョンを変更できるのか。ここが“実効的なゲート”です。
Microsoftのガバナンスモデルは承認のワークフロー・ステージ（AI承認を含む）を支え、重要な判断では人間の制御が必要であることを強調します（learn.microsoft.com → review → publish）を防ぐためにも使うべきです。草案から公開までの流れは、ログされたゲートとアイデンティティ相関を備えた、管理されたシーケンスであるべきです（learn.microsoft.com
有用な思考モデルは、各ワークフローのステップを3つの層に対応づけることです。
人間の判断は主に閾値の意思決定（threshold decisions）に置かれるべきです。例外、曖昧なコンプライアンス状況、高影響の配布判断など。ログは意思決定ポイントと副作用の周りに置くべきです（ツール呼び出し、文書への書き込み、配布／公開のアクション）。会話のターンだけをログしても、本質の説明になりにくい。ポリシー執行は、最終出力の前だけでなく、状態遷移の周りに配置するべきです。
そして企業としての再設計の課題も組織にあります。法務、セキュリティ、運用のチームが、ワークフロー自動化のプロダクトオーナーと協働し、ゲートが一貫していてテスト可能になるようにしなければなりません。
Copilot Coworkのような「実行」が当たり前になっていくなら、企業の差別化要因は“最速で下書きを作るエージェント”ではありません。差を生むのは、企業が委任された作業を確実に制約できるかです。サンドボックスに似たゾーン制御、アイデンティティ境界、監査可能な承認によって、あらゆるタスクを官僚的なボトルネックにせずに統治できるかどうかが問われます。
政策提言（具体的なアクター）： CIOおよびCISOは、本番投入するあらゆるAI対応エージェント型ワークフローについて、「実行レイヤーの準備度レビュー（execution-layer readiness review）」を必須要件として求めるべきです。受け入れ基準は3つです。
(1) 依頼者ユーザー、または狭く定義されたエージェント・アイデンティティへのマッピングとしてのアイデンティティ境界の強制（techcommunity.microsoft.com
(2) 高影響ステップの前に状態変更を止める承認ゲートを埋め込むこと。必要に応じてAI承認を用い、ポリシーの閾値が人間のレビューを要求する場合は人間の確認を組み込むこと（learn.microsoft.com
(3) Purviewでのエンドツーエンド監査可能性の検証（イベントの存在および判断の相関を含む）。ログ挙動は“前提として置く”のではなく、検証すべきだと明確に認めること（learn.microsoft.com securitylabs.datadoghq.com
予測（四半期つき）： 2026年Q3までに、企業のガバナンス・プログラムは「モデルリスクレビュー」から「ワークフロー実行契約」へと成熟していく見込みです。そこではチームが、承認ゲート、アイデンティティ境界、可観測性を“必須のインターフェース仕様”として扱うようになります。これはIAMや他の本番システム向けの監査要件を扱うのと同様の考え方です。この見通しは、監査可能なアクション、ゾーン型ガバナンス、可観測性の計測を重視するMicrosoftのエージェントガバナンス指針の方向性に沿っています（learn.microsoft.com learn.microsoft.com
実務家にとってのアクション可能な転換点は、次の問いに基づいてワークフローを組み直すことです。エージェントが「共有される現実」に触れる前に、何が真実でなければならないのか――カレンダー、文書、チームや幹部が依存する社内の知識です。人間の明示的なチェックポイントと検証可能なログを備えた実行レイヤーを作れば、プロの仕事はより速くなる一方で、説明不能にはならないはずです。