「作る人」から「確かめる人」へ——AIが先に変えたのは、仕事量ではなく技能の中身

「作る人」から「確かめる人」へ——AIが先に変えたのは、仕事量ではなく技能の中身

外注先から「AIを使うので単価を下げられます」と言われた。実際に下がった。ところが数か月経つと、社内の誰かがこう言い始めます。「安くはなったんですが、チェックにかかる時間が増えていませんか」。

この違和感は、コストの計算ミスとして処理されがちです。単価は下がったが検収工数が増えたので、差し引きでは変わらない、という話に落ち着く。しかし、もう少し別の見方もできます。減ったのは作業量ではなく、作業の種類が入れ替わっただけかもしれないという見方です。

この記事では、arXivに投稿された「From Producing to Validating: How AI Is Deskilling Freelancers」という論文の主張をもとに、AIが変えたのが仕事量ではなく技能の中身だとしたら何が起きるのかを考えます。

出典はarXiv:2608.26089（Nakul Rajpal 単著、2026年8月26日投稿）です。

先に断っておきます。この論文は実験や調査の報告ではありません。 アブストラクトは「既存の実証研究をレビューし、そのうえで予測し、論じる」という構成であり、著者自身が新たに集めたデータを示すものではありません。この記事でも、数字の裏づけがある発見としてではなく、考える枠組みを与える主張として扱います。

30秒で要点

• 論文は、生成AIが知識労働を向上させるものとして喧伝される一方、その恩恵と不利益は労働力全体に不均等に配分されていると指摘している
• フリーランス・ギグワーカーは、正社員に用意されているような技能向上の経路を欠いていることが多く、AI導入が進むにつれて技能開発と雇用の安定の両面でリスクが高まるとされる
• 論文は、機械翻訳のポストエディットとソフトウェア開発を、同じ変化の2つの現れとして参照している
• 論文は、フリーランスがこの変化の先端にいるが、変化は給与所得の実務者にも及ぶと主張し、プラットフォームとクライアントへの問いを提示して締めくくっている
• ただしこれは実証研究ではなく、レビューにもとづく予測と主張である

恩恵は、全員に同じようには配られていない

論文の出発点はここにあります。「生成AIは知識労働を向上させるものとして喧伝されているが、その恩恵と不利益は労働力全体に不均等に配分されている」。

不均等、という言い方が重要です。AIの影響を論じるとき、私たちはつい「AIは仕事を奪うのか、助けるのか」という一本の軸で考えます。しかしこの論文が置いているのは、同じ技術が、立場によって別の作用をするという前提です。誰にとっての話なのかを固定しないと、議論が噛み合いません。

そのうえで論文が名指しするのが、フリーランスとギグワーカーです。理由は、彼らが「正社員に用意されているような技能向上の経路を欠いていることが多い」からだとされています。研修も、OJTも、失敗しても給料が出る期間も、案件単位で働く人には基本的にありません。技能は、案件をこなす過程でしか育たない。 その案件の中身が変われば、育つ技能も変わります。

同じ変化が、2つの職種に別の顔で現れている

論文は、この変化を機械翻訳のポストエディットとソフトウェア開発という2つの事例に結びつけています。「同じ変化の2つの事例（two cases of the same shift）」という書き方です。

翻訳の世界では、この移行は先に起きました。ゼロから訳文を作る仕事から、機械が出した訳文を直す仕事へ。単価は下がり、求められる速度は上がりました。そして、訳文をゼロから組み立てる経験を積む機会そのものが減りました。

ソフトウェア開発でも、似た形が現れつつあります。実装をゼロから書く仕事から、生成されたコードを読んで直す仕事へ。作業の見た目は「レビュー」ですが、レビューが成立するには、そのコードを自分でも書けるだけの理解が要ります。書く機会が減った人が、書けたはずの人と同じ精度でレビューできるかどうかは、自明ではありません。

これが、この論文が deskilling という語を使っている理由です。作業量が減ったのではなく、技能の中身が「生産」から「検証」へ移った。そして検証する技能は、生産の経験を土台にして育つ部分がある。土台のほうが先に細くなると、上に乗っている検証の技能も、いずれ支えを失います。

なぜ「チェックが増えた」を工数の話だと思ってしまうのか

冒頭の「安くはなったがチェックの時間が増えた」という感覚に戻ります。この感覚が工数の問題として処理されやすいのには、理由があります。

ひとつは、チェックの時間は測れるが、チェックの質は測れないからです。何時間かかったかは記録に残ります。一方で、そのチェックがどれだけの誤りを捕まえたか——より正確には、捕まえ損ねた誤りが何件あったかは、記録に残りません。見逃したものは、見逃した時点では存在しないことになっています。

もうひとつは、発注側が受け取るのは成果物であって、過程ではないことです。相手がゼロから作ったのか、生成されたものを直したのかは、納品物を見ても分からないことがあります。分からないまま単価だけが比較されると、過程の違いは価格差として現れず、あとから検収工数として現れます。

