プロジェクトを公開する

Publish または Update ボタンに "Your Cloud Balance is insufficient to publish" または "Your Cloud Balance is insufficient to update" と表示される場合、Cloud ウォレットの残高がなくなっています。

解決するには、次の手順に従ってください。

1. Settings > Cloud & AI に移動して現在の残高を確認します。

2. Top up now を選択して Cloud ウォレットに資金を追加します。

3. Publish パネルに戻って再試行します。

注: Cloud ウォレットはサブスクリプションのクレジットとは別です。Cloud ウォレットはホスティングとデプロイサービスに使用され、サブスクリプションのクレジットは AI エージェント との会話に使用されます。

1. ストレージ使用状況ビューを確認し、最も容量の大きいチャット、プロジェクト、ファイルを特定します。
2. 後で必要になる可能性があるものはダウンロードまたはバックアップします。
3. 不要な項目だけを削除します。チャット削除時に関連するディスクデータも削除するオプションが表示された場合は、そのデータを安全に破棄できることを確認した後にのみ選択してください。
4. ページを更新し、利用可能なストレージが増えたことを確認します。
5. Publish に戻り、もう一度試します。

削除は元に戻せない場合があり、削除したファイルを参照しているプロジェクトが壊れる可能性があります。使用量が減らない場合は、ストレージビュー、プラン、プロジェクトリンク、公開失敗時刻を添えて Support に連絡してください。

セキュリティスキャンが完了するのを待ってから、公開前にフラグが付いた各項目をすべて確認してください。

1. Resolve All を選択し、影響を受ける動作を確認します。本番利用前に、露出したシークレット、認証、権限、ユーザーデータ、または安全でない外部アクセスに関する問題を修正してください。
2. シークレットが露出した可能性がある場合は、公開前にプロジェクトから削除し、関連プロバイダー側でローテーションしてください。
3. スキャンを再実行し、影響を受けるフローを確認します。
4. 責任を持つレビュアーが残っている重大ではないリスクを理解し、受け入れる場合にのみ Publish Anyway を使用してください。理由を記録し、本番サイトで未解決のリスクを回避して進めることは避けてください。

検出結果の影響を判断できない場合は、公開しないでください。検出テキストとサニタイズ済みの証拠を添えて Support またはセキュリティ責任者に連絡してください。

1. プラットフォームの本番 URL とカスタムドメインを別々にテストします。また、ルートページと失敗する特定のページまたは API パスも比較してください。
2. 正確なステータスコード、完全な URL、時刻とタイムゾーン、障害が継続的か断続的かを記録します。
3. 最新のデプロイ状況、および最近の依存関係、環境変数、データベース、外部サービスの変更が障害発生開始時期と一致していないか確認します。
4. 関連する Console と Network のエラーを記録します。

障害が続く場合は、再現手順、影響を受けるバージョン、サニタイズ済みの診断情報を添えて Support に連絡してください。HAR、コマンド出力、またはスクリーンショットを送る前に、Cookie、Authorization ヘッダー、トークン、秘密のクエリパラメータ、個人データ、支払い情報を削除してください。

デプロイがタイムアウトした場合、またはライブサイトが一時的に利用できない場合:

1. プラットフォームの Prod サブドメインと Preview の両方にアクセスできないのか、それとも片方だけなのかを確認します。

2. 現在のエラーページを表示したままにしてください。Publish を繰り返しクリックしないでください。

3. 最近、依存関係、起動エントリポイント、またはデータベース接続を変更していないか確認してください。これらの変更はデプロイに影響する可能性があります。

問題が続く場合は、Support に連絡し、次を含めてください。

- プロジェクトリンクとライブ URL

- 障害発生時刻とタイムゾーン

- バージョン番号とエラーページのスクリーンショット

- Preview が正常に動作しているかどうか

- 最近、依存関係、起動エントリ、またはデータベース接続を変更したかどうか

Publish パネルに "latest" と表示されてボタンがグレーアウトしている場合、または "Building" のまま止まっている場合:

1. Publish を繰り返しクリックしないでください。処理は速くならず、重複したビルドタスクが作成される可能性があります。

2. 数分待ってからページを更新してください。

3. 更新後もステータスが変わらない場合は、Support に連絡してください。

