目的

スクリプトによる自動オペレーションを導入して

作業時間を短縮しよう！
オペレーションミスをできるだけ減らすようにしよう！

背景

私はQCとして受け入れ試験の実施を行なっていました。
1つの案件あたり大体4つから5つのホストへアクセスし、DBでデータの取得や出力されたログファイルの中身を確認する必要がありました。
その接続するホストも決まりきっているわけではなく、数十個稼働しているホストの中から案件ごとにいずれかが試験対象になるといったケースが多かったです。
例えば、前の案件ではホストA,B,C,Dが試験中にアクセスする対象だったけれど、次の案件ではホストE,F,G,Hが対象といったイメージです。
さらに、一言でホストと言っても、踏み台環境、dev環境とstg環境、主系と副系、リプレイスによる新旧のホストの混在などという点も踏まえてアクセス先を控えておく必要がありました。
試験チームメンバーはRLoginの他にTeraTermの使用も許可されていましたが、既存メンバーのRLogin採用率が高くノウハウも蓄積されていたため、実質的にRLogin一択という空気感でした。
私が配属されしばらく経ち、自分がRLoginを使いつつ新規メンバーにもその使い方を教えることが増える中で、ふと「もしRLoginのマクロをメンバー全員が導入できてかつ保守もできたら、チーム全体の作業負担が割と減るんじゃないか？」と思う瞬間がありました。
そのように思った理由は以下です。

踏み台環境から対象のホストへ接続し、ホスト内にあるDBへのログインや出力されたログの確認など、決まり切っている手順とはいえ手動で行っているので煩雑
コマンドの実行を手動で行う以上、ヒューマンエラーが起こる可能性を拭えない。特に新規参画者はスキルレベルによってはミスを起こしやすいので、都度既存メンバーがフォローに入らなくてはならなくなる

そのため、メンバー全員がマクロを導入しやすくできるように整備を始めましたが、進めていく中でいくつか課題を感じました。

定期的にアクセス先が変更になるため、スクリプトに記載しているアクセス先を書き換える保守が必要になる
RLoginとスクリプトに対して理解の浅いメンバーが導入する場合、導入自体とその後の保守が大きな負担となってしまう

そのため、以下の方針で進めることにしました。

保守を行えるメンバーが他メンバーの環境内でも保守をできるだけやりやすくなるようにスクリプト群を整備する
少しでも多くのメンバーがなるべくコストをかけず保守を行う側の立場になれるように導入手順書を用意する

今回は、実際に運用していたスクリプト群と書き残した導入手順についてを中心に紹介しようと思います。

RLoginの導入方法

他で説明している記事等を参考にダウンロードしていただければOKです。
RLoginが用意されているgithubのページリンクを張り付けておきます。
バージョンは2025年10月時点で最新のものであれば問題ありません。
https://github.com/kmiya-culti/RLogin/releases/

導入手順としていいなと思った記事がありましたので、勝手ながら紹介させていただきます。
Rlogin入門

解凍後、任意の場所にRlogin.exeを含んでいるディレクトリごと置いてください。

スクリプトの導入方法

ディレクトリ構成について

ダウンロードしたRLoginのディレクトリと同じ階層にディレクトリとテキストファイルを用意してください。

ディレクトリ構成

rlogin_x64/
┣ RLogin.exe
┗ RLogin_script/
  ┠ config_host.txt
  ┠ config_personal.txt
  ┠ module.txt
  ┠ initialize.txt
  ┠ dev/
  ┃ ┗ example.txt
  ┗ stg/
    ┗ example.txt

各ファイルの役割と記述例について

config_host.txt

config_host.txt

Hostmap.dev.example = "dev.example.co.jp";
Hostmap.dev.example_new = "dev.example-new.co.jp";
Hostmap.stg.example = "stg.example.co.jp";

このファイルでは踏み台環境からアクセスするホストに対応する変数を宣言し、値としてホストのアドレスを代入します。
採用していた命名規則としては、ホストの連想配列なのでHostmap、dev環境だからdev、最後にホスト名であるexampleを組み合わせた形です。
もしリプレイスによって新旧のホストが混在している状態で区別をさせたいのであれば、さらに後ろにoldとかnewとか一時的に付け加えておくことで柔軟に対応できるかなと思います。

