a2の最初の技術プレビュー

リリースノート — 0.1.0a1

翌日、同じ仕事をするとき、以前の解決から何を残せるだろう。

データファイルを扱うと、この問いによく出会う。レコードは変わっても、項目の選択、変換、照合のルールの一部は同じままだ。解決を再利用するには、ルールが明確で、実装を識別でき、新しい結果を確認できる必要がある。

a2の最初の技術プレビュー、バージョン0.1.0a1をGitHubで公開した。ソースコード、インストール用パッケージ、検査できるデモ記録を利用できる。

a2は、ツール利用、共有メモリ、出力検証、再利用可能なスキルを中心とした小さなPythonエージェントのプロジェクトだ。現在はデータ変換に焦点を当てている。レコードを整え、出典を照合し、矛盾を分け、必要な項目を選ぶ。

この版で特に見えるようにしたいのは、仕事がどう行われたかだ。

どの計画が実行されたか。どのスキルを使ったか。どのコード版を選んだか。結果は形式だけを確認したのか、それとも独立に用意した期待結果とも比較したのか。

出力とともに、これらの答えを調べられる。

最初の体験：二つのファイルを照合する

紹介デモでは、CRMとERPから出力されたように用意した二つの顧客リストを扱う。

両システムの顧客コードが同じ顧客を示すと仮定する。けれどリストのレコードは同一ではない。対応がある顧客も、確認が必要な顧客もいる。

デモは二日分の合成データを使う。一日目はCRMの六件中四件が一致し、二件は別に報告される。二日目は七件中五件が一致し、二件が再び確認に回る。

両日とも同じ二つのスキルを使う。一つは項目を変換し、もう一つは顧客コードを完全一致で照合する。独立した期待結果で出力を確認する。

この実行にAPIキーは要らず、モデル呼び出しもない。デモのスキルは人が書いたものだ。

示しているのは、特定のルールで用意した解決を、同じ版のまま新しい入力に再実行することだ。

技術プレビューの範囲

この版を、方法を試すために共有できる出発点と考えている。

デモは実際の顧客データを使わない。CRMやERPに直接接続しない。名前の近似照合や、異なる顧客識別子の自動的な解決も行わない。

モデルからスキルを生成する作業は、別の証拠の流れだ。以前の限定したライブ実行では、四つのスキル群が独立の確認を通った。これで学習スキルの一般的な効率優位が示されたわけではなく、より広い比較が必要だ。

このリリースのコミットに対するGitHub CIは成功した。記録されたソフトウェア検査の結果であり、実利用者との試行や、学習・効率評価の代わりではない。

最初のプレビューのあとに向き合いたいのは、実際の仕事のルールだ。

準備と確認にどれほど手間がかかるか。再実行でもどんな介入が残るか。誤った照合を見つけられるか。ファイルが変わっても同じ解決が適しているか。

具体的な仕事についてこれらを問える段階で、a2を共有している。

---

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

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

関連: a2 · アイデアが動く道具になるまで · エージェントはいつ止まるべきか · 同じ仕事、翌日は別のファイル · 計画はなぜ実行を拒むのか