クロードとジェミニに Docker アプリを構築するよう依頼しました。一方はよりスムーズで、もう一方はよりスマートでした

私はここしばらく、小さなアプリのバイブコーディングを行ってきましたが、それらの最大の問題は、アプリが構築されたマシン上で生きたり消えたりすることです。理想的には、これらのアプリを自己ホストして、すべてのデバイスからアクセスできるようにしたいと考えています。そこで今回は、Claude と Gemini をテストして、どちらのモデルが Docker 化されたアプリを構築し、自己ホスティング プロセスをできるだけシンプルにするのに優れた仕事をしているかを確認します。

どの AI モデルがより優れた自己ホスト型アプリを構築するかを確認するテスト

Docker アプリの構築に優れているのはどのモデルですか?

作業を合理化 (または自動化) するための小さなアプリを構築することは、正直に言って、LLM の最良の用途の 1 つです。同じことを何度も繰り返すようトークンを書き込む代わりに、一度ツールを構築させて、代わりにそのツールを使用することができます。しかし、これらのバイブコーディングされたアプリには移植性に問題があります。これらは 1 つのシステム上にいくつかのファイルとして存在し、移植性があるように感じられるかもしれませんが、多くの場合、そうではありません。

バイブコーディングされたアプリが別のシステムで実行されるかどうかは、多くの場合、LLM がそれを構築した方法に依存します。たとえば、システムに必要な依存関係がすでにインストールされていることに気付いたため、それらをアプリ ファイルにバンドルしなかった可能性があります。ここで、アプリを別のシステムにコピーすると、機能しなくなる可能性があります。

私の意見では、この問題を解決する最善の方法は、単純に Docker でコンテナ化し、自己ホストすることです。こうすることで、システム上で実行されると同時に、他のすべてのデバイスでも即座に利用できるようになります。 Tailscale のようなプライベート VPN サービスを使用して、ローカル ネットワークを超えて共有することもできます。

ただし、バイブコーディングされたアプリを自己ホスト型の Docker アプリに変えるのは難しい場合があります。私の経験では、バイブコーディングプロジェクトに追加するレイヤーが増えるほど、問題が発生する可能性が高くなります。そのため、Docker 化されたアプリを作成し、デプロイメントをできるだけシンプルかつ簡単にするのに、現時点でどのモデルが最適であるかを確認したいと思いました。

このテストでは主に、Claude と Gemini という 2 つの LLM をテストしました。どちらのモデルも、単純な To Do アプリを作成するように指示されましたが、焦点は、Docker を使用して自己ホスト型にすることと、自己ホスト型プロセスを可能な限りプラグ アンド プレイにすることにありました。また、利用可能なポートを確認し、すでに使用されているポートを対象とするアプリを構築するように指示しました。これを除けば、プロンプトは非常に最小限でした。どちらが一発でより良い仕事をするかを知りたかったのです。

その様子は次のとおりです。

記事の最後に正確なプロンプトを共有しました。

クロードによる Docker アプリの構築の試み

完璧に近かったが、それを妨げたのは自分のミスがあっただけだった

クロードはすべてを構築するのに約 3 ～ 4 分かかりました。私は Opus 5 モデルを思考レベルを低く設定して使用し、Claude デスクトップ アプリ内で Cowork モードで実行していました。 Cowork を使用すると、Claude が私のファイル システムに直接アクセスできるようになるため、このために Cowork を使用することが重要です。こうすることで、私がコードをコピーして貼り付けてファイルを保存する必要がなく、クロードが必要なファイルをすべて独自に作成できます。

構築プロセス中に直面した問題の 1 つは、クロードがどのポートがすでに使用されているかを確認できないことでした。しかし、経験に基づいた推測を行って、アプリをポート 8420 に割り当てたところ、幸いにも無料でした。私のシステム上で実行されているさまざまな Docker コンテナをすべて認識していたので、それらが使用するデフォルトのポートを知っていたため、そのうちの 1 つを選択しなかったのだと思います。

また、実行できませんでした ドッカー構成 コマンドを手動で実行する必要がありました。ただし、アプリについて知っておくべきことすべてと、それを展開する方法を平易な英語で説明した詳細な README ファイルを入手しました。したがって、Docker の仕組みにまだ慣れていなかったとしても、特に難しいことはありませんでした。

