AI SRE と AI DevOps の実践：PandaSi で Agent に複数サーバーを一元管理させる

PandaSi で Agent に複数サーバーを一元管理させるには、承認済みの管理マシン 1 台から始められます。管理マシンで PandaPaw と Agent を実行し、Agent が既存の SSH、VPN、踏み台ホスト経由で明確なリスト上の対象へアクセスし、1 台ずつ身元を確認し、複数台を読み取り専用で巡回点検して結果を集約します。変更が必要な場合は、まず 1 台で試行し、承認に従ってバッチ単位で進めます。AI SRE は信頼性問題の調査に重点を置き、AI DevOps はデリバリーとインフラ変更に重点を置きます。どちらにも再確認可能な証拠と権限の境界が必要です。

PandaSi はデバイスをまたぐセッションと承認の入口を提供し、PandaPaw は実行マシンに接続します。具体的なコマンドは選択した Agent とそのツールが実行します。接続完了は、会社のサーバー権限を得たことでも、24 時間監視、自動アラート受信、無人復旧システムを導入済みであることでもありません。以下では、すでにサーバー運用権限を持ち、スマートフォンや別の PC から作業を追跡したい開発者・運用担当者を対象に、管理マシンの接続、複数マシンの読み取り専用検証、結果の集約、バッチ単位の変更という流れを扱います。各サーバーに直接インストールする方法もありますが、本記事の複数マシンの主線は管理マシン方式を採用します。

AI SRE と AI DevOps：それぞれ Agent に何を任せるか？

この 2 つの言葉が示す作業範囲には重なりがあります。本記事では、それぞれ別々に購入しなければならない 2 つの製品としてではなく、以下の役割分担として理解します。

例えば、テストサービスがリリース直後に 502 を返した場合、どの層でリクエストが失敗したかを調査するのは AI SRE 寄りです。問題を起こしたリリース設定をレビューし、次のデリバリーを準備するのは AI DevOps 寄りです。同じ Agent セッションで両方の作業を完結できますが、鍵はタスク範囲、ツール権限、受け入れ条件にあります。

ステップ 1：実行場所を選び、会社の承認を得る

インストール前に、次の 3 点を明確にします。どのマシンへの接続を許可するか、どのシステムユーザーで実行するか、どのディレクトリとサービスへのアクセスを許可するかです。ログやコードを外部モデルへ送信してよいかどうかも、接続前に確認します。個人が SSH でログインできることは、個人アカウントをリモート Agent に紐付けることを会社が承認したことを意味しません。

パス A：サーバー上で直接実行する。 会社の承認が、ユーザーレベルの Agent サービスだけでなく、デフォルトのインストール手順が関与するデバイス相互接続とネットワークサービスの変更にも及ぶことを確認します。現在のインストールスクリプトは、該当する systemd ホストで sudo を呼び出し、システムレベルのネットワークサービスを登録する可能性があります。インストール、権限昇格、ネットワーク変更についてそれぞれ承認を得て、ホストが現在のサポート条件を満たしていることを確認したうえで、サーバーに PandaPaw をインストールします。その後選択する作業ディレクトリ、shell、ツールは、すべてこの実行マシンに属します。「操作が便利だから」という理由で root を既定にしないでください。

パス B：承認済みの管理マシンからサーバーへ入る。 サーバーへのインストールが許可されていない場合は、PandaPaw を会社が承認した管理マシンにインストールし、Agent もそこで実行します。管理マシンは、会社が認める SSH、VPN、踏み台ホスト経由で対象サーバーに到達でき、対応するアカウント権限を持っている必要があります。Agent はこの既存の経路を呼び出します。PandaSi がアクセスを代わりに承認したり、踏み台ホストを回避したり、社内ネットワークを自動で開通させたりすることはありません。

2 つのパスで最も混同しやすいのは「現在のマシン」です。管理マシン方式では、Agent が既定で pwd を 1 回実行したときに表示されるのは管理マシンのディレクトリです。SSH 経由で明示的に実行したコマンドだけが対象サーバー上で発生します。セッションにサーバー名が表示されても、身元確認の代わりにはなりません。

ステップ 2：実行マシンに PandaPaw をインストールする

