グループの基幹システムで、会社ごとのデータが完全に分離される理由

月末決算前の水曜日。名古屋の中堅商社グループで経理部長が、ある顧客の入金を確認しようと帳簿を開くと、見覚えのない名前が表示されました。全く別の商材を扱う大阪の子会社のデータが、なぜか自分のレコードの中に浮かび上がってきたのです。彼女は息を呑みます。これは画面のバグなのか、それとも本社の誰かが何ヶ月も前から子会社の請求書を読んでいて、誰も気づかなかったのか。

こうした光景は、ベンダーが認めるよりもずっと頻繁に起きています。基幹システムが、同じデータベースの中に別の会社のレコードを混ぜてしまうと、被害は単発の漏えいでは済みません。信頼が少しずつ削がれていくのです。子会社は「自社の価格情報が親会社に共有されているのではないか」と疑い始めます。親会社は「子会社の税設定が自社の帳簿を汚しているのではないか」と心配します。そして監査人は「全社でシステムを共有している」と聞くと、会話を終わらせる一つの問いを投げかけます。見てはいけないものを誰も見ていないこと、証明してほしいと。

本稿は、適切に設計された基幹システムがこの問いにどう答えるかを解説します。一つのプラットフォームで複数の会社を動かす、あるいはこれから動かそうとしている経営者、CFO、業務責任者向けです。短い答えはこうです。各社はデータを完全に分離して保持し、ある会社は別の会社のレコードを見ることができず、その分離を支える統制こそが、監査人が見たい統制です。

一つのプラットフォーム、独立した複数の会社

多くのグループが共有するERPに行き着くのには、もっともな理由があります。子会社ごとに会計パッケージを一つ、倉庫ごとに在庫表を一つ、事業部ごとに営業ツールを一つ運用するとなれば、ログインは三つ、マスターデータは三つ、顧客名が六通りに綴られる場所も三つ生まれます。単一の基幹システムが魅力なのは、統合です。勘定科目を定義する場所が一つ、税のルールが一つ、月末決算が期日通りに終わる場所が一つ。

統合に伴う不安は、クラウドよりも古くからあります。全社が同じプラットフォームに乗るなら、ある会社が別の会社のデータに入り込むのを、何が止めるのか。

その答えが、会社ごとのデータ分離です。よく作られたERPでは、プラットフォームは共有でも、レコードは共有されません。登録した各社は、自社専用の分離されたデータ領域を持ちます。請求書、仕入請求書、仕訳、在庫移動、製造オーダー、顧客リード、勤怠実績は、ログインの瞬間にシステムが引き、要求が決して越えられない境界の中に存在します。名古屋の経理部長がログインすると、システムは彼女を一つの会社のデータに解決し、設計上、他社のレコードは一切返しません。

これは「権限付きの共有フォルダ」とは違います。権限は、利用者が礼儀正しく従うルールです。データ分離は、レコードの保管と取得の仕組みそのものに書き込まれた境界であり、A社のレコードがB社のセッションからは単純に到達できないことを意味します。

購入者が確認できるべきこと

グループ向けの基幹システムを評価するとき、少数の具体的な仕組みを指さし、それぞれに明確な回答を聞けるはずです。「セキュリティ」という曖昧な約束では足りません。以下を確認してください。

各社の独立したデータ領域。システムは各社に独自のレコード群を与え、その境界が何でできているかを説明できるべきです。最も強い設計は、フィルター一つに頼る単一の共有データベースではなく、各社のレコードを保管の段階で分離し、フィルターを忘れた検索でも境界を越えられないようにします。

要求の瞬間の解決。データに触れるすべての要求は、ただ一つの会社に紐づき、ログイン、要求元のホスト、またはシステムが検証する明示的な識別子から解決されるべきです。一般ユーザーが「すべてをよこせ」と踏めるような全体参照の抜け道は、存在すべきではありません。

会社に紐づいたログイン。利用者は一つの会社に属します。同じログインが、全社のレコードを開ける合鍵であってはなりません。アクセス権はロールごとに与えられ、そのロールは利用者が属する会社の中で動くべきです。

削除だけでなく停止できること。会社がグループを離れる、あるいはトライアルが終わるとき、正しい対応はレコードを黙って細断することではありません。システムは会社を「停止」状態にでき、その会社のあらゆるログインを入り口で遮断しつつ、監査期間に備えてデータを無傷のまま残せるべきです。

会社ごとの機能と上限の制御。グループが全子会社に同じパッケージを買うことは稀です。システムは機能と上限を会社ごとに制御でき、製造部門がロット追跡と製造オーダーを有効にする一方で、持株会社は会計だけを動かせるようにすべきです。ある会社がユーザー数や容量の上限に達したからといって、別の会社が制限されてはなりません。

