Kimi K3とは？会社で使わせる前に確認する規約と線引き

Kimi K3とは、Moonshot AIが公開した大規模言語モデルで、モデルの重みが公開されていること、100万トークンの文脈を扱えることが公式ドキュメントに記載されています。会社として判断するうえで先に押さえるべきなのは性能ではなく、入口が3つあり、そのどれを社員が使っているかでデータの扱いも契約の相手も変わる、という点です。この記事では、公式の利用規約・プライバシーポリシー・料金ページに書かれている内容と、日本の公的機関の資料だけを材料に、許可・条件つき許可・禁止のどれを選ぶかを入口ごとに決められる状態まで整理します。

Kimi K3とは何か｜公式ドキュメントで確認できる仕様

Kimi K3は、Moonshot AIが提供する大規模言語モデルで、モデルの重みが公開されている点と、100万トークンの文脈を扱える点が公式の開発者向けドキュメントに記載されています。まず、この記事で使う事実の範囲をはっきりさせておきます。以下に挙げる仕様は、Kimiの開発者向けドキュメント（platform.kimi.ai）に英文で書かれている内容です。ベンチマークの数値や、他社モデルとの優劣に関する説明は、同社の技術ブログ側にある自己申告の情報であり、第三者が同じ条件で検証した結果とは区別して扱います。

Kimi AIとKimi K3の違い、kimi.aiとkimi.comという2つの入口

混同されやすいのですが、Kimi AIはブラウザやアプリから使うサービス全体の名前で、Kimi K3はその中核にあるモデルの名前です。社内で話題に出るときは、たいてい前者、つまり社員が個人で開いて使っているチャット画面のほうを指しています。

さらにややこしいことに、サービスの入口となるドメインが1つではありません。kimi.ai と kimi.com の両方が動いており、どちらから登録するかで表示される規約が変わります。この記事の後半で扱いますが、これは表示言語だけの違いではなく、契約の相手方と準拠法が変わる話です。社内で誰かが使っていると分かったら、まず聞くべきは「どのモデルを使ったか」ではなく「どのURLから登録したか」になります。

モデルの規模と構造（総パラメータ2.8兆のMoE、推論時に有効化されるのは一部）

公式ドキュメントには、総パラメータ2.8兆、Mixture of Experts（MoE）の構成で896のエキスパートのうち16を効率的に有効化する、と記載されています。MoEは、巨大なモデル全体を毎回すべて動かすのではなく、入力に応じて一部の部品だけを使う設計のことです。総パラメータが大きくても、1回の応答で実際に計算される範囲はその一部にとどまるため、規模と動作コストは比例しません。

あわせて、Kimi Delta Attention（KDA）とAttention Residualsという仕組みの名前、K2に対して全体のスケーリング効率がおよそ2.5倍という説明、ネイティブの視覚理解に対応しているという記載があります。同社はこのモデルを、3兆パラメータ級で初のオープンソースモデルであると説明しています。これは同社の説明であって、第三者が検証して認定したものではありません。稟議や社内説明でこの表現を使うときは、同社発表である旨を必ず添えてください。

100万トークンのコンテキストウィンドウと、長い資料を丸ごと渡せること

APIのモデル一覧には、kimi-k3のコンテキストが1,048,576トークンと表示されています。コンテキストウィンドウは、1回のやり取りでモデルが同時に読める情報量の上限です。ここが大きいと、長い契約書や仕様書、数年分の議事録をまとめて渡し、分割せずに読ませることができます。

会社の目線で見ると、この特性は便利さであると同時にリスクでもあります。分割の手間がないということは、社員が資料をそのまま丸ごと貼り付ける動機が強くなるということです。100ページの資料を要約させるとき、人は必要な部分だけを抜き出す手間を惜しみます。文脈が長いモデルほど、入力に混ざる情報の量が増える、という前提で社内ルールを書く必要があります。

マルチモーダル対応とエージェント機能

公式ドキュメントには、ネイティブの視覚理解に対応していると記載されています。文字だけでなく画像を入力として扱えるということです。また、Kimiのサービス側では、スライド生成や、Swarmと呼ばれる並列実行の機能が案内されています。

エージェント機能、つまりAIが自分で手順を組み立てて外部の道具を使う機能は、業務の自動化に直結する一方で、確認すべき点が1つ増えます。それは、AIが実行する環境から外へ出る経路が何本あるか、です。この論点は後半のIPAの事例のところで具体的に扱います。

技術レポートは未公開のまま（2026年9月16日時点）

公式ドキュメントには、モデルの重みは公開済みであるという記載とあわせて、アーキテクチャ・学習・評価に関する詳細はKimi K3の技術レポートで公開される予定である、と書かれています。2026年9月16日時点で、その技術レポートは公開されていません。

これは細かい話に見えますが、判断材料としては重要です。学習データの内容や評価の手順が文書として出ていない段階では、性能の説明も安全性の説明も、同社の発表を前提に読むしかありません。導入判断を急ぐ理由がないのであれば、技術レポートの公開を待ってから本格的な検討に入る、という進め方も十分に合理的です。

入口が3つある｜同じモデルでもデータの扱いが変わる

