4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Bobで実現!自然言語によるIBM SQL Replication管理

4
Last updated at Posted at 2026-01-16

はじめに

IBM が発表した 次世代のAI開発パートナー「Project Bob」 により、AIを活用したソフトウェア開発の在り方が大きく進化しつつあります。
本記事では、自然言語だけで IBM SQL Replication を操作・管理できる仕組みを Bobを使って自動生成したプロセスと実装内容を紹介します。

IBM SQL Replicationとは

IBM InfoSphere Data Replication(IIDR)には、SQL Replication、Q Replication、Change Data Capture(CDC)といった複数のデータ連携製品が用意されています。
MQ を利用して高速リアルタイム連携を可能にする Q Replication や、より細粒度なログキャプチャで変化を即時に取り込む CDC に対して、SQL Replication はシンプルな構成で確実な非同期レプリケーションを実現できる点が特徴です。扱いやすさや運用負荷の低さを重視したい場合に特に有効で、IIDR の中でも導入しやすいレプリケーション方式となります。

Bobとは

Bob は、ソフトウェア開発ライフサイクル全体を支援する 高度なAIコーディングアシスタント で、設計・実装・レビュー・ドキュメンテーションといった開発作業を総合的に扱うことができます。コードベースやプロジェクト構造を深く理解し、複雑なタスクの分解・実行・最適化を行う“開発パートナー”として機能します。また、自然言語での指示から必要なコードの生成や改善を行い、アプリケーションの構築プロセスを大幅に効率化できる点が大きな特徴です。

背景と課題

IBM SQL Replication管理の複雑さ

IBM SQL Replicationの管理には以下のような課題があります:

  1. 複数サーバーを跨ぐ運用管理: キャプチャ側とアプライ側の 2 つのサーバーを個別に管理する必要があり、構成変更やトラブルシュート時の確認範囲が広くなりがちです。
  2. 扱うコマンドの多さと煩雑さ: ASNCLP、asncap、asnapply、asnccmd、asnacmd など、用途の異なるツール群を適切に使い分ける必要があります。慣れるまでは「どれを使うのが正解か」で悩むこともあります。
  3. SQL 操作を前提とした管理作業: 制御テーブルの確認や定義変更、障害対応では SQL を直接実行するケースが多く、管理者の負担が大きくなりがちです。
  4. 状態把握のしづらさ: レプリケーションの進捗や遅延状況などを“ひと目で”把握する手段が少なく、必要な情報を複数のビューやログから拾い集める必要があります。
  5. 定型作業でも手順が多い: フルリフレッシュの実行など、日常的に行う作業でも複数ステップを手動で実施する必要があり、効率化しづらい点が課題となります。

解決したいこと

そこで管理者が自然言語でSQL Replicationを管理できる仕組みを開発してみました。
目的は「複雑な操作を AI に任せ、管理者はやりたいことをそのまま指示するだけ」という状態を実現することです。

実現したい機能は次のとおりです:

  • 「キャプチャサーバーを起動してください」といった自然言語による指示で操作できる
  • ASNCLP や asncap などの複雑なコマンドや SQL を意識せずに運用作業を実行できる
  • レプリケーション状況や遅延などを自然言語の質問で分かりやすく確認できる
  • フルリフレッシュなどの定型作業を自動化し、手動操作のミスを抑制できる

Bobによる自動開発プロセス

開発環境

  • PC: MacBook Pro (2021) / Apple M1 Pro チップ
  • OS: Tahoe 26.2
  • IBM Bob: 1.105.1 + bob0.0.13
  • Node.js: 25.2.1
  • npm: 11.6.2
  • Claude Desktop: Claude 1.0.3218 (8679c9) — 2026-01-12T16:53:34.000Z

開発の始まり

以下のような指示と環境情報提供から始まりました:

ユーザーからの指示:
SQL Replication管理でやって欲しいことをDocument Centerのリンクを提示してみました。

以下を読んで、自然言語を使ったSQLレプリケーション管理ツールを作って欲しい。
クライアントはClaude Desktopを想定しています。

レプリケーション方法は単一方向のシンプルなものとします。

SQLレプリケーションの管理
https://www.ibm.com/docs/ja/idr/11.4.0?topic=program-asnclp-commands-sql-replication

キャプチャサーバーの始動
https://www.ibm.com/docs/ja/idr/11.4.0?topic=zos-asncap-starting-capture

