AutoCoder.ccでAIアプリを作り、バックエンドを本番運用に備える
AutoCoder.ccでの生成から、ソース出力、安全なAPI設定、スモークテスト、本番前の技術検収までをつなぐ実践ガイドです。
AutoCoder.ccは、プロダクトの説明からフロントエンド、バックエンド、データベース、認証を含むプロジェクトを生成できます。ただし、コードが生成されたことと、本番運用に耐えることは同じではありません。シークレットの保管場所、データベース変更の移行手順、権限の境界、外部APIが失敗したときの動作は、別途設計して検証する必要があります。
実務では、まず一つのユーザージャーニーを定義して生成結果を確認し、AutoCoder内で公開するかソースを出力するかを選びます。その後、出力したバックエンドを通常のサービスと同じ基準で検収します。ここでは、文書解析機能からモデルAPIを呼び出すケースを例に、この引き継ぎを整理します。
画面一覧ではなく、検証できる利用シナリオを書く
AutoCoderの公式概要には、フロントエンドとUI、バックエンドAPIとロジック、データ永続化、ユーザー認証、デプロイ、ソースコード出力が挙げられています。Buildでは、自然言語の説明がRequirement Listに変換され、デモ生成前に要件を調整できます。
「ログイン画面、ダッシュボード、アップロード画面」とページだけを列挙するより、完了条件のある流れを記述した方が検証しやすくなります。文書解析サービスなら、次のような流れです。
- ユーザーがアカウントを作成し、許可された形式のファイルをアップロードする。
- バックエンドがサイズ、形式、文書の所有権を確認する。
- 解析ジョブに固有IDと表示可能なステータスを付ける。
- モデルAPIはブラウザではなくバックエンドからだけ呼び出す。
- UIは結果または制御されたエラーを表示し、APIキーやプロバイダーの内部レスポンスを見せない。
生成後は、正常なファイル、不正なファイル、同じ内容の再送信で一連の操作を試します。トップページの見た目だけでは、権限漏れ、二重ジョブ、戻れないエラー状態は見つかりません。
プラットフォーム公開とソース出力を使い分ける
AutoCoderには、エディターからURLへ移る二つの方法があります。組み込みのpublishはWebsite URLとBackend URLを作成します。デモや初期の仮説検証には便利で、インフラの一部はプラットフォーム側に残ります。
リポジトリ、環境、CI/CD、シークレット、サーバー、ロールバックを自社で管理したい場合はソース出力を選びます。現在のPlans & CreditsとDeploy & Hostingによると、Source Code Exportは有料プランの機能で、Freeでは利用できません。価格やクレジット量は変わり得るため、設計資料に古い数字を固定せず、契約前に現行ページを確認してください。
選択時は、次の点を確認します。
- 検証用URLをすぐに必要としているか。
- dev、staging、productionを分離する必要があるか。
- CI/CD、シークレット、ロールバックを自社の手順に統合したいか。
- チームがアプリの運用、更新、監視を担当できるか。
ソースを取得できても、技術検収が終わったわけではありません。依存関係、権限、マイグレーションの可逆性、想定トラフィックへの対応は、改めて確認します。
モデルAPIはバックエンドの内側に置く
この構成では、AutoCoderがUI、サーバーロジック、データ構造などのアプリケーション層を生成して出力します。BetterTokenは、要約、分類、抽出といった機能を実行するモデルAPIとしてバックエンドに接続します。APIキーをフロントエンドのbundle、HTML、モバイルパッケージ、公開リポジトリに含めてはいけません。
現在公開されているBetterToken API Referenceでは、OpenAI互換のChat Completionsが説明されています。
YOUR_MODEL_IDは設定値として扱います。現在のモデルカタログ、または対象APIキーのConsole内SetupからIDをコピーしてください。古い記事にあるモデル名を恒久的な依存先にしないことが重要です。
出力したNode.jsバックエンドでは、環境変数を次のように設定できます。
実値はGitにコミットせず、環境ごとのsecret managerから実行時に渡します。互換クライアントの初期化もサーバーモジュール内に置きます。
これはモジュール境界を示す例で、完成した本番用middlewareではありません。環境変数の欠落チェック、入力サイズ制限、timeout、エラー分類、本文やキーを記録しないログを追加してください。
実トラフィックの前にスモークテストを行う
最初の最小リクエストは、アプリの主要ロジック外から送ります。API設定の問題と生成プロジェクトの不具合を切り分けるためです。
成功したレスポンスにはchoices[0].message.contentが含まれます。次に、同じ小さなケースをアプリのサーバールート経由で実行し、以下を確認します。
- リクエストがブラウザではなくバックエンドから送信される。
- 実際のキーがソースとブラウザのnetwork traceに現れない。
- upstreamのエラーが制御されたアプリケーションレスポンスになる。
- BetterToken Dashboardにモデル、時刻、ステータス、input/output/cache token使用量が記録される。
直接のcurlは成功してサーバールートだけが失敗するなら、環境変数の読み込み、変数名、proxy、bodyのserialize、レスポンス解析を確認します。両方失敗する場合は、フロントエンドを変更する前に、キー、現在のModel ID、URL、返されたエラーを確認します。
本番前に検収する項目
依存関係とビルド。 lockfileを保存し、クリーンインストールとproduction buildを実行します。ライセンスを確認し、未使用パッケージを削除します。
認証と認可。 ユーザーが自分のオブジェクトだけを閲覧・変更できることを確認します。未ログイン、一般ユーザー、管理者を分けてテストします。
データベース。 schema変更をmigrationとして保存し、データのコピーでupgradeを試し、restore手順を用意します。履歴なしで起動時にテーブルを変更するとrollbackが難しくなります。
シークレット。 開発、staging、本番のキーを分け、runtimeには必要最小限の値だけを渡します。ローテーション手順も事前に決めます。
Timeoutとretry。 モデル呼び出し時間に上限を設けます。冪等性を理解した操作だけを再試行し、無制限retryによるキューと費用の増加を防ぎます。
可観測性と予算。 内部task IDをAPIの時刻・状態と関連付けますが、非公開本文はログに残しません。Dashboardでモデル、状態、実際のtoken量を照合し、アプリ側の入力・再試行制限で予算を守ります。
ロールバック。 直前の動作するartifactと戻せる設定を保管し、コードを戻したときに適用済みmigrationと衝突しないことを確認します。
主要ジャーニーがstagingで通り、権限が検証され、モデルAPIが独立したスモークテストに成功し、データを漏らさず障害を確認でき、実際にロールバックできた段階で、限定的な本番パイロットを始められます。生成コードだけでは、その条件を満たした証明になりません。
AI呼び出しを管理されたバックエンドへ移すには、専用のAPIキーを作り、現在のModel IDをコピーし、BetterToken API Referenceに沿って最初のリクエストを実行します。実トラフィックを有効にする前に、Dashboardの記録とアプリのtask IDを照合してください。