By

【暴露】OpenAIサポートの機能不全

#HomoDeusSaid

無断画像生成、有料利用枠の消費、文脈崩壊、重複クローズ、9日間の沈黙、そして「高速かつ無制限」という表示の実態

2026年6月21日から7月20日までの約1か月間、私はChatGPTの製品不具合とサポート対応について、OpenAIへ繰り返し正式な申告を行った。

申告したのは、「生成画像の雰囲気が好みではなかった」といった主観的な品質問題ではない。

画像を生成していない会話で画像生成ツールが勝手に起動する。明示的に禁止しても再発する。現在の指示より過去の文脈が優先され、別の場所、別の成果物、別の作業内容が出力へ混入する。数値で4:5と指定しても別のアスペクト比が生成される。生成処理の進捗も結果も表示されず、確認のため再読み込みすると「リクエストが多すぎます」と制限される。

そして、それらをOpenAIへ申告すると、ケースは「重複」として閉鎖される。どのケースへ統合されたのか分からない。既に提出した説明を再提出するよう求められる。「数日以内に返信する」と案内された後、9日、20日と実質的な回答がない。OpenAI側は何週間でも沈黙できる一方、利用者には「1日以内に返信しなければクローズする」と通告する。

本稿は、保存しているメール履歴、ケース番号、OpenAI Supportの回答、料金ページの表示を基に、この一連の対応を記録するものである。

法令違反や技術的原因を断定するものではない。確認できた事実、OpenAI自身の説明、そこから生じる疑問を分けて記載する。

ただし、記録を並べれば、偶発的な一件の誤回答では片付けられない構造が見えてくる。

製品がユーザーの現在の意思を保持できない。

サポートもユーザーの現在の申告内容を保持できない。

製品が過去の文脈へ勝手に戻る。

サポートも過去の別ケースへ勝手に統合する。

製品が指示を読まず、別の処理を実行する。

サポートも申告を読まず、別の案内を返す。

問題を調査するための窓口が、申告された問題と同じ症状を再現しているのである。


ケース1:画像生成を頼んでいないのに有料機能が実行され、申告後は20日間実質回答がなかった

2026年6月21日、私は、画像生成を依頼していない通常会話、感想、分析、画像生成器へ渡すテキストプロンプトの作成中に、ChatGPTが画像生成ツールを繰り返し起動した問題を正式に申告した。

特に重大なのは、一度目の誤実行後、私が画像生成を明確に禁止し、ChatGPT自身も「雑談、感想、分析では画像生成しない」「明示的な生成依頼がある場合だけ実行する」と認めた後にも、同様の誤実行が再発したことである。

問題は、不要な画像が一枚表示されたことではない。

画像生成には利用回数、時間枠、レート制限などが存在する。ユーザーが依頼していない生成が行われれば、本来の用途へ使える利用機会が失われる。私は、ツール呼出履歴、利用枠消費、原因、補填、再発防止、関連ログの保全を要求した。

OpenAIのAI支援サポートは、Case Number 10337718として申告を受け付け、「画像生成が意図せず実行され、画像生成利用枠に影響した可能性がある不具合」と整理した。続けて、「サポートスペシャリストにエスカレーションした」「今後数日のうちに返信が届く予定」と通知した。

しかし、数日以内の返信は来なかった。

7月1日、私は調査状況、補填可否、再発防止、担当部署について再度回答を求めた。7月11日までに20日が経過しても、ログ確認、利用枠消費、原因、補填、技術部署への共有について実質回答はなかった。

7月11日、Warnerと署名されたOpenAI Supportの返信は、ようやく本件を「画像生成品質ではなく、画像生成ツールの意図しない起動に関する問題」と認識していると回答した。

だが、具体的な調査結果は開示されなかった。完了時期も示されず、利用枠消費も補填可否も回答されなかった。

さらに不可解なことが起きた。

7月15日、私は「問題は何も解決していない。実質的な是正措置までケースを閉じず定期連絡をしてほしい」と返信した。

その翌日、OpenAIは再び、「問題の説明」「再現手順」「スクリーンショット」「画面録画」を提出するよう要求し、「1日以内に返信がなければチケットをクローズする」と通知した。

