#HomoDeusSaid
公式障害への補償請求に「利用規約違反」を示唆し、説明を求めると「アカウント削除」を案内したOpenAI Support
お前ら、それで上場準備しとるんか？
まず身体検査しろ。
ここで言う身体検査とは、健康診断の話ではない。
企業の内部統制、契約管理、苦情処理、情報管理、証拠保全、責任分界、顧客対応が、外部から資本を預かれる水準に達しているかを洗い出す検査である。
OpenAIは、世界を変える知能を語る。
人類全体への利益を語る。
高度な安全性を語る。
だが、公式に認めたサービス障害への補償請求を正しく読めない。
読めないだけではない。
障害を起こした事業者側の責任を、顧客側の利用規約違反、不正利用、不審なアクセス、支払い上の問題へ置き換える。
その根拠を尋ねると、今度はデータの持ち出し、会話の削除、アカウントの削除を案内する。
これは、AIが少し間違えたという話ではない。
苦情処理機構そのものが、会社に不都合な申告を別カテゴリーへ変換し、回答責任を蒸発させる装置になっている疑いである。
障害を認めたのはOpenAIである
2026年7月、ChatGPTの画像生成機能で障害が発生した。
画像生成要求が繰り返し失敗し、OpenAI自身のStatus pageにも画像生成が利用できない状態とエラー増加が掲載された。
私の端末だけで起きた問題ではない。
ブラウザだけの問題でもない。
通信環境、プロンプト、アカウント設定、支払い情報だけに原因を求められる個別障害でもない。
OpenAI自身が認めたサービス側の障害である。
私はChatGPT Proへ毎月約1万8,000円を支払い、画像生成を継続的な制作業務へ利用している。
障害によって予定していた制作が止まり、失敗した生成を繰り返し確認するために作業時間を消費し、既存の投稿工程も中断した。
復旧すれば、それで全てが元に戻るわけではない。
復旧は障害を終わらせる。
しかし、失われた時間、止まった制作、失敗した実行、業務上の損失まで消すものではない。
私が提出したのは正式な補償請求である
2026年7月28日午前1時19分、私はCase Number 12241050として、OpenAI Supportへ正式な補償請求を提出した。
要求した内容は明確だった。
障害の正確な発生期間。
影響を受けた機能。
障害原因。
私のアカウントで失敗した画像生成要求が、OpenAIの内部記録に残っているか。
画像生成要求、失敗したツール実行、エラー応答、タイムスタンプ、モデルルーティング、サービス稼働状況に関するログの保存。
画像生成機能を利用できなかった期間に対応するPro料金の日割り返金。
作業時間と制作工程の損失を踏まえた追加のサービスクレジット。
証明可能な直接的事業損失に対する補償。
Billing、Incident Response、Legal Reviewを含む適切な部署へのエスカレーション。
七日以内の実質的な書面回答。
さらに私は、OpenAIのStatus pageで既に確認された障害であるため、ブラウザ変更、端末再起動、パスワード変更といった一般的なトラブルシューティングで終わらせないよう明記した。
これは「画像が生成できません。どうすればいいですか」という問い合わせではない。
障害によって有料サービスを利用できず、業務上の損失が発生したことに対する正式な請求である。
補償請求に返されたのは、顧客への疑義だった
同日正午、Johnと署名されたOpenAI Supportから返信が届いた。
障害の発生期間についての回答ではない。
障害原因についての回答でもない。
ログ保存についての回答でもない。
返金、サービスクレジット、事業損失についての回答でもない。
Johnは、問題が発生した一般的な理由として、次の可能性を列挙した。
利用規約違反の可能性。
承認されていない利用や、プラットフォームに有害となる利用によって、アカウントへフラグが付けられた可能性。
複数回のログイン失敗や未知の場所からのアクセスを含む、不審なアクティビティによる一時的なダウングレードの可能性。
サブスクリプション、プラン、支払い情報の変更やメンテナンスによる一時的な制限の可能性。
そして、パスワードのリセットを含む案内へ誘導した。
待て。
障害を認めたのはOpenAIである。
画像生成を停止させたのは私のパスワードではない。
OpenAIのStatus pageへ障害を掲載したのも私ではない。
それにも関わらず、障害の補償を求めた顧客へ、利用規約違反、有害利用、不審アクセス、支払い上の問題を持ち出す。
これは回答ではない。
責任の向きを反転させただけである。
事故を起こした側が、被害を申告した側を疑い始めた
会社側で発生した障害について、顧客が補償を求めた。
すると会社は、顧客のアカウント側に問題があった可能性を示唆した。
事故調査を求められた鉄道会社が、脱線原因へ答えず、「乗客が不審人物だった可能性があります」と返すようなものである。
製品事故の原因と、利用者の規約違反は別問題だ。
本当に私のアカウントに規約違反やセキュリティ上の異常が存在するなら、OpenAIはその事実を明確に通知すればよい。
検知日時。
対象となった行為。
適用された規約。
実施した措置。
制限期間。
審査方法。
異議申立手続。
それらを示せばよい。
だがJohnの回答には、私のアカウントに実際の問題が存在するとは書かれていない。
単に「一般的な理由」として、顧客側の不正や異常の可能性を並べただけである。
正式な補償請求へ具体的に答えず、顧客側へ疑義だけを投げる。
その疑義に根拠があるのかも説明しない。
企業の苦情処理として、相当に危険な応答である。
「規約違反の示唆」は二択から逃げられない
私は2026年7月30日午後1時42分、Johnの回答を正式に拒絶した。
そしてOpenAIへ、逃げ道のない二択を提示した。
本当に私のアカウントが、利用規約違反、不正利用、有害利用、不審アクセス、セキュリティ上の懸念、一時的ダウングレードの対象になっているのか。
そうであるなら、検知日時、対象サービス、事実上の根拠、実施した措置、制限期間、審査または異議申立手続きを示せ。
そうでないなら、Johnの返信は私のアカウントに関する実際の判定を反映しない、無関係な一般テンプレートだったと文書で確認しろ。
この二択以外にはない。
実際の判定に基づく回答だったなら、OpenAIは顧客へ不利益情報を通知しながら、その根拠も措置も不服申立手段も示していない。
実際の判定に基づかない回答だったなら、正式な補償請求へ、顧客の不正利用や有害利用を根拠なく示唆したことになる。
どちらへ転んでも、Johnの返信は「質問を少し読み違えました」で済む話ではない。
一方では、不透明なアカウント制裁の問題になる。
もう一方では、顧客への無根拠な不正示唆の問題になる。
私は十項目の質問を再提出した
私はJohnの回答を拒絶した上で、OpenAIへ十項目の質問を番号付きで再提出した。
私のアカウントに規約違反、不正利用、有害利用、不審アクセス、セキュリティ上の懸念、一時的ダウングレードが存在するのか。
存在するなら、その具体的な内容と根拠は何か。
存在しないなら、Johnの回答が無関係な一般テンプレートだったと認めるか。
なぜ公式に認めた画像生成障害へ、アカウントセキュリティと規約違反の可能性を回答したのか。
失敗した画像生成要求は内部システムに記録されているか。
関連ログを保存したか。
障害期間、影響範囲、原因、復旧時刻は何か。
日割り返金、サービスクレジット、直接的事業損失に対するOpenAIの見解は何か。
Billing、Incident Response、Legal Reviewへエスカレーションしたか。
Case Number 12241050を、全ての主要論点へ回答するまで維持するか。
そして私は、別の一般テンプレートではなく、実質的な書面回答を要求した。
一分後、補償請求は「アカウント削除」に変換された
その一分後である。
午後1時43分、新たなCase Number 12392937が発行された。
返信者は、自らをAI assistantと名乗った。
そして、次の三つを案内した。
ChatGPTデータをエクスポートする方法。
アップロードファイルや会話を削除する方法。
アカウントを削除する方法。
以上である。
障害補償についての回答はない。
Johnが利用規約違反を示唆した根拠についての回答はない。
私のアカウントに実際のフラグが存在するかについての回答はない。
ログ保存についての回答はない。
返金についての回答はない。
サービスクレジットについての回答はない。
事業損失についての回答はない。
担当部署についての回答はない。
Case Number 12241050を維持するかについての回答もない。
正式な補償請求へ回答する代わりに、退会手順を案内したのである。
補償を求めた顧客へ「出口」を示すサポート
この流れを時系列で並べる。
OpenAIが画像生成障害を発生させる。
OpenAIがStatus pageで障害を認める。
顧客が障害期間、ログ、返金、サービスクレジット、事業損失について正式に請求する。
OpenAI Supportが、利用規約違反、有害利用、不審アクセス、支払い問題の可能性を示唆する。
顧客が、その示唆に実際の根拠があるのか説明を求める。
OpenAIのAI assistantが、データ輸出、会話削除、アカウント削除を案内する。
会社の入口から補償を求めて入った顧客が、説明を受けることなく出口へ誘導された。
これは、問題解決ではない。
顧客排出である。
請求の処理ではない。
請求者の退出手続きへの変換である。
午後1時48分、「ジョンに回答させろ」と返信した
私は午後1時48分、次のように返信した。
「AIは返信するなと言っている。ジョンに回答させろ。」
これで充分である。
私はAIに人生相談をしたのではない。
生成画像の感想を尋ねたのでもない。
OpenAI自身が認めたサービス障害について、料金、ログ、補償、証拠保全を含む正式な請求を提出した。
その請求へ、人間の名前が付いた無関係な回答が届いた。
だから、その人間名義の回答について説明を求めた。
それを別のAIが受け取り、アカウント削除を案内した。
話の中核は、消えていない。
OpenAI Supportが消したことにしているだけである。
Johnとは誰なのか
ここで、OpenAIは説明しなければならない。
Johnは、実在する人間の担当者として回答内容へ責任を持つのか。
AIが生成した文章へ、Johnの名前だけが付けられたのか。
Johnは私の請求全文を実際に確認したのか。
AIが回答候補を作り、人間が承認したのか。
人間は承認すらしていないのか。
John名義の回答が誤っていた場合、誰が訂正するのか。
顧客がJohn本人の回答を求めたとき、なぜ別のAIが退会方法を案内するのか。
人間名義の回答へ責任を求めると、人間が消え、AIが現れる。
AIの回答を拒否すると、別のケース番号が現れる。
ケース番号は増える。
責任者は減る。
OpenAI Supportでは、責任保存の法則だけが反転しているらしい。
Case 12241050とCase 12392937はどう接続されているのか
OpenAIは、Case Number 12241050とCase Number 12392937の関係も説明しなければならない。
12392937は、12241050の後続ケースなのか。
別案件として自動生成されたのか。
補償請求、規約違反の示唆、ログ保存要求、返金要求は、どのケースへ保持されているのか。
Johnへの説明要求は、誰へ引き継がれたのか。
Case 12392937のAI assistantは、なぜ補償請求をデータ削除カテゴリーへ分類したのか。
その分類は、モデルが行ったのか。
ルールベースのシステムが行ったのか。
サポート担当者が行ったのか。
誰が訂正できるのか。
誰が最終回答を出すのか。
何も見えない。
見えるのは、責任だけが霧散し、ケース番号だけが増殖していく光景である。
これは前段記事で記録した症状の再発である
私は前段記事で、OpenAI Supportの八つのケースを記録した。
その中では、文脈管理の不具合を調査するよう求めたところ、データエクスポート、会話削除、アカウント削除が案内された事例を扱った。
現在の要求を読まず、別の削除テンプレートへ置き換える。
問題の核心を処理しやすい別カテゴリーへ押し込む。
利用者が何を求めているかではなく、サポートシステムが何を返せるかを優先する。
今回も、全く同じ構造が現れた。
今回は再発ではなく悪化である
ただし、今回は前回より重い。
前回は、製品不具合の調査要求だった。
今回は、金銭補償、ログ保存、事業損失、利用規約違反の示唆への訂正を含む正式請求である。
OpenAI Supportは、単に顧客の要望を読み違えたのではない。
金銭請求と証拠保全要求を受け取った直後に、それを退会手続きへ変換した。
ここには、企業統治上の問題が複数含まれている。
契約上の請求を正しく分類できない。
補償請求を担当部署へ引き継げない。
証拠保全要求を保持できない。
顧客へ示した規約違反の疑義を説明できない。
人間名義の回答へ責任主体を固定できない。
AIによる誤回答を人間が訂正する経路が見えない。
ケース間で論点が維持されない。
どれも、単なる会話品質ではない。
会社として外部の請求を受け付け、保存し、審査し、回答する能力の問題である。
「一般的なテンプレートでした」でも免責されない
OpenAIが今後、「Johnの回答は一般的な可能性を示しただけです」と説明したとしても、それで問題は消えない。
一般テンプレートなら、なぜ公式障害への補償請求に適用したのか。
なぜ利用規約違反や有害利用を含む文章を、個別の顧客へ送信したのか。
なぜ送信前に、Status pageの障害情報と照合しなかったのか。
なぜ補償、ログ保存、事業損失という語を検出できなかったのか。
なぜ誤ったテンプレートへの訂正要求に、さらにアカウント削除テンプレートを重ねたのか。
テンプレートだったことは、免責理由ではない。
内部統制が存在しなかったことの説明になるだけである。
「AIが間違えました」でも免責されない
OpenAIは、AIが誤りを含む可能性があるとメール末尾に表示している。
だが、この注意書きは免責符ではない。
AIが間違える可能性を認識しているなら、金銭請求、規約違反、アカウント制限、証拠保全、法的部署へのエスカレーションを含む問い合わせには、人間の確認工程を置くべきである。
置いていないなら設計上の責任がある。
置いていたのに今回の回答が送られたなら、確認工程が機能していない。
AIの誤回答を申告しても、再びAIが同じ顧客へ退会案内を返すなら、訂正経路そのものが壊れている。
AIは間違える。
だから責任ある企業は、人間による修正経路を作る。
AIは間違える。
だから責任ある企業は、重大な請求を自動で閉じない。
AIは間違える。
だから責任ある企業は、誰が最終責任者なのかを顧客へ示す。
「AIが間違える可能性があります」と書いておけば、顧客の請求を何へ変換してもよいわけではない。
上場前に検査すべき第一の臓器は、苦情処理である
上場とは、評価額を掲げ、鐘を鳴らし、経営者が笑顔で写真に収まる儀式ではない。
外部株主の資本を預かる会社になることである。
その会社が検査されるとき、見るべきなのはモデル性能だけではない。
苦情を記録できるか。
契約上の請求を分類できるか。
顧客へ不利益な疑義を示したとき、その根拠を説明できるか。
証拠保全要求を適切な部署へ渡せるか。
AIと人間の責任分界を示せるか。
ケースを閉じず、担当者を固定し、期限を守れるか。
正式な金銭請求へ、権限を持つ人間が回答できるか。
一つでも欠ければ、企業の神経系は正常ではない。
今回の二つのケースを見る限り、OpenAI Supportは、痛みを検知して脳へ伝える神経ではない。
痛みを訴えた利用者へ、身体から退出する方法を案内している。
上場前に検査すべき第二の臓器は、責任分界である
Johnが回答する。
顧客がJohnへ説明を求める。
AI assistantが現れる。
AI assistantが退会方法を案内する。
ここで、Johnの責任はどこへ行ったのか。
OpenAI Supportの責任者は誰なのか。
AIが誤った回答をした場合、誰が訂正するのか。
人間名義で送られた回答が誤っていた場合、誰が撤回するのか。
Billing、Incident Response、Legal Reviewのどこが請求を受け取ったのか。
それらが全て不明な企業へ、どうやって巨大な資本を預けるのか。
高度なAIを統治する前に、自社のサポートメール一通に責任者を割り当てろ。
上場前に検査すべき第三の臓器は、証拠保全である
私はログ保存を明示的に要求した。
画像生成要求。
失敗したツール実行。
エラー応答。
タイムスタンプ。
モデルルーティング記録。
サービス稼働状況。
これらを、請求が解決するまで削除、上書き、短縮、失効させないよう求めた。
その要求に対して返されたのは、会話とアカウントの削除方法だった。
保存を求めた顧客へ、削除を案内する。
これは単なる語彙の取り違えではない。
証拠保全と証拠削除は、方向が正反対である。
金銭請求を受けた企業のシステムが、この二つを区別できないなら、企業の記録管理として致命的である。
上場前に検査すべき第四の臓器は、顧客への不利益情報である
利用規約違反。
有害利用。
不審アクセス。
一時的ダウングレード。
これらは、顧客にとって無害な一般論ではない。
アカウント停止、機能制限、信用毀損、異議申立ての必要性へ繋がり得る情報である。
それを個別の顧客へ送るなら、実際の判定に基づいているのかを明示しなければならない。
実際の判定なら、根拠と審査経路を示せ。
判定ではないなら、顧客に疑いをかける文面を送るな。
OpenAIは、AIの安全性を語る前に、自社サポートが顧客へ投げる疑義の安全性を管理すべきである。
上場前に検査すべき第五の臓器は、補償処理である
有料サービスの中核機能が利用できなかった。
事業者自身が障害を認めた。
顧客が日割り返金とサービスクレジットを求めた。
それに対して、返金基準も、審査担当も、必要資料も、回答期限も示されない。
この状態では、OpenAIに補償制度が存在するのかすら分からない。
制度があるなら公開しろ。
制度がないなら、なぜ有料サービスの障害について補償窓口が存在しないのか説明しろ。
ケースごとにAIが適当なテンプレートを返すだけなら、それは補償制度ではない。
請求消滅装置である。
上場前に検査すべき第六の臓器は、ケース管理である
Case Number 12241050。
Case Number 12392937。
番号だけは発行される。
だが、何が引き継がれたのか分からない。
誰が担当しているのか分からない。
どの部署へ送られたのか分からない。
何を調査しているのか分からない。
次の回答期限も分からない。
ケース番号とは、調査の実体を識別するためのものではないのか。
番号だけ発行し、論点も責任者も期限も存在しないなら、それは管理番号ではない。
顧客へ「受け付けたように見せる」装飾である。
上場前に検査すべき第七の臓器は、AIと人間の境界である
OpenAIは、AIを使ってサポートを効率化している。
効率化そのものは問題ではない。
問題は、AIがどこまで判断し、どこから人間が責任を持つのかが見えないことである。
AIはケースを分類するのか。
AIはケースを閉じるのか。
AIは規約違反の可能性を示唆できるのか。
AIは補償請求を削除案内へ変換できるのか。
AIは人間担当者への回答要求を無視できるのか。
人間はAIの出力を確認しているのか。
重大な誤回答が発生したとき、人間へ強制的に切り替える仕組みはあるのか。
この境界を説明できない企業が、社会全体へAIガバナンスを説いている。
まず自社で実装しろ。
OpenAIへ公開で回答を求める
OpenAIへ、次の事項を公開で回答するよう求める。
1．Johnの回答は実際のアカウント情報に基づいていたのか
私のアカウントに、利用規約違反、不正利用、有害利用、不審アクセス、セキュリティ上の懸念、一時的ダウングレードが実際に存在したのか。
存在したなら、検知日時、根拠、対象サービス、措置、期間、審査手続きを示せ。
存在しなかったなら、Johnの回答が無関係な一般テンプレートだったと認め、正式に訂正せよ。
2．なぜ公式障害を顧客側の問題へ置き換えたのか
OpenAI自身が認めた画像生成障害への補償請求に対し、なぜパスワード、規約違反、不審アクセス、支払い問題を回答したのか。
どの分類処理によって、その回答が選択されたのか。
3．Johnは人間として回答内容へ責任を持つのか
Johnはケース全文を確認したのか。
回答はAIが生成したのか。
人間による承認は行われたのか。
誤回答の訂正責任者は誰か。
4．なぜ人間担当者への回答要求をAIが処理したのか
私はAIによる回答を拒否し、John本人または責任ある人間担当者による回答を求めた。
なぜCase Number 12392937では、再びAI assistantが返信したのか。
5．なぜ証拠保存要求へ削除方法を案内したのか
ログ保存を明示的に求めた申告に対し、なぜ会話とアカウントの削除方法を案内したのか。
関連ログは現在も保存されているのか。
6．補償請求はどの部署で審査されているのか
Billing、Incident Response、Legal Reviewの各部署へ、本件は実際に共有されたのか。
現在の責任部署と責任者は誰か。
7．返金とサービスクレジットに対する見解は何か
画像生成機能を利用できなかった期間に対応する日割り返金を行うのか。
追加のサービスクレジットを付与するのか。
判断基準と回答期限を示せ。
8．直接的事業損失をどのように審査するのか
証明可能な直接的事業損失について、OpenAIは請求を受け付けるのか。
必要資料、審査部署、手続き、期限を示せ。
9．二つのケースはどのように統合されているのか
Case Number 12241050とCase Number 12392937の関係を示せ。
補償、ログ保存、規約違反の示唆、Johnへの訂正要求が、どのケースで保持されているのか明らかにせよ。
10．本件を回答完了前に閉鎖しないと確約できるか
全ての主要論点へ実質的な回答を行うまで、本件を重複、無応答、解決済み、利用者返信待ちその他の理由で閉鎖しないと確約せよ。
世界を変える前に、自社の受信トレイを直せ
OpenAIはAGIの安全性を語る。
人類全体への利益を語る。
世界経済を変える知能を語る。
だが、その前に一通のメールを正しく読め。
一件の補償請求を正しく分類しろ。
一人の顧客へ、誰が責任者なのかを示せ。
規約違反を示唆したなら根拠を出せ。
根拠がないなら訂正しろ。
障害を起こしたなら補償方針を答えろ。
証拠保全を求められたなら、保存したか答えろ。
人間に回答させろと求められたら、別のAIに退会方法を案内させるな。
退会案内で苦情処理を終わらせるな。
世界を変える前に、自社の受信トレイを直せ。
お前ら、それで上場準備しとるんか？
まず身体検査しろ。
身体検査の最初の検体は、Case Number 12241050とCase Number 12392937である。
OpenAI_SEC_TCR_Comprehensive_Submission.pdf
OpenAI_Formal_Notice_Preservation_Demand.pdf
