何が起きたか

Appleのバグ報告システム「Feedback Assistant」において、開発者が提出したバグレポートが一方的に閉鎖される問題が指摘されている。macOS/iOS開発者のJeff Johnson氏（lapcatsoftware.com）がブログで詳細を公開し、Hacker Newsで大きな議論を呼んだ。

Appleは未修正のバグについても、開発者が2週間以内に最新ベータ版での再検証を行わなければレポートを機械的に閉鎖する運用を行っている。この仕様はAppleのどの公式ドキュメントにも明記されておらず、多くの開発者が知らぬうちに報告済みバグを「消失」させられていた可能性がある。

具体的な2件の事例

Johnson氏が公開した事例は、この問題の深刻さを端的に示している。

FB12088655（プライバシー/ネットワークフィルタ拡張の脆弱性）

2023年3月に提出されたこのレポートは、3年間Apple側からの応答がまったくなかった。報告されたバグは最終公開リリースでも再現が確認されており、開発者の側では問題が継続して存在することを把握していた。しかしある日突然、macOS 26.4 beta 4での再検証を要求する通知が届いた。内容を精査せず形式だけを管理するシステムが、3年越しのセキュリティ報告を消そうとしていた。

FB22057274（Safari固定タブの問題）

こちらは「調査完了 - 診断不能」として、Appleから何ら追加情報の請求もなく突然閉鎖された。Hacker NewsでJohnson氏のブログ記事が注目を集めた後、Appleが突然sysdiagnoseレポートの提出を要求してきた。Johnson氏はUIバグに対してsysdiagnoseを求めること自体が不適切だと指摘している。Appleが外部からの注目を受けて初めて対応を変えたという経緯は、通常の運用の問題点を浮き彫りにする。

Feedback Assistantの動作フロー

Appleのバグ報告システムがどのように動作するかを整理すると、以下のようになる。

flowchart TD A["開発者がFeedback Assistantで
バグレポートを提出"] --> B["Appleが受理・内部トラッキング開始"] B --> C{"Appleが検証要求を送信
（タイミングは不定期）"} C --> D["2週間以内に開発者が
最新ベータで再検証を実施"] C --> E["期限内に応答なし
または開発者が気づかない"] D --> F["レポート継続・優先度評価へ"] E --> G["レポート自動閉鎖
（バグは未修正のまま）"] G --> H["Apple内部のオープンバグ数が
減少——メトリクス上は「解決」"] F --> I{"Appleが修正を優先するか？"} I -->|"No"| C I -->|"Yes"| J["修正・リリース"]

検証要求はバグの深刻度や修正状況と無関係に機械的に発行される。開発者が詳細な再現手順やスクリーンレコーディングを添付済みであっても、Apple側がそれを読んだ形跡がないまま閉鎖されるケースが報告されている。閉鎖されたレポートはApple内部の優先度判定から除外される可能性が高く、実質的にバグが「存在しなかった」ことになる。

他のバグトラッカーとの比較

Appleの運用が業界標準から見てどの程度異質かを理解するため、主要なバグトラッキングシステムと比較する。

システム 自動閉鎖 閉鎖の条件 開発者への通知 再オープン可否
Apple Feedback Assistant あり 開発者が2週間以内に再検証しない場合 通知あり（見逃しリスク大） 不明・困難
GitHub Issues なし 手動のみ — 容易（コメントで再オープン）
Mozilla Bugzilla 条件付き 長期非活動（数ヶ月〜年単位）かつNEEDINFO未回答 明示的なメール通知 容易
JetBrains YouTrack なし 手動のみ — 容易
Android Issue Tracker 条件付き Googleが「解決済み」と判断した場合 通知あり コメントで可能

Appleの2週間という閉鎖期間は、他システムと比べて圧倒的に短い。また「バグが修正されているかどうか」ではなく「開発者が検証したかどうか」を閉鎖の基準にしている点が特異だ。

Hacker Newsで指摘された構造的問題

Johnson氏のブログ記事がHacker Newsに掲載されると、多くの開発者から共感と批判のコメントが相次いだ。議論の中で浮上した主な指摘を整理する。

メトリクス操作の疑惑

Appleが「オープンバグ数」をKPIとして管理しており、実際の修正ではなく報告数の削減で指標を達成しようとしている可能性が指摘された。再検証要求への未応答を理由にレポートを閉鎖すれば、内部の未解決バグ件数を減らせる。

「詳細な報告ほど損をする」逆インセンティブ

再現動画や詳細な手順を添付した高品質な報告でも、機械的に閉鎖される。これは開発者に対して「丁寧に報告しても意味がない」というメッセージを送ることになり、報告品質全体の低下につながる。

ベータ検証の非現実的な前提

再検証要求は「最新ベータ版でテストせよ」という内容が多い。しかし本番アプリをリリースしている開発者がベータ環境を常時維持することは現実的ではなく、要求自体が検証負担を過大にしている。

公開報告との二重管理

Hacker Newsへの露出後に初めてAppleが対応するという事例（FB22057274）は、内部のFeedback Assistantが機能していないことを自ら証明している。開発者は公開の場での告知を余儀なくされ、コミュニティの監視なしには問題が無視されると感じている。

開発者への実務的影響

Apple向け開発を行うエンジニアにとって、この問題は次のような実務的コストをもたらす。

追跡コストの累積

一度提出したバグに対して継続的な再検証が求められる。10件のバグを抱えている開発者は、毎月それらすべてをベータ環境で確認しなければ、修正待ちのレポートが消えていく。

セキュリティリスクの放置

FB12088655のようなプライバシー関連の脆弱性報告が3年放置された事例は、深刻なセキュリティリスクにつながりうる。Appleが「閉鎖」処理を行うことで、CVEとしての追跡対象から外れる可能性もある。

報告文化の悪化

報告コストが高く成果が見えにくい状況では、開発者がバグを報告しなくなる。Appleエコシステムのソフトウェア品質を維持するためのフィードバックループが壊れていく。

開発者が取れる現実的な対策

Feedback Assistant 運用の実務ガイド
1. 報告時にスクリーンショット・動画・sysdiagnoseをすべて添付する（後から要求される前に）
2. 報告したバグIDをローカルファイルまたはスプレッドシートで管理する
3. 2週間を目安にFeedback Assistantにログインし、「検証要求」が来ていないか確認する
4. 重大なバグは公開ブログやX（旧Twitter）で報告番号付きで言及し、可視性を高める
5. Developer Forumsで同様の報告がないか確認し、重複報告として束ねる

ローカルでのバグ追跡には、シンプルなスクリプトが有効だ。

#!/bin/bash
# apple_bugs.sh - Feedback Assistantレポートの追跡ログ
# 使い方: ./apple_bugs.sh add "FB12345678" "Safari crash on back navigation"

LOGFILE="$HOME/.apple_bugs.tsv"
DATE=$(date +%Y-%m-%d)
ACTION=$1
BUG_ID=$2
DESCRIPTION=$3

case $ACTION in
  add)
    echo -e "$DATE\t$BUG_ID\t$DESCRIPTION\tOPEN\t$DATE" >> "$LOGFILE"
    echo "Added: $BUG_ID"
    ;;
  list)
    column -t -s $'\t' "$LOGFILE"
    ;;
  check)
    # 最終検証から14日以上経過したものを表示
    awk -F'\t' -v today="$DATE" '
      {
        split($5, d, "-"); split(today, t, "-")
        days = (mktime(t[1]" "t[2]" "t[3]" 0 0 0") - mktime(d[1]" "d[2]" "d[3]" 0 0 0")) / 86400
        if (days >= 12) print "⚠️  VERIFY SOON: "$2" ("$3")"
      }
    ' "$LOGFILE"
    ;;
