ITコスト適正化の実務：無駄なライセンスとインフラ費用の見直し

ITの費用は、気付くと予算を超えていることがよくあります。主な原因は次の3つです。

• 部門ごとの個別契約（野良SaaS）：現場が独自に契約したツールが、全社の管理台帳に載らないまま増えている。
• 必要以上の性能・容量：念のためにと確保したサーバーの性能や容量が、実際の使用量に比べて大きいまま残っている。
• 解約忘れ：PoCが終わった後の検証環境や、用途を確認しないまま残っている契約に、費用がかかり続けている。退職者のアカウントは、データの保持や後任の利用のために残している場合もあるため、残っていること自体を問題にせず、残している目的と期限を確認します。

こうした費用の多くは、契約の追加や停止を誰が判断するかが決まっていないために生まれます。

見直しでは、まず契約と利用の実態を確かめます。誰が管理し、どの業務で使い、請求がどの契約に基づくのかが分からないまま停止や解約を進めると、業務やデータに影響が出るおそれがあります。金額の大きい契約でも、管理者、利用実態、請求の条件を確認するまでは「削減できる額」ではなく「確認が必要な額」として扱います。

最初に、誰が・何に・いくら使っているかを一覧にします。費目を継続して追う段階になったら、データを集約して可視化する基盤の考え方が使えます。

経理部門と協力して、次の3つの手順で棚卸しを行います。

1. 支払いデータの収集：クレジットカードの明細、請求書、販売店経由の契約をすべて洗い出します。
2. 利用者の特定：支出ごとに、利用部門・業務責任者・管理者を突き合わせます。担当が分からないものは止めずに「未確認」とし、仮の確認担当と期限を決めて、支払いの記録、契約者、利用部門、連携先から所有者と用途を調べます。専任のIT部門がない場合は、経理や総務の担当者が仮の確認担当になっても構いません。
3. 金額の単位をそろえる：年額払い、月額払い、従量課金を月額に換算して並べ、金額の大きい順に確認の優先順位を付けます。月額換算は比較のための尺度で、毎月その額が請求されるという意味ではありません。年払いの時期、契約期間、更新日と、解約・数量変更の申出期限は、月額換算とは別の欄に残します。

台帳には、利用部門・業務責任者・管理者、支払先と契約の形態（直接契約か販売店経由か）、契約期間と請求の周期、契約数・割り当て数・実際の利用、更新日と解約・数量変更の申出期限、変更できる時期、扱うデータと連携、移行・重複利用・作業にかかる費用、確認の根拠と未確認の事項、承認者・担当・期限を記録します。パスワードなどの認証情報は台帳に書きません。

次の表は、記入の仕方を示すための例です。実際の企業の診断結果ではありません。

未確認の項目は「安全」「不要」「削減済み」「費用0円」として扱いません。確認の担当と期限を残し、判断が済んだものから次の段階へ進めます。

SaaSの費用は、利用者数と単価だけで決まるとは限りません。料金体系、最低契約数、追加機能（アドオン）、従量課金、契約期間を、契約書や請求で確認したうえで見直しの候補を考えます。

見直しは、①候補の抽出、②利用・データ・契約の確認、③保持・移管と業務への影響の判断、④承認した変更、⑤請求と業務の結果確認、の順で進めます。これは判断の順序で、製品ごとの画面操作の順序ではありません。不正利用の疑いなどで急いでアクセスを止める場合は、社内の事故対応と承認の手順に沿って先に止め、データの削除や契約の変更は後で判断します。

停止、ユーザーの削除、ライセンスの割り当て解除、契約数の削減、サービスの解約は、それぞれ別の操作です。退職者のアカウントが残っていることも、それだけで無駄とは限りません。データを保持する目的や後任の利用を確認してから判断します。製品ごとの管理者・退職者データ・保持と移管の考え方は、Google Workspace・Microsoft 365の運用引継ぎで扱っています。

請求が変わる時期も、操作とは別に確認します（確認日：2026年10月14日）。

• Google Workspace：ユーザーを停止してもデータは削除されず、停止中のユーザーにもアクティブなユーザーと同じ料金がかかると説明されています（Google：ユーザーを一時的に停止する）。年間 / 定期プランでは、ライセンス数を減らせるのは契約の更新時です（Google：お支払いとご請求について）。
• Microsoft 365：ユーザーからライセンスの割り当てを外しても、契約しているライセンスの数は減りません。数を減らせる時期は、請求アカウントの種類や購入・更新の時期によって限られる場合があり、販売店や担当窓口を通じた契約ではその窓口に依頼します（Microsoft：ライセンスを購入または削除する）。

