はじめに

IBM製品の発表レターを毎朝Slackへ届ける日次ワークフローを、主にIBM webMethods IntegrationとAIエージェント使用して作りました。

製品の発表レター、サポート終了、セキュリティ情報、新機能の案内などを定期的に確認する作業は、重要ではあるものの手作業では続けにくいものです。

そこで本記事では、IBM webMethods Hybrid Integration（IWHI）の機能の1つであるIBM webMethods Integrationと、社内ですでに利用可能なAIエージェントを組み合わせて、次の処理を自動化した例を紹介します。

毎日決まった時刻に処理を開始する
IBM Docsの発表レターを製品名で検索する
AIエージェントが対象製品との関連性を判定する
発表を日本語2文で要約し、重要度を付ける
Slack WorkflowのWebhookを通じて指定チャンネルへ投稿する

この記事の主役は特定のAI基盤ではありません。HTTP経由で呼び出せて、検索などのToolを利用できるAIエージェントであれば、各社で利用中の基盤へ置き換えられます。

なぜwebMethods IntegrationとAIエージェントを組み合わせるのか

AIエージェントだけでも、検索、判定、要約、通知を一連の処理として実行できます。しかし本番運用では、すべてをAIに任せるより、役割を分ける方が安全で安定します。

webMethods Integrationが得意なこと	AIエージェントが得意なこと
毎日決まった時刻の起動	表記揺れを含む関連性判断
タイムゾーンを考慮した対象日の計算	検索結果の意味理解
HTTPリクエストと認証ヘッダー	複数検索結果の整理
同時実行の制御	重要度の分類
実行ログとエラー確認	人が読みやすい日本語要約

この分担により、決められた時刻・対象日・実行モードはワークフローで固定し、内容の理解が必要な部分だけをAIに任せる構成にできます。

今回作成してみたもの

IBM製品の発表レターを監視する日次ワークフローです。システム全体の構成は次のとおりです。

各システムの役割を整理すると次のとおりです。

システム	役割
IBM webMethods Integration	毎日決まった時刻に起動し、対象日をAIエージェントへ渡す
既存のAIエージェント	発表を検索・判定・要約し、Slackへ通知する
IBM Docs	製品の発表レターを返す
Slack Workflow	受け取った情報を見やすいメッセージに整形して投稿する

実装例では、IBM Cloud Pak for Integration、IBM webMethods Hybrid Integration、IBM App Connect Enterprise、IBM MQ、IBM Aspera、IBM DataPower Gatewayなど、12の製品ファミリーを監視しています。別名も検索するため、AIエージェントは1回の実行で14種類の検索語を使います。

たとえば、以下のような別名を考慮します。

正規化後の製品名	検索に使う表記例
IBM App Connect Enterprise	`IBM App Connect Enterprise`、`IBM App Connect`
IBM webMethods MFT	`IBM webMethods MFT`、`webMethods Managed File Transfer`

検索結果に同じ発表が複数回現れても、URLキーなどを使って同一実行内では1件にまとめます。

実際にSlackへ届いた通知の例です。

IBM webMethods Hybrid Integration（IWHI）とは

IBM webMethods Hybrid Integrationは、アプリケーション、API、イベント、メッセージ、ファイル、B2Bなどの統合を、ハイブリッド／マルチクラウド環境で扱うための統合プラットフォームです。

IBMの製品ページでは、主なプラットフォーム・ケイパビリティとして、Application integration、API management、Event management、Managed file transfer、B2B integrationが挙げられています。

参考：IBM webMethods Hybrid Integration

今回利用したIBM webMethods Integrationは、このうちApplication integrationを担うケイパビリティです。

IBM webMethods Integrationとは

IBM webMethods Integrationは、アプリケーションやサービスを接続し、定義した条件とアクションをワークフローとして自動実行するための統合機能です。IBMの説明では、クラウドからオンプレミスまでの統合の設計、デプロイ、管理を支援し、データ同期、アプリケーション接続、ワークフロー自動化などに対応します。

