購買システムと会計・生産管理のつなぎ方——CSVかAPIか、ずれと停止の気づき方

つなぐ前に「何を、どちら向きに、どの単位で」を一枚に書く

購買部門から「会計にも生産管理にも打ち直している。つなげてほしい」と頼まれたとき、最初に決めるのは CSV か API かではない。何のデータを、どのシステムからどのシステムへ、どの単位（1 件ずつか、日ごとにまとめてか、月の締めでまとめてか）で渡すのかである。受発注・会計・在庫のそれぞれが同じ取引のどの段階を受け持つのか、業務の側の線引きは受発注・会計・在庫はどこで線を引くかの記事で整理している。この記事は、その線が決まった後の「つなぎ方」の技術判断を扱う。

情報処理推進機構（IPA）の「情報システム・モデル取引・契約書」のパッケージ・SaaS 活用版は、システム化の範囲を明示する手段として、検討対象のシステムと既存・周辺のシステムとのデータの流れを明確にする「システム間関連図」と、データのやりとりを明確にする「システム間インターフェース定義書」を挙げている^[1]。同じ資料の評価項目には「データ連携があるか」「インターフェース連携があるか」「現行システムとの不整合が発生する可能性は確認したか」が並ぶ^[1]。名前は大げさに見えるが、中身は「どのデータが、どこから、どこへ」を表にしたものでよい。

表の 1 行には、少なくとも次を書く。データの名前（発注、入庫、検収、請求、品目、取引先、単価、在庫数など）、送り元、受け先、向き（片方向か双方向か）、渡す単位、渡す頻度、渡す項目、突き合わせに使うコードである。双方向と書いた行は、両側で同じデータを直せることを意味するので、後で述べるマスタの決め方に立ち返って片方向にできないかを確かめる。

連携の費用は、相手側のシステムで膨らむ

同じ IPA の資料は、既設のシステムとの連携やデータ交換は可能であるとしたうえで、システムの OS や基本構造が異なる場合は膨大な費用がかかることがあり、意図するタイミングで想定する出力が得られるとは限らず、既設システムの大幅な改造が必要となるケースも散見されると書いている^[1]。総務省の通信利用動向調査（常用雇用者 100 人以上の企業が対象）では、クラウドサービスを利用していない企業が挙げた理由のうち「クラウドの導入に伴う既存システムの改修コストが大きい」が 29.6% で、「必要がない」の 46.0% に次いで 2 番目だった^[2]。この割合の分母は、調査対象の企業全体ではなく、クラウドを利用していない企業である。

費用が膨らむのは、多くの場合こちらが入れる新しいシステムではなく、相手側の既存システムである。会計ソフトに取り込みの口があるか、生産管理システムが外部から所要量を受け取れるか、受け取れないなら誰がいくらで改修するのか。IPA の資料は、既存システムとの連携がある場合は、既存システム側の変更を含むのか、最終的にどのベンダが接続部分の責任を負うのかなど、ベンダ間での調整が必要になるとしている^[1]。連携の一覧表の各行に「受け先側の改修の要否と、その担い手」を一列足しておくと、稟議の費用の漏れも防げる。費用の書き方は購買システム導入の稟議で費用と効果をどう説明するかの記事に送る。

ファイル連携（CSV）と API 連携は、何が違うのか

国税庁の電子帳簿保存法一問一答は、会計ソフトが外部のデータを取り込む方式を説明する問いの中で、API 連携を「保存義務者が保有するシステムからインターネット等を経由して、簡単なリクエストを送信し、指定した電子取引データの記録事項を取得するデータ授受の方式」、ファイル連携を「システム間でのデータの送受信をファイルを経由して行う方式」と書いている^[3]。電子帳簿保存法の文脈での説明だが、二つの違いを短く言い表した定義として使える。API 連携は相手のシステムに直接問い合わせる方式、ファイル連携は間にファイルを置く方式である。

どちらが優れているかではなく、何を優先するかで選ぶ。主な違いを並べると次のようになる。

CSV で起きやすい事故

