はじめに
最近、YouTubeやSNSで、AIエージェントをMini PCや余っているPCにインストールして、24時間稼働させるという話をよく見かけます。
寝ている間にもAIが情報収集を行う。
プログラムを生成する。
ファイルを整理する。
外部サービスと連携して、さまざまな処理を自律的に進める。
AIエージェントによって、こうした運用が個人でも現実的になってきました。
私自身、AIを活用した業務自動化やプログラム開発を行っています。
ただ、インフラエンジニアとして気になっていることがあります。
そのAIエージェントを動かしているPCが止まったら、どうするのでしょうか。
AIエージェントに何を実行させるかという話は多いのですが、実行環境の可用性や障害復旧については、十分に触れられていないケースもあるように感じます。
今回は、AIエージェントをPCで継続運用する際に考えておきたいインフラ設計について整理します。
1. PCの24時間稼働とサービスの可用性は別
最初に整理したいのは、PCを24時間稼働させること自体に問題があるわけではないということです。
一般的なデスクトップPCやMini PCでも、適切な冷却や電源管理があれば長時間稼働できます。
しかし、24時間電源が入っていることと、24時間サービスを継続できることは別です。
例えば、次のような障害が考えられます。
| 障害・イベント | 想定される影響 |
|---|---|
| 停電・瞬断 | OSやアプリケーションの停止 |
| SSD・HDD障害 | 作業データや状態情報の消失 |
| OS更新 | 再起動による処理中断 |
| ネットワーク障害 | 外部API・クラウドへの接続失敗 |
| アプリケーション異常 | PCが動いていてもAIエージェントが停止 |
| 認証情報の失効 | 外部サービスの操作に失敗 |
| ディスク容量不足 | ログや成果物を保存できない |
Windowsの場合、更新プログラムの適用に再起動が必要になることがあります。
アクティブ時間を設定して再起動のタイミングを調整できますが、無停止を保証する仕組みではありません。
したがって、AIエージェントの運用では、PCが停止することを前提に考える必要があります。
重要なのは、PCを止めないことだけではなく、停止後に必要な仕事を再開できることです。
2. AIエージェント用PCは、実質的にサーバー運用になる
例えば、Mini PCで次のような処理を実行するとします。
- 定期的な情報収集
- Web APIからのデータ取得
- ExcelやCSVの自動加工
- Gitリポジトリへのコード反映
- クラウドストレージへの成果物保存
- メール通知
これらは、従来のサーバー上で動作していたバッチ処理やシステム連携と、それほど変わりません。
そのため、AIエージェント専用PCを継続運用するのであれば、少なくとも次の設計が必要になります。
| 設計項目 | 考えること |
|---|---|
| 可用性 | どの程度の停止を許容するか |
| 永続化 | コード・データ・状態情報をどこに保存するか |
| 障害復旧 | 別の環境で再開できるか |
| 監視 | 停止や異常をどう検知するか |
| セキュリティ | AIにどこまで権限を与えるか |
| 保守 | OS更新、依存関係、認証情報をどう管理するか |
もちろん、趣味で動かすAIエージェントに、企業の基幹システムと同じ可用性を求める必要はありません。
重要なのは、用途と停止時の影響に応じて、適切な運用水準を決めることです。
3. メインPC・サブPC・Git・クラウドストレージの役割を分ける
個人でAIエージェントを運用する場合、次のような構成が考えられます。
┌─────────────────┐
│ メインPC │
│ 開発・確認・承認 │
└────────┬────────┘
│
Git Push / Pull
│
┌────────▼────────┐
│ Gitリポジトリ │
│ コード・設定履歴 │
└────────┬────────┘
│
Git Pull
│
┌────────▼────────┐
│ サブPC │
│ AIエージェント │
│ 実行環境 │
└────────┬────────┘
│
成果物・状態の保存
│
┌────────▼────────┐
│ クラウド側の │
│ 永続ストレージ │
└─────────────────┘
※概念図です。実際には認証情報やバックアップ、監視基盤も別途必要になります。
メインPC
開発、コードレビュー、設定変更、重要操作の承認などを担当します。
人間がAIの動作結果を確認する環境として利用します。
サブPC・Mini PC
AIエージェントの実行を担当します。
メインPCの作業を妨げずに、定期処理や長時間処理を実行できます。
ただし、サブPCの内部にしか必要な情報が存在しない構成は避けたいところです。
Gitリポジトリ
ソースコード、設定テンプレート、変更履歴などを管理します。
障害時には、別のPCへコードを取得することで、実行環境を再構築しやすくなります。
ただし、Gitはデータベースや実行状態のバックアップを自動で行うものではありません。
APIキーやパスワードなどの秘密情報も、原則としてGitに格納しない設計が必要です。
クラウドストレージ
AIエージェントが生成した成果物や、復旧に必要なデータを保管します。
例えば、以下のような情報です。
storage/
├── input/
├── output/
├── state/
├── logs/
└── backup/
ただし、この構成は論理的な分類例です。
同期先のフォルダがあるだけでは、バックアップとして十分とは限りません。
誤削除や破損したデータが同期される可能性があるため、バージョン履歴や独立したバックアップを用意する必要があります。
4. Gitで復旧できるのはコードだけではないか
AIエージェントを運用する際、Gitでソースコードを管理していれば安心だと考えるかもしれません。
しかし、プログラムを復元できても、業務を再開できるとは限りません。
例えば、AIエージェントが100件のデータを処理していたとします。
70件を処理したところでPCが停止しました。
この場合、再起動後にどこから処理を再開するのでしょうか。
最初から100件を処理するのか。
残り30件だけ処理するのか。
これを判断するには、処理の進捗情報が必要です。
例えば、次のような状態情報を保存する方法が考えられます。
{
"job_id": "daily-import-001",
"status": "running",
"processed": 70,
"total": 100,
"last_processed_id": "record-0070"
}
このような情報をローカルPCのみに保存していると、ストレージ障害で失われる可能性があります。
そのため、処理の再開に必要な状態情報は、永続的なストレージやデータベースで管理する方法を検討します。
ただし、processedの件数だけで安全に再開できるとは限りません。
処理順序の変更や部分的な失敗に備えるなら、対象データごとの処理状態を管理した方が確実です。
5. 再実行を前提にした処理設計
AIエージェントの運用では、停止や再実行を前提とした処理設計が重要です。
例えば、ファイルを処理する場合、次のような状態を管理できます。
PENDING
↓
RUNNING
↓
SUCCEEDED
RUNNING
↓
FAILED
↓
RETRY
ここで注意したいのは、再実行による二重処理です。
例えば、AIエージェントがメールを送信した直後に停止した場合です。
メールは正常に送信できたものの、送信完了の記録が残らなかった。
その状態で処理を再実行すると、同じメールを二重送信する可能性があります。
これはAI特有の問題ではなく、従来のバッチ処理やシステム連携でも発生する問題です。
冪等性を意識する
同じ処理を複数回実行しても、結果が重複しないようにする考え方を冪等性と呼びます。
例えば、ユーザー情報の登録処理なら、登録前に対象IDの存在を確認する方法が考えられます。
ただし、存在確認と登録が別々の処理であれば、同時実行時に競合する可能性があります。
実際のシステムでは、データベースの一意制約やトランザクション、外部APIが提供する冪等キーなどを組み合わせる必要があります。
AIエージェントに処理を任せる場合も、こうした従来のシステム設計の知識が役立ちます。
6. 本当に24時間稼働が必要なのか
ここまで常時稼働を前提に考えてきましたが、そもそもすべてのAIエージェントを24時間動かす必要があるのでしょうか。
例えば、次のような用途です。
| 用途 | 実行方式の候補 |
|---|---|
| 毎朝のニュース収集 | スケジュール実行 |
| 夜間のExcel集計 | 定期バッチ |
| GitHubの変更検知 | イベント駆動 |
| 問い合わせ受付 | 常時受付可能なサービス |
| ローカルファイル整理 | 手動実行・PC起動時 |
| 長時間のデータ分析 | ジョブ管理・途中状態の保存 |
毎朝1回だけ処理するのであれば、24時間プロセスを稼働させる必要はありません。
Windowsならタスクスケジューラ、Linuxならcronやsystemd timerなどを利用できます。
クラウドなら、GitHub ActionsやCloud Run Jobsなども候補です。
GitHub Actionsによる定期実行
例えば、次のように設定できます。
name: Daily Agent Job
on:
schedule:
- cron: '17 22 * * *'
workflow_dispatch:
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Execute job
run: python main.py
この例は、毎日22:17 UTCを基準にジョブを起動する設定です。日本時間では翌日7:17に相当します。
GitHub Actionsのscheduleイベントは、高負荷時に遅延したり、条件によって実行が取りこぼされたりする可能性があります。
したがって、厳密な実行時刻や必達性を求める場合には、追加の監視や再実行の設計が必要です。
Cloud Run Jobsによる実行
Google Cloudでは、Cloud Run JobsをCloud Schedulerから定期的に起動できます。
こちらも、必要なときだけコンテナを実行する方式です。
PCを常時稼働させなくても、定期的なデータ処理や情報収集を実現できる場合があります。
ただし、クラウドに移したからといって、障害や再実行の問題がなくなるわけではありません。
ジョブ失敗時のリトライ、処理の重複、データの永続化、ログ、認証情報などの設計が必要です。
AIエージェントを24時間起動しておくことと、必要な処理を継続的に実行することは違います。
7. 監視を同じPCに置くことの限界
AIエージェントを常時稼働させるのであれば、監視も必要になります。
例えば、プロセスが停止した場合に自動で再起動する仕組みです。
Windowsならタスクスケジューラ、Linuxならsystemdなどが利用できます。
ただし、同じPC上の監視には限界があります。
AIエージェントのプロセスだけが停止した場合は、再起動できるかもしれません。
しかし、PCそのものが停止した場合、ローカルの監視プログラムも停止します。
そのため、重要な処理では外部監視も検討する必要があります。
例えば、次のような仕組みです。
AIエージェント
│
│ 定期的にハートビート送信
▼
外部監視サービス
│
├── 正常：記録
│
└── 一定時間応答なし
│
▼
異常通知
ただし、ハートビートが届いていても、業務処理が正常に完了しているとは限りません。
プロセスの生存確認に加えて、ジョブの成功履歴や最終処理時刻などを監視する必要があります。
これは従来のシステム運用でも重要な考え方です。
8. RTOとRPOを決める
AIエージェントを業務で利用するのであれば、どの程度の停止やデータ損失を許容するかも考えたいところです。
ここで役立つのが、RTOとRPOです。
RTO（Recovery Time Objective）
障害発生後、どの程度の時間で復旧することを目指すか。
RPO（Recovery Point Objective）
障害発生時に、どの時点までのデータを復旧できることを目指すか。
例えば、次のような考え方です。
| 用途 | RTOの例 | RPOの例 |
|---|---|---|
| 個人の情報収集 | 24時間 | 前日のデータ |
| 定期的な業務集計 | 4時間 | 最終成功実行時点 |
| 顧客向け自動受付 | 30分 | 数分前 |
※数値は説明用の仮定です。実際の目標値は業務の重要度と費用に応じて決めます。
個人利用のAIエージェントであれば、24時間停止しても困らない場合があるでしょう。
一方、顧客向けの業務に組み込むなら、より短い復旧時間が求められるかもしれません。
重要なのは、すべての環境を高可用性にすることではありません。
求められる可用性に合わせて、適切なコストで運用設計することです。
9. AIエージェントの権限設計
継続運用するAIエージェントには、さまざまな外部サービスへのアクセス権限が必要になります。
例えば、GitHub、クラウドストレージ、メール、業務システムなどです。
ここで考えたいのは、最小権限の原則です。
情報収集だけを行うAIに、ファイルの削除権限は必要でしょうか。
レポート生成を担当するAIに、メールの自由な送信権限を与える必要があるでしょうか。
こうした権限は、必要な範囲に限定すべきです。
また、外部から取得したWebページやドキュメントに含まれる指示を、AIエージェントが誤って実行してしまう可能性も考える必要があります。
AIエージェントでは、従来のアプリケーションの脆弱性対策に加えて、プロンプトインジェクションやツール操作の制御も重要です。
特に、次のような操作は慎重に扱いたいところです。
- ファイルの削除
- 本番データの変更
- 外部へのメール送信
- Gitリポジトリへの変更反映
- 課金を伴うAPI操作
必要に応じて、人間の承認を挟む構成が合理的です。
また、APIキーや認証トークンはソースコードに直接書き込まず、環境変数やシークレット管理サービスなどを利用します。
10. 個人利用と業務利用でどこまで設計するか
ここまでの内容を整理すると、AIエージェントの運用にはいくつかの段階があります。
| 項目 | 個人検証 | 個人の継続利用 | 業務利用 |
|---|---|---|---|
| 実行環境 | メインPC | Mini PC・クラウド | 要件に合わせた実行基盤 |
| コード管理 | ローカルGit | リモートGit | レビュー・変更管理 |
| データ保管 | ローカル中心 | 外部バックアップ | 復旧可能な永続ストレージ |
| 監視 | 手動確認 | 異常通知 | 外部監視・運用手順 |
| 復旧 | 手動再実行 | 再開手順を整備 | RTO/RPOに基づく設計 |
| セキュリティ | 権限の限定 | 秘密情報の分離 | 最小権限・承認・監査 |
※あくまで設計例です。個人利用であっても、重要データや外部サービスを扱う場合には、より厳密な管理が必要です。
すべてのAIエージェントに高度な冗長構成が必要なわけではありません。
しかし、少なくとも停止したときにどうなるかは考えておきたいところです。
11. AIエージェント運用前のチェックリスト
実際にAIエージェントを常時稼働させるなら、私は次の項目を確認したいと思います。
- 本当に24時間稼働が必要か
- PC停止時の業務影響を把握しているか
- ソースコードをGitなどで管理しているか
- 設定ファイルと認証情報を分離しているか
- 重要データのバックアップがあるか
- バックアップから復元したことがあるか
- 処理状態を記録しているか
- 再実行時の二重処理を防げるか
- PCやプロセスの停止を検知できるか
- 外部サービスへの権限が適切か
- OS更新やメンテナンスの方針があるか
- 別の環境で再構築できるか
このすべてを最初から実装する必要はありません。
ただし、業務として継続的に利用するのであれば、優先順位を決めて整備すべき内容だと思います。
まとめ
AIエージェントを24時間稼働させるという考え方は、魅力的です。
しかし、PCを24時間動かすことと、サービスを安定して継続することは違います。
AIエージェントを業務で利用するなら、従来のインフラ設計と同じように、可用性、永続化、監視、障害復旧、セキュリティを考える必要があります。
また、すべてのAIエージェントを常時稼働させる必要もありません。
必要な時間にジョブを実行する方法や、クラウドのマネージドサービスを利用する方法もあります。
最終的には、何を実現したいのか、どの程度の停止を許容するのか、どこまで運用コストをかけるのかによって、適切な構成を選ぶことになります。
AIの能力が高くなっても、それを実行するコンピューターの制約がなくなるわけではありません。
AIエージェントを24時間動かすことが目的になってはいけない。
重要なのは、止まらないことだけでなく、止まっても仕事を正しく再開できることです。
AIが自律的に仕事を行う時代だからこそ、従来のインフラエンジニアが培ってきた運用設計の考え方が、改めて重要になるのではないでしょうか。
参考資料
- Microsoft：アクティブ時間でPCを最新の状態に保つ
- Microsoft Learn：タスクスケジューラの失敗時再起動設定
- GitHub：ワークフローのトラブルシューティング
- Google Cloud：Cloud Run Jobsの定期実行
推奨タグ