WEBVTT

00:00:00.000 --> 00:00:07.420
私たちの自動化ボタンを押せばスクリプトが走り見事な成果物が手に入る だがここにひねりがあるエージェントはスクリプトではない彼らはあなたを観察し

00:00:07.420 --> 00:00:15.000
自分で手順を計画し5秒おきに確認することなく実行する 自動化とは自動販売機のことだエージェントとはあなたの癖を学びあなたの言葉を先回りして

00:00:15.000 --> 00:00:21.960
終わらせるインターンのような存在だ このセッションではエージェントの真の構造観察計画実行のサイクル5つの主要コンポーネント

00:00:21.960 --> 00:00:31.020
構築すべきでないときそしてガバナンスがなぜシステムの製品を分けるのかを学ぶ 現代のエージェントは観察計画実行を繰り返すことで機能するこれは反復ではなく

00:00:31.020 --> 00:00:39.640
適用のために設計された業界標準のループだこれこそが真のエージェントと呼び名を変え ただけの自動化を隔てるものでありチームにとってその違いが重要となる理由だでは混乱の

00:00:39.640 --> 00:00:49.300
元となりがちな出発点から未抵抗ボタンを押せば魔法のようにことが進む 本当にそうだろうか自動化の幻想自動化の幻想はここにある知性があるように見えることも

00:00:49.300 --> 00:00:56.340
多いが実際はよく練習された手品に過ぎない カーテンの裏側にあるのは命令によって起動する固定された手順だけでそこに意識も

00:00:56.340 --> 00:01:04.020
選択の余地もない選択肢を検討することはない 前回のことを振り返ることもないただスクリプトを再生するだけだその信頼性は生きているように

00:01:04.020 --> 00:01:10.780
感じさせるがやはり機械的だ 自動化は一つのことつまり完璧な一貫性を保つのが得意だ毎日何千もの書類に同じ方法で

00:01:10.780 --> 00:01:19.040
スタンプを押す勤勉な事務員を想像してほしい 反復的で大量かつルールに基づいた作業においてそれは恵みとなる早く正確で文句も言わない

00:01:19.040 --> 00:01:26.480
時にそれこそが必要なものだだが限界もある ほんの少し詳細を変えるだけですべてが崩壊する書類に新しい行を加えたり

00:01:26.480 --> 00:01:34.260
インクを黒から青に変えたりするだけで事務員はフリーズしてしまう 交渉の余地はない臨機応変な対応もできない誰かがルールを書き換えるまで

00:01:34.260 --> 00:01:40.720
ただ立ち尽くすだけだ だからこそ自動化スクリプトにエージェントというラベルを貼っても賢くはならないのだ

00:01:40.720 --> 00:01:47.460
自動化が c 7を押してコーラを受け取る 自動販売機ならエージェントは在庫切れに気づきあなたが昨日2本買ったことを覚えていて

00:01:47.460 --> 00:01:53.380
代わりに水を提案してくれる店員のようなものだ この違いが重要なのだ自動化は与えられたルールに従う

00:01:53.380 --> 00:02:01.920
エージェントは観察し計画しある程度の自立性を持って行動する エージェントは複数のタスクに渡って記憶を保持し状況に適用し絶え間ない監視なしに意思決定を行う能力を

00:02:01.920 --> 00:02:07.940
持っている これこそが研究者と実践者が低い一線だ一方はスクリプトを実行しもう一方は思考のサイクルを回す

00:02:07.940 --> 00:02:12.220
gps の例を考えてみよう 古いモデルは単純に a 地点から b 地点への線を引くだけだ

00:02:12.220 --> 00:02:16.980
橋が落ちていてもどうしようもない あなたは今も何もない空中を走るよう言われているようなものですそれが自動化

00:02:16.980 --> 00:02:22.720
つまり地図の上に書かれた台本です 渋滞した時に自動でルートを変更してくれる最新のシステムと比べてみてください

00:02:22.720 --> 00:02:29.200
それがエージェントの働きでありリアルタイムで進路を調整し不足の事態を考慮し 障害があっても目的地まであなたを導きます

00:02:29.200 --> 00:02:34.500
その違いは表面的なものではなく機能的なものです しかしマーケティングはあえてその境界を曖昧に従います

00:02:34.500 --> 00:02:40.180
知的なボットが有能な助手として宣伝されていても実際には使い古された提携文を 繰り返すだけだったという経験は誰にでもあるはずです