これらの情報は、6月21日以降、何度も詳細に説明済みだった。Warner名義の前回回答でも、問題内容を正しく理解したと明記されていた。

にも関わらず、ケースは初回受付以前の状態へ巻き戻された。

私は7月16日、ケース履歴を確認せず同じ情報を再要求し、利用者側へ24時間の期限を課す対応へ正式に抗議した。

ところが7月18日、再びほぼ同じ文面で、「問題の説明」「再現手順」「スクリーンショット」「画面録画」を求め、「1日以内に返信がなければクローズする」と通知された。

OpenAI側は20日間回答を保留できる。

利用者は1日返信しなければケースを閉じられる。

調査中の案件を維持する責任まで利用者へ転嫁される。

しかも、OpenAIが一度は問題を正しく理解した記録を残した後で、再び最初から説明を要求している。

これは単なる返信遅延ではない。苦情処理の継続性、ケース履歴の保持、担当者間の引き継ぎ、調査責任の所在が機能しているのかを疑わせる対応である。


ケース2:文脈管理の破綻を申告したら、OpenAIサポート自身がケースの文脈と統合先を見失った

2026年7月12日、私は画像生成ツールの誤実行とは明確に分けて、文脈管理の不具合を新たに申告した。

同一スレッド内で複数の制作物を扱う中、ChatGPTが現在の編集対象を見失い、過去の「フラワーアレンジメント動画プロンプト」へ勝手に戻り、求めていない動画プロンプト全文を出力した。

また、このスレッドでは「仕事しろ」という指示が、説明や反省ではなく、直前の成果物を即時に修正して完成本文を出す意味として確立していた。それでもChatGPTは、原因説明やメタ応答を返し続けた。

申告文には、画像生成ツールの問題は別ケースで扱っており、今回の対象は「会話文脈」「現在の編集対象」「過去文脈への誤復帰」「ユーザー固有の作業指示の保持」であると明記した。

しかし、Case Number 11319313は、送信から約1分後に「既存ケースと重複している」として閉鎖された。

私は、画像生成ツールの誤実行とは別の問題であると異議を申し立てた。

するとCase Number 11319385が発行され、OpenAIは、「Case Number 11319313がどの既存ケースと重複したのか、このメールだけでは確認できない」「重複元のケース番号を教えてほしい」と回答した。

重複と判断して閉鎖したのはOpenAIである。

ところが、何と重複したのかをOpenAI自身が把握していなかった。

私が「重複判断したのはそちらだ。そちらでケースを整理しろ」と返信すると、今度は11319385も「既存ケースと重複している」として閉鎖された。

続いてCase Number 11319521が発行された。

私は「まとめた先のケース番号を案内しろ」と要求した。

OpenAIは、「このスレッド側では統合先を確認できない」「受信箱で過去メールを検索し、元ケース番号を貼り付けてほしい」と回答した。

つまり、統合処理を行った側が統合先を参照できず、利用者へ受信箱を検索させようとしたのである。

大量の過去メールを利用者側で再提出した後、OpenAIはようやく統合先をCase Number 10837305と回答した。

しかし、その後に届いた「サポートの要約」では、独立して申告したはずの「文脈管理」「現在の編集対象の誤認」「作業ルールの不保持」が消えていた。

要約されたのは、「画像生成ではないと述べたにも関わらず画像生成を起動した」という別の問題だった。

文脈管理の破綻を、画像生成問題と分けて扱うよう繰り返し要求した。

それにも関わらず、最後には再び画像生成問題へ縮約された。

ChatGPTが「いま何を編集しているか」を見失ったため、文脈管理の不具合を申告した。

OpenAIサポートは「いま何の問題を扱っているか」を見失い、別ケースへ誤統合した。

製品の症状を、サポートがそのまま再現した事例である。


ケース3:ツール誤作動と文脈混入の調査を求めたら、会話とアカウントの削除方法を案内された

2026年7月2日、私はChatGPTの「高」設定を使用中に発生した、ツール誤呼出と文脈混入をCase Number 10837305として申告した。

一つは、「画像生成ではありません」「画像生成器へ渡す日本語プロンプト本文のみ」と明記しても画像生成ツールが起動した問題である。

