みなさん、こんにちは！
今回はちょっと技術の話から離れて、AI が当たり前になってきた今、システムエンジニアとして何を大事にしたいか、を自分の経験をもとに書いてみます。
先に結論を言ってしまうと、いちばん大事なのは「品質」です。
2年前は、AI にコードを書かせていませんでした
実は 2 年前の私は、AI にコードを書かせる、いわゆる vibe coding をほとんど使っていませんでした。コードはほぼ全部、自分の手で書いていました。
だって、生成されたコードを確認するのって、けっこう時間がかかるんですよね。しかも AI の書いたコードが増えるほど、プロジェクトの品質を自分で把握できなくなりそうで、それがどうしても怖かったんです。
「確認にこんなに時間がかかるなら、自分で書いたほうが早いし安心じゃない？」
当時は、わりと本気でそう思っていました。
きっかけは、どうしても再現しないエラーでした
そんな考えが変わったのは、ある業務システムのプロジェクトでのことです。
そのシステムが使われるのは、主に朝 8 時から夕方 5 時まで。Java の Spring フレームワークで作られていて、Redis にはコネクションプールを使って接続していました。
毎朝、最初の 1 回だけエラーになる
起きていたのは、しばらく使われなかったあとの最初のアクセスだけ、接続エラーになるという現象です。
厄介なのは、2 回目のアクセスでは何事もなかったように動いてしまうこと。「よし、調べよう」ともう一度操作すると、もう再現しないんです。こういうの、本当に困りますよね。
けっこう長いあいだ調べたのですが、原因はさっぱりわかりませんでした。
ダメもとで AI に読ませてみたら
もう打つ手がなかったので、ダメもとで AI にプロジェクトのコードをまるごと読んでもらいました。
そしたら、あっさり原因を見つけてくれたんです。これには正直びっくりしました。
細かい設定や対応の中身はもう覚えていないので、ざっくりですが、原因はこんな流れでした。
夜のあいだ、Redis へのアクセスがまったくない
↓
プールのコネクションが、全部切れてしまう
↓
翌朝の最初のリクエストが、切れたコネクションで応答を待ち続ける
↓
その間に、フロントの HTTP タイムアウトが先に来てしまう → エラー
↓
裏でコネクションが張り直されるので、2 回目は普通に動く → 再現しない
なるほど、これは再現しないわけです。
対応としては、まずフロントの HTTP タイムアウトを延ばして、エラーが出ないようにしました。最終的には、使われていない時間帯もバッチで定期的に Redis にアクセスして、コネクションが切れないようにしています。
AI が見つけられた理由
あとでわかったのですが、Spring フレームワークの GitHub リポジトリに、何年も前に同じような症状の issue が上がっていたんです。AI はそれを知っていたから、すぐにたどり着けたんですね。
人間がそこにたどり着くには、まず「何で検索すればいいか」に気づかないといけません。でも AI は、コードと膨大な過去の情報を一気に結びつけてくれます。
「探して、結びつける力は、AI のほうが人間よりずっと上だな」
このとき、素直にそう思いました。そこから少しずつ、AI をプロジェクトに参加させるようになりました。
今は、AI にかなり頼っています
今では、AI をかなり使っています。設計の相談も、実装も、テストの作成も、いろいろな場面で手伝ってもらっています。
ただ、2 年前に感じていた「品質を把握できなくなるかも」という不安が、なくなったわけではありません。不安が消えたというより、品質の守り方が変わってきた、という感じです。
AI 時代のシステムエンジニアが頑張りたい 2 つのこと
AI がどんどんコードを書くようになった今、システムエンジニアが頑張るべきところは 2 つあると思っています。
1. 品質を守る仕組みをつくる
まずは、品質を守るための仕組みです。
たとえば、テストコードは AI に書いてもらいます。でも、そのテストコードが本当に正しいかは、必ず自分で確認します。テストそのものが間違っていたら、「テストが通った！」にはなんの意味もないですからね。
フロントエンドなら、ブラウザを操作できる Playwright MCP を使って、人がブラウザで触るのと同じ流れを AI に試してもらいます。そのときに、「ちゃんと動いた」という証拠も残しておきます。
AI に書かせて、AI にテストさせて、その結果を人が確認できる形で残す。ここまでやって、やっと「品質を守れている」と言えるんじゃないかなと思っています。
2. 技術の原理を学び続ける
もう一つは、AI 時代でも、技術の原理をちゃんと学び続けることです。
さっきの Redis の件も、原因を見つけたのは AI でした。でも、「それが本当に原因なのか」「どう直すのがいいのか」を判断するには、コネクションプールやタイムアウトの仕組みを、自分がわかっている必要があります。
AI の答えを評価できなければ、間違った答えもそのまま採用してしまいます。なので、いろいろな技術の基本的な知識や、最適化の考え方なんかは、これからもちゃんと自分の頭に入れておきたいです。
品質、品質、品質
大事なことなので、3 回言います。
品質、品質、品質！
AI がプロジェクトに参加するのは、もう当たり前になってきました。でもそれは、「プロジェクトの品質を保証できる」ことが前提です。どんなに速く書けても、品質を把握できなくなったら意味がありません。
2 年前の私は、品質が心配で AI を使いませんでした。今の私は、品質を守る仕組みをつくったうえで、AI を使っています。そう考えると、品質へのこだわりは 2 年前から何も変わっていないのかもしれません。
AI に任せることが増えても、品質への責任だけは手放さない。これからも、そこだけは忘れずに AI と付き合っていこうと思います。