00:02:40.180 --> 00:02:47.380
古代広告のサイクルは繰り返しを失望へと変えてしまいます 管理職は柔軟な副操縦士を期待しているのに手渡されるのは融通の効かないマクロなのです

00:02:47.380 --> 00:02:54.260
その結果は単なる苛立ちではなく信頼の崩壊です 一度痛い目を見るとチームは二度と試そうとしなくなり本物のエージェントシステムが登場した

00:02:54.260 --> 00:02:57.140
時でさえ疑心暗鬼になります ここで明確にしておくことが重要です

00:02:57.140 --> 00:03:04.480
自動化は悪いものではありません実際自動化の方が好ましい場合もあります プロセスが普遍でルールが単純なら固定されたスクリプトの方が安価で安全

00:03:04.480 --> 00:03:13.060
そして完全に効果的です自動化が機能しなくなるのは状況が変化したり条件が進化したり 判断が必要になったりする場面ですそうしたシナリオを単なるスクリプトに任せるのは

00:03:13.060 --> 00:03:18.960
オフィスにあるプリンターに急な顧客へのプレゼンに最適な用紙を選ばせるようなものです それはプリンターが構築された目的ではありません

00:03:18.960 --> 00:03:24.900
さて短いジョークもそれが確信をついていなければ意味がありません 確かに定義を極限まで広げればトースターだってエージェントと呼べるかもしれません

00:03:24.900 --> 00:03:30.000
パンを入れ熱を加え合図に合わせて飛び出させるのですから しかしそれはエージェンシー主体性ではなく単なる仕組みです

00:03:30.000 --> 00:03:37.480
真の危険はあらゆるデバイスやボットを同じラベルで呼ぶことにあります それはエージェントという言葉の意味を薄め期待を膨らませ必然的な失望を招くことになります

00:03:37.480 --> 00:03:44.880
ガバナンスにはここでの正確性が不可欠です 自動化と主体性を混同すればシステムには扱い切れない権限を与えてしまうことになります

00:03:44.880 --> 00:03:51.000
つまり結論はこうです 自動化はスピードと一貫性で実行しますが計画したり早期したり適応したりすることはできません

00:03:51.000 --> 00:03:55.140
エージェントはそのすべてを行えます その違いは言葉遊びではなく設計上の本質的な違いです

00:03:55.140 --> 00:03:58.900
両者を混同しても誰の得にもなりません そしてここから物語が展開します

00:03:58.900 --> 00:04:06.880
幻想を取り払い自動化を正しく定義できればエージェントが実際に何を動力としているのか つまり単なる機械ではなく適応性をもたらすうちなるリズムが見えてくるはずです

00:04:06.880 --> 00:04:14.960
そのリズムは一つのループから始まります それはあなたの隣にいる若手社員のように気づき考え行動する能力を与える基本的なシーケンスです

00:04:14.960 --> 00:04:22.000
観察計画行動のエンジンです 観察計画行動というエンジンこそがエージェントという言葉が真の意味を持つ場所なのです

00:04:22.000 --> 00:04:29.060
古代広告を取り除いた後に残るのはこのサイクルです 継続的な観察熟慮された計画そして安全な実行です

00:04:29.060 --> 00:04:35.180
それは単なる飾りではなく判断と単なる再生を分かつ中核となるエンジンです まずは観察から始まります

00:04:35.180 --> 00:04:42.160
エージェントは盲目的に行動しません メールログチャットスレッドセンサーデータダッシュボードのメトリクスなど

00:04:42.160 --> 00:04:50.260
許可されたあらゆる経路から情報を収集します 具体的には適切なデータソースに接続しノイズに埋もれることなくコンテキストを把握できる

00:04:50.260 --> 00:04:56.240
十分な範囲を与えることを意味します 優れた観察者は大げさではなく慎重かつ着実に常に目を配っています

00:04:56.240 --> 00:05:00.900
ビジネスにおいてこの段階はエージェントがインテリジェントに行動するための材料を得られるかを左右します

00:05:00.900 --> 00:05:07.880
コンテキストから切り離せばそれは単なる複雑すぎるマクロにすぎません 次に計画がきますここが思考の働きどころです

00:05:07.880 --> 00:05:17.300
エージェントは入力に基づいて可能な経路を検討します この行動を取ればゴールに近づくかどのようなリスクがあるか他にどのような選択肢があるか

