目次
MistralはStudioの拡張で、Managed Agentsによるエージェントの実行と配備を提供しています。質問ごとにモデルを一度呼ぶだけでなく、ツールを繰り返し使い、長時間の処理を進め、アプリが終了した後も結果を受け取る構成を作れます。ただしManaged AgentsとAgents は公開プレビューです。、挙動、制限が変わり、更新時にコードの変更が必要になる場合があります。Mistral：Studioのエージェント・ワークフロー・アプリ拡張
Web開発者が最初に決めるべきなのは、モデルの名前より実行場所です。ローカルのプロセスで動かすのか、社内のサーバーにワーカーを置くのか、Mistralに配備するのかで、終了時の挙動と運用責任が変わります。本稿は11月7日に確認した公式資料に基づく導入解説です。実際のAPI呼び出しや障害試験は行っていません。公開仕様と、問い合わせ処理を想定した本サイトの設計案を分けて説明します。
スポンサーリンク
モデルと実行ループと作業環境を分ける
Mistral Docs：Managed Agentsはエージェントを、次の行動を選ぶモデルと、その指示に従ってツールを動かすharnessの組み合わせとして説明しています。はメッセージ、、結果を記録し、ターンは入力から回答までのまとまりです。ファイル編集やシェル操作に使うenvironmentはさらに別の概念で、既定ではエージェントに付いていません。
この区別は構成の費用や障害を調べるときに役立ちます。社内APIを呼ぶ処理が遅い場合に、モデルを替えるだけでは改善しないかもしれません。ワーカーを移した結果、接続先までの遅延が増えた可能性もあります。まず、モデル応答、ツール実行、作業環境の起動、アプリへの結果配信のどこで待つかを記録します。全体の所要時間だけを見ると、管理サービスへ移す利点を判断しにくくなります。
一度のモデル要求で終わる処理にはChat completions、手順や分岐・再試行を明示する処理にはWorkflowsという選択肢も公式が示しています。問い合わせを固定の順番で検証するだけなら、最初から自律的なループを入れる必要があるかを検討します。自由に調べる工程があり、必要なツールや次の行動が入力によって変わる仕事が、Managed Agentsを試す候補です。
三つのモードはセッションの保存場所から選ぶ
ローカル実行では、agents.Agent(...) で作るエージェントや agents chat を使い、モデルへの要求とツール実行を自分のプロセスから進めます。セッションは基本的にそのプロセスのメモリーにあり、プログラムとともに終わります。実行モードの資料には実験的なjournalによるディスク保存もありますが、本番の永続実行と同じ保証として扱わず、まず開発と試験のための方式と考えます。
自社運用の agents serve は、セッションを処理するワーカーを自社のマシンやクラスターで動かします。ツールのコードもそこで実行します。一方、セッションの保存とワーカーへの振り分けはMistralの制御側が担当し、モデル呼び出しもMistralが提供します。「self-hosted」という名前だけで、セッションの保存まで社内で完結する構成と解釈しないことが要点です。Mistral Docs：実行モード
Mistral管理の agents deploy では、からプロジェクトをし、ワーカーをMistralが動かします。アプリは配備済みのエージェントを名前で読み込み、セッションを開始します。ワーカーを自分で常駐させる負担は減りますが、配備元のとを管理する工程が必要です。ローカルで編集した直後のファイルが自動で配備されるわけではありません。
判断の例として、社内ネットワークにある問い合わせ台帳のAPIをツールから呼ぶなら、自社側ワーカーの到達性と保守負担を比較します。外部から利用できるAPIだけで完結し、自社にワーカーを持つ理由が薄ければMistral管理を試せます。どちらもセッションはMistralが保存するという共通点があるため、違いを単純に「ローカル保存か保存か」と整理しないでください。
スポンサーリンク
セッションとターンに別々のキーを付ける
Mistral Docs：セッションでは、同じイベントが二度届いた場合に、セッション開始とターン実行の両方へ idempotency_key を指定する例を示しています。問い合わせ番号をキーの基点にして、セッション用と「最初の調査」用で区別すれば、再配信された入力を別の仕事として増やすことを防ぐ設計ができます。キーを毎回ランダムに作ると、再試行と新規依頼を同一視できません。
この重複防止と、外部ツールの二重実行は別の課題です。配備済みのモードでは完了したモデル要求とツール呼び出しが記録されますが、ワーカー停止時に進行中だった操作の結果は不明になる場合があります。公式は、進行中だったモデル要求は再実行され、ツール呼び出しそのものは自動で同じように再実行されないと説明しています。それでも約1分後にモデルへエラーが返り、モデルが同じツールを再び選ぶ可能性があります。
たとえば問い合わせの調査を終えてチケットを作成した直後、結果をセッションへ記録する前にワーカーが停止すれば、再開後に同じ作成操作が選ばれる可能性があります。アプリ側で同じセッションを開けることは、チケットが一件だけである保証にはなりません。外部APIに問い合わせ番号に基づくキーを渡し、同じ作成要求では既存の結果を返す仕組みを使います。
外部APIにキーの仕組みがない場合、公式は一意制約などにより同じキーの重複登録を拒む保存先を使う方法を示しています。ただし実装では、記録を先に作った後に外部操作が失敗するケースも設計します。処理中、完了、結果不明を分け、結果不明のまま新規作成へ進まず外部側の状態を照合するのが本サイトの提案です。「実行済みか」を読むだけでは、並列処理が両方とも未実行と判断する競合を防げません。
配備はコミットと実行名を記録して進める
Mistral Docs：エージェントの配備の手順では、プロジェクトをGitHubへpushし、GitHubコネクターを接続してから agents deploy を使います。配備するのはpush済みのコミットで、未pushのコミットや上流がないは拒否されます。ワークスペース内で同じエージェント名へ後から配備すると置き換えになるため、検証用と本番用を名前で分け、配備したリビジョンを記録しておくと確認しやすくなります。
最初は公式Quickstartのように小さなツール一つで試し、ローカルと配備後に同じ入力を渡して結果を比較します。agents list で稼働状態、agents logs でログを確認できます。配備済みのエージェントは Agent.load_from(agent_name=...) で読み込みます。アプリが終了して後から結果を取る構成では、セッションIDとターンIDを保存して、同じ仕事へ戻れるようにします。
ハンドルを捨てることと、セッションを終了することも違います。公式資料では、ハンドルを破棄してもセッションや作業環境は終了せず、session.cancel() が終了操作になります。画面を閉じたら業務を中止するのか、閉じてもバックグラウンドで継続するのかを先に決め、UIの終了とセッションの終了を対応させます。結果を取りに来ない仕事が残っていないかも運用で確認します。
スポンサーリンク
継続できる時間と復旧できない状態を試験する
公式の概要では、配備時のセッションは既定で24時間、アイドルは4時間という制限があり、引き上げる設定があります。待機の種類によっても制限があるため、長時間動くという紹介だけで無期限に保持される前提を置きません。問い合わせを翌営業日に再開するなら、必要な待ち時間と、期限が切れたときの処理を対象ワークスペースで確認します。
永続化はワーカーのメモリー全体を保存するものではありません。モジュールのグローバル変数やローカルは停止で失われます。再開に必要な業務IDや外部操作の結果を、その場のメモリーだけに置かないようにします。また、公式資料はターンが通常は再開する一方、失敗したり、制限時間までRunningのままになったりする場合も説明しています。稼働状態だけで成功と数えず、最終結果と外部側の記録を照合します。
試験では、読み取りツールの途中、外部登録の直後、結果保存後という三つの位置で停止した場合を分けます。確認するのは、再開できたかだけでなく、追加されたチケット数、返された結果ID、利用者が再送したときの表示です。試験用の外部サービスを使い、意図的な停止を本番の業務データで試さないようにします。ここで挙げたケースは本サイトの試験案で、Mistralの動作を実測した結果ではありません。
採用前に運用負担と完了率を並べる
Managed Agentsの採用評価では、正常に完了した仕事の割合、重複した外部操作、結果不明のまま残った仕事、全体の所要時間を同じ入力セットで比較します。Mistral管理へ移してワーカーの保守が減っても、失敗を利用者が何度も再送するなら、運用全体の負担が減ったとは限りません。トレースと業務IDを結び付け、調査できる単位をそろえます。
料金は今回確認した導入資料だけから一律のタスク単価を確定できないため、契約と料金表で確認します。本サイトの提案は、モデル利用量だけでなく、ワーカーや作業環境、外部APIの呼び出し数、失敗後の手動対応も同じ仕事の費用へ含めることです。ローカルで正しく動く小さな処理を出発点にし、セッションがアプリより長く生きる必要がある段階で配備へ移すと、追加した実行基盤の価値を測りやすくなります。
関連記事
AIの評価データと回帰テストの始め方では、変更前後で同じ入力を比較する考え方を解説しています。
