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 Viewer、公開済みサイト、またはその両方で表示されないのかを確認してください。
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 Viewer と公開済みサイトは、プロジェクトの異なる段階を表示しています。ビジュアルの変更を保存しても、それだけではライブサイトは更新されません。

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

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

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 やスクリーンショットで共有しないでください。