LINE Bot Hono×TypeScriptでCloudflare Workersに安全なBotを構築する完全ガイド

ネットの記事通りにコードを書いたはずなのに、TypeScriptの赤い波線（型エラー）が消えない。なんとかローカル環境で動かしてCloudflare Workersへデプロイしたものの、環境変数がうまく読み込めずにBotが沈黙してしまい、エラーログを前に途方に暮れていませんか？

最近のモダン開発において、超軽量フレームワークの「Hono」と、サーバーレスの「Cloudflare Workers」の組み合わせは有力な選択肢です。しかし、公式ドキュメントがシンプルな点や、Web上にある古い記事をそのまま真似してしまうことで、TypeScriptの型定義、エッジ環境特有の環境変数、Webhook署名検証で足止めされるケースがあります。

本記事では、2026年5月時点で確認できるHono、Cloudflare Workers、LINE Developersの公式情報を前提に、TypeScriptで型安全にLINE Botを動かすための実装例を紹介します。Cloudflare Workersにおける環境変数（Bindings）の正しい扱い方、Node.jsのライブラリに依存しない軽量な署名検証、Wranglerを使ったデプロイ手順まで整理しました。全体像から確認したい場合は、先にCloudflare WorkersでLINE Botを動かす基本手順もあわせて確認すると理解しやすくなります。

---

この記事の執筆者：辺見 創（へんみ はじめ）
シニア・エッジアプリケーションアーキテクト / フルスタックエンジニア
【専門領域】 エッジコンピューティング（Cloudflare Workers）、モダンWebフレームワーク（Hono）、TypeScriptによる型安全なAPI設計。
【実績】 過去5年間で 30以上 の商用サーバーレスシステムを構築。Honoを使ったエッジアプリケーションやWebhook APIの設計・改善を支援。
【メッセージ】 私もかつて、仕様変更による環境変数のエラーや型エラーで悩んだ経験があります。一歩先を行くエンジニアの先輩として、あなたの足止めをここで終わらせるために、実務で使いやすい最新ベストプラクティスを共有します。

---

なぜLINE Bot開発で「Hono×Cloudflare Workers」が有力な選択肢なのか

従来のLINE Bot開発では、Node.jsとExpressの組み合わせがよく使われてきました。しかし、Node.jsとExpressを用いた従来のシステム構成をサーバーレス環境で動かす場合、依存関係が増えやすく、環境によっては起動遅延や設定差分に悩まされることがあります。

LINEのWebhookでは、BotサーバーがHTTPステータスコード 200 番台を返すことが重要です。さらに、LINE Developersのエラー統計では、一定時間内にレスポンスが返らない場合に request_timeout として扱われるため、Webhook処理はできるだけ軽く保つ必要があります。

この課題に対して相性がよいのが、エッジランタイムである Cloudflare Workers と、Web標準APIをベースに設計された軽量フレームワーク Hono の組み合わせです。HonoはCloudflare Workers上で動かしやすく、fetch や Request / Response といったWeb標準のAPIを自然に扱えます。

Cloudflare WorkersとHonoを組み合わせると、次のようなメリットがあります。

• HTTPSのWebhook URLを用意しやすい
• サーバー管理なしでLINE Botを公開しやすい
• Honoの c.env でBindingsを型安全に扱える
• Web Crypto APIやFetch APIを使い、外部ライブラリを減らしやすい

一方で、Cloudflare Workersは一般的なNode.jsサーバーとは環境変数や利用できるAPIが異なります。process.env 前提のコードをそのまま持ち込むと、本番環境で動かない原因になります。LINE BotをTypeScriptで作る基本を先に押さえておくと、型定義やイベント処理の理解がよりスムーズです。

---

【罠を回避】コピペで動く、型安全なHono×LINE Botの完全ソースコード

Node.jsでの開発経験があるフロントエンドエンジニアが、Cloudflare Workersの環境で最も頻繁に踏み抜く罠が「環境変数の読み込み」です。

Node.js環境であれば、チャネルアクセストークンなどの機密情報は process.env.LINE_CHANNEL_ACCESS_TOKEN のように取得するのが一般的です。しかし、Cloudflare Workers環境では、Honoのコンテキスト c.env からBindingsを取得する構成が基本です。 古いネット記事を参考に process.env 前提のコードを書くと、ローカルでは偶然動いたように見えても、本番のCloudflare環境で値が読めず、Botが応答しない原因になります。

Honoでは、Cloudflare Workersの環境変数を、リクエストごとに生成されるコンテキストオブジェクト（c.env）経由で取得します。TypeScriptの型定義を通し、インテリセンス（コード補完）を効かせるには、Honoのインスタンス化の段階で、Generics（ジェネリクス）を用いて Bindings に環境変数の型を明示的にバインドします。

以下に、型安全に環境変数を扱うオウム返し（Echo）Botのサンプルコードを示します。実運用では、この後に紹介する署名検証も組み込んでください。

import { Hono } from 'hono'

// Cloudflare Workersの環境変数の型を定義
type Bindings = {
  LINE_CHANNEL_SECRET: string
  LINE_CHANNEL_ACCESS_TOKEN: string
}

