Project as Code（PaC）とは？IaCとの違い・YAML実装手順を解説

Project as Codeは、プロジェクトの型・ワークフロー・権限・自動化といった「進め方」そのものを宣言的なコード（YAML）として定義し、Gitで管理するアプローチです。管理ツールのUIをクリックして設定する代わりに、リポジトリ内のファイルに運用ルールを書き、変更はプルリクエストのレビューを通して反映します。ここで注意したいのが略語です。「PaC」という略号は、業界では Policy as Code（ポリシーをコード化する手法）を指すのが一般的で、Project as Codeは比較的新しい別の概念です。本記事はProject as Codeを主題に、定義・用語の整理・Infrastructure as Code（IaC）との違い・実際のYAML実装手順まで解説します。

まとめ

• Project as Codeは、work item の型・状態遷移・ロール・自動化を宣言的にコード化し、Gitで一元管理する手法。
• 変更は差分（diff）とプルリクエストでレビューする。UI操作では残らない「なぜ変えたか」が履歴に残り、構成のドリフトを防げる。
• 代表的な実装はプロジェクト管理ツールPlaneのProjects-as-Code（CLI「Plane Compose」）で、YAMLとコマンドで構成を適用する。
• 略語「PaC」は Policy as Code を指すことが多く、Project as Codeと混同しやすい。文脈で区別する。
• Infrastructure as Code（IaC）は「インフラ」、Project as Codeは「プロジェクト運営」を対象にする。対象は違うが、宣言的にコード化して再現性を得る思想は共通。

以下で、コード化する具体的な対象、IaCとの違い、YAMLとCLIによる実装手順を順に見ていきます。

Project as Codeの定義とコード化する対象

Project as Codeの核心は、プロジェクトの運用モデルを「ツール設定画面の中の状態」ではなく「リポジトリ内のファイル」として持つことです。プロジェクトごとにフォルダを切り、そこにルールを記述しておけば、フォルダを開くだけでそのプロジェクトがどう動くのかが分かります。これにより、新しいチームやリージョン、規制環境に対して同じ運用モデルを繰り返し立ち上げられるようになります。

宣言的に定義する4つの対象

PlaneのProjects-as-Code仕様では、コード化する要素を次の4区分で整理しています。独自の3分類で語られることもありますが、実装が公開しているこの区分を基準にすると、コード化の範囲を見失いません。

• Structure（構造）：work item の種類、必須フィールド、既定値の定義。
• Flow（フロー）：ワークフロー、状態（state）、状態遷移のルール。
• Control（制御）：ロールと権限（ツールが対応する範囲で）。
• Automation（自動化）：イベント起点のルール、スケジュール、エスカレーションポリシー。

目標・スコープ・KPIといったプロジェクト定義を書くこともできますが、まずはこの4区分のうち運用に直結する構造とフローから着手すると、コード化の範囲を見失いません。

GUI管理との違いは「差分で残る」こと

従来のプロジェクト管理は、管理画面での設定変更が中心でした。この場合、誰がいつ何を変えたのかが残らず、同じ設定を別プロジェクトへ再現するのも手作業になります。Project as Codeでは、ワークフローの変更が1つの差分になり、運用ポリシーの変更がレビュー可能な形で明示されます。「暗黙のルール」がファイルとして可視化され、Gitの履歴で監査できる点が最大の違いです。

「PaC」の略はPolicy as Codeが一般的｜用語の整理

Project as Codeを調べる前に押さえておきたいのが略語の衝突です。「PaC」という略号は、一般には Policy as Code を指します。Policy as Codeは、アクセス制御やセキュリティ、コンプライアンスのルールを自然言語ではなく専用言語で記述する手法で、代表的な実装がOpen Policy Agent（OPA）と、その記述言語Regoです。Policy as Codeは、こうした「as code」系の実践の一つとして語られます。

Infrastructure as Code、Configuration as Code、Policy as Code、Pipeline as Code——いずれも「対象を高水準の言語でコード化し、自動化・再現性・追跡性を得る」という同じ発想の派生です。Project as Codeもこの系譜にありますが、略すと Policy as Code と衝突するため、記事や社内資料では原則フルスペルで書き分けるのが安全です。検索意図としても「pac とは」でOPA（Policy as Code）を探している読者が混在するため、冒頭で対象を明示することが誤読を防ぎます。

Infrastructure as Code（IaC）との違い

Project as Codeと混同されやすいのがInfrastructure as Code（IaC）です。どちらも「as Code」の思想を共有しますが、コード化する対象と反映先が異なります。IaCはサーバーやネットワークなどのインフラ構成をコード化し、実行すると実際の環境が変化します。一方Project as Codeが扱うのはプロジェクトの運営ルールで、反映先は環境ではなく管理ツールの構成です。

IaCの代表格であるTerraformについてはHCP Terraform（旧Terraform Cloud）の解説も参考になります。両者は競合せず、Project as Codeでプロジェクトのスコープを定義し、その定義を起点にIaCが環境を構築する、といった連携も可能です。IaC（環境）とProject as Code（運営）はレイヤーが違う補完関係にあると捉えると使い分けやすくなります。

Project as Codeの実装手順とYAML例

抽象論だけでは掴みにくいので、PlaneのProjects-as-Codeを例に、実際のファイル構成とコマンドを示します。基本は「YAMLで構成を書く→差分を確認→適用する」という、IaCと同じ流れです。

ディレクトリ構成とYAML定義

