WEBVTT

00:00:00.000 --> 00:00:02.240
誰も言わない衝撃的な事実をお伝えしましょう

00:00:02.240 --> 00:00:04.220
Azure FoundryでAIをデプロイするとき

00:00:04.220 --> 00:00:06.280
単に巨大なモデルを立ち上げるだけではありません

00:00:06.280 --> 00:00:07.940
管理されたランタイムに配置することで

00:00:07.940 --> 00:00:10.180
全ての関連アクション、メッセージツール呼び出し

00:00:10.180 --> 00:00:12.360
実行ステップがログに記録され追跡されます

00:00:12.360 --> 00:00:14.920
スレッド、実行、実行ステップがいかにして監査可能で

00:00:14.920 --> 00:00:17.660
エンタープライズ対応の実験を行うための証跡となるかが分かります

00:00:17.660 --> 00:00:19.780
これによりAIは制御不能な状態から

00:00:19.780 --> 00:00:21.540
管理可能な規律あるシステムへと変わります

00:00:21.540 --> 00:00:22.960
その構造が整ったとき

00:00:22.960 --> 00:00:26.560
真の問いは誰がこのデジタル部隊を率いるのかということです

00:00:26.560 --> 00:00:28.320
部隊のリーダーを紹介しましょう

00:00:28.320 --> 00:00:29.660
ファウンドリでセットアップを行う際

00:00:29.660 --> 00:00:31.400
単にチャットウィンドウを立ち上げているのではありません

00:00:31.400 --> 00:00:33.180
部隊のリーダーを任命しているのです

00:00:33.180 --> 00:00:35.720
これは自動補完で遊んでいるインターンではありません

00:00:35.720 --> 00:00:39.340
明確な設計に基づいてミッションを遂行する現場の隊長なのです

00:00:39.340 --> 00:00:44.240
その設計はモデル、指示、ツールの3つの主要な歯車に集約されます

00:00:44.240 --> 00:00:45.360
モデルはNOです

00:00:45.360 --> 00:00:48.100
推論と言語を司り人間の言葉を解析し

00:00:48.100 --> 00:00:50.820
ステップを計画し応答を起案する役割を担います

00:00:50.820 --> 00:00:52.540
指示はミッションの命令です

00:00:52.540 --> 00:00:54.640
NOが勝手な方向にはぐれるのを防ぎ

00:00:54.640 --> 00:00:57.040
真に必要とされる成果へとつなぎ止めます

00:00:57.040 --> 00:00:59.460
そしてツールはその身に備えた装備です

00:00:59.460 --> 00:01:01.920
コード実行、検索コネクタ、レポート用API

00:01:01.920 --> 00:01:04.260
あるいは接続するあらゆるサードパーティシステムがこれに当たります

00:01:04.260 --> 00:01:07.600
Azure AIエージェントは明確にこの3要素から構築されています

00:01:07.600 --> 00:01:10.400
それがなければ再現性も観察性も得られません

00:01:10.400 --> 00:01:12.680
証拠のないテキスト生成が残るだけです

00:01:12.680 --> 00:01:14.720
これを戦場の例に当てはめてみましょう

00:01:14.720 --> 00:01:16.620
モデルは隊長の戦闘訓練です

00:01:16.620 --> 00:01:18.960
剣を振るう方法や判決を下す方法を知っています

00:01:18.960 --> 00:01:20.560
指示はミッションのブリーフィングです

00:01:20.560 --> 00:01:23.500
5層部隊を守れ契約セットからデータを抽出せよ

00:01:23.500 --> 00:01:25.320
結果を特定のフォーマットで報告せよ

00:01:25.320 --> 00:01:27.940
それが隊長の方針を統一し予測可能な行動を可能にします

00:01:27.940 --> 00:01:29.760
そしてツールが専門性を加えます

00:01:29.760 --> 00:01:31.280
壁を登るためのグラップリングフックは

00:01:31.280 --> 00:01:33.460
分析を実行するコードインタープリタのようなものです

00:01:33.460 --> 00:01:36.180
安全な無線機はシェアポイントやカスタムMCPコネクタが

00:01:36.180 --> 00:01:37.840
ライブデータを計画に送り込むようなものです

00:01:37.840 --> 00:01:40.680
これら3つが揃うとエージェントは即興で動くことはありません

00:01:40.680 --> 00:01:43.080
ログとチェックポイントを伴ってミッションを遂行します

00:01:43.080 --> 00:01:45.300
ファウンドリはこの仕組みを実用的なものにします

00:01:45.300 --> 00:01:48.280
ほとんどのチャットAPIではモデルとプロンプとしか得られません

00:01:48.280 --> 00:01:49.420
そして対話が始まれば

00:01:49.420 --> 00:01:52.020
命令やツールオーケストレーションという正式な概念はありません

00:01:52.020 --> 00:01:55.440
それは隊長を計画も装備もなしに戦場へ切り出すようなものです

00:01:55.440 --> 00:01:57.500
対照的にファウンドリのエージェントサービスは

