重みではなく実行を: : Qwen 3.5のエージェント型ワークフローが、法務・金融・エンジニアリング・ヘルスケアにツール呼び出しを「プロダクト」として統治させる理由

無視できない転換——「答え」から「ツール実行」へ

企業におけるAI導入の第1波では、組織は正確性によって評価されました。だが今回は、実行によって評価される段階です。

コパイロットが、システムを呼び出せるエージェント型ツールへと進化し、出願書類の作成、コード変更の生成、臨床イベントの要約といった作業を担えるようになると、問いは「モデルは賢いか？」から「その実行内容を証明できるか？ 誰が実行を許可したのか？ 次に何が起きたのか？」へと入れ替わります。

その“運用上の証明”は省略できません。知的作業量が多いワークフローでは、小さな失敗が連鎖して急速に広がります。誤った引用は法的リスクになりますし、仕訳が不適切な取引区分に紐づけば監査証跡の問題になります。安全でない装置の改造は規制当局の審査案件になります。さらに欠陥のあるエンジニアリング変更は、信頼性インシデントへ直結します。

そのためエージェント型システムは、エージェントのライフサイクル全体を取り囲む「コントロール・プレーン」の構築を迫ります。許可管理、ツール呼び出しの統治、そして事後に復元可能な監査トレイルです。

オープンモデルやエンタープライズ・プラットフォームは、この現実を前提に設計された機能で応えています。たとえばAlibaba CloudのModel Studioは、Qwen3.5モデルのエージェント能力と本番展開を、管理された環境の中で位置づけています。あわせて、Model Studioを通じて利用した際にモデルがどのように振る舞うのか、モデルが利用可能であることを強調するドキュメントも用意されています。
(Alibaba Cloud Model Studio home; Alibaba Cloud Model Studio “Models” documentation)

ガバナンスを“強制”するものとしてのAlibaba CloudのQwen 3.5展開

Alibaba CloudのModel Studioは、Qwenファミリーのモデルおよび関連機能を展開するための管理された導線を提供しており、QwenとModel Studioに基づく具体的な顧客成果も強調してきました。とりわけ、Alibaba Cloudは、Tongyi Qwen LLMと「Dedicated Model Studio」を用いてAstraZenecaが構築した有害事象サマリーシステムを紹介し、製薬業界における報告の精度と効率の向上に焦点を当てていると説明しています。
(Alibaba Cloud customer story page)

なぜこれがワークフロー統治に重要なのでしょうか。有害事象の報告は、設計上「証拠に敏感」です。規制当局や社内の安全性チームは、追跡可能な入力（システムが見た事象記録や文献は何か）、透明な変換（要約や正規化でどのように文章を扱ったか）、そして説明可能な引き継ぎ（最終的な叙述を誰がレビューし承認したか）を求めます。

エージェント型の仕組みにすると、これらの期待は具体的な実行時の義務に対応します。つまり、ワークフローは、検索やツール呼び出しごとにログを残し、出力の各セクションに使われたソースの識別子を保持し、さらに、システムが「次へ進む」と判断した分岐点と「人に回す」と判断した分岐点を記録しなければならないのです。

Model Studioから伝わる商業的シグナルも、同じ方向性を補強します。採用は、モデルが“使える”だけで測られるのではなく、“本番利用されているか”で測られるべきだ、という主張です。Alibaba Cloud自身のブログは、Model Studioを通じたQwenの大規模展開について「初年度における90,000件超のエンタープライズ展開」を挙げています。
(Alibaba Cloud blog)

この数字は査読済みのベンチマークではありません。ただし、Model Studioが単なる実験用のサンドボックスではなく、運用上の環境として扱われ始めていることを示唆します。まさにその条件下で、統治要件は硬くなっていくのです。

実際のところ、Qwen 3.5型のエージェント・ワークフローは、企業に次の3つの統治プリミティブ（基本要素）の構築を促します。

