2026年のオープンAIモデル：DeepSeek、Qwen、Kimiを解説

「オープンAIモデル」とは何を意味しますか？

「オープン」は一群の説明を指す言葉であり、保証ではありません。オープンウェイトのリリースは、モデルの最終的な学習済みパラメータを共有するもので、ライセンスが許す場合には、他の人がそれをファインチューニングし、適応させ、デプロイすることができます。 ^[4] オープンソースAIシステムは、より強い主張です。Open Source Initiativeの定義は、OSIが承認した条件のもとで3つの要素を求めています。熟練した人が実質的に同等のシステムを構築できるほど詳細なデータ情報、システムの学習と実行に使われた完全なソースコード、そしてモデルのパラメータです。 ^[1]

この区別は、現実の選択に影響します。重みは入手できても、学習データと学習コードは入手できないことがあります。Open Source Initiativeによるオープンウェイトの解説は、オープンウェイトがオープンソースAIと異なるのは、学習コードや学習データセット、あるいは法的に共有できない場合のそのデータセットに関する包括的な詳細を含まないからだと述べています。それらがなければ、学習プロセスを再現したり監査したりすることは困難です。 ^[4] したがって、モデルはローカルにデプロイできても完全には再現できないことがあり、また、特定の用途を制限する条件のもとで重みが提供されていることもあります。

リリースを選ぶ前に、4つの問いを立ててください。その重みそのものを入手できるか。どのライセンスが適用されるか。選んだ形式を読み込めるのは、どのランタイムとハードウェアか。重要なタスクについて、どのような証拠があるか。「オープンソース」は、性能の等級でも、プライバシーの保証でも、モデルがノートパソコンに収まるという約束でもありません。

以下の各節では、証拠が重みに関するものである場合には「オープンウェイト」を使い、「オープンソースAI」は、より強いシステム全体の水準の意味に限って用います。そうすることで、有用な技術的区別が宣伝用の略語に変わってしまうのを避けられます。

DeepSeek V4について確認されていることは何ですか？

DeepSeekのTransparency Centerは、DeepSeek-V4をリリース日2026年4月24日として掲載し、モデルカードと技術レポートにリンクしています。 ^[2] 同社の公式の変更履歴によると、APIは2026年4月24日からV4-ProとV4-Flashに対応しました。2026年9月10日の項目には、V4 Flashが廃止され、そのAPI名は一時的にV4.1 Flashへ振り向けられていると記されており、2026年11月11日時点で最新の項目である2026年10月17日付の記載では、そのモデルがV4.1-Flash-1017にアップグレードされています。 ^[6] これらの記述が裏づけているのは、モデルファミリーのリリースとAPIの変遷です。V4のすべての派生版が同一の重み、ライセンス、価格、ローカルデプロイの要件を持つという意味ではありません。

DeepSeekの2026年4月24日の発表は、V4 Previewを「オープンソース化した」と表現し、Hugging Face上のオープンウェイトにリンクしたうえで、V4-Proは総パラメータ数1.6T、アクティブパラメータ数49B、V4-Flashは総パラメータ数284B、アクティブパラメータ数13Bだと説明しました。 ^[7] 「オープンソース化した」というのは同社自身の言い回しです。特定のV4リリースがOSIの定義を満たすかどうかは、そのリポジトリとライセンスが実際に何を提供しているかによって決まります。こうした規模は重要です。モデルは、トークンあたりのアクティブパラメータ数が総パラメータ数より少なくても、相当なインフラとモデルファイルを必要とすることがあります。APIのモデルを個人のコンピューターで快適に動かせると推測してはいけません。

開発者は、APIのモデル名と、ダウンロードしたチェックポイントを区別してください。DeepSeekのドキュメントは、API名と互換性のための振り向けについて説明しています。主要なリリースを確認し、そのカードを見つける場所としては、Transparency Centerが適切です。 ^[2][6] ローカルにデプロイする場合は、API名から推測するのではなく、個別のモデルカード、重みの入手元、ライセンス、対応ランタイムを用いてください。

一般の読者にとって、DeepSeekは1つのファミリーとして理解すると役に立ちます。関連する名前のもとに、大規模なもの、ホスト型のもの、ローカル利用向けのものが存在しうるのです。実際に選ぶべきものは、正確なリリースと提供方法であり、ブランド名への忠誠ではありません。

Qwen3.8とKimi K3.1 Proはどう違いますか？

Qwen3.8-27Bは視覚と言語を扱うモデルで、公式カードには言語モデルのパラメータ数27BとApache 2.0ライセンスが記載されています。Hugging Faceによるリポジトリのファイル概要では、モデルサイズは28Bパラメータと表示されています。カードによると、このリポジトリには追加学習後のモデルの重みと設定ファイルがTransformers形式で含まれており、Hugging Faceのページは、llama.cpp、Ollama、LM Studio、その他の互換アプリ向けの量子化版にリンクしています。 ^[3] これらの量子化版は別々のリポジトリに置かれているため、それぞれを誰が公開したのかを確認してください。したがって、このモデルがローカルモデルの有力な候補になるのは、選んだ量子化、コンテキスト、ハードウェアが見合う場合に限られます。