esac

# 登録例
./apple_bugs.sh add "FB12088655" "Network filter privacy vulnerability"
./apple_bugs.sh add "FB22057274" "Safari pinned tabs broken"

# 再検証が必要なものをチェック
./apple_bugs.sh check

Xcode Organizerやターミナルからsysdiagnoseを取得する方法も把握しておくべきだ。

# sysdiagnoseの取得（Appleが要求してくる前に手元で準備）
sudo sysdiagnose -f ~/Desktop/diagnostics/

# または特定プロセスに絞ったログ収集
log collect --device --last 1h --output ~/Desktop/bug_report_$(date +%Y%m%d).logarchive

Appleの開発者ツールが抱える慢性的な問題

Feedback Assistantの問題は今回が初めてではない。Apple開発者コミュニティでは長年、以下のような問題が繰り返し指摘されてきた。

  • Radar（旧バグトラッカー）の不透明さ: 旧システムでは報告したバグがduplicate扱いされても、原本バグIDが開示されなかった
  • 応答の欠如: 多くの報告に対してAppleからの返信がなく、修正されたのかどうかも不明なまま
  • Open Radarの存在: 開発者がAppleに報告したバグを公開共有するコミュニティサービス（openradar.appspot.com）が生まれた背景には、公式システムへの不信感がある
  • WWDC Labsの限界: 年1回のWWDC Lab対応は特定の問題には有効だが、継続的なバグ追跡の代替にはならない

Apache Airflowによるデータパイプライン自動化でCI/CD環境を整備している開発者であれば、Feedback Assistantのチェックもスケジュールジョブに組み込む発想が自然に出てくるだろう。Apple向け開発の自動化において、バグ管理は見落とされがちな盲点だ。

まとめ

Apple Feedback Assistantの自動閉鎖問題は、技術的なバグというより運用ポリシーの設計問題だ。「オープンバグ数を減らす」という内部メトリクスの最適化が、「バグを実際に修正する」という本来の目的を上回った結果とも読める。

開発者にできることは現時点では限られているが、ローカルでの追跡管理、定期的な再検証、そして公開の場での報告を組み合わせることで、少なくとも自分の報告が消えるリスクを減らすことができる。OpenHandsのようなAIコーディングエージェントを使ったデバッグ作業でも、バグの再現環境を記録しておく習慣は非常に有効だ。

Appleがこの仕様を意図的に設計しているのか、それとも大規模なレポート管理のための苦肉の策なのかは不明だ。しかし少なくとも、開発者コミュニティへの説明なしにこの運用を続けることへの批判は、今後も続くだろう。

参照ソース