キャプチャサーバーの操作
https://www.ibm.com/docs/ja/idr/11.4.0?topic=zos-asnccmd-operating-capture

アプライサーバーの始動
https://www.ibm.com/docs/ja/idr/11.4.0?topic=zos-asnapply-starting-apply

アプライサーバーの操作
https://www.ibm.com/docs/ja/idr/11.4.0?topic=zos-asnacmd-operating-apply

想定環境は、environments.txtに記述されています。

また手動フルリフレッシュについては、以下のファイルに従ったやり方で実施したい。
Manual full refresh using LOADX_TYPE=6 .md

環境情報(environments.txt):

キャプチャサーバー
ホスト名 : source.ibm.com
OS:Linux
ユーザー:db2inst1
データベースタイプ:IBM Db2
ソースDB : sample
レプリケーションタイプ: IBM SQL Replication
レプリケーション作業フォルダ: capture_work

アプライサーバー
ホスト名: target.ibm.com
OS:Linux
ユーザー:db2inst1
データベースタイプ:IBM Db2
ターゲットDB : sample
ソースDB リモートカタログDB : srcsampl
レプリケーションタイプ: IBM SQL Replication
レプリケーション作業フォルダ: apply_work

MCPサーバーを利用、クライアントはClaude Desktop

実際の開発の様子

最初のプロンプトを出した後、何回か質問が出るので答えていきます。
スクリーンショット 2026-01-15 14.17.34.png

作られたタスクは以下の通りで、段階的に自動実装していくのを眺めていくだけでした。

  1. プロジェクト構造とMCPサーバーの基本セットアップ
  2. SSH接続モジュールの実装(sourceとtargetへの接続)
  3. キャプチャサーバー制御テーブル作成機能の実装
  4. アプライサーバー制御テーブル作成機能の実装
  5. レプリケーション登録機能の実装(ソーステーブル登録、サブスクリプションセット作成、メンバー登録)
  6. レプリケーション登録の修正機能の実装(登録の追加、変更、削除、一覧表示)
  7. キャプチャサーバー起動・停止機能の実装
  8. アプライサーバー起動・停止機能の実装
  9. サーバーステータス確認機能の実装
  10. 手動フルリフレッシュ機能の実装(LOADX_TYPE=6方式)
  11. レプリケーション状況確認機能の実装
  12. エラーハンドリングとログ機能の実装
  13. README作成とClaude Desktop設定手順のドキュメント化

自動実装が完了したところです。

スクリーンショット 2026-01-14 17.44.21.png

最初の制御テーブル作成を試した段階でエラーが出たので
ASNCLPコマンドの間違いを指摘して修正してもらっている様子です。IBM SQL Replicationと伝えたつもりが Q Replicationになってしまっていました。

スクリーンショット 2026-01-14 17.44.37.png

こうして指示、修正を繰り返していきました。

自動生成されたものについて紹介していきます。

アーキテクチャ

システム構成図

system-architecture-diagram.png

主要コンポーネント

1. Claude Desktop

自然言語インターフェースを提供し、ユーザーからの指示を受け付けます。MCP Protocolを通じてMCPサーバーと通信します。

2. MCP Server (Node.js/TypeScript)

Claude Desktopとレプリケーションサーバー間の橋渡しを行います。以下の2つの主要モジュールで構成されています:

  • Tool Handlers(MCPツール実装):

    • 制御テーブル管理
    • レプリケーション設定
    • サーバー操作
    • 監視・メンテナンス
  • Core Modules: 実際の処理を担当

    • SSH接続管理(ssh2ライブラリ)
    • コマンド実行(ASNCLP, asncap, asnapply等)
    • DB2クエリ実行
    • エラーハンドリング

3. Replication Servers

SSH鍵認証を使用してMCPサーバーから接続されます:

  • Capture Server (source): ソースデータベースの変更をキャプチャ

    • DB2 Database
    • asncap(キャプチャプログラム)
    • 制御テーブル
  • Apply Server (target): ターゲットデータベースへ変更を適用

    • DB2 Database
    • asnapply(アプライプログラム)
    • 制御テーブル

プロジェクト構造

Bobが自動生成したプロジェクトの構造は以下の通りです:

ibm-sql-replication/
├── package.json                    # プロジェクト設定と依存関係
├── tsconfig.json                   # TypeScript設定
├── README.md                       # プロジェクトドキュメント
├── PLAN.md                         # 実装計画書
├── environments.txt                # 環境情報
├── Manual full refresh using LOADX_TYPE=6.md  # 手動フルリフレッシュ手順書
├── .gitignore                      # Git除外設定
└── src/
    ├── index.ts                    # MCPサーバーエントリーポイント
    ├── config/
    │   └── environment.ts          # 環境設定管理
    ├── ssh/
    │   ├── connection.ts           # SSH接続管理
    │   └── executor.ts             # コマンド実行
    ├── replication/
    │   ├── control-tables.ts       # 制御テーブル管理
    │   ├── registration.ts         # レプリケーション登録
    │   ├── capture.ts              # キャプチャサーバー操作
    │   ├── apply.ts                # アプライサーバー操作
    │   └── refresh.ts              # 手動フルリフレッシュ
    ├── monitoring/
    │   └── status.ts               # ステータス監視
    └── utils/
        ├── logger.ts               # ログ機能
        └── error-handler.ts        # エラーハンドリング

TypeScriptファイル12個、約4,200行のコードがBobによって自動生成されました。

レプリケーション管理ツール

作成されたレプリケーション管理ツールは以下の通りです:

制御テーブル管理

  1. キャプチャ制御テーブルの作成
  2. アプライ制御テーブルの作成
  3. キャプチャ制御テーブルの削除
  4. アプライ制御テーブルの削除
  5. キャプチャ制御テーブルの再作成
  6. アプライ制御テーブルの再作成

レプリケーション設定

  1. ソーステーブルの登録
  2. サブスクリプションセットの作成
  3. メンバーの追加
  4. 登録一覧の表示
  5. レプリケーション登録の削除
  6. サブスクリプションセットのアクティブ化
  7. サブスクリプションセットの非アクティブ化

サーバー操作

  1. キャプチャサーバーの起動
  2. キャプチャサーバーの停止
  3. アプライサーバーの起動
  4. アプライサーバーの停止
  5. サーバーステータスの確認

監視・メンテナンス

  1. 手動フルリフレッシュの実行(LOADX_TYPE=6方式)
  2. レプリケーション状況の確認
  3. ソーステーブル一覧の表示
  4. ターゲットテーブル一覧の表示
  5. APPLYTRAIL情報の取得

Claude Desktopを使ったフルリフレッシュの実施

実際に Claude Desktop を使用し、自然言語でフルリフレッシュまでの操作を試したので紹介します。
なお、Claude Desktop の設定や基本的な使い方については、ここでは割愛します。

管理ツールの確認

まずはどんなコマンドがあるか確認します。
スクリーンショット 2026-01-14 16.28.02.png

レプリケーション制御テーブルの作成

キャプチャ、アプライそれぞれの制御テーブルも一言で作ってもらえました。
スクリーンショット 2026-01-14 16.28.14.png

ソース表一覧の表示

レプリケーション対象の表を確認できます。
スクリーンショット 2026-01-14 16.28.23.png

レプリケーション定義の登録

EMPLOYEEテーブルにデータがあるようですのでこれを登録していきます。
ソース定義、サブスクリプションセット作成、サブスクリプションメンバー作成と続けていきます。自動的にキー列を検出してくれます。
スクリーンショット 2026-01-14 16.28.49.png

サーバーの起動

サーバー起動して、と言えば両方起動されます。最初の起動なのでキャプチャサーバーをCOLDモードでリクエストしました。
スクリーンショット 2026-01-14 16.29.12.png

結果の確認

しっかり42行のデータが同期されていることを確認できました。
スクリーンショット 2026-01-14 16.29.29.png

制御テーブルでの結果確認

APPLY_TRAIL表での確認もできました。
スクリーンショット 2026-01-14 16.30.13.png

サーバーの停止

サーバーも停止できました。
スクリーンショット 2026-01-14 16.29.41.png

まとめ

Bobによる開発で見られた特徴

