APIがないシステムの連携CSV・ファイル・画面操作を
選ぶ判断表と受注の例

APIがなくても、既存システムを残して入力の手間を減らせる場合があります。 まず調べるのは、受注を取り込む正式な機能と、登録結果を確かめる手段です。両方が使えるなら、その仕様に合わせた少量の試験から始めます。

取込機能が使えなくても、確認済みの入力表をファイルで渡し、最後の登録を人に任せる方法があります。画面操作の自動化は、提供元と管理者の許可に加え、異常時に止めて登録結果を確認できる場合の候補です。

この記事では、販売管理への受注入力を例に、方式の選び方と二重登録を避けるための記録を説明します。APIは、ソフトウェア同士が決められた方法でデータや機能をやり取りする窓口です。AIには注文文から項目の候補を作る補助を任せ、品番・数量の照合、登録の承認、結果確認とは分けて考えます。

以下の販売管理Sと注文O401は架空の設計例で、連携・AI実行・本番登録を行った事例ではありません。使える機能、権限、費用、保守条件は製品と契約で異なります。

この記事で分かること

• APIの有無だけで入替えを決めず、正式な取込と利用条件を確認します
• 読み取りと登録を分け、承認済みの明細だけを受け渡します
• 元のIDと登録結果を結び、結果不明のまま再実行しません

APIを使わない連携は、
どの順に選びますか？

「データを渡せるか」と「正しく登録されたと確かめられるか」を一組で比べます。 調べる順番は次のとおりです。

1. 正式な取込機能と結果確認が使えるなら、CSVなどの公式取込を試す。 対象列、新規・更新の区別、エラーの扱いを正式仕様で確認します。
2. 取込が使えないなら、承認済みの入力表をファイルやメールで渡し、人が登録する方法を比べる。渡した後に、登録先IDと結果を返す担当まで決めます。
3. 転記の負担がなお大きい場合は、許可された画面操作を検討する。想定外の表示で止まり、登録の成否を確認できない場合は自動再登録しない条件にします。

これは一つだけ選ぶ分類ではありません。「前半はファイルで受渡し、最後は手動登録」のように組み合わせられます。結果を追えない方式しかない場合は、照合手順を整えるまで登録の自動化を進めません。

ファイル受渡しは運ぶ方法、手動登録や画面操作は登録する方法です。メールが届いただけでは登録完了になりません。送る側の「受渡し済み」と、登録先で内容を照合した「登録確認済み」を分けて管理します。

提供元と管理者には、
何を確認しますか？

製品名、利用版、契約プランをそろえ、正式な機能と利用条件を確認します。画面にAPIの設定が見えないだけなら、「APIなし」と決めず未確認として残してください。管理者向けの機能、追加契約や代理店経由の正式な連携があるかも質問できます。

「CSV対応」という答えだけでは、一覧の書出しか、受注の取込かが分かりません。取込でも、新規登録のみか更新もできるか、明細単位か伝票単位かで扱いが変わります。

提供元が認めた方法を候補にし、権限や規約の制約を回避しません。 非公開APIの無断利用、他人のIDの共有、多要素認証の無効化、アクセス制限の回避を前提にしないでください。正式な方法が使えなければ手動を残し、運用の見直しや入替えも含めて判断します。

CSVで受注を渡すと、
登録結果はどう追いますか？

元の注文と登録先の記録を、注文ID・明細IDで対応させます。ここでは、架空の販売管理Sに受注CSV取込、明細ごとの結果一覧、元のIDで登録済みデータを検索する機能があると仮定します。明細ごとの再取込ができる設定であり、実在製品の機能を示すものではありません。

3明細のうち、
承認済み2行だけを渡す

注文O401の明細をL01〜L03とします。同じ商品を頼んだ別注文と混同しないよう、商品名ではなく注文IDと明細IDの組で追います。価格計算や在庫確保はこの例の対象外です。

AIは原文から候補を整理し、不明な品番や単位を質問へ回します。P101などの対応は確認済みの品番表と担当者が確かめ、似た商品を推測で割り当てません。希望日は顧客の希望として残し、納期回答の確約には変えません。

