Googleマップスクレイパー GitHub：2026年に使えるもの、壊れるもの

GitHub には「google maps scraper」に一致するリポジトリがざっとあります。ですが、その大半は壊れています。

大げさに聞こえるかもしれません。でも、リポジトリをクローンし、Playwright の依存関係でつまずき、深夜2時にスクレイパーが空の CSV を返すのを見たことがあるなら、その感覚はもうお分かりでしょう。Google マップは、世界でを抱える、地球上でも屈指のローカルビジネスデータベースです。だからこそ、営業担当から代理店経営者まで、誰もがそのデータを取り出したくなります。問題は、Google が数週間〜数か月単位で Maps の UI を変えることです。そのたびに、ちょうど1時間かけてセットアップしたスクレイパーが、何も言わずに壊れることがあります。ある GitHub ユーザーは 2026年3月の issue で、このツールが と書いていました。これは珍しい例外ではありません。最重要の処理が失敗しているのです。今年はこれらのリポジトリをかなり注意深く追ってきましたが、「GitHub 上では活発に見える」ことと「実際に今日データを返せる」ことの差は、多くの人が想像するよりずっと大きいです。このガイドでは、どのリポジトリが使えるのか、どれが壊れるのか、GitHub を丸ごと飛ばすべきタイミングはいつか、そしてデータを取得した後に何をすべきかまで、ノイズを取り除いて率直に整理します。

GitHub の Google マップスクレイパーとは何か（そして、なぜ使われるのか）

GitHub の Google マップスクレイパーは、通常は Python か Go のスクリプトで、Docker で包まれていることもあります。ヘッドレスブラウザで Google マップを開き、「Chicago の歯科医」などの検索を実行し、表示された事業者情報を抽出します。名前、住所、電話番号、Web サイト、評価、レビュー数、カテゴリ、営業時間、場合によっては緯度・経度も取得できます。

こうしたツールの置き場として GitHub が定番なのは、コードが無料でオープンソース、しかも理論上はカスタマイズ可能だからです。リポジトリをフォークし、検索条件を調整し、独自のプロキシ処理を追加し、必要な形式でエクスポートできます。

一般的に、ユーザーが取得したいデータ項目は次のようなものです。

これを使うのは誰でしょうか。営業チーム、アウトバウンドのリードリストを作る人たち。不動産の担当者、地域市場をマッピングする人たち。競合分析を行う EC チーム。ローカル SEO の監査をするマーケターたち。共通点はただ一つ、構造化されたローカルビジネスデータが必要で、しかもブラウザから1件ずつコピペするのは避けたいということです。

営業・オペレーションチームが Google マップスクレイパーの GitHub リポジトリを探す理由

Google マップが魅力的なのはシンプルな理由です。ローカルビジネス情報が実際にそこにあるからです。ニッチなディレクトリではありません。課金の裏でもありません。検索結果の中にそのままあります。

ビジネス上の価値は、大きく3つに分かれます。

リード獲得とプロスペクティング

これが最大の用途です。フリーランサーや代理店向けに Google マップスクレイパーを作っている創業者は、。特定の都市やニッチで見込み客を見つけ、コールドアウトリーチ用の連絡先を集め、名前、住所、電話番号、Webサイト、評価、レビュー数、カテゴリ、営業時間、メール、SNS アカウントを含む CSV を作る、という流れです。最も活発なリポジトリの1つである gosom/google-maps-scraper は、エージェントに と頼めると明記しています。これは趣味の用途ではありません。営業のパイプラインです。

市場調査と競合分析

オペレーションや戦略チームは、スクレイピングした Maps データを使って地域ごとの競合数を数え、レビューの感情を分析し、空白地帯を見つけます。あるローカル SEO の実務者は、Google マップの公開データを抽出することで、 と報告しています。この規模の分析を手作業で行うのは、ほぼ不可能です。

ローカル SEO 監査とディレクトリ構築

マーケターは、ローカル検索での露出を監査し、NAP（名前・住所・電話番号）の一貫性を確認し、ディレクトリサイトを作るために Google マップをスクレイピングします。あるユーザーは、スクレイピングした Google マップデータのスプレッドシートを、 と述べています。

スクレイピングが魅力的に見える労働コストの計算

