コンテンツにスキップ

LayerX コーポレートエンジニアリング室 — SmartHR 起点の擬似 ABAC、n8n / Dify の全社展開、コーポレートデータの Snowflake 集約

作成日: 2026-09-27 出典: LayerX エンジニアブログ（竹山 @yuya-takeyama）「SmartHR 上の属性情報を元に擬似的な ABAC システムを構築した話」／「2025 年のコーポレートエンジニアリング室におけるプラットフォーム的進化を振り返る」（Advent Calendar 2025） 関連: 社内saasデータ統合基盤_ai活用_事例比較_整理 / layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / sansan_corporate_databridge_情シス内製データ連携基盤_整理 / 社内mcp共通基盤_認証認可ログ_整理

0. 要点（3行）

  • 一言で: 「人事 SaaS の組織図を権限の源泉にし、全 SaaS のグループをそこから自動で作り直す」。SmartHR の属性（所属部署・役職・契約形態・主担当職種）から Entra ID のグループを Terraform のコードとして生成し、PR で反映、SCIM で Google Workspace・Slack・Notion・AWS・1Password 等へ流す。
  • 管理対象のグループは 2024年末の88個 → 2025年末の161個。実装は設定・テストを除き 600行未満の TypeScript。副作用を Terraform に任せ、生成部分を純粋関数にしたのが肝。設定ファイルの作成は AI エージェント（Mastra → claude-code-base-action → Claude Agent SDK）に移しつつある。
  • 並行して n8n / Dify を全社の AI 業務自動化基盤として展開（上半期だけで表彰事例9件）。すると「データがあればできるのに」という相談が増え、コーポレートデータ（まず会計）を Snowflake に集め始めた。権限・自動化・データ基盤が互いを加速する関係になっている。

1. 全体像

flowchart LR
    HR[SmartHR<br>所属部署・役職・<br>契約形態・主担当職種] --> Gen[ABAC Generator<br>TypeScript 600行未満]
    Cfg[グループ条件の設定<br>TypeScript] --> Gen
    Gen -->|Terraform ファイル生成| PR[GitHub PR]
    PR -->|マージ・CI/CD| Entra[Microsoft Entra ID<br>グループ]
    Entra -->|SCIM| GW[Google Workspace]
    Entra -->|SCIM| Slack[Slack]
    Entra -->|SCIM| Notion[Notion]
    Entra -->|SCIM| AWS[AWS]
    Entra -->|SCIM| OnePw[1Password]
    GW --> Drive[Google Drive の<br>ファイル・ドライブ権限]
    Agent[設定生成エージェント<br>Claude Agent SDK] -.->|設定変更の PR を作成| Cfg

2. 擬似 ABAC — なぜ、どうやって

2-1. 課題

  • LayerX は毎月のように入社・異動がある（全社300名超、Risk & Compliance 室も発足）
  • Entra ID から SCIM で各 SaaS へは同期済み。しかしその Entra ID のグループのメンバー管理自体が大変だった
  • 入社時はある程度自動化済み。異動時は HR の異動シートを人が読み、手でグループを足し引きしていた
  • 例:「全社マネージャー」グループ。部署 A のマネージャーが部署 B に異動し、B でもマネージャーなら残留、一般メンバーなら削除。ただし A のマネージャーを兼任で残すならやはり残留。異動情報だけでは判断できず、全所属情報と照合が要る
  • グループは Google Drive の権限やプロダクトの管理システムの権限にも使われるので、セキュリティ・ガバナンス上も重要

2-2. 考え方

多くの SaaS・社内システムは RBAC（ロールごとに権限）前提。そこで「属性に応じてグループのメンバーを自動で正しく保つ」ことで、RBAC の上に擬似的な ABAC（属性ベースのアクセス制御）を作った。

2-3. 設定ファイル

「このグループにはこういう属性の人が入る」を TypeScript のオブジェクトで書く（記事の例を簡略化）。

