仏教用語「末法」の概念を借りるなら、形は残っていても、核心が忘れられやすい時代のことだ。これはあくまで比喩であり、教義の解釈ではない。
融資を断られた一人と、誰も説明できない会議室
導入したばかりの融資審査システムを想像してほしい。仕様通りに動き、テストは通り、ダッシュボードも緑色だ。ある顧客が審査に落ちた。彼は異議を申し立てた。関係者が集まっても、なぜシステムがその結論に至ったのか、誰も説明できない。
プロダクト担当は「ルールは承認済みだ」と言う。データ担当は「モデルの精度は良好だ」と言う。エンジニアは「コードの大部分はAI支援で生成され、テストも揃っている」と言う。誰も明らかなミスを犯していない。だが、その結果に至る道筋全体を本当に理解している者もいない。
このときIT従事者が抱く不安は、単に「AIの方が自分より速くコードを書く」という話ではない。もっと厄介なのは次のことだ。理解しなくてもコードが生み出せるなら、理解している人間は一体何に対して報酬を得ているのか。
これを私は「コード末法」の時代と呼ぶことにする。
コードが消えていくからではない。むしろ、コードはこれまでになく増え続けている。「コード末法」とは、コードがあまりに安く作れるようになり、それを生み出すこと自体が能力の証明にならなくなった時代を指す。
コードの三時
末法の「三時」という構造を借りるなら、プログラミングという仕事はこう見えてくる。
正法コードの時代は、書くことと理解することがほぼ同じだった時代だ。初期システムのアセンブリやCでは、機械が何をしているか理解しなければ、正しく動く一行すら書けなかった。コードを書くことは非常に物理的な行為だった。メモリ容量、CPUの動き、バイトがどこにあるか。
像法コードの時代は、フレームワークやライブラリ、Stack Overflow、コピー&ペーストの時代だ。あらゆることが手に入りやすくなり、それは本当の進歩だった。しかしそこから、自分がきちんと読んだことのないコードを動かすことにも慣れていった。リポジトリもコミットもプルリクエストも変わらずあるが、「書くこと」と「理解すること」の距離は少しずつ広がっていった。
末法コードとは、その形式がほぼ無限に生み出される時代だ。一つのプロンプトが、サービスに、ウェブサイトに、テスト一式に、バグ分析にすらなり得る。あまりに速いため、私たちは「動くもの=理解されたもの」だと錯覚しかねない。
AIがこの乖離をゼロから作り出したわけではない。古くからの傾向を極限まで押し進め、それを私たちの目の前に突きつけただけだ。
何の価値が下がっているのか
最も早く価値を失う仕事は、まさにAIが最も得意とする仕事だ。ボイラープレート、CRUD、ありふれたUI、構文の確認、あるいは明確な要件を動くコードに変換すること。
だからといって、これらのスキルが無意味になるわけではない。エンジニアは依然としてコードを読み、修正し、評価するために、コードを知っている必要がある。しかしそれだけではもはや差別化にならない。コード行数、タイピング速度、週あたりの機能出荷数は、もともと貧弱な指標だったが、今はさらに貧弱になった。
AIが力を発揮するのは、目標が明確で、データが十分にあり、正誤の基準を具体的に示せる場合だ。現実はたいてい逆である。要件は曖昧で、データは汚く、目標同士がぶつかり合い、途中でルールが変わり、予算は常に足りない。
融資審査システムの話に戻ろう。AIはそれを書く手助けはできる。しかし、会社が利益と与信アクセス、公平性のどれを優先すべきかをAIが決めるわけではない。そして誰かが不当に断られたとき、説明のために座り、結果を修正し、信頼の喪失を引き受けるのはAIではない。
とはいえ、「価値は判断力へと移っていくだけだ」という言葉で自分を安心させるべきでもない。ある業界は一人当たりの価値を高めながら、必要な人数を減らすことができる。それは十分にあり得る。逆の可能性も同じくらい現実的だ。コードが安くなることで、より多くのシステムが生まれ、それに伴い運用、セキュリティ、統合、保守の負担も増える。天秤がどちらに傾くかは誰にも分からない。はっきりしているのは、これまでと同じ形の仕事はもう戻ってこないということだけだ。
新しいボトルネック:生成は簡単、検証こそ難しい
これはおそらく最も重要な変化だ。
コードを生成する能力は猛烈な速さで伸びている。一方、それを読み、理解し、検証する人間の能力は同じ速度で伸びてはいない。だからこそ、この職業のボトルネックは「生産」から「検証」へと移りつつある。
AIが生成した数百行のプルリクエストをレビューしたことがある人なら、この感覚が分かるはずだ。命名は美しく、コメントも十分で、構造も一見きちんとしている。あまりに滑らかで、レビュアーはつい頷いてしまいそうになる。そして本番環境に上がったあと、誰も疑わなかった小さな前提から綻びが始まる。
だからこそ、コード末法の時代はコードを書く人よりも、コードを読む人を優遇するのかもしれない。価値ある人材とは、「一見問題なさそうな」五百行を見て、こう問える人だ。ここでまだ証明されていない前提は何か。データが欠けたとき、サービスが遅延したとき、ユーザーが想定外の行動をしたとき、何が起きるのか。
経典が無限に印刷できるようになったとき、希少なのは経典そのものではない。希少なのは、それを読み理解できる人だ。この比喩は、偶然にも今日のコードによく当てはまる。
見過ごせない二つの問い
「責任を負う」ことは本当の能力なのか、それとも法律がまだ追いついていないだけなのか。
これは強力な反論だ。人間がまだ名前を出している理由は、単に法律がAIシステムに責任を負わせることを許していないからかもしれない。もし法律が変われば、この「堀」は驚くほど早く狭まる可能性がある。
しかし責任とは、誰が訴えられるかという話だけではない。それは信頼の問題でもある。ある決定が害をもたらしたとき、顧客も、同僚も、社会も、説明し、意見を聞き、やり方を変えられる誰かを必要とする。それは法的手続きだけでなく、社会的な必要性でもある。とはいえ、この境界線は今後も確実に動き続けるだろう。
もしAIがジュニアの仕事を奪うなら、十年後のシニアはどこから生まれるのか。
これは非常に現実的な逆説だ。判断力は自然に生まれるものではない。小さな仕事、間の抜けたバグ、失敗したデプロイを通じて積み上げられていくものだ。ところが、まさにそうした仕事こそが、真っ先に自動化される部分なのだ。
すっきりした答えはない。しかし、この職を学ぶ道筋は設計し直す必要がある。ジュニアはプロンプトを受け取って出力を提出するだけであってはならない。検証の仕方、実際のシステムを観察する方法、そして一つの決定を最初の前提までたどる方法を学ぶ必要がある。これはシニアと組織の仕事であり、「自分を高めよ」という曖昧な助言だけで済む話ではない。
では何を「修める」べきか
AIの外に立つための修行ではない。AIを使いながらも、自分の判断力を失わないための修行だ。
検証力を修める。 AIの出力を、方法論的な懐疑をもって読む。テストはチェックリストを埋めるためではなく、危険な前提を食い止めるために書く。ログを見て、本番環境を観察し、インシデントのたびに問い直す。自分たちは何を、確認せずに信じていたのかと。
明確さと文脈理解を修める。 AIにとって、明確な問いは解決策の大部分を占めることが多い。最初の一行のコードが書かれる前に、問題設定、成功基準、制約条件を書く練習をしよう。同時に、金融、物流、教育、医療といった特定の領域に深く入り込み、なぜその要件が生まれたのかを理解できるまで掘り下げよう。そうして初めて、「この要求は筋が通っているが、この方法で作るべきではない」と言えるようになる。
誠実さを修める。 知らないことは知らないと言う。動くから、締め切りが迫っているからという理由だけで、自分が説明できないものをリリースしてはいけない。「とりあえずデプロイしよう、見た目は問題なさそうだ」と「待て、私はこの部分をまだ理解していない」のどちらかを選ぶ場面が必ず訪れる。後者を十分な回数選び続ければ、あなたはチームが難しい仕事を任せたいと思う人材になる。
AIは、私たちがより速く試し、より速く理解するための梃子であるべきだ。自分の思考力を丸ごと預ける場所であってはならない。
コード末法は、この職業の終わりではない
末法という概念を比喩として見るなら、それは絶望への誘いではない。状況が変われば、実践のあり方も変わらねばならないという気づきである。
プログラミングという職業が消えるわけではない。終わりつつあるのは、コードを打つことと価値を生み出すことを取り違えていた時代なのだ。
コード末法の時代には、おそらく最速でコードを書く人になろうとする必要はない。むしろ、システムに何かが起きたときにチーム全員が頼る人になろう。何が起きているかを理解し、問うべき問いを知り、自分の決定に自分の名前を刻む勇気を持つ人に。