---
title: "AI Coding（Vibe Coding）の体験と課題〜Cloudflare・Hono・Stripe開発から見えたもの"
date: 2025-03-18
categories: "雑記"
url: "https://hidetaka.dev/ja/blog/1297"
---

こんにちは、岡本です。AWSやCloudflareを活用したサーバーレスアプリケーション開発、Stripeの決済統合、ReactやHonoといった最新技術に携わる開発者として、日々新しいツールや手法を試しています。今回は、AIツール「Cursor」を活用した「Vibe Coding」の体験と課題について、Cloudflare WorkersやHono、Stripeを使ったデモアプリ開発を通して紹介します。

## 1\. Vibe Codingとは何か

「[Vibe Coding](https://en.wikipedia.org/wiki/Vibe_coding)」という言葉は、AIツールを使って自然言語で指示を出し、コード生成やデバッグを自動化する開発手法を指します。実はすでに[Wikipedia記事](https://en.wikipedia.org/wiki/Vibe_coding)も英語では作られており、Google翻訳にかけると次のように定義されています。

> [この概念は、 LLM](https://en.wikipedia.org/wiki/Large_language_model)に依存するコーディング手法を指し  
> 、プログラマーは自然言語による記述を提供することで、手動で記述するのではなく、実用的なコードを生成できる。

このアプローチは、開発者が細かいコードを書く負担を軽減し、アイデアや設計に集中できる点で注目されています。

## 2\. Cursorを使ったVibe Codingの体験から感じたこと

「[AIコーディングは、AIに運転席を譲る覚悟が必要だ](https://zenn.dev/mizchi/articles/all-in-on-cline#%E3%83%89%E3%83%A9%E3%82%A4%E3%83%90%E3%83%BC%E5%B8%AD%E3%82%92%E8%AD%B2%E3%82%8B%E5%88%A4%E6%96%AD%E3%81%A8%E8%A6%9A%E6%82%9F)」という意見がありますが、やはり長年開発者をしていると、ハンドルを手放すのにはまだまだ勇気が必要です。とはいえこのまま置いていかれるのもキャリア的によくないなと思い、個人的に作ってみようと思っていたアプリ開発のハンドルを譲ってみることにしました。

アプリとしては、LINEと連携させた読書メモサービスで、LINEのチャットにメモを送信すると、それをウェブから表示・検索できるというものです。

![](https://wp-kyoto.cdn.rabify.me/wp-content/uploads/2025/03/44eb39339db6e0d3442f43d5c9c781dc-20251101220132-1024x702.png?&d=1140)

開発期間は1日半くらいで、サブスクリプションの決済やマイページ実装まで完了しています。

### 長所: とにかく早く試せる・失敗できる

実際にやってみて感じた最大のメリットはこの試行回数です。「AIエージェントの肝要は試行回数を大幅に増やせること」という話を以前教えてもらったことがあるのですが、「これがそうか・・・」となりました。

というのも実はこのAIコーディング、3つくらいのアプリを同時に開始させていました。その中でビルドエラーが治らなかったり、いつまで経っても要件を満たすアプリにならないものも出てきていて、読書メモアプリが唯一課金機能実装まで走り抜けたという背景があります。この辺りは要件が複雑だったり、自分もあまりよくわかっていない技術選定を敢えて行わせてみたりしたこともあり、「AIコーディングがダメだ」というよりは「**事前の要件・仕様次第でリリースすらできないことがある**」という捉え方をすべきだと思います。

事前準備の内容次第で結果が変わると言うことは、1つのサービス・要件に対する開発でも敢えて3つも4つものコーディングパターンを試すことができます。MVPを志向するものから、できるだけB2Bの大口契約を目指すような要件、あるいはデザインから決めるかDBやAPIから決めるかもありそうです。このような進め方のシミュレーションにもAIは使えそうだなと感じました。

## 課題: みんなが知らないことは、AIも知らない

一方で「まぁそうだよね」という気持ちと、「結局この分野ではまだまだ人間優位か」と思った点はがこれです。**「公式のドキュメントやGitHubのソースコードをよく読むと見つかるベストプラクティス」やほぼ間違いなく実装してくれません**。人間でも難しい領域ではありますが、技術カンファレンスなどで情報収集すると、「こういうやり方をするのがよい」とアウトプットされていたり、「ここでハマるから気をつけな」のような情報を得られることがあります。ただ、それらのアウトプットを重み付けすることが難しいためか、どちらかというと初心者かよく言って中級者がやるだろうなという実装をAIは仕上げてきます。実際にみたコードなどは、後半の有料部分で紹介します。

この点については、開発者が手動でレビューし、修正を加える必要があります。そのため、運転席を譲ったとしても、やはりまだ助手席で教習車のように補助ブレーキを踏む準備はしておく必要がありそうです。

## 対策案: AIの協働を仕掛ける

知らないことはできないというのはもはや仕方ないことです。ただ、人間社会における[フェイルセーフ・フールプルーフ](https://www.kaonavi.jp/dictionary/foolproof/)のような仕組みはできるはずです。今回試していて良かったなと思ったのは、Pull Request駆動開発によるGeminiでの検知です。GitHubのリポジトリには、[Gemini Code Assistを利用した自動レビュー](https://developers.google.com/gemini-code-assist/docs/review-github-code?hl=ja)を設定しています。そのため、AIにコードを書かせた際は、pull requestをGitHub上で開いてからマージするようにしました。その結果、脆弱性のあるコードが含まれていた場合や、「後でやる」とコメントだけ残されている実装などをGeminiがレビューで指摘してくれました。

![](https://wp-kyoto.cdn.rabify.me/wp-content/uploads/2025/03/4811b499be1d93d2f9db3b64b53fa889-20251101220134-1024x510.png?&d=1140)

このほかにも、Claudeを利用して事前にある程度技術的な要件を整理しておくことも効率的でした。これによって初回のAIコーディングで50%くらいまでのプロダクトが一気に出来上がります。また、作業がひと段落するたびにやり残しを整理させることで、セッションを新しくしたときにコンテキストを引き継げるようにも実装できました。

![](https://wp-kyoto.cdn.rabify.me/wp-content/uploads/2025/03/6f8cb87e04e17734ce66c2b8d03eaac0-20251101220136.png?&d=1140)

まだまだ手探りな部分のあるAIコーディングではありますが、ここまでのボリュームを2日足らずでできるとなると、「まだ早い」と様子見してる場合でもないのかもしれません。このプロダクト自体は、自分で使ってみて更新するステージですが、ある程度整えばリリースしようと思います。

## \[おまけ\] 今回のコーディングで見かけた、気になるStripe系の実装２つ

元StripeのDevRelの視点から、「多分この実装は他のPJでも高確率でやるんじゃないかなぁ・・・」と感じたものを2つピックアップしてみました。

### Stripeの商品・料金取得処理が富豪的な実装になる

指定したプランを数件返すAPIや料金表を実装する時、Stripe上にあるデータを参照するのが効率的です。ただしAIに任せたところ、次のようなコードが出てきました。

```
await stripe.products.list({ limit: 100 }).then(({data}) => data.filter(product => {
  return product.metadata.id === targetPlanId
})
```

理論上確かにデータは取得できるのですが、Stripe上に商品データが101件以上あったらどうするのかが漏れていたり、パフォーマンスの悪い実装であることが一目でわかるコードです。そのため関数やコメントを手で以下のように修正し、これに該当する形へ修正させる指示が必要でした。

```

// 製品を検索
const {data: prices} = await stripe.prices.list({
  lookup_keys: [lookupKey],
  expand: ['data.product']
});
let product = prices[0].product;
if (!product) {
  throw new Error('製品が見つかりません');
}
if (typeof product === 'string') {
  product = await stripe.products.retrieve(product);
}
if (product.deleted) {
  throw new Error('製品が見つかりません');
}
```

ここでのポイントは、「`lookup_keys`を使った検索」がさほど知られていないということです。確かにStripeのドキュメントにはあるのですが、[数行のみの言及](https://docs.stripe.com/products-prices/manage-prices#lookup-keys)です。これを見つけられるのは、よほどStripeに精通している人か、その人に教わったことがある人しかいないでしょう。

### Cloudflare Workersの特性に合わせた実装

もう1点Stripe周りで「知らないと無理じゃないか・・・？」と思ったのはWebhook系統です。Webhook APIを保護するための署名検証メソッドが、このように実装されていました。

```

/**
 * Webhook署名を検証
 */
constructEvent(payload: string, signature: string): Promise<Stripe.Event> {
  return this.client.webhooks.constructEvent(
    payload,
    signature,
    this.config.webhookSecret
  );
}
```

一見問題のない実装に見えるのですが、実はこれCloudflare Workersでは動かないのです。デプロイして実行させると、次のようなエラーが発生します。

```
{"message":"SubtleCryptoProvider cannot be used in a synchronous context."}
```

エラーメッセージの通りなのですが、Cloudflare Workersなどのエッジ環境で実行するには、非同期処理版のメソッドを使う必要があります。そのため本来は以下のコードにしないといけません。

```

/**
 * Webhook署名を検証
 */
constructEvent(payload: string, signature: string): Promise<Stripe.Event> {
  return this.client.webhooks.constructEventAsync(
    payload,
    signature,
    this.config.webhookSecret
  );
}
```

これも[Cloudflareのブログにさらっと紹介されているだけのTips](https://blog.cloudflare.com/ja-jp/announcing-stripe-support-in-workers/)です。そのため、数多くのドキュメントの中に埋もれてしまったのか、AIはこの実装を提出することができませんでした。

## 譲るからこそ、ちゃんと見る

「運転席を譲る」ことは、「運転やそれに伴う責任も完全に任せること」ではありません。実際の車においても、[所有する車で事故が起きた場合は運転者が自身でなくとも責任が多少なりと発生](https://www.carsensor.net/contents/horitsu/category_66/_3102.html)します。それゆえに、AIコーディングをするためには、逆説的かもしれませんが、自身が生成されたコードについて判断できるようになる必要があるでしょう。もしくはそれをリスクとして許容できる体制を作るかですね。