「AWSに移行した」と言えば、なんだか大仕事を成し遂げた気分になる。

実際、AI秘書「セドナ」をローカルのWindows機からAWS EC2へ移す作業は、それなりの達成感があった。.pemキーを手にして、EC2インスタンスに初めてSSHで接続したとき、小さくガッツポーズをした記憶がある。

でも、その達成感が冷めるのに、それほど時間はかからなかった。

「あれ、これ、まだ全然終わってないじゃないか」

① なぜAWSに移行しようと思ったか

セドナの起動手順を振り返ると、その「もろさ」がよくわかる。

ステップ1: uvicornサーバー起動（ターミナル1）
ステップ2: ngrok起動（ターミナル2）
ステップ3: 動作確認

ターミナルを2つ開いて、順番に起動する。どちらか落ちたら、LINEからのメッセージは届かなくなる。パソコンをシャットダウンしたら、当然セドナも沈黙する。

つまり、私が仕事しているときしか、秘書も働けない——という、なんとも本末転倒な状態だった。

「外出先からでも、夜中でも、いつでもセドナに話しかけたい。」

それがAWS移行を決めた、シンプルな動機だ。

② EC2移行で「できたこと」

AWS EC2インスタンスを立ち上げ、セドナのコードを載せた。

主な構成はこうだ。

  • FastAPI + uvicorn：LINEからのWebhookを受け取るサーバー
  • LINE Messaging API：スマホから自然言語で操作
  • Claude API（claude-sonnet-4-6）：AI本体
  • 各種ツール連携：Gmail、Googleカレンダー、WordPress、スクレイピングなど

AWSのEC2に置くことで、サーバーは24時間稼働し続ける。パソコンを閉じても、出先でも、セドナは動き続けられる——はずだった。

③ 移行してわかった「まだ終わっていないこと」

問題1：Google認証の壁

ローカル環境では、Googleの認証（OAuth）をブラウザで行っていた。credentials.jsonをダウンロードして、初回起動時にブラウザが開いて、「許可する」をクリックして完了。

これがEC2では、そのままでは動かない。

サーバーにはブラウザがない。GUIがない。「ブラウザで認証してください」と言われても、ターミナルしか開けない環境で、どうするのか。サービスアカウントを使う方法、headless認証のフロー、認証済みトークンをあらかじめ用意してEC2に置く方法——いくつかの選択肢はある。でも、「ちゃんとやる」には、それなりの設計が必要だ。

問題2：ngrokとの決別

ローカルではngrokを使って外部からのアクセスを受け付けていた。

ngrok http --url=flatfoot-deck-dispersal.ngrok-free.dev 8000

EC2に移行した今、このngrokは不要になるはずだ。代わりに、EC2のElastic IPを使い、独自ドメインでHTTPS対応する必要がある。LINEのWebhook URLはHTTPS必須なので、SSLの設定も欠かせない。「ngrokを外せばいい」——それだけに聞こえるが、やることリストは地味に多い。

問題3：Windowsべったりなライブラリ

requirements.txtを眺めると、気になる行がある。

pywinauto>=0.6.8
pyautogui>=0.9.54

これらはWindows用のGUI操作ライブラリだ。EC2のLinux環境では動かない。開発初期に「いつか使うかも」と入れたまま放置していたものが、移行の壁として残っている。

問題4：SQLiteとデータの永続性

スクレイピング結果はscraped_pages.db（SQLite）に保存している。タスク管理はtasks.json。EC2のデフォルト環境では、インスタンスを停止・再起動するとストレージの状態が変わるリスクがある。データをどこに永続化するか——EBSのボリューム設定か、S3との連携か——きちんと設計しないと、ある日突然、セドナの記憶が消える。

問題5：プロセス管理

EC2上でuvicornを起動したとして、それが落ちたとき、自動で再起動する仕組みが必要だ。systemdでサービス登録するのか、supervisorを使うのか。「起動したら動き続ける」は、当たり前のようで、きちんと設計しないと実現しない。

④ Cowork環境移設、という視点

AWS移行と並行して、もう一つ考えていることがある。

私は一人社長だが、クライアント先に常駐することもある。コワーキングスペースで仕事する日もある。自宅の書斎もある。「どこにいても、同じようにセドナが使える環境」——これが、私の言う「Cowork環境移設」の本質だ。

ローカルのWindowsで動いていたころは、家のパソコンの前に座らないとセドナは使えなかった。AWSに移行したことで、「サーバーはどこかで動き続けている」状態にはなった。でも、まだ課題は残る。

  • 認証情報の管理：APIキーや.envファイルを、複数の環境でどう安全に管理するか
  • Googleの認証トークン更新：定期的に期限が切れるトークンを、どう自動更新するか
  • 障害時の通知：サーバーが落ちたとき、どうやって気づくか

「AWSに載せた」は、スタート地点でしかなかった。

⑤ それでも、前に進んでいる

正直に言えば、この「まだまだやることがある」リストを見ると、少し気が重くなることもある。でも同時に、こうも思う。

「問題を見える化できた、ということは、解決に向けて動ける、ということだ。」

セドナを自分で作り、自分でAWSに移行しようとしたからこそ、見えてきた課題がある。外注していたら、「なんかうまく動かない」で終わっていたかもしれない。自分で手を動かしたから、問題の輪郭がはっきりした。サイバーセキュリティの仕事を長年やってきた経験から言えば、「見えていないリスク」が一番怖い。見えているリスクは、対処できる。

⑥ 次にやること（正直なリスト）

備忘録も兼ねて、残タスクを書いておく。

インフラ系

  • Google OAuth → サービスアカウント or headless認証に切り替え
  • EC2にElastic IP割り当て・ドメイン設定
  • Let’s EncryptでSSL証明書取得・自動更新設定
  • systemdでuvicornをサービス登録
  • SQLite・tasks.jsonのバックアップ戦略（S3連携など）

コード整理

  • pywinauto / pyautogui を削除（Linux環境では不要）
  • .envファイルのAWS Secrets Manager移行検討
  • ログ出力の整備（CloudWatch連携）

運用

  • サーバー死活監視の設定（UptimeRobotなど）
  • 障害時のLINE通知フロー設計
  • 本番カレンダーIDへの切り替え確認

やること多い。でも、一つずつやるしかない。

おわりに

「AWSに移行した」と書けば聞こえはいいが、実態は「移行の入口に立った」が正確だ。

インフラの世界は、完成がない。セキュリティも、完全はない。常に「今の時点でのベストを選び、改善し続ける」ことしかできない。それはたぶん、経営も、人生も、同じだと思っている。

AI秘書セドナは、まだ成長中だ。私も、まだ成長中だ。

Cowork環境移設の完了を宣言できる日を目指して、少しずつ、丁寧に進んでいく。

株式会社トーラス・ライフ　代表

#AWS #EC2 #AI秘書 #セドナ #Claude #FastAPI #LINE連携 #サーバー移行 #一人社長 #インフラ #DX #サイバーセキュリティ