道具と仕事 — 04
ある仕事を解いた後、同じ種類の別の仕事に出会う。データは変わっても、行う処理の一部は同じままだ。
この類似性に気づくのは簡単である。解決策のどの部分を再利用できるかを定めるのは、もっと難しい。
一度正しい答えが出ただけでは、まだ道具とはいえない。道具になるには、受け入れる入力、生成する出力、利用できる条件を明確にする必要がある。
a2の出発点となる問いは、ここにある。
成功した解決策を、別の課題で検証し、再利用できるスキルに変えられるだろうか。
アイデアを小さな仕事に絞る
この問いは、いくらでも広く設定できる。さまざまな道具を使い、履歴から学び、あらゆる仕事を引き受けるエージェントを考えることもできる。
a2の現在の対象は、もっと狭い。データ変換である。
記録の正規化、二つの情報源のデータの照合、競合の分離、必要なフィールドの選択。小さく見える仕事だが、道具の振る舞いを調べるための具体的な土台となる。
仮定の例を考えよう。二つのファイルが、同じ商品を異なる形式で記録している。一方は商品コード、他方は仕入先コードを使う。空の項目や、一致しない値もある。
「このファイルを結合して」という依頼から始められる。しかし正しい結果を得るには、より明確な規則が必要だ。どの項目で照合するのか。一致しない記録はどうするのか。競合する値はどう示すのか。
こうした問いに答えるにつれて、アイデアは実行可能な仕事になる。
正しく見える出力で十分なのか
最初の解決策は、整ったJSONを出力するかもしれない。項目はそろい、ファイルも読める。
それでも結果は間違っているかもしれない。記録が抜けた、異なる商品を結び付けた、競合する値の一方を黙って選んだ可能性がある。
そのためa2では、出力形式の確認と、課題の結果の検証を分けている。
独立して定められた期待出力があれば、生成結果と比較できる。その根拠がなければ、報告は検査がスキーマのみであることを示す。それを課題の意味的な正しさの検証として提示することはない。
同じ区別は履歴にも及ぶ。不正な出力を、成功した解決策として保存するべきではない。
再利用の出発点は、完了したように見える処理ではなく、特定の条件の下で検証された解決策であるべきだ。
解決策からスキル候補へ
課題を正しく解けたとき、その解決策から実行可能なスキル候補を生成できる。
これは答えを保存することとは異なる。新しい入力に対して同じ処理を行える部品を得ることが目的だ。
a2のデータ学習経路では、候補を永続保存する前に、三つの新しい検証課題で外部から検査する。期待される検証回答は、モデルとの会話には渡さない。
候補が検査を通れば、契約の版、来歴、コードのハッシュ、検証のフィンガープリントとともに保存する。
したがって「このコードは動いた」以上のものを保持する。どの条件で、どの検査を通って利用可能になったかも残す。
ただし、少数の例を通過しても、すべての入力に対する正しさの証明にはならない。保存されたスキルの範囲が、検証例や契約を越えて自動的に広がることはない。
再利用できれば、仕事は良くなるのか
スキルを生成し呼び出せることは、大切な一歩である。しかし仕事への寄与は、別に測定する必要がある。
a2の比較では、同じ課題を五つの条件で扱う。履歴なし、成功した解答例を文脈に追加、人が書いたスキル、学習されたスキル、課題と無関係なスキルである。
学習されたスキルは評価中に固定する。試験の最中に変化する道具を測ることを避けるためだ。
品質に加え、遅延、モデルと道具の呼び出し、スキルが実際に使われたか、観測されたトークン消費を記録する。スキルを作るための費用も分けて扱う。
資料に記録された限定的な実モデル学習では、四つのデータ変換ファミリーで独立した検査を通るスキルが生成された。一方、小規模で未完了の比較からは、効率面の優位性は示されなかった。
この結果は、使える部品を作ることと、その部品が作業全体を改善することが、別々の問いであると示している。
道具が正しい出力を返しても、エージェントが不要に繰り返し呼び出したり、別の部品と誤って組み合わせたりすることがある。そのため、一つの部品の受け入れだけでは、仕事全体の受け入れには足りない。
道具を使うべきでない場所
前の文章では、記録を想起するとき、その有効性を支える関係を評価することを考えた。スキルの再利用でも、似た境界に出会う。
以前は正しく動いたスキルは、新しい課題の規則と適合しているのか。
照合規則が変わったり、別の変換が求められたりする場合、古いスキルを黙って使うと誤った結果になり得る。a2では、このため契約の適合性を明示的に確認する。
既存のスキルで複数段階の計画を組むことも、別の研究開発領域である。ある部品の出力を次の部品の入力にできても、組み合わせの条件と最終結果は、別に検証しなければならない。
対応できない仕事について、計画を作れないと述べることも、この振る舞いに含まれる。動く道具は、できる仕事と現在の範囲外の仕事を区別する必要がある。
動く部品と、完成した道具
a2は、まだ開発アルファ段階にある。
オフラインのデモは、人が書いたスキルの検証と、異なる入力への再利用を示す。モデルの学習を実証する実験として扱うべきではない。
実モデル学習の記録は、別の証拠の系列を作る。ただし、複数の乱数シードによる完全な評価と、実際の利用者データによる検証は、今も必要である。
この段階では、アイデアが道具になる過程を、一つの完成の瞬間として捉えるのは難しい。各段階が次の問いを開く。
解決策は正しいか。そこから作ったスキルは新しい入力でも動くか。どの規則と適合するか。再利用によって仕事全体は改善するか。
a2で具体化しているのは、これらの問いを混同せずに進める作業である。
解決策をもう一度実行できれば、一つの部品が得られる。それをいつ使い、どう検証し、いつ止めるかを定めるにつれて、その部品は道具になる。
出典について — 2026年10月15日： 本文はa2のREADME、アーキテクチャ、評価文書、日付付き開発記録に基づく。商品ファイルの例は仮定である。本稿のために新しいモデル呼び出しや評価実行は行っておらず、資料に記録済みの限定的な結果を伝えている。
つながり
a2のデータ変換、スキル検証、再利用、評価の限界を考察する。
前の文章の記録と根拠の区別を、新しい課題でスキルを使う条件へと広げる。
前の文章の道具と範囲に関する問いを、視覚プロトタイプの共通規則の保持へ広げる。