WEBVTT

00:00:00.000 --> 00:00:07.740
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々と過ごす10日間の準備はできていますか?

00:00:07.860 --> 00:00:12.180
この1月、M365コンがさらにパワーアップして帰ってきます。

00:00:12.440 --> 00:00:18.120
世界中のMVPや業界エキスパートによるライブセッション、実践的なデモ、役立つ知識をぜひ体験してください。

00:00:18.320 --> 00:00:21.760
ありきたりなスライドは使いません。無意味な専門用語の羅列もありません。

00:00:21.960 --> 00:00:24.120
私たちが取り組むのは現実の課題です。

00:00:24.120 --> 00:00:29.400
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、そして自動化。

00:00:29.400 --> 00:00:35.040
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれの役割に最適なセッションを用意しています。

00:00:35.220 --> 00:00:40.520
10日間にわたる充実したプログラムで幅広いテクノロジーを探求し、グローバルコミュニティとつながりましょう。

00:00:40.720 --> 00:00:44.800
ライブで視聴し、組織ですぐに役立つ実践的な知見を持ち帰ってください。

00:00:45.200 --> 00:00:51.260
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付を開始しました。

00:00:51.380 --> 00:00:53.620
今すぐお席を確保しましょう。

00:00:54.840 --> 00:00:58.080
サイトはm365コン.netです。

00:00:59.400 --> 00:01:04.700
m365コン.netから今すぐ登録して、1月のライブセッションでお会いしましょう。

00:01:04.860 --> 00:01:08.280
データが手を触れずとも自動的にアクションを起こせたら、と考えたことはありませんか?

00:01:08.440 --> 00:01:11.200
在庫の減少をリアルタイムで検知することを想像してみてください。

00:01:11.380 --> 00:01:15.800
メールを送ったりダッシュボードを確認したりする代わりに、システムが自動で在庫を補充してくれたらどうでしょう?

00:01:15.980 --> 00:01:17.580
これは夢物語ではありません。

00:01:17.740 --> 00:01:20.300
ファブリックデータアクティベーターがそれを実現します。

00:01:20.300 --> 00:01:25.160
今日は、生のデータ、即時のアラート、自動応答を結びつけ、

00:01:25.520 --> 00:01:30.060
Power BIやSynapse、そしてMicrosoft Fabricの他の機能と連携して、

00:01:30.480 --> 00:01:33.580
インサイトを即座にアクションへ変える仕組みをご紹介します。

00:01:33.800 --> 00:01:35.700
データサイクルの欠けていたピース。

00:01:35.900 --> 00:01:38.940
多くのチームはリアルタイムで運用していると言いますが、

00:01:39.320 --> 00:01:43.380
中身を見ると、実際は翌日の処理になっていることが多いものです。

00:01:43.380 --> 00:01:48.080
ダッシュボードの更新は15分、30分、時には1時間おきです。

00:01:48.240 --> 00:01:50.920
その頃には検知すべきパターンはすでに変化しており、

00:01:51.220 --> 00:01:55.340
見ているレポートはライブフィードではなく、試合後の分析に近いものになっています。

00:01:55.500 --> 00:01:58.820
結果が出た後に、試合の振り返りを見ているようなものです。

00:01:59.000 --> 00:02:01.940
問題は、BIツールが現状を教えてくれないことではありません。

00:02:02.120 --> 00:02:04.420
それについては、ほとんどのツールが非常に優れています。

00:02:04.600 --> 00:02:07.060
欠けているのは、それを見た後の動きです。

00:02:07.260 --> 00:02:09.260
現状では、多くのワークフローが、

00:02:09.260 --> 00:02:14.180
人間が変化に気づき、対策を判断し、実行する、という手順に依存しています。

00:02:14.340 --> 00:02:16.100
これがボトルネックを生んでいます。

00:02:16.340 --> 00:02:20.760
指標が低下した際に顧客へメールを送るといった基本的な作業でさえ、

00:02:21.120 --> 00:02:24.140
インサイトとアクションを直接結びつけるシステムがないため、

00:02:24.480 --> 00:02:25.840
手作業で行われています。

00:02:26.040 --> 00:02:29.460
この遅延こそが、多くのチャンスを逃す原因となっています。

00:02:29.700 --> 00:02:34.120
売上低下から3時間遅れてキャンペーンを打ち出しても、緊急性は失われています。