Bobによる今回の実装を通じて、Bob には次のような開発スタイルと強みがあることが分かりました。

  1. 段階的な実装: 最初にプロンプトを与えると、Bob は自分なりに解釈して“まず動くもの”を生成してくれます。その後、生成されたコードを確認しながら、ユーザーとの対話を通じて修正や改善を重ね、少しずつ完成度を高めていくスタイルで開発が進みました。
  2. エラーハンドリングの実装: 各機能に必要なエラーハンドリングコードを適切に組み込み、例外発生時の処理や返却されるエラーメッセージが整理された形で実装されました。
  3. ベストプラクティスの適用: TypeScript の型安全性や非同期処理の扱いなど、基本的なベストプラクティスを押さえたコードを自動生成します。
  4. ドキュメントの充実: コード内コメント、README、実装計画書といったドキュメントを必要に応じて作成し、実装内容の意図や構造が後から読み返しやすい形に整理されました。
  5. 対話的なデバッグ: 実行時のエラーを伝えると、その場で状況を分析し原因の推測から修正も自動的に行ってくれるため、デバッグが非常にスムーズでした。
  6. 環境構築のサポート: Node.js や npm の準備、依存関係のセットアップなど、開発環境の構築も手順案内や手順書生成を通じてサポートしてくれました。
  7. インフラ設定の支援: SSH 鍵を用いた接続設定など、アプリケーション外の作業についても手順を提示したり、必要な手順書の自動生成まで行ってくれました。

Bobによる自動開発の成果

今回の目的は、SQL Replication の管理を自然言語だけで実行できる仕組みを作ることでした。
Bob の支援によって、この目的を 短時間でほぼ達成できた点が大きな成果です。

主な成果は以下のとおりです:

  1. 自然言語でレプリケーションを操作できるアプリケーションを実現
    「キャプチャサーバーを起動して」「レプリケーション状況を教えて」など、
    管理者が通常行っている複雑な操作を、自然言語だけで実行できるレベルにまで自動化できました。
    もともと ASNCLP/asncap/asnapply などのコマンド知識が必須だった作業が、
    シンプルな会話だけで完結 するようになったのは非常に大きな成果です。

  2. 完全自動生成による高速開発
    Bob はプロンプトをもとにアプリケーション全体を自動設計・自動実装し、試行錯誤を繰り返しながらも主要機能は 1日(約 8時間)でほぼ完成しました。

  3. 高品質なコード生成
    生成されたコードは TypeScript のベストプラクティスに沿った構造で、型安全性・非同期処理・エラーハンドリングが適切に実装されていました。

  4. ドキュメントの自動生成
    README、実装計画書、操作手順書が自動で整備され、アプリケーションの構造や使い方がすぐに理解できる状態になりました。

  5. 継続的な機能改善が容易
    「この機能を追加したい」「この動作を変えたい」と伝えるだけで、すぐに修正案とコードが生成され、開発サイクルが非常に短く回りました。

Bobを使ってみた感想

Bobを活用して開発を進める中で、以下の点を感じました:

  1. ドキュメント理解の難しさ: プロンプトで提示した URL の内容を完全に理解しきれない場面があり、SQL Replication と Q Replication が混ざってしまったり、存在しないパラメータやコマンドが生成されることがありました。そのため、正しいコマンドや SQL 文などをこちらから明示的に指示する必要がありました。
  2. 完全自動ではない: 一度のプロンプトで全機能が完成するわけではなく、必要な機能を一つずつ確認しながら、修正・追加を重ねていくプロセスは必須でした。自動生成とはいえ、「一緒に作り上げていく」感覚に近いです。
  3. “良いプロンプト”には工夫が必要:実装してほしい内容を細かく伝えないと意図と違う動作になることがあります。Bob に依頼する際は、「どう指示すれば自分の意図が伝わるか」を考えながら進める必要があり、ある意味、一人のエンジニアにタスクを依頼するのと似ています。
  4. 製品知識は依然として重要: レプリケーション管理のような複雑な領域では、設定変更や性能チューニングの誤りがシステム全体に影響する可能性があります。そのため、製品に精通した担当者によるレビューは欠かせません。
    (IBM Technology Expert Labs では、こうした製品特有の知識を活かして設計レビューから自動化まで包括的に支援しています。)
  5. Bobは一人の開発者のような存在: Bob とはまるで人間の開発者とペアプロしているような感覚があり、やり取りを重ねながら開発が進んでいくプロセスはとても楽しいものでした。今後は「一人で悩んで手が止まる」ことが減り、もっと効率よく開発ができそうだと感じています。

今後の展望

SQL Replication のような専門的な管理作業が、自然言語だけで実行できるようになった点は特に大きなブレイクスルーです。
今回の成果をきっかけに、レプリケーション以外の運用作業や周辺製品でも、Bob がどこまで活躍できるのか──その広がりを体験できるのが今から楽しみです。

※Bob の動作はプロンプトや環境に左右されます。本記事と同じ結果が得られない場合もありますが、ぜひ色々と試しながら、ご自身のユースケースに最適な活用方法を探してみてください。

参考資料


4
2
3

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
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?