Mac 開発環境構築探険記：M1 MacBook Air の改造と運用

2025 年 3 月 6 日作成・2025 年 8 月 28 日更新 所要時間：約 27 分

はじめに（全 11 部の第 1 部）

Apple プラットフォーム向け開発には、Mac ハードウェアへの理解と接触が必須です。

• プラットフォームの尊重

  • Apple ハードウェア上で動作を確認することは、ユーザー体験に対する基本的な敬意です。
  • macOS/iOS/iPadOS 向けのアプリ発表や販売にあたっては、実際のハードウェアでのテストが不可欠です。

• 代替案の検討と断念

  • 仮想マシン（VM）
    • VirtualBox や QEMU/KVM で macOS VM を試行しましたが、安定性、一貫性、パフォーマンスに欠けました。
    • Apple 推奨ではないため、非推奨な体験でした。
  • Codemagic（CI/CD サービス）
    • マルチプラットフォームデプロイが可能ですが、グラフィックインターフェースへのリモート接続には限界があります。
    • アプリの実感や詳細な UI チェックに不向きで、無料枠の制限も早に来ました。

• 結論

  • 20 年以上の IT 経験から初めて、物理的な Mac の購入を決定しました。

どの Mac を買おう？（全 11 部の第 2 部）

低予算かつ低電力消費を目指し、以下の要素で絞り込みました。

• CPU チップの選定理由
  • Apple シリコン採用：ARM アーキテクチャの利点を活用するため、迷わず選択しました。
  • パフォーマンス/ワット比：Apple の統制下にある専用チップは効率が高いです。
• 初期候補：M1 Mac Mini
  • ノートPCを好まず（入力デバイスを自分で選べるため）、単なる計算機として魅力的でした。
  • 断念した理由 ①：ファンの存在
    • メカニカルな摩耗、粉塵の吸引、故障リスクがあり、静寂を保てない可能性があります。
  • 断念した理由 ②：電源供給の制約
    • 自宅環境はバッテリーバンク（DC 12V）のみで、24V/48V は不可です。
    • Mac Mini のパワーブロック（AC アダプター）は 220V を必要とし、インバーターでの二重変換により電力損失とケーブル管理の複雑さがありました。

結論： M1 Mac Mini は電源事情から不向きとなり、断念しました。

M1 MacBook Air（全 11 部の第 3 部）

現代のクラシックな作品である M1 MacBook Air を購入しました。

• 選定理由

  • 低消費電力・軽量: Apple シリコンの恩恵を享受します。
  • ファンレス設計: 静かな動作が可能です。
  • トラックパッド: タッチ操作への対応も考慮しました。
  • ディスプレイ取付性: スクリーンが破損したモデルでも、内部ディスプレイを取り外すことが可能で、修理コストや「修理権」の問題を回避できます（Apple は交換部品販売に不向きですが）。

• 購入経緯

  • eBay で スクリーン破損の 8GB M1 MacBook Air（ローズピンク） を £300 で購入。
  • 中古市場でメモリ容量は価格差が大きく、8GB も Apple シリコン上は十分に動作すると判断しました（Flutter 開発用途において問題ないと報告あり）。

動くのか？（全 11 部の第 4 部）

届いた機器は画面が破損しており、起動確認に苦労しました。

• 初期トラブル：モニター接続

  • 小型の USB-C モニターを接続しましたが、点灯しませんでした。
  • ポート、ケーブル、電力供給などのトラブルが複雑に絡みました。
  • ケーブル交換（80% の汎用ケーブルでは電力不足）の後、ようやくモニターが点灯。その後一時的に暗く表示不良となりました。

• ログイン画面への到達

  • 電源ボタン操作（タップ、短押し、長押し）で再起動を試みました。
  • macOS ログイン画面が表示されましたが、内部ディスプレイがないため UI が欠落していました。
  • 解決策:

    CMD + F1

    コマンドを実行し、出力を外部モニターに切り替えました。これでログインが可能になりました。

ちょうど（ほぼ）動く（全 11 部の第 5 部）

内部ディスプレイの取り外いと保護処理を行いました。

• 筐体の分解

  • ネジを外し、プラスチックタブを損傷せずにリボンケーブルから接続部分を取り外しました。
  • 固着トラブル: カバーと底面の分離が難しく、ヒンジ部の公差厳格さや隠された固定具による固着でした。
  • カバー維持: 薄くて軽い筐体は保護にも最適と考え、取り外しませんでした。

• ガラスパネルの撤去

  • 接着剤で固定された超薄型ガラスを外すのに熱とスクレーパを使用しました。
  • 安全対策: ガラス粉が飛散するのを防ぐため、ダクトテープパッチや透明な保護シートを内部に貼りました。

工場出荷時リセット（全 11 部の第 6 部）

• リセット手順

  • ディスプレイ除去後、OS を再インストールし、工場出荷時状態に戻しました。
  • 起動までの時間には不安がありましたが、通常動作に復帰しました。

• 外部モニターのみでのリカバリモード操作

  • 内部ディスプレイがない状態でリカバリモードを開始すると、ファントム画面（右側に空の領域）が表示されます。
  • ウィンドウをドラッグするにはタイトルバーを把握し、物理的な画面と相対位置を確認する必要があります。
  • これらを乗り越え、OS 起動が完了しました。

これは本当に点灯しているのか？（全 11 部の第 7 部）

ヘッドレス（モニターなし）での運用において、マシンのオン/オフ状態をどう把握するかは最大の課題でした。

