こんにちは。CTO室の村主です。
みなさん、Claude Code や Cursor で色々なアプリを Vibe Coding していると思います。いきなり本番環境をゴリゴリ Vibe Coding している人は限られていると思いますが、ひとまず社内系のアプリケーションなら品質は置いといて爆速で作っていけると思います。
そこで、要望からデプロイまでを爆速にするツールを作ったので公開します。
背景
Claude Code で開発するとサクサク機能追加できます。でも非エンジニア含めてみんながみんな Claude Code を使いこなせるわけじゃないです。
そこで Claude Code Action を実装すれば GitHub に Issue を登録するだけで自動的に開発が行われ PR 作成まで簡単に進められると考えました。
でも機能追加・改善したい時にいちいち GitHub Issue を開くのが手間だなぁと思いました。それならウィジェットを置いてヒアリング・要件定義して、その内容を GitHub Issue に自動登録して、自動でコーディングして PR まで作ってくれれば、ヒアリングからコーディングまで自動で行われるんじゃない?そうするとみんなで機能開発に参加できるよね。と思い、「おし、そのウィジェットすらも Vibe Coding するか」となりました。
そして「ウィジェットだったらクライアントサイドは1行実装だよね」「なんだったら汎用的にして多数のアプリに簡単に設置できるように」と。
あと、Claude Code がどこまで出来るのか実例をもって試したかったというのも背景です。
feedback-widget
使い方は Claude Code くんが README を丁寧に書いてくれている(書きすぎているところも実験のひとつ)のでお任せするとして、ご想像の通り以下の単純な機能です。実装方法は後述します。
設置すると以下のウィジェットが表示されます。数回のやりとりで GitHub Issue が作成されます。
すると以下のように事前に設定したClaude Codeが自動でコーディングをしてくれるので、それをもとにPRを作成する流れです。


これにより、画面上で誰でも機能要望を行え、自動でコーディングされ、開発者はPRをレビューし(それすらもLLMでも)、マージするだけになります。
feedback-widget の責務はウィジェットと Issue 投稿です。作成された Issue を元に自動コーディングするところは責務に入れませんでした。今後色々なコーディングエージェントが台頭してくると思うので、あくまで橋渡し程度の実装です。
また、サーバサイドのコンテナを1個立ち上げるだけで、複数のアプリにウィジェットを配置することが出来るのも特徴です。
開発スタイルの未来
上記の例の通り、ユーザの要望から Ship されるまでの期間が爆速にできる時代になりました。エンジニアでなくても開発に参加でき、顧客からの要望すらも10分後にはコーディング完了している。もしくはまずは MVP を作って feedback-widget を設置し、顧客側で必要な機能を盛り盛りしていくようなスタイルもあり得るかもしれません。
数年後にはこのようなフローがデファクトになるかもしれませんし、ユーザの要望の集め方、コーディングエージェントへの投げ方、コーディング性能が成熟する、人によるコーディングとの速度差が広がる可能性の中でどういう開発スタイルを受け入れていくかも考えていく必要があります。
上記のような状態になるとコードは大量生成され、レビューすることがボトルネックになることは想像に容易く、しかし何でもかんでもデプロイすると品質低下が見込まれるので、テストが重要になり、今後半年もしないうちにテスト手法などの確立が急速に進んでいくと思います。そうなるとより品質が高く高速な機能開発の未来が見えますね。
ひとまずは社内アプリが増えそう
さすがに現時点では、大規模でたくさんのユーザを抱えているアプリや品質がものを言う世界では気軽に Vibe Coding はできませんが、社内アプリなど品質を自分たちで落とし所付けられるものはサクサク作れていくでしょう。
ちょろっとした OSS はすでに「 Claude Code のみで作りました」が増えています。社内アプリも自分たちで使いやすいように作るようなやつもたくさん出てくる中で、複雑ではない SaaS は自社開発で置き換えられることも多くなる可能性もあります。どう立ち回るのが良いのか、そのうち Vibe Coding しやすい(自分たちで自由に追加開発ができる)SaaSが出てくるのかな。
さて、実装方法を
- サーバサイドのコンテナを立ち上げる
- どこか適当な環境で Docker を起動してください
- 社内で1コンテナ立ち上げれば良いように作っています
起動時に環境変数を設定する
# Gemini AI API GEMINI_API_KEY=your-gemini-api-key GEMINI_MODEL=gemini-2.0-flash # GitHub Configuration GITHUB_TOKEN=your-github-token GITHUB_MENTION=@claude # Domain-API Key Mapping (Required) DOMAIN_API_MAPPINGS=example.com:widget_prod_key1,widget_prod_key2;localhost:widget_dev_key;app.company.com:widget_company_prod
環境変数 備考 GEMINI_API_KEY Google AI Studio で発行してください GEMINI_MODEL Gemini 2.5 Pro 且つ Cloud Run だと推論時間が長くエラー出ました。そういうところだけ注意ください。Flash系がオススメです。 GITHUB_TOKEN Personal Access Token を。Permission で Issues の read/write を。GitHub AppはREADMEを参照ください GITHUB_MENTION Issue作成時のメンション名を。@claude以外でも使えるようにしています DOMAIN_API_MAPPINGS 簡易な認証機能です。ドメイン制限と任意のキーが無いとリクエストを受け付けないようにしています。気が向けば強固なものにします。詳しくはREADMEを 起動後のURLをメモっておく
- どこか適当な環境で Docker を起動してください
クライアントサイドに1行追加する(パラメータ必要だったので実質1行ということで...)
- なお、認証周りがややこしければひとまず「all:widget_prod_key1」でも動くようにはなっています。他の動作確認が済んだらドメインに変えるなりしてください。
<script src="https://<サーバサイドのURL>/widget.js" data-api-key="<DOMAIN_API_MAPPINGSで設定したキー/widget_prod_key1>" data-github-repo="<Issueを登録したいOrg/リポジトリ名>"> </script>
他サイトのクライアントサイドにも順次1行を追加していく
- サーバサイドの DOMAIN_API_MAPPINGS に追加したいドメインとkeyを設定
- クライアントサイドに上記の data-api-key と data-github-repo に Issue を作りたいリポジトリを指定
注意点
- 全ての要望がそのアプリにとって必要とは限りません。
- このような開発スタイルは機能がAddされ、かなりカオスになるのが想定されます。そこから引き算するのがエンジニア・デザイナーの腕の見せ所かと思います。
- Claude Code Actionは 2025年6月時点では複数人利用の場合は従量課金になるため課金額には注意してください。ここも無制限利用できると色々革命が起きますね。
最後に
「①品質を落とせないシステム」と「②品質を落とせるシステム」でコストと納期が二極化が想定されます。①は人が手作業でコーディングし今まで通りだとして、②は上記の通り爆速で色々なシステムがたくさん作られる。②はコーディング性能の指数関数的進化や生成AI前提のテスト工程の確立、ガードレールなどのLLMOps、CodingOps関連機能の拡充が見込まれ、①をすごい勢いで追いやる気もしています。数年以内に十分起き得る事象です。
そのため①を目指して僕自身は Claude Code に All-in ですし(あくまで今日時点。ツールは2-3ヶ月後には変わってると思う)、全社員が使えるように予算を整えているところです。
なお、この文章は「 Powered by 100% Muranushi 」です。