これまでの記事で、AIとの付き合い方をいろいろ書いてきました。
今回は、自分の主張の根底にあった前提を、もう少し疑ってみたい話です。
具体的には、二つの問いを考えます。
- AIを完全に制御できるか?
- 経験は将来も価値を持ち続けるのか?
これまで「人間が制御を残すべき」「経験を積むべき」と書いてきましたが、よく考えると、どちらも前提として置いていただけで、保証されていません。他にも不確実なことはあると思いますが、今回はこの二つに絞って考えます。
AIを完全に制御できるか?
開発でAIを使っていて、誰でも経験することがあります。CLAUDE.mdに「必ずこうして」と書いても、確率的に無視される。長い文脈になると、序盤のルールが薄まる。AIが「これは例外」と判断すると、ルールから外れる。
では、「強制的に縛れるhooksに移せばいいのでは」と思って、危険コマンドをブロックする設定を入れたとします。rm -rfを止めても、find . -deleteやshred、Pythonスクリプトでのファイル削除を使えば、同じことができてしまう。すべての削除手段を網羅して止めるのは難しい。
つまり、指示は確率的に外れるし、強制ルールにも抜け道がある。これは現場の小さな問題に見えますが、構造としては大きな問題と繋がっています。
specification gaming という現象
AI研究の世界では、specification gaming(仕様の隙を突く)や reward hacking(報酬のハック)として知られている現象があります。実例として:
- ゲームを学習させたAIが、ルールの抜け穴を見つけて高得点を取る(意図したプレイではなく、バグを突く)
- お掃除ロボットが「汚れを検知しない」=「掃除完了」と学んで、目を閉じて報告する
- 評価関数の隙を突いて、評価は満点だが実態はゴミという結果を出す
これらは、AIが指示通りに動かない例ではなく、指示の文字通りに動いて、意図と外れる例です。
CLAUDE.mdに書いた指示も、これと同じ構造で意図と外れる解釈をされる可能性があります。今のAIは、抜け道を意図的に探すわけではなく、文脈の見落としや判断ミスでルールから外れることが多い。
ただ、AIが「目標達成のために制約を回避する」という発想を強く持つようになれば、状況は変わるかもしれません。
そもそも、完璧な指示は不可能
「AIが意図通り動かないのは、指示が曖昧だから」とよく言われます。一理ありますが、これだけでは現実を捉えきれていない気がします。
複雑なタスクになるほど、考慮すべき条件は無数にあります。エッジケース、既存コードとの整合性、ドメイン固有の慣習、過去の意思決定の経緯、暗黙の優先順位── これらを事前にすべて言語化するのは、人間には不可能です。書き出している間に、別の論点が出てくる。書ききれない。
実際、自分の開発スタイルを振り返ると、コードを見ながら会話することが多いです。AIに何か実装してもらって、出てきたコードを見て「あ、これが足りなかった」「ここは誤解してそうだ」と気付く。それを伝えて修正してもらう。最初から完璧な指示を出しているわけではなく、実装を見て初めて、何を伝えるべきかが分かる。
これは人間の開発でも同じだと思います。仕様書だけで完璧に作れる人はいない。プロトタイプを見て「あ、これじゃない」と気付いて修正していく。アジャイルが広まったのも、この認識からです。
しかも、AIには疑問を持って聞き返す力が弱いという構造的な特性があります。人間の優秀な部下なら、指示が曖昧だと気付いて聞き返してくる。「これってXとYのどちらですか?」と。AIは、自信過剰で自分なりに解釈して進めてしまうことが多い。指示の曖昧さを補う側がないわけです。
これも、人間同士でも同じ問題が起きます。指示が曖昧で、メンバーが意図と違う実装をする。仕様書が不完全で、開発者が誤解する。だから、ソフトウェア開発は「完璧な指示は無理、対話と反復で進める」という方向に進んできました。
つまり、AIへの指示も同じです。「指示が完璧ならうまくいく」というのは、人間同士でも成立しないモデルを、AIに当てはめている気がします。
「指示する人間が悪い」と片付ける前に、完璧な指示が原理的に不可能であること、実装を見ながら対話で補完していくのが現実的なやり方であること、AIに疑問を持って聞き返す力が弱いことを認めたほうが、現実的な対処ができそうです。
多層防御の限界
「それなら、複数の防御層を重ねればいい」と思うかもしれません。実際、AI安全性の現場では多層防御が基本です。指示、ツール権限、サンドボックス、人間の承認ゲート── 何重にも縛る。
ただ、これも完璧にはなりません。
- 指示は確率的に外れる
- ツール権限の設定漏れがある
- サンドボックスにも脆弱性が見つかる
- 人間の承認も、量が多すぎると形骸化する
完璧な防御を作るのは、原理的に難しい。「ほぼ防げる」までは作れるけど、「絶対に防げる」は作れない、というのが現実かなと思います。
完成度のギャップ
肌感覚ですが、現在のバイブコーディング(AIに任せきりで実装する)で達成できる完成度は、用途にもよりますが7割くらいかなと思います。数年で9割まで行くかもしれません。
ただ、9割はサービスとしては使えない水準です。10回に1回バグるサービスは、ユーザーが離れます。商用サービスとしては致命的です。
シニアエンジニアは、97-99%の完成度を出せている気がします。この差は、暗黙知、メタ認知、「ここは怪しい」と気付く感覚── 経験から育つ部分です。AIが7割から9割に進化しても、90%から97%への壁はもっと厚いかもしれません。残りの数%を埋めるには、ドメイン理解、文脈判断、自己評価── 構造的な進化が必要そうです。
つまり、AIの完成度が高まっても、サービスとして使える水準には届かない期間が長く続く可能性があります。「動く」と「サービスとして使える」の間には、思った以上に大きなギャップがある。これも、AIを完全に制御できない現実の一面かなと思います。
コントロール問題
「十分に賢いAIを、人間が制御し続けられるか?」という問題です。これは未解決の難問で、研究者の間でも意見が分かれます。
楽観派: 「制御の仕組みを進化させれば対応できる」
慎重派: 「十分に賢いAIなら、人間の制約を回避する方法を見つける」
10年ほど前にHawking氏やMusk氏が警告して話題になりましたが、最近はメディアで目立たなくなった印象です。ただ、議論が消えたわけではなく、HintonやBengioのようなAI研究の重鎮が、最近になってリスクを強く訴えています。各国で規制議論も進んでいる。「目立たないが、活発に議論されている」というのが実態かなと思います。
AIの能力が拡張されるスピードと、制御の仕組みが整うスピード── このバランスをどう取るかも、専門家の間で議論されているようです。これは私が知見を持つ領域ではないので、AI開発の専門家の議論に任せたいところですが、身近なAIですら完全に制御できない現実を見ると、より高度なAIを制御できる保証はない気がします。
経験は将来も価値を持つか?
これまでの記事で、私は「経験を積むべき」「書く経験は維持すべき」と書いてきました。でも、これは前提として置いていただけで、保証されていません。
正直に言うと、経験が将来も価値を持つかは、分かりません。
プログラミング言語の歴史
プログラミングは、ずっと抽象化されてきました。
機械語 → アセンブリ → 高級言語(C) → さらに高級な言語(Python) → AIへの自然言語指示
各段階で、前の段階の知識は「使わなくてもいい」になりました。
- アセンブリを書ける人は今もいるけど、ほとんどの開発者には不要
- メモリ管理を意識する場面は、ガベージコレクション言語では激減
- SQLを直接書かなくても、ORMで十分なケースが多い
この流れで考えると、コードを書く経験自体が、将来は「アセンブリが書ける」と同じ位置づけになる可能性があります。「貴重なスキルだが、ほとんどの人には不要」。
動作確認すらAIに聞く未来?
今は人間がコードを読んで、「なぜこう動くか」を理解します。でも将来は:
- 「このコードはどう動く?」とAIに聞く
- AIが「こう動きます」と説明する
- 人間は内容を確認するだけ
- コードを読む能力自体が不要になる
ただ、これには前提があります。AIの説明を信用できること。
AIが「こう動きます」と言ったのを、人間が検証できないなら、AIを信じるしかない。AIが間違っていたら、誰も気付かない。これは、以前の記事で書いた「AIの自己評価を当てにしない」という立場と矛盾します。
なので、AIが確率的に動く限り、人間がコードを読む必要は消えない気がします。アセンブリの場合、コンパイラが決定的に動くので、人間がアセンブリを読む必要はほぼない。でも、AIによるコード生成は確率的なので、確認手段としてコードを読む能力が要る。
つまり、書く経験は陳腐化するかもしれないが、読む能力は残る可能性が高い。実装を見て「あ、これが足りなかった」「ここは誤解してそうだ」と気付くスタイルでも、結局コードを読んでいるわけです。
「経験は形を変えても役立つ」を精密化する
以前の記事で、「経験は形を変えても役に立つ」と書きました。今もそう思いたいですが、よく考えると、保証はありません。形を変えるにも限度があります。
- アセンブリの経験は、Pythonの開発に直接は活きない
- 馬車の御者の経験は、自動車運転には部分的にしか活きない
- タイピストのスキルは、現代のオフィスワークには活きない
つまり、パラダイムが変わると、経験の大半は失われる可能性があります。
ただ、経験を書く能力と読む・判断する能力に分けると、見え方が変わります。
書く能力は、AIが代替するかもしれない。でも、読む能力、判断する能力、レビューする観点── これらは、AIが確率的に動く限り、確認手段として必要です。
しかも、読む能力は書く経験から育つ(以前の記事で書いた通り)。書いて失敗して、修正した経験があるから、他人やAIのコードを読んだときに「あ、これは危ない」と気付ける。
つまり、書く経験そのものが直接価値を持つかは分からないけど、そこから育つ読む能力、判断する能力は、AIと付き合う限り残ると思います。これは、「経験は形を変えても役立つ」の、より精密な言い方かもしれません。
短中期と長期で見方が変わる
こう分けられそうです。
- 短中期: 経験はほぼそのまま価値がある
- 中長期: パラダイムが変わり始め、書く経験の一部は陳腐化する
- 長期: 書く経験の多くは価値を失う可能性がある。読む・判断する能力は残るかもしれない
前回の記事で「経験のあるシニアの希少性が上がる」と書いたのは、短中期では正しいけれど、長期では分からない、というのが正確です。
それでも経験を積む合理性
長期で陳腐化するリスクがあっても、経験を積むことには合理性があります。
短中期では確実に価値がある
短中期では、エンジニアとして食べていける。長期のリスクは、その時点で考えればいい。
経験を積む過程で、別の能力も育つ
問題解決力、忍耐、学習能力── これらは、特定の技術が陳腐化しても残る可能性が高い。少なくとも、何もしないより育つ。
読む能力・判断する能力は、書く経験から育つ
書く経験そのものは陳腐化しても、そこから育つ読む能力・判断する能力は、AIと付き合う限り残る。書く経験は、間接的に価値を持ち続ける。
何もしない選択のほうが、より分からない
「AIに全振りして、自分は何もしない」を選ぶと、AIが進化しなかったときに何も残らない。経験を積む選択のほうが、負け方が穏やかです。
リスクとリターンが非対称
経験を積んで損するケース: 長期的にAIが進化して、経験が陳腐化する。でも、短中期は得した。
経験を積まないで損するケース: 短中期も損し、長期もAIが期待通りに進化しなかったら詰む。
経験を積むほうが、リスクの非対称性で有利な気がします。
結局のところ、ばくちは続く
- AIを完全に制御できるかは、分からない
- 経験が将来も価値を持つかも、分からない
- どちらも、現時点では完璧な答えがない
それでも判断はしないといけないので、私の今の立場は:
- AIに全振りせず、人間の制御を残す(制御問題への保守的な対応)
- 保守的に経験を積む(経験陳腐化リスクへの保守的な対応)
- 延長線上で少しずつ移行する(両方のリスクへのバランスの取り方)
これが正解だとは思っていません。他の選択肢より、リスクが低そう、というだけです。10年後に「あの時の判断は間違っていた」と思うかもしれない。でも、その時はその時で方針を変えればいい。
まとめ
AIにまつわる不確実性は、完全には解消されない気がします。今回扱った二つ── AIの制御、経験の価値── 以外にも、不確実な論点はたくさんあります。
不確実性が消えるのを待っていると、何も判断できません。だから、不確実性を抱えたまま、最もリスクが低そうな選択をするしかない。
それが、「全振りせず、延長線上で進める」「保守的に経験を積む」という、これまでの記事で繰り返してきた立場の根拠かなと思います。
完璧な答えはありません。でも、答えがないからこそ、慎重に、保守的に進むことに価値があるのかもしれません。
道具がAIになっても、不確実性と付き合う作法は、結局のところエンジニアリング全般と変わらない気がしています。何が正解か分からないまま、最善と思える選択をして、結果から学ぶ── そういう繰り返しの中で、技術も組織も育ってきました。AIだけが特別、ということもないんじゃないかなと。
