LINE公式アカウントと業務システムをつなぐと、利用者の目には一つの連携に見えても、裏側では用途の違う接続キーを使います。設定を担当した人が替わったとき、「何のキーがどこにあるか」が分からないと、連携の確認や復旧に時間がかかります。
この記事では、LINE側と業務システム側のキーの役割を分け、発注時と引き継ぎ時に残しておきたい情報を整理します。キーの値そのものを書き出す必要はありません。
最初に、キーの役割を分けて考える
【事実】LINEのWebhookにはx-line-signatureという署名が付きます。受信側はチャネルシークレットを使い、受け取った本文を変更せずに署名を検証します。LINEへメッセージを送るときなどに使うチャネルアクセストークンは、これとは別のものです。（出典：LINE Developers「Webhookの署名を検証する」、LINE Developers「チャネルアクセストークン」）
【推奨】連携の台帳では、少なくとも「Webhookの確認用」「LINEの機能を使うため」「業務システムへ登録するため」を別の行にします。連携によってはLINEへの送信機能がなく、チャネルアクセストークンを使わない構成もあります。
LINE側：確認用と送信用を混同しない
チャネルシークレットは、Webhookの署名検証に使う
【事実】LINEは、Webhookイベントを処理する前に署名を検証するよう案内しています。チャネルシークレットを再発行すると以前の値は無効になるため、利用中のサービスへの影響を調べてから変更する必要があります。（出典：LINE Developers「Webhookの署名を検証する」）
【推奨】発注時には「署名を検証しているか」「シークレットを替えるとき、どの連携先を更新するか」を確認します。署名のないリクエストや不一致のリクエストを登録処理へ進めないことも、検収の対象です。
チャネルアクセストークンは、LINEの機能を使う権限を示す
【事実】LINEのチャネルアクセストークンには複数の種類と有効期間があります。期限のあるものは更新を組み込む必要があり、漏えいが疑われる場合は取り消し可能な種類を取り消すよう案内されています。（出典：LINE Developers「チャネルアクセストークン」）
【推奨】トークンの種類、有効期限、更新方法を台帳に残します。送信機能を使わない連携なら、「未使用」と明記すれば十分です。
業務システム側：連携に必要な操作だけを許可する
【事実】Salesforceは連携ごとに専用ユーザーを作ることを推奨し、対応するエディションではAPI専用の連携ユーザーライセンスと権限セットを使えます。利用できるエディションとライセンス数には条件があります。（出典：Salesforce Help「Give Integration Users API Only Access」）
【事実】kintoneのAPIトークンは、アプリの設定から発行し、利用できるREST APIの種類をアクセス権で制限できます。（出典：cybozu developer network「APIトークンを使ってみよう」）
【事実】HubSpotは、従来型プライベートアプリの新規作成機能を段階的に終了すると案内しています。2026年9月28日以降に作成されたアカウントでは同日から、それより前のアカウントでは2026年10月26日から新規作成できなくなる予定です。既存アプリはこの変更の対象外で、新しいアカウント内API連携にはService Keysを案内しています。（出典：HubSpot Developer Changelog、2026年10月2日確認）
【推奨】連携先がどれでも、担当者個人の強い権限をそのまま共有する前に、登録・参照・更新のうち必要な操作を洗い出します。既存の設定を確認するときも、いきなりキーを失効させず、影響する機能と更新担当を把握してから変更します。
キーの値は画面と資料に載せず、保管場所だけを記録する
【推奨】チャネルシークレットやAPIトークンの値を、LIFFなど利用者のブラウザで動く画面、公開されるコード、共有資料には書きません。連携サーバー側の環境変数や秘密情報の保管機能を利用し、台帳には実際の値ではなく「どこで管理しているか」と「誰が更新できるか」を記します。
【事実】Google Apps ScriptのWebアプリについて、公式資料のdoPost(e)イベント項目にはリクエストヘッダーが含まれていません。LINEのx-line-signatureをこのイベントだけで検証する構成にはできません。（出典：Google for Developers「Web Apps」）
【推奨】スプレッドシートへ登録する構成でも、Webhookはヘッダーを受け取れて署名を検証できる入口で受け、その後にシートへ渡す方法を検討します。
引き継ぎ用の一枚に書くこと
自社の連携について、次の項目をキーごとに一行ずつ埋めてみてください。値そのものは記入しません。
- 用途：Webhook確認、LINE送信、業務システムへの登録など
- 管理場所：どのサービスの秘密情報保管機能にあるか
- 権限：使える操作と、アクセスできるデータの範囲
- 更新担当：誰が交換し、誰が動作を確認するか
- 交換時の影響：止まりうる機能と、切り替え後の確認方法
【推奨】この一覧が埋まらない箇所だけを、現在の制作・保守担当者に確認します。受付が少なく、担当者が手作業で管理できているなら、連携を急いで増やす必要はありません。今の運用でも、情報の置き場所と引き継ぎ先を決めることから始められます。
まとめ
接続キーを管理するときは、キーの値を集めるよりも、用途・保存場所・権限・更新担当を把握することが先です。まずは自社の連携について、その四つを一枚に書き出してみてください。
整理しても分からない箇所があれば、和-Nodeへの相談で、今の連携構成を一緒に確認できます。