PandaSi からワークスペースに入り、ログイン後にデバイスページ /devices?add=1 を開きます。デバイスの追加を選択し、現在の OS 向けにページが生成したワンタイムインストールコマンドをコピーします。既定のインストールにはデバイス相互接続の設定が含まれ、権限昇格を要求したり、システムのネットワークサービスを変更したりする可能性があります。まず会社の管理者にインストール内容をレビューしてもらい、対応する権限を承認してもらってから、前の手順で選んだ実行マシンでコマンドを実行します。ユーザーレベルの接続だけが承認され、デバイス相互接続が承認されていない場合は、本記事の既定のインストールコマンドを直接実行せず、管理者と承認済みのインストール方式を確認してください。入口やブランドの文言はバージョンによって変わるため、現在のワークスペース表示に従います。関連するホスト側の手順は クイックスタート も参照してください。

ワンタイムコマンドにはデバイスのペアリング資格情報が含まれます。会話、チケット、公開スクリプト、スクリーンショットに貼り付けないでください。同じコマンドを複数のマシンへの接続に再利用しないでください。使用済みまたは期限切れの場合は、デバイスページから再取得します。

ワンタイム資格情報を含むコマンドを使わない場合、macOS / Linux の基本インストール入口は次のとおりです：

curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh

これはインストールスクリプトをダウンロードして実行します。会社のソフトウェアインストールとスクリプトレビューのプロセスに従ってください。今回の確認は現在のドキュメントとソースコードに基づくもので、クリーンなホストでのインストールとペアリングの実測は完了していません。公開インストールスクリプトのダウンロード入口にはアクセスできることを確認済みです。ホストプラットフォームの互換性とインストールの詳細は PandaPaw ホストガイド を参照してください。

基本インストールのアカウント承認が完了していない場合は、実行マシンで続けて次を実行します：

pandapaw login

表示されるデバイス承認フローに従ってペアリングを完了し、次を確認します：

pandapaw status

コマンドが見つからない場合は、まず新しいターミナルを開き、shell に PATH を再読み込みさせます。「試しに」という理由でインストールを繰り返したり、強制的に再ログインしたりしないでください。まず、バイナリが見つからない、アカウントが紐付いていない、バックグラウンドサービスが異常である、という 3 つの状況を切り分けます。

ステップ 3：マシン、エンジン、作業ディレクトリを選択する

ワークスペースの /agent を開き、接続したばかりの実行マシンを選択します。次に Claude Code、Codex、PandaCode のいずれか、および使用を承認された作業ディレクトリを選択します。最初はテスト用ディレクトリで検証し、いきなり本番設定ディレクトリに入らないようにします。

デバイスのペアリングとモデルへのログインは別の作業です。 PandaPaw へのログインは、ホストとワークスペースのアカウントが接続されたことを示します。選択したエンジンには、引き続き有効なモデル承認、サブスクリプション、または API 設定が必要です。デバイスがオンラインなのにモデルから応答がない場合は、まずエンジンのログイン表示、クォータ、モデル設定を確認します。PandaPaw の再インストールだけに頼ってはいけません。

同時に、エンジンのツール権限設定を確認します。チャットに「まず変更しないで」と書くのはタスク上の制約であり、OS の権限やエンジンの承認メカニズムの代わりにはなりません。都度承認が必要な場合は、対応する権限モードを設定し、すべてのコマンドで確認カードが自動的に表示されると仮定しないでください。

ステップ 4：まず読み取り専用のリクエストで身元を確認する

最初のタスクに「サーバーを直して」と書かず、まず次を送ります：

身元確認のみを行い、ファイルやサービスは変更しないでください。現在のホスト名、システムユーザー、作業ディレクトリの絶対パスを報告し、ディレクトリ直下のファイル名を一覧表示してください。.env、秘密鍵、その他の資格情報は読まないでください。対象サーバーへのアクセスが必要な場合は、現在の実行マシンと対象の違いを先に説明し、私が確認してから続行してください。

Linux / macOS で使える身元確認コマンドは次のとおりです：

hostname
id -un
pwd

戻り値は期待値と項目ごとに照合します。同じ実行マシンか、承認されたアカウントか、正しいプロジェクトディレクトリか、を確認します。ディレクトリ名が似ていること、デバイスがオンラインであること、コマンドの終了コードが 0 であることは、いずれも単独では接続が正しいことを証明しません。

