DeepSeekで多拠点のIT資産台帳を突合する方法

結論から言うと： 各拠点の資産台帳とIntuneやADの端末一覧をあわせて書き出し、列の意味と突合ルールを平易な言葉でDeepSeekに説明したうえで、シリアル番号の表記ゆれを整え、ソース間で照合し、食い違いをすべて挙げさせます。一日で、根拠を示せる一度きりの棚卸し結果が手に入ります。台帳が再びずれていくのを止めるものは、何も手に入りません。

深圳・蘇州・香港に拠点を持つ情報システム部門の責任者に、会社にノートPCが何台あるかと尋ねれば、数字は返ってきます。その数字の出どころを尋ねると、書式のばらばらな三つの表と、Intuneの書き出しと、そのどれとも一致しない経理の固定資産台帳が出てきます。

誰も嘘はついていません。それぞれ別の目的で作られ、別の人が保守し、最後に更新された時期も違います。拠点の一覧は現地の担当者が実機を探すために、Intuneの書き出しは端末にパッチを当てるために、経理の台帳は資産を償却するために存在します。互いに突き合わせるようには設計されておらず、全社の数字を誰かが求めるまで、一致させる力はどこにも働きません。

書式のばらついた記録どうしを突き合わせる作業は、言語モデルが本当に得意とする種類の仕事です。難しいからではなく、「一回なら簡単だが一万回やれば必ず間違える」種類の簡単さだからです。DeepSeekがこの用途に向くのは、元データの半分がたいてい中国語だからです。「型号」「使用人」といった列が英語のシリアル番号の隣に並び、日付の書式はばらばら、拠点名は三通りの書き方がある。両方の言語をそのまま読めるモデルなら翻訳の工程がひとつ消え、工程がひとつ消えるたびに、持ち込む誤りの種類がひとつ減ります。

以下は実際に使える手順です。そして最後に、これでは直らないものについて正直に書きます。

会社にノートPCが何台あるか、誰も言えない理由

四つあり、しかも重なります。

拠点ごとに、それぞれの形で管理している。 ある拠点はシリアル番号で、ある拠点は資産番号で、別の拠点は利用者名で管理しています。列も違えば見出しの言語も違い、少なくとも一つの表にはセルが結合されていて、一行に二台分が記録されています。

例外が起きたときにしか更新されない。 購入時に追加され、不具合が起きたときに更新される。新入社員に静かに渡されたとき、別の拠点へ持ち出されたとき、退職者の引き出しに残されたときには、何も更新されません。

合計に責任を持つ人がいない。 各拠点の責任者は自分の一覧には責任を負いますが、合計に責任を負う人はいません。誰の評価にも紐づかない数字は、ずれていきます。

これを解決できるはずの仕組みは、別の目的で買われた。 IntuneやActive Directoryが把握しているのは、通信してくる端末だけです。電源が入っていないもの、再イメージされたもの、倉庫の棚にあるもの、そもそも登録されていないものは対象外になります。経理の台帳は何を買ったかは知っていて、その後に何が起きたかは決して知りません。どちらも自分の範囲では正確で、範囲の外では沈黙します。

結果は抽象的な話ではありません。予備機の数が信用できないので重複して発注する、二年前に廃棄した端末のライセンス料を払い続ける、そして社内・ISO・顧客のいずれかの監査で問われて、三週間かけて出来の悪い回答を出す——という形で表れます。

モデルが突合できる形に元データを整える

準備が作業の大半で、しかも技術的な話ではありません。

食い違っているのは、具体的にどの三つですか

まず比較対象を正確に名指しします。「表がいくつかある」は範囲の定義になりません。

拠点の表は「誰が実際に何を持っているか」については最も確かで、それ以外については最も当てになりません。利用者と設置場所は現地担当者が必要とするので正しく入っていますが、購入日や型番はしばしば雑です。

