想起能力を超えて：能力の幻想

想起能力を超えて：能力の幻想 2026年8月25日 AIとプログラミングについては、主に二つの支配的な意見があるようです。一つは、AIはひどいコードを書くため、その間違いを修正するのに自分でコードを書くよりも時間がかかるので、ほとんど役に立たないという意見です。もう一つは、AIが生成するコードは非常に優れており、最終的にはプログラマーを不要にするだろうという意見です。私はどちらの議論も、コードを書く主体に焦点を当てているため、的を射ていないと考えています。 私たちは決して全てのコードを書いてきたわけではありません。私は、構文を記憶したり、コードを記憶から打ち込んだりする能力が、自分の仕事にとって特に重要だと考えたことはありません。私はドキュメントを使います。インターネットで検索します。Stack Overflowから例をコピーします。ブログ記事を読みます。同僚が書いたコードを見ます。現代のソフトウェアシステムでは、これはほとんど避けられません。典型的なアプリケーションは、TypeScript、Python、またはGo、YAML、Dockerfiles、SQL、設定ファイル、CIパイプライン、そして数十の他の技術を扱うかもしれません。誰もがそれら全ての詳細を記憶しているわけではありません。ですから、Stack Overflowから有用なコード片をコピーすることが常に許容されてきたのであれば、なぜ機械にそのコードを生成させるのが根本的に違うのでしょうか。 所有権は決して作者権ではなかった 私が「AIがコードを書く」という議論をあまり説得力がないと感じるもう一つの理由は、私たちは常に、自分たちが書いていないシステムで作業してきたからです。あなたは別のチームからサービスを引き継ぎます。会社を辞めた人がその半分を書きました。あなたが責任を持つ部分には3人が貢献しましたが、誰がどの関数を書いたのかさえ覚えていません。それでも、そのシステムで十分に長く作業した後、あなたはそれを自分のものだと考えるようになります。なぜでしょうか？すべての行を書いたからではありません。あなたがそれを理解しているからです。それが何をするかを知っています。なぜそのように動作するのかを知っています。その境界線がどこにあるか、その依存関係は何で、何かがうまくいかなくなったときに何が起こるかを知っています。それが、真の所有権というものです。 アウトソースする危険なもの AI支援プログラミングが興味深くなるのはこの点です。問題は、機械がコードを書くことではなく、機械に思考プロセスまで任せてしまうことが非常に簡単であることです。「何が必要かを理解している。それを私に書いてほしい」と言うのと、「これを機能させて」と言って、返ってきたものをそのまま受け入れるのとでは、大きな違いがあります。前者の場合、あなたはタイピングを委任しましたが、後者の場合、あなたは理解を委任しました。そして、それらは全く同等ではありません。 デバッグは明白になる場所 コードを書くことは、驚くほど簡単にアウトソースできます。デバッグは、重要なものを手放さずにアウトソースするのがはるかに困難です。システムを自分でデバッグするとき、あなたはそれをモデル化することを余儀なくされます。あなたは期待される結果を持っています。しかし、異なることが起こりました。そこで、あなたは逆算します。何が起こるべきだったのか？観測された結果を生み出すためには何が必要だったのか？現実があなたの期待から逸脱した連鎖のどこか？これらの演習を十分にこなすと、あなたは非常に価値のあるもの、つまりシステムがどのように動作するかについての直感を養います。私はこのスキルを持たない開発者たちと一緒に仕事をしたことがあります。何かが壊れると、彼らはランダムに物事を変更しました。彼らはただ暗闇の中で手探りし、最終的に何かが機能するまで続けましたが、なぜそうなるのかは全く理解していませんでした。それはデバッグではありません。AIは、まさにこのパターンに陥ることを驚くほど簡単にします。機械にエラーを与え、修正案を提案させ、修正を試み、次のエラーを報告し、テストがパスするまで繰り返します。あなたは、自分が生成しているソフトウェアの有用なメンタルモデルを一度も構築することなく、動作するソフトウェアを生成できます。 能力の幻想 これが、AIがプログラマーを置き換えることよりも、私がより心配していることです。AIは、システムをあなたのために機能させることができるため、あなたがシステムを理解しているという幻想を作り出すことができます。あなたは質問をして、答えを得ます。あなたはエラーに遭遇し、パッチを得ます。パッチが機能しないので、あなたは新しいエラーを提供し、別のパッチを得ます。最終的に機械は何かが機能するものを発見します。外部から見れば、これは能力のように見えます。しかし、なぜその解決策が機能するのかを理解していなければ、あなたは実際にはより有能になっていません。あなたは幻想を維持するために機械に依存しているのです。そして、機械が解決できないこと、あるいは単にトークンが尽きたときに、その結果は特に深刻になります。その時点で、あなたは構築しなかったメンタルモデルが必要になります。 ジュニアにとってはさらに重要 経験豊富な開発者にとっては、少なくとも長年の問題解決の経験から蓄積された知識の大きなリザーバーがありますが、今日から始める人にとっては、その経験が同じようには決して蓄積されないかもしれません。もし、フラストレーションのたまるデバッグセッションがすべてAIに委ねられるなら、システムがなぜそのように動作するのかを4時間かけて理解しようとするインセンティブはほとんどありません。そして、その4時間は無駄な時間ではありません。それこそがメンタルモデルが生まれる場所です。あなたはシステムを成功裏に変更することによってシステムを学ぶのではありません。システムがなぜ失敗するのかを説明できるようになれば、システムを成功裏に変更できるようになるでしょう。 理解をアウトソースしない 私は、答えはAIの使用をやめることだとは思いません。全く逆です。積極的に使いましょう。定型的なコードを書かせましょう。構文を思い出させてもらいましょう。未知のライブラリを探求させましょう。面倒な部分を実装させましょう。しかし、重要な部分はあなた自身のために取っておいてください。あなたは問題を理解すべきです。システムが何をすべきかを決定すべきです。アーキテクチャ上の決定を下すべきです。各部分がどのように組み合わさっているか、そしてなぜそのように設計されたのかを説明できるべきです。AIにコードを書かせましょう。解決策を設計させるのではなく。 開発者はよりアーキテクチャ的になる コーディングが安価で誰にでもアクセス可能になるなら、コーディングはそれほど差別化要因ではなくなります。際立つ開発者は、システムを理解している人々でしょう。アーキテクチャ。統合。分散システム。オブザーバビリティ。障害モード。境界線。トレードオフ。コードの内部ではなく、その周りに存在するものです。その意味で、AIは実際に開発者をよりアーキテクチャ的な役割へと押しやるかもしれません。最高の開発者は、機械にコードを書かせない人々ではありません。彼らは、機械を使ってシステムをより良く理解しつつ、決定権をしっかりと握っている人々でしょう。この議論のビデオ版を作成しました。もし視聴したい場合はこちらをご覧ください：想起能力を超えて：AI時代のソフトウェアエンジニアの役割。お読みいただきありがとうございました。