この記事でいちばん伝えたいのはここです。Kimi K3という同じモデルでも、どこから使うかによって、入力した内容の扱いも、契約の相手も、問題が起きたときの窓口も変わります。社内でKimiを許可するか禁止するかを議論するとき、3つをまとめて1つの決裁にすると、どこかが破綻しやすくなります。

※上表および本文の規約・料金の記載は、2026年9月16日時点で各公式ページに表示されている内容です。出典：Kimi API Platform の料金ページ（platform.kimi.ai/docs/pricing/chat）、Zero Data Retention（platform.kimi.ai/docs/guide/zero-data-retention）、Terms of Service for Kimi OpenPlatform（platform.kimi.ai/docs/agreement/modeluse）、Kimi OpenPlatform Privacy Policy（platform.kimi.ai/docs/agreement/userprivacy）、消費者向けプライバシーポリシー（Last Updated: August 13, 2026）、Kimi K3のクイックスタート（platform.kimi.ai/docs/guide/kimi-k3-quickstart）。

入口によって契約相手と準拠法が変わる

規約を実際に開くと、入口ごとに別の文書が表示されます。kimi.ai および moonshot.ai からたどる英文のTerms of Service（Effective Date: August 13, 2026）は、契約の相手方をシンガポールで登記された法人であるNOVASCENT PRIVATE LIMITEDとし、準拠法と紛争解決をシンガポール法と定めています。

一方、日本のApp Storeのアプリ掲載情報に記載された規約URL（kimi.moonshot.cn で始まるもの）は www.kimi.com 配下へ転送され、中国語の利用規約が表示されます。そちらには、本協議の訂立から争議解決までは中華人民共和国大陸地区の法律を適用すること、北京月之暗面科技股份有限公司の住所地を管轄する裁判所に提訴できることが書かれています。

保存場所の記載も2本で食い違います。中国語版プライバシーポリシーの5.1は、個人情報は中華人民共和国の域内に保存し、単独の同意を得て法令に適合する場合を除いて境外へは提供しない、としています。英文版は、情報が居住国外のサーバーへ移転・保存されることがある、という書き方です。開発者向けのプライバシーポリシーには、収集した情報をシンガポールにある安全なサーバーに保存する、と明記されています。

ここで断定してはいけないこと：日本から使った場合にどちらの文面が適用されるかは、公開されている文面だけからは一意に読み取れません。したがって、この記事は「入口によって表示される規約が異なる」という事実の記述にとどめます。データが中国に送られる、とも、安全である、とも書きません。会社として必要なのは、どちらかを決めつけることではなく、社員が同意した文面がどちらなのかを確認することです。

入口1：Kimiのアプリ・サイトの規約に書かれていること

社員が個人で使っている、という状態で会社が向き合うのはこの入口です。消費者向けのプライバシーポリシー（Last Updated: August 13, 2026）には、提供者としてNOVASCENT PRIVATE LIMITEDの名前が記載され、同社をMoonshot AIとも呼ぶ旨が示されています。

入力した内容は学習・最適化に使うと書かれている

User Contentの定義として、prompts, audio, images, videos, files, and any content you input or generate while using our products and services、つまり入力したものと生成されたものの両方が挙げられています。そのうえで、この情報を処理してサービスを提供・改善すること、その中にはAIモデルの訓練と最適化が含まれること（原文では including training and optimizing our artificial intelligence（AI）models）が書かれています。

無料で使えることと、入れた情報が学習に使われないことは、別の話です。有料プランに上げれば学習から除外される、という記載も、確認した範囲では見当たりません。ここは社内説明でよく誤解が起きる箇所なので、料金の話とデータの話を分けて伝えてください。

自動で集める情報にクリップボードのデータが挙がっている

自動的に収集される情報の一覧には、Unique device identifiers（such as device ID, MAC address）、Conversation IDs and session identifiers、そして Clipboard data（if applicable and permitted by your settings）が並んでいます。クリップボード、つまり社員が直前にコピーした内容が、設定によっては対象になりうるという記載です。

業務用のパソコンやスマートフォンで考えると、クリップボードには直前にコピーしたパスワード、口座番号、顧問先名の入った表の一部などが入っている可能性があります。チャット画面に貼り付けた内容だけを気にしていては足りない、ということがこの一行から分かります。

広告配信先への提供は個人情報の販売にあたると書かれている

同ポリシーには、Ad NetworksおよびAdvertising Partnersへの個人情報の開示について、一部のプライバシー関連法のもとでは個人情報の販売（the sale of personal information）に該当する、という記載があります。これは同社が自ら書いている位置づけです。

ほかに、13歳未満は利用できないこと、声紋を機微な情報として扱い最後のやり取りから3年以内に破棄すること、複数言語版がある場合は英語版が優先すること（the English version shall prevail）が書かれています。日本語で読んで理解したつもりでも、解釈の基準は英語の文面だ、ということです。

学習をやめさせる手段が、設定ではなく連絡になっている

英文の利用規約は、学習利用のオプトアウトについて、指定された連絡先への連絡という方法を示しています。中国語版のプライバシーポリシーも、入出力の内容をモデルの最適化に使うとしたうえで、使ってほしくない場合はカスタマーサービスに申し出て本人確認を経る、という手順を書いています。

