【賢いMCP-Slackボット開発連載-1】AIが会話をすぐ忘れる問題。「Model Context Protocol」で賢いボットの土台を築く

あなたのSlackボット、期待通りに「賢く」動いていますか？

あなたのチームのSlackワークスペースに、最新のLLM（大規模言語モデル）を搭載したピカピカのAIボットを導入したとしましょう。ちなみに、この連載は4回です。

メンバーが質問を投げかけると、驚くほど的確な答えが返ってきます。チームの生産性は爆上がりだ！…と、そう思ったのも束の間。

• メンバーA: 「@￰AIボット、今度のプロジェクトのアイデアを5つ出して」

• AIボット: 「承知しました。1. 〇〇、2. 〇〇、…」

• メンバーA: 「@￰AIボット、ありがとう！その中の3つ目について、もっと詳しく教えて」

• AIボット: 「申し訳ありません、どのアイデアについてでしょうか？文脈が不明なため、お答えできません。」

あるいは、重要な会議の議事録スレッドで「@￰AIボット、この議論を要約して」とお願いしたのに、数回のやり取りの後には、自分が要約タスクを頼まれていたことすら忘れて、雑談を始めてしまう。

このような「残念なAIボット」の姿は、多くの開発者が一度は経験する壁ではないでしょうか。

この連載は、そんな「忘れっぽい」AIボットから脱却し、会話の文脈を正しく理解し、チームの真のアシスタントとして機能する「賢い」Slackボットをゼロから開発するための実践的なガイドです。

そして、その成功の鍵は、LLMのモデル選定やプロンプトの小手先の工夫だけにあるのではありません。ボットの「記憶」と「思考」の仕組み、その土台となる設計思想にあります。

本シリーズ第1回となるこの記事では、本格的な実装に入る前に、最も重要なその「土台」——Model Context Protocol (MCP)——について、なぜそれが必要で、一体何なのかを徹底的に解説します。この概念的な一歩が、あなたのボットを凡庸なツールから卓越したアシスタントへと進化させるための、最も重要な一歩となるでしょう。

問題の核心：なぜAIボットはこれほど「忘れっぽい」のか

この問題の根本原因は、驚くほどシンプルです。それは、現在の主要なLLMのAPIが、基本的に「ステートレス（stateless）」だからです。

これは、LLMが過去のやり取りや自分自身の状態を一切「記憶」していない、ということを意味します。では、なぜ一見すると会話が成り立っているように見えるのでしょうか？

それは、私たち開発者がAPIを呼び出すたびに、「これまでの経緯はこうです」という文脈（コンテキスト）情報を、毎回手動で全部LLMに渡しているからです。

この構造を、Slackボットに置き換えて考えてみましょう。

AIボットを、 「非常に優秀だが、極度の短期記憶喪失を持つ新人メンバー」 だと想像してください。
彼をSlackのチャンネルに招待し、@-メンションで話しかけるたびに、彼は「はじめまして、ご用件は何でしょうか？」という状態であなたに向き合います。

彼に有意義な仕事をしてもらうためには、メンションのたびに、以下のような完璧な申し送り事項を伝えなくてはなりません。

• 「君は、このチャンネルでは技術的な質問に答える専門家だよ」（役割定義）
• 「今、私たちは〇〇というプロジェクトの話をしている最中だ」（現在のトピック）
• 「さっき君は、Aという提案をしてくれた」（直前の発言）
• 「そして、君にやってほしいのは、そのA案のメリットを3つ挙げることだ」（今回の指示）

LLMを搭載したSlackボットも全く同じです。ボットへのメンションをトリガーにAPIを叩く裏側では、この「申し送り事項」にあたるmessages配列を毎回組み立てて、LLMに送信しているのです。

この仕組みを理解せずに、ただ闇雲にチャンネルの投稿履歴をmessagesに詰め込もうとすると、すぐに破綻します。

失敗パターン1：膨れ上がる会話履歴と「トークンオーバーフロー」

活発なSlackチャンネルでは、1日に何百ものメッセージが投稿されることも珍しくありません。もしボットが応答するたびに、チャンネルの全履歴をコンテキストとして送信しようとしたらどうなるでしょうか？

