ConductorのデータをAIに渡す？｜SEO基盤をつなぐ前の線

「SEOツールの数字は、月次の報告の前に担当者が画面から抜き出すもの。そのつもりで契約していた」「社内でAIエージェントを作る話が進んでいて、SEOのデータもつないでほしいと頼まれた。何をどこまで渡してよいのか分からない」——検索とコンテンツを受け持つマーケ部門で、担当者からも上長からも、こうした声が聞かれるようになりました。SEO・コンテンツの基盤のデータは、人が画面で見て判断に使うものだと思われがちです。しかし米国の Conductor が2026年4月に発表した AgentStack のように、基盤のデータを社内のAIモデルやAIエージェントへ直接流し込む仕組みが出てきました。問われているのは、もはや画面の見方ではありません。本当は、どのデータを、誰の資格で、どのAIに渡してよいかを先に決めることです。この記事では、SEO基盤のデータが社内のAIに届くまでを段ごとに追い、AIに任せることとマーケが決めておくことの線を整理します。

Conductorは何をする製品か

Conductor は、企業のSEOとコンテンツの業務をまとめて扱う基盤です。検索エンジンでの順位や、サイトの技術面の状態の監視に加えて、2026年10月時点の公式サイトでは、生成AIの回答の中で自社がどう言及され、どのページが引用されているかを測る機能を前面に出しています。AIの回答の中での見え方を整える取り組みを、同社はAEO（回答エンジン最適化）と呼び、従来のSEOと並べて扱っています。

公式の文書を見ると、扱うデータは大きく3つに分かれます。1つ目は、AI検索での自社の言及・引用・回答の中身・感情と、検索の順位です。2つ目は、サイトの監視から得られる技術面のデータで、ページの状態、インデックスされるかどうか、検索エンジンやAIのクローラーが訪れた記録などが含まれます。3つ目はコンテンツのデータで、記事の下書き、内容の評価、社内の知識の素材、内部リンクの候補などです。

つまり Conductor は、外から見た自社の姿（順位・言及）と、自社の中にある素材（下書き・知識）の両方を抱える基盤です。この2種類が同じ場所にあることが、社内のAIにつなぐときの判断を難しくします。外から見える数字は渡しても困りにくい一方、自社の中の素材には、公開前の企画や社外に出したくない情報が混じるからです。この違いは、後の段で渡すデータの範囲を決めるときの軸になります。

作っている会社と、国内でまだ知られていない理由

Conductor は米国の企業です。公式サイトのプレスの一覧には、2026年4月に AgentStack を発表したこと、2026年9月にAEOへの投資を強める方針を発表したことが並んでいます。2026年10月時点で、公式サイトに製品の終了や名称の変更、他社への統合の告知は見当たりません。この記事では、公式サイトと公式の文書で確かめられた範囲だけを扱います。

日本でほとんど知られていない理由は、確かめられる範囲で3つ挙げられます。まず、公式サイトの言語の切り替えは英語とドイツ語だけで、日本語の案内がありません。次に、料金は公開されておらず、3週間の無料の試用と営業への問い合わせが入り口になっています。そして、公式が対象として描いているのは、多数のサイトと担当者を抱える大企業のマーケ部門です。国内の中堅以下の会社が、比べる候補に入れる場面はまだ少ないと考えられます。

国内では、SEOツールといえば順位や被リンクを調べる道具を思い浮かべる人が多く、Conductor のような「企業全体の検索とコンテンツの基盤」という棚そのものがまだ小さいのが実情でしょう。SEOツールを有料にするか無料で済ませるかの選び方は別の記事に譲ります。ここでは、すでにこうした基盤を使っている、あるいは検討している会社が、そのデータを社内のAIにつなぐかどうかを決める場面に絞ります。

AgentStackは何をつなぐ仕組みか

AgentStack は、Conductor のデータを社外のAIや社内の仕組みへ渡すための道具をまとめたものです。公式の製品ページでは、4つの入り口が示されています（2026年10月時点）。1つ目は ChatGPT・Claude・Copilot の中で動くアプリで、開発者がいなくても使える入り口とされています。2つ目は MCPサーバーとAPIで、既存のAIの業務の流れやBIの環境、自社で作るエージェントにデータを渡すためのものです。

3つ目はデータのAPIで、BIやレポートの仕組みにデータを流し込む用途です。4つ目がすぐに使えるエージェントで、コンテンツと技術面のAEOの作業の流れを、統制を組み込んだ形で回すものと説明されています。公式は、このエージェントを開発者ではなく企業のマーケチーム向けと位置づけています。開発の部門を通さずにマーケが自分で動かせる、という売り方です。

