AI をサーバーに接続する：AI エージェントがあなたのサーバーでデプロイと管理を担う方法

ほとんどの人は、これまで AI を電話の向こうにいるとても博識な同僚のように使ってきました。サーバーの問題を説明してコマンドを提案してもらい、それをコンソールにコピーし、エラーメッセージをコピーして送り返し、動くまで同じやり取りを繰り返します。AI を自分のサーバーに接続すれば、この回り道はなくなります。Claude Code、OpenAI Codex CLI、Gemini CLI のような AI エージェントは、自ら SSH でサーバーにログインし、ログを読み、設定を確認し、変更を適用し、結果をテストし、何をしたかを書き残します。あなたが行うのは、タスクを指示することと、元に戻せない手順を承認することです。

本記事は実践レポートです。KernelHost では数か月前から、AI エージェントが毎日、当社自身のインフラの作業に加わっています：顧客ポータル、監視、決済フロー、ドキュメント。エージェントとサーバーの接続をどのように構成しているか、エージェントがどのような手順で本番システムにデプロイするか、その際に問題が起きたり情報が外部に漏れたりしないよう、どのようなルールを設けているか、そしてこれらすべてを機能させるためにサーバーに何が必要かを紹介します。ツールと構成の基礎は記事 AI マネージドサーバー：AI エージェントを安全に接続する で、サーバーへのインストールは Claude Code と Codex CLI のガイド で解説しています。

AI をサーバーに接続するとはどういうことか

AI をサーバーに接続するとは、AI エージェントに、多くの場合 SSH 鍵を使って、サーバーのコマンドラインへの専用の管理されたアクセスを与えることです。この時点から、エージェントはコマンドを提案するだけでなく自ら実行し、出力を読み、そこから次のステップを導き出せるようになります。言語モデル自体は引き続きプロバイダー（Anthropic、OpenAI、または Google）側で動作し、あなたの PC やサーバーで動くのは、コマンドを発行する軽量なコマンドラインツールだけです。

重要なのは「管理された」という言葉です。サーバーにアクセスできるエージェントは自動操縦ではなく、介入的な操作の前には必ず確認を求める、とても仕事の速い同僚です。確認なしでどこまで任せるかは、あなた自身が決めます：読み取り専用のアクセスから、決まった手順に沿ったアップデートの自律的な適用まで。

チャットボットかエージェントか：違いを表で比較

こうして 30 分の往復が数分で済むことも多く、「打ち間違い」というミスの原因は完全になくなります。

AI エージェントがサーバーで行うこと：当社の運用からの実例

以下の例は当社の日常業務から取ったものです。名前、アドレス、認証情報は伏せていますが、手順は実際のものです。

バックアップと切り戻し手順を備えたデプロイ

顧客ポータルやサーバースクリプトに変更を加えるときは、エージェントが適用作業を引き受けます。まずサーバー上のファイルを最後に確認した状態と比較し、他の人による変更を上書きしないようにします。次にドキュメントルートの外に日付入りのバックアップを作成し、切り戻しスクリプトを書き、新しいファイルの構文を確認し、以前と同じ所有者と権限で適用してから、影響を受ける機能をテストします。すべてがグリーンになって初めて、完了を報告します。詳しい手順は、後述のデプロイのセクションで説明します。

トラブルシューティング：症状から原因まで数分で

「オフィスからはウェブサイトにつながらないのに、外出先からはつながる」。以前なら、これは長い調査を意味していました。エージェントはファイアウォールのルールを確認し、保護ソフトウェアのログからオフィスの IP アドレスを検索し、作動したルールを見つけ、どのリクエストがそれを引き起こしたかを説明します。どう対処するかの判断は引き続き私たちが下しますが、探偵役はもう私たちではありません。502 Bad Gateway やディスクフルといった典型的なウェブサーバーのエラーでも、同じように作業します。journalctl とアプリケーションログを読み、仮説を立て、何かを変更する前にその裏付けを取ります。

エージェントが自ら構築する監視

当社の監視の大部分は、エージェントとの共同作業から生まれました。数分ごとに cron ジョブでサービスをエンドツーエンドでテストし、障害があれば Telegram ボットなどを通じてスマートフォンに通知を送る、小さなチェックスクリプトです。エージェントはスクリプトを書き、意図的に障害を起こしてテストし、cron ジョブを設定し、アラートをミュートする方法を文書化します。こうした仕組みを基本からどう構築するかは、記事 サーバー監視を設定する で説明しています。

棚卸しと整理

