工場のIT資産管理2026｜契約の半分が台帳の外にある

「工場のIT資産管理を見直したいのですが、何から手をつければいいですか」。タイの日系工場でよく受ける質問です。お答えはいつも同じで、パソコンの台数を数える前に契約の一覧を作ってください、と申し上げます。管理が崩れる原因はシステムが増えることではなく、契約の決裁者がIT部門の外へ散らばることにあるからです。この記事では、7つの契約を抱えるラヨーンの工場を例に、年間支出の半分が台帳の外にあった状態を追いかけます。

工場のIT資産管理が後回しにされる理由 — 契約は増えるが、管理する人は増えない

タイの日系工場で「IT資産管理をやっていますか」と尋ねると、たいていは「一応やっています」という答えが返ってきます。続けて「その台帳を見せてください」とお願いすると、出てくるのはパソコンとサーバーの一覧です。資産番号、機種名、購入年月、使用者名、設置場所。備品管理としては正しく作られていて、更新もされています。

ところが「では、いま契約しているソフトウェアとクラウドサービスの一覧はどこにありますか」と聞くと、途端に空気が変わります。IT部門が契約したものは分かる。しかし総務が契約したチャットツール、経理が契約した人事システム、営業が契約した見積システムについては、契約書がどこにあるのか、年額がいくらなのか、いつ更新されるのかを即答できる人がいません。請求書は経理を通っているので支払いは止まっていない。ただし、それが「IT資産」として一元的に集計された場所は存在しないのです。

この状態が生まれる理由は、担当者の怠慢ではありません。構造の問題です。工場のシステムは、必要になったタイミングで、必要とした部門が、その時々の決裁ルートで契約します。生産管理システムはIT部門と工場長の合議で決まる。給与システムは経理部長が決める。営業支援のクラウドは営業部長が本社の指示で導入する。決裁者が違えば契約書の保管場所も違い、更新の連絡先も違います。

そしてIT資産管理という業務には、明確な期限がありません。生産が止まれば全員が動きますが、台帳が古くなっても誰も困らない。困るのは、監査が入ったとき、ライセンス違反を指摘されたとき、そして予算を削れと言われて削る先が分からないときです。いずれも年に一度あるかないかの出来事なので、日常の優先順位では常に後ろに回ります。

さらに、工場のIT担当は多くの場合ひとりです。あるいは経理や総務との兼務です。契約が5本のうちは記憶で回ります。7本、10本と増えたとき、記憶では回らなくなる。しかし増えたことに気づくのは、たいてい記憶が回らなくなった後です。契約は増えるが、管理する人は増えない。この非対称が、工場のIT資産管理が崩れていく基本的な形です。

IT資産管理と設備台帳は別物 — 「モノ」ではなく「契約」を管理する

工場には立派な設備台帳があります。プレス機、射出成形機、コンプレッサー、フォークリフト。それぞれに資産番号が振られ、取得価額、減価償却、点検履歴、保守業者が紐づいています。工場という組織は、モノを台帳で管理することにかけては非常に習熟しています。

だからこそ、IT資産管理を同じ発想で始めてしまいます。パソコンに資産シールを貼り、サーバーの型番を記録し、設置場所を書く。これは間違いではありませんが、いまのIT支出の実態からは半分ずれています。

理由は単純で、支出の主戦場が「モノ」から「契約」へ移ったからです。オンプレミスのサーバーを買っていた時代であれば、資産の実体はモノでした。買った瞬間に金額が確定し、以降は償却と保守だけです。ところがクラウドサービスやSaaSには実体がありません。あるのは契約と、その契約に紐づくユーザーIDだけです。金額は毎月発生し、ユーザー数やプランによって変動し、放っておくと自動で更新されます。

サイバネットシステムは、IT資産管理の今後の課題として、仮想環境では物理環境との紐付けが目視では困難であること、そしてクラウドはユーザーID単位での管理が必要でシャドーIT化のリスクがあることを挙げています。これはまさに、モノの台帳がクラウドを捕捉できない理由の説明です。設置場所を書く欄はあっても、ユーザーIDを書く欄がない。台帳のフォーマットそのものが、いまの資産を写し取れない形をしているのです。

実務的な結論はこうなります。工場のIT資産管理では、モノの台帳とは別に、契約の台帳を作る必要があります。管理する単位は資産番号ではなく契約番号で、記録すべき項目は設置場所ではなく、決裁部門・年額・課金単位・更新日・解約通知期限です。この2つを同じ表に混ぜようとすると、どちらも中途半端になります。分けて作り、必要なところだけ紐づける。それが出発点です。

なお、契約を単位に費用を見るという発想は、保守契約の設計にも同じように効きます。年額の数字だけを比べても中身は分からない、という構造については業務システムの保守費用の見方で詳しく整理しています。

なぜ2026年に見直しが迫られているのか — クラウド化とSaaS化が台帳を追い越した

「昔からこうだったのに、なぜいま見直すのか」という問いには、市場の構成が変わったから、と答えています。

Mordor Intelligenceの「Thailand IT and Security Market」（2026年8月7日更新）によれば、タイのIT・セキュリティ市場は2025年の99.2億USDから2026年には102.6億USDへ拡大する見込みで、2026年から2031年のCAGRは10.26%とされています。伸びていること自体は驚きではありません。注目すべきは内訳です。同レポートでは2025年の市場構成のうち、コンポーネント別ではソフトウェアが41.72%を占め、導入形態別ではクラウドが55.84%を占めています。

