AIより先にWordPressが強敵だった。Cursorを諦め、ChatGPT Codexを選んだ「非エンジニアの生存戦略」

CursorではなくChatGPT Codexを選び、GitHubと連携してWordPressツール開発を行う非エンジニアのデスク風景 AI
本サイトはプロモーションが含まれています

前回の記事では次のことを書きました。

なぜOpenAIは競合に出資した?天才たちが認めた最強エディタ『Cursor』が非エンジニアの救世主になる

前の記事では「GeminiとCursorの2課金で行く!」とある程度決めていたのですが、やっぱり変更しました。

というのも、実際に私が一番苦しめられたのは、AIの性能差ではありません。WordPressという実行環境そのものだからです。

私は「WordPressの固定記事に貼るだけで動く単一HTMLツール」を作っています。WASMも組み込もうとしていました。ところがWordPressにコードを貼った瞬間から、ツールが“こちらの想定通りに”動いてくれないことが多かったんです。

この記事は、私がなぜ ChatGPT Plus を使うようになったのか、そしてなぜ(少なくとも今の段階では)Cursorではなく、ChatGPTブラウザ版のCodexを軸にする結論に至ったのかを、正直にまとめます。


私がハマっていたのは「AI」ではなく「WordPressの干渉」だった

単一HTMLツールを作るのは、理屈の上ではシンプルです。HTML+CSS+JavaScriptを1枚にまとめて、固定記事に貼るだけ。

でも現実には、WordPress(テーマやプラグインを含む)が記事内のHTMLにいろいろ干渉します。その結果、「昨日まで動いていたものが、今日突然壊れる」みたいなことが起きます。
そして、これが本当に消耗します。


実際に起きた“壊れ方”が、地味にキツい

ストレスを感じてハンマーを持ち、壊れたWordPressサイトを修理しようとしている人物のフラットイラスト。一つのバグを叩くと、画面の別の場所から別のバグが飛び出してくる。<h3>や<bug>のような壊れたHTMLタグがランダムに表示されている。WordPressのロゴが見えるが、グリッチがかかっている。スタイルはクリーンでモダン。完全な白背景。 ここからは、私が実際に遭遇した症状です。非エンジニアの自分には、原因を完全に説明できません。ですが、起きたことははっきりしています。 ツールの一部分が突然H3で囲まれて文字が巨大化する

どのブロックが原因か、何がどう変換されたのかを正確に説明するのは正直難しいです。
ただ、ツールの一部分が突然H3タグで囲まれたような状態になり、文字がいきなり大きくなったり、見た目が崩れたりしていました。

「自分はH3なんて入れてないのに、なんで?」という感覚で、原因の特定がかなり辛かったです。

デザインだけ直したつもりなのに、ドラッグ&ドロップが突然死ぬ

これが一番精神に来ました。「見た目だけ整えて」と依頼したのに、なぜか機能が死ぬ。

しかもChromeでは動くのにSafariでは動かないという、「直ったと思ったら別ブラウザで死んでいる」パターンです。

別の箇所を修正したら、SNSのシェアボタンが動かなくなる

ドラッグ&ドロップと同様に、別のところを直したはずなのに、SNS共有ボタンが反応しなくなったことがありました。

触っていないはずの部分が壊れる。
これがWordPress上で単一HTMLツールをやる難しさだと痛感しました。


直すと別が壊れる。この無限ループで疲れた

ここまでの話に共通しているのは、これです。

  • どこかを直す
  • すると別のどこかが壊れる
  • また直す
  • するとまた別が壊れる

このループが続くと、「いま直しているのは正解なのか?」が分からなくなります。
疲れます。普通に。

ここで私は気づきました。

「AIを変える」より、「作業の進め方(運用)を変えないと終わらない」と。


正直に告白:私はCursorは“無料版だけ”で、有料課金はしたことがない

