Chatwork MCPサーバーの作り方｜非エンジニア社長の自作実録

社内連絡の「読む・返す・見回る」をAIに任せている

社内チャットの対応に、経営者の時間が食われていく。中小企業の経営で、この悩みは珍しくないはずです。読む、返す、見回る。ひとつひとつは小さな作業ですが、積み重なると経営者の一日を確実に削っていきます。僕の会社では今、この「読む・返す・見回る」をAIに任せています。

朝、僕がPCを立ち上げると、AIアシスタントから報告が届いています。「Chatwork未読あり。顧客の会計事務所から返信が来ています。重点12ルームの巡回が完了しました」という内容です。全ルームの未読をAIが要約して報告してくれるので、僕はその報告を見て、どこから対応するかを指示するだけです。

返信が必要な案件には、AIが下書きを用意してくれます。丁寧で温かみのある返答が作成されています。「このままで良いですか？」と承認を求めてくるので、僕は承認するだけです。ワンクリックで送信されます。さらに賢いのは、送信時に「これは僕の名義で送るべき案件か、それとも社内連携はAI名義の方が適切か」を自動判断してくれることです。

週に一度、重点12ルーム全てを巡回する業務も、完全にAIが代わりにこなしています。このような運用が実現しているのは、僕が自作したChatwork MCPサーバーという、たった1つのサーバーのおかげです。市販のサービスではありません。JavaScriptで318行、9つのツールを実装したシステムです。

僕の本業は経営コンサルティングです。ハンズバリュー株式会社の代表を務め、ITコーディネータの資格は持っていますが、プログラマーではありません。その非エンジニアの僕が、2026年5月にこのシステムの初版を構築してから、本番運用をずっと続けています。AIに指示して完成させた実装が、毎日、経営者としての僕の時間を解放しています。本記事は、そのChatwork MCPサーバーの実装と運用の記録です。

中小企業のチャット業務は「細切れの集中破壊」で効いてくる

中小企業の経営者が、社内チャットで実際に何をしているのか。まず正確に把握する必要があります。

朝から晩まで継続的にメッセージが到着します。既読確認。相手の言葉から「返信すべきか、見守るべきか」を判断する。ふさわしい言葉を選ぶ。その都度、頭を切り替えます。

この「細切れの集中破壊」が、経営者の思考を深刻に蝕みます。決算書を見て重要な判断をしようとしている最中にチャットが割り込んでくる。「あ、さっきのメッセージ、返信忘れてた」という不安が常に背景にある。その不安が、また業務を割き続けます。

既存のチャットボットSaaSは、「顧客向けの自動応答窓口」が中心です。FAQを登録して、お客様からの質問に自動で回答する。そういう用途が主流です。しかし、僕が必要としているのは、それではありません。経営者自身の「社内チャット業務」を減らしたい。顧客向けではなく、社内スタッフとの連絡と顧客対応の両方を、一つのシステムで自動化する道具が必要でした。

生成AIに「このメッセージに返事を書いて」と指示することはできます。テキストの返案をコピーペーストでChatworkに貼り込めばいい。ですが、その「貼り込み」という手作業が残っている限り、細切れ作業は減りません。本当に必要なのは、AI側から「この相談が来ていますが、こう返していいですか？」と提案され、ワンクリックで送信できる状態です。つまり、AIがChatworkの公式APIを直接呼び出せる仕組みが不可欠だったわけです。その橋渡しが、Chatwork MCPサーバーの役割です。

MCPとは — AIにChatworkの「手足」を生やす仕組み

MCP（Model Context Protocol）について説明します。難しく考える必要はありません。考え方は、コンピュータのUSBポートと同じです。

USBポートは何をするか。パソコンに周辺機器を接続するための統一された規格です。キーボード、マウス、プリンタ。どれも同じUSBの形でつながる。メーカーは統一された規格に従って機器を作れば、様々なパソコンと組み合わせられます。互換性が生まれます。

MCPはこの考え方を、AIと外部システムの連携に応用しました。Anthropicという企業が2024年11月に公開したオープンな規格です。生成AI（Claude等）と、外部のサービス（Chatwork、データベース、メールシステムなど）をつなぐための、統一された通信規格です。

