目次
Mistralは2026年11月5日、Studio向けアプリを雛形から作成し、ローカル実行と配備まで扱うMistral Apps を公開プレビューとして案内しました。対象は、AIのワークフローだけでなく、利用者が操作する画面、、、バックグラウンド処理を一つのプロジェクトとして管理したい開発チームです。
今回の変化は、モデル呼び出しのサンプルが増えたことではありません。必要な構成要素を「capability」として選び、生成された通常のソースコードを編集し、同じCLIで開発環境とStudio配備をつなげられる点にあります。ただし、Appsは公開プレビューであり、利用プラン、GitHub連携、ローカルの、モジュールごとのまで揃えないと本番へ進めません。本記事では実測結果ではなく、2026年11月9日に確認した公式資料に基づき、採用判断と導入手順を整理します。
スポンサーリンク
最初にapp・workflow・pluginを分ける
Mistral Appsは、、API、データベース、エージェント、ワークフローを一つの配備単位へまとめる仕組みです。利用者が入力画面から処理を開始し、結果を確認する業務アプリや、複数のサービスを同時に配備したい構成に向きます。画面を持たない定期処理なら、単独のworkflowの方が小さく始められます。Vibeの会話へツールや指示を足すだけならpluginが別の選択肢です。
| 選択肢 | 向いている用途 | 導入時の確認 |
|---|---|---|
| app | 画面、API、DB、workerをまとめる | 複数モジュールと配備先を運用できるか |
| workflow | 画面を持たない長時間・定期処理 | 開始方法、再開、結果の受け渡し |
| plugin | Vibeへ機能を追加 | 独立したWebアプリが本当に必要か |
「AIを使うからapp」を選ぶのではなく、利用者が専用画面を必要とするか、部品を同じリリースで更新したいかで決めます。長時間処理の実行場所や再開設計が主題なら、関連記事のMistral Managed Agentsの実行場所を選ぶも先に確認してください。Apps CLIはプロジェクトと配備を扱い、Managed Agentsはエージェント実行の持続性を扱うため、置き換え関係ではありません。
presetとcapabilityで雛形の範囲を決める
標準のapp presetは、TanStack StartのWebフロントエンド、FastAPI、Postgres、workflow workerを生成し、共通設定とStudio配備用の部品も加えます。すべてが必要でなければ、最初からCustomまたは--capsで絞れます。CLIは必須依存や互換性を確認し、曖昧な構成を黙って別の部品へ置き換えないと公式資料は説明しています。
mistral login
mistral apps capability list
mistral init support-console --preset app
cd support-console
mistral apps modules
mistral dev既存プロジェクトへworkerを足す場合は、アプリのディレクトリでmistral apps capability add workflowsを使います。追加・削除・選択の操作は生成ファイルも更新するため、実行前にへし、差分をレビューできる状態にします。capabilityはライブラリ依存だけではなく、コード、設定、開発・コマンドを含む雛形です。更新を通常の更新と同じ感覚で自動適用すると、生成済みのルートや設定との衝突を見落とします。
導入時は、まずpresetで一度生成し、採用しないモジュールを消す方法より、必要なcapabilityだけを明示する方が判断を記録しやすくなります。例えば、既存フロントエンドからAPIだけを利用するなら、新しいWeb画面まで同時に持つ必要はありません。逆に、業務画面と承認結果を同じURLで提供したいなら、app presetを基準に不要な機能を整理する方が早い場合があります。
スポンサーリンク
ローカル実行では認証経路を二つに分けて確認する
mistral devは、mistral.jsonにあるモジュールとローカルgatewayを起動し、URL、状態、ログを表示します。Postgres capabilityはDockerを使うため、Dockerが停止しているとデータベースなしで他のモジュールだけが起動します。画面が開いたことだけで正常と判断せず、APIとworkerがDBへ接続できるかまで確認します。
は混同しやすい部分です。生成したworkerなどが直接Mistral APIを呼ぶためのMISTRAL_API_KEYはアプリの.envへ置きます。一方、ローカルgateway経由のAPI呼び出しは、基本的にmistral loginで選択したorganizationとworkspaceを使います。ログインがない場合は、CLIを起動したシェルやCLI設定のが参照されます。アプリの.envにキーを書いただけではgatewayの主体にならない点を切り分けます。
mistral context showでorganizationとworkspaceを確認するmistral apps modulesで起動対象の名前を確認するmistral dev --filter web,apiで問題の範囲を狭める- gatewayが疑わしい場合は
mistral dev --no-gatewayで各モジュールを直接確認する - スクリプトでログを処理する場合は
mistral dev --jsonを使う
--filterは指定しなかった依存モジュールを自動では起動しません。Webだけを起動してAPIへ接続できない場合、モデルやネットワークの障害と決めつけず、必要なbackendを除外していないか確認します。この手順は、生成された構成を一度に起動して原因が見えなくなる状況を避けるための切り分けです。
配備されるのは作業中のファイルではなくGitの状態
標準のmistral deployは、GitHubのoriginへpushされたcommitをビルドします。作業ツリーはcleanである必要があり、生成された各モジュールのDockerfileもcommitに含めます。MistralアカウントとGitHubを接続し、対象へMistral GitHub Appがアクセスできることも前提です。ローカルで直しただけのコードを配備したつもりになる事故を避けるため、配備ログへcommit IDを残す運用が適しています。
git status
git add .
git commit -m "prepare studio app"
git push -u origin HEAD
mistral deploy --organization "Example" --workspace "Web Team"初回配備ではアプリと各モジュールが作成され、配備先との対応がmistral.jsonへ保存されます。この変更もcommitし、別の端末やが同じアプリへ配備できるようにします。ローカルの.envはアップロードされません。本番用のAPIキーや接続情報は、Studioの各モジュールまたはSecrets Managerで設定します。ローカルと本番で同じ変数名を使いながら、値の保管場所を分離します。
Appsの利用可否は契約プランにも依存します。公式資料の2026年11月9日時点の記載では、Freeとpay-as-you-go無効のPro・Teamはアプリ作成枠が0、pay-as-you-go有効時は組織当たり3、Enterpriseは10です。全workspaceのアプリが組織枠へ合算されます。試作の前に管理者へ枠と課金状態を確認し、「CLIが表示されたから配備できる」とは判断しません。公開プレビューの制限や枠は変わり得るため、導入時に公式ページを再確認します。
スポンサーリンク
配備とVibe公開を別の操作として管理する
mistral deployでURLが動いても、Vibeのカタログには自動掲載されません。配備後にmistral apps publishを実行すると、既定ではproduction aliasがVibeへ公開されます。この操作はブラウザーログインが必要で、APIキーだけでは実行できません。unpublishはカタログ項目を外すだけで、配備済みアプリを停止しない点も運用手順へ明記します。
この分離により、配備URLで受け入れ確認を終えてから、対象利用者へ見せる段階を切り替えられます。公開前にはStudio側のtitle、description、visibilityと、利用者のorganizationアクセスを確認します。カタログから見えないときに再配備を繰り返すのではなく、公開aliasと可視性を先に調べます。
本番移行は五つの確認で止める
Apps CLIは雛形と配備経路を揃えますが、業務要件を自動で決めるものではありません。最初の本番候補では、次の五点を合格条件として記録します。
- 構成：appが必要な理由と、選んだcapabilityを説明できる
- 再現性：別のcloneで
mistral apps installを実行し、同じ構成を復元できる - 設定：ローカルの.envと本番Secretsの対応表があり、値をGitへ含めていない
- 配備：commit ID、organization、workspace、app aliasをリリース記録へ残す
- 観測：gateway、API、workerのどのログを見るかを障害別に決める
外部APIをAIのツールへ変換することが中心なら、Apps CLIでフルスタックを作る前に、Mistral StudioのHTTPコネクターで足りるかも比較します。専用画面、独自API、DB、workerを同じライフサイクルで配備する必要があるときにAppsを選ぶと、導入理由が明確になります。
導入時の切り分け手順
ローカルで画面だけ動く場合はDocker、DB、workerの順に状態を確認します。API呼び出しだけ失敗する場合は、アプリ用キーとgatewayが使うログイン主体を分けて確認します。配備前に止まる場合は、Gitの作業ツリー、origin、push済みcommit、GitHub Appのアクセス、Apps枠を順番に調べます。配備後に特定モジュールだけ失敗する場合は、mistral apps logs api --buildでビルドログを読み、次に実行時ログを確認します。
この順序なら、モデル品質の問題、ローカル環境の問題、配備経路の問題を混ぜずに済みます。公開プレビューを採用する場合は、CLIのバージョンとcapabilityの選択をリリース記録へ残し、更新時には生成ファイルの差分を通常のコードレビューへ含めてください。
関連記事
スポンサーリンク
