DeepSeekでMLPS等保監査の証跡を整理する

結論から：MLPS（等級保護）評価がつまずくのは、セキュリティ対策そのものではなく、対策が存在することを証明する証跡を集め、整理し、翻訳できないことです。DeepSeek が向いているのはその中間層——散在する文書を要求事項リストに突き合わせ、二言語の説明を下書きし、不足を早期に洗い出すこと。ただし「その統制が十分かどうか」を判断させてはいけません。

中国に進出した外資系企業が初めて MLPS 評価を受けると、六週目あたりでたいてい同じことに気づきます。問題はセキュリティ対策が無いことではありません。ファイアウォールはあり、バックアップは動き、アカウントは管理され、ログも保持されている。問題は、それを証明するには特定の形式で、中国語で書かれ、特定の条項に紐づいた文書が要るという点です。そしてその文書は今のところ、誰かの WeChat に残るスクリーンショット、欧州本社が英語で書いた PDF ポリシー、そして三人のエンジニアの頭の中にしかない運用慣行として存在しています。

本記事はそのギャップだけを扱います。MLPS や PIPL が何を要求するかは説明しません——サイトには中国進出企業向けの MLPS・PIPL コンプライアンスチェックリストがあり、ここで制度を再解説しても時間の無駄です。以下は証跡のワークフローです。手元にあるものを棚卸しし、要求事項に突き合わせ、足りないものを起草し、パッケージする——その分量と二言語の負荷を DeepSeek に吸収させながら。

評価を実際に遅らせるのは、コンプライアンスではなく証跡集め

ISO 27001 や SOC 2 を経験した人ほど、MLPS 評価の形に驚きます。評価機関は等級に応じた構造化された要求事項リストに沿って進み、各項目について具体的なものを求めます。規程、設定のスクリーンショット、ログの抜粋、署名済みの記録、システムが出力したレポート。ヒアリングと現地確認も重要ですが、作業量の大半は文書パックが担います。

遅延の原因は四つあり、どれもセキュリティの問題ではありません。

証跡はもともと散在している。事前に「コンプライアンス証跡」フォルダを作る人はいません。変更承認記録はチケットシステムに、アカウント棚卸しは年一回のメールのやりとりに、バックアップ検証は毎月グループチャットに貼られるスクリーンショットに、ネットワーク構成図は誰かのいちばん新しい Visio ファイルにあります。すべて存在しているのに、文書パックが期待する場所には一つもありません。

言語が合わない。外資系企業はたいていグループ本社の英語ポリシーを引き継いでいます。一方、評価は中国語で、中国語の基準に対して、提出物をそのまま読む評価者によって行われます。誰かが翻訳しなければなりません。しかも言語的な翻訳だけでなく、基準が使う用語に置き換える必要があります。「特権アカウント管理」について書かれた規程が、どの要求に答えているのか一目で分かるように。

本当に足りないものは、遅くまで分からない。チームは要求事項リストを上から順に進み、200 項目のうち 140 番目で実際の欠落を見つけ、そこでようやく統制を作り、証跡が出るだけの期間運用する必要に気づきます。二週目に見つかれば管理可能な是正、九週目に見つかれば評価日程が動きます。

担当者には本業がある。証跡準備が誰かの専任業務であることはまずありません。環境全体も見ている IT マネージャー、あるいは複数法域を担当するコンプライアンス責任者に、細切れの時間で降ってきます。

AI は四つ目を解決しませんが、前の三つを大きく圧縮します。そして圧縮した結果、三つ目が早く表面化する——価値の大半はそこにあります。

要求事項リストを証跡台帳に変える

この作業が最終的に生み出すものは一つ、証跡台帳です。要求一件につき一行、どの文書が答えるのか、その文書はどこにあるのか、どういう状態か、誰が担当かを書く。他のすべてはこの表に至る手順です。本記事から一つだけ持ち帰るなら、まず台帳を作り、それに作業を駆動させること。文書を集めてからリストを網羅していることを祈る、という順番にしないことです。

手元にあるものを要求に突き合わせ、不足を早い段階で名指しする

まず要求事項リストを機械可読な形にします。統制項目一件につき一行、条項番号と要求本文が入った表です。評価機関やコンサルが提供してくれるのが普通で、PDF で来た場合は変換するのが最初の作業であって、PDF のまま作業する理由にはなりません。

次に、実際に保有しているものの生の棚卸しを作ります。厳選リストではなく、生のリストです。規程類、ネットワーク構成図、手順書、システム設定のエクスポート、スクリーンショット、チケットのエクスポート、研修記録、ベンダー契約、過去の監査報告。ファイル名、保管場所、言語、日付、そして内容の一行説明。数百行になるのが普通です。