config_personal.txt

config_personal.txt

Personalmap.dev.example.user.id = "username";
Personalmap.dev.example.user.pw = "password";
Personalmap.stg.example.user.id = "username";
Personalmap.stg.example.user.pw = "password";

このファイルではホストへアクセスするための個人情報を変数として管理します。
ルール上、パスワードをテキストファイルに保存できない場合は宣言しなくても構いません。
あくまで自動で入力するための設定値ですので、パスワードだけ手入力すれば問題ないです。
命名規則はconfig_host.txtに記載した内容から大きな違いはありません。

module.txt

module.txt

Function Add(a, b)
{
    Return a + b;
};

このファイルは関数を宣言するために用意しました。
しかし、実際の運用では全く使わなかったので、あくまで説明例として数値の合計値を返すAddを宣言しています。

initialize.txt

initialize.txt

include("RLogin_script/config_host.txt");
include("RLogin_script/config_personal.txt");
include("RLogin_script/module.txt");
Document.Open();
wait(CONNECT);
sopen(OPEN_LOOK);
swait(1,"$");

自動で動作させるために必ず必要となる処理をここで記述するためのファイルです。
ホストへアクセスするスクリプトファイルを用意する際にこのinitialize.txtさえinclude()で取り込めば、ホストの接続先、個人情報、関数などを丸ごと芋づる式で取り込めるように用意しました。
また、Document.Open();以下の記述にソケット入力を行うためのものであり、必ず必要となる処理のためここで記述しました。
先述した通り変数や関数のファイルをいくつか用意しましたが、自分以外が保守する際にどれを記述すればいいのか困惑しないように、また記述が煩雑にならないようにという狙いがあります。
接続設定で指定するスクリプトには、このファイルを取り込む処理をおまじないとして１行目に記述してください。

example.txt

include("RLogin_script/initialize.txt");
sputs("ssh " Personalmap.dev.user.id . "@" . Hostmap.dev.example . "/n");
swait(1,"password:");
sputs(Personalmap.dev.user.pw . "/n");
sclose();

例として挙げているホストであるdev環境のexampleへアクセスするための、接続設定で指定するスクリプトファイルです。
１行目でinclude.txtを取り込むことで、ホストの接続先、個人情報、関数、ソケット入力を開く段階まで完了しているので、そのあと入力するホストへのアクセスコマンドを用意する記述となっています。
stg環境の記載については大きな変更はなく、devと書かれている部分をstgに書き換えればいいだけなので割愛します。

スクリプトの保守例

スクリプトを導入した以上、保守が必要になると思います。
具体的な保守例をいくつか紹介します。

ホストのアドレスが変わった

例えば、dev環境のexampleのアドレスが変わった場合を考えます。
その場合は、config_host.txtで宣言されているdev環境のexampleの変数の値を書き換えます。
複数人でこのスクリプト群を導入しているのであれば、一人がconfig_host.txtの保守を行い、他のメンバーへファイル連携を行うと各々で書き換えるという手間が省けます。

config_host.txt

- Hostmap.dev.example = "dev.example.co.jp";
+ Hostmap.dev.example = "dev.example_new.co.jp";

ホストへアクセスした後、DBへのログインも自動で行いたい

例えば、dev環境のexampleへアクセスした後、DBへのログインも自動で行いたい場合を考えます。
まず、DBのログインに使用するIDとパスワードに対応する変数の宣言とその値の代入を行います。
config_personal.txtは個人情報が含まれているファイルのため、各メンバーが同じ変数名で宣言をした上で値を代入する必要があります。

config_personal.txt

Personalmap.dev.example.user.id = "username";
Personalmap.dev.example.user.pw = "password";
+ Personalmap.dev.example.db.id = "username_for_db";
+ Personalmap.dev.example.db.pw = "password_for_db";

example.txtにはホストへアクセスするまでの処理が記述されているので、その記述にDBへのログインを行う処理も記述します。
直接記述するか、module.txtでDBへログインする関数を宣言してここで呼び出すかはどちらでもOKです。
example.txtを追記した後は他のメンバーへ共有し挿げ替えてもらうことが可能です。

