1. はじめに:インフラ構築は「書く」から「見せる」時代へ
-
背景: 複雑な分散キューイングの設計(送信キュー、伝送キュー、チャネル設定など)は、図解するのが一番早いが、構築には多くのコードが必要
-
解決策: IBM Bobのマルチモーダル機能(画像認識)を使い、構成図からDocker上のMQ環境を素早く構築する
2. 今回構築するシステム構成
-
シナリオ: 2つのQueue Manager(QM1, QM2)間でのメッセージ転送
-
構成要素:
-
QM1: 送信側(Local Queue, Remote Queue Definition, Transmission Queue, Sender Channel)
-
QM2: 受信側(Local Queue, Receiver Channel)
-
3. Bobへのプロンプト(指示)
単に「作って」という指示では無く、精度を高めるための指示を与えます
以下のようなプロンプトを与えることにします
#指示 MQ.jpgを読み取り、dockerで稼働するMQの構成を作ってください。
#注意事項
QM2のReceiverチャネルのAUTHENTICATION RECORDは、アドレスマップで*で作成してください。
チャネルの開始は定義しないでください。
管理ユーザは、adminで、パスワードは、passw0rdで設定してください。
使い方は、READMEで作成してください。
README.md
このプロジェクトは、DockerでIBM MQの2つのキューマネージャー(QM1とQM2)を構築し、相互接続する環境を提供します。
構成概要
-
QM1: リスナーポート 1414
- トランスミッションキュー: XMITQ
- リモートキュー: QM2.RQ.1 (QM2のDEV.QUEUE.1を指す)
- Senderチャネル: QM1toQM2
- amqsput コマンドでメッセージを送信
-
QM2: リスナーポート 1414 (ホストからは1415でアクセス)
- ローカルキュー: DEV.QUEUE.1
- Receiverチャネル: QM1toQM2
- AUTHENTICATION RECORD: アドレスマップで * を使用
-
ネットワーク: mq-network (Docker Bridge)
前提条件
- Docker Desktop for Windows がインストールされていること
- Docker Compose が利用可能であること
セットアップ手順
1. 環境の起動
docker-compose up -d
コンテナが起動するまで数分かかる場合があります。
2. 起動確認
docker-compose ps
両方のコンテナが running 状態であることを確認してください。
3. ログの確認
# QM1のログ
docker logs qm1
# QM2のログ
docker logs qm2
管理情報
- 管理ユーザー: admin
- パスワード: passw0rd
使用方法
QM1からQM2へメッセージを送信
- QM1コンテナに接続:
docker exec -it qm1 bash
- メッセージを送信 (amqsputコマンドを使用):
echo "テストメッセージ" | /opt/mqm/samp/bin/amqsput QM2.RQ.1 QM1
- コンテナから退出:
exit
QM2でメッセージを受信
- QM2コンテナに接続:
docker exec -it qm2 bash
- メッセージを受信:
/opt/mqm/samp/bin/amqsget DEV.QUEUE.1 QM2
- コンテナから退出:
exit
チャネルの手動開始
注意: チャネルの自動開始は定義に含まれていません。必要に応じて手動で開始してください。
QM1のSenderチャネルを開始
docker exec -it qm1 bash
echo "START CHANNEL(QM1toQM2)" | /opt/mqm/bin/runmqsc QM1
exit
MQ Webコンソールへのアクセス
ログイン情報:
- ユーザー名: admin
- パスワード: passw0rd
トラブルシューティング
チャネルの状態確認
# QM1のチャネル状態
docker exec -it qm1 bash -c "echo 'DISPLAY CHSTATUS(QM1toQM2)' | /opt/mqm/bin/runmqsc QM1"
# QM2のチャネル状態
docker exec -it qm2 bash -c "echo 'DISPLAY CHSTATUS(QM1toQM2)' | /opt/mqm/bin/runmqsc QM2"
キューの状態確認
# QM1のトランスミッションキュー
docker exec -it qm1 bash -c "echo 'DISPLAY QUEUE(XMITQ)' | /opt/mqm/bin/runmqsc QM1"
# QM2のローカルキュー
docker exec -it qm2 bash -c "echo 'DISPLAY QUEUE(DEV.QUEUE.1)' | /opt/mqm/bin/runmqsc QM2"
キューの深さ確認
# QM2のDEV.QUEUE.1のメッセージ数
docker exec -it qm2 bash -c "echo 'DISPLAY QUEUE(DEV.QUEUE.1) CURDEPTH' | /opt/mqm/bin/runmqsc QM2"
環境の停止と削除
停止
docker-compose stop
削除 (データも削除)
docker-compose down -v
ファイル構成
MQ/
├── docker-compose.yml # Docker Compose設定
├── qm1.mqsc # QM1のMQSC設定
├── qm2.mqsc # QM2のMQSC設定
└── README.md # このファイル
注意事項
- QM2のReceiverチャネルのAUTHENTICATION RECORDは、アドレスマップで * を使用しています
- チャネルの自動開始は定義されていません
- 本番環境で使用する場合は、セキュリティ設定を適切に強化してください
- パスワードは環境変数や Docker Secrets を使用して管理することを推奨します
4. 動作確認
- README.mdの中を確認して、以下で起動します
docker compose up -d
-
README.mdにあるように、コンテナが稼働しているか確認します
docker compose ps
- MQのコンソールを起動します(QM1)
ブラウザから、以下のURLにアクセスします
ID/パスワードは以下の通り
| ユーザーID | パスワード |
|---|---|
| admin | passw0rd |
https://localhost:9443/ibmmq/console/
-
QM2のコンソールにログインします
ユーザーIDとパスワードは、QM1と同じです
https://localhost:9444/ibmmq/console/
-
README.mdには、コマンドでのメッセージ送信方法もありますので、そちらを使うことも可能です
5. まとめ:AIによる「設計図のコード化」がもたらす変革
今回の検証を通じて、IBM Bobが単なるコード生成器ではなく、「インフラ設計の意図を汲み取るインテリジェントな翻訳者」であることが確認できました
① 属人化の解消とスピードアップ
従来、MQの分散キューイング設定は、送信キュー、伝送キュー、リモートキュー定義といった複数のオブジェクトを、パラメーターの整合性を保ちながら手動で定義する必要がありました。
効果: Bobに図解を読み取らせることで、定義ミス(タイポやポート番号の不一致)を未然に防ぎ、構築時間を数時間から数分へ短縮できます。
② 「生きたドキュメント」としての構成図
これまでは「設計図(画像)」と「設定ファイル(コード)」が乖離しがちでした。
変化: 「図からコードを生成する」ワークフローを標準化することで、構成図が常に最新の正解(Single Source of Truth)となり、メンテナンス性が飛躍的に向上します。
③ 応用可能性:マルチクラウド・ハイブリッド環境へ
今回はDocker環境での検証でしたが、BOBの能力はこれに留まりません。
今後の展望: 生成対象を mqsc だけでなく、TerraformやAnsible、あるいはKubernetes上のMQ Operator用マニフェスト(Custom Resource)へと拡張することで、オンプレミスからクラウドまで一貫した自動デプロイが可能になります。


