00:02:34.120 --> 00:02:40.740
ウェブサイトのエラー急増を次の会議まで放置すれば、本来得られたはずのコンバージョンを失うことになります。

00:02:40.940 --> 00:02:45.580
知ること、と、行動することの間にあるギャップ、そこにファブリックデータアクティベーターが存在します。

00:02:45.740 --> 00:02:48.480
このギャップを数秒まで短縮するために設計されました。

00:02:48.680 --> 00:02:52.040
マイクロソフトファブリックのネイティブ機能であるデータアクティベーターは、

00:02:52.420 --> 00:02:56.440
データソースの絶え間ないエクスポートや接続、調整を必要としません。

00:02:56.440 --> 00:03:01.940
イベントストリームが発生するたびに読み取り、定義した条件が満たされると即座に反応します。

00:03:02.140 --> 00:03:07.380
違いは、警告で止まるのではなく、他のシステム全体に連鎖反応を引き起こせる点です。

00:03:07.540 --> 00:03:12.180
例えば、ライブ販売フィードで各地域のパフォーマンスを監視している場面を想像してください。

00:03:12.380 --> 00:03:20.540
通常なら、ダッシュボードで特定の地域の急激な低下を見つけ、調査し、ターゲットを絞ったオファーを作成し、承認を得て、プロモーションを開始します。

00:03:20.700 --> 00:03:22.560
これには1時間かかるかもしれません。

00:03:22.560 --> 00:03:33.900
データアクティベーターを使えば、同じ低下が起きても、事前承認済みのAPIコールがマーケティング自動化システムに飛び、競合他社が弱点に気づく前に数分でターゲットオファーを立ち上げます。

00:03:34.060 --> 00:03:38.500
担当者が気づくのを待つ必要も、当然の対応策を検討する遅延もありません。

00:03:38.740 --> 00:03:40.160
それこそが真の変革です。

00:03:40.360 --> 00:03:44.720
従来のBIツールが追跡するのに対し、データアクティベーターは引き取り、そして対応します。

00:03:44.720 --> 00:03:53.240
例えば、Power BIの一般的な更新頻度が30分間隔の場合、検知した時点で既に変化の発生から遅れが生じている可能性があります。

00:03:53.480 --> 00:04:04.640
データアクティベーターのトリガーは、ソースによっては数秒単位のほぼリアルタイムでイベントストリームに作用するため、アクションの瞬間をトリガーとなるイベント自体に極めて近づけることができます。

00:04:04.640 --> 00:04:09.620
しかも、ファブリックに組み込まれているため、特定のダッシュボードやデータセットに限定されません。

00:04:09.780 --> 00:04:12.520
エコシステムのあらゆる要素と連携可能です。

00:04:13.500 --> 00:04:21.360
そのストリーミングフィードはシナプスデータパイプラインの一部となり、そこから複数の下流モデルやAIモデルへ供給されます。

00:04:21.900 --> 00:04:26.640
重要な出来事があれば、データアクティベーターはダッシュボードに囁くだけでは終わりません。

00:04:26.900 --> 00:04:31.700
修正が必要なシステムや、後期を活かせるシステムへと直接シグナルを送ります。

00:04:31.700 --> 00:04:34.960
これこそが、観察と実行を結ぶ架け橋なのです。

00:04:35.080 --> 00:04:41.840
チームのチャットを昼食後に確認するような情報共有メッセージで埋めるのではなく、その場で次のステップを実行します。

00:04:42.080 --> 00:04:47.400
条件に合致するすべてのイベントを、すでに決定された判断、すでに完了したアクションへと変えます。

00:04:47.560 --> 00:04:51.500
標準的なBIワークフローと並べてみれば、その優位性は明白です。

00:04:51.660 --> 00:04:53.860
監視だけでは状況を知るのみです。

00:04:54.020 --> 00:04:57.140
監視と対応を組み合わせれば、結果が変わります。

00:04:57.140 --> 00:05:03.580
チャンスの窓がすぐに閉じてしまう現代において、その違いは単なる利便性ではなく、競争力そのものです。

00:05:03.760 --> 00:05:10.840
次に、管理の複雑さを増やすことなく、使い慣れたツールにどう自然に適合するかを見ていきましょう。

00:05:11.040 --> 00:05:13.500
単なる通知を超えた、ファブリックというウェブ。

