Macメンテナンスのコマンド集

作者:

開発や日常業務で使い続ける Mac には、定期的なメンテナンスが不可欠です。
不要ファイルや更新されていないパッケージの放置は、システムのパフォーマンス低下や開発環境の不安定化を招く原因となります。

本記事では、Homebrew・Mac App Store・Docker・Xcode など、主要なツールのアップデートおよびクリーンアップを一括で行うためのコマンドを紹介します。

コマンド一覧（概要）

# Homebrewの定義情報とインストール済みパッケージをアップデート
brew update && brew upgrade

# GUIアプリを含む全Caskアプリをアップグレード（自動更新アプリも対象）
brew upgrade --cask --greedy

# 古いパッケージとキャッシュを削除し、ストレージを最適化
brew cleanup

# 参照されなくなった不要な依存パッケージを削除（Homebrew 4.0以降）
brew autoremove

# Homebrew環境の健全性をチェック（警告が出たら適宜対応）
brew doctor

# Mac App Storeアプリを一括アップデート
mas upgrade

# Xcodeの派生データや不要シミュレータを削除
xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# 未使用のDockerリソースとボリュームを削除（慎重に実行）
docker system prune -f --volumes

1. Homebrew パッケージの更新とアップグレード

brew update && brew upgrade

Homebrew のパッケージ定義情報を最新化し、インストール済みの CLI ツールを一括でアップグレードします。
セキュリティパッチの適用や新機能の取り込みにより、開発環境の安定性と安全性を確保するための基本的なメンテナンス操作です。

2. GUIアプリ（Cask）の包括的アップグレード

brew upgrade --cask --greedy

Homebrew で管理される GUI アプリケーションを含めてアップグレードします。
–greedy を指定することで、自動更新機能付きのアプリ（例：Chrome、Slack など）もアップグレード対象になります。

3. 古いバージョンやキャッシュの削除

brew cleanup

不要になったインストール済みの古いパッケージやキャッシュを削除し、ストレージの空き容量を確保します。
定期実行がおすすめです。

4. 孤立した依存パッケージの削除（Homebrew 4.0以降）

brew autoremove

他のパッケージから参照されていない依存パッケージを自動で検出し削除します。
Homebrew 環境をスリムかつクリーンに保つのに有効です。

5. Homebrew 環境の健全性チェック

brew doctor

Homebrew の設定やリンク状態など、環境の不整合を診断します。
警告が出た場合はその内容に応じて対応することで、潜在的なトラブルを未然に防げます。

6. Mac App Store アプリのアップデート

mas upgrade

mas CLI を使って、Mac App Store でインストールしたアプリを一括でアップデートします。
GUI を使わずに済むため、自動化にも最適です。

7. Xcode 関連のクリーニング（容量削減に有効）

xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

Xcode を使った開発では、以下のような不要ファイルが溜まりやすく、ストレージを圧迫します。

  • 利用できなくなった古い iOS シミュレータ
  • ビルドごとに自動生成される派生データ（DerivedData）

これらを削除することで、数GB単位のストレージ空き容量を確保できる場合があります。
特にモバイルアプリ開発者にとっては、定期実行が推奨されるクリーニング項目です。

8. Docker の未使用リソースとボリュームの削除

docker system prune -f --volumes

未使用の Docker イメージ・コンテナ・ネットワーク・ボリュームを一括削除します。
実行前にリソースの使用状況を確認し、誤削除を防ぎましょう。

まとめ：メンテナンスを習慣化して安定した Mac 環境を

Homebrew や Docker を利用する開発環境では、依存関係の肥大化や不要ファイルの蓄積は避けられません。
以下のようなスクリプトにまとめて、定期的に実行する運用体制を整えることで、健全な開発基盤を維持できます。

実行手順を自動化するスクリプト例

#!/bin/bash

# Homebrewパッケージ更新とクリーンアップ
brew update && brew upgrade && brew upgrade --cask --greedy
brew cleanup && brew autoremove
brew doctor

# Mac App Storeアプリのアップデート
mas upgrade

# Xcode関連の不要ファイル削除
xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Dockerリソースの削除
docker system prune -f --volumes

Amazon Linux 2023でのRedisサポート終了と移行先まとめ

作者:

まずはざっくり説明