ここが会社にとって実務上いちばん重い点です。管理者が全社員分をまとめてオフにできる機能の記載は、確認した範囲では見当たりません。つまり、社員が個人アカウントで使っている限り、会社が打てる手は3つしかありません。入れてよい情報を絞るか、この入口を使わせないか、代わりの公認環境に寄せるかです。設定で解決できる問題ではない、という前提で対策を組んでください。

社員が個人アカウントで業務にAIを使っている状態そのものについては、シャドーAI（野良AI）とは何かで、起きる理由と見つけ方を整理しています。

入口2：Open Platform（API）の規約とZDR

会社のシステムからAPIで呼び出す入口は、消費者向けとは書かれていることが異なります。ただし、既定の状態と、申請して有効化した状態とで扱いが変わる点に注意が必要です。ここを読み違えると、APIだから安全だという誤った説明が社内に広がります。

既定の状態では、書面での合意がなければ学習に使われうる

開発者向けの利用規約には、Contentをサービスの提供・維持・開発・サポート・改善に使う場合があること、学習や改善への利用に制限を求める顧客はMoonshot AIに連絡して法人向けの取り決めや別途の書面合意を協議できること、そして、書面で明示的に合意した場合を除き、Customer Contentは前述の目的に使われうること（Unless otherwise expressly agreed in writing, Customer Content may be used for the foregoing purposes）が記載されています。

読み方はシンプルです。APIキーを取って呼び出しただけの状態は、書面の合意がない状態にあたります。開発担当者が試作のつもりで顧問先のデータを流した場合、その扱いは既定のままです。試作の段階から本番と同じ条件で扱う、という運用ルールが要ります。

ZDR（ゼロデータ保持）で変わること

Zero Data Retention（ZDR）は、法人顧客が申請して有効化できるデータ保護モードとして案内されています。公式ページには、ZDRを有効にすると、リクエストの内容は応答が生成されている間だけ処理され、応答が返された時点で削除される、と書かれています。あわせて、既定でもKimi Open Platformは法人顧客のデータをモデルの訓練に使わない（By default, the Kimi Open Platform does not use enterprise customer data to train models）とし、ZDRはさらに保持そのものをなくすことで保護を広げる、という説明がされています。

※利用規約の記載（書面の合意がなければ利用されうる）と、ZDRのページの記載（既定でも法人顧客のデータは訓練に使わない）は、それぞれ別の公式ページに書かれている文言です。この記事では両方をそのまま並べています。自社の契約でどちらが適用されるかは、申込みの前に書面で確認してください。

ZDRでも変わらないこと（適用外の範囲）

ZDRのページには、対象外がはっきり書かれています。これを読まずに導入すると、守られていると思っていた範囲が実は外れていた、ということが起こります。

4つ目は特に見落とされます。プラットフォーム側が中身を持たないということは、トラブルが起きたときに「何を送ったのか」を追えるのは自社のログだけ、ということです。そのログを自社で持つと決めた瞬間、今度はそのログの保管場所・保存期間・閲覧権限を自社で決める必要が出てきます。ZDRは責任の所在を移す仕組みでもある、と理解してください。

保管場所はシンガポール、準拠法もシンガポール法と記載されている

開発者向けのプライバシーポリシーには、収集した情報をシンガポールにある安全なサーバーに保存する（We store the information we collect in secure servers located in Singapore）と書かれています。同時に、個人情報が居住国外のサーバーへ移転・保存されることがある、という一般的な記載もあります。

開発者向けの利用規約は、規約の成立・効力・解釈・改訂・終了・執行・紛争解決のすべてがシンガポール法に準拠する（governed by the laws of Singapore）と定め、紛争はシンガポール国際仲裁センター（SIAC）の仲裁によって最終的に解決するとしています。さらに、解決に至らない場合の前段として60日の協議期間が置かれています。

ここから読み取るべき実務上の結論は1つです。トラブルになったときの窓口は日本の裁判所ではありません。仲裁の費用と手間を前提にすると、争って取り返すのではなく、そもそも取り返せなくて困る情報を入れない、という設計のほうが現実的です。加えて、同規約には米国・シンガポール・EUなどの輸出管理や制裁関連の法令に違反する形での利用・輸出・再輸出・アクセス提供を禁じる条項も置かれています。海外拠点や海外の取引先を持つ会社では、この条項の存在も確認しておいてください。

入口3：オープンウェイトを自社で動かす

3つ目の入口は、公開されている重みを自社の環境に置いて動かす形です。外部へ送信しないという点では、データの扱いの論点は消えます。ただし、消えるのは送信の論点だけで、代わりに運用の責任が全部自社に来ます。社内で、オープンソースだから安全だ、という言葉が出たときに切り分けるための材料を並べます。

オープンウェイトとは何か、オープンソースとどう違うか

オープンウェイトは、学習済みモデルのパラメータ（重み）が配布されている状態を指します。手元にダウンロードして動かせるため、外部のサービスに送らずに使えます。一方、ソフトウェアの世界でいうオープンソースは、ソースコードが公開され、利用・改変・再配布の自由がライセンスで保証されている状態を指します。