MCPサーバーの製品ページでは、MCPに対応した基盤ならつなげるとし、例として Zapier や n8n、Opal などを挙げています。特定のモデルに縛られず、社内の非公開のLLMにも使えるとも書かれています。MCPそのものの仕組みは「AIと社内システムをつなぐMCP」の記事に譲りますが、要するにAgentStack は、Conductor のデータを社内のどのAIからでも読めるようにする差込口だと考えると、この先の判断が整理しやすくなります。

「SEOのデータは画面で見るもの」はもう前提にならない

これまでSEOツールのデータは、担当者がログインして画面を見て、必要な数字を抜き出して報告書に貼るものでした。誰が何を見たかは、ツールのアカウントの数と権限でおおむね決まっていました。データが社外に出ていく経路も、担当者が手で作る資料やメールに限られていたと言えます。管理する側から見れば、出口は人の手の数だけで、数えることができました。

AgentStack のような仕組みでは、この前提が変わります。社内のAIエージェントが、人の操作を待たずにデータを読みに行き、ほかのデータと組み合わせ、要約や改善案を作ります。データの行き先は、人が作る資料ではなく、エージェントがつながっている先になります。社内の別の道具のこともあれば、外部のAIの基盤のこともあります。しかも、エージェントが読み出した後のデータがどこまで運ばれるかは、Conductor の側からは見えません。

そのため、つなぐ判断は「便利な連携を1つ足すかどうか」ではなく、マーケのデータの出口を新しく1つ開けるかどうかの判断になります。出口を開けること自体は悪いことではありません。ただ、開ける前に、渡すデータ、つなぐ資格、AIの出した案の行き先、止め方を決めておかないと、誰が何をどのAIに渡したのか、後から誰も答えられなくなります。次の節から、この順番で段を追っていきます。

データが社内のAIに届くまでを6つの段で追う

ここでは、Conductor に溜まったデータが社内のAIに届き、AIが作った案が公開されるまでを、6つの段に分けて追います。段ごとに、AIに任せてよいことと、人が先に決めておくことが分かれます。全体を先に並べておきます。

6つの段のうち、AIが主役になるのは、データを読んで案を作る中ほどの部分だけです。1つ目から3つ目は、つなぐ前に人が決めることで、5つ目と6つ目は、つないだ後に人が持ち続けることです。AIの働きを安心して使えるかどうかは、つなぐ前の3つの段の決め方でほぼ決まります。導入の準備に時間をかけるなら、接続の作業ではなく、ここに使ってください。

この6段は、Conductor に限らず、SEOやコンテンツの基盤をAIにつなぐときに共通して使えます。ただし、段2と段3で何を決めるべきかは、基盤が抱えるデータと、提供元が公開している管理の機能によって変わります。以下では Conductor の公式の文書で確かめられた範囲を使って、段ごとに具体的に見ていきます。

段1　つなぐ先のAIを決める

AgentStack の入り口から見ると、つなぐ先は大きく3つに分かれます。1つ目は、ChatGPT・Claude・Copilot といった外部の対話AIの中で動くアプリです。2つ目は、自社で作るエージェントや、Zapier や n8n のような自動化の道具からの接続です。3つ目は、BIやレポートの仕組みへのデータの流し込みです。

同じ Conductor のデータでも、行き先によって、データの扱いを決める契約が変わります。Conductor の公式は、MCPサーバーを流れるデータを公開のモデルの学習に使わないと書き、AgentStack の製品ページでも顧客のデータで学習しないと説明しています。しかし、それは Conductor の側の約束です。データを受け取った対話AIや自動化の道具の側で、会話の記録がどこに残り、学習に使われるかどうかは、受け取る側のサービスと自社との契約で決まります。

そのため、段1で決めるのは「どのAIにつなぐか」だけでなく、「そのAIは会社として契約し、データの扱いを確かめた先か」です。社員が個人で使っている対話AIのアカウントに、会社のSEOのデータを流し込むことは避けます。最初の接続先は、情シスが法人として契約し、学習に使わない設定を確かめた対話AIか、自社の管理下で動くエージェントに限るのが無難です。BIへの流し込みは、すでに社内のデータの置き場の決まりがあるなら、その決まりに乗せます。

段2　渡すデータの範囲を4つに分けて決める

