結論から言うと

「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日公開