ブラウザを使うだけだからといって、手作業の収集が無料になるわけではありません。Upwork では、事務系のデータ入力 VA の相場はです。人が1件あたり1分かけて基本情報を集めると、1,000件で約16.7時間、QA 前の労働コストだけで約200〜334ドルになります。1件2分なら、同じリストで400〜668ドルです。これが、あらゆる「無料の GitHub スクレイパー」が競合している実コストです。

Google Maps API と GitHub スクレイパー リポジトリとノーコードツール：2026年の判断フロー

何かをクローンする前に、まず進む道を決めましょう。件数、予算、技術スキル、メンテナンスへの許容度がここでは重要です。

Google Places API が向いているケース

公式ライセンスと予測しやすい課金が必要で、件数が小〜中規模なら、API が素直な選択です。Google のでは、従来の月次クレジット制が SKU ごとの無料上限に置き換わりました。多くの Essentials SKU は、Pro は 5,000回、Enterprise は 1,000回です。その後は、Text Search Pro が1,000回あたり、Place Details Enterprise + Atmosphere は1,000回あたり5ドルです。

最大の制限はレビューです。API では1件あたり しか返りません。レビューを丸ごと取りたいなら、API だけでは足りません。

GitHub スクレイパーが向いているケース

キーワードと地理条件での一括発掘、API フィールド以上のブラウザ表示データ、レビュー全文、独自のパース処理——こうしたものが必要で、しかもスクレイパーを維持する Python/Docker スキルがあるなら、GitHub リポジトリが向いています。代償は、「無料」が時間、プロキシ、リトライ、壊れやすさへと形を変えることです。プロキシ費用だけでもかなり膨らみます。、、です。

Thunderbit のようなノーコードツールが向いているケース

非技術系のチームで、とにかくデータを Sheets、Airtable、Notion、CSV にすぐ入れたいなら、ノーコードツールを使えば Python / Docker / プロキシ設定を丸ごと飛ばせます。 なら、Chrome 拡張機能を入れて Google マップを開き、「AI で項目を提案」をクリックし、続けて「スクレイプ」を押すだけです。 できます。クラウドスクレイピングモードが自動でボット対策を処理し、 できます。プロキシ設定は不要です。

シンプルな判断フロー： 500件未満で予算がある → API。数千件必要で Python が使える → GitHub リポジトリ。技術セットアップなしで素早くデータが欲しい → ノーコードツール。

2026年版の鮮度チェック：今、実際に使える Google マップスクレイパー GitHub リポジトリはどれか？

これこそ、リサーチを始めた頃に欲しかった章です。多くの「おすすめ Google マップスクレイパー」記事は、リポジトリ名と星の数を1行で並べているだけです。そのツールが今月も本当にデータを返すのかは、どれも教えてくれません。

Google マップスクレイパーの GitHub リポジトリがまだ生きているかを見分ける方法

何かをクローンする前に、次のチェックリストを実行してください。

• 最近のコード更新: 本物のコミットが過去3〜6か月以内にあるかを見る（issue のコメントだけではなく）。
• issue の健全性: 直近で更新された issue を3件読みます。中身は、空欄、セレクタエラー、ブラウザクラッシュなどの中核的障害か、それとも機能要望か。
• README の質: 現在のブラウザ構成、Docker セットアップ、プロキシ設定が書かれているか。
• issue 内の警告ワード: 「search box」「reviews_count = 0」「driver」「Target page」「selector」「empty」を検索します。
• フォークと PR の動き: 活発なフォークやマージ済み PR は、生きているコミュニティのサインです。

最近のコード更新がなく、中核のスクレイピングバグが未解決で、プロキシやブラウザ保守の案内もない？ そのリポジトリは、たとえ星の数が多くても、ビジネス用途には十分に生きていない可能性が高いです。

評価した主要な Google マップスクレイパー GitHub リポジトリ

上記の方法に基づいて、星の多いリポジトリを評価しました。まずは要約表、その後に個別メモです。

gosom/google-maps-scraper

現時点で、オープンソースの一般用途向けとしては最も強い選択肢です。README もかなり成熟しており、CLI、Web UI、REST API、Docker 手順、プロキシ設定、グリッド / バウンディングボックスモード、メール抽出、複数の出力先を備えています。 を取得できるとし、大規模スクレイピングでは「レート制限を避けるためにプロキシが役立つ」と明記しています。

