業務システムの保守費用2026｜契約が守るのは壊れた時だけ

「保守契約を更新するたびに見積が上がる。それでも止まるときは止まる」。タイの日系工場でよく聞く話です。業務システムの保守費用が読めなくなる原因は、金額の大きさではありません。契約が「壊れたら直す」しか約束していないことにあります。工場が本当に困るのは「変わったら直す」ほうです。この記事では保守作業を4種類・費用を5層に分解し、年額450,000 THBの契約と810,000 THBの契約を5年で比べます。

業務システムの保守費用が読めないのは、契約が「壊れた時」しか約束していないから

保守費用の相談を受けるとき、最初に見せていただくのは見積書ではなく契約書の別紙です。そこに書かれているのは、たいてい次の3つだけです。受付窓口の連絡先と受付時間、障害が起きたときの一次対応、そして定期的な稼働監視とバックアップの確認。つまり「システムが壊れた状態から、元の状態へ戻す」ための約束です。

一方で、工場のシステムが実際に手を入れられる理由を1年分並べてみると、様相が変わります。取引先から「納品書のフォーマットをこの様式に変えてほしい」と言われる。新しい製品群が立ち上がって品目マスタの桁数が足りなくなる。第2工場が立ち上がって拠点コードという概念そのものが必要になる。サーバーのOSがサポート終了を迎える。データベースのバージョンが上がって、アプリケーション側の互換性を確認しなければならなくなる。原価計算のルールが本社の方針変更で変わる。

これらは一つも「壊れて」いません。システムは今日も動いています。動いているのに、そのままでは業務が回らなくなる。これが「変わったら直す」の領域です。そして多くの年額保守契約は、この領域を含んでいません。含んでいないことは契約書に明記されているのですが、「別途お見積り」という一行に圧縮されているので、契約を結ぶ時点では金額が見えないのです。

ここに保守費用が読めなくなる構造があります。年額の欄には「変わったら直す」が載っていないので、年額を並べて比較するかぎり、安い契約のほうが必ず安く見えます。しかし実際に払う金額は、年額に「別途お見積り」の累計と、その対応を待っている間に止まっていた時間の損失を足したものです。この2つは年額表には出てきません。5年の総額と、年間の停止時間に出てきます。

だからこの記事では、年額を比べません。5年の総額と停止時間で比べます。そのうえで、年額で44%安い契約が、5年総額（停止損失を含む）では9.2%高くなる、という逆転がどこで起きるのかを、費用の層に分解して追いかけます。逆転の原因は「値上げ」でも「ベンダーの怠慢」でもなく、契約設計の段階で層を1つ2つ外したことにあります。

日本企業のIT予算は、今も4分の3が現行維持に消えている

感覚の話に見えるかもしれないので、統計を置きます。日本情報システム・ユーザー協会（JUAS）の『企業IT動向調査 報告書2026』は、2025年9月5日から10月24日にかけて、東証上場企業とそれに準じる計4,500社を対象に実施され、957社から回答を得ています（有効回答率21.3%）。上場企業層の実態を見るには十分な母数です。

この調査で、IT予算の配分は25年度でランザビジネス（現行システムの維持・運用）が75.9、バリューアップ（新しい価値を生む投資）が24.1という比率になっています。予算の4分の3強が、すでにあるものを動かし続けるために消えている計算です。

さらに製造業に絞ると数字は重くなります。加工組立型製造業の25年度のバリューアップ比率は23.3%、裏返せばランザビジネスが76.7%です。タイの日系工場の多くはこの業種区分に入ります。売上規模で見ても、売上高100億円未満の企業は現在ランザビジネス78.2対バリューアップ21.8で、規模が小さいほど維持に食われる傾向がはっきり出ています。

興味深いのは目標値との差です。全体の3年後目標はバリューアップ比率32.7%、売上高100億円未満の企業でも30.7%を目標に置いています。つまり企業側は「維持に食われすぎている」と自覚していて、3割程度までは新規投資に振り向けたいと考えている。それでも現状が2割前後で止まっているということは、維持のほうが計画どおりに減っていない、ということです。

同じ調査で、IT予算が増える理由の1位は「既存システム・基盤の刷新・更新・増強」でした。IT予算が増加する企業のうち、25年度計画で66.3%、26年度予測で60.3%がこれを挙げています。予算を増やす理由の筆頭が、新しい何かを始めることではなく、今あるものを作り直すことなのです。

この2つを重ねると、実務的な含意が出てきます。予算の75.9%が維持に消えていて、増額を計画する企業の6割強はその理由に既存基盤の刷新・更新を挙げている。ならば保守契約の設計は、投資判断と同じ重みを持つはずです。ところが現場では、保守契約は「更新の稟議」として、前年と同額かどうかだけで通されることが多い。中身の層構成を見直す機会が制度として存在しないのです。これから契約更新を迎えるなら、金額の増減ではなく層の増減を見てください。

タイ拠点で保守が重くなる3つの理由

日本国内と同じ構造の会社でも、タイ拠点では保守の重さが変わります。理由は3つあり、いずれも数字で確認できます。

1つ目は、そもそもデジタル活用の土台が薄いことです。ジェトロの『2025年度 海外進出日系企業実態調査（アジア・オセアニア編）』は2025年8月から9月にかけて20の国・地域で実施され、有効回答は5,109社です。このうちデジタル技術を導入・利用・投資していると答えた企業の割合は、総数で53.5%、ASEANで52.1%。これに対してタイは46.1%（回答企業583社）で、ASEAN平均を6ポイント下回っています。周辺国より進んでいるという印象を持たれがちですが、少なくとも日系企業のデジタル活用という指標では下回っている、というのが実態です。