00:05:17.300 --> 00:05:23.720
技術的にはこのステップは多くの場合大規模言語モデルや結果をランク付けして進むべき道を決める意思決定エンジンによって支えられています

00:05:23.720 --> 00:05:30.860
チェスボードを見渡す戦略家を思い浮かべてください どの選択肢にもトレードオフがありますが目の前の進歩と長期的な立ち位置のバランスを取れる道は一つだけです

00:05:30.860 --> 00:05:36.700
組織にとってその意味は明らかです 計画の段階こそエージェントが資産となるか不採となるかが決まる場所です

00:05:36.700 --> 00:05:43.080
推論力がなければ選択ではなく単なる反応に終わります 計画が形になると実行によって言葉が現実のものとなります

00:05:43.080 --> 00:05:48.620
エージェントはここでコマンドを発行し api を呼び出し更新を送信し既存システム内のプロセスを起動します

00:05:48.620 --> 00:05:53.960
固定されたボットとは異なりエラーや権限拒否データ欠落サービスのタイムアウトにも対処しなければなりません

00:05:53.960 --> 00:05:59.860
実行には信頼性と慎重さが求められます だからこそセキュアな統合と丁寧なエラーハンドリングが重要なのです

00:05:59.860 --> 00:06:08.840
やり方を間違えれば一度のミスが下流のすべてに悪影響を及ぼします ビジネスチームにとってアクションは信頼の境界線ですここでエージェントが失敗すればもう二度と頼りにされることはないでしょう

00:06:08.840 --> 00:06:15.060
このループが性的なものではないことに注目してください 各アクションがシステムの状態を変化させそれが次にエージェントが何を観察するかのフィードバックとなります

00:06:15.060 --> 00:06:20.980
思考に失敗すればその経験が次の意思決定を再形成します 成功すればエージェントのパターン認識が強化されます

00:06:20.980 --> 00:06:28.820
時間の経過とともにこのサイクルは単なる繰り返しではなく蓄積となります 微細な調整が積み重なりパフォーマンスが向上していきますここで一つの例えが役立ちます

00:06:28.820 --> 00:06:38.720
パイロットを思い浮かべてください彼らは景気を確認し観察します 悪天候を避けるルートを書き計画します操縦感を調整し実行しそして直ちにダイヤルに目を戻して確認します

00:06:38.720 --> 00:06:44.600
迅速で反復的でフィードバックに基づいていますそれこそがループの重要性です それは華やかではありませんが生き残るために不可欠です

00:06:44.600 --> 00:06:55.280
実用的な強みはここにあります自動化は単に実行するだけですがエージェントはループするの です観察は認識をもたらし計画は判断を導き行動は選択を実行しフィードバックがこのサイクルを維持します

00:06:55.280 --> 00:07:03.480
このエンジンのどの部分が欠けても構築されたものはエージェントではなく 総ラベル付けされた壊れやすいおもちゃにすぎませんでは真の疑問はこの骨組みがどのようにして命を支えるのかということです

00:07:03.480 --> 00:07:10.920
観察計画行動がフレームであるなら何が血液を送り動きを生み出すのでしょうか このループを機能させるためにエージェントの体は何から構成されているのでしょうか

00:07:10.920 --> 00:07:18.640
次にその5つの臓器を紐解いていきましょう エージェントの体を構成する5つの臓器機能するすべてのアイエージェントには連携する5つの主要な臓器があります

00:07:18.640 --> 00:07:25.900
一つでもかければそれは信頼できるチームメイトとは呼べません それは複雑な現実世界ではすぐに失敗してしまう壊れやすい構造物です

00:07:25.900 --> 00:07:30.500
ではそれらを一つずつ実践的な観点から分解していきましょう 視覚は取り込み口です

00:07:30.500 --> 00:07:37.760
フォルダーに置かれた文書であれ現場からのセンサー信号であれ 更新をストリーミングするAPIであれ環境から情報を収集します

00:07:37.760 --> 00:07:43.860
これは単にクリーンなデータを取得するだけでなくノイズの多い性の信号を扱い 利用可能な形に成形することを意味します

00:07:43.860 --> 00:07:51.840
視覚がなければエージェントは現実から遮断され世界が変化し続ける中で盲目的に行動することになります 記憶は視覚に文脈を与えるものです

00:07:51.840 --> 00:07:59.540
ここには大きく分けて2つの種類があります 短期記憶は直近の脅威進行中の会話または最後に実行したいくつかのコマンドを保持します

