SmartHRをAIエージェントに操作させる前に｜労務データのアクセス制御

SmartHRをAIエージェントにつなげば、従業員名簿の整合チェックや、入退社手続きの下書き作成、人事データの集計といった労務のルーチンを自動化できます。ただしSmartHRが保持するのは、氏名・住所・給与、さらにはマイナンバーを含む従業員の機微な個人情報です。「便利だから」で丸ごとエージェントに開放してよいデータではありません。連携の前に、アクセス制御を設計します。

労務データが特別に難しい理由

広告アカウントやリポジトリと違い、SmartHRのデータはそもそも見えてはいけない人がいるという性質を持ちます。

機微情報の集中：マイナンバー・給与・扶養・保険といった、漏えい時の影響が大きい情報が一箇所にまとまっています。
「見ただけ」でも問題になる：他ツールでは書き込みが主なリスクですが、労務データは読み取りアクセスそのものが統制対象です。
手続きは戻せない：従業員情報の更新や各種申請は、実行後に「なかったこと」にはできません。

まず「どの従業員データに触れてよいか」を決める

SmartHR連携で最初に決めるのは、操作の種類ではなくデータの範囲です。 AIワーカーのロールごとに、到達してよい情報を絞ります。

マイナンバーや給与などの機微項目には、そもそもロールで到達させない。
集計や整合チェックに必要な項目（部署・雇用区分・在籍状況など）だけを参照させる。
特定の部署・拠点の従業員だけを対象にするなら、スコープでその範囲に限定する。

読み取り・分析は自由に、更新・申請は承認制に

データ範囲を絞ったうえで、操作を2種類に仕分けます。名簿の参照や集計、レポートの下書きといった読み取り・分析は自由に実行させ、従業員情報の更新・各種手続きの申請といった書き込みは人間の承認を経てから通します。これで、AIワーカーは労務のチェック作業を一人で走らせつつ、人の記録を変える操作の直前だけ担当者が確認する運用になります。

APIトークンをエージェントに渡さない

SmartHRのAPIトークンをプロンプトやローカルのMCP設定に置くのは避けます。認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡します。万一ワーカーのトークンが漏れても、影響はそのワーカーが触れる範囲に限定でき、 SmartHR本体のトークンを作り直す必要はありません。

誰がどの従業員データを見たかを監査に残す

労務データでは「誰が・どの従業員の・どの情報に・いつアクセスしたか」を後から追えることが特に重要です。読み取りも含めて、ワーカー・ロール・ツール・接続・対象・結果を監査ログに残しておけば、社内調査や個人情報の取り扱いに関する説明責任にそのまま使えます。

Grantryでの実現方法

Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。 SmartHRを含むMCP対応サービスに対して、ロールごとに到達できるデータと操作を絞り、更新・申請には承認ゲートを挟み、読み取りを含む全アクセスを監査ログに残します。エージェント側のコード変更は不要で、MCPクライアントをワーカートークン付きでGrantryに向けるだけです。

よくある質問

SmartHRの従業員データをAIエージェントに読ませても個人情報保護上は大丈夫ですか？

扱うデータの範囲を絞れるかどうかが分かれ目です。マイナンバーや給与などの機微情報にはロールで到達させない、必要な項目だけを参照させる、そして誰がどの従業員データを見たかを監査ログに残す。この3点を満たせるなら統制された利用が可能です。

SmartHRの従業員情報の更新や手続きをAIに自動実行させても良いですか？

従業員情報の更新や各種手続きの申請は、人間の承認を挟むべき書き込み操作です。集計や下書き作成といった読み取り・分析は自由に、登録・更新・申請は承認ゲート越しに実行する分離を推奨します。

SmartHRのAPIトークンをAIエージェントに渡さずに連携できますか？

できます。APIトークンはサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡します。生の認証情報がプロンプトやローカル設定に現れないため、漏えい時の影響範囲を限定できます。