2つの開発環境を比較するアイソメトリックイラスト。左側には、「Cursor (Local IDE)」とラベル付けされたノートPC上の複雑なダークモードIDEインターフェースがあり、多くの混乱したパネルやコード行、値札アイコンがある。右側には、「ChatGPT Codex (Browser)」とラベル付けされたシンプルなチャットインターフェースとコードブロックを表示するクリーンなブラウザウィンドウがあり、シンプルなGitHubロゴのクラウドアイコンに接続されている。非エンジニアのキャラクターが楽しそうに右側のブラウザの道を選んでいる。完全な白背景。

ここは、ちゃんと書いておきます。 私はCursorを使ってはいましたが、無料版ユーザーで、有料課金をして本格運用した経験はありません。

本当は、Cursorに課金して、IDEの中でバイブコーディングを完結させたかったです。 でも調べて進めるうちに、少なくとも現時点の自分(非エンジニア)にとっては、こう感じました。

  • IDE側の概念(プロジェクト、ファイル構造、実行、依存関係、差分適用)を理解しないと、丸投げが成立しにくい
  • 「何が起きているか分からない状態」でAIにPC内の操作権限を渡すのは、逆に怖い
  • そして私の戦場は、多ファイルのアプリ開発というより、WordPress上で壊れない“単一HTML”だった

つまり、Cursor有料で本気のバイブコーディングをやるのは、非エンジニアの自分にはハードルが高すぎるという結論に達しました。

Cursorを否定したいわけではありません。ただ、私には「導入の順番」が違った、という話です。私の知識や技術が向上し、もう少し本格的にバイブコーディングを理解できるようになったら、Cursorを使いたいと本気で考えています。


だから私はChatGPT Plusを課金して、ブラウザ版のCanvas×Codexに寄せた

私はこれまで、

  • Gemini(有料)で相談
  • Claude(無料)でコード生成
  • ChatGPT(無料)とGemini(有料)で評価
  • Claudeに修正させる

というループを回していました。無限コピペ地獄です。
でもこのやり方は、WordPressのような“実行環境の罠”があると収束しにくいです。

理由は単純で、文脈が分断されるからです。

そこで私はChatGPT Plusを導入して、次の分業に寄せることにしました。

  • Canvas:判断と整理(何を直すか、どこを触らないかを決める)
  • Codex:実装(決まった修正を最小差分で仕上げる)

Canvasは、文章やコードの「編集と改稿」に向いたUIで、やりとりを“育てる”のに使える。(OpenAI Help Center)
そしてCodexは「コーディング用エージェント」として、コードベースを読み、タスクを隔離環境で処理しながら作業できる。(OpenAI)

ちなみに、なぜClaude Codeではないかというと、私が見ている範囲ではエンジニア界の中ではCodexの方が評価が高いからです。ここが非常に面白いところで、非エンジニア界ではClaude Codeの方が評価が高いんですよね。

ここを話し出したらまた長くなるので、別の記事で。


なぜCodexならWordPressと戦えるのか:決定的な違いは「記憶の置き場」

Geminiや無料版ChatGPTとの違いを、私なりに一言で言うと「記憶の置き場」です。

通常のチャットは、会話が流れると前提(触ってはいけない部分、禁止事項、合格条件)が抜けやすい。この「前提の抜け」が、WordPressみたいな繊細な環境だと、致命的になりがちです。

一方、CodexはGitHubとつなげると、READMEやルール、コードを“リポジトリ上のファイル”として参照できます。

  • 通常のチャット:会話の流れで前提が抜けやすい(ブレやすい)
  • Codex:リポジトリ上のファイル(README/ルール)を正として参照できるので、前提がブレにくい

つまり私にとっては、 「前回の指示を忘れて、WordPressと喧嘩するコードを書いてしまう」 「よかれと思って余計な場所まで触ってしまう」 みたいな事故が、ファイル(README/ルール)を正として運用することで減らせる、という期待が持てました。

