個人開発でCursorのProプラン契約して使ってみた感想

個人開発でCursorのProプラン契約して1ヶ月使ってみたので感想です。

作ったのはこの商略AIというサービスです。 https://shoryaku.net/

モデルごとのトークン使用量

Cursor社の提供モデル（GrokとComposer）と他社のモデル（GPT、Claude、Geminiに加えて中華製AIモデルのKimiやMeta製モデルのMuseも使える）んですがCursor社のモデルと他社のモデルとでそれぞれ利用制限がかけられています。

使った感じ他社モデルはすぐ無くなるんですがGrokとComposerの利用制限は全然無くならなかったです。

ただ他社モデルのSolとかOpusとかKimiといった高推論モデル使いたい場面は結構多いのでこの体系は個人的にはあんまり嬉しくなかったです。

Grok、Composerは悪くないんですが機能のプランニングとか事業計画の壁打ちとか重要な判断が必要な場面ではやっぱり弱いのとUIが崩れたりバグったりする割合はやっぱりまだGPT、Claudeのモデルに比べると多い感じがします。

時間あたりの利用量制限

Codex、ClaudeのProプランだと5時間制限＋週辺りの制限で利用量制限されるんですがCursorのProプランの場合は1ヶ月単位でのトータルのみです。

CodexとかClaudeだと利用量制限のリミット周期が短いので結構1日中気にしてしまうというかリセット解除されたらやらせることをメモってモデルやセッションうまく管理してちょうどよく収まるように神経使うんですがCursorはそれないのは人によっては嬉しいかも。

ただ1ヶ月単位だと期間が長すぎて残りの日数とトークン残量計算してタスク見積もるのが難易度高い気はします。契約期間開始後に一気に使ってしまうとリセットまで日数が空きすぎて開発が止まってしまうなど。

個人的にはリセット周期が短いCodex、Claudeの方が合ってるかなー。という気はしてます。

個人開発で「商略AI」というAIでマーケティング分析ができるサービスを開発しました。初期立ち上げの時に考えたこと

個人開発で商略AIというマーケティングAIサービスを開発しました。Stripeで月額課金も実装したのでちゃんと売ってくつもりで作ってます。

shoryaku.net

自社の事業情報(商品URL、予算など)を入力し、Auth認証で外部サービス（Instagarm、Google Analytics、Google Search Console、Google広告、Meta広告）と連携するとその情報を取得してAIで解析して最適な施策を提案するサービスです。

初期立ち上げ時に考えたこと

サービス命名

SEOとドメイン取得の観点で世の中に出回ってない命名にはしようと思ってました。

複数言語（英語、スペイン語、ギリシャ語とか）のマーケティング用語組み合わせて造語作っておしゃれな命名にする、とかも考えたんですがむしろややダサいくらいが嫌味な感じなくていいかな。と思い日本語の古い言葉（商略）からとった命名にしました。

インフラ

金かけずに開発したかったのでFirebaseにしました。今の時代だとCloudFlareなんかも個人開発のインフラの選択肢として人気ありそうですが、Firebaseは過去にも使ったことがあり慣れてたのとAI IntegrationなどFirebase外のサービスもGCPに統一した方が管理が楽と思ったので。

フレームワーク

フロントエンドはReact + Vite、バックエンドはHonoです。これは現時点で割とスタンダードな選択だと思います。

料金体系

Stripeで決済機能実装してます。現時点でライトプラン980円から加入できます。

売り方

これはまだ試行錯誤中ですが、AIでブログ執筆のコスト大きく下がったのでうまいことAIで品質高い記事を作る術を探してこのサービスのブログページに記事量産してSEOで流入させたいと思ってます。

shoryaku.net

今後

一旦一通り実装してデプロイして動くようになってますがまだ機能は作り込んでいく予定です。

cmux、Herdrで複数セッションAIコーディングで試した感想

Rebuildで話題に出ていたHerdrとcmux導入して先週それメインで開発してみたんですが結構体験いいかもです。

rebuild.fm

cmux.com

herdr.dev

Codex、ClaudeCodeのMacアプリに比べて

• slash commandで作業進めるのが快適。定型作業やセッション管理、使用モデル切り替えなどを効率よく進められる
• 同じターミナルのUIでタブ分割して進捗眺めながら別作業できる
• Codex、ClaudeCodeを同じUIで操作できる

というメリットは感じました。

Codex / ClaudeCodeで12セッション並列で動かして大規模リファクタリングしてみた

業務でテストコード除いて6.4万行あるNest.jsの大規模機能を12セッション同時に動かして一気にリファクタリングしてみました。その時の作業環境と振り返り書いてみます。

前に8セッション同時並行に走らせて新規機能開発してみたんですが、今回機能要件は変わらずテストコードも割と充実している状態でのリファクタリングなのでもう少し激しいAIコーディングできるんじゃないかと思い試してみました。

