AIアプリビルダーのPostgreSQLデータベースアクセス

AIアプリビルダーは、既存のPostgreSQLデータベースのスキーマを所有していなくても接続できます。ただし、その境界をPostgreSQL上で実際に成立させる必要があります。「本番環境を変更しないで」というプロンプトは制御ではありません。別ロール、トランザクションの既定値、明示的なマイグレーションレビュー、スキーマチェックが制御になります。

安全なモデルでは、データベース作業を3つの経路に分けます。検出ではメタデータと許可されたデータのサンプルを読み取ります。アプリケーションは必要なテーブルと操作だけを読み書きします。スキーマ変更は、人が正確なSQLを承認した後、別のマイグレーション用IDで実行します。チームがこの3経路を便利な所有者認証情報1つにまとめ、エージェントがもっともらしい列名を、稼働中テーブルを作り直す許可だと判断した例を見てきました。便利だったのは午後の数時間だけで、後片付けはずっと長く続きました。

検出は構造上、読み取り専用にする

検出用接続には、許可されたスキーマを理解するためのアクセスは必要ですが、改善するためのアクセスは不要です。データベースやロールを作成できず、行レベルセキュリティを回避できず、広いグループから予期しない権限を継承しないログインロールを作成してください。PostgreSQLでは新しいロールにこれらの権限は最初からありませんが、明示的に宣言すれば意図をレビューできます。

CREATE ROLE app_discovery
  LOGIN
  NOSUPERUSER
  NOCREATEDB
  NOCREATEROLE
  NOINHERIT
  NOBYPASSRLS
  CONNECTION LIMIT 3
  PASSWORD 'replace-through-secret-manager';

ALTER ROLE app_discovery SET default_transaction_read_only = on;
GRANT CONNECT ON DATABASE customer_portal TO app_discovery;
GRANT USAGE ON SCHEMA app TO app_discovery;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_discovery;

default_transaction_read_onlyは、既定値を維持するセッションで通常の書き込みを止めます。有用な補助策ではありますが、主な防御策ではありません。クライアントがトランザクション設定を変更してもロールを閉じ込めるのは、INSERT、UPDATE、DELETE、TRUNCATE、CREATE、所有権を与えていないことです。ロールをアプリケーション所有者グループのメンバーにせず、スキーマの所有者にもしてはいけません。

ビルダーを接続する前に、既存の付与権限を確認する価値があります。次のクエリはテーブル権限ごとに1行を返すため、レビュアーはSELECT以外を見つけられます。

SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_discovery'
ORDER BY table_schema, table_name, privilege_type;

正常な結果はapp | invoices | SELECTのような形です。結果が空なら検出が必要なテーブルを見られない可能性があり、UPDATEで終わる行があればロールの権限が強すぎます。テーブル権限では別の場所でオブジェクトを作成できるか分からないため、has_schema_privilegeでスキーマ権限を、has_database_privilegeでデータベース権限も確認してください。

本番スナップショットを、所有者認証情報を共有する口実にしてはいけません。コピーにも顧客データが含まれていることがあり、所有者権限を持つエージェントが比較が役に立たなくなるほど変更することもあります。すべての環境で検出には専用IDを使ってください。

カタログの確認は許可リスト内に留める

ビルダーは承認済みスキーマだけを検出し、PostgreSQLが実際に返した内容を記録すべきです。information_schemaにはテーブル、列、制約、権限向けの移植性の高いビューがあります。pg_catalogはインデックス、型、生成式、行レベルセキュリティなどPostgreSQL固有の詳細を公開します。どちらも、一般的な顧客テーブルについてのLLMの記憶より信頼できる情報源です。

appとreportingのような許可リストから始めます。pg_catalog、information_schema、一時スキーマ、拡張機能のスキーマ、一覧にないテナントスキーマは、アプリケーションの対象から除外してください。クエリはデータベース、ロール、SQLの各層で絞り込みます。プロンプトだけの許可リストは、その後のチャットで消えてしまうことがあります。

SELECT
  c.table_schema,
  c.table_name,
  c.ordinal_position,
  c.column_name,
  c.data_type,
  c.is_nullable,
  c.column_default
FROM information_schema.columns AS c
WHERE c.table_schema IN ('app', 'reporting')
ORDER BY c.table_schema, c.table_name, c.ordinal_position;