example.txt

include("RLogin_script/initialize.txt");
sputs("ssh " Personalmap.dev.user.id . "@" . Hostmap.dev.example . "/n");
swait(1,"password:");
sputs(Personalmap.dev.user.pw . "/n");
+ swait(1,"$");
+ sputs("mysql -u " Personalmap.dev.example.db.id . " -p " . "/n");
+ swait(1,"Enter password:");
+ sputs(Personalmap.dev.example.db.pw . "/n");
sclose();

新しいホストへのアクセスを自動化したい

例えば、dev環境のexample2へアクセスする処理を自動化したいという場合を考えます。
dev環境のexample2に対応する変数とその値としてアクセス先を追記します。

config_host.txt

Hostmap.dev.example = "dev.example.co.jp";
+ Hostmap.dev.example2 = "dev.example2.co.jp";

dev環境のexample2にログインするためのユーザーIDとパスワードに対応する変数とその値を追記します。

config_personal.txt

Personalmap.dev.example.user.id = "username";
Personalmap.dev.example.user.pw = "password";
+ Personalmap.dev.example2.user.id = "username_for_example2";
+ Personalmap.dev.example2.user.pw = "password_for_example2";

新たにexample2.txtというファイルを新規作成します。
ファイル内に記述する内容は、example同様に踏み台環境からssh接続する場合とすると下記になります。

example2.txt

include("RLogin_script/initialize.txt");
sputs("ssh " Personalmap.dev.example2.user.id . "@" . Hostmap.dev.example . "/n");
swait(1,"password:");
sputs(Personalmap.dev.example2.user.pw . "/n");
sclose();

example2.txtの配置場所は、dev環境のため下記となります。

ディレクトリ構成

rlogin_x64/
┗ RLogin_script/
  ┗ dev/
    ┠ example.txt
+   ┗ example2.txt

RLoginでexample2の接続設定を新規作成します。Server Selectで新規を押下してください。

example2.txtを新規作成した接続設定のスクリプトファイルとして指定してください。
赤枠の参照ボタンを押下してファイル指定ができます。

おすすめの詳細設定

自動化とは少し話が脱線してしまうかもしれませんが、作業ミスを減らすという目的には合っているため、ここでいくつかおすすめの設定を紹介できればと思います。

背景色を接続先の環境によって変える

接続設定をいくつか用意していると、時折間違えた環境へアクセスして作業してしまっていたことがありました。
私の知見では接続設定の指定までは自動選択できるよう整備はできなかったので、選択した後にどの環境を選択しているのかを一発でわかるようにしようと思い、dev環境は黒、stg環境は黄土色と統一していました。
これでstg環境へアクセスしたはずなのに背景が黄土色なら、どんなにケアレスミスが発生しやすい状況でも判断できます。
実際、この設定をしてから環境を間違えることが一切なくなったので本当におすすめです。
対象の接続設定を編集するダイアログを表示させ、カラーにある背景色を押下して好きな色を選択することで変更できます。

タブを接続先の環境ごとに管理する

接続設定が増えると、１つの画面の中から探すのは億劫になってくると思います。
RLoginにはタブ機能があり、タブの名前を好きに決めた上で接続設定それぞれをグループ分けできたので、私は環境ごとにタブを用意していました。

対象の接続設定を編集するServer Edit Entryを表示させ、赤枠内にタブグループの名前を入力する、もしくはすでに存在するグループに追加したい場合はドロップダウンから選択します。

その他いろいろ

RLoginでやっておきたい設定、Tips
私が試験業務としてRLoginを使っている中で何か改善できる設定方法がないか探る時にまず参考にして記事です。
先述した2つに加えて他にも良い設定方法が記載されているので、勝手ながら紹介させてもらいます。

Q&A

話の内容が脱線しないように細かい理由等を省略して説明していましたので、疑問の浮かぶ箇所があったかと思います。
考えられる質問とその回答を記載します。