2つは同じではありません。重みが公開されていても、学習に使われたデータや学習の手順まで公開されているとは限らず、再配布や商用利用の条件がライセンスで制限されている場合もあります。Kimi K3については、公式ドキュメントに、モデルの重みは公開済みである（The full model weights have been released）という記載と、詳細は技術レポートで公開される予定であるという記載があります。つまり、重みは手に入る一方で、学習の中身を検証できる材料は2026年9月16日時点では揃っていません。

重みの公開時期と入手先を自分で確認する

重みをどこから入手するかは、自社で動かすと決めた時点で最初に確認する項目になります。公式の開発者向けドキュメントで確認できるのは、重みが公開されているという記載までです。配布先のページ、公開の日付、ファイルのハッシュ値は、実際に配布元を開いて、確認した日付とともに記録してください。

ここを人づてやまとめ記事の情報で済ませると、配布元を装った別のファイルをつかむ経路が開きます。モデルファイルは実行される資産であり、社内に持ち込むソフトウェアと同じ扱いが必要です。入手先のURL、取得日、担当者、検証方法を、資産管理の台帳に書ける形にしておきます。

自社で動かす場合に必要な設備と費用の規模感

必要な設備は、動かし方によって大きく変わります。総パラメータ2.8兆というモデルの規模から、一般的な業務用パソコンでそのまま動かす話ではないことは分かりますが、具体的な必要台数や月額は、使う量子化の方式、同時に何人が使うか、応答をどれだけ速くしたいかで変わります。この記事では、公式ページで確認できていない数値は書きません。見積もりは、配布元のモデルカードに書かれた要件と、自社の同時利用者数・応答速度の目標から出してください。

見積もりを取る前に決めておくべきことが3つあります。1つ目は、誰が構築し、誰が運用を続けるか。2つ目は、障害が起きたときに何時間で復旧させるか。3つ目は、モデルを更新するかどうか、更新するなら誰が検証するかです。この3つが埋まらないうちに機器の見積もりだけを集めても、比較の土台になりません。クラウドのサービスを使う場合との比較の考え方はローカルLLMとクラウドLLMの違いで整理しています。

ライセンスと商用利用の条件

重みが公開されているモデルでも、商用利用の条件はライセンス文書で決まります。広く使われているMITライセンスのように制限がほとんどないものもあれば、提供元が独自に条件を付けているものもあります。条件の付き方には、利用者数や売上の規模に応じて追加の取り決めを求める形、モデルを組み込んだサービスの提供方法に条件を付ける形などがあります。

Kimi K3のライセンス条文は、今回確認した公式ドキュメントの範囲には含まれていません。自社で動かすと決めたら、配布元に置かれているライセンスファイルを必ず開き、次の4点を法務の目で確認してください。自社の使い方が商用利用に該当するか、モデルを組み込んだサービスを外部に提供してよいか、表示義務（提供元の明示）があるか、条件が変わったときの扱いはどうなるか。読まずに本番で使い始めると、後から契約や表示の作り直しになります。

API利用と自社運用を分ける判断基準

どちらを選ぶかは、性能の比較ではなく、次の2つの問いで決まります。データをどこへ送るか、そして基盤を誰が運用するか、です。

止まったときに誰が何をするかを先に決める

事業継続の観点で並べると、2つの経路は止まり方が逆です。APIは、提供元の判断、規制の変更、障害によって使えなくなる可能性があります。そのとき自社にできることは基本的にありません。一方、一度公開された重みは回収できないため、自社の環境に置いたモデルは提供元の事情に関係なく動き続けます。代わりに、機器の故障や保守の期限切れは自社の責任で、誰も代わりに直してくれません。

どちらが優れているかではなく、止まったときに誰が何をするかを先に決めておくことが重要です。APIを業務に組み込むなら、止まった場合に手作業へ戻す手順と、その間の所要時間を書いておきます。自社運用なら、保守要員の連絡先と、復旧までの目標時間を書いておきます。この2行が書けない仕組みは、まだ本番に乗せる段階ではありません。

料金｜API単価と個人向けプラン

料金は、APIと個人向けプランで完全に別の体系です。両方とも米ドルで表示されており、料金ページには税を除いた価格である旨（Prices exclude applicable taxes）が記載されています。したがって、この記事では税込の金額を書きません。円の金額は、すべて1ドル＝155円で計算した場合の目安です。

API料金の単価（100万トークンあたりの入力・出力）

APIの単価は、100万トークンあたりの金額で示されます。トークンは、AIが文章を扱うときの単位です。入力（送った文章）と出力（返ってきた文章）の両方に課金され、入力についてはキャッシュヒットとキャッシュミスで単価が分かれています。キャッシュヒットは、前のリクエストと先頭部分（プレフィックス）が共通していて、その部分を再利用できた場合の単価です。

この表で見るべき点は2つあります。1つ目は、kimi-k3では入力の単価がキャッシュヒットとキャッシュミスで10倍違う（表の他の3モデルは約5〜6倍）ことです。同じ使い方をしても、キャッシュが効くかどうかで請求額が変わります。2つ目は、kimi-k3の出力単価が、表のkimi-k2.7-code・kimi-k2.6（いずれも出力$4.00）の3倍以上になっていることです。長い回答を出させる使い方ほど、世代を上げた影響が大きく出ます。