管理マシン方式では、両端をそれぞれ確認する必要があります。以下では、会社ですでに設定済みの SSH エイリアスを使う例だけを示します。company-test-server は例であり、管理者が確認した対象に置き換えてください：

ssh company-test-server 'hostname; id -un; pwd'

初回接続のプロンプトを解決するためにホスト鍵の検証を無効にしないでください。SSH パスワードや秘密鍵を Agent に貼り付けないでください。リモートの pwd はアカウントのホームディレクトリである可能性があり、これだけでプロジェクトが選択済みだと仮定してはいけません。後続のコマンドでは、リモートプロジェクトの絶対パスを明示します。

合格基準は、応答内容が正しいホスト、身元、ディレクトリに対応していること、何が実行されたかを確認できること、権限確認が現在の権限モードで期待どおりに表示されることです。その後、スマートフォンまたは別のクライアントから同じセッションに再入し、履歴が復元できるか確認します。これはオンラインの緑色の点だけを見るより、実際の利用経路に近い確認です。

ステップ 5：まずサーバー一覧を作成し、その後で複数マシンを読み取り専用で巡回点検する

1 台の管理マシン上の Agent は、既存の SSH を呼び出し、一覧にある複数のサーバーへ順番にアクセスできます。PandaSi を使うと、同じセッションでこれらのツール操作と結果を追跡できます。ここでの「一元管理」は、同じ実行入口、明確な一覧、統一されたレポートから生まれるものであり、製品にサーバー資産の検出、接続をまたぐ自動ディスパッチ、ワンクリックの一括制御 UI が標準搭載されているという意味ではありません。管理マシンは各対象についてすでに承認を得ている必要があり、1 台にアクセスできるからといって、同じネットワークセグメントの他のマシンにもアクセスできると推定してはいけません。

エイリアスと環境グループで対象を固定する

管理者に、資格情報を含まない一覧を維持してもらいます。以下の名称はすべて架空の例です。実際の一覧は会社が承認した場所に保存し、パスワード、秘密鍵、ワンタイムのデバイスコマンドを含めないでください。

SSH エイリアスは管理マシンの既存 SSH 設定内の名前であり、PandaSi のデバイス名ではありません。管理者が、エイリアスに対応する対象、アカウント、ポート、必要なアクセス中継を確認します。名前に test が含まれるというだけでテスト機だと確認してはいけません。OpenSSH は Host エントリによる設定のマッチングをサポートし、コマンドラインで指定したリモートコマンドは対象ホストで実行されます。詳細は SSH クライアント設定マニュアル と SSH コマンドマニュアル を参照してください。

各サーバーに PandaPaw を個別インストールした場合は、ワークスペースで対応する実行マシンを選択し、1 台ずつ操作することもできます。ただし「複数のマシンがすべてオンライン」を、1 つのセッションがすべての接続を自動スケジュールするという意味に解釈しないでください。本記事の以降では、管理マシンから既存の SSH を使う方式に統一し、2 つの実行位置が 1 つのレポートに混在するのを避けます。

まず直列で身元を確認し、その後で点検項目を限定する

最初は一覧に従って 1 台ずつ身元確認を行い、アプリケーション設定や完全なログは読み取りません。以下は管理マシンの Bash による直列実行の例で、今回許可されたテスト機 2 台だけを列挙しています。自動の環境識別は行わず、想定身元の人手による照合の代わりにもなりません。

for target in test-web-01 test-worker-01; do
  printf '\nTARGET %s\n' "$target"
  if ssh -T -o BatchMode=yes -o ConnectTimeout=5 "$target" \
    'hostname && id -un && pwd'; then
    printf 'IDENTITY_COMMAND_COMPLETED %s\n' "$target"
  else
    result=$?
    printf 'IDENTITY_COMMAND_FAILED %s exit=%s\n' "$target" "$result" >&2
  fi
done

これらのコマンドは構成方法を説明するためのものにすぎず、本記事ではこの 2 台の例示ホスト上で実行していません。BatchMode=yes は認証失敗時に対話入力を待たないようにします。ConnectTimeout=5 は接続確立段階を制限するものであり、リモートコマンド全体の総タイムアウトではありません。実行全体のタイムアウトは、別途、承認されたツールまたはタスク実行基盤で設定してください。バッチ実行のためにホスト鍵の検証を無効にしないでください。対話型 MFA が必要な踏み台ホストでは、会社が承認したアクセスフローを使い、この非対話の例をそのまま適用しないでください。

