法務OSの設計図(Legal Architecture)|法務判断を管理する6層リーガルアーキテクチャ|Legal GPT
法務OSシリーズ 第2回

法務OSの設計図(Legal Architecture)
法務判断を管理する6層リーガルアーキテクチャ

── 業務プロセスの5層フレームワークを、システムとして実装するための内部構造を設計する。Intake → Orchestrator → Rule → Reasoning → Execution → Audit

Legal GPT|法務OSシリーズ 第2回|2026年3月

01法務DXの限界 ── ツールを入れても「判断」は管理されない

前回の記事では、法務部に必要なのは契約レビューAIではなく「法務OS」であるという概念を提唱し、業務プロセスを5層フレームワーク(Intake → Analysis → Negotiation → Decision → Assurance)で整理しました。

しかし、この記事を書いた後に確信したことがあります。

5層フレームワークは「業務の地図」である。
しかし、地図だけでは道は走れない。
道を走るためには「エンジンの設計図」が必要である。

現在の法務DXには、致命的な盲点があります。

契約レビューAI、契約管理、文書検索──これらは確かに個々のタスクを効率化します。しかし、これらを導入しても法務の判断プロセスそのものは管理されていません

つまり、現在の法務DXの正体はこうです。

法務DXの限界を示す図 現在の法務DX(契約レビューAI・契約管理・文書検索)はツールDXにとどまり、判断プロセスは管理されていない 現在の法務DX 契約レビューAI 契約管理 文書検索 = 実態 ツールDX 判断プロセスは 管理されていない
図1:法務DX = ツールDX にとどまっている現状

AIツールを入れること自体が問題なのではありません。問題は、ツールの導入が法務のゴールだと誤解されていることです。法務のゴールは「判断の品質と説明責任の担保」であり、ツールはそのための手段の一つに過ぎません。

02法務判断の問題 ── 意思決定のブラックボックス

企業法務の本質は意思決定です。契約を通すか、止めるか。リスクを取るか、取らないか。例外を認めるか、認めないか。

しかし現実を見てください。この意思決定プロセスは、ほとんどの企業で属人化しています。

意思決定の場面現状(多くの企業)リスク
契約リスク判断担当者の経験と勘担当者不在時に判断基準が消失
例外承認口頭やチャットで了承後から「誰が」「なぜ」承認したか不明
稟議判断前例踏襲 or 感覚同じリスクでも担当者によって判断がブレる
内部統制・監査対応散在するメール・メモ監査時に証跡を再構成できない

つまり、法務部門の最大のリスクは外部からの法的リスクではなく、判断のブラックボックス化です。誰が、どの情報を見て、どのルールに基づいて、何を判断したのか──これが追跡できない状態は、企業にとって本質的なガバナンスリスクです。

03Legal Architecture ── 法務OSの内部設計

前回の5層フレームワークは、法務業務のプロセスを整理する「業務レイヤー」でした。

しかし、これを実際にシステムとして実装するには、もう一段深い設計図が必要です。

それが Legal Architecture(リーガルアーキテクチャ)である。

Legal Architecture とは、法務OSの内部構造──
法務判断がどのように受け付けられ、処理され、記録されるかを定義するシステムアーキテクチャである。

二階建て構造 ── 業務レイヤーとシステムレイヤー

法務OSは「二階建て」で理解するのが最も明快です。

法務OSの二層モデル 第1回の5層業務フレームワーク(Intake、Analysis、Negotiation、Decision、Assurance)と、第2回の6層システムアーキテクチャ(Intake、Orchestrator、Rule、Reasoning、Execution、Audit)の二階建て構造 法務OSの二層モデル 第1回:業務フレームワーク(WHAT) 法務は「何を」するのか ── 業務プロセスの地図 Intake 相談受付 Analysis リスク分析 Negotiation 交渉 Decision 稟議・承認 Assurance 証跡管理 実装するには? 第2回:システムアーキテクチャ(HOW)── 本記事 法務は「どう」動くのか ── エンジンの設計図 LAYER 1 Intake 入口 LAYER 2 Orchestrator 司令塔 LAYER 3 Rule 法務知識 LAYER 4 Reasoning AI推論 LAYER 5 Execution 成果物生成 LAYER 6 Audit 証跡・監査
図2:法務OSの二階建て構造 ── 業務の「WHAT」をシステムの「HOW」で支える

第1回の5層は「法務業務として何をするか」を定義しました。第2回の6層は「それをシステムとしてどう動かすか」を定義します。この二階建てが、法務OSの設計全体像です。

046層アーキテクチャの全体像

Legal Architectureの核心は、法務判断の流れを6つのシステム層に分離して管理することです。

