Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Azure AI Foundry Threads：AIを企業で使える状態にする方法（AI吹き替え）

Transcript

Azure AI Foundry Threads：AIを企業で使える状態にする方法（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
誰も言わない衝撃的な事実をお伝えしましょう
0:02
Azure FoundryでAIをデプロイするとき
0:04
単に巨大なモデルを立ち上げるだけではありません
0:06
管理されたランタイムに配置することで
0:07
全ての関連アクション、メッセージツール呼び出し
0:10
実行ステップがログに記録され追跡されます
0:12
スレッド、実行、実行ステップがいかにして監査可能で
0:14
エンタープライズ対応の実験を行うための証跡となるかが分かります
0:17
これによりAIは制御不能な状態から
0:19
管理可能な規律あるシステムへと変わります
0:21
その構造が整ったとき
0:22
真の問いは誰がこのデジタル部隊を率いるのかということです
0:26
部隊のリーダーを紹介しましょう
0:28
ファウンドリでセットアップを行う際
0:29
単にチャットウィンドウを立ち上げているのではありません
0:31
部隊のリーダーを任命しているのです
0:33
これは自動補完で遊んでいるインターンではありません
0:35
明確な設計に基づいてミッションを遂行する現場の隊長なのです
0:39
その設計はモデル、指示、ツールの3つの主要な歯車に集約されます
0:44
モデルはNOです
0:45
推論と言語を司り人間の言葉を解析し
0:48
ステップを計画し応答を起案する役割を担います
0:50
指示はミッションの命令です
0:52
NOが勝手な方向にはぐれるのを防ぎ
0:54
真に必要とされる成果へとつなぎ止めます
0:57
そしてツールはその身に備えた装備です
0:59
コード実行、検索コネクタ、レポート用API
1:01
あるいは接続するあらゆるサードパーティシステムがこれに当たります
1:04
Azure AIエージェントは明確にこの3要素から構築されています
1:07
それがなければ再現性も観察性も得られません
1:10
証拠のないテキスト生成が残るだけです
1:12
これを戦場の例に当てはめてみましょう
1:14
モデルは隊長の戦闘訓練です
1:16
剣を振るう方法や判決を下す方法を知っています
1:18
指示はミッションのブリーフィングです
1:20
5層部隊を守れ契約セットからデータを抽出せよ
1:23
結果を特定のフォーマットで報告せよ
1:25
それが隊長の方針を統一し予測可能な行動を可能にします
1:27
そしてツールが専門性を加えます
1:29
壁を登るためのグラップリングフックは
1:31
分析を実行するコードインタープリタのようなものです
1:33
安全な無線機はシェアポイントやカスタムMCPコネクタが
1:36
ライブデータを計画に送り込むようなものです
1:37
これら3つが揃うとエージェントは即興で動くことはありません
1:40
ログとチェックポイントを伴ってミッションを遂行します
1:43
ファウンドリはこの仕組みを実用的なものにします
1:45
ほとんどのチャットAPIではモデルとプロンプとしか得られません
1:48
そして対話が始まれば
1:49
命令やツールオーケストレーションという正式な概念はありません
1:52
それは隊長を計画も装備もなしに戦場へ切り出すようなものです
1:55
対照的にファウンドリのエージェントサービスは
1:57
これら3つの層が全て揃っていることを保証します
1:59
さらに良いことに一つの脳に縛られる必要はありません
2:02
ファウンドリカタログ内のモデルを自由に切り替えることができます
2:04
複雑な戦略にはGPT4を
2:06
軽量なタスクにはより小型なモデルを
2:08
あるいはミストラルやディープシークを導入することも可能です
2:10
ミッションに合わせて自由に選べます
2:12
その柔軟性こそが
2:13
画一的なインターンと適応力のある司令官との違いです
2:16
ではそれらの層が欠けていた場合の危険性を考えてみてください
2:19
出力が一貫性を失います
2:20
ある契約書の要約ではこう書かれているのに
2:29
デバッグは当てずっぽうな作業になります
2:32
企業においてそれは些細な問題ではありません
2:34
信頼と導入を阻む現実的なリスクなのです
2:36
ファウンドリはこの問題を直接的な方法で解決します
2:39
ガードレールがエージェントに組み込まれています
2:40
指示は必ず守るべき普遍のルールブックとして機能します
2:43
ツールセットはユースケースに応じて厳密に制限することも
2:46
拡張することも可能です
2:47
モデルは自由に入れ替えられますが
2:48
常に説明責任を強制する構造の中で行われます
2:51
これら3つの要素が組み合わさることで
2:53
規律ある部隊長、予測可能な出力、可視化された手順
2:56
そしてエンタープライズコネクタやカスタムAPIによる責任ある拡張が可能になります
3:00
これはAIを魔法の会話術として売り込むものではありません
3:03
ログを記録し命令に従い適切な装備を備えた
3:06
強靭な昇降を組織に迎え入れることを意味します
3:08
優れた隊長がそうであるように
3:10
あらゆるミッションの記録を慎重に保持します
3:12
システム監査や実行の失敗時にはその日記が必要になるからです
3:15
ファウンドリではその日記をこう呼びます
3:18
スレッドです
3:19
スレッドそれは戦場の記録です
3:21
スレッドはミッションログが形作られる場所です
3:23
Azure Foundryにおいてスレッドは閉じた瞬間に消える単なるチャットウィンドウではありません
3:27
持続可能な会話セッションです
3:29
ユーザーとエージェントのすべてのやり取りは
3:31
あなたから発せられたもの、エージェントからのもの
3:32
あるいはマルチエージェント環境下における別のエージェントからのものであっても
3:35
すべてここに保存されます
3:36
これが戦場の記録であり
3:37
チャット終了後も長く振り返ることができる
3:39
永続的な対話履歴を保持します
3:41
真の強みはスレッドが単なる静的な記録ではないという点にあります
3:44
これらは自動的に切り捨て処理を行う構造化コンテナであり
3:47
モデルの制限内でアクティブなコンテキストを維持しつつ
3:50
完全な監査証跡を保存します
3:52
つまりエージェントは進行中の会話を理解し続け
3:55
企業はレビュー可能な記録を永続的に保持できるのです
3:58
一般的なチャットアプリとは異なり
4:00
何も消えてなくなることはありません
4:01
エージェントには継続性を
4:03
ビジネスにはガバナンスをもたらします
4:04
そのログのエントリーはメッセージによって構成されています
4:06
メッセージはプレーンテキストに限定されません
4:09
画像やスプレッドシートファイル
4:10
生成されたコードブロックなどを格納できます
4:12
それぞれにはタイムスタンプが押され
4:14
ユーザーまたはアシスタントという役割ラベルが付与されます
4:16
スレッドを調査すれば何が言われたかだけでなく
4:19
誰がいつどのような形式で言ったのかまで確認できます
4:23
コンプライアンス担当者が記録を開き
4:25
昨日送信された正確なテキストリクエスト
4:27
エージェントが回答として生成したグラフ画像
4:29
そしてその両方の発生時刻を確認する場面を想像してください
4:32
それは単なる記憶ではなく完全で実在する台帳なのです
4:35
ゲーム用語で例えるなら
4:36
スレッドはダンジョンズ&ドラゴンズのキャンペーンにおけるノートブックのようなものです
4:39
ダンジョンマスターは訪れた街
4:40
成功したダイスロール
4:41
手に入れた戦利品をすべて書き留めます
4:43
そのようなログがなければ
4:44
プレイヤーたちは忘れてしまった詳細について言い争うことになります
4:46
ログがあれば出来事が記録されているため議論はすぐに解決します
4:50
企業向けAIにおいてもスレッドは同様の役割を果たします
4:52
すべてが順番に記録されているため
4:53
エージェントが実際に何をしたかについての紛争を防ぐことができます
4:56
ではなぜその記録が重要なのでしょうか
4:58
監査やコンプライアンスにおいてスレッドは非常に価値のあるものです
5:01
規制当局や内部監査チームはスレッドを開くことで
5:03
ユーザーのリクエスト、エージェントの回答、使用されたツール
5:06
そして発生時刻という一連の流れを即座に確認できます
5:08
開発者にとってはその記録はデバッグモードのように機能します
5:11
エージェントが間違ったコードを生成した場合
5:13
スレッドをそのリクエスト時点まで巻き戻して
5:15
なぜそうなったのかを正確に追跡できます
5:17
どちらのグループも可視性が高まり
5:19
時間の浪費を避けられるはずです
5:20
会話を保持しないシステムと対比してみましょう
5:23
スレッドがなければスクリーンショットや
5:25
曖昧な記憶で挙動を追うことになります
5:27
そんな対応ではコンプライアンス担当者から証拠を求められた際や
5:30
サポートがバグを再現したい際には通用しません
5:32
まるでゲームでボス戦をやり直すよう言われたのに
5:34
セーブしていなかったことに気づくようなものです
5:36
記録がなければ証拠はなく追跡できなければ修正もできません
5:40
ダイス目が悪ければ失敗すれば
5:42
口約束だけで関係者を安心させるしかなくなります
5:44
ファウンドリのスレッド機能があればその罠を回避できます
5:47
すべての会話が構造化された証拠となります
5:49
ワークフローが法的な文言を抽出する場合
5:51
記録には元のリクエスト
5:53
生成された特定の回答
5:54
サポートツールの呼び出しの有無が示されます
5:57
複数のエージェントが互いに相談してタスクを分担する場合
6:00
そのやり取りもすべてログに残ります
6:02
企業はコンプライアンスを証明し
6:03
開発者はバグを特定し
6:05
管理者はシステムから出力される結果を信頼できるようになります
6:08
スレッドは混沌としたチャットを本番環境で使えるレベルへと変えてくれるのです
6:12
一時的なやり取りの代わりに
6:13
使命と決定の安定した履歴を作り出し
6:16
信頼できる基盤となります
6:17
ただしログはあくまで日記に過ぎないことを忘れないでください
6:20
真のアクションは
6:21
エージェントがスレッドに書かれた内容を読み取り
6:22
実際に実行に移した時に始まります
6:24
次の段階とは
6:25
ミッションが紙の上のメモからリアルタイムで実際に動くものへと変わる段階のことです
6:28
ラン実行とランステップス実行ステップは
6:30
いわばサイコロを振るようなものです
6:32
ランこそがミッションが最終的に開始される場所です
6:34
ファウンドリの用語では
6:34
スレッドスレッドが会話の履歴指示コンテキストそして広げた地図を保持しています
6:38
ランはエージェントがそのコンテキストを受け取り
6:40
実際に実行に移すためのトリガーとなります
6:42
スレッドは記憶しランは実行します
6:44
ランを打ち上げボタンのようなものと考えてください
6:46
スレッドにはCSVを分析してと書かれているかもしれません
6:49
あるいは折れ線グラフを書くよう指示されているかもしれません
6:51
しかしランはエージェントがモデルの指示とツールを通じてそのリクエストを処理する瞬間なのです
6:55
そこでは外部データの取得数値の計算
6:57
あるいはコードインタープリタの呼び出しによる成果物の生成が行われます
7:00
テーブルトークRPGに例えるなら
7:02
スレッドはパーティーがテーブルを囲んで作戦を練る段階です
7:04
ランは戦闘を開始するためのイニシアチブロールです
7:07
それがなければ何も前に進みません
7:09
ファウンドリが明確にしているのはこの点です
7:11
ランはブラックボックスではありません
7:12
監視されステータスが追跡される実行プロセスです
7:15
通常急入り進行中アクション待ち完了失敗といったステータスを確認できます
7:19
SDKのサンプルではゲームマスターがターンの順序を確認するように
7:22
ループでこれらの状態を頻繁にポーリングします
7:24
これにより何が行われるかだけでなく
7:26
いつ行われるかという可視性が確保されます
7:28
しかしさらに大きな懸念があります
7:30
実行の内部で実際に何が起きたのかどうやって把握すればいいのでしょうか
7:33
回答がまともに見えても詳細がなければ
7:35
エージェントが外部APIを叩いたのかコードを書いたのか
7:37
単に文章をでっち上げたのか判別できません
7:39
そのような不透明さはエンタープライズ環境では危険です
7:42
それはチェスの試合の途中に立ち合い
7:44
正しい手が打たれたから我々を信じてくれと言われるようなものです
7:47
やり直しはできません
7:48
その手がルールに適法だったのかどうかも分かりません
7:50
その推測を排除してくれるのがランステップスです
7:52
すべてのランはステップごとに記録され
7:54
どのモデル出力が生成され
7:55
どのツールが呼び出され
7:56
どの計算が行われ
7:58
どのメッセージが生成されたかが分かります
7:59
これはAIのためのチェスフです
8:01
ポーンをE4へ
8:02
ナイトをF6へのように
8:03
10時2分にファイルを取得し
8:05
10時3分にコードブロックを実行し
8:07
10時4分にグラフを出力するといった記録です
8:09
各アクションは順番に書き留められるため
8:11
後から再現することが可能です
8:12
その構造は開発者にとって大きな安心材料となります
8:14
ランステップスがなければ
8:15
最終的な回答を前にして
8:16
それがどうやって導き出されたのか
8:17
開目検討もつきません
8:18
検索クエリが間違っていたのか
8:20
計算ミスが紛れ込んだのか
8:21
ただ推測するしかありません
8:23
ランステップスがあれば
8:24
タイムラインをスクロールして
8:25
正確なミス箇所を特定し修正できます
8:26
デバッグは当てずっぽうな作業から
8:28
科学的な検証へと変わるのです
8:30
それは誰が攻撃したのか
8:31
完全としない霧の中のボス戦闘
8:33
剣の振りや呪文の栄章すべてが記録された
8:35
戦闘ログとの違いのようなものです
8:36
コンプライアンスチームにとっても
8:37
これは大きな利点となります
8:39
監査担当者にその要約は
8:40
どのように生成されたのかと聞かれたとき
8:42
モデルの推論を抽象的な言葉で説明する必要はありません
8:44
証拠が手元にあるからです
8:46
ツール呼び出し
8:46
インタープリターのステップ
8:47
組み立てられた回答
8:48
これらすべてにタイムスタンプが押されています
8:49
これにより説明は統制へと変わります
8:52
物語を語るのではなく
8:53
証拠を示すことができるのです
8:54
企業がこれを好むのは
8:55
リスクが説明責任に変わり
8:56
約束ではなく証明に基づいた運用ができるからです
8:59
日々の業務においても
9:00
実行ステップは信頼できる再現可能なパターンを作り出します
9:03
ワークフローを再実行する必要がある場合
9:05
同じ手順をなぞるだけです
9:06
結果に疑義が生じても
9:07
それを再現して確認できます
9:09
理想的な状況下では
9:10
実行ステップが完全に記録されていれば
9:11
出力がどのように構築されたかの
9:12
監査可能かつ再現性のある証拠が得られます
9:14
他のシステムで最悪の結果が生じた場合
9:15
手元に残るのは足跡のない不確かな出力だけでしょう
9:17
だからこそ
9:18
エージェントのライフサイクルのこの部分が重要なのです
9:20
スレッドという日記
9:21
実行というアクティベーション
9:22
そして実行ステップという
9:23
一挙手一投足のログが存在します
9:25
これらが揃うことで
9:26
即興的なAIは
9:27
行動を追跡
9:28
テスト擁護できる
9:28
責任あるチームメイトへと変わるのです
9:30
もちろん
9:30
これだけの詳細が存在することを知っているだけでは
9:32
パズルのピースは揃いません
9:33
それらと対話するための手段
9:34
つまり性のAPI呼び出しに溺れることなく
9:36
エージェントを起動し
9:37
実行をトリガーし
9:38
ステップを読み戻すための構造化された方法が必要です
9:40
驚くべきことに
9:41
それを行うために派手なコマンドデッキは必要ありません
9:43
ほとんどの人が使用するコンソールは
9:45
馴染み深く
9:45
堅牢で少し地味なもの
9:47
そう
9:47
ネット
9:48
アーセナル
9:48
そしてアライアンスです
9:49
アーセナル
9:50
ブキコ
9:50
とアライアンス
10:00
ドキュメントの確認方法や計算手順を説明するだけでなく
10:03
エージェントが実際にそれを実行し
10:05
出力結果を返せるようになるのです
10:06
この違いこそが
10:07
単なるデモで終わらず
10:08
実際の企業現場でプラットフォームを価値あるものにする理由です
10:11
ファウンドリは
10:12
3つの明確な能力カテゴリーを提供します
10:14
1つ目は
10:15
組込みツールです
10:16
これには
10:16
コードインタープリター
10:17
リング検索
10:18
シェアポイントおよびマイクロソフトファブリックコネクタ
10:21
Azure iSearchなどが含まれます
10:22
これらを使えば
10:30
回答を超えて
10:31
検証や再利用が可能な具体的な成果物へと範囲を広げます
10:34
次に
10:34
マイクロソフトが提供するものだけに縛られることはありません
10:37
ファウンドリでは
10:38
オープンAPI仕様やモデルコンテキストプロトコル
10:40
MCPを通じてカスタムツールを登録できます
10:42
特にMCPは
10:43
AIツールのUSB-Cのように扱われるため重要です
10:46
エージェントをリモートのMCPサーバーに接続するたびに
10:49
ラッパーを手書きする必要はなく
10:50
システムがツールの検出
10:52
バージョン管理
10:53
呼び出しを自動的に処理します
10:54
これにより
10:55
統合のオーバーヘッドが大幅に軽減されます
10:57
特に
10:58
数十ものシステムを連携させる必要がある環境では大きなメリットです
11:00
3つ目に
11:01
ファウンドリでのすべてのツール呼び出しは
11:02
過観測
11:03
オブザーバブルです
11:03
呼び出しはステップ単位で
11:04
ID
11:05
入力
11:05
出力
11:06
タイムスタンプと共にログに記録されます
11:07
つまり
11:07
運用担当者から見て
11:08
これらのエージェントは
11:09
信じて任せる魔法ではありません
11:10
台帳そのものです
11:12
何を呼び出したかを正確に監視し
11:13
適切な権限に従っていることを確認し
11:15
コンプライアンスのために
11:15
高級的な記録を残すことができます
11:17
これらのカテゴリーを具体的に理解するために
11:18
クイックスタートのデモを思い浮かべてください
11:20
CSVファイルをメッセージとしてスレッドにアップロードします
11:22
エージェントが実行ステップ内で
11:23
コードインタープリターツールを呼び出し
11:25
ファイルを処理してグラフを生成します
11:26
その成果物は画像として返され
11:28
スレッドログ内で直接確認できます
11:30
パーサーや可視化ツールを
11:31
自分で書く必要はありません
11:33
指示を出すだけで
11:34
エージェントがツールを選択し
11:35
実行し
11:36
レポートに貼り付けられるファイルを返してくれます
11:38
これは理論ではなく
11:39
SDKサンプルで文書化されている動作です
11:42
これが進化を発揮するのは
11:43
エンタープライズ統合の場面です
11:45
ツールをロジックアップスにリンクできるため
11:47
エージェントは1400以上の既存の
11:48
SaaSおよびオンプレミスのコネクタにアクセス可能です
11:51
CRM、ERP、ITSMプラットフォーム向けの
11:53
アダプターを再コーディングする代わりに
11:54
ビジネスですでに稼働している
11:56
コネクタに対して設定を行うだけです
11:57
これはスケールのための戦略です
11:59
壊れやすいAPIブリッジを書くことなく
12:01
一つのエージェントが
12:02
広範な環境全体で安全に動作できます
12:04
次に誰もが尋ねるのはセキュリティについてです
12:06
ファウンドリはそれを中核で解決しています
12:08
ツールがシェアポイントや
12:09
ファブリックのような企業システムに接続する際
12:11
マイクロソフトエントラを介したオンビハーフ
12:14
代理、認証を使用します
12:15
機能ファイルを読み取る権限がなかった場合
12:17
今日エージェントが魔法のように
12:18
その壁を突破することはありません
12:20
IDと権限は維持されます
12:21
これこそがコンプライアンスチームが
12:23
承認を与える唯一の方法です
12:24
全ての呼び出しは追跡可能です
12:26
誰が呼び出したのか
12:27
何が送信されたのか
12:28
何が受信されたのか
12:29
そのためチームは常に証跡を保持できます
12:30
最高の成果が出せれば
12:31
このツールキット一式は
12:32
エージェント部隊を単なる目新しさ以上の存在に変えてくれます
12:35
実際のデータを紹介し処理し
12:36
IT部門が慣れ親しんだガードレール内で
12:38
行動できるユニットが手に入ります
12:39
こうした選択肢がなければ
12:40
大口を叩くだけで実作業はこなせない
12:42
単なるチャットセッションで終わってしまうでしょう
12:43
だからこそ
12:44
部隊のリーダーと同じくらい
12:45
装備する武器が重要なのです
12:47
モデルと指示がエージェントの思考を支えるとしても
12:49
ツールが責任を持って接続され
12:50
確実に記録されていなければ
12:51
それは中途半端な対策にすぎません
12:53
ファウンドリの組み込みセット
12:54
MCP
12:55
オープンAPIの拡張性
12:56
そしてエンタープライズグレードのセキュリティがあれば
12:58
推測によるプロンプトの寄せ集めではなく
13:00
規律ある力を構築できます
13:01
さてここからが全体像の話です
13:04
ファウンドリのエージェントは
13:05
気まぐれな相棒や遊び道具として作られたものではありません
13:07
構造を持ち負荷が考慮され
13:09
本番環境で役立つ装備を備えた
13:11
管理されたオペレーターとして設計されています
13:13
キャンペーンはここで締めくくりとなります
13:14
結論の時間です
13:16
ファウンドリは
13:16
モデルにプロンプトを投げるだけのものではありません
13:18
NO
13:18
ルールブック
13:19
ツールキットを備えたエージェントを構築するための
13:21
再現性のある方法を提供します
13:22
そして彼らが行う全ての動作は
13:24
スレッド、実行、実行ステップに記録されます
13:26
開発リードにとっても
13:27
コンプライアンス担当者にとっても
13:28
結論はシンプルです
13:29
ネットのようなSDKによる再現可能で
13:32
監査可能な実行により
13:33
ライフサイクル全体を完全に制御・可視化できます
13:35
次のステップとして
13:36
テストプロジェクトを立ち上げ
13:37
基本エージェントを作成し
13:38
スレッドを実行して
13:39
SDKまたはポータルで実行ステップを確認してください
13:42
それによって
13:42
ログが実際のストーリーと一致していることを確認できます
13:44
もしこれがデプロイでクリティカルヒットを出す助けになったなら
13:47
チャンネル登録と通知設定をお願いします
13:48
あるいはまた別のクラスターを制御できたなら
13:51
艦隊の隊列を維持するために登録してください