Conductor が抱えるデータは、外に出たときの影響の大きさがそれぞれ違います。全部をまとめて「SEOのデータ」と呼んでしまうと、渡してよいかどうかの判断ができません。公式の文書に出てくるデータを、影響の大きさで4つに分けて整理すると、次のようになります。

データの種類	例（公式の文書から）	外に出たときの影響	渡す前に決めること
順位・競合の数字	検索の順位、AI検索での競合との比率	小さい。外から観測できる数字が中心	どの競合を追っているかが分かってもよいか
AI検索での言及	自社の言及・引用・回答の中身・感情	中くらい。自社がどの問いを気にしているかが見える	追っている質問文の一覧を渡してよいか
技術面の監視	ページの状態、インデックス、クローラーの訪問の記録	中くらい。公開前のページの存在が分かることがある	公開前のページや社内向けのページを除けるか
自社の未公開の素材	記事の下書き、知識の素材、評価の点数	大きい。公開前の企画や社外秘が含まれうる	原則は渡さない。渡すなら案件ごとに承認する

表のうち、最も慎重に扱うべきなのは4行目です。公式の文書によれば、コンテンツのAPIでは、下書きの作成・更新・削除や、知識の素材の登録ができます。つまり Conductor には、まだ公開していない記事や、AIに書かせるために登録した社内の資料が溜まっていきます。これを社内のAIにそのまま読ませると、公開前の新製品の記事や、価格の改定の予定が、別の部署のエージェントの答えに混じることが起こり得ます。

2行目の、AI検索で追っている質問文の一覧も、見落とされやすい情報です。どの問いで自社が言及されたいかは、そのまま会社のマーケの重点を表しています。競合に知られて困るほどではなくても、社外の基盤に流すなら一度は上長が目を通しておくべき情報です。範囲は「全部渡す」から始めず、1行目と2行目から始め、必要が出たときに3行目、4行目を案件ごとに足す順番にします。

段3　誰の資格でつなぐかを決める

公式の文書によれば、Conductor のAPIはAPIキーで呼び出し、キーごとに全体の呼び出しの上限がかかります（上限の具体的な数値は公開の文書には書かれていません）。利用者の管理のAPIでは、利用者を通常の利用者と閲覧のみの利用者に分けて作り、停止すると閲覧もできなくなると説明されています。つまり、つないだAIが何を読めて何を書けるかは、つないだときのキーと利用者の資格で決まります。

ここでよくある失敗は、担当者が自分のアカウントで発行したキーを、そのまま社内のエージェントに渡してしまうことです。その担当者が編集の資格を持っていれば、エージェントも同じことができてしまいます。担当者が異動や退職をしたときに、キーを止めるとエージェントも止まり、止めなければ持ち主の分からないキーが残ります。

そこで、AIにつなぐためのキーや利用者は、個人ではなく「SEOのデータをAIに渡す役割」にひもづけて発行し、読むだけで済む用途なら閲覧のみの資格にします。発行した人、発行日、つないだ先、見直す日を、1行の記録に残します。なお、MCPでつなぐ場合の認証の方式は、2026年10月時点の公開の文書では確かめられませんでした。契約の前に、MCP経由の接続がどの利用者の資格で動くのかを、提供元に確かめてください。

段4　AIが作った記事案・改善案の行き先を決める

データを読んだAIは、記事の構成案、既存の記事の改善案、内部リンクの候補、AI検索で言及されていない問いの一覧などを作ります。公式の文書では、コンテンツのAPIから下書きの生成や評価ができ、すぐに使えるエージェントがコンテンツの作業の流れを回すと説明されています。ここで決めるのは、AIが作ったものがどこに置かれ、そこから先へ誰が運ぶかです。

行き先の候補は、Conductor の中の下書き、社内の共有の置き場、そして記事を公開するCMSの3つです。公式の文書には、CMSと連携してクロールを起動するAPIもあります。AIの案をCMSに直接流し込めるようにすると手間は減りますが、公開の一歩手前まで、人が一度も見ないまま進む道ができてしまいます。

そのため、行き先は下書きの置き場までと決め、CMSへの書き込みや公開の権限はAIエージェントに渡さないのが基本です。修正を本番のサイトに自動で当てる仕組みの是非は、Botify を扱った別の記事に譲ります。ここでは、AIの案は必ず人の手で次の段に運ぶ、という線だけを決めておきます。下書きの置き場には、どのデータを読んで作った案なのかを書き添えるよう、エージェントの指示に入れておくと、次の段の確認が速くなります。

