株式会社Global Career Incubator 代表取締役CEO 井川真一
最終更新:2026年10月29日。本文・参考資料は更新日時点の情報です。

「セキュリティ人材を一人採りたい」。採用枠が一つなら、その一人へ多くを期待したくなるでしょう。けれども、夜間のアラートを見る仕事、事故が起きたときに被害範囲を調べる仕事、社内のルールや責任分担を整える仕事は、同じ「セキュリティ」という言葉でまとめても、必要な経験が同じとは限りません。
人が足りず、現場の担当者が複数の役割を兼ねている会社ほど、「全部できる人」を探したくなる気持ちはよく分かります。採用人数を増やせない、経営側も技術側も時間がない、その中で事故だけは避けたい。だからこそ、求人票に知識や製品名を足す前に、今の会社で誰が何を担っており、次に採る人へどこからどこまで渡すのかを決めてください。
採用担当者は、監視、事故対応、統制を、仕事を切り分けるための観点として使ってください。National Institute of Standards and Technology〈NIST〉のNICE Workforce Framework for Cybersecurity〈NICE Framework〉でも、Work Roleは職名そのものではなく、個人またはチームが責任を持つ仕事のまとまりとして整理されています。[1] 一つの求人に複数のWork Roleが含まれることもあります。採用側が見るべきなのは、肩書きの一致より、候補者がどの仕事を、どの条件で、どこまで担ってきたかです。
「セキュリティ担当者を採る」では、面接で確かめる経験を決められない
最初に、採用担当者とセキュリティ責任者で、今ある仕事を三つの問いに分けてみてください。
| 見る仕事 | 採用側が先に整理する問い | 候補者に確かめる経験 |
|---|---|---|
| 監視・分析 | 何を誰が見て、どの状態を要対応と判断するのか。一次切り分け後、誰へ渡すのか。 | どの情報を見て、何を異常と判断し、誤検知や優先度をどう扱い、次の担当へ何を渡したか。 |
| 事故対応 | 誰がインシデントと宣言し、技術対応・事業判断・顧客連絡を誰が担うのか。 | 影響範囲をどう調べ、封じ込めや復旧の判断に何を使い、関係者とどう役割を分けたか。 |
| 統制・ガバナンス | どのリスク、規程、委託先、経営報告を誰が管理するのか。例外承認や方針変更を誰が決めるのか。 | リスクや要求事項をどう整理し、ルールや統制へ落とし、運用状況をどう確認し、未達を誰へ上げたか。 |
これはGlobal Career Incubator〈GCI〉が採用側の整理に使うために提案する「責任の受け渡し表」です。三分類に人を一人ずつ当てるための表ではありません。同じ候補者が複数を担えることもありますし、外部のSecurity Operations Center〈SOC〉、Managed Security Service Provider〈MSSP〉、情報システム部門、法務、経営が分担する会社もあります。
大切なのは、右端の経験を候補者へ聞く前に、左側の「自社では誰が担うのか」を決めることです。自社の分担が曖昧なまま面接すると、候補者が広く話せるほど高く評価しやすくなります。しかし、広く知っていることと、入社後に責任を持って任せられることは別です。
公的な職種資料でも、監視・事故対応・統制は同じ仕事として扱われていない
2026年10月28日に確認したNISTのWork Role紹介ページでは、Protection and Defenseの中に、Defensive CybersecurityとIncident Responseが別の仕事として示されています。前者は防御ツールから得たデータの分析によるリスク軽減、後者はネットワーク上のサイバーセキュリティ事故の調査・分析・対応を担う説明です。[2]
一方、Oversight and Governanceには、Cybersecurity Policy and Planning、Executive Cybersecurity Leadership、Security Control Assessment、Systems Security Managementなど、方針、管理、評価、責任を担う別のWork Roleがあります。[2] NIST Cybersecurity Framework〈CSF〉2.0も、Governを独立したFunctionとして置き、役割・責任・権限、方針、監督などを扱っています。[3]
ここから「監視担当、事故対応担当、統制担当を必ず別採用にすべきだ」と結論づける必要はありません。NICE Framework自体が、Work RoleとJob Titleを同じものとしていません。[1] むしろ採用側にとって重要なのは、一人にまとめる場合でも、仕事の種類と責任の境界を消さないことです。
たとえば、監視担当者がアラートを調べ、侵害の疑いを発見するところまでは担える。しかし、重大インシデントとして宣言し、業務停止を判断する権限は持たない。事故対応担当者が技術的な封じ込めを主導しても、顧客への説明や法的な通知要否は別の責任者が判断する。こうした境界があるなら、面接でもその境界を前提に経験を確認する必要があります。
公開求人と職務資料から、必要なセキュリティ経験を考える
同日に確認した、Amazon.jobs掲載のTwitch Interactiveの米国勤務Security Incident Response Engineer求人では、セキュリティイベントの経緯・影響・発見方法・対応状況を関係者へ伝えること、影響を受けるチームとインシデント対応を調整すること、手順を文書化し、学びを再発防止へつなげることなどが職務に含まれています。[4] これは、単に監視画面を見られるだけでは足りない仕事です。
自社が顧客向けの技術支援を任せたいなら、技術的な障害の整理、設計案の比較、顧客と専門担当の調整など、どの仕事が中心かを先に決めましょう。事故対応職と同じ肩書きや製品知識があっても、担う相手と判断は一致しません。自社の求人で何を任せるかに戻り、候補者の具体的な仕事を読んでいきましょう。
求人名に「Security」が付いていても、期待される仕事は違います。したがって、採用担当者は候補者の在籍企業や肩書きを見て「セキュリティ経験あり」と一括りにせず、その人が何を見つけ、何を判断し、誰へ渡し、何を変えたのかまで確認してください。
既存体制を先に書くと、採用する人の責任が見える
採用担当者と情報システム責任者は、過去半年から一年で実際に発生したセキュリティ関連の仕事を、個人名ではなく仕事単位で並べてください。事故がなかった場合も、アラート確認、脆弱性対応、アクセス権の棚卸し、委託先からの報告確認、経営会議への報告など、実際に行った仕事を使えます。
次に、それぞれについて四つだけ書きます。
- 開始条件:何が起きたら、その仕事を始めるのか。
- 担当範囲:今は誰が、どこまで実施しているのか。
- 受け渡し条件:何が分かったら、誰へ渡すのか。
- 判断権限:止める、例外を認める、外部へ説明するなど、誰が決めるのか。
この四つを埋めると、「セキュリティ人材が足りない」という話を、どの仕事が欠けているのかへ変えられます。
監視そのものは外部SOCが24時間担っていても、社内で通知を受けた後に優先度を決める人がいないかもしれません。技術担当者は事故対応をできても、事業部との復旧優先順位を決める役割が宙に浮いているかもしれません。統制文書は整っていても、例外が積み上がったときに是正を進める責任者がいないこともあります。
この状態で「SOC経験5年以上」「CISSP保有」などの条件だけを追加しても、仕事の穴は埋まりません。まず穴を仕事として定義し、その仕事を担った証拠を候補者から集める順序にしてください。
仮想ケース:一人目の専任セキュリティ担当に、どこまで任せるか
以下はGCIが作成した仮想例です。
従業員450名のBtoBソフトウェア企業があるとします。専任のセキュリティ担当はいません。情報システム部がアカウント管理や端末管理を行い、外部SOCがクラウドとエンドポイントの監視を24時間行っています。重大なアラートが出た場合は、SOCから情報システム部長へ連絡が届きます。
採用担当者が既存体制を確認すると、次の分担が分かりました。
- 外部SOCは監視と一次分析を行い、定めた条件で連絡します。
- 情報システム部の2名が、SOCから受けた内容を確認し、必要に応じて端末隔離やアカウント停止を実施します。
- 事業部のサービス停止を伴う対応は、情報システム部だけでは決められません。
- 顧客への事故連絡を誰が主導するかは案件ごとに決めており、恒常的な責任者は未整理です。
- 情報セキュリティ規程はありますが、例外申請の件数、未解消期間、是正責任者を一つの記録で追えていません。
- 年に一度、外部監査への対応があります。監査全体は管理部が取りまとめています。
経営側は「セキュリティ担当を一人採れば、SOC管理、事故対応、規程改訂、監査、社員教育まで任せたい」と考えています。
一見すると合理的に見えるかもしれません。専任者がいない会社では、散らばっている仕事を一人に集めたくなります。ただ、この要件のまま採用すると、候補者に期待する責任と、会社側に残す判断が混ざります。
改善前:求人票へ「幅広いセキュリティ経験」を足す
採用担当者が、次のように要件をまとめたとします。
セキュリティ全般をリードできる方を募集します。SOC運用、インシデント対応、セキュリティポリシー策定、監査対応、社員教育まで幅広く担当いただきます。複数領域の経験がある方を歓迎します。
この書き方では、会社が必要としている広さは伝わります。ただ、採用後に何を自分で判断できるのか、どの仕事は外部SOCや情報システム部と分担するのかが分かりません。
面接でも「SOC経験はありますか」「インシデント対応はできますか」「監査経験はありますか」と確認するだけになりやすく、候補者が「あります」と答えた後に、どこまで担ったのかを比較しにくくなります。
改善後:既存体制から「新しく持ってもらう責任」を切り出す
この会社なら、既存の監視と初動対応を継続し、社内の調査連携と例外・是正管理を新任者へ渡す案から検討します。外部SOCが担っている24時間監視を引き取り、監査全体まで任せる案よりも、会社側に残す判断と新たな責任を具体化しやすいためです。採用担当者は、次の分担案を情報システム部長と経営側へ持ち寄り、引き受けられる範囲を確かめてください。
監視については、24時間監視を外部SOCに残す案です。 新任者には、SOCから上がった事象の優先順位を社内で整理し、追加調査の要否と社内の連携先を判断する役割を置きます。新任者が不在でも連絡が届く経路を、情報システム部長と経営側が確認する必要があります。現在の部長への連絡は、その代替体制が動くと確かめてから切り替えます。
候補者には、「監視していましたか」ではなく、受け取ったアラートのどの情報を見て優先度を変えたか、誤検知や情報不足をどう扱ったか、次の担当へ何を渡したかを聞きます。
事故対応では、情報システム部との共同作業を前提にします。 新任者は調査と封じ込めの調整を進め、事業停止が必要なら、影響と選択肢を整理して会社の判断者へ上げます。情報システム部だけで停止を決められないという現在の条件は変えません。顧客通知の最終責任者も未整理なので、経営側が暫定責任者と代行経路を定めることを先に求めます。採用が決まるまで待つべき仕事ではありません。新任者へ渡すのは、会社が確定した連絡・承認体制の中での担当です。
統制については、すべての規程を作り直す仕事ではなく、例外と是正の管理から着手させます。 新任者が例外申請を記録し、期限と責任者を可視化し、長期未解消のものを情報システム部長や経営側へ上げる。そのうえで、規程改訂が必要かを関係部門と判断します。外部監査の取りまとめは管理部に残し、新任者はセキュリティ部分の証拠整理と是正状況の説明を担います。
同じ会社でも、ここまで書けば必要な候補者像はかなり変わります。「監視・対応・統制を全部一人でやった人」だけを探す必要はありません。たとえばSOCやComputer Security Incident Response Team〈CSIRT〉で、アラートの分析から社内調整まで担った人が、統制の運用を学べる余地があるかもしれません。逆に、統制や監査の経験が豊富でも、今回すぐに任せたい事故時の技術的な判断経験が乏しければ、その不足を誰が補うのかを会社側で決める必要があります。
ただし、優先順位の整理、調査の調整、例外・是正管理を一人へ渡せるかは、まだ決まっていません。情報システム責任者は、普段の通知量と調査に使う時間、事故対応中に止められない統制業務、管理部が支援できる時間を持ち寄ってください。監査の準備と事故対応が重なったときに分担できなければ、入社時の担当を絞るか、既存部門・外部支援へ仕事を残す必要があります。
未経験の統制業務を「入社後に覚えてもらう」とする場合も、教える人、使える手順、実案件の判断を確認する相手を具体化しましょう。名前だけの支援者では、現場も本人も困ります。担当者が時間を確保して引き受けた範囲から、入社後に補える条件を求人へ書いてください。
候補者の経歴は、次の担当へ何を渡したかまで聞く
経歴書に「SOC運用」「インシデント対応」「情報セキュリティマネジメントシステム〈ISMS〉の運用対応」「監査対応」と並んでいても、同じ深さの経験とは限りません。採用担当者は、候補者が担った一件を聞き、本人が決めたことと、他の人へ渡したことをたどってください。
監視・分析なら、一次判定から先へ上げた一件を聞く
「SOCで監視していました」という説明には、「情報が足りず、上位の担当へ上げた一件を教えてください」と尋ねます。本人が見た情報、追加で調べた情報、優先度を変えた理由、次の担当へ渡した内容まで聞けば、画面を見る仕事と、判断に必要な材料を揃える仕事を分けられます。
誤検知として処理した事象なら、そう判断した根拠と、誰が判断を承認したかも確かめましょう。本人が検知ルールの変更を提案したという場合は、まず案がどこまで進んだかを聞きます。提案まで、レビューまで、承認まで、実装まででは、確認できる経験が違うからです。採用担当者が記録し、技術担当者には判断根拠の妥当性を確認してもらってください。
事故対応なら、被害の大きさより本人の判断範囲を聞く
「ランサムウェア対応を経験しました」と聞いたら、「最初に分かっていたことと、ご自身が調査して分かったことを分けてください」と尋ねてみましょう。端末隔離、アカウント停止、サービス停止を誰が決め、本人はその判断者へ何を示したのかまで追います。事業部、法務、広報、経営と共有した内容も、本人が担当した範囲で聞いてください。
復旧後に対策を変えたという説明には、誰が変更を承認し、誰が実施し、本人は実施されたことを何で確かめたかを尋ねます。重大事故に参加したことと、全体を指揮したことを分けるためです。調査や情報整理に大きく貢献した人を、決裁権がなかったという理由で低く扱う必要はありません。今回任せる調査・連携の仕事に、その経験を使えるかを見ましょう。
統制なら、例外を記録した後に誰が動いたかを聞く
「ISMSや監査対応をしていました」という説明には、扱った要求事項と、一件の未達・例外を取り上げてもらいます。資料を集めたのか、リスクを評価したのか、是正を提案したのか。採用担当者は、その違いを本人の行動として書き分けてください。
「例外を一覧にしました」で止まったら、誰へ報告し、是正するか受け入れるかを誰が決め、その後の期限と責任者をどう追ったかを聞きます。一覧を作った貢献は残しつつ、是正が実行されたことまで確認できたかを確かめるためです。事故対応が豊富でも、この運用経験まで自動的に備わるとは置かず、別の一件から根拠を集めましょう。
面接の前後で、採用担当と技術担当の仕事を分ける
採用担当者だけで技術的な深さを判定しようとすると、製品名や資格の多さへ評価が寄りやすくなります。反対に、技術担当者へ面接を丸ごと任せると、自社で任せる責任との照合が抜けることがあります。
面接前に、採用担当者は次の三点を技術担当者へ渡してください。
- 今回のポジションで、入社後すぐに本人判断を求める仕事
- 既存メンバーや外部ベンダーと共同で担う仕事
- 技術的に確認してほしい候補者の経験
技術担当者には、「セキュリティの知識が十分か」だけではなく、候補者が説明した判断の妥当性を、具体的な場面で確認してもらいます。
たとえば監視なら、提示された情報から何を追加で調べるか。事故対応なら、封じ込めを急ぐことで失う情報や業務影響をどう扱うか。統制なら、技術上のリスクを誰が受け入れられるのかをどう整理するか。実際の自社環境をそのまま試験問題にする必要はありませんが、今回任せる仕事に近い判断を確かめることはできます。
ただし、構成・手順・対応の「唯一の正解」を作って判定しないでください。環境、権限、事業影響、利用できる情報が変われば、妥当な判断も変わります。候補者が置いた前提、確認した不足情報、選んだ行動、その理由を見てください。
SOC内の経験を、事業会社で任せる責任へ照らす
同じ会社の面接で、候補者は次の経験を説明しました。採用担当者は前職の資料を確認していません。
- MSSPのSOCで3年間勤務し、アラートの一次分析とエスカレーションを担当した。
- 重大度の高い事象では、勤務先MSSP内のCSIRTへ追加情報を渡した。
- 一件の侵害対応では、端末ログの確認と対象端末の特定を担当した。
- 端末隔離の最終判断は顧客側の責任者が行った。
- その後、検知条件の変更案を作り、チーム内レビューを受けた。
- 規程策定、監査取りまとめ、リスク受容の決裁経験はない。
この記録を、次のように要約してしまうと、会社の期待が本人の経験へ入り込みます。
SOC経験が3年あり、インシデント対応も経験しているため、セキュリティ全般を任せられる候補者。統制経験は不足しているが、入社後にキャッチアップ可能と考える。
採用担当者がまず残したいのは、どの会社の、どの役割で働いたかです。この候補者が説明したのは、MSSPのSOC内で一次分析を行い、同じ勤務先のCSIRTへ情報を渡した経験です。今回の仕事では、事業会社側で委託先SOCから情報を受け、自社の事業影響と結びつけて判断します。情報を集めて引き継ぐ経験には接点がありますが、判断する立場まで同じだったとは言えません。
採用担当者は、この違いを候補者へ説明し、「顧客側の判断者へ直接説明した場面はありますか。その人が判断するために、何を追加で確かめましたか」と尋ねましょう。経験があればその一件を聞き、なければ、今回の会社の分担を示した職務課題で、現在の考え方を確かめる方法があります。技術担当者が課題で観察した判断を、過去の事業会社での実績へ変えないことが大切です。
検知条件の変更案についても、最初に聞くのは実装後の成果ではありません。「どの情報を根拠に案を作り、レビューで何を指摘され、その後どこまで進みましたか」と問いましょう。承認されたか、実装されたか、誰が実装したかは、現在の記録にはありません。
回答が案の見直しまでなら、比較とレビュー対応の経験として評価します。承認・実装まで進んだと説明された場合に、承認者と実装担当を確認し、変更前後の確認内容、本人が把握した結果を続けて聞きます。実装されたという答えだけで、本人が実装も効果測定も担ったことにはしません。この順序なら、提案した貢献を残しながら、次の工程の担当を正確に確かめられます。
採用会議へは、次のように渡せます。
一次分析と勤務先MSSP内のCSIRTへの情報提供、端末ログ確認・対象端末の特定を担ったと説明している。端末隔離の決裁者は顧客側である。検知条件は変更案の作成とレビューまでを聞いており、承認・実装・結果確認は追加で確かめる。
当社が任せる、委託先SOCからの情報を自社の事業判断へつなぐ仕事は、顧客側との調整経験と職務課題の判断を分けて確認する。統制運用については、例外・是正管理を教える人と、共同で判断する範囲を会社側で決めてから、本人へ担当条件を説明する。
技術面接で今回必要な調査・連携の判断を確認でき、管理部や情報システム部が統制運用の支援を具体的に引き受けられるなら、担当範囲を限定して選考を進める理由になります。技術判断が不足し、支援する人もいなければ、「経験領域が広そうだ」という印象で進めてはいけません。会社が即時に任せる仕事と、本人が既にできる仕事の隔たりを扱う必要があります。
統制だけが不足する場合も、監査全体を管理部に残し、例外管理を共同で始められるかを確かめてください。支援者が業務時間を確保できないなら、統制部分を入社後に補えるという結論は出せません。会社の支援が未決定なのに、候補者の学習意欲だけで解消したことにしないでください。
採用担当者には、確認を候補者の弱点探しに使わず、経験を必要な役割へ結びつけるために使っていただきたいと思います。SOC内で判断材料を揃えてきた仕事には、その貢献があります。その強みを受け止めたうえで、事業会社側の責任を渡すために何が要るかを、会社も引き受けていきましょう。
採用を急ぐときほど、「今ない仕事」まで一人へ渡さない
専任者がいない会社では、新しい人が入ると、その人の知識に合わせて仕事が集まりやすくなります。これは自然なことですが、採用時点で意図していなかった責任まで増えると、候補者にも会社にも負荷がかかります。
特に、重大事故時の意思決定、顧客や当局への連絡、法的判断、リスク受容などは、採用する専門職だけに預ければ済むとは限りません。経営、法務、事業責任者などが引き受ける判断を、会社側で決める必要があります。技術に詳しいという理由だけで、組織としてリスクを受け入れる権限まで任せたことにはなりません。経営側が、決める人と範囲を明らかにしましょう。
採用要件を作ったら、最後に「この人が休んでいるとき、誰が判断するか」を聞いてみてください。ここで答えがなくなる仕事は、採用で解消する人手不足だけではなく、会社側の責任設計の課題を含んでいます。
また、現在の担当者が兼務でセキュリティを支えてきた会社では、その努力を「専任ではないから不十分」と切り捨てないでください。今まで誰が、どの連絡や判断を引き受けてきたのかを記録することが、新任者へ仕事を渡す土台になります。専任者の採用は、既存メンバーの貢献を消すことではなく、曖昧だった責任を持続可能な形へ変える機会にしてください。
通常時の分担を書いたら、新任者が不在の夜で確かめる
求人票を公開済みでも、採用担当者、情報システム責任者、経営側で要件を見直せます。直近の仕事を一件選び、開始条件、現在の担当、判断者、次へ渡す情報を書き出しましょう。その中から、新任者へ移す範囲を選びます。候補者に尋ねるのは、その仕事で本人が直接見た情報、本人と他者が決めたこと、判断後に渡したものです。
450名の会社の例なら、重大な夜間アラートを使って分担案を確かめられます。通常時は、外部SOCが条件に沿って通知し、新任者が追加調査と社内連携を整理し、情報システム部の2名と技術対応を進める案です。サービス停止が必要なときの判断者と、顧客連絡の責任者は、経営側が確定する項目として残します。
次に、新任者が不在であるという条件だけを変え、同じ一件の受け渡しを書き直してください。現在の情報システム部長への連絡経路を残す案なら、部長が受信して誰へ調査を依頼するか、事業停止の判断が必要になったら誰へ上げるかまでつなぎます。部長の名前を書くだけで終えず、本人がその時間帯に引き受けられるかと、不在時の代行者を経営側が確認します。
書き直した記録のどこで連絡が止まるでしょうか。受信者がいなければ、連絡経路と対応時間の確保が先です。情報システム部の2名へ渡せても、二人とも別の事故対応で手が空かなければ、対応の優先順位を決める人と追加支援が要ります。調査はできても事業停止を決める人がいなければ、経営側の権限設計が残っています。いずれも、新任者の候補者へさらに広い経験を求めるだけでは埋まりません。
通常時と不在時の二つの記録を、実際に担当する人へ渡し、引受けと対応時間を確認してください。採用担当者は、引受けが確認できた範囲を求人と面接の説明へ反映します。確保できなかった箇所は、会社側の担当を補うか、新任者へ渡す範囲を絞るかを経営側に決めてもらいましょう。
事故対応に時間を取られた日に、例外・是正管理と監査準備を誰が進めるかも合わせて見ます。通常時の仕事量だけで一人にまとめられると決めず、重なる仕事まで確かめてください。技術的な判断は専門担当に任せながら、採用担当者は、その判断を実行できる会社の条件を揃える。この役割を果たすことで、「一人いれば安心」という期待を、本人へ説明できる責任に変えられます。
「全部できる人」を探す前に、会社の分担を見直したいときは
監視は外部へ任せているが、その後の社内判断が弱い。事故対応はできるが、統制や経営報告が一人に集中している。逆に、規程や監査は整っていても、インシデント時に技術側を動かす人がいない。こうした状態では、求人票の条件だけを増やしても、必要な人材像は明確になりません。
GCIのTalent Search|人材紹介では、任せる役割と候補者の経験に加え、ご本人が望む仕事と働く条件を確かめ、双方が選考で確認する事項を整理します。[5] セキュリティ人材の採用でも、現在の分担と、会社側に残す判断を共有可能な範囲でお聞かせください。GCIは、その条件で探す経験と、選考で明らかにする事項を貴社と具体化します。
社内で分担が決まらないまま、採用担当者だけが求人を書き直しているなら、その判断の違いからご相談ください。監視、事故対応、統制のうち、今回の採用で補う責任を絞れれば、候補者にも任せる理由と支援条件を伝えられます。そこまで具体化して、探索を進めましょう。
参考資料
- NIST, Occupations, Jobs, and Work Roles, 2026年10月28日確認。
- NIST, NICE Framework Work Role Videos, ページ内のWork Role説明文を2026年10月28日確認。動画は未視聴。
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, 2024年2月26日公表。Governの説明と役割・責任・権限、方針、監督の項目を2026年10月28日確認。
- Amazon.jobs(募集企業:Twitch Interactive、勤務地:米国), Security Incident Response Engineer, Security Posture Improvement and Resilience Engineering, 2026年10月28日確認。
- 株式会社Global Career Incubator, Talent Search|人材紹介, 2026年10月28日確認。
