MiniMaxの新モデル「M3.1-Flash-Preview」が、MiniMax Codeに登場しました。2026年9月27日14時24分（日本時間）の公式発表は、小さな不具合修正から機能開発まで、日常的な開発作業に向けたモデルと紹介しています。これは告知の時刻であり、全利用者への反映が完了した時刻ではありません。
注目したいのは、考える度合いを変えられる設定です。いつも最大にすればよいのか、それとも小さな修正は低い設定で十分なのか。この記事では、公式仕様を整理したうえで、日本語の業務ルールを使ってlowとmaxを比較する手順を紹介します。M3.1による修正・速度・利用量の比較実測は行っていません。後半の教材は試すための例です。
新しいのは「どれだけ考えさせるか」を選べること
公式モデル一覧では、M3.1-Flash-Previewを、画像なども扱え、100万の文脈を扱う開発向けモデルとしています。トークンは文章を処理する単位で、日本語の文字数と同じではありません。100万という長さも、長い資料を必ず正確に使い切れるという保証にはなりません。
発表画像には、Effortの選択肢として low、med、high、xhigh、max の5段階が写っています。公式の資料では、高い設定ほど推論に使うトークンが増え、待ち時間も長くなると説明されています。用途に合わせて設定を変え、その仕事に必要な正確さを満たせるかを見る余地があります。
プログラムから呼び出す場合の表記には注意が必要です。Codeの画面は「med」ですが、APIの output_config.effort は medium です。APIでは省略時にmaxとなり、M3.1の推論自体を無効にする指定は受け付けません。画面の文字をそのまま設定ファイルへコピーしないでください。公式API仕様
MiniMax Codeと通常の従量APIを分けて考える
MiniMax Codeは、手元のプロジェクトを読み、許可に応じてファイルの編集やコマンド実行を進める製品です。公式案内にはmacOSとWindows向けのデスクトップ版があり、インストール後にサインインして使う手順が掲載されています。
M3.1について、公式資料は現時点の利用先を Token PlanとMiniMax Codeに限定 しています。Token Plan経由のプログラム連携は案内されていますが、通常の従量課金APIで誰でも同じように呼べる、という意味ではありません。対応モデルと提供条件
Token Planの料金表には、月額Plus 22ドル、Max 55ドル、Ultra 132ドルが掲載されています。ただし、今回確認した公開資料では、M3.1の各プランでの選択可否や設定別の消費量までは確定できませんでした。製品ページに無料クレジットの案内があっても、M3.1を無料枠で必ず使えるとは判断できません。
日本からの登録・モデル選択・支払いは本記事では試していません。開始時は自分のアカウントでモデル名、選べるEffort、残り利用量を確認してください。公式の利用案内も、対象モデルと利用量はアカウントや設定に依存すると説明しています。試用できる状態を確認してから、以下の小さな比較へ進みます。
比較するのは、架空の通販サイトの送料計算
修正前コード、9ケースの判定コード、仕様を含む依頼文、空の記録表を教材ZIPにまとめました。展開した元の教材を残し、low用とmax用にコピーして使えます。モデルによる修正結果や正解実装は入っていません。
「使いやすいサイトに直して」では、見た目や提案の好みに評価が引っ張られます。今回は、支払額を返す短いPython関数に絞ります。担当者が知っている日本語の業務ルールを、コードへ正確に反映できるかが対象です。顧客データや本番の決済処理は使いません。
仕様は次のとおりです。金額は税込みの整数円、数量は正の整数、値引きは0円以上とし、不正な入力の検査は今回の対象から外します。
- キャンセル済みの商品は、商品代と送料判定から除外する。
- 有効な商品の合計から値引きを引き、商品代の下限を0円とする。
- 値引き後の商品代が5,000円以上なら送料無料。それ未満は550円。
- 有効な商品がなければ支払額は0円。有効な商品があり、値引きで商品代が0円になった場合は送料550円を請求する。
- 戻り値は整数の支払額。渡された注文データは変更しない。
新しい練習用フォルダに、次を checkout.py として保存します。意図的に仕様違反を含む修正前コードです。このまま実務へ使うものではありません。
# checkout.py — 修正前の教材
def total_yen(order): subtotal = sum(x["price"] * x["qty"] for x in order["items"]) shipping = 0 if subtotal > 5000 else 550 return max(subtotal - order.get("discount_yen", 0), 0) + shipping同じフォルダに、判定用の check_checkout.py を保存します。判定値は記事側で決めた正解であり、AIの出力ではありません。Python 3の標準機能だけで動きます。
# check_checkout.py — このファイルはAIに変更させないfrom copy import deepcopyfrom checkout import total_yen
def item(price, qty=1, cancelled=False): return {"price": price, "qty": qty, "cancelled": cancelled}
cases = [ ("通常送料", [item(1000, 2)], 0, 2550), ("境界ちょうど", [item(5000)], 0, 5000), ("境界より上", [item(5001)], 0, 5001), ("値引きで境界未満", [item(6000)], 1500, 5050), ("値引き後が境界", [item(6000)], 1000, 5000), ("キャンセル混在", [item(6000, cancelled=True), item(1000)], 0, 1550), ("全件キャンセル", [item(6000, cancelled=True)], 0, 0), ("空の注文", [], 0, 0), ("値引きが商品代超過", [item(1000)], 1500, 550),]passed = 0for name, items, discount, expected in cases: order = {"items": items, "discount_yen": discount} before = deepcopy(order) try: actual = total_yen(order) ok = type(actual) is int and actual == expected and order == before print(name, "PASS" if ok else "FAIL", "actual=", actual, "expected=", expected, "unchanged=", order == before) except Exception as error: ok = False print(name, "ERROR", type(error).__name__, str(error)) passed += int(ok)print(f"{passed}/{len(cases)} passed")raise SystemExit(0 if passed == len(cases) else 1)この2ファイルを含む未修正フォルダを、low用とmax用にコピーします。修正後は各フォルダで python3 check_checkout.py を実行してください。9ケースすべての期待値、戻り値の型、入力を壊していないことを確認します。WindowsでPythonを py から起動している場合は py -3 check_checkout.py に置き換えます。
記事作成時に、教材だけをローカルで確認しました。掲載した修正前コードは4件合格・5件不合格となり、仕様に沿って人手で用意した確認用実装は9件すべて合格しました。これは判定用教材の動作確認であり、MiniMaxが修正した結果ではありません。
同じ日本語の依頼をlowとmaxへ渡す
比較時は新しい会話を使い、同じモデルのままEffortだけを変えます。片方の修正内容や会話をもう片方へ渡すと、同条件の比較になりません。ファイルへのアクセス許可、アプリの版、試した日時も揃えて記録します。モデルが更新されるPreviewでは、別の日の結果を混ぜないことも大切です。
最初に上の仕様を渡し、続けて次の依頼文を貼り付けます。指示の背景や出力形式の決め方は、AIへの話しかけ方の基本も参考になります。
架空の通販サイトの送料計算を修正してください。
直前に渡した5項目の仕様を正解として扱います。
対象はこのフォルダのcheckout.pyだけです。
関数名・引数・戻り値の形式は維持してください。
check_checkout.pyの変更、外部ライブラリの追加、
外部通信、他のファイルの編集は不要です。
まず仕様と現状の違いを短く述べ、必要な修正をしてください。
その後、python3 check_checkout.pyを実行してください。
実行できない場合は、その事実と理由を書いてください。
最後に、変更点と各確認項目の結果を日本語で報告してください。
テストに通すために仕様や期待値を変えないでください。この指示は比較条件であり、操作権限を技術的に封じるものではありません。仕事中のフォルダを丸ごと接続せず、練習用の2ファイルを対象にしてください。判定用ファイルが書き換えられた場合は、その回を有効な比較結果に数えません。
合否、余計な変更、時間、利用量を別々に記録する
最初は各設定1回で手順を確かめます。継続利用を判断するなら、毎回未修正の状態へ戻し、例えばlow→max→max→lowと順番を入れ替えて複数回試します。小さな教材だけでモデル全体の優劣は決められませんが、自分の依頼に設定を使い分ける材料になります。
| 記録する項目 | low | max |
|---|---|---|
| 日時・アプリの版・モデル表示 | 未測定 | 未測定 |
| 9ケースの合格数 | 未測定 | 未測定 |
| 判定ファイルの変更／対象外の編集 | 未確認 | 未確認 |
| 依頼送信から最終報告までの秒数 | 未測定 | 未測定 |
| うち、人の承認待ち時間 | 未測定 | 未測定 |
| 利用量表示の開始値→終了値、単位 | 未測定 | 未測定 |
| 追加指示の回数と内容 | 未測定 | 未測定 |
待ち時間には、生成だけでなくファイル操作や確認も含まれます。人が承認ボタンを押すまでの時間を記録しておけば、長く待たせた回をモデルの遅さと取り違えにくくなります。利用量は別の作業を止めて記録し、画面にトークン数がなければ推定で補いません。利用率しか出ない場合は表示の差として残し、金額には換算しないでください。
合格数が同じなら、余計な編集や追加指示が少ないかを見ます。そのうえで時間と利用量を比べます。仮にlowが十分なら、この種類の仕事をlowへ寄せる根拠になります。maxだけが通った場合も、修正が難しいのか、日本語の条件を読み落としたのかを確認します。長い説明を書いたこと自体を高評価にはしません。評価の考え方はAI導入効果の測り方につながります。
参考資料
仕様・提供条件は2026年9月28日に確認しました。