「このサーバーを構築した人は、もう会社にいない」
「何年も動いているけれど、設計書が見当たらない」
「再起動してよいサービスも、設定変更の影響範囲も分からない」
古いサーバーの保守を引き継ぐと、こうした状況によく出会います。稼働しているという事実だけは分かるものの、OSの設定、ミドルウェア、定期処理、バックアップ、ファイアウォール、アプリケーションの起動方法が複雑に絡み合い、サーバーそのものが唯一のドキュメントになっています。
このような環境でも、Codexを使うと、サーバー情報の収集、調査ログの整理、構成ドキュメントの作成、Ansible Playbookのたたき台作成までを、一連の作業として進められます。
もちろん、AIに本番サーバーを無条件で操作させるという話ではありません。管理者の許可、適切な接続経路、人によるレビューを前提に、Codexを「調査とコード化を手伝うエンジニア」として使う方法です。
本記事のコマンドや設定値は一般化しています。実在するIPアドレス、ホスト名、ユーザー名、ドメイン、秘密鍵、パスワード、トークンなどは掲載しません。
引き継ぎで本当に困るのは「分からないことが分からない」こと
ドキュメントがないサーバーでは、最初から正しい質問を並べることさえ難しいものです。
- どのポートが外部公開されているのか
- Webサーバーの転送先は何か
- アプリケーションはsystemd、コンテナ、手動起動のどれか
- データベースはローカルか外部サービスか
- バックアップはいつ、どこへ保存されるのか
- 証明書はどう更新されているのか
- 再起動後に自動復旧するのか
- 独自スクリプトやcronが残っていないか
人間が一つずつ調べることもできますが、確認項目の漏れ、ログの転記、設定間の関連付けには時間がかかります。Codexは、調査項目を組み立て、取得結果を分類し、文書とコードへ変換する部分で特に役立ちます。
今回Codexに任せる範囲
大まかな作業は次のとおりです。
- 作業端末の接続環境を整える
- Ansibleで対象サーバーへの疎通を確認する
- 読み取り専用の監査スクリプトとPlaybookを作る
- 実行中のプロセスをログとして表示・保存する
- 取得した情報を構成説明書へまとめる
- 現状を再現するAnsible Playbookのたたき台を作る
- 秘密情報を除外してGitで管理する
ここで重要なのは、「調査」と「変更」を別のフェーズにすることです。最初の段階ではサービスを再起動せず、設定ファイルを書き換えず、パッケージも更新しません。
1. 安全な接続経路を用意する
対象サーバーが社内ネットワークにある場合は、組織で許可されたVPNや踏み台サーバーを使います。Codexには、利用するOS、接続方式、対象ホストのグループ名などを伝え、接続確認までを依頼できます。
たとえば、次のように依頼します。
WSL上のLinux環境から、許可されたVPN経由で対象サーバーへ接続します。
秘密鍵やパスフレーズの内容は表示・削除せず、Ansibleの疎通確認を行ってください。
実行した処理と結果は、秘密情報を伏せて報告してください。
パスワードや鍵の内容をチャットへ貼り付ける必要はありません。秘密値はユーザー自身が対話入力するか、SSH Agentや安全なローカルファイル、シークレット管理サービスを利用します。
2. Ansibleのpingで管理経路を確認する
インベントリには、対象環境に応じたホストを定義します。
[legacy_servers]
legacy-01 ansible_host=<SERVER_ADDRESS> ansible_user=<SSH_USER>
そのうえで、Ansibleから接続できるか確認します。
ansible legacy_servers -m ping -i inventory.ini \
--private-key /secure/path/id_ed25519
Ansibleのpingモジュールは、単にネットワーク応答を見るものではありません。SSHログイン後、対象サーバー上でAnsibleモジュールを実行できるところまで確認します。
失敗した場合も、CodexはDNS、経路、VPN、SSH鍵の権限、ユーザー名、Python実行環境など、原因を段階的に切り分けられます。設定をむやみに変更する前に、読み取り可能な情報から原因を絞り込めるのが便利です。
3. 読み取り専用の監査処理を作る
疎通が確認できたら、現在の構成を調べます。Codexには、対象サーバーを変更しない監査処理を作るよう明示します。
対象サーバーの現在の構成を確認する、読み取り専用の監査Playbookを作成してください。
OS、ネットワーク、待受ポート、ファイアウォール、systemd、Webサーバー、
データベース、コンテナ、cron、バックアップ、SSH、SELinuxを確認します。
サービスの再起動、パッケージ更新、設定変更は行わないでください。
秘密値は出力せず、実行途中の処理が分かるログを表示してください。
監査用タスクでは、changed_when: falseを指定すると、読み取り処理であることが明確になります。
- name: Collect enabled services
ansible.builtin.command: systemctl list-unit-files --state=enabled
register: enabled_services
changed_when: false
- name: Display enabled service names
ansible.builtin.debug:
var: enabled_services.stdout_lines
調査項目の例は次のとおりです。
- OS、カーネル、仮想化方式、タイムゾーン
- IPアドレス、ルーティング、DNS設定
- 待受ポートとファイアウォールルール
- インストール済みパッケージ
- 有効化・稼働中のsystemdサービス
- Webサーバーの仮想ホストとリバースプロキシ
- データベースとキャッシュサービス
- コンテナ、イメージ、永続化ディレクトリ
- cron、systemd timer、バックアップスクリプト
- SSH認証、sudo、SELinux
本番サーバーでは、巨大なディレクトリの再帰検索や、データベース全体のダンプなど、負荷の高い調査は避けます。まずは設定の所在とサービス間の関係を把握することが目的です。
4. 実行過程をログに残す。ただし秘密値は残さない
担当者不在の環境では、最終結果だけでなく、「何を確認したか」という調査記録も重要です。Ansibleの詳細度を上げると、タスクの進行や失敗箇所を確認できます。
ansible-playbook -i inventory.ini audit.yml -v
ただし、ログは新たな情報漏えい源にもなります。以下は記録しないようにします。
- SSH秘密鍵とパスフレーズ
- パスワード、APIキー、アクセストークン
- TLS秘密鍵
- 接続文字列に含まれる認証情報
- コンテナ環境変数の秘密値
- 顧客情報や業務データ
秘密値を扱う可能性があるAnsibleタスクにはno_log: trueを設定します。設定ファイルは全文を表示せず、必要な項目だけ抽出して値をマスクします。
監査ログもGitの管理対象外にします。
logs/
.ansible/
*.retry
group_vars/all.yml
*.key
5. 取得結果から構成説明書を作る
コマンド出力を保存しただけでは、後任者が理解できるドキュメントにはなりません。Codexには、結果をサービスの役割ごとに整理させます。
監査結果をもとに、後任エンジニア向けのMarkdown文書を作ってください。
システム概要、ネットワーク、公開ポート、Web、データベース、コンテナ、
監視、バックアップ、起動順序、既知のリスクに分けて説明してください。
観測した事実と推奨改善事項は混同せず、秘密情報と実データは掲載しないでください。
「観測した事実」と「推奨する状態」を分けるのがポイントです。
たとえば、現在のサーバーでセキュリティ機構が無効になっていたとしても、それを正しい設定として記述すべきではありません。現状欄には事実を書き、改善欄には影響、移行手順、検証方法を記載します。
また、サービス同士の関係も文章にします。
利用者
↓ HTTPS
Webサーバー
↓ リバースプロキシ
アプリケーションコンテナ
↓
データベース／キャッシュ
このレベルまで整理されると、障害対応や移行計画で参照できる資料になります。
6. 現状をAnsible Playbookへ変換する
文書化した構成をもとに、CodexへPlaybookの作成を依頼します。
確認したサーバー構成を再現するAnsible Playbookを作成してください。
専用モジュールを優先し、繰り返し実行しても不要な変更が発生しないようにします。
ネットワーク、SSH、証明書発行、データベース権限、コンテナ置換など、
停止や切断につながる処理は既定で無効にしてください。
秘密値はAnsible Vault変数として参照し、Playbookへ直書きしないでください。
生成するプロジェクトは、たとえば次のように整理できます。
ansible-project/
├── inventory.ini
├── audit.yml
├── site.yml
├── group_vars/
│ └── all.yml.example
├── templates/
├── README.md
└── SERVER_CONFIGURATION.md
パッケージ管理、設定配置、サービス管理には、それぞれAnsibleの専用モジュールを使います。
- name: Install required packages
ansible.builtin.dnf:
name:
- nginx
- firewalld
state: present
- name: Deploy application configuration
ansible.builtin.template:
src: app.conf.j2
dest: /etc/example/app.conf
owner: root
group: root
mode: "0640"
notify: Restart application
ネットワーク設定や本番サービスの置換は、変数やタグで明示的に有効化する設計にします。通常実行で触れないことが大切です。
7. 適用前に人間がレビューする
CodexがPlaybookを作れても、そのまま本番へ適用するべきではありません。まず構文を確認します。
ansible-playbook -i inventory.ini site.yml --syntax-check
続いて、check modeとdiffで変更予定を確認します。
ansible-playbook -i inventory.ini site.yml --check --diff
レビューでは、少なくとも次を確認します。
- 削除や上書きの対象が広すぎないか
- サービス再起動の条件が適切か
- ネットワークやSSH接続を失う変更がないか
- ファイアウォールで管理経路を閉じないか
- 既存データや永続ボリュームへ影響しないか
- バックアップと復旧手順があるか
- check modeで予測できない処理がないか
可能であれば、使い捨ての検証環境やステージング環境で先に実行します。本番では対象ホストとタグを限定し、監視しながら段階的に適用します。
8. 文書とPlaybookをGitで引き継げる形にする
最後に、作成した監査Playbook、構成説明書、再構築用PlaybookをGitで管理します。
push前には、Codexにもステージ済みファイルを検査させます。
Gitへ追加されるファイルを一覧表示してください。
秘密鍵、パスフレーズ、Vault暗号化前の変数、監査ログ、認証情報が
含まれていないことを確認してからコミットしてください。
秘密ファイルそのものは削除せず、.gitignoreで除外してください。
ここで「秘密ファイルを削除しない」と明示するのは、ローカル運用に必要なファイルを誤って失わないためです。Gitへ入れないことと、端末から削除することは別の操作です。
一度Git履歴へ入った秘密情報は、最新コミットから削除しただけでは消えません。誤って公開した場合は、履歴修正だけでなく、鍵やトークンを直ちに失効・再発行します。
Codexに任せやすいこと、任せきれないこと
Codexが得意なのは、次のような作業です。
- 調査項目と安全なコマンドの組み立て
- Ansible疎通エラーの段階的な切り分け
- 監査スクリプトとPlaybookの作成
- 長い調査結果の分類と要約
- Markdown形式の構成説明書作成
- Ansibleの構文確認と差分チェック
-
.gitignoreやコミット対象の確認
一方、次の判断は人間が責任を持ちます。
- 本番サーバーへ接続・変更する権限があるか
- どの停止時間やリスクを許容できるか
- 観測した設定を維持するか改善するか
- バックアップから本当に復旧できるか
- 変更をいつ、どの範囲へ適用するか
- 生成された文書とコードが現場の事実に合っているか
Codexは、担当者の頭の中にあった知識を完全に復元できるわけではありません。サーバー上で観測できる事実から仮説を作り、未確認事項を明示し、人間が判断できる材料を増やすために使います。
まとめ
担当者が退職し、ドキュメントも古く、触るのが怖いサーバーでも、手順を分ければ少しずつ管理可能な状態へ戻せます。
Codexを使うと、Ansibleによる接続確認、読み取り専用の構成監査、ログの整理、構成説明書の作成、Playbook化、Git登録前の秘密情報チェックまでを、一つの流れとして進められます。
便利なのは、単にコマンドを生成できることではありません。調査で分かったことを、その場限りのターミナル出力で終わらせず、「次の担当者が読める文書」と「再実行できるコード」へ変換できることです。
サーバーそのものが唯一のドキュメントになっているなら、まず安全に観測する。そして、事実を文書化し、変更可能な部分をPlaybookへ移していく。Codexは、その地道で重要な引き継ぎ作業をかなり短縮してくれます。