1. 許可管理：誰がツール利用を有効化できるのか、どのツールがどの条件下で呼び出せるのか。ツール呼び出し型システムでは、これは能力の境界線になります。検索ツール、データアクセスツール、チケット／ワークフロー・ツール、そして「外部アクション」ツール（提出、支払い、エスカレーション）を、単一の全能ロールで共有してはなりません。
2. ツール呼び出しの統治：エージェントが外部システムを自動で呼び出してよいのか、どんな承認ゲートがあるのか、失敗が起きたときにどう扱うのか。必要なのは「承認／不承認」だけではありません。タイムアウト、部分的な検索、競合するソースといった明示的な失敗セマンティクスが、エージェントが次に実行してよいことを決めるのです。
3. 監査対応の実行：インシデント調査、コンプライアンス審査、事後検証（ポストモーテム）に耐えるログです。エージェントの場合の「監査対応」とは、ツールの連鎖（入力→ツール呼び出し→中間成果物→最終出力）を復元でき、さらにその連鎖を、実行時に有効だったワークフロー設定とポリシーのバージョンに紐づけられることを意味すべきです。

統治の細部は業界によって異なります。しかし、法務・金融・エンジニアリング・ヘルスケアに共通するのは、実行レイヤーの要件が一貫している点です。

監査トレイルが、専門業務の新しい「ユニットテスト」になる

エージェント型システムにおいて「監査トレイル」は、単なるコンプライアンス上の後付けではなく、実行時の要件へと変わります。イベントの連鎖を再構成できなければ、責任を割り当てられません。プロセスのズレも修正できません。そして、規制当局、顧客、社内のリスク担当者に対して、ワークフロー上の判断を擁護できないのです。

監査可能性が最も強く求められるケースは抽象的ではありません。テストが失敗したとき、エンジニアリングチームが実際に問うのと同じ種類の問いが、統治の言葉に翻訳されているだけです。たとえば次のような点です。

• このユーザー要請に応じて、どのツール呼び出しが行われたのか？
• どの文書や記録が取得されたのか（そしてどのバージョンか）？
• 自動で進めるかどうかを決めたポリシーバージョンは何か？
• ワークフローはどこで分岐したのか——人のレビュー、エスカレーション、再試行、フォールバックのいずれへ、そしてなぜそうしたのか？

エージェントが要約し、下書きを作り、提出できるなら、「監査トレイル」は証拠の経路（検索と変換）だけでなく、統制の経路（ポリシー判断と承認）もカバーしなければなりません。

「監査可能性」が主流になったことを示す統治のエコシステムも、すでに見えてきています。ヘルスケアの文脈では、FDAが人工知能／機械学習を可能にした医療機器に対して示すアプローチは、あらかじめ定めた変更管理計画（PCCPs）を重視しています。これは、新しいデータに応じてAI／MLソフトウェアを安全かつ迅速に変更できるようにするための仕組みです。FDAは2023年10月にPCCPのガイダンス原則を公表し、PCCPを、レビュー・ライフサイクルのすべての工程をやり直すことなく変更を管理するためのメカニズムとして位置づけました。
(FDA announcement on PCCP guiding principles)

より広い意味でのデータ保護と統治では、英国情報コミッショナー事務局（ICO）が、AIシステムに関する統治と説明責任の一部として、データセットへのアクセスを記録し監視するための「包括的な監査トレイル」の構築について明示的に論じています。
(ICO governance and accountability in AI)

これらは一般論としてのコンプライアンス声明ではありません。エージェント型のワークフローに直結しています。データセットへのアクセス、ツール呼び出し、実行時の判断——すべてが構造化されたログを必要とします。エージェント型システムは、ログ問題を増幅させます。単一のユーザー要請が複数のツール呼び出しを誘発し、さらに各ツール呼び出しが規制対象の入力に触れる可能性があるからです。実務上の含意は、監査ログをフラットなテキストの記録ではなく、「因果のグラフ」として設計しなければならない、ということになります。つまり、政策判断→ツール呼び出し→成果物→出力セクションへと、調査者が辿れる形にする必要があるのです。

OpenAIのエンタープライズ向けツールも、この運用志向を反映しています。APIプラットフォーム向けに「Admin and Audit Logs API」を提供し、セキュリティチームがセキュリティ上の問題やコンプライアンス上のリスク、そして運用手順のギャップを特定できるようにする目的の「不変で監査可能な」イベントログだと説明しています。
(OpenAI Help Center: Admin and Audit Logs API)