const config = {
  groups: [
    {
      resourceId: 'admin',
      name: '管理者権限',
      memberConditions: [
        { departmentCode: '1', employmentTypeId: EmploymentTypes.正社員 },
      ],
    },
    {
      resourceId: 'general',
      name: '一般権限',
      memberConditions: [{ departmentCode: '2' }],
    },
  ],
};
  • departmentCode は HR が発番・管理する部署コード。部署名の変更や統廃合があっても実態に合うよう更新される
  • employmentTypeId は SmartHR の雇用形態マスタの ID。雇用形態はほぼ変わらないので定数化している

2-4. 処理の流れ

sequenceDiagram
    participant Gn as ABAC Generator
    participant Hr as SmartHR
    participant En as Entra ID
    participant Gh as GitHub
    participant Tf as Terraform CI/CD
    Gn->>Hr: 全社員と属性情報を取得
    Gn->>En: 現在のユーザー情報を取得
    Gn->>Gn: 設定と照合し、グループごとのあるべきメンバーを算出（純粋関数）
    Gn->>Gn: azuread_group リソースの Terraform を出力（純粋関数）
    Gn->>Gh: PR を作成
    Gh->>Tf: マージで plan / apply
    Tf->>En: グループのメンバーを収束させる
    En->>En: SCIM で各 SaaS へ同期

生成される Terraform（記事の例。メンバーは Object ID で、人が読めるようにメールアドレスをコメントで添える）:

resource "azuread_group" "admin" {
  name             = "管理者権限"
  security_enabled = true
  members = [
    "33333333-3333-3333-3333-333333333333", # kyoko.otonashi@example.com
  ]
}

2-5. 実装のポイント

判断 理由
メンバーの追加・削除を API で直接叩かず、Terraform を生成する 以前の職場で API 直叩きのスクリプトを保守していたが、実装が複雑になり、副作用があるためユニットテストが難しかった
処理を「①情報収集（HTTP）②あるべき状態の算出 ③Terraform 出力」に分ける ②③は純粋関数になりユニットテストが容易。追加・削除の処理を一切書かずに済み、600行未満に収まった
PR として残す 当面は作者が差分を確認してマージ（将来は自動マージ予定）。レビューしなくても、意図しない割り当てがいつ起きたか履歴で追える
宣言的に定期適用 Kubernetes の reconciliation loop（あるべき状態への収束）を意識。Terraform でなくても、状態を持つ宣言的 IaC なら何でもよい

幸運だったこと: HR・コーポレートの人たちが、この仕組みとは別の目的で SmartHR 上の組織情報を整備していた。データの正本が整っていたから成立した。

2-6. のびしろ（記事時点）

  • 手で作られてきた既存グループの取り込み（Terraform の import ブロックで対応可能だが手数が要る）
  • SmartHR への属性の登録・更新が大変。特に異動は、期限までに関係者から確実に情報をもらう業務フローの問題
  • 設定変更のセルフサービス化（全員が GitHub アカウントを持っているわけではない）

3. 2025年の進化 — 設定をエージェントに書かせる

時期 取り組み
2024年末 管理グループ 88個
2025年4月ごろ 既存グループ設定の取り込みを手伝う Import Agent を Mastra で開発
2025年9月ごろ 新規グループの追加・既存の編集を行うエージェントを claude-code-base-action で試作
2025年10月ごろ それを Claude Agent SDK で「Group Config Agent」として再実装。設定ファイルの変更から PR 作成まで自動化
2025年末 管理グループ 161個
  • 細かい改善: removed ブロックで tfstate からの削除に対応、個別メンバーの除外、追加オーナー、細かいメンバー条件
  • 当初は LLM でコード片を生成するだけで、ファイルへの反映は人がコピペ。SmartHR の部署をあいまい検索するツールを持たせたことで、肝心のメンバー条件も生成できるようになってきた
  • 残るギャップ: 実際の問い合わせは「この人たちが入ったグループを作って」と名前の列挙で来る。依頼者は自分の部署名も正確に知らないことが多い。名前から属性を調べて条件に落とし、依頼者に確認する作業をツールとプロンプトに落とし込むのが次の課題

4. n8n / Dify の全社展開

  • 2025年4月、行動指針「Bet Technology」が「Bet AI」に更新。社内業務でも AI を深く使う方針に
  • 室長 @kanny が Dify、筆者が n8n を導入