ikeyu0806.hatenablog.com

リファクタリング前に感じていた課題

• コーディング規約でフォルダごとに定義した責務を無視した実装が散見される。
  • ドメインロジックはserviceレイヤーに保存する。repositoryレイヤーにDBサーバへのリクエストを処理するコードを集約する、TypeScriptの型はtypeフォルダに入れるなどの規則が無視されてなんでもservicesレイヤーに実装され1ファイルが肥大化するなどの状態
• コーディング規約で定めた行数を大きく超過するコードが10以上ある。最大6000行越えのファイルも存在していた
• 1フォルダに数十ファイルを保存していて見通しが悪い。適切にサブフォルダを作れていない

作業した時の背景、状況など

• まだ社内検証フェーズのサービスなのもあり割とレビューは甘めの体制
• まだ本番環境で本格的に使われていない機能だったのと、例えば人命に関わるような厳密なテストが要求される機能ではなかったのである程度実験的な作業ができる背景ではありました。
• 職場ではCodex、ClaudeCode共にエンタープライズプランで契約しており月単位で個々の上限が管理されているんですが月末に割と使えるトークン量がありました
• マージしても即座に本番環境には反映されないので割と雑にマージしてある程度の変更が入ったらまとめて事後レビューする進め方は可能
• CIでテスト、フォーマット、lintチェック、セキュリティチェックは動く状態

作業始める前の事前準備

• プロジェクトを識別しやすい任意の別名でgit cloneしまくる
  • git clone {レポジトリURL} {フォルダ名}
• テストコードをなるべく手厚く用意しておく。要件と既存コードをAIに読ませてテストコード追加できる余地があれば追加させておく

作業環境

• CodexはMacアプリを使いました。作業中のセッションをピン留めできるUIが今回のような使い方をするにおいて快適
• ClaudeCodeはターミナル（Ghostty）で画面分割したタブを複数作ってそこでCLIで動かして管理してました。

プランニングと実装

プランニング

• 観点ごとに推論レベル高のGPT-5.6 SolとOpus4.8にプランニングさせました
• プロジェクト内でgit管理されているコーディング規約の他、自分が感じていた課題をまとめてプロンプトに打ち込んでプランニング開始させる
• 並列作業しやすいようタスク分割して推奨実装手順をアウトプットさせる

コーディング

• トークンがもったいないので本来はGPT TerraかSonnetあたりにコーディングさせた方がいいと思うんですが割と余裕あったのでOpus使ったりはしてました
• 同じ機能なのでなるべく起こらないようにプランニングさせつつもConflictはやっぱりかなりの頻度で起こりましたがAIはConflict対応問題なくやってくれるので気にせずに並列で動かして発生したら都度直す

レビュー

• 職場でPull Request作った時にCoderabbit、CodexでAIレビューする環境ができておりマージに人間のレビューはマストではなくなっていたので自分でざっとみてガシガシマージしていきました。
• CodeRabbitとCodexのレビューはSkillで対応していく
• githubのdiffではなくローカルのエディタでレビューしたい派なんですがエディタで作業中のセッションごとの各フォルダに対象切り替えて見に行くのが面倒だったのでレビュー用のフォルダを用意してそのmainブランチに変更後のコードをどんどんpullしてレビューして直したい点あればその内容まとめてまたセッション作って直していく

感想

• めちゃくちゃ疲れます。情報量が多いのと処理対象の情報の切り替えが激しく脳が消耗している感がすごい。
• コードの状態は短時間でかなり良くなった気がします
• この使い方すると生産性はAI以前と比べて10倍くらいにはなっている気はします。github見ると1日で241コミットしていた。
• 正直時間あたりのアウトプットが多すぎてめちゃくちゃ厳密なレビューはできていないので、人命に関わる医療サービスとか金融、決済系のサービスでこれやるのはちょっと怖いかな、という気はします。

CodexでGPT5.5、5.4、5.4 miniを使った開発の振り返り

これを書いている時点で2026年7月11日ですが昨日GPT-5.6（Sol・Terra・Luna）がリリースされたので今後はそれを使っていくことになろうかと思いますがGPT5.5、5.4を使っていた開発期間の振り返り書いてみます。

GPT5.5、5.4を使った開発の振り返り

GPT5.5の方が高性能なんですが割とタスクによっては5.4や5.4miniに切り替えた方が合理的な感じはしました。

5.5で実装させると確かに動作確認した時の手戻りやレビュー時の違和感やCIの失敗（テストコード、linter、formatter）は5.4よりも少ないんですがAIの動き眺めてるとちょっとした変更でも頻繁にlintやテストコード走らせて念入りに確認してるようで5.4よりも時間食ってる感じがあります。

