X as Codeとは、何かの構造やルールをコードで記述し、そのコードに基づいてそれを動かす、という考え方です。インフラ、設定、ポリシー、ドキュメント。この十数年、対象を替えながら同じ形が繰り返されてきました。本稿は、その系譜をたどり、当社がこの考え方を組織と規程、プロンプト、AIエージェントまで延ばす理由を書きます。

先に、これを入れないと何が起きるかを書きます。規程を書いて共有ドライブに置く。プロンプトを本番に流す。エージェントに広い権限を渡す。どれも書いた時点では動いて見えます。事故は後で来ます。承認の根拠が残っておらず、監査で説明できない。プロンプトを誰がいつ何のために変えたか追えない。権限を絞っていないエージェントが、想定しない操作を実行する。書きっぱなしが、そのまま損になって返ってきます。

X as Codeとは何か

定義はこうです。

X as Codeとは、Xの構造やルールをコードで記述し、そのコードに基づいてXを動かすこと。

二つの動詞に分かれます。記述するは、手作業や頭の中にあった手順・判断を、人もシステムも読める形で外に出すことです。動かすは、その記述に基づいて対象を実際に走らせることです。どちらか一方では足りません。記述だけなら、書いた文書が現場と食い違っていても気づけません。動かすだけなら、なぜそう動くのかを後から追えません。記述に基づいて動かす、この二つがそろって初めて、書いた通りに対象が動きます。

その系譜：インフラから始まり、対象を替えて広がった

この形は、まずインフラで定着しました。系譜をたどります。

• Infrastructure as Code（IaC）。サーバやネットワークを手で設定する代わりに、設定ファイルに書きます。HashiCorpはTerraformを「人が読める設定ファイルにインフラを定義し、バージョン管理・再利用・共有できるツール」と説明します。書いたファイルから同じ環境を何度でも再現でき、変更が履歴に残ります。
• Configuration as Code。アプリやCI/CDの設定を、画面のクリックではなくファイルに書きます。設定の食い違いを、差分として見えるようにします。
• Policy as Code。「これは許可か」というルールをコードに書き、システムの判断に組み込みます。代表がOpen Policy Agent（OPA）です。OPAは2021年2月4日、Cloud Native Computing Foundation（CNCF）で最上位の成熟段階「Graduated（卒業）」に達しました。ルールを人の記憶ではなく、実行されるコードに置くという考え方が、それだけ広く採用されたということです。
• Docs as Code。ドキュメントを、コードと同じ道具で書きます。Write the Docsはこれを「コードと同じツールでドキュメントを書くべきだという思想」と定義し、課題管理・バージョン管理（Git）・レビュー・自動テストを道具として挙げます。
• GitOps。運用の望ましい状態をGitに書き、システムをその状態へ収束させます。手で本番を触るのではなく、記述を変えて動かす、という運用です。
• Enterprise as Code。BCGは、業務の暗黙の運営モデルまでコードとして書き出す構想を示しました。対象が、機械の設定から組織の運営そのものへ移ります。マッキンゼーの「AIの組み立てライン」も、同じ方向を別の言葉で描いたものです。

対象は替わっても、やっていることは一つです。頭の中や手作業にあったルールを、読めて・試せて・直せる形で外に出し、その記述に基づいて対象を動かす。ここで大事な点を一つ。バージョン管理・レビュー・履歴・自動で残る証跡は、この定義そのものではありません。こう記述して運用するから初めて効く管理方法であり、定義を満たした結果として付いてきます。順番を取り違えると、道具（Git）を入れれば済む話に見えてしまいます。

加えて「コード」の範囲をはっきりさせます。バージョン管理で行単位に差分が取れるテキストは、それだけでコードとして扱えます。設定ファイルも、ポリシーも、ドキュメントも、成文規程も、テキストである限り同じ土俵に乗ります。外れるのは、PDFやWordのように中身を行単位で追えない形式です。同じ規程でも、テキストで書けば差分・レビュー・履歴が付き、固めた文書にすれば付きません。どの形式で書くかを選んだ時点で、あとから管理できるかどうかが決まります。