コマンド完了後、まず一覧にある想定ホスト名とアカウントを 1 台ずつ照合し、次に承認済みのリモートプロジェクトパスを確認します。上記で出力される pwd は通常、リモートのログインディレクトリにすぎず、プロジェクトパスが正しいことの証明ではありません。コマンドの終了コードが 0 であることは、これらのコマンドが完了したことだけを示し、ホストの身元が一致したことや、まして業務が健全であることを示すものではありません。1 台でも身元が一致しなければ、その対象をブロック状態とし、業務データの読み取りを続けません。同じ環境またはアクセス経路に共通の疑いが出た場合は、バッチ全体の確認を一時停止します。

身元確認が通ったら、次に Agent に今回のテスト機で同じ承認済みの読み取り専用チェックを実行させます。指定サービスの状態、想定リッスンポート、ディスクの空き容量、指定時間枠内のマスク済みエラー概要、および承認済みのヘルスリクエスト 1 件です。「巡回点検」から拡張して、プローブのインストール、すべてのディレクトリの再帰読み取り、自動修復を行わないでください。OS、サービス管理システム、アプリケーションごとにチェックコマンドは異なるため、一覧に合わせて補足し、1 つのコマンドをすべてのホストに無理に適用しないでください。

1 つのプロンプトで実行境界を明確にする

あなたは管理マシン上で実行されています。承認済みサーバー一覧のうち、test グループの test-web-01、test-worker-01 にのみアクセスし、新しいアドレスをスキャンせず、production グループにはアクセスしないでください。まず各ホストのホスト名、ユーザー、リモートプロジェクトの絶対パスを直列で照合し、一覧と一致しなければその対象をブロックしてください。合格後は、一覧で明示的に承認されたサービスの状態、ポート、ディスク、ヘルスリクエストのみを確認してください。ログは指定時間枠のマスク済み断片だけを取得します。初回は全工程を直列で行い、設定変更、再起動、依存関係のインストール、自動的な権限昇格を行わないでください。1 台の接続失敗ではエラーを保持し、他の確認済み対象の独立した読み取り専用チェックを続けてください。環境の所属や共通アクセス経路に異常があれば、バッチ全体を一時停止してください。各マシンごとに時刻とタイムゾーン、コマンド、終了状態、主要な証拠、未完了項目を記録し、最後にサーバー別に集約してください。修復が必要な場合は別途提案し、実行しないでください。

これはタスク上の制約であり、読み取り専用アカウント、エンジンのツール承認、ネットワークアクセス制限と組み合わせる必要があります。「変更禁止」とプロンプトに書いても、書き込み可能なアカウントが自動的に読み取り専用アカウントになるわけではありません。

同時実行数を制限し、失敗を該当対象にとどめる

初回の巡回点検は直列のほうが照合しやすくなります。対象が多い場合は、会社が許可するツール実行方式の範囲で、小さな同時実行上限を設定できます。たとえば同時に最大 2 台までチェックする、といった設定です。ここでの「2 台」は例示的な運用予算であり、PandaSi の製品上限や性能保証ではありません。選択した Agent またはツールが同時実行数を確実に制限できない場合は、直列を続け、一時的な無制限のバックグラウンドタスクで代用しないでください。

各チェックには独立したタイムアウトと結果記録を設定します。1 つの対象の失敗で、他のマシンの再起動、再インストール、バッチ全体の無限リトライを引き起こしてはいけません。接続タイムアウト、身元不一致、権限不足、チェックコマンド失敗をそれぞれ記録し、「オフライン」に一律にまとめないでください。エラーが共用の踏み台ホスト、認証元、不明な環境の所属に由来する場合は、同時実行数を増やし続けるのではなく、いったん止めて共通原因を確認します。

集約表には、1 台ずつ身元が一致したか、どのチェックを実際に実行したか、主要な証拠、不明項目を記載する必要があります。以下は記録形式だけを示すもので、表内の文言は記入説明であり、実測結果ではありません：

