Claude時代の社内問い合わせボット設計図 — Cowork / Agent SDK / MCP / Citationsで作る営業・CSアシスタント

「PMにSlack爆撃」を止めるためのボット、2026年版

toB SaaSの営業・カスタマーサクセス（CS）が抱える慢性的な課題があります。 顧客から「この機能の権限はどう動く？」「APIのレートリミットは？」と聞かれるたびに、 PMやエンジニアにSlackでメンションを飛ばす。PMはコンテキストスイッチで疲弊し、 営業は回答待ちで商談スピードが落ちる。

この問題を解くAIボットは2024年頃から各社が試してきましたが、 2026年のスタックは大きく姿を変えています。 キーワードは Claude Cowork、MCP（Model Context Protocol）、 Claude Agent SDK、Citations API。 「LLMにRAGをくっつけてSlack Botにする」古典的レシピは、 「エージェントがMCP経由で社内ツールを横断し、出典付きで答える」設計に置き換わりました。

この記事では、(1) 2026年の前提シフト、(2) Claude Cowork で何ができるか、 (3) MCPとは何か・なぜ標準になったか、(4) Agent SDK で自前構築する場合の設計、 (5) Citations APIで出典問題を片付ける、(6) Build vs Buy 判断軸、 (7) 実装の最初の2週間、までを整理します。 toB SaaS で「営業・CS向けのプロダクト問い合わせボット」を、 Claudeのスタックで作りたいエンジニア・PM向けの設計図です。

2026年の前提 — 「LLM + RAG」から「エージェント + MCP」へ

2024年までの社内Q&Aボットは、ほぼ全てが同じ構成でした。 ドキュメントを刻んでベクトルDBに入れ、質問が来たら類似検索し、上位ヒットをLLMに渡して回答させる。 いわゆるナイーブRAGです。これは動きはするものの、いくつか致命的な弱点がありました。

決定的なのは MCP（Model Context Protocol） の登場です。 Anthropicが2024年に発表したこのオープン標準により、 「LLMに外部システムを接続する」配線が初めて統一規格化されました。 2026年現在、Slack・Notion・Confluence・Salesforce・GitHub・Linear・Google Drive など、 主要なエンタープライズSaaSのほぼ全てが公式MCPサーバーを提供しています。

Claude Cowork — 既製品としての現在地

Anthropicが2026年に投入した Claude Cowork は、 「Claude Codeがエンジニアの仕事を変えたように、エンタープライズの他職種の仕事も変える」 というポジショニングのプロダクトです。 営業・CS・マーケ・法務などの非エンジニア部門で、 Claudeが社内のSaaSを横断して動くエージェントとして振る舞います。

Coworkでできること

• 横断検索: Slack / Google Workspace（Drive・Calendar・Gmail）/ Salesforce / DocuSign / Notion 等のコネクタからライブ検索
• Salesforce連携: Agentforce 360 のアクションをClaudeから直接トリガー（取引先更新、商談ステージ変更など）
• Slack統合: SlackのDMやチャンネル内でClaudeを呼び出し、コンテキストを引き継いだまま回答
• サードパーティ拡張: LSEG・FactSet・Apollo・Clay・Outreach・Similarweb・Harvey 等の業界特化コネクタ

どこまで Cowork で足りるか

営業・CSのプロダクト仕様問い合わせ用途では、Coworkで足りるかは 「自社プロダクトの仕様書がどこにあるか」でほぼ決まります。

MCPとは — Claudeに「外の世界」を見せる規格

MCP（Model Context Protocol）の構造はシンプルです。 Host / Client / Server の3者構成で、 HostはClaude Desktop / Cowork / 自前アプリなど「ユーザーが触るもの」、 ClientはHostの中でMCP通信を担当する層、 ServerはNotionやSlackなど 各ツール側が公開するエンドポイント です。

