生成AIをWebマーケティングに使うには？5つの活用例と評価の進め方【2026年確認】

2026年10月8日に、OpenAI Node SDKの現行READMEを再読しました。現在の例はResponses APIを主なモデル対話APIとして示し、手動で会話履歴を管理する場合は出力itemの順序を保ち、toResponseInputItems()などで次の入力へ正規化するよう案内しています。Chat Completionsは継続サポートされる標準として併記され、画像入力、workload identity、SSE streaming、webhook署名検証にも別の条件があります。これはSDKの使い方の資料であり、採用モデルの品質、料金、契約、配信成果を保証する実績ではありません。

30秒で要点

• 生成AIを選ぶ前に、記事作成・問い合わせ対応・情報整理など、止まっている工程を一つ決めます。生成時間だけでなく、確認・修正・運用まで含めて評価します。
• ChatGPT、Claude、Geminiの名前だけで用途や優劣は決まりません。入力できる情報、必要な出力、社内で使える契約・設定、確認担当者をそろえて比較します。
• 本記事の5つの使い方と数値は、導入を検討するための例です。企業の実績や、特定製品が達成した削減率ではありません。

記事の下書きは増えたのに、確認が追いつかない。問い合わせの返信案は速く出るのに、誤った案内を見逃せない。こうした状況では「どのAIが強いか」より、どの工程を任せ、どこで人が判断するかが先に必要です。

ここではWebマーケティングの担当者が、最初の試行を選び、続けるかを決めるまでを説明します。2026年10月4日に公式資料を確認した範囲に基づきます。モデルの最新順位や料金一覧を扱う記事ではなく、製品の画面とAPIの違いにも注意して読み進めてください。

何を改善したいかを、製品名より先に決める

同じ「記事作成」でも、資料探し、構成、執筆、校正、承認では負担が違います。完成稿を一度に任せるより、問題のある一工程を切り出した方が、出力の良し悪しを比較できます。

表が収まらない場合は、横にスクロールできます

Anthropicの公式ガイドも、プロンプトを改善する前に成功条件と評価方法を決めるよう案内しています。これはClaude固有の効果率ではなく、試行の組み立てに使う考え方です。公式ガイド

たとえば「良い記事を作る」では採否が曖昧です。「対象読者の三つの疑問が見出しに含まれる」「資料にない実績を加えない」「確認込みで従来の作業時間を超えない」と分ければ、担当者同士で判断を合わせやすくなります。

ChatGPT・Claude・Geminiを比較するときの条件

チャット画面で契約している機能と、開発者向けAPIで使える機能・利用枠は同じとは限りません。画面の購読料を払えばAPIも同じ条件で使える、と仮定しないでください。

表が収まらない場合は、横にスクロールできます

比較に使うモデル名と設定は試行記録へ残します。ただし、本記事ではモデル版数の新旧や製品間の順位を断定しません。用途に必要な機能が現在の契約で使えるかは、採用時に提供元の案内を確認します。

活用例1：記事の構成案を作り、根拠を人が足す

ブログでは、完成文の大量生成よりも、読者の質問を整理する用途から試せます。入力は「テーマ・読者が迷う場面・扱う範囲・採用できる資料・避けたい断定」です。出力は見出しと、その見出しで答える問いに限定します。

たとえば「店舗サイトの予約導線を見直したい担当者」に向けるなら、予約方法、キャンセル条件、スマートフォンでの入力、困ったときの連絡先が必要かを確認します。AIが新しい実績や料金を埋めてきたら、そのまま採用しません。

Googleは生成AIを調査や構成に利用すること自体を否定していません。一方、利用者に価値を加えず多数のページを作る行為にはスパム方針上の問題があり得ます。本文だけでなくタイトル、説明、画像の代替テキストなども正確さを確認する必要があります。Googleの生成AIコンテンツに関する案内

APIへの入力を確かめる小さな例

次は、OpenAIのResponses API形式で要求を組み立てる関数です。outline-demo.mjs として保存し、Node.jsで node outline-demo.mjs を実行できます。外部パッケージもAPIキーも不要です。実行するのは偽のクライアントで、AIの文章品質や通信を検証する例ではありません。

import assert from 'node:assert/strict';

async function generateBlogOutline(client, { model, topic, keywords }) {
  if (typeof model !== 'string' || !model.trim() ||
      typeof topic !== 'string' || !topic.trim() ||
      !Array.isArray(keywords) || keywords.length === 0 ||
      !Array.from(keywords).every(k => typeof k === 'string' && k.trim())) {
    throw new TypeError('model, topic and nonempty keywords are required');
  }
  const response = await client.responses.create({
    model,
    instructions: '読者の疑問に答える構成案だけを日本語で作る。実績や数値は創作しない。',
    input: JSON.stringify({ topic: topic.trim(), keywords: keywords.map(k => k.trim()) }),
  });
  if (typeof response?.output_text !== 'string' || !response.output_text.trim()) {
    throw new Error('No usable outline was returned');
  }
  return response.output_text.trim();
}

const requests = [];
const fakeClient = {
  responses: {
    async create(request) {
      requests.push(request);
      return { output_text: '1. 予約する前に知りたいこと\n2. 入力と確認\n3. 困ったときの連絡先' };
    },
  },
};
const outline = await generateBlogOutline(fakeClient, {
  model: 'mock-only', topic: '店舗の予約導線', keywords: ['予約', 'キャンセル'],
});
assert.match(outline, /連絡先/);
assert.equal(requests.length, 1);
assert.equal(JSON.parse(requests[0].input).topic, '店舗の予約導線');
await assert.rejects(generateBlogOutline(fakeClient, {
  model: 'mock-only', topic: ' ', keywords: ['予約'],
}), TypeError);
await assert.rejects(generateBlogOutline({ responses: { create: async () => ({}) } }, {
  model: 'mock-only', topic: '予約', keywords: ['予約'],
}), /No usable outline/);
console.log(outline);