もう一つは、「レイキャビク・冬の地熱パイプ管理棟」と指定したにも関わらず、直前に扱っていた「富士五湖・湖畔グランピング」の内容が出力へ混入した問題だった。

最初のAIサポート回答は、「高とはGPT-5.5 ThinkingのExtended reasoningである」という説明だった。

私は「高」の名称や意味を質問していない。

問題にしているのは、その設定下で、明示的な禁止指示に反してツールが起動し、現在の入力より過去の文脈が優先されたことである。

OpenAIは、会話URLと発生日時を求めた。

私は共有リンクを提出した。

すると、今度は時刻を求められた。

発生期間を「6月20日から現在」と伝えると、「範囲が広すぎるため、一回の実行日時へ絞ってほしい」と返された。

同時に、OpenAIは「Imagesに生成物が残っていれば画像生成が実行された根拠になる」と説明し、不要なら画像が作られた会話を削除すればImagesからも消えると案内した。

これは、「証拠を消せと命じた」という意味ではない。

しかし、誤実行の事実、利用枠消費、ログ保全を調査してほしいという申告に対して、削除方法を案内することは、少なくとも証拠保全という目的とは逆方向である。

私は、共有リンク、対象アカウント、対象期間、ツール種別が明らかなら、OpenAI側で会話ログとツール実行履歴を検索すべきだと要求した。

その直後、Case Number 10837305は「重複」を理由に閉鎖された。

さらに7月12日、画像生成ツール問題とは切り離し、文脈管理だけを対象とする詳細な調査要求を同じメールスレッドへ送った。

そこには、「本件では画像生成ツールの誤実行を扱わない」「現在の編集対象、過去文脈への誤復帰、作業指示の保持を調査してほしい」と明記していた。

これに対してCase Number 11319858で返された内容は、次の三つだった。

ChatGPTデータのエクスポート方法。

アップロードファイルや会話の削除方法。

アカウントの削除方法。

文脈管理の調査要求に、データ取得と削除と退会の案内が返された。

その約1分後、ケースは重複として閉鎖された。

「現在の要求より、別の文脈を優先する不具合」を申告したメールに対して、OpenAIサポートは現在の要求を読み取らず、無関係な削除案内を返した。

ここでも、製品上の症状とサポート上の症状が鏡写しになっている。


ケース4:4:5を守らない不具合を申告したら、参照画像を失敗画像と誤認され、9日間放置された

2026年7月11日、私は画像生成器が指定したアスペクト比を守らない問題をCase Number 11271585として申告した。

私は画像生成で、単に「縦長」や「4:5」と一度書くだけではない。

横幅対縦幅を4対5、横幅÷縦幅を0.8、縦幅÷横幅を1.25と指定し、許容寸法を1024×1280、1536×1920、2048×2560、または完全に同じ比率の整数寸法だけに限定している。

1:1、3:4、2:3、9:16、16:9への変更を禁止し、別比率からのクロップ、アウトペイント、自動トリミング、自動拡張も禁止している。

それでも、別のアスペクト比が出力される。

用途が4:5のブロマイドや広告素材である以上、比率が違えば内容が良好でも使用できない。

一回の生成には約2分を要する。比率違反が起きる度、再生成、確認、再送信、再待機が必要になる。これは創作上の試行錯誤ではなく、数値仕様を守らなかったために強制される再作業である。

AIサポートは、環境、モデル名、使用したプロンプト、出力寸法、参照画像のサイズ、発生時期を求めた。

私はChrome、GPT-5.6 Instant、実際に使用した長文プロンプト全文、参照画像、問題が増えた時期を提出した。

返信には明確に「参照画像は添付」と書いた。

ところがOpenAIは、その添付画像を「アスペクト比違反が起きた生成結果」と誤認し、画像の実ピクセル寸法を利用者側で確認するよう求めた。

私は、添付画像は失敗画像ではなく参照画像であると訂正した。

また、失敗画像はOpenAIのサービス上で生成されており、生成履歴、アセット情報、出力寸法、モデル、キャンバス設定はOpenAI側の記録から確認すべきだと指摘した。