答えは明白です。LLMが一度に処理できるトークン数（コンテキストウィンドウ）の上限をあっという間に超えてしまい、APIはエラーを返すでしょう。コストも時間も膨大になり、全く実用的ではありません。

失敗パターン2：長いスレッドにおける「指示の希薄化」

では、直近のメッセージだけを送れば良いのでしょうか？それもまた、別の問題を引き起こします。

例えば、あるスレッドの冒頭で、あなたがボットに「@￰AIボット、このスレッドの議論がまとまったら、最終的な結論を要約してください」と指示したとします。

その後、チームメンバーが20回、30回と議論を重ね、スレッドが長くなったとします。その最後にあなたが「@￰AIボット、お願い」とメンションしても、ボットはもう最初の指示を覚えていません。なぜなら、ボットに渡されるコンテキスト（直近のメッセージ群）には、最初の重要な指示が含まれていない可能性が高いからです。

たとえ含まれていたとしても、大量の議論の中に埋もれてしまい、その指示の重要度は「希薄化」してしまいます。これが、ボットが途中で自分の役割を見失い、期待外れの応答を返す大きな原因です。

解決策：ボットの「脳」を設計するModel Context Protocol (MCP)

これらの根深い問題を解決し、賢いSlackボットを実現するための設計図が、 Model Context Protocol (MCP) です。

Model Context Protocol (MCP) とは

SlackボットがLLMに応答を求める前に、どのような文脈情報を、どのような構造で、どのようなルールに基づいて組み立てるかを定めた、一貫性のある 「設計思想」であり、ボットの「思考プロセス」の設計図 である。

MCPは、以下の4つの主要なコンポーネントを意識的に設計することで成り立っています。それぞれの要素が、賢いSlackボットのどの部分を担うのかを見ていきましょう。

A. ボットのアイデンティティ：システムプロンプト (System Prompt)

• Slackにおける役割

  • ボットのワークスペース内での人格、役割、行動規範を定義します。「君は何者で、何をするためにここにいるのか」という、ボットの存在意義そのものです。

• 目的

  • この「憲法」とも言える指示を一貫して与えることで、ボットの応答スタイルや振る舞いが安定し、チームメンバーは安心してボットと対話できます。

• 良い例

  • 要約ボット
    • 「あなたは、指定されたSlackスレッドの議論を、常に箇条書きで簡潔に要約するボット『Summary-kun』です。感情的な表現は避け、事実のみを客観的に記述してください。」
  • コードレビューボット
    • 「あなたは、投稿されたコードの問題点を指摘し、改善案を提案するAIアシスタント『Code-Checker』です。返答は必ずMarkdownのコードブロック内に記述してください。」

• MCPにおける位置づけ

  • ボットの思考プロセスの揺るぎない「土台」。全てのコンテキスト構築は、ここから始まります。

B. 「いま、ここ」の会話：短期記憶 (Short-Term History)

• Slackにおける役割
  • 特定のチャンネルやスレッドで行われている、直近の会話の流れに相当します。
• 目的
  • 「さっきの〇〇についてだけど…」といった、文脈に依存した質問をボットが理解するために不可欠です。これがなければ、一問一答の無機質な応答しかできません。
• 戦略
  • この部分は常に増え続けるため、管理が必要です。最も効果的なのが 「スライディングウィンドウ」 という考え方で、例えば「常にスレッド内の直近10件のメッセージだけを記憶する」といったルールを設けます。これにより、コンテキストのサイズを制御しつつ、会話の連続性を保ちます。
• MCPにおける位置づけ
  • ボットに 「会話の流れを読む能力」 を与える、流動的な記憶領域です。

C. 重要な約束事：長期記憶 (Long-Term Memory)

• Slackにおける役割
  • ユーザーやチャンネルに関する、忘れてはならない重要な情報を蓄積する場所です。
• 目的
  • これこそが、ボットを「ただのツール」から「賢いアシスタント」へと飛躍させる鍵です。
    • 対ユーザー
      • 「ユーザーU123ABC（佐藤さん）は、プロジェクトAのリーダーである」
    • 対チャンネル
      • 「#generalチャンネルでは、専門用語を避けて誰にでも分かるように説明する」
