- AppleはFeedback Assistantを通じて報告されたバグについて、ユーザーが「まだ修正されていない」と**直接確認（verify）**しない限り、自動的にクローズする
- 3年間応答がなかった**ネットワークフィルタ拡張に関する個人情報漏えいバグ（FB12088655）**について、Appleが突然確認を求め、2週間以内に返答がなければ修正済みと見なした
- しかし、Little Snitchの開発者が最新のmacOSでも同じ問題が残っていることを確認したにもかかわらず、Appleはレポートを閉じた
- この手続きはバグレポート数を人為的に減らす構造として機能し、実際の品質問題を覆い隠す効果を生んでいる
- 結果として、Appleのバグ管理方式が開発者の信頼を弱め、協力的なフィードバック文化を損なう問題として指摘されている
Appleのバグレポート自動終了問題
- Apple Feedback Assistantを通じてバグを報告した開発者が、Appleがユーザーの確認なしにレポートを任意に閉じる慣行を批判している
- Appleは、ユーザーが「バグがまだ修正されていない」と直接確認しない限り、そのレポートを自動終了する
- 何年も応答がなかったのに突然確認依頼を送り、2週間以内に返答がなければ「修正完了」と見なす
- 2023年3月に提出された**FB12088655 “Privacy: Network filter extension TCP connection and IP address leak”**の事例では、3年間応答がなかったあと、2026年3月になってようやくAppleがmacOS 26.4 beta 4での確認を求めた
- ベータ版OSを常時インストールしていないため確認が難しく、Appleに修正有無を問い合わせたが、明確な回答は得られなかった
- Appleは「2週間以内に確認しなければ修正済みと見なしてレポートを閉じる」と通知した
- Little Snitchの開発者たちは、macOS 26.4 beta 4でも同じ問題が再現すると報告した
- 実際にはmacOS 26.4正式版でも同じバグが残っていた
- Appleが未修正のバグについてユーザーによる直接確認を求めたことは、非効率で不合理な手続きだと指摘されている
- 内部的にバグレポート数を減らすためのインセンティブ構造が働いている可能性が言及されている
- その結果、「未解決バグ数」が減り、内部指標上は品質が改善したように見えてしまう
別のバグレポート事例
- 別の事例として、**FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”**というバグが言及されている
- 100%再現可能な問題だったにもかかわらず、Appleは「調査完了 - 現在の情報では診断不可（Investigation complete - Unable to diagnose with current information）」と表示した
- 3月9日に追加情報を求めたが、Appleは応答しなかった
- iPadOS 26.4ベータではSafariクラッシュバグが新たに発生していたが、Appleはこれを公開版リリース前まで修正しなかった
- 筆者は「ベータの目的はバグ修正ではなく、バグを報告する人をうんざりさせることのようだ」と批判している
Hacker News後の変化とAppleの対応
- この文章がHacker Newsのトップページに載った直後、AppleはFB22057274レポートを更新した
- AppleはUIの問題についてsysdiagnoseログの提出を求めた
- すでに再現手順と画面録画動画を提供しており、sysdiagnoseはプライバシー侵害のリスクがあり不要な資料だと指摘されている
- 筆者はAppleの要求に対して次のように応答した
- 「UIバグにsysdiagnoseは不要で、役にも立たない」
- Little Snitchなしでも再現可能な方法として、Xcode Additional ToolsのNetwork Link Conditionerでアップリンク遅延3000msプロファイルを設定すれば同じ現象を再現できると示した
Xcode Additional Toolsの案内
- Xcode Additional Toolsには複数の便利なユーティリティが含まれており、
Apple Developer Downloadsページ（ログイン必要）からダウンロードできる
総合評価
- Appleのバグレポート管理方式は開発者に不要な負担を与え、
実際の問題解決よりレポート数の削減に焦点を当てた構造として機能している
- 長期間応答のないレポート、不合理な確認要求、非効率な情報要求などにより、
開発者の信頼と協力意欲が弱まっている
1件のコメント
Hacker Newsの意見
投稿者はエンタープライズソフトウェアを経験したことがないのだと思う
開発者はバグレポートを受け取ると、「再現できないのですが、最新バージョンで確認しましたか？」と言って何もせず時間を引き延ばすのが典型的なやり方だ
確認できなければ「ユーザーエラー」や「再現不可」で閉じてしまう
唯一の対抗策は、「はい、確認しました」と言いつつ実際には確認しないことだけだ
ログにアンチウイルスソフトが見えると、「そちらに問い合わせてください」と言ってすぐ閉じられる
1人のユーザーが報告したバグより重要なビジネス上の優先事項がたくさんあるからだ
それでもユーザーの立場では残念なことだ
ほとんどの開発者は自分の製品をテストする方法を知らないか、面倒がっている
エンタープライズの技術サポート時代には、1日に少なくとも2件の新しいケースを受け取り、20件以上を同時に管理していた
何の進展もないケースを「非アクティブ終了」で閉じるときの解放感は大きかった
後になって、閉じる前に3回連絡しなければならないという規定ができて悪夢だった
結局、大企業の官僚主義がすべてを台無しにする
Appleはバグが自然に消えることを祈るような態度に見える
私ももうバグレポートは送らない
無視されるのは構わないが、問題は彼らが私を無給のQA要員として扱うときだ
バグの存在を証明するために膨大な努力を要求される
「これはお前のソフトウェアなんだから、お前がデバッグしろ」という考え方だ
オープンソースのプロジェクトでも同様にstale issueの自動クローズが行われる
一定期間が過ぎたら自動的に解決済みと見なすのはおかしい
オープンソースの利点は、自分で直したり、PRを提出したり、フォークして解決したりできる点だ
古いチケットをフィルタリングするほうが合理的だ
ユーザーの立場ではいら立つが、すべてのバグが簡単に再現可能なわけではない
ときには、関連コードを変更した後でユーザーに再テストを依頼するほうが効率的だ
それでも、古くて実行不能なバグを閉じるときは気が重い
それはAppleの社内ネットワークでだけ再現しないという意味だった
閉じるのは問題を隠す行為にすぎず、開いたままにしておくのにコストはかからない
ベータ版をインストールしなければならないのは、ユーザーにとってはるかに非効率だ
私はXcodeのサンプルプロジェクトと再現手順まで提供した
Appleは何もしていないと確信している
おそらくWWDC前にmacOS 27の準備のためバグ整理ショーをしているのだろう
FacebookとGoogleで働いていたとき、バグ管理の小細工をたくさん見た
SLA導入後、バグの優先度を人為的に下げたり、「まだ問題ですか？」と言ってユーザーに押し戻したりしていた
時間が経つと「そのバージョンは廃止された」と言って閉じてしまう
さらに、別のバグと無理やり統合して責任を回避することさえあった
結局、こうしたことは**組織の成果指標（SLA）**のせいだ
だから今ではバグレポートをほとんどしない
だが経営陣が「今はAIプロジェクトに集中しろ」と指示する
その一方で「バグが多すぎる」と叱責する
閉じるよりは、ただ無視するほうが正直だと思った
リーダーシップはこうした強制トリアージを誘導していた
自動通知を止めるのは問題だ
しかし現実にはデータ品質が低く、レポート用途には使えない
だから単一の優先度の値のほうが実用的だ
stalebotはこうした無視されたissueを代わりに閉じてくれる存在だ
顧客向けのseverityと社内向けのpriorityを別々に管理していた
Salesforceの「Lightning Experience」は名前に反して非常に遅い
社内ツールのほうがずっと速く効率的だった
ElevenLabsでも同じことがあった
バグレポートを送るとAIが自動で返信し、48時間後にstale扱いになる
そのうちLLMエージェントがこうした問題を解決しそうだ
自動で「まだ直っていません」とコメントし、定期的に「これは重要なワークフローに影響しています」と言って自動bumpできる
以前Microsoftにバグを提出したところ、数か月後に「再現不可」という連絡を受けた
実際には、その間に別の修正によって間接的に解決されていた
自分が象の一部だけを見た盲人だったのだと気づいた
元Apple社員です
Appleの社内バグトラッカーはRadarと呼ばれ、すべてのissueは「Verify」段階を経ないと閉じられない
見た目は品質保証プロセスのようだが、実際には大量のRadarがVerify状態で永遠に止まる
チームは「未検証のRadar数」で評価されるため、一定期間後に強制的に閉じてしまう
「バグ0件」という虚像はゆがんだ成果指標を生む
Appleのエンジニアが実際に修正を試みたとまでは言えない
会社で同僚たちと一緒にバックログ整理会議をしながら
古い一回限りのバグを整理していた
こうしたプロセスはごく一般的だ