OpenAIのAIエージェント「Dots」で作成した自分用のDotを、ホームラボのオーケストレーターとして組み込んでみました。携帯から「こんなWebアプリが欲しい」と話しかけてIssueを作ってもらったり、「次に取り掛かるIssue、何かない？」と候補を聞いたりしています。
内容が決まれば、そのまま調査や実装を頼めます。ラボの前に座っていなくても、思い付いたことを作業につなげられるようになりました。この記事では、普段の使い方から、それを支えるマシンの配置とエージェントの動きまで紹介します。
Dotを窓口にしたい
Dotは、OpenAIが2026年9月29日に発表した、継続的な仕事を扱うAIエージェントです。自分用のクラウドコンピューターを持ち、接続したアプリを使いながら、会話の合間にも作業を進める仕組みとして紹介されています。詳しくは公式の発表記事にまとまっています。
https://openai.com/ja-JP/index/introducing-dots/
自分のラボでは、Dotをオーケストレーターとして使っています。依頼を受けて、何を調べるか、どこで作業するか、何を確認すれば終わりかを整理する役です。
コードの調査・実装・レビューにはCodexを使います。手元のMacBookから使う場合も、Linuxマシン上で動かす場合もあります。その周りに、資料を探す入口、サーバーを操作するツール、進捗を見る画面を用意しています。
| 役割 | 担当 |
|---|---|
| 相談・依頼の整理、作業全体の調整 | Dot |
| コードの調査・実装・レビュー | Codex |
| 資料参照やサーバー操作への接続 | MCPサーバーと自作の管理ツール |
| やりたいことを伝える、方針を選ぶ、必要な判断や承認をする | 自分 |
思い付いたらそのまま作業に流す
Dotは、思い付きや短い相談を投げるのにいちばん手軽な入口です。ラボの前にいなくても、やりたいことを思い付いたときに、手元の端末から頼めます。
| こんなとき | Dotに頼むこと | 返ってくるもの |
|---|---|---|
| 欲しいアプリを思い付いた | 「こんなWebアプリが欲しい。Issueにしておいて」 | 要望と確認したいことを整理したIssue |
| 次に何を進めるか迷っている | 「次に取り掛かれそうなIssue、何かない？」 | 未完了のIssueから、着手候補とその理由 |
| 作るものが決まった | 「このIssueの作業を進めて」 | 調査・実装・検証を進めた成果と、必要な確認 |
思い付きの段階なら、まずIssueへ残してもらうだけでいい。音声でも相談できるので、最初から仕様をきっちり書く必要はありません。あとで内容を詰めて、作業に取り掛かってもらいます。
依頼した後も、調査、実装、レビューと工程ごとに指示を出し直す手間が減りました。方針や承認が必要なところは確認が戻ってきますが、通常の段取りはエージェント側で進みます。自分は、何を作りたいかと、返ってきたものが欲しかったものになっているかに集中しやすくなりました。
Mac miniをエージェントが使う作業環境に
この使い方をするために、エージェントの作業環境と、重い処理をするマシン、資料や監視を置くマシンを分けています。全体の配置と主な接続経路は、こんな形です。
青緑の実線は操作と成果回収。
青の線はWebアクセスと資料参照。
破線は監視データと共有ファイルの経路。Webアクセスは入口のCaddyから各ノードへ振り分けます。
Mac miniは、エージェント用にほぼ明け渡しています。自分が普段操作する端末というより、エージェントに渡す自由に使えるローカル環境です。たまに自分で操作することはありますが、基本はここを作業場所として使ってもらいます。
Dotが持つクラウドコンピューターもありますが、運用資料はラボ側にまとめているので、今はminiを作業場所にしています。Google DriveやSlackなどを経由して共有する方法もありますが、動作の軽さや確実性を優先して見送っています。
miniにはMCPサーバーを置き、Dotや手元のCodexに同じ資料検索と管理操作を提供しています。Dotからminiへ直接接続して操作することもできますが、クライアントごとにツールの呼び方を用意する手間を減らしたくて、共通の入口にまとめました。
Codexの作業環境、進捗を見る画面、作業管理用のDBもminiに置いています。軽い処理とmacOSのGUI・SDKを使う確認はmini側で行い、GPUなどが必要な処理はLinux側へ渡します。
Mac miniは消費電力が小さく、常時動かす作業環境に向いているのもいいところです。エージェントが使う場所をここに置き、電力を使う重い処理はLinux側へ分けています。
Raspberry Piは2台使っています。一台はAdGuard、Tailscale、Caddyを置いたアクセスの入口。もう一台は構成・運用資料、調査メモの資料庫、サービス一覧、監視、NFSを置く常設ノードです。ブラウザから資料や監視の画面を開くと、入口側のCaddyから資料・監視側のPiへアクセスが振り分けられます。
Linux側では、高性能なPCをサーバーとして運用しています。CPU・GPUとメモリを使う重たい作業の担当です。大量のメモリを使うシミュレーター、LLMの推論、画像生成などを動かしています。GitLabやCI、趣味で作ったサービス、Codexの実行環境もここにあります。
性能は高いぶん、消費電力もそれなりにあります。使わないときはスリープさせ、必要な処理をするときに動かしています。miniとPiに日常の作業環境や資料を分けたのは、この使い方にも合わせるためです。
ラボはAIの作業環境であると同時に、趣味でセルフホストのサービスを立てて使う場所でもあります。開発用のツールや、動画・音楽・写真を扱うサービスなど、日常的に使えるものを動かしています。VPNでつなげば、家の外からもいつものサービスを使える。自分が欲しいサービスをマシンスペックが許す限り増やせます。
この配置にしたのは、Linuxサーバーを止めても、相談・資料参照・作業管理を続けられるようにするためです。GitLabやCI、GPU処理が必要なときはLinux側を動かしますが、ラボの資料を読むためだけに、Linux側まで起動する必要がないようにしています。
入口が違っても、同じ資料と道具を使う
この仕組みの入口はDotだけではありません。MacBookでコードや差分を見ているなら、そのままCodexと進めます。SSHでLinuxサーバーに入り、そこでCodexを動かすこともあります。iPhone、iPad、別のMacBook Pro、Windowsも含め、手持ちの端末からラボへアクセスできます。
ラボの前にいないときはDot、コードを見ながら進めたいときは手元やSSH先のCodex、という使い分けになっています。
入口を変えても、同じ資料や管理ツール、作業ルールを使えるようにしています。端末やクライアントごとに許可する操作は異なりますが、ラボの配置や作業の進め方を一から説明し直さずに済みます。
この共通の入口に使っているのが、MCP（Model Context Protocol）です。AIから外部のツールや資料を使うための接続方式で、このラボでは資料検索、共通ルールの取得、登録済みのマシンへの操作を提供しています。
Dotからはトンネル経由でminiのMCPサーバーへ接続し、MacBookのCodexも同じサーバーを参照します。そこから資料を検索したり、管理CLIやSSHを通して登録済みのマシンを操作したりします。
SSHでLinux側に入った場合は、その場のCodexから資料や管理CLIを使います。すべての操作がminiを通るわけではありませんが、同じ運用ルールに沿って進めます。
エージェントは、操作を始める前にラボのルールと、扱えるマシンや操作の範囲を確認します。Dotからは資料を調べたり、登録済みのサーバーやPiへ操作を頼んだりできます。接続先と操作範囲をあらかじめそろえておくことで、どの入口から依頼しても同じ前提で作業を始められます。
MCPは資料や操作への接続を受け持ちます。調査や実装の進め方は共通ルールやスキルにそろえ、エージェントの実行と状態管理はハーネスで支えます。MCPを使う経路でも、SSH先でCodexを動かす経路でも、実行側では同じルールに沿って作業します。
上段: 資料と管理ツールを使う経路
下段: Codexの実行を支える仕組み
エージェントが段取りを進める
たとえば、こんな依頼をした場合を考えます。
ラボで使うメモアプリが欲しい。再起動してもデータが残るようにしたい。
この例では、DotからminiのMCPを通してLinux側のCodexへ作業を渡し、作ったアプリをLinux上で動かします。開発する経路と、できたアプリを使う経路をまとめると、次のようになります。
上段: 依頼から開発・配置まで
下段: ブラウザからPiのCaddyを経由してアプリを使う経路
資料を調べ、実装とレビューへ進む
エージェントは要望をIssueへ整理し、アプリの配置先、アクセス経路、データの保存先を調べます。構成や操作手順は運用資料、過去の判断は調査メモ、現在の状態は管理CLIや監視を参照します。
実装には作業用のブランチやGit worktreeを用意し、他の作業と混ざらないようにします。必要なら調査やレビューを子エージェントへ分担します。アプリの配置にはDocker Composeとサービス台帳、入口や監視への反映には管理CLIを使います。自分が設定先を一つずつ開いて回る部分を、エージェントがこれらの道具で進める形です。
ハーネスは、この間の「実行中」「入力待ち」「終了」といった状態を管理し、作業の継続や結果の取得を支えます。次に何をするかを考えるのはエージェントで、ハーネスはその実行を支える役割です。
普段使う条件まで確かめる
このメモアプリなら、メモを登録・一覧表示できることに加え、再起動後もデータが残ること、普段使うURLからアクセスできることを確認します。コードのテストだけでなく、頼んだアプリを実際に使う条件まで確かめます。
問題があれば、エージェントが修正と検証を繰り返します。確認条件も要望に合わせて整理し、足りない情報や方針の選択、承認が必要なところで自分に確認が戻ってきます。
進捗と結果を後から追えるようにする
一件ずつ頼むだけでなく、複数のIssueをまとめて渡して、長時間の作業をエージェント群に任せる使い方もできます。
たとえば、寝る前に「このあたりのIssueを進めておいて」と依頼しておく。自分が寝ている間も、エージェントたちは調査や実装、レビュー、検証を進めます。工程ごとに指示を出し直さずに済むので、時間のかかる作業も任せやすくなりました。
進捗を表示するWebアプリはmini上で動かしていて、iPhoneやMacBookなどのブラウザから確認できます。Codexや子エージェントの活動、作業の分担、短い進捗が見られます。Dotの活動すべてが表示されるわけではありませんが、実行側で何が進んでいるかを追えます。
エージェントは、差分と検証結果をIssueやMRへ、構成や復旧手順を運用資料へ、再利用する判断を調査メモの資料庫へ残します。実行が終了したことと、依頼したものが使えることも分けて扱います。
起きたら、完了したIssueの成果と検証結果、まだ作業中のもの、判断や承認を待っているものを確認します。必要なところへ返事をして、足りないところや次にやりたいことを伝える。作業中の画面をずっと見ていなくても、後から状況と結果を追えるのが便利です。
次の依頼でも同じ資料を参照できるので、作業の入口が変わっても続きから進めやすくなります。
ラボ全体をどう育てるかを考える
エージェントが自律的に作業するようになると、自分が見るところも変わります。個々の操作手順を追うより、メンテナンスが必要なものを洗い出したり、構成図で全体のつながりを把握したりする時間が増えます。
構成図を見ながら、メンテナンスが必要なサービスや、特定のマシンに依存している部分を洗い出す。構成を変えたら資料や図も更新してもらい、次の判断に使います。
新しい趣味サービスを動かしたい、重いシミュレーションを回したい、別の端末からも使いやすくしたい。そういう要望を渡すと、既存の構成にどう載せるかという調査から進めてもらえます。
自分の役割は、ラボで何をしたいかを決めて、エージェントが動ける環境を整える方へ寄ってきました。どこをメンテナンスし、何を増やし、どこまで任せるか。そこを考えている感じです。
気づいたら、エージェント群のマネージャーになっていた
Dotをオーケストレーターにして、手元の端末から依頼を投げるだけで、ラボの作業を進めてもらえるようになりました。これはかなり便利です。
ただ、この便利さを作るために、自分がやっていたことを振り返るとちょっと面白いです。
AIが読める資料をそろえる。MCPから操作できるようにする。作業する場所を用意して、進捗が見えるようにして、結果の受け取り方まで整える。
何を作るか、どのIssueから進めるか、どこまで任せるかを決めるのは自分です。エージェントが作業できる環境を用意して、必要なところで判断を返し、成果を確認する。手を動かす作業を任せていったら、自分の役割はエージェント群のマネージャーに近くなっていました。
便利になったのは間違いないし、環境を作るのも楽しい。ただ、任せられる作業が増えると、今度はチーム全体の動きを把握するのが大変になってきます。
今もこれを書いている裏で、AIたちがチームを組んで働き続けています。毎日かなりの量のIssueが作られ、解消され、ラボの構成も変わっていく。起きたら作業が進んでいるのはうれしいんですが、その変更を確認するコストも日に日に上がっています。
目下の目標は、この進捗確認の認知コストを下げることです。何が終わって、何が変わって、どこで自分の判断が必要なのか。それを確認するために、いくつものIssueや差分を追いかける時間を減らしたい。
手を動かす仕事は任せられるようになったけど、チームの仕事を把握する仕組みは、まだ育てている途中です。マネージャー業もなかなか楽じゃないです。
MCP Eventsを使えば、結構ごにょごにょできそうなんて考えています。