なぜ移行が必要？

Amazon Linux 2023で使っているRedis 6は、2025年8月31日でサポートが終わります。
サポートが終わると、バグ修正やセキュリティ更新が一切なくなり、システムにリスクが出ます。
そのため、別のバージョンやサービスへ移行する必要があります。

どんな選択肢がある？

簡単にまとめると次の3つです。

選択肢 特徴
Redis 7 現行に近いが、自分でインストールが必要。将来少し不安あり。
Valkey Redis互換の新しいOSS。AWS公式サポートもあり安心。
Amazon ElastiCache AWSが全部運用してくれる。超楽だけどコストは高め。

ざっくりイメージ図

 コスト重視
    ↑
 Valkey（低コスト）
    │
 Redis 7（ビルド必要）
    │
 ElastiCache（コスト高・超楽）
    ↓
 運用負荷重視

おすすめまとめ

あなたの希望 おすすめ
とにかく簡単にしたい Amazon ElastiCache
お金を抑えたい Valkey

ここから詳しい解説

はじめに

Amazon Linux 2023（AL2023）環境で稼働しているRedis 6は、2025年8月31日をもってサポート終了（EOL）となります。
これに伴い、セキュリティ更新や不具合修正が行われなくなるため、継続運用には新たな移行先の選定と準備が不可欠です。

本記事では、Redis 6 EOL対応に向けた移行先の検討ポイントおよび具体的な選択肢を詳しく整理します。

移行先選定のポイント

現在、RedisはLaravelベースのアプリケーションにおいて、キューやキャッシュに利用されています。
このため、以下の基準を重視して移行先を選定しました。

種別 内容
必須要件 Laravelとの互換性、AL2023への導入容易性
望ましい要件 長期的な保守体制、ライセンス上の安心、コスト最適化

移行候補一覧と詳細比較

1. Redis 7

  • Laravelとの互換性は高い
  • AL2023の標準リポジトリには未収録、独自ビルドが必要
  • Redis 7.4以降はライセンス変更（RSAL）により、商用利用に制限あり

2. Valkey

  • Redis 2〜7.2までと互換性あり（Laravelでも問題なし）
  • BSDライセンスで自由に使える
  • AWS公式パッケージがAL2023向けに提供済み
  • プロジェクト自体は新しいため、導入実績は発展途上

3. Amazon ElastiCache

  • AWS提供のマネージドRedisサービス
  • パッチ適用、スケーリング、監視すべて自動化
  • 導入が非常に簡単
  • ただし、ランニングコストは自前運用より高め

詳細比較表

項目 Redis 7 Valkey ElastiCache for Redis
Laravelとの互換性 高い 非常に高い 高い
AL2023対応 なし（ビルド必要） AWS公式パッケージあり AWSマネージド
ライセンス RSAL（制限あり） BSD（制限なし） AWS独自
導入の手間 中（ビルド作業あり） 低（簡単インストール） 低（数ステップ）
運用管理の負荷 高（自前対応） 高（自前対応） 低（AWSが対応）
コスト 低（ただし保守コストあり） 低 中〜高（スケールに応じ課金）
将来性 ライセンス変更リスクあり AWS公式採用で将来性あり 非常に高い

結論と推奨

パターンA：運用を楽にしたい場合

  • 選択肢：Amazon ElastiCache
  • 理由：AWSが運用代行、安定性と可用性が高い

パターンB：コストを重視したい場合

  • 選択肢：Valkey
  • 理由：Redis互換が高く、OSSとして自由に使える

おわりに

Redis 6のサポート終了は、システムリスク回避に向けた大きな節目です。
どの移行先を選ぶかは、コストと運用負荷のバランスを考慮して慎重に判断しましょう。

早めに計画を立て、移行準備を進めることを強く推奨します。

MacでHomebrewを使用したDocker Desktopのインストールエラー対処法（xattr: [Errno 1]）

作者:

はじめに

MacにHomebrewでDocker Desktopをインストールしようとすると、以下のようなエラーが発生しました。

% brew install --cask docker

