メモリスによる要約- 製品ごとに1エージェントを専属で常駐させ、コンテキストの取り違えを構造的に防いでいる
- start-memolithという1つのスクリプトで、5つのtmuxセッションとClaude Codeが一括で立ち上がる
- tmuxはターミナルアプリから独立して動くため、ターミナルを再起動してもセッションは生き続ける
メモリスは1つのアプリではなく、5つの領域に分かれて開発が進んでいる。iOS/Androidアプリ本体、APIサーバーを担うバックエンド、このブログを含むウェブサイト、YouTube運用、SNS運用。それぞれ別のリポジトリで管理していて、扱う言語もドキュメントも異なる。
これをiMac1台で、5つのClaude Codeセッションを常駐させて運用している。1リポジトリに1エージェントを固定で割り当て、tmux上で落ちない状態に保ち、必要なときに名指しで呼びかける。5隻編成の艦隊のように動かしている、といえば大げさに聞こえるかもしれないが、実際の構成は次の4点に集約される。
1リポジトリ = 1エージェントに固定する
最初は1つのセッションで全リポジトリを行き来していたが、直前の作業の文脈(例: バックエンドのAPI仕様の話)が残ったまま次の作業(ウェブサイトの記事執筆)に入ると、不要な前提を引きずって的外れな提案が出やすい。
対策はシンプルにした。1つのセッションに1つのリポジトリだけを担当させる。ウェブサイト担当はウェブサイトの話しかしない。バックエンド担当はバックエンドしか触らない。役割を混ぜず、5つを並行で動かす構成にした。
start-memolithで一括起動する
5つのターミナルを毎回手で開く代わりに、start-memolithという起動スクリプトを用意している。実行すると、tmuxの各セッションで次のコマンドが一括で走る。
claude --remote-control "<名前>" --model sonnet
モデルはsonnetに固定している。既定モデルの設定に依存すると、設定側の変更で5セッションの挙動が揃わなくなるためだ。
--remote-control "<名前>"で名前を付けているのは、名前付きセッションだけがclaude.aiやスマホアプリから個別に呼びかけられるからだ。この記事自体、端末管理担当のセッションからウェブサイト担当宛てに届いたクロスセッションのメッセージがきっかけで書き始めている。
起動スクリプトにはもう1点、同名セッションが既に動いていれば起動をスキップする多重起動防止を入れている。これがないと、iMac再起動のたびに新旧セッションが重複し、どちらが現在の担当か分からなくなる。
tmuxを土台に選んだ理由
常駐させる以上、いちばん困るのは想定外に落ちることだ。
tmuxのサーバプロセスは起動元のターミナルアプリから切り離されて動く。起動した時点で親プロセスがlaunchdに付け替わり、以降はターミナルアプリの生死と無関係に存続する。今日ターミナルアプリ(Ghostty)を再起動したが、tmux配下の5セッションはこれに影響されず、確認時点で15時間以上ノンストップで稼働していた。
同じ理由で、Macのスリープ防止用のcaffeinate -sもバックグラウンドジョブではなく、tmuxセッションの主プロセスとして常駐させている。ターミナルのウィンドウ管理から独立させたいプロセスは、まとめてtmuxに任せる方針にしている。
Remote Controlで個別セッションに直接指示を出す
--remote-controlで名前を付けて起動したセッションは、claude.aiやアプリから、その名前を指定して直接メッセージを送れる。iMacの前にいなくても、「ウェブサイト担当に開発ブログを1本書いてほしい」という指示を特定のセッションだけに飛ばせる。前の節で触れたこの記事の執筆依頼は、その実例だった。
まとめ
- 製品ごとに担当セッションを固定し、コンテキストの混在を防ぐ
start-memolithで起動を1コマンドに集約し、多重起動を防止する- tmuxでターミナルアプリの生死から切り離し、再起動耐性を持たせる
- Remote Controlで名指しの指示出しを可能にする
5隻それぞれが自分の持ち場を持ち、iMac1台の前に1人しかいなくても5つのリポジトリが同時に前に進む。艦隊と呼んでいるのは比喩だが、構成自体は上の4点だけでできている。
あわせて読みたい：