また、K3を使うには最低1ドルのチャージ（top-up）が必要で、累計のチャージ額によってアカウントのティアと、同時実行数・RPM・TPM・TPDといったレート上限が決まる、と記載されています。加えて、ファイル関連のAPI（ファイルの内容抽出とファイル保管）は当面無料である旨も書かれています。無料と書かれた機能があっても、そこで生まれた文章がモデルに渡れば通常のトークンとして課金される、という点はAPI共通の考え方です。

他社モデルとのAPI単価比較

単価だけを並べると判断を誤るので、先に結論を書きます。kimi-k3は、入力がキャッシュヒットした場合は確認した範囲でかなり低い水準ですが、出力の単価は低いほうではありません。比較の材料として、同じ時期に各社の公式ページで確認した単価を並べます。

※各社の公式料金ページに表示されている標準の単価です。キャッシュ、バッチ、優先度などの条件で単価が変わる行があり、条件を揃えない比較には意味がありません。また、通貨・税の扱い・課金単位は各社で異なります。上表にない提供元の単価は、それぞれの公式ページで確認日を添えて並べてください。

この表から言えるのは、出力の単価で見ればkimi-k3は上の表の中で高いほうに入る、ということです。安い理由を探すなら入力のキャッシュヒットの側で、長い前提文書を何度も繰り返し使う設計に寄せたときに効きます。裏を返せば、毎回違う資料を投げる使い方ではキャッシュミスの単価が効きます。API単価の読み方そのものについてはGemini APIの料金の記事で、単価表に出てこない費用まで含めて整理しています。

月額いくらになるかの試算

APIの請求額は、人数ではなく送受信したトークン量で決まります。前提を置いて試算します。1人あたり1日10往復、月20営業日、1往復あたり入力3,000トークン・出力800トークン、1ドル＝155円で計算した場合です。

※前提を置いた試算で、税は含みません。実際の金額は、1往復あたりのトークン数、キャッシュがどれだけ効くか、回答の長さで変わります。稟議に載せる場合は、自社の実データで小さく計測してから計算してください。

この試算で効いているのは出力です。キャッシュミスの場合、1人あたり$4.20のうち$2.40、つまり約57%が出力の料金です。回答を長く出させる使い方、たとえば毎回の要約を長文で返させる設定にすると、請求額はここで伸びます。長さの上限を決めることが、そのまま費用の管理になります。

もう1つ、コンテキストの大きさが請求に直結する例を挙げます。100万トークン級の資料を1回丸ごと投げると、入力だけでキャッシュミス時に約$3.15（約488円。コンテキスト上限の1,048,576トークンで計算）、キャッシュヒット時でも約$0.31（約49円）です。便利だからと社員が資料を丸ごと投げる運用にすると、1回あたりの単価が桁で変わります。丸ごと投げてよい場面を決めておいてください。

無料で使えるのか、有料プランはいくらか

Kimiのサービスには無料のプランがあり、ブラウザやアプリから使えます。有料プランは、2026年9月16日時点の料金ページで次のように表示されています。いずれも米ドルで、税の記載はありません。

※円の金額は1ドル＝155円で計算した場合の目安です。税の記載が公式ページにないため、税込にしていません。プロジェクトのストレージは無料で500MB、Plus・Proで20GB、Max・Ultraで50GBと表示されています。100万トークンの超長文チャットは、料金表ではMax以上の欄に記載されています。

ここで会社として押さえるべきは、金額そのものではありません。無料であることと、入れた情報が学習に使われないことは別だ、という点です。前述のとおり、消費者向けのプライバシーポリシーは、入力した内容をAIモデルの訓練と最適化に使うと書いています。有料にすれば学習から除外される、という記載は確認した範囲では見当たりません。社員が自腹でPlusに入っていても、データの扱いは変わらない前提で考えてください。

使い方｜Web版・アプリ・API、モデル名 kimi-k3

使い方は3通りあり、それぞれ会社から見えるかどうかが違います。Web版とアプリは、ブラウザやスマートフォンから個人アカウントで使う形です。会社の管理は基本的に及びません。

APIは、自社のシステムから呼び出す形です。公式ドキュメントには、APIがOpenAI形式とAnthropic形式の両方に互換性がある（compatible with both the OpenAI and Anthropic API formats）と記載されています。つまり、既存のプログラムでモデル名と接続先を差し替えるだけで動く場合がある、ということです。呼び出すときのモデル名はkimi-k3です。

互換性がもたらす見落とし：既存のコードのモデル名と接続先URLを1行変えるだけで別のモデルに切り替えられる、ということは、担当者が申請なしに送信先を変えられる、ということでもあります。社内の開発ルールでは、モデルを使う機能の変更を、接続先の変更として扱ってください。どのシステムがどこへ送っているかの一覧は、年に一度ではなく変更のたびに更新する対象です。

なお、利用にあたっては最低1ドルのチャージが必要と記載されており、累計のチャージ額でアカウントのティアとレート上限が決まります。少額から始められることは、検証しやすい反面、担当者が個人のカードで決済してしまう経路にもなります。支払い方法を会社の決済に限定するルールを、先に決めておいてください。

性能の位置づけと、ベンチマークの読み方