弱点は放置ではなく、端の項目で正確性が崩れることです。2026年の最近の issue では、、、 といった報告があります。つまり、事業者情報の抽出にはかなり信頼できますが、レビューや営業時間のリッチデータは、修正が入るまでやや不安定です。

omkarcloud/google-maps-scraper

星の数と長い運用歴で目立ちますが、透明な OSS というより、パッケージ化された抽出製品のように読めます。サポート窓口、デスクトップインストーラ、拡張販売などがあるからです。2026年4月のあるユーザーは、アプリを起動した後、ターミナルが で埋まり、そのまま停止したと書いていました。別の未解決 issue では、このツールが と不満が出ています。壊れてはいませんが、読者が自分で安心して直せる、検証しやすい OSS を求めるなら、最もきれいな答えとは言えません。

gaspa93/googlemaps-scraper

一般的な大量検索・リード獲得スクレイパーではありません。これは特定の Google マップ POI レビュー URL から始めて最近のレビューを取得する、特化型の です。メタデータ取得やレビューの並び替えにも対応します。この狭い用途は、特定のワークフローではむしろ強みですが、多くのビジネスユーザーが想定する「検索で見込み客を見つける」問題は解決しません。

conor-is-my-name/google-maps-scraper

現代のオペレーションチームに合った設計です。Docker 優先のインストール、JSON API、ビジネス向け項目、 でのコミュニティ可視性があります。ただし 2026年3月の issue は、このカテゴリがいかに壊れやすいかを象徴しています。コンテナを更新したら、出力がスクレイパーは と返したのです。これは最重要フローの失敗であり、見た目だけの細かな問題ではありません。

Zubdata/Google-Maps-Scraper

仕様上は項目が幅広く、メール、レビュー、評価、住所、Web サイト、電話番号、カテゴリ、営業時間に対応しています。ところが、公開 issue の様子はまったく別です。アプリバンドル内の、、 が報告されています。古い更新履歴も合わせると、2026年に勧めるのは難しいです。

patxijuaristi/google_maps_scraper

GitHub 検索では見つけやすいですが、もっとも強い公開シグナルは、活発な保守ではなく です。このリポジトリは、「検索結果では生きて見えるが、実運用では危険」という例として、この記事に載せています。

手順で理解する：GitHub から Google マップスクレイパーをセットアップする方法

GitHub リポジトリを使う方が正解だと判断しましたか？ では、実際のセットアップはこうなります。ここでは特定リポジトリに絞らず、一般論として説明します。アクティブな選択肢の間で手順は驚くほど似ています。

STEP 1: リポジトリをクローンし、依存関係をインストールする

よくある流れは次の通りです。

1. リポジトリを git clone する
2. Python の仮想環境を作る（または Docker イメージを取得する）
3. pip install -r requirements.txt か docker-compose up で依存関係を入れる
4. 場合によってはブラウザ実行環境も入れる（Playwright なら Chromium、Selenium なら ChromeDriver）

や のような Docker 優先のリポジトリは、依存関係の悩みを減らしてくれますが、完全には消えません。Docker を動かし、ブラウザイメージ用の十分なディスク容量も必要です。

STEP 2: 検索パラメータを設定する

多くの汎用スクレイパーが求めるのは次のようなものです。

• キーワード + 場所（例：「Austin TX の配管工」）
• 取得件数の上限（何件抽出するか）
• 出力形式（CSV、JSON、DB）
• 場合によっては、グリッド探索用の地理的バウンディングボックスや半径

強いリポジトリでは、これらが CLI フラグや JSON リクエスト本文として公開されています。古いリポジトリでは、Python ファイルを直接編集する必要があるかもしれません。

STEP 3: 必要ならプロキシを設定する

小さなお試しを超えるなら、プロキシはほぼ必要です。 しており、大きなジョブではプロキシが標準解だと明示しています。ない場合、数十回のリクエストで CAPTCHA や IP ブロックが出る可能性があります。

STEP 4: スクレイパーを実行し、データをエクスポートする

スクリプトを実行し、ブラウザが結果カードをたどるのを見ながら、CSV か JSON の出力を待ちます。うまくいく場合は数分で終わります。うまくいかない場合——そして実際はこちらのほうが多いのですが——起こるのは次のようなことです。