Chatwork MCPサーバーの構成はシンプルです。Claude（生成AI）→ Chatwork MCPサーバー → Chatwork公式REST API v2という3段構成です。真ん中のChatwork MCPサーバーが、生成AIとChatworkの仲介役をします。

AI側から見ると、「未読メッセージを取得する」「メッセージを送信する」「ルーム情報を調べる」といった一連の操作が「ツール」として使用可能に見えます。ですが、その操作は無制限ではありません。Chatwork MCPサーバーで定義したツール・9個の機能の範囲内でだけ、AIは動作できます。Chatworkのシステムを無限に操作することはできず、許可された操作だけが実行される仕組みになっています。

重点ルーム12室すべてをAIに巡回させること。朝の「未読はありますか？」という問い合わせに答えてもらうこと。これらが実現できるのは、Chatwork MCPサーバーという仲介層があるからです。この仲介層があって初めて、実務レベルの連携が成立します。

Chatwork MCPサーバーの実装には、公式のSDK——@modelcontextprotocol/sdkというNode.jsライブラリを使用しています。バージョンは^1.12.1です。このSDK経由でパラメータを定義し、ツール側の処理を書いて、標準入出力（stdio）でAIと通信する。ただそれだけで、「AIがChatworkを読み書きできる」という驚くべき仕組みが成立します。本番環境で毎日、それを体験しているのですが、改めて考えると不思議です。2026年の前半まで、このようなことは、一般的な中小企業には実現できない未来技術だと思い込んでいました。

Chatwork MCPサーバーの実装 — 318行・9ツールでできている

では、Chatwork MCPサーバーの中身を見ていきます。本番運用中のserver.jsは、1ファイル・全318行です。依存パッケージは実質1つで、先ほどの公式SDK（@modelcontextprotocol/sdk）だけです。パラメータ検証に使うzodというライブラリも、SDK経由で利用できるため、別途の導入は不要です。サーバーのバージョンは1.1.0。何百ファイルにも及ぶ大規模開発を想像していた方には、拍子抜けする規模だと思います。しかし、この小ささこそが、非エンジニアの経営者でも自作と保守を続けられる理由だと考えています。

実装している9つのツールは次の通りです。

ツール名	役割
me	自分のアカウント情報を取得する
rooms_list	参加している全ルームの一覧を取得する
rooms_search	ルームを名前で検索する
messages_list	ルームのメッセージ一覧を取得する
message_send	メッセージを送信する
room_info	ルームの詳細情報を取得する
room_members	ルームの参加メンバーを取得する
unread_summary	全ルームの未読サマリーを取得する
tasks_list	自分のタスク一覧を取得する

ツールの定義が実際どのようなものか、実物のコードをお見せします。毎朝の未読チェックを担うunread_summaryの実装（短縮版）です。

// 未読サマリー（おはようプロトコル用）
server.tool(
  "unread_summary",
  "未読メッセージのサマリーを取得（おはようプロトコル用）",
  {},
  async () => {
    const rooms = await chatworkAPI("/rooms");
    const unread = rooms.filter((r) => r.unread_num > 0 || r.mention_num > 0);
    if (unread.length === 0) {
      return { content: [{ type: "text", text: "Chatwork: 未読なし" }] };
    }
    const summary = unread.map(
      (r) => `- ${r.name}: 未読${r.unread_num}件`
    );
    return { content: [{ type: "text", text: `Chatwork未読:\n${summary.join("\n")}` }] };
  }
);

コードの冒頭に、次の一文が入っています。

未読メッセージのサマリーを取得（おはようプロトコル用）

これは人間向けのコメントではなく、AIに向けたツールの説明文です。AIはこの説明文を読んで、「朝の報告のときはこのツールを使えばいい」と自分で判断します。人間向けのマニュアルを別に書くのではなく、AI向けの説明をコードの中に埋め込んでおく。ここがMCPのツール定義の面白いところです。

処理の流れは3手です。パラメータを定義し、Chatwork APIを呼び、結果を整形して返す。上のコードでは、全ルームを取得して未読が残っているルームだけを絞り込み、1行ずつの要約にして返しています。未読が0件なら「Chatwork: 未読なし」という1行だけを返す設計にしました。毎朝の報告が簡潔になるよう、サーバー側で整形まで済ませています。