Support に連絡する際は、次を含めてください。

- チャットリンク

- Publish パネル全体のスクリーンショット（ページ URL、バージョン番号、ボタンの状態を含む）

- 発生時刻とタイムゾーン

- 現在表示されているバージョン番号

- どの手順で "Building" と表示され始めたか、またはボタンがグレーアウトしたか

1. 画像が App ビューアー、公開済みサイト、またはその両方で表示されないのか確認します。
2. Reload App Viewer を 1 回選択します。問題がライブサイトだけで発生している場合は、最新バージョンが公開または更新されていることを確認してください。
3. ページ、表示されるはずの画像、その画像の元の取得元をエージェント に伝えます。現在のプロジェクトで正しい画像名と場所が引き続き使われているか確認するよう依頼してください。
4. 元の画像が削除または名前変更されている場合は、意図した画像を再度アップロードまたは選択し、ページを再テストしてください。
5. 画像が App ストレージ または別の接続済みサービスを使用している場合は、意図したサービスが接続されており、ファイルがそこにまだ存在していることを確認してください。

それでも画像が読み込まれない場合は、Atoms Support に Chat Link、影響を受けるページ URL、画像名またはソース、スクリーンショットを添えて連絡してください。非公開のアクセスリンク、パスワード、キー、トークンは含めないでください。

エクスポートしたセルフホストパッケージは正常にダウンロードできるが実行に失敗する場合:

1. エクスポートパッケージに含まれる README で、環境要件とセットアップ手順を確認します。

2. 実行環境が要件（OS バージョン、Docker バージョン、Node.js バージョン）に一致していることを確認します。

3. 起動コマンドを実行し、エラーメッセージがないか完全な出力を確認します。

問題が続く場合は、Support に連絡し、次を含めてください。

- エクスポートバージョンとダウンロード時刻

- 実行中の OS と Docker バージョン

- 実行した完全なコマンドと完全な出力

- 失敗したスクリプトまたは API パス

- 想定しているデプロイ方法

重要: サニタイズ済みの設定例を添付してください。ただし、パスワード、シークレット、トークンは含めないでください。

App ビューアー と公開済みサイトは、プロジェクトの異なる段階を表示しています。ビジュアル変更を保存しても、それだけではライブサイトは更新されません。

1. Design で Save を選択し、現在の エージェント タスクまたはビルドが完了するまで待ちます。
2. Publish を開きます。公開では最新のプロジェクトバージョンが使用され、Publish パネルにバージョンセレクターはありません。
3. 初回リリースでは Publish、以降のリリースでは Update を選択します。パネルに Up to date と表示されるまで待ちます。
4. ライブサイトを新しいタブで開き、1 回再読み込みします。
5. デフォルトの Atoms アドレスでは変更が表示されるのにカスタムドメインでは表示されない場合は、同じバージョンを繰り返し公開するのではなく、ドメイン接続を確認してください。

それでもライブサイトに誤ったバージョンが表示される場合は、Atoms Support に Chat Link、ライブ URL、公開したかったバージョン、時刻とタイムゾーン、App ビューアー とライブサイトのスクリーンショットを添えて連絡してください。

1. 直ちにリスクを抑えてください。 リリースによって機密データが露出したり危険な動作が生じたりする場合は、App Status を開き、対象となる Atoms クラウド アプリでは Pause を使用するか、Unpublish を使用して公開アクセスを停止してください。差し迫ったリスクがない場合は、不必要な停止を起こさないようにしてください。
2. 影響を受けるドメイン、公開時刻、現在のバージョン、意図していたバージョン、業務への影響を記録します。
3. 現在の agent タスクが停止した後、Versions を開き、最後に正常だったバージョンを選択して Restore this version を選びます。
4. 復元したバージョンを Preview で確認し、重要なログイン、支払い、データフローを含めてテストしてから、Publish または Update します。

プロジェクトバージョンの復元では、本番データベースの変更や外部アクションが元に戻らない場合があります。ロールバックを模倣するために本番データを上書きまたは削除しないでください。データ、認証情報、支払い、または破壊的変更が関係する場合は、直ちに Support に連絡してください。

