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 と付き合っていこうと思います。