基幹システムは置き換えない 〜業務オントロジー入門 第4回〜

基幹システムの刷新は、前提ではない

「既存の基幹システムはどうするのか」。業務の型の話を稟議に上げると、必ず聞かれる問いです。答えは「刷新してから」ではありません。順番は逆でよいのです。

データは、今の場所のまま。基幹やCRMのデータを型の側に写すこと（取り込み）はしますが、置き換えはしません。決めるのは「どれが同じか」と「どれが正か」の2つです。

前回までで、受注業務のもの・関係・操作を決めました。今回は、その業務オントロジー（業務の型）を、既にある基幹システムやCRMとどう両立させるかを扱います。稟議への答えでもあります。

この記事は、業務オントロジー入門シリーズ（全7回）の第4回です。シリーズの一覧はこちら。

まずは、最初につまずく所から考えます。

「同じ会社」を同じと決めないと、「顧客」は作れない

CRMの顧客コード「C-0042」と、基幹システムの取引先コード「100042」。これが同じ会社だと決めない限り、型の上に「顧客」は作れません。

別々のシステムの記録を「同じもの」と決める作業を、名寄せと呼びます。

どれくらいの規模になるか、見積もりは簡単な算数でできます（数字は説明のための例です）。

CRMに顧客が1,200社、基幹システムに1,000社。照合して同じ会社と分かったのが800社。それぞれのシステムの中に重複が無ければ、実在する会社は 1,200 ＋ 1,000 − 800 ＝ 1,400社です。

名寄せの方針は、3つあります。

ルールで照合する場合、気をつけることがあります。「AとBは同じ」「BとCは同じ」と判定が連鎖すると、本当は別の会社のAとCまで同じになることがあります。照合には、人が確認する手順を必ず付けます。

名寄せが済んだら、IDに求める条件を確かめます。

IDの条件は、3つ

ものを個別に扱うには、一意で変わらないIDが要ります。条件は3つ覚えておけば足ります。

一意であること。時間が経っても変わらないこと。一度使った値を、別のものに再利用しないこと。

2つ目が、意外と守られていません。

データを取り込むたびに、行番号や乱数でIDを振り直している仕組みがあります。すると、取り込みのたびに「同じ受注」のIDが変わります。

担当者が型の上で付けた営業メモは、前のIDに紐づいたまま。取り込み後の受注からは、メモが消えたように見えます。別の受注にメモが付いてしまうこともあります。

同じ入力からは、必ず同じIDが出る。受注番号と明細番号をつなげて明細のIDにする、というように、元のシステムの値から決まる形にします。

IDが決まれば、ものは作れます。次に決めるのは、項目の値をどこから取るかです。

正本は、システム単位ではなく項目単位で決める

実際の会社では、1つの「受注」の情報が、いくつもの場所に分かれています。

受注金額と納期は基幹システム。取引先とのやり取りはCRM。営業の優先度や社内メモは、型の上で初めて生まれます。

そのとき問題になるのが、「どちらの値が正しいのか」です。

AIエージェントの権限設計でも触れたとおり、私たちは正本（正しい値の置き場所）を、システム単位ではなく項目単位で決めることを勧めています。

この表を、ものの項目ごとに作ります。

表が埋まっていれば、「元のデータが更新されたとき、担当者の編集とどちらを残すか」は自動的に決まります。基幹が正本なら基幹の最新値、型の側が正本なら担当者の編集です。

表で正本を決めても、同じ値を書き換えられる場所が2つ残っていると、どうなるか。

書き込み口が2つある値は、どう設定しても食い違う

納期で考えます（時刻は説明のための例です）。

9:00、担当者が型の上で納期を5月10日に変え、基幹にも書き戻した。

10:00、別の担当者が基幹の画面で直接、納期を5月20日に変えた。

次の取り込みのとき、型の上の納期はどうなるか。

「担当者の編集を優先」なら、5月10日のまま。基幹は5月20日。食い違いに誰も気づきません。

「新しい方を優先」なら、5月20日。この例では正しく動きます。でも、型で変えた納期がまだ基幹に書き戻されていない間に、基幹で備考だけが直されて行の更新日時が新しくなると、型の側の編集が古い値に戻されることがあります。

どちらを選んでも、不十分です。

根本の原因は、同じ値に書き込み口が2つあることです。

同じ連絡先リストのコピーを2人がそれぞれ持ち、別々に書き直している状態を考えてください。後で突き合わせても、どちらの書き直しが正しいのかは、リストを見ただけでは分かりません。

だから、最も効く対策は、設定ではなく構造です。値ごとに、書き込み口を1つに決める。

納期は基幹が正本。変えるときは型の操作を通し、必ず基幹に書き戻す。基幹の画面からの直接編集は、権限と業務手順で止める。

「型が正本だ」と宣言するだけでは、基幹での直接入力が続き、宣言と実態がずれます。元のシステム側の編集権限と業務手順も、同時に変えます。

では、書き戻しはどう作ればよいでしょうか。

書き戻しは正本へ1本、失敗したら操作も失敗にする

操作の効果を正本に反映することを、書き戻しと呼びます。書き戻しには、2つの作り方があります。

正本への書き戻しを、通知の形で作ってはいけません。失敗しても利用者に見えず、型と基幹の食い違いに誰も気づかないからです。

書き戻し先は、正本1つにします。正本から他のシステムへは、正本が配ります。

2つのシステムに同時に書き戻すと、片方だけ失敗したときに、どちらが正しいのか分からない状態が残ります。

それでも、書き戻しには1つ、見落としやすい落とし穴があります。

「在庫を80にする」ではなく「20引き当てる」

ここまでの例は、「納期を5月10日にする」のように、値を決め打ちで上書きする更新でした。

