Hippocratic AI、医療成果に向けたエージェントチームを発表

Hippocratic AIは、Google Newsで取り上げられた限定的な製品発表にとどまらず、単目的の音声エージェントを超えるAgentic Orchestratorsを導入した。このプラットフォームは、患者フォローアップ、服薬アドヒアランス、治験継続率、再入院削減といった成果を軸に、専門エージェントのチームを連携させる。

この違いは重要だ。病院が直面しているのは、単発の電話対応だけの問題ではない。予約の取り逃し、分断されたシステム、変化する患者ニーズ、繰り返される引き継ぎを含むケアジャーニーに苦慮している。タスクに特化したボットは一つの対話を完了できても、より広い問題は未解決のまま残り得る。

Hippocratic AIは、オーケストレーションによってこうした断絶を埋められると見込んでいる。一つのエージェントに固定スクリプトを割り当てる代わりに、同社のプラットフォームは、複数のエージェント、安全システム、人へのエスカレーション経路を、運用上の目標に沿って組織化する。

直接の対抗相手は、特定の音声AIベンダーではない。それぞれのアシスタントが狭い単一ワークフローを担い、残りの作業を別の場所へ渡す、一般的な単一エージェント導入モデルだ。

Hippocratic AIはすでに、Polarisの安全性アーキテクチャ内で連携モデルを活用してきた。Agentic Orchestratorsは、その連携をモデルレベルの監督から、医療ワークフロー全体へと拡張する。同社は実質的に、社内の安全性パターンを、より広い運用モデルへ転換している。

Google Newsの見出しは、会話型エージェントを連携させるプラットフォームを説明している。より重要な転換は、自動化タスクを販売することから、複数ステップにまたがる成果に責任を負うことへの移行だ。

Hippocratic AIは成果を中心にエージェントを組織化する

Agentic Orchestratorsは、エンドツーエンドの目標に責任を持つ複数の医療エージェントを、連携チームとしてパッケージ化する。

Hippocratic AIは、オーケストレーターを、医療保険プランの加入者維持や臨床試験の進行維持といった課題に対して、連携エージェントを展開するシステムと説明している。同社は、医療提供者、保険支払者、ライフサイエンス企業、医療技術事業者にまたがる利用可能なワークフローを整理している。

医療提供者向けのカタログは、患者オンボーディング、薬局サポート、入院患者教育、外来ケア、再入院削減、フォローアップ回復を対象とする。医療システムは、予約の取り逃し、紹介、検査結果、慢性疾患に関するワークフローも設定できる。

保険支払者向けのカタログには、健康リスク評価、服薬アドヒアランス、慢性期ケア、ネットワーク管理、加入者維持、緊急対応が含まれる。ライフサイエンス向けの用途は、治験登録、参加者維持、医薬品安全性、リアルワールドエビデンス、患者支援をカバーする。

これらは、単なるチャットボットのメニュー上のカテゴリーではない。各成果には、異なる会話スキル、データ連携、検証手順、エスカレーションルールが必要になり得る。

推奨された肺スキャンを受け損ねた患者を考えてみよう。一つのエージェントはフォローアップの必要性を説明できる。別のエージェントは予約取得を支援し、さらに別のエージェントが交通手段や保険に関する質問を処理する。

通話スーパーバイザーは、コンプライアンス、臨床上の誤り、感情的なシグナル、問題解決の成功について会話を監視できる。システムが緊急性を検知した場合、または許可された範囲を超える判断に遭遇した場合には、人間のスタッフが介入できる。

Hippocratic AIによれば、オーケストレーターは同社のPolarisプラットフォーム上で稼働する。同社のorchestrator catalogには、フォローアップ逸失、再入院削減、薬局業務、品質評価、治験運営のグループが含まれる。

この発表は、複数の既存製品も結び付ける。AI Front Doorは幅広い患者アクセスのニーズを処理し、Nurse Co-Pilotは入院患者教育と関連する看護ワークフローを支援する。

AI Call Supervisorは、他のエージェントについてコンプライアンスと臨床上の誤りを検査できる。AI Self Serviceは、組織が追加エージェントを設計、シミュレーション、認定、改善するのを支援することを意図している。

この製品アーキテクチャは、購入者が評価する対象を変える。病院はもはや、エージェントが予約電話を終えられるかだけを問うのではない。連携システムが患者をケアパスウェイ全体にわたって前進させられるかを問う必要がある。

