0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@c_u(C U)
in

IBM Bob にSSH接続情報と手順書を連携してサーバー環境を構築

0
Last updated at Posted at 2026-10-12

はじめに

IBM Bob による自動構築イメージ

本記事では、AIコーディング・自動化支援エージェント 「IBM Bob」 を活用し、「設計情報からの手順書作成」から「SSH接続情報を渡してのサーバー構築実行」「エラー時の調査・復旧」「作業ログ（エビデンス）の記録」 までを一気通貫で実施した内容をまとめます。

本記事の内容

  • 要件や設計情報をもとに IBM Bob にあらかじめ手順書（Markdown）を作成させる流れ
  • 手順書とSSH情報を IBM Bob に渡してサーバー環境を構築する流れ
  • IBM Bob がSSH経由でコマンドを実行し、出力を検証する際の実例（OS初期設定、パッケージ導入など）
  • エラー発生時に IBM Bob が自律的に原因を調査・対処した実例
  • 安全に運用するためのアクセス制御およびガードレール設計

想定読者

  • 手順書に基づくサーバー初期設定や検証環境構築の作業負担を軽減したいインフラエンジニア
  • 自動化スクリプト（AnsibleやChefなど）の作成前段階におけるアドホックな構築作業を効率化したい方
  • IBM Bob 等のAIエージェントをインフラ構築・運用の補助として活用する方法に関心がある方

動画

当記事の内容を動画にしました。理解の一助にご参照ください。

背景と動機

サーバー構築やOS初期設定の現場では、以下のような作業が定常的に発生します。

  1. 手順書に基づく手作業の実行: パラメータの確認やコマンドの入力、実行結果の目視確認。
  2. 環境差分によるエラー対応: 手順書の記載内容と対象環境の差異（リポジトリ設定やパッケージ依存など）によるエラーの切り分け。
  3. 作業ログ（エビデンス）の記録: 実行したコマンドと出力結果の記録・整理。

定常的な構成管理には Ansible や Chef、Terraform などの IaC ツールが適していますが、「初期環境のセットアップ」「検証目的のアドホックな設定」「既存手順書からの移行フェーズ」 などでは、手順書を見ながら手動でコマンドを実行するケースも少なくありません。

また、近年のエディタには「IDEリモート接続機能（Remote-SSHなど）」がありますが、接続先サーバー上でエージェント用バイナリの動作が必要となるため、IBM AIX などのリモート機能に対応していない ことが一般的です。

そこで、ローカルでのコマンド実行やファイル操作機能を備えた IBM Bob にSSH接続情報と手順書を連携し、純粋な ssh コマンド経由でアクセスさせるアプローチを検証しました。この方式であれば、IDEリモート接続機能に対応していないプラットフォーム（AIXやレガシーLinuxなど）に対しても、同一の枠組みで自動構築を実施できます。

全体構成と処理フロー

IBM Bob はローカル環境（作業用端末または踏み台サーバー）上で動作し、手順書ファイルを読み込んだ上でSSH経由で対象サーバーへコマンドを発行します。

なお、IBM Bob におけるシェルコマンドの変更処理の実行は デフォルトでユーザー承認制（Human-in-the-Loop） で、AIが組み立てたコマンド内容を実行前に人間が確認・承認した上で発行される安全設計となっています。

サーバー設定の自動構築手順

実際に IBM Bob を使用して手順書作成からRHEL環境（検証サーバー）の初期セットアップまでを実施した際の流れを記載します。

1. 手順書自体の事前作成（IBM Bob によるドラフト起草）

構築作業に先立ち、設定要件や必要なパッケージ情報を IBM Bob に提示し、あらかじめ Markdown 形式の手順書を作成させました。

【依頼プロンプト例】
RHEL8環境に対するOS初期設定手順書を作成してください。
以下の要件を含め、実行コマンドと期待される確認結果を Markdown 形式で整理してください。

- 作業ディレクトリの作成 (/work 配下)
- ルートボリュームの LVM 拡張
- cloud-init の無効化
- SELinux の無効化 (設定ファイルバックアップ要)
- /etc/hosts の追加
- firewalld の停止・無効化

IBM Bob は、各作業項目のコマンドだけでなく「事前確認コマンド」「バックアップ作成」「反映確認コマンド」を体系的に盛り込んだ手順書（os-setting-supplement.md）を即座に作成します。人間側は内容に目を通し、前提条件やパラメータの妥当性を確認するだけで手順書が完成します。

2. IBM Bob への接続情報連携と実行指示

