結論から言うと
「MEOは、公開後のメンテナンスが9割」 です。
エンジニアは「構造を設計→実装→リリース」で満足しがち。でもMEOは、リリースしてからが本番。「建物のメンテナンス」に似ています。一度建てたら終わりじゃなく、雨漏りを直し、設備を更新し、住み心地を維持し続ける作業。
この記事では、建築→エンジニア転職の私が、「構造」としてMEOを分解します。コード書けるエンジニアなら、マーケターより圧倒的に強いはずのMEO領域。なのに、なぜかエンジニアが手を出さない理由と、具体的な実装戦略を解説します。
1. はじめに：なぜエンジニアがMEOを知るべきか
1.1 「ローカル検索」という巨大市場
「近くのラーメン屋」 で検索する人、Googleマップで探す人。それがMEO（Map Engine Optimization）の領域です。
日本の小売・飲食市場は約140兆円。そのうち70%以上が「来店型」ビジネス。つまり、「Googleマップで見つかるか」 で商売が決まる。
エンジニアが開発するSaaSや、個人開発サービスも、「ローカル」 に紐付くケースが増えています：
- 予約システム（飲食店・美容室向け）
- 地域マッチングアプリ
- 物流・デリバリーの最適化
「MEOできるエンジニア」は、マーケターにはできない「技術的な実装」（API連携、自動化、構造化データ）ができます。これが圧倒的な差別化になります。
1.2 MEOの「技術的負債」
現状のMEO業界、実は 「技術的負債」 だらけです。
- Excel管理された店舗情報
- 手動での投稿更新
- 「SEO対策済み」という古いHTMLタグ
エンジニアが入れば、一発で最適化できる領域です。でも、なぜかエンジニアは「MEO＝マーケの仕事」と思って手を出しません。
||これ、 opportunity loss です|| 🥺
2. MEOを「構造」として理解する
2.1 建築の図面で考えるMEO
建築の現場では、「構造計算図」 がありました。建物が倒れないための、力の流れを可視化したもの。
MEOにも同じような 「構造」 があります。
[Google 検索クエリ]
↓
[Google マップ アルゴリズム]
├─ 近接性（Proximity）：物理的距離
├─ 関連性（Relevance）：カテゴリ・キーワード一致
└─ 知名度（Prominence）：被リンク・レビュー・被言及
↓
[Google Business Profile データ構造]
├─ NAP（Name, Address, Phone）：基本情報
├─ Category（カテゴリ）：階層構造
├─ Attributes（属性）：メタデータ（Wi-Fi有無など）
└─ Posts（投稿）：タイムスタンプ付きコンテンツ
↓
[検索結果表示]
2.2 「耐震設計」＝「アルゴリズムアップデート対策」
建築で「耐震設計」をする理由は、「来るべき地震に備える」 ため。
MEOも同じ。「Googleのアルゴリズムアップデート」 は、地震のように突然来ます。
「スパム対策」（不正なレビュー投稿を排除）
「品質アップデート」（低品質なビジネス情報を降格）
「耐震性のある構造」 とは？
- 構造化データ（Schema.org）で「機械可読な基礎」を作る
- API連携で「自動化されたメンテナンス体制」を作る
- 監視システムで「異常検知」できる仕組みを作る
これが、エンジニアのMEO戦略です。
3. 技術者が取り組むべきMEO最適化（実装編）
3.1 構造化データ：Schema.org/LocalBusiness
「建物の基礎」 にあたるのが、構造化データです。
JSON-LD形式で、Googleに 「このページは、どんな店舗/組織の情報か」 を教えます。
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Prodouga プロドウガ",
"image": "https://example.com/photo.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "本町1-2-3",
"addressLocality": "さいたま市",
"addressRegion": "埼玉県",
"postalCode": "330-0000",
"addressCountry": "JP"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.9089,
"longitude": 139.6503
},
"url": "https://prodouga.com",
"telephone": "+81-48-1234-5678",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "18:00"
}
],
"priceRange": "¥¥"
}
ポイント：
-
@type：「LocalBusiness」または具体的な「Restaurant」「Hospital」など -
geo：緯度経度は必須。住所文字列だけだと、Googleが誤解釈する可能性 -
openingHoursSpecification：ISO 8601形式。日本語の「平日」は機械に通じない
Next.jsでの実装例：
// app/page.tsx または app/layout.tsx
export default function RootLayout() {
const structuredData = {
"@context": "https://schema.org",
"@type": "LocalBusiness",
// ... 上記のJSONデータ
};
return (
<html>
<head>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(structuredData) }}
/>
</head>
<body>{/* ... */}</body>
</html>
);
}
検証方法：
Googleのリッチリザルトテストで、JSON-LDが正しくパースされるか確認しましょう。
3.2 Google Business Profile API：自動化の入口
「建物の管理システム」 にあたるのが、GBP APIです。
手動でGoogle Business Profileを更新するのは、「エレベーターなしのビル」 です。6階まで階段で登るようなもの。APIで自動化すれば、「エレベーター付き」 になります。
APIの有効化手順（簡易版）：
- Google Cloud Consoleでプロジェクト作成
- Business Profile APIを有効化
- OAuth 2.0認証設定（重要：GBP APIはユーザー認証が必要）
- APIキー発行
基本的なエンドポイント：
// TypeScript/Node.jsでの実装例
const { google } = require('googleapis');
const businessProfile = google.mybusinessbusinessinformation({
version: 'v1',
auth: oauth2Client, // OAuth 2.0認証済みクライアント
});
// 店舗情報の取得
const getLocation = async (name: string) => {
const res = await businessProfile.locations.get({
name: `locations/${locationId}`,
});
return res.data;
};
// 店舗情報の更新
const updateLocation = async (locationId: string, data: any) => {
const res = await businessProfile.locations.patch({
name: `locations/${locationId}`,
requestBody: {
title: data.title,
storeCode: data.storeCode,
primaryPhone: data.phone,
// ... 他のフィールド
},
});
return res.data;
};
注意点：
- GBP APIは 「ビジネスアカウント」 が必要。個人のGmailアカウントでは不完全
-
OAuth 2.0のスコープ：
https://www.googleapis.com/auth/business.manage - API制限：1日のリクエスト数に上限あり（大規模運用時は注意）
3.3 レビュー管理の自動化：n8nワークフロー
「建物の設備点検」 にあたるのが、レビュー監視です。
新規レビューが来たら、即座に通知し、返信テンプレートを提示する自動化。
// n8nワークフロー概要
1. 「Google My Business」トリガー（新規レビュー検知）
↓
2. 「Slack」ノード（通知送信）
メッセージ: 「新規レビュー: {{$json.comment}} ★{{$json.starRating}}」
↓
3. 「OpenAI」ノード（GPT-5.2で返信草案生成）
プロンプト: 「以下のレビューに対する丁寧な返信を作成：{{$json.comment}}」
↓
4. 「Google Sheets」ノード（レビュー内容を記録）
↓
5. 「Slack」ノード（承認待ち通知）
「返信草案: {{$json.choices[0].message.content}}」
なぜ「自動返信」しないのか？
||完全な自動化は危険|| 🚨
「GPT-5.2で生成した返信」をそのまま投稿すると、時々 「不適切なトーン」 になります。例えば、苦情レビューに対して「ご満足いただけて何よりです」みたいな。
「人間の承認」 を挟むワークフローが重要です。
「自動化」＝「人間を排除」ではなく「人間の作業を最適化」
4. 多言語対応MEOの特殊性（JapanLifeStartの知見）
4.1 「翻訳」と「ローカライズ」の違い
JapanLifeStartでは10言語の対応経験があります。
MEOの多言語化で、最も重要なのは「翻訳」ではなく「ローカライズ」 です。
| 単純翻訳 | ローカライズ（MEO向け） |
|---|---|
| "Restaurant" → 「レストラン」 | 日本なら「レストラン」、アメリカなら「Restaurant」、イギリスなら「Eatery」 |
| 営業時間「9:00-18:00」 | 国によって営業時間の文化が違う（日本の「18時閉店」は、スペインでは「異常に早い」） |
| 電話番号 | 国際電話番号（+81） vs 国内向け（03-XXXX） |
Google Business Profileの多言語設定：
// APIでの多言語対応例
{
"storeCode": "tokyo-001",
"primaryPhone": "+81-3-1234-5678",
"primaryCategory": {
"displayName": "Japanese Restaurant",
"languageCode": "en"
},
"regularHours": {
"periods": [
{
"openDay": "MONDAY",
"openTime": "11:00",
"closeDay": "MONDAY",
"closeTime": "22:00"
}
]
},
"labels": ["和食", "寿司", "sushi"], // 多言語タグ
"languageCode": "ja"
}
ポイント：
-
languageCode：各言語版のプロフィールを別々に管理 - カテゴリ：日本語版と英語版で、Googleの定義するカテゴリが異なる場合あり
- 営業時間：時差対応。APIはUTCで管理されるので、JST（UTC+9）への変換が必要
4.2 地域別のMEO戦略
「建築の現場」 で、土地の地盤によって基礎の設計を変えるように、国/地域によってMEO戦略を変える必要があります。
- 日本：「駅からの徒歩分数」が重要。Googleマップの「経路」機能との連携
- アメリカ：「Parking availability」（駐車場の有無）がカテゴリ属性として重要
- ヨーロッパ：「Wheelchair accessible」（車椅子対応）が法的要件に近い重要性
構造化データでも対応：
{
"@type": "LocalBusiness",
"additionalProperty": [
{
"@type": "PropertyValue",
"name": " nearestStation",
"value": "渋谷駅から徒歩5分"
}
]
}
5. エンジニア向けMEOツール・リソース
5.1 無料で使える分析ツール
| ツール名 | 用途 | エンジニア向けポイント |
|---|---|---|
| Google Business Profile Manager | 基本情報管理 | APIの管理画面版。API連携前にここで構造を理解 |
| Google Search Console | 検索パフォーマンス | 構造化データのエラーを検出 |
| Google Analytics 4 | 来店コンバージョン | GTM（Google Tag Manager）と連携して「来店」イベントを計測 |
| Local Falcon | ランキング監視 | 地図上で、どの位置から検索した時に何位か可視化 |
| BrightLocal | ローカルSEO監視 | API連携可能（有料プラン） |
5.2 開発者向けリソース
GitHubサンプルリポジトリ（自作）：
# Google Business Profile API連携のサンプル
git clone https://github.com/yushi-yamamoto/gbp-api-starter
主要なGoogle APIドキュメント：
- Business Profile API v1
- Places API（店舗検索・詳細取得）
- Geocoding API（住所→緯度経度変換）
npmパッケージ：
# Google APIクライアント
npm install googleapis
# 型定義（TypeScript必須）
npm install --save-dev @types/google.maps
6. まとめ：MEOは「継続的インテグレーション」である
6.1 「建物」としてのMEO
建築の現場では、「竣工」 を迎えても仕事は終わりません。「維持管理」 が始まります。
MEOも同じ。一度Google Business Profileを設定したら、そこからが本番です。
| 建築のフェーズ | MEOのフェーズ |
|---|---|
| 設計 | 構造化データ設計（Schema.org） |
| 施工 | Google Business Profile設定 |
| 竣工 | 公開・インデックス登録 |
| 維持管理 | レビュー対応、投稿更新、情報修正 |
| 改修・リニューアル | カテゴリ変更、リブランディング |
「技術的負債」 を溜めないために：
- 定期的な監査（月1回の情報整合性チェック）
- 自動化されたワークフロー（n8n/GitHub Actions）
- バージョン管理（店舗情報の変更履歴を管理）
6.2 エンジニアの強みを活かす
マーケターが「MEO対策済み」と言っても、「構造化データ入れてません」 というケースが多い。
エンジニアは、「正確な実装」 ができます：
- JSON-LDの構文エラーをゼロにできる
- API連携で手作業を排除できる
- 監視システムで異常を検知できる
これが、エンジニアのMEOにおける圧倒的優位性です。
6.3 始めるべき3つのアクション
今週中にやること：
-
Schema.org/LocalBusinessを実装する
- 自分の会社・個人サイトのHTMLにJSON-LDを追加
- リッチリザルトテストで検証
-
Google Business Profile APIを有効化する
- Google Cloud Consoleでプロジェクト作成
- OAuth 2.0認証まで行う（これが一番面倒）
-
レビュー監視の自動化を試す
- n8nで「新規レビュー→Slack通知」のワークフローを作成
- 無料枠で動作確認
最後に
「MEOはマーケターの仕事」という偏見、捨てましょう。
技術的実装ができて、データ分析ができて、自動化ができるのは、エンジニアです。
Googleマップという「デジタルな街」で、あなたの建物（ビジネス）が正しく表示されるように、「構造」 を設計してください。
建築で言う「耐震性」のある建物は、地震が来ても倒れません。MEOも、「アルゴリズムアップデート」 という地震に備えた構造を、エンジニアリングで作りましょう。
「MEOをコードで制御する」 その快感、きっと気に入りますよ。
参考リンク
書いた人：
株式会社プロドウガ代表取締役（@YushiYamamoto）
建築→エンジニア→フルスタック開発者。多言語対応サイトJapanLifeStart運営。技術で「ローカル」という身近な問題を解決したい。
2026年2月13日公開