つまり、成功は会話品質だけに依存しない。オーケストレーターは文脈を維持し、完了した行動を検証し、結果を記録し、例外を認識し、責任を安全に移管しなければならない。

発表に触れたGoogle Newsの読者には、音声AIのさらなる拡大に見えるかもしれない。医療の購入者には、患者との接点から測定可能な解決に至るまでの作業を、一つのベンダーがより多く連携させるという、より大きな提案として映るだろう。

同社は、カタログに掲載されたすべてのオーケストレーターについて、独立した成果データを公表していない。そのため、多くの提供内容は、顧客が導入範囲、完了率、臨床結果を報告するまで、製品上の主張にとどまる。

この留保は重要だ。幅広いカタログは製品の広がりを示すが、すべての連携ワークフローが本番環境で確実に機能することを示すものではない。

このプラットフォームは単一タスク型の医療エージェントに圧力をかける

Hippocratic AIは、医療自動化を一度に一つのタスクとして購入・管理すべきだという考え方に挑戦している。

医療組織は一般に、予約リマインダー、文書化、電話振り分け、患者教育のために、限定的なアシスタントを導入してきた。このアプローチは、各ツールの目標が限定され、境界も比較的明確であるため、リスクを低減する。

一方で、分断も生む。患者は教育目的の電話を終えても、交通手段を確保できないままかもしれない。服薬リマインダーが成功しても、保険上の障壁によって処方薬を受け取れない場合がある。

単一タスクのエージェントは、こうした未解決の問題を別のキューへ引き渡すことが多い。テクノロジーは割り当てられたタスクを完了するが、医療組織はなお運用上の負担を負うことになる。

オーケストレーターは、その連鎖自体を管理しようとする。専門エージェントを選択し、関連する文脈を維持し、行動を検証し、最初の対話で新たなニーズが判明した際には別のワークフローを起動できる。

最初に圧力を受けるのは、スタンドアロンの音声エージェントを販売するベンダーだ。より深い専門性、または連携ワークフローに参加するための信頼できる方法を示さなければならない。

この発表は、個別のパイロットを積み上げてきた医療システムにも圧力をかける。リーダーは、これらのツールを自ら統合するのか、それともより多くの活動を一つのオーケストレーションプラットフォームの下に集約するのかを決めなければならない。

オーケストレーションを社内で構築すると、よく知られたエンタープライズ上の課題が生じる。チームには、共有されたアイデンティティ制御、標準化された記録、監視、ワークフローの所有権、競合するエージェント出力を解決するルールが必要になる。

医療では、さらに厳格な要件が加わる。患者の同意、プライバシー、臨床エスカレーション、監査可能性、正確な文書化は、すべての引き継ぎで一貫していなければならない。

連携プラットフォームは一つの制御層を提供するが、依存関係も集中させる。オーケストレーターが文脈を失ったり、誤ったワークフローを選んだりすれば、その誤りは孤立した一つのアシスタント内のミスよりも遠くまで広がり得る。

Hippocratic AIの以前のAI Front Doorは、この戦略を示している。同社によれば、この製品は、一つの継続的な関係の中で、予約、請求、検査に関する質問、処方、交通手段、ケア指示を処理できる。

この製品は、31の連携した大規模言語モデルを使用していると報じられている。4月のvoice AI reportによると、初期導入先としてWellSpan HealthとCincinnati Children’sが挙げられていた。

この従来の設計は、一つの患者アクセス製品の内部でモデルを連携させていた。Agentic Orchestratorsは、この考え方を別々の医療目標と専門エージェントにまたがって広げる。

したがって、この変化は技術レベルでは進化的だが、商業レベルではより野心的だ。Hippocratic AIは、顧客に別の孤立した自動化ツールではなく、成果レイヤーを購入してもらおうとしている。

競合各社はいくつかの方法で対応できる。独自のオーケストレーションシステムを構築する、共通のエージェントプロトコルを介して接続する、あるいは医療組織がオーケストレーションの制御を維持すべきだと主張することだ。

医療システムは、異なるベンダーが異なる臨床領域で優位に立つ場合、モジュール性を好むかもしれない。統合コストや説明責任の空白が、各ツールを別々に選ぶ利点を上回る場合には、集約を好む可能性がある。