2つ目は人材です。同じ調査の課題項目で、「デジタル人材の不足」が60.7%で1位。2位が「導入や運用のコストが高い」で56.0%です（有効回答4,235社）。以下、「投資に見合う売り上げが見込めない」が26.6%、「既存のインフラとの統合が困難」が17.0%と続きます。ここで注目したいのは「適切な外部パートナーが不足」が10.1%にとどまっている点です。パートナーがいない、というより、いても自社側に受け止める人がいない。この構図が保守費用に直結します。社内で一次切り分けができないと、些細な事象まで外部に投げることになり、一次対応の層が膨らむからです。

3つ目は、日本本社との距離です。タイと日本の時差は2時間。タイの午後4時が日本の午後6時なので、タイ側の夕方に発生した障害は、日本側の担当者がすでに退勤している時間帯に当たることがあります。加えてタイの祝日は日本と重ならないものが多く、ソンクラーンのように連続する期間もあります。「営業時間内対応」という一行が、どちらの国のカレンダーで動くのかを決めていない契約は、実際に止まったときに揉めます。

さらに言語の層があります。工場の現場で最初に異常に気づくのはタイ人のオペレーターやスーパーバイザーで、報告を受けるのは日本人の工場長や管理部長、そして本社の情報システム部門です。受付窓口がタイ語しか受け付けない、あるいは日本語しか受け付けないと、この経路のどこかで翻訳が挟まり、症状の記述が痩せます。「エラーが出た」だけが伝わって、画面もコードも伝わらない。切り分けのやり直しが発生して、復旧が遅れます。

タイでの体制づくりを一から考える段階であれば、タイのシステム開発会社の選び方も併せて確認しておくと、保守フェーズまで見据えた選定基準が整理できます。

保守作業は4種類ある — 復旧・維持・変更・進化

ここから分解に入ります。保守という言葉が指している作業は、性質の異なる4種類に分けられます。この分類は費用の議論をするための実務的な区分で、契約書の言葉づかいとは必ずしも一致しません。だからこそ、自社の契約がどこまでを含んでいるのかを、この4分類に当てはめて読み直す価値があります。

復旧（壊れたものを元に戻す）。エラーで処理が止まった、サーバーが応答しない、特定の画面だけ開かない、といった障害への対応です。原因の切り分け、暫定回避、恒久対策までを含みます。多くの契約はこの領域を中心に書かれています。ただし「一次対応まで」と「復旧完了まで」では中身が大きく違うので、後述のSLAの節で改めて扱います。

維持（壊れないように保つ）。バックアップの取得と復元テスト、ディスク使用量やログの監視、セキュリティパッチの適用、証明書の更新、データベースの再編成といった予防的な作業です。作業自体は地味で、やっていても誰も気づかない。逆に止めていても半年くらいは何も起きないので、コスト削減の対象になりやすい領域です。削った影響は3年目あたりで表面化します。

変更（外の要求に合わせて作り替える）。法改正への対応、取引先要求による帳票やデータ連携の変更、拠点追加に伴うマスタ拡張と権限設計の見直し、OSやデータベースのサポート終了に伴う更新。システムは壊れていないのに、そのままでは使えなくなるので手を入れる、という作業です。工場のシステムで実際に工数が出ていくのは、多くの場合ここです。

進化（新しい価値を足す）。実績入力のハンディ端末対応、設備からのデータ取り込み、ダッシュボードの追加、他システムとの新規連携。これは明確に開発案件であり、保守契約に含めるべきかは議論の余地があります。ただし「進化」として切り出したつもりの案件が、実は「変更」だった、という取り違えは頻繁に起きます。

4分類の実務的な意味は、費用の予測可能性が種類ごとに違うことにあります。復旧と維持は、システムの規模と構成が決まれば工数がほぼ読めます。変更は、外部環境の変化に依存するので発生時期が読めませんが、5年というスパンで見れば「必ず何件かは起きる」と言い切れます。進化は、経営判断で発生するので完全に不定です。

読めるものは定額に、読めないが必ず起きるものは工数枠に、完全に不定のものは都度見積に。これが層設計の原則です。ところが実際の契約では、読めるものだけが定額に入り、必ず起きるものが都度見積に落ちている。次の節で、その落ち方を見ます。

年額保守が実際に含んでいるのは、4種類のうち1.5種類

タイで実際に交わされている年額保守契約の別紙を4分類に当てはめると、多くの場合こうなります。復旧は含まれる。ただし「平日日中の一次対応まで」という限定がつき、恒久対策の作業は実費になることがある。維持は一部だけ含まれる。監視とバックアップの確認は入っているが、パッチ適用やバージョン確認は「対象外」または「別途」。変更は含まれない。進化はもちろん含まれない。

数えると、4種類のうち1種類と半分。「1.5種類」というのはそういう意味です。契約書に「保守」と書いてあるので4種類全部が入っているように読めますが、実際に約束されているのは復旧と、維持の一部だけです。

この事実自体は、ベンダー側の不誠実を意味しません。変更対応の工数は事前に読めないので、定額に入れると見積が跳ね上がります。競合と年額を並べられる場面で、読めない工数を織り込んだ側が負けるのは当然です。結果として、市場全体が「年額から変更対応を外す」方向に最適化されてきた。買う側の比較の仕方が、契約の中身を決めてきたわけです。

では買う側は何を確認すればよいか。契約更新の場で、次の質問を紙で投げてみてください。答えが揃わないなら、その契約は1.5種類のままです。