00:07:59.540 --> 00:08:05.160
一方長期記憶は構造化された知識ベースやベクトル埋め込みを保存し 数ヶ月後でも呼び出すことができます

00:08:05.160 --> 00:08:09.700
これらを合わせることでエージェントは過ちを繰り返したり 対話の流れを見失ったりすることを防げます

00:08:09.700 --> 00:08:14.580
技術的には多くの場合一貫性を保つセッションメモリと長期的な記録のための外部ストレージを組み合わせます

00:08:14.580 --> 00:08:18.300
どちらの層が欠けてもエージェントは何も思い出せなくなったり タスクの途中で迷子になったりするでしょう

00:08:18.300 --> 00:08:24.560
推論は意思決定エンジンです 視覚し記憶したものを受け取り目的と照らし合わせて選択肢を比較検討します

00:08:24.560 --> 00:08:30.560
これは推論エンジンや最適化モデルあるいはプランナーとして機能する大規模言語モデルによって支えられます

00:08:30.560 --> 00:08:37.940
船の航海士のように進路を分析し前方の嵐を見抜き どちらへ舵を切るべきかを推奨するものと考えてください

00:08:37.940 --> 00:08:42.080
推論は判断をもたらし単なる反射と戦略の違いを生み出します

00:08:42.080 --> 00:08:45.560
推論がなければ主体性はなくただの機械的な反応にすぎません

00:08:45.560 --> 00:08:51.600
学習は停滞を防ぐフィードバックループです 結果を吸収し時間をかけて行動を調整します

00:08:51.600 --> 00:08:56.540
ワークフローの思考が失敗すれば学習メカニズムが次回のプレイブックを更新します

00:08:56.540 --> 00:09:02.660
実際にはエージェントはモデルの再トレーニングや成功 失敗のシグナルに基づくヒューリスティクスの更新によってこれを実現します

00:09:02.660 --> 00:09:08.540
これこそがエージェントを性的なツールから適応的なものへと引き上げ 経験を積むごとに着実に改善させるのです

00:09:08.540 --> 00:09:13.040
学習がなければどんなに賢いシステムも時代に取り残され過去のものとなってしまいます

00:09:13.040 --> 00:09:18.640
アクションはシステムの手であり声です 計画は実行に移されて初めて意味を持ちます

00:09:18.640 --> 00:09:25.000
API呼び出しファイル書き込み通知またはコマンドなど このコンポーネントは意思決定を現実に橋渡ししますがリスクも伴います

00:09:25.000 --> 00:09:32.720
もし間違ったシーケンスを起動したり保護機能を回避してしまったらどうなるでしょうか そのため堅牢なアクションにはセキュアな統合権限チェックそしてフェールセーフが不可欠です

00:09:32.720 --> 00:09:38.600
正しく実装されていれば目的を持った制御システムと操縦席でボタンを連打する用事のような振る舞いとの違いが生まれます

00:09:38.600 --> 00:09:44.200
これらの機関はどれも不可欠ですが単独で機能するものはありません それらは一つの生きた回路を形成しています

00:09:44.200 --> 00:09:51.920
視覚が記憶を養い記憶が推論の根拠となり推論が学習を促しこの4つがすべてアクションを推進します どれか一つの機関が欠ければループは機能不全に陥るか崩壊します

00:09:51.920 --> 00:09:56.660
多くのいわゆるエージェントがテストで失敗するのはそのためです 彼らには重要な解剖学的構造が欠けているのです

00:09:56.660 --> 00:10:01.060
しかし構造が揃っているだけでは安全な運用は保障されません それらの機関にはルールと監視が必要です

00:10:01.060 --> 00:10:08.640
さもなければ自信満々に間違いを犯すことになります そしてここからが議論の次のステップです強力なシステムを軌道に乗せ続けるために本当に必要なこととは何か

00:10:08.640 --> 00:10:15.400
それはガバナンスすなわち飛行マニュアルです デスクにロケットを縛り付けることではなく離陸前に飛行ルールを策定することだと考えてください

00:10:15.400 --> 00:10:25.360
エージェントは強力であり自ら判断を下し始めたらクリアな空と目に見える境界線が必要になります その構造がなければ知性に見えるものも瞬く間に混沌へと漂流してしまいます

