TL;DR
- Backstage を入れただけでは IDP（Internal Developer Platform）にならない。catalog / permission / golden path の三位一体で初めて IDP として機能する。
- AI Agent 時代の IDP は「開発者と agent の両方が顧客」になる。catalog は agent からも discoverable に、permission は agent ごとに最小権限で自動配布する設計が必要。
- 自社 IDP は 0-3 / 3-6 / 6-12 / 12-24 ヶ月の 4 段階ロードマップで立ち上げる。各段階の投資配分・KPI・移行トリガーを切り替える。
- 段階移行は「フェーズ別ゲートの AND 条件」で判定する。Phase 1→2 は Catalog coverage 80% + owner 100% + 自動更新、Phase 2→3 は Golden Path 利用率 70% + Onboarding TTI 3営業日 + Self-Service ratio 60%、Phase 3 成熟は Self-Service ratio 80% + agent asset coverage 80% + audit completeness 100%、というように段階ごとに必須ゲートと観測指標を分ける。末尾の 30 / 60 / 90 日テンプレを Platform Team の叩き台として使ってほしい。
はじめに
こんにちは、みねです。
200〜2000 人規模で開発者体験（DevEx）の整備を担う Platform Team が、ここ 1〜2 年で急増しています。きっかけは生成 AI コーディングの普及です。Claude Code・Codex・Cursor といった AI エージェントが現場に入ったことで、**「個別最適のままだと AI のばらつきが組織を壊す」**という危機感が、IDP 構築という具体的なアクションに転化しました。
ところが、いざ IDP に着手すると多くの組織が同じ場所で詰まります。
- Backstage を入れたが、catalog が育たず誰も見ない
- Golden Path を作ったが、現場が回避ルートを使う
- Platform Team が「お手伝い屋」になり、Stream-aligned チームの自走が進まない
Puppet の "2023 State of DevOps Report: Platform Engineering Edition" によれば、Platform Engineering を採用した回答者の 約 94% が「DevOps の便益実現に役立つ」と回答しています（公式値、出典: Puppet 2023 State of DevOps Report: Platform Engineering Edition）。一方で、本当に IDP が機能している組織はその一部です。差は **「ツール選定」ではなく「段階設計と AI Agent 対応」**にあります。
この記事のゴール。
Platform Team・EM・CTO が、AI Agent 時代の IDP を「何から手を付け、12-24 ヶ月でどう成熟させるか」を判断できる設計図として提示する。
本記事はAIコーディング組織展開の段階設計の Steady 段階の主要施策 に位置づけられます。Pilot/Champion/Wave までは context と guardrails の整備が中心ですが、Steady で「個人のスキルを組織の Platform に転写する」フェーズに入ったときに、IDP が必要になります。
なぜ Backstage を入れただけでは IDP にならないか
「IDP を作ろう」と決めた組織が最初に手を出すのは、ほぼ必ず Backstage です。Spotify が 2016 年に内部開発し、2020 年に CNCF Sandbox、2022 年に Incubating に昇格した、Platform Engineering の代表的 OSS です（公式値、出典: Backstage 公式 - What is Backstage?）。
しかし、Backstage は catalog の器であって、IDP そのものではありません。これを誤解すると、半年経っても catalog に 30 サービスしか登録されず、現場は「結局 README を読みに行く」状態に逆戻りします。
IDP の三位一体（catalog / permission / golden path）
CNCF Platforms WG の White Paper では、IDP を「アプリケーションチームのために設計された、再利用可能な capabilities の集合」と定義しています（公式値、出典: CNCF Platforms White Paper）。私の経験則を加えて整理すると、IDP として機能するには以下の三位一体が必要です。
| 要素 | 役割 | 代表ツール |
|---|---|---|
| Catalog | サービス・チーム・依存関係の真実の単一ソース | Backstage / Port / OpsLevel |
| Permission | 開発者・サービス・agent ごとの最小権限を自動配布 | OPA / OIDC / SPIFFE |
| Golden Path | 「迷わず本番まで到達できる」推奨経路 | GitHub Actions / ArgoCD / Backstage Templates |
Backstage が提供するのは主に Catalog と Templates（Golden Path の入口）です。Permission 層は別途設計が必要で、ここを軽視すると Catalog の登録すら進みません。「誰がどのサービスを編集できるか」が曖昧なまま catalog を公開すると、人は登録しません。経験則として、catalog 投入率（実在サービスのうち catalog 登録済み割合）は permission 設計の質と強く相関します。
「Tooling と Platform の混同」というアンチパターン
Team Topologies の著者 Skelton と Pais は、Platform を「Stream-aligned チームの認知負荷を減らすために提供される、self-service な内部プロダクト」と定義しています（公式値、出典: Team Topologies - Key Concepts）。重要なのは **「プロダクトとして提供する」**という発想です。
| 観点 | Tooling | Platform |
|---|---|---|
| 提供形態 | 個別ツールの寄せ集め | 統合された self-service 体験 |
| 顧客 | 不明確 | Stream-aligned チーム（と agent） |
| KPI | 利用率（弱い） | NPS / Onboarding TTI / Self-Service ratio |
| ロードマップ | なし | プロダクト同様にバージョン・廃止計画あり |
| サポート | チケット対応 | ドキュメント + golden path で「聞かなくても進める」 |
Tooling 段階で止まる組織は、「導入したツール」を KPI にします。Platform 段階に移行できる組織は、「Stream-aligned チームの Onboarding TTI」を KPI にします。KPI が変わらないと、組織は変わりません。
AI Agent 時代の IDP が満たすべき4要件
ここからが本記事の差別化ポイントです。2025-2026 の IDP は、開発者だけでなく AI Agent も顧客 になります。Anthropic Agent Skills や Model Context Protocol（MCP）を踏まえ、AI Agent 時代の IDP が満たすべき要件を 4 つに整理します。
開発者と agent の両方が discoverable な catalog
従来の Backstage catalog は、Markdown と YAML で構成された「人間用」のページです。これを agent にも読ませるには、以下の追加が必要です。
- 構造化された service descriptor: agent が機械的に解釈できる JSON Schema / OpenAPI / AsyncAPI
- agent 用 readme:
AGENTS.md/CLAUDE.mdを catalog から自動収集（AIエージェントが読めるリポジトリ設計で詳述） - subagent / skill / mcp tool の登録: 各リポジトリの
.claude/skills/.claude/agents/を catalog の一級市民として扱う
subagent と skill の使い分けはClaude Skills と Subagents の使い分けで詳しく整理しています。catalog 設計時は「skill = 再利用可能な手順」「subagent = 文脈を持った専門家」という区別を catalog のメタデータに反映してください。
agent ごとの最小権限が自動配布される permission 層
開発者用の RBAC は枯れた技術ですが、agent 用は未成熟です。AI Agent は「意図しないスコープでツールを呼ぶ」ことが構造的に起こり得るため、最小権限の自動配布が IDP の責務になります。動的ポリシーには Open Policy Agent (OPA) のような汎用ポリシーエンジンを使い、Tool 標準化には Model Context Protocol のような共通仕様を採用するのが定石です（公式値、出典: Open Policy Agent）。
| 設計要素 | 開発者向け | Agent 向け |
|---|---|---|
| 認証 | OIDC + MFA | Short-lived token + audience claim |
| 認可 | RBAC / ABAC | Per-task scope（OPA で動的判定） |
| Audit | SIEM 連携 | Tool call ごとに完全ログ |
| Revoke | 退職時に手動 | TTL 自動失効 + 異常検知で即時失効 |
agent 用 permission の最小権限設計はAIコーディング時代の権限設計で詳述しています。本記事では「IDP の責務として permission 層を持つ」という点だけ強調します。Backstage を入れる前に、agent permission の責務をどのチームが持つかを決めておかないと、必ず後から事故が起きます。
golden path に agent ガイドが埋め込まれている
Golden Path は「迷わず本番まで到達できる推奨経路」ですが、AI Agent 時代は「agent が自走しても外れない経路」を意味します。
具体的には、scaffold した時点で以下が揃っている状態を指します。
AGENTS.md/CLAUDE.mdがテンプレート由来で配置済み- CI に必須 lint / test / security scan が組み込み済み
- Deploy は ArgoCD 経由で
infrastructure/リポジトリに PR を出すフロー固定 - Agent が触ってよいファイルパスが allowlist で明示
CI/CD と IDP の境界はGitHub Agentic Workflows と CI/CDで整理しています。ワークフローの実体は CI 側、メタデータと scaffold は IDP 側、と責務を切り分けてください。
IDP のメトリクスが agent 起因の活動も計測できる
DORA の 4 メトリクス（Lead Time / Deployment Frequency / Change Failure Rate / MTTR）は IDP の基本指標です（公式値、出典: DORA Research）。Agent 時代は以下の追加が必要です（経験則）。
- Agent-initiated PR ratio: 全 PR のうち agent 起点の比率
- Agent rework ratio: agent PR が人間レビューで差し戻される率
- Tool call audit completeness: agent が呼んだ tool のうち完全ログが取れている割合
- Self-Service ratio (with agent): agent + 開発者の自走で main 着地した PR 比率
これらは Backstage 単独では取れません。CI / Git / SIEM のデータを統合する必要があります。
段階別ロードマップ（4 段階モデル）
ここから本題のロードマップです。0-24 ヶ月を 4 段階に分け、各段階の目的・主要施策・KPI・アンチパターン・移行条件を整理します。
Phase 0: 基盤整備（0-3 ヶ月）
目的
IDP を「何のために作るか」を Platform Team と経営の間で合意し、Service Catalog の最低限の入れ物を作ります。
主要施策
- Platform Team 立ち上げ: 経験則として、200-500 人規模なら Stream-aligned 4 チームに対し Platform 4-6 人が最小成立規模（Team Topologies 由来の経験則）
- IDP の North Star Metric 決定: 推奨は Onboarding TTI（新規メンバーの Time-To-First-PR）
- Catalog の入れ物: Backstage minimal install（テンプレート + GitHub auth のみ）
- Permission の責務分担: Security チームと Platform チームの責務を RACI で文書化
KPI
| KPI | ターゲット | 計測方法 |
|---|---|---|
| Platform Team の確立 | 4-6 人 | 組織図 |
| Catalog の存在 | minimal install 完了 | Backstage 起動確認 |
| North Star Metric 合意 | 経営承認 | Platform 戦略ドキュメント |
アンチパターン
- いきなり全機能の Backstage を入れる（半年溶ける）
- Platform Team を 1-2 人で始める（自走前に燃え尽きる）
- KPI が「Backstage を入れること」になる
移行条件（→ Phase 1）
- Platform Team が 4 人以上で成立
- North Star Metric が経営承認済み
- Catalog の入れ物が動いている
Phase 1: Catalog 立ち上げ（3-6 ヶ月）
目的
実在サービスの 80% を catalog に登録し、「真実の単一ソース」として機能させます。
主要施策
- Catalog 投入の自動化: Backstage の GitHub discovery provider を導入（
@backstage/plugin-catalog-backend-module-github）し、GitHub App または PAT でcatalog.providers.github.*.filters.topic.include/catalogPath/schedule/ rate limit を設定。catalog-info.yamlと repository topics の両方で自動登録する - Service descriptor の標準化: OpenAPI / AsyncAPI を必須化し、CI で lint
- AGENTS.md / CLAUDE.md の catalog 統合: agent 用 readme を catalog から自動収集
- Owner 明示: 全サービスに owner（個人ではなくチーム）を必須化
KPI
| KPI | ターゲット | 計測方法 |
|---|---|---|
| Catalog coverage | 実在サービスの 80% | 月次 audit |
| Owner 明示率 | 100% | catalog-info.yaml 検査 |
| Agent-readable ratio | 主要サービスの 60% | AGENTS.md 設置率 |
アンチパターン
- catalog 投入を Platform Team が手作業で行う（必ず古びる）
- owner を「個人」にする（退職で孤児化）
- README をそのまま catalog に貼る（agent が読めない）
移行条件（→ Phase 2）
- Catalog coverage が 80% 以上で 1 ヶ月安定
- Owner 明示率 100%
- Catalog の更新が自動化されている
Phase 2: Golden Path 整備（6-12 ヶ月）
目的
「新規サービスを作るときに迷わない経路」を 3〜5 種類用意し、80% のケースをカバーします。
主要施策
- Backstage Templates: Frontend / Backend API / Batch / Data pipeline / ML サービスの 5 種を最低限用意
- scaffold で AGENTS.md / CI / Deploy が同時生成: 個別実装させない
- Golden Path 利用率の計測: 新規サービスのうち template 由来の割合
- Permission の自動配布: scaffold 時に OIDC / OPA ポリシーが自動適用
KPI
| KPI | ターゲット | 計測方法 |
|---|---|---|
| Golden Path 利用率 | 新規サービスの 70% | template_id ラベル |
| Onboarding TTI | 中央値 3 営業日以内 | 新規参加者の First PR Time |
| Self-Service ratio | 60% | PR ラベル分析 |
アンチパターン
- Golden Path を「強制レール」にする → 現場が回避ルートを使う
- Template が古びて誰もメンテしない → owner 必須
- Permission が template ごとにバラバラ → 横串でレビュー必須
移行条件（→ Phase 3）
- Golden Path 利用率が 70% 以上で 2 ヶ月安定
- Onboarding TTI 中央値 3 営業日以内
- Self-Service ratio 60% 以上
Phase 3: Agent 対応（12-24 ヶ月）
目的
開発者向けに完成した IDP を、AI Agent 用にも開放します。Steady 段階のチームが「使う側」から「設計する側」に立つフェーズです。
主要施策
- Agent catalog の追加: 各リポジトリの skill / subagent / mcp tool を Backstage の独立した kind として登録
- Per-task scope の自動配布: agent が tool を呼ぶ際に OPA で動的判定
- Agent 用 golden path: agent が自走するときの推奨経路（プロンプト + 権限 + ツール）
- Tool call audit の完全ログ化: SIEM 連携で agent 活動を可観測に
KPI
| KPI | ターゲット | 計測方法 |
|---|---|---|
| Self-Service ratio (with agent) | 80% | agent + 開発者起点 PR の main 着地率 |
| Agent rework ratio | 15% 以下 | レビュー差し戻し率 |
| Tool call audit completeness | 100% | SIEM ログ |
| Catalog coverage (agent assets) | 主要 agent 資産の 80% | skill / subagent 登録率 |
社内データとして、Stream-aligned チームが IDP 経由でリソース調達した場合、単発 Slack 依頼比で Lead Time が 30〜50% 短縮するケースが複数観測されています（社内データ、N=複数案件）。
アンチパターン
- Agent permission を「広めに切って後で絞る」→ 必ず事故る、最初から最小権限で
- Tool call audit を後付け → 監査要求が来たときに対応不能
- Agent catalog を「Platform Team が手で登録」→ 1 ヶ月で古びる
段階移行を判定するトリガー
各 Phase の移行は単一指標ではなく、AND 条件で判定します。これはAIコーディング組織展開の段階設計の段階移行設計と同じ思想です。
Self-Service ratio
Self-Service ratio は「PR がレビュー以外の人手介入なしに main へ着地する率」です。経験則として 80% が成熟ラインです。Phase 2 で 60%、Phase 3 で 80% を目安にします。
Onboarding TTI（Time-To-First-PR）
新規参加者が最初の PR を main に入れるまでの時間。Phase 2 で中央値 3 営業日以内が目安です。これが伸びている間は、scaffold やドキュメントに穴があります。
Catalog coverage
実在サービスのうち catalog に登録済みの割合。Phase 1 で 80%、Phase 3 で agent 資産も含めて 80%。
AND 条件で判定する理由
単一指標を追うと、必ず「指標を上げるための運用」が始まり、本質を見失います。たとえば Catalog coverage だけを追うと、Platform Team が手で投入し始めて自動化が進みません。Self-Service ratio だけを追うと、レビューを省略する誘惑に負けます。
3 つすべてが同時に閾値を超えていることを移行条件にすることで、片肺運用を防ぎます。
ツール選定の考え方（Backstage / Port / 自作）
ツール選定は「組織規模 × Platform Team の人数 × カスタマイズ要件」で判断します。
| ツール | 強み | 弱み | 適性 |
|---|---|---|---|
| Backstage | OSS / プラグイン豊富 / Spotify origin | 運用コスト高 / 内製 plugin が必要 | 1000 人未満、Platform 4-6 人 |
| Port | SaaS / セットアップ早い / ノーコード | OSS でない / 細かい拡張に限界 | 1000 人超 / Platform に投資する余裕がない |
| OpsLevel | サービス成熟度の可視化が強い | catalog 単機能寄り | 既に CI/CD 整備済み、catalog だけ欲しい |
| 自作 | 完全な要件適合 | 半年〜1 年で技術負債化 | 推奨しない（経験則） |
経験則として、1000 人未満なら Backstage、1000 人超で Platform Team の余裕がなければ Port を第一候補にします。自作は短期的には魅力的ですが、Backstage / Port のロードマップ速度に追いつけず、6〜12 ヶ月で負債化します。
アンチパターンと回避策
Platform Team が「お手伝い屋」になる
最も多い失敗です。Stream-aligned チームから「この設定をしてほしい」「この PR をマージしてほしい」と依頼が来ると、Platform Team はそれに対応してしまいます。短期的には喜ばれますが、長期的には Self-Service ratio が下がり、Platform Team は燃え尽きます。
回避策: 依頼が来たら「個別対応せず、golden path / catalog に取り込む」をルール化。Team Topologies が言う enabling team の動き方（一時的に張り付き、自走できる状態にして撤収）を徹底します。
Catalog が古びて使われなくなる
Catalog 投入を手作業にすると、必ず古びます。退職・組織変更・サービス統廃合で owner が消え、誰も updates しない catalog エントリが増えます。
回避策: catalog-info.yaml を必須化し、CI で「catalog にないサービスはマージ不可」のチェックを入れます。owner はチーム単位で必須化し、個人にしません。
Golden Path が「強制レール」になる
「この template を使え」と強制すると、現場は別のリポジトリに横道を作って回避します。Golden Path は **「使った方が楽」**である必要があります。
回避策: scaffold 時間を計測し、template 経由が手作業より速いことを保証。手作業ルートを残しつつ、Golden Path 利用率を KPI として追います。利用率が 50% を切ったら、Golden Path 自体を見直すサインです。
30 / 60 / 90 日アクションプラン（テンプレ）
Platform Team を立ち上げる方が、明日から使える 90 日テンプレを用意しました。経営会議や 1 on 1 の叩き台として使ってください。
Day 0-30: 合意形成と最低限の入れ物
- North Star Metric を Onboarding TTI（または Self-Service ratio）に設定し経営承認
- Platform Team 4-6 人の人選とミッション宣言
- Backstage minimal install（GitHub auth + Catalog のみ）
- Permission 責務の RACI を Security チームと合意
- 競合となる「お手伝い窓口」を Platform Team の責務外に明示
Day 31-60: Catalog 立ち上げ
- Backstage GitHub discovery provider の導入（plugin インストール / backend 登録 / GitHub App or PAT 権限設定 /
catalog.providers.github.*.filters.topic.include/catalogPath/schedule/ rate limit） - catalog-info.yaml の必須化（audit-only → warning → blocking の段階導入で既存サービスへの一律強制を避ける）
- 主要 30 サービスの catalog 投入と owner 明示
- AGENTS.md / CLAUDE.md の catalog 統合パイプライン構築
- Service descriptor 標準（OpenAPI / AsyncAPI）の lint 開始
- Onboarding TTI の計測開始
Day 61-90: Golden Path 1 種目
- 最も多いユースケース（例: Backend API）の template を 1 種類完成
- template scaffold で AGENTS.md / CI / Deploy 同時生成
- Golden Path 利用率の計測開始
- Phase 1 移行判定（Catalog coverage 80%、owner 100%）
このテンプレを起点に、3 ヶ月ごとに見直してください。Phase 2-3 は同じ要領で 6-12 ヶ月、12-24 ヶ月のチェックリストに展開できます。
FAQ
Q. IDP と PaaS の違いは何ですか？
A. PaaS（Heroku / Cloud Run など）は「アプリを動かす実行環境」を提供します。一方、IDP は 「組織の Stream-aligned チームのために、catalog / permission / golden path を統合した self-service 体験」 を提供します。PaaS は IDP の構成要素になり得ますが、PaaS だけでは IDP になりません（出典: CNCF Platforms WG White Paper）。
Q. Backstage を入れたら IDP は完成しますか？
A. 完成しません。Backstage は catalog の器です。IDP として機能するには catalog / permission / golden path の三位一体が必要で、Backstage が直接カバーするのは catalog と templates の入口のみです。permission 層（OPA / OIDC）と運用ルール（owner 必須化、catalog-info CI チェック）は別途設計が必要です。
Q. Platform Team は何人必要ですか？
A. 経験則として、200-500 人規模で Stream-aligned 4 チームに対し Platform 4-6 人が最小成立規模です。1-2 人で始めると、Phase 0 の合意形成段階で燃え尽きます。Team Topologies の enabling team / platform team の動き方を分担できる人数を確保してください。
Q. AI Agent 時代に IDP は本当に必要ですか？
A. 必要性は高まります。AI Agent は「意図しないスコープでツールを呼ぶ」リスクが構造的にあるため、最小権限の自動配布と tool call audit を IDP の責務として持たないと、Steady 段階でガードレールが破綻します。逆に IDP がない組織は、agent 時代に 個別 README + 個別 token で破綻リスクが累積します。
tech-decision シリーズ + 周辺ハブとの接続（2026-05 追記）
本記事は tech-decision シリーズの child（order 5） に組み込まれます。technology-radar-howto（056）と並んで「採用判断 → 運用フレーム」の 2 軸を構成し、Platform Team 視点で IDP 採用を tech-decision の枠で評価できます。
Backstage / CNCF Platforms / Spotify Soundcheck 公式値
- Backstage: CNCF Incubating project、Spotify 由来のオープン IDP[公式値]（Backstage 公式）。catalog plugin / TechDocs / Software Templates が中核
- CNCF Platforms WG White Paper: Platform Engineering の参照アーキテクチャを公式提供[公式値]（CNCF Platforms WG）
- Spotify Soundcheck: golden path の遵守率 / quality gate を可視化する scorecard 機能[公式値]（Spotify Soundcheck）
- Port: developer-portal SaaS、Backstage の代替として採用組織が増加[公式値]（Port 公式）
AI Agent 時代の IDP 拡張（4 拡張ポイント）
本記事の §「AI Agent 時代の IDP が満たすべき4要件」を 2026-05 時点の最新 hub と接続して整理:
- Agent Catalog: agent と skill を catalog で管理（Skills対Subagents使い分け5軸 参照）
- MCP Server Registry: MCP server を catalog エントリとして扱う（MCPサーバー設計パターン集 参照）
- 認可境界の自動配布: capability token と OAuth 2.1 scope（AI Agent 認可境界の設計パターン4モデル 参照）
- Runbook / Incident hub の統合: SRE / Platform 向けインシデント対応（AIコーディング運用インシデントRunbookハブ 参照）
可観測性スタックは AIコーディング運用の可観測性スタック2026、CFR 計測との連動は AI変更後のCFR再定義ガイド を参照。
関連記事
- AIコーディング組織展開の段階設計: 本記事の親記事。Pilot/Champion/Wave/Steady の 4 段階のうち Steady 段階の主要施策が IDP 構築。
- Claude Skills と Subagents の使い分け: agent catalog 設計時に skill / subagent をどう分類するか。
- GitHub Agentic Workflows と CI/CD: IDP と CI/CD の責務境界。
- AIコーディング時代の権限設計: agent 用 permission の最小権限設計。
- AIエージェントが読めるリポジトリ設計: catalog 統合する
AGENTS.mdの設計。 - 技術選定で後悔しないための判断基準: tech-decision シリーズ親
- Technology Radar の作り方: tech-decision child（運用フレーム）
- AI Agent 認可境界の設計パターン4モデル: IDP の permission 層
- MCPサーバー設計パターン集: MCP server registry 連携
- AIコーディング運用インシデントRunbookハブ: IDP の SRE 統合
まとめ
自社 IDP は、Backstage を入れるだけでは完成しません。catalog / permission / golden path の三位一体を、4 段階のロードマップ（基盤整備 → catalog → golden path → agent 対応）で 12-24 ヶ月かけて成熟させます。
AI Agent 時代の IDP は、開発者だけでなく agent も顧客です。catalog は agent からも discoverable に、permission は agent ごとに最小権限で自動配布、golden path には agent ガイドを埋め込み、メトリクスは agent 起因の活動も計測します。
段階移行は Self-Service ratio / Onboarding TTI / Catalog coverage の AND 条件 で判定してください。単一指標を追うと、必ず本質を見失います。
末尾の 30 / 60 / 90 日テンプレを Platform Team の叩き台として使い、自社が今どの Phase にいるかを 30 分で診断してみてください。
:::message Platform Team の立ち上げ、Backstage 導入の Phase 設計、AI Agent 時代の permission 設計についてのご相談を受け付けています。お気軽にお問い合わせください。 :::