結果は取得時刻とデータベースIDを含むスキーマスナップショットとして保存します。スナップショットは生成器が見たものの証拠であり、永続的な真実ではありません。検出からコード生成までの間にPostgreSQLは変わり得るため、デプロイ前に新しいフィンガープリントと比較してください。実用的なフィンガープリントでは、順序付けたテーブル、列、型、NULL許容性、既定値、制約、インデックスの記述をハッシュ化できます。異なっていれば停止して再検出し、どの変更が無害かを推測しないでください。

行のサンプリングは別の権限判断です。列メタデータに個人データが含まれることはまれですが、行サンプルには含まれることが多いです。コード生成では行をまったくサンプリングしない方法を優先してください。例が必要なら、秘密情報と直接的な識別子を除去またはマスクするビューを公開し、そのビューだけにSELECTを付与します。LIMIT 10は機密クエリを安全にするのではなく、漏えいを小さくするだけです。

search pathも同じように扱う必要があります。承認済みスキーマとpg_catalogに設定し、生成されたテーブル名は修飾し、PostgreSQLが最初に解決したオブジェクトに頼らないでください。攻撃者や不注意なマイグレーションが、書き込み可能なスキーマに同名オブジェクトを作ることがあります。app.ordersのような修飾名なら、この曖昧さをなくせます。

実行時ロールは実際のユーザー操作に合わせる

検出と実行時は別の仕事です。実行時アプリケーションには注文の挿入、下書きの更新、慎重に設計された関数の呼び出しが必要になるかもしれません。それでも、検出したスキーマ全体への広い書き込みアクセスは正当化されません。ユーザー操作から権限マトリクスを作り、各操作を最小のPostgreSQL権限に変換してください。

たとえば請求書ビューアにはapp.invoicesとapp.invoice_linesへのSELECTが必要かもしれません。一方、メモ機能にはapp.invoice_notesへのSELECTとINSERTが必要です。請求書へのDELETE、パスワードリセット記録へのアクセス、スキーマ作成はおそらく不要です。挿入がそのシーケンスに実際に依存するときだけ、シーケンス使用権限を与えてください。PostgreSQLではシーケンスは別オブジェクトとして扱われるため、所有者アカウントでテストする生成器はここで意外な結果になります。

ビューと関数で公開範囲をさらに狭められます。ビューは承認済みの列を公開しつつ内部フィールドを隠せます。SECURITY DEFINER関数は通常の権限で表せない1つの制御済み操作を実行できますが、固定されたsearch_path、厳格な入力チェック、不要な権限を持たない所有者が必要です。このような関数は権限モデルを回避する近道ではなく、特権コードとして扱ってください。

行レベルセキュリティは共有テーブル内にデータ境界を追加します。テーブル権限の代わりにはなりません。PostgreSQLはまずロールが操作できるか確認し、その後、有効で適用対象なら行セキュリティポリシーを適用します。テーブル所有者やBYPASSRLSロールはポリシーを回避できるため、必ず実際の実行時ロールでテストしてください。マイグレーション所有者でのテストは、エンドユーザーが何を見られるかについてほとんど証明しません。

秘密情報をプロンプト、生成ソース、ブラウザバンドル、ビルドログ、スクリーンショットに含めないでください。実行時認証情報はホスティング環境のシークレットストアに置き、サーバープロセスだけに注入します。モバイルアプリとブラウザアプリはPostgreSQLパスワードを秘密にできないため、直接接続ではなくサーバーAPIを呼び出すべきです。検出、実行時、マイグレーションの認証情報は個別にローテーションしてください。1経路で漏えいしても、ほかの2経路まで開いてはいけません。

マイグレーション権限は別の承認経路に置く

アプリビルダーはマイグレーションを提案しても構いませんが、検出セッションや実行時セッションで実行してはいけません。マイグレーション作業には別ロールを与えるか、確立済みのデプロイシステムに、承認された1つのジョブだけでそのロールを引き受けさせます。通常のチャットやプレビューの間、その認証情報は使えない状態にしてください。

承認対象には、正確なSQL、対象データベースID、準備に使ったスキーマフィンガープリント、想定されるロックや書き換えの動作を含める必要があります。「顧客ステータスを追加する」のような自然言語の文だけを承認すると余地が大きすぎます。実行される変更は、NULL許容のテキスト列追加、大きなテーブルの再構築、列挙型の新設、既存全行の更新のどれかかもしれません。これらは失敗の仕方が異なる別の操作です。