決定的な問いは、所有権だ。複数のエージェントが一つのケアジャーニーに参加する場合、誰かが文脈、権限、エスカレーション、文書化、最終成果を担わなければならない。

Hippocratic AIは、その役割に自社プラットフォームを充てようとしている。この発表は、すべての単一タスク提供者に対し、自社エージェントの仕事が終わった後、誰が作業を連携させるのかを説明するよう圧力をかける。

Hippocratic AIが会話型音声AIを連携させる方法

中核となる仕組みは、厳格に管理された専門化であり、狭く焦点を絞ったエージェント、検証役、スーパーバイザーが一つの会話経路を支える。

Hippocratic AIは、その基盤設計をコンステレーション・アーキテクチャと呼ぶ。主たる会話モデルが患者と対話する一方、専門モデルが服薬安全性、プライバシー、エスカレーションロジック、ポリシー準拠、臨床的一貫性を監視する。

一部のスーパーバイザーは、同期的なゲートとして機能する。安全でない応答が患者に届く前にブロックできる。他方は非同期で監視し、後続のターンに影響を与えたり、フォローアップの行動を起動したりする。

この設計は、すべての判断を一つのモデルに依存することを避けようとしている。汎用モデルは自然な会話を維持できる一方で、専門システムは、より高い臨床的または運用上のリスクを伴う部分を確認する。

同社の6月のengineering explanationによると、初期の単一モデルのプロトタイプは、臨床上の質問に対する精度が約80%で頭打ちになった。Hippocratic AIは、知識の不足だけでなく、不整合がこの限界をもたらしたとしている。

同社によれば、Polaris 5.0のコンステレーションは、7,500人超の臨床医と70万件超の通話を含むテストで、99.89%の臨床精度に達した。これらの数値はHippocratic AIによるものであり、独立した解釈が必要だ。

同社はまた、Polarisが2億件超の患者対応を処理し、平均満足度が10点満点中8.95だったとしている。対応件数は、ユニーク患者数や完了した医療成果と同義ではない。

それでも、この規模はHippocratic AIに大きな本番シグナルの基盤を与える。音声システムは、アクセント、割り込み、背景音声、変化する意図、不完全な回答に遭遇するが、こうした要素は統制されたデモではほとんど捉えられない。

Hippocratic AIの公表研究は、多くの見かけ上の推論失敗が、音声パイプラインのさらに前段で始まると論じている。自動音声認識は、言語モデルが推論を始める前に、重要な詳細を聞き誤る可能性がある。

そのため同社は、文脈を考慮した音声認識、確認、ターンテイキング、メモリ、レイテンシー管理を統合している。各コンポーネントは、会話が自然でありながら臨床的に安全であり続けるかに影響する。

音声のレイテンシーは、別の制約を生む。安全システムは確認を増やせるが、患者は長い間や繰り返される中断に気付くだろう。

オーケストレーターは、会話に許された時間枠の中で、こうした確認を連携させなければならない。また、どのエージェントが即時に行動し、どのエージェントが対話後にレビューするかを判断するルールも必要になる。

メモリも関連する問題を提示する。システムは、臨床的に重要な詳細を保持しながら、関係のない会話履歴を捨てなければならない。誤った事実を失えば、予約やエスカレーションの判断が変わり得る。

オーケストレーションされたワークフローでは、コンテキストが専門エージェント間を移動するため、メモリー管理が難しくなる。各エージェントは、不必要な保護対象医療情報を受け取ることなく行動できるだけの情報を必要とする。

この問題は、複雑な組織内におけるナレッジマネジメントに似ている。患者データが別途管理されている場合でも、導入企業はポリシー、ワークフロー、意思決定記録のための統制された検索可能なナレッジベースを必要とする。

検証はHippocratic AIのアプローチの中核だ。同社の臨床規模に関する論文では、提案された予約がスケジューリングシステムに実在するかを確認する、ルールベースおよびモデルベースのチェックが説明されている。

同社は、監査対象となったインタラクション全体で、スケジューリングにおけるハルシネーション率が0.49%だったと報告している。オンライン検証器により、この率は0.13%まで低下し、残るケースはオフラインチェックで数分以内に検出されたという。

