readdy.aiの「修正完了」地獄から学んだこと – Auto-Fixループの真実と脱出方法

  1. はじめに:終わらない修正地獄
  2. 第1章:問題の発見 – React 19の罠
  3. 第2章:調査開始 – 「これは何かがおかしい」
  4. 第3章:他のユーザーの悲鳴 – 私だけではなかった
    1. readdy.aiのレビューサイト
    2. Bolt.newの地獄
    3. Cursorの75回の失敗
    4. Lovableの正直な告白
  5. 第4章:根本原因の発見 – AI技術の限界
    1. 1. コンテキストウィンドウの限界
    2. 2. 真のデバッグ知能の欠如
    3. 3. 確率的なLLMの性質
    4. 4. 不十分なランタイムフィードバックループ
  6. 第5章:React 19問題の真実
    1. GitHubの未解決Issue
    2. 問題の正体
    3. React 19のネイティブ機能
  7. 第6章:解決策の発見
    1. 解決策1:メンテナンスされているフォークへの移行(推奨)
    2. 解決策2:npm overridesの使用
    3. 解決策3:インストールフラグの使用
    4. 解決策4:React 19ネイティブメタデータへの移行
  8. 第7章:Auto-Fixループからの脱出方法
    1. 業界標準のベストプラクティス
      1. 1. 3回ルール
      2. 2. インクリメンタル開発
      3. 3. 明確で具体的なプロンプト
      4. 4. バージョン管理の活用
      5. 5. 手動介入のタイミング
    2. readdy.ai特有の防御戦略
      1. クレジット保護
      2. セレクターツールの使用
      3. 頻繁なバージョン保存
  9. 第8章:プラットフォーム比較 – 移行すべきか?
    1. ループ回避に優れているツール
    2. 最も問題が多いツール
    3. 移行の判断基準
  10. 第9章:私が学んだ教訓
    1. 1. AIは「ジュニア開発者」として扱う
    2. 2. 「修正完了」を信じない
    3. 3. クレジット/トークンを守る
    4. 4. 小さなステップで進む
    5. 5. バージョン管理は命綱
    6. 6. 手動スキルを維持する
  11. 第10章:未来への展望
    1. 現在の技術的限界
    2. これから期待される改善
    3. 今後の開発者の役割
  12. 結論:賢く付き合う

はじめに:終わらない修正地獄

「修正完了しました!」

readdy.aiのAIアシスタントが何度目かの「完了」メッセージを表示した。しかし、ブラウザをリロードすると、まだそこにある。消えていない。「100%」の文字が、まだページに残っている。

Auto-Fixボタンをクリックする。25クレジットが消費される。 「修正完了しました!」 リロード。まだ残っている。

またクリック。さらに25クレジット。 「修正完了しました!」 リロード。まだそこにある。

5回、10回、15回…。気づけば375クレジットを消費していた。Starterプラン(2,500クレジット)の15%が、たった一つの単純な修正のために消えた。そして、問題は全く解決していない。

これが、私がreaddy.aiで体験した「Auto-Fix地獄」の始まりだった。

第1章:問題の発見 – React 19の罠

事の発端は、React 19とreact-helmet-asyncの依存関係エラーだった。

npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.6.0 || ^17.0.0 || ^18.0.0" from react-helmet-async@2.0.5

シンプルなエラーに見えた。「ああ、依存関係の問題か。すぐ直るだろう」と思った。

readdy.aiのAIに依頼した:「React 19とreact-helmet-asyncの互換性問題を修正して」

AIは即座に反応した。

React 19とreact-helmet-asyncの互換性問題を修正します。
package.jsonからreact-helmet-asyncを削除しました。

Version 315完了。次を試そう。

「修正完了しました!」とAIは報告した。しかし、デプロイすると同じエラーが出る。

「もう一度試して」

Version 316。同じ修正。同じ結果。エラーは消えない。

「ちゃんと確認して修正して」

Version 317。全く同じコードが生成された。

これが、Version 327まで続いた

第2章:調査開始 – 「これは何かがおかしい」

Version 320を超えた頃、私は気づいた。これはユーザーエラーではない。システムの問題だ。

以下の疑問が浮かんだ:

  1. なぜAIは「修正完了」と報告するのに、実際には修正されていないのか?
  2. なぜ毎回全く同じ修正を提案するのか?過去の失敗から学習していないのか?
  3. Auto-Fixを自動化する方法はないのか?
  4. これはreaddy.ai固有の問題なのか、それとも他のAIツールでも起きているのか?

深夜2時、私は本格的な調査を開始した。

第3章:他のユーザーの悲鳴 – 私だけではなかった

調査の最初のステップは、他のユーザーの経験を調べることだった。

readdy.aiのレビューサイト