そして三つ目に、この変化は誰の意思決定でもないという事情があります。発注側が「AIを使え」と指示したわけでも、受注側が技能を捨てると決めたわけでもありません。個々の合理的な選択——安く早く出す、安く早く受け取る——が積み上がった結果として、技能の構成が動いています。決めた人がいないので、見直す担当者もいません。

確かめる技能は、どこで育つのか

論文が投げかけているのは、この空白です。論文は、フリーランスがこの変化の先端にいるとしつつ、同じ変化が給与所得の実務者にも及ぶと主張し、この仕事を仲介するプラットフォームとクライアント、そして研究者への問いを提示して締めくくっています。

答えを出していない、という点がむしろ重要です。ここには、答えを出しにくい構造があります。

受注側は、育てる余裕を持ちにくい。 案件単位で働く以上、技能を育てる時間は自己負担になります。単価が下がっている状況で、その投資を求めるのは無理があります。

発注側は、育てる責任を持っていない。 外注は、育成のコストを負わない代わりに、必要なときだけ技能を借りる仕組みです。育てないことが、そもそも外注の設計に含まれています。

プラットフォームは、育成を評価する指標を持っていない。 案件のマッチングは、実績と価格で行われます。「この人はゼロから作れる」という情報は、納品物の見た目からは区別されません。

三者のいずれもが、合理的に振る舞った結果として育成が誰の担当でもなくなる。これは、市場の失敗と呼ばれる形に近い構造です。

確かなことと、まだ確かではないこと

確かなこと：論文が、生成AIの恩恵と不利益が労働力全体に不均等に配分されていると指摘していること。フリーランス・ギグワーカーが技能向上の経路を欠くことが多く、技能開発と雇用安定の両面でリスクが高まると論じていること。機械翻訳のポストエディットとソフトウェア開発を同じ変化の2事例として参照していること。フリーランスが先端にいるが変化は給与所得の実務者にも及ぶと主張し、プラットフォームとクライアントへの問いで締めくくっていること。

まだ確かではないこと：この論文は実証研究ではありません。 著者自身が集めたデータ、サンプルサイズ、変化の速度や規模を示す数値は、本記事が確認した範囲には一切ありません。したがって「どれだけの人が」「どの程度」影響を受けているかは、この出典からは言えません。査読や学会採択の記載もないプレプリントです。この記事は、数字ではなく構造の見取り図として扱っています。

それでも、発注する側にできることについて

この構造を前にして、「では外注をやめる」という結論は現実的ではありません。育成の責任を発注側が丸ごと引き受けるのも、契約の形として無理があります。

ただ、ひとつだけ、発注側が自分の判断として決められることがあります。自分たちが何を検収しているのかを、はっきりさせることです。

いま多くの発注で起きているのは、成果物の検収と、技能の検証が混ざったまま処理されている状態です。「納品物が要件を満たしているか」を見ているつもりで、実際には「この人は分かっているのか」を毎回ゼロから確かめ直している。前者は成果物ごとの作業ですが、後者は本来なら関係の中で一度積み上げれば済むものです。混ざっていると、毎回同じ確認を繰り返すことになり、それが「チェックの時間が増えた」という感覚になります。

この記事の立場は、AI利用の可否を決めることより、確認のコストがどこから来ているのかを分けて見ることのほうが先だというものです。技能の空白は、発注側が単独で埋められるものではありません。しかし、自分が何を確認しているのかを知らないままでは、埋めるべき空白の位置すら分かりません。

判断軸の提示

「AIを使ったかどうか」を問わず、「この納品物のどこを、誰が確かめたか」を問うこと。

AI利用の可否を契約条件にするアプローチは、一見すると分かりやすい対処です。しかし、使ったかどうかは申告に依存しますし、開示そのものが信頼を下げるという研究もあります。可否を問うことは、多くの場合うまく機能しません。

代わりに問えるのは、検証の所在です。

1. その納品物で、いちばん間違えたら困る箇所はどこか — 全体を等しく確認するのは不可能なので、先に決める
2. その箇所を、相手は確かめたか — 確かめたなら、どうやって確かめたのかを聞ける形にする
3. こちらは何を確かめる約束になっているか — 決めていないと、全部を毎回見ることになる
4. 同じ確認を、次回も繰り返す必要があるか — あるなら、それは成果物ではなく関係の問題

自分でも試せる、最小の検証

直近の外注案件を1つ選び、検収にかけた時間を「成果物を見ていた時間」と「相手が分かっているかを確かめていた時間」に分けてみてください。

後者が大きいなら、増えているのは検収工数ではなく、関係の中で解決されていない確認です。それは単価交渉では減りません。次の一歩は、いちばん間違えたら困る箇所を1つ決めて、そこだけは相手がどう確かめたのかを納品時に書いてもらう、という取り決めを1件試すことになります。

この記事で扱ったような、外注と内製の線引きを自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。