私は簡潔なマイグレーションパケットを使います。

1. 変更理由と、それを必要とするアプリケーションのバージョン。
2. 正確な順方向SQLと、正直に書ける場合は正確な復元SQL。
3. コマンドが影響し得るオブジェクト、権限、行。
4. 事前確認クエリ、期待結果、新しいスキーマフィンガープリント。
5. ロックタイムアウト、ステートメントタイムアウト、バックアップまたはスナップショットの参照先、リリース責任者。

復元スクリプトが常にロールバックになるわけではありません。新しく追加した列を削除すればカタログ変更は戻せますが、リリース後に書き込まれたデータも破棄されます。PostgreSQLのトランザクションDDLは多くのカタログ操作に役立ちますが、トランザクションでは外部への影響や後続コマンドが削除したデータを戻せません。破壊的な復元は、DOWNを魔法の言葉のように扱わず、明確にラベル付けしてください。

lock_timeoutを設定し、マイグレーションが新しい作業を止めながら、混雑したトランザクションの後ろで待ち続けるのではなく失敗するようにします。statement_timeoutはレビュー済み操作に合わせて設定します。変更時間帯の中で事前確認クエリを再実行してください。テーブルサイズ、競合オブジェクト、NULL数、スキーマフィンガープリントが承認時の前提と異なれば中止します。エージェントは本番向けの新しいマイグレーションを即興で作るのではなく、不一致レポートを返すべきです。

生成されたテストに通ったからといって、マイグレーションを自動承認してはいけません。テストは通常、小さくクリーンなスキーマで動き、ロック待ち行列、古いNULL、珍しい制約、拡張機能、まだトラフィックを処理しているアプリケーションバージョンを見落とします。承認では、人が生成された意図と稼働中のシステムを照合します。

接続プールは安全性の計算を変える

プールはデータベースセッションを再利用するため、セッション状態が作成元のリクエストより長く残ることがあります。あるリクエストがSET search_pathを実行したり、ロールを変更したり、一時オブジェクトを作成したり、タイムアウトを無効化したりすると、次の利用者がその結果を引き継ぐ可能性があります。アプリケーションは変更可能なセッション状態を避けるか、接続がプールへ戻るときに確実にリセットしなければなりません。

トランザクションプーリングでは境界がさらに厳しくなります。クライアントはトランザクションごとに別のサーバーセッションを受け取ることがあり、セッション準備済みステートメント、一時テーブル、アドバイザリロック、セッションレベル設定への前提が崩れます。ビルダーは直接接続では動くコードを生成しても、この違いをモデル化していないためプールの背後で失敗しがちです。プールがセッションモードかトランザクションモードかを決め、そのモードを生成とテストに含めてください。

デプロイ前に接続数を見積もります。データベースで許可される接続数から、管理、マイグレーション、監視、ほかのサービスの容量を確保し、残りをアプリケーションインスタンスに配分します。10インスタンスが各20接続を開くと、トラフィックが静かでもPostgreSQLには200の潜在セッションが見えます。データベースに拒否されるまで接続を増やすより、待ち行列を持つ控えめな小プールの方が通常は安全です。

サーバー側タイムアウトを最後の防波堤として使います。statement_timeoutは長いステートメントを制限し、lock_timeoutはロック待ちを制限し、idle_in_transaction_session_timeoutは何もせずトランザクションを開いたままのセッションを切断します。生成されたすべてのクライアントが設定を覚えていることを信頼せず、ロールごとに値を設定してください。実際のロールで、実際のプール経由のSHOWを使って検証します。

ヘルスチェックは軽量にします。SELECT 1は往復を確認しますが、アプリケーションが承認済みテーブルに到達できるか、search pathが正しいかは確認しません。レディネスチェックでは、実行時ロールで小さく安定したビューをクエリできます。マイグレーションをアプリケーション起動に入れないでください。同時に起動したインスタンスがスキーマ変更を競うと、この設計が取り除こうとしている結合が生まれます。

作り出された列名はクエリ実行前に失敗させる

