claude line mcp の設定を、現行の公式実装で実測して解説します。MCP全般は MCPサーバーの作り方2026年完全ガイド:TypeScript・Python両対応チュートリアル をご覧ください。

・要件はNode.js 22以降。旧版の記事にあった「v20以降」は現行では動かない前提で読む
・npm最新版0.5.0は12ツール、mainのREADMEは13ツール(get_group_summaryが未リリース)
・必要なのはCHANNEL_ACCESS_TOKENだけ。個人のLINEアカウントでは使えず、LINE公式アカウント(Messaging API)が前提
・push/broadcast/リッチメニュー系はdestructiveHint付き。送信先を取り違えると実ユーザーに届く
LINE Bot MCP Serverとは:claude line mcp 連携の公式実装
LINE Bot MCP Serverは、LINEが公式リポジトリ(line/line-bot-mcp-server)で公開しているModel Context Protocolサーバーだ。READMEの説明は「LINE Messaging APIを統合し、AIエージェントをLINE公式アカウントに接続する」。TypeScript実装でライセンスはApache 2.0、GitHubスターは784、フォークは154(2026-10-08にリポジトリのページで確認)。リポジトリにはGitHub Releasesもタグも無く、配布の実体はnpmの@line/line-bot-mcp-serverだ。npmのlatestは0.5.0(2026-05-29公開)で、履歴は0.3.1(2025-08-05)→0.3.2(2025-08-26)→0.4.0(2025-11-14)→0.5.0と続く。
何ができるかを一言で言えば、「自然言語の指示を、LINE公式アカウントに対するAPI呼び出しに変換する」ことだ。コードを書かずに、テキスト送信、Flex Message送信、リッチメニュー作成、クォータ確認ができる。何を解決するかといえば、Bot開発の検証フェーズ。Claudeにコードを書かせて自分で実行して結果を貼り戻す往復を、同一セッションで完結させられる。何を代替するかは、LINE Developersコンソールでの手動操作や、動作確認用の使い捨てスクリプトだ。
READMEには「This repository is provided as a preview version」と明記されている。また
line mcp 個人 アカウントという検索があるが、このサーバーが叩くのはMessaging APIで、対象はLINE公式アカウントのBotだ。個人のLINEトークを読み書きする用途には使えない。npm 0.5.0は12ツール、mainは13ツール:LINE MCPの仕組みを実測
旧版の本文は「12ツール」「Node.js v20以降」と書いていた。2026-10-08に現行を測り直すと、どちらもずれていた。
測り方は2つ。mainをgit clone --depth 50してsrc/index.tsのregister呼び出しを数えた。もう1つはnpx -y @line/[email protected]をstdioで起動し、JSON-RPCでinitializeとtools/listを送った。
| 観点 | npm 0.5.0(tools/list実測) | main(2026-10-08のsrc) |
|---|---|---|
| ツール数 | 12 | 13 |
| 差分 | - | get_group_summary(#590、2026-09-10追加) |
| Node.js要件 | engines: >=22 | engines: >=22 |
| serverInfo | name: line-bot / version: 0.5.0 | package.jsonは0.0.1-local(公開時に置換) |
| DockerベースImage | - | node:24系 |
グループチャットの情報を取りたい場合、get_group_summary(groupIdからグループ名とアイコンURLを返す読み取り専用ツール)はnpx経由の0.5.0には入っていない。使うならmainをビルドする必要がある。リリースが無いので、次のnpm公開で入るかどうかは未検証だ。
旧版は「Node v20以降」だった。現行のpackage.jsonは"node": ">=22"で、READMEも「Node.js v22 or later」と書く。Node 20環境でnpxを叩いてcommand not foundではなくengines警告やビルド不整合に当たる場合は、まずNodeを上げる。
13ツールの一覧と安全性ヒント(実測)
tools/listが返すannotationsを読むと、ツールは読み取り系と破壊的操作に分かれる。
| 分類 | ツール | annotations(実測) |
|---|---|---|
| 送信 | push_text_message / push_flex_message | destructiveHint |
| 一斉送信 | broadcast_text_message / broadcast_flex_message | destructiveHint |
| 取得 | get_profile / get_message_quota / get_rich_menu_list / get_follower_ids | readOnlyHint |
| リッチメニュー変更 | create_rich_menu / delete_rich_menu / set_rich_menu_default / cancel_rich_menu_default | destructiveHint |
| グループ(mainのみ) | get_group_summary | readOnlyHint(ソース) |
読み取り系はget_profile、get_message_quota、get_rich_menu_list、get_follower_idsの4つ。残りは全部destructiveHintが付く。MCPクライアントによってはこのヒントで自動承認を外すので、broadcastの確認画面は必ず目で見る運用にしたい。broadcastは全フォロワーに届くからだ。
入力はpush系がuserId(省略時は環境変数DESTINATION_USER_ID)とmessage。get_follower_idsはstart(継続トークン)とlimit。create_rich_menuはchatBarTextとactions(1〜6件)で、アクション型はpostback、message、uri、datetimepicker、camera、cameraRoll、location、richmenuswitch、clipboardの9種だ(旧版は「8種類」と書いていたが、READMEの列挙は9個)。
アーキテクチャ:stdioでAPIに橋渡しする
src/index.tsはCHANNEL_ACCESS_TOKENが無いとPlease set CHANNEL_ACCESS_TOKENを出して終了する(トークン無しで起動して実測した)。トークンがあればserveStdioでMCPサーバーを立て、各ツールをregisterする。環境変数は他にDESTINATION_USER_IDとLINE_MESSAGING_API_BASE_URLがソースにある。後者はAPIのベースURLを差し替えるためのもので、検証用のモックサーバーに向ける用途で使える。
通信ライブラリはREADME外の依存を含め、@line/bot-sdk(lockファイル更新履歴では11.3.0)と@modelcontextprotocol/server(2.2.0)。MCP SDKのメジャー更新に追従しているので、設定ファイル側でバージョンを固定したい場合は@line/[email protected]のように明示する。
導入手順:claude line mcp を15分で動かす・つまずき対策
1. LINE公式アカウントとトークン
LINE DevelopersコンソールでMessaging APIチャネルを作り、長期チャネルアクセストークンを発行する(公式手順はREADMEからリンクされている)。DESTINATION_USER_IDは自分のユーザーIDで、コンソールのチャネル基本設定にある「あなたのユーザーID」から取る。
2. Claude Desktopの設定(npx方式)
{
"mcpServers": {
"line-bot": {
"command": "npx",
"args": ["@line/[email protected]"],
"env": {
"NPM_CONFIG_IGNORE_SCRIPTS": "true",
"CHANNEL_ACCESS_TOKEN": "FILL_HERE",
"DESTINATION_USER_ID": "FILL_HERE"
}
}
}
}
設定ファイルはmacOSなら~/Library/Application Support/Claude/claude_desktop_config.json、Windowsなら%APPDATA%/Claude/claude_desktop_config.json。保存後にClaude Desktopを再起動する。
3. 起動確認(トークン無しで取れる確認)
本物のトークンを使わなくても、サーバーが立つかは確かめられる。次はダミー値でtools/listを呼ぶコマンドだ。
(printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}'; sleep 6) \
| CHANNEL_ACCESS_TOKEN=dummy NPM_CONFIG_IGNORE_SCRIPTS=true npx -y @line/[email protected]
Node 22.23.3で実行し、serverInfoがline-bot 0.5.0、tools/listが12件を返した。同じ起動でget_message_quotaを呼ぶとFailed to get message quota: 401 - Unauthorizedが返る。ダミートークンがLINE側で拒否された結果で、ネットワーク経由でMessaging APIまで到達していることの陽性対照になる。本物のトークンでの送信成功までは、LINEアカウントを持たないので未検証だ。
つまずきポイントを実測した
トークンが無い・userIdが無い・引数が不正、という3つの失敗を再現した。
| 操作 | 実測した応答 |
|---|---|
| CHANNEL_ACCESS_TOKEN未設定で起動 | Please set CHANNEL_ACCESS_TOKENで終了 |
| userIdもDESTINATION_USER_IDも無しでpush_text_message | Error: Specify the userId or set the DESTINATION_USER_ID in the environment variables of this MCP Server. |
| 無効なトークンでget_message_quota | Failed to get message quota: 401 - Unauthorized |
| actionsが空配列でcreate_rich_menu | Input validation error ... Array must contain at least 1 element(s) at actions |
DESTINATION_USER_IDは任意の環境変数だが、push系・get_profileでuserIdを渡さないなら実質必須だ。ClaudeにID付きで指示を出すか、環境変数に自分のIDを置いておく。401はトークンの貼り間違い、または失効・再発行後の旧トークンを疑う。Claude Desktopでツールが表示されない場合は、設定JSONの構文エラーが最も多い原因なので、まずJSONとして読めるかを確認する。
create_rich_menuの仕組み:画像はMarpとPuppeteerで生成される
create_rich_menuは他のツールと毛色が違う。ソースを読むと、1回の呼び出しで次を順に実行する。
- actionsの件数(1〜6)を検証
- 1600×910のリッチメニューをAPIで作成
richmenu-template/template-0N.md(Nはアクション数)をMarpでHTML化し、labelを差し込む- Puppeteer(ヘッドレスChromium)でPNG化して
os.tmpdir()に保存 - 画像をアップロードし、そのメニューをデフォルトに設定
リポジトリにはtemplate-01.md〜template-06.mdの6テンプレートがあり、アクション数がそのまま使うテンプレート番号になる。つまり画像は自動生成だがデザインは固定の6パターンで、凝ったメニューは自分で画像を作って別途API/SDKで登録するほうが早い。
もう1つ注意がある。手順5で作成したメニューが即デフォルトになる。本番アカウントで試すとすべてのユーザーのメニューが入れ替わる。テスト用のアカウントを分けるか、実行直後にcancel_rich_menu_defaultで解除する運用にしたい。
Dockerイメージが日本語フォント(Noto Sans JP、IPAexゴシック)とChromiumを同梱するのは、この画像生成のためだ。npx方式で日本語ラベルのメニューを作る場合は、実行マシンにChromiumと日本語フォントが必要になる可能性があるが、フォント未導入時に実際に文字が豆腐になるかは未検証。
Docker方式とMCP Inspector
コンテナで動かすなら、READMEはリポジトリをcloneしてビルドする手順になっている(公開イメージの記載は無い)。
git clone https://github.com/line/line-bot-mcp-server.git
cd line-bot-mcp-server
docker build -t line/line-bot-mcp-server .
claude_desktop_config.json側はcommand: docker、args: ["run","-i","--rm","-e","CHANNEL_ACCESS_TOKEN","-e","DESTINATION_USER_ID","line/line-bot-mcp-server"]とenvにトークンを書く。DockerfileはビルドがNode 24.21系、実行がnode:24-alpineで、非rootのappuserで動く。ビルド自体は今回の環境では実行しておらず未検証だ。
Claudeを介さずツールを叩きたいときは、READMEにあるMCP Inspectorを使う。
npm install && npm run build
npx @modelcontextprotocol/inspector node dist/index.js \
-e CHANNEL_ACCESS_TOKEN="YOUR_CHANNEL_ACCESS_TOKEN" \
-e DESTINATION_USER_ID="YOUR_DESTINATION_USER_ID"
npm run buildはprettierのformat:checkと型検査を通した上でtscを走らせる設定だ。
ユースケースと使い分け・競合との比較
読者の最大の疑問は、これをいつ使うかだ。
・Flex Messageの試作:JSON設計をClaudeに任せ、push_flex_messageで自分のLINEに送って見た目を確認する。message.contents.typeはbubbleかcarousel
・クォータ確認:get_message_quotaは読み取り専用で、送信前に月間上限と使用量を見るのに向く
・フォロワー調査:get_follower_idsは継続トークン(start)で続きを取る設計。件数が多いアカウントでは複数回の呼び出しになる
・プロフィール確認:get_profileで表示名、アイコンURL、ステータスメッセージ、言語を取る
・リッチメニューの試作:テンプレート6種の範囲で、アクションを変えながら作り直す
逆に向かないのは、Webhookで受信したメッセージに自動返信する常駐Botだ。このサーバーにはWebhook受信の機能が無く、ツールはすべてAIクライアントから呼ぶ一方通行の操作に限られる。ClaudeがLINEのメッセージ受信を契機に動く構成は、このサーバー単体では作れない。
競合・代替との比較
| 手段 | AIから直接操作 | LINE APIの網羅性 | Webhook受信 | 向く場面 |
|---|---|---|---|---|
| LINE Bot MCP Server | 可(stdio MCP) | 主要な送信・メニュー・取得のみ | 不可 | 試作・動作確認 |
| @line/bot-sdk(Node) | 自前でLLM連携 | 全機能 | 可 | 本番Bot |
| LINE Developersコンソール | 不可 | 設定・確認 | 設定のみ | 初期設定 |
| n8n等のワークフロー | 限定的 | ノード次第 | ノード次第 | 業務自動化 |
試作で使い、本番は公式SDKに移す。これが現実的な分担になる。同じMCPクラスタの GitHub MCP Server や n8n-mcp も、公式/コミュニティ実装の違いを知る比較材料になる。
・トークンは設定JSONの平文に入る。リポジトリに設定ファイルをコミットしない
・テスト用のLINE公式アカウントを分け、broadcastとcreate_rich_menuは本番アカウントで試さない
・バージョンは明示固定し、更新時にtools/listを再取得して差分を見る
まとめ
LINE Bot MCP Serverは、LINE公式のプレビュー版MCPサーバーだ。2026-10-08の実測では、npm 0.5.0が12ツール、mainが13ツール、要件はNode.js 22以降、スターは784。起動、tools/list、401応答、引数エラーまでは自分で確認した。送信成功とDockerビルドは未検証。
用途は試作と動作確認に絞るのが良い。送信系は実ユーザーに届き、リッチメニュー作成は即デフォルト化される。この2点だけ押さえれば、LINE Bot開発の検証ループを短くする道具として使える。





