AIが実務では役に立たないとか、せいぜいchatGPTみたいなオモチャだなんて考えてはいないだろうか。実のところ、私もそう思っていた。

「AI で仕事が無くなる」という言説を、私はバカにしていた。せいぜいチャットで相談に乗ってくれる、資料をまとめて要約してくれる、自分の代わりに調べ事をしてくれる—その程度の存在だと思っていた。

しかし、この認識は完全な誤りだった。 たった一年のあいだに、すべてがひっくり返ってしまった。

ソフトウェア開発において、人間はプログラムのコードを 1 行も書かなくなった。AI の生成速度が速すぎて、設計・仕様を決めてから実装するという従来の開発フローが一夜にして陳腐化した。プログラムを書いたことのない現場担当者が、AI で業務ツールを作って自分の業務を自動化するようになった。

すべてが、私が「AI はオモチャだ。こんなオモチャに私の仕事が奪えるわけがない」と楽観的に考えていた1年のあいだに起きてしまった。

私はいま、自分のキャリアを恐れている。この瞬間も恐怖で震えている。

しかし一番恐ろしいのは、これらはエンジニア以外のすべての仕事にも、これから起きるということである。

AI エージェントとは何か

「答える AI」から「実行する AI」への移行

AI が質問に答えてくれるものという段階の話は、もうとっくに終わった。推論能力を競う時代も終わった。2024 年後期にはずいぶんとまともな推論ができるようになり、今はもう東大入試で人間が取れない点数を取るところまで来ている。

そうしていま、AIをめぐる競争はAIエージェントの時代に移った。エージェントとは、自分の代わりに何かを実行する代理人を意味する。chatGPT のように「質問に答える / 資料をまとめる / 画像を切り抜く」AI とは目的そのものが違う。出来ることも質的に異なる。恐ろしいのは、その「出来ること」というのが、今まで人間がやってきた、AI には難しいとされてきた実務作業タスクだということだ。

AI エージェントの 2 側面

AI エージェントは 2 つの側面を持つ。

ひとつは作業の代理人としての側面。 もうひとつは ツール開発の No-code プラットフォームとしての側面。

AI が実務に必要なツールを自分で作り、ツール外の操作も含めて自分で実行する、ということだ。

ユーザに代わってコンピュータを操作する「実務遂行者」

誤解を恐れずにいえば、AI はパソコンで行うすべての作業を自分で実行できる。ファイルの読み書き、インターネットへの接続、Web ブラウザの操作。これらの操作を、私たちのパソコンの中で直接実行する。chatGPT でも個別の動作はできた。しかし業務の各工程ひとつひとつを人間が手動でアップロードして指示し、結果だけを受け取る形だった。

AI エージェントは指示された業務に必要な一連の動作を、自律的に遂行する。ゴールだけ示せば、その中間の工程すべてを実施する。

自然言語でアプリが作れる、実質的な「No-code プラットフォーム」

もう一つ、chatGPT との質的な違いがある。自分でアプリ(プログラム)を作れる、という点だ。たとえば1万個のエクセルファイルを一括で置換しないといけなくなったとしよう。人力でやれば気が遠くなる作業だが、chatGPT に頼もうにもファイルアップロード制限でちまちまと分割作業を強いられて、トークン消費もバカにならない。

しかしAIエージェントに頼むと、1分で終わる。 エージェントはまず、数十行のプログラムを自分で作る。次にそれを実行する。1 分で作業が終わり、頼めば結果と検証の報告まで添えてくる。もちろん、これは単純な例だ。しかしすべての業務ツールが、この延長線上にある。

いま私たちが画面越しに向き合っているのは、そういうバケモノだ。

AIの世界に何が起きたのか、どうして変わってしまったのか

2025 年がシンギュラリティの年だったと、後の歴史書には載っているかもしれない。AI エージェントという概念が確立し、推論能力が大幅に向上し、Anthropic によって Skills と呼ばれる画期的な仕組みが提案された年でもあった。すべてが 2025 年に起きて、エンジニアの世界を業界ごと変えた。

Manus が示した「操作する AI」のコンセプト