アプリ自体に関しては、要求どおり最小限のものでしたが、私が明示的に要求していなかったいくつかの歓迎すべき点がありました。タスクを追加するだけでなく、アクティブなタスクと完了したタスクの間でフィルタリングすることもできます。明るいテーマと暗いテーマもありました。そしてもちろん、タスクはセッションをまたいで持続しました。ツールの選択も、この規模のプロジェクトとしては賢明なものでした。 Claude は、Node の組み込み HTTP モジュールをバックエンドに使用し、プレーンな JSON ファイルをデータ ストレージに使用し、REST API を通じてすべてを公開しました。

Gemini による Docker アプリの構築の試み

あまり印象に残らない結果に至るまでのスムーズな道のり

Gemini では、Google 独自のエージェント開発アプリである Antigravity を使用しました。 Cowork と同様に、フォルダーを指定すると、フォルダー内で動作します。私は高度な思考で Gemini 3.1 Pro を使用し、まったく同じプロンプトを与えました。そして、Claude と同じくらい速くアプリケーションを構築しました。

ここでの主な利点はハーネスでした。 Antigravity はターミナルにアクセスできるため、アプリを構築した後、Docker デプロイメント自体を実行しました。また、ポートの可用性もチェックされ、空いているポートが割り当てられ、最終的にはローカルホストの URL をブラウザに入力するだけで済みました。そのため、Gemini を使用すると、全体的なアプリのデプロイメントがよりスムーズになりました。

上で述べたように、Claude はターミナル コマンドを実行することもできますが、そのためには Claude Code を使用する必要がありました。この実験では、システムに端末からアクセスできない Cowork を使用しました。

さて、アプリの話になりますが、Gemini は私の指示を忠実に守り、非常に最小限の ToDo アプリを構築しました。タスクを追加し、完了としてマークし、削除するだけで十分です。派手なダーク モードやフィルタリング オプションは必要ありません。確かに、私はそんなことを求めたわけではないので、ジェミニはクロードよりも指示に厳密に従っていただけだと主張することもできます。

私の本当の不満の 1 つは、ミニマリズムがインターフェイスにのみ適用されているということです。内部では、バックエンドに Express を使用し、データベースに SQLite を使用するなど、必要以上に物事が少し複雑でした。公平を期すために言うと、どちらも標準的な選択肢であり、運用グレードのアプリとしては合理的な選択肢です。ただし、個人的な To Do リストの場合、それらは単なる追加の重量にすぎません。私は実際、ここではクロードのアプローチの方が好きでした。

---

Docker デプロイ層の Vibe コーディングはもはや大したことではありません

核心的な質問に答えると、Claude と Gemini はどちらも Dockerized アプリのバイブコーディングに優れています。どちらも特別なプロンプトを表示せずに一発で実行でき、適切なハーネスを使用すれば展開ステップも自動化できます。これは解決された問題です。

今後の私のアプローチとアドバイスは、アプリケーションをバイブコーディングしている場合は、最上位に Docker レイヤーを要求するだけです。 1 台のマシン上にあるファイルの山を、どこでも実行でき、誰にでも渡せるものに変えます。

私が使用したプロンプトは次のとおりです。

Build a simple, polished to-do list web app in the current directory.

The app must be fully self-hostable and deployable with Docker. Create all necessary source files, Docker files, configuration, and a README explaining exactly how to build, start, stop, and access the app from the terminal.

I already have Docker installed. Once deployed, I should be able to open the app in my browser at a localhost URL.

You have access to the filesystem and can run commands, so actually build and test the application rather than just providing instructions or code.

Before choosing a host port, check whether it is already in use and choose an available port if necessary. Document the final port in the README.

The finished project should work from a clean `docker compose up -d --build` invocation and should retain the to-do data when the container is restarted.

Use your own judgment for the technology and architecture. Keep the implementation reasonably simple, but make the finished application feel complete and usable.

IMPORTANT: Ensure that it's very minimal work on my end. I want it to be as plug and play as possible and something that just works.