突き合わせの工程が DeepSeek の出番です。要求本文と棚卸しリストを与えると、どの文書がどの要求に答えうるかを提案でき、さらに有用なことに——棚卸しの中に答えらしきものが見当たらない要求を指摘できます。実務で機能するプロンプトは意図的に保守的です。

「以下は MLPS 統制要求のリストと、当社が保有する文書のリストおよび説明です。各要求について、証跡になりうる文書を、直接性の高い順に挙げてください。棚卸しの中に妥当に答えられる文書がない場合はその旨を明示し、無理な対応づけはしないでください。統制が十分かどうかは評価せず、関連する文書が存在するかどうかだけを判断してください。」

最後の一文は見た目以上に重要です。この制約がないと、モデルは不足を報告するより「もっともらしい対応づけ」を作りにいきます。誤った対応づけは空欄より悪い——台帳が完成しているように見えて、実際はそうではないからです。

出てくるのは初版の台帳で、必ずどこか間違っています。それで構いません。既にある対応づけを直すほうが、空の表から組み立てるよりはるかに速く、そして初週に出てくる不足リストこそが評価日程を守るものです。

二言語の壁——証跡は英語、評価は中国語

ここが DeepSeek を汎用の欧米系モデルより選ぶ理由で、思想ではなく実務的な理由です。素材は二言語で、目標となる用語は中国語の規制語彙だからです。中国語コーパスを中心に学習したモデルは、等保の用語や中国語コンプライアンス文書の言い回しをより自然に扱い、「翻訳したもの」と一目で分かる硬さが出にくくなります。

この分類で任せる価値があるのは三つです。

既存のポリシー文書を、基準自身の用語を使った中国語に翻訳する。逐語訳ではありません。グループの情報セキュリティ規程をそのまま訳すと、技術的に正確でも、どの条項に答えているのかが見えなくなります。
存在するが文書化されていない統制の中国語説明を起草する。統制は実在し、文書だけがない状態です。実際にやっていることを口述し、台帳が期待する形式の手順書の初稿を作らせます。
本社向けの二言語サマリーを作る。本社のセキュリティチームは、自社名義で何が提出されたかを知りたがります。中国語文書ごとに英語サマリーを付ける手間はごくわずかで、パックを読めないグループ CISO による土壇場の異議を防げます。

三つとも出てくるのは下書きです。文書がパックに入る前に、必ず名前のある人間——できれば評価当日その場にいる人——が確認して承認します。

実務的なワークフロー：棚卸し・突き合わせ・起草・人手レビュー・パッケージ

この順番でやります。順番が手法であり、ツールは差し替え可能です。

棚卸し（2〜4 日）。前述の生の文書リストを作ります。進めながら整理・取捨選択したくなるのを我慢してください。この段階では網羅性が品質に優先します。無関係と切り捨てた文書が、ある統制の唯一の証跡だったということがよくあります。

突き合わせ（1〜2 日）。モデルで初版台帳を作り、人手で一通り確認します。見るのは二点、提案された対応づけが本物か、そして不足リストが正直か。不足リストは作成したその週のうちに経営層へ渡してください。この作業全体で最も価値の高い単一成果物です。

起草（1〜2 週、是正と並行）。文書の不足（統制はある、書類がない）は書き起こす。実際の統制の不足は是正プロジェクトであり、どれだけ文書を書いても、統制を作って証跡が出るまで運用することの代わりにはなりません。

人手レビュー（継続）。生成・翻訳された文書はすべて、それが事実かどうかを知っている人が最後まで読みます。形式的な手続きではありません。生成された手順書は「まともな組織ならこうする」を描いたものであって、貴社が実際にそうしているとは限りません。手順書とヒアリング内容が食い違うのを評価者が見つけたら、それは文書が一つ足りないより大きな問題です。

パッケージ（2〜3 日）。評価機関が期待する構造に組み上げます。条項でインデックスし、台帳を全体地図として添える。命名・日付・版番号を揃える。地味ですが評価の進み方に実質的に効きます。目的の資料をすぐ見つけられる評価者は、追加質問が減るからです。

AI 活用による証跡準備 vs コンプライアンスコンサル vs 表計算だけで押し切る