Trustpilotでreaddy.aiを検索すると、評価は3.4/5。そして、レビューには見覚えのあるパターンが…

“AI keeps making the same mistake over and over” (AIが同じミスを何度も繰り返す)

“Changed one currency setting, took 10+ attempts and 250 credits” (通貨設定を1つ変えただけで、10回以上の試行と250クレジットを消費)

“Starter plan (2,500 credits) doesn’t last even 3 days” (スタータープラン(2,500クレジット)が3日も持たない)

“One change deleted everything after hours of work” (1つの変更で何時間もかけた作業がすべて削除された)

私だけではなかった。これは構造的な問題だ。

Bolt.newの地獄

次に、競合ツールを調査した。Bolt.newのGitHubを見ると、驚くべき発見が。

Issue #10330: “Stuck in a loop”(ループに陥る)

“AI keeps repeating the same issues over and over. Can’t even see the app preview. It just keeps using tokens, saying it’s fixing but actually not fixing anything.” (AIが同じ問題を何度も繰り返す。アプリのプレビューすら見られない。トークンを使い続けて修正していると主張するが、実際には何も修正していない)

Issue #3293: “repetitive npm install errors”(繰り返されるnpm installエラー)

“The AI gets stuck in loops trying to fix dependency issues” (AIが依存関係の問題を修正しようとしてループに陥る)

Cursorの75回の失敗

Cursor(人気のAI IDE)の検証レポートを見つけた。

“After 50+ tool calls in 40 minutes, still couldn’t fix the issue” (40分間で50回以上のツール呼び出しを行っても、まだ問題を修正できなかった)

“75+ attempts later, nothing to show for it” (75回以上の試行の後も、何も成果がなかった)

Lovableの正直な告白

最も衝撃的だったのは、Lovableの公式トラブルシューティングドキュメントだった:

“If auto-fix fails 3+ times, it likely cannot be auto-resolved” (自動修正が3回以上失敗した場合、おそらく自動解決はできません)

プラットフォーム自身が、AIの限界を認めている。

第4章:根本原因の発見 – AI技術の限界

調査を進めるうちに、4つの根本原因が浮かび上がってきた。

1. コンテキストウィンドウの限界

readdy.aiの公式ドキュメント自体がこう述べている:

“LLMs have limited context windows and cannot retain conversations or edits from the distant past” (LLMには限られたコンテキストウィンドウがあり、遠い過去の会話や編集を保持できない)

つまり、AIは自分が過去に何を試したかを忘れる。Version 315で試したことをVersion 320では覚えていない。だから、同じ失敗を繰り返す。

2. 真のデバッグ知能の欠如

AIはコードの「パターンマッチング」を行っているだけで、実際にコードを実行して検証する能力がない

エラーメッセージを見て「このパターンならこう修正すべき」と推測しているだけ。修正が実際に機能したかを確認していない。

3. 確率的なLLMの性質

各「修正」は本質的に新しい生成。前回の失敗から学習するのではなく、毎回ゼロから生成し直している。

これは、試験で同じ問題を何度も間違える学生が、前回の間違いを見返さずに毎回新しい答えを考えているようなもの。

4. 不十分なランタイムフィードバックループ

ほとんどのAIツールは、修正が実際に機能したかをテストできない

コードを生成する → エラーが出る → エラーメッセージを見る → 修正を生成する → …

このループには、「実際に動作するかをテストする」ステップがない。

第5章:React 19問題の真実

調査を進める中で、React 19とreact-helmet-asyncの問題についても深く掘り下げた。

GitHubの未解決Issue

react-helmet-asyncのGitHubを調べると、Issue #238と#239が2024年12月から未解決のままだった。

タイトル:

  • “Unable to install react-helmet-async in React 19”
  • “Support for react 19”

コメントには絶望的なメッセージが:

“Is there any update on this?”(アップデートはありますか?) “Still no React 19 support?”(まだReact 19サポートがない?) “Last commit was over a year ago”(最終コミットが1年以上前)

メンテナンスが放棄されている。

問題の正体

技術的には、これは実際のコード互換性の問題ではない

react-helmet-asyncのpackage.jsonが:

"peerDependencies": {
  "react": "^16.6.0 || ^17.0.0 || ^18.0.0"
}

と宣言しているため、React 19(19.x.x)がこの範囲に含まれていない。

ライブラリのコード自体はReact 19で動作する可能性が高い。これは単なるpackage.jsonの宣言ミス

React 19のネイティブ機能

さらに調査を進めると、興味深い発見があった。

React 19は、react-helmet-asyncが不要になる機能を提供している。

React 19では、以下のように直接<title><meta>タグを書ける:

function BlogPost() {
  return (
    <>
      <title>My Blog Post</title>
      <meta name="description" content="Post description" />
      <article>...</article>
    </>
  );
}