IBM Bob に対し、チャットインターフェース経由で 接続情報、参照する手順書、作業時の制約事項 を指定します。

以下の対象サーバーに対して、添付の「OS初期設定手順書（os-setting-supplement.md）」を実施してください。

【対象サーバー】
- ホスト名: target-server
- 接続ユーザー: root (または sudo 権限を持つ作業ユーザー)
- 認証方式: SSH鍵認証 (~/.ssh/id_rsa)

【作業方針】
1. 事前にSSH疎通およびOSリソース（ディスク容量、メモリ、OSバージョン）を確認すること
2. 手順書の各ステップを順に実行し、実行結果（終了コードと出力）を都度検証すること
3. 設定変更を行う際は、変更前ファイルのバックアップを作成すること
4. 破壊的な変更や不要な再起動は避けること
5. 作業完了後、実行ログを `logs/os_setting_supplement_YYYYMMDD.log` として出力すること

IBM Bob のシェル実行機能を利用し、ローカルから ssh root@target-server "コマンド" の形式で対象サーバーを操作します。

3. 手順書の解釈とコマンドの組み立て（複雑なコマンドも瞬時に生成）

AIは手順書に記載された抽象的な作業項目（「ルート領域を拡張する」「SELinuxを無効化する」など）を読み取り、対象サーバーの現在のOS状態を調査した上で、実行すべき具体的なコマンドを瞬時に組み立てます。

人間が手動で組み立てる場合、物理ボリュームやボリュームグループの名前、マウントポイントの確認、コマンドオプションの仕様確認などに時間を要しますが、AIは事前調査の出力結果を解釈し、条件分岐やヒアドキュメント（EOF）を含めた複雑なコマンド列を一瞬で正確に生成します。

実例：ファイルシステム拡張（LVM / XFS）

手順書に「ルートファイルシステムを拡張する」と記載されている場合、AIはまず現状のボリューム構成を調査します。

# AIによる事前調査コマンド
ssh root@target-server "pvs && vgs && lvs && df -hT /"

調査結果の出力からボリュームグループ名や論理ボリュームパス（/dev/rhel/root）を特定し、ディスク拡張に必要なコマンドを一連のブロックとして瞬時に組み立てて実行します。

# AIが組み立てて実行したコマンド
ssh root@target-server << 'EOF'
  pvresize /dev/mapper/mpatha3
  lvextend -l +100%FREE /dev/rhel/root
  xfs_growfs /
EOF

4. OS共通設定の適用

続いて、OSの共通設定（SELinux、hosts、cloud-init、firewalld等）を順次適用します。

# AIがSSH経由で実行した設定例
ssh root@target-server << 'EOF'
  # 1. cloud-init の無効化
  touch /etc/cloud/cloud-init.disabled

  # 2. SELinux 無効化（バックアップを取得した上で変更）
  cp -p /etc/selinux/config /etc/selinux/config.org
  sed -i "s/^SELINUX=.*/SELINUX=disabled/" /etc/selinux/config

  # 3. hosts 設定（既存設定の有無を確認して追記）
  grep -q "node-01" /etc/hosts || echo "<node-01-ip> node-01" >> /etc/hosts
  grep -q "node-02" /etc/hosts || echo "<node-02-ip> node-02" >> /etc/hosts

  # 4. firewalld 停止・無効化
  systemctl stop firewalld && systemctl disable firewalld
EOF

「設定変更前にバックアップ（.org 等）を作成する」「既存行の重複チェックを行う」といったインフラ運用の慣例を、指示に基づいてコマンドへ反映して実行します。

5. エラー発生時の原因調査とリカバリ

実行中にエラーが発生した場合、AIはエラー出力を解析し、原因の特定とリカバリコマンドの実行を自律的に行います。

実例：パッケージインストール時の依存関係エラー

オフライン環境においてChefやGitLab等のRPMパッケージをインストールする際、依存パッケージが不足してエラーとなったケースです。

# エラー出力の例
Error: Problem: package chef-13.8.5-1.el7.ppc64le requires libyaml, but none of the providers can be installed

この出力に対し、AIは以下の順序で対応を行いました。

  1. リポジトリ設定の確認: dnf repolist -v でリポジトリの状態を確認。
  2. 原因特定: 依存パッケージが含まれるローカルリポジトリ（Supplement）が無効化されていたことを確認。
  3. 設定の修正: 
    ssh root@target-server "dnf config-manager --set-enabled RHEL-Supplement && dnf clean all"
  4. 再実行: パッケージインストールコマンドを再実行し、正常終了を確認。

6. 実行後ログの集約と作業エビデンスの自動作成