00:10:25.360 --> 00:10:33.800
エージェントが独立して動作するとき彼らは自らの操縦機のパイロットとして振る舞います 彼らはデータストリームを解釈し選択肢を比較検討しシステム全体にアクションをトリガーします

00:10:33.800 --> 00:10:38.480
まさにそこで物事はうまくいかなくなる可能性があるのです 入力データのバイアスが判断を歪めます

00:10:38.480 --> 00:10:44.560
透明性の欠如はブラックボックスを見つめる状態を招きます そして見えないところで下された決定はコンプライアンスや倫理と衝突する可能性があります

00:10:44.560 --> 00:10:48.100
ガバナンスこそが安定装置です それはミッションを遅らせるものではありません

00:10:55.360 --> 00:11:04.920
データ取り込みですこれはエージェントがどの情報を取り込んで良いかどう承認されるかを定義します 無作為なフィードはバイアスと漏洩の元となります一方で承認済みのパイプラインは認可された

00:11:04.920 --> 00:11:12.320
クリーンな入力のみが推論を駆動することを保障します 第二に透明性と監査証跡ですすべての決定には検証可能な足跡を残すべきであり

00:11:12.320 --> 00:11:22.640
それにより規制当局管理者利害関係者は結論に至ったいきさつを理解できます 第三に人間による監視です採用医療金融安全など結果が重大な判断においては人がプロセスに

00:11:22.640 --> 00:11:29.560
関与し続ける必要がありますこれは無駄な作業ではありません リスクが高い時に信頼を維持するための防護策なのです調査によると導入のハードルとして

00:11:29.560 --> 00:11:35.700
2つの壁が繰り返し現れることがわかっています 偏ったデータから忍び寄るバイアスと結果の説明を困難にする解釈性の欠如

00:11:35.700 --> 00:11:43.420
だからこそガバナンスには強力なデータキュレーションと推論過程を可視化するメカニズムの 両方が不可欠なのです質の高い入力は信頼性の高い出力につながります

00:11:43.420 --> 00:11:50.580
そのステップを怠ればエージェントは全速力で稼働しながら誤った学習を静かに進めてしまう 可能性がありますフレームワークはこれらの原則を実践に移す助けとなります

00:11:50.580 --> 00:11:56.820
華やかではありませんが構造的な基盤です 例えばデータの航空完成感のように機能するツールがすでに存在します

00:11:56.820 --> 00:12:03.940
マイクロソフトパービューはその選択肢の一つです データがどのようなルールに基づいて流入しコンプライアンス義務にどう適合するかを強制します

00:12:03.940 --> 00:12:10.040
知性を付加するものではなく飛行ルート自体の安全を確保するためのものです 監督の範囲は倫理にも及びます

00:12:10.040 --> 00:12:18.080
バイアスのかかった過去の履歴に過剰適合して最適化を行う採用エージェントを想像してください 高度上は効率的でも倫理的及び法的には失敗しています

00:12:18.080 --> 00:12:27.200
ガバナンスがあれば被害が広がる前に人間がその判断を確認することを義務付けられ ますこれは進歩を遅らせるのではなく訴訟スキャンダルそして評判の失墜を防ぐためのものです

00:12:27.200 --> 00:12:35.600
規制もまた飛行ルートを定める同様の役割を果たします データプライバシー規則業界コンプライアンス地域境界線はすべて飛行禁止区域のように機能します

00:12:35.600 --> 00:12:44.940
それに違反すればシステムエラーではなく罰金強制措置あるいは顧客の信頼喪失という事態に直面します 適切なガバナンスはこうした制約をスタビライザー安定化装置として捉え直します

00:12:44.940 --> 00:12:51.260
これらはイノベーションを阻むものではなく他者の領域へ迷い込まないようにするものです バイアスそのものについても触れておく必要があります

00:12:51.260 --> 00:12:58.300
方位の狂ったコンパスだと考えてください偏ったデータで針が狂えばエージェントが行う修正はすべて より一層コースを外れることになります

00:12:58.300 --> 00:13:07.480
ガバナンスは入力のキュレーションモデルの監査定期的な調整を通じてこれに対抗します これがないとエージェントは驚くべき精度で間違ったターゲットに向かって動作してしまいます

00:13:07.480 --> 00:13:13.560
ガバナンスを単なる後付けのプロセスつまり完成後の補強程度に考えるリーダーもいます その考え方は本質を見誤っています

