バイブコーディング実験・エピソード1

1年前、私たちはこんな冗談を言っていました。「真のAGIは、LLMがCSSを理解した日に達成される」と。

Miloの認識とは裏腹に、Bot Resourcesにはフロントエンド開発者がいません。正直なところ、必要としたこともありません。私たちが手がけるのはクライアント向けのエージェントシステムであり、仕事の本質はアーキテクチャ、オーケストレーション、インテグレーションです。PoCやPOVでは、機能的なUXがあれば十分で、美しいUIは不要です。ChainlitなどのライブラリでUIは事足ります。

この2年間、UIの部分はLLMに任せてきました。特にCSS。その出来栄えは...お世辞にも良いとは言えません。本職のフロントエンド開発者が私たちのCSSファイルを見たら、おそらく体調を崩すでしょう。

ウェブサイトにもその実態が表れていました。コンテンツ生成の実験台として使っていたのです。エージェントを使って自社の事業について書けるのか？答えはノー。私たちのコンテンツは破壊的すぎるのです。その大半がLLMの学習データと矛盾しています。

エージェントとは何か？エージェントシステムとは何か？なぜデータサイエンティストがその構築に最適とは限らないのか？なぜファインチューニングは大抵悪手なのか？現実的なユースケースは何か？これらの問いに対する正確な答えは、学習データセットには存在しません。

旧ウェブサイトのUIはどうだったかって？GPT-4 Turboの作品とだけ申し上げておきましょう。美しく、洗練されて、よく考え抜かれた...かどうかは別として。

しかし、それは1年以上前の話です。大半の業界では「昨日」に等しい期間ですが、私たちの業界では2世紀前と言っても過言ではありません。この間に、単純なバグでGoogle＋Stack Overflowを置き換える程度のチャットボットから、半自律的にコードベースを編集して機能を実装できるエージェントへと進化しました。リビルドの時です。

実験

私たちが日常的に使うコーディングエージェントは、IDEやコマンドラインツールに統合されています。バックエンド開発には最適ですが、フロントエンドでは使い勝手が良くありません。

フロントエンド開発はマトリョーシカのようなものです。コンポーネントの中にコンポーネント、その中にさらにコンポーネント。何層にも重なっています。そこに各種サービスやインターフェースの内部ロジックが加わると、特定のボタンの挙動を理解するために数十ものファイルを読み解く必要がある巨大なコードベースが出来上がります。

さらに「見た目」の問題があります。コーディングエージェントにウェブサイトを確認させるには、スクリーンショットを撮ってチャットに貼り付ける必要があります。理想的とは程遠い。そしてどの要素を修正すべきか、具体的に伝えなければなりません。一番確実な方法は？DOM要素をインスペクトして目的のものを見つけ、「<app-user-edit-button-admin-page>というボタンが動かない」とエージェントに伝えること。遅くて、面倒で、苦痛です。

この課題に特化したツールを探しました。Lovableを見つけ、試してみました。UX/UIの議論に使えるか？使えます。ダッシュボードのモック作成は？できます。本格的なものを作れるか？作れます。プレビュー上で右クリックしてボタンの色を変更するようエージェントに指示できるか？できます！完璧か？いいえ。しかし、第一歩としては十分です。

新たな実験の時が来ました。問いはこうです。クライアント案件に使うべきか、自社で試すべきか？前者はリスクが高すぎる。後者は...可能性がありますが、何に使うか？そこでウェブサイトのコンテンツが2024年7月から更新されていないことに気づきました。あまりにも多くのことが変わっていました。新しいウェブサイトが必要です。

野望

私を知っている方ならご存知の通り、私は地に足のついた、分別ある人間で、大きな野心とは無縁です。特に小さな社内プロジェクトを過度に壮大にするような真似は絶対にしません。参考までに申し上げると、マーケティングデータに携わっていた頃、アドサーバーのアトリビューションロジックを丸ごと作り直し、しかもより優れたものにする...などというシステムを構築しようと決断したことなど、一度もありません。

というわけで、小さな自社ウェブサイトの仕様は至って堅実です。信じてください。何も大げさなものはありません。少数のお客様しかいない小さな会社です。大掛かりなツールを構築する必要はないのです。仕様をまとめてみましょう。