// Honoに環境変数の型（Bindings）をバインドしてインスタンス化
const app = new Hono<{ Bindings: Bindings }>()

// LINEからのWebhookリクエストを受け取るルート（/webhook）を設定
app.post('/webhook', async (c) => {
  // コンテキストオブジェクト c.env から型安全に環境変数を取得
  const channelAccessToken = c.env.LINE_CHANNEL_ACCESS_TOKEN
  const channelSecret = c.env.LINE_CHANNEL_SECRET

  // channelSecretは署名検証で使用します
  console.log('Channel secret is configured:', Boolean(channelSecret))

  // リクエストのテキストデータを取得
  const body = await c.req.text()

  let parsedBody: any
  try {
    parsedBody = JSON.parse(body)
  } catch (err) {
    return c.text('Invalid JSON', 400)
  }

  const events = parsedBody.events
  if (!events || events.length === 0) {
    return c.text('OK', 200)
  }

  // 各イベントを処理（今回は簡易的なオウム返しロジック）
  for (const event of events) {
    if (event.type === 'message' && event.message.type === 'text') {
      const replyToken = event.replyToken
      const userMessage = event.message.text

      // LINE Messaging API への応答リクエスト（Fetch APIを使用）
      await fetch('https://api.line.me/v2/bot/message/reply', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Authorization': `Bearer ${channelAccessToken}`
        },
        body: JSON.stringify({
          replyToken: replyToken,
          messages: [
            {
              type: 'text',
              text: userMessage // ユーザーから送られたテキストをそのままオウム返し
            }
          ]
        })
      })
    }
  }

  // LINEサーバーに対してステータス200を返す
  return c.text('OK', 200)
})

export default app

---

✍️ 専門家の経験からの一言アドバイス
【結論】: Cloudflare WorkersでLINE Botを作る場合は、まずWeb標準APIだけで最小構成を動かすのがおすすめです。
なぜなら、Node.js向けライブラリの中には、内部でNode固有のモジュールに依存しているものがあるためです。エッジ環境では、依存関係が増えるほどデプロイ時のエラーやバンドルサイズの問題に気づきにくくなります。Honoの強みを活かすなら、上記コードのようにWeb標準の fetch APIを用いてLINEのAPIエンドポイントへ直接リクエストを送ると、構成を軽く保ちやすくなります。この知見が、あなたの成功の助けになれば幸いです。

---

本番運用に必須！Web Crypto APIを使った超軽量な「署名検証」の実装

多くの技術ブログや「やってみた」系のチュートリアル記事では、コードの簡略化のために、LINEから送られてくるリクエストの「署名検証（Signature Verification）」を省略していることがあります。しかし、署名検証を行わないBotは、外部から送られたリクエストをLINE公式からの正しい通信だと誤認して処理してしまう可能性があります。

LINE Messaging APIでは、リクエストの送信時に、HTTPヘッダーに x-line-signature という署名が付与されます。これは、リクエストボディと LINE_CHANNEL_SECRET（チャネルシークレット）を用いてHMAC-SHA256アルゴリズムで計算された値です。

Node.js環境であれば crypto モジュールを使う実装が一般的です。一方、Cloudflare Workersのエッジ環境では、Web標準である Web Crypto API (crypto.subtle) を使用して検証できます。外部ライブラリを増やさず、軽量な構成を保ちたい場合に向いています。

以下は、Honoのハンドラー内に組み込める、Web Crypto APIを使用した署名検証のサンプルコードです。