参考：IBM webMethods Integration、Product Overview

ワークフローは、簡単に言えば「サービスAでイベントが起きたら、サービスBのアクションを実行し、必要ならサービスCへデータを渡す」という処理の組み合わせです。設定後はwebMethods Integrationが自動的に実行します。

参考：Working with workflows

今回の構成では、webMethods Integrationに次の処理を任せました。

毎日09:00（Asia/Tokyo）に起動する
日本時間の前日をYYYY-MM-DD形式で計算する
実行モードと対象日をAIエージェントへ渡す
HTTP応答とエラーを実行ログへ残す
前回処理が長引いた場合の同時実行を防止する

ここで重要なのは、日付やスケジュールのような決定的な処理をAI任せにしないことです。

Slack WorkflowのWebhookとは

Slack Workflow Builderでは、Slackの外部からWebhookでワークフローを開始できます。外部システムがWebhook URLへJSONをPOSTすると、その値をワークフロー内の変数として使い、指定チャンネルへメッセージを投稿できます。

参考：Build a workflow: Create a workflow that starts outside of Slack

今回受け取る変数は次の6項目です。

{
  "product": "IBM MQ",
  "title": "Announcement title",
  "announcement_date": "2026-07-17",
  "summary": "日本語要約1文目です。日本語要約2文目です。",
  "priority": "Medium",
  "url": "https://www.ibm.com/docs/en/announcements/example"
}

Slack側では、これらの変数を上記（「この記事で作るもの」のSlack通知画像）のような投稿へ整形します。

なぜSlackへ直接投稿せず、Workflowを挟むのか

この方式には次のメリットがあります。

AIエージェントは「通知データを渡す」ことだけに集中できる
投稿先チャンネルや表示形式をSlack側で変更できる
通知本文のレイアウトを、Agentのプロンプトから分離できる
Slack側のワークフロー管理者が投稿処理を管理できる
LegacyなIncoming Webhookが利用できない環境でも、WorkflowのWebhookトリガーを利用できる場合がある

ただし、Webhookトリガーの利用可否はSlackプランや組織の管理ポリシーに依存します。利用できない場合はSlack管理者への確認が必要です。また、Webhook URLは知っている人が処理を開始できるため、パスワードと同様に秘密情報として扱います。

実装の流れ

1. SlackでWebhook起動のワークフローを作成する

Slack Workflow Builderで新しいワークフローを作成する
開始条件にWebhookを選ぶ
product、title、announcement_date、summary、priority、urlを変数として定義する
「チャンネルへメッセージを送信」ステップを追加する
6変数をメッセージへ配置する
投稿先チャンネルを指定して公開する
発行されたWebhook URLを安全な場所へ保管する

2. AIエージェントへToolを用意する

使用するAI基盤は問いませんが、少なくとも次の2つのToolが必要です。

発表レター検索Tool

IBM Docsの発表レター検索画面が内部で利用している検索エンドポイントを呼び出します。

GET https://www.ibm.com/docs/api/v1/search/announcements

今回確認した範囲では、このエンドポイントについて正式に公開されたAPI ReferenceやOpenAPI仕様は見つけられていません。

そのため今回は、IBM Docsの発表レター検索画面が利用しているJavaScriptとHTTP通信を確認して検索エンドポイントを特定し、実際のリクエストと応答JSONを検証したうえでTool化しています。

Toolへの代表的な入力例は次のとおりです。

{
  "query": "IBM MQ",
  "locale": "en",
  "limit": 20
}

各入力項目の用途は次のとおりです。

項目	用途
`query`	検索するIBM製品名やキーワード
`locale`	検索言語。今回の実装では主に`en`を使用
`limit`	1回の検索で取得する最大件数