2025 年 3 月、Manus という AI が発表された。歴史上初めての AI エージェントだ。「ユーザーに代わって、仮想マシンの中で自分でプログラムを書いて実行したり、Web ブラウザを自分で操作する」という前代未聞のコンセプトを、ユーザーが操作できる実際に動くもサービスとして公開した。正直Manusは問題も多く、公開時点ではコンセプトのデモンストレーションと呼ぶべき性質のものだった。それでも AI エージェントという進化の方向性を示した事実は揺るがない。

その方向性が正しかったことは、同年中に Claude が証明した。

Claude Code の実務浸透

AIエージェントという進化の方向性は正しかった。Anthropic はコーディングエージェントというベクトルに全力で突き進み、プログラマに代わって直接コードを書くというきわめて実務的な提案をした。ユーザーの端末に直接入り、プロジェクト全体の構成を認識し、プログラムを読んで書き換える。プログラマに広く受け入れられ、急速に浸透した。エンジニアの中で Claude Code を使ったことがないという人は、もはやごく少数派だろう。

2025 年後半、先進企業では人間が 1 行もコードを書かないのが当たり前になった。Anthropicのチーフエンジニアさえも(2025年の) 12月以降は一行も自分でコード書をいてないと語っている。Anthropic 公式も、 2026年4月のOpus 4.7 リリースに合わせて 「ペアプログラマー相手ではなく、任せられるエンジニアとして AI を扱え」 と明言している。

設計判断・目的だけ定義できれば、プログラムを書くという実作業も、専門知識も、すべて AI が代行する作業になってしまった。

Skills の誕生と OSS 文化の継承

Skills の登場によって Prompt の時代は終わった。 Skills とは、AI に特定の専門知識やルールを、外付けで与える仕組みだ。

現在の AI には 2 つの実務上の問題があり、Skills はそれを一手に解決する。 ひとつは、最新情報・学習データとの相違に弱いという問題だ。プログラムの世界はころころと書き方のルールが変わる。年一回の大きなアップデートで書き方が丸ごと変わることも珍しくない (破壊的変更と呼ぶ)。AI のモデル更新よりもプログラム世界の更新頻度の方が遥かに速多く、AIが古いルールでコードを書く、それでエラーが出る、仕方ないので人間がなおす、ということが日常茶飯事だった。 Skills はコードを書く前に最新情報やパッチノートの履歴を読ませたり、コーディングルールを先に定義して伝えることで、学習データにないけれど、いまほんとうに正しい書き方を理解させ、その通りにコードを書かせることを可能にした。

もうひとつは、AI は学習データの中からしか答え・やるべき動作・評価基準を判断できないという問題。学習データにないことを尋ねたりやらせようとすると、途端にバカになる。「特定の作業や知識に特化した AI を、汎用モデル開発者は提供できない」という構造的な問題として長く残っていた。Skills はこの問題も解決する。各工程での「視点と判断基準」を外付けで付与することで、目的に応じて異なる視点・異なる指標でコードを評価できるようになった。 実のところ AI もコードを書くのは得意だが、検品・改善はそこまで得意ではない。生成と評価を分離する設計思想が、Skills の登場で実務レベルに乗った。

でもその Skills を書くのに専門知識が必要じゃないか、と思うかもしれない。否定はしないが、プログラミングの世界にはオープンソースという文化がある。すぐれたソフトや概念を皆で公開・共有してより良くしていこう、という思想だ。生みの親ともいえるプログラミングの世界から、Skills はオープンソース文化を継承した。 その代表例が everything-claude-code という設定・Skills 集だ。

everything-claude-code は、Anthropic x Forum Ventures ハッカソンの優勝者である Affaan Mustafa 氏が 10 ヶ月以上の実運用を経て公開した、Claude Code 向けの設定集である。膨大な数の設定・Skills が収録されており、ユーザーが呼び出せばそっくりそのまま各 Skills を起動できる。ハッカソン優勝者の、すべての実務プロセス—専門知識の集大成を、誰もがそのまま自分の手元で動かせるということだ。

専門知識というのは別にプログラムに限らない。「言葉で説明し、指示できるすべてのこと」が該当する。SNS などで話題に上がる自動化・AI 導入の話のほとんどは Skills によって達成されている。つまりはAI エージェントとは、マニュアルを与えればどんなことでも自律して完遂してくれる、記憶喪失の天才である。