参照画像の役割さえ読み取れないAIへ同じ質問を反復させず、人間の担当者と技術部署へエスカレーションするよう要求した。

同日午前3時45分、OpenAIは「サポートスペシャリストへエスカレーションした。今後数日以内に返信を待ってほしい」と通知した。

2026年7月20日時点で9日が経過している。

調査結果はない。

進捗報告もない。

参照画像を誤認したことへの訂正もない。

技術部署へ共有したかも不明である。

補填可否も不明である。

利用環境、モデル、プロンプト全文、参照画像、発生時期まで提出し、人間の担当者へ引き継いだと通知した後で、9日間沈黙している。


ケース5:画像生成の進捗も結果も消え、確認すると利用制限される不具合を申告したら、一分で閉鎖された

2026年7月11日午前2時51分、私は、7月10日以降に発生した画像生成UIの異常を申告した。

画像生成を開始しても進捗表示が出ない。

処理中なのか、停止したのか、完了したのか判別できない。

待っても生成結果が画面へ返らない。

結果を確認するためにページを再読み込みする。

再読み込みを繰り返すと「リクエストが多すぎます」と表示される。

画像生成だけでなく、通常のChatGPT利用まで停止する。

申告では、この因果関係を六段階で示し、7月10日前後のUI変更や配信変更との関係、フロントエンドの状態同期、生成ログ、エラーログ、正式な回避方法、補填、技術部署へのエスカレーションを求めた。

午前2時52分、OpenAIはCase Number 11269846を発行した。

その一分後、既存ケースと重複しているとして閉鎖した。

どのケースへ統合したのかは案内されなかった。

進捗表示の消失、結果配信の失敗、再読み込みとレート制限の連動が、統合先で調査対象になったのかも分からない。

後述するCase Number 11268075と内容が近く、時間的にも後に送られているため、そこへ統合された可能性はある。

しかし、これは推測にすぎない。

OpenAIは統合先を明示していない。

「重複」という事務処理だけが通知され、技術的な論点がどこへ行ったのか分からない状態が9日間続いている。


ケース6:画像が表示されないため再読み込みすると制限される問題を、利用環境の問題として扱い、エスカレーション後9日間沈黙した

ケース5より約40分前の7月11日午前2時10分、私は、画像生成結果が表示されず、再読み込みすると「リクエストが多すぎます」と制限される問題をCase Number 11268075として申告していた。

利用状況として、ChatGPT Pro、Chromeブラウザ版、二つの画像生成ページを並行利用していることも明示した。

求めたのは、画像生成結果が表示されない原因、再読み込みがレート制限へ計上されるか、複数タブ利用の正式仕様、通常作業まで停止する条件、ブラウザ版の修正だった。

OpenAIの最初の回答は、拡張機能、VPN、プロキシ、セキュアDNSを無効化し、シークレットウィンドウや別ブラウザを試すという一般的なトラブルシューティングだった。

さらに、結果が表示されない場合は30秒から60秒待ち、「停止」して「再生成」し、必要ならハードリロードを試すよう案内した。

しかし、申告内容は「表示されないため再読み込みすると制限される」というものだった。

それに対する回避策として、再読み込みを含む操作が提示された。

また、生成がサーバー側で完了している可能性がある状態で「再生成」を行えば、重複生成になる可能性がある。

私は、問題が先月から継続しており、原因となる表示不具合を調べず、やむを得ず行った再読み込みだけを利用者側の過剰操作として扱うのは、原因と結果の逆転だと抗議した。

人間の担当者と技術部署への即時エスカレーション、生成処理ログ、フロントエンド配信、制限条件、複数タブの仕様、補償方針を要求した。

午前2時19分、OpenAIは「サポートスペシャリストへエスカレーションした。今後数日以内に返信を待ってほしい」と通知した。

それから9日が経過した。

調査結果は届いていない。

進捗報告もない。

ケース5が本件へ統合されたのかも案内されていない。

「数日以内」という文言だけが残り、技術的な説明は何も返っていない。


ケース7:GPT-5.5 Thinkingの包括的な性能劣化を英語で申告したら、二分後に「重複」として閉鎖された

2026年7月5日午後3時4分、私はGPT-5.5 Thinkingの挙動について、英語で包括的な技術調査を依頼した。