契約はすでに解約されているのに、まだ稼働しているサーバーはどれか。料金を払っているのに、もう使われていない追加サービスはどれか。エージェントはこうした問いに、データベースや API に読み取り専用で問い合わせ、結果を表にまとめることで答えます。整理は承認を得てからでなければ行えず、その前に、たとえば直近数日のトラフィックを見て、そのマシンが本当に使われていないかを確認します。

自然に育っていくドキュメント

すべての変更は、変更履歴への記入と、必要に応じた運用マニュアルへの追記で締めくくられます。エージェントにとっては数秒の作業ですが、「そもそもなぜこうなっているのか」という疑問に書面の答えがあるので、後で私たちの何時間もの手間が省けます。

AI がサーバー上で直接作業するメリット

• スピード：人が数分かけて読む内容を、エージェントは数秒で読みます。仮説もまず説明するのではなく、すぐに試します。
• 網羅性：誰かが関係ありそうだと判断した抜粋だけでなく、インクルードされたファイルを含む設定全体と、エラー前後のログ行を読みます。
• 一貫した手順：バックアップ、構文チェック、確認が毎回実行されます。金曜日の夜でも、20 回目の小さな変更でも同じです。
• 手間のかからないドキュメント化：すべての変更が、理由、バックアップの保存場所、切り戻し手順とともに記録されます。
• スクリプトを学ばなくても自動化：チェックスクリプト、cron ジョブ、レポートが普段の言葉による説明から作られ、運用前にテストされます。
• 作業しながら学べる：エージェントは、何をなぜ行うのかを説明します。そのやり取りを追っていれば、数週間後には自分のサーバーをずっと深く理解できるようになります。

3 つの構成と当社が採用している構成

エージェントをサーバーに接続する実績のある方法は 3 つあります。違いは、ツールがどこで動くか、そして認証情報がどこに置かれるかです。

当社の選択：エージェントは作業用 PC、サーバーへは SSH

当社は 1 つ目の方式を採用しています。エージェントは作業用 PC で動き、各サーバーは SSH 設定にエントリーを持ち、エージェントは専用の鍵で接続します。最も重要な理由は、当社が多くのシステムを管理していることです。この方式なら、1 つのエージェントが 1 回のセッションの中で、たとえばウェブサーバーからデータベース、さらにファイアウォールへと、複数のサーバーにまたがって原因を追跡できます。さらに、AI プロバイダーへのログイン情報と鍵が、もともと保護している 1 か所にまとまります。サーバーが 1 台だけで、夜間に自動レポートが欲しい場合は、2 つ目の方式が適しています。長所と短所について詳しくは、AI マネージドサーバー の記事をご覧ください。

ガイド：AI エージェントを SSH でサーバーに接続する

以下の 7 つのステップは、Claude Code、Codex CLI、Gemini CLI のいずれでも同じように使えます。例ではドキュメント用の IP アドレス 203.0.113.10 とユーザー名 deploy を使っているので、どちらもご自身の値に置き換えてください。前提として、記事 SSH を保護して鍵認証ログインを設定する で説明しているように、SSH 鍵でログインできるサーバーが必要です。

ステップ 1：エージェント専用の SSH 鍵を作成する

エージェントには決してあなた個人の鍵を渡さず、専用の鍵を与えます。そうすれば、自分のアクセスを失うことなくエージェントのアクセスをいつでも取り消せますし、どのログインがエージェントによるものかをログで見分けられます。

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 は鍵が短く、高速で、安全とされています。コメント ki-agent は後でサーバーの authorized_keys に表示され、ひと目でその鍵だとわかるようにします。

ステップ 2：公開鍵をサーバーに登録する

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

アクセスをさらに絞り込みたい場合は、サーバー上のファイル ~/.ssh/authorized_keys で鍵の前にオプションを追加します。from= は特定のアドレスからのログインだけを許可し、no-agent-forwarding と no-port-forwarding は、接続が踏み台として使われるのを防ぎます。

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

その後サーバーが Permission denied (publickey) を返す場合は、記事 SSH の Permission denied (publickey) を解決する が参考になります。

ステップ 3：SSH 設定にホストエイリアスを作成する

エイリアスを使うと、エージェントは短い名前を知っているだけで済み、常に正しい鍵を使います。

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

あとは ssh web-prod "systemctl status nginx" だけで十分です。IdentitiesOnly yes は、SSH がキーリング内の他の鍵を順に試すのを防ぎます。サーバーを追加するたびに専用のブロックを作成し、テストシステムと本番システムには web-test と web-prod のように異なる名前を付けるのがおすすめです。そうすれば、取り違えが名前の段階で目に付きます。

ステップ 4：エージェントをインストールしてログインする