このように2025年はAIエージェント元年であった。それだけではなく非常に多くの物事が同時に、それも大きく動いた年でもあった。その結果、ソフトウェア開発の現場はすべてが変わってしまった。

プログラミングという技術と知識の労働は駆逐された

エンジニアの仕事の概要

一般向けにざっくりと説明しよう。 大まかにいって、エンジニアの仕事は

  • 要件定義
  • 基礎設計
  • 技術選定
  • コードを設計する・書く
  • テストする
  • 運用する

に分かれる。上から順番に技術選定までが上流と呼ばれる設計と意思決定の領域、残りが「コードを書く」作業の領域だ。一年前までは、AI は「コードを設計する・書く」の相談にしか関わっていなかった。例外で学習者・個人開発・小さなチームでは技術選定の相談にも乗っていた。

いまはもう全てが置き換わっている。誤解を恐れずにいえば、人間の仕事はAIに命令して、それから承認ボタンを押すことだけだ。

ノンプログラマが業務ツールを毎週バキバキ作る時代

私が本気で AI を恐れたのは、取引先の Web 担当兼デザイナーの変化がきっかけだった。I さんという。私よりふた回り年上の中年男性で、さまざまな職を転々としてきた、どのような仕事でもそつなくこなす器用な方だ。HTML とアニメーションを付ける程度の JavaScript が担当領域で、システム関係や高度なプログラムはめっきりだった。だからこそ、エンジニアとしての私の仕事があった。

打ち合わせのたびに AI の動向について意見を交換し、その度に「まだまだ実用的じゃないし、俺らの仕事はなくならないよね」という意見で一致していた。

しかし 2025 年後期から状況は一転した。「AI はバカだ。AI が言うことを聞かない。」画面に向かってそんな悪態をつきながら、I さんは社内業務用のツールをたくさん作り始めた。プログラムとしての出来はひどい。メンテナンスもできる作りではないし、機能の拡張や修正も設計上難しい。バグも多いしよく止まる。俗にいうバイブコーディングである。

しかし、動く。役割を果たす。 彼はそういう業務ツールを次々と作り出すようになった。ほとんどは彼の業務を自動化するためのものだったが、一部は「自分も使いたいから」ということで社内のマネージャークラスにも使われるようになった。

開発速度は、エンジニアだけやってきた私よりずっと早い。自分が手で書いても、彼の 1/10 の速度しか出ない。

AIはプログラマを殺す。

私はこの時、ようやく現実を認識した。技術を磨いてきた・能力があるということの価値が、たった1年のあいだに失われてしまった。

私が、 AI をオモチャだとバカにしていた間に。

プログラミング知識という「特権」は、No-code レベルまで落ちた

プログラムを書く能力というのは専門的な技術職ではあるが、職人芸には絶対になり得ないという特殊な技能だ。高度な知識やたゆまぬ勉強に加え、様々なケースの実務経験を重ね、いつまでも最新情報にキャッチアップし続けなくてはならない、その割に最終結果は誰がやっても同じになる。たとえるなら高校までの数学のようなもので、答えは決まっており、計算過程はどうあれ答えだけ合っていればマルになる。プロとしてやっていく上で「計算過程」も重要だが、式の美しさが採点の第一基準になることは実のところ少ない。

しかしプログラムを書ける人間は希少で、需要も高く、高給取りだった。私がずっとプログラマをやってきたのもそういう理由だ。事実上の有限な解があり、その過程の式の美しさに裁量が与えられている。職業としてのプログラマの、そういう側面を愛していた。

だが、誰がやっても結果が同じになるということは、問題の設定が正しければだれにでも代替可能ということだ。AI エージェントの登場で、いまそれが現実に起きた。答えが存在しているのであれば、正しい問題設定だけ与えれば誰にでも再現できる。そのために専門的な技術や経験はほとんど必要ない。ましてAIは「まるで塾の先生が描き出すような、美しい式と模範解答」だって無限に吸収しているわけだ。

プログラムを書けることは、特別なことではなくなった。

だから 「何を、なぜ、なんのために」と問える人間であることが、エンジニアの定義になった。「プログラムが書ける / ソフトウェアを設計できる」ことは、エンジニアの価値ではなくなった。Iさんのような、Biz 側の人間や現場解像度の高いノンプログラマ実務者のほうが、遥かによいツールを作る始末である。プログラムを書けるという免許は剥奪された。技術の高低を問わず、もはや AI オペレータでしかない。技術だけを磨いてきたスペシャリストは脱落する。AI 基盤技術は例外だが、作れるということにはもう何の価値もない。