Legal Architecture 6層システムアーキテクチャ Intake、Orchestrator、Rule、Reasoning、Execution、Auditの6層構造。Layer 6のAuditが企業法務の核心 Legal Architecture ── 6 Layer System LAYER 1 Intake ── ユーザーインターフェース 事業部からの入力を構造化して受け取る入口 LAYER 2 Orchestrator ── 処理フロー管理(OSの核心) 何を・どの順に・誰が処理するかを制御する司令塔 LAYER 3 Rule ── 法務ナレッジベース 法令・社内規程・判断基準をコードとデータで管理 LAYER 4 Reasoning ── AI推論エンジン Ruleに基づいてAIが法的推論・リスク評価を実行 LAYER 5 Execution ── 成果物生成 稟議書・レポート・引継ぎメモなどの実務文書を出力 LAYER 6 Audit ── 証跡・監査・説明責任 誰が・どのルールで・どう判断したかを記録し、監査に備える 企業法務の 核心 OS核心
図3:Legal Architecture ── 法務OSの6層システムアーキテクチャ
ポイント この6層で最も重要なのはLayer 6(Audit)です。一般的なAIツールにはこの層がありません。しかし企業法務において「判断の説明責任」を担保するためには、証跡層が不可欠です。これが法務OSとAIツールの根本的な違いです。

なぜ Rule と Reasoning を分離するのか

多くのAIツールは「AIに聞く=判断」という一体構造です。しかし法務OSでは、Rule(法務知識)とReasoning(AI推論)を明示的に分離しています。

RuleとReasoningの分離設計 一般AIツールはAIが知識と推論を一体で処理するブラックボックス。法務OSはRule(法務知識)とReasoning(AI推論)を分離して管理する 一般的なAIツール AI 知識も推論も 一体のブラックボックス vs 法務OS Rule(法務知識) 法令・規程・判断基準 Reasoning(AI推論) Ruleに基づく推論実行 分離して管理
図4:Rule と Reasoning の分離 ── 法務OSのアーキテクチャ上の核心的設計判断

この分離は、リーガルエンジニアリングとしてきわめて重要です。なぜなら、AIの推論結果が正しいかどうかを検証するためには、参照元の知識(Rule)が明示されていなければならないからです。RuleとReasoningが一体化している限り、「AIがなぜそう判断したのか」は説明できません。

05各層の詳細設計

LAYER 1
Intake ── ユーザーインターフェース
「何を法務に依頼するのか」を構造化して受け取る入口

事業部門からの法務相談を、自由テキストではなく構造化された入力として受け取る層です。案件種別、リスク領域、緊急度を事業部自身に選択させることで、法務のトリアージコストを劇的に下げます。

Legal GPTが公開している法務相談受付の仕組み化は、この層の設計思想に基づいています。「確認お願いします」だけの依頼を、意味のある情報として受け取るためのインターフェース設計です。

実装例:legal_gateway.py ── セルフチェック付き法務相談フォーム
LAYER 2
Orchestrator ── 処理フロー管理
法務OSの「カーネル」── 何を・どの順に・誰が処理するかを制御する

これがLegal Architectureの核心です。コンピュータのOSでいうカーネルに相当します。

Orchestratorは、Intake層から受け取った案件情報に基づいて、以下を自動的に制御します。

どの処理パイプラインを使うか(NDA用、M&A用、労務用など)。どの順番で各層を呼び出すか。例外処理やエスカレーションをどう扱うか。

一般的なAIツールにはこの「処理フローの管理」がありません。だからツールを入れても「バラバラのアプリ」になるのです。

実装例:orchestrator.py ── 案件種別ごとのパイプライン定義と実行制御
LAYER 3
Rule ── 法務ナレッジベース
法令・社内規程・判断基準を「コードとデータ」として管理する

法務の判断根拠となる知識を、属人的な暗黙知ではなく、構造化データとして外部化する層です。

例えば、「この種の契約で必ず確認すべき論点」「過去に問題になったリスクパターン」「稟議承認に必要な条件」──これらを人間の頭の中ではなく、設定ファイルやデータベースとして管理します。

実装例:rules.yaml / memo_templates.yaml ── 法務知識の構造化定義
関連記事 【法務×AI】自作ツール開発の要件定義10STEP|稟議・監査に通る設計の作法── Rule層に格納する法務知識を「要件定義」として整理する方法を解説しています。
LAYER 4
Reasoning ── AI推論エンジン
Rule層の知識に基づいてAIが法的推論・リスク評価を行う

ChatGPT、Claude、Geminiなどの生成AIが動く層です。ただし、この層のAIは単独で判断するのではなく、Rule層のナレッジに基づいて推論するという設計上の制約があります。

これにより「AIが勝手に判断した」という事態を防ぎ、AIの出力に対して常に「どのRuleを参照したのか」を追跡できます。