実際の応答JSONは、次のような構造になっています。以下は今回の実装で使用する部分を抜粋した例です。

{
  "hits": 1,
  "start": 0,
  "previous": -1,
  "next": -1,
  "topics": [
    {
      "title": "IBM Integration Confluent add-on enables organizations to seamlessly integrate event streaming capabilities with IBM Cloud",
      "snippet": "organizations to seamlessly integrate event streaming capabilities with IBM Cloud Pak for Integration and IBM webMethods Hybrid Integration...",
      "date": "2026-07-14",
      "fullurl": "https://www.ibm.com/docs/en/announcements/integration-confluent-add-enables-organizations-seamlessly-integrate-event-streaming-capabilities-cloud-pak-integration-webmethods-hybrid-integration",
      "urlKey": "integration-confluent-add-enables-organizations-seamlessly-integrate-event-streaming-capabilities-cloud-pak-integration-webmethods-hybrid-integration",
      "product": {
        "label": "IBM Integration Confluent add-on enables organizations to seamlessly integrate event streaming capabilities with IBM Cloud Pak for Integration and IBM webMethods Hybrid Integration"
      }
    }
  ]
}

検索結果はtopics配列に格納されます。今回の実装では、topics配列の各要素から主に次の項目を使用しています。

応答項目	今回の用途
`title`	発表レターのタイトル
`snippet`	製品との関連性判定と日本語要約の根拠
`date`	指定された通知対象日との照合
`fullurl`	Slackへ掲載するIBM公式ページのURL
`urlKey`	同じ発表を複数回送らないための重複判定
`product.label`	製品との関連性判定を補助する情報

snippetは発表レターの全文ではなく、検索語の周辺を切り出した短い抜粋です。文の途中から始まる、末尾が省略される、<b>などのHTMLタグが含まれる場合があります。

そのため、今回の日本語要約は、主にtitle、snippet、date、product.labelを根拠として生成しています。より詳細で正確な要約が必要な場合は、候補を絞り込んだ後に公式ページ本文を取得する処理を追加する必要があります。

注意

このエンドポイントについて、正式に公開されたAPI Referenceや互換性保証は確認できていません。IBM Docsサイト内部の仕様変更により、エンドポイント、入力パラメーター、応答形式が変更される可能性があります。
本番運用では、HTTPステータス、JSON解析、topicsの存在、必須項目の有無を確認し、想定外の応答を受け取った場合は通知せず安全に終了する実装が必要です。

Slack通知Tool

Slack WorkflowのWebhook URLへ6項目をPOSTします。Webhook URLをTool定義や画面キャプチャで外部公開しないよう注意してください。

3. AIエージェントの処理ルールを定義する

Agentには次の順序を明示します。

入力されたtarget_announcement_dateがYYYY-MM-DD形式か確認する
不正または未指定なら、検索も通知もせず終了する
設定された製品名・別名で検索する
検索結果を統合する
HTMLタグを除去し、対象製品との関連性を判定する
別名を正規製品名へ統一する
発表日がtarget_announcement_dateと完全一致するものだけを残す
urlKey、URL、タイトル＋日付の順で重複を除く
重要度をHigh／Medium／Lowに分類する
日本語2文で要約する
実行モードがPRODUCTIONの場合だけSlackへ送る

4. 重要度を分類する

重要度は、検索結果に書かれている根拠だけで判定します。

重要度	判定例
High	Security、CVE、Vulnerability、サポート終了、必須移行、重大なライセンス・価格影響
Medium	新製品、新しいアドオン、Release、Version、新機能、提供開始
Low	情報提供、ドキュメント訂正、小規模更新

「重要そうだから」という推測だけでHighにしないことがポイントです。

5. webMethods Integrationで日次ワークフローを作成する

ワークフローは概ね次の3ステップです。

実際のwebMethods Integrationのワークフロー画面は次のとおりです。

