LINEをAIの入力口にする｜スマホから業務が動く仕組み3つと、作る前に決める判断基準
LINEをAIの入力口にする｜スマホから業務が動く仕組み3つと、作る前に決める判断基準
「ClaudeとLINEをつなげると、結局なにができるのか」。この組み合わせを調べている方の多くは、コードの書き方より先に、そこを知りたいはずです。
結論から書きます。LINEとAIをつないで作れる業務の仕組みは、大きく3種類しかありません。記録型・通知型・状態管理型の3つです。そしてどの型でも構成は共通していて、LINEを「入力口」、GAS（Google Apps Script）を「中継」、スプレッドシートを「保存先」にする3層に落ち着きます。
この記事では、実際に本番稼働している3つの仕組みを型ごとに分解し、どの業務をLINEに載せてよいか、どの順番で作るべきかまでを整理します。個別の実装コードは既存記事に譲り、ここでは「何を作るか・どう設計するか」を扱います。
結論：LINE×AIで作れる仕組みは3種類しかない
3つの型の違いは、「LINEで受け取ったあと、どこまで面倒を見るか」です。
- 記録型：LINEは短文を投げる入力口。出口はスプレッドシートやカレンダーへの記録。難易度は低い
- 通知型：LINEは受け取った情報を人に届ける出力口。出口はスタッフのグループLINEやチャットツール。難易度は低〜中
- 状態管理型：LINEが顧客ごとの状態を持ち、その人に見える画面を変える。出口はLINE画面そのもの（リッチメニューや残数表示）。難易度は高い
記録型と通知型は、実装が数十行のGASで済みます。状態管理型だけは顧客ごとのデータを保持するため、設計を誤ると多くの友だちに誤った画面が出るリスクを抱えます。作る順番も、上から下が正解です。
そして3種類のどれであっても、AI（Claude）の出番は「人間が書いた雑な日本語を、決まった形のデータに変換する」ところだけです。ここを勘違いすると、AIに判断まで任せて事故につながります。AIは翻訳係、判断は仕組みの側で持つ。この線引きが全体を通じた前提になります。
作る前に決める：LINEを入力口にしてよい業務、してはいけない業務
技術的に作れることと、業務に載せてよいことは別です。先に判断基準を持っておくと、あとから作り直す手間が減ります。
LINEを入力口にしてよい業務の条件は4つです。
1. 発生するのが現場や移動中で、PCの前にいない
2. 入力が短文で済む（長文フォームが必要なら外部フォームを使う）
3. 出口が「記録」か「通知」で完結し、その場での判断を伴わない
4. 万一間違って登録されても、後から人が直せる
逆に、次の業務はLINE入力口に向きません。金額や日程を確定させる操作、顧客への返信文面の自動送信、予約のキャンセル処理です。理由は単純で、誤りが顧客に直接届いてしまい、取り消しが効かないからです。同じ理由で、店舗の予約受付を丸ごと自動化する前に人間の確認を1枚挟むという判断も、実務では標準的な設計になります。
判断に迷ったら、「間違った内容が入ったとき、誰が最初に気づくか」を考えてください。スタッフが気づく設計なら載せてよい、顧客が先に気づく設計なら載せてはいけない、という線引きで大きく外しません。
実例1：スマホから送った一文が、タスク表とカレンダーに載る（記録型）
最初に作るべきはこの型です。弊社で本番運用している構成を例に説明します。
移動中に思いついた依頼事項をLINEに一文で送ると、Googleスプレッドシートの「タスク管理」シートに1行追加され、期限があればGoogleカレンダーにも予定が入り、同時にチャットツールへ通知が飛びます。シートは9列（受信日時／グループ名／依頼者／タスク内容／期限／担当／優先度／ステータス／元メッセージ）で、優先度は高＝赤、中＝黄、低＝緑の絵文字で通知文に反映されます。
設計上の要点は3つあります。
入力口を複数持ち、保存先は1つにする。この仕組みには、LINEからの入力とPC作業中のターミナルからの入力という2つの経路がありますが、書き込み先のシートは同一です。入力口ごとにシートを分けると、確認する場所が増えて結局どちらも見なくなります。入力は増やしてよい、保存先は増やさない。これが記録型の原則です。
期限は入力時ではなく、通知側で拾う。登録して終わりでは、シートを見ない日にタスクが埋もれます。GASのトリガーで毎日1回シートを走査し、期限が3日以内のタスクだけを通知する処理を入れています。3日前という設定は意図的なもので、当日通知では間に合わない種類のタスクが必ず出るためです。
登録元がわかる列を必ず持つ。誰が・どの経路で入れたかを列として持っておくと、後から「LINE経由の登録だけ抽出する」といった集計ができます。この列を最初に作らないと、あとから遡って埋める作業が発生します。
実装コードと詰まりどころはLINEに送った文章をClaudeに処理させる｜GAS中継の実装コードと詰まりどころ4つに、システム全体の設計思想はClaude×LINE連携をGASで実装｜送るだけでタスク自動登録にまとめています。
実例2：フォームの回答が、スタッフのグループLINEに自動で流れる（通知型）
名古屋で革製品を扱うEC事業者で構築した構成です。お客様からの修理依頼をフォームで受け、その内容をスタッフが共有するグループLINEへ自動投稿します。
LINE運用ツールのフォーム → スプレッドシート → GAS → LINE公式アカウント → グループLINEこの型で最初に決めるべきは、自作する前に、いま契約しているLINE運用ツールの標準機能で足りないかを確認することです。フォーム連携から通知までを標準機能でカバーできるツールは珍しくありません。実際にこの案件でも、自作のプッシュ送信処理を組む前提で設計を進めていましたが、確認の結果ツール標準のグループ通知機能だけで要件を満たせることが分かり、自作部分は使わずに済んでいます。作り込みの前に一手間かける価値は十分にあります。
自作する場合、通知型で必ず入れる処理が「どこまで処理したかの記録」です。スプレッドシートの変更をトリガーにする構成では、処理済みの行番号を保存しておかないと、実行のたびに過去の依頼まで再送信されます。スタッフのグループに同じ通知が何十件も流れる事態を防ぐため、新着検知・文面整形・送信・処理済み行の記録の4つを別々の関数に分け、記録処理を必須にする設計にします。
もう1点、通知型で先に確認しておくべき仕様があります。LINE公式アカウントからグループへメッセージを送る構成は、そのアカウントのWebhookを外部の運用ツールが使っている場合、思ったとおりに動かないことがあります。Webhookの送信先は1つしか設定できないため、運用ツールとMessaging APIの直接送信が競合し得るからです。この構成を採るなら、着手前に「そのアカウントのWebhookを今どのツールが握っているか」を確認し、必要なら通知専用のチャネルを別に用意する方が安全です。
詳細な列設計と実装手順はLINE公式アカウントに問い合わせフォームがない問題をどう埋めるかで解説しています。
実例3：QRを読むと回数券の残数が減り、メニューが切り替わる（状態管理型）
名古屋の美容サロンFCで構築した、回数券のデジタル化です。友だち数が50万人規模のアカウントで、店頭でスタッフが提示するQRをお客様が読み取ると、その方の残回数が1つ減り、LINEのリッチメニューが残数に応じた券面画像へ自動で切り替わります。3券種（3回券2種・5回券1種）に対して、残数ごとに計14枚のメニューを用意しています。
この型で最重要の設計判断は、「いま何を持っているか」を表す単一のフィールドを1つ立て、そこを正として分岐することです。
回数券のような仕組みでは、残回数という数値だけで表示を分岐させたくなります。しかしこの設計には落とし穴があります。未購入のお客様も、残回数フィールドの初期値は0です。つまり「残0の券面を表示する」という条件に、券を一度も買っていない人まで一致してしまいます。券種が3つあれば3種類の分岐が同時に成立し、最後に実行された表示で上書きされるという挙動になります。
そのため、現在券種のような排他的なフィールドを1つ用意し、購入QRを読んだ時点でそこを上書きする設計にします。表示の分岐条件は「現在券種＝スタートアップ かつ 残回数＝2」のように、券種と残数のANDで組みます。現在券種が未登録なら購入案内を送る、という条件も1本用意しておけば、未購入者が無反応のボタンを押す状態を防げます。
累計購入数のような履歴系の数値を分岐条件に使うのも避けるべきです。過去に別の券種を買った履歴が残っていると、後から複数の条件が同時に成立します。履歴は集計用、現在の状態は状態用と、フィールドの役割を分けておくのが安全な設計です。
状態管理型では、他にも先に決めておくべき点が2つあります。
有効期限は日付単位で判定される前提で設計する。年月日型のフィールドは時刻を持たないため、期限日の23時59分まで有効で、翌日0時から自動的に対象外になります。「購入から6ヶ月」を意図するなら、6ヶ月加算してから1日引く設定にすることで、半年後の同日の前日が期限になります。月末をまたぐケース（8月31日購入など）も、月末調整後に1日引く順序で計算されるかを確認しておきます。
履歴の保存先を、LINEツールの中だけにしない。購入・消化の履歴は運用ツール内のタイムラインには残りますが、そのままでは店舗別の集計や売上の突合ができません。外部のスプレッドシートへ定期的に同期する経路を、最初から設計に含めておきます。このとき、エクスポートしたCSVに含まれるのは「現在の値」だけなので、たとえば来店店舗の情報を過去の購入履歴に後から当てはめると、実際とは違う店舗の実績として記録されてしまいます。イベント発生時点の値をその都度スナップショットとして保存し、記録がない過去分は空欄のままにするのが正しい扱いです。
構築の全記録はLINEで回数券をデジタル化する方法、メニュー切替の実装はリッチメニューを残回数で自動切替する実装にあります。
3つに共通する設計の型
型は違っても、うまく動いている仕組みには共通点があります。
1. LINEは入力口であって、保存先ではない。LINEの中にデータを溜めると、検索も集計もバックアップもできません。受け取ったら必ず外（スプレッドシートなど）へ出します。
2. 状態は「現在の状態を表す1フィールド」で持つ。数値の初期値や履歴の累計で分岐しない。誤作動の原因はほぼここに集約されます。
3. 処理済みの位置を記録する。二重通知・二重登録は、この記録がないときに起きます。再実行しても結果が変わらない作りにしておきます。
4. AIには変換だけを任せる。「この文章からタスク名・期限・優先度をJSONで抜き出す」までがAIの仕事です。登録するかどうか、誰に通知するかは、条件分岐として仕組みの側に書きます。
つまずきやすい箇所を、先に潰しておく
着手前に確認しておくと手戻りが減る箇所を挙げます。いずれも仕様上そうなっているもので、順番に潰せば問題になりません。
- GASのWebアプリにcurlでPOSTすると動かない。GAS側でリダイレクトが発生し、その際にPOSTがGETへ変換されるため、doPostではなくdoGetが呼ばれます。動作確認はPythonのurllib.requestなど、リダイレクト後もPOSTを維持する方法で行います。
- Webhookの設定先は1つだけ。LINE運用ツールを入れているアカウントに、自作のWebhookを後から向けると、既存の自動応答やステップ配信が止まります。自作を足すなら別チャネルを検討します。
- テキスト以外のメッセージが飛んでくる。スタンプ・画像・LINE側の検証リクエストも同じWebhookに届きます。テキスト以外は無視して正常終了を返す分岐を最初に書いておきます。
- APIキーをコードに直接書かない。GASのスクリプトプロパティに保存して読み出します。共有時の事故を確実に防げます。
- 通知先は個人ではなく共有グループにする。担当者個人宛にすると、その人が休みの日に情報が止まります。
APIの料金感と最小コードについてはGASからClaude APIを叩く最小構成、LINE Bot自体の作り方はClaude CodeでLINE Botを作る手順にまとめてあります。
どれから作るか
自社で着手する場合の順番です。
1. 記録型から作る。影響範囲が社内に閉じており、失敗しても顧客に届きません。最初の1本はここで練習します
2. 入力の型を決めてから実装する。何を・誰が・いつまでに、の3項目を必ず取ると決めてから書き始めます。項目は後から増やせますが、既存データの遡り修正は手間です
3. 通知型に広げる。記録が回り始めたら、その記録を人に届ける処理を足します
4. 状態管理型は、業務が固まってから。顧客ごとの状態を持つ仕組みは、途中で仕様が変わると全員分の作り直しになります。運用ルールが確定してから着手します
まとめ
「claude line」で調べたときに知りたいのは、コードそのものより「何が作れて、どこまで任せてよいか」だと思います。作れるのは記録型・通知型・状態管理型の3つ。構成はLINEが入力口、GASが中継、スプレッドシートが保存先という3層で共通しています。
任せてよい範囲の線引きは、間違いに誰が最初に気づくかで判断します。スタッフが気づく設計なら載せてよく、顧客が先に気づく設計なら人の確認を挟む。この基準さえ持っておけば、技術的な詰まりどころは順番に潰せる程度の問題に収まります。
まずは記録型を1本、社内向けに作ってみるところからで十分です。LINEに一文送るだけで記録が残る体験ができれば、次にどの業務を載せるべきかは自然と見えてきます。