取込候補は次の2行です。これは架空仕様の見本で、そのまま実製品へ取り込めるCSVではありません。列順、文字の扱い、コード、日付、受注日などの必須列は、登録先の正式仕様へ合わせます。「Excelで開けた」「AIがCSVを出した」だけでは取込可能と判断できません。

元注文ID,明細ID,商品コード,数量,単位,希望日
O401,L01,P101,5,巻,2026-11-12
O401,L02,P102,2,箱,2026-11-12

承認担当は「取込2行、保留1行」を確認し、対象の版と確認者を記録します。L03は失敗行ではなく、まだ登録を認めていない明細です。

一部成功なら、成功した
行を再び取り込まない

L01は成功し、L02は単位コードの形式エラーになったとします。登録先の内容も確認して、次のように分けます。

再試験するのは、未登録を確認したL02だけです。 この例では、エラー表示だけでなく登録先でも未登録を確認できた設定です。実製品では結果反映の待ち時間や検索範囲も確認し、検索に出ないだけで未登録と決めません。確認できなければ「結果不明」として止めます。

L02を直した版は担当者が再確認します。L03の不明事項が解消した場合も、以前の承認を流用せず、その明細を新たに承認してください。伝票一括でしか扱えない製品に、この例の行単位の再取込を当てはめず、正式な復旧手順に合わせます。

取込機能がない場合、
どこまで人に残しますか？

正式な取込がなければ、まず「入力表まで用意し、登録と結果返却は担当者が行う」方法を試せます。O401なら、同じ確認済み2行と保留1行の区分を使い、受渡し後を次の手順にします。

1. 承認済み2行の入力表を、許可された保存先へ置く。原文、確認者、対象の版をたどれるようにします。
2. 登録担当を決め、その担当が未処理の行を引き受ける。同じ行を別の人や自動処理が同時登録しないよう、処理中の状態を共有します。
3. 担当者が既存登録を確認してから転記し、販売管理の登録先IDと内容を入力表へ対応付ける。
4. 結果確認を終えた行だけを登録確認済みにする。途中で止まった行は、未登録を確認したのか、結果が分からないのかを残します。

入力表がそろえば資料を探す手間を減らせる可能性がありますが、効果は確認・転記・結果返却まで含めて比べます。画面操作の自動化そのものを完成条件にはしません。

画面操作へ進むなら、
停止と結果確認も含める

RPAなどの画面操作は、決めた操作をソフトウェアで実行する方法です。提供元と管理者の許可、利用するアカウントと端末、認証、人の操作と競合しない実行時間をそろえます。確認ダイアログや項目が想定と違う場合は止め、近い位置のボタンを推測で押し続けない設定にします。

一例として、MicrosoftはPower Automateのデスクトップフローで、単一アクションと処理のまとまりに対するエラー処理や再試行を説明しています。ただし、これは製品機能の説明で、販売管理との互換性や二重登録の防止を保証するものではありません。Microsoftのエラー処理解説

登録ボタンを含む処理には、一律の再試行を設定しません。確定操作後に接続が切れたら、登録できている可能性を残し、次の照合へ回します。

二重登録や途中停止は、
どう扱いますか？

「登録確認済み」「未登録確認済み」「結果不明」を分け、結果不明を再登録待ちに混ぜません。 エラー表示と、登録されていないことの確認は別です。

図：登録直後に止まった場合の判断例。実システムを動かした結果ではありません。

元のID、承認した版、
登録先IDを一つにつなぐ

処理履歴には、元の注文ID・明細ID、原文の保存先、受渡しIDと版、承認者、処理担当と時刻、登録結果と確認した証拠・登録先IDを対応させます。修正前の記録を消して「成功」に上書きせず、どの版を何回扱ったかをたどれるようにします。

同じ行の再処理で登録を増やさない性質を「冪等性」と呼びます。ただし、入力表へIDを付けるだけで、登録先の二重登録を防げるわけではありません。 AWSの設計解説でも、要求を識別するIDに加え、IDの記録とデータ変更を一体で扱う重要性が説明されています。AWSの冪等な再試行の解説