• 過去12か月に発生した作業を、復旧・維持・変更・進化のどれに分類したか。件数と工数を出せるか
• そのうち、追加見積になった作業は何件で、合計いくらだったか
• 維持の項目のうち、実際に実施したものと未実施のものはどれか。未実施の理由は何か
• 次の12か月に発生が見込まれる変更を、把握している範囲で列挙できるか
• 現行のOS・データベース・ミドルウェアのサポート終了日はいつか。誰が追跡しているか

とくに最後の項目は効きます。OSやデータベースのサポート終了日は、発生時期が事前に確定している数少ない「変更」です。日付が分かっているのに予算化されていないなら、その契約は変更の層を誰も見ていない、ということになります。

分類の結果を1枚の表にしておくと、次の更新交渉で強い材料になります。「昨年は変更がこれだけの件数と工数で発生し、追加費用はこれだけかかった。これを定額の工数枠にした場合の年額はいくらか」という聞き方ができるようになるからです。年額の比較から、層の比較へ議論を移す。それが目的です。

保守費用は5層で見る

4分類は「何をするか」の区分でした。次は「何に払っているか」の区分です。保守費用は5つの層に分けると、契約間の比較ができるようになります。

単位はTHB、年額です。この表の読み方を層ごとに説明します。

層1は、パッケージ製品を使っている場合にベンダーへ支払う保守料と、クライアント側のライセンスです。この層は交渉余地が小さく、値引きを狙うより、使っていないライセンス数を毎年棚卸して減らすほうが確実です。利用者20名の想定なので、退職者・異動者の分がそのまま残っていないかを確認します。

層2は、サーバー本体、OS、データベース、バックアップ媒体、回線の費用です。オンプレミスなら償却と保守、クラウドなら月額課金です。この層で見落とされやすいのはバックアップの復元テストで、取得だけしていて戻せるか確認していないケースが本当に多い。取得は層2、復元テストは層3か層5に落ちるので、どの層の作業範囲にも明記されず、結果として誰も実施していない状態が起きます。

層3は、受付窓口の維持と、障害時の切り分け・復旧作業です。契約Aの84,000と契約Bの240,000の差は、対応時間の幅（平日日中のみか、時間外を含むか）、復旧作業を実費にするか含めるか、そしてパッチ適用や容量監視といった予防作業まで持たせるかの差です。ここは対応品質と直結する層なので、単純に安いほうを選ぶと停止時間に跳ね返ります。

層4は、変更対応の工数枠です。契約Aはゼロ、つまり変更が発生するたびに都度見積になります。契約Bの135,000は、年間で一定の工数をあらかじめ確保しておく枠の費用です。枠を使い切らなければ繰り越すのか失効するのかは、契約に書いておく必要があります。

層5は、知識を残すための費用です。仕様書の更新、年1回の構成棚卸、引き継ぎ資料の整備。この層は効果が最も見えにくく、真っ先に削られます。そして削った影響は、担当者が変わった瞬間か、ベンダーを切り替えようとした瞬間に、まとめて表面化します。

層1と層2は契約AとBで同額です。差がついているのは層3・層4・層5、つまり「人が関わる部分」だけです。安い契約とは、モノの費用が安い契約ではなく、人の関与を減らした契約なのです。

独自試算｜年額450,000 THBの契約と810,000 THBの契約を5年で比べる

ここからは具体的なモデルケースで計算します。以下はあくまでモデルケースの試算であり、実際の金額は導入規模・業務範囲・拠点構成によって変わります。数字そのものより、どの層で差がつき、どこで順位が入れ替わるかという構造を見てください。

前提は次のとおりです。タイ・アユタヤ県の日系加工組立工場、従業員300名。5年前に導入した生産管理システムで、受注から出荷までをカバーし、利用者は20名。オンプレミスのサーバー1台とクライアント20台という構成です。初期導入費（ソフト・ハード・構築の合計）は4,500,000 THB。そしてシステムが止まっている1時間あたりの逸失利益を22,000 THBと置きます。

逸失利益の置き方について補足します。ここでは出荷が止まることによる機会損失と、手作業への切り替えで発生する追加工数を合わせた概算です。実務では、月間出荷額を稼働時間で割った粗い数字から始めて、手作業へのフォールバックが可能な業務と不可能な業務を分けて調整します。自社の数字を入れ替えて読んでください。

この工場が、保守契約の更新にあたって2つの案を比較しています。

契約Aは契約Bより年額で44%安い、という関係です。初期導入費に対する比率で見ると10.0%と18.0%。国内の公開情報を参考値として挙げると、システム開発の発注支援サイト「システム幹事」（2025年10月10日更新）は、サービス委託費を除いた保守費用の目安を開発費の約5%、大規模システムで約15%としています。これは一次統計ではなく事業者側が示す目安ですが、契約Aの10.0%は目安の範囲内、契約Bの18.0%はやや上、という位置づけになります。

年額だけを見れば、契約Aを選ぶ判断は合理的に見えます。差額は年間360,000 THB。5年で1,800,000 THBの差です。稟議で「保守費用を44%削減」と書ける金額でもあります。

そして5年後、契約料の累計はこうなります。契約Aが2,250,000 THB、契約Bが4,050,000 THB。ここまでは予定どおりです。問題は、この表に載らなかった費用のほうです。

なお、そもそもの導入費用の構造から確認したい場合は、業務システム開発の費用と構成を先に読んでおくと、保守費用が初期費用のどこに紐づいているかが把握しやすくなります。