プロジェクトごとにフォルダを切り、スキーマと自動化、作業項目をファイルに分けて配置します。次はPlaneが発表時に示したディレクトリ構成の例です。出荷済みのCLIではwork/workitems.yamlなどファイル名の細部が異なるため、実際に組む際はPlaneの開発者ドキュメントで最新の構成を確認してください。

projects/
  core-platform/
    plane.yaml          # プロジェクトのメタ情報と既定値
    schema/
      types.yaml        # work item の種類（Structure）
      workflows.yaml    # 状態と遷移ルール（Flow）
      labels.yaml
    automations/
      sla-escalation.yaml   # エスカレーション（Automation）
    work/
      backlog.yaml

入口となるplane.yamlには、ワークスペースやプロジェクトキー、新規work itemの既定値などを書きます。

workspace: acme
project:
  key: CORE
  name: Core Platform
defaults:
  work_item_type: task
  state: backlog
  priority: medium

状態と遷移（Flow）はworkflows.yamlに分離しておくと、フローだけを差し替えて別プロジェクトへ再利用できます。フィールドの型や既定値（Structure）はtypes.yamlにまとめます。

CLIによる適用とレビューの流れ

記述したYAMLは、CLI「Plane Compose」でワークスペースへ適用します。主なコマンドは次の通りです。

• plane init：設定ファイル一式を初期生成する。
• plane pull：ワークスペースの最新スキーマをローカルへ取得する。
• plane status：ローカルとワークスペースの差分（適用予定の変更）を表示する。
• plane push：ローカルの変更をワークスペースへ反映する。

運用のポイントは、plane pushを個人が直接叩くのではなく、YAMLの変更をプルリクエストにしてレビューを通すことです。plane statusで差分を提示し、承認後にCIからplane pushを実行すれば、プロジェクト構成の変更もソースコードと同じ品質ゲートを通せます。Gitを中心に据える運用は、GitOpsの考え方とも地続きです。

導入のメリットと採用を見送るべき場面

Project as Codeの利点は、再現性・監査性・ドリフト防止の3点に集約されます。運用モデルがテンプレート化されるため、新しいチームや製品ラインでも同じ品質のプロジェクトを短時間で立ち上げられます。変更がGit履歴に残るので、監査や原因追跡も容易です。一方で、あらゆる現場に向く手法ではありません。

採用を急がないほうがよいケース

次のような場合は、コード化の初期コストが便益を上回りやすく、導入を見送るか部分導入に留めるのが現実的です。単発で終わる小規模プロジェクトは、構成を再利用する機会が乏しく、YAML化の手間が回収できません。メンバーの多くが非エンジニアで、GitやYAMLの学習コストが重い組織も、GUIとの併用から始めるべきです。使っている管理ツールがコードによる構成適用（Project as Code対応のCLIやAPI）を備えていない場合は、そもそも仕組みが成立しません。まずは対応ツールの有無と、構成を繰り返し使う頻度を確認してから判断してください。

AI駆動開発におけるProject as Code

AIがタスクの並びやスケジュールを提案する開発では、提案内容を「そのまま人が承認して終わり」にすると、なぜその構成になったのかが残りません。Project as Codeを併用すると、AIが提案した変更もYAMLの差分として表現され、プルリクエストのレビューと履歴管理の対象になります。学習データやモデルのバージョン、実験条件をコード化して管理すれば、性能変化の原因も差分で追跡できます。AIの提案を再現可能な形で固定できる点が、Project as CodeとAI駆動開発の相性の良さです。過度な自動化に走らず、承認フローを差分に組み込むことが、透明性を保つ鍵になります。

よくある質問

Project as Code（PaC）とは何の略ですか？

Project as Codeの略です。ただし「PaC」という略号は、業界では Policy as Code（ポリシーのコード化）を指すのが一般的で、混同されやすい点に注意が必要です。文脈やフルスペルで区別してください。

Infrastructure as Code（IaC）との違いは何ですか？

コード化する対象が異なります。IaCはサーバーやネットワークなどのインフラ構成を対象にし、実行すると環境が変わります。Project as Codeはプロジェクトの型・フロー・権限・自動化を対象にし、反映先は管理ツールの構成です。宣言的にコード化する思想は共通です。

どんなツールで実現できますか？

プロジェクト管理ツールPlaneのProjects-as-Code（CLI「Plane Compose」）が代表例です。仕組みとしては、YAMLで構成を記述し、Gitで変更を管理し、CIから適用コマンドを実行する構成になります。

非エンジニアでも使えますか？

GitやYAMLの基本操作が前提になるため、非エンジニア中心のチームでは学習コストが課題です。可視化ダッシュボードやGUIと併用し、小さな範囲から段階的に広げるのが現実的です。

Policy as Codeとの違いは何ですか？

対象領域が異なります。Policy as Code（OPA/Rego等）はアクセス制御やコンプライアンスのルールをコード化する手法で、Project as Codeはプロジェクトの運営ルールをコード化する手法です。略号「PaC」は前者を指すことが多いため、Project as Codeはフルスペルで書くのが安全です。

関連記事

• HCP Terraformとは？旧Terraform Cloud（名称変更）の機能・料金とHCPでの位置づけを解説
• Gitless GitOpsとは？OCIレジストリ中心のGitOps新方式を仕組み・導入まで解説
• Open Policy Agent（OPA）とは？Policy as Codeを実現する汎用ポリシーエンジンを解説
• Regoとは？OPA 1.0（Rego v1）の書き方とv0コード移行・テストの実装ガイド