Azure AI Foundry のスレッド：AIをエンタープライズ対応にし、監査可能にする方法

Azure AI Foundry にAIをデプロイするとき、行っているのは巨大なモデルを立ち上げることだけではありません。管理されたランタイムにエージェントを配置すると、メッセージ、ツール呼び出し、実行ステップといった関連アクションがすべてログに記録され、追跡できるようになります。これによりAIは、制御不能な存在から、管理可能で規律あるシステムへと変わります。

この記事では、エンタープライズ対応と監査可能性を支える仕組みを整理します。エージェントの基本設計である「モデル・指示・ツール」から、「スレッド」「ラン」「ランステップ」という記録の構造、ツール連携とセキュリティまでを順に見ていきます。

Azure AI Foundry のエージェントを構成する3つの要素

Foundry でエージェントをセットアップすることは、単にチャットウィンドウを開くことではありません。明確な設計に基づいてミッションを遂行する「現場の隊長」を任命するようなものです。その設計は、次の3つの要素に集約されます。

• モデル:推論と言語を担う頭脳です。人間の言葉を解析し、ステップを計画し、応答を起案します。
• 指示:ミッションの命令にあたります。エージェントが勝手な方向にそれるのを防ぎ、本当に必要な成果につなぎ止めます。
• ツール:エージェントの装備です。コード実行、検索コネクタ、レポート用API、接続するサードパーティシステムなどが含まれます。

Azure AIエージェントはこの3要素から明確に構築されており、これがなければ再現性も観察性も得られません。残るのは、証拠のないテキスト生成だけです。

隊長にたとえると分かりやすい

モデルは隊長の戦闘訓練、指示はミッションのブリーフィング、ツールは専門的な装備です。ブリーフィングの内容は「契約セットからデータを抽出せよ」「結果を特定のフォーマットで報告せよ」といったものです。これが方針を統一し、予測可能な行動を可能にします。コードインタープリターは分析を実行する道具、SharePoint やカスタムのMCPコネクタはライブデータを計画に送り込む無線機にあたります。

3つが揃ったエージェントは即興では動かず、ログとチェックポイントを伴ってミッションを遂行します。

モデルは自由に切り替えられる

多くのチャットAPIで得られるのは、モデルとプロンプトだけです。命令やツールオーケストレーションという正式な概念はありません。Foundry のエージェントサービスは、3つの層がすべて揃うことを保証します。しかも、ひとつのモデルに縛られることもありません。Foundry カタログ内のモデルを自由に切り替えられます。

• 複雑な戦略には GPT-4
• 軽量なタスクにはより小型のモデル
• Mistral や DeepSeek の導入も可能

ミッションに合わせて選べる柔軟性が、画一的な存在と適応力のある司令官との違いです。

層が欠けると何が起きるのか:企業にとってのリスク

指示やツールといった層が欠けていると、まず出力が一貫性を失います。同じ契約書の要約でも、毎回違う内容になりかねません。そうなるとデバッグは当てずっぽうの作業になります。

これは企業にとって些細な問題ではありません。信頼と導入を阻む現実的なリスクです。

Foundry はこの問題に直接対処します。

• ガードレールがエージェントに組み込まれている
• 指示は必ず守るべき普遍のルールブックとして機能する
• ツールセットは、ユースケースに応じて厳密に制限することも拡張することもできる
• モデルは入れ替え可能だが、常に説明責任を強制する構造の中で動く

その結果、規律ある振る舞い、予測可能な出力、可視化された手順、エンタープライズコネクタやカスタムAPIによる責任ある拡張が得られます。AIを魔法の会話術として売り込むのではなく、ログを記録し、命令に従い、適切な装備を備えたチームメイトを組織に迎えるという考え方です。

スレッド:監査証跡の土台となる永続的な会話記録

優れた隊長は、あらゆるミッションの記録を慎重に残します。システム監査や実行の失敗時に、その記録が必要になるからです。Foundry でその記録にあたるのがスレッドです。

スレッドは、閉じた瞬間に消えるチャットウィンドウではありません。持続可能な会話セッションです。ユーザーからの発言も、エージェントからの発言も、マルチエージェント環境における別のエージェントからの発言も、すべてここに保存されます。