flowchart LR
    User[営業・CS<br/>ユーザー] -->|質問| Host[Host<br/>Slack Bot / Cowork]
    Host --> Client[MCP Client]
    Client -->|stdio/HTTP| NotionMCP[Notion MCP Server]
    Client -->|stdio/HTTP| SlackMCP[Slack MCP Server]
    Client -->|stdio/HTTP| GitHubMCP[GitHub MCP Server]
    Client -->|stdio/HTTP| InternalMCP[自社MCP Server<br/>仕様書DB]
    NotionMCP --> Notion[(Notion)]
    SlackMCP --> Slack[(Slack)]
    GitHubMCP --> GitHub[(GitHub)]
    InternalMCP --> InternalDB[(社内DB)]

ボットを作る側にとって嬉しいのは、「自社固有の情報源」も独自MCPサーバーとして公開すれば、 Claudeから他のSaaSと同じインターフェイスで読める ことです。 自社プロダクトの管理画面、リリースバージョン管理、 feature flag DB なども、MCPサーバーを1つ書けばエージェントから利用可能になります。

Claude Agent SDKで自前構築する

Coworkで届かない領域に入る場合、Claude Agent SDK で 自前のSlackボットを作るのが王道です。 Agent SDKは元々 Claude Code SDK だったものが、コーディング以外の汎用エージェント用途に リブランドされたフレームワークで、MCP接続・会話履歴管理・ツール許可リスト・ 人間の承認ループ などを標準で備えます。

最小構成

flowchart TB
    A[Slack User] -->|"@bot 質問"| B[Slack Events API]
    B --> C[Slack Bot サーバー<br/>Node/Python]
    C --> D[Claude Agent SDK]
    D --> E{ツール選択}
    E -->|社内仕様| F[Notion MCP]
    E -->|議論履歴| G[Slack MCP]
    E -->|コード確認| H[GitHub MCP]
    E -->|チケット| I[Linear MCP]
    F & G & H & I --> J[Claude推論<br/>+ Citations]
    J --> K[Slackに出典付き回答]

Agent SDKでの実装イメージ

Pythonでの最小実装はおおよそ次のような形になります。 ここでは @anthropic-ai/claude-agent-sdk と Slack Bolt を組み合わせる想定です。

from anthropic import Anthropic
from claude_agent_sdk import Agent, MCPServerConfig
from slack_bolt import App

app = App(token=SLACK_BOT_TOKEN)

# MCPサーバーを束ねる(Notion/Slack/GitHub/自社)
mcp_servers = [
    MCPServerConfig(name="notion", command="npx",
                    args=["-y", "@notionhq/notion-mcp-server"]),
    MCPServerConfig(name="github", command="npx",
                    args=["-y", "@modelcontextprotocol/server-github"]),
    MCPServerConfig(name="internal", command="python",
                    args=["./mcp_servers/spec_db.py"]),
]

agent = Agent(
    model="claude-opus-4-7",
    system_prompt=(
        "あなたは営業・CS向けのプロダクト仕様アシスタントです。"
        "回答には必ずCitationsで出典を含め、不明な場合は推測せず"
        "『情報源で確認できませんでした』と返してください。"
    ),
    mcp_servers=mcp_servers,
    citations=True,  # Citations API有効化
)

@app.event("app_mention")
def handle_mention(event, say):
    question = event["text"]
    user = event["user"]
    # 権限はSlackユーザーIDで分離(後述)
    response = agent.run(question, user_id=user)
    say(format_with_citations(response))

Citations API — 出典問題をAPI標準で片付ける

営業がボット回答を顧客にそのまま転送するためには、 「この回答はどのドキュメントの何文目から来たか」 が必要です。 2025年初頭にAnthropicが投入した Citations API は、 これを API側の機能 として標準化しました。

仕組み

1. ソースドキュメントをメッセージのcontentに document ブロックとして渡す（base64・テキスト・URL・Files API）
2. API側が文単位でチャンキング
3. Claudeの応答に citations 配列が付与され、各claimがどの文に紐づくか構造化される
4. 呼び出し側はそのまま「出典リンク付き回答」をUIに展開できる

従来は「プロンプトで頑張って『ソースを引用せよ』と指示する」「LLMが時々サボって出典をでっち上げる」 「正規表現で出典抽出する後処理」という不安定な配管が必要でした。 Citations APIはこれを モデル側の責務 に移し、 返ってくる構造化レスポンスをそのままUIで描けるようにしました。