00:05:13.660 --> 00:05:17.180
チームで単に通知を飛ばすだけでは自動化とは言えず、ただノイズが増えるだけです。

00:05:17.360 --> 00:05:18.940
どのようなものか、お分かりでしょう。

00:05:19.140 --> 00:05:21.240
画面中を埋め尽くす大量のポップアップ。

00:05:21.240 --> 00:05:24.640
どれもこれも、重要かどうかもわからない通知ばかりです。

00:05:24.820 --> 00:05:32.260
最初は把握できているように感じますが、すぐにチームは無視するようになり、重要な情報も混乱の中に埋もれてしまいます。

00:05:32.460 --> 00:05:37.860
皮肉なことに、情報を伝えるためのシステムが、かえって状況を見えにくくしているのです。

00:05:38.060 --> 00:05:45.120
月曜の朝礼で、他のアラートに紛れて重要な顧客対応を見落とした、という話を誰もが一度は耳にしたことがあるでしょう。

00:05:45.340 --> 00:05:50.580
問題の根本は検知不足ではなく、次に何をすべきかという判断力の欠如にあります。

00:05:50.580 --> 00:05:57.680
過敏なトリガーは小さな変動再起機器として扱い、結果として誰もがそれを無視するような文化が作られてしまいます。

00:05:57.900 --> 00:06:03.620
そこで重要になるのが、マイクロソフトファブリックに統合されたデータアクティベーターです。

00:06:03.820 --> 00:06:10.140
単なる後付けではなく、パワーBIやシナプス、ファブリックのデータウェアハウスと密接に連携します。

00:06:10.360 --> 00:06:15.140
つまり、分析やパイプラインを動かしているツールと同じ土俵で機能するのです。

00:06:15.140 --> 00:06:20.620
指標が揺らぐたびに通知を送るのではなく、その揺れが業務を止めるべきものかどうかを判断できます。

00:06:20.840 --> 00:06:26.580
昔の電話交換手に例えるなら、一本一本の電話の緊急性を正確に理解しているような存在です。

00:06:26.740 --> 00:06:31.920
例えば、データフィードから読み込み中に製品名の形式が崩れたという信号が送られてきたとします。

00:06:32.140 --> 00:06:35.600
データアクティベーターは、どの回路がどのシステムにつながっているかを把握しています。

00:06:35.800 --> 00:06:38.940
マーケティングチームに明日読まれるような通知を送ったりはしません。

00:06:38.940 --> 00:06:44.880
不完全なデータが下流のレポートを汚染する前に、処理を止めるシステムへ直接問題を伝達します。

00:06:45.060 --> 00:06:46.700
具体的な例を挙げましょう。

00:06:46.960 --> 00:06:51.080
シナプスパイプラインが金融取引データを数秒ごとに取得しているとします。

00:06:51.320 --> 00:06:55.760
ベンダー側の不具合で、上流システムが重複レコードを送信し始めました。

00:06:55.940 --> 00:07:00.920
通常のアラートだけでは、チームやメールに重複レコードを検知しましたと届くだけです。

00:07:01.120 --> 00:07:04.020
すると、それは誰かのタスクリストに追加されるだけになります。

00:07:04.020 --> 00:07:13.120
データアクティベーターなら、重複が発生した瞬間にパイプラインを一時停止し、データエンジニアが悪いデータを取り込む前に対処する余裕を作れます。

00:07:13.340 --> 00:07:17.820
誰かがダッシュボードをチェックしていたからではなく、システムレベルで自動的に修正が行われるのです。

00:07:17.960 --> 00:07:19.460
これは決定的な違いです。

00:07:19.620 --> 00:07:23.320
データアクティベーターは、単一のデータセットや狭いストリームだけに縛られません。

00:07:23.320 --> 00:07:32.960
構造化されたウェアハウスのテーブルやイベントストリームその他ファブリックに接続されたソースなど、多種多様な入力に対応し、監視の手放しに同じ論理ルールを適用します。

00:07:33.120 --> 00:07:37.460
このサービス横断的な範囲により、単に何かがおかしいと知るだけでなく、適切な対応が可能になるのです。

00:07:37.600 --> 00:07:40.960
どこでブレーキをかけ、どこでアクセルを踏むべきかを的確に判断します。