// Web Crypto APIを使用したLINEの署名検証関数
async function verifyLineSignature(
  body: string,
  channelSecret: string,
  signature: string
): Promise<boolean> {
  const encoder = new TextEncoder()

  const key = await crypto.subtle.importKey(
    'raw',
    encoder.encode(channelSecret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const signatureBuffer = await crypto.subtle.sign(
    'HMAC',
    key,
    encoder.encode(body)
  )

  const generatedSignature = btoa(
    String.fromCharCode(...new Uint8Array(signatureBuffer))
  )

  return generatedSignature === signature
}

// Honoのルート内での使用例
app.post('/webhook', async (c) => {
  const body = await c.req.text()
  const signature = c.req.header('x-line-signature')

  if (!signature) {
    return c.text('Unauthorized', 401)
  }

  // 署名検証を実行
  const isValid = await verifyLineSignature(body, c.env.LINE_CHANNEL_SECRET, signature)
  if (!isValid) {
    // 署名が一致しないリクエストは処理しない
    return c.text('Invalid Signature', 401)
  }

  // --- 以降にオウム返しなどの正常処理を記述 ---
  return c.text('OK', 200)
})

重要なのは、署名検証の前にリクエストボディを加工しないことです。LINEの公式情報でも、受け取った署名とリクエストボディ文字列をそのまま使って検証することが案内されています。公開運用や顧客対応Botでは、簡易サンプルのまま公開せず、署名検証を必ず組み込んでください。

---

Wranglerでの一発デプロイ手順とLINE Developersの連携フロー

ローカル環境でコードが書けたら、CloudflareのCLIツールである Wrangler を使用して、Cloudflare Workersへ公開します。そして、発行されたエンドポイントURLをLINE Developersの管理画面に結びつけることで、実機でのテストを行います。RenderやNetlifyなど他の公開先との違いも知りたい場合は、LINE開発のデプロイ手順も参考になります。

LINE公式アカウントとMessaging APIの準備がまだの場合は、先にMessaging APIの初期設定の流れを確認してください。プロバイダー選択、チャネル確認、アクセストークン発行の順番を整理しておくと、後のWebhook設定で迷いにくくなります。

具体的な設定の流れと、注意すべき設定キーの対応関係を以下の表にまとめました。

📊 比較表
表タイトル: Wrangler（Cloudflare）と LINE Developers の設定対応マップ

手順	実行環境 / 管理画面	操作内容と必要な設定	注意点・チェックポイント
1. 公開デプロイ	ターミナル（CLI）	npx wrangler deploy を実行し、生成された https://xxx.workers.dev 形式のURLをコピーする。	コマンド実行には、事前に npx wrangler login での認証が必要です。
2. 環境変数の登録	ターミナル（CLI）	npx wrangler secret put LINE_CHANNEL_SECRET npx wrangler secret put LINE_CHANNEL_ACCESS_TOKEN を実行し、LINE側から取得した値をそれぞれ登録する。	アクセストークンやチャネルシークレットは、ソースコードやGitHubに直接書かないでください。登録後に再デプロイすると反映漏れを避けやすくなります。
3. Webhookの登録	LINE Developers 画面	「Messaging API設定」タブ内の「Webhook URL」に、手順1のURLにルートを追加した形式（例: https://xxx.workers.dev/webhook）を入力して保存する。	忘れずに「Webhookの利用」トグルスイッチを「ON」に切り替えてください。検証に失敗する場合は、Webhook URLの設定確認を見直しましょう。

デプロイは短時間で完了します。ただし、公開URL、Webhookのパス、Secretsの登録名が1文字でもずれると、Botは正常に応答しません。特に LINE_CHANNEL_SECRET と LINE_CHANNEL_ACCESS_TOKEN の名前は、コード側のBindings定義と完全に一致させてください。

---

Webhook検証でエラーが出る・動かないときのチェックリスト

設定を終えてLINE Developers画面の「検証」ボタンを押したとき、エラーやステータスコード（例: 500 Internal Server Error）が返ってくることがあります。開発者から寄せられるトラブル相談では、環境変数、URLパス、署名検証、レスポンスコードのどれかに原因があるケースが多いです。動かないときは、焦らずにこのチェックリストを確認してください。

Q1: LINE側の「検証」ボタンを押すとエラーが出るが、何が原因か？

• 原因1: wrangler secret の登録忘れ、または反映漏れ
  ローカルの wrangler.toml や .dev.vars ファイルに環境変数を書いただけで満足していませんか？それらは本番環境のCloudflare Workersに自動で登録されるものではありません。必ず上記の手順に従って npx wrangler secret put コマンドを使用し、Cloudflare側へシークレットを登録してください。
• 原因2: URLパス（ルート）の指定ミス
  LINE Developersの画面に入力したURLの末尾が、ドメイン直下（https://xxx.workers.dev）で終わっていませんか？ソースコード側で app.post('/webhook', ...) と定義している場合、LINE Developersの画面に登録すべき正しいWebhook URLは、末尾にパスを付加した https://xxx.workers.dev/webhook になります。
• 原因3: 署名検証前にbodyを加工している
  署名検証では、LINEから届いたリクエストボディ文字列をそのまま使う必要があります。JSONパース後のオブジェクトを再度文字列化して検証すると、空白や順序の違いで署名が一致しない可能性があります。

ログを確認する場合は、Cloudflare Workersのダッシュボードまたは npx wrangler tail を使います。LINE Developers側ではWebhookの検証結果やエラー統計も確認できるため、両方を見ながら原因を切り分けましょう。

---

クリーンなコードから、最高の個人開発をはじめよう

お疲れ様でした。型定義の波線を減らしやすいHonoのBindings設定、エッジ環境に適した軽量な署名検証、Cloudflare Workersへのデプロイまで、モダンなLINE Bot開発に必要な土台を一通り確認できました。

これで、スマートフォンからメッセージを送信し、オウム返しが返ってくるところまで到達できるはずです。エラーに足止めされる時間を減らすには、最初から複雑なAI連携やDB連携を入れず、まずWebhook、Secrets、署名検証、返信処理の4点を小さく動かすことが大切です。

この土台ができたら、データベースと連携した便利ツール、生成AI APIとのインテグレーション、ユーザー状態を保存するBotなどへ拡張できます。まずは「安全に受け取り、安全に返す」構成を固めてから、オリジナル機能へ進みましょう。

---

---

トラブル解決！LINE Bot Honoに関するよくある質問 (FAQ)

LINE BotをHonoとCloudflare Workersで作るときに、初心者がつまずきやすいポイントをQ&A形式でまとめました。