00:01:57.500 --> 00:01:59.700
これら3つの層が全て揃っていることを保証します

00:01:59.700 --> 00:02:02.380
さらに良いことに一つの脳に縛られる必要はありません

00:02:02.380 --> 00:02:04.980
ファウンドリカタログ内のモデルを自由に切り替えることができます

00:02:04.980 --> 00:02:06.680
複雑な戦略にはGPT4を

00:02:06.680 --> 00:02:08.180
軽量なタスクにはより小型なモデルを

00:02:08.180 --> 00:02:10.440
あるいはミストラルやディープシークを導入することも可能です

00:02:10.440 --> 00:02:12.240
ミッションに合わせて自由に選べます

00:02:12.240 --> 00:02:13.380
その柔軟性こそが

00:02:13.380 --> 00:02:16.500
画一的なインターンと適応力のある司令官との違いです

00:02:16.500 --> 00:02:19.220
ではそれらの層が欠けていた場合の危険性を考えてみてください

00:02:19.220 --> 00:02:20.940
出力が一貫性を失います

00:02:20.940 --> 00:02:22.760
ある契約書の要約ではこう書かれているのに

00:02:29.700 --> 00:02:32.180
デバッグは当てずっぽうな作業になります

00:02:32.180 --> 00:02:34.540
企業においてそれは些細な問題ではありません

00:02:34.540 --> 00:02:36.840
信頼と導入を阻む現実的なリスクなのです

00:02:36.840 --> 00:02:39.100
ファウンドリはこの問題を直接的な方法で解決します

00:02:39.100 --> 00:02:40.960
ガードレールがエージェントに組み込まれています

00:02:40.960 --> 00:02:43.540
指示は必ず守るべき普遍のルールブックとして機能します

00:02:43.540 --> 00:02:46.140
ツールセットはユースケースに応じて厳密に制限することも

00:02:46.140 --> 00:02:47.200
拡張することも可能です

00:02:47.200 --> 00:02:48.840
モデルは自由に入れ替えられますが

00:02:48.840 --> 00:02:51.920
常に説明責任を強制する構造の中で行われます

00:02:51.920 --> 00:02:53.740
これら3つの要素が組み合わさることで

00:02:53.740 --> 00:02:56.620
規律ある部隊長、予測可能な出力、可視化された手順

00:02:56.620 --> 00:03:00.160
そしてエンタープライズコネクタやカスタムAPIによる責任ある拡張が可能になります

00:03:00.160 --> 00:03:03.220
これはAIを魔法の会話術として売り込むものではありません

00:03:03.220 --> 00:03:06.440
ログを記録し命令に従い適切な装備を備えた

00:03:06.440 --> 00:03:08.840
強靭な昇降を組織に迎え入れることを意味します

00:03:08.840 --> 00:03:10.380
優れた隊長がそうであるように

00:03:10.380 --> 00:03:12.400
あらゆるミッションの記録を慎重に保持します

00:03:12.400 --> 00:03:15.840
システム監査や実行の失敗時にはその日記が必要になるからです

00:03:15.840 --> 00:03:18.000
ファウンドリではその日記をこう呼びます

00:03:18.000 --> 00:03:19.080
スレッドです

00:03:19.080 --> 00:03:21.260
スレッドそれは戦場の記録です

00:03:21.260 --> 00:03:23.880
スレッドはミッションログが形作られる場所です

00:03:23.880 --> 00:03:27.900
Azure Foundryにおいてスレッドは閉じた瞬間に消える単なるチャットウィンドウではありません

00:03:27.900 --> 00:03:29.620
持続可能な会話セッションです

00:03:29.620 --> 00:03:31.120
ユーザーとエージェントのすべてのやり取りは

00:03:31.120 --> 00:03:32.840
あなたから発せられたもの、エージェントからのもの

00:03:32.840 --> 00:03:35.300
あるいはマルチエージェント環境下における別のエージェントからのものであっても

00:03:35.300 --> 00:03:36.260
すべてここに保存されます

00:03:36.260 --> 00:03:37.480
これが戦場の記録であり

00:03:37.480 --> 00:03:39.600
チャット終了後も長く振り返ることができる

00:03:39.600 --> 00:03:41.200
永続的な対話履歴を保持します

00:03:41.200 --> 00:03:44.780
真の強みはスレッドが単なる静的な記録ではないという点にあります

00:03:44.780 --> 00:03:47.960
これらは自動的に切り捨て処理を行う構造化コンテナであり

00:03:47.960 --> 00:03:50.760
モデルの制限内でアクティブなコンテキストを維持しつつ

00:03:50.760 --> 00:03:52.660
完全な監査証跡を保存します

00:03:52.660 --> 00:03:55.720
つまりエージェントは進行中の会話を理解し続け

00:03:55.720 --> 00:03:58.840
企業はレビュー可能な記録を永続的に保持できるのです

00:03:58.840 --> 00:04:00.380
一般的なチャットアプリとは異なり

00:04:00.380 --> 00:04:01.820
何も消えてなくなることはありません