• CMSが嫌いです。CMSは最悪です。代わりに、私のCMSはLovableにします。新しい時代の幕開けです。ウェブサイト全体をエージェントシステムに完全委任しましょう。何も問題は起きないはずです。ですよね？ですよね？
• コンテンツが充実した本格的なウェブサイトが欲しい。たとえそのコンテンツを書く時間がなく、誰も読まないとしても。やりましょう。
• 多言語対応のウェブサイトが欲しい。フランスの会社ですが、なぜか海外での売上が大半を占めているので、英語とフランス語は必須です。あ、来年社員の一人が日本に行くことになっています。日本語版も作りましょう。
• ブログセクションが欲しい。もちろん多言語対応で。新しいブログの仕組みはこうです。コンテンツは自分たちで書き、イラスト選定と見栄えの調整はLovableに任せます。翻訳は課題になりますが、そのうち何か作りましょう。
• ブログ記事にコメントが投稿できるといいですね。コメントは良いものです。私のエゴを満たしてくれます。もっとコンテンツを書こうという気にさせてくれるかもしれません。しかしそのためにはバックエンドとモデレーションが必要です。モデレーションは自動化できるはず。試したことはありませんが、やってみましょう。心配は無用です。エージェントがモデレーションしていると知ったインターネットの一般閲覧者が、プロンプトインジェクションを試みるなんてことは、まさかありえませんよね。
• 見込み客向けのバックエンドが欲しい。大したものではありません。クオリフィケーションエージェントとユースケースを分析できるプリセールスエンジニアを備えた、ちょっとしたエージェントシステムがあれば十分です。
• クライアント向けのバックエンドが欲しい。基本的には見込み客向けと同じ機能に追加機能を加えたものです。契約書・請求書管理。PMエージェントもあると良いですね。タイムベースの請求には勤怠管理、プロジェクトベースの請求にはAPI利用料と成果物の管理も追加しましょう。
• 営業用のCRMが欲しい。CMSが嫌いですが、CRMも嫌いです。両方とも置き換えましょう。
• 社員向けのバックエンドが欲しい。現在の社員数は4名。休暇スケジュール、有給休暇、労働契約にアクセスできるエージェントを用意することは極めて重要です。
• もちろん、これらすべてが完全にセキュアで、保守性が高く、LLMベンダーロックインなし、SSO完備であること。

お分かりいただけたと思いますが、私の野望はどこまでも堅実で地に足がついています。

実際に起きたこと（今のところ）

一つだけ制約を設けました。コードには一切触れない。開発中も一切。完全なバイブコーディングモード。指示を出して、結果を受け取る。フロントエンドは真のバイブコーディング。コードアーキテクチャの指定なしに、大まかな指示だけを出す。バックエンドでは、病的なまでに野心的に。Lovableが対応可能と謳っていても使わない。純粋なコーディングエージェントのワークフローで。関心の分離を徹底したアーキテクチャの厳密な指示のもとに。時間があれば、その方法と理由についてブログ記事を書きます。

LovableがReact/Viteのコードを生成し、GitHubと同期、変更ごとに1コミット。GitHub Actions経由でOVHにデプロイ。認証も実装済み。SPAでEntraとGoogleを使い、バックエンドへはWebSocket経由で接続、最初のメッセージにアクセストークンを載せます。この部分は難しかったですが、それ以外は驚くほどスムーズでした。

コンテンツはマークダウンで書き、エージェントに渡します。「これをブログに追加して、見栄えよくして。」プレビューが表示され、必要に応じて調整。

国際化が必要になった時は、フランス語版と日本語版を作るよう指示しました。技術的な実装は2回目で成功。1回目はいくつかの要素を漏らしましたが、すぐにフォローアップして修正。3言語対応のサイトが稼働しています。

翻訳そのものは汎用的で、当社固有のコンテキストが不足しています。それは当然のことです。良質な翻訳にはドメイン知識と人間の監修が必要です。しかし、仕組み自体は機能しています。

出来上がったサイトは、自分で作れたどんなものよりも良い仕上がりです。数週間かかるはずの作業が、数時間で完了しました。