実接続する場合は、公式SDKの導入、サーバー側での認証情報管理、利用可能なモデルの指定、料金・上限・タイムアウト・ログ方針が別に必要です。mock-only はモデル名ではありません。公式SDKの例では responses.create() と output_text が案内されていますが、このローカル例はSDKの再試行や実サービスのエラーまで再現しません。OpenAI公式Node SDK

入力をJSONにすることや禁止事項を一文書くことだけでは、安全性を保証できません。出力を公開候補として扱い、根拠・著作権・表現の確認を担当者の工程に残します。

活用例2：問い合わせの返信案を作り、例外は引き継ぐ

FAQ対応では、まず回答元の資料を承認済みのものに絞ります。対象には営業時間、利用手順、公開済みの返品条件などが考えられます。顧客ごとの契約、返金の判断、本人確認が必要な情報は、下書きだけで完結させない設計にします。

1. 問い合わせを分類し、回答できる範囲か確認する。
2. 該当するFAQの項目と適用日を返信案に添える。
3. 担当者が条件を照合して送信するか、専門担当へ引き継ぐ。
4. 誤案内、引継ぎ漏れ、確認時間を記録する。

営業時間外に下書きを作れることと、24時間正確に自動解決できることは別です。「答えられない」と伝える文面や、翌営業日の受付案内も評価対象にします。実装へ進む場合は、チャットボットの設計原則で会話と引継ぎの条件を整理してください。

活用例3：長い資料を要約し、重要な留保を残す

要約では文章の短さだけを採点しません。売上の単位、対象期間、調査人数、対象外の条件など、意思決定を変える情報が残っているかを確認します。

入力資料を固定し、「結論」「根拠の場所」「未確定事項」に分けた出力を求めると照合しやすくなります。ただし、AIが示したページ番号や引用が実在するかは原資料へ戻って確かめます。資料にない提案は、要約と分けて表示します。

試行では短い資料・表が多い資料・結論が条件付きの資料などを含めます。機密資料を外部サービスへ入力してよいか不明なら、公開資料や合成データで先に工程を確認します。Claudeを含む特定製品が常に要約に最適、あるいは一定率で時間を減らせるとは扱いません。

活用例4：メールを用途別に下書きする

「初めて資料を請求した人」と「既存サービスの更新案内を受ける人」では必要な説明が違います。AIには、確認済みの対象条件と提供内容を渡し、用途ごとに件名や冒頭の案を出させます。

個人の属性や関心を勝手に推測して差し込む必要はありません。宛名、料金、期限、適用条件、配信停止の導線は元データと照合します。本文を作れることは送信の許可にはならず、配信可否と対象リストの確認は別に必要です。

比較するときは、同じ期間・対象条件で配信数、クリック、問い合わせ、その後の対応品質を見ます。件名以外も同時に変えた場合、結果の違いをAI文面だけの効果にはできません。開封率を含むメール計測の注意点は、Web集客の始め方で説明します。

活用例5：画像と文章の対応を確認する

画像の中に何があるかを説明する「画像理解」と、新しい画像を作る「画像生成」は異なる用途です。GoogleのGemini APIの資料は、画像の説明、分類、質問回答などの画像理解を案内しています。画像理解の公式資料

たとえば、利用権を確認した商品の写真から紹介文の下書きを作る場合、色や配置の説明は参考になります。一方、写真だけで材質、容量、安全性、認証の有無を断定させないようにします。担当者は商品台帳と照合し、画像で確認できない情報を区別します。

画像生成を使うなら、実物と見分けられない商品写真や実績の証拠として使わない運用が必要です。サービスの提供条件、画像の利用権、社内の表示方針を確認します。本記事は画像生成機能の現行プラン比較や、その利用による反応率を検証していません。

効果を測る：生成時間ではなく、確認後の合計で比べる

次は架空の1記事の作業例です。実在企業の成果でも、製品の標準的な性能でもありません。

表が収まらない場合は、横にスクロールできます

この条件では短縮時間は30分、短縮率は 30 ÷ 120 × 100 = 25% です。下書きだけの短縮55分とは違います。1件あたりの利用料が発生する場合はそれを加え、初期設定や担当者の教育は別枠の費用として記録します。

品質は平均点だけで済ませず、公開できない誤りも数えます。たとえば事実誤認、権利不明の素材、差別的な表現、個人情報の混入などは、時間が短くても修正が必要です。比較用の資料と採点基準を固定し、良かった例だけを選ばないようにします。

小さく始め、続行・変更・中止を決める

最初の試行では、一つの業務、担当者、使ってよい資料、確認者、評価日を決めます。試行件数は扱える範囲で設定し、簡単な例だけでなく、情報不足や例外のある入力を含めます。

• 続行：確認後の品質を保てており、合計時間や負担に改善が見られる。
• 変更：下書きは有用だが、入力準備や確認が重い。対象工程や出力形式を狭めて再評価する。
• 中止：根拠を確認できない回答や機密の扱いなど、許容できない問題を解消できない。

初回から自動公開や一斉送信までつなぐ必要はありません。承認済みの出力を次の工程へ渡す仕組みを先に作り、責任を持つ担当者を決めます。

5分で着手するなら、直近の一作業について「入力準備・作成・確認」の時間を分けて書き出してください。そのうち何をAIへ渡すかと、渡さずに残す判断が言えれば、製品を比較する条件が整います。集客全体の優先順位は、Webマーケティングの全体像へつなげて考えられます。