AIへの初期指示（プロンプト）の段階で、「各ステップの実行コマンドと標準出力を整理し、ログファイルとして出力すること」 を明示的に指示しています。

AIは作業を進めながら各ステップの実行結果をメモリ上に保持し、全体の構築が完了したタイミングで、作業項目ごとに構造化されたログファイル（エビデンス）を自動的に生成・保存します。これにより、人間が手作業でターミナルのログをコピー＆ペーストして整形する手間が省かれます。

================================================================================
 OS設定補足手順 設定作業ログ
 対象サーバー : target-server
 実施日時     : 2026-10-12
================================================================================

--------------------------------------------------------------------------------
[1] 作業ディレクトリ作成
--------------------------------------------------------------------------------
# mkdir -p /work/log /work/ansible /work/collections /work/gitlab
drwxr-xr-x. 8 root root 96 Oct 11 21:45 /work
...

--------------------------------------------------------------------------------
[2] ファイルシステム確認・拡張
--------------------------------------------------------------------------------
# pvresize /dev/mapper/mpatha3
# lvextend -l +100%FREE /dev/rhel/root
# xfs_growfs /
Filesystem            Type  Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root xfs    45G   21G   24G  47% /
================================================================================

AI（IBM Bob）に作業を実施させる際のリスクと解消策

AIエージェントにSSH経由で直接サーバー操作を委任する場合、人手作業とは異なる固有のリスクが存在します。安全に運用するために講じたリスクと解消策は以下の通りです。

エンジニアの今後の仕事はこちらが増えるのでは、、

想定リスク 具体的なリスク内容 解消策・ガードレール
1. 意図しない破壊的コマンドの実行 rm -rf や mkfs、予期せぬ reboot などによるシステム停止やデータ消失 ・IBM Bob のコマンド実行はデフォルトで承認制（Human-in-the-Loop） となっており、実行前にコマンド内容を人間が確認可能
・プロンプトで危険コマンドの実行禁止を明示
・作業ユーザーの sudo 権限を必要最小限に制限
2. 手順書の解釈違い・誤った設定値の適用 手順書の曖昧な記載からAIが誤ったパラメータを推測・適用してしまう ・「事前調査 → 変更計画の提示 → 実行」とフェーズを分ける指示設計
・実環境の取得値に基づき、変更前後の整合性を検証させる
3. ネットワーク・SSH設定の変更による接続遮断 firewalld や sshd_config の誤変更により、SSH接続が失われて復旧不能になる ・ネットワークやSSH関連の設定変更は慎重に対処させる
・設定反映と疎通確認を同一コマンド内で検証する、またはコンソール作業に切り替える
4. 設定変更の重複や冪等性の欠如 処理中断後の再実行時に、hosts や設定ファイルへの二重追記が発生する ・grep -q や test -f などの事前チェックを必ず含めてコマンドを組み立てるよう指示
・変更前のバックアップ（.org）取得を義務付ける
5. 秘密情報・認証情報の漏洩・残存 AIとの対話履歴やログへの認証情報の記録、および作業完了後のクレデンシャル残存 ・SSH鍵認証を利用し、パスワードの直接受け渡しを避ける
・作業ログ出力時に機密情報をマスキングする指示を含める
・作業完了後に認証情報（一時SSH鍵や作業用パスワード）を速やかにローテーション・削除する

AI作業の監視体制と事後セキュリティ

AIに実機操作を任せるにあたっては、「実行中の監視」「事後レビュー」「アクセス権の遮断」を多層的に徹底することが重要になると考えます。

1. 実施ログのリアルタイム・事後確認

AIが画面上で実行するコマンドとその出力を人間がリアルタイムに目視確認することに加え、出力された実行ログファイル（logs/os_setting_supplement_YYYYMMDD.log 等）やサーバー側の認証・監査ログ（auditd / /var/log/secure）と突き合わせて、意図しない操作が行われていないかを検証します。

2. 実施内容の報告レポート（サマリー）の作成

単なる実行ログの出力だけでなく、AIに対して「実施した作業項目」「変更前後の設定差分」「発生したエラーと対処内容」「最終的な疎通・動作確認結果」をまとめた作業完了報告レポートを作成させます。人間側はそのレポートをもとに構築が要件通り完了したかを最終判定します。

3. SSHセッションの録画・ターミナルログの完全記録

踏み台サーバーのセッションレコーディング機能や、Linux標準のターミナル録画ツール（tlog / script コマンド等）を活用し、AIがSSHセッション内で行った入出力と実行タイミングをすべて記録します。これにより、万が一のトラブル時にも作業内容を完全に再現・追跡できます。

