a2の版と信頼
昨日、計画を確認した。今日はもう一度実行する。
ファイルは変わったかもしれない。それが再実行する理由でもある。では、計画が呼び出すコードも変わっていたらどうだろう。
スキル名は同じままかもしれない。説明も変わっていないように見える。けれど、これから実行する処理は、昨日確認した処理とは違うかもしれない。
a2の紹介パッケージにある別の確認が、この状況を扱っている。
名前とともに版を知る
デモの計画は、使用するスキルの識別情報とコードハッシュを持っている。どの実装を前提に計画を用意したかが見える。
同じスキル版を一日目と二日目のデータに再利用する。そのあと、スキルの状態が変わったところで古い計画を実行しようとする、別の確認がある。
パッケージの記録には、次の停止理由がある。
skill_snapshot_changed
完了したステップのリストは空だ。この確認では計画のどのステップも実行せず、モデルも呼び出していない。
注目したいのは、作業の途中で変化に気づくのではなく、始める前に見えることだ。
変わったコードが間違いとは限らない
新しい版は本当に良くなっているかもしれない。バグを直したり、以前扱えなかった場合に対応したりしているかもしれない。
それでも、古い計画の承認を新しいコードへ自動で移したくはない。
以前の確認は、特定の実装に対するものだった。それが変われば、どの動作が保たれているかを見直す必要がある。新版へ移ることも、記録された判断であるべきだ。
以前のEvidrelの文章では、出典の変化から似た問いを考えた。根拠が変わったとき、以前の受け入れをどう扱うか。
a2での具体的な応答の一つが、計画と実行するスキルの間の版のつながりだ。
コードハッシュで分からないこと
期待する版と一致しても、そのコードが正しい証明にはならない。同じ誤ったコードを同じように再実行することもできる。
この確認が答える問いは、もっと狭い。
これから実行する実装は、計画が依拠した実装なのか。
結果が正しいか判断するには、課題のルールと独立した期待出力がまだ必要だ。コードハッシュはそれらの確認を置き換えない。
だからデモの二つの記録には意味がある。期待結果との比較と、版が変わった際の実行拒否だ。一方は出力を、もう一方は実行の前提となる実装を確認する。
再実行するための条件
繰り返す仕事を簡単にするとき、その間の変化を見えなくする危険がある。
計画の版のつながりは、特定の地点でその危険を制限する。「同じ仕事をもう一度」という依頼に、どのコードで行うかという条件を加える。
最初の技術プレビューで大切だと思う動作の一つがこれだ。動く計画とともに、根拠が変われば、なぜ動かないかを説明できる計画。
出典について — 2026年10月18日：0.1.0a1の公開文書と既存のデモ記録に基づく。データは合成、スキルは人が書いたもの。この文章のために新たなデモ、モデル呼び出し、評価は実行していない。
ソースコード · リリースとダウンロード · デモの案内 · HTMLレポートをダウンロード · デモの証拠をダウンロード · GitHub CI
関連: a2 · 同じ仕事、翌日は別のファイル · エージェントはいつ止まるべきか · 結果を使うのをいつやめるべきか · a2の最初の技術プレビュー
つながり
a2の0.1.0a1技術プレビューとリリースパッケージの限定的な証拠を扱う。
二日分のデモから、スキル状態変更後の別の実行拒否確認へ進む。
停止の問いを、計画が期待するスキル版の確認で具体化する。
Evidrelの出典変更とa2の計画の前提コードの変更を、仕組みを区別してつなぐ。