Enterprise as Code：組織に適用する

この考え方を組織に当てると、こうなります。

組織の構造・権限・業務手順・判断条件をコードで記述し、そのコードに基づいて業務と統制を動かす。これが当社の考えるEnterprise as Codeです。

ここにも、二つの段階があります。

• コードで組織を記述する。誰が何を担当するか、誰にどの権限があるか、どの条件で承認が必要か、例外時に誰へエスカレーションするかを明示します。
• コードで組織を動かす。記述されたルールに基づいて、業務の割り当て、権限制御、承認、AIエージェントの実行、ログ記録を実際に行います。

BCGはこれを「直感から仕様へ」の移行と呼び、ガバナンスと統制を後付けではなく最初からロジックに組み込め、と書いています。「自動化は秩序を生まない。秩序に依存する」という一文もあります。ここまでは絵です。その秩序を、承認ゲート（リリース前に人の承認を挟む仕組み）やIAM、ログにどう落とすか。絵を描くことと、それを実装することは違います。当社が立つのは、実装の側です。この考え方を組織という対象に落とし込んだ解説は、Organization as Codeとは：AI時代の組織統治を、成文規程もコードとして管理するで書いています。

「人をコードで動かす」のではない

「組織をコードで動かす」とだけ言うと、人まで機械のように制御する話に聞こえます。そうではありません。正確に言うとこうです。

人の判断に委ねられていた組織の運営モデルをコードで記述し、コードと人の判断を組み合わせて動かす。

当社らしい短い言い方にすると、こうなります。

組織をコードで記述する。コードに基づいて動かす。人の判断が必要な場所も、コードで明確にする。

人をコードで動かすのではありません。人とAIが働くための運営モデルをコードにする、という説明です。むしろ、判断を人に残す場所こそ、どこで誰が何を根拠に決めるかをコードに書いておきます。判断を消すのではなく、判断の場所を記述する。ここが「人を機械で回す」との分かれ目です。

この発想には下敷きがあります。トヨタ生産方式の自働化（じどうか）です。トヨタは自働化を「automation with a human touch（人の知恵を加えた自動化）」と説明し、異常が起きたら機械が自ら止まり、人がその場に来て対処する仕組みに置きます。人が機械をただ見張る必要をなくす一方で、判断が要る場所は人に戻す。全部を機械に流し切るのではなく、止まって人を呼ぶ点を最初から設計に組み込む、という考え方です。McKinseyが引くフォードの組み立てラインが「流す」側なら、自働化は「止めて人に渡す」側です。Enterprise as Codeでいえば、この「止まって人を呼ぶ点」が、次章の検収ゲート・承認・エスカレーションに当たります。

AIプロダクションシステム：運営モデルを回す規律

Enterprise as Codeが「組織を何として表すか」なら、AIプロダクションシステムは「その運営モデルを実際に回す進め方」です。属人的な作業を工程に分け、AIとシステムに載せ替え、検収と品質基準と証跡で回します。

ここで「人の判断が必要な場所」は、工程の中の検収ゲート・承認・エスカレーションとして置きます。工程を通ると、判断が自然に証跡として残ります。後から根拠を探さないと出てこない承認は、コードではなく人の記憶に依存しています。判子は押されていても、何を根拠に通したのかが残っていない、という状態です。

工程に載せるとき、機械に全部任せて済むとは考えません。ログを総ざらいすれば全部拾える、とは書きません。どこを見るかの当たりをつけて探索範囲を絞り、そのうえで機械の実行と現場での確認で裏を取る。この当たりをつける経験こそ、記述に落とす価値があります。手を動かすのは、その工程が仕組みとして残る見込みがあるときです。頭数と時間で押し切って仕組みに残らない作業は、工程化の対象になりません。

