KimiのClaude転送問題｜企業データを守る判断基準

2026年9月、Anthropicは、Kimiに入力された一部の依頼が利用者への開示なくClaudeへ転送されたと報告しました。顧客情報や社内資料を入力する企業にとって、問題は情報が想定外の事業者へ渡り、保存や学習に使われ得ることです。この記事では、KimiからClaudeへの転送問題を確認し、企業が生成AIへ預ける情報を判断する基準を整理します。

企業が押さえるべきなのは、実際に情報を受け取る相手と、その扱いです。入力の送信先、保存先、学習利用、契約主体を確認できない環境には、顧客情報、認証情報、未公開情報を入力しないことが基本です。

KimiからClaudeへの転送で何が起きたのか

Kimiは、中国・北京のMoonshot AIが提供する生成AIサービスです。Anthropicは、Moonshot AIが一部のKimi利用者から受け付けた依頼をClaudeへ開示なく送り、Claudeが生成した回答をKimiの画面に表示していたと説明しました。

Anthropicによると、ある10日間に約30万件のKimi利用者リクエストがClaudeへ転送され、その大半をClaude Opusが処理しました。この活動には、Moonshot AIに関連すると同社が判断した5,380件の不正アカウントが使われたとされています。

別のAIが生成した回答を使ってモデルを改善する方法は「蒸留」と呼ばれます。今回の中心的な問題は手法の名称ではなく、利用者が認識していない別会社のAIへ入力が送られ、そのやり取りが回答生成やモデル改善に使われたと報告されたことです。

約30万件という件数やMoonshot AIへの帰属は、Anthropicが自社の内部データを調査して公表した内容です。検知ログの全体が第三者による検証に利用できる形で公開されているわけではないため、記事内ではAnthropicの報告として扱います。

企業にとって問題なのは回答元より入力情報の行き先

画面に表示されるサービス名と、実際に回答を生成する事業者が異なれば、企業が想定していた情報管理の範囲も変わります。Kimiとの間だけで処理されると考えていた入力がClaudeへ送られた場合、契約相手以外の事業者による処理やログ保存も影響範囲に入ります。

Anthropicは、転送された情報の具体例として、監視カメラのデータを分析する依頼を挙げました。対象には人民解放軍施設や国有企業の周辺が含まれ、依頼者には人民解放軍との関係が疑われたと説明しています。

別の例では、中国の国有企業の技術者が入力したとされる内部コードと、有効な認証情報が含まれていました。ソースコードに加えてシステムへ接続できる情報まで入力されていれば、保存先や閲覧範囲が変わったときの影響は業務システムにも及びます。

中小企業でも問題の構造は同じです。たとえば営業担当者が、顧客名、相談内容、予算を含むメールを要約させたとします。利用者に知らされていない転送があれば、顧客から預かった情報が想定外の事業者へ渡る可能性があります。

開発担当者が不具合調査のためにソースコードと有効なAPIキーをまとめて入力した場合は、認証情報まで自社の管理外へ出るおそれがあります。コードの相談では設定ファイルや操作記録を貼り付けることがあるため、本人が意識しないまま重要情報を含めてしまう点にも注意が必要です。

公開報告には、転送された会話全体の内訳、機微情報を含む件数、保存された割合、保存期間は記載されていません。自社の入力が対象だったかも公開情報だけでは特定できません。利用期間と入力履歴を確認し、顧客情報や認証情報を入力していた場合は、影響し得る情報を洗い出す必要があります。

中国の法律と企業の情報管理

中国の国家情報法第7条は、組織と国民に、法に基づく国家情報活動への協力と秘密の保持を求めています。第14条では、国家情報機関が関係する組織などへ必要な協力を求められると定めています。中国の事業者へ機密情報を預ける企業にとって、こうした法制度も契約先を選ぶ際の判断材料になります。

今回のKimiでは、利用者への開示がないまま別会社のAIへ入力が送られたと報告されています。会社が許可した送信先と、実際の処理先が食い違えば、顧客から預かった情報をどこへ渡したのか説明できなくなります。企業の契約では、情報を処理する会社、保存場所、外部への送信を明確にする必要があります。

自社サーバーで動かすAIと、ブラウザで使う外部サービスでも、情報を管理する相手は変わります。社員が使っている画面の名前だけで承認せず、実際に誰が情報を扱うのかまで把握することが大切です。

生成AIへ企業データを預ける前に確認する7項目

生成AIの導入時には、次の7項目を具体的に確認します。サービス紹介に「安全」「企業向け」と書かれているだけで判断せず、自社に適用される契約、規約、管理画面の設定を確認してください。

必要な安全水準は業務によって異なります。公開情報の要約なら、情報が外部へ出た場合の影響は比較的小さく抑えられます。顧客から預かった情報や認証情報を扱うなら、7項目の回答を確認できないサービスは利用対象から外します。

確認結果は、規約や説明ページの所在、確認日、対象となる契約、判断した担当者とともに残します。「学習に使わない」と書かれていても、会話ログの保存、外部の処理事業者への転送、障害調査時の閲覧まで同じ条件とは限りません。項目ごとに分けて確認すれば、契約更新やサービス変更の際にも、どの条件を再確認すべきか判断できます。

無料サービスやブラウザ拡張機能を社員が使う場合も、誰とどの条件で契約し、入力がどこへ送られ、何の目的で保存されるかを把握します。必要な情報が開示されていない場合は、用途を公開情報の処理だけに限定します。