• ブラウザが突然閉じる
• Chrome ドライバのバージョン不一致
• セレクタ / 検索ボックスの失敗
• レビュー数や営業時間が空で返る

この4パターンは、 にすべて出ています。

STEP 5: エラーと破損に対処する

スクレイパーが空結果やエラーを返したら、

1. 同様の報告が GitHub Issues にないか確認する
2. Google マップの UI 変更を探す（新しいセレクタ、ページ構造の違いなど）
3. リポジトリを最新コミットまで更新する
4. メンテナが直していないなら、フォークにコミュニティ修正がないか確認する
5. デバッグにかける時間が、ツールを切り替える価値に見合うか考える

現実的な初回セットアップ時間: ターミナルには慣れているが、Playwright / Docker / プロキシの作業環境がまだ整っていない人なら、最初の成功スクレイプまで 30〜90分 が現実的です。5分ではありません。

Google マップをスクレイピングするときに BAN とレート制限を避ける方法

「X 回リクエストしたらブロックされる」という公開の Google マップしきい値はありません。Google は意図的に曖昧にしています。サーバー上の Playwright 環境では、およそ の後に CAPTCHA が出たという報告もあります。一方で、企業が作った Maps スクレイパーで を回せたという人もいました。しきい値は高いとか低いとかではなく、不安定で、状況依存です。

実践的な戦略表は次の通りです。

リクエスト間にランダムな遅延を入れる

1秒固定の間隔は危険信号です。動作間に 2〜5秒のランダムな揺らぎを入れ、時々もっと長く止めましょう。最も簡単にできる対策で、コストもかかりません。

プロキシをローテーションする（住宅用 vs データセンター）

住宅用プロキシは実ユーザーに見えやすいため効果が高いですが、その分高価です。現在の価格は、、、 です。データセンタープロキシは軽いスクレイピングなら機能しますが、Google 系ではより早くフラグが立ちます。

ブラウザのフィンガープリントをランダム化する

ヘッドレスブラウザのスクレイパーでは、ユーザーエージェント、ビューポートサイズ、その他のフィンガープリント信号をローテーションします。デフォルトの Playwright / Puppeteer 設定は、非常に簡単に検知されます。実装は難しめですが、無料で、しかもかなり効果的です。

クラウドベースのスクレイピングで問題を肩代わりさせる

のようなツールは、クラウドスクレイピング基盤を通じてボット対策、IP ローテーション、レート制限を自動で処理します。Thunderbit はクラウドモードで でき、プロキシ設定も遅延設定も不要です。ボット対策の半分を自分でやりたくないチームにとって、これが最も現実的な道です。

Google のレート制限は実際どんなふうに見えるか

レート制限を受けているサインは次の通りです。

• スクレイプ中に CAPTCHA が出る
• 以前は成功していたクエリの後で、結果が空になる
• 一時的な IP ブロック（通常1〜24時間）
• ページ読み込みの劣化（遅くなる、内容が一部しか出ない）

復旧方法は、スクレイピングを止め、IP を切り替え、15〜60分待ってから、同時実行数を下げて再開することです。頻繁に制限に当たるなら、プロキシか、根本的に違うアプローチが必要です。

ノーコードの逃げ道：GitHub の Google マップスクレイパーに時間を割く価値がないとき

Google マップスクレイピングの記事の約90%は、Python に慣れていることを前提にしています。でも、読者の大部分——代理店経営者、営業担当、ローカル SEO チーム、研究者——が本当に必要なのは、スプレッドシートの行です。ブラウザ自動化プロジェクトではありません。もしそれがあなたなら、この章はトレードオフを率直に説明します。

「無料」の GitHub スクレイパーにかかる本当のコスト

「無料」の GitHub スクレイパーは、請求を時間に付け替えているだけです。自分の時間を時給50ドルと見積もり、セットアップに2時間、トラブルシュートに1時間、プロキシ設定に30分かけたなら、1件も取得する前に175ドルです。さらにプロキシ費用と、Google が UI を変えたときの継続保守が乗ってくると、「無料」の選択肢は急に高く見えてきます。

Thunderbit で Google マップスクレイピングがどう簡単になるか

での実際の流れはこうです。