もう1つ、9つのツール全てから呼ばれるAPIラッパー関数もお見せします。

async function chatworkAPI(path, options = {}, sender = DEFAULT_SENDER) {
  const token = TOKENS[sender];
  const res = await fetch(`${API_BASE}${path}`, {
    ...options,
    headers: { "X-ChatWorkToken": token, ...options.headers },
  });
  if (!res.ok) {
    throw new Error(`Chatwork API error ${res.status}`);
  }
  if (res.status === 204) return null; // 新着なし等は空ボディ
  return JSON.parse(await res.text());
}

ヘッダーにAPIトークンを載せてChatwork公式REST API v2を呼び、エラーならその場で例外を投げる。それだけの関数です。この共通関数があるおかげで、各ツールの実装は「どのAPIを呼んで、結果をどう整形するか」だけに集中できます。

非エンジニアの僕が、これをどうやって書いたのか。正直に言えば、自分の手でコードを打った時間はほとんどありません。Claude Code（AIコーディング環境）に「Chatworkの未読を要約するツールを作って」と日本語で指示し、生成されたコードを動かして確認し、直してほしい点をまた日本語で伝える。この反復だけです。人間の仕事は、仕様を言語化することと、動作を検証することでした。プログラミングの知識よりも、「自分の業務のどこをAIに任せたいのか」を言葉にできることの方が、はるかに重要だったと感じています。

一番効いた工夫 — 「島田名義」と「AI名義」の2トークン切替

Chatwork MCPサーバーを運用してみて、一番効いた工夫は技術的なものではありませんでした。「AIがチャットを送るとき、誰の名前で送るのか」という名義の設計です。

作った当初は、全ての送信が僕（島田）の名義でした。すると、困ったことが起きます。AIが代筆した連絡を受け取った相手は、僕本人が書いたと受け取ります。悪意はなくても、実態と受け取られ方が少しずつずれていく。AIを業務に導入するとき、一番悩むのは技術ではなく「人がどう受け取るか」なのだと痛感しました。

解決策は、ChatworkのAPIトークンを2つ用意することでした。僕本人の名義のトークンと、AIアシスタント名義のトークンです。server.jsではTOKENSというオブジェクトでshimada/tsumugiの2名義を環境変数から読み込み、指定を省略した場合はshimada名義になる設計です。送信ツールのmessage_sendにはsenderというパラメータを実装し、呼び出しのたびにどちらの名義で送るかを選べるようにしました。実物のパラメータ説明文には、こう書いてあります。

送信名義。shimada=島田本人、tsumugi=AIチーム＠常磐ツムギ。省略時はshimada（島田名義）

使い分けの基準は明快です。お客様のルームには島田名義で送り、社内のルームにはAI名義で送る。さらに、送信が完了すると「メッセージ送信完了（名義: ○○ / message_id: ○○）」という応答が返るようにして、どちらの名義で送ったのかを毎回確認できるようにしました。この名義切替は最初からあった機能ではなく、2026年7月の改修で追加したものです。運用してみて初めて必要性に気づいた、後付けの発明でした。

代筆そのものにも運用ルールを定めています。AIが下書きを作り、僕が承認してから送信する。この順番は崩しません。社内の運用ルールには、こう書いています。

代筆の原則: 島田が直接書くと表現が直接的になるため、ツムギが代筆する。丁寧かつ温かみのある表現を心がける

自分で言うのも変な話ですが、僕が急いで書く返信は、どうしても表現が直接的になります。AIが間に入ることで、丁寧さと温かみが一段上がる。受け取る側の心理まで含めて設計するわけです。ホームページ上でお客様の質問に答える仕組みはつなぐAIチャットとして別に提供していますが、あちらも根っこは同じで、「誰が、どんな言葉で応対するのか」という設計が価値の中心にあります。名義の設計は、コードの行数にすればわずかですが、Chatwork MCPサーバーの運用を支える一番の発明だと思っています。

作ってわかった落とし穴 — 3つのつまずき

最後に、作ってみて初めてわかった落とし穴を3つ共有します。どれも、動かす前には想像していなかったものです。