ベンダーがこの五つを示せないなら、「共有プラットフォーム」という売り文句は、中身がほとんどないことを大げさに飾っているだけです。

現実感を持たせるシナリオ

東大阪の精密部品メーカー、社員約70名を想像してください。横浜に15名の営業子会社、福岡に10名の倉庫拠点があります。本社はグループを一つの基幹システムに乗せ、月末決算、在庫、税務申告のそれぞれで起きる三つのパニックを終わらせたいと考えています。

CFOには譲れない条件が二つあります。横浜の子会社は、親会社が契約上見てはならない顧客リストを扱っています。かつての株主の離脱契約が、その顧客帳簿を壁で囲んだからです。福岡の倉庫は追跡性のためにロット記録を保管しており、その記録は営業オフィスから絶対に編集されてはなりません。

会社ごとのデータ分離を持つシステムなら、グループは一つのプラットフォーム上に三つの会社領域を登録します。それぞれが独自のレコードを持ちます。横浜の営業チームがログインすると、自社のリード、見積、受注だけが見えます。東大阪の本社がログインすると、自社の請求書と仕入請求書、そして子会社の顧客ファイルを覗き見るのではなく、書き出した結果から作る集計レポートが見えます。福岡の倉庫は、自社の領域の中で在庫移動、移動オーダー、ロット追跡を動かします。

アクセス権はロールごとに与えられるため、東大阪のCFOは自社の管理者ロールを持ちつつ、横浜ではいかなるロールも持ちません。システムは彼女に「子会社の顧客リストを開く」ボタンを一度も提示しません。そのデータが彼女の領域に存在しないからです。月末決算が動くとき、各社は自社の複式簿記の帳簿で自社の決算を行い、グループは全員が読める共有ライブ帳簿ではなく、書き出しと査読を通じて連結します。

数字は事態をより鋭く示します。サイバーセキュリティクラウドの2025年企業セキュリティインシデント調査報告書によると、日本で公表されたセキュリティインシデントは2025年に165件に達し、前年の121件から約1.4倍となりました。IPA（情報処理推進機構）の2024年度中小企業セキュリティ調査（2025年2月公表）では、日本の中小企業のサイバーインシデントの約70%が取引先に影響を及ぼしました。グループがデータを混ぜて運用すれば、一つの侵害は全社の侵害になります。各社がデータを完全に分離すれば、横浜での問題が東大阪での問題になることはありません。

データ分離が日本の重圧点とどう結びつくか

会社ごとのデータ分離は、横にくっつけたセキュリティ機能ではありません。日本企業の日々の業務を可能にする、同じ境界線です。

インボイス制度を例にします。グループの各社は、自社の適格請求書発行者登録番号を登録し、自社の消費税を申告し、自社の売上税と仕入税の勘定を持ちます。レコードを混ぜて運用するグループは、どの請求書にどの番号を載せるべきか推測する羽目になります。会社ごとの分離で運用するグループは、各社の登録番号、税率、売上税と仕入税の勘定を自社の領域に保持するため、請求書も税務申告も、一つの会社の事実だけから作られます。

月末決算を例にします。各社は独自の勘定科目、独自の予算、独自の決算スケジュールを持ちます。承認ワークフローは各社の中で動くため、福岡で承認が必要な仕訳が、横浜の承認待ち一覧に誤って浮上することはありません。決算が終われば、グループは背後の帳簿を統合することなく、会社ごとに予算と実績を比較できます。

在庫と追跡性を例にします。ロット追跡、在庫移動、移動オーダー、出荷は、在庫を所有する会社の中に存在します。ロット番号に依存するリコールは、ある会社の領域からレコードを返し、同じロット番号が無関係の二つの事業に属し得るような会社横断の混在からではありません。スクラップは在庫操作として扱われ、同じ境界の中に留まります。

人を例にします。タイムシート、勤怠、出退勤、休暇申請は、一つの会社のスタッフに属します。横浜の営業担当が福岡の倉庫に対して作業時間を打刻できるべきではなく、システムはそれを「良くない」で済ませず、不可能にすべきです。

現在手作業であることと、その正直さが意味するもの

良いベンダーは、自動化がどこで終わるかを教えます。会社ごとのデータ分離は、ここで説明するシステムで構築され強制されており、それが保護するモジュール（複式簿記、適格請求書の処理、ロット追跡、承認ワークフロー、タイムシートと勤怠、CRM、販売、購買、在庫、経費精算、パートナー向けのB2Bポータル）はすべてその境界の中で動きます。B2Bポータル自体も同じ分離を尊重します。ポータルからログインしたパートナーは、プラットフォーム全体ではなく、所有する会社が公開したレコードにだけ到達します。