列挙した問題は五つある。

画像生成を禁止してもツールを起動する。

サンフランシスコのホテル裏口という過去の舞台を、ベルギー・アントワープ港の新しいプロンプトへ混入させる。

「ブロマイド」は4:5縦長、上半身という作業条件を繰り返し失う。

アメリカンダイナーのテーブルが通路へ飛び出して見える問題を、カメラ、クロップ、遠近法で直さず、実物のテーブル自体を異常に小さくする。

完成本文だけを求めているのに、説明、謝罪、メタコメントを挿入する。

私はこれらを、単発の創作上の解釈違いではなく、回帰、ルーティング異常、設定劣化、メモリや文脈処理の問題、ツール使用上の不具合、アカウント単位の挙動異常の可能性として調査するよう求めた。

「モデルは間違えることがあります」という一般論は求めていないとも明記した。

午後3時6分、Case Number 10976796は「既存ケースと重複している」として閉鎖された。

所要時間は二分だった。

どのケースと重複したのか。

五つの症状が既存ケースへ引き継がれたのか。

GPT-5.5 Thinkingの回帰という論点が技術部署へ共有されたのか。

回答はなかった。

日本語で個別症状を送れば、周辺的な質問とテンプレート回答が返る。

英語で複数症状を整理し、包括的な回帰調査を求めれば、二分で重複閉鎖される。

問題を細分化しても、統合しても、実質的な技術調査へ進まない。


ケース8:Pro料金表は「高速かつ無制限」と明記するが、OpenAIはPlusより常に速いわけではなく、制限もあると回答した

2026年7月2日、私はChatGPT Proの画像生成速度について、PlusからProへ変更しても体感上ほとんど差がないとして、Proの「高速」「無制限」が具体的に何を意味するのか問い合わせた。

これは個別環境の一時的な遅延調査ではない。

Proプランの表示、Plusとの差、契約上提供される機能の正式な意味を確認する質問だった。

最初のAIサポート回答では、Proの画像生成がPlusより常に明確に速くなることを保証する固定仕様や、速度差の内訳を明文化した公開情報はなく、同じモデル、同じ混雑状況なら体感速度がほぼ同じに見えることもあり得ると説明された。

その後、Razelと署名されたOpenAI Supportの人間担当者から、より具体的な回答が届いた。

その回答によれば、Proの「faster」は、全ての画像がPlusより明確に速く完成することを保証するものではない。

主として、高い利用上限、高需要時の優先アクセス、混雑時の遅延や制限を受けにくくすることを意味する。

通常負荷時には、PlusとProの画像生成速度が体感上ほぼ同じに見える場合も想定されている。

「unlimited」または「virtually unlimited」も、制約が一切ないという意味ではない。

通常利用に固定の日次・月次クォータがないという趣旨であり、フェアユース、一時的なレート制限、スロットリング、不正利用防止、安全対策、メンテナンス、インフラ状況による制御を受け得ると回答された。

一方、2026年7月20日現在、OpenAIの日本語料金ページは、Proの特典として、明確に「高速かつ無制限の画像作成」と表示している。

その直下には、「無制限で利用できますが、不正利用防止のための安全対策が適用されます」という注記がある。

しかし、「高速」が個々の画像生成時間の短縮を保証せず、通常負荷時にはPlusと同程度になり得ることや、実質的には主として混雑時の優先性を指すという説明は、少なくとも同じPro欄には表示されていない。

料金ページで利用者が最初に目にする表現は、「高速かつ無制限」である。

購入後、サポートへ詳しく問い合わせると、「全ての生成が速いわけではない」「通常時はPlusと同程度の場合がある」「無制限にも複数の制限がある」と説明される。

購入前の表示は短く、強い。

限定条件は購入後の個別回答で長く説明される。

この情報配置に、一般消費者の契約判断へ影響するほどの乖離があるかが、景品表示法上の検討対象となる。

消費者庁は、サービスの品質、規格その他の内容について、実際より著しく優良であると一般消費者へ誤認させ、自主的かつ合理的な選択を阻害する恐れがある表示を、優良誤認表示として禁止している。また、価格その他の取引条件について、実際より著しく有利であると誤認させる表示を、有利誤認表示として禁止している。故意でなく、誤って表示した場合でも規制対象となり得る。

