バイブコーディング、自動化、そしてMCP
(stdy.blog)バイブコーディング = AIに外注すること
バイブコーディングは本質的にAIにプログラム開発を外注すること。
受託開発を依頼した経験を振り返ると、良い発注者は次のようなことがうまい。
- 自分の問題を解くための作業を定義する
- それを開発者がよく理解できるようにコミュニケーションする
- プログラムをうまく作るためのリソースを提供する
- 作られたプログラムが意図どおりに作業を代行してくれるか検収する
- この過程で自分が分からないことは開発者から学び、徐々に自分でもできるようになる
これをバイブコーダーの立場に当てはめると、
- PRDとユーザーフローを定義する
- 良いプロンプトと指示(Cursor Rules など)を使う
- 意図から外れた部分を見つけて自動テストを実行する
- この過程でAIとやり取りしながら学習する
では3は何か? これはプログラムの2つの側面から考えられる。
- 第一に、プログラムはどこかで実行されなければならない。→ 実行・デプロイ環境の決定
- 第二に、プログラムは「入力を処理して出力する」コードの集合である。→ データとAPIの提供
プログラムは実行されなければならない
- 受託開発では、開発者の責任は通常コード実装までで、デプロイと運用の責任は依頼者側にある
- その代わり、開発者は依頼者がこのプログラムを実行できるためのガイドを提供する
- 外注の発注者としてAIにコードを実行・デプロイする環境を伝えると、とてもうまくやってくれる。
- 特にWebブラウザ上で動くコードならなおさらである
- 以前は、'正規表現でMarkdown文書の一部の文法を取り除く' のようなとても単純なスクリプトでさえ、非開発者が実行・デプロイするのは簡単ではなかった
- 今ではClaude ArtifactsやGemini Canvasのようなもので、自分だけの小さなプログラムをさっと作って実行できる。ほかの人にも使ってほしければLovableで作ってデプロイすればよく、しかもすべて一瞬で無料でできる
- バイブコーディングだからといって、必ずしも「アプリ」を作る必要はない。自分の問題を解決し、反復作業を減らしてくれるプログラムなら、それがアプリでも、スクリプトでも、GPTsでも、プロンプトでも構わない
プログラムをさらに有用にしてくれるAPI
- ただし、小さなプログラムには限界がある
- Markdown RemoverにはDBも、APIも、LLMもつながっていない
- そのためテキスト入力もユーザーが直接行い、出力されたテキストもユーザーが直接コピーして別の場所に投稿しなければならない
- もしユーザーの目的が「Notionに書いておいた文章を整えてSNSに投稿する」ことだったら?
- 入力: Notionページのリンクだけを入力
- 処理: 取得した文章をLLMに入れてSNS向けに要約し、その後Markdown記法を削除
- 出力: 文章を確認し、承認すれば自分のSNSアカウントに自動投稿してくれる
- 応答時間の速さと汎用性を犠牲にする代わりに、その作業にかかるユーザーの時間とエネルギーを大きく減らせただろう。つまり、特定の目的においてはより「有用」になる
- 結局、プログラムの有用性は、入力・処理・出力の観点でユーザーが直接やらなければならないことをどれだけ減らせるかにかかっている
- 入力を自動化するか
- 処理をより複雑にするか
- 出力を自動化するか
- 一般的なプログラムでは、APIを通じて(つまり他のプログラムと接続することで)入出力の自動化と高度な処理が可能になる
- 入力: Notionの権限を取得し、Notion APIを呼び出してページ内容を取得する
- 処理: LLM APIにシステムプロンプトとともにNotionページの内容を渡し、SNS向けの応答を受け取る
- 出力: Threadsの権限を取得し、SNS APIを呼び出して投稿する
- しかし、こうしたものを作るのは熟練した開発者にとっても決して簡単ではない。特に権限付与が厄介だからだ
- これをもっと簡単にできるだろうか?
面倒なAPI連携を代わりにしてくれる自動化ツールとMCP
- Zapier、Make などの自動化ツールを使えば、API連携を自分で直接しなくてもよい
- 例: Notion DBに新しいアイテムが追加されたら -> ChatGPTを回して -> InstagramにアップロードするZap
- もともとInstagramの投稿APIを呼び出すには、専用アプリを作って審査まで受けなければならない
- ZapierやMakeでは、Instagramアップロード用アプリをすでに作ってあり、権限を取得してデータをやり取りするフローもすべて実装済みである。面倒な権限問題を自分で気にする必要がない
- しかし人によっては、こうした「これをやって次にあれをやる」という構築ですら難しく面倒に感じることがあり、そういう人がLLMチャットボットで全部できるようにしてくれるのがMCP/A2Aのようなものだ
- 一般的なプログラムがAPIを通じて単純なロジック以上のことを実行できるようになったのと同じように、LLMチャットボットというプログラムもMCPを通じて他のプログラムと接続され、単純な(?)テキスト/画像/音声出力以上のことを実行できるようになる
- つまりClaudeで「自分のNotionページを取得して要約してからInstagramに投稿して」が可能になるということだ
- もちろんそのためには、適切なMCPサーバー(Notion、Instagram)をMCPクライアント(Claude)に接続しなければならない
- MCPサーバーの最大の役割は tool を通じてAPIを代わりに呼び出すことだが、Notionにはすでに公式MCPサーバーがある一方で、Instagramにはない
- ではClaudeはInstagram APIをどう呼び出すのか?
- ここで再びZapierが登場する。ZapierやMakeが提供するMCPサーバーを通せば、Instagramへのアップロードが可能になる
- つまり、LLMチャットボットに(すでに多くの連携を備えた)自動化ツールをMCPで接続すると、非常に強力になる
MCPの潜在力と限界
- ただ、こうして見ると、なぜわざわざMCPを使うのかと思うかもしれない
- 現在、チャットボット + MCPでできる作業のほとんどは、自動化ツールでもできるからだ
- しかし筆者は、MCPの潜在力は次の3つの理由で非常に大きいと感じている
- 便利なインターフェース(チャットボット秘書が全部やってくれるのが究極のプログラムではないだろうか?)
- センシティブな作業に対するユーザー介入がよりやりやすい
- ファイルシステム制御、ブラウザ制御など自分のローカルPCでやるべきことも自動化できるうえ、リソース、プロンプトテンプレートなどさらに多くの情報も提供できる
- MCPを使う際に気をつけることも多い
- MCPに多くを任せるほど、セキュリティにもより注意が必要になる。だからローカルよりは公式のリモートMCPサーバーのほうが安全だ
- LLMにMCPツールを与えすぎると、自分が望むツールが実行されないことがあり、ツール定義がすべて入力トークンとして渡されるため、LLM呼び出しのコストと時間も増える
- LLM特有のランダム性も商用サービスでは常に注意しなければならない
- 結局、自分のプログラムにAPIをつなぐにせよ、自動化フローを設計するにせよ、LLMチャットボットにMCPを付けるにせよ、やっていることはすべて「自分の仕事を代わりにやってくれ」で同じだ
- MakeやMCPのようなキーワードが急浮上しているからといって、ストレスを感じる必要はない。自分にとってやりやすい方法で、それぞれの方法の長所と短所を把握しながら、自分の仕事を代行するプログラムを作ればよい
まとめ
- バイブコーディングとは、プログラム開発の外注をAIに任せることだ。
- 自分の作業をうまく代行してくれるなら、Webアプリ、コードスニペット、プロンプトのどれも有用なプログラムになりうる。
- プログラムをより有用にするには、入出力の自動化と高度な処理のためにAPI接続が必要だ。
- 自動化ツールは、API接続の面倒さを代わりに解決してくれる。
- LLMチャットボットというプログラムも、MCP接続によってさらに有用になりうる。特に自動化ツールが提供するMCPサーバーを接続するのが強力だ。
- API、自動化、MCPはどれか1つだけを使う必要はなく、組み合わせるとさらに簡単かつ強力になる(例: ClaudeにNotion MCPだけをつなぎ、ZapierでNotion to Instagramを設定してアップロードを自動化する)。
- 長所と短所を踏まえ、自分に合った方法で、自分の問題を解決するプログラムを(AIと一緒に)作ってみよう
4件のコメント
バイブコーディング程度では、外注とは言えないでしょう。外注はプロジェクト単位で検収しますが、今のAIコーディングエージェントはそれより小さいタスク単位で検収しなければならないからです。
外注なら仕事を任せて、自分は別の仕事ができるはずですが……まだあまりにも頻繁に面倒を見てやる必要があります。賢いけれど不器用なジュニア開発者のように……
そう遠くないうちに……外注とまではいかなくても、小さな開発チームのように働けるのではないか……と思います。作業を指示して、随時レビューして、直して……しかし、まだその程度ですらない気がします。
もしかすると、私にバイブが足りないからなのかもしれません……
https://tech.kakao.com/posts/700 この投稿を見て、Vibe Codingの良い事例だと感じていましたが、文脈が似ている気がします。私もお書きになった内容に共感します。
おかげで面白い文章を読めました!ありがとうございます。
では3は? -> リソース対応の話です。
上では1、2、4、5と番号を振ったのですが、Markdownで自動的に1234に変わってしまいました。