ビジネス/キャリア

キーエンス出身の営業パーソン・あさひ氏が共有していた「A&Q（Answer & Question）」という商談テクニックが非常に実践的だったので紹介する。 「お客様のFAQになるな」 キーエンス時代に上司から言われていた言葉だという。 特に展示会後のフォローやインバウンド商談で起きがちなのが、商談が始まった途端に顧客から質問の嵐が飛んでくるパターンだ。 「防水性能は？」 「初期費用いくら？」 「納期は？」 「API連携できる？」 今の時代は顧客も事前にWebサイトや生成AIで情報収集しているから、聞きたいことが山ほどある状態で商談に臨んでくる。 致命的なミス：「音声版FAQ」になること 多くの営業パーソンがやってしまうのが、「聞かれたことにただ正確に答えるだけ」のマシーンになってしまうこと。 「防水性能は？」→「はい、IP67です」 「初期費用は？」→「30万円です」 「納期は？」→「2週間です」 「API連携は？」→「可能です」 正確に情報を伝えてはいるが、これでは営業パーソンではなくただの「音声版FAQ」でしかない。商談の主導権を完全に顧客に握られてしまう。 顧客がすべての質問を終えて「わかりました、検討します」と言った瞬間、商談は終了。こちらは顧客の情報を何一つ引き出せないまま、ただ情報を吸い取られただけで終わる。 営業のミッション 営業のミッションは「質問に答えること」ではない。顧客の課題を解決し、幸せになってもらうことだ。 そのためには顧客の質問の意図を掴んで、こちらから提案のボールを投げ返さなければならない。 質問の「背景」を読む 顧客の質問には必ず「背景」がある。 「防水性能は？」と聞く人は、水に濡れる環境で使う予定がある 「納期は？」と聞く人は、いつまでに稼働させたいという期限を抱えている 「安くなる？」と聞く人は、予算の上限が決まっている 質問そのものが「情報の宝庫」への入り口になっている。FAQボットになっている営業パーソンは、この宝の山をみすみす見逃している。 A&Q：Answer & Question 重要なのは、ボールを受けたあとにしっかり打ち返すこと。あさひ氏はこれを「キャッチ＆リターン」と呼んでいた。 A&Q = Answer（回答）のあとに必ず Question（質問）をセットにする。 具体例：防水性能を聞かれたとき ダメな対応: 「はい、IP67に対応しています」（終了） キーエンス流の対応: 「はい、ご安心ください。最高等級のIP67に対応しております。……ちなみに、今回は防水防塵が必要になるような水や粉塵が舞う過酷な環境下でのご利用をご検討されているのですか？」 すると顧客が「実は工場の屋外ヤードに置きたくて」と答えてくれる。そこで「屋外であれば防水だけでなく直射日光による熱対策も必要ですね。遮光カバーもセットでご提案できます」と、単価アップやトラブル防止の提案に繋がる。 スペックを答えるだけでなく、「なぜそのスペックが必要なのか」という利用シーンを引き出しているのがポイント。 具体例：価格を聞かれたとき ダメな対応: 「はい、その通りです」（価格確認マシーン） キーエンス流の対応: 「はい、そのプランでご案内可能です。ちなみに、複数あるプランの中であえてこちらに目をつけていただけた背景をお伺いしてもよろしいですか？」 すると顧客の「選定基準」が見えてくる。「この機能が必須だから」と言われればその機能を軸にクロージングできるし、「一番安いから」と言われれば機能不足のリスクを説明する必要があるとわかる。 A&Qのリズムを身体に染み込ませる 一方的にこちらから聞くと「尋問」になる。でも相手の質問への打ち返しとして聞けば、極めて自然な「会話」になる。 なぜ興味を持ってくれているのか 他社も検討中なのか いつ導入したいのか 予算は確保済みなのか これらを全部、相手の質問を起点にした会話の中で引き出していく。 まとめ 質問に答えるのは義務。でも答えっぱなしにするのは「罪」。相手の質問を利用して相手の懐に深く潜り込む。それが単なる情報提供係から「パートナー」に昇格するための技術だ。 お客様は生成AIやGoogle検索でわかることを聞くためにあなたを呼んだわけではない。検索では出てこない「自社の課題への最適解」を求めている。 「FAQにはなるな」 ── この教えは、営業に携わるすべての人に通じる本質だと思う。 参考 あさひ著『凡人が天才に勝つ最強の営業 営業に「センス」はいらない』（2026年3月29日発売）

