COLUMNS

TOP　＞　COLUMNS
AI時代、組織は成文規程ではなく、意思決定も承認も権限もコードで統治される
2026.06.18

BCGは業務をコードのように定義する「Enterprise as Code」、マッキンゼーはエージェントを並べて回す「AIの組み立てライン」を示しました。組織はコード化され、組み立てラインのように運営される、というイメージです。

同じことを、当社は実装の側から言ってきました。AI時代、組織を統治するのは成文規程だけではありません。コードに書かれた権限・ログ・承認・実行ルールも、組織を動かします。では、それを誰が設計し、実装できるのでしょうか。

組織はコード化され、組み立てラインのように回り始めた

BCGの「Enterprise as Code」は、業務の暗黙の運営モデルを捉えて、コードとして書き出す構想です。BCGはこれを「直感から仕様へ」の移行と呼びます。手順や判断のルールを、人もシステムも読めて、試せて、直せる形にする、という考えです。

そのうえでBCGは、運営ロジックを書き出すときに、ガバナンスと統制を「後付けではなく最初から、そのロジックに組み込め」と書いています。「自動化は秩序を生まない。秩序に依存する」という一文もあります。同じ方向を、マッキンゼーは「AIの組み立てライン」と呼びました。各社向けのエージェントが部門をまたいで仕事を片づけ、意思決定の過程まで工業化する、という構想です。

2社は絵を描きました。マッキンゼー自身も、複雑な案件はエージェントが人にエスカレーションして「説明責任と信頼を保つ」と書いています。ですが、その説明責任を、承認ゲート（リリース前に人の承認を挟む仕組み）やIAM、ログにどう落とすかまでは書きません。絵を描くことと、それを実装することは違います。当社が立つのは、実装の側です。

成文規程だけでは、組織はその通りに動かない

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

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

ルールを書いてきた人は、実装したことがない

ここに当社の見立てがあります。ルールを書いてきた人たちは、それを実装したことがありません。

法律家はルールを書きますが、承認ゲートやIAMには落としません。学者は枠組みを示しますが、本番のパイプラインは組みません。どちらも書く側で止まります。

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

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

コード化された権限・承認・ログに落とすのは、実装をやってきた人の仕事です。当社はTerraformやAWS、MCPで実装をしてきました。だから規程を、動くコードと、自動で残る証跡まで持っていけます。当社が持っているのは、この実装側のコンセプトです。

コードのインシデントが、プロンプトで再現する

実装の側から見ると、これから起きることが見えます。コードで起きてきたガバナンス不足の事故が、プロンプト群で制御される企業やサービスで、そのまま再現します。

並べてみると同じ構造です。

  • プロンプトは新しいコードです。書きっぱなしにすれば、コードを管理しないのと同じ事故が起きます
  • プロンプトインジェクションは新しいSQLインジェクションです。外部入力を信じて流せば、同じ型で破られます
  • 権限設計を知らないままエージェントを動かすのは、rootで本番を回すのと同じです
  • プロンプトにバージョン管理も承認もログもないのは、レビューなしで本番へデプロイするのと同じです

どれも、コードの現場を通った人には見覚えのある事故です。AIで新しく見えるだけで、構造は同じです。だから、コードに対して積み上げてきた管理を、そのままプロンプトとエージェントに持ち込めます。

全社の号令と、1つのパイプラインの実装は別レイヤー

BCGもマッキンゼーも、大手のCEOが全社のオペレーティングモデルを作り替える話として書いています。当社が入るのは、その手前です。1つの業務、1つのパイプラインで、権限・承認・ログがコードに落ちているかを診て、落ちていなければ実装します。射程が違います。

「うちは小さいから、そこまでの仕組みは要らない」という読み方が出ます。ですが、プロンプトのバージョン管理や、エージェントの権限を絞ることは、1つの経路からでも始められます。むしろ小さく始めたほうが、記憶に頼った承認がどこにあるかが見えます。

最初の一手はこうです。

  1. プロンプトをコードとして扱う。バージョン管理・承認・ログを付ける
  2. エージェントに渡す権限を絞る。rootのまま動かさない
  3. 承認の証跡が自然に残るかを確かめる。後から探す状態なら、コードに移す

まとめ

AI時代、組織は成文規程だけではなく、コードに書かれた権限・ログ・承認・実行ルールでも統治されます。BCGもマッキンゼーも、その絵を描きました。

ですが、絵を描く人と、実装できる人は別です。ルールを書いてきた人は、実装したことがありません。当社が業務に入ってやるのは、規程を、動くコードと残る証跡に移すことです。

参考・一次ソース

■お問い合わせ

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

お問い合わせ