これらの結果は、オーケストレーションが単一の会話モデルを上回り得る理由を示している。検証器に共感的な応答や長い対話の管理は求められない。記録の正本となるシステムに対し、一つの限定的な確認を行うだけだ。

ただし、連携には固有の失敗経路も生じる。主エージェントが誤った専門エージェントを選択したり、不完全なコンテキストを送信したり、矛盾する推奨を受け入れたりする可能性がある。

オーケストレーターは、意図された医療上の成果を生み出さないまま、複数の技術的ステップを完了することもある。患者が受診できない、あるいは紹介に必要な書類が不足しているなら、予約が入ったこと自体に大きな意味はない。

だからこそ、アウトカム測定が重要になる。完了率、円滑な引き継ぎ、再接触、治療遵守、再入院、未解決の例外は、会話精度だけよりも強い全体像を示す。

専門的な検証がすでにPolarisを支えていることから、この仕組みには信頼性がある。未解決の問いは、そのパターンが対話の監督からケアジャーニー全体の連携へと拡張可能かどうかだ。

Google Newsでの注目は医療アウトカムを検証できない

プラットフォームにとって最大のリスクは、連携したエージェントが会話できるかどうかではなく、報告される成功がより安全で良いケアを反映しているかどうかだ。

音声AI、医療現場の人員不足、エージェントベースの自動化を組み合わせた製品発表は、特にGoogle Newsを通じて急速に広がる。独立したエビデンスが追いつく前に、可視性が顧客の関心を加速させる可能性がある。

Hippocratic AIは、インタラクション量、満足度スコア、臨床医テスト、安全性指標を含む広範な性能主張を公表している。その大半は、同社が作成したもの、または同社主導の研究から得られたものだ。

それは結果に情報価値がないことを意味しない。読者が、検証された対象と公の結論を区別しなければならないという意味だ。

臨床安全性スコアは、定義された基準の下でレビューされた応答を示すことができる。しかし、フォローアップの見落とし、エスカレーションの遅れ、不公平な性能、長期的な患者アウトカムを自動的に測るものではない。

インタラクション数には、短時間の通話、繰り返しの接触、異なるワークフローが含まれ得る。それだけでは、何人の患者がケアを完了したか、あるいはスタッフが後からエージェントをどの程度修正したかは分からない。

同社の研究は有用な運用上の詳細を提供している。予約関連の通話の2.74%では患者が症状に言及しており、事務的な依頼が臨床的エスカレーションへ変わり得ると報告している。

ある事例では、患者が予約手続き中に、転倒、脱力、けがの可能性、薬剤の影響、心理的苦痛について話した。システムはその患者をライブチームの担当者へ振り分けたという。

この例は、狭いワークフローのラベルが誤解を招き得る理由を示している。予約エージェントは、意図された業務が事務作業に見える場合でも、予告なく高リスクの臨床状況に入り込む可能性がある。

Hippocratic AIは、人の判断が必要な場合にエージェントがエスカレーションするとしている。それでも導入企業には、感度、誤警報、応答時間、すぐに人が対応できない場合に何が起こるかに関するデータが必要だ。

同社が公開した臨床フレームワークでは、1,000万件を超える実際の患者通話での展開と、99.9%の臨床安全性スコアが報告されている。また、雑音の多い音声、多言語での継続性、長時間の会話も重視している。

この論文はマーケティングページよりも深い内容を提供しているが、多くの著者はHippocratic AIに所属している。独立した再現検証と顧客レベルのアウトカム報告があれば、結論の説得力は増すだろう。

医療機関は、責任がどのように分担されるかも検討しなければならない。オーケストレーターはエージェント間で業務を割り当てられるが、法的・臨床的な説明責任を同じように委任することはできない。

複数のモデルが関与した場合、見逃されたエスカレーションの責任は誰が負うのか。一方のエージェントがデータを収集し、別のエージェントが行動を選択した場合、欠陥のある引き継ぎを誰がレビューするのか。

監査証跡は、あらゆるステップを再構成できなければならない。そこには患者の発言、取得された情報、エージェントの判断、検証結果、システム上の操作、人による介入が含まれる。

プラットフォームは権限の拡大も防がなければならない。予約準備を説明する権限を持つエージェントが、無関係な請求情報や投薬記録へ自動的にアクセスできるべきではない。