どちらも、契約の種類、購入の経路、更新日によって、請求が変わる時期は異なります。すべての契約ですぐに減額できるわけではないため、契約と請求で確認してから変更の時期を決めます。

AWSやGCPなどのクラウドは使った分だけ課金されるため、使っていない資源や大きすぎる構成が、気付かれないまま費用になり続けます。なお、保守費が下がらない原因が古いシステムの構成そのものにある場合は、削減の方法を考える前に、レガシーシステムの移行方式を検討します。

• サイズの見直し（ライトサイジング）：CPU・メモリの平均使用率だけで決めず、ピーク時、月末や年次の処理、応答・処理の時間、復旧の要件を確認してから、サイズを下げる候補にします。変更後は、業務と性能に影響がないことを確かめます。
• 長期利用の割引：AWSのSavings PlansやReserved Instancesは、1年または3年の利用を約束して割引を受ける仕組みです（AWS：EC2の請求と購入オプション）。Google Cloudの確約利用割引（CUD）も、一定の利用量や支出額を一定期間約束する仕組みで、約束した期間の料金がかかります（Google Cloud：確約利用割引）。今後も安定して使う見込みがあるか、対象と期間、構成を変える予定がないかを確認してから判断します。利用を減らすことと、契約した費用が減ることは別です。
• Spot Instanceの利用：AWSのSpot Instancesは大きな割引がある代わりに、中断される可能性があります（AWS：Spot Instanceの中断）。開発環境かどうかではなく、中断されても再実行できる処理かどうかで判断します。
• 開発環境の停止：夜間・休日に稼働する必要がない開発・検証サーバーは、停止の候補になります。夜間のバッチや連携、再起動の手順、保存しているデータを確認してから決めます。Amazon EC2では、オンデマンドで都度課金される実行分は停止すると課金が止まりますが、EBSボリュームの保管料金などは残ります（AWS：Amazon EC2 よくある質問）。購入済みのSavings PlansやReserved Instancesの費用も、インスタンスを停止しただけではなくなりません。Reserved Instancesは稼働の有無にかかわらず契約期間の料金がかかり（AWS：Reserved Instancesの請求）、Savings Plansも約束した利用額に対して支払います（AWS：Savings Plans よくある質問）。支払いは前払いや月払いなど契約によって異なります。一方で、割引がほかの対象の利用に適用される場合もあるため（AWS：Savings Plansの適用）、停止時間だけで削減額を決めず、契約と請求の全体で確認します。インスタンスストアのデータは停止すると消去されるため、保存の方式と再開の条件も確認します（AWS：EC2インスタンスの停止と開始）。停止で減る費用と残る費用を分け、実際の請求で確かめます。

製品の料金や条件は変わることがあります（確認日：2026年10月14日）。変更の前に、利用中の契約と請求で確認します。

理由を説明しないまま現場に費用の削減だけを求めると、反発を招きやすくなります。必要な業務と品質を保つことを前提に、確認が済んだものから次の順で進めることを、社内で合意しておきます。

1. 不要と確認できたもの（用途のない契約、使われていないID）：保持・移管、連携と業務への影響、契約の条件、変更の承認がそろった候補から実施します。担当と実施日、変更後の確認結果を記録します。
2. ほかのツールで代えられるもの（機能が重なるツール）：移行期間の二重契約の費用を含めて判断し、移行期間を設けて統合します。
3. 手間と時間がかかるもの（システム構成の変更、プランの変更）：費用差の試算と業務への影響を確かめ、中長期の計画で進めます。

削減できた分の一部を、新しいDXへの投資や従業員への還元に回すと先に示しておくと、現場の協力を得やすくなります。

一度整理しても、管理ルールがなければ、確認されないまま契約やアカウントが再び増えることがあります。定期的に見直し、変更の結果を確かめる仕組みを、次のように決めておきます。

• 契約するときの承認：SaaSを契約するときは、情報システム部門またはセキュリティ担当（専任がいない場合は指名した担当者）の承認を受けることにします。
• アカウントの発行と取り消しの仕組み化：入社・退社の手続き（オンボーディング・オフボーディング）と連動させ、IDの付与と取り消しを自動化するか、申請の記録（チケット）で管理します。
• 定期的な見直し：四半期ごとに費用の報告を経営会議に出し、予算と実績の差の原因を確かめます。契約の更新日と、解約・数量変更の申出期限もあわせて確認します。経営会議へ出す報告の項目と、判断を記録する記入例は、月次IT報告の作り方で紹介しています。

前半は見直しの候補を洗い出す項目、後半は変更してよいかを確認し、結果を確かめる項目です。