Azure AI Foundryでエージェントを使っているチームにとって、今回の「Public Preview: Toolbox connectors and triggers in Microsoft Foundry」の要点は、AIエージェントを“手動で呼び出すもの”から、“外部サービスとつながり、時刻やスケジュールで動くもの”へ近づける更新です。これまでAzure Functions、Logic Apps、キュー、独自の認証処理などで補っていた起動・連携まわりを、Foundryプロジェクト内で扱いやすくする方向の機能と考えると分かりやすいです。
ただし、これはパブリックプレビューです。すぐ本番の中核処理に置き換えるより、まずは日次レポート、定期チェック、チケット作成、社内通知など、影響範囲を限定しやすい業務から検証するのが現実的です。Microsoftの公式情報では、プレビュー機能はSLAなしで提供され、本番ワークロードには推奨されないとされています。(Microsoft Learn)
Azure AI FoundryのToolbox connectors and triggersで何が変わるのか
今回の更新では、Microsoft FoundryのToolboxにコネクタと時間ベースのトリガーが追加され、エンタープライズ開発者や自動化担当者が、イベント駆動に近いAIエージェントを構築しやすくなります。Azure Updatesでは、この機能は2026年6月2日 UTCに公開されており、日本時間では2026年6月3日に確認される更新です。(マイクロソフトアジュール)
これまでFoundryエージェントを業務システムに組み込む場合、典型的にはアプリケーションからAPIで呼び出す、ポータルやプレイグラウンドから実行する、または外部の自動化基盤を使って起動する必要がありました。今回のプレビューにより、Foundry内のToolboxやRoutinesを使って、外部サービスとの接続や定期実行をよりFoundryプロジェクトに近い場所で管理できるようになります。
実務上の変化は、次の3点です。
| 変更点 | これまでの典型例 | 今回のプレビューで期待できること |
|---|---|---|
| 外部サービス連携 | GitHub、Slack、Box、業務DBなどとの接続を個別に実装 | Foundry Tools Catalogのコネクタを使い、管理されたMCPサーバー経由で操作を公開 |
| エージェント起動 | API呼び出し、手動実行、外部スケジューラー | Routinesでタイマーまたは繰り返しスケジュールからエージェントを起動 |
| 運用管理 | Logic Apps、Azure Functions、キュー、認証コード、ログを個別管理 | トリガー、アクション、権限、接続、実行履歴をFoundryプロジェクト側で扱いやすくする |
ポイントは、複雑な業務ワークフロー全体を置き換える機能ではなく、軽量なエージェント自動化をFoundry側に寄せる機能だということです。MicrosoftのRoutinesドキュメントでも、分岐、複数エージェント、人間の承認、複雑な状態管理が必要な場合はワークフローを使うべきと説明されています。(Microsoft Learn)
コネクタは何を可能にするのか
コネクタは、エージェントが外部サービスに対してアクションを実行するための入口です。Microsoft Learnでは、Foundry Tools CatalogがSaaS、データ、業務システム向けの1,000以上の事前構築済みコネクタを提供し、コネクタをエージェントに追加するとFoundryが管理されたMCPサーバーを作成すると説明されています。(Microsoft Learn)
たとえば、次のような用途が考えられます。
| 活用シーン | エージェントに任せたい処理 | 注意点 |
|---|---|---|
| 開発チームのIssue管理 | GitHub Issueの作成、更新、分類 | 書き込み権限を必要最小限にする |
| サポート業務 | 問い合わせ内容を要約し、チケットへ登録 | 個人情報や機密情報の取り扱いを確認 |
| 社内ナレッジ運用 | ConfluenceやBox上の情報を参照し、回答や更新を支援 | 参照範囲とデータ所在地を確認 |
| 営業・業務部門 | CRMや業務システムへの記録作成 | 誤登録時の取り消し手順を用意 |
コネクタ追加の基本的な流れは、FoundryポータルでTools Catalogから対象コネクタを探し、接続先に認証し、エージェントに公開するアクションを選び、ツールとして追加するというものです。Microsoft Learnでは、Browse、Connect、Select actions、Add toolの4ステップとして整理されています。(Microsoft Learn)
ここで重要なのは、コネクタ全体を丸ごとエージェントに渡さないことです。たとえばGitHub連携なら、最初からリポジトリ削除や権限変更のような強い操作を渡すのではなく、「Issueを作成する」「Issueを検索する」など、業務上必要なアクションだけを選ぶべきです。Microsoft Learnでも、必要なアクションだけを選ぶことで、意図しない操作のリスクを下げ、モデルが利用可能なツールを判断しやすくなると説明されています。(Microsoft Learn)
トリガーは何を可能にするのか
トリガーに関しては、Foundry Agent ServiceのRoutinesが中心になります。Routinesは、定義したトリガーが発火したときにエージェントを自動実行する仕組みです。公式ドキュメントでは、「特定の時刻またはスケジュールが来たら、このエージェントを呼び出す」と表現されています。(Microsoft Learn)
プレビュー時点でサポートされるトリガーは、主に次の2種類です。
| トリガー種別 | 用途 | 具体例 |
|---|---|---|
| Timer | 指定した日時に1回だけ実行 | 移行判定レポートを指定日時に作成する |
| Recurring | cron形式に近い繰り返しスケジュールで実行 | 毎営業日朝にサポート状況を要約する |
Routinesの構成要素はシンプルです。1つのRoutineには、1つのトリガーと1つのアクションがあります。プレビューでは、アクションは1つのPrompt AgentまたはHosted Agentを既存のエージェントエンドポイント経由で呼び出す形式です。(Microsoft Learn)
つまり、Routinesは「小さく、明確な定期実行」に向いています。
向いている例は、次のようなものです。
- 毎朝7時に前日の問い合わせを要約する
- 毎週月曜に未対応Issueを分類する
- 毎日決まった時刻に異常傾向を確認して通知文案を作る
- 一度だけ、移行前チェックを指定日時に実行する
一方で、次のような用途ではRoutinesだけに寄せないほうが安全です。
- 承認者の判断によって処理を分岐する
- 複数のエージェントを順番に呼び出す
- 失敗時に複雑な補償処理を行う
- 長時間の状態管理が必要
- 会計、契約、顧客通知など、誤実行の影響が大きい処理
この場合は、既存のLogic Apps、Power Automate、Azure Functions、ワークフロー基盤と組み合わせる設計を検討してください。
対象者ごとの影響範囲
この更新の影響は、開発者だけに閉じません。特に企業利用では、管理者、セキュリティ担当、業務部門の責任分界を先に決めておく必要があります。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| Azure AI Foundry開発者 | エージェントから外部サービスを操作しやすくなる | どのアクションをツールとして公開するか |
| 自動化エンジニア | 定期実行や軽量な自動起動をFoundry側で設計できる | 既存のLogic AppsやFunctionsとどこで役割分担するか |
| IT管理者 | プロジェクト単位の権限、接続、実行履歴管理が重要になる | RBAC、プロジェクト、接続リソースの管理方針 |
| セキュリティ担当 | 外部サービス、MCP、認証情報、データ流出リスクの確認が必要 | コネクタの発行元、データ所在地、権限範囲 |
| 業務部門 | AIエージェントによる定型処理を導入しやすくなる | 誤実行時の確認・取り消し・責任範囲 |
特に注意したいのは、Foundry Tools CatalogにはMicrosoft製、検証済みサードパーティ、独立系パブリッシャーのコネクタが含まれる点です。Microsoft Learnでは、コネクタ詳細ページの発行元を確認し、外部サービスへ送られるデータや保持・所在地の扱いを確認するよう説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者は、機能を試す前に「使えるか」よりも「安全に止められるか」「権限を絞れるか」を確認してください。AIエージェントは自然文で柔軟に動くため、コネクタ操作の範囲が広すぎると、想定外のアクションを実行するリスクが高まります。
プロジェクトとリージョン
管理されたMCPサーバーは、作成されたFoundryプロジェクトにスコープされます。公式ドキュメントでは、サポート対象リージョンとしてjapaneastを含む複数リージョンが列挙されています。日本リージョンで検証したい場合は、対象のFoundryプロジェクトが対応リージョンにあるかを確認してください。(Microsoft Learn)
ただし、リージョン対応はプレビュー期間中に変わる可能性があります。公開前提の記事や社内手順書にする場合は、「2026年6月時点」などの表記を付け、最新のMicrosoft Learnで確認する運用にしておくと安全です。
RBACと役割
コネクタを追加・管理するユーザーには、Foundryプロジェクト上の適切な権限が必要です。Microsoft Learnでは前提条件として、アクティブなMicrosoft Foundryプロジェクト、Foundry Project Managerロール、接続先サービスの資格情報が示されています。(Microsoft Learn)
管理者は、少なくとも次を分けて考えるべきです。
| 権限 | 付与対象の例 | 注意点 |
|---|---|---|
| プロジェクト管理 | プラットフォーム担当、リード開発者 | コネクタ作成・変更の責任を明確にする |
| コネクタ利用 | エージェント実行者、アプリケーション | 接続先の権限と合わせて最小化する |
| 実行履歴閲覧 | 運用担当、監査担当 | 入出力に機密情報が含まれる可能性を考慮 |
| 接続先サービスの権限 | GitHub、Box、Slackなどのサービスアカウント | 個人アカウント依存を避ける |
認証情報とシークレット
Routineの入力やプロンプトに、APIキー、個人アクセストークン、パスワードなどを直接書かないでください。Microsoft Learnでも、Routineの入力やプロンプトにシークレットや認証情報を含めず、可能な場合はプロジェクト接続やMicrosoft Entra IDベースのアクセスを使うよう注意されています。(Microsoft Learn)
ありがちな失敗は、「検証だから」と個人のOAuth接続や個人アクセストークンで始め、そのまま部門利用に広がるケースです。後から権限棚卸しが難しくなるため、初期検証の段階からサービスアカウント、管理対象ID、接続名の命名規則を決めておくのが理想です。
開発者が確認すべき実装ポイント
開発者は、AIエージェントに「何をさせるか」だけでなく、「何をさせないか」を設計する必要があります。
公開するアクションを最小化する
コネクタを追加するときは、利用可能なアクションをすべて選ぶのではなく、業務シナリオに必要なものだけを選びます。
たとえば、問い合わせ管理エージェントなら次のように絞ります。
| やりたいこと | 許可するアクション | 最初は避けたいアクション |
|---|---|---|
| 問い合わせ内容からIssueを作る | Issue作成、ラベル取得 | リポジトリ設定変更、ユーザー権限変更 |
| ナレッジを参照する | ファイル検索、メタデータ取得 | ファイル削除、共有設定変更 |
| 通知文案を送る | 下書き作成、指定チャンネルへの投稿 | 全社チャンネル投稿、外部共有 |
最初から書き込み操作を多く渡すと、検証で問題が出たときに原因を追いにくくなります。まずは読み取り専用、次に下書き作成、最後に本送信や更新という順で拡張すると、運用チームも承認しやすくなります。
Routineの入力を固定しすぎない
Routineでは、エージェントに渡す入力をテキストまたはJSONで設定できます。定期実行では入力が固定化されやすいため、日付範囲、対象システム、出力形式、失敗時の扱いを明示しておくと安定します。
悪い例は次のような入力です。
昨日の状況をまとめてこれでは「昨日」がどのタイムゾーンか、どのシステムを見るのか、どの形式で出すのかが曖昧です。
改善例は次のようにします。
{
"task": "support_daily_summary",
"timezone": "Asia/Tokyo",
"target_period": "previous_business_day",
"sources": ["support_tickets", "github_issues"],
"output": {
"format": "markdown",
"sections": ["件数", "未対応", "重大インシデント候補", "翌営業日の優先対応"]
},
"safety": {
"do_not_send_external_notifications": true,
"create_draft_only": true
}
}JSON化すると、実行履歴を見たときに「何を意図して実行したか」が追いやすくなります。特に複数人で運用する場合は、自然文だけでなく構造化入力を使う価値があります。
実行履歴とトレースを前提に設計する
Routinesは実行履歴を記録し、入力、出力、ステータス、関連するエージェント応答やトレース詳細へのリンクを確認できると説明されています。(Microsoft Learn)
そのため、検証時点から次の観点でログを確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| トリガー発火 | 予定時刻に実行されたか、タイムゾーンの認識にズレがないか |
| 入力 | 想定したJSONやテキストが渡されているか |
| ツール呼び出し | 不要なコネクタアクションを呼んでいないか |
| 出力 | 業務で使える粒度か、曖昧な判断を断定していないか |
| 失敗時 | リトライ、通知、手動復旧の判断材料が残っているか |
特にツール呼び出しは、プロンプトだけを見ても問題が分からないことがあります。どのツールを、どのパラメータで呼んだかを確認できる運用にしておくことが重要です。
移行時の考え方：既存のLogic AppsやAzure Functionsはすぐ捨てない
今回の機能は便利ですが、既存の自動化基盤をすぐ全面移行する必要はありません。むしろ、最初は「Foundryに寄せる部分」と「既存基盤に残す部分」を分けるほうが安全です。
| 処理 | Foundry Routinesに向く | 既存ワークフローに残すべき |
|---|---|---|
| 毎朝の要約 | 向いている | 重要通知の最終送信は人間承認にする |
| 一度きりのチェック | 向いている | チェック後の複雑な修復処理は別基盤 |
| 複数システム更新 | 条件付きで検証 | トランザクション性が必要なら慎重に設計 |
| 承認フロー | 単体では不向き | Logic Apps、Power Automate、業務ワークフロー |
| 複数エージェント連携 | 単体では不向き | ワークフローやオーケストレーション基盤 |
移行の進め方は、次の順番がおすすめです。
| フェーズ | 作業内容 | 成功条件 |
|---|---|---|
| 棚卸し | 既存の定期実行、Webhook、Functions、Logic Appsを一覧化 | 何がエージェント起動だけの処理か分かる |
| 候補選定 | 低リスクで読み取り中心の処理を選ぶ | 誤実行しても業務影響が小さい |
| 並行稼働 | 既存処理を残したままRoutineを試す | 出力品質と実行安定性を比較できる |
| 権限縮小 | コネクタのアクションと接続権限を絞る | 不要な書き込み権限がない |
| 段階展開 | 部門、対象業務、実行頻度を少しずつ拡大 | 監視・停止・復旧手順がある |
特に本番移行では、「エージェントが正しい回答をしたか」だけでなく、「間違ったときに止められるか」「どの接続を使ったか追えるか」「権限を取り消せるか」を合格条件に入れてください。
展開前チェックリスト
プレビュー機能を組織で試す場合は、以下のチェックリストを使うと抜け漏れを減らせます。
| 確認項目 | チェック内容 |
|---|---|
| プレビュー利用の承認 | SLAなし、本番非推奨であることを関係者が理解している |
| リージョン | 対象プロジェクトのリージョンが対応範囲に含まれる |
| RBAC | Foundry Project Managerなど必要最小限の権限に整理している |
| コネクタ発行元 | Microsoft、検証済みサードパーティ、独立系のどれか確認した |
| データ境界 | 外部サービスに渡るデータ、保持場所、規約を確認した |
| アクション範囲 | エージェントに公開する操作を最小限にした |
| 認証 | 個人トークンやプロンプト内シークレットに依存していない |
| Routine設計 | TimerかRecurringか、実行時刻とタイムゾーンを明確にした |
| 監視 | 実行履歴、トレース、失敗時の確認担当を決めた |
| 停止手順 | Routineの無効化、接続の取り消し、権限削除の手順がある |
このチェックリストで1つでも曖昧な項目がある場合は、書き込み系のコネクタ操作を許可する前に設計を見直したほうがよいです。
導入に向くケース、まだ慎重にすべきケース
導入に向くケース
今回のプレビューは、次のようなケースに向いています。
- 日次・週次で同じ確認を行う
- エージェントの出力をまず人間が確認する
- 読み取り中心、または下書き作成中心の処理
- 既存の手動作業を短縮したい
- 外部サービス連携の試作を素早く行いたい
- 実行履歴やトレースを見ながら改善したい
具体例としては、「毎朝、前日のサポートチケットを分類してMarkdownで要約する」「毎週、GitHub Issueの停滞状況を集計して対応優先度を提案する」「指定日時に移行前チェックを実行し、リスク項目を一覧化する」といった用途が現実的です。
まだ慎重にすべきケース
反対に、次のケースでは慎重に進めるべきです。
- エージェントが外部顧客へ直接通知する
- 契約、請求、権限変更など重大な操作を行う
- 複数システムの更新結果に整合性が必要
- 人間の承認や例外処理が多い
- データ所在地や規制要件が厳しい
- 失敗時のリカバリー手順が未整備
このような業務では、Foundry Routinesを「起点」や「補助」に使い、最終的な承認や状態管理はワークフロー基盤に残す構成が安全です。
よくある疑問
Azure AI FoundryとMicrosoft Foundryは同じものですか？
公式ドキュメント上では、Azure AI StudioやAzure AI Foundryの文脈がMicrosoft Foundryへ整理されています。Microsoft Learnでは、従来のAzure AI Studio / Azure AI Foundryが現在のMicrosoft Foundryに対応する形で説明されています。(Microsoft Learn)
日本語の検索では「Azure AI Foundry」で探す読者も多いため、記事や社内資料では「Azure AI Foundry（Microsoft Foundry）」のように併記すると混乱を避けやすくなります。
コネクタのトリガーも使えるのですか？
注意が必要です。Managed MCP serverのドキュメントでは、コネクタトリガーはサポートされず、エージェントが呼び出せるアクションのみ利用できると説明されています。(Microsoft Learn)
つまり、「外部サービスのイベントを直接受けて起動するWebhook型のコネクタトリガー」と、「Foundry Routinesによる時間ベースの起動」は分けて考える必要があります。今回のプレビューでまず整理すべきなのは、コネクタは外部サービスへのアクション、Routinesは時間ベースのエージェント起動という役割分担です。
既存のワークフロー基盤は不要になりますか？
不要にはなりません。Routinesは軽量な自動化向けです。複数ステップ、分岐、承認、複数エージェント、複雑な状態管理が必要な場合は、ワークフローを使うべきと公式ドキュメントでも説明されています。(Microsoft Learn)
本番利用してよいですか？
プレビュー機能のため、少なくとも重要な本番ワークロードへ直ちに適用するのは避けるべきです。Microsoft Learnでは、プレビューはSLAなしで提供され、本番ワークロードには推奨されないと明記されています。(Microsoft Learn)
まずは、読み取り中心、下書き作成、社内向けの要約、手動確認を挟める処理から始めてください。
まず取るべき次の行動
今回の「Public Preview: Toolbox connectors and triggers in Microsoft Foundry」は、Azure AI Foundryでエージェントを業務に組み込むうえで、外部連携と定期実行をFoundryプロジェクト側に寄せる重要な一歩です。
最初にやるべきことは、既存の自動化をすべて置き換えることではありません。まずは、日次要約や定期チェックのような低リスク業務を1つ選び、対応リージョン、RBAC、コネクタ発行元、公開アクション、Routineの実行履歴を確認してください。
検証で見るべき成功条件は、「エージェントが動いたか」ではなく、必要な権限だけで動くか、誤実行を防げるか、履歴から原因を追えるか、止めたいときに止められるかです。ここまで確認できれば、Azure AI Foundryのエージェント自動化を、より安全に次の業務へ広げられます。
コメント