(もちろん、Codexに「READMEを前提にして」と最初に言う運用は必要です。自動で守るわけではないので、そこは“運用で勝つ”領域です。)

(GeminiのGemの機能やChatGPTのプロジェクト機能もありますが、使った感じ、「どうも忘れっぽい」というのが否めません。だからやっぱりCodexを使うのがいいと判断しています)


私はコードを理解していない。だからこそ運用で勝つしかなかった

私は非エンジニアなので、正直に言うと「どの修正が、どの不具合に効いたのか」を技術的に説明できません。AIに丸投げしている以上、内部で何が変わったかを自分で追跡できない。

ただ、それでも一つだけ確かなのは、WordPress上では「直す→別が壊れる」が何度も起きて、精神的に消耗した、という事実です。私に必要だったのは“原因究明”ではなく、“壊れない方向に収束させる運用”でした。

私は「原因究明で勝つ」のをやめました。代わりに「壊れない方向に収束させる手順」を作りました。

  • Canvasで、触る範囲と触らない範囲、合格条件を先に決める
  • Codexには、その範囲内で最小差分の修正だけをやらせる
  • ルールは(GitHub連携も使って)固定し、毎回同じ前提で作業する

私がChatGPT Plus(Canvas×Codex)に課金した理由は、結局ここに尽きます。非エンジニアでも前に進めるのは、コードの理解ではなく、運用の設計でした。

(本当はGeminiで完結したいのですが、現状は自分の運用だと噛み合いませんでした。加えてGoogle AI Studioは、無償利用(Unpaid Services)の場合、入力や生成結果がプロダクト改善等に使われ得る点も気になっています。一方で、Cloud Billingなどで有償扱い(Paid Services)にすると、プロンプト/回答は改善目的には使われないとされています。なので今は、まずChatGPT PlusのCanvas×Codexで運用を固めることにしました。)


「評価できない」代わりに、これだけは評価する(私の合格条件)

私はコードの中身を細かく追えません。だから評価軸を絞りました。私が評価できるのは、せいぜいこれだけです。

  • Chromeで動くか
  • Safariで動くか
  • ドラッグ&ドロップができるか
  • SNSの共有ボタンが反応するか
  • H2/H3など記事側の要素があってもツールが壊れないか

修正のたびに「この条件が全部OKなら合格」と決める。コードの中身を追う代わりに、合格条件だけを固定する。これだけでも、「直すと別が壊れる」ループは少しずつ減っていきました。


まとめ:Cursorは捨てたのか?捨ててない。「順番」を変えただけ

私はCursorを“使わない”と決めたわけではありません。ただ今の自分には、Cursor有料でIDE中心のバイブコーディングに突入するより先に、WordPress上で壊れない単一HTMLの型を確立する方が先だと判断しました。

だから今は、

  1. Canvasで仕様と制約を固める
  2. Codexで最小差分で仕上げる
  3. WordPressに貼って合格条件で判定する

このループで前に進めています。


次回予告(4本目)

次回は、私が実際に使っている

  • Canvasで「修正方針」を固めるテンプレ
  • Codexに渡す“事故防止プロンプト”(コピペ用)
  • AIに「WordPressを壊すな」と誓わせる、GitHub READMEの書き方

をまとめます。これさえあれば、コードが読めなくても「壊れないツール」は量産できます。


参考リンク↓

OpenAI:Introducing Codex
https://openai.com/index/introducing-codex/

OpenAI Help:Canvas
https://help.openai.com/en/articles/9930697-what-is-the-canvas-feature-in-chatgpt-and-how-do-i-use-it

OpenAI Help:Connecting GitHub to ChatGPT(GitHub連携は基本“読み取り”)
https://help.openai.com/en/articles/11145903-connecting-github-to-chatgpt

Google:Gemini API Additional Terms(Unpaid/Paidのデータ利用)
https://ai.google.dev/gemini-api/terms

コメント