AI 活用は分量作業で最速です。数百の文書と数百の要求の突き合わせ、翻訳、初稿の起草——しかも着手を決めたその日から使えます。一方で評価上の立場は一切なく、評価機関との関係もなく、「この統制は通るか」について信頼に足る意見も持ちません。出力は素材であって、提出物ではありません。
コンプライアンスコンサルは AI に出せない判断を持ち込みます。その都市のその評価機関が実際に何を期待するか、現状の実装が受け入れられるか、ある不足がどれほど重いか。ここは支払う価値があり、実際にリスクを負う部分です。時間単価が高いからこそ、その時間を文書の仕分けや翻訳に使うべきではありません。
表計算と人力だけは多くの企業の既定路線で、実際に機能します——対象システムが小さく、要求リストが短く、経験者がいるなら。規模が大きくなると一人の注意力を通る直列のボトルネックになり、不足の発覚が遅れ、二言語の負荷が本業と無関係に「たまたま二言語ができる人」に集中します。

機能する組み合わせは、分量は AI、恒久的な台帳は表計算、コンサルの時間は判断と評価機関とのやりとりに集中させる、というものです。

AI に判断させてはいけないこと

次の二つの問いは、毎回、有資格の評価機関または中国法弁護士に回さなければなりません。どんなプロンプトでも社内で安全に答えられるようにはなりません。

「この統制は当社の等級に対して十分か」十分性は、認可を受けた評価機関が基準に照らし、現地の実務を踏まえて下す判断です。モデルは「この文書は条項に対応しているように見える」とは言えますが、その実装が受け入れられるかは言えません。ここで自信のある誤答が出るのは、答えが無いより悪い——問うのをやめてしまうからです。

「この不足は重大か」不足が認証を止めるのか、是正期間で済むのか、指摘のうえ通るのかは技術判断ではありません。評価機関か弁護士に回し、それを前提に計画を組む前に書面で回答を得てください。

システムが保持するデータに関する PIPL 上の義務についても同じ規則が当てはまります。制度どうしは相互に作用し、その作用は事実関係に依存し、IT ではなく法律の問題です。

これを正しくやるには——証跡の機密、データの所在、そして IT を呼ぶタイミング

MLPS の証跡パックは、貴社が作る中で最も機微な文書の集合体の一つです。ネットワーク構成、セキュリティ設定、アカウント運用、既知の不足、是正計画——実質的に「自社をどう攻めるか」を索引付きでまとめたものです。扱いはそれに見合ったものにし、最初の一文書がチャット画面に入る前に、次の三点を決めてください。

どの提供形態を使うか。消費者向けの公開チャット、商用データ条項のある API、自社インフラ上に私的展開したオープンウェイトモデルは、三つの異なるリスク位置です。DeepSeek は自己ホスト可能なオープンウェイトモデルを公開しており、証跡作業においてこれは現実的な選択肢です。「たまたま開いていたから」で消費者向けアプリを既定にせず、きちんと評価する価値があります。条項は提供元に直接確認してください。商用のデータ取扱方針は変わります。

実際に何を入れる必要があるか。価値の大半は文書の説明、要求本文、規程の文章から得られます。生の設定エクスポート、認証情報、実ログではありません。既定で大胆にマスキングしてください。突き合わせや翻訳に全文が要らないなら、全文を貼らないことです。

出力をどこに置くか。台帳と下書き文書は、元の証跡と同じだけ機微です。個人のドライブやチャット履歴ではなく、証跡と同じアクセス制御のかかった管理下の文書基盤に置くべきものです。

提供形態を選び、チームが実際に守れるデータ取扱ルールを書き、次のサイクルで再利用できるようプロンプトと台帳テンプレートを整備する——これは AI+ サポートの仕事です。統制そのもの、そして証跡パックを「後から再構築する」のではなく「もともと組み上げられる」状態にする月次のギャップ分析と設定バックアップの規律は、アジア拠点のセキュリティコントロールセンターと有資格コンサルタントが常態業務として担うマネージド IT セキュリティサービスの領域です。その下にある日常運用——パッチ適用、アカウント棚卸し、バックアップ検証。これらは環境をきちんと運用した副産物として証跡を生みます——はマネージド IT サポートです。評価日程がすでに決まっていて証跡の状況が不透明なら、九週目ではなく今ご相談ください。

よくある質問

セキュリティ証跡を AI ツールに通してよいのですか

提供形態と社内規程によります。一般則で決まる話ではありません。自社インフラ上のオープンウェイトモデルと、消費者向けチャットアプリでは立場がまったく違います。まず提供形態を決め、不要な内容はマスキングし、そのルールを文書化してください。ここでの失敗は「検討したうえで AI を使う判断」ではなく、誰も駄目と言わなかったからエンジニアがファイアウォール設定を公開チャットに貼ってしまうことです。