戻る
E-023 / エッセイ

同じ仕事、翌日は別のファイル

二日分の合成CRM/ERPデモから、同じスキルの再利用、コードの完全一致、独立した結果確認を考える。

a2の作業記録

データ処理を再利用できるか理解するには、二つ目のファイルを見る必要がある。

最初のファイルで動く解決は、その細部だけに合わせたものかもしれない。レコードが変わると、何が変わらないかが見えやすくなる。

そのため、a2の紹介デモには別々の二日がある。

場面は小さい。CRMリストのどの顧客コードにERP側の対応があるかを見る。両システムが同じ一意のコードを使うと仮定する。データも会社も架空のものだ。

まずルールから

最初のスキルはCRMの項目を準備する。codeをidに、nameをlabelにする。名前の前後の空白を取り除く。

二つ目は、準備したレコードを顧客コードでERPリストと照合する。対応があるレコードは結果に入り、対応のないCRMレコードはmissing_matchというコードで別に保持する。

ERPにだけあるアカウントは、この課題の一致した顧客リストには入らず、件数を別に報告する。

これは大切な選択だ。「二つのファイルを照合する」のあらゆる意味を実装しているわけではない。指定した向きとルールで比較を実行している。

二日分の記録

リリースパッケージの実行要約には、次の結果がある。

記録一日目二日目
CRMレコード67
一致したレコード45
対応のないCRMレコード22
ERPにだけあるアカウント11
モデル呼び出し00

両日の結果は独立した期待結果と比較された。使ったスキルのコードハッシュも同じだ。

この表を速度や学習の比較としては読まない。同じルールを同じスキル版で二組のデータに実行した、限定的な記録として読む。

小さな細部:0007

デモの顧客コードの一つに0007がある。

数に見えても、ここでは識別子だ。先頭のゼロを保つ。7に変えることは、課題の契約で許されていない変更になる。

照合は完全一致で、大文字と小文字を区別する。名前が似ているから同じ顧客だとは推測しない。空のコードや重複コードは受け入れない。

小さな細部に見えるかもしれない。けれどデータ処理の信頼性は、こういう点で決まることが多い。システムが何を変換するかを知り、何を変換しないかも曖昧にしないことだ。

結果のあとに見る場所

デモは要約画面だけを生成するのではない。計画、一致したレコード、問題リスト、実行記録も調べられる。HTMLレポートが、それらを一緒に読むのを助ける。

インストール後は、次のコマンドでデモを実行できる。

python -m a2.customer_demo --output runs/customer-demo --compact

再実行するときは、新しい出力ディレクトリを選ぶ必要がある。

この例で答えられる問いは狭い。新しいファイルで同じ二つのスキルを使い、別の参照で結果を確認できるか。

実利用では別の問いが加わる。元のシステムは本当に同じ識別子を使うか。ルールは変わっていないか。確認に回したレコードを誰が扱うか。

二つ目のファイルは再利用の始まりだ。仕事の意味が変わっていないかを確かめる責任は、そのあとも続く。


出典について — 2026年10月18日:0.1.0a1の公開文書と既存のデモ記録に基づく。データは合成、スキルは人が書いたもの。この文章のために新たなデモ、モデル呼び出し、評価は実行していない。

ソースコード · リリースとダウンロード · デモの案内 · HTMLレポートをダウンロード · デモの証拠をダウンロード · GitHub CI

関連: a2 · a2の最初の技術プレビュー · a2でたどる仕事の道のり · 計画はなぜ実行を拒むのか

つながり

探究するa2

a2の0.1.0a1技術プレビューとリリースパッケージの限定的な証拠を扱う。

拡張するa2の最初の技術プレビュー

公開案内の再利用の考えを二日分のデモ記録で具体化する。

参照するa2でたどる仕事の道のり

データ処理の道のりを公開された合成CRM/ERP例へつなぐ。

拡張する計画はなぜ実行を拒むのか

二日分のデモから、スキル状態変更後の別の実行拒否確認へ進む。