a2の作業記録
データ処理を再利用できるか理解するには、二つ目のファイルを見る必要がある。
最初のファイルで動く解決は、その細部だけに合わせたものかもしれない。レコードが変わると、何が変わらないかが見えやすくなる。
そのため、a2の紹介デモには別々の二日がある。
場面は小さい。CRMリストのどの顧客コードにERP側の対応があるかを見る。両システムが同じ一意のコードを使うと仮定する。データも会社も架空のものだ。
まずルールから
最初のスキルはCRMの項目を準備する。codeをidに、nameをlabelにする。名前の前後の空白を取り除く。
二つ目は、準備したレコードを顧客コードでERPリストと照合する。対応があるレコードは結果に入り、対応のないCRMレコードはmissing_matchというコードで別に保持する。
ERPにだけあるアカウントは、この課題の一致した顧客リストには入らず、件数を別に報告する。
これは大切な選択だ。「二つのファイルを照合する」のあらゆる意味を実装しているわけではない。指定した向きとルールで比較を実行している。
二日分の記録
リリースパッケージの実行要約には、次の結果がある。
| 記録 | 一日目 | 二日目 |
|---|---|---|
| CRMレコード | 6 | 7 |
| 一致したレコード | 4 | 5 |
| 対応のないCRMレコード | 2 | 2 |
| ERPにだけあるアカウント | 1 | 1 |
| モデル呼び出し | 0 | 0 |
両日の結果は独立した期待結果と比較された。使ったスキルのコードハッシュも同じだ。
この表を速度や学習の比較としては読まない。同じルールを同じスキル版で二組のデータに実行した、限定的な記録として読む。
小さな細部: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の0.1.0a1技術プレビューとリリースパッケージの限定的な証拠を扱う。
公開案内の再利用の考えを二日分のデモ記録で具体化する。
データ処理の道のりを公開された合成CRM/ERP例へつなぐ。
二日分のデモから、スキル状態変更後の別の実行拒否確認へ進む。