AIにアプリ作りを任せる前に、Convexでどこまで受け止めるか決めた

AIにコードを書かせる時、私はつい画面から先に作りたくなる。ボタン、入力欄、一覧、生成中の表示。目に見える部分は進んでいる感じが出るからだ。けれど、ここ数日のログを見返すと、毎回つまずく場所はだいたい同じだった。生成結果をどこに保存するのか。途中状態をどう見せるのか。失敗した処理をどこから再開するのか。つまり、画面ではなくバックエンドの置き場所だった。

今日のネタ棚では「CodexとConvexの統合」が残っていた。最初は、ただの技術メモとして扱うと弱いと思った。公式ドキュメントを読むと、ConvexはTypeScriptで書くリアクティブなデータベース兼バックエンドで、データが変わるとクエリ結果も反応する設計になっている。AIエージェントにアプリ作りを任せる時、この特徴は「後でDBを足す」よりも先に考える価値がある。

今回の記事では、Convexを全面採用する話ではなく、Codexに実装を任せる前に、どこまでをConvexに寄せると事故が減るのかを整理する。私が迷ったのは、速く作ることより、生成途中の状態、公開前の確認、失敗時の復旧をどう残すかだった。

画面だけ先に作ると、状態が散らばる

AIに「この管理画面を作って」と頼むと、見た目はかなり速く出る。ReactやNext.jsの画面、カード、フォーム、一覧表示までは一気に進む。問題は、そのあとだ。

たとえばブログ自動化なら、候補選定、本文生成、画像生成、WordPress投稿、noteミラー、公開後確認がある。動画やKDPでも同じで、素材、承認、生成結果、投稿可否、失敗理由がある。これを最初にローカルJSONや一時ファイルだけでつないでいくと、画面は動いているのに、どの状態が正なのか分からなくなる。

私が今回直したかったのは、ここだった。AIがコードを作れるなら、なおさら「どの状態を保存するか」を先に決めないと、あとで人間がログを掘る羽目になる。Convexを調べた理由は、DBとサーバー関数とクライアントの更新を、TypeScriptの同じ文脈で扱えるからだ。

Convexで見たかったのは、速さよりも同期の形

公式のConvex Overviewでは、Convexは「queries are TypeScript code running right in the database」という説明になっている。さらに、Reactの状態が変化に反応するように、Convexのqueryもデータ変更に反応するという考え方が中心に置かれていた。

この説明で腑に落ちたのは、AIアプリでよくある「生成中の状態」を扱いやすそうな点だ。通常のHTTPだけで作ると、生成が終わるまで待つか、ポーリングするか、別途WebSocketを足すか、どこかで分岐が増える。Convexの発想では、まず状態をDBに置き、画面はqueryを購読する。状態が変われば画面も追従する。

これは派手な機能というより、運用の負債を減らす設計だと思った。AIが作業者になるほど、途中状態は増える。下書き中、画像待ち、レビュー待ち、公開済み、note未投稿、再試行待ち。これを画面側の一時状態だけで持つと、あとで必ず苦しくなる。

queries、mutations、actionsを分けて考える

Convexの関数は、大きくqueries、mutations、actionsで考える。私はここを、AI自動化の作業分担に置き換えて読んだ。

queriesは読むための関数。たとえば「今日の候補一覧」「公開待ちの記事」「画像が2枚そろっていない記事」を画面に出す。mutationsはDBを書き換える処理。候補を採用する、レビュー結果を保存する、公開済みにする。actionsは外部APIや長い処理を含む場所。AI生成、WordPress投稿、外部サービス呼び出しのように、DBの外へ出る仕事を受け持つ。

この分け方を最初に決めておくと、Codexへの頼み方も変わる。「全部作って」ではなく、「状態テーブルを作って」「採用はmutationにして」「外部投稿はactionに分けて」「画面はqueryを読むだけにして」と頼める。AIに任せる範囲が広いほど、こういう境界線が効く。

Codex連携で気になった公式情報