Reactが自動的にこれらを<head>に移動し、SSR対応、重複管理、ストリーミングサポートを提供する。

react-helmet-asyncは、もはや必要ない可能性がある。

第6章:解決策の発見

調査の末、私は4つの実用的な解決策を発見した。

解決策1:メンテナンスされているフォークへの移行(推奨)

@dr.pogodin/react-helmetというフォークが、React 19を公式サポートしている。

npm install @dr.pogodin/react-helmet

インポートパスを変更するだけで移行できる:

// 変更前
import { Helmet } from 'react-helmet-async';

// 変更後
import { Helmet } from '@dr.pogodin/react-helmet';

解決策2:npm overridesの使用

package.jsonに以下を追加:

{
  "overrides": {
    "react": "19.0.0",
    "react-dom": "19.0.0"
  }
}

これにより、すべての依存関係がReact 19を使用するよう強制される。

解決策3:インストールフラグの使用

npm install react-helmet-async --legacy-peer-deps

ただし、これは依存性チェックを回避するため、本番環境では十分なテストが必要。

解決策4:React 19ネイティブメタデータへの移行

外部依存を完全に削除し、React 19の組み込み機能を使用する:

function Page() {
  return (
    <>
      <title>Page Title</title>
      <meta name="description" content="Page description" />
      <meta property="og:title" content="OG Title" />
      <Content />
    </>
  );
}

第7章:Auto-Fixループからの脱出方法

React 19の問題だけでなく、Auto-Fixループ全般に対する対策も発見した。

業界標準のベストプラクティス

複数のプラットフォームのドキュメントとユーザーレポートから、共通のパターンが見えてきた。

1. 3回ルール

Auto-Fixが3回失敗したら、それ以上クリックしない。

これは、Lovableが公式に推奨し、Bolt.newやWindsurfのトラブルシューティングでも言及されているルール。

理由:3回失敗した時点で、AIは問題を理解していない可能性が高い。これ以上続けてもクレジット/トークンを無駄にするだけ。

2. インクリメンタル開発

小さな変更ごとにテストする。

readdy.aiの公式推奨:「1ページ1コンポーネント」アプローチ。

一度に複数の変更をAIに依頼すると、どこで問題が発生したかの特定が困難になる。

3. 明確で具体的なプロンプト

悪い例:

“エラーを修正して”

良い例:

“src/components/Header.jsxの42行目で発生している’Cannot read property of undefined’エラーを修正してください。エラーはuserオブジェクトがnullの場合に発生します。userが存在しない場合のフォールバック処理を追加してください。”

4. バージョン管理の活用

動作している状態で頻繁に保存する。

すべての主要ツール(readdy.ai、Bolt.new、Replit)はバージョン履歴機能を持っている。動作確認後、すぐに明示的なバージョンとして保存する。

問題が発生したら、すぐに前のバージョンに戻る。

5. 手動介入のタイミング

AIに3回以上失敗させるより、手動で修正する方が速い。

特に依存関係の問題は、ターミナルで直接npm install --legacy-peer-depsを実行する方が確実で速い。

readdy.ai特有の防御戦略

readdy.aiでは、追加の戦略が必要:

クレジット保護

Auto-Fixは1回25クレジット消費する。3回失敗(75クレジット)したら、それ以上クリックせず:

  • サポートに連絡する
  • 手動デバッグに切り替える
  • 他のプラットフォームへの移行を検討する

セレクターツールの使用

readdy.aiの「Accurate Edit」機能を使用。テキスト説明ではなく、ビジュアルセレクターで変更箇所を指定する。

頻繁なバージョン保存

動作する状態を頻繁に保存し、削除/復帰オプションを活用する。

第8章:プラットフォーム比較 – 移行すべきか?

調査の過程で、各プラットフォームの特徴が明確になった。

ループ回避に優れているツール

Windsurf

  • より良いクロスファイル認識
  • コンテキスト管理が優秀
  • ただし、それでも完璧ではない

v0.dev (Vercel)

  • カスタム「vercel-autofixer-01」モデル
  • 依存関係エラーに特化した対応
  • 確率的な性質は残る

Replit

  • エージェントとアシスタントモードの明確な分離
  • 公式ドキュメントで「エージェントがループに陥った場合」のトラブルシューティングを提供
  • 透明性が高い

最も問題が多いツール

Bolt.new

  • 無限依存関係ループの報告が最多
  • GitHubで多数の未解決Issue

Cursor

  • エージェントモードで75回以上の失敗報告
  • 実用的なコード生成は優秀だが、自動修正は弱い

readdy.ai

  • クレジット消費の悪循環
  • 不十分なカスタマーサポート
  • リセット/デバッグツールの欠如

移行の判断基準

