ハクソク

世界を動かす技術を、日本語で。

Appleは、バグが修正されていないことを「確認」しない限り、バグ報告をランダムにクローズします

2026年3月26日原文(lapcatsoftware.com)

概要

Apple Feedback Assistantへのバグ報告を続ける理由と、その苦悩を解説。 Appleのバグ対応に対する不満と、報告者に対する扱いの問題を指摘。 バグ修正の実態や、ベータ版検証依頼の理不尽さを具体例で紹介。 Appleのバグ報告管理の問題点と社内体制への疑念を提起。 ベータ版の存在意義に対する疑問で締めくくり。

Apple Feedback Assistantにバグ報告を続ける理由

  • Apple Feedback Assistant へのバグ報告をやめられない心理
    • 狂気、もしくは依存症という自嘲的な動機
    • 報告をやめる期間と、再び報告を始めてしまう期間の繰り返し
  • ボイコット運動 の試み
    • 他の開発者を巻き込んで改善要求リストを作成
    • しかし、運動は広がらず失敗
  • バグ報告を続ける動機
    • 一部のバグが実際に修正される 実績の存在

Appleのバグ報告対応に対する主な不満

  • 最大の不満は「未修正」ではなく、 報告者や報告内容への軽視
    • 報告者の時間や労力を当然視し、感謝や配慮が感じられない対応
  • Appleの態度
    • ユーザーがAppleに奉仕する義務があるかのような姿勢
    • 報告者の時間を意図的に浪費させる対応

具体的なバグ報告事例と対応

  • FB12088655「Privacy: Network filter extension TCP connection and IP address leak」
    • 2023年3月に詳細な再現手順とXcodeプロジェクト付きで報告
    • 3年間Appleから一切返信なし
    • 最近になり「macOS 26.4 beta 4で再現するか検証して更新せよ」と要請
  • ベータ版検証の困難
    • 毎年6月のWWDCベータはインストールするが、9月以降は未使用
    • 年間を通じて無償テスターになる余裕や端末がない 現実
    • 過去にも「修正されていないバグの検証依頼」を受けてきた経験
  • Appleの対応
    • 「beta 4で修正されたか」直接質問するも、 曖昧な回答と2週間以内の強制クローズ警告
    • Little Snitch開発者に確認したところ、 beta 4でもバグ再現
    • 公開版macOS 26.4でもバグがそのまま残存

Appleのバグ管理体制への疑念

  • FB22057274「Pinned tabs: slow-loading target="_blank" links appear in the wrong tab」
    • 100%再現可能なバグにも関わらず「調査完了 - 現情報では診断不可」と一方的に終了
    • 追加情報提供を申し出るも、Appleからは一切追加要求なし
  • Apple内部のバグ報告クローズ方針への疑念
    • 未修正でもクローズを奨励するインセンティブ の存在を推測
    • 表向きのバグ件数を減らし、品質問題がないように見せかける社内指標

ベータ版の存在意義への疑問

  • iPadOS 26.4ベータで 新たなSafariクラッシュバグ を報告
    • Appleは修正せずに公開版リリース
  • ベータ版の目的 に対する根本的な疑念
    • バグ報告者を煩わせるだけで、実質的な改善につながらない現状

Hackerたちの意見

公平に言うと、これはどのバグジラでもよくある春の大掃除だよね。

└

よくあることだけど、やっぱり良い慣習とは言えないね。

└

まさに「誰かがこれで問題ないって言う前にコメントしに来た」って感じで、最初のコメントが「これで問題ない」って言ってるのには驚いたよ。ソフトウェアの人たちがローカルオプティマムを最適化してる感じがする。プログラマー版の「重要なら連絡が来るだろう」みたいなもので、こういう方針の現実的な影響を完全に無視してる。

ユーザーの立場から見るとイライラするのはわかるけど、その気持ちも理解できる。すべてのバグが簡単に再現できるわけじゃないし（ユーザーには100%再現できても、開発者にはそう簡単じゃないこともある）。それに、関連する部分でコードを変更したと思っても、最も「効率的」なのはユーザーに再テストをお願いすることだったりする。アクションが取れない古いバグを閉じるときは、ちょっと気が引けるけど、実際に何もできないのにバグを開けておくのも悪いかもしれない。

└

Appleみたいな会社なら、バグ発生時のシステム状態を完璧にキャッチできる複雑なツールがあるべきだよね。

└

実際に何もできないのにバグを開けておくのも悪いかもしれない これを他の人からも聞いたことがあるけど、その考え方が本当に理解できない。バグを開けておくことに何の害があるの？

└

それがどう悪いの？ 開いたままにしておくと、検索してる人にはまだ問題があるってわかるじゃん。アクティブなバグのフィルターにも引っかかるし。修正せずに閉じると、状況がわかりづらくなるだけだよ。実際に問題があるなら、「Issues (1)」のままにしておくのは何も損しないし（プライドを除いて？）。

└

キャリアの別の部分で、MacをActive Directoryに接続する仕事をたくさんしてたんだ。その実装に関するバグについてAppleからよく聞いたフレーズは「17.x.x.xで動く！」ってやつ。ジョークは、Appleがインターネット上の17.x.x.xクラスAの範囲を持っているってこと（早くに取得したから、第二のクラスBも持ってたし、昔は第二のクラスBも持ってたけど返した）。エンジニアたちが本当に言いたかったのは、Appleが設定したADシステムでは再現できなかったってことなんだ（多くの場合、ADが.localドメインで設定されていたからで、これは本当にダメなことだったんだけど、当時はMicrosoftのトレーニング資料に例として載ってたんだよね…）。

└

すべてのバグが簡単に再現できるわけじゃない。Appleは再現できないとは言ってないし、修正したとも言ってない。ただ「macOS 26.4 beta 4で確認して」って言うだけだった。 それに、ユーザーにとっては100%再現できても、開発者にとってはそう簡単じゃない。 ユーザーにとっても簡単じゃないよ！ブログにも書いたけど、普段ベータ版は使わないから、このバグをテストするためにmacOS 26.4 beta 4をインストールするのは大変だった。むしろ、Appleがベータを開発してる時の方がテストしやすいんじゃないかな。 一番「効率的」なのは、ユーザーに再テストをお願いすることだね。Appleから見れば効率的だけど、バグ報告者からしたらめちゃくちゃ非効率だよ。 現実的には、これに対して何もできない。 今回は、AppleにサンプルのXcodeプロジェクトと再現手順を提供したから、実際にはそれを試すこともできたはずだよ。

作者は企業向けソフトウェアで働いたことがないんじゃないかな。これは典型的な手法で、開発者がバグの作者に「再現できないから、最新バージョンで確認してくれる？」って言って、実際には何もしないんだよ。そして確認されなければ「ユーザーエラー」か「再現不可」として閉じられる。これに対抗する唯一の方法は「はい、確認しました」って言うことだけど、実際には確認してない。

└

マイクロソフトの（有料）サポートの経験から言うと（5件チケット出したけど、いつも違うチームに回されるし、チケットを内部で移動させるのは負け犬のやることらしい）、再現の証拠を求められるよ。で、彼らは責任を押し付けるチャンスを逃さないんだ。「ああ、ログにアンチウイルスが動いてるのが見えるから、そっちにチケット出して。閉じるね」みたいな。

└

著者は企業向けソフトウェアで働いたことがないんだろうな。オープンソースプロジェクトとも。クソったれのスターボット。

Hacker Newsで議論の続きを見る