レポートには「何台をチェック予定で、何台完了し、何台失敗し、何台スキップしたか」を記載し、各対象の証拠を示します。結果がない場合に健全とみなしてはいけません。バッチコマンドの最終終了コードが 0 であっても、途中でいずれかのマシンがすでに失敗したことを覆い隠すことはできません。

ステップ 6：まず 1 台のテストサービスで 502 調査と復旧を最後まで行う

以下は教育用の例であり、本記事で実際に発生した事故でも、すべてのサーバーにそのままコピーできる修復コマンド一式でもありません。承認済みのテストサービスがリリース後に 502 を返し、テストドメイン、サービス名、プロジェクトディレクトリをすでに把握していると仮定します。

まず調査範囲を限定する

テストサービスのリリース後に発生した 502 を調査してください。まず対象ホスト、ユーザー、ディレクトリを確認し、直近のリリース記録、関連サービスの状態、リッスンポート、指定時間枠のプロキシログとアプリケーションログを読み取り専用で確認してください。再起動、設定変更、依存関係のインストール、他の環境へのアクセスは行わないでください。今回の障害に関連するマスク済み断片だけを返し、証拠、考えられる原因、不足している情報を列挙してください。

時間枠と明確なログ取得元を先に指定し、Agent がサーバー全体を再帰的に調べ尽くすのを避けます。読み取り専用でもデータ漏えいは起こり得ます。ログ内のトークン、顧客情報、リクエスト本文は、モデルのコンテキストに入る前にフィルタリングする必要があり、送信後にモデルに「忘れさせる」ものではありません。

502 はプロキシが利用可能な上流応答を得られなかったことを示しますが、ステータスコードだけでは、プロセス終了、ポート不一致、依存関係の異常、接続問題のどれかを判断できません。Agent に、プロキシの上流アドレス、実際のリッスン状態、同一時間帯のログを突き合わせさせます。マシンをまたぐログは先にタイムゾーンを統一します。「マシンがオンライン」を「アプリケーションが健全」とみなさず、一致するログがないことをそのまま「エラーが発生していない」とみなしてもいけません。

レビュー可能な修復提案を求める

証拠が「リリース設定の上流ポートと実際のリッスン状態が一致していない」ことを支持する場合、Agent に具体的なファイルと最小差分、実行予定コマンド、影響を受けるテストサービス、設定チェック方法、ロールバック条件を提出させます。これはあくまで条件付きの例であり、証拠が支持しない場合は調査を続けます。

承認の対象は具体的な変更 1 件であるべきで、「すべて任せる」ではありません。たとえば、指定したテストプロキシ設定の変更を承認し、設定チェックが通った後にそのテストプロキシを再読み込みする、といったものです。ついでに依存関係をアップグレードしたり、データベースをクリーンアップしたり、本番設定を変更したり、ホスト全体を再起動したりしてはいけません。実際のコマンドは、使用しているプロセス管理システムとデプロイ制度に基づいて決める必要があります。

実行後にユーザー経路を検証する

承認後に実行したら、受け入れ確認では少なくとも次をカバーします。設定チェックが通ったか、関連プロセスとポートが想定どおりか、ヘルスエンドポイントが正常か、独立したクライアントから元の入口経由で実際のテストリクエストを送信して復旧したか。ヘルスエンドポイントが 200 でも、業務ルーティング、認証、データベースリクエストが依然として失敗している場合は、「問題解決済み」と書いてはいけません。

最後に Agent に、実行済みコマンド、実際の変更、検証結果、残存リスクを集約させます。検証していない項目は不明と明記します。確認済みの原因と再発防止策は会社の記録システムに戻します。調査段階では AI SRE の支援を行い、その後修正を設定リポジトリとリリースプロセスに組み込むことで AI DevOps に広がります。

ステップ 7：1 台で合格した後、他のサーバーをバッチ単位で変更する

複数マシンの巡回点検とバッチ変更の承認は分けるべきです。複数のサービスでバージョン不一致が見つかっても、それらをすべて直接アップグレードしてよいわけではありません。同じ名前のサービスでも、異なる役割を担ったり、異なる設定を使ったりする可能性があります。まず差異が想定どおりか確認し、その後、対象ごとに項目を列挙した変更計画を提出します。

