マーケティングの判断を、毎回ゼロから始めない。
Growth-OS は、貴社のマーケティングの前提・データ・判断の履歴をひとつの場所に集約し、AIが毎回そこを読んでから動く状態をつくる仕組みです。当社が設計・構築し、そのうえで調査から実装・計測までを継続的に回します。
レポートは毎月届くのに、そこから何を変えたかが残っていない。半年前に見送った施策を、なぜ見送ったのか思い出せない。——その状態を、判断が積み上がる状態に変えることが目的です。
マーケティングの現場で起きている問題の多くは、施策の巧拙ではなく前提と記録の置き方に原因があります。以下の5つは、いずれも構造的な問題です。それぞれについて、何が起きているのかと、解決すると何が期待できるのかを書きます。
症状。「この施策、前にもやって効かなかった気がするが、なぜやめたか思い出せない」「担当者が変わってから、何を基準に判断していたのかが分からない」
何が起きているのか。マーケティングの意思決定は、会議・チャット・メール・スプレッドシートのコメント欄に分散します。決定そのものは記録されても、その決定に至った前提——どのデータを見て、どの選択肢を検討して、なぜ採らなかったのか——は記録されません。
これが効いてくるのは半年後です。マーケティングは施策の連続で、前の判断を前提に次を決めます。根拠が消えると、前提が変わったのか、単に忘れただけなのかを区別できず、同じ議論をもう一度することになります。
ドキュメント化しても解決しないことが多いのは、同じ事実が複数の場所に書かれるためです。提案書にも、議事録にも、スプレッドシートにも同じ数字が書かれ、どれかが更新されないまま残ります。どれが最新かを判断するコストが、記録を読まない理由になります。
解決すると何が期待できるか。
症状。「生成AIに調査や原稿を頼むが、毎回ブランドの説明から書き直している」「同じことを頼んだのに、前回と違う答えが返ってくる」
何が起きているのか。生成AIは、セッションをまたいで前提を保持しません。記憶機能を持つものもありますが、何が記憶されていて何が記憶されていないかを人の側が管理できないため、業務の前提としては使えません。
そして出力の質は、モデルの性能よりも入力される前提の質で決まります。同じ質問でも、対象ブランドが違えば、禁止事項が違えば、過去に何を試したかが違えば、正しい答えは変わります。前提を毎回書き直している限り、書き漏らしのぶんだけ出力がぶれます。
したがって再現性の条件は、毎回同じ前提を、決まった順序で読ませることです。Growth-OS はその状態を、貴社のブランドに合わせて設計してつくります。
解決すると何が期待できるか。
症状。「先月より数字が良くなったが、何が効いたのか分からない」「悪くなった原因が、施策なのか季節要因なのか外部要因なのか切り分けられない」
何が起きているのか。これは計測ツールの設計に由来します。GA4もSearch Consoleも広告管理画面も、「何が起きたか」は記録しますが「何をしたか」は記録しません。
サイトを更新した日、タグを入れ替えた日、広告の配信面を変えた日——これらがどこにも残っていないと、数値の変化を施策に帰属させられません。結果として「全体的に改善しています」という、対象と数値のない報告になります。
必要なのは、反映の履歴と施策の実施記録を、計測データと突き合わせられる形で最初から残しておくことです。後から思い出して書くのでは間に合いません。
解決すると何が期待できるか。
症状。「レポートにセッション数と表示回数が並ぶが、事業の数字と結びつかない」「問い合わせが何経由で来たのか分からない」
何が起きているのか。GA4は、既定では「問い合わせ完了」を成果として数えません。何を成果とみなすかは、利用する側がキーイベントとして定義する必要があります。これが未設定のまま運用されている例は珍しくありません。
さらに、フォームが外部サービスの埋め込み（HubSpot、SalesforceのWeb-to-Leadなど）の場合、送信完了がページ遷移を伴わないことがあります。「サンクスページの表示」を成果として数える設計だと、そもそもイベントが発生しません。この場合、タグマネージャ側でフォームの送信イベントを拾い、GA4へ転送する経路を組む必要があります。
あわせて、何を成果として数えないかも決める必要があります。たとえば問い合わせフォームに種別の選択を設け、営業目的の送信を成果から除外しないと、数字が実態から離れます。
解決すると何が期待できるか。
症状。「検索順位は落ちていないのに、クリックが減っている」「AI検索の影響と言われるが、自社でどれくらい影響があるのか分からない」
何が起きているのか。Google検索の生成AI機能（検索結果の上部に表示されるAIによる要約）の中にページが引用されると、その表示はSearch Consoleの表示回数に計上されます。しかし要約の中で答えが完結すると、利用者はリンクをクリックしません。
この結果、掲載順位は高いのにCTRが極端に低いという、従来はあり得なかった組み合わせが現れます。順位を上げる施策を続けても改善しないため、「SEOが効かなくなった」という誤った結論に至りやすい領域です。
Search Console には「Google 検索の生成AI機能におけるサイトのパフォーマンス」というレポートがあり、表示のうちどれだけが生成AI機能内で起きたかをページ単位で確認できます。通常の表示とAI機能内の表示を切り分けてはじめて、順位の問題なのか、AI要約による構造変化なのかを判断できます。
当社ではこの切り分けを LLMO（Large Language Model Optimization、生成AIの回答に引用される状態をつくる取り組み）の出発点に置いています。
解決すると何が期待できるか。
Growth-OS は、ソフトウェア製品ではなく運用の型です。貴社ブランドごとに専用の作業場所を用意し、そこを「マーケティングに関する事実と判断の唯一の置き場所」にします。役割は3つに分かれています。
| 層 | 役割 |
|---|---|
| Repo | 前提・データ・判断の履歴を、ひとつの場所に集約して記録する |
| Agent | 決めた手順で、毎回同じ前提から検知・提案・下書きを行う |
| Eval | 提案の採否を記録し、手順そのものを改善する |
この3つが同じ場所でつながっていることが要点です。記録だけでは実行されず、実行だけでは積み上がらず、評価がなければ精度は上がりません。
Eval があるため、運用を続けるほど前提と手順が貴社に合っていきます。逆にいえば、初月がいちばん精度の低い状態です。そこは正直にお伝えしています。
中身の設計——何をどこに置くか、どの手順を何本持つか、何をどう記録するか——は当社が貴社の事情に合わせて組みます。貴社側に開発の知識は必要ありません。
AIが単独で行うのは、データの取得と集計、異常・機会の検知、改善案と下書きの作成までです。次の操作は必ず人の承認を経ます。
ゲートは2か所です。「何をやるか」を決めるときと、「どう反映するか」を確認するとき。1か所にまとめない理由は、この2つで判断する人も判断の中身も違うためです。施策の採否は事業判断で、反映の可否は実装の確認です。
反映は、確認項目を先に書いてから実施します。「反映してから確認する」と、問題が起きたときに何を戻せばよいかが分からなくなるためです。
AIに投入してよい範囲を最初に取り決め、文書として残します。
また当社は、自社の公開物にクライアント案件の情報を混ぜません。社名を伏せても、業種・サービス種別・金額・媒体名・期間の組み合わせで1社に絞れるものは公開しません。この判定は感覚に頼らず、公開前に機械的に検査しています。
このページに当社自身のデータしか載せていないのも、同じ理由によるものです。
| 一般的な運用支援 | Growth-OS | |
|---|---|---|
| 前提の置き場所 | 担当者の頭・メール・チャット | ひとつの作業場所（貴社に引き渡し可能） |
| 定例の成果物 | レポート | レポート＋実行ログ＋施策の採否記録 |
| AIの使い方 | 担当者が都度プロンプトを書く | 手順として固定し、毎回同じ前提で実行 |
| 施策の履歴 | 残らないことが多い | 候補・実施・結果を同じ場所に記録 |
| 担当者の交代 | 前提の引き継ぎに時間がかかる | 記録を読めば前提がそろう |
| 実装 | 別会社に依頼することが多い | 当社が反映まで行う |
| 契約終了後 | 前提が残らない | 記録一式が貴社に残る |
右の列に「速くなる」「上がる」と書いていないのは、意図したものです。Growth-OS が最初に変えるのは成果そのものではなく、成果を判断できる状態です。判断できる状態をつくってから、何を変えるかを決めます。
Growth-OS はこの4領域を同じ場所の上で扱います。個別のサービスとしても提供していますが、分けて発注するほど前提の共有コストが増え、各社が別の基準で報告してくる状態に戻ります。
| 領域 | 内容 | 個別のサービスページ |
|---|---|---|
| Web戦略・サイト実装 | 情報設計、制作、反映、計測設計 | Webサイト制作／デジタルマーケティング支援 |
| SEO・LLMO | 検索と生成AI検索の両方に対する対策 | SEO対策 |
| セールスイネーブルメント | 営業資料・事例・提案フォーマットの整備 | アドバイザリー |
| AIドキュメント | 調査・提案・レポートの制作を型として回す | デジタルコンテンツ制作 |
当社は、生成AIクローラーの影響を計測する WordPress プラグイン Assignment GPT LogViewer も提供しています。LLMO の計測部分で、必要に応じて併用します。
貴社ブランド用の作業場所を設計し、運用が回る状態まで立ち上げます。
| 段階 | やること | 貴社にお願いすること |
|---|---|---|
| 1. 棚卸し | 既存サイト・計測・コンテンツ・広告の現状を把握する | 各種管理画面の閲覧権限 |
| 2. 前提の明文化 | 誰に何を売っているか、使う言葉・避ける言葉、意思決定の履歴を文書化する | 商談記録・過去資料の提供、ヒアリング |
| 3. 計測の整備 | 計測の抜けを塞ぎ、成果イベントを定義する | 変更の承認 |
| 4. 手順の設計 | 定期実行する調査・検知を、貴社の事情に合わせて組む | — |
| 5. 引き渡し | 構造と運用ルールを説明する | — |
構築したものを当社が回します。月次の流れは次のとおりです。
対象ブランド数、既存資産の状態、計測の整備度合いによって大きく変わるため、金額は個別にお見積りします。棚卸しの結果をもとに、構築フェーズの範囲と運用フェーズの月額をご提示します。
費用の前に、Growth-OS が貴社に適しているかどうかをお話しさせてください。適さないと判断した場合は、そのようにお伝えします。
契約が終わっても、次のものは貴社の資産として残ります。
当社以外の会社に引き継ぐこともできます。囲い込みを前提にしていません。前提が文書化されていない状態のほうが、結果として貴社の選択肢を狭めるためです。
Growth-OS は、まず当社のサイト（assignment.co.jp）に適用しています。クライアント案件のデータは公開できませんが、自社サイトのデータであれば、判断の過程ごと公開できます。
Search Console の「生成AI機能」レポートによると、当社サイトの直近90日の表示回数 10.7万のうち、4.95万（46.3%）が生成AI機能内での表示でした（2026-06-18〜09-17、2026-09-20取得）。
特定の1ページでは、掲載順位3.9位に対して CTR 0.03% という組み合わせが観測されています。同ページの表示の56%が生成AI機能内で発生しており、AI要約の中に出てもクリックされないことがこの数字を説明します。順位を上げる施策では改善しない構造です。
「AI検索で流入が減った」という感覚を、自社のデータで裏付けた例です。同じ切り分け方を、貴社のプロパティにも適用できます。
当社は、こうした判断の過程を記事としても公開していく方針です。支援する側が自社で試していない手法を、貴社に勧めることはしません。
次の場合、Growth-OS はおすすめしません。
貴社側に専門知識が必要ですか。
開発の知識は必要ありません。記録はテキストと表で、ブラウザやテキストエディタで読めます。編集は当社が行い、貴社は内容を確認して採否を決めていただきます。
自社の機密情報をAIに読ませることになりませんか。
AIに投入してよい範囲を最初に取り決め、文書として残します。認証情報は記録に含めません。商談記録は個人名・社名を置き換えた版を分析に使い、原文は分けて保管します。取り決めを変更するときも記録を残します。
AIが勝手にサイトを更新したり、広告を止めたりしませんか。
しません。サイトへの反映、計測タグの変更、広告設定の変更、メールの配信は、すべて人の承認を経る設計です。AIが行うのはデータの取得・集計と、検知・提案・下書きの作成までです。
既存の制作会社・広告代理店との関係はどうなりますか。
置き換えを前提にしていません。前提とデータを1か所に集約することで、各社に同じ基準で依頼し、同じ基準で報告を受け取れる状態をつくる、という使い方ができます。
複数ブランドを持っています。
ブランドごとに作業場所を用意します。市場・競合・用語のように複数ブランドで共通して真である事実は、共通の場所に置いて参照します。
途中でやめられますか。
記録一式は貴社にお渡しします。形式がツールに依存しないため、他社への引き継ぎも可能です。
まずは貴社サイトと計測の現状について、30分ほどお話をうかがうところから始めます。その場で、どこに問題がありそうか、Growth-OS が適しているかをお伝えします。