契約の外に出た費用は何だったのか

5年間に実際に発生した作業のうち、契約の外に出た費用を並べます。金額はTHB、5年の合計です。

一つずつ、なぜ発生したかを確認します。

帳票・データ連携の改修（2件）。大手取引先が納品データの様式を変更し、EDIの項目が増えたケースと、別の取引先が指定伝票のレイアウトを変えたケースです。どちらもこちらの都合ではなく、取引を続けるために必要な変更です。断る選択肢が事実上ありません。契約Aでは240,000と180,000の追加見積になりました。契約Bでは層4の工数枠で吸収されています。

OSとデータベースのサポート終了に伴う更新。3年目に発生しました。サーバーOSとデータベースのサポート期限が到来し、アプリケーションの互換性確認、検証環境での動作テスト、本番切り替えを実施しています。契約Aで520,000、契約Bで260,000。契約Bでもゼロにならないのは、ライセンス費用と本番切替の作業が工数枠を超えるためです。それでも差が260,000ついているのは、契約Bでは層5の構成棚卸によって現行構成が文書化されていて、調査工程を圧縮できたからです。

拠点追加に伴うマスタ拡張と権限設計の変更。第2工場の立ち上げに伴い、拠点コードの追加、品目マスタの属性追加、拠点別の参照権限の設計変更が必要になりました。システムは壊れていません。しかしこの改修なしには新拠点の実績を管理できません。契約Aで160,000の追加です。海外拠点への横展開を検討している段階なら、海外拠点へのシステム展開で起きることも参考になります。

時間外・休日の復旧対応（5回）。契約Aは平日日中のみが対象なので、夜勤帯と休日の障害は実費対応になります。5年で5回、合計125,000 THB。金額としては小さく見えますが、この項目の本質は費用ではなく、対応が始まるまでの待ち時間です。次の節の停止時間に反映されます。

仕様書が残っていないための現状調査。これが5年間で最も見えにくい費用です。契約Aは層5をゼロにしたため、5年前の導入時点の仕様書しか存在しません。その間に加えた改修は仕様書に反映されておらず、担当者も日本側・タイ側ともに交代しています。4年目に大きめの改修を検討した際、まず「今どうなっているか」を調べるために300,000 THBかかりました。作った機能ではなく、思い出すための費用です。

大きな機能追加（1件）。契約Bの300,000は、実績入力の仕組みを増やす明確な進化案件で、工数枠を超えるため別途費用としています。契約Aの欄を「契約内扱いにしない」としているのは、契約Aではこの案件が見送られ、費用として計上されなかったためです。安く済んだのではなく、改善そのものが行われていません。これは表に載らない損失です。

契約料と契約外の費用を合計すると、契約Aが3,775,000 THB、契約Bが4,610,000 THB。5年で1,800,000 THBあった契約料の差は、ここで835,000 THBまで縮んでいます。それでもまだ契約Aのほうが安い。逆転はもう一段先です。

止まっている時間を金額に載せると、順位が入れ替わる

最後の要素が停止時間です。システムが止まっている間、出荷指示は出せず、実績も入力できません。紙とホワイトボードで回すにしても、復旧後の追い入力が発生します。

年間18時間と6時間、その差は12時間です。年に12時間と言われるとたいした差に見えませんが、1時間あたり22,000 THBを掛けると年間264,000 THB、5年で1,320,000 THBになります。

差が生まれる理由は3つあります。1つ目は対応開始までの待ち時間です。契約Aは平日日中のみなので、金曜の夜に起きた事象は月曜の朝まで動きません。2つ目は切り分けの速度です。契約Bは層5で構成情報が維持されているため、どこを見ればよいかの当たりが早くつきます。3つ目は予防の有無で、契約Bは層3にパッチ適用や容量監視の実施まで含まれており、そもそも起きる件数が少なくなっています。層1と層2の金額は両案で同じなので、この差も設備ではなく人の関与から生まれています。

5年総額を出します。

順位が入れ替わりました。差額は485,000 THB。契約Aは契約Bより9.2%高いという結果です。年額では44%安かった契約が、5年・停止損失込みでは9.2%高くなる。これがこの記事の中心にある逆転です。

大事なのは、この逆転が「契約Aのベンダーが悪い」から起きたのではない、という点です。契約Aのベンダーは契約どおりの仕事をしています。逆転の原因は、契約設計の段階で層4（変更対応）と層5（知識維持）を費用の外に出し、層3（一次対応）を薄くしたことにあります。層4を外したので帳票の改修420,000 THBと拠点追加160,000 THBが都度見積になり、層5を外したので現状が分からなくなって調査に300,000 THBかかり、層3を薄くしたので時間外の実費125,000 THBと待ち時間が積み上がった。契約外費用の小計は1,525,000 THBに達し、切り分けの遅れで停止時間は3倍になった。

もう一つ付け加えると、初期導入費に対する倍率は予算計画の出発点になりますが、二段に分けて押さえてください。実際に支出として予算化すべきなのは契約料と契約外費用の部分で、これは初期導入費の0.84倍（契約A）から1.02倍（契約B）です。停止損失まで含めた総コストは1.17倍から1.28倍に達しますが、こちらは支出ではなく機会損失なので、予算書ではなく投資判断の側で見る数字です。逆に言えば、年額を初期費用の10.0%に抑えても、5年総額は1.28倍まで膨らみうる。年額の削減幅は、総額の削減幅と一致しません。

SLAが約束しているのは「応答時間」であって「復旧時間」ではない