事例 — ServiceNow と Anthropic自身

ServiceNow: 営業準備時間 -95%

ServiceNow は29,000名規模の従業員にClaudeとClaude Codeを展開しました。 注目すべきは 顧客ミーティング準備のためのClaude駆動コーチングツール で、 営業担当が「明日の○○社のミーティング準備をして」と頼むと、 ClaudeがCRM・社内ナレッジ・過去の議事録を横断して 「先方の関心領域、最新の課題、関連プロダクト機能、想定質問と回答案」を返す。 この構成で 営業準備時間を95%削減 したと公表しています。

Anthropic内製: 27%は「やらなかった仕事」

Anthropic自身の社内利用データも示唆に富みます。 自社エンジニアの仕事の60%でClaudeが活用され、 自己申告ベースの生産性は50%向上。 さらに重要なのは、Claude経由の作業の27%は「Claudeがなければやらなかったタスク」 だったという事実です。 内訳は「社内ツールの構築」「ドキュメントの整備」「papercutsの解消」。 問い合わせボットを作ると、それ自体が papercuts可視化装置 になり、 ドキュメント整備や運用改善の優先順位を変える、という波及効果が見込めます。

Build vs Buy — Coworkで足りるか、Agent SDKで作るか

実務的な判断ロジックは次のとおりです。

• Coworkで始めるべき: 仕様書がNotion/Confluence/Salesforceに集中、〜200名規模、立ち上げ速度優先
• Cowork + 一部MCPサーバー追加: GitHubコードや独自Wikiもカバーしたいが、Slack体験は標準でいい
• Agent SDKで自前構築: ソースコードが仕様の真実 / プロダクト内に組み込みたい / オンプレ要件 / Slack以外のチャネルで配信したい

実装プラン — 最初の2週間

自前構築する場合、以下の順序で進めるのが現実的です。

1. Day 1〜3: ベースライン計測。PMへの仕様問い合わせを1週間ログる（後でROI証明に必要）
2. Day 4〜6: 情報源の絞り込み。最初は3つ（例: Notion + リリースノート + GitHub）。MCPサーバーをローカルで起動して接続確認
3. Day 7〜10: Agent SDKでスケルトン実装。Citations API有効化、system_promptに「分からない時は推測しない」を明示
4. Day 11〜12: Slack Bolt経由でSlack Botに接続。@メンションで動くところまで
5. Day 13〜14: 社内3〜5名のドッグフード。Faithfulnessの目視評価を50件 + Slackで👍/👎ボタン回収

よくある落とし穴

まとめ — 「LLM + RAG」から「エージェント + MCP」へ

toB SaaSで「営業・CS向けのプロダクト問い合わせボット」を作る選択肢は、 2026年に大きく変わりました。要点は3つです。

• 標準化された配線: MCPによってClaudeと社内ツールの接続が「USB-C的」に統一された。SaaS側がMCPサーバーを公開するだけで、エージェント側は同じインターフェイスで使える
• 既製品の充実: Claude Coworkで立ち上げできる範囲は予想以上に広い。仕様書がNotion/Confluence/Salesforce/Slackに集中していれば、まずはCoworkで始めるべき
• 自前は明確な理由がある時だけ: ソースコードが仕様の真実、プロダクト内組込、オンプレ要件 — このいずれかに該当する場合は Claude Agent SDK + カスタムMCPサーバーで作る価値がある

そして共通する勘所は、Citations APIを最初から有効化し、出典を文単位で構造化すること。 営業がボットの回答を顧客に転送できるかどうかは、出典の有無で決まり、 そこが信頼できないと「あれば便利だけど結局PMに聞く」現象が再発します。 「ボットを作る」プロジェクトは、最終的には 社内ナレッジマネジメントの再定義 であり、ドキュメントの古さ・矛盾を可視化する装置でもあります。 これは負債ではなく、組織にとっての贈り物として捉えるのがおすすめです。