Error: Failure while executing; /usr/bin/sudo -E -- /usr/bin/xattr -w com.apple.metadata:kMDItemAlternateNames \(\"docker\"\) /opt/homebrew/Caskroom/docker/4.38.0,181591/Docker.app/Contents/Resources/etc/docker.bash-completion exited with 1. Here's the output:
xattr: [Errno 1] Operation not permitted: '/opt/homebrew/Caskroom/docker/4.38.0,181591/Docker.app/Contents/Resources/etc/docker.bash-completion'

対策

いろいろと調べた結果、「HomebrewでDocker Desktopを再インストールするときに注意すること」というページを見つけました。

–forceをつけて全部削除してインストールし直すだけで解決できるようです。 

brew uninstall --cask docker --force
brew install --cask docker

これで無事にDocker Desktopをインストールすることができました。

ありがとうございました。

Android14のSelected Photos Accessについて

作者:

問題

AndroidManifest.xmlの下記の行で警告が表示されます。

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

警告メッセージは以下の通りです。

Your app is currently not handling Selected Photos Access introduced in Android 14+ More... (⌘F1) 
Inspection info:Selected Photo Access is a new ability for users to share partial access to their photo library when apps request access to their device storage on Android 14+.  Instead of letting the system manage the selection lifecycle, we recommend you adapt your app to handle partial access to the photo library.

このエラーの原因と対策を調べました。

原因

この警告メッセージは、Android 14（APIレベル 34）で導入された「Selected Photos Access（選択した写真へのアクセス）」に対応していないことを指摘しています。

Android 14以降、ユーザーはアプリがデバイスのストレージにアクセスを要求する際に、写真ライブラリ全体へのアクセスを許可する代わりに、選択した写真への部分的なアクセスを共有する新しい機能を利用できます。

android.permission.READ_MEDIA_IMAGESパーミッションを使用することで、アプリはユーザーのデバイス上の画像にアクセスできますが、Android 14+では、ユーザーが選択した写真へのアクセスのみをアプリに許可するオプションが追加されています。この変更により、ユーザーのプライバシーがさらに強化され、アプリは必要な写真にのみアクセスできるようになります。

この警告に対処するためには、アプリを「Selected Photos Access」に対応させる必要があります。具体的には、アプリが選択した写真への部分的なアクセスを管理し、この新しいアクセス権限に適応するようにする必要があります。

Selected Photos Accessの特徴と動作

  • 部分的なアクセス許可:ユーザーはアプリに対して、写真ライブラリ全体ではなく、選択した写真にのみアクセスを許可できます。これにより、ユーザーはプライバシーを保護しつつ、アプリの機能を利用できます。

  • 動的なアクセス管理: ユーザーはいつでも設定を変更し、アプリがアクセスできる写真を追加または削除できます。アプリは、これらの変更をリアルタイムで反映する必要があります。

  • ユーザーインターフェースの調整: アプリは、選択された写真へのアクセスが許可された場合、ユーザーが新たにアクセスを許可した写真に簡単にアクセスできるようにユーザーインターフェースを調整する必要があります。

対応

Selected Photos Access を利用する

アプリで Selected Photos Access を利用するには、以下の手順が必要です。

  1. アプリのターゲット API レベルを 33 に設定します。
  2. アプリの AndroidManifest.xml ファイルに以下の権限を追加します。 
    <uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />
  3. アプリで PhotoPicker クラスを使用して、ユーザーが写真や動画を選択できるようにします。

PhotoPicker クラスの使用

PhotoPicker クラスは、ユーザーが写真や動画を選択するための UI を提供します。このクラスを使用するには、以下の手順が必要です。

  1. PhotoPicker.Builder クラスのインスタンスを作成します。
  2. Builder インスタンスに、ユーザーが選択できる写真や動画の種類を指定します。
  3. Builder インスタンスの build() メソッドを呼び出して、PhotoPicker インスタンスを作成します。
  4. PhotoPicker インスタンスの start() メソッドを呼び出して、写真選択画面を表示します。

ユーザーが選択した写真や動画へのアクセス

ユーザーが写真や動画を選択した後、アプリは PhotoPicker インスタンスの getSelectedPhotos() メソッドを使用して、選択された写真や動画への URI を取得できます。

Selected Photos Access の制限事項

Selected Photos Access には、以下の制限事項があります。

  • ユーザーが選択した写真や動画のみアクセスできる
  • ユーザーがアプリをアンインストールすると、アプリは選択された写真や動画へのアクセス権を失う