APIのないシステムに同じ機能が備わるとは限りません。重複を拒否する機能がなければ、担当の一本化や処理中の管理、登録前後の照合を組み合わせます。それでも結果を確かめられない行は自動で進めず、人が調査する対象にします。

三つの例外で、次の行動を決める

• 確定操作の後で接続が切れた場合： O401-L01を元のIDで検索し、S7001があれば内容を照合して記録します。確認できなければ結果不明のまま止め、担当者へ渡します。
• 取込ファイルが再送された場合： 受渡しIDと版、元の明細IDで履歴を確認します。ファイル名が変わっていても、L01が登録済みなら新規注文として扱いません。同じIDで内容が変わっていれば、修正版として差分を確認します。登録済みの行の修正版は、新規登録や再取込の対象に戻しません。責任者と正式な更新・取消手順、在庫や帳票への影響を確認してから、変更を承認します。承認された変更方法がなければ、修正版を保留に残して担当者へ渡します。
• 画面の項目や確認表示が変わった場合： 操作を止め、処理ID、止まった段階、登録結果の確認状態、対応担当を通知します。変更後は通常登録だけでなく、不足、重複、途中停止、結果確認を試し、担当者の承認後に再開します。

通知に注文全文や顧客の連絡先を丸ごと載せず、権限のある原本へ必要な担当者がたどれる形にします。

CSV列や単位コード、画面、端末、認証の変更を受け取る窓口と、試験・復旧を行う担当、その代理も決めます。バックアップだけでは誤登録の取消を保証できません。取消権限、在庫や帳票への影響、承認手順を正式仕様で確認し、自動操作の逆順で戻せるとは推測しないでください。

少量の試験で、何を
確かめれば広げられますか？

最初は、書出したデータを読み、候補を作るところまでに限定できます。登録権限を与える前に、品番や列の対応を確認するためです。出力できる情報をすべて外部AIへ渡さず、目的に必要な列と利用先の条件を管理責任者が確認します。実データが不要な試験は、架空の注文と品番表で行えます。

登録を試す段階では、本番と区別した許可済みの環境で、業務担当者も結果を確認します。O401なら次の内容を試験記録へ残してください。

• 商品コード、数量、単位、希望日、元のIDが意図した欄へ入る。並び順が変わっても、行番号ではなく元のIDで照合できる。
• 数量5と単位「巻」が、意図せず箱単位へ変わっていない。換算がある場合は、正式仕様に沿って換算前後を照合できる。
• 取込2行に対し、登録確認1行と未登録確認1行を追える。保留1行を取込失敗へ混ぜず、確認待ちとして残せる。
• 同じ対象の再処理、部分成功、確定直後の停止でも、登録済み行を増やさず、結果不明を担当者へ返せる。

承認前の候補と承認済みの版も区別します。ファイル名の「確定」だけを承認の証拠にせず、確認者と対象の版が記録されることを試してください。必要な値や対応を登録先に残せなければ、補助台帳で追えるかも含めて方式を見直します。

この照合ができないまま件数を増やさず、停止、修正、再開までの手順を整えます。業務選定から運用へ進む条件は、AI導入の段階と確認条件で整理しています。

相談には、どの
資料を持参しますか？

製品名と正式な機能資料、機密を含まない入力と期待結果、担当者の確認手順を用意します。未確認の欄は無理に埋めず、提供元へ聞く質問と社内で決める条件に分けて渡せます。IDやパスワードを送る必要はありません。

社内と外部の役割分担は、AI担当の体制を比較する記事も参考になります。外部へ調査や実装を頼んでも、品番の正しさ、承認条件、入力できる情報の許可など、会社で決める判断は残ります。

まるっとAIへ相談する場合も、既存システムを使い続けたい条件と、今分かっている機能から整理します。すべての製品へ接続済み、必ず入替え不要、すべて月額内と約束するものではありません。自社で調べられる場合は、まず上の質問表で正式な取込と結果確認の方法をそろえるところから始めてください。