LINE Bot MCP ServerでAIに任せる操作・任せない操作｜全員送信とリッチメニューの承認、トークンと送信ログ

LINE Bot MCP Serverは、LINEヤフーがGitHubで公開しているMCP（Model Context Protocol）サーバーです。ClaudeなどのAIエージェントに組み込むと、LINE公式アカウントから友だちへのメッセージ送信、プロフィールの取得、リッチメニューの作成や切り替えを、会話での指示で実行できるようになります。2026年9月25日時点で公開されている最新版はv0.5.0で、ツールは12個あり、リポジトリではプレビュー版（実験的な提供）と位置づけられています（公式リポジトリ）。

任せ方の結論から書きます。AIに任せてよいのは、読み取りと下書き、それに宛先を限った個人宛ての送信までです。友だち全員に届くブロードキャスト（全員送信）と、全員の画面が変わるリッチメニューの変更は、人が中身を確かめて承認してから実行します。ツールに付いている目印では1人への送信と全員への送信を見分けられず、MCPサーバーの側には特定のツールを止める設定も無いため（src/index.ts）、この線引きは使う側で決めて、AIクライアントの設定と社内の手順に落とし込む必要があります。

あわせて、AIに渡すチャネルアクセストークンは、READMEが取得手順を案内している無期限の長期トークンではなく、AI専用に発行した有効期間の短いものにします。ログは、LINEの開発ガイドラインが保存を勧めるリクエストIDを、誰がいつ承認したかの記録と突き合わせられる形で残します。以下では、公式リポジトリのREADMEとソースコード（v0.5.0と2026年9月24日時点のmainブランチ）、LINE Developersのドキュメントで確かめた範囲で、それぞれの中身を説明します。区分や承認の置き方は当社の提案で、LINEヤフーが定めた要件ではありません。

LINE Bot MCP Serverの12ツールと、プレビュー版という位置づけ

LINEヤフーは2025年4月14日、LINE Developersのニュースでこのサーバーの公開を知らせ、試験的な公開のためMessaging APIの機能をすべては扱っていないと断っています（LINE Developersのニュース）。日本語のREADMEの冒頭にも、実験的な目的での提供で、機能やサポートが十分でない場合がある旨の注記があります（README）。

使い方は、AIクライアントの設定にサーバーの起動方法と、チャネルアクセストークン（CHANNEL_ACCESS_TOKEN、必須）、既定の送信先のユーザーID（DESTINATION_USER_ID、任意）を書くだけです。操作の対象はMessaging APIを有効にしたLINE公式アカウントで、個人のLINEアカウントのトークを読み書きするものではありません（同README）。v0.5.0のツールは次の12個です。

出典：v0.5.0のREADMEとツールの定義（src/tools）。「目印」はツールの注釈（readOnlyHint／destructiveHint）。管理画面（LINE Official Account Manager）で作ったリッチメニューが一覧に出ないことはリッチメニューの概要による。区分の列は当社の分類。

ツールは版を追って増えてきました。初版のv0.1.0（2025年4月30日）は送信の4つとプロフィールの取得の5つで、v0.2.0で送信数の確認、v0.3.0でリッチメニューの一覧・削除・切り替え、v0.4.0でリッチメニューの作成、v0.5.0（2026年5月29日）で友だちのユーザーIDの一覧が加わりました（リリース一覧）。mainブランチには2026年9月10日にグループトークの概要を取るget_group_summaryが追加されましたが（追加の変更）、9月25日時点でnpmに公開されている最新版はv0.5.0のままです。READMEの設定例は版を指定せずにnpxで起動する形なので、新しい版が取得されれば、AIが使えるツールもそのまま増えます。区分を決めたら版を固定し、版を上げるときにツールの一覧を見直す手順を入れておきます。

もう一つ、v0.5.0のソースを読むと、サーバーは起動した時点で12のツールをすべて登録し、特定のツールだけを外す設定項目はありません（src/index.ts）。どのツールをAIに使わせるかは、サーバーの外、つまりAIクライアントの設定か、サーバーの手前に置く仕組みで決めることになります。

ツールの目印では「1人に送る」と「全員に送る」を区別できない

v0.5.0では、各ツールにMCPの注釈（annotations）が付きました（v0.5.0のリリースノート）。取得系の4つには読み取り専用を示すreadOnlyHintが、残りの8つには環境を壊しうる変更を示すdestructiveHintが付いています。AIクライアントはこの目印を見て確認の出し方を変えられますが、1人への送信も、友だち全員への送信も、リッチメニューの削除も、同じdestructiveHintです。影響が1人で済むのか全員に及ぶのかは、目印からは読み取れません。

全員送信のツールの説明文には、全員に届くことへの注意書きが入っています（broadcastTextMessage.ts）。ただ、これはAIに読ませる説明で、送信を止める仕組みではありません。MCPの仕様も、注釈はあくまでヒントであり、信頼できないサーバーから受け取った注釈をもとにツールの使い方を決めないよう求めています（MCP仕様のToolAnnotations）。そのうえで仕様は、ツールの呼び出しを人が拒否できる状態を保つこと、影響の大きい操作の前に確認を求めること、呼び出しを監査のために記録することを、クライアントに求めています（MCP仕様のTools）。承認とログの設計は、この求めを自社の操作に合わせて具体的にする作業です。

影響の広さで分ける：読み取り・下書き・個人宛て送信・表示変更・全員送信

当社では、ツールを「外に何かが届くか」「誰の画面に影響するか」「取り消せるか」で分け、区分ごとに人の関わり方を決めることを勧めています。

読み取りでも、get_profileが返す表示名やプロフィール画像は、友だち一人ひとりの情報です。AIに渡してよい範囲や、外部のAIサービスに送るときの注意は、友だちの情報をMCPでAIにつなぐときの個人情報を整理した記事で扱っています。get_follower_idsは認証済アカウントかプレミアムアカウントでしか使えず、ブロックした人やプロフィール情報の取得に同意していない人は一覧に含まれないため、管理画面の友だち数と一致しないことがあります（Messaging APIリファレンス）。

区分をAIクライアントの設定に落とし込む

MCPサーバーの側でツールを止められないので、区分はAIクライアントの設定で反映します。設定のしかたはクライアントごとに違います。一例としてClaude Codeでは、ツールごとに許可（allow）、確認（ask）、禁止（deny）のルールを書け、禁止、確認、許可の順に評価されます。MCPのツールはmcp__サーバー名__ツール名の形で指定し、ツール名そのもので禁止したものは、AIから見えなくなります（Claude Codeの権限設定）。サーバー名をline-botとして登録した場合、上の区分は設定ファイル（settings.json）に次のように書けます。

{
  "permissions": {
    "allow": [
      "mcp__line-bot__get_profile",
      "mcp__line-bot__get_follower_ids",
      "mcp__line-bot__get_message_quota",
      "mcp__line-bot__get_rich_menu_list"
    ],
    "ask": [
      "mcp__line-bot__push_text_message",
      "mcp__line-bot__push_flex_message",
      "mcp__line-bot__create_rich_menu",
      "mcp__line-bot__set_rich_menu_default",
      "mcp__line-bot__cancel_rich_menu_default",
      "mcp__line-bot__delete_rich_menu"
    ],
    "deny": [
      "mcp__line-bot__broadcast_text_message",
      "mcp__line-bot__broadcast_flex_message"
    ]
  }
}

この設定はツール単位で効くため、同じpush_text_messageの呼び出しのうち、宛先が担当者か顧客かまでは区別しません。確認の画面で宛先と本文を目で確かめる運用にするか、宛先で機械的に止めたい場合は、送信ログの節で触れる中継の仕組みを使います。

個人宛て送信で決めておくこと

個人宛てのpush_text_messageとpush_flex_messageは、宛先のuserIdを省くと、環境変数DESTINATION_USER_IDの宛先に送ります（pushTextMessage.ts）。READMEはこの値の調べ方として、開発者が自分のユーザーIDを確かめる手順を案内しています（ユーザーIDを取得する）。既定の宛先を運用担当者本人にしておけば、AIが宛先を書き忘れても、顧客には届きません。

宛先の中身にも注意が要ります。ツールは受け取った値をそのままプッシュメッセージの宛先（to）に渡しており、Messaging APIの宛先にはユーザーIDのほか、グループトークや複数人トークのIDも指定できます（Messaging APIリファレンス）。個人宛てのツールでも、グループに送れるということです。ユーザーIDは「U」のあとに16進数32桁が続く形式なので（ユーザーIDとは）、承認の画面や中継では、この形式と社内の許可リストの両方で宛先を確かめます。

Messaging API開発ガイドラインは、同じユーザーへの大量送信と、存在しないユーザーIDへのリクエストを禁じています（同一ユーザーへの大量送信の禁止、存在しないユーザーIDへのリクエストの禁止）。AIが同じ宛先に何度も送り直したり、会話の途中で組み立てたIDに送ったりすると、これに触れるおそれがあります。宛先はget_follower_idsや自社の顧客データから取ったIDに限り、1人あたり1日に送る回数の上限も決めておきます。

送信に失敗したときの扱いも、先に決めておきます。LINEのドキュメントによると、500番台のエラーやタイムアウトが起きても、メッセージは送られている場合があり、同じリクエストを送り直すと相手に2回届きます。これを防ぐリトライキー（X-Line-Retry-Key）は、最初のリクエストで付けておく必要があります（失敗したAPIリクエストを再試行する）。ところがMCPサーバーのツールの入力は宛先と本文だけで、ソースを見ても送信時にリトライキーを付けていません（pushTextMessage.ts）。送信のツールがエラーを返したら、AIに自動で送り直させず、人が届いたかどうかを確かめてから次を決める、というルールを明文化しておきます。

送信の結果が成功でも、届いたとは限りません。ブロックしているユーザーや、友だち追加していないユーザー（1対1のトークで7日以内にメッセージをくれた人を除く）に送った場合もステータスコード200が返り、実際には届きません（Messaging APIリファレンス）。また、プッシュで送った分も、料金プランで決まる月の通数に含めて数えられます（Messaging APIの料金）。

全員送信とリッチメニューの変更は、人が承認してから

全員送信は、AIに下書きまでを任せる

ブロードキャストは、LINE公式アカウントと友だちになっている全員に同じメッセージを送る機能で、通数は送信の対象になった人数で数えられます（Messaging APIリファレンス、Messaging APIの料金）。LINE Developersは、チャネルアクセストークンが漏れたときの被害の例として、第三者がブロードキャストで悪意のあるメッセージを全員に送れてしまうことを挙げています（チャネルアクセストークン）。AIが全員送信のツールを使える状態は、同じ出口を、指示の取り違えやAIの思い違いに対しても開けておくことになります。

そこで当社では、全員送信のツールはAIクライアントの設定で禁止し、AIの役目を下書きと、担当者本人への試し送りまでにする形を勧めています。試し送りはpush_flex_messageで担当者自身に送り、スマートフォンで表示と代替テキストを確かめます。本番の送信は、別の担当者が文面・リンク先・送信時刻を確かめたうえで、人が行います。

どうしてもAIのツールで全員送信をする場合は、1回ごとの確認に加えて、送る前にget_message_quotaで当月の通数の目安と利用数を確かめること（上限を超える送信はエラーになり、送られません）と、2人目の承認を記録に残すことを条件にします（Messaging APIの料金）。送信の結果は空のJSONで返り（Messaging APIリファレンス）、どの配信だったかを後から特定できる値は、ツールの結果に含まれません。記録の残し方は送信ログの節で扱います。

リッチメニューは「作成と同時に全員へ表示」を前提に承認する

create_rich_menuは1回の呼び出しで、リッチメニューの作成、ボタンの名前を入れた画像の自動生成とアップロード、デフォルトへの設定までを続けて行います（createRichMenu.ts、v0.4.0のリリースノート）。作ったものを確かめてから公開する、という間はありません。入力はトーク画面のメニューバーの文言と、1〜6個のボタンの動作（URLを開く、メッセージを送るなど）だけで、画像のデザインを指定する項目もありません。承認は、ツールを呼ぶ前に、ボタンの名前・種類・開くURLの一覧を見て行います。

デフォルトのリッチメニューは、トーク画面を開いたすべてのユーザーに表示されます。表示の優先順位は、Messaging APIで設定するユーザー単位のもの、Messaging APIで設定するデフォルト、LINE Official Account Managerで設定するデフォルトの順です（リッチメニューの概要）。つまり、AIがAPIで設定したデフォルトは、マーケティング担当が管理画面で設定したリッチメニューより優先して表示されます。変更は、ユーザーがトーク画面を開き直したときに反映され、1分ほどかかることがあります（反映されるタイミング）。

運用の担当者と共有しておきたいのは、APIで作ったリッチメニューは管理画面では編集できず、表示回数やクリックの統計も管理画面では見られない（APIでしか取れない）ことです（設定するツール、統計情報）。AIに作らせたメニューの効果は、普段見ている管理画面の数字では追えません。

戻し方も承認の時点で決めておきます。cancel_rich_menu_defaultはMessaging APIで設定したデフォルトを解除するツールで（Messaging APIリファレンス）、優先順位の仕様から、管理画面でデフォルトを設定していれば、解除するとそのメニューが表示される状態に戻ります。承認の記録には、変更の前に表示されていたメニュー（管理画面のものか、APIで設定したどのIDか）を残します。delete_rich_menuで消したメニューを戻すツールは無いため、削除は作成や切り替えよりも重く扱います。

チャネルアクセストークンは、AI用に分けて短命にする

READMEは、CHANNEL_ACCESS_TOKENの取得方法として長期のチャネルアクセストークンの手順へ案内し、設定例ではトークンをAIクライアントの設定ファイルに直接書いています（README）。長期のトークンには有効期限がありません（長期のチャネルアクセストークン）。設定ファイルが残っている限り、全員送信もできる鍵がそのパソコンに置かれ続けることになります。チャネルアクセストークンには次の4種類があります。

出典：チャネルアクセストークンの種類、チャネルアクセストークンv2.1を発行する、Messaging APIリファレンスのステートレス・短期・v2.1の取り消しの各項。

LINE Developersは、トークンを開発チームや利用者のグループごとに発行し、1つが漏れたり再発行が要ったりしても、ほかに影響しない運用を例に挙げています（チャネルアクセストークンの運用例）。AIエージェントも利用者の一つとして扱い、人が使うシステムとは別に、専用のトークンを発行します。

種類は使い方で選びます（当社の提案）。その日の下書きと試し送りのような単発の作業なら、15分で切れるステートレスのトークンが合います。LINEも、ステートレスは使うたびに発行する使い方を想定していると説明しています。ただし、発行したものを取り消すことはできません。日々の運用で続けて使うなら、v2.1で有効期間を業務の区切り（例えば1日）に合わせ、使い終えたら取り消します。v2.1と短期のトークンは、使うたびに発行し直さないよう求められています（有効期間内は繰り返し使用できます）。

MCPサーバーは、起動したときに環境変数からトークンを一度読むだけで、期限が近づいても自分では取り直しません（src/index.ts）。LINEは期限が切れる前に新しいトークンを自動で発行する仕組みを勧めていますが（同）、その仕組みはMCPサーバーの外に用意し、期限が来たら新しいトークンでサーバーを起動し直します。発行に使うチャネルシークレットやアサーション署名キーの秘密鍵は、トークンより強い権限の元です。AIクライアントの設定ファイルやAIが読める作業フォルダには置かず、発行は人か、AIから切り離した仕組みで行います。

試す段階は、本番とは別の検証用のLINE公式アカウントで行います。LINE Developersに載っている日本の料金プランの例では、月額0円のコミュニケーションプランでも月200通まで送れます（Messaging APIの料金）。

送信ログは、承認の記録とLINEのリクエストIDをつなげて残す

Messaging API開発ガイドラインは、APIへのリクエストのログとして、レスポンスヘッダーのリクエストID（x-line-request-id）、リクエストの時刻、HTTPメソッド、呼んだエンドポイント、返ってきたステータスコードを一定期間保存するよう勧め、リクエストとレスポンスの本文も役に立つとしています。LINEヤフーは問い合わせを受けてもログを提供しないため、保存は開発者の責任です（ログ保存の推奨）。

ところが、MCPサーバーがAIに返すツールの結果は、レスポンスの本文だけです（src/common/response.ts）。プッシュなら送ったメッセージのID（sentMessages）が入りますが、ブロードキャストは空のJSONで（Messaging APIリファレンス）、どちらにもリクエストIDやステータスコードは含まれません。AIクライアントの会話履歴を残すだけでは、ガイドラインが挙げる項目はそろわないため、記録は2か所で取ります。

HTTPの層で取る方法として、v0.5.0のソースには、Messaging APIの接続先を環境変数LINE_MESSAGING_API_BASE_URLで差し替える処理があります（src/index.ts）。公式リポジトリのテストも、この変数で接続先を手元の模擬サーバーに向け、届いたリクエストを記録しています（E2Eテスト）。同じ仕組みで社内の中継サーバーを通せば、リクエストIDを記録したり、全員送信のエンドポイントを止めたり、宛先を許可リストと照合したりできます。ただし、READMEには載っていない設定で、v0.5.0ではリッチメニュー画像のアップロード（api-data.line.me宛て）はこの差し替えの対象外です。プレビュー版なので、版を上げるたびに挙動を確かめます。ライセンスはApache License 2.0なので、ツールを減らしたりログを足したりした改修版を自社で持つ方法もあります（LICENSE）。

突き合わせのために、承認の記録にはツールの入力と実行した時刻を残し、HTTPの層のログと、時刻・エンドポイント・宛先で照合できるようにしておきます。ステータスコード200は、LINEプラットフォームが受け付けたことを示すもので、相手に届いたことの証明ではない点も（Messaging APIリファレンス）、ログを読む人と共有しておきます。保存期間はガイドラインに定めがなく「一定期間」とあるだけなので（ログ保存の推奨）、社内の記録の規程に合わせて決めます。

試す順番：検証用のアカウントから広げる

ここまでの内容を、試す順番に並べ直すと次のようになります（当社の提案）。

1. 検証用のLINE公式アカウントでMessaging APIを有効にし、AI専用のトークンを発行する。DESTINATION_USER_IDは担当者本人のユーザーIDにする。
2. 最初は読み取りのツールと担当者本人への送信だけを許可し、全員送信と表示変更は禁止する。模擬サーバーに向けて、AIがどのツールをどんな入力で呼ぶかを先に見ておく方法もある。
3. 区分の表、承認のしかた、ログの項目、使うMCPサーバーの版を、社内の生成AIの利用ルールに書く。
4. 本番のアカウントでは、顧客宛ての個人送信を1通ずつの承認から始め、ログを見直してから許可の範囲を広げるかを決める。全員送信は人が送る運用を続ける。

LINE Bot MCP Serverについてよくある質問

まとめ

LINE Bot MCP Serverのツールは、どれもLINE公式アカウントの権限でそのまま実行されます。ツールの目印とサーバーの設定だけでは、1人への送信、全員への送信、画面の変更を分けられないため、読み取り・下書き・個人宛て送信・表示変更・全員送信の区分を自社で決め、AIクライアントの設定と承認の手順に落とし込みます。トークンはAI専用に有効期間の短いものを発行し、ログは承認の記録とLINEのリクエストIDを突き合わせられる形で残します。

Aurant Technologiesでは、生成AIやMCPを業務に組み込むときの権限と承認の設計をAI活用支援で、LINE公式アカウントとMessaging APIの運用の設計をLINE運用・伴走支援でお手伝いしています。どこまでをAIに任せるかの線引きから、検証用のアカウントでの試行まで、ご相談ください。