契約書の中で最も誤読されているのがSLA（サービス品質保証）の時間定義です。ここを正確に読めるかどうかで、停止時間の見積が変わります。

応答時間は、障害の連絡を受け付けてから、一次返答を返すまでの時間です。「受け付けました、調査を開始します」という返信が来た時点で、この時計は止まります。

復旧時間は、サービスが使える状態に戻るまでの時間です。工場が気にしているのは当然こちらですが、多くの保守契約は復旧時間を約束していません。理由は明快で、障害の原因が分からない段階で復旧までの時間を約束できないからです。ハードウェア故障なら部品調達に日数がかかるかもしれず、データ破損なら復元に何時間かかるか分からない。約束できないものを契約に書かないのは、ベンダー側としては正しい判断です。

問題は、買う側が「4時間以内対応」という文言を「4時間で直る」と読んでしまうことです。この文言はほぼ確実に応答時間を指しています。契約更新の場では、次の点を一つずつ確認してください。

• その時間は応答時間か復旧時間か。契約書のどの条文にどう書かれているか
• 復旧時間の目標値（保証ではなく目標でもよい）が設定されているか。設定されていないなら、過去の実績値の中央値と最大値を出せるか
• 障害の重大度を何段階に分け、どの事象がどの段階に当たるかを、具体的な例で定義しているか
• 重大度ごとに応答時間がどう変わるか

そのうえで、タイ拠点では時間そのものの定義を詰める必要があります。

• 「営業時間」とは何時から何時までか。タイ時間か日本時間か
• 祝日はどちらの国のカレンダーに従うか。ソンクラーンのような連休中の扱いはどうなるか
• 時間外の受付経路は何か。電話か、メールか、チャットか。誰が出るのか
• 時間外対応の料金体系はどうなっているか。呼び出し1回あたりか、時間単価か、最低請求時間はあるか
• 受付言語はタイ語・日本語・英語のどれか。複数なら、どの時間帯にどの言語が使えるか

言語の項目を軽く見ないでください。現場で最初に異常に気づくのはタイ人スタッフで、その人が直接ベンダーに連絡できるかどうかで、初動の早さが変わります。日本人管理者を経由しないと連絡できない体制だと、その管理者が会議中なら初動はそこで止まります。時差2時間を挟んで本社の情報システム部門に判断を仰ぐ設計なら、さらに遅れます。

契約書に「日本語対応可」と書いてあっても、それが日本時間の9時から18時だけを意味するなら、タイの午後4時以降は実質的に対応がない、ということになります。この一行を詰めるだけで、年間の停止時間は変わります。

タイ・ASEANで保守契約に固有で効く論点

タイで運用する場合に、日本国内の契約では出てこない論点をまとめます。

電子インボイスの動向。タイのe-Tax Invoice & e-Receiptは、2026年時点で任意です。B2Bの電子インボイス義務化は法制化されていません。ただし優遇措置は続いており、電子インボイスと電子源泉徴収への投資について200%の損金算入、源泉徴収税率1%の優遇が設けられています。2026年6月に閣議が2027年末までの延長を承認しましたが、勅令と省令はまだ発行されていません。また年商30,000,000 THB以下の事業者は、メール方式の簡易版を利用できます。

保守契約の観点で重要なのは「任意である」という事実ではなく、任意であっても対応が必要になる経路があることです。大手取引先が自社の効率化のために電子インボイスでの受け渡しを求めてきた場合、法的義務がなくても対応せざるを得ません。そしてこの改修は、法改正対応ではなく取引先要求対応です。契約書の変更対応の定義が「タイの法令改正に伴う改修」と限定されていると、この改修は契約外になります。定義を「法令改正および主要取引先の要求に伴う改修」まで広げておくかどうかで、数十万THBの差が出ます。

言語とドキュメントの版。仕様書やマニュアルを何語で維持するかを決めていない現場が多くあります。日本語だけで維持すると、タイ人の担当者が読めません。タイ語だけだと本社が読めません。実務的には、画面レイアウトや操作手順はタイ語と日本語、システム構成やインターフェース仕様は英語、という切り分けが機能します。どの文書をどの言語で維持するかを契約に書いておかないと、更新のたびに揉めます。

人の入れ替わり。ジェトロ調査で課題1位が「デジタル人材の不足」（60.7%）だったことは前述しましたが、タイの労働市場では転職が一般的で、システム担当が2年から3年で入れ替わることは珍しくありません。これは自社側だけでなくベンダー側でも起きます。だからこそ層5（知識維持）が効きます。人に紐づいた知識は必ず失われる前提で、文書に落とす費用を毎年払う、という設計です。

駐在員のローテーション。日本人管理者は3年から5年で交代します。契約を結んだ人と、更新を判断する人が別人になる。前任者がなぜその契約にしたのかが引き継がれていないと、更新の場で「高いから安いほうへ」という判断だけが残ります。契約の設計意図を1枚のメモに残しておくことをお勧めします。層ごとに、なぜこの金額を払っているのかを書く。それだけで次の更新の質が変わります。

システム選定そのものの見直し。保守が重すぎる原因が契約ではなく、システムの構成そのものにある場合もあります。過度にカスタマイズされたスクラッチ開発は、変更のたびに影響範囲の調査が必要で、層3と層4が構造的に膨らみます。乗り換えを含めて検討する段階なら、生産管理システムの比較と選定基準で、保守しやすさという軸から候補を見直してみてください。

ベンダーロックインを避ける4点セット

契約を切り替えられない状態は、それ自体が費用です。値上げを受け入れざるを得なくなり、対応品質に不満があっても交渉材料がなくなります。切り替え可能性を保つために契約書へ書いておくべきものは、次の4点です。