プロフェッショナル・ファームにとって重要なのは、いずれかのプラットフォームが“すべてをログに残すかどうか”ではありません。エージェント型ワークフローが今や要求する最低基準が、次の点にあることです。すなわち、何が起きたのかを再構成でき、かつシステムの行為が承認されたポリシーと設定に適合していたかを判断できるだけの、監査可能なツール利用と実行状態の記録です。

責任は実務でどう生まれるか——責任はツールの連鎖に沿って動く

専門業務における責任問題は、望ましくない結果が出た後にだけ生じるわけではありません。AIシステムに「下書き以上のこと」をさせた瞬間から始まります。

エージェントがツールを呼び出すとき——特に外部当事者に影響し得るツールでは——責任は分散します。エージェントを許可した組織、モデル挙動とプラットフォーム統制を提供したベンダー、そしてツール呼び出しのシーケンスを組み上げた開発チームです。ツール連鎖が自律的であるほど、組織はガバナンスと監督の実証をより強く求められます。

規制の枠組みも、この方向を映し始めています。たとえばFDAのPCCPガイダンスは、変更を安全に管理し、変更プロトコルや影響評価の期待と結びついた文書を伴うことを意図しています。つまり、その枠組みは暗黙に、監査可能性と管理されたライフサイクル管理を安全性の一部として扱っているのです。
(FDA announcement on PCCP guiding principles)

ソフトウェアとプラットフォームの世界では、MicrosoftのPurviewにおけるCopilotやAIアプリケーションの監査ドキュメントが、AI関連のやり取りを記録する監査ログの利用可能性に言及し、セキュリティやコンプライアンスチームがそれを活用できるとしています。Purview上で監査ログへアクセスし、操作名やプロパティでフィルタして記録を検索できることも説明されています。
(Microsoft Learn: Audit logs for Copilot and AI applications)

知的作業量の多い組織にとっての法的含意は、細かな判例法は異なり得るとしても、かなり明快です。ツールの連鎖が示され、ログに残され、統治されているなら、責任の議論は「モデルが予測不能なことをした」から「承認されたワークフロー手順を、段階ごとにレビューできる」に移ります。言い換えれば、監査トレイルはコンプライアンス上の道具であるだけでなく、責任追及の道具にもなるのです。

実例：AstraZenecaの有害事象ワークフローと実行レイヤー

AstraZenecaの有害事象サマリーシステムは、「重み」ではなく「実行」を体現している、規制下の知的ワークフローにおける最も分かりやすい例の一つです。Alibaba Cloudは、AstraZenecaがTongyi Qwen LLMとDedicated Model Studioを用いて有害事象サマリーシステムを構築したと説明し、報告の精度と効率の向上を強調しています。
(Alibaba Cloud customer story page)

時系列の観点では、Alibaba Cloudの公開された顧客ストーリーは、抜粋部分において特定のローンチ日を必ずしも明示していない可能性があります。ただし、ワークフローとプラットフォーム機能との、文書化された結びつきは提示されています。編集目的でより重要なのは、そうした仕組みによって生じる企業側の期待の転換という“タイムライン”です。すなわち、チームはモデル支援による下書きを、エビデンスの取り扱いとレビューゲートを組み込んだ再現可能なパイプラインに変換しなければならない、という点です。

「実行レイヤー」を具体化するなら、通常は社内試験から監査可能な有害事象ワークフローを分ける統治要件は、次のような形になります。