左から順に、Repeat-from（スケジュール起動）→ Format Date and Time（日付計算）→ HTTP Request（AIエージェント呼び出し）の3ステップで構成されています。

AIエージェントへ送るmessageの例です。

{
  "message": "execution_mode: PRODUCTION\ntarget_announcement_date: 2026-07-14\n\n設定されたすべての製品検索を実行してください。announcement_dateがtarget_announcement_dateと完全一致する一意の発表だけを通知してください。それ以外の日付は絶対に送信しないでください。一部の検索が失敗しても残りを続行してください。"
}

HTTP Requestでは、各AI基盤のエンドポイント、APIキーまたはトークン、Content-Type: application/jsonを設定します。具体的なURLや認証方式は利用するAI基盤に合わせてください。

安全に本番化するための3つの実行モード

いきなり本番送信するのではなく、次のモードを用意しました。

モード	動作
DRY_RUN	検索・判定・要約まで実行するがSlackへ送らない
TEST_SEND_ONE	条件一致する発表を最大1件だけSlackへ送る
PRODUCTION	条件一致する一意の発表をSlackへ送る

推奨テスト順は次のとおりです。

Slack WorkflowのWebhookを単体テストする
IBM Docs検索Toolを単体テストする
AgentをDRY_RUNで実行し、検索数、対象日、候補を確認する
過去に発表が存在すると分かっている日を指定し、DRY_RUNで候補が出ることを確認する
TEST_SEND_ONEでSlackの表示を確認する
webMethods IntegrationからDRY_RUNでAgentを呼ぶ
問題がなければ毎日09:00のPRODUCTIONへ切り替える

重複通知について

今回のAgentは、同じ実行の中で複数の検索語に同じ発表が現れた場合、その発表を1件にまとめます。

一方、異なる実行をまたぐ通知履歴は保存していません。日次実行で「前日分だけ」を対象にすれば通常の重複は抑えられますが、同じ対象日でPRODUCTIONを手動再実行すると再送される可能性があります。

厳密な一度だけの送信が必要なら、次の永続ストアを追加します。

urlKeyを履歴ストアで確認
    ↓
未送信の場合だけSlackへ送信
    ↓
Slack成功後にurlKeyと送信時刻を保存

データベース、Key-Value Store、社内APIなど、運用環境で利用できる永続ストアへ置き換えられます。

導入して感じたメリット

1. AIエージェントを「業務の中」で動かせる

AIエージェントをチャット画面で使うだけでなく、webMethods Integrationから定期的に呼び出すことで、既存業務フローの一部として運用できます。

2. 既存のAIエージェントを再利用できる

特定のAIサービスへ固定せず、HTTP APIとTool Callingに対応した社内Agentを利用できます。Agentが変わっても、webMethods側のスケジュールやSlack側の表示を大きく変えずに済みます。

3. 自然言語処理と決定的処理を分離できる

製品名の表記揺れ、関連性、要約はAIが得意です。一方、日時計算、認証、再試行、同時実行制御は統合基盤が得意です。両者を組み合わせることで、それぞれの強みを活かせます。

4. 通知先の変更をSlack側へ閉じ込められる

チャンネルやメッセージ形式を変更するとき、Agentのロジックを変更せずSlack Workflowだけを編集できます。

5. DRY_RUNから段階的に本番化できる

「検索結果は正しいか」「古い発表を送らないか」「Slackの表示は正しいか」を段階的に確認でき、誤送信リスクを下げられます。

運用上の注意

AI基盤のAPIキーやアクセストークン、Slack Webhook URL、Agentの非公開エンドポイントを記事、リポジトリ、スクリーンショットへ含めない
Webhook URLが写った過去の画面キャプチャは、公開前に必ずマスクする
target_announcement_dateが不正な場合はfail closed、つまり何も送らず停止する
Slack投稿の成功後だけ通知済み履歴を保存する
AIの出力件数だけを信用せず、検索Toolの実行ログも確認する
snippetは全文ではないため、重要な判断に使う場合は公式ページ本文も確認する
Slack Workflowの利用可否やWebhook権限は組織の管理者に確認する

