「企業のAIアーキテクチャは、設計ではなく積み重ねでできている」という指摘が話題になっています。AIのPoC、部門ごとのSaaS契約、コーディングエージェントによる開発の高速化。一つひとつは小さな変更でも、積み重なった結果は誰も設計していない全体像です。

一方で、アーキテクチャレビューを厳しくすると、審査待ちで案件が止まり、現場は正式な手続きを避けるようになります。本記事では、この二択から抜け出すための組み立て方を整理します。

課題 ― 審査が「関門」か「抜け道」になっている

アーキテクチャガバナンスとは、個々のシステム判断が全社のあるべき姿（EA：エンタープライズアーキテクチャ）から外れないようにする仕組みです。多くの企業では、その中心に審査会（ARB：アーキテクチャレビューボード）を置いています。

ところが現場では、次のどちらかに陥りがちです。

  • 関門化：あらゆる案件が審査会に集まり、開催を待つあいだに案件が止まる
  • 形骸化：審査対象の線引きが曖昧で、SaaS導入や小さな改修が審査を通らずに進む

どちらの場合も、「なぜその構成を選んだのか」という判断理由が残りません。数年後の刷新時に、誰も前提を説明できなくなります。

なぜ審査中心の統制は機能しなくなったのか

従来の審査は、大型案件が年に数件という前提で設計されていました。いまは変更の単位が小さく、数が多く、スピードが求められます。すべてを一つの会議体で見ようとすると、審査会がボトルネックになるのは構造的に避けられません。

また、AIを業務に組み込む判断は「どの判断をAIに任せるか」を含むため、システム図を見るだけの審査では論点を取りこぼします。

四つの部品で組み直す

審査会を強くするのではなく、審査会に来る前の段階で判断が揃う仕組みをつくります。

部品 役割 成果物
アーキテクチャ原則 現場が自分で判断できる基準を示す 原則集（判断の理由と例外条件付き）
審査の振り分け 案件の影響度に応じて審査の深さを変える 振り分け基準表
例外承認 原則から外れる判断を、期限と是正計画付きで認める 例外台帳
決定記録（ADR） 何を、なぜ、何と比較して決めたかを残す ADR（背景・決定・影響の短い文書）

TOGAFでも、審査会の設置、計画との適合性レビュー、原則から外れる場合の例外承認（ディスペンセーション）がガバナンスの要素として整理されています。ADR（Architecture Decision Record）は、開発の現場で広く使われる軽量な記録形式です。これを全社レベルの判断にも適用します。

何を審査し、何を任せるか

振り分けの軸は「影響範囲」と「元に戻しやすさ」です。

区分 例 扱い
全社に影響し、戻しにくい 基幹データの定義変更、全社共通基盤の選定 審査会で決定
部門内に閉じるが、戻しにくい 部門SaaSの本格導入、外部へのデータ連携 アーキテクトへの事前相談とADR
影響が小さく、戻しやすい 原則の範囲内の改修、期限付きのPoC 現場で判断し、ADRで事後共有

審査会の時間は、上の区分と例外承認に集中させます。それ以外は「判断は現場、記録は必須」とすることで、スピードと追跡可能性を両立できます。

進め方

  1. 既存の判断を棚卸しする：直近の主要な案件で、何が審査され、何が審査を経ずに進んだかを洗い出します
  2. 原則を少数に絞って定める：守られていない原則は削ります。原則ごとに「なぜ」と「例外にしてよい条件」を書きます
  3. 振り分け基準と記録の型を決める：ADRの書式は一枚程度に抑え、起案書のテンプレートに組み込みます
  4. 四半期ごとに例外台帳を見直す：期限切れの例外や、例外が繰り返される原則は、原則そのものの改定を検討します

審査を案件の起案・予算承認の流れに組み込むと、独立した手続きとして避けられることがなくなります。起案時の論点整理はプロジェクトの意思決定設計、システム全体の棚卸しはアプリケーションポートフォリオ管理とあわせて設計すると効果的です。

よくある失敗と回避策

失敗 回避策
原則が抽象的で、判断に使えない 原則ごとに適用例と例外条件を添える
例外承認が「事実上の免除」になる 期限と是正計画を必須にし、台帳で追う
ADRが書かれなくなる 起案書と一体化し、別作業にしない
審査会が技術議論の場になる 事業影響とトレードオフの判断に議題を絞る

まとめ

アーキテクチャガバナンスの目的は、現場の判断を止めることではなく、全体の整合を保ちながら判断を速くすることです。原則を共有し、影響度で審査を振り分け、例外は期限付きで認め、判断を記録に残す。この四つが揃えば、審査会は本当に議論すべき論点に集中できます。EAの立ち上げ全体の進め方はEAの始め方もご覧ください。

FAQ

Q. 審査会（ARB）は誰が議長を務めるべきですか。 全社の投資判断に責任を持つCIOやIT企画部門長が適任です。アーキテクトは論点整理と原則の解釈を担う方が、事業部門との対話が進みます。

Q. 小規模なIT部門でもADRは必要ですか。 必要です。むしろ人の入れ替わりの影響が大きい組織ほど、判断理由を残す価値は高くなります。書式は簡潔にし、主要な判断に限定して始めてください。

Q. AIエージェントの導入判断も同じ仕組みで扱えますか。 扱えます。ただし、権限や自律実行の範囲など固有の論点があります。詳しくはAIエージェントのガバナンス設計で整理しています。

参考資料