5.4を使ってとにかく一旦実装作業をAIにやってもらってgit pushしてgithub上でCI走らせつつ自分がコードレビューしたりUI上で動作確認する進め方をした方が5.5を使うよりも早いな、と感じることは割とありました。

あとコンフリクト解消したりgit commitさせたりドキュメントの簡単な更新させたりといった軽量タスクは5.4miniを使うとより早い感じはあります

なので5.5でプランニング→5.4で実装→コンフリクト解消やgit commitはmini、といった切り替えをして進めるのが開発の効率いいかな、という感想です。

GPT5.6以降

リリースされたGPT-5.6は急に命名のテイストが変わって高性能モデルは「Sol」、バランスモデルは「Terra」、軽量モデルは「Luna」という分類になったのでプランニングはSol、実装はTerra、簡単な作業はLunaで進めていく形になる見込みです。

Codexで8セッション同時並行に動かして機能開発してみたので振り返り

勤務先の会社がOpenAIとアライアンスを組んでいて無料で使える期間があり、せっかくなのでトークン制限気にせずに使おうと思い、8セッション同時並行でCodex動かして1つの機能開発してみた時の振り返りです。

実装時の状況

• 開発対象はNext.js / Nest.js製のWebサービス
• バックエンドの構成はモノリス
• バックエンドはVertical Slice Architectureっぽい機能単位で分かれたようなフォルダ構成
• フロントエンドコンポーネントのフォルダ構成はfeatureパターン
• 開発担当していたのは同じ機能内で100近い細かい分岐が発生する要件。大分大規模なコードベース、ロジックの機能開発

開発手順

• 同じプロジェクトを8つローカルにgit cloneしてそれぞれcodexに別のプロジェクトとして追加
  • 1つのフォルダで複数セッション立ち上げてそれぞれ別のブランチで作らせることも可能ですが管理しにくそうだったので別フォルダで作業させました
• 大体ファイル差分が30前後のpull requestを作って1つずつレビューしてマージ。次のPRもコンフリクト対応しながらレビューしてマージを繰り返す

感想

• 流石に1セッション立ち上げて1つPR作ってマージしてから次のに着手するよりは大分作業進むの早い感じがしました
• コンフリクトは激しくなりますがAI使えば低級モデルでもコンフリクト解消は大体うまく解消してくれるのでそこまで気にならず
• 結局人間のコードレビューの速度は上げられないのとUIで動作確認すると期待通りにならないところはあって、そこはボトルネックになって結局全部マージするのに時間かかりました
• 今回みたいに似たような処理を量産する要件であればレビューで見るポイントも似通ってくるので人間の脳みそが認知不可に耐えられる感じはしましたが全然性質の違うタスクをこのやり方で進めると人間の脳ではレビューするの大分きついかも
• 1つのセッション開発で発生した問題を他のセッションでも同じように修正依頼出さないといけない状況が発生したので、ある程度知見が溜まってから再発しないようにskillを作るとかプロンプトの情報量を充実させて1つ1つ作業した方が無駄にトークン使わないし手戻り少ないかな、という気はしました
• というのでトークン消費は激しくなるので上限厳しい開発環境には向いていなそう。際限なく使える状況では割とアリなやり方な気はしました

Codexで差分ファイル行数が5万行近い機能改修を行った時の振り返り

CodexでNext.js/Nest.js構成のWebサービスに機能改修で5万行近い規模大きめのPull Request（自分の経験としては1 Pull Requestでは過去最大のdiff）を作ってみたんですが、大分効率悪いやり方をしてしまった感がありました。

基本PR粒度でcodexのセッションを切り替えているので今回大きすぎるタスクをPhase分割せずに1セッションで進めたんですがこれも良くなかった。

振り返りメモです。

• セッション
  • セッションを切り替えないとノイズが増えてコーディング結果の精度がどんどん悪くなってくる。結果手戻りが多くなり大きく作業時間増えてしまった感ありました
  • 古いコードの状態も参照しているような動きをしていた感じがあります
• Pull Request
  • AIコーディングで不注意にガシガシ変更積み重ねてdiffが大きくなりすぎるとPull Requestのレビューが追いつかなくなります
  • 結局テストパスして正常な動作確認できるがコードは汚い状態でマージして、その後時間かけて見返してリファクタリングのPR5つ出す羽目になってしまった

あとこれは大規模改修に限った話ではないですが推論レベルを最大にしたまま設計、コーディング、Lint、テストコードのチェックやCoderabbitの対応まで全部やらせていたのは効率悪かったです。

「実装後にテストコード、ESLint、PrittierチェックとCoderabbitお願い」みたいなプロンプトを推論レベル高い設定で投げるとかなり結果が返ってくるのが遅くなります。場合によっては作業終了に数時間かかる。

設計は推論レベル最大、コーディングは推論レベル中、Lintやテストコードは小など用途によって切り替えて作業させないとAIの思考時間が長くなりすぎて時間が溶ける感じがあります。