採用の候補者管理、スプレッドシートで頑張っていませんか。応募者やスカウト対象が増えるほど煩雑になるのに、専用のツールを入れるほどでもない。社内にエンジニアはいても忙しく、自分の採用業務のために手を借りるのは頼みづらい。そんな板挟みのなかで、Claude Codeを触りはじめた人事担当の方も多いはずです。
株式会社プロリクの橋崎です。これまで、「【実践Claude Code】Google広告の操作をClaude Codeで自動化してみた——構築の全記録と6つの落とし穴」や「【実践Claude Code】Facebook（Meta）広告をClaude Codeで自動化した話」、「【実践Claude Code】Claude Codeで喋る端末を作ってみた」など、Claude Codeで多数の開発記録を記事にしてきました。それらに続き、今回は、自社で使う採用管理システムを、Claude Codeで自作した記録を記事にしたいと考えています。ねらいは、エンジニアに頼らず、いま会社で使っているGoogle Workspaceの中に、自分で採用管理ツールを作ることです。実装のコードはClaude Codeが書くので、作ったのはGAS（Google Apps Script：Google Workspaceの中で動かせるプログラム）とスプレッドシートの組み合わせです。同じ立場の人事担当の方が、そのまま真似できる形で残します。
AHRとは？
AHR（AI and Human Resources）とは、企業の経営課題に向き合う組織能力を充足させるため、AI資源と人的資源を経営資源として設計・運用・再配分する、株式会社プロリクが2025年6月に提唱した実践フレームです。従来のHRが人的資源のみを扱ったのに対し、AHRはAIを人と並ぶ「経営のコア資源」と捉え、組織能力獲得を目指す考え方です。AHRは、株式会社プロリクの登録商標です。
📄 詳細記事: 【決定版】AHRとは？-人とAIの働き方をリデザインする
この記事の要点（TL;DR）
- エンジニアには頼みづらい、でも有料ATSを入れるほどでもない。そんな人事担当者（非エンジニア）が、Claude Codeを学びながら採用管理システムを自作した記録
- 作ったのはGAS＋スプレッドシート。いま会社で使っているGoogle Workspaceの中で完結するので、新しいSaaSを増やさず、データも社内のGoogle環境から出ない。個人情報の安全対策もGoogle（Workspace）側に任せられる
- いきなり「作って」ではなく、手書きの仕様 → ChatGPTで整理 → Claude Codeで要件定義 → 基本・詳細設計 → ロードマップ、と積み上げた。設計はClaude CodeだけでなくChatGPT・Geminiも併用
- 権限に注意。「スプレッドシート」の権限はそのアカウントの全シートに及ぶので、採用管理専用のアカウントで動かし、触れる範囲を1枚に閉じる
有料ATSが基本。でも、その手前で困る会社が多い
先に、正直な前提を書きます。採用管理のデータは、氏名・連絡先・経歴といった個人情報そのものです。しかも候補者が増えるほどデータ量が増え、管理も煩雑となります。こうしたデータを安全に、安定して扱うなら、本来はセキュリティも運用も作り込まれた有料のATS（採用管理システム）を使うのが基本だと考えています。
有料のATS（採用管理システム）については別記事でも整理しておりますので、よろしければご覧ください。別記事：ATSとは？業界別に選ぶ採用管理システム比較ガイド2026｜IT・医療介護・建設
ただ、有料ATSは月額数万円から数十万円かかります。採用の規模がそれほど大きくない会社では、費用に見合わず、導入を決めにくいのが実情かと思います。
有料のATSを導入しない場合、多くの会社はまずスプレッドシートで管理していると思います。しかし、やってみると分かりますが、スプレッドシートでの採用管理は、正直かなり煩雑です。媒体ごとに候補者が発生するのでその候補者の手入力登録、候補者ごとの進捗、面接の日程、評価のメモと、列も行も増え続け、更新も追いつかなくなります。
そこで今話題のClaude Codeを使ってATSを作ってみた、というのが今回の記事の主題です。
有料ATSは規模に見合わない、でもスプレッドシートは煩雑。その中間を埋めるのが、Claude Codeでの自作です。今回はそれを実際に試しました。
採用管理という仕組みを社内に入れる上でそもそもどういう選択肢があるか
以下の表に、有料の採用管理ツール、スプレッドシート管理、Claude CodeでのATSといった選択肢を並べ、各々の観点で評価を記載してみました。Claude Codeでの自作する場合もいくつかパターン分けができますが、今回は「GAS＋スプレッドシート」と「専用のWebアプリ（自前のデータベース）」の2通りに分けて掲載をしています。
観点 | 有料ATS | スプレッドシート管理 | 自作：GAS＋スプレッドシート | 自作：専用Webアプリ（自前DB） |
費用 | 別途、月数万〜数十万円 | 追加費用なし（既存Workspace内） | 追加費用なし（既存Workspace内＋AIの利用分のみ） | サーバー・DBの費用がかかる（Workspaceの外＋AI利用分） |
始めやすさ | 契約・初期設定が必要 | すぐ始められる | 作る手間はかかる（設計が要る） | 作る手間＋環境構築（非エンジニアには荷が重い） |
個人情報の安全対策 | 提供元が作り込み済み | 自社のWorkspace内に収まる（管理はGoogle／Workspace側） | 自社のWorkspace内に収まる（管理はGoogle／Workspace側） | 自分で設定する必要（非エンジニアには難所・ミスで外部から読める危険） |
候補者情報の入力（媒体からの取り込み） | 媒体と自動連携して取り込める | 各媒体から1件ずつ手作業でコピペ（最も手間） | 貼り付けるだけでAIが構造化して自動入力 | 同じくAIで構造化して自動入力 |
画面・UIの自社最適化 | 汎用SaaSのため自社専用に変えにくい | 画面はなく、列・行が増えると集計が崩れやすい | 自社に合わせて作れる | いちばん自由に作り込める |
AIによる書類選考 | 製品次第（対応は限定的なことも） | なし（手作業） | 自分で組み込める（下書きとして） | 自分で組み込める（下書きとして） |
向いている人 | 採用規模が大きい会社 | ごく小規模・立ち上げ初期 | エンジニアに頼らず自分で作りたい人事担当（非エンジニア） | 作り込みたい・エンジニアに頼める人 |
表を順に読み解いてみます。
有料ATS（採用管理システム＝候補者情報と選考の進み具合を一元管理する仕組み）は、セキュリティも運用も作り込まれていて、いちばん安心して使えます。ただし月に数万〜数十万円かかり、採用規模がそれほど大きくない会社には費用が見合いません。しかも汎用のSaaSなので、自社の選考に合わせて画面を変える、といった融通は利きにくいのが弱点です。
一方で、スプレッドシート管理は、いますぐ追加費用なしで始められて手軽です。しかし先にも触れたように、候補者が増えるほど非常に煩雑ですし、とくに媒体からの候補者情報は1件ずつ手でコピペするしかなく、ここが日々いちばんの手間になりますね。
次に、今回のテーマであるClaude CodeによるATSの自作についてです。詳細は後述しますが、Google Apps Scriptと、スプレッドシートを使った形での開発を1つの選択肢として提示しています。データはいまのスプレッドシートのまま、入力や一覧の画面だけをClaude Codeで作る形です。追加のSaaS費用はかからず（AIの利用分のみ）、データも会社のGoogle Workspaceの中に収まりますので、新しくデータの置き場所を設けず、社内セキュリティとして許容しやすいものだと思います。媒体のテキストを貼ればAIが構造化して入れてくれるので、コピペの手間も消えます。エンジニアに頼らず、人事担当が自分の手で始められる形ですね。一方で、Googleの基盤で開発することになるので、通常のWebサービスと違って、やや処理速度が遅かったり、リッチなものが作りにくい、というデメリットがあります。
最後に、自前のデータベースで専用Webアプリとして開発する形です。まさに有料のSaaS型のATSを社内で開発してしまう、というようなイメージですね。GASで開発するのと違い、自由にATSを作り込むことができます。しかし、専用のデータベースやサーバーが必要で、非エンジニア人事がClaude Codeで単独開発するにはやや荷が重いものです。特に、個人情報の塊を扱うATSというサービスを、セキュリティ知識がない非エンジニアが作るのは、リスクが高い行為だと言えます。
ATSをClaude CodeでGoogle Workspaceの中に作ってみる
上の表のとおり、Claude Codeでの自作の方法として、一旦2通り提示しました。いま使っているスプレッドシートをそのままデータの置き場所にする「GAS＋スプレッドシート」と、専用のデータベースを用意する「専用のWebアプリ（自前のデータベース）」です。
今回私は、GASの方でATSを作ってみました。理由は主にセキュリティ観点です。
非エンジニアの自分が、いちばん危ない「個人情報の安全設定」を自分で触らずに済むからです。先に述べたように、データベース含めて自前で開発を進める場合、どうしてもセキュリティリスクが強く発生します。一方で、GAS＋スプレッドシートであれば、データはGoogle Workspace内で完結し、ログイン認証も会社のGoogle Workspaceが担うため、設定ミスによって個人情報を外部から見られる、という一番怖い事故がそもそも起きにくくなっているためです。
（なお、私自身は別途、専用のデータベースを用いたWebアプリ版も作りました。自由に作り込めるため快適でしたが、結局セキュリティ観点から破棄することにしました。）
開発のステップ
採用管理システムは、広告の自動化や喋る端末より一段大きい仕組みです。いきなりClaude Codeに「ATSを作って」と言っても、なかなかまともなものは出てきません。実際にやったのは、思いつきから実装までを、AIと一緒に何段か積み上げる進め方でした。段ごとに使うAIを変えています。順に説明します。
① 手書きの企画メモを書く
最初にやったのは、「こういう採用管理がほしい」を、自分の頭のまま文章で書き出すことです。候補者の管理、採用計画（何名を採るために、どの経路で、どうKPIを積むか）、AIでの書類選考、応募経路ごとのファネル分析——ほしい機能を思いつく順に並べ、それぞれに「絶対に要る／あると嬉しい」といった機能の優先度を付けます。
コツは2つあります。1つは、整えようとしないこと。きれいな仕様にしようとすると手が止まるので、箇条書きの殴り書きで構いません。もう1つは、迷っている点を"質問のまま"メモに書き込むことです。私の実際のメモには、候補者の状態を「合格・不合格・辞退・タレントプール・連絡が滞っている…」とざっと並べた横に、「これをMECE（もれなく・だぶりなく）に整理したい」とAIへの相談を含んだ内容をメモしています。連絡の記録方法についても「この仕組みでいいのか？ 他に手はないか？」と、答えを出さずに疑問だけ残しています。
粗々でもいいので考えていることの取っ掛かりを作成し、AIに投げる準備を整える、というフェーズですね。
② ChatGPTで壁打ち——殴り書きを"仕様"に変える
次に、その生メモをChatGPTと壁打ちしました。並べただけのメモには、抜け（考え忘れ）と矛盾（両立しない要望）が必ずあります。ChatGPTは、ばらばらの機能をグループにまとめ直し、「ここはどうする？」と穴を突いてくれます。
このとき効いたのが、①で書き残した"質問"です。「状態をMECEにしたい」と投げれば、分け方の候補を出して一緒に詰めてくれる。さらに、自分では言葉にできていなかった設計の前提まで引き出してくれました。たとえば「使う人はITに詳しくない」という前提を置くとすると、「操作を増やさない」「細かすぎる状態を作らない」「アクセス管理は自分で作らずGoogle側に依存させる」といったアイデアをAIは出してくれます。
ここではまだ、コードの話は一切しません。目的は、殴り書きを「他人に説明できる仕様」にまで引き上げることです。この段を飛ばして実装に入ると、システムそのものが場当たり的で過度に煩雑なものになってしまいます。
③ Claude Codeでダブルチェックをかける——実務のデータにあわせる
Claude Codeとも仕様の議論を継続しました。実務のデータが弊社には多数残っているので、それをコンテキストデータとして把握させ、ChatGPTと議論した仕様と実務に乖離がないかを修正したかったからです。
Claude Codeは様々なファイル形式でも柔軟に内容を理解し、咀嚼し、一般化する能力に長けています。ChatGPTとの議論で実務から離れていた部分を、適切に修正してくれました。
④ 再度ChatGPTに戻って基本設計・詳細設計を実施
要件（何を・なぜ）が固まったら、次は「どう作るか」です。ここもChatGPTの方が視野が広く、正確で、網羅的な検討が可能な能力を持っているため、ChatGPTに依頼しました。基本設計として、全体の骨組み——どんなデータを、どのシートに、どんな画面で持つか——を決めます。次に詳細設計で、その中身を具体化する。スプレッドシートの列を一つひとつ定義し、処理の流れを追い、AIに渡すプロンプトの文面まで書き下ろしてくれました。
ファイルは.md形式で書き出してもらい、Claude Codeに読み込ませやすい形にしています。
⑤ ロードマップはClaude Codeに作り、順序立てて開発する素地を作る
次に、基本設計・詳細設計ができたら、それをClaude Codeに読み込ませ、「どの機能を、どの順番で実装するか」の開発ロードマップを作ってもらいました。Claude Codeでの開発では、途中でクラッシュしたり、日をまたいだり、セッション内のやりとりが溜まりすぎたりするため、新しいセッションで再開することが多くあります.。
その意味で、いつセッションが途切れてもすぐに現在地が分かり、すぐ開発ができることは開発効率につながりますので、ロードマップはその接点の役割を担ってくれます。
設計はClaude Code一本で進めない——ChatGPT・Geminiも併用する
ここまで読んで気づいたと思いますが、設計はClaude Codeだけで進めていません。 ChatGPTおよび、Geminiからも第三者としての意見をもらいながら進めています。
とくに効くのは、同じ問いを別のAIに投げることです。片方が良しとした設計を、もう片方が「ここが抜けている」と拾うことがある。人にレビューを頼むのと同じで、視点が増えるほど設計は堅くなります。「Claude Codeで作る」とはいえ、実装の手前の"考える"工程では、複数のAIを行き来していました。
ここまでが、コードを書き始める前の話です。繰り返しになりますが、コード実装はClaude Codeが難なく実施してくれますが、最初にこの積み上げをしっかりするかどうかは品質に大きく関わる点だと感じます。
⑥ Claude Codeで実装
設計とロードマップができれば、あとは順に実装するだけ——とはいえ、実際に詰まった点もいくつかありました。いちばん時間を溶かしたのは"版ズレ"です。特に今回はGASの開発をしているので、開発と画面確認、再度修正のサイクルを回すためのプロセスが通常とは違います。このプロセスを効率的に行えるまでにやや無駄な時間を過ごしてしまいました。
実装を進めると、Claude Codeからのアウトプットとしては、.gasのコードや、.htmlが吐き出されるわけですが、それらをGASの編集画面に貼りつけ、デプロイし、公開された画面を見るというプロセスだとやや時間がかかります。本番用のURLを毎回「新しいバージョンとしてデプロイ」し、その待ち時間は、直すたびに積み重なります。
非常に初歩的な誤りではあるのですが、デプロイの画面には、本番用のURL（末尾が /exec）のほかに、テスト用のURL（末尾が /dev）があります。/dev は、デプロイしたバージョンではなく、いま編集画面に保存されているコードをそのまま動かします。 デプロイが要りません。これを使うことで、より修正プロセスが効率化されました。Claude Codeが書いたコードを編集画面に貼る、保存する、/dev のタブをリロードする。それだけで、デプロイの操作も待ち時間も消え、直した結果がその場で画面に出て確認が効率化されました。
私のように、あまりにGASに慣れていない方はこういった細かい点の非効率なプロセスも発生するかと思いますので、ご参考いただければ幸いです。
権限の話
作るうえで、最初に決めておきたいこと、かつ重要な論点が権限です。このアプリは「スプレッドシートを読み書きする」権限を使いますが、ここに一つ落とし穴があります。この権限は、アプリが使うその1枚だけではなく、そのアカウントが見られるスプレッドシート全体に及びます。つまり、普段使いのアカウントでそのまま動かすと、他の社内シートにもアプリが触れられる状態になる。採用データを扱う道具としては、見過ごせません。
対策はシンプルです。採用管理専用のアカウントを1つ立てて、そのアカウントとしてアプリを動かす。 そのアカウントには採用管理のスプレッドシートだけを置き、他のシートは共有しない。こうすれば、権限が広くても、アプリが実際に触れられるのはその1枚だけになります。
Workspaceを使っているなら、さらにきれいにできます。専用のユーザーを1人作ってアプリの実行者にし、利用は組織メンバーに共有する。すると、使う人は各自の会社アカウントでログインしたまま（＝誰が操作したかも残せる）、アプリがデータに触れる範囲は専用アカウントの1枚に閉じる、という形が両立します。
非エンジニアでも作れた
社内にエンジニアはいません。それでも、採用管理の仕組みが形になりました。進め方は、これまでの記事と同じ3つです。
- 最初に「何を作るか」をひととおり相談してから、コードに入る
- 小さく作って、動かして、次に進む。最初から評価も日程も全部、と詰め込まない
- エラーが出たら、そのままClaude Codeに貼る
採用の規模が大きくなって、有料ATSの費用に見合うようになったら、そのとき有料へ移ればいいと思います。自作は、その手前の「有料ATSは規模に見合わない、でもスプレッドシートは煩雑」という段階に合った選択肢です。同じ自前管理でも、スプレッドシートより自社に合い、しかも安全に始められます。
まとめ
採用管理システムのように大きいものでも、やり方はこれまでと変わりませんでした。いきなり「作って」と言うのではなく、手書きの仕様からAIと一緒に、要件・設計・ロードマップへと積み上げる。難しいのはコードではなく、自社の採用を言葉にすることの方でした。
エンジニアに頼らず自社用に始めるなら、いま会社で使っているGoogle Workspaceの中で、GAS＋スプレッドシートから。動かすのは採用管理専用のアカウントにして、触れる範囲を絞る。自社に合うATSがないと感じている方は、まず自社の選考の段階を紙に書き出し、Claude Codeに相談してみてください。
弊社お問い合わせ窓口
株式会社プロリクでは、生成AI導入・実装・運用支援サービス「MIRAIGEN（ミライジェン）」を提供しています。本記事のような採用に関わるClaude Code開発など、ご興味おありの企業がいれば、お気軽にご相談ください。
著者について
橋崎 良哉（株式会社プロリク ）
Webサイト制作事業にて在学中に起業。家業に入り、鉄鋼加工会社で取締役として業績回復を牽引。その後グローバルに特化したデジタルマーケティング支援会社にてマーケター、データ解析などを担当した後、AIスタートアップであるエッジテクノロジー株式会社の取締役COOとして、機械学習実装支援や、機械学習を用いた営業自動化SaaSを立ち上げ、6年で0から社員70名程度までグロースさせる。2020年2月株式会社プロリクを設立。
よくある質問（FAQ）
Q. ATS（採用管理システム）とは何ですか？ A. 候補者の情報と、その人が選考のどの段階にいるかを一元管理する仕組みです。書類選考中・一次面接・内定といった進み具合を、候補者ごとに追いかけられます。
Q. エンジニアでなくても採用管理システムを自作できますか？ A. Claude CodeのようなAIコーディングツールを使えば、実装はAIに任せられます。ただし「自社の選考の段階や選択肢をどう決めるか」「AIの判定をどこで自分が確認するか」は自分で決める必要があります。難しいのはコードよりも、この設計です。
Q. GASと専用Webアプリ（自前データベース）、非エンジニアはどちらで作るべきですか？ A. 非エンジニアが自社用に始めるなら、GAS（Google Apps Script）＋スプレッドシートをおすすめします。データがGoogleの中にとどまり、ログインもアクセス管理もGoogleが行うため、設定ミスで個人情報を外部から見られる状態にしてしまう事故が起きにくいからです。専用データベースは自由度が高い反面、安全対策を自分で設定する必要があります。
Q. GASで作ると、どんな権限が必要ですか？注意点は？ A. このアプリは「スプレッドシートの読み書き」と「外部への通信（AIのAPIを呼ぶ）」の権限を使います。注意したいのは、スプレッドシートの権限が、そのシート1枚ではなく、そのアカウントが見られるスプレッドシート全体に及ぶことです。普段使いのアカウントで動かすと他の社内シートにも触れられるため、採用管理専用のアカウント（Workspaceなら専用ユーザーを1人立て、利用は組織メンバーに共有）を用意し、そのアカウントとしてアプリを動かすのが安全です。
Q. 候補者の個人情報はどう扱えばいいですか？ A. GAS＋スプレッドシートなら、データはGoogleの中にあり、安全対策は実質Googleに任せられます。自前のデータベースを使う場合は、データを入れる前に、外部から直接読めないよう設定することが必須です。作った直後は誰でも読める状態になっていることが多いので、必ず確認してください。
Q. AIに書類選考をどこまで任せていいですか？ A. 下書きまでにとどめるのが安全です。AIに経歴と募集要件を渡せば「合格・不合格・要確認」と根拠を返せますが、AIは間違えます。判定を合否に自動反映せず、画面で確認してから人がボタンひとつで反映する、要確認のときは自動で状態を動かさない、という設計にしておくと、速さと安全を両立できます。
Q. 採用媒体からの候補者入力もAIにできますか？ A. できます。媒体からコピーしたテキストを貼り付けると、AIが氏名・電話・メールを抜いてフォームに反映する、という作り方が現実的です。コツは、欲張って全項目を構造化しようとしないこと。抜くのは確実に欲しい数点だけにし、読み取れない項目は空にして埋めさせない（会員番号やニックネームを氏名に拾わせない）。原文はそのまま経歴として残します。
Q. 自作と有料ATSの契約は、どちらが良いですか？ A. 採用の規模が大きく、費用に見合うなら、セキュリティも運用も作り込まれた有料ATSが基本です。規模がそれほど大きくなく、有料に踏み切れない段階の会社にとって、自作は現実的な選択肢になります。
Q. スプレッドシート管理と比べて何が良いのですか？ A. スプレッドシートは、候補者ごとの進捗・日程・評価が増えるほど煩雑になり、更新も追いつかなくなります。GASで画面を作れば、データはスプレッドシートのまま、入力や一覧を使いやすくでき、AIに書類選考の下書きまでさせられるので、同じ自前管理でも手間が大きく減ります。