AI支援とデバッグ能力の逆説
AIを導入すれば、エンジニアの生産性は爆発的に上がるはずだって、今、世界中の企業がそう信じて疑いませんよね。
それが現在のコンセンサスというか常識みたいになっていますからね。
ですよね。でももし、AIを使った若手エンジニアの方が、自力でコードを書いたエンジニアよりもスキルのテストで17%も低い成績を叩き出したとしたら、これどう思いますか?
いやー直下に完全に反するデータですよね。最高のツールを与えられたはずなのに。
そうなんですよ。最高のツールを与えられた彼らがなぜかポンコツになってしまった。
今日はこのちょっと背筋が凍るようなパラドックスからスタートしたいと思います。
はい。よろしくお願いします。
今日のディープダイブへようこそ。今回私たちが読み解くのは、若手エンジニアの生々しいコードリーディングの実践記録から、
AI駆動開発がもたらすパラダイムシフト、そしてエンジニアの生存戦略までを網羅した専門的な技術記事の数々です。
どれも非常に興味深いタイムリーな資料でしたね。
ええ。よし、これを紐解いていきましょうか。
今日のミッションはですね、AIがコードを書いてくれる時代において、人間にとって本当に価値のあるスキルとは一体何なのか、これを突き止めることです。
この数年で起きた知覚変動を理解する上で、絶対に避けては通れないテーマですね。
早速なんですが、先ほどの17%の成績低下という衝撃的なデータについて、少し深掘りさせてください。これ、アンソロピック社が行った研究ですよね。
ええ、そうです。52名の若手エンジニアを対象にした調査ですね。
AI支援ありのグループとなしのグループに分けてコーディングタスクを行わせたと。
普通に考えたら、関数とかクラスのひな形を瞬時に作ってくれるAIを使った方が圧倒的に有利なはずですよね。
そう思いますよね。そこがこの研究の最も面白いところなんですが、タスクを完了するスピード自体は、確かにAIを使った方が早かったかもしれないんです。
はいはい。
でも、その後に実施された習熟度テストでは、AIを全く使わなかったグループの方が優秀だったんですよ。
ええ、使わなかった方が優秀だったんですか?
ええ。特に大きな差が開いたのが、デバッグ能力なんです。
デバッグ、つまりバグを見つけて直す力ですね。
その通りです。生成されたコードの中に潜む論理的な破綻とかバグを見つけ出して修正する力が、AI依存グループでは著しく低下していたんです。
なるほど。つまり、AIが書いたコードがなぜ動いているのか、あるいはなぜ動かないのかをそもそも理解できていないってことですね。
まさにそういうことです。ブラックボックス化してしまっているんですね。
これなんかすっごくよくわかる気がします。私最近は車の運転で完全にカーナビに頼り切っているんですよ。
ああ、GPSのナビですね。
次を右ですとか、その次を左ですって言われるがままにハンドルを握っていると、自分の頭の中に空間の地図が全く作られないんですよね。
はいはい、わかります。
結果として、山奥とかでふと電波が途切れた瞬間に、自分がどこにいるのかすらわからず、完全に迷子になってしまう。
AIへの過度な依存って、このコーディングにおける方向感覚の喪失と同じ現象なんじゃないですか?
そのカーナビの例えは、今起きている問題を非常に正確に捉えていますね。
本当ですか?
ミシガン大学のマーク・グズディアル教授も似たような比喩を使っています。
彼はこれを自転車と自動車の違いで説明しているんです。
自転車と自動車ですか?
はい。かつてスティーブ・ジョブズは、コンピュータのことを人間の能力を拡張する知的自転車だと表現していましたよね。
有名な言葉ですね。自分の足でペダルを漕ぐからこそ遠くまで行けると。
そうなんです。思考というペダルを漕ぐから筋肉が鍛えられる。
でも、教授が言うには、生成AIは自転車ではなく自動車なんだと。
なるほど。つまりペダルを漕ぐ必要すらないと。
認知的アウトソーシングと計算論的思考
目的地には確かに早く着くかもしれない。でも確実に足腰は弱っていきますよね。
うわ、それは怖いですね。
これを専門用語で認知的アウトソーシング、つまり外部委託と呼ぶんです。
認知的アウトソーシング。
プログラミングの学習において本当に重要なのは、Pythonとかジャバスクリプトといった文法を暗記することではないんですよ。
じゃあ何が重要なんですか?
複雑な課題を小さな要素に切り分けるチャンキングという処理や、過去の経験から解決策を導き出すパターン認識といった認知的なプロセスなんです。
ああ、なるほど。人間が行うべき脳の働きそのものですね。
その通りです。AIがこれらのプロセスを代行してしまうと、人間の脳内でその思考回路をつなぐ神経回路が構築されなくなってしまいます。
ということは、見た目は立派な行動が出来上がっていても、エンジニア自身の問題解決能力は萎縮してしまっているわけですね。
ええ。とりあえず動く行動で満足してしまうことが、実務においていかに危険かという話です。
そうか。AIは文法の壁を取り払ってくれたけれど、問題解決のための認知的な壁まで消し去ってくれたわけではないんですね。
まさにその通りです。
でも、自動車、つまりAIが代わりに運転してくれる世界になってしまった以上、人間がもう一度自転車に戻ってペダルを漕ぐ練習をするのも、なんか非現実的ですよね。
ええ。後戻りは出来ないでしょうね。
だとしたら、AIが運転手になる世界で、私たち人間は助手席でただぼーっと座っている以外に何をすべきなんでしょうか。
人間はですね、助手席に座るのではなく、全体を見渡してナビゲートする側に回らなければならないんです。
ナビゲートする側。
はい。つまり、コードを書くスキルからコードを読み解き、構造を設計するスキルへの根本的なシフトが必要になります。
コードリーディングと問題の構造化
ああ、なるほど。そういえば今回読んだ資料の中に、ある3年目のウェブエンジニアが書いたコードリーディングのすすめという素晴らしい記事がありましたよね。
ええ、ありましたね。非常に実践的な内容でした。
あれ、面白かったんですよ。いきなりコードの1行目から読み始めるんじゃなくて、まずはディレクトリ構成を見て、プロジェクトの全体像、つまり森を把握すると。
はい。全体像の把握ですね。
で、次にデータがどう流れているかを追いかけて、最後にコメントやAPIドキュメントと実際の挙動を擦り合わせるっていうアプローチでしたよね。
まさにそれです。このアプローチこそがAI時代に必須とされる計算論的思考の実践そのものなんですよ。
計算論的思考ですか。英語だとコンピュテーショナルシンキングですね。
これには4つの柱があります。大きな問題を小さく分ける分解、不要な情報を削ぎ落として本質を見抜く抽象化、共通のルールを見つけるパターン認識、そして処理の手順を組み立てるアルゴリズム設計です。
ここからが本当に面白いところなんですが、つまりこれまでは人間の書いたコードを読むためのスキルだったコードリーディングが、
今はAIが吐き出したブラックボックスのコードを解読して、意図通りに修正を指示するための必須スキルに変わったってことですか。
まさにその通りです。AIになんかいい感じのECサイトを作ってと丸投げするのはナビゲーションでもなんでもありません。
確かにそれはただの丸投げですね。
そうではなくて、商品データの定義はどうするかとか、決済APIとの連携フローはどうするかというふうに問題を分解して、必要な要件だけを抽象化してプロンプトに落とし込む。
なるほど。
そして出てきたコードを過去のパターンと照らし合わせて検証する。
プロンプトエンジニアリングの本質って、実はAIを通じたプログラミング、つまり計算論的思考の実行なんです。
プロンプトエンジニアリングって、ただのAIへの上手なお願いの仕方だと思っていましたけど、全然違うんですね。
少し補足すると、UCバークレーのサラ・チェイシンズ教授も問題を構造化する能力の重要性を強調しています。
問題の構造化。
AI時代のエンジニアの4役割
ここで重要なのは、ジェネレーション全コンプリヘンション、つまり生成させてから理解するというサイクルです。
生成させてから理解する。
アンソロピック社の研究で成績が良かった少数のエンジニアたちは、AIにコードを書かせた後、それをただコピペするんじゃなかったんです。
何をしたんですか?
なぜこのライブラリを選んだのかとか、この実装のボトルネックはどこかというのを、AI自身に説明させていたんです。
AIにコードを生成させて、さらにその理由を問い詰めていたわけですか?
ブラックボックスを解体して、自分の脳内にチャンキングとして再構築する作業を怠らなかったんですよ。
AIを使って誤った答えをより早く得るのではなく、正しい界に到達するための姿勢ですね。
なるほどな。でもちょっと待ってください。
はい。
つまりこれってどういうことですか?
もし私たちがタイピングしてコードを書くことから解放されて、そういうシステム全体の構造化とか検証ばかりをやるようになるなら、
実際の開発現場での私たちの肩書きってどうなるんでしょう?
もう開発者とかプログラマーって呼ぶのはしっくりきませんよね。
それは重要な問いですね。実際に現場の役割はすでに再定義され始めています。
AI時代のエンジニアが担うべき4つのコアコンピテンシーというものが資料で提示されていました。
ありましたね。4つの新しい役割。
システム全体の設計図を描くアーキテクト。複数のAIエージェントやツールを連携させてワークフローを作るオーケストレーター。
オーケストレーターかっこいいですね。
そしてAIが吐き出したコードのセキュリティや品質の防波堤となるクオリティガーディアン。
最後に組織全体のAI活用を技術的に支援するイネーブラーです。
イネーブラーってなんだかコンサルティング会社が使いそうなバズワードっぽく聞こえますけど、具体的には何をする人なんですか?
確かに抽象的に聞こえますよね。
例えば社内の誰もが安全に使える社内版ChatGPTの環境を構築するとかですね。
ああ、なるほど。
あとはAIを使ったコードレビューの自動化パイプラインを整備するとか。
自分自身が製品のコードを書くのではなく、チーム全体のAIリテラシーと開発環境を底上げする役割です。
イノベーションのインフラ整備役みたいな感じですかね。
まさにそれです。もはや開発者ではなくイノベーションの推進役へと変化しているんです。
さらに資料によると、AIが下流工程を担うことで、エンジニアにはビジネス視点とかユーザー視点、それに業界知識といったドメイン知見がこれまで以上に求められるようになっていると。
ええ、専門チームもどんどん細分化されていますからね。
いや、ちょっと待ってくださいよ。リスナーの皆さんも今情報を聞きながら息苦しくなってませんか?
と言いますと?
だってコードの品質も守って、ツールの指揮も取って、さらにビジネス課題も解決しろって、今のエンジニアってスーパーマンにならないといけないんでしょうか?
その不安は非常に全うです。
ですよね。
全てを一人で完璧にこなす必要はないんですよ。
本当ですか?
タイピング作業から解放された分、意識の向け先をどうコードを書くかから、なぜこのシステムが必要でどう価値を生むかにシフトするだけなんです。
なるほど。HowからWhyへのシフトですね?
その通りです。それに多分野の専門家との調整力、つまりソフトスキルがその負担を補ってくれます。全体像を見据えたチーム戦になるわけです。
スーパーマンになるんじゃなくて、チームで戦うためのソフトスキルが大事だと。それなら少し安心しました。
AI活用の落とし穴と批判的思考
ただ、スーパーマンになる必要はないとしても、このAIとの共同において絶対にやってはいけない落とし穴ってありますよね?
もちろんです。そこを避けることが最低条件になります。
資料にもいくつかアンチパターンが挙げられていましたね。
ええ。最も致命的なのが盲目的信頼です。検証せずに本番環境に投入してしまうことですね。
うわー、それは怖すぎる。
さらに、プロンプトに機密情報を入れてしまう機密情報漏洩やライセンス違反も致命的です。
そのあたりはルールでガチガチに防ぐしかないですね。でも、もっと日常的にやってしまうミスもありそうです。
そうですね。中リスクとして挙げられているのが雑なプロンプトです。レイジープロンプティングとも呼ばれます。
あー、雑なプロンプト。リスナーのあなたも最近AIにとりあえずこれ作ってとだけ入力する雑なプロンプトを使っていませんか?
これ本当に多いんですよ。背景にある文脈や制約条件を伝えずに丸投げしてしまう。
そして出てきた答えを根拠なく、なんかもっともらしいからって信じてしまうんですよね。
これを防ぐためには、先ほどお話しした計算論的思考と並んで批判的思考、つまりクリティカルシンキングが不可欠になります。
AIを疑う力ですね。
面白いデータがありまして、マイクロソフトの研究なんですが、AIを信頼すればするほど人間の批判的思考が低下するという結果が出ているんです。
え?信頼すると批判できなくなる?
そうなんです。AIは自分より賢いと思い込んで思考停止してしまうんですね。
怖っ。じゃあその罠にはまらないための今日からできるベストプラクティスって何なんでしょうか?
はい。高スコアを出したエンジニアたちが実践していた概念的質問というアプローチが有効です。コンセプチュアルインクワイヤリーですね。
概念的質問。具体的にはどうやるんですか?
いきなりコードを書かせるのではなく、この要件を満たすにはAとBどちらのアプローチが良いか、それぞれのトレードオフは何かとAIに問いただけるんです。
なるほど。さっきの生成してから理解するというサイクルと同じですね。
動いたから正しいではなく、期待値と実際の差分を特定する。このデバッグ手法こそがAI時代を生き残る最強の武器になります。
期待値と実際の差分をデバッグする。本質的な部分は何も変わっていないんですね。
そうですね。
抽象化の歴史と自然言語の未来
さて、そろそろ今回のディープダイブの全体像が見えてきました。プログラミングの歴史を振り返ってみると、これってアセンブリ言語から自然言語への抽象化の歴史に過ぎないんですよね。
まさにその通りです。抽象化のレベルが上がっただけで。
だからこそ、本質的な問題を分解し、手順を設計する力は何も変わっていない。
はい。回のレイヤーがAIによって自動化されたからこそ、上位のレイヤーである論理的に問題を構造化する力の重要性が剥き出しになっていると言えます。
リスナーのあなたがプログラマーであっても、日常的にAIを使うビジネスパーソンであっても、真の価値は的確な指示を出し、出てきた結果を検証する目利きの力にあるわけですね。
全く同感です。
最後に、今日の内容を踏まえてリスナーの皆さんに一つ考えてみてほしいことがあります。
はい。
今日の議論のベースにあった自然言語が最もホットなプログラミング言語であるという事実。もしこれが本当なのだとしたら。
私たちが普段同僚と交わしている会話や部下への指示、顧客へのメールといった日常のコミュニケーションそのものが、未来のソフトウェアを動かすための最初のソースコードになっていると言えないでしょうか。
日常のコミュニケーションが最初のソースコード。これは非常に示唆に富んだ視点ですね。
あなたの普段発している言葉の解像度はAIを正しく安全に動かせるレベルに達していますか。
次にプロンプトを入力するとき、ぜひこの問いを思い出してみてください。
素晴らしい締めくくりですね。言葉の解像度、私も意識したいと思います。
それでは今回のディープダイブはこの辺で、また次回お会いしましょう。