CSV は「誰でも開ける」ことが長所であり、同時に事故の元でもある。表計算ソフトで開いて保存し直すと、先頭が 0 の品番（「00123」など）が数字として扱われて「123」になる、長い数字が指数表記に変わる、日付の書式が変わる、といったことが起きる。文字コードも揃える必要がある。古い会計ソフトや生産管理システムは Shift_JIS のファイルしか受け付けないことがあり、新しいクラウドのサービスは UTF-8 で書き出すことが多い。区切りの記号（カンマかタブか）、項目の中にカンマや改行が入ったときの囲み方、金額の桁区切りの有無も、両側の仕様を一度並べて確かめる。人が開いて保存し直す手順を挟まないことが、いちばん確実な対策である。

API で起きやすい事故

API 連携は自動で回るぶん、止まっても誰も気づかないことが多い。よくあるのは認証の期限切れである。外部サービスの API は、一定期間で失効する鍵（アクセストークン）を使い、更新用の鍵で取り直す仕組みのものが多い。更新が一度失敗すると、それ以降の連携はすべて止まる。ほかに、一定時間あたりの呼び出し回数の上限、相手側の API の版の変更や廃止がある。選定の段階で、版の変更を何か月前に予告するのか、上限はいくつかを確かめておく。

人の手が入る経路を残さない

連携の途中に「受け取ったファイルを人が開いて手直ししてから取り込む」工程があると、システムの記録と相手から受け取った内容がずれる。電子取引で受け取ったデータのコードを付け替えて取り込む場合の扱いは線引きの記事で国税庁の考え方を紹介している。同じ一問一答は、令和 9 年 1 月 1 日以後に施行される規定に関する問いの中で、API 連携等の方式であっても、完全には自動化されておらず手作業による訂正または削除が可能となるものは、その規定に定める方式に該当しないと書いている^[3]。税務上の扱いの細部は顧問税理士に確かめるとしても、設計の方針としては、受け取ったデータを人が手直しする工程を連携の途中に置かず、直す必要があるなら元のデータを残したうえで別の記録として直す形にしておく。

どのシステムのマスタを正にするか

マスタとは、品目・取引先・単価・勘定科目のように、取引のたびに参照される基本の台帳のことをいう。連携で最も揉めるのは取引のデータではなく、このマスタである。同じ品目が生産管理と購買の両方にあり、両方で名前や単価を直せる状態になっていると、どちらが正しいのか誰にも言えなくなる。

原則は一つで、作る・直す場所を一つに決め、他のシステムは受け取るだけにすることである。どこを正にするかは、その項目を最初に決める人がどのシステムを使っているかで決めるのが自然である。たとえば品目そのもの（品番・品名・構成）は設計や生産管理の側で決まることが多く、取引先ごとの購入単価は見積と交渉を受け持つ購買の側で決まり、勘定科目や部門は会計の側で決まる。在庫の数量は、物を数えて受け払いを記録する在庫の側が正になる。受発注・会計・在庫のどこで発生した取引を正にするかという業務の線引きは受発注・会計・在庫の線の記事で扱ったので、ここではマスタに絞った。どの品番を社内の正にするかという番号の選び方は自社品番と相手品番の紐づけの記事に送る。

取引先は特に割れやすい。購買が見る「発注先」と、会計が見る「支払先」が同じ会社とは限らないからである。発注先は工場、支払先は本社や代理店ということがある。この場合は一つのマスタに無理にまとめず、それぞれのシステムで持ったうえで、対応関係を表で持つほうが壊れにくい。突き合わせには必ずコードを使い、社名で突き合わせない。社名は「株式会社」の位置や全角・半角の違いで簡単に一致しなくなる。コードの付け方は取引先コードの付け方の記事が詳しい。

上場会社では、つなぐシステムが増えると統制の範囲も増える

金融庁の内部統制の基準は、IT に係る全般統制は通常、業務を管理するシステムを支える IT 基盤を単位として構築するとしたうえで、購買・販売・流通の業務管理システムがそれぞれ異なる IT 基盤の上で稼働している場合には、IT 基盤ごとに全般統制を構築することが必要になると説明している^[4]。同じ基準は、業務処理統制の例として、例外処理（エラー）の修正と再処理、マスタ・データの維持管理を挙げている^[4]。これは上場会社の財務報告に係る内部統制の枠組みであり、すべての会社に義務として課されるものではない。ただ、会計に数字を渡す連携を作るなら、上場会社でなくても「エラーになったデータを誰がどう直して送り直すか」「マスタを誰が直すか」は決めておく価値がある。