最初のバッチでは、明確なテスト機 1 台だけを選びます。計画には、対象エイリアス、確認済みのホスト身元、元のバージョンまたは設定、変更予定差分、想定影響、チェック方法、ロールバック手順、停止条件を固定します。承認後にこの 1 台を実行し、ヘルスエンドポイントと実際のユーザー経路の受け入れ確認を待ちます。復旧を証明する証拠がなければ、状態を成功として次のバッチに進むことはできません。

試行が通った後で、次のバッチの対象リスト、バッチサイズ、同時実行上限を明確にします。「残りのすべてのマシン」のように、一覧の変化に伴って変わる暗黙の範囲を使ってはいけません。各バッチ終了時に実際のバージョンとリクエスト結果を確認し、成功、失敗、未実行の対象を記録します。身元不一致、設定チェック失敗、業務リクエストの劣化、ロールバック失敗が発生した場合は後続バッチを停止し、証拠を保持して責任者に渡します。テスト段階の承認を本番の承認と取り違えないでください。

ロールバックもマシンごとに定義します。設定変更は承認済みの方法で以前の設定に戻せます。データベース移行、データ書き込み、外部システムへの副作用を伴う場合は、「旧バージョンに戻す」だけで影響を取り消せると仮定せず、先に責任者が復旧方針を決めます。実際に変更し、復旧が必要な対象だけをロールバックし、グループ全体に無差別に逆方向コマンドを実行してはいけません。

次のタスクは次のように書けます：

今回のマシン別巡回点検の証拠に基づき、まず test-web-01 についてのみ修復計画を提案し、実行しないでください。確認済みのホスト身元、具体的な差分、完全なコマンド、影響、ロールバック手順、受け入れリクエスト、停止条件を列挙してください。この 1 台について明確な承認を得てから実行できます。完了後は実際の証拠を示し、次のバッチ対象の承認を待ってください。未承認のマシンは未実行のままにしてください。production グループは今回の範囲外であり、テストの承認を継承できません。

テストと本番の両方を処理する必要がある場合、本番は別途、会社の変更プロセスに従います。管理入口が統一されても、環境分離、メンテナンスウィンドウ、リリース承認、監査要件がなくなるわけではありません。

スマートフォンが切断された後は、まずタスク状態を確認する

クライアントを閉じたこと、スマートフォンがバックグラウンドに移動したこと、ネットワークが切断されたことを、リモートコマンドが停止したと解釈してはいけません。実行マシン上のプロセスは動き続けている可能性があります。ホストの切断、エンジンの終了、リモート経路の制限によって失敗している可能性もあります。元のセッションに戻ったら、まずツール結果を見て、次にプロセス、成果物、サービス状態を確認し、インストール、リリース、移行を重複して開始するのを避けます。

リモートコマンド経路では「終了状態が返らない」ことがあります。接続層のタイムアウトは、コマンドが開始されていないことを示すものではありません。長時間タスクでは、会社の実行経路でタイムアウト、状態記録、キャンセル方法を明確にします。特に複数回の SSH ホップを伴う場合に重要です。本記事では、あるバージョンの経路タイムアウト値を、すべての SSH ツールに共通するルールとして扱いません。

停止が必要な場合は、明確な停止操作を使い、リモートの実行状態を確認します。状態が不明な非冪等変更に遭遇した場合は、まず人が引き継いで確認します。繰り返しクリックしたり、同じ指示をもう一度送ったりして、前回が成功したか判断しないでください。

会社と家庭のデバイス相互接続は、本記事とどう関係するか？

本記事は、管理マシンから各サーバーへの承認済みアクセス経路がすでに存在することを前提とし、Agent が対象ごとに作業をどう整理するかに焦点を当てます。会社と家庭の複数デバイスをどうネットワークに参加させ、相互アクセスさせ、ネットワーク境界をどう扱うかは別の接続タスクであり、ここでは混ぜて書きません。接続に成功しても、その中のすべてのデバイスを運用する権利があるわけではありません。デバイス接続を知りたい場合は、既存の デバイス相互接続の説明 を先に参照し、会社のネットワーク承認プロセスに従ってください。

会社データ、モデル、中継の境界