• 効果
  • この記憶があることで、ボットは「プロジェクトAの件ですが、リーダーの佐藤さんはいかがお考えですか？」といった、高度に文脈を理解した発言が可能になります。毎回同じ説明を繰り返す必要がなくなり、対話はよりスムーズで効率的になります。
• MCPにおける位置づけ
  • ボットに 「経験から学習する能力」 を与え、パーソナライズされた対話を実現する戦略的な記憶領域です。

D. チームの知識：動的コンテキスト (Dynamic / RAG Context)

• Slackにおける役割
  • Slack外部にある、チームの公式ドキュメントやナレッジベースを参照する能力です。
• 目的
  • LLMが元々知らないはずの、社内ルール、プロジェクトの仕様書、過去の議事録といった情報に基づいて、ボットが回答を生成できるようにします。これが RAG (Retrieval-Augmented Generation) の仕組みです。
• 活用例
  • メンバーが「@￰AIボット、経費精算のルールを教えて」と質問した際に、ボットが社内規定のドキュメント（ConfluenceやNotionなど）を検索し、その内容を要約して回答します。
• MCPにおける位置づけ
  • ボットを単なるおしゃべり相手から、**チームの集合知にアクセスできる「ナレッジハブ」**へと進化させるための、強力な拡張機能です。

Slackボットの思考プロセス（MCPの動作イメージ）

では、これらの要素が実際のSlackでのやり取りでどう機能するのか、ボットの頭の中を覗いてみましょう。

• 状況
  • メンバーの佐藤さんが、「#project-a」チャンネルのスレッドでボットにメンションしました。

1. イベント発生: @￰AIボット、前回の決定事項を踏まえて、新しいタスクリスト案を作って
2. ボットの思考開始 (MCP起動)
   • (Step 1: 自己認識) まず、[A]システムプロンプトを読み込み、自分の役割を再確認する。「私はプロジェクト管理を支援するAIアシスタントだ…」
   • (Step 2: 長期記憶の参照) 次に、[C]長期記憶を検索する。「ユーザーは佐藤さん…彼はこのプロジェクトのリーダーだ。#project-aチャンネルは重要な決定を行う場所…」これらの情報をコンテキストに加える。
   • (Step 3: 短期記憶の読み込み) Slack APIを叩き、このスレッドの**[B]短期記憶**にあたる直近の会話（「前回の決定事項」に関するやり取り）を取得する。
   • (Step 4: 外部知識の検索) 指示に「前回の決定事項」とあるため、[D]動的コンテキストとして、関連する議事録ドキュメントをナレッジベースから検索・取得する。
   • (Step 5: 最終ブリーフィングの作成) これら全ての情報（A+C+D+B+最新の質問）を、LLMに渡すための最終的なmessages配列へと、定められたルールに従って組み立てる。
   • 応答生成 : 完成した「完璧な申し送り資料」をLLMに送信し、返ってきたタスクリスト案をスレッドに投稿する。

この一連の整理されたプロセスこそが、MCPの力です。

まとめと、次回の実装に向けて

本記事では、「賢い」Slackボット開発の根幹をなす 「Model Context Protocol (MCP)」 という設計思想について、その必要性と具体的な構成要素を解説しました。

• Slackボットが忘れっぽいのは、LLMがステートレスだから。
• 「記憶」は、開発者がコンテキスト管理によって意図的に「構築」するもの。
• MCPは、そのための設計図であり、「システムプロンプト」「短期記憶」「長期記憶」「動的コンテキスト」の4要素から成る。
  この土台となる考え方を理解することが、行き当たりばったりの開発から脱却し、真に価値のあるAIアシスタントを生み出すための第一歩です。

さて、ボットの脳の「設計図」は手に入りました。次はいよいよ、その脳を実際に作り始めます。

連載第2回『わずか50行！Slackボットの「記憶」を司るMCPエンジンをPythonで実装する』 では、今回学んだMCPの中核、特に「短期記憶」を管理するクラスを、驚くほど短いPythonコードで実装します。このクラスが、我々が作るSlackボットの心臓部となります。

ぜひエディタを準備して、次回のハンズオンにご参加ください！

この記事が、皆さんのAIアプリケーション開発の安定化に少しでも貢献できれば嬉しいです。役に立ったと感じたら、ぜひ Like をお願いします！

Written by A.H.