連携が増えれば、攻撃対象領域も増え得る。プロンプトインジェクション、本人確認の誤り、侵害された統合、誤解を招く患者の発言は、接続されたワークフロー全体に伝播する可能性がある。

Hippocratic AIは、隠された意図や安全制御を徐々に回避しようとする試みを含む、複数ターンにわたる敵対的行動を研究してきた。ただし、継続的なテストの重要性はリリース時のベンチマークを上回る。

モデル、プロンプト、統合、顧客ポリシーが変われば、性能も変化し得る。数十のオーケストレーターを管理するプラットフォームには、各組み合わせに対するバージョン管理と回帰テストが必要だ。

公平性も未解決の問題だ。音声システムは、アクセント、言語、発話障害、騒音環境によって異なる性能を示す可能性がある。

Hippocratic AIは、多言語対応とコードスイッチングを積極的なエンジニアリング上の優先事項としている。導入企業には、自社の患者集団に合致する導入環境でのサブグループ別性能データが必要だ。

導入に関する問題もある。患者はAIエージェントとの会話を拒むかもしれず、その役割を誤解するかもしれない。また、より早い段階で人間にアクセスできると期待する可能性もある。

同社のある研究文書では、コールセンター導入における患者の拒否率は3%未満だったと報告されている。この数値を、すべての集団、疾患、ワークフローに一般化すべきではない。

したがって、最も鋭い懐疑的な見方は単純だ。エージェントのオーケストレーションは、プラットフォームが連携できる対象の数を増やす一方、失敗し得る境界の数も増やす。

好意的なGoogle Newsの報道サイクルは市場の注目を示す。しかし、それはオーケストレーターが医療提供者、保険者、ライフサイエンスのプログラム全体でより良いアウトカムを生むことの証明にはならない。

医療導入企業にはアウトカムレベルのエビデンスが必要だ

病院はAgentic Orchestratorsを、印象的な音声デモの集合ではなく、臨床運用インフラとして評価すべきだ。

最初の評価層はワークフローの定義である。導入企業は、正確なアウトカム、責任を持つ人間のチーム、対象となる集団、エスカレーションが必要となる条件を特定すべきだ。

再入院の削減といった広範な目標だけでは不十分である。組織は、どの患者が対象となるか、いつアウトリーチを開始するか、エージェントが何をできるか、完了をどう測定するかを具体化しなければならない。

第2の層は行動の検証である。すべての予約、紹介、処方依頼、移送手配、記録更新は、権威あるシステムに照らして確認されるべきだ。

会話上の発言は、行動が発生したことを証明しない。オーケストレーターは、試行された行動、技術的に完了したトランザクション、解決された患者ニーズを区別しなければならない。

第3の層は引き継ぎの品質である。導入企業は、受け取るエージェントまたはスタッフが、患者に同じ話を繰り返させることなく正確なコンテキストを得られるかを測定すべきだ。

また、システムが意見の相違をどう扱うかも検証すべきである。予約エージェントと安全性監督役は、緊急性について異なる結論に達する可能性がある。

プラットフォームには、高リスクの衝突に対する決定論的なルールが必要だ。不確実性がある場合は、エージェントの権限を狭め、人の関与を増やすべきである。

第4の層は導入後のモニタリングである。組織には、解決率、再接触、エスカレーション頻度、修正率、患者の拒否、未解決の例外に関するダッシュボードが必要だ。

集計された安全性スコアだけでは不十分である。チームは、ワークフロー、言語、場所、患者グループ、ソフトウェアバージョン別に結果を分類すべきだ。

第5の層はガバナンスである。臨床、セキュリティ、プライバシー、運用、患者体験のリーダーが、変更に対する共通の権限を持つ必要がある。

単一の部門でシステム全体を評価することはできない。情報技術チームは統合を理解し、臨床医は危険なコミュニケーションを認識し、運用責任者は壊れたワークフローを把握する。

調達には、インシデント報告、モデル変更、データ保持、監査アクセス、移行計画を扱う契約条項も必要だ。一つのプラットフォームが多数の患者ジャーニーを連携する場合、ベンダーへの集中は重大なリスクとなる。

医療システムは、範囲を限定した経路から始めるべきだ。対象集団を絞り、明確な人間による代替手段を用意すれば、失敗を検出・修正しやすくなる。

拡大は、カタログの充実度ではなく、測定された性能に従うべきだ。予約回復で実証されたオーケストレーターが、投薬安全性や慢性疾患ケアに対する権限を自動的に得るわけではない。