Intune・Jamf・ADの書き出しは「実際に動いて通信している端末」についての事実です。シリアル番号、OSビルド、最終通信日については権威があり、一度も登録されていない端末については何も知りません。

経理の固定資産台帳は「何を買い、帳簿上いくらか」についての事実です。購入日と取得価額については権威があり、ノートPC二十台を一行で記録していることが多く、シリアル番号はたいてい入っていません。

これを先に言語化してください。二つのソースが食い違ったときにどちらを採るかが決まり、産物に根拠を与えるのはモデルではなく、そのルールだからです。

明示しておくべき突合ルールは何ですか

ルールを与えなければモデルは推測しますし、推測されたルールこそが静かな誤りの発生源です。書き出して、プロンプトに入れてください。

シリアル番号の正規化。 空白とハイフンを除去し、大文字小文字を区別するかを決め、Excelに先頭アポストロフィを付けられた値や、列幅の都合で切れた値の扱いを明記します。Dellのサービスタグ、Lenovoのシリアル、Appleのシリアルは形が違います。何を想定するかを書いてください。

言語をまたぐ列の対応づけ。 「序列号」と「Serial No.」は同じ列であること、「使用人」は利用者に対応すること、ステータス列の「已报废」は廃棄済みを意味することを伝えます。二言語を読めるモデルが効いてくるのはここです。ファイルを翻訳してずれないことを祈るのではなく、対応関係そのものを記述しているからです。

何をもって一致とみなすか。 シリアル完全一致は一致です。資産番号が同じでシリアルが違うのは一致ではなく矛盾です。利用者も型番も同じでどちらにもシリアルがないものは候補であり、候補は必ず人に回すべきで、自動で統合してはいけません。

残ったものをどうするか。 突合できなかった記録はすべて発見であり、発見には種類があります。Intuneにあるがどの拠点台帳にもない、拠点台帳にあるがIntuneが一度も見ていない、経理の帳簿にしかない。種類ごとに分けて出させてください。取るべき次の行動が違います。

データは必要な分だけに。ハードウェアの棚卸しに住所も電話番号も人事番号も要りません。書き出す個人項目が少ないほど、後で答えるべき統制上の問いも小さくなります。

実際の突合の進め方——正規化し、照合し、印を付け、人が確かめる

一度に問うのではなく、四段階に分けます。

第一段階——正規化だけをする。 ファイルは一度に一つだけ渡し、単一のスキーマに整えた表を出させます。シリアル、資産番号、型番、利用者、拠点、状態、購入日、出典。照合はまだしません。一拠点分の出力を元ファイルと突き合わせてから先へ進んでください。正規化が誤っていれば、以降のすべてがそれを受け継ぎます。

第二段階——強いキーで照合する。 正規化済みのデータ間でシリアル完全一致を取り、各ソースの一致件数と不一致件数を出させます。合計が合わないことが最初の本当の発見で、たいていは本当の欠落ではなく正規化の問題を指しています。

第三段階——弱い一致を提案させる。 ここで、より柔らかい手がかりによる候補を、理由つきで出させます。「資産番号と利用者が同じ、拠点台帳にシリアルなし」。理由は必ず求めてください。理由のない候補一覧は検証できませんが、理由付きの候補一覧なら、分かっている人が一行あたり一分ほどで処理できます。

第四段階——例外を分類する。 突合できなかった記録を例外の種類別にまとめ、それぞれに次の行動案を付けさせます。現物を探す、廃棄済みと確認する、拠点責任者に確認する、経理台帳を訂正する。

そのうえで人が確かめます。例外だけでなく、一致した側も抜き取ってください。例外は見るからにおかしいので自然に精査されます。そのまま受け入れられてしまうのは、自信ありげに見える誤った一致のほうです。一致行を無作為に二十件抜いて元ファイルと照合する二十分が、その回の結果全体を信用してよいかを教えてくれます。