Claude Code、Codex CLI、Gemini CLI は Linux、macOS、Windows で動作し、プロバイダーのアカウントまたは API キーでログインします。インストールとブラウザーなしでのログインは、ステップバイステップガイド で説明しています。作業用 PC 方式の場合は、ツールをサーバーではなく自分の PC にインストールします。

ステップ 5：エージェントが従うルールを決める

3 つのツールはいずれも、起動時に作業ディレクトリにあるルールファイルを読み込みます。Claude Code は CLAUDE.md、Codex CLI は AGENTS.md、Gemini CLI は GEMINI.md です。そこに、あなたのサーバーでどのように作業するかを書きます。実際の運用で試したひな形は次のとおりです。

# サーバー上での作業ルール

- 変更の前には必ず、ドキュメントルートの外に日付入りのバックアップを作成する。
- 適用の前に構文を確認する（nginx -t、php -l、apachectl configtest）。
- 適用の後はサービス、ログ、機能を確認し、結果を報告する。
- パスワード、API キー、トークンは決して出力せず、ファイルにもコピーしない。
- 削除、データベースの変更、元に戻せない操作はすべて、明示的な承認を得てから行う。
- コントロールパネルが管理するファイルは直接変更しない。
- テスト用ファイルはテスト後に削除する。

ルールは運用とともに育っていきます。エージェントがあなたの意図と違うことをしたら、そのたびに修正内容をルールとしてこのファイルに加えます。数週間もすれば、エージェントはあなた自身と同じように作業するようになります。

ステップ 6：承認と許可リストを設定する

初期設定では、ツールは何かを変更するコマンドの前に毎回確認を求めます。最初はそれが正解です。いつも承認している読み取り専用のコマンドは、あらかじめ許可しておけます。Claude Code では、ファイル .claude/settings.json で設定します。

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

このリストにないものは、引き続きあなたの承認が必要です。すべての確認を無効にするスイッチは、使うとしても使い捨てのテストマシンまでにとどめてください。

ステップ 7：最初のタスクは読み取りのみ

何も変更できないタスクから始め、エージェントがどのように進めるかを観察してください。

web-prod で直近 24 時間の nginx のエラーを確認し、最も多い原因を 3 つ、
それぞれログからの根拠を 1 つずつ添えて挙げてください。何も変更しないでください。

分析が正確だとわかってから、新しいログローテーションや systemd サービス のような小さな変更に進み、本番システムへのデプロイはさらにその後です。

エージェントのデプロイ方法：本番システムを変更するたびに従う当社の手順

AI エージェントが本番システムにデプロイしてよいのは、バックアップ、事前に用意した切り戻し手順、適用前後の確認を含む決まった手順に従う場合だけです。当社では、その手順は次のとおりです。

1. 現状を確認する。 サーバー上のファイルを、最後に確認した状態と比較します。その間に誰かが変更していた場合、エージェントはその変更を上書きせずに作業を中止し、確認を求めます。
2. バックアップを作成する。 対象のファイルを、日付を付けてドキュメントルート外のバックアップフォルダーに保存します。ドキュメントルート内のバックアップは、場合によっては外部から取得できてしまいます。
3. 切り戻し手順を用意する。 1 つのコマンドで元の状態に戻す小さなスクリプトを、緊急時になってからではなく、変更の前に作成します。
4. 構文を確認する。 新しいファイルは適用前に確認します。PHP なら php -l、nginx なら nginx -t を使います。こうすれば、構文エラーがそもそも本番システムに届きません。
5. 正しい権限で適用する。 所有者、グループ、ファイルのパーミッションは元のファイルから引き継ぎます。アップデート後の障害の原因として、誤った権限は構文エラーに次いで多いものです。
6. 副作用なしでテストする。 テストは読み取りのみで行うか、架空のテストデータを使うか、隔離された環境で実施します。本物の注文や本物の顧客データは決して使いません。
7. 本番環境で確認する。 適用後に、HTTP ステータス、エラーログ、変更した機能を確認します。
8. 記録する。 変更履歴と運用マニュアルに、バックアップの保存場所と切り戻し用のコマンドも含めて追記します。

実際のパスの代わりにプレースホルダーを使ってコマンドの流れで表すと、おおよそ次のようになります。

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

切り戻し手順を変更の前に用意する理由

障害が起きているときに、きれいな切り戻し方法をじっくり考えられる状態の人はいません。スクリプトがすでに用意されていれば、切り戻しは数秒で終わり、適用後の確認が失敗したときにはエージェントが自分で実行することもできます。これこそが、「さっと」何かを変更するエージェントと、本番システムを任せられるエージェントとの最大の違いです。