• 入力の来歴（エビデンスの紐づけ）：出力の各文、または構造化された各フィールドは、入力記録に追跡可能であるべきです（例：有害事象のケース文や、キュレーションされたソース断片）。実務的には、検索で取得した文書の識別子をログに残し、各要約セクションに使われた“原文の該当箇所”を正確に保持することを意味します。
• ツール呼び出しの統制（能力のスコープ設定）：エージェントは、要約とエビデンス取得に必要なツールだけを呼び出せるようにすべきで、さらに「外部アクション」（たとえば安全性システムへの提出）は、明示的な承認ゲートの背後に分離しておかなければなりません。
• レビューおよびリリースのワークフロー（判断のルーティング）：人は単なる最終編集者としてではなく、判断ポイントとして配置されるべきです。ワークフローには監査可能なルーティング規則が必要です。たとえば「レビューが必要」となるトリガー（低い信頼度、エビデンス欠落、規制に敏感なフィールド）、エスカレーションのトリガー、「自動リリース」のトリガーは何か。さらに、どのような条件でそう判断するのかを明確化します。
• 変更管理（バージョン付きのワークフロー設定）：プロンプトテンプレート、検索設定、ツール定義、変換ロジックはバージョン管理されるべきです。エージェントの挙動が変わった場合、組織は、保存された設定スナップショットを使って、その変更が「特定の提出の前か後か」を答えられる必要があります。
• 失敗セマンティクス（エージェントが確信を持てないとき何をするか）：検索が失敗したり、ソースが競合したり、必要フィールドが欠けている場合、エージェントは（a）欠けている入力を求める、（b）構造化された「エビデンス不足」出力を作る、（c）人に回す——のいずれかを行うべきです。捏造したり、黙って劣化させたりしてはなりません。

AstraZenecaが述べたユースケースは、採用が「モデルを試す」から「パイプラインを運用する」へ移る過程をどう示すか——そしてそれはモデルの正確さを証明することでなく、ワークフローの各ステップが事後に検査可能になるようにすることで起きるのだ、ということを示しています。

実例：モデルのライフサイクル実行に対する統治の青写真としてのFDA PCCPs

ヘルスケアは、エージェント型ワークフローの責任が特に鋭く問われる領域の一つです。モデルの挙動が安全性や臨床的意思決定支援に影響し得るからです。

FDAの2023年10月の発表は、あらかじめ定めた変更管理計画に関するもので、人工知能／機械学習を可能にした医療機器の更新や改造をどう管理するかというアプローチを示しています。PCCPを、モデルが新しいデータに応じて進化していく中でも、安全性と有効性を担保するためのメカニズムとして位置づけているのがポイントです。
(FDA announcement on PCCP guiding principles)

特定の製品が、チャットボットの意味での「ツール呼び出し」を含まない場合でも、根底にある統治ロジックはエージェント型ワークフローにそのまま移植できます。実行時の変更を許すのであれば、管理された変更経路、文書化、そしてトレーサビリティが必要になるからです。

臨床運用でエージェント導入を進める企業に対する編集上の結論は、医療機器モデルの更新で必要とされるのと同じライフサイクル規律を、エージェントのツール連鎖にも翻訳しなければならない、ということです。具体的には、バージョン付きのツール設定、監査可能な実行記録、そして変更に対する事前の監督期待です。

実例：MicrosoftのCopilot監査ログと、企業が目指す運用可視化への移行

法務と金融の領域において、採用の障壁として最も粘り強く残るのは、モデル性能そのものではありません。運用可視化（オブザーバビリティ）です。インシデント後に、セキュリティやコンプライアンスチームが「何が起きたのか？」に答えられることが求められます。

MicrosoftのPurviewにおけるCopilotおよびAIアプリケーションの監査ログに関するドキュメントは、組織が監査ログと検索機能を使ってAI関連のイベントを見つけられること、そして操作名や関連プロパティでのフィルタ方法などのガイダンスを含んでいることを示しています。
(Microsoft Learn: Audit logs for Copilot and AI applications)

さらにMicrosoftは、Copilot Studioの監査ログについても文書化しており、監査イベントやトランスクリプトがどのように記録され、管理者がどこでログにアクセスできるかを説明しています。
(Microsoft Learn: View audit logs for admins, makers, and users of Copilot Studio)

これが「エージェント型」へのシフトで重要になるのは、エージェントがツール呼び出しを許可された瞬間、組織にはソフトウェアの変更管理に匹敵するプラットフォームレベルの可視化姿勢が必要になるからです。多くの企業では、AI監査ログを、eDiscovery、データ損失防止（DLP）のワークフロー、そして社内のインシデント管理のような幅広い統治システムと統合することが意味を持ちます。

