PR本記事にはプロモーション（アフィリエイトリンク）が含まれる場合があります。
CONTENTS目次
結論から書きます。すでに作ってあった「集客用のAI商材」を、ゼロから作り直さずに採用向けの別商材へ転用できました。しかもやったことは全部の作り直しではなく、同じエンジンに『採用モード』を足しただけです。この記事では、プログラミング未経験の私がAIと一緒に、集客用LPを採用LP＋求人票＋採用ブログの一式に作り替えた過程と、そのときに悩んだ設計判断を正直に共有します。「AI 商材を別の用途に転用できるか知りたい」「求人票の構造化データってどう扱うの？」という方の参考になればうれしいです。
この記事でわかること
- 集客用AI商材を採用向けに転用するときに足した機能（採用モード）の中身
- 求人票の構造化データ（JobPosting）で初心者がつまずく点と対処
- 作り直しではなく「モード追加」で済むかどうかは最初の設計で決まるという気づき
なぜ集客用AI商材に「採用モード」を足そうと思ったのか
もともと私が作っていたのは、AIが自動で記事を書き続けるLP（ランディングページ＝1ページで完結する紹介ページのこと）です。これを商材として売っていました。使ってみると、集客目的のお客さんにはそこそこ売れるのですが、求人・採用目的のお客さんには売れませんでした。
仕組みとしては同じ「AIが記事を自動で書く」なのに、採用の文脈になると刺さらない。これはもったいない、つまり売れたはずの相手を取りこぼしている機会損失だと感じたのがきっかけです。
そこで考えたのが、新しい商材をゼロから作るのではなく、いまあるエンジンに「採用モード」を追加して、採用LP＋求人票＋採用ブログの一式として売れる形にすることでした。集客モードと採用モードを設定画面で切り替えられるようにすれば、中身は1つのまま2種類の商材として出せるのではないか、という発想です。
未経験の自分にとって、新規でもう一本作るのは正直しんどいです。だからこそ「足すだけで済むか」を最初に検討したのは、我ながら良い判断だったと思います。
作り直さずに済んだ理由｜LPのモード切替という発想
今回やった実装を、やったこと順に並べるとこうなります。
- 求人票のデータベースと管理画面のCRUD（作成・表示・更新・削除のこと）を用意した
- 求人票の公開ページを作った
- 記事生成の種類に「採用系の記事タイプ」を追加した
- 設定画面で集客モードと採用モードを切り替えられるようにした
ポイントは、記事を生成する心臓部分（エンジン）はそのまま使い回している点です。採用向けに変えたのは「記事のタイプ」と「出力先のページ」であって、AIが文章を書く仕組み自体は作り替えていません。
ここが「LP モード切替」という考え方の肝でした。1つのエンジンに対して、どのモードで動くかを設定で指定する。集客モードなら集客向けの記事と導線、採用モードなら求人票と採用ブログ、という具合です。
💡 ポイント： 新しい用途が出てきたとき、まず「エンジンは共通で、出す先や記事タイプだけ差し替えられないか」を疑ってみると、作り直しを避けられることがあります。
未経験なりに実感したのは、同じゴール（別商材を作る）でも、アプローチ次第で作業量がまるで違うということです。今回は追加実装で済みましたが、これはたまたまではなく、最初の設計がモードを足せる作りになっていたから、というのが大きいです。
求人票の構造化データ（JobPosting）で詰まったところ
採用モードで一番気を使ったのが、求人票ページに出す構造化データです。構造化データというのは、ページの内容を検索エンジンに分かりやすく伝えるための「印」のようなもので、今回は求人情報用の JobPosting という形式を使いました。
これをきちんと出すと、Googleの求人検索（求人情報がまとめて表示されるあの枠）に拾ってもらえる可能性が出てきます。採用LPとして価値を持たせるなら、ここは外せないと思いました。
ただ、構造化データは中身がいい加減だと逆効果になりかねません。必須項目が欠けているのに出してしまうと、検索側に正しく認識されないおそれがあります。そこで必須項目が揃っていない求人票では、構造化データをあえて出力しない仕様にしました。「出せるときだけ出す」という安全側の割り切りです。
⚠️ 注意： 構造化データは「とりあえず出せばいい」ものではありません。項目が欠けたまま出すとかえって信頼を下げる可能性があるので、必須項目のチェックとセットで考えるのが安心です。
正直、構造化データまわりは専門用語が多くて、最初は何が必須なのかを理解するのに時間がかかりました。ここはAIに「JobPostingの必須項目は何か」を質問しながら、少しずつ埋めていった部分です。
AIに書かせない判断と、採用モード専用の安全チェック
意外に思われるかもしれませんが、求人票そのものはAIに文章を生成させていません。登録されたデータを、テンプレート（決まった型）に流し込むだけにしました。
理由はシンプルで、求人票は給与や条件といった事実そのものが命だからです。ここをAIに自由に書かせると、登録していない数字が混ざるリスクがあります。採用ブログや紹介文はAIに任せても、求人票の中身だけは人が登録したデータだけを使う、という線引きをしました。
さらに採用モード専用の安全チェックも入れました。具体的にはこの2つです。
- 給与などの数値は、マスタ（あらかじめ登録した正しい値の一覧）に登録済みの値しか通さない。マスタにない数値が出たらブロックする
- 年齢や性別など、差別的と受け取られかねない求人表現の判定を別途入れる
採用の文章は、集客の文章よりもルールが厳しい世界です。書き方ひとつで問題になりかねないので、集客モードにはなかった専用のガードをわざわざ足しました。AIを使うからこそ、「AIに任せていい部分」と「任せてはいけない部分」をはっきり分けることが大事だと感じた場面です。
動作確認で分かったこと｜1本生成コストと既存機能の無事
作ったら必ず動かして確かめる、というのは未経験の自分が特に気をつけていることです。今回も採用モードで実際に記事を1本生成して、ちゃんと動くことを確認しました。このときのコストは $0.09 でした。1本あたりの実費としては、試しやすい範囲だと思います。
もう1つ、地味ですが大事な確認があります。採用モードを足したことで、既存の集客モードが壊れていないかどうかです。新しい機能を足すと、知らないうちに前からあった機能が動かなくなることがあります。今回は集客モードの既存動作が壊れていないことも確認できました。
💡 ポイント： 機能を足したら「新しい方が動くか」だけでなく「前からある方が壊れていないか」も必ず確認する。モードを増やすタイプの改造では特に効いてきます。
この「既存が無事」という確認が取れると、安心して採用モードを本番に出せます。逆にここを飛ばすと、せっかく売れていた集客商材のほうを巻き込んで事故らせる危険があるので、面倒でも省けない工程でした。
転用して得た結論｜「出す先」を変えると別商材になる
転用を進める前に、整理しておいて良かった前提があります。それは「求人票を自分のドメイン（自分のサイトの住所）に置いても意味がない」ということです。
Googleの求人検索で資産になるのは、あくまでクライアント（お客さん）のドメインに置かれた求人票です。自分のところに置いたままでは、お客さんの採用の役に立ちません。だから求人票は複製して、クライアントのドメインに納品する形が必須になる、と整理しました。この前提に気づかずに作っていたら、仕組みは動いても商材としては片手落ちになっていたと思います。
そして一番の結論はこれです。同じエンジンでも「出す先」を変えるだけで別商材になる。 今回は集客向けの記事エンジンを、採用LPと求人票という別の出口につないだだけで、新しい商材になりました。
ただし、これが作り直しではなく「モードの追加」で済むかどうかは、最初の設計でほぼ決まっていた、というのも正直な実感です。偶然うまくいったというより、分岐を足せる余地が最初にあったから成立した、という話です。この辺りの考え方は、私の他の制作記事とも地続きなので、興味があれば運営者紹介（/about）ものぞいてみてください。
まとめ
集客用に作っていたAI商材を、ゼロから作り直さずに採用向けへ転用できた記録でした。やったのは同じエンジンへの「採用モード」の追加で、求人票のデータベースと管理画面、公開ページ、採用系の記事タイプ、集客／採用のモード切替を実装しています。求人票はAIに書かせずデータをテンプレートに流し込む形にし、給与の数値チェックや差別表現の判定といった採用モード専用の安全策も用意しました。構造化データ（JobPosting）は必須項目が揃うときだけ出力し、求人票はクライアントのドメインに複製して納品する必要があるという前提も整理。1本の生成コストは$0.09、既存の集客モードが壊れていないことも確認済みです。得た結論は、同じエンジンでも出す先を変えれば別商材になること、そしてそれがモード追加で済むかは最初の設計で決まる、ということでした。
FAQ
よくある質問
Q採用モードを足すのに、全部作り直しましたか？
いいえ。記事を生成するエンジン自体はそのまま使い回し、求人票のデータベースと管理画面、公開ページ、採用系の記事タイプ、集客モードと採用モードを切り替える設定を追加しただけです。ただし、こうしたモード追加で済むかどうかは、最初の設計にモードを足せる余地があるかどうかに左右されます。
Q求人票はAIに書かせましたか？
書かせていません。求人票は登録したデータをテンプレートに流し込むだけにしました。給与などの事実が命なので、マスタに登録済みの値しか通さず、登録のない数値が出たらブロックする安全チェックも入れています。採用ブログなど説明系の文章はAIを使っています。
Q求人票の構造化データ（JobPosting）は必ず出した方がいいですか？
Googleの求人検索に拾ってもらう狙いがあるなら有効ですが、必須項目が欠けたまま出すのは避けた方が無難です。私の実装では、必須項目が揃っていない場合は構造化データを出力しない仕様にして、出せるときだけ出すようにしました。