コンポーネント別ではソフトウェアが4割を超え、導入形態別では市場全体の過半がクラウドである。この2つを重ねると、タイでIT支出を管理するという行為の重心が、どこにあるのかが見えてきます。ハードウェアの台数ではなく、ソフトウェアの契約です。しかも設置型ではなく、ユーザーIDと月額課金で動くクラウドの契約です。

多くの工場のIT台帳は、この重心の移動に追いついていません。台帳のフォーマットが作られたのは、まだサーバーとクライアントPCが支出の中心だった時期です。当時の設計思想のまま運用を続けているので、クラウドの契約は台帳の欄に収まりきらず、結果として「台帳の外」に置かれます。置かれた場所は、担当者のメールボックスか、部門のフォルダか、あるいはどこにもありません。

もう一点、2026年に特有の事情があります。この数年で導入された業務用SaaSの多くが、初回契約から2年目、3年目を迎えていることです。初年度は導入時の交渉で価格が抑えられ、担当者も内容を覚えています。2年目以降は自動更新が効き始め、担当者は異動し、プランは初期設定のまま推移します。契約が「静かに動く」期間に入るのが、ちょうどいまなのです。

Money Forward Adminaも、SaaS利用料のコスト最適化に関する解説記事（2026年1月30日公開、2026年4月23日更新）で、把握しきれないサブスクリプション費用が経営を圧迫する構造を扱い、不要なアカウントの削除、プランの見直し、ツール重複の整理を実務の起点として挙げています。日本国内でも同じ問題が起きているということであり、タイ拠点だけの特殊事情ではありません。

タイ拠点でIT資産管理が特に崩れやすい3つの理由

そのうえで、タイ拠点には固有の崩れやすさがあります。3つあります。

1つ目は、決裁ラインが二重になっていることです。 タイ法人には現地の決裁権限がありますが、同時に日本本社の方針で導入されるシステムもあります。本社が全社標準として契約したグループウェアやクラウドストレージは、タイ側の台帳には載りません。費用が本社側で計上されているからです。しかし実際にIDを使っているのはタイの従業員であり、退職者が出れば整理が必要になるのもタイ側です。「誰が払っているか」と「誰が使っているか」がずれている契約は、どちらの台帳にも中途半端にしか載りません。

2つ目は、担当者の入れ替わりが早いことです。 タイの労働市場では転職が一般的で、システム担当が2年から3年で入れ替わることは珍しくありません。日本人管理者も駐在のローテーションで3年から5年で交代します。契約を結んだ人と、その契約を更新する人が別人になる確率が、日本国内より明らかに高いのです。契約の経緯が引き継がれていないと、更新の判断は「前年と同額だから通す」に収束します。

3つ目は、契約書の言語と保管の分散です。 タイ現地のベンダーとはタイ語または英語の契約書、日本のベンダーとは日本語の契約書、グローバルSaaSとはオンラインの利用規約への同意だけ。この3種類が同じ棚に並ぶことはまずありません。とくに3種類目、つまりクレジットカード決済でオンライン契約したサービスは、契約書という形の紙が存在しないので、探しようがない状態になります。

この3つが重なると何が起きるか。IT部門が把握している契約と、実際に会社が払っている契約の間に、恒常的な差が生まれます。しかもその差は、支払いが止まらない限り可視化されません。請求は経理に届き、経理は「毎月来ているから正しいのだろう」と処理する。ここに、誰も嘘をついていないのに実態が分からない、という状態が完成します。

海外拠点への展開そのものが持つ難しさについては、海外拠点へのシステム展開で起きることも併せてご覧ください。導入段階の意思決定が、その後の資産管理の形を決めてしまう部分があります。

台帳から漏れる契約には3つの型がある

台帳から漏れる契約を数多く見てきた結果、漏れ方には3つの型があると整理しています。型が分かれば、探し方が決まります。

第1の型は「部門契約型」です。 総務、経理、営業、品質保証といった部門が、自部門の業務課題を解決するために単独で契約したサービスです。金額が部門決裁の範囲に収まっているため、IT部門の承認を経ていません。悪意はまったくなく、むしろ現場が自主的に改善した結果として導入されています。ただしIT部門から見れば、存在自体が見えない契約です。この型を探すときは、システムの名前ではなく、経理の支払データを部門別に並べるのが最短です。

第2の型は「個人契約型」です。 担当者が個人のクレジットカードや個人アカウントで契約し、経費精算で処理しているケースです。翻訳ツール、図面のビューア、オンラインストレージ、AIアシスタントなど、単価が小さいものが多いのが特徴です。金額としては大きくならないことが多い一方で、リスクは最も高い型です。業務データが会社の管理外のアカウントに保存されており、その人が退職した瞬間にアクセスできなくなるからです。dxecoがシャドーITの解説記事で扱っているのも、まさにこの領域です。

第3の型は「付帯契約型」です。 主契約に付随して発生している契約で、主契約の台帳には載っているのに、付帯部分だけが台帳から抜けているケースです。生産管理システムの追加ライセンス、クラウドサービスのストレージ増設オプション、バックアップの保管期間延長オプション。契約としては1本なので見落としやすく、しかし年額は着実に増えています。この型を探すには、請求書の明細行まで開く必要があります。契約単位ではなく明細単位で見ないと出てこないからです。

この3つの型は、探す場所が全部違います。部門契約型は経理の支払データ、個人契約型は経費精算のデータ、付帯契約型は請求書の明細。IT部門が持っている契約フォルダを何度見直しても、どれも出てきません。棚卸しの初手として、この3か所のデータを取り寄せるところから始めてください。