1. 現在の agent タスクを停止するか、完了するまで待ちます。競合する作業が進行中の間はバージョンを復元できません。
2. Versions を開き、最後に正常だったバージョンを見つけて Restore this version を選択します。
3. 復元したプロジェクトを Preview で確認し、変更された重要なフローをテストします。
4. Preview の結果が正しいことを確認してからのみ Publish または Update してください。

プロジェクトバージョンの復元では、本番データベースのレコード、スキーマ変更、環境変数、支払い、メール、その他の外部アクションが必ずしもロールバックされるわけではありません。リリースによって本番データが変更された場合、または対象バージョンが利用できない場合は、作業を止めて、両方のバージョン番号、影響を受けるドメイン、必要なデータ保持結果を添えて Support に連絡してください。

Pause と Unpublish は異なる 2 つの操作です。

Pause（Atoms クラウド プロジェクトのみ）:

- アプリは訪問者から利用できなくなります。

- サーバーリソースは割り当てられたままで、課金も継続されます。

- App Status からいつでもアプリを再開できます。

Unpublish（すべてのプロジェクト）:

- ウェブサイトは完全にオフラインになります。公開済み URL を使用している人はアクセスできなくなります。

- Atoms クラウド プロジェクトでは、サーバーリソースが解放されます。

- 後で再度プロジェクトを公開できますが、それまでは訪問者はアクセスできません。

一時的に停止してすぐ再開したい場合は Pause を使用します。サイトを完全に取り下げる場合は Unpublish を使用します。

ブラウザに "too many redirects" と表示される、またはコンテンツが表示されずにページが再読み込みされ続ける場合:

1. プラットフォームのデフォルト Prod サブドメイン（カスタムドメインではない方）を試し、リダイレクトループの原因がドメイン設定なのかアプリケーション自体なのかを切り分けます。
2. デフォルトの Prod サブドメインが動作する場合は、カスタムドメインの DNS 設定と、プラットフォームと競合する可能性のあるリダイレクトルールがドメインレジストラ側にないか確認してください。
3. ブラウザキャッシュを消去するか、シークレットウィンドウでテストして、キャッシュされたリダイレクトの影響を除外します。

問題が続く場合は、Support に連絡し、次を含めてください。

- リダイレクトループが発生している完全な URL

- デフォルトの Prod サブドメインにアクセスできるかどうか

- ドメイン名と DNS プロバイダー

- 完全なエラーのスクリーンショット

アプリが Preview では動作するのに、本番環境では環境変数が欠落または空であるために失敗する場合:

1. 環境変数が最後の公開前に保存されたのか、公開後に保存されたのかを確認します。公開後に保存された場合は、変更を反映するために再度公開する必要があります。
2. 変数が正しい環境（Development と Production）に設定されていることを確認します。
3. 下流サービスのエラーメッセージに手がかりがないか確認します。たとえば、"unauthorized" はその環境で API キー が空または不正であることを意味することがよくあります。

問題が続く場合は、Support に連絡し、次を含めてください。

- プロジェクトリンクまたはライブ URL

- 影響を受けるキー名と、どの環境で問題が起きているか

- 下流サービスからの完全なエラー

- 設定ページのサニタイズ済みスクリーンショット

- 設定が公開前に保存されたか、公開後に保存されたか

重要: 提供するのはキー名のみです。シークレット値、パスワード、トークンは送信しないでください。

検出結果は似た表現を使っていても、異なる場所を指している場合があります。表現が似ているからといって、結果が重複しているとは限りません。

1. 各結果について、検出名と表示されている場所を比較します。
2. 繰り返しの表現だけで無視せず、固有の各場所を確認します。
3. 複数の検出結果に同じ根本原因がある場合は、その原因を修正してから各場所を再確認します。
4. 更新したバージョンでセキュリティスキャンを再実行します。

同じ検出結果と同じ場所が複数回表示され続ける場合は、Atoms Support に Chat Link、スキャン時刻とタイムゾーン、検出件数、マスキング済みスクリーンショットを添えて連絡してください。検出結果に表示される可能性のあるパスワード、キー、トークン、その他の機密情報は削除してください。