4. 作業中のリソース・プロセス監視（予期せぬ負荷の検知）

AIが大規模な探索コマンド（広範囲の find など）や重いコンパイル処理を誤って実行しないよう、作業中は既存の監視エージェントや top コマンド等でCPU・メモリ使用率やプロセス状態を監視し、サーバーへの過度な負荷を検知・抑止できるようにします。

5. OS監査ログ（auditd 等）の使用検討

AIが操作した内容をOS側で客観的かつ改ざん不能な証跡として残すため、OS標準の監査デーモン（Linux の auditd や AIX の audit サブシステム）の活用を検討します。
作業ユーザーが実行したシステムコール（コマンド実行 execve）や、重要設定ファイル（/etc/hosts, /etc/ssh/sshd_config, /etc/selinux/config 等）への書き込み・属性変更をカーネルレベルで記録しておくことで、AIの出力ログとは独立した公的な監査ログとして事後検証が可能になります。

6. 作業完了後の人手による認証情報変更（アクセス遮断）

作業終了後は、人手で確実に認証情報を変更・削除します。作業用の一時SSH公開鍵の削除（authorized_keys からの除去）や、作業用ユーザーのパスワード変更・アカウント無効化を行うことで、作業完了後にAI（およびAIの動作環境）からサーバーへ再アクセスできない状態を担保します。

導入における利点と注意点

利点

  • IDEリモート非対応環境（AIX等）への適用性: IDEのリモート接続機能ではなく標準のSSHコマンド経由でアクセスするため、AIX や各種 UNIX 環境でも Linux と全く同様に自動構築を実施できる。
  • デフォルトの承認制による安全性: IBM Bob はコマンド実行前に人間が承認するフローが標準となっているため、AIの生成したコマンドを確認しながら安全に作業を進められる。
  • コマンド組み立ての迅速性: ディスク拡張やsed置換などの複雑なコマンド列であっても、環境調査結果から瞬時に正確なワンライナーやスクリプトが生成される。
  • 作業時間の短縮: 手順書を見ながらの手動入力・画面確認の往復作業を削減できる。
  • 誤入力の防止: パラメータの打ち間違いや手順の読み飛ばしを防ぐことができる。
  • エビデンス作成の自動化: プロンプトで指示しておくことで、実行後の全結果が構造化された作業ログとして自動集約される。
  • トラブルシューティングの効率化: パッケージ依存や設定不整合に対して迅速に対処できる。

注意点

  • 事前の前提条件の明示: 許可する変更範囲や禁止事項をプロンプトで明確に指定する必要がある。
  • 冪等性の確保: 再実行時に不整合が発生しないよう、状態確認を挟むコマンド構成を意識させることが重要である。
  • 作業後のアクセス遮断の徹底: 前述の通り、作業終了後に認証情報を変更してアクセス権を無効化する運用ルールを必ず設ける。

まとめ

IBM Bob を活用することで、以下のインフラ構築ライフサイクルを一貫して支援させることができます。

  1. 要件や設計情報から、あらかじめ体系的な手順書（Markdown）を作成する
  2. 手順書の意図を読み取り、環境に合わせたコマンドを瞬時に組み立てる
  3. SSH経由でリモート実行し、終了コードと出力を確認する
  4. エラー発生時は出力を解析して修正コマンドを実行する
  5. 作業完了後に構造化されたログファイルを自動集約・生成する

手順書のドキュメント作成から実機への設定適用、エビデンス生成までを一連の流れとして実施できるため、定常的な構成管理コードの作成前段階や、検証環境のセットアップ作業において実用的なアプローチとして活用できます。

おわりに

本記事でご紹介したように、IBM Bob をはじめとする AI エージェントは、アプリケーション開発だけでなく、インフラ構築やサーバー運用の現場においても強力な作業支援パートナーとなり得ます。

手順書の作成から実機へのコマンド発行、トラブルシューティング、ログの自動集約に至るまでを一連のワークフローとして任せることで、作業ミスの防止や工数削減に大きく寄与します。また、デフォルトのコマンド承認機能（Human-in-the-Loop）や認証情報の管理といった安全対策を適切に組み合わせることで、実務においても安心して活用を進めることができます。

まずは検証環境やサンドボックス環境などで、日常の構築・運用作業の補助として試してみてはいかがでしょうか。

IBM Bob のトライアルについて

IBM Bob には 30 日間の無料トライアル枠が用意されています。実際に環境構築やコード生成を試してみたい方は、以下の公式ページをご参照ください。

Bob2.png
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?