AIエージェントは「検証できる仕事」から広がる——では最後に残るのは何か

最近わたしは、Claude Codeというツールを使っています。

名前だけ見ると「コードを書くためのツール」に見えます。実際、もともとはそういう文脈で語られることが多いツールです。でもわたしの使い方はというと、レッスンログの整理、朝のカレンダー読み上げ、メールの仕分け、教室運営の情報整理……コーディングとはほぼ無関係なことばかりに使っています。

それで、ふと疑問に思いました。

「これって、そもそもコーディングのために作られたものなんだっけ？」

目的ではなく、適性だった

調べたり考えたりしてわかったのは、たぶん「コーディングのために作られた」というより、「コーディングが最初にうまくいった実験場だった」という方が近いということです。

AI、特に今のエージェントと呼ばれる仕組みの根っこにある大規模言語モデル自体は、最初から雑談も要約も翻訳もこなす、わりと何でも屋として作られています。コーディング専用というわけではありません。

ただ、「AIに複数の作業を任せて、試行錯誤させながら仕上げさせる」という、いわゆるエージェント的な使い方が最初に実用化されたのは、たしかにコーディングの領域でした。

なぜかというと、コードには「実行してみれば正解かどうか機械的にわかる」という性質があるからです。テストが通るか、通らないか。コンパイルが通るか、エラーが出るか。人間の感覚を挟まずに、コンピュータ自身が「合っているか間違っているか」を判定できる。

これはAIを開発する側にとって、ものすごくやりやすい条件です。AIが何かをやってみて、結果を見て、間違っていたらやり直す。このループを自動で回せる。だからコーディングは、エージェントAIが最初に鍛えられる場所として選ばれた——目的というより、都合がよかった、という話に近い気がしています。

(ここは私自身の推測も混じった整理なので、「絶対にそうだ」と言い切れるわけではありません。ただ、腑に落ちる説明ではあります。)

じゃあ次はどこに広がるのか

この理屈が正しいなら、次にAIエージェントが広がっていく先も予想がつきます。

「正解が機械的に検証できる領域」です。

たとえば会計。仕訳や集計は、合っているかどうかを規則に照らして機械的にチェックできます。たとえばWebサイトのデザイン確認。表示が崩れていないかは、スクリーンショットを撮って見比べれば判定できます。

こういう「答え合わせができる仕事」は、これからどんどんAIエージェントに任せられるようになっていくはずです。

では、最後まで残るのは何か

逆に考えると面白いのは、「答え合わせができない仕事」です。

生徒に何と声をかけるか。教室にどんな空気を作るか。誰かの話をどう聞くか。これらには「これが唯一の正解」という機械的な判定基準がありません。人によって、状況によって、正しさが変わる。テストで◯×がつけられない。

わたしがずっと大事にしてきた「教室の空気そのものが商品になる」という感覚は、まさにこの答え合わせのできない領域の話です。樫の森コンピューティング教室でやっている見守りサポートも、コードのように「実行して合っているか確認する」ことができません。生徒それぞれの状況に合わせて、伴走し続けるしかない仕事です。

だから、AIがどれだけ「検証できる仕事」を飲み込んでいっても、この手の仕事は最後まで残るだろうと思っています。

これは、AIに置き換えられる不安からくる負け惜しみではなく、むしろ逆です。検証できない仕事にこそ価値が残るのだとしたら、そこに時間をかけてきたことは、これから先も強みになる。そう思える話でした。