法務、エンジニアリング、金融の各チームにおける実務上の採用パターンは、ますます同じになっています。つまり、まずはコパイロットを試す（パイロットする）が、ツール連鎖に対する監査ログが存在し、組織がそれらを反復可能な形でエクスポートまたは問い合わせできるようになってからでないと規模拡大しない、ということです。

実例：プラットフォーム層としてのOpenAIのエンタープライズ・コンプライアンスと監査ログ

OpenAIのエンタープライズ向けツールは、監査ログやコンプライアンスのエクスポートを、企業が実運用できるものとして明示的に位置づけています。

2024年7月、OpenAIはChatGPT Enterprise向けの新ツールについて説明しました。「ChatGPT Compliance API」を「Compliance Logs Platform」に組み込むアップデートや、「不変でタイムウィンドウ化されたJSONLログファイル」を通じて観測可能性とコンプライアンスデータをエクスポートできることを強調しています。また、統合は金融、ヘルスケア、法務サービスといった規制産業にも対応すると述べています。
(OpenAI: New compliance and administrative tools for ChatGPT Enterprise)

これは編集上の主張とも一致します。エージェント型の層が拡張するほど、ログはプロダクト体験の一部になります。「単なる監視」ではなく、実行を証明できるという企業側の能力なのです。

ここで見える採用パターンは、プラットフォームが機能をどう説明するかにも表れています。彼らは、ガバナンスのアウトプット（監査ログ、不変のイベント記録、コンプライアンスのエクスポート）を前面に出します。企業が「必須」とみなすものが変わったからです。

採用が実際に起きる場所——モデル点よりも「統治の準備度」

知的業務における採用パターンは、ますます「パイプライン型」になっています。チームはまず、狭いワークフローの中にコパイロットを投入します。その後、統治プリミティブが成立して初めて能力を広げていくのです。

定量面では、KPMGの2024年の報告が示すのは、米国の金融機能でのAI導入です。米国企業の62%は中程度または大きな割合でAIを利用しており、58%が生成AIをパイロットまたは導入しています。さらに52%は金融報告においてAIを使っています。
(KPMG US: AI adoption across US finance functions reaches highest levels)

これらの数字は勢いも示す一方、実務上の制約も示します。導入がすでに広がっているとしても、「パイロット」と「本番」の差は、多くの場合、レビュー可能性や統制を含む統治の成熟度と相関します。

エンジニアリング側でも、可視化要件は、プラットフォームベンダーが保持期間や管理者の可視性をどう定義するかに現れています。GitHubのチェンジログは、ユーザー管理APIフィールドに関する保持ポリシーの更新を示しており、その中には、当該APIエンドポイントのパブリックプレビューで「last_activity_at」を90日保持する方針への切り替えが含まれています。
(GitHub Changelog: retention period to 90 days)

これらの産業を横断して一貫しているのは、組織が下書きの段階でのモデル不確実性には多少は耐えられても、ツール実行の段階での不確実性には耐えにくい、という点です。したがって、統治は規模拡大のための門（ゲート）になります。

企業が構築している定量的なガードレール

エージェント型ワークフローを運用に乗せるため、企業は「政策（ポリシー）」を「エンジニアリング指標」へ翻訳する定量的な統治指標を導入しつつあります。指標の厳密な中身はベンダーやコンプライアンスの枠組みによって異なりますが、統治の潮流と期待を示すデータポイントとして、次の3点が象徴的です。

• 90日：GitHubのCopilot関連のユーザー管理APIフィールド（「last_activity_at」）におけるパブリックプレビューでの保持は、2025年2月18日開始の更新として90日へ設定されています。
  (GitHub Changelog)
• 62%、58%、52%：KPMGの2024年の調査では、米国企業が金融機能でAIを中程度または大きな割合で使っている割合（62%）、生成AIをパイロットまたは導入している割合（58%）、金融報告においてAIを使っている割合（52%）がそれぞれ示されています。
  (KPMG US report)