モデルケース｜ラヨーン工場の7契約を棚卸しする

ここから具体的なモデルケースで見ていきます。以下は独自試算によるモデルケースであり、実在する企業の数値ではありません。金額そのものより、どこに漏れが生じ、棚卸しで何が動くのかという構造をご覧ください。

前提はこうです。タイ・ラヨーン県にある日系の電子部品組立工場、従業員250名。過去8年のあいだに、7つの業務システムを別々のタイミング、別々の決裁者で契約してきました。IT資産管理の専任者はおらず、経理担当者がExcelの台帳を兼務しています。よくある構成です。

棚卸しを実施し、7契約すべてを1枚の表に並べたのが次の内容です。年額はTHB建てです。

この表を作った時点で、すでに一つ目の発見があります。台帳に載っていた4件の年額合計は636,000、これは総支出の49.5%にあたります。逆に台帳外だった3件の年額合計は648,000で、総支出の50.5%です。つまり、この工場が把握していたIT支出は、実際の支出の半分未満でした。

ここで注目していただきたいのは、台帳掲載の有無が「システムの重要度」でも「金額の大小」でも分かれていないことです。分かれているのは決裁部門だけです。IT部門が決裁した4件は全部載っていて、それ以外の部門が決裁した3件は全部載っていない。しかも台帳外の3件のほうが、合計金額では上回っています。単価で見ても、最も高額な契約であるNo.7の見積・受発注システム（264,000）は台帳の外にありました。

この構造は、担当者の注意力ではどうにもなりません。IT部門の担当者は、自分が関与していない契約の存在を知る手段を持っていないからです。台帳が半分しか埋まらないのは、担当者が半分しか働いていないからではなく、担当者に情報が半分しか届いていないからです。

つまり、IT資産管理の精度を上げる方法は「もっと丁寧に台帳をつける」ことではありません。「IT部門を経由しない契約の情報が、どこかで必ずIT部門に届く経路を作る」ことです。この違いは実務の設計を大きく変えます。前者は個人の努力、後者は仕組みの話だからです。

台帳外だった3契約に何が起きていたか

台帳外の3契約について、契約内容と利用実態を調べたところ、3件ともそれぞれ違う形で無駄が生じていました。共通しているのは、どれも「誰も見ていなかった期間」に発生していることです。

No.7 見積・受発注システム（営業部門決裁、年額264,000）。 契約2年目に、プランの自動更新でプレミアムプランへ切り替わっていました。当初の年額は216,000でしたが、更新後は264,000になっています。差額は48,000、当初年額に対して22.2%の上昇です。営業部門は上位プランに切り替わったことを認識しておらず、追加された機能も使っていませんでした。

No.5 社内問い合わせチャットボット（総務部門決裁、年額216,000）。 総務部門が従業員からの問い合わせ対応を効率化するために契約したものです。ところが調査の結果、生産管理システム（No.1）の既存契約の範囲内に、FAQとヘルプの機能が最初から付帯していることが分かりました。つまり機能が重複していたわけです。さらに利用実績を確認すると、月間90件の問い合わせのうち、実際に社内問い合わせとして使われていたのは18件（20.0%）にとどまり、残りはテスト運用や重複起票でした。

No.6 給与・人事システム（経理部門決裁、年額168,000）。 ユーザーID単位の課金体系で、退職者のアカウントが5枠そのまま残っていました。1枠あたりの月額は800 THB、年額にすると9,600 THBです。5枠合計で年額48,000 THBが、誰も使っていないアカウントに対して支払われていたことになります。

3件を並べると、無駄の発生源がそれぞれ違うことが分かります。No.7は契約条件の変化を追っていなかったこと。No.5は他システムとの機能重複を確認していなかったこと。No.6は人事の異動情報とシステムのアカウント情報が連動していなかったこと。原因が違うので、対策も違います。ひとつの施策で3件まとめて解決することはできません。

そして、この3件に共通する条件がひとつだけあります。いずれも台帳の外にあり、年次でレビューされる機会が一度もなかったことです。逆に言えば、台帳に載っていた4件では、こうした状態は見つかりませんでした。台帳に載せることそのものに直接の削減効果はありませんが、載っていれば少なくとも「見る機会」が生まれます。IT資産管理の実務的な価値は、そこにあります。

自動更新が生む「静かな値上げ」

3つの発見のうち、最も気づきにくいのがNo.7の自動更新です。この項目だけ、単独で見ておきます。

クラウドサービスやSaaSの契約は、ほとんどが自動更新を前提に設計されています。解約や条件変更の意思表示がない限り、契約は同じ条件で継続する。これは利用者にとっても事務負担を減らす合理的な仕組みで、それ自体が問題なわけではありません。

問題は、「同じ条件で継続」の中身が、必ずしも同じ金額を意味しないことです。上位プランへの自動移行、利用量に応じた段階的な課金、期間限定だった初年度割引の終了、為替や現地価格改定に伴う調整。いずれも契約条項としては最初から書かれており、事前の通知メールも送られています。ただしその通知は、契約を結んだ担当者のメールアドレス宛に届きます。その担当者が異動していれば、メールは誰にも読まれません。

モデルケースのNo.7では、年額が216,000から264,000へ、差額48,000だけ上がりました。単年で見れば、稟議にかかるほどの金額ではありません。増えたことに気づいた人もいませんでした。しかしこの48,000は、来年も再来年も発生します。しかも、いったん上位プランで更新された契約は、次の更新でも上位プランのまま継続します。放置した期間の長さに比例して、累計の差は開いていきます。