段5　公開の前に人が確かめる

AIの案を公開する前に人が確かめることは、通常の記事の確認に加えて、AIにデータをつないだからこそ増えるものがあります。1つは、案に未公開の情報が混じっていないかです。段2で範囲を絞っていても、エージェントが別の道具から読んだ社内の資料を混ぜることがあります。

2つ目は、数字と事実の出典です。AIは Conductor のデータを読んで「この問いでは競合が多く引用されている」といった主張を書きますが、その数字がいつの時点のもので、どの質問文の結果なのかが抜け落ちやすくなります。AI検索の数字は日によって揺れるため、数字をそのまま記事や社内の報告に載せず、時点と条件を添えてから使います。測り方そのものは、AI検索での言及の測り方を扱った別の記事に譲ります。

3つ目は、AI検索で言及されることを狙うあまり、不自然な書き方になっていないかです。特定の問いへの答えを繰り返し詰め込んだ文章は、読者にとって読みにくく、自社の言い回しの決まりからも外れがちです。AIの案は、読者に向けた記事として成り立っているかを、人が最後に決めるという線を外さないでください。確認した人と日付は、公開の記録に残します。

段6　止め方と、つないだ記録を持つ

つないだものは、止められて初めて安心して使えます。Conductor の側で止める手段としては、公式の文書から、APIキーの無効化と、利用者の停止が確かめられます。停止した利用者はデータを見られなくなり、必要なら元に戻せると説明されています。これに加えて、受け取る側の対話AIや自動化の道具で、接続そのものを外す手順も確かめておきます。

止める場面は、思わぬデータが渡っていたと分かったとき、エージェントの案に未公開の情報が混じったとき、担当者が異動したとき、契約を見直すときなどです。どの場面で誰が止めるかを、マーケの上長と情シスで先に決めておきます。止める権限がマーケにしかなく、マーケの担当者が不在だと止められない、という状態は避けます。

記録には、つないだ先、渡すデータの範囲（段2の表のどの行か）、使うキーや利用者、承認した人、見直す日を書きます。3か月に1度はこの記録を見て、使われていない接続を外すと決めておくと、つないだまま忘れられた出口が残りません。

• 担当者の個人のキーを、そのまま社内のエージェントに渡す
• 社員が個人で使う対話AIのアカウントに、会社のSEOのデータを流し込む
• 下書きや知識の素材まで、最初から全部読ませる
• AIの案をCMSに直接書き込ませ、公開の手前で人が見ない
• AI検索の数字を、時点と条件を添えずに記事や報告に載せる
• つないだ先と承認者を記録せず、止める手順も決めない

段ごとに「AIに任せること」と「人が決めておくこと」

ここまでの6段を、AIに任せてよいことと、人が先に決めておくことに分けて並べます。部門で導入を決めるときに、この表の右の列が埋まっているかどうかを、上長が確かめる材料にしてください。

段	AIに任せてよいこと	人が決めておくこと
1 つなぐ先	なし（つなぐ先はAIが選ばない）	会社として契約し、データの扱いを確かめた先か
2 渡すデータ	渡された範囲のデータの下読み・要約	どの種類のデータを渡すか、追加するときの承認
3 つなぐ資格	なし	役割にひもづけたキーと、閲覧のみか編集もか
4 案の行き先	記事案・改善案・内部リンクの候補の下書き	下書きの置き場までとし、公開の権限を渡さない
5 公開前の確認	出典の候補や、表記の揺れの指摘	事実・未公開の情報・言い回しの最終の判断
6 止め方と記録	接続の利用状況の集計	止める人と場面、3か月ごとの見直し

表を見ると分かるとおり、AIに任せてよいのは、渡された範囲のデータを読み、案を下書きし、人の確認を手伝うところまでです。何を渡すか、誰の資格で動くか、何を公開するかは、AIが学んで決めるものではなく、会社が決めるものです。この線を部門で合意しておくと、エージェントを増やしたいという要望が出たときにも、どの段を決め直せばよいかがすぐに分かります。

公式の文書で確かめられなかったこと

2026年10月時点で、Conductor の公開の製品ページと文書を読んでも確かめられなかった点があります。製品の評価を下げる理由ではありませんが、つなぐ前に提供元に確かめておくべき点です。契約の前の打ち合わせで、次の項目を聞いてください。

