こんにちは、プロダクトエンジニアのa2cとhiisukeとyonetaniです。 今回は、私たちが所属している情シス開発部のID管理機能の紹介や取り組みについて紹介します。
ID管理機能とは？
SmartHRは、従業員の入退社や異動、所属・役職などの人事データを常に最新の状態で管理しています。そんなSmartHRの強みを活かして、社内で使うさまざまなSaaSアカウント(以後「アカウント」と呼びます)の管理を効率化できるのが「ID管理」機能です。
この機能を使うと、SmartHR上の従業員データをもとに、アカウントの一覧を表示したり、アカウントの作成・削除までできます。たとえば、退職者のアカウントを見つけたいときも、一覧を見ればすぐに把握できます。棚卸しや確認作業にかかっていた時間をぐっと減らせるほか、不要なアカウントを早めに削除することでコスト削減や削除漏れによるセキュリティリスクの低減にもつながります。
3か月で50のSaaS連携を目指す
ID管理機能の開発では、「3か月で50件のSaaSと連携する」という目標を掲げました。開始時点で既に5件は完了していたものの、残り45件を3か月で追加する必要があり、当時の実装ペース（月約5件）のままでは到達が難しい状況でした。
そこで、AI活用の標準化と開発プロセスの見直しを同時に進め、仕様作成・実装・検証の各工程のムダと待ち時間を圧縮しました。その結果、開発ペースを計画値まで引き上げ、最終的には期限の1週間前に目標を達成しています。ここからは、実際に実施した施策の一部とそこから得られた効果を具体的に紹介します。
AIの活用
50件のSaaSと連携するという目標は、従来の開発手法では非常に困難なものでした。各SaaSごとにAPI仕様が異なり、ドキュメントの整備状況もバラバラ。さらに、実装後のテストや検証の工数も考慮すると、チームメンバーだけでは到底間に合わない計算でした。
それまではAIを「補助ツール」として各開発者が各自で活用するにとどまっていましたが、チーム全体で活用し、より一層の開発効率向上を目指しました。ここからは、実際にどのようなAI技術をどのように活用したのかを紹介します。
Cursor Ruleの整備
チーム全体でAIを活用するにあたり、入力のコスト及び出力品質のばらつきを抑えるため、Cursor Ruleを整備しました。プロンプトのルール、命名規則、コメントのフォーマットなどを統一することで、AIが生成するコードの品質が安定し、レビュー工数の削減にもつながりました。具体的には以下のようにルールを整理しました。
.cursor/rules/ ├── common-implementation-rules.mdc # 共通実装ルール（常時適用） ├── initialize-handler.mdc # 初期実装ガイド（常時適用） ├── job-message.mdc # Job Message構造 ├── get-token.mdc # トークン取得 ├── get-users.mdc # ユーザー取得 ├── create-user.mdc # ユーザー作成 └── destroy-user.mdc # ユーザー削除
ルールづくりで工夫したポイント
Cursor Ruleの整備において、以下の2つのポイントで工夫しました。
機能別ルール（alwaysApply: false + globs指定）の設定
特定のファイルパターンに対してのみルールを指定し、不要なルールを適用しないようにしました。これによりトークン消費を抑えたり、コンテキストが明確になり、AIの回答精度が上がることを狙いました。
# 例：トークン取得機能のルール # 該当ファイルを編集する際に自動的にルールを適用 globs: internal/http_client/*/get_token*.go
必須事項/禁止事項の設定
各実装方針や禁止事項を明確化することで、AIが生成するコードの品質を一定以上に保ちつつ、レビュー時の指摘事項を減らすことができました。また、レビューで指摘された内容や合意された方針をルールに記載することで改善のサイクルが機能するようにしました。
## ✅ 必須事項 1. lint, formatを実行する 2. インターフェース検証を各ファイルに記載する 3. 一貫したエラーメッセージを使用する 4. 適切なインデントを使用する ## ❌ 禁止事項 1. 不要なコメントを追加する（TODOコメントのみ許可） 2. 型名やパッケージ名を間違える 3. 戻り値の型を間違えること
SDD(Specification-Driven Development)の導入
各SaaS連携の開発では、SDD（Specification-Driven Development） を採用しました。SDDは、先に仕様を固め、実装はAIに任せる進め方で、Cursor・Cline・Devin など主要なAIエージェントも推奨しています。
進め方は以下の通りです。 1. API仕様書などをもとに、AIと一緒に Design Doc（設計ドキュメント） を作成する。 2. そのDesign Docを指示としてAIに渡し、初期実装を生成してもらう。 3. 人間は設計とレビューに集中し、AIが出した初期実装を検証・改善する。
このやり方により、初期実装の速度が大幅に向上しました。AIは詳細な仕様があるほど高精度にコードを生成できますが、曖昧な指示では品質が落ちがちです。だからこそ、「人間が設計とレビュー、AIが初期実装」という役割分担を明確にしています。
以下は実際に作成したDesign Docの抜粋です。
# 外部サービスAPI連携 ## 概要 外部ワークマネジメントシステムのAPI連携により、ユーザー情報の取得を自動化する。 認証はアクセストークンによる認証を用いる。 ## Goal - ユーザー情報の取得機能の実装 ## Non-Goal - ユーザーの作成・削除機能 - 組織設定や権限モデルの管理 ## 仕様について ### トークン取得 - 認証方式: アクセストークンによる認証 - 再発行エンドポイント: `POST /api/v1/auth/token/refresh` ### アカウントの取得 - エンドポイント: `GET /api/v1/users` - 必要なパラメータ:...
参考：Cursor/Clineなど「AIエージェント」を用いた開発、何が変わるのか？
Devinの活用
小規模な修正や設定値の更新といった、比較的シンプルな作業にはDevinを積極的に活用しました。特に、ある程度パターンが決まっているSeedデータの変更や、本番リリース後の正常系フロー確認での活用が特に効果的でした。
具体的には、あらかじめ用意したプロンプトをディレクトリ内で管理し、開発者が簡単に利用できるようにしています。Devinは対象ファイルを自動で特定し、変更内容をPull Requestとして提示してくれるため、開発者はその内容を確認してマージするだけで済みます。また、本番リリース後の動作確認でも、主要な機能のチェックや画面遷移テストをDevinに任せることで、初動確認の負担を減らせました。
結果としてDevinの活用はチームの中でも「人がやるにはもったいないけれど、やらないと困る」作業をうまく引き受けてくれる存在になっています。こうした小さな自動化を積み重ねることで、チーム全体の生産性に貢献しました。
docs/
└── prompts/ # プロンプト集
├── README.md # プロンプト集の概要・使い方
├── template.md # プロンプトテンプレート
├── add-new-provisioning-seed-by-devin.md # 新サービスのseed追加
├── create-design-doc-for-new-service-integrate.md # 新サービス連携のDesign Doc作成
└── make-scaffold-by-devin.md # 新サービスのスキャフォールド生成
MCP Serverの活用
SaaS連携を進める中で、各サービスのヘルプページを作成する必要がありました。従来の手作業では、APIドキュメントの確認、実装内容の把握、ヘルプページの執筆という工程に多くの時間がかかっていました。そこで、社内のUXライティンググループが開発したMCP Serverを活用し、これらの作業を自動化することができました。
MCP Serverを利用することで必要な情報を自動的に収集・整理できるようになり、ドキュメント整備の負担が大きく軽減され、1つのヘルプページ作成にかかる時間を従来の1〜2時間から30分程度に短縮できました。さらに、フォーマットの統一性も向上し、ドキュメント品質の安定化にも貢献しました。
DeepResearch機能を使ったアカウント調査
SaaSごとのAPI仕様や利用プランを調査する際には、ChatGPTが提供するDeepResearch機能を活用しました。特に各サービスのAPI提供状況や利用可能プラン、認証方式などを体系的に調べる必要があったため、プロンプトを用意して自動化を進めました。このプロンプトでは、各SaaSについて以下の観点を包括的に調査するよう指示しています。
- APIの提供有無と公式ドキュメントURL
- APIの種類（REST / GraphQL / SCIM など）と認証方式
- APIが利用可能なプラン名・価格・比較ページURL
- アカウントの取得／作成／削除といった操作の可否・制約
- 利用上限や必要権限、一括操作可否などの条件整理
- プランごとのAPI利用可否の表形式まとめ
- 支払い方法（請求書対応・クレジットカードなど）の確認
DeepResearch機能にこのプロンプトを実行させることで、手動では時間のかかる情報収集を短時間で高精度に行えるようになりました。たとえば、上記のような調査項目を手動で網羅的に調べるだけでも1サービスあたり数十分を要していた作業が、数分程度で要約結果を得られました。一方で、実装を始めると事前の調査結果と異なる点もありましたので、最終的な判断や仕様確認のフェーズでは人間の目による確認が欠かせないと感じました。
開発プロセスの改善
これまではAI活用について紹介してきましたが、ここからは開発プロセスに関するさまざまな改善施策の中から、いくつかの取り組みを抜粋して紹介します。
連携方針のドキュメント作成
短期間で連携数を伸ばす中で、SaaSごとにAPIの前提やドキュメント整備状況がばらつき、着手から実装までの工数が読みにくいことが課題でした。中には設計が整理されていてスムーズに進むものもあれば、仕様を手探りで確かめる必要があるものもあり、毎回「どう実装するか」の判断が発生していました。
そこで、判断の再利用ができるように連携方針をドキュメント化しました。たとえば「認証がAuthorization Codeならこの認可フロー／Client Credentialsならこのトークン取得手順」「API KeyでScope指定不可なら採用を避けOAuthを第一候補にする」「ページングがcursor型なら次ページトークン方式、offset型なら件数上限と並び順固定を必須にする」「429系のレート制限がある場合は指数バックオフ＋Idempotency-Keyを必須にする」など、典型パターンごとのガイドを用意し、設計前に参照できるようにしました。
共通の判断基準を用意したことで、迷いが減って設計の往復が短縮され、相談・調整コストも圧縮。結果として、着手までのスピードと実装の安定度が上がり、連携の進みが加速しました。
実際のドキュメントのイメージはこちらになります。
## 連携方式 あくまで現状の方針なので必要であれば都度変更する ドキュメントに指定があればそれに従いますが、特に明確に基準が記載されていない場合は下記を元に判断する - アプリストア形式の場合は共通のClientIDを利用 - AuthorizationCodeGrantとClientCredentialsGrantがあればAuthorizationCodeGrantを採用 - OAuth のパターンとAPI Keyの場合 - API KeyでScopeの指定ができればAPI Keyを採用 - API KeyでScopeの指定ができなければ相談 (まだ特に話してない) ### 実際の検討ケース #### パターンA (実際のSaaS名は伏せています) - パターンA はドキュメントの方針に沿ってServiceAccount認証を利用する 参考リンク: https://example.com #### パターンB - OAuthの申請が難易度高いのと、OAuthでプロビジョニングのScopeの指定が出来ないのでPATを採用 参考リンク: https://example.com #### パターンC - APIトークンはあるが、有効期限が1ヶ月+1日という短い期間で設定されている。 - APIトークンの期限が切れた場合はユーザー自身で更新する必要がある。 - ヘルプページにも案内を記載済み 参考リンク: https://example.com ## プロビジョニングの連携項目 - 要望がなければアカウント取得のみ対応 - 難易度が高いプロビジョニングの場合は後回しにするが要望が高い場合は対応する - 必須項目以外は現時点では連携しない ### 実際の検討ケース #### パターンA - アカウント作成でdepartmentIdを連携するのは難しいので、アカウント取得・削除のみの対応にする - -> 部署名もしくはIDで連携することを検討したが、一旦アカウント作成の開発は保留する。パターンAの部署コードの開発をリクエストする。 #### パターンB - 招待中メンバーも課金対象であり、実質的にアカウントとして管理する必要があるため、正式メンバーと招待中メンバーの両方を取得し、hanica側では両方とも「アカウント」として扱う - ユーザー作成時には実際にアカウントの作成は行われず、招待のみしか行われないが問題ないと判断
一人一SaaS担当制
SaaS連携の新規開発では、サービスごとに機能やAPI仕様、用語の前提が異なります。そこで私たちは、特定のSaaSを一人が継続して担当し、API調査から仕様検討、Design Docの作成、実装・検証までを一気通貫で進める体制にしました。担当者が背景とサービスを深く理解したうえで判断できるため、読み直しや確認の往復が減り、設計からPRまでの流れが滑らかになります。速度を上げつつ属人化を避けるために、相談や困りごとは週二回の定例会議の場を積極的に活用しました。
段階的なリリース
初期は「取得・作成・削除」を各SaaSで一括で出す想定でしたが、価値が届くまでの時間が大きい課題が見えてきました。そこで、SaaSごとにお客様から求められる機能や要件を丁寧に整理し、現時点で必要な連携から順番に提供するよう進めました。たとえば、アカウント取得だけで十分なSaaSでは、まず取得機能のみ連携し、作成や削除といった追加の要望が生じたタイミングで段階的に機能拡張する形を採用しました。
この段階的なリリースにより、限られた期間で最大限価値を届けつつ、重要な部分に集中して効率的に開発を進めることができました。
まとめ
これまで紹介してきたAI活用やプロセス改善の取り組みをチーム一丸となって積み重ねた結果、私たちは「3か月で50件のSaaSと連携する」という非常にチャレンジングな目標を、期限の1週間前に達成することができました。
上の「Code frequency」の週ごとの追加行（Additions）に着目すると、前半は小さな山が散発的だったのに対し、中盤からは週あたり最大で約1万行規模の山が連続して現れています。これは、上述したような取り組みが機能し、新規のSaaS連携を継続投入できたフェーズと一致します 注: このグラフは新規連携に加えて、周辺の改善やリファクタリングも含む全体のコード変更量を表しています（連携追加のみを切り出したものではありません）。
この取り組みによって連携できるSaaSの数が短期間で飛躍的に増加したことは、私たちにとって、そしてお客様にとって大きな価値となりました。 実際にお客様からは、開発速度に対するポジティブな反応をいただく機会も増え、ID管理機能の今後に高い期待を寄せていただけていると感じています。
また、社内でのモメンタムも高まりました。連携先が増えたことでセールスメンバーがお客様へID管理機能を提案しやすくなり、その結果、具体的な商談や導入検討のケースが増えるという好循環も生まれています。
ID管理の開発はまだまだ0→1の段階であり、道半ばです。今回の経験を踏まえ、今後もチームとして、そしてプロダクトとしての改善を続けていきます！！
We are hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも「面白い」と思った方、情シス向けのプロダクト開発に興味がある方、ぜひカジュアル面談でお話しましょう！
情シス領域のプロダクトエンジニアとしてご応募されたい方は、直接の応募もお待ちしております！
