夏休みの自由研究として、ちょっとしたお絵かきアプリを作りました(大遅刻)。コンセプトは『欲しいツールはその場で生成』です。これは、現状のAIコーディングの課題をどう乗り越えるのか、どうすれば「バイブコーディング」の心意気を真の意味で達成できるのかを考える実験でもあります。

何を作ったのか

このツールは、SVGベースのベクターグラフィックお絵かきウェブアプリです。アプリを開くと、真ん中にキャンバスとサンプル図形が表示され、左側に各種のツールのボタンが並んでいます。このアプリでは、ユーザーは既存の機能から使いたいものを選ぶのではなく、ユーザーがいま使いたい機能をユーザー自身がその場で生成します。

たとえば、ユーザーが「クリックしたところにランダムな色の星を描くツール」が欲しいとしましょう。まずツール一覧の一番下にある「+」ボタンを押します。このボタンを押すとダイアログが開くので、テキストボックスに自分が使いたいツールについての説明を入力し「ツールを生成」のボタンを押します。すると、大規模言語モデル(LLM)がその説明に沿ったコードを生成し、ツールを作成します。あとはキャンバスをクリックすれば、クリックした位置に様々な色で☆が描画されます。

ユーザーのアイデア次第で、さまざまなツールを生成することができます。

クリックした図形の色を変えるツール
ドラッグすると直線を引くツール
クリックした図形を複製するツール
クリックした図形を左右に反転させるツール
図形の頂点を移動して変形させるツール

などなど。生成されたツールは他のツールと同様に画面左に並ぶので、選択すればいつでも使えるようになります。自分にとって使いやすい道具箱を自分で育てていくような感覚もあります。これは 生成的UI(Generative UI) の一種といえるかもしれません。

実際のアプリ

アプリは以下のページで実際に試すことができます¹。（なお、Anthoropic APIのコストはもちろん私の個人的なお財布から出ているので、遠慮しながら使ってください。ツール生成が動かない場合は予算が空になってるかもしれませんので、私に大金を送っていただければ復旧します）

アプリにはあらかじめいくつかのツールをサンプルとして表示するようになっているので、そちらを試してもいいでしょう。図形の色を変えるツール、図形を移動するツール、ドラッグで線を描くツールなどをあらかじめ登録してあります。

こうした仕組みのアプリには、次のような利点がありそうです。

高機能なアプリは便利ですが、そういったアプリは須らく習得が大変です。その点このアプリでは、ツールは自分が指示して生成したものです。使いかたは自分自身が把握していますし、ツールの習得というプロセス自体がほとんどありません
自分が使わない機能というものはUI上にほとんどなく、すっきりします。多くのお絵かきツールには画面上にぎっしりとボタンやコントールが詰まっていて選ぶのに迷いますが、ユーザーが使う機能は実はその一部だけです。このツールではUI上に並んでいるのはユーザーが実際に必要とした機能だけです
「ランダムに色を変える」というような比較的複雑な機能でも、欲しいと思ったらすぐに生成してツールとして使うことができます。従来のお絵かきアプリでは、別の誰かが作成したプラグインを探してインストールしたり、自分でスクリプトを書いたりしなくてはなりません。あるいは「色を選択」→「クリック」という操作を手作業で繰り返すしかないかもしれません
画像生成AIを使って画像から画像を生成するのは柔軟で高機能ですが、1枚の画像を生成するのに数十秒から数分かかったりします。これは細かく調整して見栄えを確かめるにはとても不便です。それに対してこのようなアプリでは、たとえば図形の位置を調整したければマウスでドラッグするだけで、すぐに見栄えを確かめることができます。高品質な作品を作るには、そうした細かい調整が不可欠です

アプリの仕組み

このウェブアプリのサーバー側の機能はClaudeを呼び出す部分だけで、あとはブラウザで動くシングルページアプリケーションになっています。

内部の実装の仕組みをざっくり説明すると、このアプリの「ツール」とは、要するにアプリのプラグインだと思えばいいでしょう。ユーザーが欲しいツールの説明をテキストボックスに入力すると、その説明をLLM(中身はclaude-opus-4)へと送信し、LLMはそのJavaScriptソースコードを動的に生成します。そしてそのコードをその場でブラウザに読み込んで実行しているというわけです。ツールは、プラグインインターフェイスを通じてのみドキュメントやアプリに干渉できます。

なお、生成したコードはendo/sesのサンドボックス上で実行しています。SESは、JavaScriptのグローバルオブジェクトをロックダウンして変更不可能にするとともに、Compartmentという独立した環境を用意して、そこで任意のJavaScriptコードを隔離して安全に実行できるものです。

²

人間が頑張って書くアプリ基盤部分と、LLMに勝手に生成させるプラグイン部分が、完全に分離されているわけですね。また、各プラグインもお互いに完全に独立しており、何も共有しません。プラグインの状態も完全にCompartmentに閉じ込められています。本体部分の機能は、Redo/Undoやドキュメントのインポート/エクスポートなど、ごく限られたものだけです。

現状のAIコーディングの課題