00:07:41.140 --> 00:07:46.740
変換ロジックやストレージと同じエコシステム内で動作するため、データフローと競合することもありません。

00:07:46.740 --> 00:07:49.180
データフローに完全に組み込まれているのです。

00:07:49.380 --> 00:07:57.060
そのため、インジェスト、変換、検証、解決までを一連の流れで実行でき、担当者間での受け渡しに追われることもなくなります。

00:07:57.240 --> 00:08:04.680
これは、データに反応するだけでなく、品質と適時性を維持するためにシステムが途中で適用するという違いを生みます。

00:08:04.880 --> 00:08:11.580
しかし、真のメリットは、これを単なる警告ツールではなく、業務上の意思決定レイヤーとして捉えたときに見えてきます。

00:08:11.580 --> 00:08:19.920
コンテキストに基づいて応答するため、ノイズが劇的に減り、意味のある行動を促すアラートの割合が高まります。

00:08:20.360 --> 00:08:22.560
もう、アラートに埋もれることはありません。

00:08:22.780 --> 00:08:26.920
最小限の労力で、ノイズの中から重要なシグナルを捉えられるようになります。

00:08:27.100 --> 00:08:36.040
これらの決定がジョブの一時停止、記録の更新、修正プロセスの開始といった実際の変更を促せるため、単に認識と行動の間の遅延を縮めるだけではありません。

00:08:36.240 --> 00:08:38.200
そのギャップを完全になくしてしまうのです。

00:08:38.200 --> 00:08:43.600
では、皆さんの注目を集めるであろう、APIを呼び出してマイクロソフト外部の世界と連携する部分を見ていきましょう。

00:08:43.780 --> 00:08:49.220
内部から外部へと呼びかける際、皆さんが不在着信に気づくよりも早く、データが電話をかけることができるのです。

00:08:49.380 --> 00:08:50.640
これは比喩ではありません。

00:08:50.860 --> 00:08:58.320
追跡中のイベントストリームをそのまま利用し、マイクロソフトファブリックエコシステムの外部でリアルタイムに何かを起動させるのです。

00:08:58.320 --> 00:09:11.200
ダッシュボードを確認したりチームのアラートをクリックしたりするのを待つのではなく、条件が満たされた瞬間にシステム自体が物理的あるいは比喩的に外部へ発信し、他のアプリケーションやサービスでアクションを開始します。

00:09:11.400 --> 00:09:14.320
多くのBI環境はまさにここで立ち止まってしまいます。

00:09:14.520 --> 00:09:22.000
洞察を浮かび上がらせることは得意で、時には鮮やかなビジュアルやAIによる解説も提供しますが、ボールを渡して後は任せたという状態なのです。

00:09:22.000 --> 00:09:28.100
結局、CRMを開いて注文を送り、ERPを更新し、プロセスを手動で開始しなければなりません。

00:09:28.280 --> 00:09:31.600
そのギャップにこそ、人間によるボトルネックが入り込む余地があるのです。

00:09:31.800 --> 00:09:37.760
問題は数分で検知できても、誰かが動けるようになるのを待つために、実行は数時間後になってしまいます。

00:09:37.940 --> 00:09:42.040
データアクティベーターを使えば、そのステップは短縮されるのではなく、完全になくなります。

00:09:42.220 --> 00:09:46.900
1日の途中で、在庫レベルが補充基準値を下回った場面を想像してみてください。

00:09:46.900 --> 00:09:53.680
通常の環境では、運用担当者がPower BIでこれに気づき、調達部門に連絡して確認を待つことになります。

00:09:53.900 --> 00:09:57.540
その間にも製品は売れ続け、欠品へと近づいていきます。

00:09:57.800 --> 00:10:04.740
データアクティベーターなら、データがその基準を超えた瞬間に、サプライヤーの発注システムへ直接APIコールを送ることができます。

00:10:04.940 --> 00:10:10.940
発注が行われ、配送が手配され、チームの誰もアラートを読んでいないうちに、すでに修正に向けた動きが始まっています。

00:10:11.140 --> 00:10:14.780
それが、ファブリックの内部から直接外部への呼び出しを実行する価値です。

00:10:14.780 --> 00:10:17.460
マイクロソフトのツールに限定されることはありません。

00:10:17.660 --> 00:10:27.660
SaaSのCRM、レガシーなERP、カスタムのレストエンドポイント、あるいはパートナーのAPIであっても、リアルタイムのトリガーを接続して検知と解決の間のギャップを埋めることができます。