Q: なぜconfig_host.txtとconfig_personal.txtを分けてるんですか？
A: 保守担当者が他メンバーの設定変更を容易に行えるようにしたかったため: ホストの接続先が変わったくらいだと、保守できる側の人がconfig_host.txtを整備して展開するだけで各々が整備する必要性を回避できるよなと思ったからです。また、RLoginに対する知識が不十分なメンバーがいる状態だと、メンバー各々が設定を書き換えるという形式は、書き換えた部分でシンタックスエラーが発生するなど、有識者のサポートや修正が必要となってしまう場合もありえます。もし導入するメンバーに保守を行うスキルが身についている場合や、接続時にパスワードなど個人的な情報の入力をする必要がない場合はconfig_host.txtとconfig_personal.txtを統合してしまっても問題ないと思います。

Q: TeraTermでも同じことはできますか？
A: できますが、それでもRLoginをおすすめしたいです: TeraTermについて深い知識がないのであまり説得力のある回答にはならないかもしれません。しかし、TeraTermでは拡張機能として取り入れないといけない機能がRLoginにはデフォルトで備わっていているという差は使い勝手の点で大きいかと思います。TeraTermでしかできないことがある、TeraTermでやったほうが効率のよいことがある場合はTeraTermでもよいのかなと思いました。

Q: 接続した際に変なダイアログが出たのですが、表示しないようにしたいです
A: デバッグモードがONになっているので、以下画像のチェックを外してください: 対象の接続設定を選択し編集を押下。Sever Edit Entryでスクリプトを選択することで表示ができます。

Q: rlogin_x64配下にスクリプトを用意した理由は？
A: 新規メンバーが参画した時に丸ごと渡しやくするため: 新規メンバーが参画したときは、立ち上げ作業の1つとしてRLoginのダウンロード手順がまとまっている資料をそのメンバーに渡してはいましたが、実際のところは立ち上げのサポートを行う既存メンバーが持っているRLoginの実行ファイル等を丸ごとコピーして渡してたので、「じゃあスクリプトもそのとき渡してしまえばいいじゃん」と思いRLogin.exeと同じ階層に用意しました。

Q: スクリプトのファイル指定で相対パスを使っている理由は？
A: 3つの理由から相対パスを使うようにしました: 1つ目は、RLoginのダウンロード手順については指定がありましたが、どこに配置するかまでの指定はなかったためです。既存メンバーは各々好きな場所に実行ファイルを配置しています。それなのに「自動化させたいのであればこれからは私が指定したパスに配置するようにしてください」と私が言ったところで不都合極まりないでしょうから相対パスを採用しました。2つ目は、試験環境都合の話になりますが、各メンバーのフルパスの中にはメンバー特有のアカウント名が含まれてしまい、導入時都度書き換えるのが手間になためです。3つ目は、一度フルパスで指定してしまうと、rlogin_x64を何かしらの理由で移動させないといけない時に再設定が必要となってしまうためです。

Q: devとstgでディレクトリを分けている理由は？
A: 1つのディレクトリ内にまとめてしまうと多過ぎていたためです: 背景に記載している通り、何十ものホストへ接続していたため、それに合わせてスクリプトを用意していました。それを1つのディレクトリにまとめていると管理しにくいと感じたため、環境ごとにディレクトリを用意しまとめていました。もし「そこまで多くはない」というのであれば、まとめてしまっても問題ないかなと思います。逆に「もっと細かく分けたい」という場合も都度ディレクトリを用意して問題ないです。いずれにせよ、スクリプトファイルの配置場所を変更した後は、接続設定で指定しているスクリプトファイルのパスを書き換えることをお忘れないようにしていただければと思います。

Q: 宣言している変数に連想配列を採用している理由は？
A: ホストの正式名称をそのまま変数名の文字列として採用したかったから: キャメルケースなど大文字で単語を区切るようにしてしまうと、実際のホスト名は全部小文字なのに先頭が大文字になっているという違いが生じてしまい「ちょっと気持ち悪いな」って思ったのと、RLoginのスクリプトの仕様上_(アンダーバー)が使用できないので連想配列を採用しました。そこにこだわりがなければ、連想配列でなくても構わないです。