自宅のMac StudioをAIワークベースにして、CodexとClaude Codeに何を任せているか
Mac StudioをAIワークベースにして、CodexやClaude Codeへ任せている開発、記事制作、定期ジョブと、人間が確認する実運用を紹介します。
僕が仕事の休憩でモニターの前を離れている間も、Mac Studioの上ではAIエージェントが業務を進めています。
業務時間中は1時間に1回Slackを確認し、仕事の依頼が来ていれば修正作業を進めて、タイトル案を作るところまで勝手に進む。気づけばAIのbe-suフローが完了した状態になり、僕がやるのはその成果物に目を通して、業務品質まで上げて、使えるかどうかを判断することです。
この記事では、自宅のMac Studio(M4 Max・メモリ64GB)で実際に動かしているAIワークフローの中身を紹介します。何を任せていて、どんな入力から始まり、何が成果物として残り、どこを人間が確認しているか。日々動いている代表例を、この視点で順番に見ていきます。
先に断っておくと、AIエージェントの作り方や設定手順を解説する記事ではありません。仕組みのチュートリアルではなく、運用実例を見せる内容です。読み終わったときに、自分ならどの作業をAIへ渡すかを考えられる状態をイメージしてもらえればと思います。
Mac StudioをAIワークベースにするとは、どういう状態か
僕の場合、Mac Studioの上では大きく2種類の仕事が同時に動いています。
ひとつは、僕が依頼プロンプトを書いて始まる対話型の開発や制作。
もうひとつは、決まった頻度で勝手に回る定期実行やデータ観測・集計系のジョブです。
プロダクト開発も、コンテンツ制作も、データの集計も、Mac Studio1台の上で並行して回っていて、任せた仕事は、Gitの差分やNotionのレポート、記事の下書きmarkdownファイルといった形で残ります。この状態を、僕は「AIワークベース」と呼んでいます。
動かしている主役は、CodexとClaude Code、それにHermes Agentsです。使い分けは僕の実感ベースで決まっていて、Codexにはプロダクトの開発と定期実行、それに画像生成を任せています。
Claude Codeはブラウザ操作の品質が高く、同じようなライブラリを使っていてもCodexより安定して操作できる印象です。日本語のテキスト処理もうまいので、記事の構成案やタイトル作成のようなテキスト系の仕事はClaude Codeが中心になっています。
Hermes Agentsは以前、定期実行系のジョブでよく使っていました。でもCodexの性能が上がったこともあって、今はあまり使っていません。ゼロになったわけではなく、出番が減ったという状態です。念のため書いておくと、これはあくまで僕の環境と仕事内容での使い分けで、AIの進化によって3ヶ月で入れ替わるような世界観なのでそこはさっ引いてもらえるといいですね。
すべてをAIへ任せるのはまだ早いから、人間の判断と責任が必要
この記事で伝えたいことを先に言うと、AIワークフローは自宅のMacで実行できる、ということです。クラウドの専用環境や特別なインフラを用意しなくても、開発、記事制作、業務のコンテンツ制作、日次レポート、コンテキスト管理といった仕事が、普段使っているマシンの上で並行して回ります。
ただ、AIへタスクを任せれば全部終わるという話ではありません。AIの成果物がそのまま公開や納品に使えることは、僕の運用ではほぼありませんし、すべてAIへ任せられるワークフローはまだないという実感です（1年後にどうなっているかはわかりませんが）。
AIが進めてくれるのは1から2、2から3へといったの部分で、最初と最後の確認と品質の判断、責任は人間に残ります。この境界線がどこに引かれているかを見分けるのが重要になってきているんですよね。
AIを何をきっかけに動き出させるか、何を入力にするか、AIが何をするか、何が成果物として残るか、そして人間がどこを確認するか。これらのポイントを踏まえて自分の仕事のどれを渡せそうで、渡したあとに何が残るのかを参考にしていただけると思います。
業務系のコンテンツ制作: 1時間ごとのSlack確認から、人間のチェックまで
いちばん自動化が進んでいるのは、会社員としての業務で使っているコンテンツ制作のプロジェクトです。
業務案件なのでプロジェクト名は伏せますが、AIエージェントのリポジトリとしては、僕がいちばん時間をかけて作り込んだものです。もともとは僕自身が毎回繰り返していた作業をワークフローとして整理し、すべてのワークフローをAIエージェントができるように作り込みました。そのため、人間の作業をほぼそのままAIの工程に移せた例でもあります。
起動条件は朝から夜まで1時間ごとの定期実行です。この頻度に深い理由はなく、定期的に確認が回っていればこの業務では必要十分だからです。
SlackにAPIで接続していて、指定したチャンネルのメッセージを定期的に読み込みます。そこに業務の依頼が来ていれば、Claude系のエージェントがその先の工程へ自動で進む仕組みです。入力は依頼メッセージで、AIがやるのは編集・校正・修正作業やタイトルの作成といった、以前は僕が手を動かしていた工程です。工程が終わると、納品前の編集済み素材が手元に残ります。
この仕組みのポイントは、僕がモニターの前にいなくても業務が進むことです。休憩中でも、別の作業をしていても、依頼が来ればエージェントが編集作業やタイトル作りを進めてくれる。以前は勤務時間中ずっとSlackを気にしてチラチラSlackを見る必要がありましたが、その見張り自体がAIの仕事になったので、Slackを常時監視しなくてもよくなり、その行動が僕の1日から消えました。
そうやって監視自体を人がやらなくてよくなったとしても、成果物がそのまま納品されるわけではありません。エージェントが作業してくれた成果物は、僕がすべて目を通します。納品できる形になっているか、業務として品質が担保されているか。その判断はAIに渡していません。依頼の受信と工程の実行はAI、検品と納品の責任は人間、という分担です。
なお、この仕組みでは、Google Workspace・Google Cloud・Slack・Python・Node.jsなどを利用しており、セキュリティには十分気をつけて実装しています。
UPTIMEの記事制作: 音声取材からClaudeの下書きまで、編集は人間
次は、このブログ自体の話です。UPTIMEの記事がどうやって作られているかというと、これもMac Studio上のAIワークフローで回っています。
起点となるのは企画です。記事のアイデアを僕とAIで精査して、やると決めた企画は、企画を一覧管理するMDファイルへ追加していきます。
思いつきを全部書くのではなく、公開する価値があるかをここで一度ふるいにかける。企画を進めると決めたら、次は取材です。といっても、取材相手は僕です。AIが質問案を作り、僕がそれに音声で答えていきます。実際に使っているガジェットをどう使っているか、どこで困ってどんな解決をしてどんなメリットがあるのか、なぜその判断をしたか。僕の頭の中にあるコンテキストを、質問への回答という形で吐き出していくわけです。
回答が溜まると、記事の下書きを書けるだけの材料になります。そこから日本語の扱いがうまいClaudeが下書きを書き、できた原稿を編集するのは僕、人間の仕事です。
事実チェック、話の順番、書きすぎている箇所の削除。言い回しはまさに今ここのテキストは修正を加えて細くを入れたりしています。
ここは音声で答えた本人でないと判断できません。記事のサムネイル画像は、Codexに専用のスキルを作らせてトンマナやデザインを統一したものがあるので、それで作ってもらっています。
つまり、質問づくり、下書き、サムネイルはAIと分担し、企画の採否と本文の編集という判断は僕が握っている構図です。ちなみに、いま読んでいるこの記事も同じ流れで作られています。質問に音声で答えた僕のことばが材料になり、Claudeが下書きを書き、最後に僕が編集して公開する流れです。
今はテキストだけをAIと一緒に作っていますが、MiniMax H3の動画生成能力が飛躍的に向上したので記事テキストを素材にして動画にすることも検討しています。時代は動画ですしね。
プロダクト開発と画像生成: 人の依頼が起点、成果物はGit差分と公開物
開発の仕事は、定刻ではなく僕の依頼がスタートです。
代表例はこのUPTIME自体の開発で、記事を配信しているサイトもリポジトリで管理しています。CodexやClaude Codeが当たり前になったことによって、今までフロントエンドフレームワークはNext.jsしか使っていなかったところ、簡単に他の新しいフレームワークへ乗り換えることができるようになり、高速化できるようになったためTanstack Startを使ってこのサイトは構築されています。
僕が依頼文を書くと、Codexがリポジトリを読み込んで、コードや資料の状況を把握した上で開発を進めてくれます。サイトで使うライブラリやシステム設計とSEO対策などはすでに熟成されて慣れた設計が手元にあるので、ブログシステムなら一日で作ることが可能です。
入力は依頼文とリポジトリそのもの。成果物として残るのは、Gitの差分、テストの結果、そして実際に公開されるサイトやページです。画像が必要な場面では、Codexと専用スキルの組み合わせで生成します。画像生成のモデルはGPT Image 2が良い、というのが今の評価です。
僕がやるのは、出てきた差分をプレビュー環境で見て取り込むかどうかを決めることです。依頼どおりに動いているか、余計な変更が混ざっていないか。ここでも、AIが作ったものをそのまま本番へ流すのではなく、採否の判断が人間側に残っています。
UPTIME以外にも開発しているリポジトリが複数あり、自分のコンテキストデータをまとめて、どこからでも読み出せるようにしたmycontextや、法人サイトのhfmtokyoなどがあります。今もこの記事を編集しながら、裏ではAIエージェントが僕の新規サイトをゼロから構築してくれています。
どれも進め方は同じで、依頼、リポジトリ読み込み、開発、差分の確認という流れで回っています。
日次レポートとLLM Wiki: 取得はスクリプト、AIの分析はまだない
人がいなくても回る集計・管理系では、GA4とGSCの日次レポートが最も日常的なジョブです。
起動は日次で、入力はAPIから取得するデータ。取得とNotionへの同期はスクリプトが行い、僕はNotionに同期されたレポートの数値を毎日確認しています。数値が欠けていたり異常だったりしたら、APIの接続あたりが原因だろうと見当をつけて、Codexに修理を依頼する。そういう流れです。
スクリプトとAIをどう分けているかというと、基準は知能が要るかどうかです。決まったデータを定期的に取ってくるだけなら、プログラムで確実にできます。取得したデータをもとに考える、つまり推論が必要な部分だけをAIに渡す、という線引きにしています。
取得したデータから今どういう状態で、どこに改善ポイントがあるのかをAIにテキストで出力させ、レポートへ添えさせれば、自分の思考時間をショートカットさせられます。分析レポートを見て記事の企画やページの改善へつなげる判断は、いまのところ僕の頭でやっています。
過去には、運営しているサイトの競合や世間のトレンドを定点観測して、定期的に収集したデータからトレンドや改善点の分析レポートをAIに作らせていたこともあります。
意思決定に役立つ水準の情報まで出せるようになり、相当時間削減ができるようになったというのが僕の評価です。データの収集はできても、そこから使える判断材料を出させるところがキモなので、そこのチューニングにはハーネスエンジニアリングのスキルが必要になってきますね。
もうひとつ、LLM Wikiというジョブが日次と週次で動いています。これはObsidianを中心にしたコンテキスト管理で、毎日CodexやClaude Codeで実行したセッションを定刻に読み込み、今日一日の作業してきた内容を元に新しくまとめを作って、常に最新のコンテキストを保つ仕組みです。
AIと長く仕事をするほど、こちらの文脈をどう渡すかが効いてくるので、その土台を自動で更新し続けている感覚ですね。
人間へ戻す境界: AIはゼロから1を進め、責任は人間が持つ
代表的な事例は上記の通りなんですが、共通する境界線をここで整理します（AIは境界線という言葉をよく使いますよね。境界って言い過ぎ）。
まず、AIの成果物がそのまま公開やデプロイ、納品に使えることはほぼありません。それでも価値があるのは、1から2、2から9までの作業を進めてくれるからです。あくまでゼロは生み出せないのでこの解釈をしていることと、最終的に10まで持っていくのは人間だからです。
1から2、2から3と手前の工程を進めて、意思決定の材料を出してくれる。間違っていれば、間違っていると人間が指示を出せばいい。この往復ができるだけで、仕事の進み方が大きく変わりました。Claude Codeがリリースされたのが一年ほど前ですが、そのときは「まったく使えねえなこれ。でもコード自動で書いてくれるのはいいなー」という程度だったのが、AIの進化と人間の適応が進んだことでずいぶんと楽になりましたね。
一方で、最終成果物やクリエイティブの品質、公開や納品の判断とその責任は人間の仕事です。考えることや創造の面では、AIはまだまだだと感じる場面が多い。そして最終的に責任を取るのは人間なので、ここを渡すことは今のところ考えていません。なお、動画制作のワークフローも整備を進めていますが、テキストの制作フローを抽象化してしまえば動画であろうとやることはほとんど変わりません。
もうひとつ正直に書くと、任せられる状態を作るまでが大変でした。AIはこちらの業務フローもマニュアルも知らない状態から始まるので、最初は望んでいない成果物しか出てきません。当たり前ですよね。AIに暗黙の了解は通用しないからです。
だから、人間がやっていた作業をスキルという形に落とし込み、そのスキルで読み込むコンテキストとしてマニュアルやドキュメントの整備に時間をかけ、コンテキストデータをどこからでもMCPで呼び出せる環境を作りました。この修正を重ねるAIが働く環境を整備するには相当な時間がかかりましたが、この整備時間をすっ飛ばしてしまうと得られる成果も得られなくなるため避けては通れないと感じています。
この苦労を飛ばして「任せたら楽になった」とだけ書くのは違いますからね。
そして最大の注意点はセキュリティです。パスワードやAPIキーの管理、情報漏えい、プログラムの仕様を理解していないことで起きるバグなど。
AIに実行権限を渡す以上、このセキュリティ設計の最初から組み込んでおく必要があります。僕はスキルやエージェントを作るとき、セキュリティを初期段階の設計へ入れるようにしています。プログラミングやシステム設計をある程度理解していて、最低限何をやらないといけないかの当たりがつくことに、助けられている実感があります。
AIがあるから誰でもSaaSが作れるようになった！という話が盛り上がることはありますが、本当に分かっている人は、セキュリティがどれだけ重要か理解しており、プロダクトの運用・保守の大変さから、よく警告を出しています。ちょっと理解していればAPIからデータ吸い出されてデータベース荒らされちゃいますから、業務で使う個人用のアプリケーションであっても、セキュリティには注意に注意を重ねていきたいところです。
AIワークベースを与えるためにMac Studioである必要はあるのか
このAI運用にMac Studioが必須なのか疑問が沸いてくるかもしれません。正直必須ではありませんし、ここで挙げたAIジョブは、基本的にMac miniでも全部動くと僕は思っています。
それでも僕がMac StudioにAIワークフロー・ジョブを集約させている、ここがメインの作業マシンだからです。基本的にモニターの前にいるマシンで、AIエージェントの作成もスケジューリングも全部ここで制御している。
それに、ローカル実行だとCodexがリポジトリの状況もローカルのファイルも全部読み込んだ上で作業してくれます。
リポジトリの外にあるファイルまで扱えるのはローカルならではで、クラウド実行は今のところ考えていませんし、スキルやエージェントはGitHubで管理しているので、Mac Studioのメインマシン1台に集めたことによる管理の面倒も特に感じていません。なお、データベースのPostgresだけは自分が管理しているLinuxサーバーに任せていて、Mac Studioには実行と制御の役割を集めています。
つまりMac StudioでAIを運用すると合理的になるのは、AIワークフローの数が増えて、並行・継続して動かすようになり、しかも主力マシンの上のファイルやリポジトリを直接扱わせたい場合です。逆に言えば、AIを使い倒す頻度がそこまで高くないなら、Mac Studioは要らないと思います。
このように、AIを自分のマシンで動かすようになってからの使い勝手の面では、人間側の通常作業が遅くなった体感はなく、熱も音も気にならず、安定しています。ただ、トラブルがなかったわけではありません。
CodexやClaude Codeが暴走して、メモリを70GBほど使った状態で止まってしまったことがあります。これは僕の環境で起きた例で、AIエージェントが一般にそれだけ使うという話ではないんですが、この運用で先に足りなくなる資源はメモリだ、という実感にはなりました。
こんな状態でもスペックには今も余裕があって、この使い方なら1年後や2年後でも困らないだろうと思っています。
この運用が向いてない人
この使い方が合わない人もいます。僕の考える条件は次のとおりです。
まず、AIの使い方がライトな人。ChatGPTのWebを開いて質問する程度の使い方が中心で、AIワークフローを10個以上のような数で動かす予定がないなら、この運用のためにマシンを用意する必要はありません。
次に、プログラミングやシステム設計を理解しておらず、パスワードやAPIキーの管理、無限ループ、情報漏えいに不安がある人。仕組みを作ること自体は自由ですが、その不安が残っているうちはやめておいた方がいい、というのが僕の意見です。
今ではChatGPTが進化してChatGPT Workが登場しました。このWorkはローカル環境で動かすCodexをOpenAIが管理するサーバー上で再現するようなもので、Workをブラウザから使う方が安全だろうなと思います。
まず手持ちのMacで、AIにひとつ依頼してみる
Mac Studioを買わなくても、この記事の中身は試せます。基本はMac miniでも動きます。Excelのデータを読み込ませてAIに分析してもらうとか、自分のサイトを一ページだけ作りたいんだよね。といった程度の利用なら、Mac miniより下のスペックのWindows機でも構いません。5万円のPCで十分に動きます。
だから順番としては、まず手持ちのマシンで、普段の作業をひとつ依頼してみる。特別な準備もマシンの買い足しも要りません。それで出てくる成果物と、自分が確認に使う手間を体感してから、任せる仕事を増やすかを決めればいい。ワークフローが実際に増えて、並行で回し続ける運用が始まり、主力機のローカルファイルを扱わせたくなってから、Mac Studioクラスを検討しても遅くありません。
僕は一日中Macの前にいるし、iPhoneからリモートで自宅のMac Studio Codexへ指示を出すような使い方だから、Mac Studioがベストでした。
AIが快適に過ごせる環境を、少しずつ作る
僕にとってのMac Studioは、AIが快適に過ごせる環境です。指示を出すのも、スクリプトを実行するのも、エージェントを動かし続けるのも、動作が遅くて待たされることがほぼない。だから仕事を任せる相手として信頼して、開発も記事制作も業務も集められています。