採用広報の記事を1本書くのに、インタビューから公開まで10時間以上。少人数の人事にとって、その時間を捻出すること自体が難しくなっていないでしょうか。
株式会社ブリングアウトの杉開様は、一人HRとして採用広報を立ち上げました。Claude Codeに「インタビューしてきたから、記事を作って」と伝えるだけで、10分後にドラフトが上がる仕組みを作り、1本あたりの作業は10〜12時間から3〜3.5時間に収まっています。
ただし杉様が繰り返し強調したのは、自動化の華やかさではありません。AIは素材を調理する優れたシェフであり、素材を集めるインタビュー設計は人が担う という線引きと、人のチェックは一生残るという前提でした。
2026年9月30日に開催したOffersウェビナーの内容を、ディスカッションと質疑応答も含めてお届けします。
1本10時間の採用広報記事を、3時間に収めるまで 杉様：株式会社ブリングアウトという40名程度のAIスタートアップで、VP of Recruitingとしてリクルーティングをやっております。新卒でPR会社のベクトルに入り、その後はNPO法人en-courageを運営するRECCOOに5年ほど在籍しました。
さらにフォースタートアップスで、スタートアップ企業の採用支援を3年ほど担当しています。ブリングアウトはその時に出会った一社で、2年ほど外側から採用を支援した後、昨年8月に入社しました。
当時は営業のメンバーが採用を兼務している状態だったので、私がそこを巻き取る形で、一人HRとして動いています。オペレーションを担う業務委託の方が1名いる、2名体制です。
ブリングアウトは、商談や社内会議などの会話音声を非構造化データ化し、コンテキストとして扱えるプラットフォームにしていく自社プロダクトを持つ会社です。
ただ、プロダクトを使っていただくというよりは、コンサルタントが入る事業でして。経営変革の論点を整理した上で、テーラーメイドのプロダクトを乗せて提供しています。
なかなか伝わりづらい事業なので、広報がすごく大事だなと。エージェント時代にこの会社の説明が難しかったという原体験もあって、入社してすぐにnoteアカウントを作り、採用広報を始めました。
採用については、この1年で15人ほど入社し、来年は30人ほど採用したいと考えています。ターゲットはコンサルファーム出身のシニアなメンバーと、シニアなエンジニアが中心です。専門性の高い方向けにどういった広報をやっていくかが、この1年の重要テーマ でした。
「インタビューしてきたから、記事を作って」で10分後にドラフトが出る 杉様：1本の記事をnoteで書き出すのに、私は10時間から12時間ほどかかっていて、それが重たい工数になっていました。今はClaude Codeを使いながらだと3時間ぐらいに収まります。インタビューして、少し作業したらすぐ出せる状態です。
まずデモからです。実際のClaude Codeの画面を収録した動画で、今回はCTOとEMの2名の対談を作ろうと、1時間のインタビューをZoomで行いました。Claudeに「インタビュー終わったから記事にしといて」というプロンプトを投げると、10分後には記事が出てきます。
裏側ではスキルというものが動いていて、記事作成の進行役、ライター、記事を読んでフィードバックする編集長など、いくつかのエージェントが共同作業で記事作成を進めてくれます。AIっぽい文章になるのを避けるように修正してくれる内容も、スキルの中に入っているものです。
一回ゲラが出てきたものに対して、編集長とペルソナの読者、ファクト検証のエージェントがレビューし、それを元に修正が行われます。フィードバックを挟んで修正されたものが私に上がってくるのが、10分後ぐらいでしょうか。
ほぼ問題ない状態で出てくるので、私が一回目を通し、インタビューした2人に「こんな感じで問題ないですか」とそのまま渡してフィードバックをもらい、また修正する。それが今、私が実際に記事を作るときの工程です。
進行役・ライター・編集長。記事づくりを分担するスキルの中身 杉様：プロンプトとしては本当に楽をしたいので、「インタビューしたよ」と伝えたら、ファクトチェックなども行われた状態で記事が出てくる。そんな状態を目指して作ってきました。
裏側では、まずインタビューの書き起こしデータを読み込みます。テキストで渡しても、ファイルを読み取らせてもいいです。
次に記事の企画書。向こう3ヶ月のクォーターでどんな記事を作るかを、採用の計画や、すでにnoteに発信されている記事で足りていないものは何かを分析してもらい、Claudeとディスカッションして作ったものです。
さらに、記事作成手順書にあたるスキル、「ブリングアウトのnoteっぽい記事とはこういうもの」というルール、そして関連記事を読み込みます。
例えば現場のエンジニアの記事を一緒に出す予定なら、2本を同時に出したときにお互いいい相互関係になっているかを確認するため、関連記事も読み込んでくれるわけです。これらを踏まえて、一回ゲラを作ります。
三者視点レビュー：編集長・想定読者・ファクト検証 杉様：そのゲラに対して、三者視点レビュースキルというものを作っています。1つ目が編集長スキルです。Forbesの編集長ならこの記事にどうフィードバックするか、NewsPicksの編集長ならどうか、といったことをClaudeとディスカッションしました。
そうやって「ブリングアウトのnoteの編集長はこういう観点を大事にしている人だ」という人格を作り、それがずっとフィードバックし続けてくれます。
2つ目が想定読者です。今回ならCTOやEMなど、AI時代の開発組織を作ろうとしている人がメインターゲットだと企画書に書かれています。その人格のペルソナを作り、実際にそういう人が読んだらどう感じるかをフィードバックしてくれるものです。
3つ目がファクト検証です。修正が入り、修正された記事ドラフトが私に出てくる、という裏側でした。
スキルは「AI向けの業務マニュアル」 杉様：スキルとは、AIに渡すAI向けの業務マニュアルだと捉えていただけるといいかなと思います。記事作成の進行役、いわばPMのスキルには、企画準備があって取材があり、記事を作成してレビューが入って公開に至る、という流れ全体が書かれています。
それをいかに効率的に進めるか、AIエージェントの誰に指示をするかを取りまとめてくれる進行役がいて、「記事作っといて」というプロンプトには、まず彼が第一に反応してくれる。そんなイメージですね。
ライターのスキルには、文章の書き方や記事の構成のイメージ、口調の整え方が入っています。なるべく本人のキャラクターは残した上で、ノイズになる口調はこう直しましょう、といったルールです。
このスキル自体は私が書いたわけではなく、「こういう記事にしたい」とClaudeに話しながら、Claudeが作ってくれたもの になります。
最後に文面調整スキルがあります。AIはダッシュや点々をよく使ったり、長ったらしい言い回しをしてきたりするので、そういうことを全部やめてくれという禁止や要注意の項目を入れました。都度足していったりもしています。
お手本を渡し、会話でルールにしていく 杉様：最初から全部整っていたわけではなく、細かく一個ずつ作っていきました。当初は自分で手書きで記事を書いていたので、まずは自分で書いた記事を渡して「レビューして」と頼むところからです。
「想定読者の視点でレビューしてみて」「Forbesの編集長だったらどうレビューするか教えて」とやりながら、私が求めるレビューのあり方をディスカッションしていく。「いいね」と思えたら「今回それマニュアルにして」とスキル化を依頼する。そんなプロセスでした。
途中で、都度確認が入るのは手間だと感じたので、Claudeに記事作成の前後の全体像を整理してもらいました。AI化できるものとできないものを分け、緑で塗られた工程は基本的に全部AIで自動化できるものだったので、「この緑はもう全部自動化していきましょう、頼んだ」とまた依頼したわけです。
地味に楽なのは、例えばカレンダーと連携できているので、この人にインタビューしようと決めたら、60分空いている予定を勝手に押さえてくれることです。カレンダーのメモ欄に取材背景まで残しておいてくれます。徹底的に自分の作業をなくしていった結果が、冒頭のデモの状態でした。
理想のワークフローができたら、逆算して自動化する 杉様：理想のワークフローができたら、そこから逆算して自動化を進めていく形です。最初は「この全工程表の緑の部分を自動化したいので、まず日程調整と取材相手の申し送りをつないでおいて」と一個ずつ頼んでいました。
書き起こし素材もずっとコピペで渡していたのですが、「コピペすら面倒なので、もう自分で取ってきて」と直していきます。後半はもう「まだ自動化できていないやつは一旦全部やっておいて、わからないところは私に聞いて」という指示で進めました。
結果として業務がみるみる自動化され、今は全工程が3時間から3.5時間ほどに収まる体制です。人事の方は日々忙しく、3時間すら取るのが大変でなかなか記事作成が進まないでしょう。
私も3.5時間になったからといって、めちゃくちゃ記事を出せるかというとそんなこともないのですが、だいぶ楽にはなったという感覚です。
Tips1：お手本を渡すのが、求めるクオリティに一番近づく 杉様：Claude Codeで何かアウトプットを出したいとき、記事に限らず、お手本を渡すのが一番いい と思っています。NewsPicksの記事っぽく自社の記事を作ってみたい、あの会社の採用広報の記事っぽくやってみたい、というイメージがあるなら、それをClaudeに渡す。
「こんな感じで作りたい」と伝えるだけで、結構それっぽくなります。プロの方がやられているものには全然及びませんが、なんとなく方向性はつかんでくれるものです。
そこから、なぜその記事をお手本にしたいと思ったのかを抽象化して言語化させ、すり合わせながらルール化し、スキルにしていく。このプロセスから入るのが一番楽でしょう。
一個一個、自分でいい記事の要件を言語化してClaudeに伝えていくのは至難の技です。基本的にはお手本を渡してから修正する形をおすすめします。
AIは優れたシェフ。素材集めは人が担う 杉様：2つ目のTipsとして、インタビュー設計は自分で時間をかけてやった方がいいと考えています。どういった記事にするか、どんなタイトルになりそうか、そのためにどんな質問をするか、という事前準備の部分です。
今のAIが得意なのは素材を調理することで、優れたシェフのようなものでしょう。一方で、インタビューから何を聞き出せたかという記事の素材は、AIが自分で作り出せるものではないし、作らせない方がいいものです。
この素材集めこそが、自分が一番力を入れてやるべき仕事 だと考えています。AI任せにすると、意図していない方向性の記事になってしまうことも普通に起こるものです。
ゆえに、たたきは作ってもらいます。記事の書き筋や出口の仮説、あり得るタイトルや骨子を出してもらい、そのための質問リストも一度すべて出してもらう。ただ、それはしっかり自分で確認してフィードバックし、納得のいくものになってからインタビューに臨むようにしています。
これがちゃんとできていると、インタビュー自体が綺麗にストーリーになるので、ほぼ書き起こしのままでも記事になるものです。後の修正があまり入らず、すごく楽ですね。
逆にここで手を抜くと、情報が足りない、質問と質問のブリッジングが必要でもう一度取材しなければ、となって相手の時間も取ってしまいます。だからここには一番時間をかけているのです。
Tips3：サムネイルもお手本を渡す 杉様：3つ目は、noteなどでサムネイル画像を作る場面です。私はデザイナーの経験が全くなく、Canvaで作っていましたが、最近はChatGPTで作った方がそれっぽくなると思い、試し始めています。ここはClaudeよりChatGPTの方が向いているという感覚です。
誤解のないように先に申し上げると、パクりは良くないので、その線引きやポリシーは今回は割愛します。その上で、記事と同様にサムネイルもお手本を渡した方がいいと考えていまして。参考にする画像を渡して「これを参考に9パターンぐらいテンプレートを作ってみて」と頼めば、パッと出てきます。
そこに「今回の想定読者はこんな人だから、こんな雰囲気にしたい」と加えていくと、どんどんオリジナリティになっていくでしょう。パクってそのまま使うのは良くないと思って気をつけています。
応用編：悪魔の代弁者ブリーフと、毎朝の採用ブリーフ 杉様：記事作成に限らず、いろいろなことの自動化をやっています。ポイントは、アウトプットのイメージに対してマニュアルをAIに作ってもらい、マニュアルをすり合わせ、アウトプットを確認していくこと。これで結構いろいろなことができます。
1つ目の事例が「悪魔の代弁者ブリーフ」です。最終面接にステータスが変更された方がいたら、自動的に作成されます。最終面接に進むということは、高評価で何かしらがいいと思って進んでいるわけですよね。
そこに面接官のバイアスが入っていないかを洗い出しながら、この人に本当にオファーしていいのかを、最終面接官向けにブリーフィングする資料です。
性格がいい人たちが面接官に立ち続けると、いいところばかり見てしまいます。そこで意図的にAIに客観的な立場を取らせ、「すごい成果を出したと言っているけれど、なぜ成果が出たのかという実際の行動は、まだちゃんと聞けていないよね」といった論点を、面接の書き起こしなどから出してもらっているのです。
毎朝7時、その日にやるべき採用アクションがSlackに届く 杉様：もう1つの事例が、毎朝、その日にアクションを取らなければいけないタスクが全部整理されて届く仕組みです。お見せしているのは全部ダミーデータですが、「昨日誰の面接があって、この人は評価が入っていない」と確認したりするのがすごく大変でした。
明日の面接の人の申し送りができているかを確認して作成し、渡すのにも時間がかかっていて、これを全部自動化できないかと思って書き始めた取り組みです。
デリバリーはSlackで、その日にアップデートがあった動きと、明日の面接官向けの申し送り資料が流れてきます。あとは内容を目視で確認し、問題なければそのまま面接官に渡す運用ですね。
内容が安定してきたら、ATSに直接申し送りが投稿される運用にしたいと考えています。そうなると、数時間かけていた毎朝の仕事がまるっとなくなるイメージです。こういったものも、記事作成でのClaude Codeの使い方を応用するだけでできるので、おすすめでございます。
AIっぽさを消し、自社らしさを出すには ――岡田：ここからはディスカッションです。1つ目のテーマは「AIが書いた採用広報記事のAIっぽさを消し、自社らしく仕上げるには」です。ドラフトの後に編集長・読者・ファクト検証のレビューを回すというお話がありましたが、自動で直せる部分と、人が見ないと直せない部分の切り分けはどうなっているのでしょうか。
杉様：前提として、最後はやっぱり人がチェックした方がいい と思っています。新しいモデルが出てきたら試すようにしていますが、モデルが変わるとアウトプットも変わるので、そのたびにチェックが必要です。
コンテキストウィンドウがいっぱいになると変な挙動をすることもあるので、人のチェックは一生残るという気がしていますね。
その上で、やれる限りのことをやる中で2つのアプローチを取っています。1つは、Xなどで定期的に、AIっぽい文章を防ぐことに成功したプロンプトを共有してくれている人たちがいるので、いいものを見つけたらClaudeに渡して試すこと。実際に良くなったかをチェックして修正します。
それでも都度気になるところは出てきますし、自分がずっと書いていると気づかなくなってくるものです。そこで他のメンバーに「AIっぽいところない？」と聞いて、それをまたClaudeに伝え、マニュアルに反映してもらうことをやっています。
想定読者のペルソナは、採用要件と企画書から毎回作られる ――岡田：質問も来ています。「三者視点レビューの想定読者のペルソナはどう作っていますか。採用ターゲットごとに複数用意されているのでしょうか」というものです。
杉様：都度私が作成しているわけではなく、Claudeが判断して作ってくれます。前提情報として渡しているのは、自分たちの採用ポジションと採用ターゲットの要件、JDそのものです。ハイアリングマネージャーと話して出てきた議論のメモも渡しました。
なのでClaudeは、ブリングアウトがどういう人を採用したいかをある程度わかってくれています。そこに、記事の企画書に書かれた「今回は誰をターゲットにするか」を掛け合わせ、「こういう人がペルソナだよね」というものをガーッと作ってくれて、毎回それが想定読者としてアサインされる流れです。
均質化は、書き起こしで差をつける ――岡田：読者を先に決めて、その人の目で読ませていくということですね。もう1つ、自社らしさをどう出すかは非常に大事だと思っています。私自身もAIでコンテンツ作成をしていくと、どうしても均質化する、どの会社の記事も同じような顔になってしまうのではないかと感じます。
――岡田：らしさの元は書き起こしのデータや社員さんの言葉だと思うのですが、何が一番のキーになっているのでしょうか。同じフォーマットで書いていって、均質化してしまったと感じたことはありますか。
杉様：均質化に関しては、書き起こしで差をつけるのが一番 だと思っています。自社のメンバーにしか聞けないことを、いかにインタビューで聞けているか。
それさえあれば、質問と回答の会話調にするのか、一人語り形式にするのか、フォーマットは最適なものを選べばいい。だからこそ、インタビューの事前設計に一番時間をかけるべきだと思っているわけです。
スキルが肥大化したら、Claudeに「最適化しておいて」と頼む ――岡田：先ほどの文面調整のスキルが48行ほどあるように見えました。私もスキルが大きくなるとアウトプットの制御が効かなくなる問題を常日頃感じていて、Anthropicの公式ガイドでもスキル本文は500行以内と書かれていたかと思います。
――岡田：私自身、半分以上削った経験があるのですが、杉様は継ぎ足すだけでなく、減らすという意思決定もされていますか。
杉様：マイナスも定期的にします。ただ、自分でスキルを目視で見に行って削ることはほとんどやっていません。MDファイル自体が増えてきた、一つひとつの中身が大きくなってきた、というときに、全部Claudeに「最適化しておいて」と指示する形で対処しています。
スキル自体が増えていくことについては、スキルがどういうワークフローの中でつながっているかを意識して、合体させるか、複数のスキルを扱うためのスキルを1つ作っておくのがいいでしょう。先ほどお見せした進行役スキルがまさにそれです。
記事作成にどんなスキルがあるかは彼が把握しているので、「記事作っといて」と言えば、どのスキルをどの順番で使うかを判断して動かしてくれます。
オペレーション系などミスが許されないものは、スキルの中身を丁寧に見ておいた方がいいと思います。ただ記事作成は、裏側のスキルが多少ミスっていようが、最終的なアウトプットを自分で見て問題なければ問題ないので、そこまで厳密にやらなくていい領域ではないでしょうか。
最終面接は見極めに使い切り、アトラクトは別の場で ――岡田：2つ目のテーマは「アトラクトに寄りがちな最終面接で、見極めを漏らさないためには」です。人はいいところを探して選考を進めてしまうというお話がありましたが、悪魔の代弁者ブリーフを入れてから、最終面接で見極めに使う時間とアトラクトに使う時間の割合は変わりましたか。
杉様：ブリングアウトの場合、最終面接は60分の中で、見極めに60分かけなければいけないなら60分全部を見極めに使ってもらっています。アトラクト自体は、最終面接の場でなくてもできる からです。
見極めてオファーすると決まってから座談会を組む、会食にお誘いする、最終面接前にアトラクトが必要そうなら先に段階を組んでおく。面接では見極めを絶対に漏らさず、納得いくまでやり切っていただく設計にしました。
ただ、社長が最終面接に出る場合は、社長にしか話せないことは話してもらうよう申し送りしています。全面接の申し送りを今はAIで作っていますが、そこに書くのは見極めのポイントだけではありません。
前回までの面接で話した内容、転職活動の軸や聞き出した価値観に仮説をぶつけて、「次はこういうポイントでアトラクトしに行くといいかもしれない」という示唆も申し送りに載るようにしています。それを面接官に見てもらい、うまくやっていただく体制です。
面接官にはどう受け止められたか ――岡田：「実際、面接官の方にどう受け止められましたか。面接の中身はどれくらい変わったのでしょうか」という質問も来ています。率直なところ、いかがでしたか。
杉様：「悪魔の」という名前は少し物騒ですが、社内的には好評です。最終面接官は基本忙しいので、これまでの面談のサマリーを全部読めるかというと難しく、サマリーにすると情報が薄くなって漏らしてしまうこともあります。
これまでの面接での対話の経緯を確実に把握し、「だったらここを見極めなければいけない」という最終面接官としてのロールを演じ切るのは難しい仕事でしょう。少しでもそのサポートになればと思ってやっていて、そういった観点で好評をいただいています。
少人数の人事は、事故らない領域から始める ――岡田：3つ目のテーマは「少人数の人事部門は、何からAIに着手すべきか」です。先ほどのスライドでは20工程のうち8つが完全自動になっていたかと思います。2人体制の中で、一番最初にスキルにした工程はどれで、なぜ選んだのでしょうか。
杉様：一人人事でまだAIによる業務効率化が進んでいない段階なら、基本的には好きなところ、やりたいと思ったところからやればいいと思っています。逆に触らない方がいいのは、候補者とのオペレーションのところです。
理由は2つあります。1つは、オペレーションは事故ると良くないからです。正しくスキル設定がされていない段階で、ある候補者の情報を間違って処理してしまったとき、そのチェックが機能として備わっていないと気づけない。なるべく事故らないところからやった方がいいでしょう。
採用広報の記事作成は、最終的にどうせ人がチェックしますし、頻度もそれほど多くないので、AIが思い通りに動かなくても修正できます。AIがうまく回らなくてもマイナスはなく、100点でなくても少しうまくできれば助かる領域から始める のがいいと思います。
そうしてAIを扱う経験値が上がれば、本丸のオペレーションを変えるときに気をつけるべきことも見えてくるはずです。
ATSのAPIと、セキュリティチームとの対話が前提になる 杉様：もう1つはツール環境の話です。社内規定で個人情報をどう扱ってよいか、ATSがAPIを開放しているかで状況は全く違います。一人HRでここから変えていくなら、取りかかるべきことは2つです。
1つ目は、セキュリティチームと本当にずっと話し続けること。「こういうことがやりたい、それはやっていいのか、やっていい状態にするには何を整えなければいけないのか」を徹底的に話し、環境的にガードレールが引かれてから、実際に情報の扱いを進める。このプロセスを踏まないといけないと思っています。
2つ目は、API対応されているATSに切り替えるか、現在使っているATSのAPI開放のスケジュールを確認することです。採用のオペレーションは本丸で、非常に時間がかかっているので自動化のインパクトは大きい。
ただ、ATSとClaude Codeが連携していないと、毎回ATSの情報をコピペして渡すことになります。
それは情報管理のリスクがありますし、AIに情報を渡す仕事が増えるだけで、自動化したつもりが仕事が1つ増えて変わらない、ということにもなりかねません。オペレーションはATSのAPI前提で作るべきで、まずはAPIを使える状態を目指すのがいいと思います。
質疑応答 ライティングスキルの観点は、どう蓄積されたか ――岡田：ライティングスキルの指示の観点はどのように蓄積されたのですか。
杉様：ライターさんとおしゃべりしているのとあまり変わらないことを、テキストでやっています。ただ、メモリー化しておかないと、コンテキストウィンドウの圧縮のタイミングで消えてしまうので、「これはマニュアル、スキルに反映しておいてね」と都度伝える。会話ベースでずっとやっている形ですね。
――岡田：作成した編集長には、構成の面でどのようなことを常時チェックさせているのですか。
杉様：編集長の一番大きな役割は、読者の心理的な変遷を捉えてもらうことです。「タイトルを読んだときは多分こういう頭の中になるはずなのに、リード文がこうなっているのはおかしい」といった読者ジャーニーが中心ですね。
他にも「この言い回しはこってりしすぎている」とか、文章としての美しさがあるかも見てくれています。
インタビュー設計とタイトルは、なぜ人が持ち続けるのか ――岡田：インタビュー設計でAIに質問項目の叩き台を出させた後、どのくらい人間側で調整していますか。かける時間や意識していることを教えてください。
杉様：時間は20分ぐらいだと思います。AIは「こういう情報を把握しているから、こういう質問設計をした」という情報源を持っていますが、こういう記事を作りたいとなったとき、AIより私の方に情報が入っている部分があるものです。結局、何がずれているかというと、インプットに使っている情報の違いですね。
なので私は、とにかくそこをひねり出します。先週の開発採用の定例でCTOからこういう話を聞いたから、こっちに踏み込まないといけない。ビジネスチームの事業状況にこういうアップデートがあって記事に盛り込みたいから、この方向の話を聞けるように組まなければいけない。
AIにまだ渡していないコンテキストをもとに内容を作っていく のが、一番やっている部分だと思います。
――岡田：記事生成の工程のうち、タイトルを人が決める工程として残したのはなぜですか。
杉様：タイトルもできれば自動化したいのですが、しっくりくるものが出てくる状態にまだ整えられていません。試行錯誤したものの、「ちょっと違うな」というタイトルになりがちで、結局自分で考える時間がかかっているという認識です。うまいやり方があれば、むしろ教えていただきたいポイントですね。
記事の企画書には、ターゲットや目的の他に何を書いているか ――岡田：記事の企画書にはターゲットや目的の他にどんな項目を書いていますか。AIの仕上がりに特に効いた項目があれば知りたいです。
杉様：企画書は大きく2つあり、1つがクォーターの計画を作る企画書です。これは大まかにしか書いていません。我々の場合、スカウトを送るときに必ず社内のnote記事を貼るようにしていて、そのポジションで送りたい人に読んでもらいたいベストな記事がないと思ったときに記事を作るのが最優先になります。
なのでペルソナを明確にした上で、その人に届けたい記事はこうだよね、と整理し、それを3ヶ月でどういう順番で作るかをスケジュール化したものが企画書です。その段階でペルソナのすり合わせがされています。
このペルソナのすり合わせが、なんだかんだ一番大事 ではないでしょうか。質問設計にも、インタビュー素材をどう調理するかにも反映されるからです。
記事はどう届け、効果はどう検証しているか ――岡田：作成された記事はどのようにターゲットに届けていますか。デリバリーにもAIを活用していますか。また、効果検証はどのように行っていますか。
杉様：デリバリーには全然使っていません。効果検証については、我々のフェーズではPV数がすごく大事だとはあまり思っていなくて。スカウトのタイミングで渡すもの、エージェントさんに「この人にはこの記事を渡してほしい」と頼むもののラインナップが、ある程度最適化されて整っているかを重視しています。
直接お渡しするために記事を作っているのが今の段階です。なので、面接やカジュアル面談のタイミングで「見ていただいたものはありますか」という確認は必ずしています。バズればいい、拡散されればいいとは思いますが、偶然性もあるので優先順位としては後回しですね。
PRチームがない体制で、サムネイルと採用PRをどうするか ――岡田：サムネイルなどはPRチームとも確認を取られているのでしょうか。
杉様：うちにはまだPRチームがなく、プレスリリースも社長と私で書いたりしているので、PRチームの確認ができない体制です。採用チームの権限としてサムネイルは決めていいことになっていますが、社長には結構相談しますね。
「これダサいですか」「ちょっとうちのイメージと違うんじゃない」「そうですよね、直します」といったやり取りをしています。
――岡田：PR担当を今後採用する予定はありますか。それともAIと仕事した方が楽なのでしょうか。採用コストとAIの利用コストの天秤も気になります。
杉様：今40人ぐらいですが、100人になるぐらいまでは、採用PRという意味での専任は少なくとも取らないですね。noteの記事を出すぐらいなら自分でやってしまえ、というところがあるので。
ただ、会社全体のブランディングや、それを踏まえた採用ブランディングは、AIに正解を出させられるものとは全然違うケーパビリティだと思っています。そちらに重きが置かれるタイミングはあり得ますし、外部のアドバイザリーでいいという話もあるかもしれません。
取材相手からの修正依頼と、言葉のニュアンスの扱い ――岡田：取材相手の本人確認で返ってくる修正依頼は、AIで書くようになってから増えましたか、減りましたか。
杉様：減っています。ただ、インタビュー素材をどれだけうまく取れたかに依存するものです。インタビュー設計がうまくできておらず、その場で考えながら出した質問が綺麗なストーリーになっていないと、急に話題が変わって記事として変になるので、間を埋める文章をこちらで作ることになります。
それが多いときほどフィードバックは来やすい。ただ、精度は上がってきているので、「このままでいいんじゃないですか」というパターンが最近は多いのが嬉しいところですね。
――岡田：文字起こしデータだと拾いきれない、取材対象の言葉のニュアンスはご自身の確認の時にチェックされていますか。スキルに組み込んでいるならどう組み込んでいますか。
杉様：本人が話さなかった行間を読め、という意味なら、スキルにそれを読ませる指示は入れていないと思います。AIはモデルの性能以上の行間読みはやっていないのではないでしょうか。やった方がいいのかもしれないと思ったので、考えてみます。
一方で、文字起こしデータがそもそも本人たちの話した言葉のままになっていない、という課題なら話は別です。一旦汚くてもいいから完全に書き起こせるツールを使い、それを自分の指示したスキルでクレンジングしてノイズをなくし、綺麗な素材にしてもらう。
そうすれば、話してもらったニュアンスは少なくとも全部残る形にできると思います。
ネタ出しはどうしているか。ネタがないと困ることはないか ――岡田：どんな記事を書くかのネタ出しはどのようにされていますか。ネタがないと困ることはありませんか。
杉様：全然あります。ただ今は、どちらかというと供給体制の方に課題があり、最初にブレストしたものをまだ消化しきれていない状況です。もう一度ブレストし直すとき、専門性が出てきたときにネタがない問題は起こりうるでしょう。
ただ、やり方は結構あります。例えば、note発信にすごく力を入れている会社のnoteのURLをClaudeに渡して、「うちの記事のラインナップと比較して、こんな記事も足したらいいというアイデアを100本出して」とやったことがありまして。
100本のうち18本ぐらいは「これは確かにいい、記事化したい」となって、今リストに入れた状態です。ネタ出しにもClaudeを使うのはすごくいいですし、ネタ出しでもお手本を渡すのがいいと思います。
なぜClaude Codeを選んだのか ――岡田：最後に、様々なAIツールがある中で、Claude Codeを選ばれた背景はありますか。
杉様：私が選んだわけではありませんが、会社としては春ぐらいから全社員がClaude Codeを使っています。スキル前提で動くように作られていて、業務効率の部分でそれがすごく便利だとわかっていたためです。
採用界隈でもAI活用をすごくやられている方は、Claude Codeを使われている方が多い印象ですね。
補足すると、会社から「野生のClaude Code」のように社員に使わせるのではなく、できること・できないことを会社側で決めたルール内でしか使えないClaude Codeとして配られています。
例えばSlackと連携するとき、このチャンネルはアクセスできるが、非公開情報の多いチャンネルは絶対アクセスできないようにする。カレンダーは日程調整できるが、メールはまだ見られないようにする。
許可することとしないことを全社で統一して整備し、その環境下でみんなが仕事できるようにする上でも、Claude Codeはちょうどよかったのだと思います。
おわりに ――岡田：お時間も近づいてまいりましたので、最後に一言いただければと思います。
杉様：AI化、自動化すると仕事がすごく楽になりますし、自動化する仕事自体がすごく楽しくて、没頭してしまいます。皆でAIを使ったら絶対に良くなると思っているので、一緒に作っていけたら嬉しいです。今日はありがとうございました。