これを「静かな値上げ」と呼んでいるのは、値上げの通知が来ないからではなく、値上げの決裁が存在しないからです。通常、支出が増えるときは誰かが判断します。判断があれば記録が残り、記録があれば後から検証できます。自動更新による増額には、この判断のステップがありません。誰も決めていないのに支出が増えているので、後から「なぜ増えたのか」を追いかける手がかりが残らないのです。

対策は驚くほど単純で、更新日と解約通知期限を台帳に書いておくことに尽きます。多くのSaaS契約には、更新の何日前までに申し出れば条件変更や解約ができる、という期限が設定されています。この期限を過ぎてしまうと、その年は条件を動かせません。つまり交渉のタイミングは、更新日ではなく、更新日から通知期限を引いた日です。台帳にこの日付が書いてあるかどうかで、交渉できるかどうかが決まります。

もうひとつ実務的に効くのが、契約の連絡先を個人のメールアドレスから、部門の共有アドレスへ変更しておくことです。担当者が交代しても通知が届き続けます。手続きとしては数分で終わる作業ですが、実施している工場はほとんどありません。

重複契約はなぜ生まれるか — 機能は重なっても契約は別

No.5のチャットボットは、機能が重複していた典型例です。ただし「調べれば分かったはずだ」と結論づけるのは、実態を見誤っています。重複が起きる構造には、それなりの必然性があるからです。

総務部門の担当者の立場で考えてみます。従業員からの問い合わせ対応に時間を取られている。就業規則、有給の残日数、社会保険の手続き、社内申請の書き方。同じ質問が繰り返し来るので、自動で答えられる仕組みが欲しい。市場を調べるとチャットボットのSaaSが見つかり、価格も部門の決裁範囲に収まる。導入する。ここまでの流れに、判断の誤りはひとつもありません。

一方、生産管理システムにFAQ・ヘルプの機能が付帯していることは、生産管理システムの契約書と製品資料に書かれています。しかしその資料は、IT部門と工場の生産管理担当が持っているもので、総務部門の担当者が読む機会はありません。そもそも総務部門から見れば、生産管理システムは工場の現場が使うもので、社内問い合わせとは無関係な製品カテゴリです。「生産管理システムの資料を読めば解決したかもしれない」という発想が生まれないのは、極めて自然なことです。

つまり重複契約は、情報の非対称から生まれます。既存契約に何が含まれているかを、契約していない部門が知る経路がない。これは調べる努力の問題ではなく、情報が置かれている場所の問題です。

そして重複はもうひとつの層でも起きます。契約が別であれば、機能が重なっていても、システム上は何の警告も出ません。同じ会社の中で、同じ目的の機能に二重に払っていることを検知する仕組みは、個々の業務SaaSの側には組み込まれていません。検知できるのは、全契約を1か所に並べた人間か、そのために作られた管理ツールだけです。

対策として実務的に効くのは、契約台帳に「主な機能」の列を作り、5個から10個程度の粗い機能タグで分類しておくことです。問い合わせ対応、帳票、在庫、実績収集、勤怠、承認ワークフロー、といった粒度で十分です。同じタグが2つの契約についていれば、それが重複の候補になります。厳密な機能比較をする必要はなく、候補を見つけて確認する入口があればよいのです。

なお、モデルケースではチャットボット契約を解約せず、ライトプランへ縮小する判断をしています。利用実績が月18件残っているためです。重複が見つかったからといって、必ずしも全廃が正解ではありません。実績のある使い方を残しつつ、規模を実態に合わせる。この調整のためにも、利用実績のデータが必要になります。

エンジニアリング系ソフトウェアが特に難しい理由

工場のIT資産管理で、最後まで残る難所がエンジニアリング系のソフトウェアです。CADやCAE、設備の設計・シミュレーションに使うソフトウェアがこれにあたります。

OpenLM Japanの「2026年版 エンタープライズIT向けライセンス管理ソリューション徹底比較ガイド」（2026年6月17日公開）は、Autodesk、Bentley、ANSYS、Esri、Dassault Systèmesといったエンジニアリングソフトウェアを、とりわけ高額かつ複雑なライセンス管理を必要とする領域として位置づけています。工場の資産管理でこの領域が難しいのは、次のような事情が重なるためです。

第一に、ライセンスの形態が多様です。特定の端末に紐づくノードロック、社内で同時利用数を管理するフローティング、期間で区切るサブスクリプション、モジュール単位の追加ライセンス。同じ製品でも契約形態が違えば、管理の単位が変わります。「何本持っているか」という問いに、形態を確認せずに答えられません。

第二に、実際に使われているかどうかが見えにくいことです。フローティングライセンスの場合、同時に使える人数の上限を買っているので、上限に対して実際の同時利用がどれくらいだったかを測らないと、適正な本数が分かりません。1年に数回しか起動されていないライセンスと、常時上限に張り付いているライセンスが、台帳の上では同じ「1本」として並びます。

第三に、単価が高いことです。金額が大きい分、余剰があったときの影響も、逆に不足して業務が止まったときの影響も大きくなります。だからこそ削りにくく、結果として「余裕を持って多めに買う」判断が積み上がりやすい領域でもあります。

同ガイドは、ライセンス管理そのものが「誰が何を持っているか」を把握する段階から、リアルタイムの利用分析、AIの活用、FinOpsやGreenOpsへの対応へと進化していることも指摘しています。これは大企業のIT部門を想定した話ですが、方向性としては工場にも当てはまります。台帳を作ることがゴールではなく、利用実績を測って契約に反映するところまでが一連の作業になる、ということです。