本件が実際に違法かどうかは、私が断定することではない。

当時の日本語料金ページ全体、注記の位置と明瞭性、「高速」「無制限」という表現の根拠、PlusとProの実測・運用差、一般消費者が受け取る全体的印象を、消費者庁が判断する事項である。

ただし、OpenAI自身のサポート回答と、現在の料金ページ上の表示が、そのまま一致していないことは確認できる。

だからこそ私は、優良誤認表示または有利誤認表示に該当し得る疑いとして、消費者庁への情報提供を行うことをOpenAIへ通知した。

OpenAIはその後も説明を撤回せず、懸念を社内の適切なチームへ共有したと回答した。

表示修正の予定、法務審査の有無、根拠資料、具体的な対応時期は明らかにされていない。


八つのケースを貫く、同じ処理構造

個々の不具合だけを見ると、別々の問題に見える。

無断画像生成。

文脈混入。

アスペクト比違反。

進捗表示の消失。

結果配信の失敗。

レート制限。

プラン表示。

だが、サポート対応まで含めて並べると、共通する処理構造がある。

1.問題の核心を別のカテゴリーへ置き換える

ツール制御の問題を画像品質の問題として扱う。

文脈管理の問題を画像生成問題へ統合する。

現在の編集対象の誤認を、データエクスポートやアカウント削除の話へ置き換える。

表示とレート制限の因果関係を、VPNや拡張機能の問題へ置き換える。

利用者が何を問題にしているかより、サポートシステムが処理しやすい既存テンプレートへ申告内容を押し込んでいるように見える。

2.OpenAI側が保有する情報の再収集を、利用者へ要求する

会話URL。

発生日時。

スクリーンショット。

画面録画。

生成画像の実寸。

過去ケース番号。

統合先ケース番号。

これらの一部を補助情報として求めること自体は不合理ではない。

問題は、OpenAI側の会話履歴、ツール呼出記録、生成アセット、ケース履歴、添付ファイルから確認できるはずの情報まで、利用者が改めて探し、整理し、提出しなければ調査が始まらないかのように扱われていることである。

とりわけ、重複判定したOpenAIが統合先を把握できず、利用者へ過去メールを検索させた事例は象徴的である。

3.「重複」が、調査の整理ではなく回答終了の装置になっている

重複ケースを一つにまとめる運用自体は合理的である。

しかし、合理的な統合には最低限、次の情報が必要だ。

統合先ケース番号。

移管された論点。

既存ケースで調査される内容。

担当部署。

次回の回答予定。

今回の複数ケースでは、「重複なので閉じました」とだけ通知され、統合先すら示されなかった。

重複判定が、複数の問題を総合的に調査するためではなく、個々のケースを閉じるために機能しているように見える。

4.エスカレーションは通知されるが、その後の工程が見えない

「サポートスペシャリストへエスカレーションしました」

「今後数日以内に返信がある見込みです」

この文言は何度も送られた。

しかし、その後に9日、11日、20日と返信がない。

担当部署は不明。

調査開始の有無も不明。

ログ確認の有無も不明。

次回回答予定日も不明。

エスカレーションという言葉はあるが、エスカレーション後の責任主体が見えない。

5.OpenAIの期限と利用者の期限が著しく非対称である

OpenAIは、「数日以内」と案内した後、20日間実質回答をしなかった。

その一方で利用者には、「1日以内に返信がなければケースをクローズする」と通知した。

しかも、その前日に利用者はケース継続を明示していた。

事業者側の無応答は無期限に近く許容され、利用者側には24時間の返信義務が課される。

この運用は、苦情処理の責任を利用者側へ移す構造になっている。

6.AIサポートが、申告されたAIの問題を再演している

文脈管理の破綻を申告すると、サポートが申告の文脈を見失う。

添付画像の役割を説明しても、サポートが画像を誤認する。

現在の問題を説明しても、過去の別ケースへ戻る。

同じ情報を何度提出しても、再び最初から質問される。