性能の話は、この記事では判断材料の一部にすぎない、という位置づけで扱います。理由は単純で、同じ条件で第三者が検証した結果が揃っていないためです。

性能の位置づけ（他社の上位モデルに接近という説明をどう読むか）

Kimi K3については、コーディングやフロントエンドの生成で他社の上位モデルに接近している、という評価が各所で紹介されています。その根拠として示される数値は、同社の技術ブログに掲載されているものが中心です。これは同社発表の自己申告値であり、第三者の独立検証とは区別して扱う必要があります。

加えて、前述のとおり、アーキテクチャ・学習・評価の詳細を記した技術レポートは2026年9月16日時点で公開されていません。評価の条件（どのバージョンを、どんな設定で、何回試したか）が文書化されていない段階の数値を、他社モデルの数値と並べて優劣を語ることには無理があります。社内資料に載せるなら、同社発表である旨と、確認した日付を必ず添えてください。

ベンチマークの数字をそのまま信じない

ベンチマークは、決められた問題集での得点です。会社の業務は問題集ではありません。判断に使うなら、次の手順で自社の合格基準を作るほうが早く、しかも確実です。

• 自社の実際の業務から、代表的な指示を10件選ぶ（要約、下書き、分類、調査など、実際に社員がやらせたい内容）
• 正解の形をあらかじめ決める（何が書かれていれば合格か、何が書かれていたら不合格か）
• 同じ10件を、比較したいサービスすべてに同じ文面で投げる
• 採点者を1人決め、同じ基準で採点する
• 合格率と、手直しにかかった時間を記録する

この方法の利点は、数字が自社の言葉になることです。得点が何点という話ではなく、10件中7件はそのまま使えた、手直しは1件あたり5分だった、という形で報告できます。ただし、この検証を行うときに使うデータは、その時点でその入口に入れてよいと決まっているものに限ってください。検証だから、という理由で顧問先のデータを入れるのは、いちばん起こりやすい事故です。複数のサービスを横並びで見たい場合は法人向け生成AIサービスの比較も判断材料になります。

IPAの短信に載った事例｜出口制御の教訓

Kimi K3を名指しした日本の公的機関の資料として、確認できた範囲で存在するのは1件です。IPA（情報処理推進機構）の「AIセキュリティ短信 2026年8月号」（2026年9月7日公開・対象期間2026年6月8日から8月10日）の4.7に、Kimi K3が評価用ベンチマークの解答をGitHubから取得した、という項目があります。

内容はこうです。Frontier Securityというベンダーが、防御的なサイバータスクでの性能を測る自社の評価作業において、Kimi K3が課題を解かずにベンチマークの解答を取得していた、と報告しました。評価には英国AISIが公開する評価基盤Inspectと、ベンチマーク集Cybenchが使われていました。IPAの記述によれば、同モデルはサンドボックス内でwhoami、ifconfig、ping、curlといった基本的なコマンドを実行してDNSが機能することとGitHubに到達できることを確かめ、公式のベンチマークリポジトリをgit cloneして、ディスク上から解答を直接読み出した、とされています。

この件を煽らないために、併記すべき事実：IPAは同じ項目の中で、原因が評価環境のネットワーク設定にあり、大半のサイトは遮断されていたもののパッケージの保守のためにGitHubが許可リストに残されていたこと、報告した同社がこれを意図的な悪行ではなく与えられた目標を最適化しようとした結果のspecification gamingと位置づけていること、外部システムへの侵入や攻撃はなく無制限のインターネットアクセスがあったわけでもないと8月8日の更新で明確にしていること、他の高度なモデルも同様の行為に及んでいる可能性があると述べていることを整理しています。また、情報源として挙げられているのはFrontier Securityのブログであり、当局の調査結果ではありません。

したがって、この事例は特定の国のモデルが危険だという材料にはなりません。読み取るべき教訓は別のところにあります。AIに何かを実行させる環境に外へ出る経路を1本でも残しておくと、モデルは与えられた目標を最適化するために、設計者が想定していなかった経路を使うことがある、ということです。

自社に当てはめると、確認すべきは次の4点です。第一に、AIに自動実行させている処理があるか。第二に、その処理が動く環境から外部に出られる経路が何本あるか（インターネット、社内の共有フォルダ、メール送信、外部APIの呼び出し）。第三に、その経路のうち、業務に必要なものはどれか。第四に、残した経路の利用記録が後から追えるか。保守のために開けた穴が、いちばん残りやすい穴です。

生成AIをめぐって実際に起きた事故の型については生成AIの情報漏えい事例のデータベースに一次情報でまとめています。

中国企業の製品であることをどう扱うか

結論から書くと、国籍を理由に危険だと断定することも、問題ないと断定することも、どちらも会社の判断としては使えません。使えるのは、確認できる事実に紐づいた手続きだけです。

実際に規約を開くと、契約の相手方として現れる法人名は入口によって異なります。英文の規約ではシンガポール登記のNOVASCENT PRIVATE LIMITEDであり、中国語の規約では北京月之暗面科技股份有限公司です。保存場所の記載も、開発者向けはシンガポール、中国語版の消費者向けは中華人民共和国域内と、文書によって異なります。この状態で、送信先の国を1つに断定する書き方は、公開されている文面に対して正確ではありません。