モデルの制限を保ちつつ、記録は残す

スレッドは単なる静的な記録ではなく、自動的に切り捨て処理を行う構造化コンテナです。モデルの制限内でアクティブなコンテキストを維持しながら、完全な監査証跡を保存します。エージェントは進行中の会話を理解し続け、企業はレビュー可能な記録を永続的に保持できます。エージェントには継続性を、ビジネスにはガバナンスをもたらす仕組みです。

メッセージの中身

スレッドのエントリーはメッセージで構成されます。プレーンテキストに限らず、画像、スプレッドシートファイル、生成されたコードブロックも格納できます。各メッセージにはタイムスタンプと、ユーザーまたはアシスタントという役割ラベルが付きます。何が言われたかだけでなく、誰が、いつ、どのような形式で言ったのかまで確認できます。

たとえばコンプライアンス担当者は、昨日送信されたテキストのリクエスト、エージェントが回答として生成したグラフ画像、その両方の発生時刻を記録から確認できます。

なぜこの記録が重要なのか

• 監査・コンプライアンス:規制当局や内部監査チームは、ユーザーのリクエスト、エージェントの回答、使用されたツール、発生時刻の流れを即座に確認できます。
• 開発者:エージェントが誤ったコードを生成した場合、スレッドをそのリクエスト時点まで巻き戻し、原因を正確に追跡できます。
• マルチエージェント:複数のエージェントが相談してタスクを分担した場合も、そのやり取りがすべてログに残ります。

会話を保持しないシステムでは、スクリーンショットや曖昧な記憶に頼ることになります。証拠を求められたときも、バグを再現したいときも、それでは通用しません。記録がなければ証拠はなく、追跡できなければ修正もできません。

ラン:スレッドの内容を実際の実行に変える

ログはあくまで日記にすぎません。本当のアクションは、エージェントがスレッドの内容を読み取り、実行に移したときに始まります。

スレッドは会話の履歴、指示、コンテキストを保持しています。ランは、エージェントがそのコンテキストを受け取って実行に移すためのトリガーです。つまり、スレッドは記憶し、ランは実行します。スレッドに「CSVを分析して」「折れ線グラフを描いて」と書かれていても、実際にモデルの指示とツールを通じて処理するのはランの役目です。外部データの取得、数値の計算、コードインタープリターの呼び出しによる成果物の生成が、ここで行われます。

ランはブラックボックスではない

ランは、監視され、ステータスが追跡される実行プロセスです。通常、キュー待ち、進行中、アクション待ち、完了、失敗といった状態を確認できます。SDKのサンプルでは、ループでこれらの状態を繰り返しポーリングします。これにより、何が行われるかだけでなく、いつ行われるかも把握できます。

ランステップ:AIの一挙手一投足を残す実行ログ

ランのステータスが分かっても、内部で実際に何が起きたかまでは分かりません。回答がまともに見えても、外部APIを呼んだのか、コードを書いたのか、文章をでっち上げただけなのか、判別できないのです。この不透明さはエンタープライズ環境では危険です。

この問題を解消するのがランステップです。すべてのランはステップごとに記録され、次の点が分かります。

• どのモデル出力が生成されたか
• どのツールが呼び出されたか
• どの計算が行われたか
• どのメッセージが生成されたか

チェスの棋譜のように、「ファイルを取得」「コードブロックを実行」「グラフを出力」といった行動が時刻とともに順番に書き留められます。そのため、後から再現できます。

開発者にとっての価値

ランステップがなければ、最終的な回答を前にしても、どう導かれたのか見当がつきません。検索クエリが間違っていたのか、計算ミスが紛れ込んだのか、推測するしかありません。ランステップがあればタイムラインをたどって誤りの箇所を特定し、修正できます。デバッグは当てずっぽうの作業から、科学的な検証へと変わります。

コンプライアンスにとっての価値