まとめ

今回の構成では、IBM webMethods Integrationが「いつ、どの日付を対象に、どのAgentを起動するか」を管理し、AIエージェントが「どの発表が関係するか、どう要約するか」を担当し、Slack Workflowが「どこへ、どの形式で投稿するか」を担当します。

つまり、3者の役割は次のように整理できます。

webMethods Integration：業務フローを確実に動かすオーケストレーター
既存のAIエージェント：非構造的な情報を検索・理解・要約する判断エンジン
Slack Workflow：利用者へ届ける通知インターフェース

webMethods IntegrationとAIエージェントを組み合わせることで、AIを単発のチャットから、毎日動く業務プロセスへ組み込めます。今回は製品アナウンスの監視を題材にしましたが、同じパターンは、障害情報、法改正、競合ニュース、サポート期限、社内ナレッジ更新などにも応用できます。
さらに、IWHIはオンプレミス環境からクラウド環境まで幅広く対応しているため、既存システムやSaaSを含むさまざまなシステムと柔軟に連携でき、AIを組み込んだ業務自動化を企業全体へ拡張していくことが可能です。

💡 AIを活用したTips

今回の構築では、生成AI（IBM Bobなど）を、設計・実装・テストを支援する壁打ち相手として活用しました。

システム間連携では、接続先ごとの仕様、認証、JSON Schema、日付処理、エラー対応など、確認すべき項目が多くあります。生成AIへ目的、設定画面、エラーログ、実行結果を共有することで、調査や試行錯誤を対話形式で進められました。

AIの提案をそのまま本番へ適用したのではなく、次の流れを繰り返しています。

やりたいことをAIへ伝える
        ↓
構成案・設定案を整理する
        ↓
実際の環境で設定・テストする
        ↓
画面やログをAIへ共有する
        ↓
原因と修正案を整理する
        ↓
再度テストする

以下は、今回AIが特に役立った場面です。

① 曖昧なアイデアをシステム構成へ落とし込む

最初は、「IBM製品の発表レターを確認し、AIで要約して、毎朝Slackへ送りたい」というアイデアから始まりました。

AIへの相談例：

IBM Docsに対象製品の新しい発表が掲載された場合、内容を日本語で要約し、毎朝Slackへ自動通知したいです。
webMethods Integrationを使う場合、どのような構成が考えられますか？

AIとの対話を通じて、各システムの役割を次のように整理しました。

webMethods Integration：日次起動、対象日計算、AIエージェントの呼び出し
AIエージェント：検索、関連性判定、重複排除、重要度判定、要約
Slack Workflow：Webhook受付、メッセージ整形、チャンネル投稿

「どの製品に何を担当させるか」が曖昧な段階でも、構成案を比較しながら整理できました。

② 制約が判明したときの代替案を検討する

当初はSlack Incoming Webhookの使用を想定していましたが、利用環境では使用できないことが分かりました。

AIへの相談例：

Slack Incoming Webhookが使えない環境です。
外部システムから値を渡して、指定チャンネルへメッセージを投稿する別の方法はありますか？

この相談をきっかけに、Slack Workflow BuilderのWebhookトリガーを利用する構成へ変更しました。

AIを壁打ちに使うことで、最初の案が実現できない場合も、目的を維持した代替手段を検討しやすくなります。

③ 設定画面・YAML・JSON Schemaの作成を支援してもらう

AI AgentやToolを構成する際には、Input Schema、Output Schema、Toolの説明、Agent構成用YAMLなど、多くの設定が必要でした。

AIへの相談例：

この検索結果のJSONから、AIエージェントが利用するToolのOutput Schemaを作成してください。
Agentが余計なパラメーターを送らないよう、Toolの入力項目も整理してください。