00:04:01.820 --> 00:04:03.040
エージェントには継続性を

00:04:03.040 --> 00:04:04.500
ビジネスにはガバナンスをもたらします

00:04:04.500 --> 00:04:06.940
そのログのエントリーはメッセージによって構成されています

00:04:06.940 --> 00:04:09.020
メッセージはプレーンテキストに限定されません

00:04:09.020 --> 00:04:10.480
画像やスプレッドシートファイル

00:04:10.480 --> 00:04:12.580
生成されたコードブロックなどを格納できます

00:04:12.580 --> 00:04:14.220
それぞれにはタイムスタンプが押され

00:04:14.220 --> 00:04:16.880
ユーザーまたはアシスタントという役割ラベルが付与されます

00:04:16.880 --> 00:04:19.580
スレッドを調査すれば何が言われたかだけでなく

00:04:19.580 --> 00:04:23.160
誰がいつどのような形式で言ったのかまで確認できます

00:04:23.160 --> 00:04:25.100
コンプライアンス担当者が記録を開き

00:04:25.100 --> 00:04:27.060
昨日送信された正確なテキストリクエスト

00:04:27.060 --> 00:04:29.180
エージェントが回答として生成したグラフ画像

00:04:29.180 --> 00:04:32.200
そしてその両方の発生時刻を確認する場面を想像してください

00:04:32.200 --> 00:04:35.080
それは単なる記憶ではなく完全で実在する台帳なのです

00:04:35.080 --> 00:04:36.040
ゲーム用語で例えるなら

00:04:36.040 --> 00:04:39.060
スレッドはダンジョンズ&ドラゴンズのキャンペーンにおけるノートブックのようなものです

00:04:39.060 --> 00:04:40.720
ダンジョンマスターは訪れた街

00:04:40.720 --> 00:04:41.860
成功したダイスロール

00:04:41.860 --> 00:04:43.620
手に入れた戦利品をすべて書き留めます

00:04:43.620 --> 00:04:44.600
そのようなログがなければ

00:04:44.600 --> 00:04:46.960
プレイヤーたちは忘れてしまった詳細について言い争うことになります

00:04:46.960 --> 00:04:50.020
ログがあれば出来事が記録されているため議論はすぐに解決します

00:04:50.020 --> 00:04:52.460
企業向けAIにおいてもスレッドは同様の役割を果たします

00:04:52.460 --> 00:04:53.760
すべてが順番に記録されているため

00:04:53.760 --> 00:04:56.080
エージェントが実際に何をしたかについての紛争を防ぐことができます

00:04:56.080 --> 00:04:58.300
ではなぜその記録が重要なのでしょうか

00:04:58.300 --> 00:05:01.140
監査やコンプライアンスにおいてスレッドは非常に価値のあるものです

00:05:01.140 --> 00:05:03.580
規制当局や内部監査チームはスレッドを開くことで

00:05:03.580 --> 00:05:06.080
ユーザーのリクエスト、エージェントの回答、使用されたツール

00:05:06.080 --> 00:05:08.460
そして発生時刻という一連の流れを即座に確認できます

00:05:08.460 --> 00:05:11.620
開発者にとってはその記録はデバッグモードのように機能します

00:05:11.620 --> 00:05:13.540
エージェントが間違ったコードを生成した場合

00:05:13.540 --> 00:05:15.400
スレッドをそのリクエスト時点まで巻き戻して

00:05:15.400 --> 00:05:17.260
なぜそうなったのかを正確に追跡できます

00:05:17.260 --> 00:05:19.100
どちらのグループも可視性が高まり

00:05:19.100 --> 00:05:20.940
時間の浪費を避けられるはずです

00:05:20.940 --> 00:05:23.500
会話を保持しないシステムと対比してみましょう

00:05:23.500 --> 00:05:25.740
スレッドがなければスクリーンショットや

00:05:25.740 --> 00:05:27.700
曖昧な記憶で挙動を追うことになります

00:05:27.700 --> 00:05:30.580
そんな対応ではコンプライアンス担当者から証拠を求められた際や

00:05:30.580 --> 00:05:32.480
サポートがバグを再現したい際には通用しません

00:05:32.480 --> 00:05:34.780
まるでゲームでボス戦をやり直すよう言われたのに

00:05:34.780 --> 00:05:36.860
セーブしていなかったことに気づくようなものです

00:05:36.860 --> 00:05:40.300
記録がなければ証拠はなく追跡できなければ修正もできません

00:05:40.300 --> 00:05:42.160
ダイス目が悪ければ失敗すれば

00:05:42.160 --> 00:05:44.460
口約束だけで関係者を安心させるしかなくなります

00:05:44.460 --> 00:05:47.160
ファウンドリのスレッド機能があればその罠を回避できます

00:05:47.160 --> 00:05:49.560
すべての会話が構造化された証拠となります

00:05:49.560 --> 00:05:51.980
ワークフローが法的な文言を抽出する場合

00:05:51.980 --> 00:05:53.360
記録には元のリクエスト

