OpenAIの組織管理をコードで宣言する──公式Terraform providerを設定ファイルから読む

複数プロジェクト・複数メンバーでOpenAI APIの組織設定を管理していると、「誰がいつどの権限を追加したか」が画面操作の履歴に埋もれがちになる。2026年7月29日、OpenAIはこの組織管理をコードで宣言的に扱える公式Terraformプロバイダをリリースした。公式ガイド（developers.openai.com/api/docs/guides/terraform）でセットアップ手順を確認した。GitHub上のソースリポジトリ（openai/terraform-provider-openai）を確認すると、作成日は2026年6月25日で、GA公開（7月29日）の約1カ月前から開発が進められていたことが分かる。本記事執筆時点でスター29・フォーク5と、まだ規模の小さいリポジトリだ。

3行まとめ

• OpenAIが2026年7月29日、組織のプロジェクト・ユーザー・サービスアカウント等をコードで管理できる公式Terraformプロバイダをリリース。Admin APIキー必須でTerraform 1.0以上（importは1.5以上）が前提
• サブガイド「Import and reconcile」を読むと、openai_projectリソースをTerraform管理から外す（terraform destroy等）とプロジェクトがアーカイブされ、復元できないという重大な挙動がある一方、レート制限やホスト型ツール権限などは「Terraformの追跡を外すだけで、リモート側の設定は変わらない」という非対称な削除挙動になっている
• サービスアカウントのAPIキー自体はTerraformの管理対象外で、Administration API経由で別途作成・管理する設計。State fileにシークレットを残さないための意図的な設計だとみられる

最小構成のmain.tf

公式ガイドが示す最小構成は次の形だ。

terraform {
  required_version = ">= 1.0"
  required_providers {
    openai = {
      source  = "openai/openai"
      version = ">= 1.0.0"
    }
  }
}

provider "openai" {}

resource "openai_project" "example" {
  name = "terraform-managed"
}

Admin APIキーはOPENAI_ADMIN_KEY環境変数から読み込まれる。ガイドは「コミット履歴にAdmin APIキーを含めないこと」を明記しており、環境変数かシークレットマネージャーでの管理を前提とした構成になっている。OPENAI_ORG_ID・OPENAI_PROJECT_IDは任意設定で、未設定時はAPIキーから組織・プロジェクトが自動解決される。

terraform init→terraform fmt→terraform validate→terraform plan→terraform applyという標準的なTerraformワークフローがそのまま使える。.terraform.lock.hclをコミットしてプロバイダのバージョンを固定することが推奨されている。

用途別のガイドが5本用意されている

公式ドキュメントは、最小構成の後に用途別ガイドへ誘導する形になっている。

「Import and reconciliation」の存在は、すでに画面操作で作られた既存プロジェクトを後からTerraform管理下に移行できることを示している。ゼロから作り直す必要はない設計だ。

既存リソースの取り込みとID形式

「Import and reconciliation」ガイド（terraform/import-and-reconcile）を実際に読むと、既存プロジェクトをTerraform管理下に取り込む手順と、リソースごとのimport ID形式が具体的に示されている。

取り込みの手順は「設定ファイルを既存リソースの現状に合わせて書く→importブロックを追加→terraform planでno-op（変更なし）になることを確認してからapply」という流れで、terraform plan -detailed-exitcodeを使うと、変更なしなら終了コード0、変更ありなら2、エラーなら1が返る、という具体的なドリフト検知の方法も示されていた。

「削除」の挙動はリソースによって非対称——プロジェクトは復元不可

同じガイドの「Understand removal behavior」節には、実運用で見落とすと危険な注意点がある。Terraform設定からリソースブロックを削除しても、リモート側（OpenAI組織側）で起きることはリソースの種類によってまったく違う、という一覧だ。

つまり、「Terraformの設定ファイルからブロックを消せば、対応するOpenAI側の設定も元に戻る」という単純な思い込みは危険だ。プロジェクトを誤ってterraform destroyすると復元不可能なアーカイブ状態になる一方、レート制限などは逆にTerraformの管理下から外れるだけで実際の制限値はそのまま残り続ける。IaC（Infrastructure as Code）でよくある「消せば元に戻る」という前提が、リソースの種類によって成り立たない場合がある、という点は、実際に導入する前に知っておく価値のある挙動だ。

なお、サービスアカウント関連のサブガイド（terraform/service-accounts）を確認すると、サービスアカウントの識別情報（ID）自体はTerraformが管理する一方、「サービスアカウントのAPIキーの作成・管理はTerraformの外、Administration API経由で行う」と明記されている。APIキーという機密情報をTerraformのstateファイルに残さないための、意図的なスコープ限定だと考えられる。

AnthropicのAdmin API対応との比較

似た方向性の動きは競合にもある。Anthropicは同じ2026年8月に、Admin API（組織メンバー・招待・ワークスペース・APIキー・レート制限などを扱うAPI）をant CLIと各言語SDKに正式対応させている（当サイトの既報参照）。ただしAnthropic側はSDK・CLI経由での対応であり、公式Terraformプロバイダの提供は本記事の調査範囲では確認できなかった。OpenAIが先にTerraform providerという「IaC専用の入口」を用意した形になる。

個人開発者・小規模チームにとっての意味

Terraformでの組織管理が効くのは、複数人でOpenAIのプロジェクト・APIキーを運用しているチームだ。個人で1プロジェクトだけを使っている場合、画面操作で十分事足りることが多く、Terraform導入のコストに見合わない可能性がある。一方で、退職者のAPIキー失効漏れ、意図しないレート制限の変更といった「気づいたら設定が変わっていた」系の事故を防ぎたいチームには、構成をコードでレビューできる利点がある。

Admin APIキーを発行しての実地検証はしていない

本記事は公式ガイド本文（トップページ・「Import and reconciliation」・「Service accounts」の3本）とGitHub上のプロバイダリポジトリを情報源としている。ただし「Projects and access」「Rate limits and spend」「Model, tool, and data controls」の3本については見出しと概要のみの紹介にとどめ、本文までは読み込んでいない。自分の手元でAdmin APIキーを発行してTerraformを実際に適用する検証までは行っておらず、「プロジェクトのアーカイブは本当に復元できないか」「レート制限の削除挙動が記載通りか」といった点も、公式ドキュメントの記述をそのまま紹介したにとどまる。各リソースの詳細な引数は、公式ガイドがTerraform Registry側のリファレンスに委ねているため本記事では扱っていない。

関連記事: Claude・GPT・Gemini API料金の読み方 / Claude Code / Claude APIの2026年8月の変更点まとめ / OpenAI API、8月の実務変更5件

感想・指摘はコメント欄へ。