AI時代のプログラミング ― ChatGPTとGeminiを競わせる「一筋縄ではいかない」付き合い方

プログラムを一から書くのは、もはや大学の授業くらいではないでしょうか。

DeNAの南場智子氏のスピーチによると、今やほぼ全ての現場で「コードを書く」という作業が激減しているそうです。「プロジェクトによっては、作業の5%を人間が、95%をAIが担うものまである。結果、従来の20倍の生産性を手にした事例もある」とのこと。

南場智子「ますます"速さ"が命題に」DeNA AI Day2026全文書き起こし - エンジニアtype | 転職typ

一方で、生成AIは「作る側」を楽にする反面、「チェックする側」の負荷を増大させている、品質の低い成果物の検証や修正に追われる現場の話も、最近よく耳にします。先日も、こんな記事がありました。

AIで創出できた時間の約4割が「手戻り作業」で消失、若手従業員に最大の業務負荷──Workday調査|EnterpriseZine（エンタープライズジン）

また、@ITの記事によると、OpenAIの共同創業者カルパシー氏は、AIが生成した低品質なコードが、十分なレビューを経ないままシステムに組み込まれていく未来を、「slopacolypse（スロポカリプス）」と呼び、警鐘を鳴らしているそうです。

"アフターAIの世界"、エンジニアは何者になるのか？：AIが開発工程を覆う時代に問われる、役割の再定義 - ＠IT

この記事では、実装の大部分をAIが担うことで「若手がコードを書く機会が減り、AIの出力をレビューできる人材が育たないのではないか」という、まつもとゆきひろ氏の危機感についても触れています。

では、いったい、誰がレビューをするのでしょう？
「テスト作成、整形、リファクタリング」、そういう「繰り返し作業はAIに任せて、人間は判断と設計に集中する」と記事には書かれていますが、レビューのやり方も、当然、現状のままではないでしょう。
ただし、レビューはなくならないと思います。なぜなら、「責任」を持つのは人間だからです。なので、アニメ「PSYCHO-PASS サイコパス」のように、システムに「判断」と「責任」を委ねる世界になれば話は別ですけど。

と、前置きがずいぶん長くなってしまいましたが、ここからが本題、2026年3月時点での「AIによるプログラミング」の実力と、どう付き合うべきか、私の実感をお話しします。

私はもともとIT業界の人間ですし、現在も研究で数値計算などの自作プログラムを頻繁に作成しています。3月に入ってからだけでも10個以上のプログラムを組みましたが、一から自分で作ることは、ほぼありません。
生成AIが、ある程度書いてくれるので、これは、かなり楽ちんです。ある程度、と言っても、もちろん、ちゃんと動きます。
でも、動けば良い、という訳でもないので、一つ一つ確認しながらの作業になります。
一昔前のように、「えっ、全然、言ったこと反映してくれてないじゃん。これって、一般的なやつ（基本アルゴリズム）だよね」ということもなく、きちんと、こちらの考えを、汲み取って（今までの会話の流れやアップした資料の内容を反映して）書いてくれるのですが、だからと言って、結果が信用できるかどうかはまた別の話です。
鵜呑みにはできないので、私は作業ステップごとにプログラムを作らせて、都度、その実行結果をチェックするようにしています（その分、プログラムの数は増えます）。
現在は、GeminiとChatGPTに並行して作らせています。
同じ情報や指示を与えても、結果は、結構、違います。
最初のうちは、ChatGPTの結果がどう見てもおかしく、それを指摘しても、「仕様です」、「なぜ、これが正しいのか」などウダウダと説明してきて、相当、ウザい思いをしました。その点、Geminiは、すぐに不具合箇所を特定し、改善案を出してきて、かなり良い感じでした。（こういう話をすると、必ず「それはChatGPTに課金してないからじゃないの？」という人がいますが、私は、Geminiも、ChatGPTも課金しています。）
そして、Geminiの改善案を、ChatGPTにも教えながら、答えが一致するように、進めます。
面倒でも、ChatGPTを見捨てず、一緒に作業をさせ、自分の予測と、Gemini、ChatGPT、それぞれの結果と比較することで、不具合の発見が早くなりますし、自分の理解も深まります。
それを続けていくと、こちらのやりたいことが十分に伝わったのか、ChatGPTの作るプログラムの精度がぐっと上がり、「さらに、こういう方法で確認できます」と結果の評価方法についても、提案してくるようになってきました。いいぞ。見捨てなくて良かった。
ChatGPTの調子が上がってくると、今度はGeminiがミスを連発するようになってしまいました。計算に必要なデータを読み込んでなかったり、使用すべき値が抜けていたり。そして、なぜか、「次に行きましょう」、「いよいよ次ですね」と先を急がせる。
ひどいのは、実行エラーが出ていたときの原因がファイル名のミスだったので、それを指摘したら、ファイルが存在しなかった場合は、エラーにならないように処理を変えてしまいました。それは、やっちゃダメでしょ。注意したら、「不完全なデータで計算が進むよりは、エラーで止まるべき、という先生のご方針、研究の誠実性の観点から全面的に賛成いたします。」だって。調子いいやつだ。
立場、逆転で、ChatGPTの信頼度が上がって、Geminiは、今一つ信用できなくなりました。
結果が異なった場合は、Geminiの方を疑い、ChatGPTに、Geminiのソースコードを読ませて、デバッグさせてみました。
「入力ファイルが違う」とChatGPT。いや、それは、GeminiとChatGPTの使用ファイルが分かるようにファイル名を変えているからであって、中身は同じです。
「そういうことではないよ」と、結果の具体的な違いを伝えると、なんと、ChatGPTは、自分の言っていた仕様とは違う方法で計算を行っていました。Gemini、疑ってゴメンね。
何が起きているか、なぜこのような結果になるのか、淡々と説明が出てきて、「必要なら、先生の意図どおりの修正版コードをそのまま出します」とのこと。いや、自分でコードを出す前に、「論文にそのまま使えるように仕様をまとめます」って言ってたよね。なんで、その仕様と違うんだよ。
こいつも、やはり、信用できないな。
でも、よく見てみると、この違う結果になった仕様（アルゴリズム）の方が、元の考えより、優れているように思います。
こうした「揺らぎ」が生成AIの特徴であり、「正確性」「再現性」を過度に求めてはいけない、と前回のブログ（卒論指導で見えた生成AIとの付き合い方 ― その正体と活用をめぐる3つの話）で書いたことを自ら再確認する結果となりました。

まとめると、

• 生成AIでのコーディングは、一から書くよりも、かなり楽。
• ChatGPTにしても、Geminiにしても、高度なコードを書けるが、丸投げで「確認なし」はあり得ない。
• どちらが優れている、とは現段階では言えず、どっちもどっち。
• 結果を評価することで、自身の仕様の理解度が深まったり、新たな仕様（手法）を発見できたりする。

といったところです。

※このブログ記事のためにGoogle Gemini（Nano Banana）が描いてくれたイラスト。自分の方をよく描くところがお茶目。