00:10:27.880 --> 00:10:38.680
出力は、Webhookへの単純なデータ送信から、全く別のプラットフォームで多段階のワークフローを起動するような構造化されたペイロードの送信まで対応可能です。

00:10:38.680 --> 00:10:47.700
この時点で、ファブリックは単なる分析ツールのセットではなく、運用環境の中枢神経系のように機能し始めます。

00:10:48.220 --> 00:10:55.260
イベントが発生したとき、神経系は単に目に信号を送るだけでなく、即座に行動できる手足に指示を送ります。

00:10:55.460 --> 00:11:00.320
こうして、運用を監視する段階から、運用が自律的に調整される段階へと移行するのです。

00:11:00.460 --> 00:11:03.760
これは、IoTの活用が進んでいる業界で見ることができます。

00:11:04.000 --> 00:11:08.140
重要な機械に振動センサーが設置された製造工場を想像してみてください。

00:11:08.340 --> 00:11:11.720
これらのセンサーは、データをリアルタイムでファブリックにストリーミングします。

00:11:11.960 --> 00:11:22.180
測定値が故障警告範囲に入った瞬間、データアクティベーターがDynamics 365で作業指示書を作成、割り当てし、機械が故障する前にエンジニアをスケジュールします。

00:11:22.180 --> 00:11:30.180
監督者が業務を中断して電話をかける必要はなく、システムが自動的にジョブをルーティングし、技術者に必要なコンテキストまで提供します。

00:11:30.360 --> 00:11:33.800
ダウンタイムが議論される前に、修理作業が開始されます。

00:11:34.000 --> 00:11:38.820
自動監視とアウトバウンドAPIの組み合わせこそが、真の自立性を実現する鍵です。

00:11:38.960 --> 00:11:44.960
単にアラートを関連性でフィルタリングするだけでなく、フィルタリングされたトリガーを即座に実行される具体的なアクションに結びつけるのです。

00:11:44.960 --> 00:11:52.100
これは、データ駆動型からデータ起動型への飛躍であり、検知と同じ速さでシステムが応答できるようになります。

00:11:52.280 --> 00:12:02.460
正しく設定すれば、プロセスは人間によるマイクロマネジメントを回避するだけでなく、検知とアクションのループが堅牢かつ一貫して常時稼働するため、積極的に改善されていきます。

00:12:02.580 --> 00:12:08.260
誰かがアラートを見たかどうかを心配する代わりに、より優れたルールやロジックの設計に集中できます。

00:12:08.480 --> 00:12:12.580
しかし、どれほど反応の良い神経系であっても、無視できない敷地は存在します。

00:12:12.580 --> 00:12:16.620
開始前にそれを知らなければ、結果はすぐに混乱したものになってしまうでしょう。

00:12:16.780 --> 00:12:18.880
構築前に限界を知っておくこと。

00:12:19.080 --> 00:12:25.180
すべての自動化の英雄には、原点となる物語と、あらかじめ気づいておけばよかったという失敗談があります。

00:12:25.420 --> 00:12:33.160
データアクティベーターにおいて、検知と反応というアイデアには無限の可能性があるように聞こえますが、その基盤には非常に現実的なフレームワークがあります。

00:12:33.380 --> 00:12:34.740
これは魔法ではありません。

00:12:34.740 --> 00:12:43.740
依然としてファブリックのアーキテクチャ上で動作しており、エコシステム内の他のすべてに適用されるものと同じ容量モデル、サービス制限、設計上の前提に従っています。

00:12:43.980 --> 00:12:49.860
そうした境界を無視すれば、善意の自動化が停止したときに何が起こるかをすぐに思い知ることになるでしょう。

00:12:50.100 --> 00:12:54.440
厄介なのは、障害の発生ポイントが概念実証の段階では通常現れないということです。

00:12:54.440 --> 00:12:57.480
小規模なテストでは、すべてが瞬時に行われるように感じられます。

00:12:57.600 --> 00:13:01.220
条件がトリガーされ、アクションが実行され、その結果をほぼ即座に確認できます。

00:13:01.400 --> 00:13:08.740
規模を拡大し、複数の外部システムを接続し、トリガーの量を増やし、複雑なロジックを重ねたときに初めて、制約が牙を剥くのです。

