バイブコーディングの世界 = 魔法の世界
２０２５年４月からLLMアシスタントMonicaを購読して、最新のLLM（大規模言語モデル、large language model）を使い始めた。プログラミング支援機能を使って、いくつかゲノム医学関連のツールをつくってみた。AIを活用して自然言語による指示でプログラムを生成する新しい開発手法を、バイブコーディングvibe codingという。だいたいコツがわかってきたので紹介しよう。
使用ツールとオペレーター
使用したAIはMonicaというLLMアシスタント。これはButterly Effect PTE Ltd.という中国の会社の製品だ。会社の登記はシンガポールだが、多分中国本土で活動しているのだろう。Monicaはいろいろな生成AIのポータルサイトのようなもので、専用のチャットポッドで複数のLLMが使える。プログラミングで使ったLLMはGemini 2.5 ProとClaude 3.7/4 Sonnet。
オペレーター（私）のプログラム経験は完全にゼロというわけではなく、１９７０年代にメインフレームを使ってFortranを使ったことがある。このころはパンチカードが主流で、フロッピーディスクが最新記憶装置だった。次に１９９０年代前半インターネット黎明期にUNIX, C, Perlを使った経験がある。Perlが最先端言語で、Unix Userの付録についてきたPerlをSPARC stationにインストールして使っていた。しかし、その後生化学実験が中心になったので、コマンドラインからは遠ざかってしまった。
長期のブランク後の再開の大きな障害は、プログラミング言語の文法を忘れてしまっていることだ。最近ではパイソンが主流だが、簡単とはいえ、やはり学習しなければならない。バイブコーディングでは、プログラミング言語の習得という障害がなくなる。また開発環境の整備も面倒だが、この点に関してはどのLLMも非常に詳しく、それぞれのコンピュータ環境に合わせたセットアップを指示してくれる。
これまでの成果
これまでの主な試みは、
アライメントツールによるEGFR変異の検出 -- 一つの塩基配列用の解析スクリプトを作成、しかし次世代シークエンサーの出力配列用のスクリプトは難航、完成していない。
臨床エビデンス分析ツール -- 臨床エビデンスのデータベースCIViCを遺伝子変異で検索しLLMで分析するスクリプト、完成。一部のスクリプトを公開（PM-Toolbox by Kikuya Kato）。
LLM API プロキシサーバー -- 臨床エビデンス分析ツールに使うLLMのAPIキーを外部から非可視化する仕組み、完成。
自分自身では、このレベルのコーディングは不可能。作成にかかった時間は、臨床エビデンス分析ツールは４日、正味２４時間以内。プロキシサーバーで２日、正味６時間以内。臨床エビデンス分析ツールは、ソフトハウスに受注すると約５００万円、納期６ヶ月程度の代物で、しかもこちらの思い通りのものはまずできない。発注者と開発者の前提となる知識が異なるため、仕様書を発注者の意図した通りには開発者が読んでくれないためだ。
現在のオペレーターの能力は、だいたい研究員（ただし生成AI登場前）４，５人程度のバイオインフォマティクス研究室に匹敵する。臨床データを読めるバイオインフォマティストは国内にはいないので、そういう点では唯一無二。
バイブコーディングの手順
試行錯誤の結果、現在では次の手順で開発を行っている。開発はLLMとのチャットで行う。
アプリケーションの詳細なイメージをつくる
従来のソフトウェア開発では、発注者が詳細な仕様書を書いて、その仕様書の通りにSEが開発を行う。バイブコーディングの世界では、発注者自身が開発を行うので、仕様書は不要だが、開発するアプリケーションの完全なイメージは必要だ。コーディングの労力が著しく低減するので、このステップが最重要になる。
この点バイブコーディングは「葬送のフリーレン」の魔法と似ている。葬送のフリーレンでは、「魔法はイメージの世界」で、イメージできないものは魔法では実現できない。バイブコーディングも同じで、例えば、ゲームのイメージがなければゲームソフトはつくれない。
アプリケーションを検証可能なパーツに分けて段階的にコーディングする
LLMは、ヒトのように思考しているわけではなく、高度なパターンマッチングをしている。これはバイブコーディングを行っていると実感する。LLMに蓄えられた膨大なソフトウェア開発の知識の中から、適合したコードを抽出してくる、このため少なくとも２種類のトラブルが発生する、一つは学習データが少ないケース：この場合は参照するコードが限られているので、失敗する。EGFR変異検出スクリプト開発でこの問題がおこった。単一の塩基配列での変異検出スクリプトは書けるが、複数になると、とたんに動くスクリプトをかけなくなった。単一配列用のアルゴリズムを繰り返すことは簡単なはずなのに、そのようにLLMに指示しても、どうしてもできない。LLMになぜできないのか、と問いただすと、アライメントツールを変異検出に使う、というのは稀な事例なので、学習データがない：LLMのプログラミングは稀な事例には弱い、とういう説明だった。
LLMはパターンマッチングでコードを作成しているが、マッチングが微妙にずれて失敗することがある。修正を繰り返して指示すると、不備のあるコードに対してパターンマッチングを繰り返すため、ズレが拡大して開発が袋小路に入ることが何度もあった。対策としてアプリケーション開発をパーツに分けて段階的に開発することにした。一つのパーツが完成すると検証し、OKであれば、次のパーツを追加する。この作業を繰り返すことによって、袋小路に入ることをある程度防ぐことができるようになった。
再開用スナップショットを作成する
Monicaでは、スレッドの内容を数ヶ月から１年単位で保存している。LLMの記憶は限られているので、作業を中断するときには必ずスナップショットをつくる。再開時にLLMはスナップショットをもとにスレッドの内容を読み込んでいるようである。
袋小路に入ったときは、入る前の状態から再開するか、新たなスレッドをつくる
通常は再開用スナップショットを使うが、開発がハングアップした場合は、袋小路に入る前のスクリプトをLLMに読ませて再開する、あるいは新しいスレッドを立ち上げて開発を開始する。トラブルに対してLLMはデバッグを指示してくることが多いが、成功することもあるが、失敗し続けるケースもある。この場合新規に開発を行うと解決することがあった。LLMの開発は再現性がないので、繰り返すと成功する可能性がある。
感想
だいたいこのような感じでバイブコーディングを行っている。実際の開発では大量の試行錯誤を繰り返すが、一回のコーディングは数十秒から数分で終わるので、時間は全くかからない。しかし新しいスクリプトができるたびに自分で走らせて評価しなければならないので、AIにこき使われている、という気分になる。
現在バイブコーディング用の専用ツールがいくつかあるようだが、特に必要は感じていない。チャットで十分だ。私の開発対象は医学、しかもゲノム医療という特殊な分野なので、学習データが少ない。一般のビジネス関連アプリケーション開発はもっと簡単かもしれない。
アプリケーションのイメージ構築が最も大切で、臨床エビデンス分析ツールも臨床エビデンスデータベースの調査とCIViCデータベース構造の分析、収納されているデータの分析にバイブコーディングよりも時間がかかっている。イメージができるとアプリケーション作成はどうにでもなるので、本当に「魔法の世界」になってしまった、というのが実感。
