MENU

制作はWindows、業務の自動化はUbuntuへ。PC2台で仕事を分けた

制作はWindows、業務の自動化はUbuntuへ。PC2台で仕事を分けた、という記事のタイトル画像。

PCを2台に分けて、
Web制作と業務の自動処理を別々に動かすようにしました。

使っているのは、
WindowsのメインPCと、
UbuntuのサブPCの2台です。
メインPCはWeb制作・開発用。
サブPCには、
営業・秘書Bot・情報収集・業務の管理画面を移しました。

普段の操作はメインPCから。
そこからサブPCへ接続して、
業務システムの修正や確認も進められます。

それなら操作を全部メインPCにまとめればよくない? と考えたんですが、
チャットで仕事を頼む経路まで集めると、
メインPCの起動が必要になる。
サブPCだけで仕事を受けて進める経路も残すことにしました。

目次

WindowsのメインPCで制作、UbuntuのサブPCで業務を動かす

メインPCでは、
Windows上でLinux環境を使えるWSLを入れて制作・開発をしています。
サブPCにはUbuntuを直接入れ、
業務システムを動かす担当にしました。

PC主な担当置いているもの
メインPC/Windows+WSLWeb制作・開発・普段の操作制作コード・素材・手元の作業履歴
サブPC/Ubuntu営業・連絡取得・秘書Bot・月次処理業務アプリ・管理画面・業務DBの正本

業務のほうでは、
メールやチャットを取り込んだり、
案件や請求に必要な情報を整理したりしています。
チャットアプリのDiscordから依頼を受ける秘書Botも、
サブPC側。
制作中に触る環境と、
定期的に動かしておきたい処理の置き場所を分けました。

コードを書くときはメインPCを使い、
業務システムの修正ならサブPCへ反映して確認する。
手元で直ったところまででは作業を終えず、
実際の実行先でも動くところを見ます。

普段の操作はメインPCから、SSHでサブPCへ

普段は、
エディタ兼AIとの作業窓口としてOrcaを使っています。
そこでAIの作業役であるCodexに依頼すると、
SSHでサブPCへ接続し、
必要なコマンドを実行してくれます。

メインPCのOrcaで指示 → CodexがSSHで接続 → サブPCで作業

ファイルの確認や編集、
変更の反映、
ログの確認などはこの経路で進められます。
毎回サブPCのOrcaワークスペースを自分で開く必要はありません。

接続に使っているのは、
別のPCの操作やファイル転送ができるOpenSSH。
画面を見るPCと、
実際に処理するPCが違っていても、
普段の作業はメインPCから進められます。

業務の管理画面もブラウザから確認します。
PCではSSH転送を使い、
スマホではTailscale内で使うHTTPSの画面へ接続する構成です。

それでも、全部メインPC経由にはしなかった

ここで一度、
サブPC側のOrcaもなくして、
全部メインPCのCodexに任せればいいのでは、
と考えました。
操作する場所が1つなら分かりやすい。
普段の開発や保守だけなら、
それで足ります。

ただ、
Discordから秘書Botに頼む作業もあります。
今はサブPCで完結する一般業務なら、
サブPC側のOrcaにあるCodexの会話へ渡す仕組みです。
メインPCの制作案件は、
メインPCにある対象の案件環境へ振り分けます。

このAIの実行役をすべてメインPCへ集めると、
サブPC向けの依頼であっても、
メインPCが起動していない間は新しく作業を進められなくなる。
サブPCに業務を移したのに、
制作PCの電源を気にすることになります。

なので、
普段の操作窓口はメインPCに寄せつつ、
サブPCだけで受けて進める経路も残す
ことにしました。

やりたいこと今の経路
自分が会話しながらサブPCを開発・保守するメインPCのOrca → SSH → サブPC
DiscordからサブPC向けの一般業務を頼むサブPCの秘書Bot → サブPCのOrca
Discordから制作案件を頼むサブPCの秘書Bot → メインPCの案件環境
営業・情報収集などの定期処理サブPCのサービスとして実行

ここでいう依存は、
AIへの新しい依頼や、
その後の判断をどこで動かすかという話です。
サブPCで独立して動いている定期処理まで、
メインPCを切るたびに止まるわけではありません。

メインPCを止めている間も、
サブPCで完結する業務はサブPCに任せる。
メインPC上の制作案件を扱うときは、
メインPCを起動する。
この使い分けでいきます。

メモ・制作履歴・業務DBは、渡し方を変えた

2台にすると、
どのデータをどちらに置くかも決める必要がありました。
今は用途ごとに扱いを変えています。

データ扱い方
制作コード・素材メインPCに置いて制作を続ける
ObsidianのメモメインPCとサブPCで双方向同期
制作履歴メインPCからサブPCへ要約を送る
顧客・案件・請求などの業務DB更新する正本はサブPCに集約
業務データのバックアップサブPCで作成し、完成した世代をメインPCにも保管

Obsidianのメモには、
双方向同期ツールのUnisonを使っています。
両方で編集がぶつかったときは自動で上書きせず、
競合として残す運用です。
メインPCが止まっている間の同期は、
復帰後に追いつかせます。

制作履歴は、
ダッシュボードや日報で使う要約だけをサブPCへ送ります。
この履歴転送では、
生のAI会話ログや認証情報を丸ごと渡してはいません。

業務DBはサブPCに集約しました。
メインPCにもバックアップは置きますが、
そちらを普段の台帳として更新することはしません。
現在の顧客・案件・請求を確認する先はサブPCです。

移行では、古い処理を止めるところまでやった

サブPCへ移した後は、
メインPC側で動いていた営業・秘書Botなどの旧業務処理を停止しました。
再起動したときに復活しないよう、
起動を防ぐガードも入れています。

同じ処理が2台で動くと、
通知や請求の作成が重複するおそれがあります。
メインPCに残した古い業務データも保管用。
そのまま起動し直すとサブPCで進んだ状態と食い違うので、
復旧時も最新のデータから確認します。

サブPCの中では、
営業・連絡取得・管理画面・秘書Botを別々のサービスに分けました。
営業だけを停止・再起動しても、
管理画面や連絡取得を巻き込まない構成です。
業務DBなどの共通部分への依存は残ります。

バックアップにはDBに加えて、
処理結果や同期位置などの状態も含めています。
受信したファイルの一致とDBの整合性は検証済み。
ただ、
この業務バックアップだけでPC全体を戻せるわけではなく、
認証やブラウザの状態などは別途保全が必要です。

制作PCの電源に、業務まで合わせなくて済むように

移行時には、
サブPCの蓋を閉じた状態で接続とサービスの稼働を確認しました。
SSHの再接続、
制作履歴の転送、
メインPCへのバックアップ転送も確認しています。

まだ移行して日が浅いので、
長期の安定性や、
どれくらい手間が減ったかはこれから見ていくところ。
今の段階で時短の数字までは出せません。

今回話していて、
自分でも整理できたのが、
操作をメインPCに集めることと、
業務の実行までメインPCに集めることは別
という点でした。

普段はメインPCで制作し、
必要なときだけそこからサブPCを操作する。
サブPCで完結する業務は、
サブPC側で受けて進める。
制作PCの電源に業務まで合わせなくて済むよう、
この分担で運用していきます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次