1つ目は、Chatwork APIの「204 No Content」です。Chatwork APIは、新着メッセージがない場合などに、中身が空のレスポンスを返すことがあります。空のボディをJSONとして解析しようとすると、そこで例外が発生します。先ほどのAPIラッパーに「ステータス204ならnullを返す」という1行が入っていたのは、このためです。ステータス204と空テキストをnull返却で吸収する。たった1行ですが、これがないと「新着がない」という正常な状態のたびにエラーが起きるという、笑えない動作になります。

2つ目は、差分取得の罠です。messages_listにはforce=falseという指定があり、前回取得した以降の新着メッセージだけを返してくれます。便利な機能ですが、「どこまで読んだか」という取得済みの判定は、APIトークン単位で記録されます。つまり、週次巡回の読み取りと、ふだんの閲覧で同じトークンを使うと、お互いに取得状態を食い合ってしまいます。片方が読むと、もう片方には「新着なし」に見えてしまうのです。この問題の解決策が、前の章で説明した名義（トークン）の分離でした。名義切替は「誰の名前で送るか」のためだけでなく、「どこまで読んだかを混ぜない」ためにも効いています。

3つ目は、APIトークンの置き場所です。トークンは、Chatworkのアカウントそのものを操作できる鍵です。コードの中に直接書いてしまうと、コードを誰かに共有した瞬間に、鍵ごと渡してしまう事故につながります。Chatwork MCPサーバーでは、トークンはコードに書かず、CHATWORK_API_TOKENなどの環境変数で渡す設計にしました。環境変数が未設定なら、起動時にエラーで終了します。「設定を忘れたまま動いてしまう」ことを防ぐためです。

振り返って思うのは、もし「とりあえず動いた」の段階で手を止めていたら、この仕組みは使い物にならなかった、ということです。204のエラーで朝の報告が止まり、差分取得の食い合いで週次巡回が壊れ、運用はどこかで崩れていたはずです。自作の価値は、作った瞬間ではなく、作った後の運用改善まで含めて初めて生まれます。小さく作って、運用の中で育てる。Chatwork MCPサーバーの318行は、その積み重ねの結果です。

「自分で作る」か「できたものを使う」か

ここまで読んで、「うちでも作れそうだ」と感じた方もいれば、「やはり自社では難しい」と感じた方もいると思います。どちらの感覚も正しいので、正直にお答えします。

自作は可能です。ここまで紹介した通り、規模は318行、依存パッケージは実質1つです。社内にIT担当がいる会社なら、挑戦する価値は十分にあります。仕様を日本語で言語化し、AIに書かせて、動かして確かめる。この記事がその出発点になるはずです。

一方で、APIトークンの管理、名義の設計、代筆や承認の運用ルール整備まで含めると、片手間で回すには重いのも事実です。そこで当社では、この仕組みを商品化した「つなぐAIアシスタント」を開発しています。Chatworkに常駐するAIアシスタントで、2026年7月時点では先行案内を受け付けている段階です。当社が提供している接客AIクラウドの考え方を、社内チャットの領域に広げたものだと捉えていただければと思います。

自作に挑戦して途中で詰まった場合の相談も歓迎します。お問い合わせからご連絡ください。どこでつまずいているかを一緒に切り分けるだけでも、前への進み方は変わります。

まとめ — 318行が経営者の朝を変えた

要点を3つに絞ります。

1つ目。MCPという仕組みを使えば、AIはチャットの実務を直接こなせます。文章の下書きを作るだけでなく、読んで、要約して、承認を経て送信するところまで、AIの仕事にできます。

2つ目。規模は318行です。大規模な開発は要りません。小さく作って、運用の中で育てる。この順番が、非エンジニアの会社でも続けられる作り方です。

3つ目。本丸は技術ではなく、名義と運用の設計です。誰の名前で送るのか、誰が承認するのか。そこを決めて初めて、Chatwork MCPサーバーは現場の道具になりました。

明日の朝、ご自身がチャットの確認と返信に何分使っているか、一度測ってみてください。その時間が経営判断に回ったら何が変わるか。そこから検討が始まります。

著者: 島田慶資（ITコーディネータ）