Mac Mini で動かす Claude：最も安価な Apple 製品をバックグラウンドの労働力に変える方法

日本語訳

ほとんどの自動化は同じように消えていく。誰かが賢いものを作り、チャットウィンドウで一度実行し、夕食に行くためにラップトップを閉じると、すべてが蒸発する。スクリプトが弱点だったわけではない。ラップトップが問題だった。作業を続けるためには、ラップトップは開いたまま、電源に接続され、起動したままでいなければならなかった — しかしラップトップはその逆を行うように作られている。

Mac mini にはその問題がない。ベースモデルで約 $599、デスクランプよりも消費電力が少なく、ほとんど音もなく、ただ一つの役割を持っている：起動し続けること。この特性こそが、人々がこっそりと Claude のワークフローを任せるマシンになった理由のすべてだ。

この記事では、そのようなワークフローを3つ紹介する — 自動で仕分けされる受信トレイ、一晩でレビューされるプルリクエスト、そしてミーティングのタイトルではなく事前説明を提供するカレンダー — これらはすべて、家のどこかに置かれた mini で動作し、誰も起動することを覚えておく必要がない。

なぜこれに Claude チャットを使わないのか？

メールを Claude に貼り付けて返信の下書きを依頼することは、すでに可能だ。diff を貼り付けてレビューを依頼することもできる。この記事の内容に、チャットウィンドウにすでに存在しない機能を必要とするものは何もない。

変わるのは、誰が実行ボタンを押すかだ。

チャットでは、あなたが毎回トリガーになる。タブを開き、コンテンツを貼り付け、答えを読み、どこかにコピーする。あなたがそれをやめると、プロセスは停止する。それは、あなたの手が触れている時だけ動くツールだ。

mini では、トリガーは時計、または Webhook、またはフォルダに新しいファイルが到着することだ。Claude が作業を行い、事前に書いたルールに照らして自分の出力を確認し、結果を送信するか、再試行する — 誰もラップトップを開く必要なく。これが「私が使うモデル」と「動くシステム」のすべての違いだ。

実際にデスクに置かれているもの

3つの層があり、どれも特別なものではない。

マシン。 launchd ジョブ（macOS で cron の行儀の良い親戚）を実行する Mac mini が、スケジュールまたはファイル変更に応じて Python スクリプトを起動する。常時稼働する小さな PC ならどれでも同じ仕事ができる — mini はたまたま静かで、安価に動作し、モニターの後ろに隠れるほど小さいだけだ。

ストレージ。 プレーンなフォルダと Markdown ファイル、そしてワークフローが直接触れるもの — IMAP 経由の受信トレイ、ローカルにクローンされた GitHub リポジトリ、.ics フィードに同期されたカレンダー。何も他人のアプリの背後に存在しない。もし mini が明日消えても、生成されたすべてのファイルはどのコンピュータでも正常に開く。

推論エンジン。 API 経由で呼び出される Claude。Sonnet は実際の判断を必要とするもの — プルリクエストのマージが安全かどうかの判断、あなたらしい返信の作成 — を担当する。Haiku は安価で大量の処理 — 仕分け、ラベル付け、Yes/No のチェック — を担当する。このように作業を分割することが、月額料金をコーヒーサブスクリプション以下に抑えられる主な理由だ。

では、実際のワークフローを見ていこう。

ルーティン1：確認する頃にはノイズがなくなっている受信トレイ

ほとんどの受信トレイは、難しい決断で溢れているわけではない。それらは、あなたをまったく必要としないもの — ニュースレター、カレンダーの確認、50回は答えたベンダーの質問 — で溢れている。難しいのはそれらに答えることではない。あなたが決断する前から、それぞれが奪う20秒の注意力だ。

