WEBVTT 00:00:00.000 --> 00:00:07.720 1日の半分を承認待ちで費やしていませんか 誰かが休暇中だったりメールを見落としていたりようやく決断が下る頃には依頼の前提と 00:00:07.720 --> 00:00:14.520 なった状況は過去のものになっています 忙しいと繰り返す人々に阻まれ停滞する企業内煉獄では待つ必要のないシステムを 00:00:14.520 --> 00:00:20.420 想像してみてください条件が満たされた瞬間に動き出すワークフローです それが自動化の仮面をかぶった官僚主義キラー 00:00:20.420 --> 00:00:25.080 マイクロソフトコパイロットスタジオのエージェントフローです ここでは ai が最初の承認者となります 00:00:25.080 --> 00:00:34.020 データの内容をポリシーに照らして評価し人間が瞬きする間に根拠ある承認または 拒否を下します境界線上のケースだけがマネージャーの受信箱に届くため 00:00:34.020 --> 00:00:42.600 監視を犠牲にすることなくスピードを維持できます 複雑な条件で崩壊する従来の承認フローとは異なりこの ai 主導型フローは自動的に分岐 00:00:42.600 --> 00:00:49.500 検証監査を行いながらスケールします このオークスルーでは同僚が全員返信ボタンを探すよりも早く決断を下す 00:00:49.500 --> 00:00:55.940 多段階の条件付き承認システムの構築方法をご紹介します カスタム承認ロジックを備えた ai ステージの設定 00:00:55.940 --> 00:01:00.780 敵を絞った人的レビューの追加 動的に再ルーティングする条件の設計 00:01:00.780 --> 00:01:08.400 コンプライアンスのための文書検証統合の方法を学びます 最後には機械のように考えるべき時と人間の判断に委ねるべき時を理解する自動化 00:01:08.400 --> 00:01:11.180 プロセスが完成しているはずです 行列に従うのはやめましょう 00:01:11.180 --> 00:01:19.080 ロジックを先導させるのです 従来の承認プロセスが抱える問題従来の承認チェーンは非効率性の悲劇的なリミックスにすぎません 00:01:19.080 --> 00:01:25.820 誰かがフォームを提出しメールが飛び交い スプレッドシートの動機外れ転送のループの中で誰も最終版を把握できなくなります 00:01:25.820 --> 00:01:32.160 関与する各人が価値ではなく遅延を生み出しています このプロセスは業務を管理しているのではなく0.4遅延を製造しているのです 00:01:32.160 --> 00:01:37.320 一般的なパワーオートメートの承認フローもこの解決を試みますが 細かなニュアンスが入ると停止してしまいます 00:01:37.320 --> 00:01:46.480 単純なイエスかノーが必要なだけなら単一の承認パスで十分です 管理レイヤーや支出位基地特殊なルールを追加した瞬間設計は断片化し始めます 00:01:46.480 --> 00:01:55.100 マトリオシカのように条件が入れ子になり不恰好で脆弱な半年後にはデバッグ不可能なシステムが 出来上がりますコネクタが一つ壊れればシステム全体が沈黙のうちに停止します 00:01:55.100 --> 00:02:02.560 人間がボトルネックもっと言えば遅延濃度になってしまうのです 彼らに届くすべてのメッセージが新たな非同期の往復作業となります 00:02:02.560 --> 00:02:08.560 承認手段としてのメールは光ファイバーの世界で電所バトを使うようなものです 技術的には動作しますが使うべきではありません 00:02:08.560 --> 00:02:13.920 そこでマイクロソフトコパイロットスタジオの登場です これは単なるパワーオートメートのマイナーアップデートではありません 00:02:13.920 --> 00:02:21.720 AIを搭載しつつ組織のデータソース役割論理構造と完全に統合された承認システムエージェントフローを導入します 00:02:21.720 --> 00:02:28.940 確定的ポリシーの強制と適応的な意思決定を架け橋としてつなぎます その素晴らしさは各ステージをどのように分離するかにあります 00:02:28.940 --> 00:02:35.200 スピードが必要な場所は自動化し検証が必要な場所は人の手に これは階層構造の再設計と言えます 00:02:35.200 --> 00:02:44.260 AIステージは固定ルール金額制限カテゴリ分類日付範囲を冷徹なまでに効率的に評価します 判断に迷うグレーなケースのみ人間が介入するため 00:02:44.260 --> 00:02:50.040 些細な案件まで行列を作る必要はありません これだけで指数関数的な遅延が解消されます 00:02:50.040 --> 00:02:59.720 10人が順番に確認するのではなくAIが80%を瞬時に処理し例外のみを振り分けます さらにコパイロットスタジオはデータバース基盤を通じて全てを追跡し 00:02:59.720 --> 00:03:06.100 メールのアーカイブを掘り返さなくても検証可能なログを作成します 従来のワークフローは人間を中心に構築されていました 00:03:06.100 --> 00:03:11.320 エージェントフローは人間を軸に据え単なる反復作業ではなく判断が必要な時にだけ人間が関与するように します 00:03:11.320 --> 00:03:16.700 このアーキテクチャの機能を知れば従来の承認プロセスはまるでロウソクの明かりで 帳簿をつけているかのように原始的に感じられるでしょう 00:03:16.700 --> 00:03:23.120 その重要性はコンプライアンス一貫性そして拡張性にあります 現代の業務は自動検証なしでは立ち行かず 00:03:23.120 --> 00:03:29.860 AIによるロジックが信頼性の基盤となっています 静的なフローから条件付きで監査可能なエージェントフローに移行すれば 00:03:29.860 --> 00:03:37.260 バータリ的な承認管理から脱却し生きたシステムとして運用できます その違いは単なるスピードではなく構造的な健全性です 00:03:37.260 --> 00:03:44.480 AIステージを構築し最初の承認者を教育するここからが面白いところです 最初のデジタル官僚を育成しましょう 00:03:44.480 --> 00:03:52.840 AIステージは承認プロセスにおける論理的なゲートキーパーです その役割は人間のように考えることではなく構造的な推論を超人的な一貫性で行うことです 00:03:52.840 --> 00:03:59.880 指示を読み入力内容と照らし合わせ承認か却下のいずれかを判定します 政治的な駆け引きやコーヒーブレイクは必要ありません 00:03:59.880 --> 00:04:06.920 まずは新しいエージェントフローの定義から始めます 作成時AIステージは回答キーを待つ白紙の試験用紙のように中心に配置されます 00:04:06.920 --> 00:04:11.660 トリガーは通常データバースから送られ請求や経費のテーブルにレコードが追加 変更された際に発生します 00:04:11.660 --> 00:04:20.560 申請が作成されるとこのステージが作動しデータを評価して適切に判断を下します ステージ内で最も重要なフィールドが操作の能となる指示プロンプトです 00:04:20.560 --> 00:04:27.600 ここで承認ロジックを平易かつ厳密な言葉で記述します 決して即興で動かない弁護士に指示を出すつもりで書きましょう 00:04:27.600 --> 00:04:35.720 例えば金額が500未満説明が心身の健康に関するもの 購入日が申請から30日以内であれば承認するといった具合です 00:04:35.720 --> 00:04:40.040 いずれかのルールを満たさない場合は却下します それだけで白黒が明確になります 00:04:40.040 --> 00:04:45.280 次に動的な入力を定義します これらは実際のデータをロジックに供給する変数だと考えてください 00:04:45.280 --> 00:04:52.480 多くの場合金額説明購入日を含めることになります それぞれがコンテンツテキスト数値の入力として追加され 00:04:52.480 --> 00:04:59.620 ai が判断を下す際に利用されます コパイロットスタジオはこれらの入力をテキスト数値画像ドキュメントといった型に分類します 00:04:59.620 --> 00:05:05.560 型を混同すると例えば数値をテキストとして保存するなど 人間と機械の両方が混乱するため適切に選択してください 00:05:05.560 --> 00:05:11.260 各入力の下にテスト用のサンプルデータを入力します これはロジックを調整するための足場として機能します 00:05:11.260 --> 00:05:22.560 例えばフィットネス用ヨガマット金額300購入日8月22日といった申請例を入力してみましょう テストを実行するとコパイロットスタジオは基盤となる gpt 推論モデルを走らせ 00:05:22.560 --> 00:05:30.660 判定結果と説明を出力します結果が期待通りであれば問題ありません そうでなければ指示に決定論的な一貫性が欠けています 00:05:30.660 --> 00:05:38.140 初心者の多くがここで失敗します妥当な経費や最近の購入といった抗議で曖昧な表現は ai にとって毒となります 00:05:38.140 --> 00:05:45.280 システムは企業の空気を読めないため数学的な定義が必要です テスト結果が一貫したものになるまで容赦なく指示を洗練させてください 00:05:45.280 --> 00:05:52.780 言い回しを変えるたびに再現性を高めるために判断エンジンを調整しているのです 目指すべきは同一の入力に対して常に同一の出力が得られるパターンです 00:05:52.780 --> 00:06:00.700 必要なのは社内の噂話ではなく機械的な論理です 複数のテストケースで信頼できる判断がプロンプトから得られれば ai 承認者のトレーニングは完了です 00:06:00.700 --> 00:06:07.040 次にデータバースから抽出したトークン申請金額の詳細購入日や提出日などを使用して 実際の動的データを注入します 00:06:07.040 --> 00:06:15.680 これらは本番運用時にテスト値と置き換わります それ以降 ai は文脈に応じて各申請を評価し新しいデータが入るたびに承認の判定を返します 00:06:15.680 --> 00:06:23.640 勝利を宣言する前に反復テストを行ってください 金額を600に変更したら却下されますか日付を3ヶ月前に変更したら向こうとしてフラグが立ちますか 00:06:23.640 --> 00:06:29.920 ipad の購入といった不適切な申請を追加して不一致を検出できますか どのパスも一貫した因果関係を示す必要があります 00:06:29.920 --> 00:06:38.240 回答が変動する場合問題は ai モデルではなくプロンプトの明確さにあります 一貫したパターンが見えてきたらコンテンツ変数に命名規則を確立しましょう 00:06:38.240 --> 00:06:43.420 文字列には str アンダーバークレームアンダーバーアマウント 数値にはナムアンダーバーパーチェスアンダーバーデートといった説当時をつけます 00:06:43.420 --> 00:06:53.380 この小さな規律が後にマルチ分岐ロジックへ拡張する際の混乱を防ぎます この段階で自動承認者はポリシーに基づき監視なしで独立した判断を下せるようになります 00:06:53.380 --> 00:06:59.100 しかし自動化とは独裁ではなく異人です 機械が担うのは速度と精度であり判断ではありません 00:06:59.100 --> 00:07:05.240 境界線上のシナリオでは ai が却下または不確実とみなしたものを見直す ヒューマンインザループ人間の介在によるエスカレーションが必要です 00:07:05.240 --> 00:07:13.680 そこで次のステージが登場しシリコンと人間との間で権限がどのように共有されるかが決まります 人間の監視多段階ロジック条件付きロジックの追加です 00:07:13.680 --> 00:07:19.480 ai が自信を持って申請を判断できるようになったら官僚組織が皮肉にも人間味と呼ぶ要素を追加できるようになります 00:07:19.480 --> 00:07:29.660 コパイロットスタジオでは手動ステージを設けることで人間が判断を下すチェックポイントを作成できます これはいわば安全弁のようなものです予測可能な処理はすべて自動で流れていきます 00:07:29.660 --> 00:07:36.280 複雑な判断が必要なものはマネージャーのデスクに送られます まず承認デザイナーで ai ステージの直後に手動ステージを追加します 00:07:36.280 --> 00:07:44.160 これでエージェントフローに第二のゲートが作成されます この引き継ぎには条件があります ai が承認と判断した場合のみ人間によるステージに進みます 00:07:44.160 --> 00:07:50.520 ai が拒否と判断すればプロセスはそこで終了します ポリシーですでに除外されたものをマネージャーに確認させる必要はありません 00:07:50.520 --> 00:07:55.640 効率化とは選択的な注力を自動化という形で実現することです 具体例を挙げて設定してみましょう 00:07:55.640 --> 00:08:02.060 従業員が事務の回避の経費生産を申請したとします ai はすべての基準がポリシーに適合しているためこれを承認します 00:08:02.060 --> 00:08:11.720 するとその決定によりマネージャー承認という手動ステージが起動します 内部設定でステージタイトルに申請者からの経費承認依頼などを指定します 00:08:11.720 --> 00:08:18.360 これらの変数はデータバースから動的にデータを取得します 割り当て先フィールドでタスクの受け取り人を定義します 00:08:18.360 --> 00:08:25.640 通常は申請者の上司です ルーティングを自動化するためコパイロットスタジオはオフィス365ユーザーコネクタと統合できます 00:08:25.940 --> 00:08:31.820 まずデータバースのユーザーテーブルで id で行を取得 アクションを使い申請者のレコードを取得します 00:08:31.820 --> 00:08:38.200 これで申請者の情報が取得できます 次にマネージャーの取得アクションでメールアドレスからそのユーザーの上司を取得します 00:08:38.200 --> 00:08:45.120 その結果を str マネージャーメールといった変数として手動ステージに渡します 結果としてハードコーディングや古い組織改装に悩まされることはありません 00:08:45.120 --> 00:08:49.800 マネージャーが変われば改装情報も自動的に更新されます ここで条件分岐が登場します 00:08:49.800 --> 00:08:55.000 これこそが多段階承認の真の目的です エージェントフロー内に直接ロジックを組み込むことができます 00:08:55.000 --> 00:09:01.740 経費額が150以上の場合管理者承認のステージを追加します それ以外の場合はプロセスを終了します 00:09:01.740 --> 00:09:08.880 これにより単純な2段階のルーチンが状況に応じた多層的な決定義へと進化します 小額の申請は一人の人間が担当します 00:09:08.880 --> 00:09:15.360 高額またはリスクのある申請はさらに別の人のチェックに回されます デザイナーでフローを閉じる前に条件アクションを挿入します 00:09:15.360 --> 00:09:23.600 ナム経費額のような数値変数を参照します 演算子に以上を選び式位置を150に設定します 00:09:23.600 --> 00:09:30.460 はいの分岐に管理者承認という主導ステージを追加します コンプライアンス管理者など特定の承認者を割り当てます 00:09:30.460 --> 00:09:38.020 いいえの分岐ではそのまま承認として終了します その結果ワークフローは単なるボトルネックではなく合理的な組織のように機能します 00:09:38.020 --> 00:09:46.400 ここで少し実用的なユーモアを権限異常には期待だけでなく信頼も必要です 何でも承認できてしまうような広すぎるセキュリティロールは割り当てないようにしましょう 00:09:46.400 --> 00:09:52.820 データバースのロールベースアクセス制御を使用して関連するユーザーまたは グループへの権限を制限しますそうしなければ無秩序な自動化になってしまいます 00:09:52.820 --> 00:10:01.060 構造をテストすることで各パーツがいかにスムーズに組み合わさるかがわかります 150ドル未満の申請が ai レビューを通過するとマネージャーの承認をもってフローは終了します 00:10:01.060 --> 00:10:11.700 150ドルを超える場合システムは最終処理の前に管理者によるレビューへ自動的に回します 各経路には ai の推論ログタイムスタンプ付きの承認記録された結果といった監査証跡が残りデータバースに保存されます 00:10:11.700 --> 00:10:18.960 後になってそんなものは見ていないとは誰にも言わせません データベースが真実を証明するからです洗練させる過程では命名規則を厳格に守りましょう 00:10:18.960 --> 00:10:24.500 マネージャー承認済み管理者承認済みのように人によるステップを明確に説当時で示せば 視覚的に分岐を追跡できます 00:10:24.500 --> 00:10:32.420 フローチャートは謎のアートではなく論理として読めるものであるべきです 満足できたら公開し実際のシナリオでテストします連鎖が展開される様子を見守りましょう 00:10:32.420 --> 00:10:39.200 ai が即座に評価しますマネージャーには対象を絞った承認タスクが届きます 管理者は条件が満たされた場合にのみ介入します 00:10:39.200 --> 00:10:49.060 その結果単なる自動化ではなく自律的に機能する透明性の高い階層構造が実現します この多層的な連携はドキュメント検証という新たな領域も切り開きます 00:10:49.060 --> 00:10:57.100 フォームの入力欄は嘘をつくことがあっても領収書は嘘をつかないからです 次のステップは申請が受信箱に届く前に ai に物理的な証拠を検証させることです 00:10:57.100 --> 00:11:05.260 そこで領収書検証が登場し完了的な手続きを検証可能な科学へと変えます 動的な入力とドキュメントの検証領収書の話をしましょう 00:11:05.260 --> 00:11:10.300 払い戻しを申請する段になって突然重要な証拠へと変わる あの小さくしわくちゃな紙切れのことです 00:11:10.300 --> 00:11:15.600 手動の承認プロセスでは人間が目視で確認します そうそれはヨガマットに見えますね 00:11:19.060 --> 00:11:25.560 を行わせ判断の疲れを排除します コパイロットスタジオのエージェントフローにおいてドキュメント検証は動的なコンテンツ入力 00:11:25.560 --> 00:11:32.780 具体的には画像やファイルを承認ロジックに渡す機能によって実現します これにより ai 承認者に資格という3つ目の感覚が加わります 00:11:32.780 --> 00:11:37.960 テキストフィールドだけに頼るのではなくモデルがドキュメントを読み取り 書かれている内容とアップロードされた内容を称号します 00:11:37.960 --> 00:11:43.660 構造は以下の通りです ai ステージ内に画像またはドキュメントという新しい入力タイプを追加します 00:11:43.660 --> 00:11:50.540 領収書ファイルのように明確なラベルをつけます テスト用にサンプル領収書をアップロードしますこれは本番環境ではなくロジックのレイアウトを 00:11:50.540 --> 00:11:54.960 トレーニングするためのものです 次にドキュメントの相互検証を含めるように指示プロンプトを調整します 00:11:54.960 --> 00:11:59.580 以前のロジックを拡張します 以下の条件をすべて満たす場合に申請を承認します金額が500ドル以下であること 00:11:59.580 --> 00:12:05.880 申請内容が心身の健康を支援するものであること購入日から30日以内であること そして領収書の内容が申告された品目金額日付と一致していること 00:12:05.880 --> 00:12:11.380 この4番目の条件により ai 承認者は単なるポリシーの執行者から法医学的な会計担当へと進化するのです 00:12:11.380 --> 00:12:17.940 テストが実行されるとモデルはドキュメントから読み取り可能なテキストを抽出し 構造化された入力データとの整合性を検証します 00:12:17.940 --> 00:12:24.680 レシートにフィットネスマット300ドル8月22日と記載されているのに申請内容が異なれば 判定は却下に変わります 00:12:24.680 --> 00:12:31.840 さて実装にあたっては承認プロセスが走る前にそのドキュメントを取得する必要があります データバースのファイルまたは画像のダウンロードアクションを使用します 00:12:31.840 --> 00:12:39.760 申請レコードが存在するのと同じテーブルおそらくクレームをターゲットにします ファイル列にはレシートのような名前が付けられていることが多い添付ファイルフィールドを選択します 00:12:39.760 --> 00:12:49.020 次にトリガーから動的に行きIDを指定し固有の申請識別紙を設定します このアクションはファイルのメタデータとコンテンツを返しますがここに微妙な落とし穴があります 00:12:49.020 --> 00:12:56.700 コンテンツの出力には ai が正しく解釈するための少しの手術が必要です ファイルコンテンツをドキュメントレシートのファイル入力にマッピングする際 00:12:56.700 --> 00:13:04.400 式エディターを開きボディ参照にコンテンツを追加します その最後の微調整によりメタデータのラッパーではなく実際のファイルバイトが渡されるようになります 00:13:04.400 --> 00:13:11.560 これを忘れると ai は空のレシートを喜んで承認してしまいます 次にドキュメントワークフローの泣きどころである同期の問題に対処しましょう 00:13:11.560 --> 00:13:20.420 ほとんどのデータバーステーブルはレコードが最初に保存されるまで添付ファイルを保存しません つまりレコード作成時にフローがトリガーされるとファイルが存在する前に起動する可能性があります 00:13:20.420 --> 00:13:25.640 症状としてはフローが失敗するかレシートの内容が空になります その解決策はエレガントです 00:13:25.640 --> 00:13:31.200 トリガー条件をアイテムの変更時に変更しレシート列が変更された時のみ起動するように制限します 00:13:31.200 --> 00:13:40.840 そうすれば誰かがファイルをアップロードまたは置き換えた瞬間に検証が開始されます これを構成するにはトリガー設定を開き変更された列を選択し 00:13:40.840 --> 00:13:50.160 データバースの列詳細にある詳細ツールから取得できるレシート列の論理名を貼り付けます 設定したら公開しますこれで自動化プロセスは適切に動作するようになります 00:13:50.160 --> 00:13:56.080 検証すべき対象が存在するまで待機するからです 申請に新しいレシートが更新されるとフローが再開されます 00:13:56.080 --> 00:14:07.780 ファイルをダウンロードし ai ステージに送りすべての入力をクロスチェックします 金額の不一致古い日付説明の矛盾などがあれば ai は理由を添えて却下します 00:14:07.780 --> 00:14:14.700 理由ログには申請額305ドルがドキュメント合計300ドルと異なりますといった内容が表示されます これが不平を言わないコンプライアンスです 00:14:14.700 --> 00:14:22.240 実質的な影響は何でしょうかすべての提出が自己監査されるようになります 従業員は疑わしいレシートや曖昧な説明をごまかすことはできなくなります 00:14:22.240 --> 00:14:30.200 ai が判断を下しデータバースが証拠を提供しそのどちらも休憩を取ることはありません ですからドキュメントの検証は決してやりすぎではありません 00:14:30.200 --> 00:14:36.280 それはワークフローのための免疫記憶なのです 異常値は分子レベルつまりレシートに印刷された文字単位で検出され 00:14:36.280 --> 00:14:43.880 人間のレビュアーは手作業のチェック係から例外処理担当者へと昇格します おめでとうございますこれであなたは誠実さそのものを自動化したことになります 00:14:43.880 --> 00:14:52.440 信頼性の構築テストバージョニングそして公開 どんな自動化も動かすまでは完璧に見えるものですだからこそ信頼性は単なる段階ではなく 00:14:52.440 --> 00:14:59.020 一つの規律なのですコパイロットスタジオはバージョン管理 テスト公開といった制御をエージェントフローに直接組み込むことでその規律を驚くほど 00:14:59.020 --> 00:15:04.060 簡単にします まずは反復テストから始めましょう承認フローは一つ一つが小さなエコシステムです 00:15:04.060 --> 00:15:10.860 たった一つの変数の名前が誤っているだけで大混乱を引き起こしかねません ですからテストは科学的なプロセスとして扱ってください変更を分離し 00:15:10.860 --> 00:15:16.940 データを適用し出力を観察するのです フローエディターではコパイロットスタジオを使って本番のトリガーを動かさずに 00:15:16.940 --> 00:15:24.020 サンプルデータをシミュレーションできます 異常な金額古い日付無関係な項目名など様々なシナリオを入力しそれぞれで正しい判定が 00:15:24.020 --> 00:15:30.780 下されるか確認してください 次に命名規則に移ります退屈ですかその通りです不可欠ですか空気よりも大切です 00:15:30.780 --> 00:15:36.980 すべての変数に体系的なプレフィックスをつけましょう 文字面ならstr数値ならnamファイルならドックといった具合です同様にアクションにも明確な 00:15:36.980 --> 00:15:41.040 ラベルをつけます 領収書ファイルのダウンロードマネージャー承認の確認申請承認の更新などです 00:15:41.040 --> 00:15:46.840 3ヶ月後に誰かがなぜアクション7が壊れたのかと尋ねた時 考古学的な調査よりもこうした手がかりがあることに感謝するはずです 00:15:46.840 --> 00:15:52.620 個別のテストが成功したらエッジケースの検証に広げます 少し不慣れなユーザーになったつもりで操作してください 00:15:52.620 --> 00:16:00.480 領収書をアップロードしない日付を来年にする500と入力すべき場所に5000と打ち込むなどです AIがクラッシュせずに説明し拒否することを確認してください 00:16:00.480 --> 00:16:09.700 これらは架空の失敗ではなく現実のリハーサルです 失敗のケースを事前に潰しておけば置くほどまたフローが止まったという深夜2時のチームメッセージに悩まされることは減ります 00:16:09.700 --> 00:16:16.340 公開することでガバナンスが始まります 大きな変更を保存するたびにコパイロットスタジオは新しいバージョンを自動的に作成します 00:16:16.340 --> 00:16:23.140 いつでも以前のバージョンに戻せます 上書きの不安はありませんこれを利用して実験用のロジック環境を本番環境から分離しましょう 00:16:23.140 --> 00:16:29.640 申請承認開発用と申請承認本番用というフローを作成します 開発環境でテストし安定している場合のみ公開してください 00:16:29.640 --> 00:16:37.140 信頼性とは正しさだけではなく変化に直面した時のコントロール力であることを忘れないでください 公開後はアクティビティログを活用します 00:16:37.140 --> 00:16:41.380 これらは単なる飾りではなく ai と人間の対話を示す法的レベルの記録です 00:16:41.380 --> 00:16:48.000 タイムスタンプ承認者の身元推論の要約などが含まれます これらのログを定期的に確認してくださいパターンが見えてくるはずです 00:16:48.000 --> 00:16:53.620 どのルールが多くの拒否を引き起こしているかどのマネージャーが ai の判断を覆したか コンプライアンス手順がどれくらいの頻度で実行されたかなどがわかります 00:16:53.620 --> 00:17:02.060 こうした洞察がポリシーと設計の双方を宣伝させます もう一つの小さなベストプラクティスは各ブランチの最後にデータバースレコードへのステータス更新を自動化することです 00:17:02.060 --> 00:17:09.560 項の更新アクションで申請ステータスが承認または却下になるように明確なフィールドを設定してください この目に見える終着点が信頼を強固にします 00:17:09.560 --> 00:17:15.080 ユーザーは自分のテーブルビューで決定を確認できます 個別の追跡用スプレッドシートも正体不明の承認も不要です 00:17:15.080 --> 00:17:21.080 システムがすべてのテストに合格したら静かな自信を持って公開ボタンを押してください 以前の世代のパワーオートメイトフローとは異なり 00:17:21.080 --> 00:17:27.060 エージェントフローにはコンテキストメタデータ ai 意思決定スキーマ動的コンテンツバインディングバージョンタグが保持されます 00:17:27.060 --> 00:17:34.660 その結果は単にプロセスが実行されるだけでなく再現可能な成果物であり 監査可能な自動化となります最後の信頼性チェックはあなたの思考にかかっています 00:17:34.660 --> 00:17:39.800 過剰なエンジニアリングは避けましょう フローの失敗は技術的なバグではなくルールが複雑すぎることが原因である場合もあります 00:17:39.800 --> 00:17:45.460 可能な限りロジックを簡素化してください 段階を減らし指示を明確にし曖昧さを最小限に抑えます 00:17:45.460 --> 00:17:53.780 自動化を妨げるのはランダムな要素ではなく不必要な上手さです この段階を終えれば承認システムは運用上の成熟度を備えテスト可能でバージョン管理され 00:17:53.780 --> 00:18:00.860 ロールバックが容易で検証可能なものとなります ai による判断から管理者の承認に至るまで全ての成果には精査に頼るデジタルフットプリントが残ります 00:18:00.860 --> 00:18:08.740 それは定量化された信頼性であり雰囲気や運ではありません あなたが眠っている間に思考するよう構築したツールが構造化された推論を忠実に記録するのです 00:18:08.740 --> 00:18:15.260 結果と現実世界へのメリット完了的なプロセスを数学に委ねるとどうなるでしょうか 承認のために待つ必要はなくなります 00:18:15.260 --> 00:18:21.800 ai 主導の多段階エージェントフローによりカレンダーの空き状況に依存しなくなるため 処理期間は数日から数分に短縮されます 00:18:21.800 --> 00:18:29.660 客観的なポリシーを満たす申請はすべて即座に承認されます 例外的なケースはすべて文脈が添付された状態で管理者の給へ正確に送られます 00:18:29.660 --> 00:18:35.540 人間は事務的な確認作業ではなく価値判断を行うようになります その影響はまず時間の圧縮として現れます 00:18:35.540 --> 00:18:45.080 かつてはメール4通とリマインダー2回を必要とした経費生産が今では昼食前に完了します 各部門は処理サイクルの短縮アイドル状態の低減そして完全に記録された推論の奇跡を 00:18:45.080 --> 00:18:48.820 享受します 承認メカニズムはもはや中断を意味するものではなくなります 00:18:48.820 --> 00:18:52.820 それはインフラストラクチャとなります 次にエラーの低減がもたらされます 00:18:52.820 --> 00:19:01.020 AIを通じて決定論的なルールを強制することで主導承認の弊害である主観的なズレを排除できます これも健康維持費に含まれると思ったという言い訳はもう通用しません 00:19:01.020 --> 00:19:07.220 AIは毎回同じ方法で基準を解釈します 管理ロジックにおいて一貫性は思いやりよりも拡張性に優れています 00:19:07.220 --> 00:19:17.360 管理者は異常なケースのみに対処すれば良くそれらについても監査証跡が自動で付与されます データの入力決定の履歴モデルによる説明監査は慌ただしい作業から穏やかな検証へと変わります 00:19:17.360 --> 00:19:24.900 組織レベルで見ればこれは単に早いだけでなくより安全でもあります コンプライアンスは記憶や気分に依存しませんそれはシステムに組み込まれています 00:19:24.900 --> 00:19:32.880 データバースのログには誰がいつなぜ承認したかが記録されています すべての決定が検索可能な形で永続的に残るためこの透明性が手抜き文化を抑止します 00:19:32.880 --> 00:19:38.360 そして哲学的にはワークフローは ai が補佐する人間中心から人間が修正する ai 中心へと転換します 00:19:38.360 --> 00:19:43.440 これは sf ではなく実践的なガバナンスです ai がルールの強制を担い人間が判断を下します 00:19:43.440 --> 00:19:49.440 このハイブリッドな体制がより公平でより早くそして最終的に信頼できるシステムを生み出します それを監査人に説明する場面を想像してみてください 00:19:49.440 --> 00:19:53.480 その後に見せる相手の笑顔こそが自動化を行う何よりの価値です そういうことです 00:19:53.480 --> 00:20:00.040 マイクロソフトコパイロットスタジオは単なる自動化ツールではありません それはあなたの組織の決断の遅れが終わりを迎える場所なのです 00:20:00.040 --> 00:20:06.580 条件を考慮し適切にエスカレーションを行い領収書を称号しすべての動作を記録できる 承認エンジンを構築するのです 00:20:06.580 --> 00:20:11.560 それは単なるフローではなくガバナンスモデルです 他のことを忘れてもこれだけは覚えておいてください 00:20:11.560 --> 00:20:17.640 AIは判断を予測可能にし人間をより例外的な存在にすべきです 習慣で何でも人に回すのはやめましょう 00:20:17.640 --> 00:20:26.620 日常業務はロジックに任せマネージャーは例外処理に集中するのです この解説によって上司の承認待ちで1週間を費やすことがなくなったならぜひチャンネル登録を 00:20:26.620 --> 00:20:34.140 次回のチュートリアルではコパイロットスタジオの高度な自動化を深掘りし エージェントのフローをパワープラットフォームの分析や適用型ポリシーと連携させます 00:20:34.140 --> 00:20:38.920 アップグレードの道を確実にするため登録と通知設定を行い 新しいエピソードが自動的にデプロイされるようにしましょう 00:20:38.920 --> 00:20:44.060 手動の確認もリリースの見逃しもなし有益な知識が継続的に配信されます 進めてください