LLMはもっともらしい識別子を作り出します。プロンプトで顧客の表示名を扱うと、データベースにはgiven_nameとfamily_nameしかないのに、生成コードがcustomers.display_nameを使うかもしれません。データベースはこのクエリを拒否します。誤ったフィールドを黙って読むよりは良いものの、本番エラーをスキーマ検証にするのはよくありません。

承認済みカタログスナップショットから型付きスキーマ成果物を生成し、それをクエリ構築の唯一の情報源にしてください。その成果物にないテーブルや列は生成エラーにします。タスクが明示的にマイグレーション経路に入らない限り、モデルにマイグレーション追加でエラーを修復させてはいけません。見つからない識別子は、古い検出、スペルミス、別の環境、本当のプロダクト要件を意味することがあります。対応はそれぞれ異なります。

静的チェックではSQLを解析し、すべてのリレーションと列をスナップショットに照らして解決します。その後、書き込めないトランザクションか使い捨てデータベースに対してステートメントを準備します。PostgreSQLのパーサーなら、成功する業務データがなくても、不明な列、曖昧な参照、演算子の型エラー、多くの不正なキャストを検出できます。実行時ロールで統合テストを実行し、権限と行ポリシーも参加させてください。

失敗レポートには、人が判断できる十分な詳細が必要です。SQL内の位置、未解決の識別子、近い有効な識別子、スナップショットフィンガープリント、対象データベースIDを含めます。候補表示は有用ですが、自動のあいまい置換は危険です。名前が近いからといってbilling_address_idをshipping_address_idに変えると、SQLは有効でも業務上の意味が誤ることがあります。

動的なフィルターと並べ替えでは、公開API名を修飾済みSQL式の閉じた集合に対応付けます。値パラメータ経由であっても、モデルが渡した識別子をSQLにそのまま貼り付けてはいけません。パラメータが保護するのは値であり、テーブル名や列名ではありません。ユーザーがソート項目を選べるなら、createdをapp.orders.created_atのような既知の式に変換し、不明なトークンはすべて拒否します。

スキーマドリフトはリリースを止めるべきであり、創造的な調整を始める合図ではありません。スナップショットを再生成して差分を示し、テストを繰り返してください。その遅れは細かすぎるように思えるかもしれませんが、データベースに対する理解が会話記録にしかないコードをデプロイするより安く済みます。

破壊的SQLには拒否ポリシーと証拠が必要

ビルダーは、誰かが実行できるようになる前にSQLを分類すべきです。DROP、TRUNCATE、レビュー済み述語のない広範なDELETEやUPDATE、所有権の変更、権限昇格、拡張機能の変更、承認済みスキーマ外を対象とするコマンドをブロックしてください。ALTER TABLEは自動的に安全とせず、レビュー必須として扱います。列型の変更や新しい非NULL制約はデータを走査または書き換え、重要なロックを保持することがあります。

SQLにはコメント、引用符付き識別子、関数、副作用を表すさまざまな方法があるため、文字列照合だけでは不十分です。PostgreSQL対応パーサーでステートメントを解析し、構文木を検査し、同時にデータベースロールで禁止操作を拒否してください。分類器はレビューを改善し、権限は境界を強制します。どちらか一方だけに負担を負わせてはいけません。

マイグレーションが実際のテーブル形状やデータ分布に依存するなら、最近の適切に保護されたスナップショットから復元したステージングデータベースを使います。そこで正確なマイグレーションパケットを適用し、所要時間とロックの観察結果を記録し、実行時認証情報でアプリケーションテストを実行してから、環境を破棄します。ステージングと本番の間でSQLを黙って編集してはいけません。編集はすべて新しい成果物となり、新しいフィンガープリントと承認が必要です。

ログは、秘密や機密行を記録せずに、提案と実行を結び付けるべきです。不変のマイグレーション成果物を誰が承認したか、そのダイジェスト、対象ID、開始と終了の状態、PostgreSQLエラー詳細を記録します。生成された差分と事前確認結果も保存してください。エージェントとのチャットは役に立つ文脈ですが、ユーザーは分岐、再試行、指示の言い換えができるため、監査記録にはなりません。

スナップショットとロールバック制御は復旧時間を短くしますが、破壊的SQLを許容できるものにはしません。実際に必要なのが削除された1列の復元なのに、スナップショットでデータベース全体を以前の時点に戻すことになり、スナップショット後の正当な書き込みを失う場合があります。復旧は別途テストし、誰が実行できるかを文書化してください。