現時点の大規模言語モデル(LLM)では、大規模なソースコードを継続的に改善・機能拡張していくというのはかなり難しいという実感があります。機能追加を命じればLLMはモリモリ元気にコードを生成するのですが、重複したコードも遠慮なく生成します。このため、コード量は際限なく膨らんでいき、あちこちに不穏なコードが散らかっていきます。そしてあるとき、LLMは命じられた機能の実装に失敗し、人間がいざソースコードを覗いてみたら、理解不能、制御不能の混沌になっていた、というのはよくある話です。そうならないためには、人間が監視を怠らず、常にコードを整理し続けなくてはなりません。また、AIにコーディングをさせるとしても、人間の側にも十分なプログラミングの知識が必要になります。

それに対して、今回のアプリのアーキテクチャでは、以下のような利点がありそうです。

生成したツールのコードは、人間が一切確認しなくてもOKです。何が起きているのかイメージしやすいように画面上に生成中のコードを表示していますが、ユーザーは実際にはこのコードを読む必要はありません。ユーザーにはプログラミングの知識が不要で、自然言語で指示するだけで問題なくコードを生成して使うことができます
というのも、各ツールのコードは完全に独立しているため、どんなにツールを追加してもコードが互いに絡み合うことはありません。コード全体が複雑にならないように人間が監視しなくて大丈夫です
生成されたコードの可読性も関係ありません。そのコードを人間が編集したり修正することはありません
このため、プログラミングの知識がなくても、エンドユーザーがコード生成を十分に扱えます
要らないツールのコードは簡単に消せます。適当にツールを消しても、他のツールに影響することはありません
LLMが把握するべきコンテキストは、このアプリが規定するプラグインインターフェイスのみです。このため、コードベース全体をコンテキストに突っ込む必要がありません
指示したとおりの機能のツールを安定して生成できます。各ツールは単機能でコードが小さいためと、LLMは既存のコードを編集するのは苦手ですが、まっさらな状態から自由にコードを生成させると成功しやすいからです
生成したツールがバグで動かなくても、人間がそのコードを読んで修正する必要はありません。プロンプトを調整したりして再度生成させれば十分修正できます
LLMが生成したコードはサンドボックス上で動作するので、万が一LLMがおかしなコードを出力しても安全です。編集中の絵を他人に送信してしまう、というような流出事故も起きません。³
ツールができるのは基本的にプラグインインターフェイスを通じて現在の図形を編集することだけなので、アプリ全体を巻き込んでクラッシュさせることはありません
もし編集がうまくいかなくても、「取り消し」で確実に戻せます。ツールのバグで現在のドキュメントが復旧できなくなることはありません

もちろん、以下のような難点もありそうです。

プラグインインターフェイスを設計するのが難しいです（プラグイン機構をもつアプリに共通の問題かもしれませんが）。十分な機能を提供しないと、LLMが指示したとおりのツールを生成できません
LLMに扱わせるには難しすぎる機能もけっこうあります。たとえばpath要素のd属性は異様に複雑な仕様なのですが、そのせいでd属性の値を正しく扱うコードを生成することができませんでした。仕方がないので、d属性の値を正規化するライブラリの関数をプラグイン側に露出し、ツール側では簡単なコードでd属性の値を扱えるようにしています
UIを自由にカスタマイズできるようなプラグインは、難しくてまだ実現できるようになっていません。既存のUIとの統合が難しいですし、ツール同士の機能もバッティングしやすいです
ツールで互いにコードを共有しないため、全体のコード量は増えそうです
いろんなツールを指示して生成できるといっても、実際にどんなツールが実現可能なのかはユーザーには把握しにくいでしょう。たとえば、このツールはSVGベースなので「ドラッグすると水彩画風に色が混ざるようなペイントをするツール」は実現できません。SVGやベクターグラフィックスの原理を知っている(またはPhotoshopとIllustratorの違いを理解している)必要があります

おわりに

「バイブコーディング」の語はLLMを利用したコーディング全般を指して使われることもありますが、本来のバイブコーディングはすべてをLLMに委ねるようなコーディングスタイルだそうです。すべてをLLMに委ねる開発は現実には難しいですが、今回試したアーキテクチャでは、ツール(プラグイン)の実装に関しては、本来の意味でバイブコーディングの精神を実践することができるのではないかと思います。

このツールの名前は、Mogana としました。「言わずもがな」の「もがな」です。古い日本語で「〜があったらなあ」という意味で、このツールはユーザーの願望を実現するツールだということです。以前作ったSVGツールに比べると、デモとしてはもう少し遊べるものになったのではないかと思います。

今後AIコーディングがどうなるかはわかりませんが、AIが生成したコードを人間が必死にレビューやデバッグばかりする未来はあまり楽しくなさそうです。自分としてもなんとか楽しいプログラミングを続けていきたいものです。なお、この記事はすべて人間が書きました。

参考文献

バイブコーディングとは何か？ AIに「委ねる」プログラミング新手法 https://www.technologyreview.jp/s/359884/what-is-vibe-coding-exactly/

テスト不足なのでアプリが動かなくなったりするかもですが、ブラウザのサイトデータを消去してリロードしてみたらまた動くようになるかもしれません。 ↩
この図、わざわざ描く必要あったかな……？ ↩
副次的な効果ですが、ツールのコードはサンドボックス上で動作するので、仮に悪意のある人間が書いたコードでも安全に実行できます。これにより、誰かが生成したツールのコードを自分の環境で使っても安全なのですが、実装が面倒だったのでそういう機能はまだありません。 ↩