株式会社SWIFT代表の井口亮平氏（@Ryohei_Iguchi）がX（旧Twitter）で公開した記事が、月商100〜300万円を目指すフリーランスや小規模事業者にとって示唆に富む内容だったので紹介する。 2つのパターン 月商100〜300万円を作る方法は、突き詰めると 2パターン しかないという。 パターン1: 100万を1本取る 高単価案件を1本受注する戦略 例: コンサルティング、システム開発、ハイエンドなクリエイティブ制作 メリット: クライアント管理がシンプル、1案件に集中できる デメリット: 案件が途切れたときのリスクが大きい、営業コストが高い パターン2: 20万を5本積む 中単価の案件を複数積み上げる戦略 例: 月額制のSNS運用代行、サブスク型サービス、定期的な制作案件 メリット: 収益が安定しやすい、1案件がなくなっても致命傷にならない デメリット: マルチタスクの管理能力が必要、スケーリングに限界がある どちらを選ぶべきか どちらが正解というわけではなく、自分のスキルセットや事業の性質に合ったパターンを選ぶことが重要だ。 専門性が高い人 → パターン1（高単価×少数）が向いている オペレーションが得意な人 → パターン2（中単価×複数）で安定収益を作りやすい 実際には、パターン2で安定した基盤を作りつつ、パターン1の高単価案件を狙うハイブリッド型が現実的なアプローチになることも多い。 エンジニア・フリーランスへの示唆 エンジニアやIT系フリーランスの場合: パターン1: 技術顧問、アーキテクト案件、受託開発 パターン2: 保守運用契約、技術メンター、複数社への業務委託 月商300万円を超えるには、いずれのパターンでも「自分が動く」だけでは限界が来る。仕組み化やチーム化を見据えた設計が、次のステージへの鍵になる。 参考 元ツイート（X記事） 株式会社SWIFT — X運用のプロフェッショナル集団

AI スタートアップが必死に探している人材がいる。営業でもマーケでもエンジニアでもない、しかしその全部を1人でやる「GTMエンジニア」だ。Y Combinator 出身の創業者たちがこぞって求めるこの職種は、AI 時代のキャリアの新しい形を示している。 GTMエンジニアとは GTM は “Go-To-Market” の略で、プロダクトを市場に届けるための戦略とオペレーション全体を指す。どのターゲットに、どのチャネルで、どうやって届け、売上につなげるか。マーケティング、営業、カスタマーサクセスにまたがるこの一連のプロセスが「GTM」だ。 従来はこの領域を、SDR（インサイドセールス）、RevOps（レベニューオペレーション）、グロースチームといった複数部門が分担していた。それが今、AI の進化によって 1人で完結できる ようになりつつある。 この「1人で全部やれる人間」が GTMエンジニアだ。テック業界で最も高給な職種の一つになりつつあり、平均年収は3,000万円〜5,000万円程度とされる。 GTMエンジニアが1人でやること その仕事の範囲は驚くほど広い： ICP（理想的な顧客像）とTAM（獲得可能な市場全体）の設計 メール配信インフラの構築 「買いそうなシグナル」の検知 — 企業の採用情報や資金調達などからリストを構築 アカウント情報のエンリッチメント アウトバウンド営業の自動化と有望リードの自動振り分け インバウンドのリード評価・スコアリング・商談準備の一気通貫設計 営業コールのAI分析とフィードバックループ構築 CRMのアーキテクチャ設計とレポーティング 以前は3つ以上のチームが10人以上で回していた仕事だ。それを AI を武器にして1人でやる。 なぜ今、この役割が生まれたのか 背景は2つある。 1. AIツールの進化 Clay、Apollo、Gong、Salesforce といったツールが個別に進化してきたところに、ChatGPT や Claude のような LLM が登場し、ツール間の「接着剤」となる作業を自動化できるようになった。API を繋ぎ、プロンプトでロジックを組み、ワークフローを自動化する。技術的に考えられる人間が1人いれば、チーム全体のオペレーションを設計・実行できてしまう。 2. スタートアップの経済的現実 シード期のスタートアップに SDR チーム、RevOps マネージャー、グロースマーケターをそれぞれ雇う余裕はない。でも GTM はやらなければ売れない。「1人で全部やれる人間」への需要が爆発した理由はここにある。 GTMエンジニアに求められる3つの能力 1. 営業サイクル全体の理解 見込み客の発掘からナーチャリング、商談、クロージングまで。一連の流れを理解していないと、自動化の設計ができない。何を自動化すべきで、何は人間がやるべきか。この判断は営業プロセスへの深い理解なしにはできない。 2. 技術的思考力 コードをゴリゴリ書く必要はないかもしれないが、API の仕組み、データの流れ、ワークフローの設計ができなければ話にならない。「Clay のテーブルを作れます」程度では全く足りない。システム全体をアーキテクチャとして設計する力が必要だ。 3. AIで実務を回した経験 「AI を知っている」ことではなく「AI で実際にオペレーションを回した経験がある」ことが求められる。パイプラインを組んで、データを流して、結果を見て改善する。この実務経験がなければ、チーム全体の業務を1人で回すことはできない。 「AIが仕事を奪う」話ではない GTMエンジニアの登場は「AI が人間の仕事を奪った」話ではない。「AI によって1人の人間の能力が10倍になった」話 だ。 ...