四拠点で一度目を回したときの現実的な結果は、大半はきれいに一致し、相応の件数が候補として残り、しつこい少数は本当に所在不明の端末である、というものです。最後の一群はどれだけデータを扱っても解決せず、誰かが部屋に入って現物を見るしかありません。

一度きりのAI突合 vs 本物の資産管理システム

• 信用できる数字が出るまでの速さ — AI突合の圧勝。一日の作業と、システムと展開と運用ルールを要する案件との比較です。
• 着手コスト — AI突合が有利。API料金と自分の時間だけで、調達するものがありません。
• 雑然とした二言語混在の入力への強さ — AI突合が有利で、しかも大差です。厳密なスキーマを持つシステムが最も苦手とする形の問題です。
• 来期また同じようにずれるのを防ぐ — 管理された資産台帳が決定的に有利。突合は写真であり、貸出・返却の手続きとIntune連携を持つ台帳は、現状を保ち続ける仕組みです。
• 監査・コンプライアンスの証跡 — 台帳が有利。「これが資産システムで、配布履歴も償却スケジュールもあります」は監査人への回答になります。「三月にAIで整理した表です」は次の質問を呼びます。
• ライセンスと保証の管理 — 台帳が有利。ライセンス数の追跡や期限通知は継続的な業務であって、一度きりの分析ではありません。

正直な読み方はこうです。AIの一巡で問題の深刻さを把握し、きれいな基準線を作る。そのうえで、その基準線を自ら保てる場所に置く。前半だけやって後半をやらないなら、来年また前半をやることになります。

割に合ったかどうかを決めるのは、その後の一手

台帳を誰が持つのか、です。

突合が生むのは、ある特定の日付における、きれいな一覧です。その瞬間から劣化が始まり、速度はおおむね組織が機材を動かす速さと同じになります。委託先があり、拠点間の移動があり、通常どおりの人の出入りがある多拠点の中国オペレーションでは、それは多くの人の見積もりより速いものです。半年後に向き合うのは、また三つの表と、四つ目——突合済みで、いまや同じく誤っている表です。

きれいな一覧が労力に見合うのは、二つが揃ったときだけです。自分の拠点だけでなく、合計の持ち主として名前の挙がる人がいること。そして、端末を動かすすべての出来事——貸出、移動、返却、廃棄——が、後から記憶で再構成されるのではなく、起きたその場で一箇所に書き込まれること。

それが、催しではなく仕組みが要る理由のすべてです。BrocentのFINOS IT資産管理はこの形の問題のためにあります。シリアル、資産タグ、利用者、設置場所、状態、保証期限を持つ自動採番の資産レコード。配布履歴をその場で残す貸出・返却。登録済み端末を打ち直さずに取り込むMicrosoft Intune連携。期限警告つきのソフトウェアライセンス管理。そして、経理が別に台帳を持っていた理由そのものである償却スケジュール。別料金のサブスクリプションではなくBrocentのマネージドITに含まれており、この種の案件が止まる典型的な理由がひとつ消えます。

ここを外さない——資産データ、越境移転、そしてITに相談すべき時

何かをアップロードする前に、実務上の三点です。

その書き出しは個人情報として扱ってください。実際にそうだからです。 利用者列を含むハードウェア台帳は、中国のPIPLのもとでは個人情報にあたります。識別されるのは端末ですが、同時にそれを持つ人も識別されます。対処は書類を増やすことではなく、必要最小限にすることです。ファイルが自社環境を出る前に利用者列を削るか仮名化し、シリアルと資産番号で突合し、あとから手元で氏名を戻す。突合ロジックのほとんどは、そもそも氏名を必要としていません。

処理がどこで行われるかを把握する。 拠点台帳をホスト型モデルに送ることはデータの移転であり、ファイルが中国本土を出るなら、固有の要件を伴う越境移転になり得ます。DeepSeekは自社で管理する基盤上で動かせるオープンウェイトのモデルを公開しており、ファイルを環境外に出せない場合の最も素直な答えになります。ホスト型APIを使うなら、自分が実際に使っている階層の現行条件を「たぶん」で済ませず確認してください。階層によって異なり、条件も変わります。

