1. 試したこと：新しい値を選ぶ前に、反映してよいかを分ける
商品案内を二つの表で管理していると、同じ価格が両方で変わったり、価格と案内文が別々に直されたりします。そこで、変更を一つずつ見て「反映する／反映不要／保留」に分け、対象の項目だけを反映できるかを試しました。
正本や責任者を決める考え方は、複数システムの項目別の正本を決める記事を参照してください。元記事で提案にとどめていた競合・途中の変更・重複反映の扱いについて、今回は短い架空台帳で動かした結果を示します。実システムでの連携を確認したものではありません。
メモと台帳の比較、取得一覧の全件性、書類の工程別の再開とは分け、同じ商品の同じ項目の変更だけを対象にしました。商品の名寄せや、変更一覧を漏れなく取得できたかは扱いません。
2. 作り方の要点：正本・前回値・変更の由来をそろえる
架空の商品台帳A・Bと、項目別の正本表
商品1〜商品6の6行を両台帳に用意しました。両方にある項目は「価格」と「案内文」です。価格は試作用の架空の円表示で、hirostaの料金ではありません。
| 項目 | 正本 | 反映する向き | 確認する担当 |
|---|---|---|---|
| 価格 | 台帳A | AからBへ、価格だけ | 商品管理担当 |
| 案内文 | 台帳B | BからAへ、案内文だけ | 案内担当 |
入力時点の値は次のとおりです。差のない案内文はすべて「標準」です。
| 商品 | Aの価格 | Bの価格 | Aの案内文 | Bの案内文 |
|---|---|---|---|---|
| 商品1 | 1,100 | 1,000 | 標準 | 標準 |
| 商品2 | 2,100 | 1,900 | 標準 | 標準 |
| 商品3 | 3,200 | 3,000 | 標準 | 持ち運び用 |
| 商品4 | 4,100 | 4,100 | 標準 | 標準 |
| 商品5 | 5,200 | 5,000 | 標準 | 標準 |
| 商品6 | 6,000 | 6,000 | 現行案内 | 屋内用 |
各変更に持たせた情報
変更IDのA・Bは、今回その変更を受け取った台帳を表します。「反映元ID」は、他方へ反映されても引き継ぐ、最初の変更の番号です。別の変更IDで戻ってきた記録を、新しい業務上の変更と区別するために使います。
| 変更ID | 商品・項目 | 前回の値 → 変更後の値 | 反映元ID | 承認の状態 |
|---|---|---|---|---|
| A01 | 商品1・価格 | 1,000 → 1,100 | A01 | 承認済み |
| A02 | 商品2・価格 | 2,000 → 2,100 | A02 | 承認済み |
| B02 | 商品2・価格 | 2,000 → 1,900 | B02 | 承認済み |
| A03 | 商品3・価格 | 3,000 → 3,200 | A03 | 承認済み |
| B03 | 商品3・案内文 | 標準 → 持ち運び用 | B03 | 承認済み |
| B04 | 商品4・価格 | 4,000 → 4,100 | A04 | 承認済み |
| A05 | 商品5・価格 | 5,000 → 5,200 | A05 | 不明 |
| B06 | 商品6・案内文 | 記録なし → 屋内用 | B06 | 承認済み |
変更日時も架空に設定しました。A側は2026年10月28日9時、B側は同日10時です。B02の方がA02より新しくても、価格の採用理由にはしません。日時は経緯をたどる補足情報として扱いました。
商品4には、反映元A04の「商品4・価格4,100をBへ反映完了」という架空の控えを用意しました。今回届いたB04は、その反映が戻ってきた設定です。前回値の「記録なし」は空欄への変更とは別で、推測で埋めません。
整理する前に固定した想定表
変更の整理前に、次の想定と根拠・確認先を保存しました。整理後にもファイルのSHA-256が一致し、結果に合わせて想定を変更していないことを確認しました。正解を同じAIが決め、参照できる条件の照合です。
| 場面・変更 | 想定 | 根拠 | 確認先・確認する記録 |
|---|---|---|---|
| 片側だけ：A01 | 反映する | 正本A・承認済み。Bは前回値1,000のまま | 商品管理担当：価格承認票とBの直前値 |
| 同じ項目の両側変更：A02 | 保留 | 正本でも、相手の価格が前回値から変わっている | 商品管理担当・B入力担当：両変更の依頼と承認票 |
| 同じ項目の両側変更：B02 | 保留 | 非正本。日時が新しくても、競合の採用値は未決 | 商品管理担当・B入力担当：両変更の依頼と承認票 |
| 同じ行の別項目：A03 | 反映する | 正本A・承認済み。Bの価格は前回値3,000のまま | 商品管理担当：価格承認票とBの価格 |
| 同じ行の別項目：B03 | 反映する | 正本B・承認済み。Aの案内文は前回値「標準」のまま | 案内担当：案内承認票とAの案内文 |
| 反映済みの再到着：B04 | 反映不要 | 変更IDが違っても、反映元A04の商品・項目・値・反映先に完了控えがある | 連携記録担当：A04の完了控え |
| 承認不明：A05 | 保留 | 正本でも承認を確認できない | 商品管理担当：価格承認票 |
| 比較元なし：B06 | 保留 | 正本・承認済みでも、前回値がなく比較できない | 案内担当・台帳担当：前回の照合控え |
「反映する」はこの試作のコピーを変更する対象、「反映不要」は同じ変更の完了控えがある状態、「保留」は現在値を残して確認へ戻す状態です。実務での反映許可を意味しません。確認先も架空の役割で、人に問い合わせた結果ではありません。
最初の形と、修正した指示
初版は、商品ごとに差と「要確認」だけをまとめました。商品3の価格と案内文を別方向へ反映することや、商品4の再到着の根拠を、その6行では表せませんでした。日時による上書きは実行していません。
そこで、素材と想定表を変えず、出力を変更ごとの状態・根拠・確認先へ広げました。
商品・項目・変更IDごとに、反映する／反映不要／保留と、根拠・確認先を残してください。日時だけで採用値を決めず、同じ項目の両側変更は両方保留してください。正本以外から反映せず、承認不明・前回値なしは止めてください。再到着は反映元IDと完了控えをたどり、同じ変更を再反映しないでください。
汎用の生成AIに指示して処理した部分は、作業しているAI自身による初版・修正版の整理と読み合わせです。PythonはAIを呼ばず、整理済みの結果から「反映する」だけを受け取り、反映条件を確認してコピーを変更します。
正本、承認、前回値、相手側の変更、反映済みの履歴、反映元の現在値を確認し、条件が欠ければコードでも保留に戻す形にしました。実行したコードの中心は次の部分です。条件確認を省いた抜粋で、単独では動きません。
output[target][product][field] = change["value"]
history.append({"origin": change["origin"], "product": product,
"field": field, "value": change["value"], "target": target})行全体のコピーをせず、商品と項目を指定して反映します。履歴には変更IDとは別に反映元IDを残します。
3. 結果：3項目を反映し、競合している値を残した
修正版の状態・根拠・確認先は、上の事前想定の8行と対応し、不一致はありませんでした。Pythonの実行後も、反映する3件・反映不要1件・保留4件となりました。同じAIによる照合で、人の評価は未実施です。正答率や実務の精度を示す結果ではありません。
コピーに反映したもの
| 変更 | 反映先と結果 | 対象外の項目 |
|---|---|---|
| A01 | Bの商品1の価格を1,000から1,100へ | 案内文「標準」は保持 |
| A03 | Bの商品3の価格を3,000から3,200へ | Bが管理する案内文「持ち運び用」は保持 |
| B03 | Aの商品3の案内文を「標準」から「持ち運び用」へ | Aが管理する価格3,200は保持 |
商品3では、同じ行に二つの変更があっても、別の項目なのでそれぞれの正本から反映できました。Bの方が新しいという理由で行ごとコピーすると、Aの価格3,200がBの3,000へ戻ります。今回は項目単位なので、その上書きは起きませんでした。
変更せずに残したもの
| 変更 | 状態・残った値 | 理由と確認先 |
|---|---|---|
| A02・B02 | 両方保留。Aは2,100、Bは1,900のまま | 同じ価格が両方で変更。商品管理担当とB入力担当が依頼・承認票から採用値を決める |
| B04 | 反映不要。両台帳とも4,100のまま | 反映元A04の完了控えあり。連携記録担当が同じ商品・項目・値・反映先を確認する |
| A05 | 保留。Aは5,200、Bは5,000のまま | 承認不明。商品管理担当が価格承認票を確認する |
| B06 | 保留。Aは「現行案内」、Bは「屋内用」のまま | 前回値なし。案内担当と台帳担当が前回の照合控えを確認する |
商品4の反映元A04の完了履歴は1件のままで、B04を理由とする反映や新しい完了履歴は追加しませんでした。今回の3反映の履歴だけを加えています。保留は値の差を解消した意味ではなく、差と確認先を残した結果です。
この試作にかかった時間
2026年10月28日、日本時間8時42分16秒の想定表固定後から、素材・初版・修正版・反映コードの作成、コード実行、同じAIの読み合わせ、ハッシュ確認を終えた8時43分1秒まで、経過は45秒でした。事前調査、想定表の準備、記事制作、構文・ビルド・表示確認、人の確認は含みません。人の業務時間や削減時間、AI単体の速度を測った値ではありません。
4. うまくいかなかったことと、直したこと
初版の商品単位の表は、差があることは示せても、何を反映し、誰の何の確認を待つかを引き継げませんでした。変更ごとの三つの状態と、反映元ID・根拠・確認先を残す形へ直しました。初版には意図的に出力を絞る制約を付けており、AIが自然に起こした誤更新を修正した実験ではありません。
修正版でも、商品2の正しい価格、商品5の承認の有無、商品6の前回値は分からないままです。今回の短い記録には、承認不明や前回値なしを明記しています。実務の曖昧な履歴から同じように読み取れるかは試していません。
コードは一度読み込んだコピーを順に変更するだけです。永続的な履歴保存、同時実行、実行中の別担当の編集、通信が途切れた後の再開は未実施です。再到着も、既存の完了控えがある架空の1変更だけを扱った結果です。
5. 実際の業務で使う前に確認すること
- 項目の意味と正本：標準価格と個別の見積価格などを混ぜず、項目ごとの責任者・反映方向を決めます。正本でも競合や未承認なら止める条件を確認します。
- 前回値と実行直前の値：前回の照合記録が同じ商品・項目・時点のものかを確認します。整理後に反映先が変わっていたら保留へ戻し、確認と書き込みの間の編集を防ぐ方法も検討します。
- 重複と実行結果：変更IDだけでなく、反映元ID・商品・項目・値・反映先をたどれる完了記録を用意します。履歴がないだけで未実行とせず、結果が不明なら再反映せずに確認します。
- 保留の引き継ぎ：両側の値、依頼・承認の根拠、確認担当と回答期限を残します。担当者が採用値と理由を決めるまで、自動で正本の値にそろえません。
- 人による評価：利用環境とAIに渡してよい情報を確認し、担当者が原記録から判断した結果と比較します。コピーでの結果を、実システムの安全な連携の保証にはしません。
6. 相談への案内
「新しい方で上書きすると別の変更が消える」「反映済みの変更が戻ってくる」といった状況から、項目と記録の流れを整理できます。AI業務改善ガイドとサービス・料金も参考に、現在の入力先や確認の手順をお聞かせください。