実装例:llm_gateway.py ── Rule参照付きのプロンプト実行とレスポンス管理
関連記事 オフラインAIで作る理由──外部送信NGの現場で法務ツールを動かす設計思想── Reasoning層をオフラインで構築する際のアーキテクチャ設計を解説しています。
LAYER 5
Execution ── 成果物生成
稟議書・レポート・引継ぎメモなどの実務文書を出力する

Reasoning層の分析結果を、実際の業務で使える形に出力する層です。

稟議書、リスク評価レポート、契約交渉の引継ぎメモ、内部統制向けの承認記録──これらの「成果物」を、フォーマットに沿って自動生成します。

実装例:memo_generator.py / handover_generator.py ── テンプレート準拠の文書生成
関連記事 稟議書作成が面倒すぎたので無料ツールを作った話──契約書ドロップで自動生成── Execution層の実装例として、稟議書自動生成ツールの設計と運用を紹介しています。
LAYER 6 ── 企業法務の核心
Audit ── 証跡・監査・説明責任
誰が・どのルールで・どう判断したかを記録し、事後検証に備える

これが法務OSと一般的なAIツールを決定的に分ける層です。

Audit層は、すべての法務判断について以下を自動的に記録します。

誰が判断したか。どの情報(Rule)を参照したか。AIが何を推論(Reasoning)したか。最終的にどう決定したか。例外があった場合、その理由は何か。

これらの証跡が存在することで、監査や内部統制の場面で「なぜこの契約を通したのか」に即座に回答できます。

実装例:audit_logger.py / legal_os.db ── 判断証跡の自動記録と検索
関連記事 監査で問われる「契約承認の根拠」── 逸脱理由まで残す内部統制の作り方── Audit層が実務でどのように機能するかを、内部統制の文脈で解説しています。
PROMPT COLLECTION
法務OSの各層を支えるプロンプト設計
法務OSの6層それぞれで、AIプロンプトが「推論エンジン」として機能します。
契約レビュー、リスク評価、稟議書生成、コンプライアンスチェック──100本のプロンプトが、法務判断の品質を底上げします。
法務AIプロンプト集100選を見る →

06End-to-End ワークフロー ── 法務業務自動化ライン

6層アーキテクチャが実際の業務でどう動くのか。ここでは、契約レビュー案件を例にしたEnd-to-Endのフローを示します。

法務業務自動化ライン End-to-Endフロー 事業部入力、自動マスキング、AI分析、稟議書自動生成、アラート・承認フロー、証跡保存の6ステップで構成される契約レビューの自動化パイプライン 法務業務自動化ライン ── End-to-End Flow 1 事業部が法務相談フォームに入力 Intake層:案件種別・取引先・金額・緊急度を構造化入力 2 契約書をアップロード → 自動マスキング Orchestrator層:個人情報・機密情報を自動検出し、墨消し処理を実行 3 法務ルールに基づくAI分析 Rule層 + Reasoning層:論点抽出・リスクスコアリング・類似案件照合 4 稟議書・レポート自動生成 Execution層:リスク評価レポート+稟議書をテンプレート準拠で出力 5 アラート+承認フロー実行 Orchestrator層:重要論点フラグ → 担当者通知 → 承認ワークフロー起動 6 証跡保存 ── 判断根拠・承認記録・例外理由をDBに記録 Audit層:すべての判断プロセスが監査可能な形で永続化される 全自動パイプライン
図5:契約レビュー案件のEnd-to-Endフロー ── 事業部入力から証跡保存まで

この一連のフローを「法務業務自動化ライン」と呼びます。重要なのは、個々のステップが自動化されていることではなく、6つの層がパイプラインとして連結されていることです。

関連記事 契約書マスキングを「安全に・速く」行う方法|オフライン対応の無料ツール── ワークフローのStep 2(自動マスキング)を実装した無料ツールの紹介です。

07法務OSはガバナンス装置である

ここが本記事の核心です。

企業法務の最終的な責任は「判断の説明責任」に帰着します。なぜその契約を通したのか。なぜその例外を認めたのか。なぜそのリスクを受容したのか。

法務OSはAIツールではない。
法務判断を管理するオペレーティングシステムであり、
企業のガバナンスインフラ(Governance OS)
である。

法務OSが管理するもの ── 従来との比較

管理対象従来(多くの企業)法務OS対応する層
判断理由担当者の頭の中構造化データとしてDBに記録Audit
判断基準暗黙知・前例踏襲rules.yaml として外部化Rule
例外判断口頭・チャット了承例外承認ログとして永続化Audit
リスク評価担当者の属人的判断Rule準拠のスコアリングRule + Reasoning
処理フロー暗黙の慣行Orchestratorが制御Orchestrator
成果物品質担当者のスキル依存テンプレート準拠で標準化Execution