コトラーが提唱するように、現代のマーケティングにおいて「価値の提案（バリュー・プロポジション）」は核心だ。しかし、情報が氾濫する現代では、顧客は 「時間を消費すること」に対して非常に慎重 になっている。 顧客が貴重な時間を割いてでも「見たい」「知りたい」と思う価値には、共通するいくつかの要素がある。 1. 「切実な不満」を解消する価値 顧客が抱えている「痛み（ペインポイント）」が深いほど、その解決策には時間を投資する。 効率化: 「これまで3時間かかっていた作業が5分で終わる」という提案 不安の解消: 「なぜ資産が減り続けているのか？」といった、生存や安全に関わる問いへの答え 2. 「未知の自分」に出会える価値（自己実現） コトラーの「マーケティング4.0/5.0」でも語られるように、人間は自己実現や精神的充足を求める。 変身の予感: 「これを見れば、憧れの自分に一歩近づける」という高揚感 スキルの習得: 学習コストを払ってでも手に入れたい、市場価値を上げる情報 3. 「物語（ストーリー）」というエンターテインメント データや機能の羅列には誰も時間を割かないが、物語 には惹きつけられる。 共感と葛藤: 開発者がどのような苦労をしてその製品を作ったのかというドラマ 文脈の提供: 自分の生活がその製品によってどう劇的に変わるかという「ビフォー・アフター」 4. 「信頼」というコスト削減 「この人の言うことなら間違いない」というブランドの信頼感は、顧客が情報を取捨選択する時間を大幅に短縮させる。結果として、そのブランドが発信する「長尺のコンテンツ」でも安心して見てもらえるようになる。 価値を際立たせるための3つの視点 時間を割いてもらうためには、以下の3つの要素を掛け合わせるのが効果的だ。 要素 内容 顧客の反応 Relevance（関連性） 自分に関係があるか 「これは私のことだ！」 Benefit（便益） 得られる利益は何か 「見る価値がありそうだ」 Urgency（緊急性） 今見るべき理由は何か 「後回しにできない」 4つの価値と3つの視点の関係 前述の4つの価値は、この Relevance・Benefit・Urgency の掛け合わせで説明できる。 1. 「切実な不満」の解消 は、3つの視点すべてが自然に揃うケースだ。痛みを抱えている本人にとって Relevance は明白であり、解決策という Benefit は直接的で、痛みが続いている限り Urgency も高い。だからこそ最も強い動機づけになる。 2. 「未知の自分」への自己実現 は、Relevance と Benefit は強いが Urgency が弱くなりがちだ。「いつかやりたい」で終わらせないために、「今だけの機会」「このスキルがないと取り残される」といった緊急性の演出が鍵になる。 3. 「物語」によるエンターテインメント は、Relevance の入口を広げる役割を果たす。データの羅列では「自分には関係ない」と素通りされる情報も、共感できるストーリーに包むことで「これは自分の話だ」と感じさせることができる。 4. 「信頼」によるコスト削減 は、3つの視点すべてのハードルを下げる。信頼されたブランドからの発信であれば、Relevance の判断に迷わず、Benefit を疑わず、Urgency を感じやすくなる。信頼は個々の価値を増幅するレバレッジだ。 ...

