[GN] 非開発者 + Claudeで本番運用238日 — 何ができて、何ができなかったか？

 (chajooin.com)
7 ポイント 投稿者 workdriver 2026-04-12 | 5件のコメント | WhatsAppで共有

チャジュインドットコム(chajooin.com)を作った運営者です。高卒、貨物トラック歴8年（2017年〜）。コードを1行も書けない状態で、2025年8月16日にClaudeと一緒に最初のコミットを打ちました。238日が経ち、今このサービスは毎日自動でデータを収集し、レポートを公開しています。

この記事は「作った」ではなく、**「作って運用中だ」**という記録です。バイブコーディングでプロトタイプを作った体験談は多いですが、本番運用を続ける経験は珍しいので書きます。成功談ではなく、うまく機能したことと機能しなかったことの率直な記録です。

背景

  • ドメイン: 貨物トラック相場比較（17兆ウォン市場、実取引価格の公式記録なし）
  • 以前の試み: 2024年にターンキー外注3,000万ウォン → 修正の主導権が外注側にあり断念
  • 転換: 2025年7月にAIを2か月学習 → 8月16日に初コミット

スタック

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
収集        Playwright (headless) + ソース別パーサー46個  
ML          LightGBM (Python, 75 features)  
デプロイ    Railway (Docker)  
自動化      Node scheduler + Telegram通知  
AI協業      Claude（主開発）+ GPT-4o（ショート動画台本/プロンプト）  
認証        Naver/Kakao OAuth

スタックを「選んだ」わけではありません。AIに「これを作るなら何を使えばいい？」と聞いて、そのまま採用しました。後から見ると合理的な組み合わせでした。AIエージェントの実用的な価値は、選択に伴う認知的負担を代わりに引き受けてくれることです。

数字（2025-08-16 ~ 2026-04-12）

項目 値
総コミット数 3,493
コミットした日 189日
コードファイル数 約1,500（js/ts/py基準）
ロールバック 20回+
デプロイ失敗 39回（初期Railwayセットアップ2日間）
同じバグの最大反復 7回（価格単位）
アクティブ掲載 約48,000台
外部ソースパーサー 46個
CLAUDE.md 187行、24条の絶対ルール
メモリファイル 129個

第1部. 作ること — 動くようにできた3つの要因

1.1 CLAUDE.md — ルールでAIを制御する

同じバグが2回起きたら、「気をつけて」は無意味です。具体的なルールをファイルに書き、AIが各セッション開始時に読むようにします。

"パーサー=ウォン → 正規化=÷10,000 → DB=万ウォン。DB値への×10,000は禁止"  
"パーサーの年式抽出に失敗した場合、getFullYear()の代入禁止"  
"kakaotalkをvercel.json UA rewriteに追加禁止"  
"setInterval値はMath.min(value, 2^31-1)でのクランプ必須"

現在24条。すべて実際の事故の後に生まれました。

1.2 役割分担 — 企画・判断は人、実装はAI

コードは読めなくても、結果は判断できます。ポーター2トンが500万ウォンで表示されれば「これは違う」と言えるし、ウイングボディとカーゴが同じ価格で出れば「分けろ」と言えます。ドメイン感覚がテストの役割を果たします。

1.3 メモリファイル — セッション間でコンテキストを維持

129個のメモリファイルに決定・失敗・方針を蓄積。新しいセッションが開くたびに関連メモリを読んで、過去の判断を維持します。AIのコンテキストウィンドウの限界を、ファイルシステムで補う構造です。

第2部. 運用 — 作ることとは別の問題

2.1 自動で回っているもの

  • 掲載データのインジェスト: スケジューラが外部ソースからデータ収集 → 品質ゲート → DB反映
  • 相場レポート: 毎日自動生成 → ブログ/カフェに自動公開
  • ショート動画台本生成: トン級別にGPT-4oが台本/Soraプロンプトを生成（動画合成は別段階）
  • ML再学習: 週1回、新規データで相場エンジンを再学習
  • 監視: パイプライン異常時にTelegram通知

開発者は私ひとりです。

2.2 コスト

  • インフラ: Railway（PostgreSQL + Node + Playwright）
  • AI API: Claudeサブスクリプション（開発用）+ GPT-4o API（ショート動画生成用、api_usage_logベースで月1ドル前後と推定）
  • ドメイン/OAuth: Naver/Kakao