1. をインストールする
2. Google マップに移動して、検索を実行する
3. 「AI で項目を提案」 をクリックする — Thunderbit の AI がページを読み取り、列（事業者名、住所、電話番号、評価、Web サイトなど）を提案します
4. 「スクレイプ」 をクリックすると、データが自動で構造化されます
5. サブページスクレイピング を使って、スクレイプした URL から各事業者の Web サイトを訪問し、メールや電話番号などの追加連絡先情報を抽出します。GitHub リポジトリ利用者が手作業でやっていることを自動化できます
6. する — 出力に課金の壁はありません

Python も、Docker も、プロキシも、保守も不要です。リード獲得を行う営業・マーケティング向けには、GitHub リポジトリで必要になるセットアップ負担をまるごと消せます。

料金の補足: Thunderbit は のクレジットモデルです。無料枠は月6ページ、無料トライアルは10ページ、スタータープランは です。

スクレイピング後：Google マップデータのクレンジングと拡張

多くのガイドは、抽出したところで終わります。でも、生データはリードリストではありません。フォーラムでは、 という報告や、「この構成で重複はどう処理するの？」という質問がよく出ます。ここからが、スクレイプ後の作業です。

結果の重複を除去する

重複は、ページネーションの重なり、重なる範囲での繰り返し検索、同じ事業者を含むグリッド / バウンディングボックス戦略、複数掲載の店舗などから入り込みます。

重複排除のおすすめ順序:

1. スクレイパーが出力するなら place_id で照合する（最も信頼性が高い）
2. 正規化した事業者名 + 住所 の完全一致
3. 名前 + 住所のあいまい一致を行い、電話番号か Web サイトで確認する

簡単な Excel / Sheets の式（COUNTIF、重複の削除）で大半は処理できます。大きなデータセットなら、pandas を使った軽い Python の重複排除スクリプトが有効です。

電話番号と住所を正規化する

スクレイプされた電話番号は、(555) 123-4567、555-123-4567、+15551234567、5551234567 など、ありとあらゆる形式で出てきます。CRM に取り込むなら、E.164 形式、つまり + 国番号 + 国内番号、たとえば +15551234567 に揃えましょう。

します。クレンジング工程が1つ減ります。

住所は、通り名、都市、州、郵便番号という一貫した形式に標準化します。余分な空白を取り、略称の揺れ（St と Street など）を修正し、精度が重要ならジオコーディングサービスで検証します。

メール、Web サイト、SNS プロフィールで拡張する

Google マップの掲載情報には、Web サイト URL はほぼ必ず入っています。メールアドレスが直接入っていることはほぼありません。勝ちパターンは次の通りです。

1. ビジネス発掘のために Maps をスクレイプする（名前、住所、電話番号、Web サイト URL）
2. 各事業者の Web サイトを訪問し、メールアドレス、SNS リンク、その他の連絡先情報を抽出する

ここで、最良の GitHub リポジトリとノーコードツールが交わります。

• します
• は、スクレイプした URL から各事業者の Web サイトを訪問し、メールアドレスや電話番号を抽出して、元の表に追記できます

組み込みの拡張機能がない GitHub リポジトリ利用者にとっては、2本目のスクレイパーを作るか、各サイトを手で訪問する必要があります。Thunderbit なら、この2工程を1つのワークフローにまとめられます。

CRM や業務ツールへエクスポートする

最も実用的な出力先は次の通りです。

• Google Sheets：共同でのクレンジングと共有
• Airtable：フィルタやビューを備えた構造化データベース
• Notion：軽量なオペレーション用 DB
• CSV / JSON：CRM 取り込みや下流自動化

Thunderbit は できます。多くの GitHub リポジトリは CSV か JSON のみの出力なので、CRM 連携は別途対応が必要です。スクレイプしたデータをスプレッドシートに入れる別の方法を知りたいなら、 のガイドもご覧ください。

Google Maps Scraper GitHub リポジトリ：完全比較

すべての選択肢を並べた、保存用のまとめ表はこちらです。

スクレイピング手法の選び方をもっと知りたいなら、 のまとめや、 も役立ちます。

法務と利用規約の注意点

短くても、重要な章です。

Google の現在の Maps Platform 利用規約は明確です。顧客は、 とされており、許可された利用の外で事業者名、住所、ユーザーレビューをコピー・保存することも含まれます。Google のサービス別規約では、特定の API に対してのみ限定的なキャッシュが認められ、通常は です。

法的な優先順位は明確です。

