Organization as Codeとは、組織の構造・権限・業務手順・判断条件をコードで記述し、その記述に基づいて業務と統制を動かすことです。X as Code（何かの構造やルールをコードで記述し、それに基づいて動かす考え方）を、組織という対象に当てたものです。X as Codeの系譜と思想はX as Codeとは何か：何かを「記述して、動かす」思想とその系譜にまとめました。本稿は、その組織版を当社の考えで解説します。

先に、これを入れないと何が起きるかを書きます。規程を書いて共有ドライブに置く。承認は口頭とメールで回す。誰にどの権限があるかは担当者の頭の中にある。どれも回っているように見えます。事故は後で来ます。監査で承認の根拠を出せない。退職者しか経緯を知らない。権限が広いまま放置され、AIエージェントが想定しない操作を実行する。書いて棚に置いた規程は、動く統治にはなりません。

Organization as Codeとは

定義はこうです。

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

二つの段階に分かれます。

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

BCGは同じ考えを「Enterprise as Code」と呼び、業務の暗黙の運営モデルをコードとして書き出す構想を示しました。呼び名は問いません。組織を、人もシステムも読めて・試せて・直せる形で書き出し、その通りに動かす。ここでは、それをOrganization as Codeと呼びます。

誤解を避けるために一つ。これは人を機械のように制御する話ではありません。人の判断に委ねられていた運営モデルをコードで記述し、コードと人の判断を組み合わせて動かす、ということです。判断を人に残す場所こそ、どこで誰が何を根拠に決めるかをコードに書いておきます。

成文規程は、コードとして管理して初めて動く

成文規程は、書いて置くだけでは組織を動かしません。規程を権限・承認・ログ・実行ルールとしてコードに落として初めて、統制が実際の動作になります。誰がどの権限を持つか、何が記録に残るか、何を承認したら次へ進むか、AIがどのツールをどの条件で実行してよいか。これらがコードに落ちて初めて、規程は動きます。

ここでいう「コードとして管理する」には、もう一段あります。規程を承認や権限として実装するだけでなく、規程文書そのものをコードと同じ管理下に置きます。バージョン管理に規程を載せ、変更はレビューで通し、履歴を残す。いつ、誰が、なぜ変えたかが規程自体に刻まれ、旧版との差分も追えます。

ここは形式の選び方で決まります。バージョン管理で行単位に差分が取れるテキストなら、規程はそのままコードとして扱えます。逆に、PDFやWordで固めると、行単位の差分もレビューも履歴も付きません。同じ規程でも、テキストで書くか、固めた文書にするかで、あとから管理できるかどうかが変わります（この「何がコードか」はX as Codeの記事で整理しています）。仕組みはGitでも、用途に合わせて作り込んだ専用のバージョン管理でもかまいません。大事なのは道具の名前ではなく、規程に差分とレビューと履歴が付くことです。当社自身、規程やデータのバージョン管理に、汎用ツールだけでなく、用途を考慮して自前開発したシステムも運用しています。

成文規程が腐るのは、共有ドライブやポータルに置かれて履歴も承認も残らないからで、規程という形式が劣るからではありません。だから、成文規程を捨ててコードに置き換えるのではありません。成文規程を、コードとして管理するのです。

承認を例にします。承認が機能しているかは、証跡が自然に残っているかで分かります。後から根拠を探さないと出てこない承認は、コードではなく人の記憶に依存しています。判子は押されていても、何を根拠に通したのかが残っていない、という状態です。

公的なガイドラインは方針を示す。実装は事業者に残る

組織統治の方針は、公的な文書がすでに示しています。NISTのAI Risk Management Framework（AI RMF）は、GOVERN・MAP・MEASURE・MANAGEの4機能を置き、GOVERNで組織の責任と方針を扱います。日本のAI事業者ガイドライン（総務省・経済産業省、第1.2版）は、事業者の自主的な取組を促す非拘束的な指針であり、責任者の設定、ログの記録・保存、必要最小限のアクセス権なども扱っています。第1.2版では、AIエージェントに伴うリスク例と、それに対応する指針・対策例も追加されました。

ただし、具体的な承認フローを誰に割り当て、どのIAMポリシーや承認ゲートとして実装するかまでは規定していません。法律家はルールを書きますが、承認ゲートやIAMには落としません。学者は枠組みを示しますが、本番のパイプラインは組みません。ガイドラインが示す統制を、個別の業務システムで動くコードに変換する作業は残ります。当社が入るのは、この実装の部分です。

実装：権限・承認・ログをコードに落とす

コード化された権限・承認・ログに落とすのは、実装をやってきた人の仕事です。当社はTerraformやAWS、MCPで実装をしてきました。実際の提供案件でも、特定業務の指示プロンプトを、スクラッチ開発したシステムでバージョン管理し、ログを採っています。だから規程を、動くコードと、自動で残る証跡まで持っていけます。

機械に全部任せて済む、とは考えません。どこを見るかの当たりをつけて範囲を絞り、機械の実行と現場の確認で裏を取る。手を動かすのは、その工程が仕組みとして残る見込みがあるときです。頭数と時間で押し切って仕組みに残らない作業は、工程化の対象になりません。

最初の一手

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

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

まとめ

Organization as Codeとは、組織の構造・権限・業務手順・判断条件をコードで記述し、その記述に基づいて業務と統制を動かすことです。成文規程は、書いて終わりにできません。捨てるのでもありません。履歴・承認・レビューの効くコードとして管理して初めて、統治が動作になります。

方針は公的ガイドラインが示しました。ですが、方針を書く人と、それを実装できる人は別です。当社が業務に入ってやるのは、規程とプロンプトを、動くコードと残る証跡に移すことです。X as Codeという考え方の全体像は、X as Codeとは何かにまとめています。

参考・一次ソース

• AI Risk Management Framework（AI RMF 1.0、NIST。任意の枠組み）
• AI事業者ガイドライン（第1.2版、総務省・経済産業省。自主的取組を促すもの）
• Enterprise as Code: An Operating Model for the AI Era（BCG）
• X as Codeとは何か：何かを「記述して、動かす」思想とその系譜（アハクラフト）
• アハクラフト株式会社 AIプロダクションシステム（工程化・検収・品質基準で回す進め方）

■お問い合わせ

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

お問い合わせ