「この要約はどのように生成されたのか」と監査担当者に問われたとき、モデルの推論を抽象的な言葉で説明する必要はありません。ツール呼び出し、インタープリターのステップ、組み立てられた回答が、タイムスタンプ付きで手元にあるからです。説明が統制に変わり、物語ではなく証拠を示せます。ワークフローを再実行する場合も、同じ手順をなぞるだけです。結果に疑義が生じても、再現して確認できます。

ツールとセキュリティ:実務で使えるエージェントにする

スレッド、ラン、ランステップを操作するには、SDKによる構造化された方法があります。個々のAPI呼び出しに溺れることなく、エージェントを起動し、実行をトリガーし、ステップを読み戻せます。ドキュメントの確認方法や計算手順を説明するだけでなく、エージェントが実際に実行して結果を返せる点が、デモで終わらず企業現場で価値を持つ理由です。

3つの能力カテゴリー

1. 組み込みツール:コードインタープリター、SharePoint や Microsoft Fabric のコネクタなど。回答にとどまらず、検証や再利用が可能な成果物まで範囲を広げます。
2. カスタムツール:OpenAPI仕様やモデルコンテキストプロトコル(MCP)を通じて登録できます。MCPはAIツールのUSB-Cのような存在で、リモートのMCPサーバーに接続しても、ラッパーを手書きする必要はありません。ツールの検出、バージョン管理、呼び出しはシステムが自動で処理するため、数十のシステムを連携させる環境ほど統合の負担が軽くなります。
3. 観測可能な呼び出し:すべてのツール呼び出しは、ステップ単位でID、入力、出力、タイムスタンプとともに記録されます。運用担当者にとってエージェントは「信じて任せる魔法」ではなく、台帳のようなものです。

CSV分析の流れ

クイックスタートのデモでは、CSVファイルをメッセージとしてスレッドにアップロードします。エージェントは実行ステップ内でコードインタープリターを呼び出し、ファイルを処理してグラフを生成します。成果物は画像として返され、スレッドログ内で直接確認できます。パーサーや可視化ツールを自作する必要はなく、指示を出せば、エージェントがツールを選んで実行し、レポートに貼り付けられるファイルを返します。これはSDKサンプルで文書化されている動作です。

既存システムとの統合と権限管理

ツールを Logic Apps にリンクすれば、エージェントは1400以上のSaaSおよびオンプレミスのコネクタにアクセスできます。CRM、ERP、ITSMプラットフォーム向けのアダプターを書き直す代わりに、ビジネスですでに稼働しているコネクタに設定を行うだけで済みます。

セキュリティ面では、SharePoint や Fabric のような企業システムに接続する際、Microsoft Entra を介した On-Behalf-Of(代理)認証を使います。ファイルを読む権限がなければ、エージェントがその壁を突破することはありません。IDと権限は維持され、誰が呼び出し、何を送信し、何を受信したのかも追跡できます。これがコンプライアンスチームの承認を得るための条件になります。

実践のためのポイント

• エージェントは「モデル・指示・ツール」の3要素で設計する。どれが欠けても再現性と観察性は失われる。
• モデルはタスクに合わせて Foundry カタログから選び、指示をルールブックとして明確に書く。
• スレッドを永続的な会話記録として活用し、リクエスト、回答、使用ツール、時刻を監査に備えて残す。
• ランのステータスを監視し、ランステップで何がどの順に行われたかを確認する。
• ツールはユースケースに応じて制限・拡張し、MCPやOpenAPI、既存コネクタで統合の手間を減らす。
• 企業システムとの接続では、Microsoft Entra のOn-Behalf-Of認証によって権限を維持する。
• まずテストプロジェクトを立ち上げて基本エージェントを作成し、スレッドを実行して、SDKまたはポータルでランステップを確認する。

まとめ

Azure AI Foundry は、モデルにプロンプトを投げるだけの場ではありません。指示とツールを備えたエージェントを、再現可能な形で構築するための基盤です。エージェントの動作はスレッド、ラン、ランステップに記録され、開発リードもコンプライアンス担当者も、ライフサイクル全体を可視化し、統制できます。まずは小さなテストプロジェクトで実行ステップを確認し、ログが実際の出来事と一致していることを確かめるのが、導入への確実な第一歩です。