「コードレビューは死ぬ」— AI時代のレビューは500行のdiffを読むことではない hiroki_daichi氏のポストが、Latent Space に掲載された記事「How to Kill the Code Review」を紹介し、555いいね、80RT、約51,000表示と大きな反響を呼んでいます。 「コードレビューは死ぬ」という刺激的な記事が出ていた。AI活用チームはタスク完了21%増、マージ98%増。一方でPRレビュー時間は91%増。変更の数も規模も指数的に増えている。人間がコードを全部読むのはもう無理だ。 — hiroki_daichi この記事の著者は Aviator の創業者兼CEO、Ankit Jain 氏です。Aviator はコードレビュー・マージキュー・デプロイメントの自動化プラットフォームを開発しており、著者の主張は「自社の課題認識から生まれた設計提案」という性格を持っています。Latent Space 編集部も「全面的に同意しているわけではないが、思考を刺激する内容として掲載した」と注記しています。 問題 — AI がコードを書く速度に、人間のレビューが追いつかない 数字が示す矛盾 記事が引用するデータは、AI コーディングツールの導入効果と副作用を同時に映し出しています。 指標 変化 タスク完了数 +21% マージされた PR 数 +98% PR レビュー時間 +91% PR の数が倍近く増え、レビュー時間も倍近く増える。これは持続可能な状態ではありません。 従来のコードレビューの限界 著者は、人間によるコードレビューがAIが登場する前から機能不全だったと指摘します。 PR が数日間放置される 500行の diff をスキミングして「LGTM」を返すラバースタンプ承認 レビュアーは自分の作業を抱えながら他人のコードを読む AI がコード生成を加速させたことで、この構造的な問題が表面化しただけだという主張です。 提案 — レビュー対象を「コード」から「意図（Intent）」へ 核心の発想転換 著者の提案は明快です。 人間がやるべきは500行のdiffを読むことではなく、仕様・制約・受け入れ基準を定義すること。コードはspecの成果物に過ぎない。 つまり、レビューの対象を**コード（How）から意図（What / Why）**へ移すということです。 従来のレビュー Intent ベースのレビュー 「このコードは正しく書かれているか？」 「正しい問題を、正しい制約で解いているか？」 500行の diff を読む 仕様・受け入れ基準をレビューする 実装の詳細に注目 設計意図と制約条件に注目 コードが成果物 Spec が成果物、コードは副産物 人間の役割の再定義 hiroki_daichi氏の要約が本質を突いています。 ...