社内ではツール名ではなく情報の種類で入力範囲を決める

社内ルールを特定のツール名だけで作ると、新しいサービスが追加されるたびに判断が必要です。先に情報の種類で禁止範囲を決め、その後で承認済みサービスと利用条件を対応させると、担当者が迷いにくくなります。

最優先で入力禁止にする情報

• 顧客や従業員の個人情報、未公開の相談内容、決済情報
• ID、パスワード、APIキー、秘密鍵などの認証情報
• 契約交渉、価格交渉、未発表の事業計画、買収に関する情報
• 公開していないソースコード、脆弱性、ネットワーク構成
• 人事評価や健康情報など、外部流出時の影響が大きい情報

認証情報は、文章の一部に紛れ込むことがあります。不具合の相談で設定ファイルや操作記録を貼り付けるときは、氏名や会社名だけでなく、接続文字列、アクセストークン、メールアドレスなども除く必要があります。匿名化しても業務や人物を推測できる内容は、承認された環境以外へ入力しません。

条件を確認したうえで扱う情報

• 氏名、会社名、連絡先、固有の案件情報を除いた文章
• 公開済みのWebページ、プレスリリース、商品説明
• 社内で承認した企業向け環境へ、必要な範囲だけ入力する業務データ
• 保存と学習利用の条件を確認し、権限を限定した環境で扱う情報

判断に迷ったときは、「別の事業者に見られた場合、顧客へ説明できるか」「公開された場合、契約違反や業務停止につながるか」を考えます。説明できない情報や影響を判断できない情報は入力しません。

入力前の確認は、担当者の注意だけに任せず、業務の流れに組み込みます。たとえば顧客メールを要約する業務なら、氏名、連絡先、案件名、予算を除く担当者と、匿名化後の文章を確認する担当者を決めます。コードの相談では、認証情報や接続先が含まれていないことを確認してから、承認済みの環境だけで扱います。

誤って禁止情報を入力した場合に備え、利用を止める連絡先、入力履歴を確認する担当者、認証情報を変更する判断者も決めておきます。禁止事項だけでなく、問題が起きた後の初動まで定めることで、担当者が一人で対応を抱え込まずに済みます。

一つの低リスク業務から運用を確かめる

新しいAIを導入するときは、公開済み文章の要約など、影響の小さい業務を一つ選びます。入力できる情報、出力を確認する担当者、問題が見つかったときの停止方法を先に決め、運用記録を残します。導入対象を絞って進める流れは、中小企業がAI導入を始めるときの手順で詳しく整理しています。

複数のサービスを部署ごとに追加すると、同じ情報が異なる契約条件の環境へ入力されやすくなります。ツール名の一覧ではなく、業務上の役割と扱う情報で整理する方法は、増えすぎたAIツールを社内で整理する方法を参考にしてください。

入力禁止情報、承認済みサービス、利用責任者、事故時の連絡先まで文書にすると、担当者による判断の差を減らせます。社内規程へ落とし込む項目は、生成AIの社内利用ガイドラインを作る方法で確認できます。

KimiとClaudeの転送問題についてよくある質問

自社の入力がClaudeへ転送されたか確認できますか？

公開情報だけでは、個々の入力が転送対象だったか確認できません。社内で利用期間、利用アカウント、入力履歴を調べます。顧客情報や認証情報を入力していた場合は、サービス提供者への照会、パスワードやAPIキーの変更など、情報の種類に応じた対応を検討してください。

Kimiの業務利用は直ちにすべて止めるべきですか？

すべての用途を一律に止めるのではなく、扱う情報と確認できる契約条件で判断します。送信先、保存、学習利用、契約主体が分からない状態で顧客情報や未公開情報を扱っているなら、その用途は停止します。公開情報だけを扱う用途は、必要性と影響を分けて評価します。

公開モデルを自社環境で動かせば同じ問題は起きませんか？

外部への送信を自社で制御しやすくなりますが、それだけで安全が保証されるわけではありません。外部通信、アクセス権限、操作ログ、バックアップ、更新経路を自社で管理する必要があります。同じモデル名でも、クラウド版とはデータ経路が異なります。

どの情報を最優先で入力禁止にすべきですか？

顧客の個人情報、有効な認証情報、未公開の契約・事業情報を優先してください。特にAPIキーやパスワードは、外部へ出ると第三者によるシステム接続に使われるおそれがあります。文章要約やコード相談へ紛れ込ませない運用が必要です。

まとめ：モデル名ではなくデータ経路で利用可否を決める

Kimi問題の核心は、利用者が見ていたサービスとは別のClaudeへ入力が開示なく送られ、その回答が表示され、やり取りの一部がモデル改善にも使われたとAnthropicが報告した点です。

利用中の生成AIについて、契約主体、実際の送信先、処理・保存地域、保存期間、学習利用を棚卸ししてください。確認できない環境から顧客情報、認証情報、未公開情報を外し、入力可能な情報、禁止情報、責任者、利用停止の条件を社内ルールとして定めます。

利用中の生成AIのデータ経路や入力範囲を整理したい場合は、Aillyへご相談ください。現在の業務を確認し、入力禁止にする情報、人による確認を残す業務、利用環境を見直す範囲を一緒に整理します。

本記事は2026年10月23日時点で確認できる公開情報に基づいています。

参考

確認日：2026年10月23日

• ▶ Anthropic：2026年9月の脅威調査報告
• ▶ Anthropic：モデルの不正利用に関する調査
• ▶ 中国国家情報法