何も壊すことのないテスト

多くの機能は、実際に何かが起きることなしにはテストできません。注文、支払い、メールなどです。ここで役立つのが 3 つの手法です。1 つ目は、ツール自体が備えているドライランです。2 つ目は、どこにも存在しないことが確実な架空の ID です。3 つ目は隔離された環境です。ネットワークのない専用のネットワーク名前空間で動くプロセス（unshare -n）は、外部の API に到達することも誤って何かを購入することもできませんが、Unix ソケット経由でローカルのデータベースには引き続きアクセスできます。テストが終わったら、テスト用ファイルはすべて削除します。

費用が発生する操作にはロックが必要

何かを注文、課金、削除する処理は、誰かがダブルクリックしたりエージェントがコマンドを繰り返したりした場合でも、同時に 2 回実行されてはいけません。Linux で最も簡単な解決策は flock です。

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "すでに実行中です"

データベースアプリケーションでは名前付きロック（MySQL と MariaDB の GET_LOCK）が、API では Idempotency-Key が同じ役割を果たします。これについては、後述の KernelHost API のセクションで詳しく説明します。

セキュリティ：何も漏らさずにエージェントにアクセスを与える

最もよく耳にする懸念は「自分のデータはどうなるのか」というものです。正直に答えると、エージェントは読んだものをすべて、処理のためにプロバイダーの言語モデルに送ります。そのため、エージェントがそもそも何を目にするかは、以下のルールであなたが決めます。

秘密情報はチャットに入れない

パスワード、API キー、トークンは、タスクに書き込むことも、エージェントに出力させることも決してしません。スクリプトはそれらを権限 600 のファイルから読み込み、エージェントはスクリプトを使うためにその中身を表示する必要がありません。それでもキーがチャットに入ってしまった場合は、すぐにプロバイダー側で無効化し、新しく発行します。断片もチャットに入れてはいけません。キーの先頭の数文字はトラブルシューティングの役には立ちませんが、攻撃者の手間を減らしてしまいます。

専用の鍵、専用の権限、いつでも取り消し可能

エージェントごとに専用の SSH 鍵を与え、どの鍵も authorized_keys 内のコメントで識別できるようにします。アクセスを取り消したいときは、その 1 行を削除すれば済みます。それで足りる場合、エージェントは専用のユーザーと、必要なコマンドだけを許可する sudo ルール で作業します。API には必要最小限の権限を持つ専用のキーを発行し、分析だけが目的なら読み取り専用にします。

承認：人の判断なしには決して行わないこと

当社では、明示的な同意がない限り、エージェントは削除、データベースへの書き込み、ファイアウォールや保護ルールの緩和、マシンの停止、注文のいずれも行えません。ツールもこれを支えています。Claude Code は介入的な操作を一時停止し、さらに、安全フィルターが危険なコマンドを検知して承認されるまでブロックするよう設定することもできます。当社の日常業務での実例として、このフィルターは、技術的には正しいものの元に戻せない操作を一度ならず止めてきました。その操作は、人が明示的に承認してから初めて実行されました。まさにそうあるべきです。

追跡可能性：ログ、変更リスト、バックアップ

どのセッションも、人が読める痕跡を残します。日付入りのバックアップ、切り戻しスクリプト、変更履歴の記載、システムログに残るログイン記録です。さらに /etc を etckeeper で Git 管理すれば、設定の変更をすべて差分として確認できます。追跡できないものは、元に戻すこともできません。土台となるのは、きちんと機能する バックアップ戦略 です。エージェントはバックアップの代わりにはならないからです。

AI エージェントに適したサーバーとは

AI を活用した管理に使うサーバーには、完全なルート権限、SSH 鍵によるログイン、制限のない外向き接続、常時 DDoS 対策、そして理想的には、サーバーを自動で注文し制御できる API が必要です。言語モデルはプロバイダー側で動くので、GPU は必要ありません。

AI マネージドサーバーに KernelHost を選ぶ理由

基本的に、AI エージェントはシェルを使えるサーバーであればどれとでも作業できます。しかし実際には、どれだけの作業を本当に任せられるかは環境で決まります。KernelHost の KVM ルートサーバー や 専用サーバー には、制限付きのアカウントも、AI プロバイダーへの HTTPS 接続を妨げる障壁も、試すだけで高くつくような契約の縛りもありません。常時 DDoS 対策 はすべてのサーバーで追加料金なしに有効で、計算負荷の高いタスクには専用コアを備えた プロフェッショナル VDS もあります。料金は PrePaid 方式で、契約なし、最低利用期間なし、初期費用なしです。まず試してみたい場合は、無料のテストサーバー から始められます。