• 検知手法の試行錯誤

  • LED インジケーター: ポートや CapsLock の LED は、完全起動時しか光らないため不十分でした。
  • Wi-Fi スキャン: ルーター上の接続クライアントリストを確認するのが最も確実です。起動直後から Wi-Fi に接続されます。
  • Ping 確認: ターミナルで

    ping

    を送り、応答があるかどうかで状態を判定しました。

• 自動化スクリプト（mac-get-status） 以下のスクリプトにより、ターミナル内で単一行にステータスとバッテリー残量を表示する仕組みを作成しました。

#!/bin/bash
# 概要: LAN 上の Mac を Ping し、バッテリー残量を SSH で取得して表示
# 出典: https://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/mac-get-status

ip_to_check=192.168.8.123
hostname=AIR

wht='\033[1;15m'
red='\033[1;31m'
ylw='\033[1;33m'
ong='\033[38;5;208m'
grn='\033[1;32m'
nc='\033[0m'

update_battery () {
  battery_check_output=$(ssh AIR "bash --login -c battery-check")
  percentage=$(echo "${battery_check_output}" | tr -dc '0-9')
  
  if [[ $percentage -lt 15 ]]; then battcolor=$red
  elif [[ $percentage -lt 30 ]]; then battcolor=$ong
  elif [[ $percentage -lt 80 ]]; then battcolor=$ylw
  else battcolor=$grn; fi 
}

tput civis
update_battery
sleep 1
update_battery
sleep 1

i=0
while :
do
  if ping -c 1 ${ip_to_check} &> /dev/null; then
    if [[ $i -lt 2 ]]; then color=$wht; else color=$battcolor; fi
    echo -ne "  ${hostname} ${grn}    ON     ${nc}${color}${percentage}%${nc}\r"
    ((i++))
    if [[ $i -eq 36 ]]; then i=0; update_battery; fi
  else
    echo -ne "  ${hostname} ${red}   OFF       ${nc}\r"
  fi
  sleep 5
done

• バッテリー表示スクリプト（battery-check）

  #!/bin/sh
  percent=$(system_profiler SPPowerDataType | grep "State of Charge (%)" | awk '{print $5}')
  echo "battery: ${percent}%"
  

マグネット（全 11 部の第 8 部）

• カバーと睡眠モードの問題
  • MacBook Air のヒンジ内蔵のホールセンサーにより、カバーを閉じるとスリープします。
  • カバーを開き、MacBook の下に置くことで「カバーが閉まった」と誤認識され、間欠的にスリープ/覚醒を繰り返していました。
• 解決策
  • TODO: カバーからマグネットを取り除く！

リモートアクセス（全 11 部の第 9 部）

主に Android タブレット（Termux/Proot-distro）上で macOS マシンを管理しています。

• SSH によるビルド（非グラフィカル）
  • Flutter デベロップメントの 90% は、ローカルの Debian ARM64 環境で可能です。
  • Android APK ビルド時は、MacBook に SSH 接続し、以下のように自動化します。

#!/bin/sh
# 概要: Mac 上で APK をビルドし、ローカルに同期
remote_commands=$(cat << 'EOF'
echo "~~~~~~~ Remote: Source local environment ~~~~~~~"
source ~/.zprofile
source ~/.zshrc
cd ~/development/audav
git pull
flutter build apk --split-per-abi
EOF
)

ssh AIR "bash --login -c '${remote_commands}'"
rsync -r --mkpath --progress AIR:development/audav/build/app/outputs/flutter-apk $HOME/000-WORK/audav/build/app/outputs/

• NoMachine：完全リモートグラフィカルアクセス
  • Xcode 以前のファイルマネージャーやウィンドウ管理の不便を克服するため、Galaxy Tab S8 Ultra で macOS を使用できます。
  • LAN 上での遅延が少なく、Linux/DWM環境から MacOS にシームレスにアクセス可能です。

ヘッドレス実行：学んだこと（全 11 部の第 10 部）

• カバー操作の心得

  • 電源投入時：カバーを閉じないでください。
  • シャットダウン中：プロセス完了まで待機し、カバーを閉じてからスリープします。
  • リセット直後など：ネットワーク上で可視化される（Ping 通る）ことを「オン」の指標とします。

• デッド状態からの復帰

  • 長期不使用でバッテリーが低下した際、USB-C ポートの接続順序や充電器の種類によっては起動しない場合があります。
  • 解決策: ケーブルを外し、MacBook にケーブルを先に接続してから、充電器を繋ぎ、30 秒待機すると起動するケースがあります。

最終結果とボーナス（全 11 部の第 11 部）

• 良い点

  • 静寂な動作（ファンレス）。
  • Apple シリコンの高効率性（太陽光発電環境でも良好）。
  • スクリプトによる状態監視は不便を解消。

• 悪い点

  • 完全な MacOS ユーザー体験ではない（Xcode など）。
  • バッテリー切れ時の復帰が難しい場合がある。
  • DP Alt Mode の不具合により、USB-C モニター接続時に内部ディスプレイ除去の影響が出る可能性がある。

• 結論

  • 異なる好みを持つユーザー向けにソフトウェアをビルドするための専用環境として最適です。

ボーナス：E-Ink MacBook

Boox Max Lumi タブレットを外部モニターとして使用しています。アクセシビリティ設定を変更すれば、MacOS も E-Ink モニターで動作します。

ディストピア的想像: Apple の壁の庭に閉じ込められつつ、爆発寸前に Vim で作業している自分を容易に見ることができます。