設計書。画面仕様、帳票仕様、データベースの物理設計とテーブル定義、他システムとのインターフェース仕様、バッチ処理の一覧と実行順序。これらが導入時点ではなく現時点の状態を反映していることが条件です。改修のたびに更新する義務を契約に書き、年1回は差分がないことを確認します。この作業が層5です。

ソースコードまたは設定情報。スクラッチ開発ならソースコードと、それをビルドして動かすための手順書。パッケージなら、カスタマイズした設定内容、追加した帳票の定義、ワークフローの設定、権限マトリクス。「ソースコードは納品済み」と言われても、5年前のバージョンしか手元にないことがあります。最新版が誰の管理下にあるか、どこに保管されているかまで確認してください。

データのエクスポート形式。全マスタと全トランザクションを、外部で読める形式（CSVやその他の一般的な形式）で出力できること。そして出力データの項目定義書があること。ここで見落とされやすいのが、コード値の意味です。ステータス欄に「3」と入っていても、3が何を意味するかの対応表がなければ、データは移行できません。エクスポート機能があるかどうかではなく、出したデータが自力で解釈できるかどうかで判断します。

引き継ぎの手順と期間。契約終了時に、後任のベンダーまたは自社へ何を引き渡し、どれだけの期間・工数で対応するかを、契約書に条項として書きます。「終了時には協力する」という抽象的な文言では機能しません。引き渡す成果物の一覧、引き継ぎ期間（たとえば契約終了前の30日間）、その期間の対応工数、費用負担の区分まで書いてはじめて実効性が出ます。

この4点が契約書にないと、契約終了時に手元に何も残りません。残らないと、次のベンダーは現状調査から始めることになります。モデルケースで見た300,000 THBの現状調査費は、まさにこの状態で発生した費用です。

4点セットの実務的な確認方法を一つ挙げます。年に1回、「今日ベンダーとの関係が終わったとして、90日で別のベンダーに引き継げるか」を自問してください。引き継げないと感じる要素があれば、それがロックインの実体です。設計書が古いのか、コード値の意味が分からないのか、特定の担当者しか知らない運用があるのか。具体的に特定して、次の契約更新の交渉材料にします。

内製と外注の分界点

すべてを外注すると層3が膨らみ、すべてを内製すると人が抜けた瞬間に止まります。分界点をどこに置くかが設計の要点です。実務的に機能している線引きは、一次受付とマスタ運用は現地で内製、変更対応と基盤更新は外注、というものです。

現地で内製すべきもの。第一に一次受付です。現場から上がってきた事象を受け止め、切り分けの初手を打つ役割です。具体的には、そのエラーが1人だけに起きているのか全員に起きているのか、特定の画面だけか全機能か、直前に何をしたか、ネットワークかアプリケーションか、といった判別です。この工程が社内にあるかないかで、外部に投げる件数が大きく変わります。前述のとおり層3は人の関与の費用なので、投げる件数が減れば直接的に効きます。

第二にマスタ運用です。品目、取引先、単価、作業区、権限。これらの追加・変更は日常的に発生し、外注すると1件ごとに依頼と待ち時間が発生します。マスタの登録ルールを文書化し、社内の担当者が運用するのが原則です。ただし「マスタの構造を変える」作業は別で、これは変更対応の領域です。品目マスタに1件登録するのは内製、品目マスタに属性を1列足すのは外注、という線になります。

第三に日常の運用確認です。バックアップが正常終了しているかの目視確認、ディスク容量の確認、前日のエラーログの確認。作業自体は1日10分程度で、手順書があればタイ人スタッフが実施できます。

外注すべきもの。変更対応と基盤更新です。プログラムの改修、データベースの構造変更、OSやミドルウェアのバージョンアップ、セキュリティパッチの適用判断。これらは頻度が低く、しかし失敗の影響が大きい作業です。頻度が低いということは、内製しても習熟しないということです。年に2回しかやらない作業を社内で抱えるより、日常的にやっている側に任せるほうが速く、安全です。

分界点を機能させる条件が2つあります。1つは、内製側の担当者が1人だけにならないこと。タイでは転職が一般的なので、一次受付ができる人を最低2人育てておく必要があります。もう1つは、内製側と外注側の責任範囲を文書で確定しておくことです。「マスタは社内、構造変更は外部」という線引きは、口頭では必ず曖昧になります。どちらの作業か判断がつかない事象が出たときに、誰が判断するかまで決めておきます。

この分界点を採用すると、契約Bの層3が240,000 THBという水準に収まる理屈も見えてきます。一次切り分けが社内でできていれば、外部に渡る時点で情報が整理されており、ベンダー側の工数が減るからです。内製は費用を社内に移すのではなく、全体の工数を減らします。

契約前に紙で決める10項目

契約更新や乗り換えの交渉に入る前に、次の10項目を紙に書き出してください。すべて、口頭の合意では機能しない項目です。

• 保守の対象範囲を、復旧・維持・変更・進化の4分類で明記する。とくに変更が含まれるか、含まれるなら年間何人日までかを数字で書く
• 対応時間を、タイ時間で何時から何時までか、どちらの国のカレンダーの祝日に従うかまで書く
• SLAの時間が応答時間か復旧時間かを明示し、復旧時間の目標値または過去実績の中央値を書面で受け取る
• 障害の重大度を3段階程度に分け、それぞれに該当する事象の具体例を3つ以上書く
• 受付言語と受付経路を、時間帯ごとに書く。タイ語・日本語・英語のどれが、いつ使えるか
• 時間外・休日対応の料金体系を書く。呼び出し1回あたりか時間単価か、最低請求時間があるか
• 変更対応の工数枠について、未消化分が繰り越されるか失効するか、枠を超えた場合の単価はいくらかを書く
• 設計書・ソースコードまたは設定情報・データエクスポート形式・引き継ぎ手順の4点セットを、成果物として一覧で書く
• 年1回の構成棚卸と仕様書更新を、実施時期と成果物を指定して契約に含める
• 契約終了時の引き継ぎ期間、引き継ぎ工数、費用負担区分を条項として書く