00:13:13.560 --> 00:13:21.780
ガバナンスはパラシュートではなく機体そのものに組み込まれた安定化システムです 揺れを抑え景気を正しく保ち乱気流の中でも飛行を継続させるためのものです

00:13:21.780 --> 00:13:29.740
称賛されることはありませんが離陸の旅に頼りにされている存在です ここでチームへの実践的なアドバイスをします重大な決断や曖昧な判断が必要な場合には必ず

00:13:29.740 --> 00:13:34.500
人間を介在させてください 金銭安全公平性に影響する選択については監督者に最終決定権を与えてください

00:13:34.500 --> 00:13:40.700
日常的な自動化についてはエージェントに任せて巡行させましょう このシンプルな選別がすべてを停止させることなく信頼を構築します

00:13:40.700 --> 00:13:46.820
つまりガバナンスは自立性の醍醐味を奪うものではありません それは潜在能力を確かな成果へと変換するものです

00:13:46.820 --> 00:13:54.380
ルールが整えば次に考えるべきはエージェントが飛べるかどうかではなく あなたのミッションに適した機体はどれかということです

00:13:54.380 --> 00:14:02.720
格納庫の選択マイクロソフトのエージェントを現場へ エージェントの設置場所を選ぶ際は派手な機能よりも任務に最適な機体を見極めることが重要です

00:14:02.720 --> 00:14:07.860
マイクロソフトは格納庫に複数のプラットフォームを用意しており それぞれが異なるパイロットと飛行計画に合わせて構築されています

00:14:07.860 --> 00:14:15.040
重要なのは名前を覚えることではありません 自分の役割課題の複雑さコンプライアンス要件そしてシステム全体とどれだけ深く連携させる必要があるかを考慮し

00:14:15.040 --> 00:14:19.260
最適な操縦席を選ぶことです 格納庫を選ぶ前に調整すべき4つのダイヤルがあると考えてください

00:14:19.260 --> 00:14:24.180
1つ目はユーザーの種類です あなたはエンドユーザーですかパワーユーザーですかそれとも開発者ですか

00:14:24.180 --> 00:14:28.940
2つ目は任務の複雑さです シンプルなワークフローか企業規模の課題か

00:14:28.940 --> 00:14:33.860
3つ目はデータの機密性です コンプライアンスや監査の要件が影のようにつきまといますか

00:14:33.860 --> 00:14:39.380
そして4つ目は統合の必要性です エージェントは質問に答えるだけでしょうかそれとも技術スタックの半分に組み込む必要があるでしょうか

00:14:39.380 --> 00:14:46.340
各マイクロソフトのプラットフォームはこの枠組みに綺麗に当てはまります まずはシェアポイントエージェントからこれらはドキュメントやチームのワークフローを中心に活動する

00:14:46.340 --> 00:14:52.520
エンドユーザー向けに調整されています 最適な対象はエンドユーザープロファイルで任務の複雑さが低中程度そして内部コンテンツに

00:14:52.520 --> 00:14:59.260
主に紐付く中程度の統合ニーズがある場合です 派手さはありませんがシェアポイント内の既存記録の取得要約整理など

00:14:59.260 --> 00:15:05.840
ドキュメント中心のアシスタントが必要な場合に進化を発揮します 記憶力の優れたオフィス事務員だと考えてください

00:15:05.840 --> 00:15:13.020
堅実で役立ちイントラネットの規則に従順です コパイロットスタジオはその能力を一段階引き上げます

00:15:13.020 --> 00:15:19.860
ローコード開発を求めるエンドユーザーに最適で 対話型ヘルパーや軽量なプロセス自動化を得意とします

00:15:19.860 --> 00:15:26.580
ここでの任務の複雑さは控えめです カスタマーサービスのチャット知識検索ガイド付きワークフローなど

00:15:26.580 --> 00:15:33.880
コンプライアンスの要求は通常低いですが統合のしやすさは維持されています 高度なエンジニアリングを必要とせずビジネスアプリと連携できます

00:15:33.880 --> 00:15:39.020
要するにコパイロットスタジオはビジネスユーザーのためのグライダーであり 軽量で操縦しやすく多少のミスも許容されます

00:15:39.020 --> 00:15:44.780
アジュールアイファウンドリーは全く別の存在です これは重い任務に取り組むパワーユーザーや専門家のためのものです