00:05:53.360 --> 00:05:54.900
生成された特定の回答

00:05:54.900 --> 00:05:57.000
サポートツールの呼び出しの有無が示されます

00:05:57.000 --> 00:06:00.100
複数のエージェントが互いに相談してタスクを分担する場合

00:06:00.100 --> 00:06:02.100
そのやり取りもすべてログに残ります

00:06:02.100 --> 00:06:03.840
企業はコンプライアンスを証明し

00:06:03.840 --> 00:06:05.280
開発者はバグを特定し

00:06:05.280 --> 00:06:08.220
管理者はシステムから出力される結果を信頼できるようになります

00:06:08.220 --> 00:06:12.440
スレッドは混沌としたチャットを本番環境で使えるレベルへと変えてくれるのです

00:06:12.440 --> 00:06:13.940
一時的なやり取りの代わりに

00:06:13.940 --> 00:06:16.240
使命と決定の安定した履歴を作り出し

00:06:16.240 --> 00:06:17.640
信頼できる基盤となります

00:06:17.640 --> 00:06:20.280
ただしログはあくまで日記に過ぎないことを忘れないでください

00:06:20.280 --> 00:06:21.060
真のアクションは

00:06:21.060 --> 00:06:22.700
エージェントがスレッドに書かれた内容を読み取り

00:06:22.700 --> 00:06:24.200
実際に実行に移した時に始まります

00:06:24.200 --> 00:06:25.080
次の段階とは

00:06:25.080 --> 00:06:28.380
ミッションが紙の上のメモからリアルタイムで実際に動くものへと変わる段階のことです

00:06:28.380 --> 00:06:30.740
ラン実行とランステップス実行ステップは

00:06:30.740 --> 00:06:32.000
いわばサイコロを振るようなものです

00:06:32.000 --> 00:06:34.180
ランこそがミッションが最終的に開始される場所です

00:06:34.180 --> 00:06:34.980
ファウンドリの用語では

00:06:34.980 --> 00:06:38.860
スレッドスレッドが会話の履歴指示コンテキストそして広げた地図を保持しています

00:06:38.860 --> 00:06:40.980
ランはエージェントがそのコンテキストを受け取り

00:06:40.980 --> 00:06:42.920
実際に実行に移すためのトリガーとなります

00:06:42.920 --> 00:06:44.860
スレッドは記憶しランは実行します

00:06:44.860 --> 00:06:46.800
ランを打ち上げボタンのようなものと考えてください

00:06:46.800 --> 00:06:49.320
スレッドにはCSVを分析してと書かれているかもしれません

00:06:49.320 --> 00:06:51.360
あるいは折れ線グラフを書くよう指示されているかもしれません

00:06:51.360 --> 00:06:55.680
しかしランはエージェントがモデルの指示とツールを通じてそのリクエストを処理する瞬間なのです

00:06:55.680 --> 00:06:57.740
そこでは外部データの取得数値の計算

00:06:57.740 --> 00:07:00.560
あるいはコードインタープリタの呼び出しによる成果物の生成が行われます

00:07:00.560 --> 00:07:02.200
テーブルトークRPGに例えるなら

00:07:02.200 --> 00:07:04.840
スレッドはパーティーがテーブルを囲んで作戦を練る段階です

00:07:04.840 --> 00:07:07.420
ランは戦闘を開始するためのイニシアチブロールです

00:07:07.420 --> 00:07:09.300
それがなければ何も前に進みません

00:07:09.300 --> 00:07:11.280
ファウンドリが明確にしているのはこの点です

00:07:11.280 --> 00:07:12.880
ランはブラックボックスではありません

00:07:12.880 --> 00:07:15.520
監視されステータスが追跡される実行プロセスです

00:07:15.520 --> 00:07:19.900
通常急入り進行中アクション待ち完了失敗といったステータスを確認できます

00:07:19.900 --> 00:07:22.660
SDKのサンプルではゲームマスターがターンの順序を確認するように

00:07:22.660 --> 00:07:24.500
ループでこれらの状態を頻繁にポーリングします

00:07:24.500 --> 00:07:26.260
これにより何が行われるかだけでなく

00:07:26.260 --> 00:07:28.220
いつ行われるかという可視性が確保されます

00:07:28.220 --> 00:07:30.040
しかしさらに大きな懸念があります

00:07:30.040 --> 00:07:33.320
実行の内部で実際に何が起きたのかどうやって把握すればいいのでしょうか

00:07:33.320 --> 00:07:35.120
回答がまともに見えても詳細がなければ

00:07:35.120 --> 00:07:37.620
エージェントが外部APIを叩いたのかコードを書いたのか

00:07:37.620 --> 00:07:39.360
単に文章をでっち上げたのか判別できません

00:07:39.360 --> 00:07:42.200
そのような不透明さはエンタープライズ環境では危険です

00:07:42.200 --> 00:07:44.140
それはチェスの試合の途中に立ち合い

00:07:44.140 --> 00:07:47.040
正しい手が打たれたから我々を信じてくれと言われるようなものです