Hippocratic AIのプラットフォームは、多数の独立したエージェントを組み立てる場合と比べて、統合を簡素化できる可能性がある。それでも導入企業は、統合によって許容可能な切り替えコストが生じるかを検証すべきだ。

外部エージェントが参加できるか、ワークフロー記録がポータブルなままかを問うべきである。閉鎖的なオーケストレーションは、初期導入が迅速であっても、将来の変更を難しくする可能性がある。

競争はこうした問いをより鋭くするだろう。医療データプラットフォーム、アンビエント文書化企業、患者エンゲージメントベンダー、クラウドプロバイダーは、いずれもエージェント型ワークフローへと拡大している。

一部の競合は、オーケストレーションは医療システムの既存データプラットフォーム内に属すると主張するだろう。別の企業は、独自の連携レイヤーを備えた垂直統合型エージェントを販売するだろう。

勝者を決めるのは、最も長い製品リストではない。検証されたアウトカム、統合の信頼性、失敗時の明確な説明責任によって決まる。

Hippocratic AIは、本番環境での音声運用経験と、専門家による監督を軸に設計された安全アーキテクチャに強みを持つ。課題は、そうした強みがマルチエージェント運用へ移転できることを証明することだ。

この発表は、導入企業に評価すべき具体的なアーキテクチャを提示した。同時に、すべての医療エージェントベンダーに期待されるエビデンスの基準を引き上げるものでもある。

戦略の成否を示す三つのシグナル

次の段階は、さらなる製品発表ではなく、顧客アウトカム、独立した検証、競合の対応によって判断されるべきだ。

第1のシグナルは、顧客レベルのアウトカム報告である。Hippocratic AIには、連携したワークフローを、完了したフォローアップ、治療遵守、アクセス、継続利用、再入院の指標に結び付ける導入結果が必要だ。

それらの報告では、分母、比較期間、患者集団、人の貢献、未解決のケースを定義すべきである。明確な方法論は、同社のアウトカムベースのポジショニングを強化するだろう。

第2のシグナルは、オーケストレーションされた患者ジャーニー全体にわたる独立した安全性検証である。レビュー担当者は、引き継ぎ、矛盾するエージェントの推奨、多言語通話、システム障害、人によるエスカレーションの遅延をテストすべきだ。

単一応答の精度では、こうした状況を捉えられない。評価は、エージェント、システム、時間をまたぐ患者のジャーニーを追跡しなければならない。

エージェント間で信頼性の高い連携を裏付ける独立した証拠が示されれば、孤立したアシスタントに反対するHippocratic AIの主張は強まる。エージェント間で重大な失敗が生じれば、人による統制をより強く効かせた限定的な導入が望ましいという見方を後押しするだろう。

第3のシグナルは、競合他社と医療システムがどのように反応するかだ。新たなオーケストレーション製品が登場すれば、市場が成果レベルのエージェント連携を独立したプラットフォームカテゴリーとして受け入れていることを示す。

一方で、モジュール型エージェントや顧客主導のオーケストレーションへの強い需要は、Hippocratic AIの統合モデルを弱めるだろう。これは、買い手がワークフローの中核的な所有権を移さずに、専門化されたツールを求めていることを示唆する。

同社の資金調達は、この戦略を追求するための余地を与えている。Hippocratic AIは、2025年11月に1億2,600万ドルのシリーズCを調達した後、報道によれば評価額35億ドルに達した。

資本は、統合、臨床試験、導入チームを支援できる。しかし、透明性のある顧客成果に取って代わることはできない。

これがGoogle Newsでの露出の本質だ。Hippocratic AIは単に音声エージェントを増やしているのではない。医療機関に対し、1つのプラットフォームでそうしたエージェントのチームを連携させることを求めている。

その約束は、引き継ぎの断絶を減らし、より多くのケアジャーニーを完遂できることだ。その代償は、技術、運用、説明責任が1つのシステムにより集中することである。

医療のリーダーは今後、導入を拡大する前に、成果の定義、サブグループ別データ、エスカレーション記録、独立したレビューを受けた失敗事例を求めるべきだ。より広範な信頼を正当化するに足る強い証拠を、どのオーケストレーション済みワークフローが生み出すのだろうか。