とはいえ、最初から利用分析まで実装する必要はありません。エンジニアリング系ソフトウェアを保有している工場であれば、まず「製品名・ライセンス形態・本数・年額・更新日」の5項目を1枚に揃えるだけでも、判断材料は大きく変わります。モデルケースの工場はこの領域の契約を持っていませんが、設計機能を持つ拠点では、ここが最大の金額になることが珍しくありません。

棚卸しをやるとどれだけ動くか — モデルケースの削減内訳

棚卸しの結果として、モデルケースの工場が実行した対策と削減額をまとめます。繰り返しになりますが、これは独自試算であり、実在企業の数値ではありません。

総支出1,284,000に対して、削減額は216,000。削減率は16.8%です。棚卸し後の状態が維持されれば、5年間の単純累計では1,080,000の削減になります（この試算に棚卸しにかかる工数のコストは含めていません）。

内訳を見ていくと、3つの対策の性質がまったく違うことに気づきます。

チャットボットの縮小（120,000） は、機能重複と利用実績の両方を根拠にした判断です。3つの対策のうち最も金額が大きく、そして最も検討に時間がかかりました。既存の生産管理システムのFAQ機能が、総務が求める用途に本当に使えるのかを確認し、月18件の実利用をどう受けるかを決める必要があったからです。金額の大きい対策ほど、技術的な確認と部門間の合意が必要になります。

プランの適正化交渉（48,000） は、自動更新で上がった分を元に戻す交渉です。追加された機能を使っていないという実績があるため、交渉の材料は明確でした。ただしこれは更新日と解約通知期限を把握していないと成立しません。期限を過ぎていれば、話を聞いてもらえても、その年度の金額は動かせないからです。

放置アカウントの解約（48,000） は、3つのうち最も単純で、最も早く実行できる対策です。退職者リストとアカウント一覧を突き合わせるだけで完了します。技術的な検討も、部門間の交渉も不要です。棚卸しを始めるなら、まずここから着手することをお勧めしています。効果が出るまでの時間が最も短く、しかも成果が数字で出るので、次の対策を進めるための社内の理解が得やすいからです。

一方で、この対策には注意点もあります。退職者のアカウントは、削除すると過去のデータへのアクセスも失われることがあります。給与・人事系であれば、在籍期間中の記録を保持する必要が出る場合もあります。解約する前に、データの保持要件を人事・法務の観点で確認してください。単純な作業ですが、確認を飛ばすと後で困ります。

削減率16.8%という数字をどう受け止めるかですが、これは「1年目に一度だけ出る効果」ではないことが重要です。棚卸しの本質的な価値は、削減額そのものより、その後の増額に判断のステップが入るようになることにあります。台帳と更新監視の仕組みができれば、自動更新による静かな増額は起きなくなります。効果は削減額として1回、増額の抑止として毎年、という二重の形で出ます。

IT資産管理の実務フロー｜台帳・棚卸・契約統合・更新監視の4段階

ここまでの内容を、実務の手順として4段階に整理します。順番に意味があるので、飛ばさずに進めてください。

第1段階は台帳の整備です。 ゴールは「いま会社が払っているIT関連の契約を、1枚の表に全部並べる」ことです。IT部門の契約フォルダだけでは埋まりません。経理から支払データを部門別に取り寄せ、経費精算のデータからIT関連の項目を抽出し、請求書の明細行まで開きます。前述の3つの型、部門契約型・個人契約型・付帯契約型を、それぞれ違う場所から拾い上げる作業です。この段階では、金額の妥当性を判断しません。とにかく網羅することだけを目指します。判断を混ぜると作業が止まります。

第2段階は棚卸しです。 台帳に並んだ契約について、契約条件と利用実態を突き合わせます。契約書に書かれた本来のプランと、いま適用されているプラン。契約しているユーザー数と、実際にログインしているユーザー数。契約している機能と、実際に使われている機能。この段階で必要になるのが、各サービスの管理画面から出力する利用実績データです。ほとんどのSaaSは管理者向けにログイン履歴やアクティブユーザー数のレポートを持っています。使っていない機能があるはずだ、という感覚ではなく、データで確認します。

第3段階は契約統合です。 棚卸しで見えた重複・過剰を、実際の契約変更に反映します。プランの縮小、ユーザー数の削減、重複契約の解約または縮小、更新時期の揃え直し。この段階でぶつかるのが、部門間の調整です。契約している部門にとっては、自部門の判断を否定される話に見えかねません。「無駄遣いだった」という切り口ではなく、「会社全体で見ると同じ機能に二重に払っている状態なので、どちらに寄せるかを決めたい」という切り口で進めてください。実務上、この言い方の違いだけで進み方が変わります。

第4段階は更新監視です。 ここが最も軽視され、そして最も効きます。全契約の更新日と解約通知期限を一覧にし、通知期限の30日前にアラートが出るようにします。仕組みとしてはカレンダーの繰り返し予定でも構いません。重要なのは、アラートの宛先を個人ではなく複数名にすることと、アラートが出たときに何をするかを決めておくことです。「更新月が近い契約について、利用実績を確認して継続・縮小・解約を判断する」という一文を運用ルールに書いておきます。

この4段階のうち、第1段階と第2段階は一度きりの作業、第3段階は契約の更新タイミングに合わせて順次、第4段階は恒常的な運用です。よくある失敗は、第1段階と第2段階を完璧にやろうとして息切れし、第4段階まで到達しないことです。台帳の精度は8割で構いません。8割の台帳に更新監視がついている状態のほうが、10割の台帳が更新されずに放置されている状態より、はるかに機能します。

