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

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

X as Codeとは何か

定義はこうです。

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

二つの動詞に分かれます。

どちらか一方では足りません。記述に基づいて動かす、この二つがそろって初めて、書いた通りに対象が動きます。

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

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

ルールを人の記憶ではなく、実行されるコードに置く。OPAがGraduatedに達したことは、この考え方がそれだけ広く採用されたことを示します。

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

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

Enterprise as Code：組織に適用する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初の一手

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

まとめ

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

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

参考・一次ソース

■お問い合わせ

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

お問い合わせ