エンジニアの定義の変化

プログラムは誰にでも欠けるものになった。だからエンジニアの定義は 「何を、なぜ、なんのために」と問える人間 に変わった。ソフトは作れますよね、じゃあ何を作るべきですか、どんなものを作ればこの業務を自動化出来ますか、問題を解決できますか、そもそも何が問題の根本なんですか、という話である。

皮肉なことに、それを問えるのは技術者ではなく、現場の問題をよく知る実務者・営業やマーケティングなどビジネス側の人間のほうである。AIを使い倒す彼らこそが「エンジニア 」と呼ばれるようになる日が目と鼻の先まで迫っている。

ソフトウェア開発においては、エンジニアの役割は「“指示待ちの天才エンジニア軍団”に指示を与え、上がってきた報告に目を通す仕事」に移行した。これと同じことが、これから他の職種でも起きる。時間の問題でしかない。その時、エンジニアの役割は現場の声を聴き、業務を深く理解し、AI を中心に業務フローを再設計する人になる。問題が明確であれば、AI エージェントがすぐにツールを作る。プログラムで解決できないことは代わりに実行する。だから社内の情シスの仕事は工数を割いてシステムを作ることではなくなり、AI と人間の橋渡し(=interface になること) しか価値が残らない。

これが「エンジニア」の新しい仕事になるだろう。

開発速度は 10 倍、代償は現場の人間が払う

ソフトウェア開発速度は 10 倍になった

ソフトウェア開発の生産性は、文字通り桁が変わった。従来 15.5 人日 かかっていた案件が 1.5 人日(工数 87% 削減)で完了した事例が報告されている。OpenAI 社内では、人間の手では一切コードを書かず Codex に全生成させる実験が継続中で、Symphony 導入後はプルリク件数 (コードの納品兼承認の申請) が 5 倍に増えた。

生産性の代償は現場の人間が支払っている。「残業は減った、納期も守れている、上層部からの評価も悪くない。それなのに、現場の開発者の間に静かな疲労感が漂っている」。便益の分配は経営・PM 層と開発者で非対称で、PM・経営は「とりあえず作ってみて、違ったら直す」を選べる立場に移ったが、開発者は同じ時間でより多くのタスクをこなすことが前提化される。やり直しの回数が増え、上流の不備を下流が吸収する構造が静かに固定化していく。

処理しなければならない仕事の量も、生産性に比例して増えた。実装時間は短く、残業も発生しない、しかし意思決定の回数が増えて、タスクの切り替えと同時進行の頻度が上がり、やり直しによる心理的コストが蓄積する。「忙しくないはずなのに疲れている」という、従来のフレームワークでは説明しにくい状態が常態化する。労務管理の指標(労働時間)と実際の消耗度(認知負荷)の間に、ギャップが広がっていく。

開発フローは AI に破壊された

AI は生成速度が速すぎるので、何かを決めてから作るというフローが成り立たなくなった。作ってから直していく、という順番にしないと、人間が AI の生産性を殺すだけになる。旧来の開発スタイルでは AI を使っても生産性が向上しない。

現場で技術を磨いてきた人ほど、今までの常識と戦わなければならない。知っていれば知っているほど、自分の知識や経験と戦う羽目になる。これまでは人間が実装する前提で組まれていたから、設計から共有事項まで順番に決め、実装は最後にプログラマが分担して作業できる状態にしなければならなかった。

片やAI は決める・考えるよりも「作る(生成する)」方が遥かに得意だ。 旧来の方法では AI の作業を人間が止め続ける状態になってしまう。AI を中心に据えると、大雑把な計画だけして、とにかく作って、作って、作ってから直して全体の整合性を取る、という順番のほうが適している。経験があればあるほど、データベースだとかセキュリティだとか機能要件・非機能要件だとか「最初にしっかり詰めておかないと後でオワること」が頭に昇ってくる。それを一度、すべて捨てなくてはいけない。