構築されていないのは、CFOが次に尋ねる部分です。会社をまたぐ連結会計は自動生成されません。システムは一つのボタンを押して子会社を一つの連結財務諸表に統合することはありません。各社はクリーンで分離された複式簿記の帳簿を保ち、グループは監査を受けたグループが常にそうしてきたように、会社ごとの結果を書き出して査読することで連結を組み立てます。各社の為替レートを維持する多通貨エンジンはありません。今日のデータ設計に通貨の項目が存在しないためです。異なる通貨で事業を行う会社は、帳簿の外でそれを処理します。不変の専用監査ログテーブルもありません。代わりに、承認ワークフローの履歴が誰が何をいつ承認したかを記録し、その記録は同じ会社ごとの境界の中に存在します。

この正直さこそが要点です。最も強いデータ分離の物語は、境界が本物であり、その中の自動化が本物であり、構築済みとロードマップの境界線が日の当たる場所に引かれているものです。魔法の連結ボタンを約束するベンダーは、たいていの場合、レコードがそもそも真に分離されていなかったことを意味します。

よくある質問

グループで共有フォルダをすでに使っており問題なく動いています。なぜデータ分離が必要ですか。

動かなくなるまで問題ない、というだけです。共有フォルダは混在したデータの上に権限を被せたものであり、リンクが転送され、シートが複製され、退職するスタッフがフォルダをダウンロードした瞬間に分離は消滅します。会社ごとのデータ分離は、人がルールを覚えていることに依存せず、境界は利用者が慎重でも不注意でもすべての要求で強制されます。

各社が分離されていると、グループは全体像をどうやって見るのですか。

ライブの共有帳簿ではなく、統制された書き出しと査読を通じてです。各社は自社の帳簿を決算し、グループはスケジュールに従って会社ごとの結果を取り出して人間の判断で連結します。これは内部統制を重んじるグループに対して監査人が期待する姿そのものであり、分離があるからこそ会社ごとの数字が信頼に足るものになります。

子会社が小規模なら、データ分離は関係ないのでは。

小さな会社も漏えいします。中小企業のサイバーインシデントの多くが取引先に影響を及ぼすという調査結果こそが、分離の根拠です。境界の弱い小さな子会社が、親会社の帳簿への入り口になるべきではありません。各社を独自の境界の内側に置くことは、小さい会社も大きい会社も同時に守ります。Kikan System は最大2ユーザーまで無料、クレジットカード不要で、まず1社の境界を自社で確かめられます。

ログインが増えてスタッフの作業が遅くなりませんか。

いいえ。利用者は一つの会社に属し、単一のログインでその中で働きます。通常業務では境界は見えず、境界が見えるようになるのは自分のものではないレコードに手を伸ばそうとしたときだけです。それはまさに境界を見えてほしい瞬間であり、分離は摩擦ではなく安全装置として働きます。

2026年が境界を直す窓である理由

経済産業省が警告した2025年のレガシーシステムの崖は、今や現実のものとして到来し、METIは2025年5月に再びレガシーシステムに関する調査結果を更新しました。日本企業の基幹システムの約60%が21年を超えると見込まれ、近代化の圧力は緩んでいません。新しいフロントエンドを、共有された混在データのバックエンドの上に載せただけで刷新したグループは、まさにその崖が解消するはずだったリスクの上に今も座っています。

きれいに切り抜けるグループは、データ分離を一項目ではなく第一級の要件として扱ったところです。彼らは、各社がデータを完全に分離して保持し、アクセス権がその境界の中でロールごとに与えられ、構築済みの自動化とロードマップの差が率直に示された基幹システムを選びました。それが、監査と取引先の問いかけと次のインシデントの見出しを生き延びる構造です。

重要なポイント

会社ごとのデータ分離は、一つの機能ではありません。ある会社が別の会社のレコードを見られないという構造的な約束であり、保管と要求の層で強制されます。それが、共有プラットフォームをグループが本当に信頼できるものに変えるものです。

自社のグループで分離を確かめる

基幹システムは、一つのプラットフォーム上で各社に完全に分離されたデータ領域を与え、アクセス権をロールごとに与え、適格請求書と消費税を会社ごとに処理し、承認ワークフロー、ロット追跡、複式簿記をその境界の中で動かします。2ユーザーまで無料、カード不要で /#get-started から始めるか、/#pricing でプランを比較してください。グループでリプレースを検討しているなら、最初の打ち合わせに子会社のことも監査の問いもお持ちください。

関連記事

-> 関連：基幹システムとは？クラウドERPの選び方

-> 関連：2025年の崖を前にした基幹システムの刷新