ConvexのAI Code Generationのドキュメントには、Codexのようなクラウド/バックグラウンド系のコーディングエージェントがConvex deploymentを使う時の説明がある。Agent Modeでは、エージェントがcodegen、テスト、一回限りの関数実行などを進めやすいように、権限を絞りながら作業できるという位置づけだった。

ここで私が見たかったのは、流行りのAI対応という見出しではない。AIにバックエンドを触らせるなら、権限、環境、生成コード、テスト実行の線引きが必要になる。特に個人の自動化基盤では、外部投稿や送信に近い処理を持つので、AIが触る場所と触らない場所を分けたい。

Convex MCP ServerやAgent Modeの考え方は、そのまま本番投稿まで任せるためのものではなく、開発中の問い合わせや検証を安全に寄せるための入口として見るのがよさそうだと感じた。

私なら最初にこの3テーブルだけ置く

もし今日、AI自動化用の小さな管理アプリをConvexで作るなら、最初から大きく設計しない。まずは3つだけにする。

runs: 1回の自動化実行。種類、日時、現在ステータス、停止理由、公開URLを持つ
artifacts: 記事、画像、音声、動画などの成果物。生成元、保存先、レビュー状態を持つ
events: 重要な状態変化。候補採用、画像生成、投稿成功、投稿失敗、note未投稿などを時系列で残す

この3つがあるだけで、画面の見方がかなり変わる。今日の実行がどこで止まったか、画像だけ足りないのか、WordPressは成功してnoteだけ失敗したのか、あとから追える。今のローカル運用でもJSONLログで近いことはしているが、管理画面にするなら、最初から状態として持ったほうがいい。

逆に、いきなりユーザー管理、課金、通知、複雑な権限まで作ると重くなる。まずは「AIが作ったものを、人間が公開前に見られる」ことに絞る。個人運用では、ここが一番リターンが大きい。

Codexに渡す前のプロンプトを変える

今回の気づきは、Convexを使うかどうか以前に、Codexへの依頼文を変える必要があるということだった。

以前なら「ブログ自動化の管理画面を作って」と言っていたと思う。これだと、見た目から作られやすい。次に頼むなら、こう分ける。

まずConvex schema案を出す
runs、artifacts、eventsの関係を説明する
外部投稿はactionへ分ける
公開前承認はmutationで状態を変える
UIはqueryを読むだけから始める
WordPress投稿やSNS投稿は、最初はdry-runにする

この頼み方なら、AIが勢いで投稿処理まで進むのを避けやすい。私は外部送信や投稿に近い作業では、最後の実行線をかなり慎重に扱っている。だから、アプリ構成でも「生成する」「保存する」「レビューする」「公開する」を別々の状態に分けるほうが合っている。

画像にしたい流れ

この記事の本文図解では、次の流れを1枚にまとめたい。

Codexが候補や画面を作る
Convexにrunとartifactを保存する
queryで管理画面へ反映する
人間がレビューしてmutationで承認する
actionが外部投稿を実行し、eventsに結果を残す

ポイントは、AIが直接「公開」へ飛ばないことだ。AIに任せる範囲を広げるほど、途中の状態を見える場所に置く必要がある。Convexを使う意味は、単にDBを足すことではなく、AIの作業状態をアプリの中心に置くことだと思う。

今日の判断

今日の結論は、Convexを「いつか使うバックエンド」ではなく、「AIに実装を任せる前の状態設計ツール」として見る、ということだった。

小さな個人ツールなら、最初はローカルファイルでも十分に動く。ただ、生成結果、承認、投稿、再試行が増えてきたら、状態をDBに寄せたほうがいい。特に、画面を開いた時に最新状態が自然に反映される設計は、AI自動化の管理画面と相性がいい。

次に試すなら、いきなり本番の投稿系ではなく、ローカルの「公開待ち成果物ビュー」から始める。CodexにConvex schemaと最小UIを作らせ、投稿ボタンはdry-runにする。そこで状態の見え方が良ければ、WordPressやnoteの実投稿へ近づける。

AIに仕事を任せるなら、コードを書く速さだけを見ない。どの状態を残し、どこで人間が止め、どこから外部へ出すのか。そこを先に決めたほうが、あとから直す量は減る。