ChatGPTの不具合を調査する入口に、同種の不具合を持つAIを配置し、そのAIがケースを閉じる権限まで持っている。

この設計では、製品上の問題とサポート上の問題が互いを増幅する。


「モデルは間違えることがある」で終わる問題ではない

生成AIが常に正解するとは考えていない。

創作における解釈差、文章表現の違い、人物の細部、背景の美的判断まで、全てを不具合と呼ぶつもりもない。

今回問題にしているのは、より基礎的で、検証可能な事項である。

「画像生成ではない」と書いたのに画像生成ツールが起動した。

「4:5」と数値で指定したのに別比率が生成された。

現在の地名を明記したのに、過去の別の地名が出力された。

同じ質問を二度繰り返しても、現在の質問へ戻れなかった。

進捗も結果も表示されず、状態確認すると利用制限を受けた。

「数日以内に返信する」と案内され、9日、20日返信がなかった。

これらは、創造性の幅や好みの差ではない。

ツールの起動有無。

キャンバス比率。

現在の入力文字列。

画面上の処理状態。

ケースの返信日。

いずれも客観的に確認可能な事項である。


OpenAIへ公開で回答を求める

本稿の公開後も、私は次の点について回答を求める。

Case Number 10337718で、画像生成を依頼していない会話に対するツール起動を、OpenAIのログで確認したのか。

明示的な画像生成禁止後にも再発した事実を確認したのか。

誤実行によって画像生成の利用枠、時間枠、利用機会が消費されたのか。

補填、利用枠回復、クレジット、利用期間延長、料金調整を検討したのか。

Case Number 11271585で、添付画像が失敗画像ではなく参照画像だったことを認識したのか。

指定4:5と実出力の寸法を、OpenAI側の生成履歴で照合したのか。

Case Number 11268075で、画像生成結果がフロントエンドへ表示されない原因を調査したのか。

再読み込みがレート制限へ影響したのか。

二つの画像生成ページを同時利用する正式な仕様は何か。

重複閉鎖されたCase Number 11269846、10976796、11319313、11319385、11319858の統合先はどこか。

それぞれの申告内容が統合先で調査対象として保持されているのか。

「サポートスペシャリストへエスカレーションした」という通知は、実際にどの部署へ、どの情報を、いつ送ったことを意味するのか。

「数日以内」と案内しながら9日、20日連絡しなかった理由は何か。

Proの「高速かつ無制限の画像作成」という日本語表示について、「高速」が個別画像の生成完了時間ではなく主として混雑時の優先性を意味するなら、なぜその限定を料金比較画面上で明示しないのか。

「無制限」に適用されるレート制限、フェアユース、スロットリングその他の条件を、契約判断前の利用者へどこまで具体的に表示しているのか。


記録は、説明が消えた後にも残る

OpenAIは画面を更新できる。

料金ページの文言を変更できる。

サポートケースを閉じることもできる。

過去の返信を要約し、別の論点へ縮約することもできる。

だが、保存されたメール、ケース番号、日時、スクリーンショット、サポート担当者名、返信内容までは、後から「何も起きなかった」ことにはできない。

本稿で公開したのは、OpenAIの内部推論でも、機密情報でもない。

利用者が実際に受け取ったサービス。

利用者が実際に送った申告。

OpenAIが実際に返した回答。

そして、返さなかった回答である。

OpenAIが「安全」「信頼」「高度な知能」を掲げ、有料プランを提供するのであれば、その信頼性はモデルのデモ映像だけで測られるべきではない。

誤作動が起きたときに、事実を確認できるか。

利用者の説明を保持できるか。

ケースを適切に引き継げるか。

有料資源を誤って消費した場合に原状回復できるか。

料金表示の意味を、購入前に明瞭に説明できるか。

そして、自社の不具合について、責任ある人間が期限を区切って回答できるか。

そこまで含めて、初めて有料AIサービスである。

このブログを購読(RSS)
1st Project Anniversary 🎉
Shōhei KIMURA|Facebook
Yōhaku KIMURA|𝕏
コーヒーブレイクを提供してくださいますか?

【開発に興味のある方】
bitBuyerコミュニティ規約
LINEオープンチャット
Dicordサポートラウンジ

bitBuyer Projectをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む