• 90,000件超のエンタープライズ展開：Alibaba Cloudが、Model Studioを通じたQwenの展開が初年度に「90,000件超のエンタープライズ展開」に到達したとする主張です（同社ブログの文脈で提示）。
  (Alibaba Cloud blog)

これらの数字はそのまま互換ではありません。しかし指し示す現実は同じです。企業は実験からワークフロー統合へ移行しており、その移行には統治と監査可能性のためのエンジニアリングが必要になります。

許可管理の問い——エージェントのライフサイクル・パイプラインを設計する

「重み」がモデルの脳だとすれば、「エージェント・ライフサイクル・パイプライン」は組織の神経系です。そこには、作成、承認、テスト、展開、実行時の統制、インシデント対応、そして廃止までが含まれます。

Alibaba CloudがModel StudioをQwenモデルの運用環境として位置づけることで、展開を標準化したい企業にとって、この“パイプライン志向”の見取り図は現実味を帯びます。
(Alibaba Cloud Model Studio home; Alibaba Cloud Model Studio models documentation)

一方、MicrosoftやOpenAIのプラットフォーム・ドキュメントは、監査ログやトランスクリプトが、隠れた痕跡ではなく、エンタープライズの一次成果物として扱われるようになっていることを示しています。
(Microsoft Learn: Audit logs for Copilot and AI applications; OpenAI Help: Admin and Audit Logs API)

では、企業はQwen 3.5型のエージェントによるツール呼び出しを導入する際、何を運用可能な形にすべきでしょうか。

1. ツール境界での許可管理：各ツール（文書の検索、請求照会、コード実行、臨床記録の要約）を、明示的なスコープを伴う「許可された能力」として扱います。
2. 呼び出しポリシーをコード化する：プロンプト内の「指示」に依存するのではなく、承認ルールとフォールバック挙動を実装としてエンコードします。
3. 監査トレイルの完全性基準：監査人やインシデント対応者が実行を再構成するために、何をログとして残す必要があるかを定義します。
4. ヒューマン・イン・ザ・ループのトリガー：特に外部へのアクション（提出、支払い、臨床的に重要な出力）の前に、人の承認が必須となるタイミングを設計します。

規制下の知的業務における許可管理は、単なるIT設定ではありません。組織の代理としてエージェントが何をしてよいかを定義する“契約”です。

政策提言と、今後12か月の実務的な見通し

安全に規模拡大したい企業は、次の単純なルールを採用すべきです。監査対応の統治成果物なしに、エージェント型のツール呼び出しを行わないこと。

提言（ポリシーと運用モデル）：CFO、GCオフィス（法務）、CIO、CISOは、法務・金融・エンジニアリング・ヘルスケアのあらゆるエージェント型ワークフローについて、監査可能な実行記録を必ず生成することを求めるべきです。その記録には、ツール呼び出しイベント、ポリシー判断のトレース、そして実行時点におけるバージョン付きのワークフロー設定が含まれていなければなりません。具体的には、リーダーは、デプロイのチェックリストにおいて「監査の完全性」のサインオフを義務化し、可能ならプラットフォームの監査ログを活用します（たとえばMicrosoft PurviewのCopilot／AI向け監査ログ、OpenAIのAdmin and Audit Logs APIの機能など）。
(Microsoft Learn: Audit logs for Copilot and AI applications; OpenAI Help: Admin and Audit Logs API)

見通し（タイムライン）：2026年3月20日から今後12か月の間に、規制下のプロフェッショナル・サービス領域では、「コパイロットのパイロット」から「エージェント・パイプラインの標準化」へ加速する可能性が高いです。理由は、監査ログと統治コントロールが、本番展開の可否を決めるゲーティング要因になってきているからです。構造的な要因もあります。財務領域ではすでに導入の裾野が広い（KPMGの2024年の数字では、半分超が生成AIをパイロットまたは導入）ことに加え、規模拡大の圧力が、統治を形式知化しない限り手戻りやインシデント対応のループで詰まる状況を生みます。
(KPMG US report)

この期間で勝ち残るのは、必ずしも最高のベンチマークを持つ組織ではありません。勝つのは、実行を証明できる組織です。