確立済みデータベースに触れるアプリでKoder.aiを使うとき、エクスポートしたソースと提案されたデータベース境界を確認するまで、私は作業を計画モードに保ちます。スナップショットとロールバックは復旧のための制御であり、そのレビューを省く許可ではありません。同じ原則はどのビルダーにも当てはまります。製品の利便性は、データベースの強制力の内側に置く必要があります。

スキーマ変更は新旧アプリケーションの混在に耐える必要がある

マイグレーションが安全なのは、リリース時間帯に古いアプリケーションと新しいアプリケーションの両方が動ける場合だけです。本番環境が一瞬で1つのバージョンから別のバージョンへ切り替わることはめったにありません。新しいインスタンスが起動する間にも古いインスタンスにリクエストが届き、キュー内のジョブには古いペイロードが残り、ロールバックで昨日のコードが今日のスキーマに戻ることがあります。最終コードを最終スキーマに対してだけ検証するアプリビルダーでは、この重なりを見落とします。

まず追加的な変更を優先します。NULL許容の列、新しいテーブル、古い経路を削除しないインデックスを追加します。両方の表現を読み、新しい表現に適宜書き込めるコードをデプロイします。既存行のバックフィルは別途レビュー済みのジョブで行い、エラーと遅延を監視してから新しいフィールドを正とします。実行中のコードが古い列や制約を使っていない証拠が得られた後、別リリースで削除します。

この手順はALTER TABLE文を1つ生成するより時間がかかりますが、失敗を分離できます。削除前に新しいコードが誤動作しても、古い経路は残っています。バックフィルが遅れても、アプリケーションリリースを止めずに一時停止できます。デプロイをロールバックしても、古いアプリケーションはデータベースを認識できます。前のバイナリが、すでに削除した列をクエリすることをロールバック中に発見するより、追加のリリースの方が安く済みます。

PostgreSQLでは名前が直ちに変わるため、リネームには特に注意が必要です。生成器は新しい名前の方が読みやすいとして、customer_refをcustomer_idへ変更する提案をするかもしれません。マイグレーションのコミット直後から古いインスタンスは失敗します。customer_idを追加し、アプリケーションコードまたは範囲を絞ってレビューしたトリガーで両フィールドを同期し、読み取り側を移行します。古い書き込み側がなくなってからcustomer_refを削除してください。一時的な重複は削除条件を持つ見える負債ですが、即時リネームは見えないリリース結合です。

既定値と非NULL制約にも隠れた作業があります。SET NOT NULLを承認する前に、既存のNULLを数え、すべての稼働中ライターが値を渡すことを確認してください。大きいテーブルや高負荷テーブルでは、PostgreSQLのバージョンが制約をどのように検証し、どのロックを取るかレビューします。ビルダーは代表的なトラフィックがないスキーマから推測せず、これらの前提条件を報告すべきです。

データバックフィルを無制限のスキーマトランザクション内で実行してはいけません。承認済みワーカーを通じて計測可能なバッチで行を更新し、安定したカーソルで進捗を記録し、再試行を冪等にします。冪等とは、PostgreSQLが2回目のクエリを受け付けるだけでなく、2回適用しても意図した状態になることです。派生値では、後のコードが別の計算をする可能性があるなら、導出バージョンを記録してください。

リリースパケットには、4つの互換性ポイントを記載します。

1. マイグレーション前に実行を許容する最も古いアプリケーションバージョン。
2. 旧バージョンと新バージョンの両方が受け入れるスキーマ状態。
3. 破壊的なクリーンアップリリースを許可するシグナル。
4. データ変更後に新コードをロールバックした場合の復旧経路。

生成クエリでは、この移行中にSELECT *を避けてください。列の追加により、古いSQLが解析できても、スキャンコスト、結果のデコード、位置によるマッピング、データ公開が変わる可能性があります。修飾済みの列を明示的に列挙し、同じスキーマスナップショットからデコーダーを生成してください。これにより、ソースレビューでデータベース境界を越えるデータも正確に分かります。

準備済みマイグレーションツールは、適用済みバージョンをテーブルに記録することがよくありますが、バージョン番号だけでは互換性を証明しません。見やすい名前が同じ2つのファイルに別のコマンドが入ることがあるため、正確なSQL成果物のダイジェストを記録します。実行器は、すでに記録されたバージョンでダイジェストが異なる場合に拒否すべきです。また、必要な先行マイグレーションが欠けている場合は後続マイグレーションも拒否すべきです。