まだ線が引かれていない領域へ延ばす

系譜を並べると、次に線を引く場所が見えます。プロンプト、AIエージェント、成文規程です。ここにはまだ、確立した as Code がありません。だからこそ、確立領域で証明済みの管理術を、そのまま延ばせます。

• プロンプトをコードとして扱う。プロンプトは新しいコードです。書きっぱなしにすれば、コードを管理しないのと同じ事故が起きます。プロンプトインジェクションは、外部入力を信じて流すという点で、SQLインジェクションと同じ型です。バージョン管理・承認・ログを付ければ、コードに積み上げてきた管理がそのまま効きます。
• 成文規程をコードとして管理する。規程を承認や権限として実装するだけでなく、規程文書そのものをコードと同じ管理下に置きます。バージョン管理に規程を載せ、変更はレビューで通し、履歴を残す。いつ、誰が、なぜ変えたかが規程自体に刻まれ、旧版との差分も追えます。Docs as Codeの延長です。成文規程が腐るのは、共有ドライブやポータルに置かれて履歴も承認も残らないからで、規程という形式が劣るからではありません。

仕組みはGitでも、用途に合わせて作り込んだ専用のバージョン管理でもかまいません。大事なのは道具の名前ではなく、記述に差分とレビューと履歴が付くことです。当社自身、規程やデータのバージョン管理に、汎用ツールだけでなく、用途を考慮して自前開発したシステムも運用しています。実際の提供案件でも、特定業務の指示プロンプトを、スクラッチ開発したシステムでバージョン管理し、ログを採っています。実装はTerraformやAWS、MCPで積み上げてきました。だから規程やプロンプトを、動くコードと、自動で残る証跡まで持っていけます。

最初の一手

「うちは小さいから、そこまでの仕組みは要らない」という読み方が出ます。ですが、記述して動かす形は、1つの経路からでも始められます。むしろ小さく始めたほうが、記憶に頼った承認がどこにあるかが見えます。

1. 規程をバージョン管理に載せる。変更はレビューで通し、いつ誰がなぜ変えたかを履歴に残す（記述する）
2. プロンプトをコードとして扱う。バージョン管理・承認・ログを付ける（記述する）
3. その記述に基づいて動かす。エージェントに渡す権限を絞り、rootのまま動かさない（動かす）
4. 承認の証跡が自然に残るかを確かめる。後から探す状態なら、コードに移す（動かす）

まとめ

X as Codeとは、何かの構造やルールをコードで記述し、その記述に基づいて動かす考え方です。インフラから始まり、設定・ポリシー・ドキュメント・運用へと、対象を替えて広がってきました。次に線を引く場所は、組織の運営モデルと、成文規程、プロンプト、AIエージェントです。

当社の言い方はこうです。組織をコードで記述する。コードに基づいて動かす。人の判断が必要な場所も、コードで明確にする。絵を描く人と、実装できる人は別です。当社が業務に入ってやるのは、規程とプロンプトを、動くコードと残る証跡に移すことです。

参考・一次ソース

• Terraform: What is Infrastructure as Code?（HashiCorp。IaCの説明）
• Open Policy Agent（OPA。Policy as Codeのエンジン）
• CNCF、Open Policy Agentの卒業を発表（2021年2月4日）
• Docs as Code（Write the Docs。ドキュメントas Codeの定義）
• Toyota Production System（トヨタ自動車。自働化＝automation with a human touch の説明）
• Enterprise as Code: An Operating Model for the AI Era（BCG）
• The AI assembly line: strategic imperatives for CEOs（McKinsey & Company）
• アハクラフト株式会社 AIプロダクションシステム（工程化・検収・品質基準で回す進め方）

■お問い合わせ

規程やプロンプト、エージェントの権限・承認・ログが「記述して動かす」形になっているかを診て、記憶に頼った承認を、動くコードと残る証跡に移したいときは、アハクラフトにご相談ください。

お問い合わせ