00:07:47.040 --> 00:07:48.200
やり直しはできません

00:07:48.200 --> 00:07:50.340
その手がルールに適法だったのかどうかも分かりません

00:07:50.340 --> 00:07:52.820
その推測を排除してくれるのがランステップスです

00:07:52.820 --> 00:07:54.400
すべてのランはステップごとに記録され

00:07:54.400 --> 00:07:55.840
どのモデル出力が生成され

00:07:55.840 --> 00:07:56.920
どのツールが呼び出され

00:07:56.920 --> 00:07:58.000
どの計算が行われ

00:07:58.000 --> 00:07:59.720
どのメッセージが生成されたかが分かります

00:07:59.720 --> 00:08:01.600
これはAIのためのチェスフです

00:08:01.600 --> 00:08:02.480
ポーンをE4へ

00:08:02.480 --> 00:08:03.980
ナイトをF6へのように

00:08:03.980 --> 00:08:05.460
10時2分にファイルを取得し

00:08:05.460 --> 00:08:07.280
10時3分にコードブロックを実行し

00:08:07.280 --> 00:08:09.560
10時4分にグラフを出力するといった記録です

00:08:09.560 --> 00:08:11.020
各アクションは順番に書き留められるため

00:08:11.020 --> 00:08:12.380
後から再現することが可能です

00:08:12.380 --> 00:08:14.660
その構造は開発者にとって大きな安心材料となります

00:08:14.660 --> 00:08:15.560
ランステップスがなければ

00:08:15.560 --> 00:08:16.720
最終的な回答を前にして

00:08:16.720 --> 00:08:17.940
それがどうやって導き出されたのか

00:08:17.940 --> 00:08:18.680
開目検討もつきません

00:08:18.680 --> 00:08:20.180
検索クエリが間違っていたのか

00:08:20.180 --> 00:08:21.620
計算ミスが紛れ込んだのか

00:08:21.620 --> 00:08:23.040
ただ推測するしかありません

00:08:23.040 --> 00:08:24.040
ランステップスがあれば

00:08:24.040 --> 00:08:25.180
タイムラインをスクロールして

00:08:25.180 --> 00:08:26.980
正確なミス箇所を特定し修正できます

00:08:26.980 --> 00:08:28.580
デバッグは当てずっぽうな作業から

00:08:28.580 --> 00:08:30.200
科学的な検証へと変わるのです

00:08:30.200 --> 00:08:31.700
それは誰が攻撃したのか

00:08:31.700 --> 00:08:33.080
完全としない霧の中のボス戦闘

00:08:33.080 --> 00:08:35.080
剣の振りや呪文の栄章すべてが記録された

00:08:35.080 --> 00:08:36.440
戦闘ログとの違いのようなものです

00:08:36.440 --> 00:08:37.740
コンプライアンスチームにとっても

00:08:37.740 --> 00:08:39.060
これは大きな利点となります

00:08:39.060 --> 00:08:40.420
監査担当者にその要約は

00:08:40.420 --> 00:08:42.020
どのように生成されたのかと聞かれたとき

00:08:42.020 --> 00:08:44.640
モデルの推論を抽象的な言葉で説明する必要はありません

00:08:44.640 --> 00:08:46.100
証拠が手元にあるからです

00:08:46.100 --> 00:08:46.740
ツール呼び出し

00:08:46.740 --> 00:08:47.620
インタープリターのステップ

00:08:47.620 --> 00:08:48.420
組み立てられた回答

00:08:48.420 --> 00:08:49.880
これらすべてにタイムスタンプが押されています

00:08:49.880 --> 00:08:52.060
これにより説明は統制へと変わります

00:08:52.060 --> 00:08:53.220
物語を語るのではなく

00:08:53.220 --> 00:08:54.600
証拠を示すことができるのです

00:08:54.600 --> 00:08:55.580
企業がこれを好むのは

00:08:55.580 --> 00:08:56.940
リスクが説明責任に変わり

00:08:56.940 --> 00:08:59.060
約束ではなく証明に基づいた運用ができるからです

00:08:59.060 --> 00:09:00.320
日々の業務においても

00:09:00.320 --> 00:09:03.140
実行ステップは信頼できる再現可能なパターンを作り出します

00:09:03.140 --> 00:09:05.260
ワークフローを再実行する必要がある場合

00:09:05.260 --> 00:09:06.620
同じ手順をなぞるだけです

00:09:06.620 --> 00:09:07.700
結果に疑義が生じても

00:09:07.700 --> 00:09:09.080
それを再現して確認できます

00:09:09.080 --> 00:09:10.100
理想的な状況下では

00:09:10.100 --> 00:09:11.680
実行ステップが完全に記録されていれば

00:09:11.680 --> 00:09:12.820
出力がどのように構築されたかの

00:09:12.820 --> 00:09:14.280
監査可能かつ再現性のある証拠が得られます

00:09:14.280 --> 00:09:15.820
他のシステムで最悪の結果が生じた場合