この10項目のうち、既存契約で書けている数を数えてみてください。5つ未満なら、その契約は年額の多寡にかかわらず見直す価値があります。とくに3番目（応答か復旧か）と8番目（4点セット）は、書かれていないことによる損失が最も大きい項目です。

書き出す作業自体にも意味があります。10項目を埋めようとすると、自社側で決まっていないことが必ず出てきます。「重大度の高い障害とは何か」を定義しようとして、出荷が止まる事象と、月次締めが遅れる事象のどちらが重いか社内で議論が起きる。この議論を契約前にやっておくと、実際に障害が起きたときの判断が速くなります。

よくある失敗5パターン

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

年額の比較だけで決める。最も多いパターンです。相見積を並べ、年額が安い順に評価する。層構成が違うものを金額だけで比べているので、層4と層5を外した契約が必ず勝ちます。そして5年後に、この記事のモデルケースと同じ逆転が起きます。対策は、見積を層別に出させることです。「層1から層5の内訳で出してください」と依頼すれば、比較可能な形になります。

サポート終了日を誰も追いかけていない。OSやデータベースのサポート終了日は、何年も前から公開されています。にもかかわらず、期限の3か月前に気づいて緊急対応になるケースが後を絶ちません。緊急対応は工数単価が上がり、検証期間が取れないので切り替えのリスクも上がります。対策は、稼働している全製品のサポート終了日を1枚の表にして、毎年更新することです。追跡の担当を契約でベンダー側に持たせる方法もあります。

仕様書の更新を止める。予算を削る際、真っ先に候補に挙がるのが文書更新の費用です。止めても半年は何も起きません。問題が出るのは、担当者が交代したときと、ベンダーを切り替えようとしたときです。モデルケースでは、この判断が4年目に300,000 THBの現状調査費として返ってきました。削減額の何倍かが後から請求される、と考えたほうが実態に近いです。

一次受付を社内に置かない。現場から上がった事象をそのまま外部に転送する運用です。切り分けがされていないので、ベンダー側は基本的な確認から始めることになり、往復が増えて復旧が遅れます。件数も減らないので層3が膨らみます。対策は前節の分界点のとおりで、一次切り分けができる人を社内に2人以上置くことです。

契約終了時のことを契約書に書かない。関係が良好なうちは誰も終了の話をしません。しかし終了条項がないまま5年が経過し、いざ切り替えを検討すると、手元にデータの意味を説明できる資料がない。結果として切り替えを断念し、条件交渉の余地がないまま契約を続けることになります。これは金額として表に出ないので、最も見えにくい失敗です。契約を結ぶ日に、終わり方を書いておいてください。

よくある質問

業務システムの保守費用の相場はどれくらいですか？

一次統計はありません。参考値として、システム開発の発注支援サイト「システム幹事」（2025年10月10日更新）は、サービス委託費を除いた保守費用の目安を開発費の約5%、大規模システムで約15%としています。またサービス委託費については、日本国内の水準として月額200,000円から500,000円（JPY建て）という値を示しています。ただしこれは事業者側が示す目安であり、統計調査に基づく数値ではありません。本記事のモデルケースでは、初期導入費4,500,000 THBに対して契約Aが10.0%（450,000 THB）、契約Bが18.0%（810,000 THB）という設定にしています。率で比べるより、層1から層5のどこまでが含まれているかで比べてください。

保守契約は何年で見直すべきですか？

契約年数そのものより、見直しの単位を分けることをお勧めします。年額の水準は毎年確認する。層構成（何が含まれ何が含まれないか）は2年から3年ごとに見直す。そして基盤の更新時期、つまりOSやデータベースのサポート終了が近づくタイミングでは、その前年に必ず全体を見直す。この3つのサイクルを分けて回すと、更新のたびに全部を交渉し直す負荷が減ります。また日本人管理者の交代時期に契約更新が重なると判断の質が落ちるので、可能なら時期をずらしてください。

年額を下げたいのですが、どの層から削るべきですか？

削る順番としては、層1（ライセンス）が最も安全です。使っていないライセンスを毎年棚卸すれば、業務に影響なく減らせます。次が層2で、オンプレミスからクラウドへの移行やバックアップ方式の見直しで下がる余地があります。層3を削る場合は、社内に一次受付を置くこととセットで実施してください。件数を減らさずに対応時間だけ狭めると、停止時間に跳ね返ります。層4と層5を削るのは推奨しません。モデルケースで見たとおり、この2層を外した削減額は、契約外費用と停止損失として戻ってきます。

タイの電子インボイス対応は保守契約に含まれますか？

多くの場合、含まれていません。タイのe-Tax Invoice & e-Receiptは2026年時点で任意であり、B2Bの電子インボイス義務化は法制化されていません。したがって「法令改正に伴う改修」という定義では対象外になります。しかし取引先から電子的な受け渡しを求められた場合、法的義務がなくても対応が必要になります。契約の変更対応の定義を「法令改正および主要取引先の要求に伴う改修」まで広げておくかどうかが分かれ目です。なお現行の優遇措置として、電子インボイスと電子源泉徴収への投資に200%の損金算入、源泉徴収税率1%の優遇があり、2026年6月に閣議が2027年末までの延長を承認しています（勅令と省令は未発行）。年商30,000,000 THB以下の事業者はメール方式の簡易版を利用できます。

