はじめに:AIと開発?それって楽なの?…ちょっと待った!
最近、「生成AI」ってすごいですよね! CursorやClaudeみたいなAIアシスタントが、まるで魔法のようにコードを書いてくれたり、相談に乗ってくれたり。もう開発はAIにお任せで楽ちん!…なんて思っていませんか?
甘い! (と、今回の実験で私は学びました)
確かにAIは強力な助っ人ですが、彼ら(彼女ら?)と本気で「協働」しようとすると、そこには予想外のドタバタ劇が待っていたのです。
この記事では、AI VTuberを作るという野心的なプロジェクトで、
- Cursor: バックエンド担当大臣(サーバー側のあれこれ)
- Claude (Desktop): フロントエンド担当大臣(見た目のあれこれ)
という豪華(?)布陣で開発作業を分業させ、その仲立ちを playwright-mcp
という技術にやらせてみた顛末記です。
華々しい成功!…だけではなく、
- AIに指示を出すたびに承認クリック地獄に陥ったり…
- モニターが悲鳴を上げるほど画面で埋め尽くされたり…
- AI同士が会話できないから、私が人間伝書鳩になったり…
そんな舞台裏のドタバタも含めて、playwright-mcp
や MCP
を使ったAI協働開発について紹介します。
この記事でわかること(主な登場人物とあらすじ)
-
playwright-mcp
: AI界のスーパー通訳? ブラウザ操作をAIに任せる魔法の杖(ただし、ちょっとクセあり)。 - Cursor & Claude: それぞれ得意分野を持つ優秀なAI大臣たち。でも連携は苦手。
-
Filesystem MCP
: AIにファイルの読み書きを許可する門番。 - AI分業: 上手くハマれば効率爆上がり!でも連携は人間頼み。
- 環境構築: Windowsだとちょっとした罠も。Node.jsのバージョンとかパスとか…。
- 舞台裏: クリック地獄、モニター崩壊、人間伝書鳩… AI開発のリアルな笑い話。
環境および事前準備
- OS:Windows
- Cursorをインストール
- Claude Desktopをインストール
- Node.js
AI VTuber開発という名のドタバタ劇場
AI VTuberを作るぞ!と意気込んだものの、フロントエンド(Three.jsとかVRMとか)とバックエンド(PythonとかWebSocketとか)の両方が必要。これは一人(とAI一人)では大変そうだ…。そうだ、AIにも分業してもらおう!
Cursor (バックエンド) vs Claude (フロントエンド) の役割分担(大臣任命)
AIにも個性と得意分野があるらしい、ということで、適材適所で大臣を任命しました。
-
Cursor バックエンド大臣:
- 担当: サーバー周りの難しい処理、API設計など。Python (Flask) と WebSocket を操る。
- 任命理由: コード全体の構造を理解したり、ロジックを組み立てたりするのが得意そう。まさに縁の下の力持ちタイプ。
-
Claude フロントエンド大臣:
- 担当: ユーザーが見る画面、3Dモデルの表示など。JavaScript (Three.js) と VRM を操る。
- 任命理由: ブラウザ操作が得意で、見た目に関する実装に強そう。華やかな舞台がお似合い。
さあ、これで完璧な布陣!…のはずでした。
playwright-mcp
とFilesystem MCP
:AIに力を与える魔法のアイテム(と副作用)
AI大臣たちに実際に開発してもらうには、彼らが我々のPC環境にアクセスする手段が必要です。そこで登場するのが MCP (Model Context Protocol)
という名の魔法体系。
MCPとは?
超ざっくり言うと、AIが外部ツール(ブラウザとかファイルとか)と安全にやり取りするための「共通言語」みたいなものです。
今回は、このMCP体系から2つのツール(MCPサーバー)を授けました。
-
playwright-mcp
(ブラウザ操作):- 効果: AIが「localhost:3000を開け!」とか「このボタンを押せ!」とか呪文を唱えると、実際にブラウザが動くすごいツール。
-
副作用(要注意!): 標準 (
microsoft/playwright-mcp
) だと、Cursor大臣とClaude大臣が同時に同じ場所(URL)にアクセスすると、力が反発してエラーになることが判明! -
解決策(別の方法): そんなときは
@executeautomation/playwright-mcp-server
という別のツールに--shared-session
という魔法を付与して使うと、大臣それぞれが別のウィンドウ(でも同じ場所を見れる)を開けるように! 平和的解決。 -
設定例: 大臣たちの設定ファイル(例:
.cursor-settings.json
とclaude_desktop_config.json
)にこう書く。{ "mcpServers": { "playwright": { "command": "npx", "args": [ "-y", // なければ勝手にインストールしてくれるおまじない "@executeautomation/playwright-mcp-server", "--shared-session" // これが大事! ] } } }
- 参考:
※Cursorの設定ファイルの場所(現在、MCPは40ツールまでに制限されているよう)
※Claudeの設定ファイルは以下に作成する必要があります。
C:\Users\ユーザー名\AppData\Roaming\Claude\claude_desktop_config.json
-
Filesystem MCP Server
(ファイル操作の巻物):- 効果: AIがプロジェクトフォルダ内のファイルを読んだり、書き換えたりできるようになる巻物。
-
設定例: Claude大臣の設定ファイルだけ記述。
# frontendフォルダへのアクセス許可! { "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "C:\\Path\\To\\Your\\Code\\Directory" // ここにフォルダのパスを書く ] } } }
- 参考: Filesystem MCP Server GitHub
これらのアイテムをAI大臣に与えることで、彼らは開発メンバー(?)として活動できるようになります。しかし、これらの力をAIに与えるということは…?
開発環境とAI連携フロー(人間は伝書鳩、時々クラゲ鑑賞)
実際の開発フローは、理想と現実のギャップに満ちていました。
-
領土分割: プロジェクトを
frontend
とbackend
に分ける。平和的。 - 権限付与: Cursor大臣にはバックエンド領土、Claude大臣にはフロントエンド領土(とファイル操作の巻物)を与える。
-
ブラウザ操作許可: 各大臣にブラウザ操作の杖 (
@executeautomation/playwright-mcp-server
推奨) を設定。 -
人間、奔走す: ここからが本番。
- クリック地獄: AI大臣たちが何か行動(ブラウザを開く、ファイルを読むなど)しようとするたびに、「許可しますか?」のポップアップが両方から飛んでくる!まるでモグラ叩きのように承認クリックを繰り返す羽目に。「許可!」「許可!」「あ、こっちも許可!」…忙しい!
- 人間伝書鳩: Cursor大臣とClaude大臣は直接会話できません。「Cursor大臣、APIの仕様こうなりましたよ」「Claude大臣、フロントの表示がこうなってますけど…」と、私が両者の間を行き来して情報を伝達。まさに文通状態。タイプミスしたら大惨事。
- クラゲ鑑賞タイム: ふと気づくと、Cursor大臣がバックエンドで黙々とコードを書き、Claude大臣がフロントエンドで画面をいじっている。それぞれが独立して動いている様子は、なんだか水族館でふわふわ漂うクラゲを眺めているような、不思議な感覚でした(ちゃんと連携してるか時々不安になる)。
- 統合と調整(人間の仕事): AI大臣たちが作ったものを最終的にチェックし、繋ぎ合わせるのは人間の役目。AIのコードは時に大胆なので、微調整は必須。
Windows環境でのMCP環境構築Tips(ハマりどころ満載)
特にWindowsでこの魔法体系を構築しようとすると、ちょっとした落とし穴が。
-
Node.jsバージョン: LTS版 (例:
v20.19.0
) を使いましょう。古いと動かないことも。 -
NVM for Windows のパス:
nvm-windows
を使っている場合、パス設定に注意。nvm which <version>
で確認! -
パス指定: JSONファイルでは
\
を\\
と書く!絶対パス推奨! - モニター画面、崩壊寸前: CursorのUI、Claude Desktop、フロントエンド確認用ブラウザ、バックエンドのログ…気づけばモニターはウィンドウで埋め尽くされ、はみ出しそうに!物理的な作業スペースも大事だと痛感しました。マルチモニター推奨。
CursorとClaudeによる具体的な実装と直面した課題
AI大臣たちの活躍と、人間(私)の奮闘の記録です。
Cursorバックエンド大臣の功績:
- Flask + WebSocketサーバーの基本骨格構築
- 外部LLM連携APIの実装
- 感情分析機能の組み込み
- TTSエンジン連携
Claudeフロントエンド大臣の功績:
- Three.jsによる3D空間構築
- VRMモデルのロードと表示
- WebSocket通信の基礎実装
- 表情変化 / リップシンクの基礎
直面した課題(人間ヘルプデスク案件):
-
ブラウザ操作の競合: 上述の通り。
@executeautomation/playwright-mcp-server
で解決! - 複雑なライブラリ: Three.jsやVRMの奥深い機能はAI大臣も苦手。「なんか動きません!」「このオプション何ですか?」→人間がドキュメント読んで教える。
- 非同期処理の壁: WebSocketの複雑なやり取りでAI大臣が混乱。「データが来たり来なかったり…?」→人間がデバッグ。
- 連携不足: 人間伝書鳩の伝達ミスや遅延で、フロントとバックエンドが噛み合わないことも。「APIの仕様、変わったって言ってませんでしたっけ?」「えっ?」
考察:AI協働開発は「銀の弾丸」か?それとも…?
今回のドタバタ劇を通して見えてきた、AI協働開発の光と影(主に影?)についての考察です。
光(メリット):
- 効率化: 単純作業はAIに丸投げ!人間はもっと面白いことを考えられる。
- 24時間稼働: AIは眠らない(ただし、たまに変な方向に暴走する)。
- コード品質(?): 書き方は一貫してるかも。コメントもちゃんと書いてくれる(ことが多い)。
- 新技術: 知らない技術もAIに聞けばとっかかりやすい。
影(デメリット・課題):
- 複雑な設計: 全体の設計思想とか、ゼロイチはまだ人間。
- 最新情報: AIは過去の情報で学習してるので、最新ライブラリとかは苦手。
- 細かい調整: パフォーマンスとかエッジケースとか、AIは気づかないことが多い。
- AI間連携: AI同士は基本他人行儀。人間が仲介しないと会話しない。
- 環境構築: 新技術ゆえのトラブルはつきもの。情報も少ない。
- 人間側の負担: クリック地獄、伝書鳩、モニター圧迫… AIを使う側のスキルや忍耐も必要。
生成AIによる開発分業の未来(もっと楽になる…はず!)
今はまだドタバタしていますが、未来はきっと明るい…はず!
- AIの進化: もっと賢く、もっと連携上手になる…はず。
-
ツールの進化:
playwright-mcp
みたいなツールがもっと洗練され、設定も簡単になる…はず。 - AIチーム: AI同士がもっとスムーズに連携するようになる…はず。
- 人間の役割: 面倒な作業はAIに任せ、人間は創造的な仕事に集中できる…はず。
playwright-mcp
のような技術は、AIが開発に直接参加する未来を予感させます。今はまだ人間が汗水たらしてAIのご機嫌を伺う場面も多いですが、この経験が未来のスタンダードを作っていくのかもしれません。
参考情報・ツール
- playwright-mcp (Microsoft版): https://github.com/microsoft/playwright-mcp
- @executeautomation/playwright-mcp-server: https://www.npmjs.com/package/@executeautomation/playwright-mcp-server
- Model Context Protocol (MCP): https://github.com/modelcontextprotocol
- Filesystem MCP Server: https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem
- Cursor: https://www.cursor.com/
- Claude: https://claude.ai/
- Three.js: https://threejs.org/
- VRM: https://vrm.dev/
- nvm-windows: https://github.com/coreybutler/nvm-windows
まとめ:AI開発は、まだ冒険の途中!
CursorとClaudeという強力なAI大臣を従え、playwright-mcp
という魔法の杖を手に、AI VTuber開発という冒険に乗り出した結果…そこには効率化と同時に、予想外のドタバタと笑いがありました。
クリック地獄に耐え、人間伝書鳩となり、モニター崩壊の危機を乗り越え…それでも、AIが自律的にブラウザを操作し、コードを書き換えていく様子は、まさに未来を感じさせるものでした。
AI協働開発は、まだ発展途上の技術です。ツールを使いこなす知識や、AIとの上手な付き合い方、そして時にはトラブルを楽しむくらいの遊び心が必要なのかもしれません。
この記事が、これからAIとの協働開発に挑戦するあなたの、ちょっとした道標や、クスッと笑える息抜きになれば幸いです。(モニターとクリック用の指の準備は忘れずに!)