1実行時間：平日15分ごと
2監視対象：プライマリ受信トレイの新着メール
3
4手順：
5  1. 同じスレッドの最後の10メッセージをコンテキストとして取得
6  2. Claude が新着メッセージを分類：
7       - ルーティン（確認、ニュースレター、自動返信）
8       - 返信が必要（実際の質問、リクエスト）
9       - 人間の判断が必要（金銭、紛争、曖昧なもの）
10  3. ルーティン → 自動的にアーカイブ、日次ダイジェストに記録
11     返信が必要 → Claude が自分の口調で返信の下書きを作成、下書きに保存、
12                    私が開いて確認するまで送信しない
13     人間の判断が必要 → そのまま、フラグ付き、下書きは作成しない
14
15確認：分類には、1行の理由を含める必要がある。Claude が実際のメッセージ
16       内容を参照する理由を生成できない場合、そのアイテムはデフォルトで
17       「人間の判断が必要」に分類される。
18停止：バッチ内のすべてのメッセージが仕分けられた場合、または1つのメッセージ
19       に対して3回の再試行後に直接私にフラグが付けられた場合。

ここで重要なのはフォールバックルールだ。Claude が自信を持って分類できないものは推測されない — それが通常通りあなたのところに届く。このワークフローは、難しい10%に対する判断を置き換えようとしているわけではない。簡単な90%であなたの注意を奪うのを止めようとしているのだ。

ルーティン2：あなたが起きる前にプルリクエストが最初のレビューを受ける

コードレビューには奇妙な障害モードがある：最も重要なレビュー — 午後11時に届いた PR のレビュー — は、半分眠った状態で急いで行われたり、さらに悪いことに「明日見る」と約束してマージされて、結局実行されない可能性が最も高い。

1実行時間：GitHub Webhook 経由で、新しいプルリクエストごとに
2
3手順：
4  1. diff と関連する Issue（存在する場合）を取得
5  2. Claude が固定の採点基準に従ってレビュー：
6       - 関連する Issue の実際のスコープと一致しているか？
7       - 認証、支払い、またはマイグレーションへの変更があるか？（フラグを立てる、判断はしない）
8       - 変更された行のテストカバレッジ — 存在するか、欠落しているか？
9       - 命名と構造がファイルの残りの部分と一貫しているか？
10  3. コメントは PR に直接投稿され、採点基準項目ごとに1〜5で評価され、
11     最も弱い2つのポイントが明示的に指摘される
12
13確認：コメントは、特定の行番号を引用している場合のみ投稿される。
14       行参照のないレビューは破棄されて再試行される —
15       曖昧なフィードバックは送信する価値がない。
16停止：コメントが投稿された場合、または2回の再試行後、自動レビューが
17       完了できなかったというメモとともに PR はそのまま残される。

ここでは何もマージされない。それは疲れることのない第二の目であり、あなたの実際の最初の目の前に PR に置かれる。固定の採点基準に対するスコアリングが有用性を保つ — モデルに「このコードをレビューして」と自由形式で依頼すると、すべてを褒めるか、ランダムに細かいことを指摘する傾向がある。4つの固定質問に対してスコアリングされたモデルは、毎回同じ種類のフィードバックを生成する。それがまさに、朝の8時に読む価値がある理由だ。

ルーティン3：ミーティングにはタイトルだけでなく事前説明が付いてくる

カレンダーの招待状は、いつ、どこで行われるかを教えてくれる。しかし、実際に参加する前に覚えておくべきこと — その人との最後のメールスレッド、前回のミーティングからの未解決事項、誰かが尋ねてくるであろう数字 — をほとんど教えてくれない。

1実行時間：各カレンダーイベント（参加者2名以上）の45分前
2
3手順：
4  1. 最後のメールスレッドと、参加者の名前またはイベントタイトルに
5     リンクされた共有ドキュメントを取得
6  2. Claude が1ページの事前説明を作成：
7       - 前回合意されたこと（もしあれば）
8       - 提起する価値のある未解決の質問1つ
9       - 最後のやり取りで言及された数字や日付
10  3. イベントの30分前にプッシュ通知で配信
11
12確認：事前説明は、実際の以前のメッセージまたはドキュメントを参照する
13       必要がある。以前のコンテキストが見つからない場合 → 通知は
14       「履歴が見つかりません」と表示し、でっち上げた要約は表示しない。
15停止：送信された場合、または参加者が新しい場合は完全にスキップされる。