自分が解いているのがどちら半分かを知る。 分析は安いほうの半分です。突合できなかった端末を現物で探し、本当に失われたものを判断し、経理台帳を訂正し、その結果を正確に保ち続けることが本体で、それを担うのが私たちのAI+サポートとマネージドITサポートです。Brocentは2007年の北京での創業以来アジアでマネージドITを提供しており、本社はシンガポール、2016年から香港にも拠点があります。拠点ごとに台帳が別々にある中国の多拠点環境は、私たちの通常の領域です。同じデータ所在の考え方は社内AI全般にあてはまり、中国の規制に適合した社内ナレッジ活用で詳しく扱っています。

よくある質問

シリアル番号と利用者データはPIPL上の個人情報にあたりますか

利用者列は該当し、たいていその一列でファイル全体が対象になります。シリアル番号単体は端末の情報ですが、従業員名の隣にあるシリアル番号は個人を識別します。実務的な答えは、書き出し前に氏名列を落とし、シリアルと資産番号で突合することです。突合ロジックの多くはもともとそれで足ります。氏名を残さざるを得ない場合は、ファイルを自社環境に留め、自社設置のモデルを使ってください。

資産シリアル番号に対するAIのあいまい一致はどれくらい正確ですか

正規化後の完全一致は非常に信頼できます。決定論的だからで、価値は一致処理ではなく正規化にあります。部分的なシリアル、型番、利用者名によるあいまい一致は確かに有用ですが、黙って信用してはいけません。候補ごとに理由を必ず出させ、人が一件ずつ確認してください。あいまい一致の出力は結論ではなく、確認用の候補リストとして扱います。

片方の一覧にしかない資産はどう扱いますか

どの一覧に現れたかで分類してください。意味が違います。Intuneにあって拠点台帳にないなら台帳が不完全。拠点台帳にあってIntuneが一度も見ていないなら、未登録か、廃棄済みか、すでに存在しない。経理の帳簿にしかないなら、経理に伝えずに処分された可能性が高い。前二者はデータの修正で、最後の一つは除却の相談です。

どのくらいの頻度でやり直すべきですか

表から突合しているなら四半期ごとが現実的で、年一回では遅すぎて役に立ちません。ただし頻度は最適化すべき問いではありません。繰り返さざるを得ない突合は、それ自体が症状です。配布と移動が起きたその場で一つの仕組みに記録されるようになれば、この作業は案件ではなく抜き取り確認になります。

ホスト型のAIサービスにデータを送らずにできますか

できます。DeepSeekは自社のハードウェアや自分が管理するクラウド上で動かせるオープンウェイトのモデルを公開しており、突合はそれに向いた処理です。バッチであり、応答速度を要求せず、最大のモデルを必要としません。契約・規制・社内規程が資産データの外部送信を禁じている場合の標準的な答えになります。

これは資産管理システムの代わりになりますか

なりませんし、代わりだと考えることがこの取り組みの主要な失敗要因です。代替されるのは、資産システムに載せる前に必要になる手作業のクレンジングのほうです。実際そのクレンジングこそが案件を止めている原因なので、そこには確かな価値があります。産物はきれいな基準線であり、システムはその基準線を真であり続けさせるものです。

まずどこから

数字の食い違いが最も大きい二拠点を選び、その台帳と対応するIntuneの範囲を書き出し、その部分集合だけで四段階を回してください。二時間ほどで、大きく動く前に知っておく価値のある二つが分かります。各ソースが実際どれだけ離れているか、そしてその差がデータの問題なのか現物の問題なのか。データはきれいになるのに合計の持ち主が誰か言えない、という結論なら、それこそ始める価値のある話です。お問い合わせください。