「言語化が上手い」にも種類がある — 2 軸 5 分類で自分の得意・苦手を知る もとやま(@ysk_motoyama) 氏が、「言語化」を 2 軸で整理し 5 種類に分類する考察を公開しました。 最近整理しておきたいなと思ったのが「言語化っていったい何なんだよ？」です。Amazonで検索すると、たくさんの言語化が出てきます。流派がいろいろあって、ぜんぶ言語化。あれも言語化、これも言語化。 — @ysk_motoyama 「言語化力を上げたい」と思ったとき、実は 5 種類の言語化は頭の使い方が全く異なり、間違った種類のトレーニングをしても目的の力は身につきません。自分が伸ばしたい言語化がどれなのかを特定するための分類フレームワークを解説します。 「言語化」が指すものが多すぎる問題 書店やネットで「言語化」を検索すると、全く異なる能力が同じ言葉で呼ばれていることに気づきます。 自分の感情を書き出すこと = 言語化 人が言い表せないモヤモヤを一言で言い表すこと = 言語化 素敵なキャッチコピーを生み出すこと = 言語化 俳句とか歌 = 言語化 これらは全て「言語化」ですが、必要な頭の使い方が根本的に違います。構造化が上手くなりたいのにジャーナリングの練習をしても、いつまでも構造的に物事を整理できないまま、ということが起こり得ます。 2 軸のフレームワーク もとやま氏は大量の言語化に関する書籍や記事を読み込み、2 軸で整理できることを発見しました。 軸 1: 何を言語化するか 対象 説明 例 外界 観察できる事実、誰かの発言、何かの状態 市場データ、アンケート結果、業務フロー 内面 感情、欲求、価値観、解釈 モヤモヤ、怒り、直感的な違和感 軸 2: どう言語化するか 方向性 説明 0→1 何もないところから生み出す 100→10 混沌としたものを整理する 10→1 ギュッと圧縮してまとめる この 2 軸を掛け合わせると、言語化は 5 種類に分類できます。 外界（事実・状態） 内面（感情・価値観） ┌──────────────────┬──────────────────┐ 0→1 │ (1) コピーライティング │ (4) アート │ 生み出す │ 的な言語化 │ 的な言語化 │ ├──────────────────┼──────────────────┤ 100→10 │ (2) 構造化 │ (5) ジャーナリング │ 整理する │ 的な言語化 │ 的な言語化 │ ├──────────────────┼──────────────────┤ 10→1 │ (3) 要約 │ │ 圧縮する │ 的な言語化 │ │ └──────────────────┴──────────────────┘ 5 種類の詳細 (1) コピーライティング的な言語化 定義: まだ世の中に形として存在していない価値や概念を、短い言葉で新たに定義する力 ...

科学が格付けした 10 の勉強法 — 100 年の研究が示す「想起練習」と「分散学習」の圧倒的効果 @grandchildrice 氏が X で投稿した、勉強法の科学的格付けに関するポストが反響を呼んでいます。 アメリカの名門 4 大学が共同でまとめた研究結果がめちゃ有益で目玉飛び出た。この結果を見れば、今日から勉強の効率を爆上げできるかも。研究では、世の中で有効と言われている 10 種類の勉強法を過去の膨大な実験結果から格付け。 元になっている論文は Dunlosky et al. (2013) による “Improving Students’ Learning With Effective Learning Techniques”（全 55 ページ）です。本記事では、この論文の知見を技術者の学習にも活かせるよう、各勉強法の評価理由と実践方法を解説します。 論文の概要 著者と所属 4 大学 5 名の認知心理学・教育心理学の研究者が執筆しました。 著者 所属大学 John Dunlosky Kent State University Katherine A. Rawson Kent State University Elizabeth J. Marsh Duke University Mitchell J. Nathan University of Wisconsin-Madison Daniel T. Willingham University of Virginia 研究方法 過去に発表された膨大な実験結果をメタ分析し、10 種類の勉強法を 4 つの変数カテゴリ（学習条件、学習者の特性、教材の種類、評価タスク）で横断的に評価しています。単一の実験ではなく、数十年にわたる研究の蓄積を総合評価した点が特徴です。 ...