実際の応答JSONをAIへ渡し、次のような項目を整理しました。

Toolへ渡すquery、locale、limit
応答のtopics
title、snippet、date
fullurl、urlKey
product.label

画面の項目名だけでは設定方法が分かりにくい場合でも、実際のJSONや画面キャプチャを共有することで、入力すべき値を具体化できました。

④ エラーログから原因と修正案を整理する

構築中には、YAMLの構文エラー、HTTP 422、Tool呼び出しエラーなどが発生しました。

AIへの相談例：

Agent構成用YAMLを登録すると、次のエラーが表示されました。
エラーの原因と、修正する箇所を教えてください。

YAML syntax error at line 151, column 42

また、HTTPリクエストが失敗した場合には、ステータスコード、レスポンス本文、送信したJSONを共有し、期待されているデータ型との違いを確認しました。

AIはエラーを自動的に修正するものではありませんが、長いログから確認すべき箇所を絞り込み、次に試す修正案を整理する用途で役立ちました。

⑤ 実行結果をもとに安全な運用設計へ改善する

テスト中には、対象日ではない古い発表がSlackへ送られることがありました。

AIへの相談例：

通常は最新情報が送られますが、今回は前年の発表がSlackへ送信されました。
Agentの出力、Slack通知、webMethodsの実行ログから、原因として考えられる点を整理してください。

ログを確認しながら、次のように構成を改善しました。

現在日付の計算をAIエージェントに任せない
webMethods Integrationで日本時間の対象日を確定する
target_announcement_dateをAgentへ明示的に渡す
発表日が対象日と完全一致するものだけを候補にする
対象日が欠落または不正な場合は、検索・通知を行わず停止する
DRY_RUN、TEST_SEND_ONE、PRODUCTIONを分ける

AIとの対話は、単にエラーを直すだけでなく、「どのシステムがどの責任を持つべきか」を見直すためにも活用できました。

⑥ テストケースと確認観点を作る

本番前には、AIへ正常系・異常系のテスト観点を整理してもらいました。

今回確認した主なテストは次のとおりです。

テスト	確認内容
Slack単体テスト	6項目が正しく投稿されるか
検索Tool単体テスト	検索結果とJSON構造を取得できるか
DRY_RUN	Slackへ送らず候補を抽出できるか
過去日指定テスト	発表が存在する日を正しく抽出できるか
日付不正テスト	検索前に安全停止するか
TEST_SEND_ONE	最大1件だけ投稿されるか
PRODUCTION	対象日の発表だけを投稿するか

テスト結果をAIへ戻して確認することで、想定どおりの成功なのか、部分的な失敗を含んでいるのかを整理しやすくなりました。

⑦ 構築内容を手順書や記事として整理する

構築後は、設定内容、判断理由、テスト結果、既知の制約をAIへ渡し、README、構築手順書、Qiita記事として整理しました。

AIへの相談例：

今回作成した仕組みを、初めて触る人でも再構築できる手順書にしてください。
webMethods Integration、AIエージェント、Slackの設定を分けて説明してください。

設定を完成させるだけでなく、次の担当者が再現できる形へ残す作業にもAIを活用できます。

ただし、生成された文書にAPIキー、Webhook URL、社内URL、個人情報などが含まれていないかは、人が必ず確認する必要があります。

生成AIを使えば、アイデアの整理、構成案の比較、設定項目の理解、エラー原因の切り分け、テストケースの作成を対話形式で進められるため、システム間連携に取り組む際の最初のハードルを下げられます。

今回のように、webMethods Integrationが確実な処理とシステム接続を担い、AIが設計・判断・要約を支援することで、アイデアを比較的短期間で動く形へ近づけることができます。

参考リンク

本記事の画面名・機能名・利用条件は執筆時点のものです。利用環境のバージョン、契約、管理ポリシーによって表示や利用可否が異なる場合があります。