業務の更新の多くは、今の状態を見て次の状態を決めます。在庫を引き当てる。状態を「与信確認中」から「確定」に進める。

このとき、取り込みの遅れが問題になります。古い状態を見て上書きすると、基幹側で先に起きた更新が消えるからです（時刻は説明のための例です）。

9:10の書き戻しが「状態を確定にする」という値の上書きなら、基幹のキャンセルは消え、キャンセルされた受注が確定されてしまいます。

在庫でも同じです。基幹の在庫が100。基幹で直接30出庫して70になった。まだ取り込まれていない型の上で「20引き当て」を実行し、「在庫80」を書き戻すと、30の出庫が消えます。

これは失われた更新と呼ばれる問題で、型の仕組みだけでは防げません。前提条件は型の上の状態で判定されるからです。

対策は、判定を正本の側にさせることです。

原則は1つです。上書き型の更新を、型と基幹の両側から行わない。

構造で防いでも、食い違いは起きます。緊急対応や古い運用で、直接編集は残るからです。

食い違いは、見つけて業務として処理する

起きないことを前提にせず、起きたら必ず気づく仕組みを作ります。

定期的に、基幹の値と、型から最後に書き戻した値を比べます。差があれば、型を経由しない変更があったということです。

見つかった食い違いは、型の上に「不整合」として1件ずつ作り、担当者と期限を割り当てます。「基幹の値を採用する」「型の値に戻す」という操作で解消します。

型は、食い違いを防ぐ道具であると同時に、食い違いを処理する業務の道具にもなります。

照合の仕組みが無いと、食い違いが見つかるのは月次の締めや監査のときです。最初から作っておきます。

ここまで読むと、書き戻しは重い仕事に見えると思います。そのとおりです。だから、順番があります。

読むだけから始め、書き戻す項目を1つずつ増やす

最初は、読むだけで始めます。基幹やCRMから取り込み、型の上で検索し、照合し、候補を出す。書き戻しはしません。

正本と例外処理が決まった項目から、1つずつ書き戻しの対象に加えます。

AIエージェントの権限設計で説明した「記録だけの期間」も、ここで使います。型の操作を通らない書き込みを、止めずに記録だけする期間を置き、既存の運用で何件が引っかかるかを確かめてから止めます。

書き戻しを始める前に、項目ごとに4つの問いを表にしておきます。

この表が埋まらない項目は、まだ書き戻しの対象にしません。

書き戻しは、技術より業務ルールの問題です。

よくある失敗

推進担当が情シスに説明するときの要点

• 業務オントロジー（業務の型）は基幹システムを置き換えない。データは今の場所のまま、型は正本から取り込んで使う
• 「同じ会社」は名寄せで決める。IDは一意・不変・再利用しない。取り込みのたびに変わるIDは使わない
• 正本は項目単位で決める。1つの値に書き込み口を2つ作らない
• 正本への書き戻しは、失敗したら操作も失敗する形にする。通知の形で作らない
• 状態や在庫のような「今の状態に依存する更新」は、値ではなく操作を送るか、基幹の業務機能に判定させる
• 食い違いは照合で見つけ、「不整合」として業務で処理する。読むだけから始め、項目ごとに書き戻しを増やす

「どれが同じか」「どれが正か」を決めれば、既存システムは残せる

業務の型は、もう1つのシステムを増やすことではありません。既にある記録の上に、「同じもの」と「正しい値」の決め事を置くことです。

決め事が置けた項目から、AIに書き込みを任せられるようになります。

次回は、その型の上でAIがどう動くかを扱います。AIに渡す3種類の道具と、見る権限と変える権限の違い、3つの任せ方です。

シリーズの目次

1. なぜ今、業務に「型」が要るのか 〜業務オントロジー入門 第1回〜
2. 業務から「もの」を切り出す 〜業務オントロジー入門 第2回〜
3. 状態遷移図から業務操作を定義する 〜業務オントロジー入門 第3回〜
4. 基幹システムは置き換えない 〜業務オントロジー入門 第4回〜（この記事）
5. AIエージェントは型の上でどう動くか 〜業務オントロジー入門 第5回〜
6. Palantir、Fabric IQ、SAPはどう違う？ 〜業務オントロジー入門 第6回〜
7. 最初の1業務を型にする 〜業務オントロジー入門 第7回〜

関連記事

• AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：項目単位の正本と、記録だけの期間
• AIエージェントは誰の権限で動くのか｜ID・代理実行・社内検索の落とし穴：基幹に書き戻すときの鍵と権限
• AIエージェントの監視と停止：改ざんできない記録と、止める手段

参考資料

• Palantir「Action types • Side effects • Webhooks」（書き戻し用 webhook は他のルールより先に実行され、失敗すれば変更されない。https://www.palantir.com/docs/foundry/action-types/webhooks （2026年11月1日確認））
• Palantir「How user edits are applied」（元データと編集の合流。公式名は「Apply user edits（既定）」「Apply most recent value」。https://www.palantir.com/docs/foundry/object-edits/how-edits-applied/ （2026年11月1日確認））
• SAP Community ブログ「Guidelines for API Journal Entry – Post」（2019年9月6日。基幹の業務機能に判定させる例 （2026年11月1日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事で説明した「読むだけから始め、記録だけの期間を置いてから書き込みを絞る」進め方は、Askhubでも同じです。まず警告で既存の業務への影響を測ってから確定に進められるので、導入した日に業務を止めずに済みます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：外部ツール連携、データベース・ノート

自社の業務をどう型（オントロジー）にするか相談したい方は、お問い合わせからご連絡ください。業務の洗い出しから定義表づくりまで、伴走支援のコンサルタントが一緒に進めます。