ツール 強み
Dify Knowledge（ベクトルストア）で RAG を作りやすい
n8n 連携できるアプリが多く、複雑なワークフローを組める
  • 先に流行ったのは n8n（一部エンジニアが個人で試していた。CPO が Slack 上で AI エージェントを動かす例を紹介）
  • 普及の壁は資格情報: 各サービスへの接続に API キー等が要り、サービスごとに管理者が違い、セキュリティの懸念もある → 専用チャンネルに質問を集約し、適切な部署・人を巻き込みながら地道に解消
  • 非エンジニアは Web API の一般知識もないので、「Slack の返信をスレッドにするには？」のような質問にも一つずつ自分で試して答えた
  • 事業部ではエンジニア中心に広がったが、コーポレート部門には差があった → 生成 AI の原則から Dify / n8n の使い方までのワークショップを実施
  • 上半期の月刊表彰「ラシトピ」で Dify / n8n が絡む事例が9件（人事、営業支援、オペレーション組織、Slack での顧客質問対応 bot など）

5. コーポレートデータを Snowflake に

flowchart LR
    Acc[会計 SaaS] -->|API<br>Snowpark で取り込み| SF[(Snowflake<br>コーポレートデータ)]
    Future[人事など<br>今後拡大] -.-> SF
    SF --> Biz[各事業部への提供<br>経営企画の分析]
    SF --> Auto[Dify / n8n の<br>業務自動化]
  • バクラク事業部は2024年ごろから BigQuery → Snowflake へ移行中
  • 経営企画などでは、会計・人事などコーポレート部門のデータを組み合わせないとできない分析がある
  • Dify / n8n の相談でも「データがあればできるけど、無いとできない」「データはあるが散在していて集めるのが大変」というケースが本当に多い
  • そこでコーポレートデータも Snowflake に集約することにした。まず会計データを API 経由・Snowpark で取り込み、個別の事業部に提供するところから開始
  • 筆者自身はデータエンジニアリング経験が少なく、OLAP 的なテーブル設計から学びながら進めている（記事時点では「成果につなげられているとは言い難い」と自己評価）

6. 3つの取り組みの関係

flowchart LR
    Perm[権限の自動化<br>ABAC Generator] --> Safe[安全に SaaS と<br>データを開ける]
    Safe --> AIBase[AI 活用基盤<br>Dify / n8n]
    AIBase -->|データが無いと<br>できない相談| Data[データ基盤<br>Snowflake]
    Data -->|使えるデータが増える| AIBase
    AIBase -->|設定作業も<br>エージェント化| Perm

記事のまとめ: 「AI 活用基盤が広がるほどデータ基盤の重要性が増し、データ基盤が充実するほど AI エージェント化の適用範囲が広がる。業務の AI エージェント化を進めるには AI 活用基盤の改善も要る」。

図の「権限の自動化 → 安全に開ける」の矢印は自分の解釈。記事は3つの相互作用を述べているが、権限との因果までは明言していない。

7. まとめ

一言で: 「権限の源泉を人事 SaaS に一本化し、副作用は IaC に任せ、その上で AI とデータを広げる」。

状況 LayerX から借りるアイデア
異動のたびに SaaS の権限を手で直している 人事 SaaS の属性 → IdP グループを自動生成し、SCIM で配る
権限変更スクリプトがテストできない あるべき状態を純粋関数で算出し、反映は Terraform に任せる
権限変更の履歴が追えない 変更を PR にする（自動マージでも履歴は残る）
n8n の各 SaaS 接続で資格情報が問題になる 質問チャンネルに集約し、SaaS の管理者を巻き込んで1件ずつ解消
AI 自動化の相談が「データが無い」で止まる コーポレートデータを DWH に集め始める（まず1ソースから）

参考リンク

  • 生産性とガバナンスを両立したグループ管理のため、SmartHR 上の属性情報を元に擬似的な ABAC システムを構築した話: https://tech.layerx.co.jp/entry/psuedo-abac-system-using-smarthr
  • 2025 年のコーポレートエンジニアリング室におけるプラットフォーム的進化を振り返る: https://tech.layerx.co.jp/entry/corporate-engineering-platform-evolution-2025
  • Terraform Provider for Azure AD（azuread_group）: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/group

作成: 2026-09-27 ／ 最終更新: 2026-09-27