• MCPでつなぐときの認証の方式と、どの利用者の資格で動くのか
• MCPやアプリの経由で、下書きの作成や設定の変更など、書き込みの操作ができるのか
• APIキーごとの呼び出しの上限の具体的な数値と、上限を超えたときの扱い
• 接続の経由で読まれたデータや、AIとのやり取りの記録が、どこにどれだけの期間残るのか
• すぐに使えるエージェントに組み込まれた統制が、具体的に何を止めるのか
• 利用者や接続ごとに、いつ何が読まれたかを後から確かめられる記録があるか

このうち、書き込みの可否と記録の有無は、段4と段6の決め方に直接関わります。公式の文書では、データのAPIは読むためのもの、コンテンツのAPIは下書きの作成・更新・削除ができるものと書き分けられていますが、MCP経由でどこまでできるかは書かれていませんでした。確かめられないことは、できる前提で守りを置くのが安全です。書き込めるかどうか分からないなら、書き込めるものとして資格を絞ります。

費用の増え方と、やめるときに残るもの

Conductor は料金を公開していないため、金額の比べ方はこの記事では扱いません。費用がどう増えるかについては、公式に示された料金の仕組みがないので、一般的な目安として考えます。企業向けのSEOの基盤は、対象にするサイトやドメインの数、追う検索語や質問文の数、利用者の数で費用が決まることが多く、AIにつなぐと、ここに呼び出しの量が加わる可能性があります。

見落としやすいのは、受け取る側の費用です。社内のエージェントが Conductor のデータを読むたびに、エージェントの側では生成AIのモデルの利用料がかかります。データを細かく何度も読ませるほど、Conductor の契約とは別のところで費用が増えます。つなぐ前に、どの頻度でどれだけのデータを読ませるかを決め、両側の費用を合わせて見積もるようにしてください。

やめるときに残るものも、先に確かめておきます。エージェントや社内のレポートが Conductor のデータを前提に作られていると、契約をやめた時点でそれらが止まります。過去の順位や言及の推移を、自社の置き場に書き出せるかどうかも確かめておきます。つなぐ数が増えるほど、やめるときに止まるものも増えるので、段6の記録はやめるときの一覧としても使えます。

よくある質問

AIのクローラーを拒否するかどうかの話とは関係がありますか

別の話です。AIのクローラーに自社のサイトを読ませるかどうかは、公開しているページを外のAIにどう扱わせるかの判断で、別の記事で詳しく扱っています。この記事で扱ったのは、自社が契約している基盤のデータを、社内のAIにどう渡すかの判断です。

社内のAIに渡したSEOのデータは、学習に使われますか

Conductor の公式は、MCPサーバーを流れるデータを公開のモデルの学習に使わず、顧客のデータで学習しないと説明しています（2026年10月時点）。ただし、データを受け取った対話AIや自動化の道具での扱いは、そのサービスと自社との契約で決まります。受け取る側の設定を、情シスと一緒に確かめてください。

AI検索での言及の数字は、どう読めばよいですか

この記事では、数字を社内のAIに渡す判断に絞りました。AI検索での言及の測り方や、測る道具を買うか自前で測るかは、別の記事で整理しています。数字を渡すときは、時点と質問文の条件を必ず添えてください。

大企業でなくても検討する意味はありますか

公式が対象として描いているのは大企業のマーケ部門です。ただ、この記事の6段は、どのSEOの基盤をAIにつなぐときにも使えます。まだ基盤を持たない会社は、まず社内のAIに何を渡してよいかの決まりを作るところから始めると、後で基盤を選ぶときの判断が速くなります。

まとめ

Conductor は、検索とAI検索での自社の見え方を測り、コンテンツの改善までを扱う企業向けの基盤で、AgentStack によってそのデータを社内のAIやエージェントへ直接渡せるようになりました。これは、マーケのデータの出口を新しく開けることでもあります。つなぐ先、渡すデータの範囲、つなぐ資格を先に決め、AIの案は下書きの置き場までとし、公開の前に人が確かめ、止め方と記録を持つ。データの下読みと案の下書きはAIに任せ、何を渡し何を公開するかは人が決める。この線を部門で合意してから、つなぐ範囲を広げてください。

• 製品の機能・データの扱い・管理の機能は、Conductor の公式サイト、AgentStack と MCPサーバーの製品ページ、公式の文書を2026年10月19日に確かめた範囲に基づきます。機能や条件は更新されることがあるため、利用前に最新の原文を確かめてください
• 社外のAIの基盤にデータを渡す場合は、契約と自社の情報管理の決まりに関わります。実際の運用は情シスと法務の担当者と確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。