所要期間について、これまでご支援してきた範囲での感覚をお伝えすると、契約数が10本前後の工場であれば、第1段階と第2段階に1か月から2か月、第3段階は各契約の更新日に合わせて1年かけて順次、というのが現実的な進み方です。相場として一般化できる数字ではありませんが、全部を一度に変えようとする必要はない、という点だけは共通しています。

内製で持つ部分と外部に任せる部分の線引き

IT資産管理を全部内製すると、担当者が抜けた瞬間に止まります。全部外注すると、契約情報という機微な情報を外に預けることになり、しかも判断の速度が落ちます。線引きが必要です。

実務的に機能しているのは、台帳の保持と更新監視は社内、棚卸しの分析と契約交渉の設計は外部、という分け方です。

社内で持つべきもの。 まず台帳そのものです。どの契約が存在し、いくら払い、いつ更新されるか。これは会社の基礎情報なので、外部に預けるべきではありません。次に更新監視の運用です。アラートを受け取り、判断のプロセスを回す部分は社内に置きます。判断そのものを外部に委ねると、部門との調整が進みません。3つ目に、退職・異動に伴うアカウント整理です。人事情報と連動する作業なので、社内で完結させるのが自然です。モデルケースのNo.6で見つかった48,000は、この運用があれば発生しませんでした。

外部に任せてよいもの。 ひとつは、初回の棚卸しにおける分析です。7本、10本の契約を横に並べて機能の重複を見抜く作業は、複数の企業の構成を見た経験があるほど速くなります。社内でやると、既存の使い方が前提になってしまい、重複そのものが見えにくくなる面もあります。もうひとつは契約交渉の設計です。どの条件が交渉可能で、どのタイミングで持ち出すべきか、代替案として何を提示できるか。この判断は市場の相場観に依存するので、外部の知見が効きます。

線引きを機能させる条件が2つあります。 1つは、社内側の担当を1人にしないことです。タイでは転職が一般的なので、台帳の場所と更新の運用を知っている人を最低2人置いてください。1人体制の台帳は、その人が辞めた瞬間に「存在するが誰も開けないファイル」になります。もう1つは、外部に渡す情報の範囲を先に決めておくことです。契約金額と契約条件は渡す必要がありますが、従業員の個人情報まで渡す必要はありません。棚卸しに必要なのは「アカウント数」であって「氏名」ではない、という切り分けをしておきます。

新しくシステムを追加する場面でも、この線引きは効きます。導入検討の段階から契約条件を台帳の項目に沿って整理しておけば、稼働後に台帳へ載せる作業が発生しません。導入と資産管理を別の仕事にしないことです。導入費用の構造から確認したい場合は、業務システム開発の費用と構成も参考になります。

タイ・ASEAN拠点で固有に効く論点

タイで運用する場合に、日本国内の議論には出てこない論点を挙げます。

契約通貨と支払方法の混在。 タイ拠点のIT契約は、THB建て、USD建て、JPY建てが混在します。グローバルSaaSはUSD建てのクレジットカード決済、日本のベンダーはJPY建ての本社経由請求、現地ベンダーはTHB建ての振込。台帳を作るとき、この3種類を同じ列に並べると合計が出せません。実務的には、台帳に「契約通貨」の列と「THB換算額」の列を分けて持ち、換算レートの基準日を決めておきます。年に1回の棚卸しであれば、期末レートで揃えるのが扱いやすい方法です。

本社契約と現地契約の境界。 前述のとおり、本社が全社標準として契約したサービスは、現地の台帳に載りません。しかしIDを使っているのは現地の従業員です。ここで決めておくべきなのは、退職者が出たときに誰がアカウントを止めるか、という一点です。費用が本社持ちだと、現地には止める動機が生まれにくい。しかし止めないままだと、退職者が会社のデータにアクセスできる状態が続きます。費用の話とセキュリティの話を分けて、後者は必ず現地の運用に含めてください。

言語と契約書の保管。 契約書がタイ語・英語・日本語で分散していると、更新時に条件を確認できる人が限られます。全文を翻訳する必要はありませんが、契約期間、更新条件、解約通知期限、料金体系の4項目だけは、台帳に日本語または英語で転記しておいてください。原本の言語が何であれ、判断に必要な情報が読める状態になります。

担当者交代の頻度。 現場を見ている感覚では、タイ側のシステム担当が2年から3年、日本人管理者が3年から5年で交代することは珍しくありません。この前提で設計するなら、台帳は個人のPCではなく共有フォルダに置き、契約の連絡先メールアドレスは部門の共有アドレスにし、更新アラートの宛先は複数名にする。いずれも技術的には簡単ですが、決めておかないと自然には実現しません。

現地ベンダーとの契約更新の商習慣。 タイのベンダーとの契約では、更新時の条件見直しが日本ほど形式化されていないことがあります。逆に言えば、こちらから利用実績のデータを持って交渉すれば、条件が動く余地は残されています。モデルケースのNo.7で48,000の適正化ができたのも、追加機能を使っていないという実績があったからです。データのない交渉は値切り交渉になり、データのある交渉は条件の再設計になります。

電子帳票やクラウドサービスの現地展開。 タイ拠点では、日本本社で使っている製品をそのまま持ち込むケースと、現地で調達するケースが混在します。ライセンス体系が国によって異なる製品もあるため、契約前に現地での提供形態を確認しておくのが安全です。たとえば電子帳票の分野では、i-Reporterの価格とライセンス体系のように、ライセンスの数え方そのものが費用構造を決める製品があります。

