【コードで解説】コンシェルジュMVPはこう作る!LINEとスプレッドシートで始める最速検証ガイド
.png&w=3840&q=75)
前回の記事では、「最速で学びを得るためのMVP設計法」として、完璧なプロダクトを作る前に、人力で価値を提供する「コンシェルジュMVP」が有効であると解説しました。
しかし、「人力でやるって、具体的にどうすればいいの?」「結局、専門的な知識が必要なんじゃない?」と感じた方も多いかもしれません。
そこで今回は、その疑問にお答えします。特別なサーバーや高価なツールは一切不要。多くの人が普段から使っている「LINE」と「Googleスプレッドシート」を組み合わせるだけで、コンシェルジュMVPの仕組みがいかに簡単に作れるか、具体的なコード例を交えながらステップ・バイ・ステップで解説します。
今回作るコンシェルジュMVPのシナリオ
前回から引き続き、「20代後半〜30代前半の働く女性向け健康管理アプリ」のMVPを想定します。
- 検証したい仮説: ユーザーは月額500円を払ってでも、専門家からパーソナライズされた体調アドバイスを受け取りたいか?
- ユーザー体験:
- 専用のLINE公式アカウントを友だち追加する。
- 毎日、LINEで体調を簡単なテキストで報告する。(例:「今日は少し頭が重い感じ。睡眠は6時間でした」)
- 1営業日以内に、運営チームからパーソナライズされたアドバイスがLINEに届く。
- 運営側の動き:
- ユーザーからの報告がGoogleスプレッドシートに自動で蓄積される。
- 運営チーム(専門家)はスプレッドシートを確認し、アドバイスを考える。
- スプレッドシートに返信内容を入力すると、自動でユーザーのLINEに送信される。
この一連の流れを、ほぼ無料で実現する仕組みを作っていきます。
使用するツール(技術スタック)
- ユーザーとの窓口: LINE Messaging API
- LINE公式アカウントを通じてユーザーと1対1のやり取りをするためのAPIです。無料プランの範囲で十分に検証可能です。
- データベース兼管理画面: Googleスプレッドシート
- ユーザー情報ややり取りの履歴を記録するデータベースとして、また運営チームが作業するための管理画面として利用します。
- 自動化の心臓部: Google Apps Script (GAS)
- スプレッドシートやGmailなどを操作できるプログラミング環境。LINEとスプレッドシートを繋ぐ「糊(のり)」の役割を果たします。
サーバー契約もデータベース構築も不要。この3つだけで完結します。
STEP 1: LINEからのメッセージをスプレッドシートに自動記録する
まずは、ユーザーがLINEで送ったメッセージを、リアルタイムでスプレッドシートに記録する仕組みを作ります。
仕組みの全体像:
ユーザーがLINE送信 → LINEのサーバー (Webhook) → GAS → スプレッドシートに追記
具体的なコード (Google Apps Script):
Googleスプレッドシートを開き、「拡張機能」>「Apps Script」から以下のコードを貼り付けます。
// LINE Developersで取得したチャンネルアクセストークン
const CHANNEL_ACCESS_TOKEN = 'ここにあなたのチャンネルアクセストークンを入力';
// 記録用のスプレッドシートID
const SPREADSHEET_ID = 'ここにあなたのスプレッドシートIDを入力';
// 記録用のシート名
const SHEET_NAME = 'ユーザーログ';
// LINEサーバーからWebhook経由でPOSTリクエストが来た時に実行される関数
function doPost(e) {
// WebhookのJSONデータをパース(解析)する
const event = JSON.parse(e.postData.contents).events[0];
// テキストメッセージの場合のみ処理する
if (event.type === 'message' && event.message.type === 'text') {
// ユーザーID、メッセージ内容、タイムスタンプを取得
const userId = event.source.userId;
const userMessage = event.message.text;
const timestamp = new Date(event.timestamp);
// スプレッドシートに書き込む
const sheet = SpreadsheetApp.openById(SPREADSHEET_ID).getSheetByName(SHEET_NAME);
sheet.appendRow([timestamp, userId, userMessage, '', '未返信']); // D列(返信内容)、E列(ステータス)は空で追加
}
return ContentService.createTextOutput(JSON.stringify({'status': 'ok'})).setMimeType(ContentService.MimeType.JSON);
}
何をやっているか?
- LINEでメッセージが送信されると、LINEのサーバーがこのGASのプログラム(doPost関数)を呼び出します。
- プログラムは、送られてきた情報の中から「誰が(userId)」「何を(userMessage)」送ったかを取り出します。
- 指定したスプレッドシートを開き、appendRowという命令で最終行に新しい行として情報を書き込みます。
このGASを「ウェブアプリ」としてデプロイし、発行されたURLをLINE Developersの「Webhook URL」に設定すれば、連携は完了です。
完成したスプレッドシートのイメージ:

STEP 2: スプレッドシートからLINEに返信する
次に、運営チームがスプレッドシートのD列にアドバイスを入力したら、それがユーザーのLINEに届く仕組みを作ります。
仕組みの全体像:
運営がスプレッドシート入力 → GAS(手動実行 or トリガー) → LINE Messaging API → ユーザーにLINEが届く
具体的なコード (Google Apps Script):
先ほどのスクリプトエディタに、以下の関数を追加します。
// スプレッドシートからメッセージを送信する関数
function sendReplyMessages() {
const sheet = SpreadsheetApp.openById(SPREADSHEET_ID).getSheetByName(SHEET_NAME);
const lastRow = sheet.getLastRow();
const dataRange = sheet.getRange(2, 1, lastRow - 1, 5); // 2行目から最終行、5列分(A-E)のデータを取得
const values = dataRange.getValues();
// 各行をチェック
for (let i = 0; i < values.length; i++) {
const row = values[i];
const userId = row[1]; // B列: ユーザーID
const replyMessage = row[3]; // D列: 返信内容
const status = row[4]; // E列: ステータス
// D列に返信内容が入力されていて、かつE列が「未返信」の場合のみ送信
if (replyMessage && status === '未返信') {
const url = 'https://api.line.me/v2/bot/message/push';
const payload = {
'to': userId,
'messages': [{
'type': 'text',
'text': replyMessage,
}],
};
const options = {
'method': 'post',
'contentType': 'application/json',
'headers': {
'Authorization': 'Bearer ' + CHANNEL_ACCESS_TOKEN,
},
'payload': JSON.stringify(payload),
};
// LINE APIにリクエストを送信
UrlFetchApp.fetch(url, options);
// 送信後、ステータスを「返信済み」に更新
sheet.getRange(i + 2, 5).setValue('返信済み');
}
}
}
何をやっているか?
- このsendReplyMessages関数を実行すると、スプレッドシートの全行をチェックします。
- もし「返信内容(D列)」が入力済みで、かつ「ステータス(E列)」が"未返信"の行を見つけたら、
- その行の「ユーザーID(B列)」と「返信内容(D列)」を使って、LINEのAPIに「この人にこのメッセージを送って」というお願い(POSTリクエスト)をします。
- 送信が成功したら、混乱しないように「ステータス(E列)」を"返信済み"に書き換えます。
運営チームは、スプレッドシートにアドバイスを書き溜めておき、1日に1回、GASのエディタ画面からこのsendReplyMessages関数をポチッと実行するだけで、全ユーザーへの返信が完了します。
まとめ:これは「開発」ではなく「検証の仕組み作り」
いかがでしたでしょうか。驚くほどシンプルなコードと、普段使っているツールだけで、コンシェルジュMVPの核となる仕組みが作れることをご理解いただけたかと思います。
重要なのは、このコードは「プロダクト」ではないということです。
これは、あなたの事業における最もクリティカルな仮説を「検証するための使い捨ての装置」にすぎません。
- エラー処理は甘いかもしれません。
- デザインもお世辞にも綺麗とは言えません。
- ユーザーが1000人になったら破綻します。
しかし、それで良いのです。なんなら全て手動でもいいです。
なぜなら、最初の5人、10人のユーザーが、この不格好なサービスに本当にお金を払ってくれるのか? 彼らの生の声を聞き、深いインサイトを得ることこそが、このMVPの唯一の目的だからです。
仮説が正しいと確信できてから、初めて本格的なアプリ開発を始めれば良いのです。まずはこの「最速の検証装置」で、あなたのアイデアが本当に価値を持つのか、確かめに行きましょう。
こうした検証のためのMVP開発についても承っておりますので、お気軽にご連絡ください。