AI ネイティブな企業組織モデルの設計について

A large engineering organization is a complex orchestration. Dozens of departments, subsidiaries, and regulated groups operate at once, arranged in nested hierarchies and distributed across countries, regions, and legal jurisdictions, each carrying its own requirements for access, integrations, policy, usage, and data residency. No two are organized the same way.

Building a software factory that fits inside that environment is a challenge. AI agents act autonomously, use credentials, consume spend, and operate inside customer environments. As such, any deployment has to respect every access boundary, residency requirement, and policy the business already enforces. It also has to be malleable enough to adapt as the structure changes, instead of forcing the business to reshape around it.

The Factory Organization Model provides that flexibility. One commercial relationship and one control surface sit above distinct organizations for the parts of the business that need to operate differently, and the model flexes as the business does: organizations can be created, nested, and scoped to match how the company runs today and reshaped as it changes. It gives teams a way to expand AI development beyond an initial group without losing control of governance, residency, spend, or access.

The result is a governable software factory: central control at the top, explicit boundaries where teams differ, and one structure that scales from an initial group to the entire enterprise.

The Factory Organization Model

Factory gives companies controls to separate the enterprise account from the organizations that operate within it.

The enterprise account is the commercial and administrative umbrella: the customer relationship, billing, identity configuration, and enterprise-level administration.

An organization is the operating boundary. Users, integrations, policies, model access, usage limits, membership, and regional settings are all defined at the organization level, and integrations in particular are defined per organization only.

Organizations can be created under the enterprise account or nested under another organization, so the hierarchy reflects business structure while every operating boundary stays explicit.

A parent organization can represent a major operating boundary, such as a region, platform group, or delivery practice. Child organizations sit beneath it when a narrower group needs its own membership, admins, integrations, model policy, usage limit, or residency setting. Enterprise admins keep centralized visibility and governance across the hierarchy, while each child organization can carry different controls when one shared configuration would be too broad.

Enterprise umbrella

governed via Admin Console

Enterprise account**billing + portfolio + governance

Top-level organization

enterprise admins

Admin Console home

Parent organization

region or platform group

100 members

broad model access

1B FSC limit

Peer organization

separate business group

40 members

restricted model access

250M FSC limit

Child organization

regulated workload

25 members

BYOK model access

500M FSC limit

Child organization

sandbox workload

15 members

experimental model access

100M FSC limit

• ## Configuration patterns

An organization can represent a department, business unit, region, subsidiary, agency, client delivery group, regulated environment, or deployment environment. Organizations are best used when a group needs a real boundary:

Separate integrations, credentials, service accounts, or repository access.

• Separate regional or data residency requirements.

• Separate model access, including BYOK or customer-hosted inference.

• Separate admins, membership rules, policies, or usage limits.

• Separation required by finance, IT, security, compliance, or operating structure.

The examples below reflect where we see this model deliver the most value, drawn from working directly with large, global companies every day to configure Factory around how they *actually* operate. Each keeps central governance in place while giving operating groups their own boundaries.

Global Systemically Important Bank (GSIB)

A large, highly regulated financial institution often needs to *separate* regions, regulated workloads, shared platform groups, and pre-production environments while keeping billing, identity, and governance** *centralized*.

Enterprise account**billing, identity, directory, governance

North America

regional admins + integrations

EMEA

EU residency + regional integrations

Shared Platform

platform integrations + central visibility

Regulated Workloads

strict controls + limited model access

Pre-production

sandbox, staging, service accounts

Global Consulting Firm

A consulting firm that organizes by project can keep one enterprise account while giving each project multiple scoped organizations for delivery, client-specific integrations, and controlled environments**.

Enterprise account**firm-wide billing + identity

Professional Services

delivery governance

Project A

project-level oversight

Project B

separate client boundary

Project A

Client Environment

client integrations +

service accounts

Project A

Restricted Work

custom controls +

usage limit

Project B

Client Environment

client-specific

integrations

Multinational Telecommunications Operator

A multinational telecom operator may organize Factory by geography, operating company, and infrastructure environment, giving each boundary its own residency, administration, integrations, and controls**.

Enterprise account

global governance + billing

Global Platform Services

shared tooling + central visibility

Europe Operating Company

EU residency where required

North America Operating Company

regional integrations

APAC Operating Company

regional admins

EU Regulated Infrastructure

restricted access + strict controls

EU Network Operations

local service accounts

APAC Network Infrastructure

local integrations + usage boundary