棚卸しシートに書く10項目

台帳のフォーマットについて、最低限そろえるべき項目を挙げます。すべて、記憶ではなく紙に書いてはじめて機能する項目です。

• システム名と提供元。日本語名と英語名の両方を書く。ベンダーとの連絡時に名称が食い違うことを防ぐため
• 決裁部門と現在の管理責任者。契約時の決裁者ではなく、いま判断できる人の名前を書く
• 契約形態。買い切りか、年間サブスクリプションか、月額課金か。自動更新の有無も同じ欄に書く
• 課金単位。ユーザーID単位か、同時接続数か、拠点単位か、データ量か。ここが変動費の発生源になる
• 契約数量と実利用数量。契約しているID数と、直近1か月に実際にログインしたID数を並べて書く
• 年額とその通貨。THB換算額を別の列に持ち、換算の基準日を明記する
• 契約開始日と更新日。更新日が「契約から1年後」としか分からない場合は、実際の日付を計算して書く
• 解約通知期限。更新日の何日前までに申し出が必要かを、日付そのもので書く
• 主な機能タグ。問い合わせ対応、帳票、在庫、実績収集、勤怠、承認ワークフローといった粗い分類で構わない
• データの保管場所と退職時の処理。クラウド上のどこにデータがあり、利用者が退職したときに誰が何をするか

10項目のうち、最初に埋まらないのはたいてい8番目の解約通知期限です。契約書を開かないと分からず、しかもオンライン契約の場合は利用規約の中に書かれているためです。ここを埋める作業には手間がかかりますが、交渉可能なタイミングを決める項目なので、省略しないでください。

5番目の契約数量と実利用数量も、多くの工場で空欄のままになります。実利用数量はサービスの管理画面から取得するもので、契約書には書かれていないからです。しかしこの2つの数字が並んだ瞬間に、削減の候補が自動的に浮かび上がります。モデルケースのNo.6で見つかった5枠の放置アカウントも、この2列を並べれば初回の棚卸しで発見できました。

既存の台帳がある場合は、この10項目のうちいくつが埋まっているかを数えてみてください。5項目未満であれば、その台帳は資産の記録としては機能していても、費用の管理には使えない状態です。

よくある失敗5パターン

タイの日系工場で実際に見てきた失敗を5つ挙げます。

パソコンの台数から始めてしまう。 最も多いパターンです。IT資産管理と聞いて、まず端末の棚卸しに着手する。作業量は大きく、達成感もありますが、支出の構成から見ると効果が限定的です。前述のとおり、いまの支出の中心はソフトウェアとクラウドの契約に移っています。端末の棚卸しをやるなとは言いませんが、順番は契約が先です。契約の棚卸しは端末の全数調査より短い期間で終わることが多く、金額としての効果も先に出ます。

IT部門の中だけで台帳を作る。 IT部門が把握している契約を丁寧に整理しても、モデルケースで見たとおり、それは支出の半分にしかなりません。台帳を作る作業の入口は、IT部門の契約フォルダではなく、経理の支払データです。ここを間違えると、精度の高い半分の台帳ができあがります。

「無駄遣い」という切り口で部門に話しに行く。 部門契約型の契約は、その部門が業務課題を解決するために正当な判断で導入したものです。棚卸しの結果を「無駄があった」という言葉で伝えると、部門は防御的になり、次から情報が出てこなくなります。IT資産管理は継続的な運用なので、一度の削減より、情報が集まり続ける関係のほうが価値があります。

台帳を作って終わりにする。 最初の棚卸しで削減効果が出ると、そこで一区切りついた気分になります。しかし台帳は作った瞬間から古くなります。半年後には新しい契約が2本増え、1年後には更新条件が変わっている。4段階のうち最後の更新監視まで到達しないと、2年後にはまた同じ状態に戻ります。台帳の作成は作業、更新監視は運用。この2つは別のものです。

退職者のアカウント整理を人事に任せきりにする。 退職手続きのチェックリストに「システムのアカウント停止」と一行だけ書いてあり、具体的にどのシステムかが書かれていないケースです。人事担当者は全システムの一覧を持っていないので、把握しているものだけを止めます。台帳外の契約は当然そこから漏れます。対策は、退職手続きのチェックリストに、システム名を個別に列挙することです。台帳ができていれば、そのままリストにできます。

よくある質問

IT資産管理とは何を管理することですか？

ハードウェア、ソフトウェア、そしてそれらに紐づく契約とライセンスを、会社の資産として一元的に把握する活動です。工場では設備台帳の延長として端末管理から入ることが多いのですが、いまの支出の中心はソフトウェアとクラウドの契約に移っています。Mordor Intelligenceのタイ市場レポートでも、2025年の市場構成でソフトウェアが41.72%、導入形態ではクラウドが55.84%を占めています。したがって工場のIT資産管理では、モノの台帳とは別に契約の台帳を作り、決裁部門・年額・課金単位・更新日・解約通知期限を管理する必要があります。

ソフトウェアライセンス管理は何から始めればいいですか？

契約フォルダではなく、経理の支払データから始めてください。IT部門が把握している契約だけを整理しても、モデルケースで見たとおり支出の半分程度にしかなりません。支払データを部門別に並べ、経費精算のデータからIT関連の項目を抽出し、請求書は明細行まで開く。この3か所から、部門契約型・個人契約型・付帯契約型の3つの型を拾い上げます。網羅が終わってから、契約数量と実利用数量を突き合わせる棚卸しへ進みます。最初から金額の妥当性を判断しようとすると作業が止まるので、まず並べることに集中してください。

