Mistral API キーの作成手順と初回リクエストでの確認方法

Mistral の API キーは無料のまま発行できます。有料プランへの加入は前提ではありません。作成は Studio コンソール（console.mistral.ai）で行い、左サイドバーの API Keys から Create new key を選んで、名前、有効期限、コネクターのアクセス範囲を決めれば完了です。公式クイックスタートが示す所要時間の目安は約5分です。フルキーは一度しか表示されないので、出てきた時点でコピーして保管しておきます。

動作確認の最短ルートは curl です。https://api.mistral.ai/v1/chat/completions に対して model を mistral-small-latest にして POST し、応答が返るかどうかだけを見ます。応答が返ればキーは有効で、以降つまずくとすれば原因はアプリへの組み込み方やプロンプトの中身に移ります。

Mistral API キーは何のために作り、どこで作成しますか

Mistral のモデルを API 経由で呼び出すときの認証情報です。作るのは Studio の API Keys 画面で、Mistral アカウントにサインインしている必要があります。

キーが担っている役割

リクエストが api.mistral.ai に届くと、まずどのアカウントから送られたものかが判定されます。判定に使うのが Authorization ヘッダーに載せるキーです。キーが無ければサーバー側は利用者を特定できず、応答を返せません。

扱いはクレジットカード番号に似ています。文字列を知っている人は誰でも、あなたのアカウントに課金されるリクエストを送ることができます。保管の仕方と用途ごとの分け方が後で効いてくるのはそのためです。

キーには用途が分かる名前を付けておきます。数か月後に「このキーは何に使っているのか」を追いやすくなるからです。最初は試作用に1本だけ作るのが分かりやすい進め方です。動作を確かめてから本番用を分ければ、使われないキーが最初から並ぶのを避けられます。

作成を始める前に用意するもの

用意するのは Mistral アカウントだけです。手順の中にカード情報を入力するステップはありません。Free モードでは API アクセスが既定で有効になると書かれています。

登録には、メールアドレスを使う方法と、Google などの既存アカウントを使う方法が紹介されています。会社のメールで登録するか個人のアカウントで始めるかは、後でキーを誰が引き継ぐかで変わります。チームで使うなら、引き継ぎ先がはっきりするアカウントを最初から選んでおくと、担当が変わっても困りません。

どの Workspace にキーが作られるか

Studio に表示されるのは、いま active になっている Workspace のキーだけです。キーもその Workspace に作られるため、上部の Organization / Workspace セレクターで対象を切り替えてから Create new key を押します。複数の Workspace を使っているときに目的のキーが見当たらないのは、この仕組みのためです。

ユーザーにキー作成を許可するかどうかは、管理者が Workspace の API Key Creation 設定で決めます。作成ボタンが見当たらないときは、権限と選択中の Workspace の両方を確認すると原因を早く切り分けられます。

無料モードでクレジットカードは必要ですか

不要です。公式クイックスタートには、Free モードなら API アクセスが既定で有効になり、クレジットカードは要らないと明記されています。利用量とレート制限が適用される点もあわせて書かれています。

Free モードでできること

新しいアカウントは Free モードから始まります。この状態でキーを作成し、プランに含まれる月次用量の範囲内でモデルを呼べます。上限の基準になるのは Admin Panel › API › Limits に表示される数字です。Mistral のヘルプセンターは、Free モードは制限が最も低く、評価と試作向きだと説明しています。

キーを作る流れの中に請求設定の画面は出てきません。手順として書かれているのは、API Keys を開いてキーを作り、コピーして保管するまでです。

含まれる月次用量を使い切ったら

含まれる月次用量を超えたあとの挙動は、pay-as-you-go の有効・無効で変わります。有効ならトークン単位の課金に切り替わり、無効なら次の請求サイクルまで利用が止まることがあります。判断材料になるのは Admin Panel › API › Limits に出ている数字です。

キーの発行と支払いの担当が分かれているとき

チームで同じアカウントを共有していると、キーは自分が作るのに支払いの判断は別の人が持っている、という状況があります。有料の従量課金に進む可能性があるなら、キーの発行と支払いの可否を誰が決めるのかを先に揃えておけば、作成の途中で止まりません。

API キーを作成する手順

API Keys を開いて Create new key を押し、ダイアログの項目を決めればキーができます。1回の作業は、表示されたフルキーをコピーして保管するところまでです。

作成ダイアログで決める3つの項目

ダイアログで決める項目は3つです。名前は用途が分かるものにしておくと、キーが増えたときに役立ちます。

有効期限は、いつ切れるかを先に把握しておけば更新のタイミングを計画に組み込めます。コネクターのアクセス範囲は、共有されたコネクターだけを使うか、自分のプライベートなコネクターも使うかの選択です。

判断に迷いやすいのは有効期限です。短くすると万一のときの影響は小さい代わりに、期限が切れて動かなくなる日に作業が発生します。試作中は長めに、本番用はローテーションの周期に合わせて、というように用途で分けておくと扱いやすくなります。

フルキーは一度だけ表示される

作成を確定するとキーが表示されます。ただし表示されるのはこの1回だけです。確認ダイアログを閉じたあと、同じ文字列を再表示する方法はありません。必要になったら新しいキーを作り直すことになります。

コピーは表示より先に準備しておきます。表示されてから保管先を探し始めると、その間に閉じてしまう事故が起きます。パスワードマネージャーやシークレットボルトを開いた状態で作成を押せば、この手戻りは避けられます。

最初のリクエストでキーが動くことを確認する

https://api.mistral.ai/v1/chat/completions に curl で POST し、Authorization: Bearer にキーを載せ、model に mistral-small-latest を指定します。応答が返ればそのキーは有効です。OpenAI 用のコードが既にあるなら、api_key と base_url を差し替えるやり方でも同じ確認ができます。