以下の場合、readdy.aiからの移行を検討すべき:

  1. 継続的なクレジット消費:単純な変更で100クレジット以上消費
  2. サポート無反応:3日以上返信がない
  3. 頻繁な全削除:変更で作業が消える頻度が高い
  4. 依存関係地獄:npm/yarnエラーが解決しない

移行先の推奨順:

  1. Windsurf – 依存関係管理が強い
  2. v0.dev – Vercelのインフラ、React特化
  3. Replit – 透明性と制御性が高い

第9章:私が学んだ教訓

この調査と体験から、私は重要な教訓を学んだ。

1. AIは「ジュニア開発者」として扱う

AIは魔法ではない。監督が必要なジュニア開発者のように扱うべき:

  • 生成されたコードは必ずレビューする
  • 重要な変更は人間が最終確認する
  • 複雑なロジックは人間が設計する
  • AIはボイラープレートやシンプルなタスクに使用

2. 「修正完了」を信じない

AIが「修正完了しました」と言っても、必ず自分で確認する

これは、すべてのAIツールで共通の問題。AIは修正が実際に機能したかを検証できない。

3. クレジット/トークンを守る

Auto-Fixは便利だが、無限に使えるものではない。

3回ルールを厳守:3回失敗したら手動介入。

クレジット/トークンは限られたリソース。無駄にしない。

4. 小さなステップで進む

一度に大きな変更を依頼すると、問題の特定が困難になる。

インクリメンタル開発

  • 小さな変更を加える
  • テストする
  • 動作を確認する
  • 次の変更に進む

5. バージョン管理は命綱

頻繁に保存、頻繁にコミット。

動作している状態を常に保持しておけば、いつでも安全な状態に戻れる。

6. 手動スキルを維持する

AIに完全依存しない。

依存関係の問題、ビルドエラー、デプロイ問題は、手動で対処する方が速い場合が多い。

基礎的なスキルを維持することが、AIツールを効果的に使うための鍵。

第10章:未来への展望

この調査を通じて、AI開発ツールの現状と限界が明確になった。

現在の技術的限界

コンテキストウィンドウ:改善されているが、まだ十分ではない 実行検証:ほとんどのツールは修正を実際にテストできない 学習能力:失敗から学習するメカニズムが不足 状態管理:長期的な会話で一貫性を保てない

これから期待される改善

より良いフィードバックループ

  • 自動テスト実行
  • リアルタイム検証
  • 修正の効果測定

より賢いコンテキスト管理

  • 重要な情報の優先順位付け
  • 失敗パターンの記憶
  • プロジェクト全体の理解

透明性の向上

  • 何を試みたかの明示
  • 失敗の理由の説明
  • 代替アプローチの提案

今後の開発者の役割

AIツールの進化により、開発者の役割は変化していく:

変わらないもの

  • アーキテクチャ設計
  • 複雑なロジックの実装
  • セキュリティとパフォーマンスの最適化
  • コードレビューと品質管理

AIに任せられるもの

  • ボイラープレートコード
  • シンプルなCRUD実装
  • 基本的なUI実装
  • テストコードの生成

重要になるスキル

  • AIとの効果的なコミュニケーション(プロンプトエンジニアリング)
  • 生成されたコードの品質評価
  • 問題の切り分けと診断
  • 手動介入のタイミング判断

結論:賢く付き合う

Version 327に到達した私のreaddy.ai体験は、貴重な学びの機会だった。

Auto-Fix地獄からの脱出方法は存在する:

  1. 3回ルールの厳守 – 3回失敗したら停止
  2. 小さなステップ – インクリメンタル開発
  3. 頻繁な保存 – バージョン管理を命綱に
  4. 明確なプロンプト – 具体的で詳細な指示
  5. 手動介入の判断 – AIに任せきりにしない

React 19問題の解決策も見つかった:

  • @dr.pogodin/react-helmetへの移行
  • npm overridesの使用
  • React 19ネイティブ機能への移行

そして最も重要な教訓:

AIは強力なツールだが、魔法ではない。

監督が必要なジュニア開発者として扱い、生成されたコードは必ずレビューし、基礎的なスキルを維持し続けることが、AIツールを効果的に使うための鍵だ。

Auto-Fixボタンを無限にクリックする日々は終わった。

今、私はAIツールと賢く付き合う方法を知っている。


追伸:あなたの体験を教えてください

この記事を読んでいるあなたも、同じような体験をしているかもしれない。

  • readdy.aiやBolt.newで何度もAuto-Fixを試した?
  • 「修正完了」と言われても修正されていなかった?
  • クレジット/トークンを大量に消費した?

コメント欄で、あなたの体験やヒントを共有してほしい。

私たちは、AI開発ツールの黎明期を生きている。今の問題は、将来への貴重なフィードバックになる。


参考リンク