はじめに：20年前のバグが教えてくれたこと
私は2025年の秋に、プログラミングのほとんどをAIに任せる「AIコーディング」を試し始め、2026年の夏にはすっかり移行しました。プログラミングを始めてから35年以上、ずっと楽しんで書いてきた人間としては、大きな方向転換です。
私は情報通信系の教員として講義を持ち、学生の研究を指導しています。この記事は、プログラマーとしての実感と、大学教員としての立場の両方から書いています。
きっかけは、20年前に自分が書いた物理エンジンでした。2025年11月、AIが、回転行列をクォータニオンに変換する関数の符号の誤りを見つけて直してくれました。ある条件のときだけ回転が逆向きになるという、2005年から残っていた1行のバグです。研究室の学生が摩擦モデルを実装する中で気づいたもので、本来なら20年前に直っているべきバグでした。これをきっかけに、AIコーディングを本格的に試し始めました。
さらに大きかったのは、スライダー関節の可動域の制限が効かないという、もう一つのバグです。原因は一つではありませんでした。可動域の拘束力を求める反復計算が、更新前の古い速度の値を参照していたこと。スライダー関節では、位置のずれを補正する処理が中身のないまま残っていたこと。さらに、ばねもダンパも0の、実質的に働かないモーターまで拘束として計算に加えていたこと。こうした問題が絡み合ったバグを、AIはあっさり直してしまいました。そのとき「これは移行すべきだ」とはっきり思い、そこから半年ほどかけて、開発のやり方をAIコーディングへ移しました。
この記事では、試し始めてからのおよそ1年で分かったことと、いまコンピュータサイエンス（CS）を学んでいる学生のみなさんに伝えたいことを書きます。
試して分かった、大切な2つのこと
使い込むうちに、うまくいくかどうかを分けるポイントが2つ見えてきました。
1つ目は、AIが自分でループを回せる環境を作ることです。 AIがコードを書き、テストを実行し、その結果を自分で評価して、また修正する。このサイクルを人間が介在しなくても回せるようにしておくと、AIの力が一気に発揮されます。逆に、毎回人間が実行して結果を貼り付けるような環境では、速度も精度も出ません。といっても、テストや判定の仕組みを私が作るわけではありません。「テストを用意し、結果を判定できるように開発を進めること」という方針を伝え、その開発プロセス自体をAIに設計させます。人間の役割は、そうした方針を示すことと、提案されたプロセスが妥当かを確かめることです。
2つ目は、方針や手法が意図通りに伝わっているかを確認することです。 AIはこちらの言葉をそれらしく解釈して、それらしく動くものを作ります。しかし、こちらが考えていた方針とは別のやり方で「動いて」しまうことがあります。だから、「どういう方針で進めるつもりか」を説明させ、ずれがあればその場で直します。タイミングは作業に入る前に限りません。途中の報告で引っかかったとき、テスト結果に違和感があったときなど、どんなきっかけでも介入すべきです。方針のずれを正すと、それまで行き詰まっていた問題が一気に解決することがよくあります。
コードは読まない。でも、中身は確認する
AIとのやりとりは、学生の研究指導に似た面があります。研究室で学生がプログラムを書いているとき、教員は一行ずつコードを読むわけではありません。「どういうアルゴリズムで解いているのか」「その数式で合っているのか」「閾値はどう決めたのか」「次は何から手をつけるのか」を聞いて、方向を確かめます。教員として長くやってきたことなので、AI相手でも違和感なく進められています。ただ、学生は指導を通じて成長し、やがて自分で研究を進めるようになりますが、AIは指導しても成長しません。そこは大きな違いです。
実際、私はAIが書いたコードを全く読んでいません。その代わりに、次のようなことはよく確認します。
- アルゴリズムを説明させ、それに対して指示を出す
- 使っている数式が意図したものかを確認する
- どんな変数、データ構造、定数を使っているかを確認する。特に、アドホックな定数や閾値がどこにどう入っているかを確かめる
- 作業の手順や段取りを指示する
コードという「実装」ではなく、設計と判断のレベルで見ているわけです。これはまさに、シニアプログラマーやプロジェクトマネージャーがやってきた仕事に近いものだと思います。
開発速度は10倍から100倍に
体感では、開発速度は10倍から100倍になりました。何日もかかると思っていた機能が数時間で動き、後回しにしていたアイデアを次々と試せるようになっています。
もちろんタダではありません。速度に応じてAIの使用料はかかります。ただ、私自身が使っているのは x5 程度のプランで、これで十分です。それ以上にしても、AIに方針を伝え、結果を確認する私自身の管理力と時間のほうが足りなくなるからです。速度の上限を決めているのは、AI自体の処理時間もありますが、それ以上に、人間が把握・管理できるタスクの数と複雑さの限界です。
学生のみなさんへ（1）：ある程度の規模のものを作って、自分で使ってみよう
CSの学生のみなさんに、まず伝えたいのはこれです。AIコーディングを、ぜひ試してみてください。
それも、課題の小さなプログラムや、数十行のスクリプトで終わらせないでほしいのです。ある程度の規模がある開発で、自分が実際に使うものを作ってみてください。
理由は2つあります。小さなプログラムなら、AIは一発でそれらしいものを出してきます。そこからは「AIはすごい」か「AIは当てにならない」という感想しか得られません。規模が大きくなって初めて、方針のずれ、テストの重要性、段取りの組み方といった、本当に必要なスキルが見えてきます。
もう1つは、自分で使うことで「動く」と「使える」の違いが分かることです。毎日使えば、不便なところ、想定外の入力、遅いところが必ず出てきます。それをAIにどう伝えて直させるか。そこに、これからのプログラマーに求められる力が詰まっています。
一例として、最近私が作ったものに aigw があります。スマホのブラウザで動くWebアプリ（PWA）から、チャットのような画面でターミナルや Claude Code などのAIエージェントを操作する仕組みです。外出先からでもAIに指示を出し、進み具合を確認できるようにしたくて作りました。
小さなツールに見えますが、中身はそれなりの規模です。パスキー（WebAuthn）で管理者権限を時限式に開閉するデーモン、ユーザーごとのバックエンドを systemd で必要なときだけ起動する仕組み、モバイル向けのUIなどが組み合わさっています。最初に作った方式を、安全性の観点から設計ごと作り直した部分もあります。添付ファイルが多いと接続が集中してサービスが落ちる、といった実際に動かして初めて分かる問題にも出会いました。こうした判断や問題への対処こそが、規模のある開発を自分で使うことで得られる経験です。
ただし、AIに丸投げするだけでは学びは残りません。Anthropicが2026年に発表した実験でも、使い方次第で学習効果に大きな差が出ることが示されています。アルゴリズムを説明させ、閾値や数式を確かめるという関わり方は、自分の学びを守る使い方でもあると思います。
学生のみなさんへ（2）：まだ誰も答えを持っていない問題
もう1つ、正直に伝えておきたいことがあります。
かつて新入社員は、まずコーディングを任されました。たくさんのコードを書き、先輩にレビューされ、失敗しながら、少しずつ設計や見積もり、段取りの感覚を身につけていきました。その積み重ねの先に、シニアプログラマーやプロジェクトマネージャーがいたわけです。
ところが今、その「新入社員がやっていたコーディング」をAIがやるようになりました。では、これからの若い人は、どうやってシニアやPMのスキルを身につければよいのか。その方法は、まだ確立していません。 私も、正解は知りません。直感から模索して進めています。
大学のカリキュラムも、当然この変化には追いついていません。授業で習うことが、AIの時代に合っていないように感じる場面もあるでしょう。
それでも、大学での学びが不要になるという保証は、どこにもありません。むしろ、役立つ可能性は高いと私は考えています。AIに方針を伝え、数式やアルゴリズム、データ構造の説明を聞き、それが妥当かを判断する。そのとき頼りになるのは、データ構造、アルゴリズム、計算量、数値計算、ソフトウェア工学といった基礎です。その習得にはAIを使わずにプログラミングや数学、実験の課題に取り組む必要があります。AIの説明が正しいかどうかを見抜けなければ、AIを指導することはできません。
おわりに
35年以上プログラミングを続けてきた私にとっても、この1年は驚きの連続でした。そして、いちばん大きな発見は、プログラミングの楽しさが消えなかったことです。手を動かす場所が変わっただけで、何を作るか、どう作るかを考える面白さは、むしろ増えています。
これからのプログラマーがどう育っていくのか、答えはまだありません。だからこそ、いま学生であるみなさんが、AIと一緒に本気で何かを作り、その経験から学んでいくことに大きな意味があると思います。基礎をしっかり学びながら、ぜひ新しいやり方にも飛び込んでみてください。
