dotsで人事の確認作業を減らせるか
人事の提出物確認、勤怠CSV、規程の問い合わせ。dotsに任せる作業を小さく分け、ExcelやPower Automateとどう組み合わせて試すかを考えます。
この記事でわかること
- 提出物から確認一覧を作る、小さな検証案
- 定型の照合と、備考・根拠の整理を分ける
- 架空データで見逃しと確認時間を比べる
提出物の不足を探す。勤怠CSVの確認箇所を拾う。問い合わせに答えるために規程を開く。人事の仕事でdotsを試すなら、担当者が判断する前の、こうした作業が候補になります。
ぼくが個人開発で使っているdotsを、人事業務へ持ち込むならどうするか。最初に決めたいのは、使うツールよりも任せる作業の範囲です。
最初の候補は、架空の提出物から確認一覧を作る作業です。Excelなどで処理できる照合は条件を固定し、dotsには備考の整理や確認理由の説明を試してもらいます。正式な台帳の更新や本人への連絡は、担当者が確認したあとに行う形を考えています。
dotsのどこを業務で試したいか
OpenAIの公開ヘルプでは、dotは会話の間にも作業を進め、接続したアプリなどを使って継続的な仕事に取り組むエージェントと説明されています。詳しい機能や利用条件は、実際に使うアカウントと環境での確認が必要です。
参照：OpenAI Help Center「Getting started with your dot」（2026年10月4日確認）
ぼくの個人開発では、コードの作成や修正、テストなどを頼んでいます。一方、Cloudflareへのログインは完了できず、初期設定では自分で操作する必要がありました。途中の作業を任せられる場面はあっても、接続や実行結果の確認まで省けるわけではありません。
人事で試したいのも、資料を見て確認箇所をまとめ、担当者に戻すところです。「人事の仕事を任せる」では範囲が広すぎるので、一つの入力から一つの成果物が出る単位に分けます。
最初は提出物の確認一覧に絞る
例として、架空の研修参加確認を使います。対象者一覧と回答一覧を用意し、担当者が確認したいものを別ファイルにまとめてもらう検証です。
IDを照合した未回答、IDの重複、必須項目の空欄は、条件を決めて機械的に抽出できます。ここはExcelの関数やPower Queryなどで処理する案を先に検討します。
参照：Microsoft Support「Merge queries (Power Query)」
dotsに試してもらいたいのは、備考の中にある日程変更の希望や、担当者への質問を拾い、その理由を示す作業です。出力には対象ID、元ファイル、該当箇所、確認理由を入れます。
状態は少なくとも「未提出」「内容の確認が必要」「読み取れず確認できない」を分けます。読み取れなかったファイルを未提出扱いにすると、提出済みの人へ誤った連絡をする原因になります。
最初の検証では元データを変更せず、メールも送らせません。一覧を人が確かめてから、必要な処理を進めます。
勤怠CSVと規程の問い合わせは範囲を分ける
勤怠CSVを対象にする場合は、出退勤の片方が空欄、IDと日付が重複している、といった確認条件を先に定義します。夜勤や休暇などの扱いも含め、何を確認するかを決めてから検証します。
条件に該当した行の抽出と、備考を読んで質問を整理する作業は分けます。出力は担当者が確認する候補として扱い、給与への反映や勤怠記録の修正までつなげません。実務で使える精度かどうかは、別に確かめる必要があります。
規程の問い合わせなら、利用を認められた資料から根拠を探し、回答案に文書名、改訂日、条項やページを添える使い方が候補です。資料が古い、適用範囲が分からない、根拠が見つからない場合は、そのまま未確認として戻してもらいます。
回答案は担当者が確認します。採用、評価、処遇の決定など、人への影響が大きい判断を、今回の小さな検証に混ぜないようにします。
ExcelやPower Automateとどう使い分けるか
既存の仕組みで条件を固定できる仕事は、そのまま使う案を残します。dotsを入れること自体を目的にすると、いま動いている処理まで作り直すことになります。
ExcelやPower Queryなどで検討すること
IDの照合、空欄や重複の抽出、決まった条件での集計。確認条件と期待する結果を明確にする作業です。
Power Automateなどで検討すること
組織で認められた接続先の間で、決まった条件に応じてファイルを保存したり通知したりする処理。実際の接続方法や権限を確認して設計します。
参照：Microsoft Learn「Microsoft SharePoint Connector in Power Automate」
dotsで検証すること
備考の内容を整理する、資料から確認候補を探す、担当者向けの説明や問い合わせ案を作ること。解釈を含む出力には根拠を付け、人が確かめます。
たとえば未提出者を探すだけなら、Excelで足りるかもしれません。備考の読み取りまで毎回必要なら、その部分にdotsを足す意味があるかを比べます。すべてをAIに通す必要はありません。
業務データを入れる前に決めること
検証には、まず実在する人と結びつかない架空データを使います。氏名だけを番号に置き換えても、部署や日付などから本人が分かる場合があるためです。
実データへ進む前には、少なくとも次を職場で確認します。
- 組織が認めた利用環境か、入力してよい情報は何か
- 閲覧できるファイルと、書き込める場所をどこまでにするか
- 入力と出力の保存先、保管期間、作業記録をどう扱うか
- 担当者の確認が必要な操作と、止まったときの連絡先は何か
- 誤った出力や更新があったとき、どう元の状態へ戻すか
指示文で制限を書くことに加え、接続先の権限も必要最小限にします。閲覧だけで足りる検証なら、正式な台帳への書き込み権限は持たせません。操作の記録や復旧の仕組みが、利用環境で実際に使えるかも確認します。
架空データで確認結果を比べる
初回は、対象者二十件ほどの小さな架空データから始める案です。これは動きを確かめるための例で、本番に必要な精度を示せる件数という意味ではありません。通常の回答に加えて、未提出、重複、必須項目の空欄、備考の変更希望、読み取れないファイルを用意します。期待する確認結果も先に作ります。
入力は「対象ID」「提出期限」を含む対象者一覧と、「対象ID」「回答日時」「参加日」「備考」を含む回答一覧のCSVにそろえる案です。結果の出力先は入力と分け、正式な台帳を上書きしないようにします。使う保存先とファイル形式が、実際の接続環境で扱えることも先に確認します。
そのうえで、次の順に試します。
- 対象データ、確認条件、出力する項目、実行しない操作を決める
- 元データを残し、確認一覧を別ファイルに出す
- 期待する結果と突き合わせ、見逃しと誤検出を数える
- 根拠が正しいか、確認できなかったものが報告されるかを見る
- 準備、確認、修正を含む時間を、手作業や既存のExcelと比べる
列の順番やファイル名が変わった場合も試します。一度動いたことだけで、本番に進める判断はしません。重要な見逃しや根拠のない説明が残る、確認の手間がかえって増える、といった場合は、対象を狭めるか既存の手順に戻します。
減らしたい確認を一つ選ぶ
試すなら、「何を見比べる仕事を減らしたいか」を一つ選びます。入力するもの、確認条件、人が受け取る一覧を決めれば、既存ツールだけで足りる部分と、AIに試してもらう部分が見えてきます。
提出物の確認が候補なら、「対象者一覧」と「回答一覧」の照合条件を書いてみてください。定型の照合だけで終わるなら、Excelなどで処理する案から。備考の読み取りや根拠探しも必要なら、架空データでdotsの出力と比べるところまで、範囲を絞って試せます。
もう少し詳しく考えたことは、noteに
提出物の確認一覧、勤怠CSV、規程の問い合わせについて、どこを任せてどこを人が確認するかをnoteにも書きました。
noteの記事dotsの人事業務利用を考えるnoteで読む