クリーンアーキテクチャという「型」の暴力 — 過剰な抽象化が現場を壊すメカニズム @sside 氏が X で投稿した、クリーンアーキテクチャの過剰適用への批判が反響を呼んでいます。 クリーンアーキテクチャかぶれの糞プロジェクト、異なる会社で2度目撃しました。(どっちもNestJS) この投稿は、@masuda220（増田亨）氏のツイートへの引用です。増田氏は以下のように述べています。 私の狭い観測範囲ではあるけれど、クリーンアーキテクチャを取り入れていると説明されたコードを見ると、過剰な変換コードと過剰な依存性の逆転をしているものが多い。実験目的であれば、やりすぎるのもありだと思うが、実プロダクトでは、不要な複雑さを持ち込んで苦しんでいるように見える。 2 人の指摘は、日本のエンジニアコミュニティで繰り返し議論されてきた「クリーンアーキテクチャのカーゴカルト問題」を改めて可視化しています。本記事では、クリーンアーキテクチャとは何か、カーゴカルトとは何かを整理した上で、なぜこの問題が繰り返し起きるのかを構造的に分析します。 クリーンアーキテクチャとは何か 起源と系譜 クリーンアーキテクチャは、Robert C. Martin（通称 Uncle Bob）が 2012 年にブログで提唱し、2017 年に書籍『Clean Architecture: A Craftsman’s Guide to Software Structure and Design』として体系化した設計思想です。 この思想は突然生まれたものではなく、先行するアーキテクチャパターンの集大成です。 年 アーキテクチャ 提唱者 核心 2005 ヘキサゴナルアーキテクチャ（Ports and Adapters） Alistair Cockburn アプリケーションを外部から分離する 2008 オニオンアーキテクチャ Jeffrey Palermo 依存関係を内側に向ける 2012 クリーンアーキテクチャ Robert C. Martin 上記を統合し SOLID 原則と結びつける クリーンアーキテクチャが新たに発明したものは実はほとんどありません。ヘキサゴナルアーキテクチャとオニオンアーキテクチャのルールを包含し、SOLID 原則（特に依存性逆転の原則）を軸に再構成したものです。 同心円図と依存性ルール 書籍で最も有名なのが、4 層の同心円図です。 ┌─────────────────────────────────────────┐ │ Frameworks & Drivers（外側） │ │ ┌───────────────────────────────────┐ │ │ │ Interface Adapters │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ Application Business Rules │ │ │ │ │ │ ┌───────────────────────┐ │ │ │ │ │ │ │ Enterprise Business │ │ │ │ │ │ │ │ Rules（中心） │ │ │ │ │ │ │ └───────────────────────┘ │ │ │ │ │ └─────────────────────────────┘ │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘ 依存性ルール: すべての依存は外側から内側に向かう（→ 中心） 依存性ルールがこのアーキテクチャの柱です。外側の層（フレームワーク、DB、UI）が内側の層（ビジネスロジック）に依存し、逆方向の依存は許されません。これにより、ビジネスロジックはフレームワークやデータベースの変更に影響されず、テスト可能で長寿命なコードになるとされています。 ...

AIチャットボットにあなたのプライバシーは存在しない — スタンフォード大学が暴いた構造的欠陥 スタンフォード大学の研究チームが、米国の主要AIチャットボット6社のプライバシーポリシーを体系的に分析した論文 “User Privacy and Large Language Models” を発表しました。その結論は明確です——全6社がユーザーの会話データをデフォルトでモデル学習に利用しており、実効的な保護は極めて限定的です。 論文概要 項目 内容 タイトル User Privacy and Large Language Models: An Analysis of Frontier Developers’ Privacy Policies 著者 Jennifer King, Kevin Klyman, Fotis Gaspelos, Tiffany Saade, Victoria Bhatt 所属 Stanford University 発表 2025年10月（AAAI AIES 掲載） 論文 arXiv:2509.05382 対象6社 企業 チャットボット Amazon Nova Anthropic Claude Google Gemini Meta Meta AI Microsoft Copilot OpenAI ChatGPT 1. データの「統合」—— 会話が資産として再利用される構造 全6社がデフォルトでモデル学習に利用 Anthropic は長らく「消費者の会話データを学習に使わない」と差別化していましたが、2025年9月にオプトイン → オプトアウトへ転換。これにより全6社がデフォルト学習利用に揃いました。 ...

