はじめに
「とりあえず、SlackからChatGPTを使えるようにしてほしい」
情報システム部門やDX推進チームの皆さんは、現場からこんなリクエストを受けることが増えているのではないでしょうか。確かに、APIキーを取得し、簡単なスクリプトを書けば、SlackとLLM（大規模言語モデル）をつなぐことは技術的に難しくありません。ネット上には数多くの記事があり、コードをコピー＆ペーストすれば、数時間でプロトタイプは動くでしょう。
しかし、対話設計やNLU（自然言語理解）の要件、そして業務フローとのバランスを考慮したアーキテクチャの観点から言えば、ここには大きな落とし穴が潜んでいます。
初期構築の容易さに目を奪われ、ユーザーの発話パターンに応じた適切な対話フローの調整や、エラー時のフォールバック設計など、「運用フェーズ」での持続可能性が置き去りにされているケースは珍しくありません。担当者が異動して誰もメンテナンスできなくなったPythonスクリプトや、エラーログの所在が分からないブラックボックス化したサーバーはその典型です。
さらに深刻なのが、生成AIの進化スピードに追従できない「硬直性」です。例えば、OpenAIのGPT-4o等の旧モデルが廃止され、新たな主力モデルへ移行する際、ハードコードされたシステムでは都度改修作業が避けられません。また、PC操作の自律化や長文推論能力が大幅に向上した他社の最新モデルを試してA/Bテストを行いたくても、APIの仕様違いによりコードを根本から書き直す必要が生じます。
これらはすべて、システムアーキテクチャの初期設計における「戦略不足」が招く技術的負債と言えます。
本記事では、ノーコードプラットフォームである「Make」を単なる自動化ツールとしてではなく、企業システムの「戦略的ハブ」として捉え直し、SlackとLLMを連携させるための設計思想を紐解きます。具体的なモジュールのつなぎ方よりも、なぜその構成にするのかという論理的な背景を深掘りし、変化の激しいAI技術に柔軟に対応できる基盤作りのヒントを提示します。
持続可能で、セキュアで、そして将来の拡張にも耐えうるAI連携基盤。その青写真を、共に描いてみませんか。
なぜ今、AI連携に「戦略的ハブ」が必要なのか
AI技術の進化スピードは凄まじく、昨日のベストプラクティスが明日には陳腐化することも珍しくありません。このような環境下で、システムをガチガチに作り込んでしまうことはリスクになります。ここで重要になるのが、システムの「疎結合（Loose Coupling）」という考え方です。
「とりあえず導入」が招く技術的負債
多くの開発現場で最初に行われるのが、Slackのボット機能とOpenAIのAPIを直接プログラムコード（PythonやNode.jsなど）でつなぐ「Point-to-Point（地点間）」連携です。これはシンプルで高速ですが、システム同士が密接に関わりすぎているため、片方の仕様変更がもう片方に即座に影響します。
例えば、社内のセキュリティポリシーが変わってAzure OpenAI経由での利用が必須になったり、特定の業務にはAnthropic社のClaudeシリーズ（最新モデル）を使いたいという要望が出たりしたとします。プログラムコードで直接連携している場合、これらの変更にはエンジニアによるコードの書き換え、テスト、デプロイ（本番環境への反映）が必要です。
さらに深刻なのは「属人化」です。そのコードを書いたエンジニアが不在になると、そのボットは誰も触れない「開かずの箱」となり、やがてエラーを吐き続けて停止するか、あるいは誰にも管理されないまま動き続ける「ゾンビボット」となります。これはセキュリティリスクそのものです。
API直接連携 vs iPaaS経由の比較論
そこで推奨したいのが、MakeのようなiPaaS（Integration Platform as a Service）を間に挟むアーキテクチャです。Makeは、異なるアプリケーション同士をつなぐ「ハブ（中継地点）」の役割を果たします。
SlackはMakeにメッセージを投げ、MakeがLLMに問い合わせ、その結果をSlackに返す。一見すると一手間増えているように見えますが、この構造には大きなメリットがあります。
- 可視化（Observability）: データの流れがグラフィカルに見えるため、対話フローの全体像を直感的に把握できます。
- 保守性（Maintainability）: エラーが発生した際、どの処理で止まったのかが視覚的に分かり、迅速なフォールバック対応が可能です。
- 柔軟性（Flexibility）: AIモデルを切り替えたい場合、Make上のモジュールを差し替えるだけで済みます。
変化の激しいAIモデルへの柔軟な対応力
現在、LLMの世界は群雄割拠です。特定のモデルにロックイン（依存）してしまうことは、企業の競争力を削ぐことになりかねません。
特に注意すべきは、モデルの「廃止（Deprecation）」と「移行」のサイクルです。かつて主力だったモデルでも、APIの提供が終了し、より高性能な後継モデルへの移行を余儀なくされるケースは珍しくありません。公式ドキュメントでも推奨モデルが頻繁に更新されるため、これらに追従し続けるコストは無視できないものになります。
Makeをハブにしておけば、「法務相談ボットには論理的思考に強いClaudeを」「コード生成ボットには高機能モデルを」といった使い分けや、あるいは「複数のモデルに同時に回答させてA/Bテストを行う」といった高度なフローも、ノーコードで素早く実装・変更が可能です。APIの仕様変更やモデルの廃止にも、モジュールの設定変更だけで柔軟に対応できます。
システム開発において「変更しやすい状態を保つ」ことは、実験と改善のサイクルを回す上で非常に重要な価値なのです。
Slack × LLM連携のアーキテクチャ設計原則
では、具体的にどのような構成にすべきでしょうか。単にメッセージを往復させるだけでなく、業務で使えるレベルの安定性と自然なユーザー体験（UX）を提供するための設計原則を見ていきましょう。
単なるチャットボットを超えた「エージェント」化
目指すべきは、単に応答するだけのボットではなく、ユーザーの発話意図（インテント）を正確に理解し、必要に応じてツールを使いこなす「エージェント（代理人）」としての振る舞いです。これを実現するために、システムを3つの層に分けて考えます。
- UI層（Slack）: ユーザーとの接点。入力の受付と結果の表示に徹する。
- ロジック層（Make）: 司令塔。ユーザーの入力を受け取り、どのAIモデルを使うか、あるいは社内データベースを検索するかなどの判断と対話フロー制御を行う。
- 頭脳層（LLM）: 推論エンジン。Makeから渡されたコンテキスト（文脈）に基づき、回答を生成する。
この役割分担を明確にすることで、例えば「UIをSlackからMicrosoft Teamsに変えたい」といった場合でも、ロジック層と頭脳層はそのまま再利用できます。
同期処理と非同期処理の使い分け
SlackとMakeを連携させる際、技術的に最も注意すべき点が「タイムアウト」です。SlackのEvent APIは、メッセージを受け取ったサーバーに対し、3秒以内にHTTP 200 OKのレスポンスを返すことを求めています。これを超えると、Slackは「送信失敗」と判断し、同じリクエストを何度も再送（リトライ）してきます。
LLMの回答生成には通常数秒から数十秒かかるため、まともに待っていると確実に3秒の壁を超え、Make側では同じ処理が何度も走る「多重起動」が発生します。結果、Slackには同じ回答が何度も投稿されるという、不自然な挙動になります。
これを防ぐための設計パターンが「非同期処理」です。
- Makeの最初のシナリオ（Webhook受信）は、リクエストを受け取ったら即座に「受け付けました（HTTP 200）」だけをSlackに返し、処理を終了するか、別のシナリオにデータを渡します。
- 実際のLLMへの問い合わせや重い処理は、ユーザーを待たせずに裏側（バックグラウンド）で実行します。
- 処理が完了次第、MakeからSlackへプッシュ通知で回答を投稿します。
この「受付」と「実行」を切り離す設計は、ユーザー体験を損なわず、かつシステムリソースを無駄にしないための鉄則です。
コンテキスト管理の戦略的設計
人間同士の会話には文脈があります。「それを要約して」と言われたとき、「それ」が何を指すのかは直前の会話に依存します。しかし、基本的にLLMのAPIは「ステートレス（記憶を持たない）」です。毎回、過去のやり取りを含めて送信しなければなりません。
Makeでこれを実装する場合、どこに「記憶（会話履歴）」を持たせるかが対話設計の肝になります。
- 簡易的な方法: Slackのスレッド内のメッセージを取得し、テキストとして連結してLLMに投げる。実装は楽ですが、スレッドが長くなるとトークン数（課金対象の文字数）が膨大になり、コストがかさむ上にLLMの入力制限に引っかかる可能性があります。
- 本格的な方法: 会話IDをキーにして、MakeのData Storeや外部データベース（Google Sheets, Airtable, Vector DBなど）に要約した履歴を保存する。毎回全てのログを送るのではなく、重要な文脈だけを取り出してLLMに渡す設計です。
業務利用を想定するなら、トークン節約と対話の自然さを両立する観点から、後者のような「外部記憶」を持つ構成を検討すべきでしょう。これは、後述するRAG（検索拡張生成）への布石にもなります。
ガバナンスと可観測性の確保
企業導入において、技術的な実現性以上にハードルとなるのが「セキュリティ」と「ガバナンス」です。「社員が機密情報をAIに入力してしまわないか」「APIの利用料が青天井にならないか」。情報システム部門が抱くこれらの懸念に対し、Makeをハブにすることで論理的な解決策を提示できます。
ブラックボックス化を防ぐログ監視体制
APIを直接叩くスクリプト開発では、ログの保存や閲覧のための仕組みを別途作り込む必要があります。しかしMakeには、標準で詳細な「Execution History（実行履歴）」機能が備わっています。
いつ、誰が、どんなプロンプトを送信し、AIがどう返したか。入出力のデータがすべて記録されます。このログはトラブルシューティングに役立つだけでなく、ユーザーの発話パターンを分析し、対話フローを改善するための貴重なデータソースとなります。
さらに一歩進んで、Makeのシナリオ内に「監査ログ保存モジュール」を組み込むことをお勧めします。例えば、LLMとのやり取りをすべて外部データベースに自動で書き出すように設定します。これにより、管理者は定期的にログを分析し、利用状況のモニタリングが可能になります。
個人情報・機密情報のフィルタリング戦略
「AIに個人情報を渡さない」というルールをユーザーのモラルだけに頼るのは危険です。システム側で安全弁（ガードレール）を設けるべきです。
Makeのフローの中で、Slackから受け取ったテキストをLLMに投げる「前」に、フィルタリング処理を挟むことが可能です。
- 正規表現によるチェック: クレジットカード番号やマイナンバーなどのパターンにマッチする文字列が含まれていないかチェックする。
- PII検出APIの利用: 専用の個人情報検出AIを経由させ、機密情報が含まれている場合はマスキング（黒塗り）するか、処理を中断して適切なフォールバックメッセージをユーザーに返す。
このように、LLMにデータが渡る前の「前処理（Pre-processing）」を自由に設計できるのが、iPaaSを介在させる大きなメリットです。
利用コストの可視化と制御
LLMのAPI利用料は従量課金制が一般的です。予期せぬ大量利用や、無限ループによる暴走を防ぐための「リミッター」もMake上で設計できます。
例えば、MakeのData Storeを使って、ユーザーごとの1日の利用回数や推定トークン量をカウントします。設定した閾値を超えた場合、「本日の利用上限に達しました」と返信し、APIへのリクエストをブロックするロジックを組み込みます。
また、API管理画面のアラート機能と併用しつつ、Make側でも部門ごとの利用量を集計して日次レポートを自動送信するなど、コストの「見える化」を徹底することで、安心して全社展開に踏み切ることができます。
拡張を見据えたモジュール型開発アプローチ
初期リリースが成功すると、必ず「あれもしたい、これもしたい」という要望が出てきます。このとき、1つの巨大なMakeシナリオにすべての機能を詰め込むと、メンテナンスが困難な「スパゲッティ・シナリオ」ができあがります。これを防ぐのが「モジュール型開発」です。
機能のマイクロサービス化
プログラミングにおける「関数」のように、Makeのシナリオも機能ごとに分割しましょう。
- ルーター（振り分け）シナリオ: Slackからの入力を受け取り、ユーザーの意図（インテント）を判定して適切なサブシナリオへデータを転送する役割。
- 翻訳シナリオ: テキストを受け取り、翻訳して返す。
- 要約シナリオ: 長文を受け取り、要点をまとめて返す。
- 検索シナリオ: 社内DBを検索して結果を返す。
各シナリオ間は「HTTP Request」モジュールや「Webhook」を使って連携させます。こうすることで、特定の対話ロジックだけを修正したい時に、他の機能に影響を与えずに安全に変更が可能になります。
他SaaS（Notion, Google Drive）との連携ロードマップ
SlackとLLMがつながったら、次は社内のナレッジベースとの連携が視野に入ります。Makeは多数のアプリと連携可能です。
例えば、Notionに蓄積された日報や、Google Drive上の仕様書を参照させたい場合、Makeを経由すれば比較的スムーズに実装できます。ただし、ここで重要になるのが「非構造化データの構造化」です。
単に全データをLLMに投げても、文脈が繋がらず業務要件を満たす回答は得られません。Makeを使ってデータの更新をトリガーに取得し、LLMが理解しやすい形（チャンク化など）に加工してVector Databaseに保存する。この「データパイプライン」を構築することが次のステップになります。
RAG（検索拡張生成）統合への準備
上記の流れは、まさに現在主流となっているRAG（Retrieval-Augmented Generation）アーキテクチャそのものです。RAGとは、LLMが学習していない社内固有の情報を外部から検索し、その情報をヒントとして与えることで回答精度を高める技術です。
Makeを中心に据えた設計をしておけば、最初は単純なチャットボットからスタートし、ユーザーテストを通じて徐々に社内ドキュメント検索機能を追加し、最終的には自律的にタスクをこなすエージェントへと、段階的に進化させていくことができます。
組織への定着と文化醸成のステップ
素晴らしいアーキテクチャを構築しても、実際にユーザーに使われなければ意味がありません。システム開発と同じくらい重要なのが、組織への「定着化戦略」です。
「魔法」ではなく「道具」としての期待値調整
AIに対する過度な期待は、失望を生む原因になります。「何でも完璧に答えてくれる魔法」だと思って使い始めたユーザーは、一度でも的外れな回答（ハルシネーション）が返ってくると離脱してしまいます。
導入初期には、「AIはあくまでアシスタントであり、最終確認は人間が行う必要があること」「得意なことと苦手なこと」を明確に伝えるコミュニケーションが不可欠です。正しい期待値をセットし、ユーザーテストと改善のサイクルを回す土壌を作りましょう。
プロンプトエンジニアリングの社内標準化
「AIが賢くない」と感じる原因の多くは、実は「指示の出し方（プロンプト）」にあります。曖昧な指示には曖昧な回答しか返ってきません。
「役割を与える」「出力形式を指定する」「参考情報を与える」といった基本的なプロンプトエンジニアリングのテクニックを社内で共有しましょう。さらに、Makeの設計側で、ユーザーの短い入力を受け取った後、裏側でシステムプロンプトを自動付加することで、ユーザーのスキルに依存せず回答品質を底上げする工夫も有効です。
フィードバックループの構築と改善サイクル
最後に、ユーザーからのフィードバックを集める仕組みを作りましょう。Slackボットの回答に対して「Good/Bad」ボタンをつけたり、専用の要望チャンネルを設けたりします。
集まったフィードバックとMakeのログを照らし合わせ、「どのプロンプトで失敗したのか」「ユーザーの発話パターンにどのような傾向があるのか」を分析します。この実験と改善のサイクルを回し続けることこそが、業務要件を満たし、実際に使われるAIを育てる唯一の道です。
まとめ
SlackとLLMの連携において、MakeのようなiPaaSをハブとして配置することは、単なる開発工数の削減以上の意味を持ちます。それは、変化の激しいAI技術に追従できる「柔軟性」、ブラックボックス化を防ぐ「透明性」、そしてセキュリティを守る「ガバナンス」を担保するための論理的な戦略判断です。
直接コードを書くことの自由度も理解できますが、組織として持続可能なシステムを残すためには、あえて「作らない勇気」を持ち、既存のプラットフォームを賢く組み合わせるアーキテクチャ設計が求められています。
今日からできる第一歩として、まずは現在稼働しているボットや自動化スクリプトが、誰にでもメンテナンス可能で、ユーザーのニーズに応じた対話フローの改善が容易な状態かを見直してみてはいかがでしょうか。
持続可能で、ユーザーに実際に使われるAI連携基盤を構築するためには、継続的な検証と改善のサイクルが不可欠です。共に実用的なAIの形を模索していきましょう。
コメント