「ツールがローカルマシンで実行される」は実行位置を説明するものであり、データが永遠に会社の外に出ないことを約束するものではありません。セッションメッセージと承認は製品の通信経路を通ります。Agent に提供するログ、コード、ツール出力も、選択したモデルプロバイダーのリクエストに入る可能性があります。接続前に、会社が承認したモデル、データ処理の取り決め、ログ保持とアクセスポリシーを確認します。

既存の鍵管理と監査プロセスを維持し、資格情報は実行マシンの承認済み資格情報基盤から読み取ります。会話やコードリポジトリに貼り付けないでください。実行アカウントとネットワーク到達範囲を制限し、必要に応じてログとディレクトリの権限を付与します。退職、デバイス廃棄、権限変更の際は、ワークスペースのデバイス承認、実行マシンのアカウント、対象サーバーのアクセス権を同時に処理します。クライアントを 1 つ削除することは、すべての実行権限を取り消すことと同じではありません。

FAQ

PandaSi は自動で当番対応し、アラートを受信して本番を修復できますか？

本記事はリモートセッション、承認済み操作、人手による追跡の流れを扱います。24 時間監視、アラート連携、自動トリガー、無人復旧には、追加の監視システム、トリガー、ランブック、権限ガバナンスが必要であり、接続成功からこれらの能力がすでに備わっていると推論することはできません。

会社のサーバーにソフトウェアをインストールできない場合でも使えますか？

承認済みの管理マシン方式を検討できます。ただし、管理マシンが対象への正当なネットワークアクセスと身元権限をすでに持っていることが前提です。会社がこの種の外部 Agent 接続も禁止している場合は、隠れた接続経路に切り替えるのではなく、先に承認を得る必要があります。

サーバーにパブリック SSH ポートを開放する必要がありますか？

PandaPaw のセッション接続は両側から能動的にアウトバウンド接続を確立するため、通常、クライアント接続のために新たにパブリックのインバウンドポートを追加する必要はありません。ただし、管理マシンから対象サーバーへの会社が認めるアクセス経路は引き続き必要です。アウトバウンドが制限されている場合は、ネットワーク管理者が設定し、自分で防御を無効にしないでください。

すべてのサーバーに PandaPaw をインストールする必要がありますか？

本記事の管理マシン方式では、すべての SSH 対象に PandaPaw をインストールする必要はありませんが、管理マシンには承認済みのネットワーク経路とリモートアカウントが必要です。直接インストール方式では、対応するホストで Agent を実行し、それぞれ接続します。両者を同じ自動一括制御機能と混同しないでください。

1 台の巡回点検が失敗しても、他のマシンは続行できますか？

身元が確認済みで相互に独立した読み取り専用チェックであれば、その対象の失敗証拠を保持したうえで他の対象を続行できます。共通のアクセス障害や環境の所属の疑いがある場合は、バッチ全体を一時停止します。変更段階では承認済みの停止条件に従い、「巡回点検は続行可能」というルールを適用してはいけません。

接続後に最初に何を受け入れ確認しますか？

まず管理マシン、モデル応答、セッション復元を確認し、次に一覧に従って対象の身元、ディレクトリ、権限を 1 台ずつ照合し、読み取り専用の巡回点検と結果集約を完了します。最後に 1 台のテストサービスで承認、実際のリクエストの受け入れ確認、後続のバッチ処理の流れを通します。接続の価値は、承認済みタスクを継続的に追跡できることにあります。より多くのサービスへ拡大するかどうかは、今回の受け入れ確認の証拠で判断します。

資料と確認範囲

本記事の初稿は 2026 年 10 月 31 日に、プロジェクトのクイックスタート、PandaPaw ホストドキュメント、デバイスインストールコマンドの生成ロジック、公開インストールスクリプトのダウンロード入口を確認しました。11 月 1 日に複数マシンの操作フローを補足し、OpenSSH 公式マニュアルと照合して SSH 設定とパラメーターの意味を確認しました。今回の確認は現在のドキュメントとソースコードに基づくものであり、クリーンなホストでのインストールとペアリングの実測は完了しておらず、実際の複数マシン環境で本記事の巡回点検、バッチ変更、502 の例を実行してもいません。各社のネットワーク、エンジン承認、データコンプライアンスは、自社のテスト環境で受け入れ確認する必要があります。掲載画像はすべて AI 生成の概念図またはフロー示意であり、画面のスクリーンショットではありません。