Kimi K3.1 Proは、規模もライセンス上の位置づけも異なります。公開元のカードは、これをオープンウェイトのマルチモーダルなMixture of Expertsモデルと呼び、総パラメータ数2.8T、アクティブ化されるパラメータ数104Bを記載し、Kimi固有のライセンスを挙げています。 ^[5] 技術的には入手できても、普通のハードウェアでのローカル利用にふさわしい選択肢であるとは限らず、Apacheライセンスのモデルのようにライセンスされているとも限りません。

この2つのリリースは、パラメータ数だけでは「どちらが優れているか」に答えられない理由を示しています。Qwenの27Bという規模は、適切な量子化を使えば、ローカルで試しやすい場合があります。Kimiのはるかに大きな規模は、はるかに多くのメモリとデプロイ能力を備えたインフラを想定しているのかもしれません。正しい比較の軸は、タスク、出力の品質、遅延、コスト、ライセンス、ハードウェアであり、一方のファミリーがすべてのベンチマークで勝つという主張ではありません。

どちらのカードも、公開元による情報です。ベンチマークに関する主張や能力の説明は、評価の出発点として扱うべきであり、代表的なプロンプト、言語、失敗事例を試すことの代わりにはなりません。重大な結果を伴う用途では、人間によるレビューの段階と、独立した情報源確認のプロセスを残してください。

どのオープンモデルが何に向いていますか？

ローカルデプロイを学ぶためなら、目的の言語とタスクを扱える、サポートされた最小のモデルを選び、それを試してください。扱いやすいQwen互換の量子化版のほうが、はるかに大きなリリースよりも、最初の実験として現実的かもしれません。Hugging Faceは、GGUF、MLX、その他の形式について、LM Studio、Ollama、llama.cpp、MLX LMを含むローカルアプリでの利用方法を文書化しています。 ^[8]

ホスト型のワークフローでは、APIを使うことで、重みのダウンロード、ランタイムの選択、ハードウェアの維持といった負担を減らせます。それはサービスの選択であり、ローカルでのプライバシーの選択ではありません。DeepSeekのAPIドキュメントには、モデル名の変更とAPIのリリースが示されています。ユーザーは、機密性の高い内容を送信する前に、現行のサービス規約、価格、データの取り扱いを確認するべきです。 ^[6]

研究チームやインフラチームにとって、非常に大規模なオープンウェイトのリリースは、管理されたセルフホスティング、専門的な評価、適応を支えるものになりえます。同時に、運用上の作業も増えます。重みの入手、推論能力の管理、セキュリティ更新の適用、ライセンスの順守、出力品質の監視です。Kimi K3.1 Proの規模は、重みが入手できるからといって、こうしたコストがなくなるわけではないことを示しています。 ^[5]

マルチモーダルな作業では、どのモデルも画像、動画、文書を受け付けると決めてかからず、正確なモデルカードを確かめてください。QwenはQwen3.8-27Bを視覚と言語を扱うモデルと説明し、Kimiのカードはテキストと画像のモダリティを説明しています。 ^[3][5] それだけでは、特定の画像や文書に対する正確さについて、とりわけ慎重さを要する分野では、何も語っていません。

プライバシーが重要な作業では、ローカルで実行することで、ホスト型の提供者とプロンプトを共有することを減らせますが、それで自動的にプライバシーが守られるわけではありません。モデルのダウンロード、更新、ローカルのログ、バックアップ、プラグイン、ネットワークに公開されたサーバーは、それぞれ別個のリスクとして残ります。ハードウェアとプライバシーのトレードオフの全体像については、当サイトのローカルAIガイドをご覧ください。

オープンウェイトのモデルをどう評価すべきですか？

まずモデルカードを読んでください。公開元、モデルのリビジョン、ライセンス、想定されるタスク、アーキテクチャ、モダリティ、既知の限界、対応するデプロイ形式を確認します。カードは正確さの認証ではありませんが、公開元が何をリリースしたと述べているのかを知るための、最も直接的な情報源です。 ^[2][3][5]

次に、現実的なテストセットを1つ選びます。期待される事実が分かっている代表的なプロンプト、難しい境界事例、想定する言語を含む、小さなセットを使ってください。出力を、正しさ、網羅性、一貫性、有害な過信の観点から比較します。洗練された最初の応答や、1つの公開ベンチマークだけでモデルを判断してはいけません。

正確な環境を記録してください。モデルのリビジョン、量子化、コンテキストの上限、ランタイム、ハードウェア、プロンプトの与え方、ツールへのアクセスです。これらの変数が異なれば、同じ名前のモデルから2人のユーザーが異なる結果を得ることがあります。この記録があれば、有用な構成を再現したり、まずい回答の原因を調べたりすることも可能になります。