シャドーIT対策として、まず何を止めるべきですか？

止めることから入らないほうが、結果的にうまくいきます。個人契約でツールを使い始めた担当者は、業務上の必要があってそうしています。一律に禁止すると、より見えない場所へ移動するだけです。実務的には、まず経費精算データから存在を把握し、業務上必要なものは会社契約へ移行する。そのうえで、データの保管場所と退職時の扱いを明確にします。サイバネットシステムも、クラウドはユーザーID単位の管理が必要でシャドーIT化のリスクがあることを課題として挙げています。管理の単位をIDに合わせることが、禁止よりも先に来る対策です。

システム契約の更新管理はどう仕組み化すればいいですか？

更新日ではなく、解約通知期限を基準に管理してください。多くのSaaS契約には、更新の何日前までに申し出れば条件変更や解約ができるという期限があります。この期限を過ぎると、その年度は条件を動かせません。台帳に解約通知期限を日付で書き、その30日前にアラートが出るようにします。アラートの宛先は個人ではなく複数名にし、契約の連絡先メールアドレスも部門の共有アドレスへ変更しておきます。担当者が交代しても通知が届き続ける状態を作ることが、仕組み化の実体です。

IT予算の見える化は、どこまでやれば効果が出ますか？

契約単位の年額が1枚に並び、合計が出せる状態になれば、最初の効果は出ます。モデルケースでは、7契約を1枚に並べた時点で「台帳に載っていたのは総支出の49.5%だった」ことが分かり、そこから3つの対策で年額216,000 THB、削減率16.8%の削減につながりました。次の段階として、契約数量と実利用数量を並べると、削減の候補が具体的に浮かび上がります。最初から利用実績の自動収集やダッシュボードを構築する必要はありません。Excel1枚と、更新日のアラートで十分に機能します。

まとめ

要点を整理します。

工場のIT資産管理が崩れるのは、システムの数が増えるからではありません。契約の決裁者がIT部門以外に分散するからです。決裁部門が違えば契約書の保管場所も更新の連絡先も違い、IT部門には情報が届きません。台帳が半分しか埋まらないのは、担当者の努力不足ではなく、情報の経路が設計されていないためです。

管理すべき対象も変わっています。設備台帳の発想でモノを数えても、いまの支出は捕まえられません。タイのIT・セキュリティ市場では、2025年の構成でソフトウェアが41.72%、導入形態ではクラウドが55.84%を占めています。管理の単位は資産番号ではなく契約番号であり、記録すべきは設置場所ではなく、決裁部門・年額・課金単位・更新日・解約通知期限です。

モデルケースの試算では、ラヨーンの電子部品組立工場が抱えていた7契約の年額合計は1,284,000 THBで、そのうち台帳に載っていたのは636,000 THB、総支出の49.5%にとどまりました。台帳外だった3契約では、自動更新による年額216,000から264,000への上昇（差額48,000、22.2%）、月間90件中18件（20.0%）しか使われていない重複契約、退職者アカウント5枠の放置による年額48,000の無駄が、それぞれ見つかっています。棚卸し後に実行した3つの対策で年額216,000 THBを削減し、削減率は16.8%、5年の単純累計では1,080,000 THBになりました。これは独自試算であり実在企業の数値ではありませんので、金額ではなく、どこに漏れが生まれてどう塞ぐかという構造をご覧ください。

実務としては、台帳の整備、棚卸し、契約統合、更新監視の4段階で進めます。最も軽視され、最も効くのが4段階目の更新監視です。台帳の精度が8割でも更新監視がついていれば機能しますが、精度10割の台帳でも更新されなければ2年で元に戻ります。社内で持つのは台帳と更新監視とアカウント整理、外部に任せてよいのは初回の分析と交渉設計、という線引きが実務的です。

タイ拠点では、契約通貨の混在、本社契約と現地契約の境界、契約書の言語の分散、担当者交代の頻度が、いずれも台帳を崩す方向に働きます。だからこそ、台帳を共有フォルダに置き、連絡先を共有アドレスにし、アラートの宛先を複数名にするという単純な設計が効いてきます。

まずは、いま会社が払っているIT関連の契約を1枚に並べるところから始めてみてください。それだけで、把握できていた割合が見えます。

自社の契約が何本あるのか分からない、という段階でも構いません。TOMAS TECHはタイの日系工場向けに生産管理をはじめとする業務システムの導入と運用を手がけており、既存の契約一覧を一緒に整理するところからのご相談も承っています。新しいシステムの導入を前提にしないご相談も歓迎ですので、まず現状を整理したいという方はお問い合わせからお声がけください。

参考情報

• OpenLM Japan — 2026年版 エンタープライズIT向けライセンス管理ソリューション徹底比較ガイド（2026年6月）
• サイバネットシステム — IT資産管理に関する今後の課題（IT資産管理ナレッジ）
• サイバネットシステム — ソフトウェアライセンス管理の重要性と管理のポイント（IT資産管理ナレッジ）
• Money Forward Admina — SaaSコスト削減の決定版 情シスが実践すべき最適化とライセンス管理（2026年1月公開、2026年4月更新）
• Mordor Intelligence — Thailand IT and Security Market Size and Share Analysis（2026年8月更新）
• dxeco — シャドーITとは？潜むリスクと原因、調査から対策まで5つのステップで徹底解説（dxecoコラム）