バイブコーディングの限界──壊れる日は突然やってくる｜内科医のAI開発記

前回（#32）では、有料の音声認識サービスを自作で置き換えた話を書いた。今回は、もう少し正直な話を書く。

ツールが壊れた。

朝、いつものように診察室でPCを開いたら、昨日まで動いていた紹介状ツールが動かない。ボタンを押しても反応しない。コンソールを開くとエラーが赤く並んでいる。

昨夜、別のツールを直していたときに、共通部分を触ったらしい。らしい、というのは、自分でも何を変えたか正確に把握できていないからだ。

バイブコーディングの最大の弱点

コードを「書いて」いないから、何がどう繋がっているかの全体像が頭に入っていない。

AIに「ここを直して」と言う。AIが直す。動く。次に行く。この繰り返しで35個のツールが動いている。

でも「ここを直して」のひとつが、別の場所を壊すことがある。いわゆるデグレーション。

エンジニアなら当たり前に知っている概念だが、僕はこれを体で覚えた。

もっと困るのは、壊れたことに気づかないケースだ。

あるツールの表示レイアウトが崩れていたことがあった。ある日、印刷プレビューを開いて「あれ、前と違うな」と気づいて調べたら、共通CSSの変更が波及していた。

いつから崩れていたかはわからない。数日かもしれないし、もっとかもしれない。

テストを書いていないから、壊れたことを検知する仕組みがない。気づくのは、自分が使ったときだけだ。

「テストを書けばいいじゃないか」と言われると思う。

その通りだ。

ただ、バイブコーディングの世界では、テストを書くのもAIに頼むことになる。テスト自体が正しいかどうかを、自分では判断しきれない。

テストが通っているのに壊れている、ということが起きうる。実際に起きた。

ツールが増えるたびに、共通部分が太くなっていく。最初は1つのHTMLファイルで完結していたものが、共通モジュールを参照し、プロキシサーバーを経由し、設定ファイルを読み込む構成になる。

これは自然な進化だが、非エンジニアにとっては「いつの間にか、全体が見えなくなる」ということでもある。

AIに「全体の構成を説明して」と聞けば説明してくれる。でもその説明を鵜呑みにしていいのか、自分では検証できない。

ひとつ目は、壊れたらすぐ直すこと。朝の診療前に全ツールを一通り触って、動作確認する習慣をつけた。5分もかからない。でもこの5分がなければ、壊れたまま使い続けるリスクがある。

ふたつ目は、触る範囲を限定すること。「Aを直すついでにBも直しておいて」は事故の元だと学んだ。ひとつ直したら、他は触らない。

みっつ目は、引き返せる状態を保つこと。変更前のファイルをコピーしておく。動いている状態を壊さないように、別ファイルで試す。地味だが、これで何度も救われた。

先週も壊れた。来週も壊れると思う。

バイブコーディングは万能ではない。プログラミングを知らない人間がAIに頼ってソフトウェアを作るという行為には、構造的な限界がある。

でも、やめようとは思わない。

壊れるたびに、ツールの構造への理解が少しだけ深くなる。デグレを経験するたびに、「変更の影響範囲」という概念が体に入ってくる。

それはプログラミングの勉強とは違う。でも、ソフトウェアとの付き合い方を学んでいる、という感覚はある。

たぶん、エンジニアから見たら笑われる話だと思う。

テストも書かず、CIも組まず、手動で動作確認して「壊れたら直す」と言っている。それはソフトウェア開発じゃないだろう、と。

でも、35個のツールが毎日の診療で動いているのは事実だ。壊れても直る。直せる。それは1年前にはできなかったことだ。

バイブコーディングの限界を知ったうえで、続ける。壊れることを前提に、壊れても大丈夫な運用を組む。

それが、今の僕のやり方だ。

ひろつ内科クリニック（福岡市博多区）
開業1年3ヶ月 / ツール数35個 / AI: AWS Bedrock Claude ZDR + ローカルWhisper

この記事は hirotsu.clinic/blog/ にも掲載しています。