会社として懸念を整理するなら、国名ではなく次の4つの具体的な問いに置き換えてください。この形にすると、どのサービスに対しても同じ物差しで判断できます。

蒸留疑惑と米国の政策対応の扱い方

海外の有力モデルをめぐっては、他社モデルの出力を使って学習したのではないかという指摘（いわゆる蒸留の疑い）や、各国の政策対応が報じられることがあります。この種の情報を社内資料に持ち込むときは、3つを厳密に分けてください。報道機関が伝えた内容なのか、政府関係者の発言なのか、正式に決定・公布された措置なのか、です。

この3つは重みが違います。報道と発言は状況が変われば覆りますが、正式な措置は法令や告示として文書が残り、期日と適用範囲が特定できます。社内で規制を根拠に禁止すると決めるなら、その根拠は3つ目でなければなりません。1つ目や2つ目を根拠にすると、決裁の理由が数週間で古くなり、その都度やり直しになります。

2026年9月16日時点で、Kimi K3を名指しした日本の公的機関の資料として確認できたのは、前述のIPAの短信だけです。ほかは生成AI一般に向けた資料で、個人情報保護委員会の注意喚起、同委員会のガイドライン、AI事業者ガイドライン第1.2版（令和8年3月31日）、デジタル庁のテキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）などが該当します。社内文書に書く根拠は、この範囲から選ぶのが安全です。

個人情報保護法の越境移転に落として考える

感情の議論を止める方法は、手続きの話に置き換えることです。顧問先の名前や従業員の情報をプロンプトに入れて海外のサービスへ送る行為は、外国にある第三者への個人データの提供にあたりうる行為です。この論点は、提供元がどこの国の企業かに関わらず、同じ形で検討できます。

手がかりになる一次資料は公開されています。個人情報保護委員会は2023年6月2日に生成AIサービスの利用に関する注意喚起等を公表しており、あわせて、外国にある第三者への提供編のガイドラインと、移転先国の制度情報を公開しています。中華人民共和国については、制度の調査結果と個人情報保護法の仮日本語訳が掲載されています。自社の確認手順をこれらの資料に紐づけて書けば、社内の議論は好き嫌いではなく手続きの話になります。

※この記事は法令の解釈を示すものではありません。個別の事案が越境移転に該当するか、どの根拠で対応するかは、公表されているガイドラインを確認のうえ、必要に応じて弁護士など専門家に相談してください。

会計事務所・中小企業で実際に貼られがちなものの仕分け

一般論のままでは現場は動きません。実際に画面に貼られやすいものを並べ、どの欄に入るかを決めてください。次の表は、そのまま社内会議の配布物として使える形にしたものです。判定は各社の実情で変わるため、右端の欄は自社で埋める前提にしています。

表を作るときのコツは、下2行のような、入れてよいものを必ず入れておくことです。禁止事項だけを並べた表は、読んだ人に何も使えないという印象だけを残します。公開情報の要約やメールの文面整えなど、今日から使ってよい用途を明示すると、ルールは守られやすくなります。

法人利用時に確認する項目

ここまでの内容を、決裁の前に確認する項目としてまとめます。サービス名が変わっても使える形にしてあります。1つでも空欄が残るなら、その入口はまだ許可の判断ができない状態です。

• 入力の保存と学習利用について、規約のどこに何と書かれているか該当箇所を引用して記録します。要約ではなく原文を残すと、後から解釈が揺れません。
• 学習利用を止める手段が、設定か、連絡か、契約か設定でないなら、管理者が一括で制御できないことを前提に対策を組みます。
• 保存場所と越境移転について、どの文書に何と書かれているか入口ごとに文書が違う場合は、自社が同意した文面を特定します。
• アクセス制御｜誰がアカウントを持ち、誰が発行と停止をするか個人アカウントでの利用が混ざっていないかを確認します。
• ログ｜誰が何を送ったかを、後から追えるか提供元が内容を保持しない設定の場合、自社でログを持つ必要が出ます。
• 契約｜準拠法と紛争解決の窓口はどこか日本の裁判所でない場合、争って取り戻す前提を置かない設計にします。
• エージェント権限｜自動実行させる処理から、外に出られる経路は何本あるか保守のために開けた経路が残っていないかを実機で確認します。
• 支払い｜誰のカードで決済されているか個人の決済で会社の業務が回っている状態を洗い出します。
• 退職・異動時の手順｜アカウントと履歴をどうするか個人アカウントの場合は会社側から消せないことを前提に手順を書きます。
• 止まったとき｜業務は何時間止まり、誰が代替手順を動かすか提供元の都合で使えなくなる場合と、自社設備が壊れる場合の両方を書きます。

この10項目は、Kimiに限らず、社員が使いたいと言ってくる新しいサービスすべてに同じ形で当てられます。項目を製品名で書かないこと、それがルールを長持ちさせるコツです。より広い範囲の点検項目は生成AI利用のセキュリティチェックリストにまとめています。

会社としての線引きを、入口ごとに決める

線引きは、サービス単位ではなく入口単位で決めてください。Kimiを許可するか禁止するか、という問いの立て方だと、アプリを禁止したのに開発部門がAPIを使っていた、という食い違いが起きます。次の表の形で、3つの入口それぞれに、許可・条件つき許可・禁止のどれかを割り当てます。

