外出先からスマホだけでサーバ障害を復旧できた日
今日、AIxECのAPIサーバが重くなりました。
外出先でした。手元にPCはありません。スマホだけです。
普通ならかなり不安になる状況です。サーバに入れるのか。どのプロセスが重いのか。止めていいプロセスなのか。止めたあと、どう復旧するのか。
ところが今回は、Kurage Agent Deck からCodexに依頼して、SSH接続、プロセス確認、サービス停止、原因調査、コード修正、リモートサーバへの反映、サービス再起動、疎通確認まで進めることができました。
これは単なる「AIでコードを書けた」という話ではありません。
経営者が、自社のシステム運用に直接関われる状態を作っておくことの価値を、かなり強く実感した出来事でした。
障害時に一番困るのは、状況が見えないこと
システム障害で一番怖いのは、サーバが落ちることそのものではありません。
何が起きているかわからないことです。
- どのサーバが重いのか
- どのプロセスがCPUを使っているのか
- そのプロセスを止めてよいのか
- 止めたらどの機能に影響するのか
- 復旧後に同じことが再発しないか
外出先でPCがないと、この確認がさらに難しくなります。
しかし、Kurage Agent Deck があれば、スマホから自然文で指示できます。
「SSHのポートは2222。ユーザーはこの情報。入ってプロセスを止めて」
このように依頼すれば、Codexがサーバに入り、ログやプロセスを確認し、必要な操作を進められます。
もちろん、すべてを自動で任せるわけではありません。止めるべきプロセス、サービス名、影響範囲、復旧確認を会話しながら進めます。
ここが重要です。AIは魔法ではありませんが、経営者の判断を支える実務担当者のように動けます。
今回止めたのはAIxECのAPIサーバ
今回重くなっていたのは、AIxECで使っている api_server.py でした。
このAPIは、AIxECの商品データ、投稿、楽天API中継、ランキング、worker状態管理、LP生成など、いくつかの処理をまとめて受け持っていました。
調査すると、公開WEBサーバからAPIへのアクセスが増えたときに、APIサーバ側の負荷がそのまま上がる構造になっていました。
特に負荷になりやすいのは、次のような処理です。
- 楽天APIへ問い合わせる書籍ランキング
- Ollamaに投げるLP生成
- worker状態確認の頻繁なアクセス
- 公開WEBサイトからの投稿一覧や商品検索
ひとつひとつは必要な機能です。
しかし、これらを1つのAPIプロセスにまとめていると、アクセス増加時に重い処理が全体へ影響します。
今回も、まずサービスを止めてサーバを落ち着かせました。その後、APIの中身を確認し、重くなりやすい処理を洗い出しました。
復旧だけで終わらせない
障害対応で大事なのは、ただ再起動することではありません。
再発しにくくすることです。
今回は、最新コードを取り込み、/books/ranking にキャッシュを追加しました。楽天APIへ毎回問い合わせるのではなく、一定時間は保存済みの結果を返すようにしました。
また、外部API取得中に同じリクエストが何本も走らないようにし、失敗時には古いキャッシュを返せるようにしました。
さらに、/lp/generate は新規生成を止めている状態では即座に disabled を返すようにしました。重い生成処理が不用意に動かないようにするためです。
修正後、リモートサーバに反映し、systemdのサービスとして起動し直しました。
最後に、ローカルAPIと公開プロキシの両方で 200 応答を確認しました。
スマホだけで、ここまでの運用ができました。
経営者にとっての本当の価値
この体験で改めて感じたのは、VWork や Kurage Agent Deck の価値は「開発を速くすること」だけではないということです。
経営者が、自社の業務システムを理解し、運用し、改善できる状態を作ることに価値があります。
従来なら、障害が起きたら開発会社や詳しい担当者へ連絡し、状況説明を待ち、対応を待つことになります。
もちろん、専門家の力が必要な場面はあります。
しかし、すべてを外部待ちにすると、判断も改善も遅くなります。小さな問題でも、自社側で何が起きているか見えないと、経営判断ができません。
VWork では、経営者のPCや作業環境に、AIと一緒に業務改善を進めるための土台を作ります。
Kurage Agent Deck は、その土台をさらに実務へ近づけるものです。
PCが手元になくても、スマホからAIエージェントに指示できる。
サーバの状況を調べられる。
止めるべきものを止められる。
コードを確認できる。
修正して、再起動して、結果を確認できる。
これは、経営者にとってかなり大きな安心材料です。
障害対応は、システムを育てる機会でもある
今回の対応で、次の課題も見えました。
APIサーバを1本にまとめすぎているため、公開WEBからのアクセス増加、外部API待ち、生成AI処理、worker管理が同じプロセスに集中しています。
今後は、処理を分ける必要があります。
- 公開WEB向けの読み取りAPI
- 楽天APIなどの外部API中継
- Ollamaを使う生成系処理
- worker起動や状態報告の管理API
このように分ければ、アクセス増加に強くなります。別サーバへ逃がすこともできます。
障害は嫌なものです。
しかし、AIと一緒に調査できる環境があれば、障害対応そのものがシステム改善の入口になります。
「なぜ重くなったのか」
「どこを分けるべきか」
「短期対策として何を入れるか」
「長期的にはどう設計を直すか」
ここまで会話しながら進められるのが、バイブコーディングの実務的な強さです。
AIを導入するとは、経営の反応速度を上げること
AI活用というと、文章生成や画像生成の話になりがちです。
しかし、会社にとって本当に重要なのは、日々の業務とシステム運用の反応速度を上げることです。
問題が起きたときに、すぐ状況を見る。
必要な処置をする。
原因を調べる。
改善を入れる。
その内容をブログや社内ナレッジに残す。
今回、復旧できたこと自体も大きいですが、それ以上に「この仕組みを作っておいてよかった」と実感しました。
VWork は、完成したシステムを納品して終わるものではありません。
経営者がAIと一緒に、自社のシステムを育てていくための作業基盤です。
Kurage Agent Deck は、その実践をスマホからでも扱えるようにします。
外出先でPCがなくても、会社のシステムに向き合える。
この安心感は、経営者にとってかなり大きな価値だと思います。