00:09:15.820 --> 00:09:17.860
手元に残るのは足跡のない不確かな出力だけでしょう

00:09:17.860 --> 00:09:18.500
だからこそ

00:09:18.500 --> 00:09:20.680
エージェントのライフサイクルのこの部分が重要なのです

00:09:20.680 --> 00:09:21.600
スレッドという日記

00:09:21.600 --> 00:09:22.980
実行というアクティベーション

00:09:22.980 --> 00:09:23.940
そして実行ステップという

00:09:23.940 --> 00:09:25.400
一挙手一投足のログが存在します

00:09:25.400 --> 00:09:26.320
これらが揃うことで

00:09:26.320 --> 00:09:27.320
即興的なAIは

00:09:27.320 --> 00:09:28.100
行動を追跡

00:09:28.100 --> 00:09:28.940
テスト擁護できる

00:09:28.940 --> 00:09:30.400
責任あるチームメイトへと変わるのです

00:09:30.400 --> 00:09:30.940
もちろん

00:09:30.940 --> 00:09:32.700
これだけの詳細が存在することを知っているだけでは

00:09:32.700 --> 00:09:33.780
パズルのピースは揃いません

00:09:33.780 --> 00:09:34.820
それらと対話するための手段

00:09:34.820 --> 00:09:36.580
つまり性のAPI呼び出しに溺れることなく

00:09:36.580 --> 00:09:37.460
エージェントを起動し

00:09:37.460 --> 00:09:38.260
実行をトリガーし

00:09:38.260 --> 00:09:40.220
ステップを読み戻すための構造化された方法が必要です

00:09:40.220 --> 00:09:41.080
驚くべきことに

00:09:41.080 --> 00:09:43.540
それを行うために派手なコマンドデッキは必要ありません

00:09:43.540 --> 00:09:45.200
ほとんどの人が使用するコンソールは

00:09:45.200 --> 00:09:45.940
馴染み深く

00:09:45.940 --> 00:09:47.080
堅牢で少し地味なもの

00:09:47.080 --> 00:09:47.800
そう

00:09:47.800 --> 00:09:48.300
ネット

00:09:48.300 --> 00:09:48.920
アーセナル

00:09:48.920 --> 00:09:49.920
そしてアライアンスです

00:09:49.920 --> 00:09:50.420
アーセナル

00:09:50.420 --> 00:09:50.840
ブキコ

00:09:50.840 --> 00:09:51.600
とアライアンス

00:10:00.940 --> 00:10:03.480
ドキュメントの確認方法や計算手順を説明するだけでなく

00:10:03.480 --> 00:10:05.220
エージェントが実際にそれを実行し

00:10:05.220 --> 00:10:06.900
出力結果を返せるようになるのです

00:10:06.900 --> 00:10:07.760
この違いこそが

00:10:07.760 --> 00:10:08.840
単なるデモで終わらず

00:10:08.840 --> 00:10:11.680
実際の企業現場でプラットフォームを価値あるものにする理由です

00:10:11.680 --> 00:10:12.320
ファウンドリは

00:10:12.320 --> 00:10:14.560
3つの明確な能力カテゴリーを提供します

00:10:14.560 --> 00:10:15.320
1つ目は

00:10:15.320 --> 00:10:16.400
組込みツールです

00:10:16.400 --> 00:10:16.840
これには

00:10:16.840 --> 00:10:17.920
コードインタープリター

00:10:17.920 --> 00:10:18.720
リング検索

00:10:18.720 --> 00:10:21.000
シェアポイントおよびマイクロソフトファブリックコネクタ

00:10:21.000 --> 00:10:22.680
Azure iSearchなどが含まれます

00:10:22.680 --> 00:10:23.380
これらを使えば

00:10:30.940 --> 00:10:31.540
回答を超えて

00:10:31.540 --> 00:10:34.320
検証や再利用が可能な具体的な成果物へと範囲を広げます

00:10:34.320 --> 00:10:34.820
次に

00:10:34.820 --> 00:10:37.560
マイクロソフトが提供するものだけに縛られることはありません

00:10:37.560 --> 00:10:38.180
ファウンドリでは

00:10:38.180 --> 00:10:40.500
オープンAPI仕様やモデルコンテキストプロトコル

00:10:40.500 --> 00:10:42.820
MCPを通じてカスタムツールを登録できます

00:10:42.820 --> 00:10:43.940
特にMCPは

00:10:43.940 --> 00:10:46.920
AIツールのUSB-Cのように扱われるため重要です

00:10:46.920 --> 00:10:49.560
エージェントをリモートのMCPサーバーに接続するたびに

00:10:49.560 --> 00:10:50.940
ラッパーを手書きする必要はなく

00:10:50.940 --> 00:10:52.320
システムがツールの検出

00:10:52.320 --> 00:10:53.240
バージョン管理

00:10:53.240 --> 00:10:54.780
呼び出しを自動的に処理します

00:10:54.780 --> 00:10:55.560
これにより

00:10:55.560 --> 00:10:57.660
統合のオーバーヘッドが大幅に軽減されます