「4時間以内対応」と書かれていれば4時間で復旧しますか？

しません。この文言はほぼ確実に応答時間、つまり受付から一次返答までの時間を指しています。復旧時間（サービスが使える状態に戻るまでの時間）を保証している契約は多くありません。原因が判明していない段階で復旧時間を約束できないためです。契約更新の場では、その時間が応答時間か復旧時間かを条文で確認し、復旧時間については保証でなくてもよいので目標値、または過去実績の中央値と最大値を書面で受け取ってください。

ベンダーを切り替えたいのですが、何から確認すればよいですか？

手元に何が残っているかの確認から始めてください。現時点の状態を反映した設計書があるか。ソースコードまたはカスタマイズの設定情報が最新版で保管されているか。全データをエクスポートでき、その項目定義とコード値の対応表があるか。そして契約書に引き継ぎの条項があるか。この4点が揃っていれば切り替えは現実的です。揃っていない場合、次のベンダーは現状調査から始めることになり、その費用が発生します。まず現契約のうちに4点を揃える交渉をしてから、切り替えの検討に入るほうが結果的に安く済みます。

社内に情報システム担当がいなくても運用できますか？

専任者がいなくても、一次受付とマスタ運用ができる人が2人いれば回ります。求められるのは開発の知識ではなく、事象を切り分けて正確に伝える能力です。1人だけに任せる体制は避けてください。タイでは転職が一般的で、その1人が抜けた瞬間に運用が止まります。ジェトロ調査でも「デジタル人材の不足」が課題の1位（60.7%）に挙がっており、人材確保は前提条件ではなく、継続的に取り組む課題として設計に織り込むべきものです。

まとめ

この記事の要点を整理します。

保守費用が読めなくなるのは、金額が高いからではなく、契約が「壊れたら直す」しか約束していないからです。工場が実際に必要とするのは「変わったら直す」で、法改正・取引先要求・拠点追加によるマスタ拡張・OSやデータベースのサポート終了が、その中身です。この差は年額には出ず、5年総額と停止時間に出ます。

保守作業は復旧・維持・変更・進化の4種類に分かれます。一般的な年額保守が実際に含んでいるのは、復旧と維持の一部だけ、4種類のうち1.5種類です。費用はライセンス・インフラ・一次対応・変更対応・知識維持の5層で見ます。契約間で差がつくのは層3から層5、つまり人が関わる部分だけです。

モデルケースの試算では、年額450,000 THBの契約Aは年額810,000 THBの契約Bより44%安いにもかかわらず、5年総額（契約料＋契約外費用＋停止損失）では5,755,000 THB対5,270,000 THBとなり、契約Aのほうが9.2%高くなりました。逆転の原因は、契約Aが層4（変更対応）と層5（知識維持）を費用の外に出し、層3（一次対応）を薄くしたことです。層4を外したので変更のたびに都度見積となり、層5を外したので現状が分からなくなって調査費用が発生し、層3を薄くしたので時間外が実費になり、切り分けが遅れて停止時間が3倍になりました。これはあくまでモデルケースの試算であり、金額は構成や業務範囲で変わります。見ていただきたいのは金額ではなく、どの層を外すとどこに跳ね返るか、という構造です。

契約の読み方としては、SLAの時間が応答時間か復旧時間かを必ず確認してください。タイ拠点では、営業時間の定義、どちらの国の祝日に従うか、日本本社との時差2時間、受付言語をタイ語・日本語・英語のどれにするかまで書面に落とします。そして設計書・ソースコードまたは設定情報・データのエクスポート形式・引き継ぎの手順と期間という4点セットを契約書に書いておかないと、契約終了時に手元に何も残りません。

運用体制は、一次受付とマスタ運用を現地で内製し、変更対応と基盤更新を外注する線引きが機能します。内製側は必ず2人以上を確保してください。

保守契約の更新が近づいているなら、まず既存契約を4分類と5層に当てはめて、どこが空欄になっているかを確認するところから始めてください。空欄が層4と層5にあるなら、その契約は年額の安さと引き換えに、5年後の総額と停止時間を担保に入れています。

現在の契約内容が自社の運用に対して妥当かどうか、見てほしいという段階でもかまいません。TOMAS TECHはタイの日系工場向けに生産管理をはじめとする業務システムの導入と保守を手がけており、契約書の層構成の読み解きや、既存ベンダーとの契約を続ける前提での体制整理といったご相談も承っています。乗り換えありきではなく、まず現状を整理したいという段階のご相談も歓迎です。お問い合わせはこちらからどうぞ。

参考情報

• 一般社団法人 日本情報システム・ユーザー協会 — 企業IT動向調査 報告書2026（2026年4月）
• 一般社団法人 日本情報システム・ユーザー協会 — 企業IT動向調査 案内ページ（2025年度調査）
• 日本貿易振興機構（ジェトロ） — 2025年度 海外進出日系企業実態調査（アジア・オセアニア編）（2025年度調査）
• 日本貿易振興機構（ジェトロ） — 同調査 記者発表資料（2025年度調査）
• VATupdate — タイのe-Invoicing最新動向（2026年7月）
• システム幹事 — システム開発の保守費用相場（2025年10月更新）