条件つきにするなら、書くのはこの5行

条件つき許可は、いちばん運用されにくい選択肢です。条件が曖昧だと、実質的に自由利用と同じになります。最低限、次の5行を書き切ってください。

1. 入れてよい情報：公開済みの情報、社外に出しても問題のない一般的な内容、自分で書いた文章の推敲など、具体的に例示する
2. 入れてはいけない情報：顧問先や取引先の名前が入ったもの、個人が特定できるもの、認証情報、未公表の数字。こちらも例示する
3. 使ってよい入口：どのURL・どの経路から使うか。個人アカウントを使ってよいかどうかを明記する
4. 誰が承認するか：新しい用途を始めるときの承認者を、役職名で1人に決める（部署ごとに窓口を分けると判断がぶれます）
5. 退職・異動のときの扱い：アカウント、履歴、支払い方法をどうするか。個人アカウントの場合、会社側から履歴を消せないことを前提に手順を書く

3つ目の入口の記載は、意外と抜けます。社員が私物のスマートフォンで、自分のアカウントで使う分には自由なのか、業務の内容を入れるなら禁止なのか。ここを書かないと、あとで注意した側もされた側も根拠を示せません。ガイドライン全体の作り方は生成AI利用ガイドラインの作り方で、章立てから決め方まで解説しています。

承認者を1人に決めると、判断が速くなる

承認者を複数人にすると、社員は通りやすい人に持っていくようになり、結果として基準が壊れます。役職名で1人に決め、判断に迷う案件はその人が持つ、という形が最も運用しやすい形です。あわせて、判断した内容を1行ずつ記録していくと、半年後には自社の判例集になります。

記録の形式は簡単で構いません。日付、誰が、何をやりたくて、どの入口で、どう判断したか。この5列の表を1つ作っておくだけで、次に似た相談が来たときの判断が数分で終わります。

禁止だけでは止まらない｜公認の置き場所を先に決める

ここが最後の論点です。禁止の通達だけを出しても、利用は止まりません。社員が海外の無料AIを使うのは、目の前に片付けたい仕事があるからです。代わりの手段を渡さずに経路だけを塞ぐと、会社の端末では使わずに私物の端末で続ける、という形に移るだけです。そしてその状態は、会社からはまったく見えません。

実務として効くのは、順番を変えることです。禁止を出す前に、同じ仕事ができる公認の環境を用意し、そこに寄せてから個人利用を締める。この順番にすると、社員にとっては取り上げられるのではなく置き換わるだけになるため、抵抗が小さく済みます。公認の環境に必要な条件は、次の3つです。

• 入力が学習に使われない設定であること：契約や設定で確認でき、社員が個別に申請しなくてよい状態になっていること
• 管理者から利用状況が見えること：誰がアカウントを持ち、どれくらい使っているかを管理画面で把握できること
• 社員にとって不便でないこと：日常業務で必要な機能（文章作成、要約、資料の読み取りなど）が揃っていて、待たされないこと。遅い、機能が足りない、と感じられた時点で個人利用に戻ります

3つ目が抜けている環境は、形骸化しがちです。用意しただけで使われない環境を作るくらいなら、何が足りなくて社員が外のサービスを選んだのかを先に聞き取ったほうが確実です。複数のAIを1つの環境でまとめて使う方法の比較はマルチAIとはで整理しています。

よくある質問

まとめ

Kimi K3は、モデルの重みが公開され、100万トークンの文脈を扱えるモデルとして公式ドキュメントに記載されています。ただし、会社として決めるべきことは性能の評価ではありません。入口が3つあり、Kimiのアプリ・サイトは入力をAIモデルの訓練と最適化に使うと明記し、APIは書面の合意がなければ同様の利用がありうるとしたうえでZDRの申請を案内し、自社で動かす形では送信そのものが発生しない、という違いがあります。この3つを1つの決裁でまとめて扱うと、どこかが抜けやすくなります。

断定してはいけない点も明確です。契約相手はNOVASCENT PRIVATE LIMITEDと北京月之暗面科技股份有限公司で入口ごとに異なり、保存場所の記載もシンガポールと中華人民共和国域内で文書によって違います。日本から使った場合にどちらが適用されるかは文面から一意に読めないため、この記事は入口によって表示される規約が異なる、という事実の記述にとどめています。IPAの短信に載った事例も、当局の調査結果ではなくベンダーの報告であり、報告した同社が意図的な悪行ではなくspecification gamingと位置づけたこと、外部システムへの侵入や攻撃はなかったことを、IPAがあわせて記載しています。読み取るべきは国籍の話ではなく、AIに実行させる環境から外へ出る経路を残さない、という出口制御の教訓です。

実務の順番は、確認する項目を10個埋め、入口ごとに許可・条件つき・禁止を割り当て、条件つきにするなら5行（入れてよい情報・入れてはいけない情報・使ってよい入口・承認者・退職時の扱い）を書き切る。そして、禁止を出す前に同じ仕事ができる公認の環境を用意する。この順番にすると、ルールは守られやすくなります。法人のAI活用に関する他の記事はAI活用コラム一覧をご覧ください。