すべてのアプリケーションインスタンスに起動時マイグレーションを実行させてはいけません。マイグレーションツールがアドバイザリロックを使うとしても、起動は特権認証情報と、ヘルスチェックが期限切れになる前のスキーマ作業完了に依存します。マイグレーション実行は1つのリリースジョブに置き、その記録済み結果を待ち、スキーマを変更できないIDで実行時インスタンスを起動してください。リリースシステムがこの段階を分離できないなら、アプリケーションに所有者権限を渡す前にリリースシステムを修正します。

到達点だけでなく、次のタイムラインをテストしてください。旧コードと旧スキーマ、旧コードと拡張済みスキーマ、新コードと拡張済みスキーマ、新規書き込み後にロールバックしたコードです。クリーンアップは後で別にテストします。このマトリクスなら、構文上は有効でも運用上は元に戻せない変更を見つけられます。

否定的テストで境界を証明する

安全設計は、禁止操作がテストで失敗するまで完成しません。検出ロールで接続し、挿入、テーブル作成、SET TRANSACTION READ WRITEを試みます。実行時ロールで、未付与テーブルへのアクセス、行レベルセキュリティで保護されたテナント間読み取り、スキーマ変更を試みます。期待する結果はエージェントログの約束ではなく、PostgreSQLの権限エラーです。

肯定的テストも実行してください。検出は許可されたすべてのカタログ項目を読めなければなりません。実行時はプールを通じ、承認済みの各ユーザー操作を実行できなければなりません。マイグレーション実行は承認経路を通る場合だけ動作しなければなりません。通常の製品作業を止める境界では、障害発生時に誰かが所有者認証情報へ置き換えたくなります。

小さなアクセス契約をアプリケーションソースのそばに置いてください。データベース、許可スキーマ、検出範囲、実行時操作、プールモード、タイムアウト方針、マイグレーション承認者、スキーマフィンガープリントの方法、禁止ステートメントを記載します。継続的なチェックで実際の付与権限とこの契約を比較してください。誰もアプリケーションコードを変えていなくても、PostgreSQLの権限ドリフトは構成ドリフトです。

ロール変更、新しいテーブル、データベース復元、プールの更新、ホスティング変更の後に再確認します。既定権限は将来のオブジェクトに影響します。SELECT ON ALL TABLESの付与で対象になるのは現在のテーブルであり、後から作られたテーブルではありません。新しいオブジェクトをレビューまで見えない状態にするか、範囲を絞った既定権限で含めるかを決めてください。明示的な付与によって新しいテーブルをアクセスの検討対象にできるため、私は既定では見えない方法を好みます。

失効もテスト計画に含めます。検出認証情報を無効化して実行時トラフィックが続くことを確認し、実行時認証情報を無効化してマイグレーションツールがより強いIDを黙って代用しないことを確認します。その後、接続が有効な間に各シークレットをローテーションし、プールが意図した時間内に古いセッションを破棄するか観察します。パスワード変更では、すでに認証済みのセッションは終了しません。そのため、ローテーション手順には明示的なプール再作成またはPostgreSQLセッション終了ポリシーが必要です。

これらのテスト中は、障害メッセージから意図しない情報が出ないか確認してください。PostgreSQLエラーには、リレーション名、SQLの断片、制約名、渡された値が含まれることがあります。詳細なエラーはアクセスを制限したサーバーログへ送り、クライアントには安定した公開エラーを返し、本番エラーのストリーム全体をエージェントとの会話に流し込まないでください。ビルダーがコードを修正するにはステートメントの位置とサニタイズ済みのデータベース応答が必要であり、顧客の値は不要です。

最後に、意外なほど多くの危険な統合を見つけられるテストがあります。マイグレーション認証情報を完全に削除してアプリケーションのテストスイートを実行してください。通常の起動、ヘルスチェック、プレビュー、リクエスト処理が失敗するなら、スキーマ所有権が実行時経路に漏れています。ビルダーを本番に接続する前に、この結合を修正してください。AIアプリビルダーは所有しないデータベースでも使えますが、生成コードが取り決めを忘れたとき、PostgreSQLが拒否できなければなりません。