2.3 障害対応記録

  • 1,138件のデータ汚染（3/2）: 年式フォールバックバグを発見 → DBパッチ + 再処理パイプライン + ルール追加
  • Slack通知が6か月不作動（3/18発見）: 環境変数/パスの問題 → Telegramの単一路線へ統合再構成
  • setInterval 32-bitオーバーフロー（4/10）: ログイン停止 → ホットフィックス + クランプルール追加
  • KakaoTalkで空白画面（1/31）: SEO UA rewriteがKakaoTalkのアプリ内ブラウザまで拾っていた → UAリスト修正

2.4 運用ルール抜粋

CLAUDE.mdには運用観点のルールも含まれています。

"デプロイ後は3つの数字で報告: サーバー状態（health 200）、  
 今日のクロール件数（昨日の±20%以内）、アクティブ掲載数（急変動なし）"  
  
"4ファイル以上の修正時、スケジューラ接続時、DBスキーマ変更時、  
 以前revertされた領域を再修正する時 → 事前報告必須"  
  
"一時変更（フォールバック/TODO/ハードコーディング）は台帳に記録:  
 何をいつまでに元へ戻すべきか、戻さないと何が壊れるか"

AIはこのルールを毎回読み、該当状況になると作業前に先に報告します。

第3部. うまく機能しなかったこと

3.1 同じバグを7回反復 — データ経路全体を見られない

価格単位バグが7回起きた理由は、収集 → パーサー → 正規化 → DB → API → UIの6段階のうち1か所だけ直しても、別経路でまた発生するからです。「全体を見る力」が、非開発者+AIの組み合わせで最も不足している点です。AIは指示された場所だけ直し、人は他の経路の存在を知りません。

3.2 1,138件のデータ汚染 — AIの「親切な」デフォルト値

パーサーが年式抽出に失敗したとき、getFullYear()を返すコードが入っていました。AIの立場では「nullより現在の年のほうがまし」という判断だったのでしょう。結果として、2003年式のポーターが2026年式としてDBに書き込まれました。「わからなければnull」とAIに明示しておかないと、何かしら埋めてしまいます。

3.3 Slack通知が6か月不作動 — 監視システムを監視していなかった

通知は失敗で終わり、その失敗自体がログに残らなかったため、6か月間静かなままでした。その間にもパイプライン異常は何件かありましたが、「問題ない」と錯覚していました。AIで作ったシステムで最も危険なのは、『うまく動いているように見える』状態です。 現在はTelegram単一路線に簡素化しました。

3.4 setInterval 32-bitオーバーフロー — 言語の落とし穴

setIntervalがint32しか受け付けないことを知らなければ、30日をミリ秒にして入れたとき即時実行されることもわかりません。ログイン停止。AIはこうしたedge caseを自発的に警告してくれません。問題が起きてから初めてクランプルールが生まれました。

3.5 MLの過学習 — 学習MAPE 8.56% vs 実運用42%

LightGBM 75 featuresで学習MAPE 8.56%を達成して「できた」と思いました。実運用では42%。理由は、売り希望価格データの構造的限界（実取引価格不在、ダウン契約書、ディーラーマージン）です。ドメイン専門家なら最初からわかることですが、「学習結果が良ければいい」に閉じ込められていました。

残った考え

238日を振り返って整理すると:

  • AIは実装速度を大きく引き上げる。 コードがわからない人でも動くサービスを作れる。
  • その代わり、運用品質は自動ではついてこない。 障害は例外なく起きるし、AIは自発的に警告してくれない。
  • 非開発者の仕事はコードを書くことではなく、ルール・監視・検証の設計へと移る。結果判断と再発防止が本業になる。

ひとりで運用している本番環境なのでサンプル数 n=1 です。一般化するつもりはありません。同じ条件で他の方々の経験が気になります。

リンク

フィードバック歓迎です。特に**「うまく動いているように見える状態」を一人でどう監視しているか**が気になります。

関連記事

5件のコメント

 
savvykang 2026-04-13

一見うまく動いているように見える状態の問題は、定期的に障害復旧訓練を行い、データのどの特性が正常なのかを定義すれば、ある程度は緩和できるのではないかと思います
 
workdriver 2026-04-13

はい、貴重なご意見ありがとうございます。
システムが大きくなると、管理が大変になるのは事実です。
 
savvykang 2026-04-13

お一人で運用されるなら、監視サービスも直接管理しなければならないため、現状では簡単ではないと思われます。外部の監視サービスを利用されるのも一つの方法です。
 
jjw9512151 2026-04-13

実際の現場データをありがとうございます。
 
workdriver 2026-04-13

はい、ありがとうございます