3年契約のリモートデスクトップ更新を前に、自前運用に切り替えた話——Claude Code がなければ選択肢にすらなり得なかった
はじめに——3年契約の更新を前に
東京で税理士事務所を運営しています。スタッフ数名の小さな事務所です。
事務所では3年前、ある 年契約のリモートデスクトップサービス を、3年まとめ払い で契約していました。「3年分まとめれば割引になる」というおすすめを受けたからです。コロナ時代を経てテレワークが当たり前となっていた当時でしたので、必要なものなら便利で少しでも安いほうがいいと判断しての契約でした。ちなみにchromeデスクトップであれば無料で使うこともできましたが、マルチディスプレイを基本にするうちの事務所ではディスプレイの切り替えを手軽に行えるサービスが必要でした。
そして今年4月。当時から3年経過してその更新タイミングが来ました。
届いた更新案内には 値上げ通知が記載されていました。営業担当から連絡もあり、「もう一度3年まとめ払いをすれば、値上げ後でもいくらか安くできる」という提案を受けました。テレワークの社員もいるのでずっと利用してきたサービスです。値上げ後の金額も、昨今の情勢を考えれば仕方ないとも思えました。
それでも、私は 自前運用に切り替える ことを選びました。
結果から先に書きます。5月末に始めた移行は、約2週間で完了しました。コストは年契約サービス時の 1/数〜1/10以下 にまで下がり、しかも自分でインフラを把握できるようになりました。
そして、これは正直に書くべきことだと思っています。
Claude Code がなければ、そもそも『自前運用に切り替える』という選択肢が、私の中に成立しませんでした。
引き留め交渉と、それでも自前に切り替えた理由
営業担当の方から「3年まとめ払いで値上げを軽減できます」という提案を受けたとき、正直考えました。安いとは思いませんでしたが、ひとまず問題なく利用していたサービスです。何より、移行作業のリスクを考えれば、引き留めに乗るほうが圧倒的に楽です。
それでも、決断したのには3つの理由がありました。
ひとつめは、コスト構造の問題。3年まとめ払いで値上げを軽減しても、3年後にはまた同じ問題が来ます。事務所の規模は小さく、契約サービスのままでは「払い続けるだけ」の構造から抜けられない。
ふたつめは、セキュリティの観点。年契約サービスは外部のクラウドを経由します。便利な一方で、通信経路が他社の管理下にあることは、税理士事務所として小さくない論点でした。自前運用にすれば、通信は事務所と自宅のあいだだけで完結する。
みっつめは、自分たちで仕組みを持ちたいという思い。これは NT-5 で書いた「現場の人間が、現場のために、自分で作る」という哲学の延長です。リモートデスクトップは事務所の業務の土台。土台こそ自前で持ちたい。
ただ、こうした「自前で持ちたい」という思いは、実は以前からありました。10年前にも、20年前にも、心のどこかで思っていました。なのに踏み切れなかった。理由は明確で——そもそも、自分でセルフホスティングできる気が、まったくしなかった からです。
Claude Code を半年使ってきた経験が、確信に変えた
ここで Claude Code の話が出てきます。
今年に入ってから、私の事務所の自動化はずいぶん変わりました。Gemini でGAS自動化スクリプトを書き、Claudeのコワークでファイル操作を任せ、4月後半からは Claude Code でプロジェクト全体を見渡してもらう ようになりました。詳しくは 前回の note で書いた通りです。
この半年でいろいろなものを作りました。Slack Bot、Gmail自動振り分け、Notion 連携の業務管理基盤、請求書到着の自動通知、整合性監査ツール——どれも、自分一人では手が出せなかった領域です。Claude Code に手伝ってもらいながら、ターミナルでDocker を動かし、SSH で NAS に入り、認証トークンを管理する経験を、地道に積み上げてきました。
4月、更新通知を見たとき、頭にふっと浮かんだのは「もしかして、リモートデスクトップも自前で持てるんじゃないか」でした。
これは唐突な思いつきではありませんでした。ここ半年、Claude Code と一緒に作業してきた感覚から、「これならいける」という確信が、すでに自分の中に育っていた のです。1年前なら、リモートデスクトップを用意されたサービス以外で利用できるなんて考えもつきませんでしたが、今なら自分で1ヶ月以内に動かせる——そういう感覚があったから、引き留めを受けず、自前運用へ踏み出せました。
逆に言えば、Claude Code との半年がなかったら、自前運用は最初から選択肢になり得ませんでした。「自前で持ちたい」という思いだけはずっとあって、でも「やれる気がしない」で消えていく——その繰り返しだったはずです。
PoC——まずは自宅NASで動かしてみた
5月末、まずは自宅の NAS（普段から Docker でいくつかのツールを動かしている環境）に、オープンソースのリモートデスクトップソフト を入れて試運転することにしました。
Claude Code に「自宅 NAS の Docker で、別 LAN のPCから接続できるリモートデスクトップを立ち上げたい」と相談しました。すると、Claude Code が NAS の現状を確認しながら、Docker Compose の構成、ネットワーク設定、認証の組み立てを順番に提案してくれました。
ここがチャットUI 時代との大きな違いです。チャットUI なら、私が NAS の状態をスクショで送り、コードをコピペして、エラーが出たらまたスクショを送って…という往復が必要でした。Claude Code はターミナル越しに実機を確認しながら進めてくれるので、その往復が消えました。
PoC の山場——「別LAN間で初回実接続に成功」——に到達するまで、着手から1日半 でした。
「これなら本番化できる」——そう確信した瞬間でした。
本番サーバーをどこに置くか——自宅NASは不向きだった
PoC は自宅 NAS で動かしました。これは自宅NASに以前から導入していたVPNサービスがあって、その延長線上で動いたからでした。じゃあそのまま本番運用も自宅 NAS で——とは、なりませんでした。
理由は 回線です。自宅の回線は IPv6プラス（共有IP方式）。共有IP方式は固定IPが取れず、外部からのアクセスのためのポート開放にも制約があります。VPNサービスであれば、それでも問題ありませんでしたが、このVPNサービスをスタッフ全員に広げると追加投資でランニングコストが4倍ほどになってしまうので、覚悟を決めて事務所にサーバーを置くことにしました。
幸い、事務所の回線はすでに固定IP契約でした。これは何年も前にIT環境を整えてきた中で、業務上必要だと判断して取った契約です。当時の自分に感謝しました。「事務所が本番ホストの場所として最適」 という考えはありましたが、セキュリティ対策が不安でした。これを何度もClaudeに相談し本当に自前のサーバーでセキュリティ対策までできるか納得いくまでシミュレーションしたところ、対策できる自信が持てたので、覚悟を決めました。
残った問題は 事務所側で何のサーバーを使うか でした。
候補は2つ。NASを更新して導入する か、既存のPCを再活用する か。
事務所には、Windows PC として使うにはスペック的にやや古く、業務には使いにくくなっていた1台がありました。捨てるには惜しいが、メインで使うには非力。これを Linux マシンに入れ替えれば、サーバーとしては十分実用 に耐えるはずだ——というのが、Claude Code との相談の結論でした。
現在事務所にあるNASではDockerが利用できず、利用できる機種に更新してNASを買えば数万円〜十数万円コストがかかります。既存PCをLinux化すれば、ハードウェアは追加投資ゼロ。スペックも、Linux なら「Windowsとしては低い」ものが「サーバーとしては十分」になります。ハードウェア更新コストをかけずに本番サーバーが整う——この選択は気持ちよく決まりました。
「使われなくなったPCを Linux サーバーとして再活用する」というのは、聞けば当たり前のように響くかもしれません。でも実際にやるとなると、Linux のインストール、ネットワーク設定、Docker のセットアップ、起動設定の作り込み——一つひとつのステップで詰まる箇所が出てきます。これも Claude Code と並走しながら、半日くらいで土台が完成しました。
半日で PoC から本番化へ
普通なら、PoC が成功したあとは「数週間〜数ヶ月かけて検証、その後で本番化」というのが定石です。
でも、私は その日のうちに本番化に踏み切りました。
理由はシンプルでした。「PoC でうまくいくということは、本番でもうまくいく。先送りする理由がない」。そして、Claude Code がいる前提なら、本番化のスピードがまったく違う。地雷を踏んでも、Claude Code がその場で原因を切り分けてくれる。手順書を読みながら一人で詰まる、というモードに入らずに済む。
5/28 の昼に PoC の山場を超えて、夕方には本番運用の構成を組み始め、夜には Pro ライセンスを購入、その日のうちにスタッフ用のクライアント配布の準備までが整いました。半日で完走 です。正直に言うと実際に細かい設定を済ませた上でスタッフにクライアント配布するのは数日後になりますが、とりあえず使えるものという意味では半日でした。
PoC から本番への「壁」は、技術的なものではなく、心理的なものだと思っています。「これで本当に大丈夫だろうか」「もう少し検証してから」と先送りしているうちに、勢いを失う。Claude Code が横にいる感覚があったから、その心理的な壁を一気に越えられました。
セキュリティで苦労した話
自前運用の最大の利点は「通信が外部サーバーを経由しない」ことです。一方で、最大の負担は「認証・通信暗号化・接続元の制限・不正アクセス対策を、自分で設計しなければいけない」ことです。
ここがいちばん神経を使いました。大きく2つの面で苦労しました。
1. SSO 連携で2回ハマる
私の事務所では、社員アカウントは Google Workspace で一元管理しています。せっかく自前運用にするのだから、リモートデスクトップへのログインも Google Workspace の SSO（シングルサインオン） に統合したい。スタッフは普段のメールやドキュメントと同じアカウントでログインできるし、退職時に Workspace 側でアカウントを止めれば、リモートデスクトップにも自動で入れなくなる。何よりGoogleのセキュリティを利用させてもらえます。
ところが、SSO 連携の設定で 2回、深くハマりました。認証のコールバックURLでホスト名と IP直アクセスで挙動が違って認証が落ちる現象。最初は何が起きているか分からず、エラーメッセージとコードを Claude Code に見せながら、原因を1つずつ切り分けていきました。最終的に「内部DNSを整備して、すべてホスト名で統一する」設計に落ち着きました。
2. ボットからの攻撃に対する備え
もうひとつ、自前に踏み切る際に神経を使ったのが ボットからの攻撃への防御 です。
リモートデスクトップを外部から到達可能な状態に置く以上、世界中のボットが「とりあえずログインを試す」アクセスを送り続けてきます。これは年契約サービスを使っていたときは、ベンダー側がすべてブロックしてくれていた領域です。お任せだったので、私自身は意識する必要がありませんでした。
自前運用にした瞬間、この ボット対策は自分の責任 になります。具体的には、
不審な接続元IPからのアクセスをはじく仕組み
ログイン試行回数の制限と、超過時の自動ブロック
ログイン試行のログ監視と通知
これらを、Claude Code と相談しながら一つずつ組み立てていきました。完璧にはまだ届いていません。でも「対策しなければいけない領域」が見えただけでも、進歩です。
年契約サービスを使っていたときは、こうしたセキュリティ設計や運用ノウハウは、ベンダーがやってくれていました。「お任せ」を解いたとき、初めてその大きさが見えた のです。これは負担というよりも、自分のインフラへの理解を深める経験でもあります。
コストはどれだけ下がったか
数字に落とします。
移行前：3年まとめ払いで契約していた年契約サービス（具体額は伏せます）
移行後：自前運用の Pro ライセンスのみで 年36,000円・9名運用
サーバーは既存PC を Linux に再活用したので、ハードウェアの追加投資ゼロ。事務所の固定IP回線も既存です。
ざっくり、1/10以下 にまで下がりました。
しかも、スタッフが1人増えても費用がほぼ変わらない 構造になりました。年契約サービスのときは「ユーザー数で課金される」モデルだったので、新規採用のたびにコストが積み上がっていました。自前運用にしたら、9名でも12名でも、サーバーの負荷が許す範囲ではコストは横ばいです。これは事務所の成長を見据えると、かなり大きいです。
15年の経験 × Claude Code で乗り切れた話
正直に書きます。
この移行は、Claude Code がなければ実行できなかった以前に、選択肢としても成立しませんでした。「自前で持ちたい」という思いだけがあって、「やれる気がしない」で毎回消えていく——数年前なら間違いなくそうだったはずです。
ここで Claude Code の意味を改めて整理させてください。この半年、Claude Code と一緒にいろいろなものを作ってきた経験の蓄積が、「これなら自前運用もいける」という確信を、私に与えてくれた。3年契約の更新通知を見たときに「自前運用も検討する」という選択肢が、ようやく現実味を持って浮かんだのは、その蓄積があったからです。
一方で、Claude Code だけでもこの移行は実現できませんでした。15年かけて積み上げてきた「自前 IT インフラを動かす感覚」——NAS の構成、ルーターの設定、ドメインと DNS の関係、Docker の動かし方、SSL 証明書の扱い、SSO の設計思想——これがあったから、Claude Code の提案を「ああ、それね」「いや、それはこう変えたほうがいい」と判断できました。
NT-18 でも書きましたが、AI に仕事を任せるということは、「自分がやっていた仕事を、理解した上で委任する」ということだと思います。Claude Code に丸投げで自前運用を始めようとしたら、たぶん途中でセキュリティの穴に気付かないまま運用していた可能性があります。
15年の経験 × Claude Code 半年の蓄積。この両輪が揃ったから、引き留めを受けずに自前運用へ切り替える勇気を持てました。
まだ運用は始まったばかりです
このリモートデスクトップの自前運用は、6月のカットオーバーから本番運用に入ったばかりで、まだ運用ノウハウが溜まりきっていない段階です。
今後、月次の負荷監視、バックアップ運用、サーバー更改のタイミング、ボット攻撃ログの定期確認——いろいろなことを継続的に整えていく必要があります。前回のnoteで書いた「自動化は『完成』ではなく『メンテ』である」のと同じで、自前運用も「切り替えがゴール」ではなく、ここから始まる継続のメンテ だと位置付けています。
引き留めを受けて短期的に楽をするのも、自前運用に踏み切って長期的に持つのも、どちらも合理的な選択です。ただ、もし「自前運用、ずっと興味はあったけど、自分にはできないと思っていた」という方がいたら、伝えたいことがあります。
今は、Claude Code がいる時代です。15年前の私が同じことをやろうとしたら、たぶん半年でも完成しなかったと思います。今なら、2週間で本番運用にまで持っていけました。
「お任せ」を解いて、自分で持つ。その選択肢が、現実的な範囲に入ってきています。少なくとも、私の小さな事務所では、もう絵空事ではなくなりました。
関連記事
鎌原輝明税理士事務所では、税務申告や経理のご相談はもちろん、業務効率化のためのツール選びやIT活用のアイデアもお伝えしています。お問い合わせは kamaharatax.com から。