• API 利用 が最も契約上の足場がしっかりしています
• GitHub スクレイパー はかなりグレーな領域です
• ノーコードツール は運用負荷を下げますが、あなた自身のコンプライアンス責任を消すわけではありません

個別のユースケースについては、必ず自分の法務担当に相談してください。法的な状況をさらに詳しく知りたい場合は、別記事で を扱っています。

重要ポイント：2026年に最適な Google マップスクレイパーの選び方

リポジトリ、issue、フォーラム、料金ページを掘り下げた結果、現状はこうです。

1. セットアップに時間をかける前に、必ずリポジトリの鮮度を確認してください。 星の数は「今動く」ことの指標ではありません。直近3件の issue を読み、過去3〜6か月以内のコードコミットを確認しましょう。

2. 現時点で最も優れたオープンソース候補は gosom/google-maps-scraper です — ただしそれでも、2026年の最新フィールド回帰が見られます。放置して使うツールではなく、監視が必要な生きたシステムとして扱ってください。

3. 安定性と法的明確さを求めるなら Google Places API が正解です — ただし制限があります（レビュー最大5件、従量課金）。大量発見にはあまり向きません。

4. 非技術系チームには、 のようなノーコードツールが実用的な代替です。 設定から最初のデータ取得までが数時間ではなく数分で済み、しかも半分プロのスクレイパー保守係になる必要がありません。

5. 生データは仕事の半分にすぎません。 重複排除、電話番号の正規化、メール拡張、CRM へのエクスポートの時間も見込んでください。これらを自動で処理するツール（Thunderbit のサブページスクレイピングや E.164 正規化など）は、多くの人が思っている以上に時間を節約します。

6. 「無料のスクレイパー」は、未払いの保守が付いたソフトウェアだと理解するのが正しいです。 スキルがあって、その作業自体を楽しめるなら問題ありません。でも、金曜までにフェニックスの歯科医リードを500件欲しいだけの営業担当なら、良い取引ではありません。

ビジネスデータ抽出の他の方法も見たいなら、、、 のガイドもご覧ください。 でチュートリアル動画も視聴できます。

FAQ

GitHub の Google マップスクレイパーは無料で使えますか？

ソフトウェア自体は無料です。でも、作業は無料ではありません。セットアップに30〜90分、壊れたときの継続的なトラブルシュート、そして本格的な件数なら月10〜100ドル超のプロキシ費用がかかることもあります。自分の時間に価値があるなら、「無料」は正確な表現ではありません。

GitHub の Google マップスクレイパーを使うのに Python のスキルは必要ですか？

人気リポジトリの多くは、基本的な Python とコマンドラインの知識を必要とします。Docker 優先のリポジトリは負担を軽くしますが、ゼロにはなりません。コンテナの問題をデバッグし、検索パラメータを設定し、プロキシも扱う必要があります。非技術ユーザーには、 のようなノーコードツールが、コーディング不要の 2クリック代替になります。

Google マップスクレイパーの GitHub リポジトリは、どのくらいの頻度で壊れますか？

固定の周期はありませんが、現在の GitHub issue 履歴を見ると、中核の破綻や項目の回帰は 数週間〜数か月 のサイクルで起きています。Google は Maps の UI を定期的に更新するため、セレクタや解析ロジックが一夜で壊れることがあります。活発なリポジトリはすぐ直しますが、放置されたリポジトリはずっと壊れたままです。

GitHub スクレイパーで Google マップのレビューを取得できますか？

一部のリポジトリはレビュー全文の抽出に対応しています（gaspa93/googlemaps-scraper はそのための設計です）。一方で、評価やレビュー数のような要約データだけを取るものもあります。レビューは、Google がページ挙動を変えたときに最初に崩れやすい項目の1つでもあります。そのため、レビュー対応のリポジトリでも、UI 更新後に不完全な結果が返ることがあります。

GitHub スクレイパーを使いたくない場合、最良の代替は何ですか？

主な選択肢は2つです。1つは、コストと項目制限はあるものの、公式で構造化されたアクセスができる Google Places API。もう1つは、コーディング不要で高速に AI 抽出できる のようなノーコードツール です。API は、コンプライアンスを重視する開発者に最適です。Thunderbit は、すぐにスプレッドシートへデータを入れたいビジネスユーザーに最適です。

さらに詳しく