a2でたどる仕事の道のり

作業机から — 10

仕事はしばしば、短い一文から始まる。「このデータを整えてほしい」。

けれど、その一文にはまだ決めていないことが含まれている。どの項目を残すのか。どの名前を変えるのか。空白を取り除くのか。同じレコードが二つあれば、両方を残すのか。

a2での仕事の道のりを、こうした判断を小さく追跡できる部分に分けることから考えたい。

ここではプロジェクトのサンプルファイルにある単純な変換を取り上げる。実際の利用者データを含まない、二つのレコードの仕事だ。

依頼から明確なルールへ

サンプル入力の各レコードには、コード、名前、使わない項目がある。

{
  "code": "A1",
  "name": "  First item  ",
  "ignored": "discard"
}

求める変換は小さい。codeをidに、nameをlabelにする。名前の前後の空白を取り除き、それ以外の項目は出力しない。

けれどルールはそこで終わらない。すべてのレコードを残し、この例では問題レコードを生成しないことも契約に含まれる。

こうした細部が、「整える」という言葉に残る余地を狭める。どの変更をしてよく、どの変更をしてはいけないかを定める。

最初の重要な部分は、データそのものより先にあるこの契約だ。

入力を受け入れる

課題はモデルに届く前に拒否されることもある。

a2のデータ経路では、ローカル入力が期待した構造である必要がある。JSONの重複キーや無効な数値は受け入れず、入力サイズにも上限がある。

これらの確認で課題の意味を解けるわけではない。もっと基本的な問いに答える。曖昧さなく読めるデータが手元にあるか、という問いだ。

例えば、同じオブジェクトに二度書かれた項目名を黙って受け入れると、変換の前から、どちらの値を使ったかが不明瞭になりうる。

だから入力を受け入れることも仕事の一段階だ。ファイルが存在するだけでは、処理の準備ができたとはいえない。

どの経路で仕事をするのか

a2のすべての課題が同じ経路を通るわけではない。

この変換に対して、契約が完全に一致する検証済みスキルがあれば、data applyで直接実行できる。この経路ではモデルを呼び出さない。

ここでの一致は、二つの仕事が似ていることより厳密だ。変換の種類、保存された契約、契約の版をまとめて確認する。適したスキルがない場合や選択が曖昧な場合は、レポートを残して停止する。自動的にモデルへ切り替えて別の解決を試すことはない。

モデルで解決することと、新しいスキルを学習することは別の経路だ。

この区別によって、仕事がどう実行されたかを理解しやすくなる。既存の部品を再利用したのか、新しい解決を生成したのか、それとも再利用可能なスキル候補を用意したのか。

できたファイルが似ていても、それぞれの経路の根拠と費用は異なる。

出力と向き合う

最初のサンプルレコードに期待する変換は、次のとおりだ。

{
  "id": "A1",
  "label": "First item"
}

二つ目のレコードも同じルールで変換する。完全な出力には、変換したレコードを収めるrowsと、問題を収めるissuesがある。

ここには二つの別々の確認がある。

一つは、出力が期待した構造かどうか。もう一つは、独立に用意した期待結果と一致するかどうかだ。

a2のサンプルファイルでは、期待する答えは別に保持される。課題を解くモデルには参照の答えを渡さない。生成結果に対する確認は、外側から行う。

この例では全レコードを残す必要があるため、比較では重複レコードの数も保つ。整って見える出力が、欠けたレコードを隠してはいけない。

期待結果が与えられなければ、レポートにはスキーマだけの確認であると記される。そのレポートを読むときには、「成功」がどの検証範囲で付けられたかを見る必要がある。

一つの仕事を次の仕事へつなぐ

変換したレコードを、そのあと別のファイルと照合したい場合もある。

これは一つのスキルだけの例より大きな仕事だ。最初のステップの出力を、二番目のステップのどの入力へつなぐのかを明示しなければならない。

a2のdata pipelineは、呼び出す側が用意した逐次計画を実行する。前のステップのrowsやissuesを、指定した入力へ渡せる。この接続で暗黙の項目変換は行わない。

あるステップが失敗すると、それ以降は実行しない。中間結果に問題が含まれるなら、それを次のステップへどう渡すかも明示する必要がある。問題を転送するだけでは、その意味の保持は証明できない。結果には別の確認が必要だ。

モデルに計画案を求めることもできる。けれど提案を生成することと、計画を実行することは別の操作だ。計画案は、目標を正しく解けるという承認ではない。

こうして仕事の道のりに、もう一つの判断点が生まれる。これらの部品は、本当に求めた仕事をする形でつながったのか。

仕事のあとに残る記録

最後に変換済みデータだけがあれば十分だとは思わない。

どのスキルを使ったのか。何を確認したのか。実行は完了したのか、無効な結果を出したのか、それとも制約で止まったのか。

a2のレポートには、実行経路に応じてこれらの問いの跡が残る。直接の再利用では選択したスキルと検証範囲を、多段階の実行では完了したステップと使用したスキルのコードハッシュを記録する。

新しいスキルを学習する場合も、別の検証経路がある。一つの課題で正解を出しても、同じ処理が他の入力で動くことを示したとはいえない。

この二つのレコードの例から導ける結論にも限界がある。明示的な契約と、確認できる期待結果を示すことはできる。そこから実際の仕事での一般的な効率や広い正確性を結論づけることはできない。

a2でたどりたい道のりはこうだ。依頼がルールになり、適した実行経路が選ばれ、出力を確認し、読める記録が残る。

次の仕事が来たとき、以前のファイルに戻って問い直せるように。

ここで何を達成し、どの条件なら再び信頼できるのか。

---

出典について — 2026年10月15日：a2に含まれるサンプル入力と期待結果、および既存のデータ処理、再利用、計画、逐次実行のコードに基づく。二つのレコードの変換はプロジェクトの教材例であり、実際の利用者の仕事ではない。そのあとの照合は、流れを説明する拡張例である。この文章のために新たなモデル呼び出しや評価実行は行っていない。

a2プロジェクト · 前の文章：エージェントはいつ止まるべきか