はじめに
watsonx Orchestrate（wxO）とwatsonx.data（wxD）は同じIBMのサービスなので、wxDのデータをwxOから簡単に使えるだろうと思っていました。ところが調べてみると、定義済みのツールやコネクターにDB接続向けのものが見当たらず、自分でツールを作る必要があることに気付きました。
せっかくなので実際に手を動かして、エージェントからwxDの数値データにチャットで問い合わせする体験をしてみることにしました。
Pythonはほぼ素人なので、コードはClaude（生成AI）に手伝ってもらいながら作りました。詳細な手順やコードはGitHubにまとめています。
構成
やったこと
wxD上のIcebergテーブルにサンプルのIT運用データ（サーバーリソースメトリクス）を用意して、wxOのエージェントから自然言語で問い合わせできるようにしました。裏側ではPrestoエンジン経由でSQLが実行されます。
検討して決めたこと
OpenAPIではなくPythonツールにした
wxOのカスタムツールにはOpenAPI（YAML/JSON）とPythonの2種類があります。OpenAPIの方がシンプルで最初はそちらを試みたのですが、PrestoのREST APIが非同期のポーリング方式（nextURIを繰り返し取得する仕組み）のため、OpenAPIでは表現が難しいとわかりました。prestodbライブラリがポーリングを内部でうまく処理してくれるので、Pythonツールとして実装するのが素直な方法でした。
固定SQLツールとText2SQLツールを両方用意した
最初は「用途ごとにSQLを固定したツール」だけ作る設計にしました（例：CPU使用率Top3を返すツール）。LLMがSQLを生成する必要がなく安定しています。
一方で、任意のSQLを受け取って実行する汎用ツール（Text2SQLツール）も作ってみました。エージェントのBehaviorにテーブル定義を書いておくと、LLMが自律的にSQLを組み立てて実行してくれます。2種類のツールを同時に登録しておくと、質問の内容に応じてエージェントが自分でどちらを使うか選んでくれました。
ConnectionをKey-Value方式にした
wxOのConnectionはBasic AuthとKey-Value Pairが選べます。Basic Authだとusername/passwordしか持てず、接続先のhostやportはコードに直書きする必要があります。Key-Value方式にすると、host・port・username・passwordをすべてConnection側で管理できて、コードをすっきりさせることができました。
注意点
APIキーのusername形式
IBM Cloud SaaS版のwatsonx.dataに接続する場合、Prestoのusernameは ibmlhapikey_<IBMCloudのメールアドレス> という形式が必要です（公式ドキュメント：IBM watsonx.data Presto connection）。最初は ibmlhapikey だけで試していてエラーになりました。正確な値はwxDコンソールの接続情報JSONスニペットで確認できます。
TechZone環境を使う場合（参考）
IBM TechZoneのVM仮想環境版でも試しました。PrestoのポートがTechZoneによりリダイレクトされているため払い出し環境の記述ページでポートを確認する必要があること、自己署名SSL証明書のためコード側で証明書検証スキップの対応が必要なことがありました。IBM Cloud SaaS版ではこれらは不要です。
おわりに
wxOのPythonツールは @tool デコレーターを付けた関数のコードをADKでインポートするだけで動くので、思ったよりシンプルでした。生成AIにコードを手伝ってもらいながらですが、ここまで動くものが作れて満足しています。固定SQLツールとText2SQLツールを組み合わせた構成は、安定性と柔軟性のバランスがよくて気に入っています。
詳細な手順やサンプルコードはGitHubをご覧ください。
👉 https://github.com/matsuo-iguazu/wxo-wxDtools
（本記事は、執筆にあたりAnthropic Claudeを利用し、その出力を参考にしています。）