連携の頻度は、業務の締めから逆算する

頻度は高いほど良いわけではない。高くするほど止まったときの影響が早く広がり、監視の手間も増える。決め方は、受け取った側がそのデータを「いつまでに」使うかから逆算することである。

会計への受け渡しは、月の締めに間に合えば足りることが多い。日次で送っておけば締めの前に差異に気づけるので、件数が多い会社では日次にする価値がある。生産管理から購買への所要量（何をいつまでにいくつ手配すべきか）は、生産計画を更新するタイミングに合わせればよく、それより細かくしても発注の判断は変わらない。一方、在庫の数量を見て発注するかどうかを決める運用なら、在庫の受け渡しが遅れるとその間の判断は古い数字で行われる。購買の担当者が発注を判断する時刻より前に、最新の在庫数が届いている必要がある。

IPA の非機能要求グレードは、運用中の監視の間隔を「監視を行わない」「不定期監視（手動監視）」「定期監視（1 日間隔）」「定期監視（数時間間隔）」「リアルタイム監視（分間隔）」「リアルタイム監視（秒間隔）」の 6 段階で示している^[5]。これは監視の間隔の物差しだが、連携の頻度を決めるときにも同じ段階で考えると話が通じやすい。連携を 1 日 1 回にするなら、その結果を確かめる間隔も少なくとも 1 日 1 回にする。連携より確認の間隔が粗いと、止まっていた期間のデータをまとめて直す羽目になる。

ずれは、件数と合計で見つける

連携が「成功」と表示されていても、データが全部届いているとは限らない。相手側で一部の行が弾かれていたり、条件に合わない行が黙って飛ばされていたりすることがある。ずれを見つける最も確実な方法は、送った側と受けた側で件数と合計金額を突き合わせることである。

たとえば会計への受け渡しなら、購買側で「検収済み・未払い」の金額の合計と、会計側の買掛金のうち購買に由来する分の合計を月に一度比べる。在庫の受け渡しなら、品目の件数と数量の合計を比べる。合わなければ差分の一覧を出し、どちらが正しいかをマスタの決め方に従って判断する。発注・検収・請求を突き合わせる業務上の手順は3 点照合の記事で扱っているので、ここではシステム間の突き合わせを「連携の検査」として独立に持つことだけを強調しておく。移行の直後に件数と合計で突き合わせる手順はデータ移行の記事にもあるが、連携では同じことを毎月続ける点が違う。

連携が止まったとき、誰がどう気づくか

非機能要求グレードは、監視で何を見るかの段階として、対象がオンラインかどうかを見る死活監視、ログ等にエラー出力が含まれているかを見るエラー監視、CPU やメモリなどの使用状況を見るリソース監視、応答時間や処理量を見るパフォーマンス監視を定義している^[5]。またシステムとして機能する状態にあるかを判断するシステムレベルの監視の例として、バックアップの監視やジョブの監視を挙げ、エラー監視やリソース監視などを行うことで障害の原因を追いやすくなり、障害を未然に防げるなど、品質を保つための運用コストが下がるとしている^[5]。

クラウドのサービス同士をつなぐ場合、利用者の側でサーバの死活やリソースを見ることはできない。利用者がやるべき監視は、連携の 1 回ごとの結果を見ることである。具体的には次の四つを決めておく。

1. 結果がどこに残るか
連携の 1 回ごとに、開始時刻、成功か失敗か、件数、エラーの内容が記録に残るかを確かめる。残らない仕組みなら、止まったことを後から証明できない。

2. 誰に知らせるか
通知先を担当者個人のメールにすると、休暇や異動で誰も見なくなる。部署の共有の宛先にし、受け持ちを決める。

3. 何を異常とするか
失敗だけでなく、「成功したが 0 件」「最後に成功した時刻が想定より古い」も異常として扱う。認証の期限切れのように、処理が始まらずに止まる場合は失敗の記録すら残らないことがあるため、最後の成功時刻を見るのが確実である。