最後の確認が注目に値する。実際のコンテキストが見つからない場合、Claude が何もないところからもっともらしい事前説明を書くのは簡単だ — そしてもっともらしい偽物は、事前説明がないより悪い。なぜならあなたはそれを信じてしまうからだ。正直に「何も見つかりませんでした」と強制することが、実際に届く事前説明を読む価値のあるものにする。

上記のすべてが依存する2つのルール

具体的な内容を除けば、すべてのルーティンは同じ2つのガードレールに依存している。

確認可能なルールであり、雰囲気ではない。「このメールを分類して」は雰囲気だ。「このメールを分類し、ラベルを正当化する文を引用できない場合は、安全なカテゴリにデフォルト設定する」はルールだ。違いは、Claude が特定の基準に対して自分の作業を評価しているか、単に完成したように見えるものを生成しているかにある。

実際の停止条件。 上記のすべてのルーティンには、再試行のハードリミットと、クリーンにジョブを実行できない場合の定義されたフォールバックがある。それがなければ、1つの不正なメールや壊れた diff を持つ PR が、一晩中再試行ループで API 呼び出しを消費し、バグ報告が届く前に請求書が届くことになる。

これら2つを正しく設定すれば、特定のタスクはほとんど問題にならない — 受信トレイ、コード、カレンダー、またはまったく別のものであっても。

構築する前に手動で感触を確かめる

これには、始めるためにターミナルに触れる必要はまったくない。通常の Claude 会話で同じ形を実行し、自動化する前にそれが実際に役立つかどうかを確認できる：

1あなたはこのタスクをパスごとに進め、完了と呼ぶ前に自分の出力を確認します。
2
3タスク：
4[処理したいこと]
5
6パスルール：
7- 作業を行う。
8- 次の条件に照らして確認する：[具体的で確認可能な条件]
9- 確認に失敗した場合、何が問題かを言い、その部分だけをやり直す。
10- 確認に合格した場合、「完了」と言って停止する。
11- 私に明確化の質問をしないでください — 最も妥当な仮定を立て、それを1行で述べ、続行してください。
12
13開始。

これが全体のメカニズムの縮図だ。mini も Webhook もスケジュールもない — ただ Claude がもっともらしい最初の下書きで止まる代わりに、ルールに照らして自分の作業を確認するだけだ。これを同じ種類のタスクで手動で3、4回実行し、繰り返し使っているなら、それはあなたが起動することを覚えておく必要のないマシンに載せる価値があるというサインだ。

午前2時に壊れないための順序

これらを確実に実行している人は、cron ジョブを書くことから始めない。実際に機能する順序は次のとおりだ。

1. 出力が一貫して正しくなるまで、チャットで手動で実行する。
2. その正確なプロンプトをスクリプトに変換する — ロジックに変更は加えない。
3. 他の何よりも先に、確認と再試行制限を追加する。
4. その後にのみ、スケジュールまたは Webhook に接続する。

ステップ4に直接飛ぶと、「停止条件がない」ことの代償を痛い目で知ることになる。通常は、重複した PR コメントでいっぱいの朝か、送信済みフォルダに何百もの同一の下書きが置かれることになる。

これが実際に買っているもの

これにより Claude が賢くなるわけではない。それは、あなたが使うものと、あなたが注意を払っているかどうかにかかわらず動作するものの違いを生み出す。mini は面白い部分ではない — それは、再び開かれる必要のないマシンをワークフローに与えるための、最も安価で最も静かな方法に過ぎない。

この記事の手動バージョンから始めよう。数回以上手動で実行していることに気づいたら、それがあなたが寝た後も起動し続けるボックスに載せる価値のあるものだ。

お読みいただきありがとうございます

制作者： [@0xclayn](https://x.com/@0xclayn)

保存する