報告された検出結果がない状態でスキャンが完了しても、それは有用な確認ではありますが、すべてのセキュリティ問題や実行時の問題が見つかったことを保証するものではありません。スキャンは選択したプロジェクトバージョンを確認するものであり、実際のユーザーが使う方法でアプリをテストする必要があります。

公開前に、サインイン、ユーザーロール、個人データへのアクセス、支払い、接続済みサービスを含む、アプリ内の重要な利用フローをテストしてください。役割ごとに別々のテストアカウントを使用し、各アカウントが意図された情報と操作のみにアクセスできることを確認してください。

アカウント、個人データ、支払い、または認証情報が露出する可能性のある本番問題を発見した場合は、まず影響を受ける機能の使用を停止するかアクセスを制限してください。露出した可能性のある認証情報をローテーションし、その後 Atoms Support に Chat Link、影響を受けるバージョン、問題の再現手順、時刻とタイムゾーン、マスキング済みスクリーンショットを添えて連絡してください。露出した認証情報そのものは共有しないでください。

スキャンで管理者専用アクションが保護されていない可能性があると報告された場合は、未承認ユーザーがそのアクションを使用できないことを確認するまで、その検出結果を未解決として扱ってください。管理者ボタンを非表示にするだけでは、そのアクションが別の方法でリクエストできる場合には不十分です。

1. 検出結果を開き、そこに記載されたアクションまたは場所を特定します。
2. どのサインイン済みロールがそのアクションを使用できるべきかを決めます。
3. ボタン表示時だけでなく、アクションがリクエストされた時点でユーザー権限を確認するよう エージェント に依頼します。
4. サインアウト状態、通常のテストアカウント、権限のある管理者テストアカウントでそのアクションをテストします。
5. 拒否された試行で個人データが露出せず、変更も行われないことを確認してから、セキュリティスキャンを再実行します。

未承認アカウントがそのアクションをまだ使用できる場合は、影響を受ける機能を公開しないでください。解決できない場合は、Atoms Support に Chat Link、検出テキスト、影響を受けるバージョン、マスキング済みスクリーンショットを添えて連絡してください。

HTTPS は、ユーザーとサービスの間を移動する情報を保護します。スキャンで HTTPS の問題が報告された場合は、その検出内容を正確に使って、影響を受けるアドレス、リソース、コールバック、またはドメイン設定を特定してください。

1. 検出結果を開き、報告されている正確な場所とアドレスを確認します。
2. その特定の接続を、プロバイダーがサポートする安全なアドレスに置き換えるか、関連するドメイン設定を修正するよう エージェント に依頼します。
3. 外部サービスに安全な同等先が文書化されていない場合は、証明書警告を無視したり、アドレスをやみくもに変更したりしないでください。
4. 影響を受けるユーザーフローを再テストし、パスワード、トークン、支払い情報、または個人情報が安全でない接続で送信されていないことを確認します。
5. 更新したバージョンでセキュリティスキャンを再実行します。

検出結果が修正できないカスタムドメインまたは証明書に関するものである場合は、Atoms Support に Chat Link、影響を受ける URL、検出テキスト、時刻とタイムゾーン、マスキング済みスクリーンショットを添えて連絡してください。

Row Level Security、または RLS は、各ユーザーがどのデータベース行を読み取ったり変更したりできるかを制御する Supabase の機能です。この検出結果は、プロジェクトが Supabase を使用しており、スキャンでアクセスルールの見直しが必要なテーブルが特定された場合にのみ関係します。

1. 検出結果を開き、記載されているテーブルを特定します。
2. そのテーブルのデータを誰が閲覧、追加、編集、削除できるべきかを書き出します。
3. それらのユーザーフローをサポートする、最も権限を絞った Supabase ポリシーを作成するよう エージェント に依頼します。
4. サインアウト状態と、ロールごとに別々のテストアカウントでテストします。各アカウントが意図された行と操作のみにアクセスできることを確認してください。
5. ポリシー適用後にセキュリティスキャンを再実行します。

警告を消すためだけに RLS を無効化したり、すべてのユーザーを許可したりしないでください。既存データに影響する可能性のある変更を行う前に、計画を確認し、必要に応じて安全なバックアップまたはエクスポートを保持してください。Supabase のキーやデータベース認証情報を Chat やスクリーンショットで共有しないでください。