curl で送る最小のリクエスト

キーを環境変数 MISTRAL_API_KEY に入れておけば、コマンドはそのまま貼り付けるだけで済みます。Windows の PowerShell なら $env:MISTRAL_API_KEY="your_api_key_here" の形で設定します。

curl https://api.mistral.ai/v1/chat/completions \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-small-latest",
    "messages": [{"role": "user", "content": "Hello, Mistral!"}]
  }'

返ってきた JSON では、choices の配列に応答本文が入っています。そこまで読めれば、認証とリクエスト形式の両方が通ったことになります。この時点で、キーの作成と保管、モデルの指定、認証の3つが同時に確かめられたことになります。

SDK と OpenAI 互換のコードから試す

公式の Python SDK なら pip install mistralai で導入し、Mistral(api_key=…) でクライアントを作って、chat.complete に model と messages を渡します。生の HTTP リクエストと SDK の両方を押さえておくと、応答が返らないときに切り分けやすくなります。

OpenAI のライブラリをそのまま使うなら、api_key に Mistral のキー、base_url に https://api.mistral.ai/v1 を指定します。呼び出しは chat.completions.create のままでよく、変えるのは model の名前だけです。

応答が返らないときの見分け

初回でつまずく場所は、多くの場合キーかリクエスト形式です。よく出る HTTP ステータスと対処をまとめます。

401 が出たら、環境変数がそのシェルに実際に渡っているかを確認します。設定していない別のターミナルや CI で実行していれば、キーは送られていません。429 は短時間に送りすぎたときに返るので、間隔を空けて試します。

キーを安全に保管・管理するにはどうしますか

基本は、パスワードマネージャーなどに保管し、環境変数 MISTRAL_API_KEY に置いてソースコードから切り離すことです。本番、ステージング、ローカルの3系統に分けておけば、1本漏れても影響を止められる範囲を限定できます。使わなくなったキーはコンソールから失効させます。

環境変数に置き、ソースコードから切り離す

キーをコードに直接書くと、リポジトリを共有しただけで漏洩の範囲が広がります。環境変数に置けば、コードを触らずに実行環境ごとに違うキーを渡せます。

シークレットスキャナーを入れておくと、誤ってコミットしたときに気づきやすくなります。キーが漏れたら、見つけた時点で失効させて作り直すまでを1回の作業として決めておけば、被害を広げずに済みます。

用途ごとに分け、不要になったら失効させる

1本のキーをすべての用途で使い回すと、1つを止めたいときに他の処理まで止まります。本番、ステージング、ローカルで分けておけば、ローカルのキーだけを失効させられます。

共同開発でキーをチャットに送って共有すると、履歴に残ったまま消えません。共有が必要なら、相手専用のキーを作って渡し、不要になったらそのキーだけを失効させるほうが後始末は簡単です。

キーが増えてきたら、保管先、用途、期限、失効させる条件をそろえておくと棚卸しがしやすくなります。この進め方は、キーが増えたときの管理とローテーションの進め方でまとめています。

モデル名と利用料金はどこで確認しますか

モデル ID は公式のモデル一覧、単価は公式の価格ページとコンソールで確認します。名前には mistral-small-latest のような latest タグのものと、mistral-large-2512 のように年月が付いたものがあります。latest は中身が更新されうるので、版を固定したいときは日付付きの名前を選びます。

latest タグと日付付き版の違い

latest が指すのは、そのモデルの最新の安定版です。常に新しいものを使える代わりに中身が変わりうるため、時間が経つと応答の傾向がわずかに変わることがあります。日付付きの版はどの版かを識別しやすくしますが、再現性はプロンプトやパラメータにも左右されます。

mistral-large-2512 は、2025年12月に公開された Mistral Large 3 を指す名前です。古い解説にある mistral-large-2411 は 2026年5月31日に提供が終了しており、指定するとリクエストは 404 で失敗します。実際に使う ID は公式のモデル一覧で確認します。

初回リクエストの目的はキーの確認なので、公式の例と同じ mistral-small-latest を使うのが最短です。版を固定するかどうかは、比較や評価を始める段になって効いてきます。

単価はどこで見るか

料金はモデルごとに異なり、入力と出力で別々に設定されています。次の表は、2026-10-12 時点で公式の価格ページに掲載されている単価です。

単価は改定されることがあるので、見積もりに使う数字はコンソールの表示で確かめます。まず小さいモデルで試作し、精度が足りない部分だけ大きいモデルに切り替えると、費用を抑えやすくなります。

見積もりは、1リクエストあたりの入出力トークン数に1日のリクエスト数を掛けて出します。入力は指示文と会話履歴、出力は生成された本文で、単価が違うため別々に数えます。毎回長い履歴を送る設計は入力側が膨らみやすいので、費用の中心がどこにあるかを押さえておくと、後の見直しが早くなります。

複数のモデルを1つのキーで扱うときの選択肢

ここまでの手順は Mistral のキー1本で完結します。他のベンダーのモデルと比べながら試す段になると、キーも請求先もベンダーごとに増えていきます。

MixRoute は、複数ベンダーのモデルを1本のキーで扱えるようにする gateway です。公開ページでは 250+ のモデルを単一のエンドポイントから呼べると説明されています。base URL を https://api.mixroute.ai/v1 に向ければ OpenAI SDK 互換のまま呼び出せ、pricing では platform fee は 0% とされています。

Mistral のキーで最初の1回が通ったら、次は料金と利用条件です。MixRoute の料金と利用条件を確認するのが次の一歩になります。ページの金額は米ドル表示で、日本円などの現地通貨への自動換算は行っていません。支払い条件や請求書の扱いは所在地とプランによって変わるため、個別の相談で確認する形です。