つまり法務OSは、法務部門の「暗黙知」と「属人判断」を、組織の「制度」と「記録」に変換する装置です。

08内部統制・J-SOXとの関係

法務OSをガバナンス装置として理解すると、内部統制制度との関係が明確になります。

金融商品取引法に基づく内部統制報告制度(いわゆるJ-SOX)は、業務プロセスの統制活動の記録と評価を求めます。法務部門が関与する契約承認プロセスも、その対象となり得ます。

実務上の注意 J-SOXの適用範囲や統制評価の具体的な方法は、企業の事業内容、規模、監査法人の方針等によって異なります。法務OSがJ-SOX対応を完全に代替するものではなく、内部統制の設計にあたっては監査法人等の専門家との協議が不可欠です。

そのうえで、法務OSの各層が内部統制のどの側面を支え得るかを整理すると、以下のようになります。

法務OS Evidence Infrastructure 証跡基盤 法務判断から証跡記録を経て監査対応に至る流れ。Rule層とReasoning層が判断根拠を提供し、Audit層が自動記録し、監査に即座に回答可能にする 法務OS ── Evidence Infrastructure(証跡基盤) 判断 法務判断 契約リスク評価 例外承認判断 稟議通過判断 Rule + Reasoning が根拠を提供 証跡 証跡記録 判断者・日時 参照ルール AI推論結果 例外理由 Audit層が 自動記録 監査 監査対応 内部監査 外部監査 有事の振り返り 証跡があるから 即座に回答可能
図6:法務OS = Evidence Infrastructure ── 判断→証跡→監査の流れ

法務OSが提供するのは、「AIによる自動化」ではなく「判断の追跡可能性(Traceability)」です。誰が、何を根拠に、どう判断したかが、いつでも再構成できる状態を作る。これこそが、法務部門が経営に対して提供すべき最大の価値です。

関連記事 【実務解説】電子帳簿保存法の運用本格化|税務調査で聞かれる10問と”証跡”の作り方(2026)── 証跡管理の実務を電子帳簿保存法の文脈で解説しています。

09プロンプトは「知能」、法務OSは「制度」

ここで、Legal GPTが提供している有料プロンプト集の位置づけを明確にしておきます。

プロンプトとは何か。それは法務OSにおける「知能」です。Reasoning層でAIを動かすための命令セット。法務の判断品質を決定する、最も重要なコンポーネントの一つです。

しかし、知能だけでは法務は回りません。

Prompt→Legal OS→Platformの3段階モデル プロンプトはAIの推論品質を決める知能、法務OSは判断の追跡と説明を可能にする制度、Platformは法務部門の運営基盤 Prompt 知能 AIの推論品質を決める Legal OS 制度 判断の追跡と説明を可能にする Platform 基盤 法務部門の運営基盤
図7:Prompt → Legal OS → Platform ── プロンプトは法務OSの「知能」である

プロンプトが「知能」であるならば、法務OSはその知能を組織的に管理し、運用し、説明責任まで含めて制度化する仕組みです。優れたプロンプトは、法務OSの中で初めてその真価を発揮します。

INTELLIGENCE FOR LEGAL OS
法務OSの「知能」を手に入れる
契約レビュー、リスク評価、コンプライアンスチェック、稟議書生成、法改正対応──
法務実務を横断する100本のプロンプトが、6層アーキテクチャのReasoning層を支えます。
「ツールDX」から「法務OS」への転換を、プロンプトの品質から始めてみませんか。
法務AIプロンプト集100選を見る →

まとめ ── AIツールは法務を変えない。変えるのは法務OSである。

本記事では、前回提唱した法務OSの概念を、システムアーキテクチャとして具体化しました。

記事テーマフレームワーク焦点
第1回法務OSの思想5層業務フレームワーク法務業務の「WHAT」
第2回(本記事)Legal Architecture6層システムアーキテクチャ法務OSの「HOW」
第3回(次回)AIエージェントエージェント設計法務OSの「WHO(自動化)」

核心は一つです。

AIツールを導入しても、法務は変わらない。
法務を変えるのは、判断プロセスを管理するシステム ── 法務OSである。

そして法務OSの内部設計図 ── Legal Architectureは、
Intake → Orchestrator → Rule → Reasoning → Execution → Audit
の6層で構成される。

この6層の中で最も重要なのはAudit(証跡・監査)であり、
これこそが法務OSをガバナンス装置たらしめるものである。

次回の第3回では、この6層アーキテクチャを実際に動かすAIエージェントの設計を解説します。Legal Gateway、Contract Agent、Risk Agent、Decision Agent──法務OSを自律的に駆動するエージェント群の全体像をお見せします。