サイトKPI/ROI Develop and Track Site KPIs and ROI to Optimize Marketing ウェブサイトへの訪問者が何に反応しているかを知ることは不可欠です。CMSシステムには初歩的なアナリティクスが含まれているものもありますが、専用のサービスを利用すれば、セールスやビジネスリードのコンバージョンに至るルートが表示されます。今は詳細なレポートまで行かなくても、アナリティクス・パッケージをインストールした時点から、そのデータは収集され、利用できるようになります。 目標を達成するには アナリティクスソフトウェアを設定し、具体的なゴール（例えば、購入やメールリストへの登録など）と、各ゴールのコンバージョンポイントをトラッキングする。 アナリティクスでこれができない場合は、できるアナリティクスを導入しましょう。 Googleアナリティクスで目標を作成するには アナリティクスを開き、プロフィールの1つに入ります。 トップナビゲーションのAdminをクリックします。カスタマイズタブの隣にあります。 [表示]列の[目標]を開きます。 New Goalをクリックし、ゴール名とゴール先のURLを入力します。ゴール名をクリックすると、ここで既存のゴールを編集できます。 確認ページの処理方法に応じて、マッチタイプを指定します。 購入を測定していない場合でも、目標に金額を割り当てます。これにより、アナリティクスはチャネル、ランディングページ、訪問者の価値を計算することができます。 コンバージョンファネル アナリティクスでコンバージョンファネルを設定することで、段階的に進捗を追跡し、顧客の摩擦のポイントを特定することができます： 目標ページの名前をクリックして目標に入ります。 Goals Detailsをクリックします。 Funnel をオンにします。 コンバージョンプロセスに進むために訪問するページのURLを入力します。これはウェブサイト毎に異なります。 あらかじめ決められた経路がない場合は、Conversionsの下にあるReverse Goal Pathレポートで、各ゴールのコンバージョンで訪問した3つのページを確認してください。 ページヒートマップ ページにヒートマップを設置し、ユーザーエンゲージメントを促進するデザインやコンテンツ要素を監視できるようにしましょう。これらの指標を使用して、ビジネスに最も影響を与えるデザイン、コンテンツ、マーケティングの取り組みの優先順位を決め、針を動かさない取り組みの優先順位を下げましょう。 コンバージョンファネル SEOマーケティングにおけるコンバージョンファネルとは、潜在顧客がウェブサイトを訪問してから商品購入や問い合わせなどの目標達成（コンバージョン）に至るまでのプロセスを段階的に可視化したものです。 ファネルとは？ ファネル（漏斗）とは、広く集客した上で、ふるいにかけられた見込み顧客が、検討・商談、そして成約へ流れる中で段々と少数になっていくことをいう。 その様を図にすると、漏斗で濾した様子に似ているところからそう呼ばれている。 コンバージョンファネルの概念 コンバージョンファネルは、顧客の購買行動を以下のような階層構造で捉えます。 認知（Awareness）: 潜在顧客が商品やサービスについて初めて知る段階。 興味・関心（Interest）: 潜在顧客が商品やサービスに興味を持ち、情報を収集し始める段階。 検討（Consideration）: 潜在顧客が競合他社と比較検討し、自社の商品やサービスが最適かどうかを判断する段階。 購入（Purchase）: 潜在顧客が商品やサービスを購入する段階。 ロイヤリティ（Loyalty）: 購入者が商品やサービスに満足し、継続的な利用や推奨に繋がる段階。 SEOマーケティングにおけるコンバージョンファネルの重要性 SEOマーケティングでは、コンバージョンファネルの各段階に合わせた施策を講じることで、効率的にコンバージョン数を増やすことができます。 認知段階: 幅広いキーワードで検索エンジン上位表示を目指し、多くの潜在顧客にウェブサイトを訪問してもらう。 興味・関心段階: 潜在顧客のニーズに合った有益なコンテンツを提供し、商品やサービスへの興味を高める。 検討段階: 競合他社との比較情報や顧客の声などを掲載し、自社の商品やサービスの優位性をアピールする。 購入段階: 購入しやすいウェブサイト設計や決済方法の提供、キャンペーンの実施などにより、購入を促進する。 ロイヤリティ段階: 購入後のサポートや情報提供、コミュニティ形成などにより、顧客満足度を高め、リピート購入や口コミを促進する。 コンバージョンファネルの活用 コンバージョンファネルを分析・活用することで、以下のような効果が期待できます。 ボトルネックの発見: コンバージョンファネルの各段階における離脱率を分析することで、改善点を見つけることができます。 施策の最適化: 各段階に合わせた最適な施策を講じることで、コンバージョン率を高めることができます。 顧客理解の深化: 顧客の購買行動を理解することで、より効果的なマーケティング戦略を立案することができます。 SEOマーケティングにおいては、コンバージョンファネルの概念を理解し、各段階に合わせた施策を講じることが、成功への鍵となります。