00:10:57.660 --> 00:10:58.100
特に

00:10:58.100 --> 00:11:00.960
数十ものシステムを連携させる必要がある環境では大きなメリットです

00:11:00.960 --> 00:11:01.500
3つ目に

00:11:01.500 --> 00:11:02.760
ファウンドリでのすべてのツール呼び出しは

00:11:02.760 --> 00:11:03.080
過観測

00:11:03.080 --> 00:11:03.940
オブザーバブルです

00:11:03.940 --> 00:11:04.900
呼び出しはステップ単位で

00:11:04.900 --> 00:11:05.260
ID

00:11:05.260 --> 00:11:05.700
入力

00:11:05.700 --> 00:11:06.140
出力

00:11:06.140 --> 00:11:07.560
タイムスタンプと共にログに記録されます

00:11:07.560 --> 00:11:07.840
つまり

00:11:07.840 --> 00:11:08.760
運用担当者から見て

00:11:08.760 --> 00:11:09.580
これらのエージェントは

00:11:09.580 --> 00:11:10.960
信じて任せる魔法ではありません

00:11:10.960 --> 00:11:12.020
台帳そのものです

00:11:12.020 --> 00:11:13.420
何を呼び出したかを正確に監視し

00:11:13.420 --> 00:11:15.020
適切な権限に従っていることを確認し

00:11:15.020 --> 00:11:15.860
コンプライアンスのために

00:11:15.860 --> 00:11:17.020
高級的な記録を残すことができます

00:11:17.020 --> 00:11:18.640
これらのカテゴリーを具体的に理解するために

00:11:18.640 --> 00:11:20.080
クイックスタートのデモを思い浮かべてください

00:11:20.080 --> 00:11:22.540
CSVファイルをメッセージとしてスレッドにアップロードします

00:11:22.540 --> 00:11:23.860
エージェントが実行ステップ内で

00:11:23.860 --> 00:11:25.180
コードインタープリターツールを呼び出し

00:11:25.180 --> 00:11:26.680
ファイルを処理してグラフを生成します

00:11:26.680 --> 00:11:28.500
その成果物は画像として返され

00:11:28.500 --> 00:11:30.360
スレッドログ内で直接確認できます

00:11:30.360 --> 00:11:31.780
パーサーや可視化ツールを

00:11:31.780 --> 00:11:33.240
自分で書く必要はありません

00:11:33.240 --> 00:11:34.280
指示を出すだけで

00:11:34.280 --> 00:11:35.880
エージェントがツールを選択し

00:11:35.880 --> 00:11:36.640
実行し

00:11:36.640 --> 00:11:38.860
レポートに貼り付けられるファイルを返してくれます

00:11:38.860 --> 00:11:39.900
これは理論ではなく

00:11:39.900 --> 00:11:42.280
SDKサンプルで文書化されている動作です

00:11:42.280 --> 00:11:43.720
これが進化を発揮するのは

00:11:43.720 --> 00:11:45.260
エンタープライズ統合の場面です

00:11:45.260 --> 00:11:47.040
ツールをロジックアップスにリンクできるため

00:11:47.040 --> 00:11:48.980
エージェントは1400以上の既存の

00:11:48.980 --> 00:11:51.100
SaaSおよびオンプレミスのコネクタにアクセス可能です

00:11:51.100 --> 00:11:53.680
CRM、ERP、ITSMプラットフォーム向けの

00:11:53.680 --> 00:11:54.920
アダプターを再コーディングする代わりに

00:11:54.920 --> 00:11:56.020
ビジネスですでに稼働している

00:11:56.020 --> 00:11:57.440
コネクタに対して設定を行うだけです

00:11:57.440 --> 00:11:59.200
これはスケールのための戦略です

00:11:59.200 --> 00:12:01.100
壊れやすいAPIブリッジを書くことなく

00:12:01.100 --> 00:12:02.200
一つのエージェントが

00:12:02.200 --> 00:12:04.060
広範な環境全体で安全に動作できます

00:12:04.060 --> 00:12:06.500
次に誰もが尋ねるのはセキュリティについてです

00:12:06.500 --> 00:12:08.680
ファウンドリはそれを中核で解決しています

00:12:08.680 --> 00:12:09.860
ツールがシェアポイントや

00:12:09.860 --> 00:12:11.940
ファブリックのような企業システムに接続する際

00:12:11.940 --> 00:12:14.060
マイクロソフトエントラを介したオンビハーフ

00:12:14.060 --> 00:12:15.760
代理、認証を使用します

00:12:15.760 --> 00:12:17.520
機能ファイルを読み取る権限がなかった場合

00:12:17.520 --> 00:12:18.820
今日エージェントが魔法のように

00:12:18.820 --> 00:12:20.100
その壁を突破することはありません

00:12:20.100 --> 00:12:21.680
IDと権限は維持されます

00:12:21.680 --> 00:12:23.140
これこそがコンプライアンスチームが

00:12:23.140 --> 00:12:24.480
承認を与える唯一の方法です