つまり、業務フローが根底からひっくり返った。今日までの常識を捨てなければ、AI ネイティブな環境に適応できない。現場で再設計を主導できる人間と、従来手法に固執する人間で、結果は二極化する。

エンジニア以外の領域でも、既に同型の現象が観測される。 Ubie(医療機関向け生成 AI プロダクト) のプロダクトマネージャー 林田氏は「仕事の半分が AI に代替された」からと残り半分の価値を 顧客の現場一次情報 + 業務プロセス再設計に置き換えたと語っている。では現場で何をやっているかというと、診察室で医師と一緒にホワイトボードを眺めながら業務フローを組み直し、医師が下書きを書いて事務がチェックする従来の流れを、事務が AI で叩きを作って医師がレビューする逆転フローへと再設計した。 曰く「ヒアリングして帰るのではなく、現場で一緒に手を動かし、業務プロセスごと組み直すところまで踏み込む」とのことで、まさしくAIネイティブ時代の「エンジニア」の姿そのものではないか。

AI に触れるかどうかでキャリアが二極化する

スキルを磨けば磨くほど自分が貧乏になる時代

AI に触れない選択は、技術を磨き続ける選択を意味する。しかし技術で雇われる仕事は減っていく。時代に取り残された会社・市場でしか仕事を見つけられなくなる。競争力がないので、貧乏になる一方だ。自分が頑張っている間にも、人材の価値・基準値は AI に依っていく。働いて、勉強して、実務経験を積んで、頑張れば頑張るほど、人材価値がなくなっていく という構造が、すでに動き出している。

人材の二極化は、エンジニアの世界で既に観測されている。Findy の 188 社調査では「AI 技術やツールの活用経験の有無」を採用評価に使う企業はまだ 18.1% に留まる一方で、Karat の 2026 年レポートは AI を活用できるエンジニアの ROI が従来の 3 倍 と予測している。日本でもDeNAなどを筆頭に、比較的若い企業を中心に「AIを使うエンジニア」の採用に舵を取り始めている。この流れは非常にゆっくりとしたものだが、エンジニアの世界ではAIを使い倒す会社で仕事ができるか、そうでないかは、これからのキャリアの形成に致命的な影響を与えるだろう。

人材評価軸の変化

「できる」のは当たり前になった。実装速度もコンピュータには勝てない。元々計算では勝ち目がなかったが、AI によって「実務を執行する能力」でも勝てなくなった。人間に残されたのは「なぜ・なんのために」を問えるという、意思決定と判断だけだ。これからは、この部分でしかしか評価されない。

それを示唆するかのように、エンジニアの世界では人材評価・面接の現場でも急速な変化が起きている。

techcellar が示す Vibe Coding 時代の採用基準は、「コードが書ける」から「AI の出力を評価し、正しい設計判断ができる」へ移った。チーム構成も従来 8 名 → 6 名に縮小しつつ、シニア比率が上がり、ジュニア 5 名教育コスト < シニア 2 名 + AI ツール投資、という計算に変わった。

Meta は 2025 年 10 月に CoderPad 3 パネル + GPT-4o mini / Claude 3.5 Haiku / Llama 4 Maverick から選択可能な AI アシスタント付き面接を導入し、Google は対面面接を復活させて AI を排除した。「正しい / 正しくない」の話ではなく、何を測りたいかの違いで企業が分岐し始めた。Googleは天才しか入れないので例外で純粋に頭の良さと人柄を見抜くためだろうが、AI使用可の実務テストをし、その成果物を元にディスカッションをするという採用試験の事例が国内外で出始めている。

結論: AI を使う・命令する側にならないと仕事は無くなる

シンギュラリティはすでに起きている。 業務の遂行と正解のある領域において、人間はもはや勝負にならない。シンギュラリティという語の射程をこの 2 領域に限定すれば、それは 既に起きてしまった出来事だ。

時代に取り残されないためには、AIを「使えるか / 使えないか」を判断するのではなく「どうすれば、AIを業務に取り込めるか」という立場で向き合ってなくてはいけない。 特定の業務において、今はオモチャかもしれない。しかしオモチャだと思っている間に、あっというまに我々の仕事をすべて持ち去っていく。昨日まで磨いてきた技術と経験は、明日には何の免許にもならなくなってしまう。

すべてがAIに置き換わっていくのは、時間の問題である。

記事内で引用した文献