サムネイルは競技Vibe Codingのイメージ図です。
こんにちは。ペパボのVibe Coding大臣のyukyanです。
今回は、社内で「第一回 競技Vibe Coding」を行ったので、その模様をお伝えしていきたいと思います。
Vibe Codingとは何か？については、先日テックブログに記載した日本初!?「Vibe Coding研修」を2025年新卒研修の目玉として実施しますをぜひご覧ください。
競技Vibe Codingとは？
「お題のものをVibe Codingを駆使して一番早く作った人が勝ち」というシンプルなルールの競技です。
実際に開催時に使ったルールを以下に記載します。
- お題が与えられます
- それをVibe Codingで作ってください
- コピペ以外なら道具は基本なんでもありです。要件の調べ物に使うのも良いでしょう
- Cursor、ChatGPT、Anthropic、etc…
- 可能な限りVibe Codingしてください
- 「作った！！！！！」と宣言して、「要件を満たせたプロダクト」を見せれた人が勝ちです
- 要件を満たせているか、客観的に判断できる材料があるとよいでしょう
- 厳密なテストケースがあるわけではないので、司会の主観でできたかどうかを判断します、ご了承ください！
大会の目的
ペパボでは、日本初!?「Vibe Coding研修」を2025年新卒研修の目玉として実施します にも記載した「大量のコード生成に耐えうるエンジニアリング」を実現するため、Vibe Codingに関する様々な取り組みを進めています。
以前、全社員向けにVibe Coding研修としてCursorやCopilotの機能をハンズオンで教える会を設けました。その中で、次のアクションとして「LLMの威力をより感じてもらうにはどうすれば良いか？」という課題がありました。そこで生まれたアイデアになります。
大会概要
今回は職種問わず参加者を5名募集し、Google Meet上で各々の画面を共有しながら行いました。また、その模様を限定公開のYouTube Liveで配信しました。
Vibe Codingをしている様子を見てもらうことで、それぞれのやり方の気づきを得てもらったり、すごいスピードでプロダクトができるという部分に驚いてもらう、といった効果を狙っていました。
また、職種を問わず参加してもらうことで、もはやコーディングは職業エンジニアでなくても現実的に可能になってきている、といったことを伝える目的がありました。
大会の参加者
今回は以下の5名に参加してもらいました。
- Ā−YA ロリポップ・ムームードメイン事業部 CSグループ
- てつを。 新卒14期 事業開発部 エンジニア
- どすこい 新卒14期 EC事業部 エンジニア
- yoshikouki 事業開発部 エンジニアリングリード
- 三宅悠介 ペパボ研究所研究員 プリンシパルエンジニア
大会のお題
今回は以下のお題をCTOのあんちぽから出題しました。
エンジニア以外の方も参加するため、スタートラインをなるべく揃えるために専門的な知識を要するお題を設定しています。 また、音が出るお題にすることで、観戦者の方に楽しんでもらいたいという意図がありました。
お題：適当に押すだけで曲になるグリッド型コード楽器
音楽理論に詳しくない人でも、グリッド状に並んだボタンを適当に押していくだけで、自然なコード進行や雰囲気のある演奏ができる「コードパッド楽器」を実装してください。AgentがVibeしてる間、演奏しながら実装を進めましょう。音がなると盛り上がっていいですよね。必須要件として、ダイアトニックコードだけでなく、セカンダリードミナントやモーダルインターチェンジなどのノンダイアトニックコード、テンションや色彩感のある補助的なコード（sus、add9、maj7 など）も演奏可能であること。また、任意のキーとスケール（モード）を切り替えて演奏できること。
その他、ループ再生や記録、演奏内容の保存・シェアなど、作曲ツールとしての拡張があるとなおよいですね。UI、サウンド、演奏体験に創意工夫を凝らし、「つい触りたくなる」楽器に仕上げましょう。
大会の様子
社内向けに行った配信のアーカイブになります。ぜひご覧ください。
優勝はCSのĀ−YAです！おめでとうございます！アプリケーションの完成度やデザインから、司会の私がVibeで判定しました。
個人的に面白かったのは 24:50〜からの、「AIがyoshikoukiに操縦席を渡すシーン」です。
インタビュー
出場していただいた選手の皆さんにインタビューを行ったので、ここからはそれを記載していきたいと思います。
質問1: 職種を教えてください。また、普段どのようにAIを活用していますか？
Ā−YA
職種は「カスタマーサービス」です。 お問い合わせ対応も行っていますが、業務効率化にも取り組んでいて、その中で生成AIの可能性と出会いました。 例えば、カスタマーサービスのみんながより素早く正確に対応できるように、AIを使った仕組みを考えたり、DifyやGPTを活用してプロンプトを作成するだけでなく、APIを使った連携も含めて実際にシステムを作ったりしています。
日常でもAIを活用して旅行プランを作成したり、ニュースや記事の要約・解説を依頼したり、ブログ記事を書いてもらったりしていて、生活の中に自然とAIが溶け込んでいる感じです。
てつを。
職種:エンジニア
業務においてはコーディングの補助、主にCSSやエラーの修正をしてもらうことが多いです。
また、実装の0→1は完全に任せることが多くて、仕様書の作成からしてもらいます。
日常では、本を読むときに片手にスマホでAIチャットを立ち上げてわからない単語や意味を都度聞きます。
同じ本の内容を聞くので途中から、単語の意味だけでなくその本がどういう意味でそれを使っているのかを理解し始めて、勝手に感想を言ったりするのが面白いです。
どすこい
エンジニアです。
日常
悩んだこと、こんがらがったこと、思ったことの整理や別の視点からのリフレーミングにLLMを使います
業務
以下の時に使います
- ど忘れしたことをシュッと思い出させてもらう
- 文章をまとめたり整理してもらう
- Deep Serachを用いた他社の事例やOSSの調査
- コードリーディングの補助
- コード全体のおおまかな調査
- テストコードのたたきの作成
- エラーの調査
yoshikouki
事業開発部でエンジニアリングリードをしています。普段は Alive Studio を開発しています。 AI活用について、業務・趣味でツールを分けていることはないです。
- 開発時のエディターは Cursor が中心 (Playwright MCP なども利用)
- 開発設計を例にする高品質な出力が必要なときは OpenAI o3 (ChatGPT)
- 日常的な会話やアイディアだしなどは OpenAI GPT-4o (ChatGPT)
- 目的のある調査には Gemini DeepResearch with 2.5 Pro
- 軽い調べものには Perplexity
三宅悠介
ペパボ研究所で研究開発を担当する研究員です。 研究開発では、機械学習や最適化を用いたサービスの改善を進めています。 コーディングエージェントはPoCの作成時に非常に役立っています。
質問2: 競技Vibe Coding大会に参加したきっかけはなんですか？
Ā−YA
大きなチャレンジではあるものの、まだ新しい分野だからこそ、アイデアと工夫で戦えるかもしれないと思ったのがきっかけです。 まだ提唱されてから日が浅いVibe Codingという新しい領域であれば、尊敬するエンジニアの方々に負けないくらいの結果が出せる”かもしれない”と思いました。
正直”行けるかも…！”という気持ち半分、”でもめちゃくちゃ怖い！”という気持ち半分でした。 そして、いざ出場が決まったときからずっとドキドキが止まりませんでした（笑）。
てつを。
社内で応募があった際におもしろそう！！と思い一瞬で参加の表明をしました。
Vibe Coding自体は競うものではないという感覚だったため競うとどうなるのかと、興味が湧きました。
どすこい
これからは当たり前になっていくVibe Codingの現在の姿がどれくらいか、直に感じたかったからです。
yoshikouki
私の普段の開発スタイルは「ハンドラーは生成AIだが、計画・設計・実装はしっかり自分でも確認する」というスタイルで、当初言われている Vibe Coding よりもまだ従来の開発手法寄りであると思います。
ここに自分でも課題を感じており、一度時間制限ありの完全な Vibe Coding を実践してみることで、自分の開発スタイルについても考えるきっかけになればと考えました。
三宅悠介
コーディングエージェントのベストプラクティスについて社内外からの情報収集に努めていますが、お題という形で比較評価可能な形式で自身のやり方の水準を確認できるというのは非常に良い機会だと考えたからです。
また、コーディングエージェントの利活用を自発的に面白く盛り上げていこうという気概に共感したためです。
質問3: 課題が出題された時の印象はどうでしたか？
Ā−YA
音楽は好きだったので「これはイケるかも！」と最初は思いましたが、必須要件に知らない音楽理論用語が並んでいて「うわ、これはやばいかも」とすぐに冷や汗をかきました。 音楽について少し知識はあったものの、参加者がざわついていたのを見て「これはチャンスかも！」と感じたのも事実です。 生成AIは、そういった専門用語をわかりやすく言い換えてくれる強みがあるのに、そのときにうまく活用できなかったのは反省点です。 本当はもっとAIに頼ればよかったなと振り返っています。
てつを。
簡単なお題ではないだろうと、身構えていましたが本当に何もわかりませんでした。
AIにそもそもどういうものか聞きながらVibe Codingをするという二刀流で実装を進めました。
どすこい
ぜんぜんわからなかったです。 音楽？音が鳴って楽しい感じ？ってイメージでした。 僕の知識がボトルネックになることで、Vibe Codingによる開発の精度が弱くなっちゃうかもしれないなぁという焦りがありました。
yoshikouki
初見は「全然分からん」という印象で、30分の時間制限を考えるとすべて生成AIに任せるしかないと覚悟が決まりました。
三宅悠介
背景知識がほとんどない分野であったことから、一本取られたなという感じでした。 というのも、そもそも自分自身が、コーディングエージェントの導入に関して、「みんな自分のわかる範囲のものを効率的に作らせることが多いが、知らない分野のコードを書き始めた例は少ない気がします」と述べており、この発言構造をそのまま適用された形になったからです。 とはいえ、新しい分野であるからこそ、そして時間制限があるからこそ、先入観なくAIに委ねる部分は委ねようと考え方を極端に振り切ることができたのはとても良かったと思います。
質問4: 課題に対してどのような戦略を考えていましたか？
Ā−YA
基本は以下の4ステップで進めました！
- 要件の情報をもとにGPT-o3に、Cursorで使うためのプロンプトを作ってもらう
- 作ってもらったプロンプトをCursor上で実行する
- Cursorに作ってもらう！（とにかく祈る）
- 動いたら、細かい修正や改良をしていく
結果として、CursorでGPT-o3を使うには追加課金が必要だと途中で判明して、代わりにGPT-4oを使うことにしました。 幸いGPT-4oでも問題なく対応できたので、よかったです。
てつを。
今回は質より速さを優先した回だったため、とにかく動くものを作ることを優先するように指示しました。
難しいお題が来そうだな、ということは予想していたため、Vibe CodingはCursorに任せつつ、知らない単語などはChatGPTで聞きながら指示をしようと思っており、実際にその通りになりました。
また、AIは考えてから実装に着手するのが早く、かつコードを書くのも爆速なので、指示するためのタイピングがボトルネックになると考えていました。そのため、音声を文字起こししてそれを理解させるという戦略を立てました。
どすこい
まずは課題の内容がわからなかったので、人間がわかるようにお題を要件に落としてもらいました。 その後、要件を参考にVibe Codingをしました。 様子見て、無限ループでエラーが解決できない時は、新たにコンテキストを切ってやり直しました。
yoshikouki
30分の時間制限を考えると「私が余計な茶々をいれない」ことが開発速度に繋がるので、基本的にAIに任せることを優先しました。 その他は、フェーズに依って以下のような戦略を考えました。
スタート時
- 「課題」から「要件」を洗い出すこと
- 要件の進捗を私がわかるようにドキュメントファイルとして整備
- この開発が時間制限付きのハッカソンイベントであることをAIに伝える
開発途中
- いつでも戻せるように細かくコミットを残してもらう
- 要件の進捗管理をドキュメントファイルに反映する
- Playwright MCP を使って自身で操作・デバッグしてもらう
三宅悠介
従来スタイルでは、こちらで大枠の設計は見えた状態から、そこに近づけてもらうというのをとっていましたが、上記のお題を受けて、AI先導にしようと切り替えました。
- はじめに、CursorのAskモードで、お題に関する議論を進めました。AIからは要件の深堀が、こちらからはそもそもお題の前提知識についてヒアリングを行いました。結果はprojects.mdに出力し、セッションを切り替えました。
- 次に、これを最短で実装するための設計候補と推奨を出してもらい、Goを出しました。CursorのAgentモードでモデル選択はAutoで依頼しました。コマンドは
rm -rf以外許可しているので環境構築から全て実行され、動作するアプリケーションが出力されました - その後、アプリケーションの動作確認を通してようやくお題でやりたかったことに頭が追いつき、自分自身から改善するための要件が浮かびました。例えば、素人が適当に押してもAIが自動で伴奏したりエフェクトをかけてそれらしく聞こえるようにしてほしいというものです。
- セッションをかえ、この要件を伝え、結果が出力されましたが、見た目の飾り付けが全くなくなってしまったので、追加の要件とともにデザインの修正を伝えました
- 結果は500エラーになり、ここで時間切れとなりました。
Git管理をしていたものの、AIに委ねすぎて構成を把握していなかったため、状態のロールバックに慌てる羽目になりました。 この辺は、AI主導範囲をもっと広げる開発経験の中で、勘所を掴んでいきたいなと感じています。
質問5: 完成物をぜひ見せてください！
Ā−YA
ボタンをポチポチ押すだけで、コード音が流れ、再生もしてくれる楽器アプリを作成しました。音楽理論がわからなくても楽しめるように、使いやすさを意識しています。 ブラウザで動作するので、ぜひ気軽に試してみてください！
♫ アプリはこちら
https://aaya-pb.github.io/grid-music-app/
てつを。
どすこい
https://github.com/t-daisuke/vibe-music-maker
やりたかった機能の実装は完了できなかったです。 また、途中でデザインがスマホ対応になったり、おさまりが悪くなったりしてしまいました。
yoshikouki
| リポジトリ | https://github.com/yoshikouki/vibe-coding-contest |
| アプリ | https://yoshikouki.github.io/vibe-coding-contest/ |
三宅悠介
壊れる前の画面です。
質問6: 大会が終わった後の感想を教えてください。
Ā−YA
他の参加者のレベルが非常に高く、正直「これは負けたかも」と思った瞬間が何度もありました。 また、自分の作品も”なんとなく動いた”というレベルで、しっかりコードレビューできていない部分もありました。 なので、「優勝させていただきました！」という気持ちが正直なところです。
それでも、結果として引けを取らない成果物だと思ってもらえたのかな？と感じられたことが、とても嬉しかったです。
てつを。
何もわからないところから、実際に動くものができることに感銘を受けました。
特に、細かい指示はしなくても与えられたお題に対して自分でドキュメントを見て調べて理解をしているところがもう人やん、となりました。
自分はタイピングがボトルネックになると思ったのでキーボードも使わずに、声とマウスだけでVibe Codingをしました。
マイクで拾えなかった声や間違った文字起こしも適切に補完して理解していたので音声認識と相性が良いな、と感じました。
どすこい
要件に落とした後に、もうちょい完成作品をどうしたらいいのかを吟味したらよかったと思いました。 また、抽象的な指示でAIに任せてしまったので、デザインが微妙だったり、動くべきところが動かなかったり、TODOのところが残ってしまったりしてしまいました。 要件や完成図を人間が理解すること、そこへのマイルストーンも人間が理解して方針の修正ができることがVibe Codingにおいて重要だなぁと実感しました。 unknown-unknownのものを任せているのか、known-unknownを任せているのかの切り分けがキーかもしれないです。
yoshikouki
いつもと違う緊張感で楽しかったです！
Cursor などの生成AIが支援してくれる開発ツールを利用していたとしても、私自身がコードを書いたり制御しようとすると実現不可能な速度で開発が進む様子はやはり圧巻でした。できあがったときに「これなにを作ったんだろう？」という感じてしまい、指示したのは私なのにそれが何なのか分からない始末でした。
Vibe Coding の「完全に雰囲気に身を任せて、コードの詳細に気を払わず、自然言語だけで指示をしてコーディングする」コーディングスタイルを体現できたなあという気持ちです。
時間制限付きのハッカソンであることをAIに伝えていたので、「あと10分だ！」などと適宜伝えることでハッカソンのチームメンバーのような雰囲気ができあがり、余計な確認がなくなったように感じました。MCP や PRD などでコンテキストを渡すことは重要ですが、この空気感のようなコンテキストを渡すことも有効だったのではと思います。
あんまり楽しかったので今度鹿児島でも開催します！
https://kagoshima-mk.connpass.com/event/353757/
三宅悠介
お題の感想と重なりますが、お題や時間の制約を踏まえるとAIとやらなければとても完遂できないような部分へ、自分の速度を超えて、高速に切り込んでいけたという経験が非常によかったです。 身体操作を伴うスキル（短距離走やピアノ演奏）向上の方法論として、上級者の世界を体感する方法がとられることがあると聞いたことがあります。例えば、個人の経験になりますが、短距離走では、単純に足の速い人から引っ張ってもらうと、足の動かし方が変わるのを感じます。この感覚を忘れないように走ることで独力でもタイムが改善したりします。黒閃もこんな感じかもしれません。閑話休題。 この大会でも、お題の特性から、知らず知らずに自分に課していた速度を一度振り切る経験ができたと感じます。 戦略については、このスピード感を忘れないように適したものに組み立て直していかなければなあと盛り上がっているところです。
質問7: 他の選手から学びはありましたか？
Ā−YA
なんと言っても、まず真っ先に取り入れたのはよしこさんの進捗管理リストでした。 あるのとないのとでは、進行のしやすさと制作物の安定性がまったく違うことを、早速試してみて痛感しました。
そして、てつをさんのカラフルで思わず触りたくなるUIも非常に印象的でした。 もし自分が子供だったら、楽しくてずっと触っているだろうなと思えるくらい素敵なデザインでした！
てつを。
先にドキュメントを整理して、タスクベースでLLMに管理させている選手がいてめっちゃいいなと思いました。
どすこい
わりと自分で手がいっぱいになってしまったので、あとから見返しました。 結構人によって方法ややりたいことが違って見えて学びになりました！ 社内でモブVibe Codingをすると面白いかもしれないとちょっと思いました。
yoshikouki
正直自分のことで手一杯だったのであまり周りは見えていなかったのですが、「人間がボトルネック」という課題に対して音声入力で対応している参加者がいて、Vibe 具合が良いなあと思いました。
三宅悠介
上記の（私からすると）加速状態が常になっている方を何人か見かけました。自身も、方法論どうこうではなくこのスピード感について、常駐戦陣、全集中・常中でものにしていくぞ！と刺激を受けました。
質問8: 最後に一言！
Ā−YA
「すごい時代がやってきた」と本気で思っています。今の生成AIは「ちょっと試してみる」だけでも新しい世界が見えるので、少しでも興味があればぜひ触ってみてほしいです。 私自身もVibe Codingを試してみて感動して、課金して本格的に作りはじめたのが、ほんの1週間前のことでした。 それでも、簡単なWebアプリであれば短期間で形にできるようになりました。
もちろん、サーバーやプログラミングの基本的な知識は多少必要ですが、生成AIがあればわからないことも丁寧に教えてもらえます。 生成AIを日常に取り入れるかどうかはその人によりますが、一度試してみてから考えても遅くはないと思います。
てつを。
Vibe Codingは、不確実な状態から手を動かせるという点で強力な手法だと感じています。
ただし、それによって生まれるコードは、意図や背景が欠けたまま積み上がることも多く、動作していても信頼できるかどうかの判断が難しくなる場面があると思っています。（最近PAR RAGという、「ずれの蓄積」を防ぐことを目的とした探索手法の記事を読みました。）
実装の正しさをどう担保するかについては、テストや観測に加え、そもそも「何を実現しようとしていたか」を記録しておくことのほうが重要になると考えています。
コードの評価は、書かれた内容だけでなく、その前提との整合性をよく見る必要があると今回の競技Vibe Codingで感じたからです。
また、1日1万行のようなスケールでコードが生成される状況になると、もはやコード単体を見ても意味が取れません。
意図・背景・文脈を含めた対話ログが主な参照点になると考えています。
Vibe Codingは便利ですが、それによって生まれる曖昧さとどう向き合うかが、今後の大きな課題なんだろうな、と感じました。
どすこい
VibeのVibesが上がりました！選手としても、運営としてもぜひまたしたいです！
yoshikouki
Vibe Coding を例に、LLMとそれを活用したツール群によって、開発プロセスの少なくとも一部分は大きく変わったように感じています。それは 日本初!?「Vibe Coding研修」を2025年新卒研修の目玉として実施します - Pepabo Tech Portal にも記載してあるとおり、「圧倒的な量」が大きな一因としてありそうです。
では、新しいパラダイムがもたらす最も劇的な変化とはなんなのか。それは、AIが生み出すコードの「圧倒的な量」です。Cursor AgentやClineのようなツールを使いこなせば、1日に1万行、あるいはそれ以上のコードを生成することも、もはや非現実的な話ではありません。
この変化が世界規模で起こっている事実を思えば、ビジネスやそれを取り巻く環境の変化が今以上に早くなるのは明らかです
変化に迅速に対応するためには、変化しないことを見定め “続ける” ことも同時に求められます。前提が変わったため大きな変化が起こっている状況で、しかし変わらない部分もある。そこに本質的な価値やレバレッジの支点が存在するように思います。 一方で、変わらないと思われていた部分も数年後には変わる可能性があることを忘れずに見定めていきたいです。
開発プロセスにおける「変わらないこと」は何か。「変化しやすい設計」、「仕様を保証するためのテスト環境」などは現時点で重要であろうと考えています。これらと Vibe Coding のような開発プロセスを融合させた取り組みを一つ一つ実践していきます。
この大きな流れの渦中にいれることをとても嬉しく、楽しく感じます。
三宅悠介
さて、AIコーディングが前提となれば、今回のお題の状況が常に発生することになるでしょう。 わからないものを扱うこと、そしてそのわからないものの動作をどう保証するか。 これが、1万行/人/日の速度で実行されたらどうなるかと言ったことに考えを広げなくてはなりません。
今回のお題を例にすると、「動いた」以上を私が判断することができませんでした。 この判断を分類すると、鳴っているコードが本当にそうなのか、そのコードがダイアトニックコードなのかといった点での、そのアプリケーションを作る上での敢えて述べるまでもない当然としての非機能要件と、「自然なコード進行や雰囲気のある演奏」といった機能要件になるかと思います。
非機能要件（Webアプリケーションとしての基本要件も含む）については、その分野に取り組むものとして当然に知っておくべきこととして、AIが逸れないように明確な基準を提示（もしくは合意）して、作り上げていく必要があるでしょう。 一方で、機能要件については、どう担保することができるでしょうか。 ここについては、アプリケーションやサービスの利用者からのフィードバックこそが答えになると考えます。 私自身も、今回のお題では最初の動くものを見てから具体的な改善の方向性を言語化することができました。
ここまでの方向性を振り返ると、定量的に基準化できるものは自動テストなどで動作を保証し、定性的な評価が必要な要件は利用者からのフィードバックを受け取るという、従来の方式の延長線上にあるように思えます。 よって着目すべきはその量なのだろうと考えられます。 ここで、問いかけを逆にしましょう。 つまり、1万行/人/日の速度で開発しなければ、わからないものの動作を保証できないし、扱えないのではないか？ということです。 利用者の頭の中という「わからなさ」へ寄り添っていくには、継続的なコミュニケーションが必要です。 コミュニケーションを継続するためには、利用者も運用者にも負担のない方式が求められます。 従来の方法では、至る所に人間が関与せざるをえませんでした。 コーディングをはじめとしたシステム運用を取り込むことでこれらの負担が取り除かれ、継続的なコミュニケーション、つまり1万行/人/日の速度で出力される改善とフィードバックの反映によって、利用者の頭の中という究極のわからなさとのズレを補正し続けることができるでしょう。 もちろん、これらを支えるエンジニアリングの難しさ（テストの自動生成やデプロイ高速化）は、挑戦しがいのある課題です。 ただ、なぜこのようなフィードバックや大量のコード出力が重要なのか、その前提として「わからなさ」への挑戦が価値につながるということを改めて考えました。
以下はペパボ研究所のコンセプトである「なめらかなシステム」についての考察です。今回のわらないを前提としたシステムの必要性の議論につながっています。よければご覧ください。
おわりに
今回は音楽理論の理解が必要といった難しいお題であっても、Vibe Codingによって１から作り上げられることが示されました。また、Vibe Codingは職業としてのエンジニアでなくても、ものを作る力を与えてくれる強力な武器であることがわかったと感じています。
また、大会の中で、参加者同士や、観戦者との間でVibe Codingのやり方に関する気づきがそれぞれにあったのが発見でした。手で行うプログラミングと同様に、Vibe Codingであってもモブプロのような形で行うことで知見の交換をできそうだなと感じました。
第一回は大成功だったので、ぜひ第二回も行おうと思っています。Vibe Codingでの新たなコーディングに挑戦したい方、ぜひ↓からご応募ください！