00:12:24.480 --> 00:12:26.060
全ての呼び出しは追跡可能です

00:12:26.060 --> 00:12:27.080
誰が呼び出したのか

00:12:27.080 --> 00:12:28.180
何が送信されたのか

00:12:28.180 --> 00:12:29.220
何が受信されたのか

00:12:29.220 --> 00:12:30.900
そのためチームは常に証跡を保持できます

00:12:30.900 --> 00:12:31.940
最高の成果が出せれば

00:12:31.940 --> 00:12:32.940
このツールキット一式は

00:12:32.940 --> 00:12:35.060
エージェント部隊を単なる目新しさ以上の存在に変えてくれます

00:12:35.060 --> 00:12:36.740
実際のデータを紹介し処理し

00:12:36.740 --> 00:12:38.400
IT部門が慣れ親しんだガードレール内で

00:12:38.400 --> 00:12:39.560
行動できるユニットが手に入ります

00:12:39.560 --> 00:12:40.720
こうした選択肢がなければ

00:12:40.720 --> 00:12:42.380
大口を叩くだけで実作業はこなせない

00:12:42.380 --> 00:12:43.960
単なるチャットセッションで終わってしまうでしょう

00:12:43.960 --> 00:12:44.620
だからこそ

00:12:44.620 --> 00:12:45.820
部隊のリーダーと同じくらい

00:12:45.820 --> 00:12:47.220
装備する武器が重要なのです

00:12:47.220 --> 00:12:49.260
モデルと指示がエージェントの思考を支えるとしても

00:12:49.260 --> 00:12:50.700
ツールが責任を持って接続され

00:12:50.700 --> 00:12:51.980
確実に記録されていなければ

00:12:51.980 --> 00:12:53.560
それは中途半端な対策にすぎません

00:12:53.560 --> 00:12:54.640
ファウンドリの組み込みセット

00:12:54.640 --> 00:12:55.300
MCP

00:12:55.300 --> 00:12:56.820
オープンAPIの拡張性

00:12:56.820 --> 00:12:58.920
そしてエンタープライズグレードのセキュリティがあれば

00:12:58.920 --> 00:13:00.480
推測によるプロンプトの寄せ集めではなく

00:13:00.480 --> 00:13:01.840
規律ある力を構築できます

00:13:01.840 --> 00:13:04.020
さてここからが全体像の話です

00:13:04.020 --> 00:13:05.060
ファウンドリのエージェントは

00:13:05.060 --> 00:13:07.440
気まぐれな相棒や遊び道具として作られたものではありません

00:13:07.440 --> 00:13:09.120
構造を持ち負荷が考慮され

00:13:09.120 --> 00:13:11.020
本番環境で役立つ装備を備えた

00:13:11.020 --> 00:13:13.020
管理されたオペレーターとして設計されています

00:13:13.020 --> 00:13:14.940
キャンペーンはここで締めくくりとなります

00:13:14.940 --> 00:13:16.180
結論の時間です

00:13:16.180 --> 00:13:16.760
ファウンドリは

00:13:16.760 --> 00:13:18.720
モデルにプロンプトを投げるだけのものではありません

00:13:18.720 --> 00:13:18.940
NO

00:13:18.940 --> 00:13:19.540
ルールブック

00:13:19.540 --> 00:13:21.380
ツールキットを備えたエージェントを構築するための

00:13:21.380 --> 00:13:22.640
再現性のある方法を提供します

00:13:22.640 --> 00:13:24.300
そして彼らが行う全ての動作は

00:13:24.300 --> 00:13:26.340
スレッド、実行、実行ステップに記録されます

00:13:26.340 --> 00:13:27.440
開発リードにとっても

00:13:27.440 --> 00:13:28.940
コンプライアンス担当者にとっても

00:13:28.940 --> 00:13:29.940
結論はシンプルです

00:13:29.940 --> 00:13:32.020
ネットのようなSDKによる再現可能で

00:13:32.020 --> 00:13:33.160
監査可能な実行により

00:13:33.160 --> 00:13:35.720
ライフサイクル全体を完全に制御・可視化できます

00:13:35.720 --> 00:13:36.600
次のステップとして

00:13:36.600 --> 00:13:37.720
テストプロジェクトを立ち上げ

00:13:37.720 --> 00:13:38.920
基本エージェントを作成し

00:13:38.920 --> 00:13:39.800
スレッドを実行して

00:13:39.800 --> 00:13:42.040
SDKまたはポータルで実行ステップを確認してください

00:13:42.040 --> 00:13:42.640
それによって

00:13:42.640 --> 00:13:44.840
ログが実際のストーリーと一致していることを確認できます

00:13:44.840 --> 00:13:47.120
もしこれがデプロイでクリティカルヒットを出す助けになったなら

00:13:47.120 --> 00:13:48.960
チャンネル登録と通知設定をお願いします

00:13:48.960 --> 00:13:51.080
あるいはまた別のクラスターを制御できたなら

00:13:51.080 --> 00:13:53.040
艦隊の隊列を維持するために登録してください