KernelHost API：エージェントがサーバーを自ら注文し、制御する

最も大きな効果が得られるのは、個々のサーバーより 1 つ上のレイヤーです。KernelHost API を使えば、エージェントは商品と価格の照会、サーバーの注文、自分のサービスのステータスの取得、サーバーの起動、停止、再起動、解約の申請と取り消しを行えます。これにより「テストサーバーを用意して」が 1 つのタスクになります。エージェントがマシンを注文し、プロビジョニングを待ち、SSH で接続し、アプリケーションをインストールして、アドレスを報告します。

エージェントによる利用を想定して、この API は意図的に慎重な設計になっています。API キーには必要な権限だけが付与され、分析用のキーでは何も注文できません。Idempotency-Key により、タイムアウトエラーの後にエージェントが再送した注文が二重に実行されることはありません。リクエストはキーごと、アカウントごと、アドレスごとに制限されているので、無限ループに陥ったエージェントでも雪崩のようなリクエストを引き起こすことはありません。さらに、認証情報が取得されるたびにメールで通知が届くので、エージェントがいつ認証情報を読んだかを把握できます。

AI マネージドサーバーの費用はどれくらいか

費用の項目は 2 つです。1 つ目はサーバー自体です。SSH 経由で作業するエージェントのためであれば特別な構成は必要なく、アプリケーションがもともと動いているルートサーバーで十分です。エージェントをサーバー上で直接動かす場合でも、ツール自体に必要なメモリは数百メガバイト程度なので、ほかにあまり動かしていなければ 2 vCPU と 4 GB RAM のルートサーバーで足ります。2 つ目は言語モデルです。コマンドラインツールの利用を含むプロバイダーのサブスクリプションか、従量課金の API キーのどちらかです。毎日集中的に使うならたいていサブスクリプションのほうが安く、人が付かない自動化タスクには、月額予算で上限を設定できる API キーがクリーンな方法です。最新のサーバー料金は ルートサーバーのレンタル のページでご確認いただけます。

よくある失敗とその防ぎ方

• エージェントが管理者個人の鍵で作業している。 これでは、エージェントのアクセスだけを取り消すことも、ログで区別することもできません。解決策：専用のコメントを付けた専用の鍵。
• すべての確認が無効になっている。 初日はクリックの手間が省けますが、いずれサーバーを 1 台失うことになります。解決策：読み取り専用のコマンドには許可リスト、介入的な操作にはすべて承認。
• 変更前にバックアップを取っていない。 解決策：バックアップと切り戻しスクリプトを、CLAUDE.md または AGENTS.md の固定ルールにする。
• バックアップがドキュメントルート内にある。 ドキュメントルートにある config.php.bak のようなファイルは、データベースのパスワードごと外部から取得できてしまう可能性があります。解決策：ドキュメントルートの外に、権限 700 のバックアップフォルダーを置く。
• プロンプトに秘密情報を入れている。 解決策：認証情報はスクリプトが読み込む権限 600 のファイルにだけ置き、うっかり漏らしたらすぐに再発行する。
• 二重実行。 ダブルクリックや再送されたリクエストで、2 回注文されてしまいます。解決策：flock によるロック、または Idempotency-Key。
• コントロールパネルが管理するファイルを直接変更している。 パネルは次のアップデートでそのファイルを上書きするか、そのファイルが原因で動作しなくなります。解決策：そうしたファイルをルールで対象外にし、変更はパネルかその API を通じて行う。
• 出力を確認せずに受け入れている。 出力を理解できないエージェントは推測します。解決策：根拠を求め（「そのログ行を見せて」）、結果を本番環境で確認させる。

まとめ

• AI をサーバーに接続するとは、Claude Code、Codex CLI、Gemini CLI のようなエージェントに、専用の SSH 鍵と明確なルールを与えることです。
• エージェントはログを読み、変更を適用し、結果を確認して記録します。介入的なステップは承認があるときだけ実行されます。
• デプロイはすべて決まった手順に従います：現状の確認、バックアップ、切り戻し手順の準備、構文チェック、適用、テスト、本番環境での確認、記録。
• 秘密情報は決してチャットに入れず、費用が発生する操作には二重実行を防ぐロックが必要です。
• サーバーに必要なのは、ルート権限、SSH 鍵、自由な外向き接続、DDoS 対策で、GPU は不要です。
• KernelHost のサーバーは、PrePaid で契約の縛りもなく、最初からすべての要件を満たしています。さらに KernelHost API を使えば、エージェントがサーバーを自ら注文し、制御することもできます。