00:15:44.780 --> 00:15:51.460
コンプライアンスが厳格で深い統合が求められる企業レベルのインテリジェンスシステム向けです 基準との整合性は明らかです

00:15:51.460 --> 00:16:04.380
高度なユーザータイプ高い任務の複雑さ高いデータ機密性そして広範な統合ニーズ ファウンドリはカスタム ai エンジンの設計ガバナンス管理の強化規制対象システム全体の拡張を行う場所です

00:16:04.380 --> 00:16:11.300
これは空母クラスの航空機であり大規模で複雑 かつスピードと同じくらい精度や規制が重要な任務に適しています

00:16:11.300 --> 00:16:20.480
次は実験者のためのセマンティックカーネルとオートゲンです これらのプラットフォームはすぐに使える勘弁さよりも柔軟性やオーケストレーションを重視する開発者や研究者に適しています

00:16:20.480 --> 00:16:29.740
適合基準開発者というユーザー層高いミッション複雑性環境により変化するコンプライアンス そして複数のシステムを連携させるオーケストレーションに不可欠な高度な統合ニーズ

00:16:29.740 --> 00:16:35.620
セマンティックカーネルは既存アプリにAIの推論機能を拡張し オートゲンは連携するエージェント群を調整します

00:16:35.620 --> 00:16:42.660
これを単一のパイロットではなく飛行隊だと考えてみてください 空中でエージェントからエージェントへと引き継ぎを行う変態飛行のようなものです

00:16:42.660 --> 00:16:50.500
業界の事例を見るとなぜこのマッピングが重要なのかがわかります あるグローバル消費材メーカーはエージェントを活用したアプローチでマーケティングデータを集約

00:16:50.500 --> 00:16:57.780
分析し意思決定を効率化した実績を記録しています この展開には広範な統合機能と高度な計画能力の両方が必要であり

00:16:57.780 --> 00:17:02.480
アジュールアイファウンドリーのようなエンタープライズグレードのプラットフォームが必要である ことは明白でした

00:17:02.480 --> 00:17:12.020
ビジネスケースは抽象的なものではなく適切なハンガー環境を選択したことで測定可能なロイをもたらしました そして空は一社が独占しているわけではないことも指摘しておくべきでしょう

00:17:12.020 --> 00:17:20.380
マイクロソフトは強力なフリートを提供していますがセールスフォースエージェントフォースのような選択肢があることは競争の存在を示しています その存在は特定のベンダーの独占が道を決定するわけではないことを強調しています

00:17:20.380 --> 00:17:29.200
道を決めるのは戦隊に書かれたブランドではなくミッションの内容であるべきです 意思決定のフレームワークは単純です自分たちの立ち位置作業の複雑さデータの機密性

00:17:29.200 --> 00:17:34.380
そして統合の必要性を照らし合わせることです そうすれば最適なハンガーが自然と明らかになります

00:17:34.380 --> 00:17:41.260
ミスマッチが起きれば些細なタスクに過剰なエンジニアリングを行うかあるいは要求の厳しい ミッションに装備が不足するかのどちらかですしかし最後の罠には注意してください

00:17:41.260 --> 00:17:48.600
問題が明確で反復可能なものであれば従来の自動化で十分です スクリプト化されたワークフローを超えた記憶計画または自立性が必要な場合にのみ

00:17:48.600 --> 00:17:58.060
エージェントを選んでくださいその違いを明確に理解できれば旅の最後のピースが 見えてきますエージェントの真の定義を再考しそれを単純なものと勘違いすることが

00:17:58.060 --> 00:18:06.100
リスクと機械損失の両方を生む理由を理解することです 結論まとめに入りましょうエージェントは自動化とは別物です

00:18:06.100 --> 00:18:12.760
スクリプトではなくループで試行しますこれらは5つの重要な要素によって支えられた 観察計画実行エンジンで動作します

00:18:12.760 --> 00:18:22.120
ガバナンス安全な取り込み人間による監視監査証跡がなければ重要なミッションを 任せることはできませんそれが気の利いたマクロと実際のチームメイトとの違いです

00:18:22.120 --> 00:18:29.580
片方は繰り返すだけもう片方は適用します次はあなたの番です あなたの組織で単純な自動化ではなくエージェントを本当に必要としているプロセスは何ですか

00:18:29.580 --> 00:18:36.340
コメント欄で教えてください鋭い例には目を通します 価値ある成果ですね脳のアップデートを自動で行うためにチャンネル登録をどうぞ