4. 送り直したときにどうなるか
失敗した分を送り直したとき、成功していた分まで二重に登録されないかを確かめる。同じデータを 2 回送っても 1 件のままになる作りかどうかで、復旧の手順が大きく変わる。金融庁の基準が業務処理統制の例に「例外処理（エラー）の修正と再処理」を挙げているのは、まさにこの部分である^[4]。

選定のときに提供事業者へ聞くこと

連携を前提に購買システムを選ぶなら、機能の一覧とは別に、次の問いへの答えを文書でもらう。

1. 書き出せるデータと取り込めるデータの種類、それぞれの項目の一覧
2. ファイルの文字コードと形式（区切り記号、囲みの扱い、日付と金額の書き方）
3. API の有無、認証の方式、呼び出し回数の上限、版を変えるときの予告の期間
4. 連携が決まった時刻に自動で回るのか、人が画面から実行するのか
5. 連携の 1 回ごとの結果（成功・失敗・件数・エラー内容）が記録に残るか、失敗をどう知らせるか
6. 同じデータを送り直したときの扱い
7. 突き合わせのキーに使えるコード（品番・取引先コード）を持てるか
8. 相手側のシステムに改修が要る場合、その範囲と誰が担うか

要望を選定に使える要件の形に書き直す手順と評価表への落とし方は要件の書き方の記事で扱っている。上の 8 項目は、その非機能要件の「運用」と「連携」の欄に入れればよい。

よくある質問

最初から API でつながないと意味がありませんか

そんなことはない。件数が少ないうちや試行の期間は、CSV を人が書き出して取り込む形で始め、どの項目が実際に要るのかを確かめてから自動化するほうが、作り直しが少ない。ただし、人が開いて手直しする工程は最初から挟まないようにする。

会計へは、発注・検収・請求のどの時点のデータを送ればよいですか

会計で仕入を計上する基準によって変わる。どの基準でどの日付を使うかは、計上時期の考え方として仕入はいつ計上するかの記事で扱っている。連携の設計としては、計上の基準になる時点のデータを、その時点の日付と一緒に渡すことが肝心である。

画面の操作を自動化する仕組みで転記してもよいですか

画面を人の代わりに操作する仕組み（RPA）は、相手のシステムに取り込みの口がない場合の選択肢になる。前出の国税庁の一問一答も RPA を API 連携等の一つとして挙げている^[3]。ただし画面の配置が変わると黙って間違った欄に入れることがあり、失敗の記録も残りにくい。使うなら件数と合計の突き合わせを必ず組み合わせる。

いまのシステムをやめるとき、データを次のシステムに入れられますか

書き出せる形式と範囲は、入れるときではなく選ぶときに確かめておく必要がある。やめる・乗り換えるときに困らないための確認項目はクラウドの購買システムをやめる・乗り換えるときの記事にまとめている。持ち出したデータを次のシステムに入れるときも、この記事の連携の一覧表と突き合わせの手順がそのまま使える。

まとめ

購買システムを会計・生産管理・在庫とつなぐ前に、データ・送り元・受け先・向き・単位・頻度・項目・突き合わせのコードを一覧にし、受け先側の改修の要否と担い手を書き込む。ファイル連携は始めやすく、API 連携は自動で回せるが、どちらも人が途中で手直しする工程を挟まない。マスタは作る・直す場所を一つに決め、他は受け取るだけにし、突き合わせには社名ではなくコードを使う。頻度は受け取った側がいつまでに使うかから逆算し、確認の間隔を連携の頻度より粗くしない。ずれは件数と合計で毎月確かめ、止まったときに備えて、結果の記録・通知先・異常の定義・送り直しの扱いを決めておく。

出典・参考資料

1. 情報システム・モデル取引・契約書（パッケージ、SaaS/ASP活用、保守・運用）〈第二版追補版〉（独立行政法人情報処理推進機構（IPA）／2025 年 4 月 8 日更新）
2. 令和 6 年 通信利用動向調査報告書（企業編）（総務省 情報流通行政局）
3. 電子帳簿保存法一問一答【電子取引関係】（国税庁／令和 7 年 6 月）
4. 財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準（金融庁 企業会計審議会／令和 5 年 4 月 7 日改訂）
5. 非機能要求グレード2018（システム基盤の非機能要求に関する項目一覧）（独立行政法人情報処理推進機構（IPA）／2018 年 4 月）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで