BUILD OR BUY

LINE Messaging APIで
AI返信を自作するときに
詰まる9つの点

LINE Messaging APIとLLMをつなぐだけなら、動くものは短時間で作れます。問題はそのあとです。実際にファンへ公開する段階で必ず引っかかる箇所を、先に並べておきます。自作するかSaaSを使うかの判断材料にしてください。

2026年9月8日AI Friend Studio運営約8分

MINIMUM

最小構成は単純

LINEでAIに返信させる最小構成は、次の4ステップです。

  1. 01

    Messaging APIチャネルを作る

    LINE Developersでチャネルを作成し、Channel secretとChannel access tokenを取得します。

  2. 02

    Webhook URLを登録する

    HTTPSで公開したエンドポイントを登録します。1つのチャネルに対して向き先は1か所だけです。

  3. 03

    受信したイベントをLLMへ渡す

    メッセージ本文を取り出し、生成AIのAPIに投げます。

  4. 04

    リプライトークンで返信する

    Webhookで受け取ったリプライトークンを使って応答します。

ここまでは半日もあれば動きます。以下が、そのあとに出てくる問題です。

PITFALLS

運用に乗せると出てくる9つの問題

  1. 01

    署名検証をしていない

    Webhookエンドポイントは公開URLです。x-line-signature ヘッダをChannel secretで検証しないと、誰でも偽のイベントを投げられます。最初に実装すべき箇所ですが、動作確認の段階では省略されがちです。

  2. 02

    LLMの応答を待つとWebhookがタイムアウトする

    Webhookは即座に200を返すことが前提です。生成AIの応答は数秒かかることがあり、待ってから返すとタイムアウトします。受信したら即ACKし、返信は非同期で行う構成が必要です。

  3. 03

    リプライトークンの期限が切れる

    リプライトークンは1回しか使えず、有効期限があります。非同期にした結果、処理が遅れてトークンが失効すると返信できません。代わりにプッシュ送信を使うことになりますが、こちらは課金対象の通数を消費します。設計の失敗が、そのまま費用になります。

  4. 04

    同じイベントが複数回届く

    ネットワークの状況や再送設定によって、同一イベントが重複して届くことがあります。イベントIDで冪等性を担保しないと、同じ返信が2回送られます。

  5. 05

    会話の記憶をどこに持つか決まっていない

    1往復で完結するボットなら不要ですが、会話を続けるなら履歴の保持が要ります。全履歴をそのままプロンプトに積むとコンテキストが膨らみ、費用と応答時間が線形に増えます。要約や長期記憶の設計が必要です。

  6. 06

    ユーザーごとの分離が甘い

    記憶をユーザー単位で分けていないと、別のファンの会話内容が返信に混ざります。これは一度起きると取り返しがつかない種類の事故です。保存・検索・削除のすべての経路でユーザーIDによる絞り込みを強制する必要があります。

  7. 07

    送信量の制御がない

    1人のユーザーが延々と話しかけると、その分だけAPI費用が出ていきます。1日あたりの上限、1人が使える月間枠の割合、上限到達時の案内など、止める仕組みを先に入れておかないと、月末に気づくことになります。

  8. 08

    公開前に試す場所がない

    プロンプトを変えたときの挙動を、本番のファンに届く前に確認できる経路が必要です。テスト用の記憶と本番の記憶が同じ場所にあると、テストの会話が本番の文脈を汚します。

  9. 09

    シークレットの置き場所

    Channel access tokenとLLMのAPIキーは、コードにも環境変数の平文にも置きたくありません。シークレット管理の仕組みと、漏洩時のローテーション手順が要ります。

DECISION

自作するべきか

上の9点は、どれも解けない問題ではありません。判断すべきなのは「解く価値があるか」⁠です。

状況向いている選択
既存の会員システムやDBと連携したい自作
会話ロジックそのものが事業の中核自作
複数のクリエイターを1つの基盤で運用したい自作するならマルチテナント設計から。相応の工数
会話の運用と設定調整が目的SaaS
障害対応を自分で持ちたくないSaaS

見落とされやすいのは、初期構築より運用の継続コストです。LINEの仕様変更、LLMのモデル更新と価格改定、深夜の障害対応。作った本人が配信者本人である場合、この負担は活動時間を直接削ります。

ARCHITECTURE

AI Friend Studioがどう解いているか

参考までに、同じ問題をAI Friend Studioがどう扱っているかを書いておきます。自作する場合の設計の当たりをつける材料になるはずです。

  • 即時ACKと非同期処理の分離:Webhookは署名検証と受付だけを行い、キューへ積んで即座に200を返します。生成は後段のワーカーが担当します
  • 記憶のスコープ分離:会話の記憶をテナントとユーザーの組で分離し、他のファンの文脈が混ざらないようにしています
  • テストと本番の記憶を分ける:テスト用の記憶だけをリセットでき、本番の会話には影響しません
  • 設定は不変バージョン:公開済みの設定は上書きせず、新しいバージョンを積みます。会話は「公開中のバージョン」⁠を参照します
  • 送信前チェック:公開状態、契約状態、月間上限、送信時間帯、対象割合を確認してから送信します
  • 接続情報の保護:Channel secretとaccess tokenは暗号化して保管し、登録後は管理画面へ再表示しません

TRY IT ON LINE

まず挙動を見る

実装の参考にする前に、応答速度と会話の継続性をデモアカウントで確認できます。

LINEで友だち追加して試す

FAQ

Messaging APIでの自作についてよくある質問

1つのLINE公式アカウントに複数のツールを接続できますか?

Webhookの向き先は1チャネルにつき1か所のため、外部サービスを2つ同時に接続することはできません。自作とSaaSの併用も同様です。

Webhookはどれくらいの速さで応答する必要がありますか?

即座に200を返すことが前提です。生成AIの応答を待ってから返す構成にすると、応答時間が伸びたときにタイムアウトします。受信と生成は分離してください。

リプライトークンが切れたらどうなりますか?

リプライでの返信ができなくなるため、プッシュ送信を使うことになります。プッシュは課金対象の通数を消費するため、遅延がそのまま費用になります。

会話履歴は全部プロンプトに入れればいいですか?

会話が続くほどコンテキストが膨らみ、費用と応答時間が増えます。要約や長期記憶に切り出す設計が必要になります。

署名検証は必須ですか?

Webhookエンドポイントは公開URLです。x-line-signatureヘッダをChannel secretで検証しなければ、第三者が偽のイベントを送信できます。最初に実装すべき箇所です。