00:13:08.900 --> 00:13:11.920
0点子が蓄積し、容量使用率が急増します。

00:13:12.100 --> 00:13:16.800
突然、そのリアルタイム意思決定エンジンが制限されたり、急に入ったりします。

00:13:16.800 --> 00:13:24.660
トリガーが、接続はされているものの、ファブリックのネイティブサービス内で実行されていないソースに依存している場合に何が起こるかを考えてみてください。

00:13:24.880 --> 00:13:29.540
例えば、レポートに送られる外部イベントハブからのデータストリームがあるかもしれません。

00:13:29.740 --> 00:13:41.020
データアクティベーターが重要なプロセスを実行するためにそのフィードに依存していても、ソース側の処理間隔がファブリックのターゲット応答時間より遅ければ、期待する応答性は決して得られません。

00:13:41.020 --> 00:13:47.080
トリガーのロジックに追いつけない純正的なデータに基づいて条件が構築されたために、展開が停滞するのを見たことがあります。

00:13:47.300 --> 00:13:50.420
自動化が失敗したわけではなく、単に遅すぎて役に立たなかったのです。

00:13:50.620 --> 00:13:52.480
すべてを監視したいという誘惑もあります。

00:13:52.780 --> 00:13:54.940
最初は理にかなっているように思えるでしょう。

00:13:55.160 --> 00:14:03.280
監視条件が増えれば対応の機会も増えるはずですが、定義するトリガーはすべてファブリック容量に対するワークロードとして加算されます。

00:14:03.280 --> 00:14:10.140
つまり、BIのリフレッシュ、データフロー、ウェアハウスのクエリをサポートするのと同じ容量を消費しているということです。

00:14:10.280 --> 00:14:16.780
過度に行えば、トリガーが計算リソースを食いつぶすことで、他のワークロードが停滞するという波及効果を目の当たりにするでしょう。

00:14:16.980 --> 00:14:18.880
容量計画はここでは不可欠です。

00:14:19.100 --> 00:14:22.600
自動化が自ら招くダウンタイムに変わるのを防ぐための規律だからです。

00:14:22.780 --> 00:14:24.440
0.4の目標も重要です。

00:14:24.440 --> 00:14:30.160
データアクティベーターは数秒で反応できますが、それはアップストリームとダウンストリームのシステムがその速度に対応できる場合に限られます。

00:14:30.280 --> 00:14:37.740
トリガーされたAPI呼び出しが15分ごとにバッチ処理されるERP統合を指している場合、実質的に組み込みの遅延を招いていることになります。

00:14:37.900 --> 00:14:41.860
トリガーは実行されますが、最終結果は次のバッチまで待たされることになります。

00:14:42.080 --> 00:14:46.720
サービスリズムのこうした違いは、システムを接続し始める前にマッピングしておく必要があります。

00:14:46.720 --> 00:14:51.220
より安全な道は、価値が高く頻度の低い条件から始めることです。

00:14:51.340 --> 00:14:57.940
つまり、1日に数回しかトリガーされなくても、それぞれが自動化する価値のある明確な影響を持つシナリオを選ぶということです。

00:14:58.120 --> 00:15:04.040
それは、容量を溢れさせたり、ダウンストリームのサービスを圧倒したりすることなく、有効性を証明することです。

00:15:04.180 --> 00:15:09.220
トリガーロジックを微調整し、処理プロファイルを理解してから拡張を開始します。

00:15:09.400 --> 00:15:14.400
価格設定と容量がストレージやリフレッシュだけのものではないことも覚えておく価値があります。

00:15:14.400 --> 00:15:18.340
トリガーの評価とアクションの実行は、同じプールからリソースを消費します。

00:15:18.540 --> 00:15:21.420
そのアウトバウンドのAPI呼び出しも計算リソースなのです。

00:15:21.620 --> 00:15:25.100
条件チェックの前に実行する変換処理も計算リソースを消費します。

00:15:25.300 --> 00:15:31.840
パブリックユニットのプールを考慮せずに条件や接続をスケールアップすると、予想よりも早く上限に達してしまいます。

00:15:32.100 --> 00:15:36.240
幸いなことに、制限の所在さえ把握していれば、それを回避するように設計できます。

00:15:36.480 --> 00:15:38.260
自動化されたプロセスを構築し、