個人的な実験の範囲を超えてデプロイする前に、ライセンスを確認してください。OSIの定義は、オープンソースAIには重み以上のものが含まれることを説明しており、OSIによるオープンウェイトの解説は、重みだけではシステムを完全に利用し、研究し、改変し、共有するために必要なものに届かないと述べています。 ^[1][4] 商用利用、再配布、ファインチューニング、ホスト型サービスでの利用、帰属表示は、それぞれ異なる条件によって規律されていることがあります。

最後に、出力の境界線を適用してください。オープンモデルは、下書きを作り、翻訳し、分類し、情報の探索を助けることができます。しかし、独立した最新の証拠と適切な専門家の判断なしに、法律、金融、医療、安全、セキュリティに関する決定の最終的な拠り所にするべきではありません。

混乱せずにオープンモデルをローカルで動かすにはどうすればよいですか？

モデルファイルをダウンロードする前に、ランタイムを決めてください。Hugging Faceは、互換性のあるローカルアプリケーションと形式を一覧にしています。たとえば、LM StudioはGGUFとMLXのモデルに対応し、OllamaはGGUFに対応し、MLX LMはMLXのテキスト生成モデルに対応しています。 ^[8] 形式の合わないモデルファイルは、役に立つダウンロードではありません。

公開元の公式ページか、定評のあるモデルホスティングサービスから始め、そのうえでコンピューターに合う形式を選びます。Qwen3.8-27BのHugging Faceのページは量子化版にリンクしていますが、基本となる27Bのリリースそのものは、あらゆるデバイスがあらゆる版を読み込めるという主張ではありません。 ^[3] モデルのディスク上のサイズを必要量のすべてとして扱うのではなく、オペレーティングシステムとコンテキストのためにメモリの余裕を残してください。

最初のサーバーは同じコンピューターの中だけにとどめ、差し支えのないデータで試してください。別のデバイスから使いたいというだけの理由で、ローカルモデルのエンドポイントを公開インターネットにさらしてはいけません。後になってネットワークサービスが必要になった場合は、認証を使い、ランタイムに修正を適用し、誰がそこにプロンプトを送れるのかを把握してください。

設定にはバージョン管理を使い、モデルのライセンスの記録を残しておきましょう。ローカルモデルは、技術的には簡単に動かせても、計画しているサービスには法的に適さないことがあり、その逆もあります。秩序立った実験のほうが、出所のはっきりしない巨大なファイルを何度もダウンロードするよりも、安全で有用です。

モデルがうまく答えられないときは、変数を1つずつ変えてください。より小さなコンテキスト、別の量子化、別のランタイム、あるいはタスクにより合ったモデルです。パラメータ数を増やすことだけが解決策ではありません。

2026年のオープンモデルで、読者は何に注目すべきですか？

リリースの識別情報を注意深く見てください。DeepSeekの公式ページは、V4、V4-Pro、V4-Flash、そしてV4.1-FlashへのAPIの変更を区別しています。 ^[2][6] 「DeepSeek V4」と書かれた見出しは、読者が使おうとしているものとは異なる正確なモデルや提供経路を指しているかもしれません。

ライセンスとデプロイの詳細を、能力と同じくらい綿密に見てください。Qwen3.8-27Bの公開ページはApache 2.0を明示し、Kimi K3.1 ProはKimi固有のライセンスを明示しています。 ^[3][5] これらの表示は、実際のリポジトリの中で読むべきです。基本モデル、コミュニティによる量子化版、派生モデルでは、ドキュメントが異なることがあるからです。

タスクに合った証拠に注目してください。コーディングのベンチマークは文書理解について決着をつけるものではなく、長いコンテキストに関する主張は事実の正確さについて決着をつけるものではなく、モデルが画像に対応していることは画像に対する信頼性について決着をつけるものではありません。オープンなリリースはテストと適応を容易にしますが、評価の必要性をなくすものではありません。

リリースノートだけでなく、運用上の変化にも注目してください。ホスト型のAPIは、DeepSeekのV4の変更履歴が示すように、エンドポイントの名前を変えたり、振り向けたり、廃止したりすることがあります。 ^[6] APIに依存するチームは、本番で使う前に代替となるものを必ずテストし、予備の手順を残しておくべきです。セルフホスティングを行うチームは、その代わりに、ダウンロードの完全性、ランタイムのアップグレード、ストレージ、処理能力について計画しなければなりません。どちらの道も、永久に保守が不要になることはありません。稼働開始の前に、ロールバックを計画し、監視のための予算を確保し、それぞれの運用上の責務を誰が担うのかを文書化してください。

モデルカードのリビジョン、参照したライセンスの文面、ランタイムのバージョン、評価用のプロンプト、観察された失敗のパターンを収めた証拠ファイルを保管してください。これは個人のプロジェクトにとってはささやかな作業であり、組織での利用には不可欠です。オープンなリリースについての魅力的な主張を、再現可能な判断へと変えてくれます。また、モデルの限界を、量子化、プロンプト設計、ローカル設定の誤りから区別する助けにもなります。

変わらず残る選択は、抽象的なDeepSeek対Qwen対Kimiではありません。ユーザーが維持できるデプロイの体制のもとでタスクを満たす、最も小さく、ライセンスが最も明確で、能力を検証できる、正確なモデルを選ぶことです。