AOEDEイーグル・アーキテクチャ解説書

エージェンティックAI、信頼の構造を築く

オントロジーからハーネス、そして現場の机まで — ワシの解剖学

ビジネスチーム・管理者のための統合ナラティブ・2026年7月・Business Model Governance, LLC

※本ページは AI（Claude）による自動翻訳版です。原文は韓国語で作成されています。

目次

• 文書について
• 要約
• 本書の読み方
• 第1章. AOEDEイーグル（ワシ）：全体鳥瞰図
• 第2章. テオリア：判断する頭
• 第3章. ポイエーシス：作る翼
• 第4章. プラクシス：治め、調整する翼
• 第5章. CLAW：爪が地面に触れる
• 第6章. 統合実行ガイド：管理者の机の上で
• 付録A. 用語集
• 付録B. 五つの章を貫く文章

文書について

目的

本書は、AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークの五編のナラティブ — 全体アーキテクチャ（イーグル）、テオリア、ポイエーシス、プラクシス、CLAW — を一つの解説書として統合し、ビジネス組織の目線に合わせて整えたものです。技術仕様書ではなく、導入を検討し主導すべき人々がフレームワークの設計意図と管理上の要点を理解できるよう助けるための、物語形式のガイドブックです。

対象読者

一次読者はビジネスチームと中間管理職です。エージェンティックAI導入の課題を与えられた、あるいは検討中の事業部門長、現場のプロセスとリスク・コンプライアンスに責任を負う管理者、そして現場と技術組織の間で要件を翻訳しなければならない企画・分析担当者を念頭に置いて執筆しました。コードやシステム運用の経験は前提とせず、専門用語は初出時に噛み砕いて説明し、付録の用語集に改めて整理しました。

文書の構成と読み方

本書は六つの章と二つの付録で構成されています。第1章はワシの比喩で表現された全体アーキテクチャの鳥瞰図です。第2章（テオリア）、第3章（ポイエーシス）、第4章（プラクシス）はそれぞれ頭と二つの翼を内側から見つめ、第5章（CLAW）はそのすべてが現場の机に触れる場面を描きます。第6章は五つの章に散らばった管理者向けの指針を、ロードマップ・役割・指標・会議体の実行体系として統合したガイドです。

時間のない読者は、エグゼクティブサマリーと第1章、第6章だけを読んでも、意思決定に必要な骨組みを得ることができます。各章の冒頭には扱う内容の予告が、末尾には要点のまとめがボックスで示されているため、ボックスだけを追って全体をざっと見渡してから、関心のある章に戻る読み方もお勧めです。本文中の太字は、その段落の中心となる命題を示しています。

凡例

本文中の画面構成、数値、事例（住宅ローン審査、融資デューデリジェンス、法人融資ワークプレイスなど）は、原ナラティブが記述した時点でのサンプル実装を基準としており、製品の詳細はバージョンによって異なる場合があります。ただし本書が重視しているのは画面そのものではなく、その背後にある規律 — アーキテクチャによって強制される原則群 — であり、導入の意思決定の根拠とすべきものもそちらです。外来語はできる限り日本語で言い換えましたが、フレームワーク固有の名称（テオリア、ポイエーシス、プラクシス、ネクサス、ミメーシスなど）は原語表記をそのまま用いています。また、本版では社内の議論で使われ始めた表記に従い、いくつかの用語を統一しました。能力の実装単位は「能力カプセル」、オントロジーの種であり運搬形式は「ジェネシス」、システムに登録する行為は「登録」、エンティティと関係の構造モデルは「ビジネスオブジェクトモデル」と表記し、オントロジーサーバーは別途のコード名を設けず「AOEDEオントロジーサーバー」と呼びます。旧資料もあわせてご覧になる方は、この対応関係だけ覚えておかれれば混乱はないはずです。

要約

本書が答えようとする問い

エージェンティックAI（Agentic AI）、すなわち自ら状況を判断し行動するソフトウェアを、企業業務に本格的に導入しようとする組織は、最終的に一つの問いの前に立たされます。自ら判断し行動するソフトウェアに、行動の自由と信頼できる規律をどう同時に与えるか。

自由だけを与えれば統制されない判断がリスクを生み、規律だけを強調すれば自動化の効用が失われます。本書はそのジレンマに対する一つの体系的な答えとして、AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークを紹介します。AOEDEはオントロジー（ビジネスの概念モデル）を出発点とし、エージェントを設計し（ポイエーシス）、運用を治め（プラクシス）、実際の現場業務に適用する（CLAWS）という全過程を、一つの一貫した構造にまとめ上げます。

一羽のワシ、五つの器官

AOEDEは全体アーキテクチャを、翼を大きく広げた一羽のワシとして具象化します。この比喩は装飾ではなく、設計そのものです。飛行中のワシが複数の器官の精緻な均衡によって動くように、AOEDEの各構成要素は互いに噛み合いながら一つのシステムを成しています。

本書は五編のナラティブ — 全体アーキテクチャ、テオリア、ポイエーシス、プラクシス、そして爪のサンプル実装であるCLAW（法人融資増強ワークプレイス） — を一つの報告書として統合し、ビジネス組織と中間管理職の視点から改めて整理したものです。

五つの中心メッセージ

本書全体を貫く考え方は、五つにまとめることができます。最初に来るのは、自動化より言語化が先という原則です。オントロジーなしに動くエージェントは自律的な存在ではなく、責任を問うことのできない存在にすぎません。そのためAOEDEでは、エージェントを作る前に、まずビジネスそのものが明確な言語で定義されます。この原則から自然に導かれる二つ目の考えは、私たちが作るべきものはエージェントではなくハーネスであるということです。賢いが手綱のないAIは、今やどこでも手に入ります。企業が自ら築くべきなのは、その知性に取り付ける馬具 — すなわち、何を知り、何ができ、どこで必ず止まるのかが組み込まれた構造物 — です。

三つ目の考えは、導入の速度に関するものです。自律性とは宣言するものではなく、積み立てるものであるという命題のもと、AOEDEはスキル（人の能力の増強）からタスク（一つの役割の代行）を経て、活動（フロー全体の自律運用）へと上る三段階のはしごを提示します。小さな単位で検証された信頼だけが、より大きな自律性を正当化するという意味です。四つ目は、オントロジーの育ち方に関するものです。オントロジーは大聖堂ではなく、地図のように育ちます。実行可能最小限オントロジー（MVO）のアプローチは、「全体をすべて設計してから始める」方式と「統制なき実験」という誤った二者択一をいずれも退け、今必要なスキル一つに十分な分だけを定義したうえで、一つの配備が成功するたびに地図を一区画ずつ広げていきます。

そして最後に、すべての結論には系譜がなければなりません。数字は想像されるものではなく計算され、決定は即興ではなく根拠から導き出され、その過程全体が追跡可能な記録として残ります。監査人のどんな問いにも画面一つで答えられる状態 — それこそが規制産業でエージェントを運用できる条件であり、本書のすべての章は最終的にこの状態へと収束していきます。

旅程の地図：五つの章のつながり方

本文の五つの章は、それぞれ独立した解説であると同時に、一つの物語としてもつながっています。第1章では、ワシの解剖構造全体を鳥瞰しながら、判断が行動に先立ち、作ることと治めることが一対であり、すべての結論に系譜がなければならないという、フレームワークの文法を身につけます。第2章はその頭の中へ入り、オントロジーが定義され、補強され、検証される作業台と、その作業台が崩れないよう支える二重のハーネスを見ます。第3章は左の翼へと渡り、そうして言語化された業務がスキル・タスク・活動という三つの大きさのハーネスへと組み立てられ、判断の隙間と禁止線が数学によって磨き上げられたのち、試験飛行を経て出荷されるまでの工程をたどります。

第4章では、右の翼の舞台が開かれます。それまでの章が取っておいた二つの名前 — ハーネスの規格であるネクサスと、それを忠実に実行するミメーシス・エンジン — の正体が明らかになり、配備されたハーネスの中でエージェントが働き、監視され、認証される運用の日常が繰り広げられます。そして第5章で、このすべての構造がついに現場の机に触れます。法人融資増強ワークプレイスという実物を通じて、フレームワークが一人の担当者、審査役、リスク管理者の朝を実際にどう変えるのかを確認するのです。第6章は、この旅程で管理者が押さえておくべきことを、ロードマップと役割と指標の実行体系として改めてまとめます。

管理者が本書から得るもの

本書は、読者が読み終えた後、次の問いに自ら答えられるようになることを目標としています。

エージェンティックAI導入の課題が持ち込まれたとき、それがスキルの増強なのか、タスクの代行なのか、活動（ワークフロー）の自律運用なのかをどう見極めるか。オントロジー管理、カプセル承認、変更統制、認証更新といった新しい管理業務の担い手は誰であるべきか。増強段階の成果は何で測り、どのような記録が積み重なれば次段階の自律性を承認できるのか。そして監督当局や監査人を前にした「その決定はどのように下されたのですか」という問いに、組織はどのような構造で答えることになるのか。

各章の末尾には、当該領域を担う管理者が押さえるべき実践項目がまとめられており、第6章ではこれを一つの統合実践ガイドとして束ねています。

もちろん、一冊の文書が導入をめぐるすべての問いに答えられるわけではありません。ただし、フレームワークの言葉 — ハーネス、系譜、はしご、地図 — を組織が共有するようになるだけでも、議論の質は変わります。「AIを導入しよう」という漠然とした一文が、「どのスキルから、どの大きさのハーネスで、何を記録しながら始めよう」という具体的な一文へと変わること、それがこのエグゼクティブサマリーが願う第一の変化です。

本書の読み方

文書の構成

本書は六つの章と二つの付録で構成されています。

第1章「AOEDEイーグル：全体鳥瞰図」は、フレームワーク全体の解剖構造を扱います。ワシの各器官が何を意味するのか、能力カプセルとMVOアプローチがなぜこのアーキテクチャの中核的な設計判断なのかを説明します。時間の限られた読者は、この章だけを読んでも全体の骨組みを把握できます。

第2章「テオリア：判断する頭」は、オントロジーが定義され管理される作業環境を扱います。概念モデル・ジェネシス・セマンティック・ファクトリーという三つの柱、チームが日々使う画面群、システムが崩れないよう支える二つのハーネス、そしてデジタルツインへと至る段階的な旅路を説明します。

第3章「ポイエーシス：作る翼」は、ビジネスシナリオが配備可能なエージェントハーネスへと組み立てられる過程を扱います。活動・タスク・スキルというハーネスの三つの大きさと、ポイエーシスが組織に与える八つの能力を一つずつ見ていきます。

第4章「プラクシス：治める翼」は、配備されたハーネスが実際に働く運用の舞台を扱います。これまで取っておいた二つの名前 — ハーネスの規格であるネクサスと、それを実行するミメーシス・エンジン — が、ここで余すところなく明らかにされます。

第5章「CLAW：爪が地面に触れる」は、爪のサンプル実装である法人融資増強ワークプレイスを扱います。抽象的なアーキテクチャが現場担当者の朝の画面でどのような姿として現れるのか、そして「代替ではなく増強」という設計思想が採用戦略としてもなぜ正しいのかを説明します。

第6章「統合実践ガイド」は、五つの章の管理者向け実践項目を一つの運用モデルにまとめ、導入ロードマップと成果指標体系、よくある質問を整理します。

付録A「用語集」は、本文に登場する主要用語を管理者の言葉で解説し、付録B「五つの章を貫く文章」は、本文各所の中心的な文章を一か所に集め、その文脈と含意を振り返りました。

読者別おすすめの読み方

役員および意思決定者には、エグゼクティブサマリーと第1章、そして第6章の導入ロードマップをお勧めします。フレームワーク全体の論理と、組織が準備すべきことを把握するには十分です。

導入を検討する現場の部門長と中間管理職には全体を通読することをお勧めしますが、自身の役割に近い章を中心に深く読むこともお勧めします。オントロジーとナレッジ管理を担うなら第2章を、エージェントの設計と実装を担うなら第3章を、運用とリスク統制を担うなら第4章を、現場適用と変革管理を担うなら第5章を中心に据えてください。

実務担当者には、担当領域の章を精読したうえで、付録Aの用語集を手元に置きながら他の章を参照する読み方をお勧めします。

表記について

本文中、固有名称は初出時に原語を併記し、以降は日本語表記を用います（例：テオリア（THEORIA））。オントロジー、ハーネス、エージェントのように、すでに業界で通用している外来語はそのまま使用しますが、初出の箇所で意味を噛み砕いて説明します。各章の冒頭には当該章の要点をまとめた案内文が、末尾には管理者向けの実践項目が置かれています。

語源について

テオリア、ポイエーシス、プラクシスの三語はいずれも古代ギリシア哲学、とりわけアリストテレスが人間の活動を区分する際に用いた中心概念に由来します。AOEDEの命名がなぜ絶妙なのかも、この語源を知ればより明確になります。

テオリア（θεωρία, theoria）は、本来「見ること」「観照（かんしょう）」を意味します。語源的には「見物する、観察する」という動詞（theorein）に由来し、もともとは祭典や神託を見に行く使節の「見る」ことを指す言葉でした。アリストテレスにとってテオリアとは、何かを作ったり変えたりするためではなく、真理そのものを知るために世界を見つめる活動、すなわち純粋な思索と認識の生でした。彼はこれを人間の活動の中で最も高いものと見なしました。英語のtheory（理論）はここから生まれました。AOEDEにおいて、オントロジーを定義する「頭」にこの名を与えたのは、行動に先立ってビジネスをありのままに「見て知る」段階という意味と、正確に符合します。

ポイエーシス（ποίησις, poiesis）は「作ること」「制作」を意味します。「作る」という動詞（poiein）に由来し、英語のpoetry（詩）の語源でもあります — 詩人は言葉で何かを「作り出す」人であるという発想です。アリストテレスの区分において、ポイエーシスの特徴は、活動の目的が活動の外にある成果物にあるという点です。家を建てる行為の目的は、建てる行為そのものではなく、完成した家です。だからこそ、作る翼、すなわちハーネスという成果物を組み立てる場所にこの名が与えられました。

プラクシス（πρᾶξις, praxis）は「行うこと」「実践」を意味します。ポイエーシスと対比される概念で、目的が成果物ではなく、行為そのものとその行為をうまく成し遂げることにある活動です。政治、倫理的な生、共同体の中での正しい行いが典型的なプラクシスです。良い統治の産物は何かの「物」ではなく、うまく治められている状態そのものです。だからこそ実践には、フロネシス（phronesis）、すなわち状況の中で正しく判断する実践知が求められるとされました。運用と統制、ガバナンスという — 終わる時点がなく「うまく成し遂げること」自体が目的である — 治める翼に、この名が与えられた理由です。

三つの概念を一列に重ねてみると、アリストテレスは人間の活動を、知ること（テオリア）、作ること（ポイエーシス）、行うこと（プラクシス）に分けたことになり、AOEDEはその古典的な三分法を、エージェンティックAIのライフサイクル — 定義し、組み立て、運用する — にそのまま移し替えたものです。参考までに、ネクサス（nexus）はラテン語で「束ね、結びつき」を、ミメーシス（mimesis）はギリシア語で「模倣、忠実な再現」を意味し、五つの名前はすべて同じ古典語彙の系譜の上にあります。また、AOEDE（eii:di、発音：エイディ）は、ギリシアの音楽の女神の一柱である歌の女神であり、「ワシの歌」を意味します。

第1章. AOEDE イーグル（ワシ）：全体鳥瞰図

本章で扱う内容：エージェンティックAI導入における根本的な問いと、それに対するAOEDEの答え、ワシの比喩で表現された全体アーキテクチャの六つの構成要素、能力カプセルという実装単位、そして実行可能最小限オントロジー（MVO）という方法論的な核心。

1.1 一つの問いから始める

エージェンティックAIを企業に本格的に導入しようとする組織は、パイロットの高揚感が落ち着いた後、結局一つの問いの前に立たされます。自ら判断し行動するソフトウェアに、行動する自由と信頼できる規律をどのように同時に与えるか？

この問いが難しい理由は、二つの要求が互いに反対方向を指しているからです。自由のないエージェントは、既存のルールベース自動化と変わらず、導入する理由が失われます。逆に規律のないエージェントは、特に金融産業のように一つの意思決定のコストが資本規模で測られる産業では、組織が抱えきれないリスクの源になります。多くの組織がこの間で揺れています。ある組織は統制を理由に何も始められず、ある組織は速度を理由に統制なしで始めてしまい、最初の事故でプロジェクト全体を失います。

AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークは、この問いに一つのイメージで答えます。翼を大きく広げたワシです。

1.2 なぜワシなのか

この比喩は単なる装飾ではありません。飛行中のワシは、複数の部分が精緻にバランスを取ってこそ動く一つのシステムです。状況を判断する頭があり、必ず共に動かなければならない二つの翼があり、意図を実際の動きに変える胴体があり、そして最終的に獲物を掴む爪があります。どれか一つが欠けてもワシは飛べず、飛べたとしても何も掴めません。

AOEDEは、アーキテクチャの中核要素一つひとつをこの構造に対応させます。そしてその対応は、見つめるほどに明確な設計意図を明らかにします。判断が行動に先立つべきであること（頭）、作ることと治めることは一対であること（二つの翼）、すべての行動は統制を通過しなければならないこと（胸のベルト）、実行は忠実でなければならないこと（エンジン）、そしてこのすべての価値は結局、実際の業務を掴めるかどうかで評価されるということ（爪）です。

それでは、各器官を順に見ていきましょう。

1.3 頭：テオリア（THEORIA）— 判断が行動に先立つ

ワシの頭に当たるのが、オントロジーの座であるテオリア（THEORIA）です。

ここでいうオントロジー（ontology）とは、哲学用語ではなく実務用語です。私たちの業務領域にどのような対象（エンティティ）が存在するのか、それらは互いにどうつながっているのか、この領域における「意思決定」とは具体的に何を意味し、「根拠」はどのような形であるべきか — こうした問いへの答えを、コンピューターが理解できる構造で書き記したものがオントロジーです。簡単に言えば、私たちのビジネスの公式な地図であり、公式な辞書です。

AOEDEの原則は明確です。エージェントを作ったり、何らかの行動を自動化したりする前に、ビジネスモデル自体がまずこの明確な言語で定義されなければなりません。テオリアはまさにこの定義が行われる場所であり、フレームワーク全体の思考と判断が始まる概念的な中心です。

ワシが飛ぶ前にまず見るように、AOEDEではオントロジーが自動化に先立ちます。この順序を逆にすると、どのようなことが起こるでしょうか。オントロジーなしに動くエージェントは自律的なのではなく、単に責任を問えない存在にすぎません。そのエージェントが自らを何をしていると信じていたのか、どのような概念に基づいて判断したのかを、誰も説明できないからです。事故が起きたときに「なぜそのような判断をしたのか」に答えられないシステムは、規制産業では存在し得ないシステムです。

1.4 二つの翼：ポイエーシスとプラクシス — 作ることと治めること

二つの翼は、頭が見たものを実際の動きへと移し替えながら、意図的に互いに相反する役割を担います。

左の翼ポイエーシス（POIESIS）は「作る翼」です。ここでテオリアの理論モデルが、実行可能なコンポーネントへと変わります。概念が実際に動くエージェントになる、いわば組立ラインの領域です。重要なのは、この組み立てが職人の即興作業ではなく標準化された工程であるという点です。契約が導き出され、エンジンが組み立てられ、すべてのコンポーネントは頭で定義されたオントロジーに照らして検証されます。誰が作っても同じ規格の成果物が出るように、工程自体が設計されています。

右の翼プラクシス（PRAXIS）は「治める翼」です。デプロイされたエージェントの実行を監視・管理し、すべての行動が定義された範囲とコンプライアンス基準の中にとどまるよう保証します。作る側が「このエージェントはこのように働くことになっている」を定義するとすれば、治める側は「実際にそのように働いているか」を瞬間ごとに確認します。

この対称性は目新しい発明ではありません。うまく機能している組織であればすでに知っている原理 — 商品を作る部署とその商品のリスクを審査する部署が分離されつつも、同じ基準の上で働かなければならないという原理 — を、エージェントの世界に移し替えたものです。違いがあるとすれば、人間の組織ではこの分離が規定と会議によって維持されるのに対し、AOEDEではアーキテクチャによって維持されるという点です。

この対称性がフレームワークの核心です。統制なく作ることだけをする組織はリスクを大量生産し、作らずに統制だけをする組織は何も生み出せません。飛行には二つの翼が共に動くことが必要です。後述するように、AOEDEはこの対称性をスローガンにとどめず、工学的に実装します。二つの翼は同じサーバー、同じデータベースを共有する二つの顔であり、作る側が渡したものと治める側が受け取ったものの間に、翻訳も、複製も、食い違う隙間もありません。

1.5 胸のベルト：ネクサス・ハーネス

ワシの胸を横切り、盾をX字形に包み込むのがネクサス・ハーネス（NEXUS HARNESS）です。行動（Action）、統制（Control）、ガバナンス（Governance）から成る黄金のベルトであり、エージェントが安全かつ効果的に動作することを保証する中核的な制御層です。

ここで「ハーネス（harness）」という言葉について触れておきます。ハーネスとは、馬や牽引動物に装着する馬具を意味します。馬具は動物をつなぎ止める鎖ではありません。動物の力が馬車を引く方向にのみ伝わるようにする、力と方向を結びつける装置です。AOEDEがこの言葉を選んだ理由はまさにそこにあります。エージェントの知能を抑え込むのではなく、その知能が組織の許した方向にのみ発揮されるように編まれた構造物 — それがハーネスです。

X字の形にも意味があります。行動と統制は順を追って通過する段階ではなく、システムの心臓の上で互いにぴんと張り合う交差した帯です。行動が大きくなれば統制も共に締まり、統制が行動を失えばベルト全体が緩みます。そしてガバナンスは、その緊張を留めるバックルです。エージェントが行うすべてのことはこのハーネスを通過し、ハーネスが説明できないことはエージェントも行いません。

1.6 胴体のエンジン：ミメーシス・エンジン

ワシの中央、ハーネスの下ではミメーシス・エンジン（MIMESIS ENGINE）が作動します。ネクサスを実行するために設計された実行ドライバーであり、フレームワーク運用の動力源です。

この名前は慎重に選ばれました。ミメーシス（mimesis）とは「忠実な再現」を意味します。このエンジンは結果を作り上げたりしません。オントロジーが定義した内容を、ハーネスが許容する範囲の中でそのまま実行するだけです。数字は想像されるのではなく計算され、決定は即興で下されるのではなく根拠から導き出されます。

この点において、生成AIに対するよくある懸念 —「もっともらしく作り上げた答えを出すのではないか」— に対するAOEDEの姿勢が明らかになります。創造性が必要な場と忠実さが必要な場を区別し、実行の心臓部には忠実さのみを置くということです。このエンジンが強力である理由は、逆説的にも、指示された通りにのみ正確に動くからです。

1.7 爪：AOEDE CLAWS — 実際のビジネスを掴む

ワシの構造は結局、爪が何を掴めるかによって評価されます。どれほど精緻な頭と翼を備えていても、爪が虚空しか掴めなければ、そのワシはビジネスに何ももたらしません。AOEDE CLAWSは、フレームワークが実際のビジネスと出会う接点です。フロントオフィスと顧客関係、すなわちCRMと営業環境に直接適用され、収益と顧客エンゲージメントを生み出します。

左の爪は専門金融サービスを担当します。企業向け融資、貿易金融、キャッシュマネジメントのように複雑性が高く、判断の根拠が契約文書にあり、統制されない意思決定のコストが資本規模で測られる領域です。右の爪は顧客側面を担当します。顧客管理、資産管理、そして包括的リスク管理のように、その実体が関係とポートフォリオ、日々変動するエクスポージャーである領域です。

二つの爪の性格が異なるという点も注目に値します。左は文書と契約が根拠の中心となる世界であり、右は関係と時系列データが中心となる世界です。一つのフレームワークが、性格の異なる二つの世界を同じ原理 — オントロジー、ハーネス、忠実な実行 — で掴めるのか。CLAWSはその検証の舞台でもあります。

接点の位置をフロントオフィスに定めたことにも理由があります。バックオフィスの自動化はコストを削減しますが、フロントオフィスの拡張は収益と顧客体験を直接動かします。そしてフロントオフィスこそ判断の密度が最も高い場所 — 毎日数十件の照会と比較、優先順位付けが行われる場所 — であり、系譜と統制を備えたエージェントの価値が最も早く実感される地形でもあります。爪が最初に触れる場所が、組織がフレームワークの価値を初めて実感する場所になるわけです。

1.8 能力カプセル：比喩がエンジニアリングになる地点

CLAWは能力カプセル（capability capsule）を基盤として実装され、まさにこの地点でワシの比喩がエンジニアリングの現実となります。

能力カプセルとは、それ自体で完結し、ガバナンスが組み込まれた能力単位です。各カプセルには、業務ドメイン知識パックとスキルパックをはじめ、次の七つの要素が収められています。

第一に、ゴールドスタンダード・レポートです。このスキルが生み出すべき成果物の合格基準としての役割を果たす模範的な産出物であり、カプセルのすべての構成要素はこの基準に向かって整列します。第二に、エンティティモデルとデータ契約です。このスキルが用いるビジネス上の意味に従って、データが何であり、どのような形であるべきかを正確に記述します。第三に、ソリューションツリーです。結論がどのような過程を経て導き出されるかを記録し、答えだけでなく答えに至る道筋そのものを検討可能にします。第四に、決定論的計算エンジンです。すべての数値を生み出す計算装置であり、同じ入力には必ず同じ出力が得られます。第五に、シグナルとギャップ検知器です。カプセルが自らの状態を監視し、異常と隙間を知らせます。第六に、回帰テストフィクスチャです。変更があるたびに既存の品質が維持されているかを自動的に判定し、デプロイの可否を見極めます。

そして第七が特に重要です。人間の判断と学びが検討可能な形で残るように用意された明示的なスロットです。業務ルールを収める意思決定テーブル、承認者が直接値を入力するガバナンスパラメータ、まだ存在しないモデルに対する機械学習要件フックがそれに当たります。人間の介入が必要なとき、その介入は場当たり的なものではなく、最初から設計された場所で行われます。

このように見ると、各能力カプセルは縮小された一羽のワシです。ゴールドレポートはテオリアの意図が具体化されたものであり、カプセルの組み立てはポイエーシスの作業であり、監査と承認はプラクシスの実行であり、ランタイムフックと閾値はぴんと締められたネクサス・ハーネスであり、エンジンは定められた通りに正確に実行するミメーシスです。最も小さな単位の中に全体の原理が完結した形で収められているからこそ、それらを積み上げたより大きな構造も崩れないのです。

1.9 MVOアプローチ：掴むたびに育つオントロジー

CLAWの実装において最も重要な設計上の決定は、技術ではなく方法論です。AOEDEは実行可能最小限オントロジー（MVO, Minimum Viable Ontology）アプローチを採用します。その理由は、エージェンティック・オントロジーのアプローチ手法が、全面的・全社的な革新を志向するよりも、小さく始めて試行錯誤と段階的な移行を推奨するものだからです。AIエージェント技術がまだ発展途上にあり、LLMもまた発展過程にあるため、全面的かつ同時的に推進するにはリスク要因が多いためです。

1.9.1 なぜ「すべてを設計し尽くす」は失敗するのか

エンタープライズAIの失敗事例を見ると、最初の能力を完成させる前に企業全体をモデリングしようとしたオントロジープロジェクトが少なくありません。数百人へのインタビュー、数千ページに及ぶ定義文書、そして完成する前に陳腐化してしまった数年がかりの取り組みです。ビジネスはオントロジーのモデリングが終わるのを待ってはくれず、完成した瞬間のモデルは、すでに昨日のビジネスを描いています。

MVOはその順序を逆転させます。「私たちのビジネスの完全なオントロジーとは何か？」を問う代わりに、「この一つの中核能力、スキルを信頼できるものにするために必要な最小限のオントロジーとは何か？」を問います。すなわち、目的地がオントロジーを引き寄せて存在させる方式です。

1.9.2 最小限はどのように決まるのか

具体的には、各能力カプセルは自分自身の最小オントロジーを持ちます。その範囲は、ゴールドレポートと能力カプセルが目指す目標が実際に要求するエンティティ、属性、関係、業務ルール、ガバナンスパラメータ — ちょうどそれだけであり、それ以上でもそれ以下でもありません。

例えば、グループ伝播リスクマッピング能力カプセルには、グループ構造、関係会社間のつながり、エクスポージャー上限に関するエンティティのみが必要です。離反リスク評価能力には、口座残高、保有商品、接触・相互作用の履歴、収益レコードのみが必要です。各能力カプセルにおいて、スキルは銀行全体の地図ではなく、自らの目的地までの道の地図のみを要求します。

それでは、目的地がまだデータに存在しない何かを要求するときはどうするのでしょうか。例えば、ゲージチャートに必要な許容限度や、軌跡分析に必要な遷移モデルがまだない場合は？ このときオントロジーは決して捏造することなく、宣言によってその場所を守ります。承認者が埋めるパラメータスロットが作られたり、チームが構築すべきモデル要件が明示されたりし、その値が準備されるまでは決定論的フォールバック（安全なデフォルト動作）がその場所を守ります。ないものをあるふりをするのではなく、ないという事実そのものを管理可能な形で登録するのです。

1.9.3 断片が地図になる仕組み

このようにして全社オントロジーは、ワシの握力が強まる方式そのままに — 爪一本、能力カプセル一つ、デプロイ一つずつ — 段階的に作られていきます。CLAWの中にカプセルが積み重なるにつれて、それぞれの最小オントロジーが重なり合い始めます。離反顧客把握能力カプセルの「顧客」エンティティが、融資能力カプセルの「債務者（obligor）」エンティティと出会う瞬間が訪れます。この二つを調整する作業は、もはや机上の空論的なモデリング作業ではなく、実際の根拠に裏付けられた小さな整理作業になります。二つの能力カプセルがすでに現場で検証されているため、調整の基準もまた現場にあります。

テオリアは、あらかじめ建てられた大聖堂ではなく、実際に飛行してみた領土から組み立てられる生きた地図となります。頭が爪から学ぶのです。

1.10 鳥瞰図をチェックリストとして読み替える

この鳥瞰図は鑑賞用の絵ではなく、そのままチェックリストとして使うことができます。何らかのエージェンティックAI課題が机の上に上がってきたとき、ワシの器官を一つずつ指し示しながら、六つの問いを投げかけてみるのです。

まず頭から問います。この課題が扱う業務領域の対象と関係と判断基準が、担当者の頭の中ではなく検討可能な言語で定義されているか。次は左の翼です。エージェントが作られる過程が個人の即興ではなく標準化された工程に従っており、その産出物がオントロジーに照らして検証されているか。右の翼に移り、作られたものがデプロイされた後も監視され、変更が統制され、定義された範囲を逸脱しないよう治められているか。胸のベルトについては、エージェントのすべての行動が統制とガバナンスの層を通過しているか、それとも迂回路が開かれていないかを問います。胴体のエンジンについては、数字と結論が作り上げられるのではなく計算され導き出されているか、その過程が再現可能かを問い、最後に爪については、この構造すべてが結局、現場のどのような実際の業務を掴むのか、その効果を誰の一日の中で確認できるのかを問います。

六つの問いのうちどれか一つでも答えが空白であれば、その空白こそがプロジェクトのリスクが潜む場所です。オントロジーなしに始めた課題は、事故が起きたときに説明する言葉を持たず、統制なしにデプロイされたエージェントは律儀に間違った道を進み、爪のない構造はどれほど精緻であっても、成果報告書に書く文章がありません。続く章では、この六つの問いそれぞれに対してAOEDEが用意した答えを、画面と規律のレベルまで踏み込んで示していきます。

1.11 第1章のまとめ

これがAOEDEイーグルの静かながらも根本的な差別化ポイントです。「巨大な事前設計」と「統制なき実験」という誤った二者択一を拒むこと。フレームワークの処方を五つの文に凝縮すると、次のようになります。

見える範囲だけオントロジーを定義してください。行動できる範囲だけエージェントを作ってください。すべての行動を統制とガバナンスにつなぎ止めてください。エンジンには忠実に実行させ、爪には実際の業務を掴ませてください。そしてワシが実際に掴む方法を学んだ分だけ、オントロジーを育ててください。

続く四つの章では、この鳥瞰図の各器官の内側へと入っていきます。第2章では頭（テオリア）が実際にどのような画面と規律で構成されているかを、第3章では左の翼（ポイエーシス）がハーネスを組み立てる八つの能力を、第4章では右の翼（プラクシス）の運用の舞台とともにネクサスとミメーシスの正体を、そして第5章では爪（CLAW）が実際の企業向け融資業務の現場に触れた姿を見ていきます。

第1章の要点：AOEDEは、判断（テオリア）、制作（ポイエーシス）、統制（プラクシス）、制御層（ネクサス）、忠実な実行（ミメーシス）、現場接点（CLAWS）の六つの要素から成る一つのシステムである。実装単位はガバナンスが組み込まれた能力カプセルであり、方法論の核心は、目的地が要求する分だけオントロジーを定義し、デプロイの経験によってそれを育てていくMVOアプローチである。

第2章. テオリア：判断する頭

本章で扱う内容：オントロジー・フレームワークの三本柱（コンセプトモデル、ジェネシス、セマンティック・ファクトリー）、チームが日々作業する画面群、システムを崩壊させないように支える二つのハーネス（モデルハーネスと実行ハーネス）、そしてジェネシスから出発し、デジタルツインを段階的に構築していく旅程。

2.1 テオリア・オントロジー・アーキテクチャ

オントロジーを導入しようとする組織が最初に受ける反問はこれです。「そのモデルは何を根拠に正しいと言えるのか？」担当者一人の頭の中から生まれたモデルであれば、その人が異動する瞬間にモデルの権威も一緒に去ってしまい、コンサルタントが描いてくれたモデルであれば、プロジェクトが終わった瞬間から古びていきます。テオリアのオントロジー・アーキテクチャは、この反問に構造で答えます。上には国際標準の系譜に錨を下ろし、中央には会社のビジネスモデルという単一の真実の源泉（single source of truth）を打ち立て、下にはその真実の源泉を異なる観点から検証する二つの証拠ストリームを流します。上の錨は「このモデルは正しい方法で記述されているか」を担保し、下の二つのレンズは「このモデルは意味の次元において、そして運用の次元において現実と一致しているか」を絶えず問い続けます。そして、この問いにおいてずれが発見される瞬間こそが、このアーキテクチャの真の設計意図が現れる瞬間です — ギャップは事故ではなくシグナルであり、判定を経てどちらか一方の改善を引き起こす引き金なのです。

本書はその構造を五つのステップで歩みます。標準の基礎（MOF）、日陰から導くシャドー・オントロジー（メタフレームワーク）、日向の真実の源泉（会社のビジネスモデルとオントロジー）、二つの証拠レンズ（セマンティクス・ストリームとデータ・ストリーム）、そしてギャップの判定と価値優先の運用戦略です。

2.1.1 出発点：MOF、標準から受け継いだ基礎

物語の最上位にはMOF（Meta Object Facility、メタオブジェクトファシリティ）があります。MOFは国際標準化機構であるOMG（Object Management Group）が制定したメタモデリング標準であり、OMGのMDA（Model Driven Architecture、モデル駆動アーキテクチャ）体系の最上位基盤を成しています。テオリアが独自に考案した概念ではなく、ソフトウェア産業が数十年かけて磨き上げてきた標準を継承したものです。

MDAとMOFの核心的な洞察は、モデルにも階層があるということです。一番下に現実のデータがあり、そのデータの構造を定義するモデルがあり、そのモデルの記述方法を定義するメタモデルがあり、一番上にメタモデル自体を記述する基盤層 — MOF — があります。階層を混同しないこの規律が、後述する「定義的な問いとインスタンスの問いの区別」にまでつながる、このアーキテクチャ全体の背骨です。

管理者にとって、この出発点が意味するところは明確です。テオリアのオントロジーは、どこかの個人の発明の上にではなく、業界が検証したメタモデリング標準の系譜の上に立っています。「その方法論の根拠は何か」という監査人の問いに対して、担当者の経歴ではなく国際標準の名において答えられるということです。もちろんテオリアはMOFの階層的思考を継承しつつ、ビジネスオントロジーの目的に合わせて再解釈しています — 何を受け継ぎ、何を変形したのかを明示することこそが、標準の権威を借りる正しい方法です。

2.1.2 シャドー・オントロジー：日陰から導くメタフレームワーク

MOFに基づいて構築されるのがメタ・ビジネスモデル・フレームワークです。業務対象・エンティティ・属性・活動・タスクといったメタオブジェクトが「どんな会社のモデルでも収められる文法」を宣言する層であり、一文で要約すれば会社についての知識ではなく、会社についての知識を記述する方法についての知識です。

しかし、この層の戦略的な正体を正確に押さえておく必要があります。メタ・ビジネスモデル・フレームワークは特定の会社に依存しない（company-agnostic）上位オントロジーです。それ自体はどの会社の実際のオントロジーでもありません。しかし、まさにそれゆえに、あらゆる会社のオントロジーに対してシャドー・オントロジー（shadow ontology）として機能できるのです。シャドー・オントロジーの役割は二つあります。

第一はモデリングのガードレールです。会社のビジネスオントロジーがどのチームによってどのような順序で構築されようとも、その作業はシャドー・オントロジーが予め用意した完結した上位構造の導きを受け、軌道を外れることがありません。ボトムアップで育つモデルが混乱に陥らない第一の理由がここにあります。

第二は意味の浄化装置（semantic purifier）です。ユーザーが自然言語で質問を投げかけるとき、その質問に含まれる概念はまずシャドー・オントロジーの語彙に照らして解釈され、精錬されます。会社のオントロジーにまだ定義されていない概念が質問に登場したとしても、上位構造がそれを受け止める概念的なセーフティネットを提供するのです。

この戦略の妙味は、日陰と日向の関係にあります。シャドー・オントロジーは完結した上位構造として日陰にとどまり、会社のスコープ・オントロジーがMVOアプローチによって定義される分だけ、その概念が日向へと現れます。つまり、完全性は日陰に予め備えられており、実在性は日向で一区画ずつ稼ぎ取っていく構造です。全体を事前にすべて構築することなく、それでいて全体の導きを受けること — 「壮大な事前設計」と「統制なき実験」という誤った二者択一を拒否する本書の原則が、この日陰と日向の分業によって実現されています。

2.1.3 日向の真実の源泉：会社のビジネスモデルとオントロジー

シャドーの導きのもと、日向で構築されるのが会社のビジネスモデルです。会社の商品と顧客セグメント、チャネル、業務領域と業務対象が、メタフレームワークが定めた文法の中で精錬され具体化され、それがコンピュータが理解し答えられる形に確定されたものがビジネスモデル・オントロジーです。

ここで、このアーキテクチャの第一原則が宣言されます。会社のビジネスモデルが単一の真実の源泉です。下から上がってくる二つの証拠ストリームは、真実の源泉と競合する別の真実ではなく、真実の源泉を異なる観点から検証するレンズです。セマンティクス・ストリームは意味の観点（semantic perspective）から、データ・ストリームは運用の観点（operation perspective）からビジネスモデルを照らし出します。真実は一つであれど検証は二つ — この非対称性が、後述するギャップ判定メカニズムの前提となります。

第一のレンズ：セマンティクス・ストリームとセマンティック・ファクトリー

第一の証拠レンズはセマンティクス（semantics）です。このレンズの表現形式は概念明確化（concept clarification）です。私たちのドメインにおいて「顧客」と「借主」は同じものの異なる呼び名なのか、「融資」は「金融商品」の下位概念なのか、互いに排他的だと宣言した二つの概念を同時に継承する矛盾はないか — 概念エディタと内蔵された推論エンジンが、こうした問いに論理的に検証された答えを確定していきます。これは用語集を作る作業ではなく、論理的に検証される語彙体系を打ち立てる作業です。

明確化された概念の根拠は、セマンティック・ファクトリーのセマンティック・オントロジーが供給します。セマンティック・ファクトリーは規程集や契約書、業務マニュアルといった実際の文書を読み込み、エンティティ・事実・関係を抽出し、すべての項目にどの文書のどの箇所から得られたかという出典を紐づけて蓄積します。原文に根拠が見当たらない項目は、忠実性ゲートで却下されます。このように文書から育った知識の体系がセマンティック・オントロジーであり、会社のオントロジーとは別に管理されながら、定期的に照合されます。文書には登場するがモデルには存在しない概念、文書が語る関係とモデルが宣言した関係が食い違う箇所が、矛盾検知によって表面化します。要するにこのレンズは「私たちのモデルは、私たちが記述した意味と一致しているか」を問うのです。

2.1.5 第二のレンズ：データ・ストリームと運用の実体

第二の証拠レンズはビジネスオブジェクトとデータインスタンスです。概念が意味を扱うのに対し、このレンズは構造と実体を扱います。各業務対象が所有するビジネスオブジェクトモデルが、その領域のエンティティ・属性・関係を構造として宣言し、その構造の実在性を、実際のデータベースに記録された行 — データインスタンス — が保証します。

階層の規律はここでも守られます。「紛争処理には何個のエンティティが定義されているか」はビジネスオブジェクトモデルが答えるべき定義的な問いであり、「紛争案件が現在何件溜まっているか」はデータインスタンスが答えるべき問いです。二つの平面を厳密に区別しつつ上下でつなぐこと、それが正確な答えともっともらしい誤答とを分ける違いです。このレンズが問うのは「私たちのモデルは実際に起きている運用と一致しているか」です。

ギャップの二つの顔と判定：リスクが表面化する仕組み

ここからがこのアーキテクチャの心臓部です。二つのレンズの問いにおいてずれ — ギャップ（gap） — が発見されると何が起こるのか。核心は、ギャップの種類によってその意味と処理経路が異なるという点にあります。

セマンティクスの証拠とビジネスモデルの間のギャップは、改善の機会です。文書が語る概念とモデルが宣言した概念が食い違っている場合、どちらが古びているのかは決まっていません。モデルが現実に追いついていない場合もあれば、規程文書が改訂を見落としている場合もあります。したがってこのギャップの判定は「どちらを直すか」という双方向の問いであり、どちらを直すにせよ組織の知識は一歩精錬されます。

ビジネスモデルとデータ・ストリームの間のギャップは、コンプライアンス案件です。モデルは組織が「こうすることにした」と宣言したものであり、データは「実際にこうした」という記録です。両者のずれは、定義上、宣言と実行の不一致であるため、開かれた調整としてではなく、コンプライアンスの言葉 — 原因究明、是正、必要に応じたエスカレーション — で扱わなければなりません。

どのギャップであれ、識別された瞬間に判定（verdict）が下され、その判定はどちらか一方の改善を引き起こす引き金となります。このメカニズムの真の価値は、個別のギャップの修正そのものではなく、その先にあります。ほとんどの組織において、ビジネスはかなりの部分が暗黙知の上で回っており、「規程と実務が違う」という事実は事故が起きてから初めて発見されます。このアーキテクチャでは、それが常時検知されるシグナルになります。暗黙のうちに潜んでいた潜在リスクが、運用の最中に構造的に表面化すること — ギャップ判定メカニズムは、オントロジーを文書化ツールからリスク早期発見装置へと格上げします。最後のピースとして、判定の主体とエスカレーション経路 — 特にコンプライアンス・ギャップを誰が判定し、どこに上げるのか — を組織の役割表に明示しておくことで、このメカニズムの信頼性は完成します。

価値優先のギャップ縮小：持続可能な運用戦略

ギャップの発見が積み重なると、自然な問いが続きます。これらのギャップを減らす努力に、どれだけを、いつ費やすのか。このアーキテクチャが選んだ答えは正直です。ビジネス価値の実現が先であり、実現した価値の一部をギャップ縮小のコストとして配分します。

理想的には完全な整合性を先に確保したいところですが、その順序は現実には持続しません。多額の予算をかけてビジネスオントロジーを構築しても、ビジネスの実現が伴わなければ、組織はギャップを減らそうとする関心そのものを急速に失います。反対に、ユーザーがオントロジーの価値を実際のビジネスケースとして実感すれば、不整合を減らそうとする努力は自ずと精力的になります。ギャップ縮小の努力は、ビジネス価値の回収に比例して大きくなります。したがって、価値を先に実現し、その回収分で整合性を買い取る戦略は、最善（best）ではないとしても持続可能な次善（better）です。これはMVOの経済学とまったく同じリズムでもあります — オントロジーが目的地に引かれて育つように、整合性管理も価値に引かれて育つのです。調整の予算ではなく、調整の動機を設計する方式なのです。

日陰の導き、日向の真実、二つのレンズの問い

アーキテクチャ全体をもう一度たたんでみましょう。上から下へは定義の系譜が流れます。国際標準MOFがメタフレームワークの基礎となり、そのフレームワークはシャドー・オントロジーとして日陰から会社のオントロジー構築を導き、日向では会社のビジネスモデルが単一の真実の源泉として確定されます。下から上へは二つの証拠レンズの問いが上がってきます。セマンティクス・ストリームが意味の一致を、データ・ストリームが運用の一致を検証し、発見されたギャップは改善の機会あるいはコンプライアンス案件として判定され、どちらか一方の改善を引き起こします。そして、その改善の努力は実現されたビジネス価値によって調達されます。

管理者にとって、この構造が与えてくれるのは点検の言語です。オントロジーの品質が疑わしいときに投げかける問いが、四つの方向に整理されます。文法に沿って記述されているか（標準への係留）、シャドーの導きを受けているか（上位構造）、文書の意味と食い違っていないか（セマンティクスのレンズ）、運用の実体と接しているか（データのレンズ）。この四つの問いすべてにシステムが答えを持っているなら、そのオントロジーは信頼してよく、いずれかが空いているなら、その空白こそが次に補強すべき領域です。オントロジーの信頼とは宣言ではなく、日陰の導きと日向の真実と二つのレンズの問いが日々維持されているという事実そのものなのです。

2.2 青写真が画面になる瞬間

私たちはワシの解剖構造を見てきました。判断する頭、創り治める二つの翼、胸を締めるハーネス、忠実に実行するエンジン、そして実際のビジネスを掴む鉤爪。その物語において頭に該当するのが、オントロジーの座、テオリアでした。「自動化に先立ち、ビジネスがまず言語化されなければならない」という原則のことです。

これから見ていくのは、その原則の実物です。AOEDE-テオリア・クライアントは、その「頭」を私たちのチームのブラウザの中に持ち込んだウェブアプリケーションであり、その背後でオントロジーを実際に保管し検証し回答するのがAOEDEオントロジー・サーバーです。

本章は二つの層を同時に扱います。画面上で何をするかだけでなく、その画面の裏側でどのような規律が働いているかまで扱います。管理者がシステムを信頼するためには、後者を知る必要があるからです。画面は変わり得ますが、規律はアーキテクチャであり、導入の意思決定の根拠とすべきなのは規律の側です。

物語は五つの大きな流れで進みます。第一に、オントロジー・フレームワークを成す三本の柱 — コンセプトモデル、ジェネシス、セマンティック・ファクトリー — それぞれの意味と、これらが会社のビジネスオントロジーと結ぶ連携。第二に、そのフレームワークの上でチームが日々作業する画面群 — 作業スペース、ダイアグラムエディタ、補強、顧客価値実現。第三に、この全体を崩壊させないように支える二つのハーネス — オントロジー・モデルハーネスとAIエージェント実行ハーネス。第四に、ジェネシスから出発して段階的にデジタルツインを構築していく旅程とそのナビゲーションマップ。最後に、管理者が押さえておくべき事項です。

2.3 三本の柱と一つの循環

テオリアのサイドバーにはコンセプト・オントロジー、ビジネス・オントロジー、セマンティック・ファクトリーが並んで配置されています。初めて見る人にはどれも似たような知識メニューに見えますが、この三つは異なる層で異なる仕事をしており、その関係を理解することがテオリア全体を理解する近道です。

結論から言えばこうです。コンセプトモデルは文法であり、ジェネシスは種であり、ビジネス・オントロジーは私たちの会社という文であり、セマンティック・ファクトリーはその文が現実と一致しているかを照合する証拠保管庫です。この一文を覚えておいていただければ、以下の詳細がすべてこの一文の注釈であることがお分かりいただけるはずです。

2.3.1 二段階モデル：メタオントロジーと会社オントロジー

サーバーの基礎設計文書が「これを誤解すると、その上のすべての階層が誤る」と釘を刺している概念があります。オントロジーは一つの層ではなく二つの層であるということです。

上層はメタオントロジーです。「業務対象」「エンティティ」「属性」「活動」「タスク」といった、名前の前に`#`が付くメタオブジェクトの世界です。九つのメタ・ビジネスオブジェクトモデル（実体関連モデル）ダイアグラムが一つに連結され、「どんな会社のモデルでも収められるものの文法」を宣言します。例えば「一つの業務対象は複数のエンティティを持つ」「事業部門は顧客セグメント、商品群、独立したチャネル群を持つ」といった関係とカーディナリティ（連結の個数の規則）がここで定められます。この層は会社についての知識ではなく、会社についての知識を記述する方法についての知識です。

下層が会社オントロジーです。例えば「紛争処理」という私たちの会社の業務対象は、二つの顔を同時に持っています。一つはメタオブジェクト「#業務対象」のインスタンスとして、データベースに記録された一行であるという顔であり、もう一つは自分自身のビジネスオブジェクトモデル・ダイアグラム — 紛争案件、紛争調査といった自らに属するエンティティを定義したモデル — を所有する一つのモデルであるという顔です。つまり「紛争処理」はメタダイアグラムと構造的に同じ種類の存在でありながら、一方は`#`が付いたフレームワークで、もう一方は会社の実物であるという違いがあるだけです。

管理者にとってこの区別が重要な理由は、問いの種類が分かれるからです。「紛争処理には何個のエンティティが定義されているか？」はモデルについての定義的な問いであるため、紛争処理自身のビジネスオブジェクトモデルで答えるべきであり、「紛争案件が今何件溜まっているか？」はインスタンスの問いであるため、データ行で答えるべきです。サーバーはこの二つの平面を厳密に区別します。設計文書の表現を借りれば、この階層規律が「正確な答えと、もっともらしく見える誤答との違い」を生み出します。実際、過去の誤答事例は例外なく、この二つの平面を混同したことから生じたと記録されています。

2.3.2 コンセプトモデル：言語の言語を磨く場所

コンセプト・オントロジー（ジェネシス・コンセプトエディタ）は、この文法層を直接編集する作業台です。画面ではコンセプト（concept）とその間の上位下位（IS-A）関係、OWLスタイルの属性、分類スキーム、そしてコンセプトと動詞の連結を扱います。私たちのドメインにおいて「顧客」と「借主」は同じものの異なる呼び名なのか、「融資」は「金融商品」の下位概念なのか、「リスク」という言葉はどの分類体系の下に置かれるのか — こうした問いへの答えを確定する場所です。

こうした問いが些細に見えるならば、用語のずれが組織にもたらすコストを思い浮かべてみてください。部署ごとに「顧客」の定義が異なり、報告書の数字が合わない事態、同じ指標を異なる名前で二重に管理する事態 — 人の組織でも高くつくこの混乱が、エージェントの世界では直ちに誤った自動判断につながります。

ここで注目すべきは、エディタの中に推論エンジン（reasoner）が内蔵されているという点です。保存ボタンを押して終わりではなく、サーバーがコンセプトグラフ全体を検査します。上位下位関係に循環が生じていないか（AがBの下位で、BがまたAの下位であるという矛盾）、互いに排他的（disjoint）と宣言された二つの概念を同時に継承する概念はないか、直接宣言してはいないが論理的に導かれる上位下位関係は何か。検査結果は、一貫性の有無、推論された関係の提案、充足不可能なクラスの一覧、同値グループとして整理され、画面に表示されます。

要するにコンセプトモデルは「用語集」ではなく論理的に検証される語彙体系であり、すべての修正はリビジョン履歴として残ります。

もう一つ、ガバナンス上の詳細にも触れる価値があります。コンセプトモデルは、ログインしているリポジトリのセッションに紐づいて保存されます。以前はクライアントがリポジトリ名を指定できたため、他のリポジトリのコンセプトモデルに触れられる隙がありましたが、サーバーのパッチによってセッションが唯一の権限となるよう塞がれました。小さな変更に見えますが、「誰がどの地図の文法を修正できるのか」という問いに、システムが構造的に答えられるようになったということです。概念を明確にする作業は容易な過程ではありません。多様なステークホルダーの業務要求に合わせて、全員が同意する意味として定義することは骨の折れる仕事です。コンセプトエディタでは、概念の分類、説明、そして関係にGenus（類）-Differentia（種差）-Species（種）を反復的に適用することで、一貫性があり重複のない固有の定義ができるようにし、概念定義の速度を飛躍的に短縮します。

2.3.3 ジェネシス：オントロジーの種子であり運搬形式

ジェネシスは二つの顔を持つ名前です。一つは先ほど見たコンセプトエディタの名前であり、もう一つはジェネシス・パッケージ — 業務対象定義とビジネスオブジェクトモデル・ダイアグラムを収めた移植可能なファイル形式です。この二つは偶然同じ名前を使っているのではありません。創世記（ジェネシス）というその名の通り、新しいオントロジーの世界が生まれる地点が、まさにここだからです。

流れは双方向です。出ていく方向では、よく磨き上げられたリポジトリの業務対象をジェネシス・パッケージとしてエクスポートできます。サーバーが該当リポジトリのビジネスオブジェクトとダイアグラムをまとめて一つの圧縮ファイルとしてストリーミングしてくれ、名前とバージョンがファイル名に刻まれます。入ってくる方向では、ジェネシス・パッケージから新しいリポジトリをブートストラップします。ファイルをアップロードし、会社名と管理者アカウントを指定すると、サーバーが業務対象とビジネスオブジェクトモデル・ダイアグラムを取り込み、メモリ内オントロジーと依存関係グラフを構築し、リポジトリは即座に使用可能な状態になります。すなわち、新しいビジネスオントロジーに基づくデジタルツインの世界が創造されるのです。

この双方向性が意味するところを管理者の言葉に置き換えるとこうなります。検証されたオントロジーは複製可能な資産になります。ある事業部で磨き上げられた与信ドメインのモデルをパッケージとしてエクスポートし、別の法人のリポジトリを開く種として使うことができ、パイロット・リポジトリで実験した構造を本番リポジトリへ移すこともできます。第1章で述べたMVO — 目的地が要求する分だけの最小限のオントロジーから始める — が実務で可能なのは、その「最小限」を収めて運ぶ規格化された器があるからです。だからこそ、MVOによるAIエージェントの適用は即座に効果を見せ、体系的な持続性を持つのです。

2.3.4 セマンティック・ファクトリー：文書の世界とモデルの世界をつなぐ橋

第三の柱であるセマンティック・ファクトリーは性格が異なります。コンセプトモデルとビジネス・オントロジーが人が意図的に設計する世界であるならば、セマンティック・ファクトリーは文書の山から知識を掘り出す工場です。画面の説明文がその性格を要約しています — 「文書添付から蓄積された知識です。」

内部動作はこうです。ウィキに添付された文書（規程集、契約書、業務マニュアルなど）をセマンティック分析の対象に指定すると、サーバーのビルダーがバックグラウンドで文書を読み込み、知識を抽出します。抽出単位は三つです。

第一に、文書が言及するエンティティです。各エンティティごとにページが作られ、新しい文書が入ってくるたびにそのページが累積的に充実していきます。第二に、エンティティに付随する事実です。すべての事実には、どの文書のどの箇所から得られたかという出典が必ず紐づきます。第三に、エンティティ間の関係トリプルです。文書の原文表現を保存しながら、自ら維持する関係語彙辞書に正規化されます。

抽出過程には忠実性ゲートがあります。原文に根拠が見当たらない — すなわちモデルが作り出した — 項目は保存される前に却下され、却下件数はログに残ります。AIが文書を読み込む一方で、AIの想像が知識ベースに入り込めないよう、門番が立っているのです。

そして、決定的な層がもう一つあります。矛盾検知です。セマンティック・ファクトリーが文書から発見したエンティティと関係は、オントロジーのエンティティとは別に管理されますが、システムはこの二つを定期的に照合します。文書には登場するがオントロジーには存在しない概念、文書が語る関係とオントロジーが宣言した関係が食い違う箇所 — これらが人がレビューすべき発見事項として整理されます。

ここで三本の柱のつながりが完成します。コンセプトモデルが文法を定め、ジェネシスがその文法に沿った構造を種として植えてビジネス・オントロジーを打ち立てると、セマンティック・ファクトリーは現実の文書がそのオントロジーと一致しているかを継続的に監視します。オントロジーが現実より先を行けば（宣言されたが証拠のない概念）それが見え、現実がオントロジーより先を行けば（文書にはあるがモデルにはない概念）それも見えます。第1章で「頭が鉤爪から学ぶ」と述べた一文が、ここでは「モデルが文書から学ぶ」という具体的なメカニズムとして実装されているのです。

2.4 最初の画面：オントロジーがそのままナビゲーションである

フレームワークを理解したところで、いよいよ画面に入っていきましょう。テオリアにログインすると、左側のアイコンサイドバーにこのアプリケーションの世界観が並びます。コンセプト・オントロジー、ビジネス・オントロジー、ITオントロジー、RAGシステム、オントロジー・プロジェクト、ドメイン管理、セマンティック・ファクトリー。一般的な業務システムが「メニュー」を並べるとすれば、テオリアは「私たちのビジネスを見つめるレンズ」を並べるのです。

中心はビジネス・オントロジー・ツリーです。商品ポートフォリオ、顧客セグメント、チャネル分類、市場、業務アーキテクチャの能力モデルと業務領域、業務コンポーネント、業務対象 — このツリーはフォルダ一覧ではなく会社構造そのものであり、チームメンバーがどんな作業をしようとも、その作業は必ずツリーのどこかに掛かっています。「この文書はどの業務の成果物なのか？」という問いに、ファイルパスではなくビジネス構造上の座標で答えることになるのです。

画面下部のステータスバーは、どのサーバーのどのリポジトリに接続されているか、現在どのエンティティが選択されているかを常時表示し、複数のリポジトリを行き来するチームのミスを減らしてくれます。

ツリーが最初に生まれる方法は、先に見た通りジェネシス・ブートストラップであり、育つ方法は以降の節で見る補強と編集です。ここで管理者が覚えておくべきことは一つです。ツリーはすべての作業の座標系であるため、ツリーを整える権限と責任が明確でなければならないという点です。

2.5 作業スペース：ダブルクリックで開く業務解決策ウィザード

ツリーでエンティティをダブルクリックすると、右側に作業スペースが開きます。ブラウザのタブのように複数を同時に開くことができ、シナリオ・プロセスダイアグラム・補強エディタ・レポートを並べて行き来できます。

その代表格が、業務解決策シナリオ・コンポーザーです。左側のツリーダイアグラムで文書の構造をノードとして組み立て、右側の詳細パネルで各ノードに文脈と質問を記入した後「マイニング」を押すと、AIが業務解決策の内容をマイニングして生成します。重要なのは、AIが白紙から作り出すのではないという点です。他のノードの内容、添付したPDF、ウェブ検索結果、RAG（検索拡張生成）で検索した社内知識がコンテキストとして一緒に取り込まれ、生成された内容は完全性・明確性・一貫性・実行可能性の四つの軸で品質分析を受けることができます。

AIエンジン自体も管理対象です。設定のブレイン（Brain）タブでLLMプロバイダー、温度とトークン上限、システムペルソナを定め、シナリオ単位・ノード単位で設定を変えて与え、「設定の伝播」で階層全体に反映させることができます。AIの活用が個人技ではなくチーム標準の領域になるということです。同じツールを使っていても、あるチームは標準設定と充実したコンテキストで作業し、別のチームはそれぞれ勝手に作業するのであれば、成果物の品質格差はツールではなく慣行から生まれます。

作成が終わった内容は公開プレビューで確認し、ノードまたは階層全体を公開し、翻訳連携で翻訳版を作成し、外部の公開プラットフォームへエクスポートすることもできます。各ノードには下書き・レビュー中・承認済み・ロック済みの状態が付き、「この文書はどこまで進んだか？」が一つのステータス値で答えられ、バージョン履歴で過去のスナップショットの比較と復元が可能です。

2.6 設計から実行可能なモデルへ：オントロジー詳細エディタ群

ここがテオリアが一般的な文書ツールと分かれるポイントです。作業空間では文章を書くだけでなく、実行の材料となるモデルを描きます。

ワークフロー設計は、BPMN標準（業務プロセスを描く国際標準表記法）に基づいたタスクフローエディタです。業務の開始と終了、タスクとサブプロセスを配置し、各タスクに担当ビジネスコンポーネントを指定します。

判断が必要なタスクは業務決定設計へと接続されます。ここはDMN標準（意思決定モデリングの国際標準）の意思決定テーブルエディタで、「どのような条件ならどのような結論になるか」という業務ルールが、担当者の頭の中ではなく、検討可能なテーブルとして文書化されます。そのほか、ビジネスオブジェクトモデルビューアとレポート、商品設計、戦略目標設計、ビジネスコンテキストダイアグラムなどが、エンティティタイプに応じた動的メニューとして提供されます。

これらのダイアグラムは絵で終わりません。BPMNエディタには「Poiesisへ提出」ボタンがあり、完成したタスクフローを作る翼へと引き渡し、設定にはPoiesis URLとPraxis URLが並んで配置されています。私たちのチームがここで描くプロセスと決定テーブルは、参考資料ではなくエージェントが実際に従うことになる仕様です。それだけ正確に描く必要があり、それだけ描く価値があります。

2.7 補強と顧客価値実現：オントロジーに肉付けをする作業

2.7.1 補強：エージェントという新しい職員の職務記述書

ツリーが骨格だとすれば、実務時間が最も多く費やされるのは、その骨格に肉付けをする補強（Enrichment）です。エンティティを右クリックすると、タイプに応じた補強エディタが開きます。業務対象補強はオブジェクトの属性と意味を、ドメイン知識補強はその領域の概念・手順・ヒューリスティック・因果関係・ルール・規制を、業務決定補強は決定の条件とパラメータを埋めていきます。

そして、役割補強、スキル補強、ツール補強、ガバナンスポリシー補強——この四つを並べて読んでみると、人の組織を設計する際に問う質問とまったく同じであることに気づかれるでしょう。どのような役割が必要か、その役割にはどのようなスキルが必要か、どのようなツールを持たせるか、どのようなポリシーの下で働かせるか。補強作業とは、すなわちAIエージェントという新しい「職員」の職務記述書を書く作業なのです。

ただし、決定的な違いが一つあります。その職務記述書は自然言語の文書ではなく、オントロジーに結合された構造化データであるという点です。そのため、「このポリシーを変更するとどのエージェントが影響を受けるか」をシステムが追跡できます。人の職務記述書は引き出しの中で眠りますが、エージェントの職務記述書は生きたまま接続されています。

2.7.2 顧客価値実現（CVR）：ニーズからエージェントポートフォリオまで

顧客に向けた補強が顧客価値実現（CVR）エディタです。一つの顧客活動を七つの段階で扱います。

まず顧客ジャーニーとドライバーをマッピングするフレームがあり、タスクと成果を重要度・満足度でランク付けするタスク定義が続きます。満たされていない成果をソリューションとエージェントコンセプトへと変えるアイディエーション、価値の流れを接点・チャネルのスイムレーンとして具体化する設計、機会をポートフォリオへと収束させるAIエージェント機会段階がそれに続きます。顧客要求と設計対応の整合性はQFD（品質機能展開／品質の家）手法で検証され、最後に定義段階の成果に対する実現の有無を確認する実現・測定段階が循環を閉じます。ニーズからトレードオフ、詳細実装へと降りていく反復ファネルも併せて備わっており、一つのシナリオをラウンドごとに忠実度を高めていくことができます。

デザインシンキングの言葉をそのまま用いながらも、成果物がワークショップの付箋で終わらず、オントロジーとエージェントポートフォリオへ直結するツールであるという点が差別化要素です。

2.7.3 能力カプセルワークベンチ：知識が最終パッケージ化される場所

知識とスキルが最終的にパッケージ化される場所が能力カプセルワークベンチです。能力カプセルは、まるで風邪薬の複数の薬剤が一つのカプセルに収められて効能を発揮するように、目標とする能力の効能を伝えるための業務ドメイン知識とスキルパックがカプセル化された単位です。ドメイン知識カプセルと能力カプセルはバージョン単位の独立した文書として保存され、すべてのカプセルは下書き→レビュー提出→承認→公開というライフサイクルに従います。提出されたカプセルは差し戻し・撤回が可能で、承認されたカプセルも公開前であれば撤回できますが、一度公開されたバージョンは最終版です。修正が必要な場合は新しいバージョンを作成する必要があります。

この単純なルールの重みを指摘しておきたいと思います。エージェントが参照する知識には常に「誰がいつ承認したどのバージョンか」というタグが付くということ——これが事後監査やインシデント調査において組織を守る最も基本的な防衛線です。

2.8 二つのハーネス：システムが崩れない理由

第1章では、ワシの胸をX字に横切るネクサス・ハーネスについて述べました。行動と統制という二つの交差したベルト、そしてその緊張を保持するガバナンスというバックル。テオリアとAOEDEオントロジーサーバーのコードを覗いてみると、その比喩が実際に二種類のハーネスとして実装されていることに気づきます。一つはオントロジーモデル自体を統治するモデルハーネスであり、もう一つはAIの実行を統治する実行ハーネスです。この節が第2章の心臓部です。

2.8.1 オントロジーモデルハーネス：MVOを混乱から救う規律

MVOアプローチの魅力は明確です。全体をすべて設計するのではなく、今必要なスキル一つに十分な最小限のオントロジーから始めるということ。しかし、このアプローチにはよく知られた影があります。ボトムアップで断片的に育つモデルは、統治する手がなければたちまち混乱に陥ります。チームAが作った「顧客」とチームBが作った「顧客」が微妙に異なる意味になり、昨日のエンティティ名が今日変わっており、循環参照と矛盾した分類が誰も気づかぬまま積み重なっていきます。事前設計の硬直性を避けようとして無秩序状態に到達すること——これがボトムアップアプローチが失敗する典型的な経路です。

オントロジーモデルハーネスは、この経路を防ぐために四層で締め上げられています。

第一層はメタオントロジーという文法です。どのチームがどのような順序で何を作ろうとも、作られるものはすべて`#`で始まるメタオブジェクトが宣言した形式——業務対象はエンティティを持ち、エンティティは属性を持つという文法——の中でしか存在できません。ボトムアップではあっても、無形式ではないのです。サーバーはリポジトリを開く際にこの文法をメモリ上に読み込み、入ってくるデータをその文法と照合して検証します。

第二層は概念推論エンジンです。先に見たとおり、概念モデルへのすべての変更は、循環検査、排他衝突検査、充足不可能クラス検出を通過します。各チームがそれぞれ概念を追加しても、論理的矛盾は保存時点で明らかになり、システムが推論した暗黙の上下位関係は提案として表示され、人が確定します。

第三層は境界と履歴です。概念モデルとオントロジーデータはログインセッションが指すリポジトリにのみ帰属し、他のリポジトリに触れられる隙間が構造的に塞がれています。編集ロックは二人が同じ対象を同時に修正する事故を防ぎ、リビジョン履歴とバージョン管理はすべての変更を追跡可能にし、ごみ箱は削除さえも復元可能な行為にします。カプセルライフサイクルの承認ゲートは、この履歴の上に人の判断を重ねます。

第四層が最も興味深いものです。セマンティック・ファクトリーの矛盾検知です。前の三層がモデル内部の整合性を守るとすれば、この層はモデルと現実の文書との間の整合性を監視します。MVOで育つオントロジーが「重なり始めるとき」——解約スキルの「顧客」と融資スキルの「借主」が出会うその瞬間——調整の根拠となるのが、まさにこの証拠層です。

この四層を一文に凝縮すればこうなります。モデルハーネスがあるからこそ、爪の一本一本のように育つオントロジーが大聖堂ではなく地図になりながらも、その地図が落書き帳にはなりません。モデルハーネスのないボトムアップは、速く始まって速く泥沼にはまるアプローチであり、モデルハーネスのあるボトムアップこそが、初めてMVOという名に値するのです。

2.8.2 AIエージェント実行ハーネス：問題生成機にならないための条件

二つ目のハーネスは方向が逆です。モデルハーネスが「地図を描く手」を統治するなら、実行ハーネスは「地図の上を走るAI」を統治します。そして、こちらの失敗の様相はより騒々しいものです。統制されていないAI実行システムは静かに腐るのではなく、積極的に問題を生み出します。存在しないテーブルを照会するクエリ、もっともらしくでっち上げられた数字、要求をこっそり狭めておきながら全体に答えたふりをする応答、限界を知らない探索がシステム全体を引きずり下ろす負荷。目標志向的に動くエージェントほど、手綱がなければその目標に向かって忠実に事故を起こします。

AOEDEオントロジーサーバーの自然言語クエリハーネスは、この問題に対する教科書的な答えを備えています。設計文書が「交渉の余地のない二つの原則」と呼ぶものから出発します。

第一に、スキーマ幻覚の禁止です。AIは実在しないエンティティ・属性・関係を参照するクエリを決して実行できません。第二に、読み取り専用と有限性です。すべてのクエリは読み取りのみで、結果件数と探索の深さが構造的に上限に縛られます。

そして、決定的な条件が付きます。この二つの原則は「AIが善良に振る舞うこと」や「レビュアーが勤勉であること」に依存してはならず、構造的に強制されなければならないということです。善意と勤勉さは良いものですが、アーキテクチャの安全性をその上に築くことはできません。

そのため、アーキテクチャは三つの層（tier）に分かれ、その間にただ一つの信頼境界が引かれます。

A層——言語理解（信頼しない）。LLMが自然言語の質問を受け取り、形式化されたクエリ計画——解釈・選択・探索・集計・影響分析といった型を持つ演算のグラフ——へと翻訳します。要点は、この層の出力を誰も信用しないということです。LLMはデータベースクエリ言語を直接書くことができず、中間表現しか出力できず、その中間表現は間違っていてもかまいません。誤った計画は次の層でふるい落とされるからです。

B層——検証とコンパイル（信頼境界）。決定論的なコードがA層の計画を受け取り、計画のすべての末端——対象エンティティ、属性、関係、指標——を生きたスキーマカタログと照合して結束（バインド）します。結束できない葉は実行されずに脱落し、生き残った演算だけがコンパイラを通過します。コンパイラはシステム内でクエリ言語を生成できる唯一のコンポーネントであり、生成されるすべてのクエリは読み取り専用で、件数・深さの上限が課された状態でのみ作られます。計画が「9999段階の探索」を要求しても、設定された最大値に切り詰められます。

そして——管理者の視点から見ると白眉なのですが——この層は理解レポート（Comprehension Report）を併せて出力します。質問のうち何がそのまま実行され、何が絞り込まれ、何がなぜ脱落したのかの明細です。システムはできないことを黙って省いて答える代わりに、できなかったと述べます。

C層——実行と検証（決定論）。検証済みの計画が実行され、クリティック（critic）が結果を検査します。結果が空になっていないか、形が質問に合っているか、条件が実際に適用されたか。問題があれば有限回数の範囲内で計画を修正して再試行し、最終結果は関連度で並べ替えられ、根拠・出典・能力レポート・実行トレースとともに返されます。

この構造がユーザーにどのように見えるかは、すでに体験されたことがあるかもしれません。オントロジーQ&Aで「確定した影響」と「影響の可能性あり——検討が必要」が区別され、推論項目に未確定の表示が付き、一致するエンティティがない場合に「影響がないことを確認したのとは違う」と明示されること——その画面上のすべての文言の背後に、この三層ハーネスがあります。

2.8.3 二つのハーネスは一対である

まとめましょう。モデルハーネスがなければ、ボトムアップで構築する瞬間にオントロジーは混乱に陥ります。断片同士が噛み合わず、名前が衝突し、矛盾が沈黙のうちに積み重なり、MVOの「最小限」は「杜撰さ」の別名になってしまいます。実行ハーネスがなければ、システムは問題生成機になります。もっともらしい誤答が確信に満ちた口調で届けられ、統制されていないクエリがリソースを消費し、エージェントは目標に向かって忠実に誤った道を進みます。

そして両者は互いを必要としています。実行ハーネスのB層が末端を結束する対象である「生きたスキーマカタログ」は、モデルハーネスが整合性を守ってきたオントロジーそのものです。モデルが乱れていれば、どれほど優れた実行ハーネスであっても、乱れた地図の上を正確に走るだけです。逆に、実行ハーネスの能力レポートとセマンティック・ファクトリーの矛盾発見は、モデルの空白を照らす明かりとなり、モデルハーネスが次に統治すべき対象を教えてくれます。ワシの紋章のX字——互いを張り詰めて引き合う二本のベルト——は装飾ではなく、この相互依存の肖像であったというわけです。

2.9 ジェネシスからデジタルツインへ：段階的構築とナビゲーションマップ

いよいよ最後の全体像です。ここまで見てきたすべての断片——ジェネシスの種、二層のオントロジー、補強、セマンティック・ファクトリー、二つのハーネス——は、実は一つの目的地に向かって整列しています。それが私たちのビジネスのデジタルツインです。

ここでいうデジタルツインとは、工場設備の3D複製のようなものではありません。私たちのビジネスの構造と知識と状態をコンピュータが理解できる形で映し出し、質問すれば根拠を持って答え、変更すれば波及を示してくれる生きた対応物を意味します。

重要なのは、このツインが一度の大工事で作られるわけではないという点です。ジェネシスはその段階的構築の礎石であり、オントロジーは各段階で道に迷わないようにしてくれるナビゲーションマップです。構築の六つの段階をたどってみましょう。

第1段階——種を植える。ジェネシスパッケージでリポジトリをブートストラップします。この瞬間に生まれるのは骨格だけです。業務対象群とそのビジネスオブジェクトモデル、そしてメタオントロジーという文法。しかし、この骨格こそが地図の骨組みです。以後のすべての作業が「オントロジー地図のどこに」置かれるかが、この瞬間に決まります。

第2段階——定義平面を立てる。各業務対象のビジネスオブジェクトモデルを磨き上げ、概念モデルにおいて用語の上下位関係と排他関係を確定します。推論エンジンが矛盾をふるい分けるなかで、「私たちのドメインにおいて何が存在し、どのように結びついているか」という定義的知識の平面が完成していきます。この平面がデジタルツインの座標系です。

第3段階——肉付けをする。補強エディタ群で属性と意味、ドメイン知識、決定ルール、役割・スキル・ツール・ポリシーを埋め、BPMNとDMNでプロセスと判断をモデリングします。ツインが構造だけでなく振る舞い方を持ち始めます。

第4段階——証拠をつなぐ。セマンティック・ファクトリーに実際の文書群を流し込みます。規定集や契約書、マニュアルから抽出された事実と関係が出典を伴った状態で積み重なり、矛盾検知がモデルと現実のずれを照らし出します。ツインが設計図の複製ではなく現実の反映になる段階です。

第5段階——グラフとして目覚める。デジタルツインRAGがオントロジーと補強内容全体から知識グラフを構築します。このとき、先に見た階層の規律がそのまま守られます。定義的な質問はビジネスオブジェクトモデルに由来するモデル平面で、インスタンスに関する質問はデータ行平面で——二つの平面が混ざらないからこそ答えが正確になります。そして、このグラフの上で実行ハーネスが自然言語の質問を安全に受け止めます。

第6段階——増殖する。十分に成熟したリポジトリは、再びジェネシスパッケージとして書き出され、次のドメイン・次の法人・次の実験の種になります。カプセルのインポートとコレクションのExcel入出力が部分単位での移動を担います。一つのツインの完成が、次のツインの出発点になるのです。

この六つの段階がMVOのリズムと正確に重なり合う点に注目していただきたいと思います。どの段階も「全体を終えなければ」次へ進めない関門ではありません。一つの業務対象、一つの能力カプセルのスキル範囲の中で1段階から5段階までを小さく完走し、その完走を隣接領域へと広げていきます。そして各段階においてオントロジーツリーがナビゲーションマップの役割を果たします。今、私たちが地図のどの区域を築いているのか、どの区域が定義だけあって証拠がないのか、どの区域が文書とずれているのか——ツリーと状態値と矛盾レポートが常にそれを示してくれます。霧の中で建てるのではなく、地図を見ながら一区域ずつ明かりを灯していく建設なのです。

このリズムが組織にもたらす心理的効果も軽視できません。数年がかりの大工事は完工前まで誰も成果を手にできないため、途中で予算が揺らぎ、スポンサーが交代すればプロジェクト全体が漂流してしまいます。一方、一区域ずつ明かりを灯していく建設では、四半期ごとに実際に灯った明かり——展開されたスキル、答えられるようになった質問、減少した見落とし——を示すことができます。オントロジープロジェクトが生き残る条件は完璧な設計ではなく、着実に示し続けられる明かりであるということを、この六段階の構造は最初から織り込んでいます。

2.10 オントロジーに直接尋ねる：ツインとの対話

構築の報酬は対話です。オントロジーQ&Aタブを開くと、チームが積み上げてきたツイン全体を相手に自然言語で質問を投げかけることができます。「『個人』業務対象の詳細情報と能力を説明してほしい」「ここでいうLTVとは何を意味するのか」「このエンティティを削除すると何が影響を受けるのか」、さらには「どのプロセスが最も複雑か？複雑度はタスク数で計算せよ」のように、ユーザーがその場で指標を定義するような質問まで受け止めます。

回答の性質は、すでに前節で見た実行ハーネスが決定します。説明型の質問には、サーバーがオントロジーを正確に照会し決定論的に構成したブロック——何が一致し、どこに属し、上下位の依存関係が何であるか——が権威ある答えとしてまず提示され、AIが合成した記述はその下に置かれます。根拠となるノードはグラフとして可視化され、クリックすると属性が開きます。影響分析では確定と推定が区別され、補強の接続に異常が検知されると、該当項目が確定結果から除外されたことが明示されます。

管理の観点から見ると、この機能は二つのことを変えます。第一に、「これを変えたら何が壊れるか」という変更影響の質問が、担当者の招集や会議の召集なしに、数秒で一次回答を得られます。第二に、チームが補強と文書連携を丁寧に行うほど回答の品質が目に見えて向上するため、オントロジー管理が「後のための文書化」ではなく、「今すぐ返ってくる投資」になります。

2.11 一日の流れで見るテオリア

ここまでの話をあるチームの一日に置き換えてみると、この作業台の手触りがより生き生きと感じられます。

朝、オントロジー担当者がテオリアにログインします。画面下部のステータスバーがどのサーバーのどのリポジトリに接続されているかを確認させてくれ、左側のオントロジーツリーには昨日まで磨き上げてきた会社の構造がそのまま広がっています。夜の間にセマンティック・ファクトリーが新たに添付された与信規定の改定版を読み込んでおり、矛盾検知が二件の発見事項を上げています。一つは改定規定には登場するもののオントロジーにはまだない概念で、もう一つは文書が語る関係とモデルが宣言している関係とがずれている箇所です。担当者はこの二件を、今日の午後のオントロジー協議体の議題へと移しておきます。モデルと現実のずれが放置された負債ではなく朝会の議題になること——これがこの作業台の日常です。

午前中には、業務設計者が「紛争処理」業務対象をダブルクリックして作業空間を開きます。シナリオコンポーザーで新しい業務シナリオの骨格をノードとして組み立て、各ノードにコンテキストと質問を書き込んだ後、マイニングを押します。AIが下書きを埋めますが、その材料は白紙ではなく、他のノードの内容と添付された規定文書、RAGで検索された社内知識です。生成された内容は完全性・明確性・一貫性・実行可能性の四つの軸で品質分析を受け、ノードには「レビュー中」のステータスが付きます。隣の席の同僚は同じ時刻にBPMNエディタでタスクフローを磨いており、判断が必要なタスクにはDMN意思決定テーブルが接続されていきます。

午後、ドメイン能力カプセルが一つ、レビューに提出されます。承認者はカプセルの内容がゴールドスタンダードに照らして十分か、出典がきちんと付いているか、実行結果が約束された能力を提供しているかを確認したうえで、承認の印を押します。このバージョンは公開されれば最終版となり、以後どのエージェントがこの知識を参照しても「誰がいつ承認したどのバージョンか」というタグが付いて回ります。退勤間際、チームリーダーはオントロジーQ&Aタブを開き、「このエンティティを削除すると何が影響を受けるか」を尋ねます。数秒後、確定した影響と検討が必要な推定とが区別されて返ってきて、能力レポートはどの部分を絞り込んで答えたのかを正直に明かします。チームリーダーはその「絞り込んだ部分」を来週補強すべき区域としてメモします。

この一日にドラマチックな場面はありません。しかし注意深く見れば、すべての作業に同じ文法が流れています。発見はシステムが行い、調整は人が行い、生成はAIが行い、確定はレビューが行い、知識は積み重なりますが必ず出典と承認のタグを伴って積み重なります。今日もまた、新しい能力が会社の運営に加わりました。デジタルツインは、こうした一日一日が積み重なって育っていくものであり、ある日竣工式を開く建物ではないのです。

2.12 結びに：頭を託された管理者へ

テオリアとそのサーバーを一文で要約すればこうなります。概念モデルという文法の上に、ジェネシスという種で会社のビジネスオントロジーを植え、セマンティック・ファクトリーで現実の証拠をつなぎ合わせ、二つのハーネスでモデルと実行を共に統治し、段階的にデジタルツインを築き上げていく作業台。多言語対応、編集ロックとバージョン履歴、ごみ箱とカプセルの入出力といった実務装置が、その作業を支えてくれます。

この作業台を任されることになる管理者にいくつかお伝えしておきたいことがあります。最初に決めておくべきはジェネシスと概念モデルの管理権限です。オントロジージェネシスはすべての作業の座標系であり、概念モデルはその座標系の文法であるため、文法が乱れれば、その上に書かれるすべての文章がともに乱れてしまいます。誰がツリーの構造を変更でき、誰が概念の定義を確定するのかは、導入初週に名前で決めておくべき問題です。次に、ブレイン設定と補強の慣行をチームの標準として確立することです。同じツールであっても、コンテキストを丁寧に埋めるチームとそうでないチームでは成果物の品質に大きな差が生じるため、設定伝播機能はまさにその標準を階層全体に展開するために用意されているものです。

カプセルライフサイクルの承認者の役割も軽く見てよいものではありません。下書きから公開へと移るその関門が、私たちのチームが生み出すエージェントの信頼水準を決定づけるため、承認は決裁ではなくレビューでなければなりません。セマンティック・ファクトリーが上げてくる矛盾レポートも同様です。モデルと文書のずれは放置すれば負債になりますが、定期的な議題として扱えば、オントロジーが育つ最も安価な原料になります。ハーネスは発見までしか行ってくれず、調整は常に人の役割だからです。

そして最後に、理解レポートを読む文化を作っていただきたいと思います。システムが「この部分は絞り込んで答え、この部分は答えられなかった」と正直に述べるとき、その告白を聞き流さないチームだけが、正直なシステムの価値を余すところなく享受できます。正直な失敗報告は減点の材料ではなく、次に築くべき区域を教えてくれる地図なのです。

ワシの頭はもはや抽象的な概念ではなく、毎朝開いて仕事をする画面であり、ハーネスは比喩ではなくコードで締め上げられた実物であり、デジタルツインはある日完成するプロジェクトではなく一区域ずつ明かりを灯していく地図です。見えるところまでだけ定義し、定義した分だけ補強し、補強したものを二層のハーネスで統治して引き渡すこと——テオリアでの一日一日が、まさにその地図に明かりを灯す作業なのです。

第2章の要点：テオリアは、概念モデル（文法）、ジェネシス（種であり運搬形式）、セマンティック・ファクトリー（証拠の保管庫）という三本の柱の上に築かれたオントロジー作業台である。モデルハーネス（メタ文法、推論エンジン、境界と履歴、矛盾検知）がボトムアップの成長を混乱から守り、実行ハーネス（A層の言語理解、B層の検証・コンパイル、C層の実行・検証）がAIの回答を構造的に強制する。この上でデジタルツインが六段階にわたり、MVOのリズムに合わせて育っていく。

第3章 ポイエーシス（POIESIS）：作る翼

本章で扱う内容：ポイエーシス（POIESIS）が作るものの正体（エージェントではなくエージェント・ハーネス）、ハーネスの三つの大きさ（活動・タスク・スキル）と導入のはしご、そしてポイエーシス（POIESIS）が組織に付与する八つの能力。事例ドメインには住宅ローン審査を使用します。

3.1 はじめに：ポイエーシス（POIESIS）が作るものの正体

第2章は一つのボタンで終わりました。テオリアで完成した業務フローを、作る翼へ引き渡す「Poiesisに提出」ボタンです。本章はそのボタンが押された後の物語です。

ただし、物語を始める前に、AOEDE-ポイエーシス（POIESIS）が作るものの正体を正確にしておく必要があります。ポイエーシス（POIESIS）は、いわゆる「AIエージェント」を作る場所ではありません。より正確に言えば、AIエージェント・ハーネスを組み立てる場所です。

この区分は言葉遊びではありません。裸のAI——賢いが手綱のない知能——は市場のどこでも手に入ります。企業が作らなければならないのは、その知能に装着する馬具（ばぐ）です。何を知っているべきか、何ができるか、どこまで進んでよいか、どの地点で必ず止まる、あるいは人に引き渡さなければならないかが組み込まれた構造物。第2章で実行ハーネスについて「手綱のない目標志向エージェントは、目標に向かって忠実に事故を起こす」と述べた、まさにその問題意識が、ポイエーシス（POIESIS）では作ることそのものの対象になります。ポイエーシス（POIESIS）において「作る」ということは、すなわち「ハーネスを組む」ということです。

ポイエーシス（POIESIS）が対象とするユーザーが開発者ではなくビジネスアナリストと業務設計者であるという点も、この正体とつながっています。ハーネスの本質——どこまで任せ、どこで止めるか——は技術的判断ではなく業務判断だからです。エージェントの内部仕様は専用言語で記述されますが、ポイエーシス（POIESIS）の存在理由は、現場の専門家がそのコードを直接書かなくても、自然言語と視覚的な設計ツールで完結したハーネスを組み立てられるようにする点にあります。コードは成果物であって、入場券ではありません。

本章は画面案内書ではありません。まず、ポイエーシス（POIESIS）が築くハーネスの三つの大きさ——活動、タスク、能力——を理解し、その上でポイエーシス（POIESIS）が組織に付与する八つの能力を一つずつ見ていきます。事例には、システムに実際に搭載されている住宅ローン審査ドメインを使用します。

なお、組み立てられたハーネスの内部規格と、それを実行するエンジンの話——ネクサス（NEXUS）とミメーシス（MIMESIS）——は本章では扱いません。それは、配備されたエージェントが実際に働く舞台であるプラクシス（PRAXIS）とともに、第4章で余すところなく展開するのが適切だからです。

3.2 三段階のハーネス：活動（ワークフロー）、タスク、能力

ポイエーシス（POIESIS）の作業対象リストを開くと、実装対象が最初から二つの層に分かれて到着していることが分かります。活動レベルとタスクレベルです。そして、その下で能力の階層が設計されます。この層区分は整理用フォルダではなく、AOEDEが自動化を捉える視点そのものです。ハーネスには三つの大きさがあり、大きさごとに目的と人の立ち位置が異なります。

3.2.1 活動（ワークフロー）レベル・ハーネス：流れ全体を包む最大の馬具

活動レベル・ハーネスは最大の馬具です。一つの業務活動——例えば住宅ローン審査という最初から最後までの流れ全体——を包み、目標は自律運用（autonomous operation）です。申込受付から最終意思決定まで、複数のタスクと複数の関門を通過するエンドツーエンドのワークフローがエージェントたちの協働で回り、人は流れの中の定められた介入ポイントと例外エスカレーションにのみ登場します。

この大きさのハーネスが担うべきものは、個別判断の品質を超えた流れ全体の健全性です。関門間の整合性、役割間の引き継ぎ、全体の基調の調整までがハーネスの一部です。

3.2.2 タスクレベル・ハーネス：一つの役割の代理人

タスクレベル・ハーネスは中間の大きさです。活動全体ではなく、特定の役割が遂行する一つのタスク——例えば審査担当者による担保評価、コンプライアンス担当者によるマネーロンダリング点検——を包みます。この大きさでは、エージェントは流れの主人ではなく、一つの役割の代理人または同僚です。タスクの入力と出力、そのタスクに必要なスキルと習熟度、タスクが守るべき規則と権限がハーネスの内容となり、タスクの前後は依然として人または他のハーネスがつなぎます。

3.2.3 能力レベル・ハーネス：最も小さいが最も精巧な馬具

能力レベル・ハーネスは最も小さいものの、ある意味で最も精巧な馬具です。目標が自動化ではなく、人の働き手の能力拡張（augmentation）だからです。担保価値の算定、所得書類の検証、規程の照会といった一つの能力単位において、エージェントは人に取って代わるのではなく、人の手に握られる精密な道具になります。

そして、まさにそれゆえに、この小さなハーネスには二つのことが凝縮されていなければなりません。第一に、その能力に関する包括的な知識——関連するドメイン知識、スキル、判断の材料、参照すべき規程と出典。第二に、統制ポイント（control points）——ある値は必ず検証を経なければならず、ある結論は絶対に下してはならず、ある場合には必ず人の確認を受けなければならないという地点です。要するに、能力ハーネスとは「物事が正しい方法でのみ行われるようにする」知識と手綱の最小完結単位です。

3.2.4 重なり合う構造、そして導入のはしご

三つの大きさの関係も重要です。これらは互いに異なる三つの製品ではなく、重なり合う構造です。活動ハーネスはタスクハーネス群の編み合わせであり、タスクハーネスは能力ハーネス群の編み合わせです。第1章で能力カプセル（Capability Capsule）について「各カプセルは縮小された一羽のワシである」と述べた一文が、ここで構造的な意味を得ます。最も小さな能力ハーネスにも知識と統制が完結的に含まれているからこそ、それらを積み上げたタスクと活動も崩れないのです。

管理者にとって、この三段階はすなわち導入のはしごでもあります。組織はたいてい、能力ハーネスから出発するのが安全です。人が依然としてハンドルを握ったまま、拡張された能力の品質を検証する段階です。検証されたスキルが集まれば、一つの役割のタスクをハーネスに任せることができ、タスクが十分に熟せば、ようやく活動全体の自律運用を論じる資格が生まれます。第1章のMVO（実行可能最小限オントロジー）——爪一本、能力一つずつ育つオントロジー——とまったく同じリズムです。自律性は宣言するものではなく、小さなハーネスから積み立てていくものです。

人を採用することになぞらえると、このはしごの感覚がより鮮明になります。新入社員に初日から部署全体の運営を任せる組織はありません。最初は先輩のそばで資料調査や草案作成といった一つの仕事(能力)を手伝わせ、腕前が検証されれば一つの業務(タスク)を完全に任せ、複数の業務で信頼が積み重なって初めて、一つの流れ全体(活動)を任せます。AOEDEの三つのハーネスは、この常識的な昇進の仕組みをエージェントにそのまま適用したものであり、後で見る認証と習熟度の仕組みは、その昇進の人事記録に相当します。

それでは、この三段階のレンズをかけて、ポイエーシス（POIESIS）が組織に付与する八つの能力を歩いてみましょう。

3.3 第一の能力：ハーネス実装のパイプラインを一目で把握する

ポイエーシス（POIESIS）が管理者に与える最初の贈り物は、華やかな機能ではなく可視性です。テオリアから引き渡された実装対象は、活動レベルとタスクレベルに層分けされた状態で到着し、到着した瞬間から一つのライフサイクルを付与されます。受付済み → 作成中 → 検証済み → 配備済み、そしてどの段階からでも移行しうる差し戻し。

この五つの状態は単なるラベルではありません。ポイエーシス（POIESIS）の作業フロー自体が作成 → 検証 → バージョン → 配備という四段階の順次工程で組まれており、各工程は次の工程への入場条件となります。作られていないハーネスは検証できず、検証されていないハーネスは配備できません。状態は、その工程上で各ハーネスが今どこにいるかを示す座標です。

管理者の立場から見て、これが変えるのは進捗会議の言葉です。「あの件はどうなっているか」という問いに、担当者の記憶で答える代わりに、パイプライン上の座標で答えるようになります。どの活動ハーネスが何週間も「作成中」にとどまっているか、タスクハーネスのうち「検証済み」と「配備済み」の間にボトルネックがあるかは、照会の対象になるのであって、聞き回りの対象にはなりません。

小さな一つの規律が、この能力の性格をよく表しています。根拠となるドメインデータが接続されていない対象は、そもそも作業を開始できないようロックされています。データなしにハーネスから組み始めること——あらゆる実装プロジェクトが一度は経験する誘惑——が、このパイプラインでは構造的に起こりません。

3.4 第二の能力：シナリオから出発するハーネス設計

ハーネス組み立ての最初の一手は、コードではなく物語です。担当者はこの活動またはタスクが行うことを自然言語のシナリオとして記述し、この業務が達成すべき目標を併せて定義します。そして、AIの支援を受けながら、そのシナリオを構造化された設計草案へと発展させます。

ここで重要なのは、AI支援の方式です。ポイエーシス（POIESIS）のAI生成は自由作文ではなく、規格が与えられた作文です。ハーネスにどのような構成要素が存在しうるか、それらが互いにどう結合しうるかが、あらかじめ定義された規格としてシステムに登録されており、生成はその枠内でのみ行われます。第2章の原則——「AIの出力は検証されるまで信頼されない」——が、設計段階では「AIの出力は規格の中でのみ生まれる」という形で貫かれているのです。ハーネスを組むアシスタントにも、ハーネスが装着されているというわけです。

AI活用の条件そのものもチームの資産として管理されます。どのモデルをどの温度（temperature）とペルソナで使うか、翻訳をどう付けるかが設定として標準化されているため、誰が作成しても同じ条件で同じ品質の草案が得られます。インターフェースは韓国語・英語・中国語・日本語を行き来し、多国籍チームが一つのドメインを共に設計する状況を最初から想定しています。

管理者の目でこの能力をまとめると、次のようになります。設計の出発点が現場の言葉になり、AIはその言葉を規格へと翻訳するアシスタントになります。現場が要件を書いて開発組織に投げ、数週間後に翻訳の誤りを発見するという従来のリズムが、現場が直接ハーネスの草案を手にするリズムへと変わるのです。

3.5 第三の能力：ハーネスに入れるすべての知識に根拠の身分証を付ける

能力ハーネスの定義を改めて思い出してみましょう——「物事が正しい方法でのみ行われるようにする、包括的な知識と統制ポイントの最小完結単位」。本節はその前半、知識の話です。ハーネスに収められる知識の品質は結局「何に基づいているか」によって決まり、ポイエーシス（POIESIS）がこの点で提供する能力は一文に要約できます。エージェントが参照する世界の事実の一つひとつに、身分証が付いているのです。

設計者は作業中いつでも、ドメインの全容を複数の角度から確認できます。どのような業務対象が存在し、何をもって同一性を判別するのか、対象同士がどのような関係で絡み合っているのか、どのような事象がどのような状態変化を引き起こすのか。しかし、ポイエーシス（POIESIS）のドメイン知識は単なる閲覧資料の域を超え、版を重ねるごとに三つの方向へと深化してきました。

最初に深まった方向は、規制との連結です。業務規則と不変条件——常に守られるべき宣言的な規則群——には、その根拠となる規制条項が直接リンクされており、規程・条項・引用が構造化されたグラフとして探索できます。「この規則はなぜ存在するのか」という問いには、担当者の記憶ではなく条項リンクが答えます。

ここに権限との連結が加わります。誰がどの行為をどの範囲で実行できるか、決裁チェーンは何か——委任の規則、金額の上限、有効期間まで——がマトリックスとして宣言されています。ハーネスが許容する行動の境界は、慣行ではなく仕様なのです。

そして最後の方向が、出典との連結です。各データ値がどこから来たのかという出典の帰属、その値がどれほど確実かという不確実性プロファイル、複数の出典が衝突した際の調整規則までが、値単位で記録されます。

この三つの層が合わさって生み出す状態を、管理者の言葉に置き換えるとこうなります。監査人のどのような質問にも、一つの画面で答えられるハーネス。「その数字はどこから出たのか」「その規則の法的根拠は何か」「その行為をそのエージェントが行う権限はあるのか」——規制産業でエージェントを運用しようとする組織が必ず通過しなければならない三つの問いへの答えが、設計の時点からハーネスの中に蓄積されます。

3.6 第四の能力：能力から活動まで、働く主体を組織のように設計する

ハーネスの三段階が実際の設計物として現れる場所が、まさにこの能力です。エージェントを作るということは、結局のところ新しい働き手を組織に迎え入れることであり、ポイエーシス（POIESIS）は人の組織を設計する際に使う語彙を、そのままこの世界に適用します。

最も下に能力のアーキテクチャがあります。複合的な能力が原子的なスキルへと分解され、末端の原子スキルが実際のツールと結合する階層構造——能力ハーネス群の系譜です。各スキルには、それを支えるドメイン知識、遂行の技法、判断の骨格となる推論テンプレートが連結されます。前節で見た身分証付きの知識がスキル単位でまとめられ、次節で見る統制ポイントがここに結合すると、人の働き手の手に握られる拡張の単位——能力ハーネス——が完成します。

その上に役割とタスクのアーキテクチャがあります。どのような役割が存在し、役割間の階層とエスカレーション経路——問題が大きくなると誰に上がるのか——はどうなっているか、各役割はどのタスクを担うか。そして、各タスクがどのスキルをどの習熟度で要求し、自動化が可能な段階はどこかを明らかにする業務-スキル対応表が、二つの層をつなぎます。この対応表こそが、能力ハーネスをタスクハーネスへと昇格させられるかどうかの判定表です——タスクが要求するスキルがすべて検証済みのハーネスとして存在するか?

最も上に活動のアーキテクチャがあります。タスクがプロセスとしてつながり、関門が流れを統制し、決定的に人の介入ポイント（HITL（Human-in-the-Loop）チェックポイント）が第一級の設計要素として宣言されます。活動ハーネスの自律性とは、人が消えた状態ではなく、人の居場所が正確に設計された状態です。エージェントがどこまで進み、どこで人に引き渡すかは設計の成果物であって、運用中の即興ではありません。

興味深い原則が一つ、この視点の深さを物語っています。エージェントのあらゆるLLMベースの作業さえも、登録された「認知能力」という形式を通じて宣言されなければなりません。このシステムでは、AIの知能さえも登録された能力であり、登録されていない能力はハーネスの中に存在しません。

3.7 第五の能力：統制ポイントを数学で鍛え上げる

能力ハーネス定義の後半——統制ポイント——の話です。ハーネスの統制ポイントの中で最も精巧に鍛え上げられているのが判断の統制であり、ポイエーシス（POIESIS）の最新版が集中的に強化したのがまさにここです。

3.7.1 意思決定テーブルの静かな落とし穴

出発点は、おなじみの意思決定テーブルです。「条件がこうであれば、決定はこれ」という行のリストです。住宅ローン審査ドメインには、審査の関門ごとにこうしたテーブルが連結されています。

ところが、古典的な運用方式——上から読んで最初に該当する行を採用する方式——には、静かな落とし穴が二つあります。複数の行が同時に該当する場合、どれが正しいかを吟味せずに上の行を選ぶこと、そして、どの行にも該当しない場合を音もなく見逃すことです。どちらもシステムがエラーを出さないため、誤った判断が正常処理の顔をして流れていきます。

3.7.2 落とし穴の大きさをまず測定する

ポイエーシス（POIESIS）は、この落とし穴の大きさをまず測定しました。このドメインで可能な入力の組み合わせ1,410通りをすべて展開してみたところ、97通りは複数の規則が同時に該当する真の多値(多値)事例であり、897通りはどの規則にも該当せず、旧方式が静かに取りこぼしていた事例でした。千件近いずれが、もっともらしい外見の下に隠れていたのです。

3.7.3 三つの処方：台帳、順序、禁止

そして、学界の多値意思決定理論を取り入れ、三つの方法で応えました。

まず、隠れていた多値事例と非カバー事例をすべて台帳に載せました。存在を認めることが管理の始まりだからです。

次に、複数の決定が競合する場合に「最も保守的な決定から」という深刻度順で同点を解消する判断ツリーを導入し、深さ優先型と簡潔型の代替案を並べて提示することで、ドメイン専門家がトレードオフを見て選択できるようにしました。どの規則にも該当しない事例は、テーブルごとに作成されたデフォルト決定が受け止め、判断のカバレッジは1,410分の1,410——抜け漏れなし——になりました。

そして、白眉は最後にあります。禁止規則——「この条件ではこの決定は絶対に出てはならない」という『してはならない』の文法——が194個導出され、各規則は既存の規程文言から根拠を引き継ぎ、深刻な規則は標準検証規格へとコンパイルされて、設計検証時点と運用時点の両方で機械的に強制されます。この強制は関門ごとに勧告と強制を選択でき、現在は六つの関門すべてが強制モードです。導入方式さえも慎重でした。関門一つずつ、シャドー検証期間を経る段階的な展開であり、各段階の判断根拠が報告書として残されています。こうした多次元的な統制ポイントを通じて、これまで見えていなかったリスクを排除できるようになりました。

3.7.4 願望から証明可能な性質へ

「物事が正しい方法でのみ行われるようにする」という能力ハーネスの使命は、ここでは願望ではなく、数学的に証明可能な性質となります。すべての入力に判断が存在すること(カバレッジ)、競合時に保守的な方向へ傾くこと(深刻度順)、禁止線を機械が守ること(禁止規則の強制)。

エージェントに「何をせよ」だけを教える組織と、「何を絶対にするな」までを強制する組織との間には、リスク等級の差があります。ポイエーシス（POIESIS）は、その差を配備後の事故対応の場面ではなく、作る段階で作り出します。

3.8 第六の能力：活動ハーネスの基調を計器盤で調整する

前の能力が個別判断の統制ポイントを鍛え上げるものだとすれば、今回の能力は活動レベル・ハーネスだけが持ちうる統制——流れ全体の基調——を扱います。核心概念はスロットル（throttle）です。自動車のアクセルペダルのように、自律運用される活動全体の保守性と積極性を調整するつまみです。

作動原理は一つの回路です。市場指標、延滞動向、運用データといった外部・内部のシグナルが、それぞれの重みとともに登録されており、これらのシグナルが合算されて現在のスロットルスコアになります。そのスコアは、活動を構成する各審査関門のパラメータ——承認閾値、判断の保守性バイアス——へと変換され、一斉に反映されます。そして、そのように調整された判断の結果が、関門別の成果推移や不良債権指標との相関として測定され、再びシグナルとなって戻ってきます。シグナル → 基調 → 判断 → 成果 → シグナルという閉じた輪です。

この回路が活動ハーネスの自律性にとってどのような意味を持つか、確認する価値があります。自律運用の本当のリスクは、個別判断の誤りよりも、世の中が変化したのにシステムの姿勢がそのままである状態です。スロットルはそのリスクへの答えです。市場が悪化する際、数百個の個別規則を一つひとつ改修する代わりに、流れ全体の姿勢を一つの政策レバーで調整できます。

そして、管理者にとってこれは実はなじみのない概念ではありません。与信政策委員会が会議と公文書で行ってきた、まさにその業務の計器盤版です。変わったのは透明性です。今四半期の基調調整がどのシグナルによって、どの関門に、どれだけ作用したか、その結果として不良率がどう動いたかが、すべて記録として残ります。基調調整が「勘」の領域から計器盤の領域へと移ってくるのです。

3.9 第七の能力：配備する前に飛行してみる

組み立てられたハーネスが実世界へ出て行く前に、ポイエーシス（POIESIS）は三重の試験を要求します。構成が規格に適合しているかを見る形式検証、内容が業務規則に適合しているかを見る意味検証、そして実際の実行を模してみるシミュレーション実行。文章が文法に合っているか、意味が合っているか、動かしてみると意図どおりに動くか——三つの問いが順に投げかけられます。

試験のツールも豊富です。関門とカテゴリの格子を埋め、どこが空いているかを明らかにするカバレッジ分析があり、システムが自らの知識基盤を批評し、自律エージェントに不足している情報が何かを特定してくれる「批評と補完」機能があります。

検証器の最終出力が、この文化の性格をよく表しています。現在のドメインの検証結果はエラー0件、警告18件ですが、その警告さえも「強制はされているが、規制条項へのリンクがまだ付いていない禁止規則」といった——つまり、次にやるべきことのリストです。検証は合格・不合格の判を押すものではなく、バックログ生成器として機能します。

シミュレーション実行は本格的な試験飛行場であり、ハーネスの大きさによって試験の性格も変わります。スキルとタスクのレベルでは個別判断の正確性が関心事であり、活動レベルではエージェント同士の協働——段階ごとに何が起きたかの逐次トレースと、複数のエージェントが互いに何をやり取りしたかの相互作用関係図——が関心事になります。あらかじめ用意されたシナリオ集から事例を選ぶか、直接作成して実行し、数十から数百のシナリオを一斉に回すバッチ実行が統計的な確信を加え、集計された成果ダッシュボードが結果を集約します。

システムの随所にある一つの表示が、この文化を要約しています。シミュレーション実行を経ていない分析画面には「静的モード」というバッジが付きます。実行して確かめていない主張には、タグが付けられるのです。

管理者にとって、この能力が持つ意味は承認会議の風景の変化です。配備承認の議案に上がるのは、担当者の意見ではなく飛行記録——どのシナリオを何件回したか、トレースで何が見えたか、カバレッジの空欄は何か——になります。

3.10 第八の能力：履歴と関門でハーネスの出荷を統制する

試験に合格したハーネスには、二つの最後の規律が待っています。履歴と関門です。

履歴の規律は、ソフトウェア開発の実証された慣行をそのまま取り入れています。すべてのハーネスは枝分かれ(ブランチ)と確定記録(コミット)で管理され、二つの版の間の差分を比較でき、過去の版へ戻すこともできます。版ごとにパイプラインの状態がバッジとして付いているため、「今実際に運用に出ている版はどれか」という問いにも、一度の照会で答えられます。テオリアのカプセル・ワークベンチで見た原則が、ここでも繰り返されます。ハーネスのどの版がいつどの状態にあったかは、記憶ではなく記録の問題でなければならないという原則です。

関門の規律は、配備を一つの儀式にします。配備前のチェックリストがあり、承認手続きがあり、通過したハーネスだけが運用の舞台——治める翼プラクシス（PRAXIS）——へと引き渡されます。そして、切り戻し(ロールバック)が常に用意されています。出て行く門が狭く、戻ってくる門が開いている構造——配備統制の定石です。

ここで、プラクシス（PRAXIS）との関係を一つだけ確認しておきます。ポイエーシス（POIESIS）とプラクシス（PRAXIS）は、同じサーバーと同じデータベースを共有する二つの顔です。能力、スキル、技法、推論、エージェント名簿、監督体系——両翼が参照するこれらの中核業務オントロジーは、文字どおり同じ本の同じページです。作る側が引き渡したハーネスと治める側が受け取ったハーネスの間には、翻訳も、複製も、食い違う余地もありません。第1章で「飛行には両翼がともに動くことが必要である」と述べた文の工学的な実現が、まさにこの共有構造であり、その舞台の上で起きること——配備されたハーネスの中でエージェントが実際に働き、監督される物語——は第4章の役目です。

付け加えると、静かながらも印象的な規律が一つ、履歴の世界を完成させます。ドメインデータを直接修正する編集機能さえも、手綱がかけられているという点です。修正が許される項目はあらかじめ宣言されたリストに限定され、保存は変更部分のみが単一の経路で送信され、元に戻す機能が用意されており、変更は監査の対象として残ります。データを直す手にも手袋がはめられているということ——ハーネスを作る工場自身が、ハーネスを装着して働いているというわけです。

3.11 一式のハーネスが生まれるまで

八つの能力を一つの物語につなぎ合わせると、ポイエーシス（POIESIS）で一式のハーネスが生まれる過程は、おおよそ次のように流れていきます。

発端は、テオリアから引き渡された実装対象です。住宅ローン審査活動の下に、審査担当者による担保評価というタスクが受付済み状態で到着しています。根拠となるドメインデータが接続されていることをシステムが確認して初めて、作業が開かれます。業務設計者は、このタスクが行うことを自然言語のシナリオとして記述し、達成すべき目標を併せて書き込みます。AIがその物語を構造化された設計草案へと発展させますが、その作文は自由作文ではなく、ハーネスの規格の中でのみ生まれる作文です。状態は作成中に変わります。

設計が厚みを増していく間に、収められる知識の一つひとつに身分証が付けられます。担保評価に適用される業務規則には、根拠となる規制条項がリンクで連結され、このタスクで許容される行為の範囲と決裁チェーンが権限マトリックスとして宣言され、参照するデータ値には出典と不確実性プロファイルが記録されます。タスクが要求する能力群——担保価値の算定、所得書類の検証、規程の照会——は、それぞれのドメイン知識と推論テンプレートを備えた能力ハーネスとしてまとめられ、判断の関門には意思決定テーブルが連結されます。ドメイン専門家は、規則が競合する際の保守性の順序を確定し、どの規則にも該当しない事例を受け止めるデフォルト決定を書き込み、「この条件ではこの決定は絶対に出てはならない」という禁止規則が規程文言から根拠を引き継いで強制モードで設定されます。

いよいよ試験飛行です。形式検証が規格との一致を、意味検証が業務規則との一致を確認し、カバレッジ分析が空欄を明らかにし、シミュレーション実行が用意されたシナリオ集とバッチ実行によって統計的な確信を積み上げます。検証器が残した警告18件は、不合格判定ではなく次にやるべきことのリストとしてバックログに登録されます。状態は検証済みとなり、配備承認の議案には担当者の意見ではなく飛行記録——どのシナリオを何件回し、トレースで何が見えたか——が添付されます。承認関門を通過したハーネスは、コミットとブランチの履歴を携えたまま、配備済み状態でプラクシス（PRAXIS）の舞台に上がります。

この旅路で注目すべきは、どの段階においても、治めることが作ることの後回しにされていないという点です。規格は設計の始まりから存在し、根拠は知識が収められる瞬間に付けられ、禁止線は配備の前にすでに機械に刻まれていました。作る翼が速い理由は、治めることを省略しているからではなく、治めることを工程そのものにしたからです。

3.12 むすびに：作る翼の管理者へ

ポイエーシス（POIESIS）が組織に付与する能力を一つの段落にまとめると、次のようになります。活動・タスク・能力という三つの大きさのハーネスを、パイプライン上で進捗を一目に把握しながら築く。現場のシナリオから規格のある設計を得て、ハーネスに収めるすべての知識に規制・権限・出典の身分証を付け、能力から活動まで働く主体を組織のように設計し、統制ポイントを数学で鍛え上げ、自律運用の基調を計器盤で調整し、配備前には必ず飛行してみて、履歴と関門で出荷を統制する。八つの能力に共通する文法は一つです。作る速度のために治めることを後回しにせず、治めることをハーネスそのものとして作り出すこと。

この翼を任される管理者に残したい助言も、物語の流れそのものです。新しい自動化課題が持ち込まれたら、「エージェントを作ろうか」ではなく、「これは能力拡張なのか、役割のタスクなのか、活動の自律運用なのか」という大きさの問いから投げかけてください。能力ハーネスで十分な場所に活動ハーネスを築いたり、活動が必要な場所に能力だけを与えたりする大きさの誤判断が、この領域で最も高くつく失敗であり、能力ハーネスで積み立てられた信頼のみがタスクと活動の自律性を正当化するという導入のはしごの原則が、その問いの羅針盤になります。進捗を語るときは、パイプラインの五つの状態——受付済み、作成中、検証済み、配備済み、差し戻し——を会議の言葉としてください。進捗報告はこの五語で十分であり、この五語でこそ正確です。

判断の統制に関する事柄は、技術部門ではなくドメイン専門家の机の上に置かれるべきです。規則が競合する際にどちらがより保守的な決定か、どの規則にも該当しない事例をどう受け止めるかはリスク政策の問題であり、システムはその政策を書き込む欄を用意しているにすぎません。保守性の原則とデフォルト決定の作成を専門家の正式な業務として付与し、検証が残した警告の大半を占める禁止規則の規制根拠の補強を、次四半期の課題として挙げておいてください。警告リストがすなわち業務リストです。

配備の関門では、断固たる姿勢が美徳です。シナリオを何件回したか、バッチを何回実行したか、トレースで何が見えたか——この三行がない承認要請は差し戻すことが、このツールの文化に合っています。シミュレーション実行のない配備承認を慣行から消してください。そして、活動ハーネスの自律性が大きくなるほど重くなるレバー、スロットル回路の持ち主を決めておいてください。シグナルの重みと関門との連結は、一度決めて忘れる値ではなく、成果のフィードバックを見ながら定期的に手を入れる政策レバーです。

ワシの左翼は、こうして働きます。物語が入ってきて三つの大きさのハーネスとなって出て行き、その間のあらゆる手入れに規格と根拠と記録が付き従う場所。次章では右翼プラクシス（PRAXIS）へと渡り、配備されたハーネスの中でエージェントたちが実際に働き、治められる舞台とともに、今回取っておいた二つの名——ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）——の物語を余すところなく展開します。

第3章の要点：ポイエーシス（POIESIS）はエージェントではなくエージェント・ハーネスを組み立てる場所であり、ハーネスには能力(拡張)・タスク(代行)・活動(自律運用)の三つの大きさがある。八つの能力——パイプラインの可視性、シナリオベースの設計、根拠の身分証、組織型設計、数学で鍛え上げた統制ポイント、スロットルによる基調調整、配備前のシミュレーション飛行、履歴と関門による出荷統制——に共通する文法は、治めることをハーネスそのものとして作り出すことである。

第4章 プラクシス（PRAXIS）：統治し、調整する翼

本章で扱う内容：これまで温存してきた二つの名前の正体――ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）――、そして展開されたハーネスが実際に稼働し、統治される運用の舞台。事例ドメインには融資デューデリジェンス（due diligence）業務を用います。

4.1 はじめに：ワシの最後の一片

本書もいよいよ第4章に至りました。第1章ではワシの解剖構造を見て、第2章では判断する頭部テオリア（THEORIA）を、第3章では作る左翼ポイエーシス（POIESIS）を掛けてきました。第3章は一つの約束で締めくくられました。ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）の物語を、展開されたエージェントが実際に働く舞台とともに余すところなく展開するという約束です。

本章はその約束を果たす場です。AOEDE-プラクシス（PRAXIS）は右翼、統治する翼です。ポイエーシスが三つの大きさのハーネス――能力、タスク、活動――を組み立てて関門を通過させると、そのハーネスはプラクシスの舞台に上がります。ここでエージェントたちは実際の文書を受け取り実際の判断を下し、人はその実行をリアルタイムで見守り、習熟度が測定され、認証が更新され、変更が管理され、異常が知らされます。第1章の一文を借りれば――「統制なしに作るだけの組織はリスクを大量生産し、作らずに統制するだけの組織は何も生産できない」――プラクシスは、その一文の後半が空言に終わらないようにする場所です。

プラクシスの最初の画面が、本書全体の世界観を一枚の図として要約しているという点も言及に値します。スタート画面にはAOEDE――エージェンティック・オントロジーの構想および展開環境――の全体地図が広がり、テオリア（THEORIA）・ポイエーシス（POIESIS）・プラクシス（PRAXIS）という三つのワークプレイスと、その中央のNEXUS、そしてエージェントを構成する能力の車輪――認知、知識、メモリー、推論、インタラクション、学習、ペルソナ、プレゼンテーション――が描かれています。これまで三章にわたって語ってきたことが、運用者の最初の画面にすでに一枚の図として掛けられているわけです。

本章も先行する各章と同じ方式に従います。画面案内ではなく、能力の物語です。ただし順序には理由があります。まず先送りにしていた二つの名前――ネクサスとミメーシス――を明らかにし、その上でプラクシスが組織に与える統治の能力群をたどっていきます。事例ドメインは、ポイエーシスで組み立てられたそのハーネスが実際に稼働する融資デューデリジェンス（due diligence）業務です。

4.2 ネクサス（NEXUS）：ハーネスの規格であり、一つの原本から花開く七つの視点

まず一つ目の名前です。第1章ではネクサス・ハーネスを「行動、統制、ガバナンスから成る黄金のベルト」と呼び、第3章ではその組み立てを扱いながらも名前の正体は伏せておきました。今こそ語ることができます。ネクサスとは、ハーネスが記述される規格であり、作る翼と統治する翼がやり取りする契約文書の形式です。

4.2.1 九十七種の語彙で書かれた契約書

具体的に、ネクサスはCC-DSL（Cognition Control-Domain Specific Language）という専用言語（ドメイン特化言語）で記述された一つのパッケージです。その中には、これまで三章にわたって語ってきたすべて――ビジネス領域、作業（ジョブ）と段階、役割、機能、スキル、技法、知識ベース、推論テンプレート、そして監督規則――が一そろいの定義として収められます。

驚くべきはその規模です。この規格は九十七種の定義要素と二十八種の連結関係から成り立っており、エージェント組織一つを記述するのに必要な語彙がほぼ余すところなく備わっています。人間組織にたとえるなら、組織図、職務記述書、業務マニュアル、権限規定、監査基準が一つの一貫した言語で書かれているようなものです。ここで使用するCC-DSLはネクサスのための専用言語であり、AOEDEハーネスを標準化するために開発されました。

4.2.2 二つの扉、そして自動整列

プラクシスにおいて、ネクサスは二つの扉から入ってきます。一つはシナリオ設定ウィザードです。DSLファイル群をアップロードすると、システムが定義が参照より先に来るように――メイン、知識、技法、推論、スキル、ハンドラーの順に――依存関係に基づいて自動整列し一つに統合したうえで、検証を経て検知された構成要素の一覧――ビジネス領域いくつ、役割いくつ、スキルいくつ、監督規則いくつ――を表示してからネクサスを生成します。もう一つは、ネクサスページでの直接アップロードと展開です。どちらの扉から入っても、展開されたネクサスには「展開済み」の表示が付き、運用のリポジトリに登録されます。

4.2.3 七つの視点：食い違うことのできない文書群

しかし、ネクサスページの真の価値は登録ではなく翻訳にあります。一つのネクサスを選択すると、システムは同じ原本を七つの視点に解きほぐして示します。経営陣の言葉で書かれたビジネス要件、原文そのままのDSLソース、役割別の流れを描いたワークフロー・スイムレーンとBPMN、アクションの入力と出力がどうかみ合うかを示すデータ依存関係図、定義要素の関係全体を見渡すオントロジーマップ、どの監督規則がどこに適用されているかのガバナンス・トレース、そして定義の隙間を指し示すギャップ分析です。

管理者にとって、この七つの視点が意味するところは明白です。これまで組織において、要件文書、プロセス図、データフロー図、統制マトリクスは、それぞれ異なる人が異なるツールで描くために互いに食い違うのが常だった四枚の紙でした。ネクサスでは、これらが一つの原本から機械的に派生する視点であるため、原理上互いに食い違うことがあり得ません。「文書と実態が異なる」という古い病が、文書がすなわち実態である構造によって癒やされるのです。

4.3 ミメーシス・エンジン（MIMESIS ENGINE）：「作業」という名の忠実な実演

二つ目の名前です。第1章はミメーシスをこう紹介しました――「エンジンは結果を作り上げたりしない。オントロジーが定義した内容を、ハーネスが許容する範囲内でそのまま実行するだけである。エンジンが強力である理由は、指示されたとおりにしか動かないからだ。」プラクシスにおいて、その一文は作業（Job）という形で実体を得ます。

4.3.1 作業の誕生：明示されたトレードオフ

作業の誕生から見ていきましょう。運用者は新しい作業を作成する際、展開済みのネクサス（DSLテンプレート）を選択し、処理対象となる実際の文書――契約書、財務諸表、鑑定評価書――を添付し、優先順位と実行条件を定めます。

興味深いのは処理戦略の選択肢です。システムが自動的に決める自動、一度に一、二ページずつ精読する品質優先、中間サイズのバランス、大量を高速に処理するスループット、そして自ら指定するカスタム。大量文書を扱ってきた管理者ならば、このダイヤルの意味をすぐに理解するでしょう。精度と速度のトレードオフが、担当者の勘ではなく明示的な設定として表に出ているのです。

4.3.2 実演の舞台：三層構造と生きた可視化

作業が開始されると、ミメーシスの実演が繰り広げられます。実行の単位はネクサスが定義したとおり――トランザクションがステージを従え、ステージがアクションを従える三層構造です。画面上部の二重進捗バーはトランザクションレベルとアクションレベルの進捗を同時に示し、反復処理中であれば何回目かまで表示します。

ワークフロー・タブでは実行フローが有向グラフ（DAG）として動き、エージェント・タブでは複数のエージェントが時間軸上で仕事をやり取りするスイムレーンと相互作用の関係が描かれ、イベント・タブには何がいつ起きたかという流れが秒単位で積み重なります。

4.3.3 系譜がダウンロードボタンとして存在する状態

そして実演の終わりに、ミメーシスの性格が最も鮮明に現れます。成果物タブには最終的な結果物だけがあるのではありません。すべてのアクション一つひとつの入力と出力がペアで保存され、それぞれ個別にダウンロードできます。融資デューデリジェンス作業であれば最終的にマークダウン報告書とHTMLダッシュボードが作成されますが、その報告書のどの数字であっても、「どのアクションが、どんな入力を受け取り、どんな出力を出したか」という連鎖にさかのぼることができます。

結果を作り上げないエンジンとは、まさにこういうことです。すべての結論に系譜があり、その系譜がダウンロードボタンとして存在する状態。

管理者の言葉でこの節を締めくくります。従来の自動化において、「その結果はどうやって出てきたのですか」は開発チームに問い合わせる質問でした。ミメーシスの舞台では、それはタブを一つ開くだけのことです。

4.4 約束によって結ばれた実行：要請され、約束され、陳述され、受諾される

ミメーシスが実行するトランザクションには、注目に値する構造がもう一つあります。各トランザクションは要請済み → 約束済み → 陳述済み → 受諾済みという四つの局面を経ます。言語行為理論（speech act theory）に根ざしたこの構造は、仕事とは作業の羅列ではなく行為者間の約束の環であるという観点を含んでいます。発信者が仕事を要請し、実行者がやると約束し、やったと陳述し、発信者が結果を受諾することで環が閉じます。

そのため、プラクシスの実行台帳には事実と並んで約束が第一級の項目として存在し、約束にはステータスがあります――アクティブ、履行済み、違反、キャンセル。トランザクション画面では、各トランザクションの発信者と実行者、トリガー、そして段階別のアクションがフロー図とツリーで展開されます。

これが管理の観点からなぜ重要なのでしょうか。エージェントシステムにおける責任の所在は、しばしば霧の中にあります。複数のエージェントが絡み合って仕事をする中で何かが誤れば、どこから食い違ったのかを突き止めるのは困難です。約束の環はその霧を晴らします。すべての仕事には要請した者と約束した者がおり、違反した約束は「違反」というステータスで実行台帳に残ります。責任の追跡が事後調査ではなく、データ構造そのものなのです。

4.5 生きている名簿：エージェント、役割、そして八つに分かれた能力

舞台上の役者たちを見る番です。

4.5.1 エージェント名簿：人とAIが同じ文法で

エージェント画面は、登録されたエージェントたちの生きている名簿です。各エージェントには種別――LLMベース、ルールベース、ハイブリッド、そして人間――があり、ステータスと最終ハートビート（生存信号）があり、どんな役割を担い、どんな機能・スキル・技法を保有しているかがツリーで展開されます。

目を引くのは、「人間」がエージェント種別の一つであるという点です。この名簿において、人とAIは同じ文法で登録される仲間です。これは修辞ではなく実用です。人とAIが混在して働くワークフローを一つの実行台帳で管理するには、両者を同じ語彙で記述できなければならないからです。

この選択が含意するところは、もう一歩先に進みます。人とAIが同じ文法で登録されるということは、業務を設計する際に「このタスクは人のもの、あのタスクはAIのもの」という二分法の代わりに、「この役割を今誰が担うのが最善か」という配置の問いを立てられるということです。今日人が担っていた役割を明日検証済みのエージェントが引き継いでも、あるいはその逆でも、フローの設計そのものは変わりません。ハーネスが役割に紐づいており、個人に紐づいていないからです。人間組織において引き継ぎがこれほど脆弱である理由が、業務が人に付随しているためであることを思い起こせば、この文法の実用的な価値が明らかになります。

4.5.2 役割登録簿：委員会議決までも語彙の中へ

役割画面は、その役者たちが担う配役の登録簿です。役割には種別――外部、人間、AI、人間グループ――があり、グループ役割には定足数と投票規則（過半数、全会一致、重み付け）まで定義されます。委員会の議決構造がハーネスの語彙の中に組み込まれているのです。各役割が遂行できる許可された作業の一覧と委任可能な対象が明示され、今この役割を実際に遂行中のエージェントたちが並んで照会できます。

4.5.3 エージェントロジー（Agentology）：役者の内面を解剖する

そしてエージェントロジー画面が役者の内面を解剖します。エージェントの能力は八つに分類されます。中核となるAI処理を担う認知、情報アクセスと検索の知識、文脈と状態管理のメモリー、論理と意思決定の推論、人・エージェントとのコミュニケーションであるインタラクション、適応と改善の学習、アイデンティティと行動様式のペルソナ、出力形式のプレゼンテーション。これに、入力と出力の両方にかかる七重の安全フィルターが加わります。第3章で「AIの知能さえも登録された能力である」と述べた原則が、運用の側ではこの八分類体系として生きているのです。

一つの概念上の区別が画面に明示されているため、記しておきます。能力（capability）はビジネス層――システムが行うことであり、コンピテンシー（competency）はエージェントロジー層――AIエージェントの認知能力です。「我々のシステムは担保評価を行う」（能力）と「このエージェントは文書からエンティティを抽出できる」（コンピテンシー）を区別する語彙が、組織の中に生まれるのです。

4.6 共有台帳の向こう側：同じ能力を運用の目で読む

第3章で、二つの翼は同じサーバー、同じデータベースを共有する二つの顔であると述べました。プラクシスでその共有台帳の向こう側――能力、スキル、技法、推論、ドメイン知識――を開いてみると、作る側で組み立てられた能力ハーネスが運用の目でどう読まれるかが分かります。

スキル画面では、各スキルが自身の実装する機能、使用する技法、参照するドメイン知識とともに成熟度を示します。技法画面は、各技法の入力、段階別タイムライン、出力要件――必須フィールドと任意フィールド――、そして抽出プロンプトまでを示します。

推論画面が特に印象的です。各推論テンプレートには思考連鎖の目標と要点、few-shot例が整理されており、何よりもLLM制約条件とドリフト防止規則――モデルが時間の経過とともに本来の意図から逸脱するのを防ぐ仕組み――が仕様として付随しています。推論タイプの語彙も豊富です。連鎖思考（Chain of Thought）、思考の木（Tree of Thought）、ReAct、リフレクション（Reflexion）からエンティティ関係推論、因果推論、比較分析まで、十三種類のタイプが標準分類として存在します。

この台帳のすべての項目には、二つのバッジが付いて回ります。一つはステータス――ドラフト、アクティブ、展開済み、廃止予定、アーカイブ済み――であり、もう一つは変更管理レベルです。後者は次節の主役なので、ここでは一文だけ残しておきます。能力ハーネスの定義――「包括的な知識と統制ポイントの最小完結単位」――は、展開された瞬間に消え去る設計意図ではなく、運用者が毎日開いて見る台帳の実物なのです。

4.7 統治の三つの道具：変更管理、シグナル、監督規則

統治する翼の核心的な任務は、結局のところ統制です。プラクシスは三つの道具でこれを遂行します。

一つ目の道具は変更管理です。台帳の各項目には変更管理レベルが宣言されています――自由変更、要レビュー、そしてMRM必要。MRM、すなわちモデルリスク管理（Model Risk Management）は、金融業界の管理者にとってなじみ深い重みを持つ言葉でしょう。規制が求めるモデル検証手続きが必要な項目はそのように表示され、変更管理ダッシュボードにはレビュー待ちの項目が集まって承認または却下を待ち、処理の履歴が残ります。ポイエーシスでハーネスを作る際に刻まれた統治が、運用中の変更にまで及んでいるのです。一度検証されたハーネスであっても、その部品を修正するには再び関門を通らなければなりません。

二つ目の道具はシグナルとモニタリングです。リアルタイムのメトリクスとシグナル活動が流れ、アラートは情報・警告・緊急の深刻度に分類され、ダッシュボード最上部――全作業、アクティブなエージェント、トランザクションと並んで――にアクティブなアラート数として集計されます。第3章のスロットル回路が信号を消費して基調を調整したのだとすれば、プラクシスはその信号が生まれ、監視される現場です。

そして三つ目の道具が監督規則です。ネクサスに盛り込まれ展開された監督オントロジー――ガバナンスと監督の規則群――が運用側で照会でき、先に見たネクサスのガバナンス・トレースの視点が、どの規則がどの実行ポイントに適用されているかを示します。実行記録の詳細さすらも統制の対象です。監査レベルは、なしから基本、詳細、完全まで段階的に宣言されます。

三つの道具を管理者の視点でまとめるとこうなります。何が変わるのか（変更管理）、何が起きているのか（シグナル）、何が守られているのか（監督規則）――統治の三つの問いにそれぞれ専任の道具があり、三つの道具は同じ台帳の上で機能します。

4.8 信頼の通帳：認証と習熟度

第3章は「自律性は宣言するものではなく、小さなハーネスから積み立てるものである」と述べました。プラクシスには、その積立が記録される通帳があります。認証と習熟度です。

エージェントのスキル習熟度は四段階で測定されます――未訓練、初級、熟練、エキスパート。そして熟練の主張は試験によって証明されます。認証画面で運用者はエージェントを選び、テストスイート――テストケース群と合格基準から成る試験――を受験させ、結果はスコアとともに認証記録として残ります。

認証には有効期限があります。一度取得した資格が永遠ではないということ――人間の専門資格が継続教育と更新を要求するように、エージェントの資格も更新を要求します。モデルが変わり、データが変わり、規制が変わる世界において、これは当然の要求です。

この仕組みがハーネスの三段階と交わる点こそが要点です。能力ハーネスからタスクハーネスへ、タスクから活動の自律運用へと上がる梯子の各段は、結局のところ「このエージェントをどれだけ信頼できるか」という問いですが、認証と習熟度はその問いにスコアと有効期間のある答えを提供します。自律性の拡大が、担当役員の確信ではなく認証記録の蓄積の上で決定される組織――それがこの通帳が可能にする状態です。

4.9 翼の彼方へ：フェデレーションとテナント

プラクシスの視野は、一つの組織の垣根の中では終わりません。

フェデレーション（Federation）画面は、A2A（エージェント対エージェント）プロトコルで接続された外部世界の名簿です。他組織のエージェントがエンドポイントとともに登録され、組織別に分類され、オンライン状態が追跡されます。そして運用者は特定の能力を指定して――対象エージェントを選ぶか、「利用可能な任意のエージェント」に対して――能力を呼び出すことができます。自分たちのハーネスが持たない能力を、フェデレーションの隣人から借りるのです。

内側にはテナント管理があります。一つのプラクシスの上で複数の事業部、複数の法人がそれぞれの垣根を持って運用され、ダッシュボードはテナント別に分けて見ることができます。

この二つの方向がともに指し示す絵があります。エージェント経済は、一社の一システムに閉じることはないでしょう。組織の内側には複数の主体が、組織の外側には複数のパートナーが、それぞれ自分のエージェントを持つようになり、その時必要になるのは身元と能力と呼び出しの標準的な文法です。プラクシスのフェデレーションとテナントは、その文法の早い実例です。

4.10 ある午後のデューデリジェンス作業：系譜をさかのぼる

プラクシスの一日を一場面に折りたたんでみましょう。午後、運用者が新しい作業を作成します。展開済みのネクサスの中から融資デューデリジェンステンプレートを選び、処理対象となる実際の文書――契約書、財務諸表、鑑定評価書――を添付し、今日は精度が優先されるので処理戦略ダイヤルを品質優先に合わせます。実行ボタンを押した瞬間から、ミメーシスの実行が始まります。

画面上部の二重進捗バーがトランザクションレベルとアクションレベルの進捗をともに満たしていき、ワークフロー・タブでは実行フローが有向グラフとして動きます。エージェント・タブを開くと、複数のエージェントが時間軸上で仕事をやり取りするスイムレーンが描かれ、イベント・タブには何がいつ起きたかが秒単位で積み重なります。その間、各トランザクションは要請され、約束され、陳述され、受諾される四つの局面を静かに通過します。ある一つの約束が違反状態のまま残るとすれば、それは霧ではなく台帳の一行になります。

作業が終わると、成果物タブにマークダウン報告書とダッシュボードが置かれます。運用者は報告書の中の担保評価額を一つ選び、系譜をさかのぼります。その数字を出したアクションが何だったのか、そのアクションが受け取った入力が何だったのか、その入力はどの前段階の出力だったのか――連鎖の節目ごとにダウンロードボタンが付いています。以前であれば開発チームに問い合わせチケットを開いて数日待たされたであろう質問が、数回タップするだけのことになったのです。この一場面に、統治する翼の存在理由が凝縮されています。実行は速く、しかしどの結論も自らの系譜を失わないということ。

4.11 むすびに：ワシが完成する

四つの章を貫いた旅程を一段落に折りたたみます。テオリアにおいてビジネスがオントロジーとして言語化され、二重のハーネスによって統治されました。ポイエーシスにおいてその言語が活動・タスク・能力という三つの大きさのハーネスに組み立てられ、判断の隙間と禁止線が数式によって鍛え上げられたのち、試験飛行と関門を経ました。そしてプラクシスにおいて、ハーネスはネクサスという契約の形式で展開され、ミメーシス・エンジンがそれを系譜が残る方式で実演し、約束の環と生きている名簿と三つの統制の道具と信頼の通帳がその実行を統治します。頭が見て、左翼が作り、右翼が統治し、エンジンが実演し、鉤爪が実際の業務を掴む。ワシが完成したのです。

統治する翼を任される管理者への申し送りも、この舞台の感覚そのものです。何よりも作業成果物の系譜を監査の標準に据えていただきたいと思います。すべてのアクションの入力と出力がダウンロードできるシステムにおいて、結果だけを見て済ませるレビューは道具を無駄にすることになるため、重要な作業についてはサンプルを抽出して系譜をさかのぼって確認する手続きを定例化してください。変更管理レベルの指定は、リスク部門とともに決めるべき事柄です。どのスキルと推論テンプレートがMRM対象であるかは技術的判断ではなく規制対応の判断であり、指定が終わった瞬間、変更管理ダッシュボードの保留項目がそのままリスク部門の業務リストになります。

運用のリズムの中で見落とされがちなこともあります。認証の期限切れを放置しないでください。期限切れの認証のまま働くエージェントは、更新教育を飛ばした従業員と同じですから、期限が迫った認証の点検は月例運用会議の固定議題であるべきです。そしてトランザクション台帳における「違反」状態の頻度とパターンを指標としてお読みください。約束違反は、どのハーネスのどの継ぎ目が弱いかを教えてくれる最も正直な信号です。最後に、垣根の外の問いを一つ、あらかじめ引き寄せておいてください。フェデレーションに提供する能力と借りる能力の方針――自分たちのエージェントのどの能力を外部に登録し、外部のどの能力をどのような条件で呼び出すのかは、技術が成熟してから決めたのでは遅い、今この時点でのガバナンスの問いです。

第1章はこう締めくくられていました――「見ることができる分だけオントロジーを定義せよ。行動できる分だけエージェントを作れ。すべての行動を統制とガバナンスに繋ぎとめよ。エンジンに忠実に実行させ、鉤爪に実際の仕事を掴ませ、ワシが実際に掴む術を学んだことに合わせてオントロジーを育てよ。」四つの章を経てきた今、その一文一文すべてに実物が備わりました。あとに残るのは、そのワシが実際のビジネスの地面に鉤爪を下ろす場面――第5章の物語です。

第4章の要点まとめ：ネクサスは九十七種の定義要素から成るハーネスの規格であり、二つの翼がやり取りする契約文書であって、一つの原本から七つの視点が機械的に派生するため、文書と実態が食い違うことはあり得ない。ミメーシス・エンジンはすべてのアクションの入出力をペアで保存し、すべての結論にダウンロード可能な系譜を残す。約束の環、生きている名簿、三つの統制の道具（変更・シグナル・監督規則）、そして認証・習熟度という信頼の通帳が運用を統治する。

第5章．CLAW：鉤爪が地面に触れる

本章で扱うこと：CLAWS（鉤爪群）の実装例の一つであるCLAW（企業融資拡張ワークプレイス）の全貌。企業融資業務の全生涯を収めた職場の地図、役割によって異なる三つのダッシュボード、傍らに座る同僚としてのエージェント、「分析一文」の威力、そして代替ではなく拡張を選んだ設計思想とその成果測定法。

5.1 はじめに：最初の文書の約束を果たす場

第1章はこう記しました。「ワシの構造は結局、鉤爪が何を掴むことができるかによって評価される。AOEDE CLAWSは、フレームワークが実際のビジネスと出会う接点である。左の鉤爪は専門金融サービスを担う。企業融資、貿易金融、資金管理のように複雑性が高く、根拠が契約文書にあり、統制されない意思決定のコストが資本規模で測定される領域である。」

第2章から第4章まで、私たちは頭（テオリア）と両翼（ポイエーシス、プラクシス）を順に歩んできました。オントロジーが定義され、ハーネスが組み立てられ、ミメーシスが系譜を残しながら実演するところまで見てきました。しかし、一つの問いが残っていました。では、現場の机の上では何が変わるのか？

本章ではその問いに答えます。主役は第1章で予告した、まさにあの左の鉤爪、企業融資を掴むCLAWSの実装例 — CLAW（Corporate Loan Augmenting Workplace、企業融資拡張ワークプレイス）です。

この名前はじっくり読んでみる価値があります。Corporate Loanはドメインであり、Workplaceは形態です。重心は真ん中の単語、Augmenting — 拡張にあります。第3章ではハーネスの三つのサイズについて語りながら、最も小さな能力ハーネスの目標を「自動化ではなく人間の働き手の能力拡張」だとし、「自律性とは宣言するものではなく、小さなハーネスから積み上げていくもの」だとして導入の梯子を描きました。CLAWはその梯子の最初の段が実物として建てられた姿です。ここでAIは審査役を代替しません。審査役の傍らに座ります。

あらかじめ一つ明らかにしておきます。このアプリケーションはCLAWSの実装例（リファレンス）です。データはデモ用であり、百数十の画面のうち代表的な画面は完全に実装されており、残りは登録された骨格として存在します。しかし実装例であるからこそ、かえってよく見えるものがあります。AOEDEが現場のシステムと出会うときに取る形、すなわち鉤爪のパターンです。本章ではそのパターンを読み解くことに集中します。

5.2 職場の地図：企業融資という業務の全生涯

CLAWを開くと最初に出会うのは、企業融資業務の全生涯を八つのモジュールに展開した地図です。その順序がそのまま与信の一生です。

物語は相談支援から始まります。目標顧客を検索し、企業の総合情報 — 企業概要、経営陣と主要株主、信用評価、営業現況、関係会社、企業動向 — を照会し、財務情報を財務状態表・損益計算書・キャッシュフロー計算書・財務比率など七つのタブで確認し、自行と他行の取引履歴を確認し、業種情報を比較します。そしてついに条件試算と申請 — 融資条件をシミュレーションし申請書を作成する画面 — に至ります。

続いて総合担保モジュールが担保の評価と登記と解除を担い、審査承認モジュールが与信承認の進行状況と基本登録、承認、実行、本部管理を担当します。

承認以降は管理の時間です。限度管理はPre-NPL管理、信用与信限度、総エクスポージャー（Total Exposure）、総合信用与信限度、大企業営業限度を扱います。与信資産健全性は資産健全性の登録と分類、引当金を管理します。事後管理は債権再調整と競売という与信の最も難しい局面を担い、与信審査モジュールは融資点検報告の検証を担当します。最後に総合経営情報が各種与信実績日報、日次延滞速報、月別延滞率現況、ヴィンテージ分析、金利プレミアムモニタリングといった報告の世界を締めくくります。相談から競売まで — 一枚の地図に与信の一生がすべて収められています。

この地図で管理者が注目すべきは、規模と登録の方式です。システムには183の画面が一つのレジストリに固有IDとともに登録されています。企業融資という業務の関節一つひとつが座標を持っているのです。そして画面群は十一の業務ドメイン — 企業顧客管理、相談支援、信用評価、財務分析、審査承認、総合担保、限度管理、早期警報、与信資産健全性、事後管理、与信審査 — にもまとめられており、利用者がどの画面に移動しても、システムが今どの業務領域にいるかを自動的に検知して文脈を合わせます。

この地図を歩いていると、一つの印象が残ります。八つのモジュールの順序が、そのままリスクの一生でもあるという点です。相談と試算の段階で下された判断が担保と審査の関門を通過し、承認以降は限度と健全性の監視のもとに置かれ、事がうまくいかなければ事後管理の難しい局面へ、うまく流れれば経営情報の報告書へと流れ込みます。拡張エージェントがこの地図の上のどこに座ろうとも、その場所の前後に何があるかをシステムが把握していること — それが文脈検知の実質的な意味です。

第2章の文章を覚えていらっしゃるでしょう。「オントロジーツリー（ジェネシス）はすべての作業の座標系である。」CLAWの画面レジストリとドメイン地図は、その座標系が現場の職場に降り立った姿です。鉤爪はどこにでも掴みかかるわけではありません。地形をすべて把握したうえで掴むのです。

5.3 三人の朝：役割が異なれば同じシステムも異なる顔

CLAWは三人の一日を想定して作られました。午前九時、同じ銀行の三人がそれぞれの席で同じシステムにログインします。支店の顧客担当はコーヒーを置く間もなく今日処理すべき案件を確認しなければならず、本部の審査役は夜間に積み上がった承認待ち行列の長さが気になり、リスク管理者は昨日の延滞指標が予警報線にどれほど近づいたかをまず見たいと思います。ログインした瞬間、同じシステムがこの三人にまったく異なる三つの顔で現れます。

顧客担当（RM）の朝は今日やるべきことの風景です。ダッシュボードの中心は作業キューです。K電子のB2B限度設定申請、M企業の信用評価進行案件、L流通の担保評価結果到着、N建設の現場実査準備が並んでいます。その隣には満期緊急度パネルが秒読みに入った案件を並べています。A電子の信用調査満期まで2日、B食品の融資満期まで3日、C貿易の買入外国為替満期まで5日。担当顧客の一覧、案件別の進行状況、銀行からのお知らせがこれを取り囲みます。RMの一日で最も高くつく失敗は「見落とし」です。このダッシュボードは見落としの候補を毎朝目の前に整列させます。

本部審査役の朝は関門の風景です。承認待ちの案件が優先順位と待機日数を伴って並んでおり — M企業の信用評価はすでに5日目の待機中です — 審査・信用評価・担保評価・限度管理へと続く本部業務のメニューが整列しています。審査役の一日で最も高くつく失敗は「ボトルネック」であり、この画面はボトルネックを数字で示します。

リスク管理者の朝は計器盤の風景です。ダッシュボードの一番目立つ位置にNPL（不良債権）率の推移が予警報線2.0%とともに描かれており、資産健全性分類の推移とヴィンテージ分析 — 融資実行時期別のまとまりの延滞率曲線 — が並んで配置されます。リアルタイム報告、ポートフォリオ現況、安定性、収益性の報告書群がその下を支えます。リスク管理者の一日で最も高くつく失敗は「発見の遅れ」であり、この画面は発見の時点を早めるために存在します。

三つのダッシュボードが共有する設計原則が一つあります。役割こそが視点であるということです。本シリーズを通して、役割はハーネスの第一級の要素でした。テオリアの役割補強、ポイエーシスの役割アーキテクチャ、プラクシスの役割登録簿がそれです。CLAWにおいて、その役割はついに朝の画面の姿となります。そして次節で見るように、役割を知っているのは画面だけではありません。

5.4 傍らに座る同僚：AOEDE-Claw エージェント

画面右側には折りたたんで開閉できるパネルが一つあります。AOEDE-Claw AIエージェント — このワークプレイスに常駐する同僚です。システムがエージェントに与えた自己紹介が設計思想を要約しています。「CLAWに内蔵された（embedded）知能型AI同僚（co-worker）。」ツールでもチャットボットでもなく「同僚」という言葉を選び、その言葉の価値を果たすために二つのことが設計されています。

何よりこのエージェントはユーザーが誰であるかを知っています。今ログインしている人の役割と作業キュー、今日の日付が常にエージェントの文脈に含まれています。そのためRMにかける最初の挨拶とリスク管理者にかける最初の挨拶は異なります。RMには「本日満期が迫った案件が3件あり、A電子の信用調査が最も急を要します（残り2日）。本日の業務計画を優先順位順に立てましょうか？」と話しかけます。リスク管理者には「今月の延滞率が前月比0.3ポイント上昇し、予警報の閾値を超えました。今すぐ月次リスク分析サマリーを作成しましょうか？」と話します。

そしてエージェントのパネルには二つのタブがあります。一つは協業対話 — 質問して答えるおなじみのチャットです。もう一つがこの設計の核心であり、まさにインテリジェンス・インサイトタブです。尋ねなくてもエージェントが自ら差し出す話がここに蓄積されます。RMには満期間近の警報と5日目に入った遅延中の評価案件、そして「今月のデータから見て、B食品の融資現況の月次報告書を作っておくとよい」という提案が置かれます。審査役には待機案件の優先順位付けとともに、「BB+以上の格付けの標準申請3件が検知されたため、一括審査で迅速に処理できる」という提案が上がってきます。リスク管理者には延滞率の閾値超過警報と、「2024年第3四半期実行分のバッチの延滞率が過去平均を上回っている — ヴィンテージ異常信号」という発見が届きます。

このリストを改めて読むと、共通点が見えてきます。すべて人がいずれにせよやらねばならなかったが、しばしば遅れたり見落としたりしていた種類の仕事 — ざっと目を通すこと、順番を整理すること、異変の兆しに気を配ること — です。そしてもう一つ重要な共通点があります。エージェントのすべての提案は確認要求で終わります。「作成を始めましょうか？」「一括処理を確定しましょうか？」「今すぐ分析しましょうか？」 — 実行の引き金は常に人間の指にあります。拡張ワークプレイスの統制ポイントとは大それたものではありません。まさにこれらの問いかけです。

5.5 一文の魔法：「分析　[企業名]」

CLAWの拡張が最も劇的に現れる瞬間があります。エージェントの対話ウィンドウにたった一文 — 「分析　A電子」 — を入力する瞬間です。

画面には四段階の進行が順に表示されます。企業基本情報を取得中、財務データを分析中、市場シグナルとSNS世論をスキャン中、総合評価報告書を生成中。そしてしばらくすると、企業総合分析報告書が画面に展開されます。

報告書の最初の行は六つの主要指標です。総合スコア、信用格付けと見通し、予想売上高と3年累積成長率、営業利益率と同業他社内での位置づけ、負債比率の適正性、そしてSNS好感度と同業他社平均との比較。その下にセクションが続きます。3か年の財務実績の推移チャート。経営陣評判分析 — CEO、CFO、CTOそれぞれの評判スコアと市場の評価要旨。市場動向とSNS世論分析 — 好意的・中立・否定的な世論の分布、話題語クラウド（デジタルトランスフォーメーション、ESG経営、原材料コスト、規制リスクなど）、直近の投稿のセンチメントと株価の推移。そして最後にこれらすべてを貫く総合分析意見が置かれます。

この一場面が、本シリーズの複数の文章を同時に実演していることを指摘しておきます。第3章は能力ハーネスを「包括的知識と統制ポイントの最小完結単位」と定義しました。「企業総合分析」はまさにそのような能力の一つです。信用・財務・評判・市場・世論という知識のまとまりが定められた手順に従って召集され、結果は人が検討する報告書の形で止まります。第4章はミメーシスを「すべての結論に系譜がある実演」だとしました。報告書の段階別収集過程が画面にそのまま露出しているのは、その系譜感覚がフロント画面へと翻訳された姿です。そして何より、この能力を呼び出す方法がメニューを七回クリックすることではなく自然言語の一文であるという事実 — 相談の電話を受けながら、稟議書を書きかけのまま、会議に入る直前にも呼べる同僚の形であるという事実が、「拡張」という言葉に実感を与えます。

RMの時間単位に置き換えるとこうなります。以前であれば六つ七つの画面を巡って半日かけて集めていた一企業の全貌が、顧客との通話が終わる前に机の上に置かれます。判断は依然としてRMの役目です。ただ、判断の材料が用意される速度が変わったのです。

5.6 拡張の文法：なぜ代替ではなく拡張なのか

ここで一歩下がって、CLAWが取った形そのものを読み解いてみます。このシステムには目立つ特徴が一つあります。既存のワークプレイスの文法をほぼそのまま尊重しているという点です。照会条件と結果テーブル、タブに分かれた詳細画面、入力フォームと試算機 — 銀行員であれば目を閉じても描けるような画面の文法が180ほどの画面に一貫して流れており、AIはその文法を覆す代わりに右側のパネル一つとして静かに入り込んで座りました。

これは技術の限界ではなく意図された設計であり、その理由は三つの層で解くことができます。

最も深い層に置かれているのは信頼の経済学です。第3章の導入の梯子を思い出してください。スキルで積み上げられた信頼だけが、タスクと活動の自律性を正当化します。企業融資は統制されない意思決定のコストが資本規模で測定される領域です。このような領域で初日から判断を機械に委ねる組織はなく、委ねてもなりません。拡張とは、その信頼が積み上がっていく形です。エージェントの要約が正確だったか、優先順位の提案が正しかったか、分析報告書が審査の結論とどれほど一致したか — 日々の業務がそのまま検証の記録になります。

その上に置かれるのは人の居場所に対する誠実さです。CLAWにおいて承認の押印、一括処理の確定、報告書生成の開始は、すべて人の確認を待ちます。これは第3章と第4章で見たHITLチェックポイントの原則 — 「自律性とは人が消えた状態ではなく、人の居場所が正確に設計された状態」 — の実務版であり、規制産業の責任構造とも整合します。監督当局の前で「その与信は誰が承認したのか」という問いへの答えは、常に人の名前でなければなりません。

そして最も外側の層が変化管理の現実です。現場の職場を根こそぎ作り変える導入は、教育コストと抵抗によって崩れがちです。使い慣れた画面はそのままにして傍らに同僚を一人座らせる導入は、初日から使うことができ、最初の週から感謝されるようになります。拡張ワークプレイスは技術戦略である以前に採用（adoption）戦略です。

要するに、CLAWの文法はこうです。画面はそのまま、判断の主は人、AIは要約と優先順位付けと草稿と警報を担う。そしてこの文法が定着した後に初めて — あるタスクにおいてエージェントの打率が十分に証明された後に初めて — 梯子の次の段、タスクハーネスへの昇格が議論されます。

5.7 鉤爪のパターン：この実装例が示すもの

CLAWは実装例ですが、実装例が示すパターンは普遍的です。AOEDEの鉤爪が現場のドメインを掴むときに取る形を、このアプリケーションから四つ抽出することができます。

一つ目のパターンはドメインの全貌を先に登録することです。183画面のレジストリと十一の業務ドメインの地図が先にあり、実装はその座標の上で進められます。代表画面12個が完全に作り込まれ、残りが骨格として登録されている現在の状態は、未完成ではなくMVOのリズムそのものです。第1章の表現を借りれば、「目的地がオントロジーを引き寄せて存在させる」方式です。次に作るべき画面が何かは、地図がすでに知っています。

二つ目のパターンは役割をシステムの第一級概念とすることです。ダッシュボードも、エージェントの挨拶も、インサイトの内容も役割によって分かれます。これは本シリーズを通して積み上げてきた役割アーキテクチャ — テオリアの役割補強、ポイエーシスの役割設計、プラクシスの役割登録 — がフロント画面で実を結ぶ地点です。

三つ目のパターンはエージェントを画面ではなく文脈に内蔵することです。AOEDE-Clawエージェントは特定画面の機能ではなくワークプレイス全体に常駐し、ユーザーの役割・作業キュー・現在の業務ドメインという文脈を常時把握しています。「分析　[企業名]」のようなスキル呼び出しがどの画面からでも可能な理由です。

そして四つ目のパターンは背後のワシと接続する余地を残しておくことです。この実装例のエージェントは実際のAI APIで動作しており（キーがなければデモモードに切り替わります）、その場所はすなわち本シリーズが歩んできた全体スタック — テオリアのオントロジーが根拠を、ポイエーシスのハーネスが統制ポイントを、プラクシスのミメーシスが系譜ある実行を供給する — が差し込まれるソケットです。今日の実装例ではインサイトと分析はデモデータの上で動いていますが、その形は実戦でネクサスに配備された能力ハーネスが満たすことになる形と同じです。鉤爪はワシの末端であって、ワシとは別個の生き物ではありません。

5.8 管理者の目：拡張の成果を何で測るか

拡張ワークプレイスの導入を検討する管理者にとって、CLAWの三つのダッシュボードは成果指標のヒントまで併せて与えてくれます。各役割の「最も高くつく失敗」を裏返せば、それがそのまま測定項目になります。

RM側では見落としの減少です。満期漏れ件数、信用調査期限超過率、そして顧客からの問い合わせから総合情報の回答までの所要時間 — 「分析一文」が短縮するまさにその時間です。

審査側ではボトルネックの解消です。承認待ち日数の分布、標準案件の処理リードタイム、そして一括審査提案の採用率とその正確度が指標になります。

リスク側では発見の早期化です。閾値超過から対応着手までの時間、そしてヴィンテージ異常信号がどれだけ先んじて警報を鳴らしたか（先行日数）を測ります。

これらの指標が実際に使われる場面を想像してみると、その重みが明らかになります。半年後のある昇格審査の場、議題は「企業総合分析能力をタスクハーネスに昇格させるか」です。テーブルの上に置かれるのは担当役員の所感ではなく記録です。過去半年間にこの能力の提案が何件あり、そのうち何件が採用されたか、採用された分析がその後の審査結論とどれほど一致したか、認証試験の点数と有効期間はどうか。記録が厚ければ昇格は自然な流れとなり、薄ければ審査は先送りされます。いずれにせよ、決定の根拠が人の確信ではなく蓄積されたデータであるという点が、この体系の要諦です。

そしてもう一つあります。前節の論理に従えば、拡張段階における最も重要な産出物は効率ではなく積み上げられた信頼の記録です。エージェント提案の採用率と事後の正確度を役割別・能力別に蓄積してください。その記録が十分に厚くなった能力がタスクハーネス昇格の候補となり、第4章で見た認証・熟練度体系がその昇格を公式化する手続きとなります。拡張のダッシュボードは、それ自体が自律化の審査書類というわけです。

5.9 むすびに：ワシが掴む術を学ぶ場所

五章にわたる旅をここで締めくくります。テオリアでビジネスが言語となり、ポイエーシスで言語が三つのサイズのハーネスへと組み立てられ、プラクシスでハーネスがネクサスへ配備され、ミメーシスが系譜を残しながら実行しました。そしてCLAWにおいて、そのすべてが向かっていた地面 — 一人のRMが朝に開く画面、一人の審査役が向き合う待機列、一人のリスク管理者が見守る予警報線 — に鉤爪が触れました。

この鉤爪を任される管理者への言付けは、結局のところ一つの姿勢に集約されます。拡張から始めつつ、拡張にとどまる計画は立てないでください。CLAWの形は梯子の最初の段にすぎませんから、エージェント提案の採用率と正確度を導入初日から記録し、どの能力が次の段へ上がる資格を積み上げているかをデータで把握できるようにすべきです。成果を語るときは総論ではなく役割の言葉を使ってください。見落としとボトルネックと発見の遅れ — 役割ごとに「最も高くつく失敗」を定義し、それを指標とするとき、測定が組織を動かします。

運用が定着していくほど守るべきものは確認要求の文化です。「確定しましょうか？」という問いかけは摩擦ではなく統制ポイントであり、利便性を理由にこの問いかけを取り除こうという要求は必ず出てきます。その要求には当該能力の正式な昇格審査で答えるのが正しく、問いかけの削除で答えるべきことではありません。あわせて、画面の地図をオントロジーとつないでおいてください。183画面のレジストリはそれ自体で優れた資産ですが、この画面がどの業務対象、どのタスクの表面であるかがテオリアの座標と結びついたとき、初めて鉤爪が胴体の神経とつながります。

そして視線を少し遠くに向けてください。第1章は左の鉤爪（専門金融サービス）の傍らに右の鉤爪 — 顧客管理、顧客資産管理、包括的リスク管理 — を描いておきました。CLAWで検証されたパターン、すなわちドメイン登録と役割第一級化と文脈内蔵型エージェントとスタックソケットは、次のドメインでもそのまま再利用されます。次の鉤爪を準備してください。一つの鉤爪の成功は一つの鉤爪の成功で終わるのではなく、掴む術の組織的な学習として残ります。

第1章の最後の文章でこの旅を締めくくるのがよいでしょう。「エンジンに忠実に実行させ、鉤爪に実際の業務を掴ませ、ワシが実際に掴む術を学んだ分だけオントロジーが育つようにしてください。」CLAWはその文章の最後の一節が始まる場所です。鉤爪が掴み、掴んだ経験が記録され、その記録が頭へと昇ってオントロジーを育てる循環 — ワシは今や飛ぶ術だけでなく、掴む術を学んでいる最中です。

第5章の要点：CLAWは企業融資ドメインに対するCLAWSのリファレンス実装であり、183画面のレジストリと11の業務ドメイン地図の上で、役割別（RM・審査役・リスク管理者）のダッシュボードと文脈内蔵型のAI同僚を提供する。設計の重心は代替ではなく拡張であり、すべてのエージェント提案は人間の確認を経て実行される。拡張段階における中心的な産出物は効率ではなく積み上げられた信頼の記録であり、その記録がタスクハーネス昇格の審査書類となる。

第6章. 統合実行ガイド：管理者の机の上で

本章で扱う内容：五つの物語に散らばっていた管理者向けの指針を、一つの実行体系に統合する。導入ロードマップ、組織と役割別の責任、成果指標体系、会議体の運営ルール、そしてよくある質問への回答。

6.1 本章の性格

第1章から第5章までは、それぞれワシの一つの器官を巡りながら物語を展開してきました。各章の終わりには、その器官を担当する管理者に向けた提言が五つから六つずつ置かれていました。本章では、それらの提言を一箇所に集め、導入を実際に主導すべき管理者の時間軸に沿って再配列しています。新しい内容を付け加えるというより、散らばっていたものを実行可能な形にまとめることが目的です。

6.2 導入ロードマップ：拡張から自律へ至る梯子

AOEDEの導入は、技術プロジェクトのスケジュール表としてではなく、信頼が積み上がっていく梯子として設計されています。シリーズ全体を貫くこの原則を導入段階に移すと、次のような流れになります。

準備段階 — 最初の鉤爪と最初のオントロジーを選ぶ。出発点は「自社の全体オントロジー」ではなく、一つの到達点、すなわち一つの能力です。複雑性が高く、根拠が文書にあり、誤った判断のコストが大きい領域 — つまり系譜と統制が切実に求められる領域 — が良い最初の候補です。その一つの能力が信頼できる形で機能するために必要な、最小限のエンティティ、属性、関係、ガバナンスパラメータを定義します。これがMVO（実行可能最小限オントロジー）の出発点です。

第1段階 — テオリアで言語化する。ジェネシス（Genesis）パッケージでリポジトリをブートストラップし、対象業務のビジネスオブジェクトモデルと概念モデルを整え、拡充エディタで知識・ルール・役割・ポリシーを埋め、BPMN・DMNでプロセスと判断を描きます。セマンティック・ファクトリーに実際の規程や契約文書を流し込み、モデルと現実のずれを確認します。この段階の完了基準は「『Poiesisへ提出』ボタンを押せる状態」です。

第2段階 — ポイエーシスでハーネスを組み立てる。ハーネスの規模（スキル・タスク・アクティビティ）をまず合意し、シナリオから規格の整った設計を作り、意思決定テーブルのカバレッジ・重大度の順序・禁止ルールを練り上げ、形式検証・意味検証・模擬実行という三重の試験を通過させます。この段階の完了基準は「飛行記録が添付された配備承認」です。

第3段階 — プラクシスで統治しながら運用する。ネクサスで配備し、ミメーシスが実演する作業の系譜を標本監査し、変更管理・シグナル・監督ルールという三つの道具を稼働させ、認証と習熟度の通帳を積み上げます。この段階に完了基準は特にありません。運用は終わりのない仕事であり、その代わりに次の段階へ進むための根拠がここで積み上がっていきます。

第4段階 — CLAW型の拡張で現場に届ける。鉤爪の四つのパターン — ドメイン登録、役割の一級化、コンテキスト内蔵エージェント、スタックソケット — に従い、現場のワークプレースにエージェントを同僚として配置します。画面はそのまま残し、判断の主体は人のままとし、提案の採択率と正確度を記録します。

第5段階 — 梯子を昇る。採択率と正確度の記録が厚みを増した能力を、タスクハーネスへの昇格候補に挙げ、認証・習熟度の手続きを経て昇格を正式なものとします。タスクが十分に熟せば、アクティビティレベルの自律運用を議論する資格が生まれます。同時に、この鉤爪で検証されたオントロジーとパターンをジェネシスパッケージとして書き出し、次のドメインの種として活用します。

このロードマップをカレンダー上に置いてみると、最初の90日間の見取り図はおおよそ次のように描けます。最初の月には、最初の鉤爪となる能力を一つ選び、その能力のゴールドスタンダード — どのような報告書が出れば成功と言えるか — を現場と合意し、プロセス上の役割にペルソナ名を割り当てます。二か月目には、テオリアでその能力の最小オントロジーを立ち上げて拡充し、実際の規程や契約文書をセマンティック・ファクトリーに流し込んで、モデルと現実の最初の照合を受けます。三か月目には、ポイエーシスでハーネスを組み立てて模擬実行の飛行記録を積み上げ、関門を通過した最初の配備をプラクシスの舞台に載せます。三か月後に経営陣への報告に上がるのは、大げさな転換宣言ではなく、実際に灯った明かり一つ — 機能している能力、その系譜、そして次の区域の地図です。

このロードマップにおいて最もありがちな誘惑は、段階を飛ばすことです。特に「すでに検証された技術なのだから、最初からアクティビティレベルの自律運用に行こう」という要求が必ず出てきます。シリーズの答えは一貫しています。自律性は宣言するものではなく積み立てるものであり、規模の見誤り — 能力で十分な場面にアクティビティ・ハーネスを築いたり、アクティビティが必要な場面に能力だけを与えたりすること — が、この領域における最も高くつく過ちです。

6.3 役割と責任：新たに生まれる管理業務の担当者を決める

AOEDEの導入は、新しい種類の管理業務を生み出します。これらの業務の担当者が決まっていなければ、道具はあっても統治のない状態になります。五つの章の提言から抽出した責任一覧は次のとおりです。

オントロジー・オーナー（テオリア）。オントロジーツリーと概念モデルの管理権限を持ちます。ツリーはあらゆる作業の座標系であり、概念モデルはその座標系の文法にあたるため、文法が乱れれば、その上に成り立つすべての文章が乱れてしまいます。セマンティック・ファクトリーの矛盾報告を定例議題として扱い、モデルと文書のずれを負債としてではなく、オントロジーが成長するための原料として消化するのも、この役割の務めです。

カプセル・ハーネス承認者（テオリア・ポイエーシス）。ドメイン知識カプセルと能力カプセルのライフサイクル（草案 → レビュー → 承認 → 公開）、そしてハーネスパイプラインの関門（受付済み → 作成中 → 検証済み → 配備済み）を守ります。模擬実行記録のない配備承認要求を差し戻すことが、このツールの文化にかなっています。

リスクポリシー担当（ポイエーシス・プラクシス）。意思決定テーブルの保守性原則とデフォルト決定の作成、禁止ルールの規制根拠の補強を、ドメイン専門家の正式な業務として付与します。どのスキルと推論テンプレートがMRM（モデルリスク管理）の対象であるかをリスク部門と共に指定し、指定が終われば変更管理ダッシュボードの待機項目がそのままリスク部門の業務リストになります。

運用監督者（プラクシス）。作業成果物の系譜を標本監査し、認証の失効を月例点検し、約束違反（「違反」状態）の頻度とパターンをハーネスの接合部の健全性指標として追跡します。スロットル回路 — シグナルの重み付けと関門連携 — の定期的な調整もこの役割が主管しますが、政策的判断は与信政策協議会と共に行います。

現場採用リーダー（CLAW）。役割ごとの「最も高くつく過ち」を指標として定義し、エージェント提案の採択率・正確度の記録を管理し、確認要請の文化を守ります。フェデレーション（Federation）に提供する能力と借りる能力のポリシーをあらかじめ定めるという対外ガバナンスの課題も、技術が成熟した後に先送りするのではなく、今この役割と経営陣が共に取り組むべきです。

一人が複数の役割を兼任することは可能です。しかし、いかなる役割も空席であってはなりません。特に初期段階で最も空席になりやすいのが、オントロジー・オーナーです。「モデルはコンサルタントが作って去っていった」という状態のまま運用に入った組織では、オントロジーは半年のうちに古びた文書になってしまいます。

6.4 成果指標体系：何を測り、何を報告するのか

五つの章で言及された測定項目を三つの層に整理すると、次のようになります。

第一層 — 現場効果指標。役割ごとの「最も高くつく過ち」を裏返した指標群です。見落としの減少（満期漏れ件数、期限超過率、総合情報の回答所要時間）、ボトルネックの解消（承認待ち日数の分布、標準案件の処理リードタイム）、発見の早期化（閾値超過から対応着手までの時間、異常シグナルの先行日数）。この層は経営陣報告の言語です。

第二層 — 信頼積立指標。自律性昇格の審査書類となる指標群です。エージェント提案の採択率と事後正確度（役割別・スキル別）、認証試験の点数と有効状態、模擬実行のカバレッジと配置統計、約束違反の頻度とパターン。この層は「次の段階へ進んでよいか」という問いへの根拠です。

第三層 — ガバナンス健全性指標。システム自体の規律が生きているかを見る指標群です。セマンティック・ファクトリーの矛盾報告の発生と処理速度、検証警告バックログ（例：規制条項との連結が不十分な禁止ルール）の消化推移、変更管理待機項目の滞留時間、認証失効の放置件数、能力報告書において「絞って回答した・回答できなかった」として現れたオントロジーの空白区域。この層は運用会議の言語です。

三つの層の指標は、報告の流れにもつながっています。現場効果指標は四半期の経営陣報告の冒頭に置かれ、信頼積立指標は昇格審査の書類となり、ガバナンス健全性指標は月次運用会議のチェックリストとなります。同じデータが三つの異なる会議で、三つの異なる問い — 効果はあるか、さらに任せてよいか、規律は生きているか — に答える構造です。指標を新たに考案する必要はありません。システムが運用の中で自然に残す記録を、三つの筋道で読む習慣さえあれば十分です。

指標体系において、シリーズが特に強調している文化が一つあります。理解報告書を読む文化です。システムが「この部分は絞って回答し、この部分には回答できなかった」と正直に語るとき、その言葉を聞き流さないチームだけが、正直なシステムの価値を余すところなく享受できます。正直な失敗報告は減点の材料ではなく、次に築くべきオントロジーの区域を示す地図です。

6.5 会議体と運営ルール：五つの章の提言をカレンダーに載せる

提言はカレンダーに載って初めて実行されます。五つの章の指針を会議体の観点で再配列すると、次の定例議題になります。

週次 — パイプラインレビュー（ポイエーシス）。進捗報告の言語は、受付済み・作成中・検証済み・配備済み・差し戻しという五つの状態に統一します。何週間も「作成中」にとどまっているハーネスや、「検証済み」と「配備済み」の間のボトルネックが、この会議の関心事です。

月次 — 運用・ガバナンス会議（プラクシス）。失効間近の認証の点検を固定議題とし、変更管理の待機項目、約束違反のパターン、有効なアラートの推移を併せて見ます。重要作業の系譜標本監査の結果も、この場で報告されます。

月次または隔月 — オントロジー協議会（テオリア）。セマンティック・ファクトリーの矛盾報告を定例議題とし、文書とモデルのずれを調整します。MVOとして育っていくオントロジー同士が重なり始める地点 — 例えば、ある能力の「顧客」と別の能力の「借主」が出会う瞬間 — の整理もここで扱います。ハーネスは発見までしかしてくれません。調整は人の務めです。

四半期 — 政策レバー点検（ポイエーシス・プラクシス）。スロットル回路のシグナル重み付けと関門連携を、成果フィードバックとともに再検討し、禁止ルールの規制根拠補強バックログの消化状況を確認します。検証が残した警告リストが、そのままこの四半期の業務リストになります。

四半期または半期 — 昇格審査（全社）。信頼積立指標が十分に積み上がった能力のタスクへの昇格、タスクのアクティビティへの昇格を審査します。審査の根拠は、担当役員の確信ではなく、認証記録と採択率・正確度の蓄積でなければなりません。確認の疑問符を取り払おうという現場からの要求も、この審査を通じてのみ受け入れます。

6.6 よくある質問への回答

導入をめぐる議論で繰り返し登場する質問について、シリーズの論理に沿って回答を整理しておきます。

「オントロジーの整備だけで何年もかかるのではないか」その懸念こそ、MVOがまさに回避しようとしているパターンです。AOEDEは、全社オントロジーを先に完成させるアプローチを明示的に拒否しています。最初の一つの能力に必要な最小限だけを定義し、一つの配備が成功するたびに、オントロジーを一区域ずつ広げていきます。全社オントロジーは目標ではなく、鉤爪が積み重なる中で自然に組み上がっていく結果です。このMVOアプローチの弱点を補うためにシャドウ・オントロジーが導入されており、最初の能力オントロジーの適用の段階から、シャドウ・オントロジーが日の目を見るようにしています。

「AIが捏造した数字で報告書が出てしまったらどうするのか」これは構造的に遮断されています。数字を生成するのはLLMではなく決定論的コンピュートエンジンであり、自然言語による問い合わせは三段構成（A段：言語理解 — B段：検証・コンパイル — C段：実行・検証）のハーネスを通過し、スキーマに結び付かない要素は実行前に除外されます。セマンティック・ファクトリーの抽出処理にも忠実性ゲートがあり、原文に根拠のない項目は保存前に却下されます。重要なのは、この遮断が「AIが行儀よく振る舞うこと」に依存するのではなく、アーキテクチャによって強制されている点です。

「結局のところ人がすべて確認しなければならないなら、効率は出るのか」拡張段階の効率は、判断の自動化からではなく、判断材料の準備速度から生まれます。半日かかっていた企業の全体像の収集が、通話が終わる前に用意されること、見落とし・ボトルネック・発見の遅れが指標として減っていくこと、それがその効率です。そして確認という行為の記録そのものが、次の段階の自律化の根拠となるため、人による確認はコストではなく投資です。

「監査や監督当局への対応はどうなるのか」三つの問いに画面上で答えられる状態にすることが、目標であり設計そのものです。「その数字はどこから来たのか」にはアクション単位の入出力の系譜で、「そのルールの法的根拠は何か」にはルールと規制条項の構造化された連結で、「その行為を行う権限はあったのか」には権限マトリックスと監査記録で答えます。そして最終承認の名義は、常に人の名前です。

「自社のデータ品質で可能なのか」完璧なデータを前提としない点が、このフレームワークの特徴です。セマンティック・ファクトリーはモデルと現実の文書とのずれを見つけ出すための装置であり、出典帰属と不確実性プロファイルは、値がどれほど信頼できるかを値単位で記録します。そして到達点が求める値がまだ存在しない場合、オントロジーは捏造される代わりに、承認者が埋めるべきスロットと決定論的フォールバックとして育っていきます。つまり、データの欠陥は導入を阻む壁ではなく、システムが顕在化させ、人が返済していく管理対象なのです。むしろ、最初の鉤爪の範囲を定める際には、データが比較的整っている領域を選ぶことが現実的なコツです。

「配備済みのハーネスに問題が発生したらどうなるのか」戻ってくるための扉は常に開かれています。すべてのハーネスはブランチとコミットによって履歴が管理されており、過去のバージョンにロールバックできます。配備後の部品の修正は、変更管理レベルに応じて再び関門を通過しなければならず、シグナルとアラートが異常を重大度別に集計します。約束の連鎖のおかげで、どこからずれが生じたかは事後調査ではなく台帳照会の問題であり、系譜のおかげで、問題となった結論の原因となったアクションまで遡ることができます。出て行く扉は狭く、戻ってくる扉は開いている構造 — 配備統制の定石がそのまま実装されています。

「既存システムを刷新しなければならないのか」CLAWのパターンがその答えです。使い慣れた画面の文法はそのまま残し、AIは右側のパネル一つに収まって座ります。拡張ワークプレースは、技術戦略である以前に採用戦略であり、総入れ替え型の導入が教育コストと抵抗によって頓挫するという現実を正面から反映した設計です。CLAWは既存システムをそのまま残し、企業のオントロジーを活用して既存の従業員の能力を拡張するように設計されています。ここでAIエージェントは、有能な協力者として画面の片側に座り、人間の作業者の能力を増幅させます。

6.7 むすびに：日々の飛行

本文書の冒頭に置かれていた問いに立ち返りましょう。自ら判断し行動するソフトウェアに、行動する自由と信頼できる規律を、どのようにして同時に与えるのか。

五つの章を経てきた今、答えは一つの構造に要約されます。見える範囲だけオントロジーを定義し（テオリア、MVO）、行動できる範囲だけエージェントを作り（ポイエーシス、三つの規模のハーネス）、すべての行動を統制とガバナンスに結び付け（ネクサス、プラクシス）、エンジンに忠実に実行させ（ミメーシス、系譜）、鉤爪に実際の業務を掴ませ（CLAWS、拡張）、実際に掴む術を学んだ分だけオントロジーを成長させる（循環）。

そして、この構造は一度の決断で完成するものではなく、日々の運用によって維持されます。テオリアで定義し、ポイエーシスで組み立て、プラクシスで統治し、鉤爪で記録する日々 — それがワシの飛行です。

最後に一つだけ付け加えます。本文書が長く語ってきたことは、結局のところ技術ではなく組織の習慣です。矛盾報告を議題に載せる習慣、飛行記録のない承認を差し戻す習慣、疑問符を守り抜く習慣、正直な失敗報告を地図として読む習慣。道具はこうした習慣が根づく枠を用意してくれるだけであり、その枠を満たすのは常に人です。エージェンティックAIの時代に組織が備えるべき競争力があるとすれば、それは最も賢いモデルを選ぶ目利きではなく、こうした習慣を地道に守り続ける筋力でしょう。本文書が、その筋力を鍛えるための一助となる教範となることを願っています。

第6章の要点：導入は、準備（最初の鉤爪の選定）→ 言語化（テオリア）→ 組み立て（ポイエーシス）→ 運用（プラクシス）→ 拡張（CLAW）→ 昇格という梯子をたどります。オントロジー・オーナー、承認者、リスクポリシー担当、運用監督者、採用リーダーという五つの役割に空席があってはならず、成果は現場効果・信頼積立・ガバナンス健全性という三つの層で測定します。提言はカレンダーに載って初めて実行され、自律性の拡大は常に記録の蓄積の上で審査されます。

付録A. 用語集

本付録は、本文に登場する主要用語を管理者の言葉で解説したものです。正式な定義ではなく理解を助けるための実務的な説明であり、本文で初めて登場する文脈と併せてお読みいただくことをお勧めします。

AOEDE (Agentic Ontology Envisioning and Deployment Environment) エージェンティックAIを企業に導入するための全体フレームワーク。オントロジー定義（テオリア（THEORIA））、ハーネス組み立て（ポイエーシス（POIESIS））、運用統制（プラクシス（PRAXIS））、現場適用（CLAWS）を一つの一貫した構造にまとめ、全体アーキテクチャを翼を広げたワシに対応させる。

エージェンティックAI（Agentic AI） 定められた手順のみを繰り返す自動化とは異なり、目標を受け取り自ら状況を判断し行動を選択するAI。自由と規律を同時に設計すべき対象であり、本文書全体のテーマである。

オントロジー（Ontology） 自社の業務領域にどのような対象が存在し、それらがどのように関連し、「意思決定」と「根拠」が何を意味するのかを、コンピュータが理解できる構造で記述したもの。ビジネスの公式な地図であり、公式な辞書。

テオリア（THEORIA） ワシの頭部。オントロジーが定義・拡充・検証される場所であり、フレームワーク全体の判断が始まる概念的中心。Webアプリケーション（テオリア・クライアント）とAOEDEオントロジーサーバーの二層構造で実装される。

ポイエーシス（POIESIS） ワシの左翼、「作る翼」。オントロジーで定義された業務を、実行可能なエージェント・ハーネス（アクティビティ・タスク・スキルの三つの粒度）へと組み立てる場所。対象ユーザーは開発者ではなく、ビジネスアナリストと業務設計者である。

プラクシス（PRAXIS） ワシの右翼、「治める翼」。デプロイされたハーネスの中でエージェントが実際に働く舞台であり、実行のモニタリング・変更管理・認証・監督ルールを担う。

ネクサス（NEXUS） ハーネスが記録される規格であり、「作る翼」と「治める翼」がやり取りする契約文書の形式。CC-DSL専用言語で記述され、97種の定義要素と28種の連結関係により、一つのエージェント組織を漏れなく記述する。一つの原本から、要求仕様・プロセス・データフロー・ガバナンスなど七つの視点が機械的に派生する。

ミメーシス・エンジン（MIMESIS ENGINE） ネクサスを実行する決定論的な実行ドライバー。「忠実な再現」という名の通り結果をでっち上げることなく、すべてのアクションの入力と出力をペアで保存し、あらゆる結論についてダウンロード可能な系譜を残す。

CLAWS／CLAW CLAWSは、フレームワークが実際のビジネスと接する接点（かぎ爪）の総称。CLAW（Corporate Loan Augmenting Workplace）はその中でも法人融資ドメインの実装例であり、「拡張ワークプレイス」のパターンを示す。

ハーネス（Harness） AIという知能に装着する馬具。何を知るべきか、何ができるか、どこまで進んでよいか、どこで必ず止まるか、あるいは人に委ねるかが編み込まれた構造物。AOEDEにおいて「エージェントを作る」とは、すなわち「ハーネスを編む」ことを意味する。

ハーネスの三つの粒度（アクティビティ・タスク・能力） アクティビティ・ハーネスは業務フロー全体の自律運用を、タスク・ハーネスは一つの役割の特定タスクの代行を、能力ハーネスは人の能力拡張を目標とする。三つは入れ子構造になっており、導入は能力→タスク→アクティビティのはしごを上る。

MVO（Minimum Viable Ontology、実行可能最小限オントロジー） 「まず全体のオントロジーを完成させる」というアプローチを拒み、今必要な能力を一つ、信頼できるものにするために必要な最小限だけを定義する方法論。デプロイが成功するたびに、オントロジーが一区画ずつ育っていく。

能力カプセル（Capability Capsule） ガバナンスが組み込まれた、それ自体で完結する能力単位。ゴールドスタンダード・レポート、スキル、推論、エンティティモデルとデータ契約、ソリューションツリー、決定論的コンピュートエンジン、シグナルとギャップ検知器、回帰テストのフィクスチャ、そして人の判断のための明示的スロットを含む。

メタオントロジー／会社オントロジー オントロジーの二つの層。メタオントロジーは「#」が付くメタオブジェクトの世界であり、会社に関する知識を記述するための文法である。会社オントロジーは、その文法で記述された自社の実物モデルである。この二つの平面を混同することが、誤答の典型的な原因となる。

ジェネシス（Genesis） 二つの意味を持つ名称。一つは概念エディタの名前、もう一つは業務対象の定義とビジネスオブジェクトモデル図を含む可搬パッケージ形式。検証済みのオントロジーをエクスポートし、新しいリポジトリをブートストラップするための種であり、運搬用の器でもある。

セマンティック・ファクトリー（Semantic Factory） Wikiに添付された文書（規程集、契約書、マニュアル）からエンティティ・事実・関係を抽出し蓄積する工場。すべての事実に出典が付与され、原文の根拠がない項目は忠実性ゲートで却下され、文書とオントロジーの矛盾を検知して人によるレビュー案件とする。

拡充（Enrichment） オントロジーツリーという骨格に肉付けを行う作業。業務対象の属性と意味、ドメイン知識、決定ルール、役割・スキル・ツール・ガバナンスポリシーを構造化データとして満たす。AIエージェントという新しい「従業員」の職務記述書を書くことに相当する。

CVR（顧客価値実現）エディタ 顧客ジャーニー・タスク定義・アイデア創出・バリューフロー設計・エージェント機会・QFD・実現度測定の七段階で顧客活動を扱うエディタ。デザインシンキングの言語を用いつつ、成果物はオントロジーとエージェントポートフォリオに直結する。

モデル・ハーネス／実行ハーネス テオリアを支える二つのハーネス。モデル・ハーネスはオントロジーモデル自体の整合性（文法、推論エンジン、境界と履歴、矛盾検知）を守り、ボトムアップの成長が混乱に陥ることを防ぐ。実行ハーネスはAIの自然言語クエリの実行を三段構造で統制し、システムが問題生成器になることを防ぐ。

三段実行ハーネス（A段・B段・C段） A段（言語理解）ではLLMが自然言語を形式化されたクエリ計画へと翻訳するが、その出力は信頼されない。B段（検証とコンパイル）では決定論的コードが計画のすべての要素を生きたスキーマに束縛し、束縛できない要素は排除され、読み取り専用かつ上限が設定されたクエリのみが生成される。C段（実行と検証）では批評エンジンが結果を検査し、有限回数の範囲内で再試行する。

理解レポート（Comprehension Report） 質問のうち何がそのまま実行され、何が絞り込まれ、何がなぜ除外されたのかを明示する成果物。システムができないことを黙って省いて答える代わりに、できなかったと言わせるための仕組み。

デジタルツイン（Digital Twin） ビジネスの構造・知識・状態をコンピュータが理解できる形で映し出し、問えば根拠をもって答え、変更すれば波及効果を示してくれる生きた対応物。一度の大工事ではなく、六つの段階（種をまく→定義平面→肉付け→証拠の連結→グラフとして目覚める→増殖）で築かれる。

BPMN／DMN 業務プロセス（BPMN）と意思決定テーブル（DMN）の国際標準表記法。テオリアで描かれるこれらの図は参考資料ではなく、エージェントが実際に従うことになる規格である。

意思決定テーブルの三つの規律 カバレッジ（すべての入力の組み合わせに判断が存在すること――デフォルト決定を含む）、重大度順序（複数のルールが競合する場合は最も保守的な決定から適用）、禁止ルール（「この条件ではこの決定が絶対に出てはならない」というルールの機械的強制）。住宅担保ローンの例では、1,410通りの入力組み合わせの全数分析により、多値ケース97件と未網羅ケース897件が明らかになり、禁止ルール194件が導出された。

スロットル（Throttle） 自律運用されるアクティビティ全体の保守性と積極性を調整するポリシーレバー。市場・延滞・運用シグナルが加重合算されてスロットルスコアとなり、各ゲートの承認閾値と保守性バイアスに変換され、成果が再びシグナルへと戻る閉じたループである。

HITL（Human-in-the-Loop）チェックポイント 人が介入する地点。アクティビティ・ハーネスにおける自律性とは、人がいなくなった状態ではなく、人の居場所が正確に設計された状態を意味し、HITLチェックポイントはその居場所を第一級の設計要素として宣言したものである。

約束のリング（要求済み→コミット済み→報告済み→受諾済み） 言語行為理論に根ざしたトランザクションの四つの相。あらゆる事柄に要求した者とコミットした者が存在し、コミットメントには有効・履行済み・違反・取消の状態があるため、責任の追跡が事後調査ではなくデータ構造そのものになる。

エージェントロジー（Agentology） エージェント能力の八分類――認知、知識、メモリ、推論、インタラクション、学習、ペルソナ、プレゼンテーション――と、入出力双方に設けられた七層の安全フィルター。登録されていない能力はハーネス内に存在しないという原則の運用面での実装。

能力（Capability）とコンピテンシー（Competency） 能力はビジネス層――ビジネス価値を生み出す仕事（「担保評価を行う」）を指す。コンピテンシーはエージェントロジー層――エージェントの認知能力（「文書からエンティティを抽出できる」）を指す。この二つの層を区別するための語彙。

MRM（Model Risk Management、モデルリスク管理） 規制が要求するモデル検証手続き。プラクシスの変更管理レベル（自由変更――レビュー要――MRM要）の中で最も重い段階であり、対象の指定は技術的判断ではなく規制対応上の判断である。

認証と習熟度 エージェントスキルの習熟度の四段階（未訓練・初級・熟練・エキスパート）と、テストスイートの受験によって証明され有効期限を持つ認証制度。自律性の拡大が担当役員の確信ではなく、認証記録の積み重ねの上で決定されるようにする信頼の通帳。

フェデレーション（Federation）／A2A 組織の壁の外にあるエージェントと、標準プロトコル（A2A、エージェント間通信）で接続される体系。他組織のエージェントがエンドポイントとともに登録され、自社のハーネスが持たない能力を条件に応じて呼び出すことができる。

RM（Relationship Manager） 法人顧客を担当する営業・リレーションシップ管理担当者。CLAWの三つのペルソナ（RM、本部審査役、リスク管理者）の一つ。

NPL（Non-Performing Loan）／ヴィンテージ分析 NPLは不良債権。ヴィンテージ分析は融資を実行時期別のグループに分け、各グループの延滞率カーブを追跡する手法であり、特定時期の実行分に生じる異常シグナルを早期に浮かび上がらせる。

拡張ワークプレイス（Augmenting Workplace） 既存の画面文法を尊重しながら、AIを文脈組み込み型の同僚として配置する導入形態。画面はそのまま、判断の主体は人、AIは要約・優先順位付け・草案作成・アラートを担い、すべての提案は人の確認を経て実行される。

付録B. 五つの章を貫く文章

本文の随所に置かれていた重要な文章を一箇所に集め、それぞれの文章がどのような文脈から生まれ、管理者に何を求めているのかを簡潔に振り返ります。会議資料や研修資料で引用する際、本付録が索引の役割を果たせるでしょう。

「オントロジーなしに動くエージェントは自律的なのではなく、単に責任を問えない存在にすぎない。」 第1章、頭部に関する文章です。エージェンティックAIの導入順序を定める文章でもあります。この文章が求めているのは完璧な全社モデルではなく、エージェントが足場とするだけの言語――その業務領域の対象と関係と判断基準の定義――が自動化に先立って存在すべきだという順序の規律です。

「統制なしに作ることだけを行う組織はリスクを大量生産し、作ることなく統制だけを行う組織は何も生み出せない。」 第1章、二つの翼に関する文章です。導入をめぐる議論がスピード重視派と慎重派に分かれるとき、双方に向けて投げかけられる文章であり、AOEDEがこの対称性をスローガンではなく、同一のサーバーと同一のデータベースを共有するアーキテクチャとして実装していることが、この文章の裏付けとなります。

「目的地がオントロジーを引き寄せ、存在させる。」 第1章、MVOに関する文章です。「自社ビジネスの完全なオントロジーとは何か」という問いを「この一つの能力を信頼できるものにするために必要な最小限のオントロジーとは何か」に置き換えた瞬間、何年もかかるモデリングの大工事は、四半期単位で灯りをともしていく建設へと姿を変えます。

「正確な答えと、もっともらしく見える誤答との違いは、階層の規律から生まれる。」 第2章、二層のオントロジーに関する文章です。モデルに関する定義的な問いと、データに関するインスタンスの問いを混同することが誤答の典型的な原因であり、システムがこの二つの平面を構造的に区別していることが、回答への信頼の基盤となります。

「モデル・ハーネスのないボトムアップは速く始まって速く泥沼にはまり、モデル・ハーネスのあるボトムアップこそが初めてMVOの名に値する。」 第2章、最初のハーネスに関する文章です。小さく始めるという合意だけでは不十分であり、小さく育っていく断片を文法と推論エンジンと履歴と矛盾検知によって統御する手が同時に必要だという条件を付け加えます。

「手綱のない目標志向エージェントは、目標に向かって真面目に事故を起こす。」 第2章、二つ目のハーネスに関する文章です。エージェントリスクの本質が悪意ではなく統制されない真面目さにあるという洞察であり、それゆえ解決策も訓戒ではなく構造――信頼境界を挟んだ三段の実行ハーネス――であるべきだという結論につながります。

「システムはできないことを黙って省いて答える代わりに、できなかったと言う。」 第2章、理解レポートに関する文章です。正直なシステムの価値は、その正直さを読み取る組織においてのみ実現されます。「絞り込んで答えた」という告白を、次に築くべき区画の地図として読み取る文化が、この文章のもう半分です。

「ポイエーシスにおいて『作る』とは、すなわち『ハーネスを編む』ことである。」 第3章の最初の文章であり、このフレームワークにおける「制作」の定義を変える文章です。賢い知能は市場から調達し、組織が構築するのはその知能が自社の業務の中でどこまで進み、どこで止まるかという構造物である、という役割分担がここで確定します。

「自律性は宣言するものではなく、小さなハーネスから積み立てていくものである。」 第3章、三つの粒度のハーネスに関する文章です。能力からタスクへ、タスクからアクティビティへと上るはしごの各段は、結局のところ信頼の問いであり、その信頼は確信ではなく記録――採用率、正確性、認証――によって積み立てられます。

「エージェントに『何をすべきか』だけを教える組織と、『何を絶対にしてはならないか』までを強制する組織との間には、リスク等級の差がある。」 第3章、禁止ルールに関する文章です。カバレッジ、保守性の順序、禁止ルールという三つの規律が、「正しいやり方でのみ物事が行われる」という希望を、数学的に検証可能な性質へと変えます。

「実行して確かめていない主張には、タグが付く。」 第3章、模擬実行に関する文章です。デプロイ承認の議題が担当者の意見から飛行記録へと変わる文化、そして模擬実行のない承認申請を差し戻す慣行が、この文章の実務版です。

「文書と実際が異なるという古くからの病は、文書がすなわち実際であるという構造によって治癒される。」 第4章、ネクサスに関する文章です。要求仕様書、プロセス図、データフロー図、統制マトリクスが、一つの原本から機械的に派生する七つの視点であるとき、互いに食い違う四枚の紙という光景は原理的に消滅します。

「すべての結論に系譜があり、その系譜はダウンロードボタンとして存在する。」 第4章、ミメーシス・エンジンに関する文章です。「その結果はどうやって出たのですか」という問いが、開発チームへの問い合わせではなく、タブを一つ開くだけの行為になる状態――監査対応の観点から、このフレームワークが約束する到達点です。

「責任の追跡は事後調査ではなく、データ構造である。」 第4章、約束のリングに関する文章です。要求され、コミットされ、報告され、受諾されるという四つの相、そして「違反」という状態値があるからこそ、複数のエージェントが絡む事故においても、どこから食い違いが生じたのかは台帳照会の問題になります。

「ここでAIは審査役を代替しない。審査役の隣に座る。」 第5章、CLAWの設計思想に関する文章です。拡張という選択は技術の限界ではなく、信頼の経済学と責任構造と変革管理を併せて計算した結果であり、それゆえ拡張ワークプレイスは技術戦略である以前に採用戦略なのです。

「判断は依然として人の役割である。ただし、判断の材料が用意される速度が変わったのだ。」 第5章、「分析一文」に関する文章です。拡張段階の効率がどこから生まれるのかを正確に指し示す文章であり、効率指標を設計する際に何を測るべきか――判断の代替率ではなく、材料準備の速度と見落としの減少――も同時に教えてくれます。

「確認のクエスチョンマークは摩擦ではなく、統制ポイントである。」 第5章、エージェントの確認要求の文化に関する文章です。利便性を理由にクエスチョンマークを取り除こうという要求は必ず出てきますが、その要求に対しては、クエスチョンマークの削除ではなく、当該スキルの正式な昇格審査をもって応えるのが正しいあり方です。

「拡張のダッシュボードは、それ自体が自律化の審査書類である。」 第5章、成果測定に関する文章です。今日の採用率と正確性の記録が明日の昇格根拠となる循環――拡張段階で記録を積み上げない組織は、次の段階へ上るはしごを自ら取り払っているに等しいのです。

これらの文章を改めて読み返すと、一つの共通した基調が聞こえてきます。どの文章も技術の驚異を誇っていません。代わりに、順序と規律と記録を語っています。エージェンティックAIの時代に組織が新たに学ぶべきことがあるとすれば、それはより大きなモデルの名前ではなく、この基調――自由を与えながらも系譜を残し、スピードを出しながらも関門を守る姿勢――でしょう。

お読みいただきありがとうございます。ご不明な点がございましたら、[email protected] までご連絡ください。

AOEDEイーグル・アーキテクチャ解説書

エージェンティックAI、信頼の構造を築く

オントロジーからハーネス、そして現場の机まで — ワシの解剖学

ビジネスチーム・管理者のための統合ナラティブ・2026年7月・Business Model Governance, LLC

※本ページは AI（Claude）による自動翻訳版です。原文は韓国語で作成されています。

目次

• 文書について
• 要約
• 本書の読み方
• 第1章. AOEDEイーグル（ワシ）：全体鳥瞰図
• 第2章. テオリア：判断する頭
• 第3章. ポイエーシス：作る翼
• 第4章. プラクシス：治め、調整する翼
• 第5章. CLAW：爪が地面に触れる
• 第6章. 統合実行ガイド：管理者の机の上で
• 付録A. 用語集
• 付録B. 五つの章を貫く文章

文書について

目的

本書は、AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークの五編のナラティブ — 全体アーキテクチャ（イーグル）、テオリア、ポイエーシス、プラクシス、CLAW — を一つの解説書として統合し、ビジネス組織の目線に合わせて整えたものです。技術仕様書ではなく、導入を検討し主導すべき人々がフレームワークの設計意図と管理上の要点を理解できるよう助けるための、物語形式のガイドブックです。

対象読者

一次読者はビジネスチームと中間管理職です。エージェンティックAI導入の課題を与えられた、あるいは検討中の事業部門長、現場のプロセスとリスク・コンプライアンスに責任を負う管理者、そして現場と技術組織の間で要件を翻訳しなければならない企画・分析担当者を念頭に置いて執筆しました。コードやシステム運用の経験は前提とせず、専門用語は初出時に噛み砕いて説明し、付録の用語集に改めて整理しました。

文書の構成と読み方

本書は六つの章と二つの付録で構成されています。第1章はワシの比喩で表現された全体アーキテクチャの鳥瞰図です。第2章（テオリア）、第3章（ポイエーシス）、第4章（プラクシス）はそれぞれ頭と二つの翼を内側から見つめ、第5章（CLAW）はそのすべてが現場の机に触れる場面を描きます。第6章は五つの章に散らばった管理者向けの指針を、ロードマップ・役割・指標・会議体の実行体系として統合したガイドです。

時間のない読者は、エグゼクティブサマリーと第1章、第6章だけを読んでも、意思決定に必要な骨組みを得ることができます。各章の冒頭には扱う内容の予告が、末尾には要点のまとめがボックスで示されているため、ボックスだけを追って全体をざっと見渡してから、関心のある章に戻る読み方もお勧めです。本文中の太字は、その段落の中心となる命題を示しています。

凡例

本文中の画面構成、数値、事例（住宅ローン審査、融資デューデリジェンス、法人融資ワークプレイスなど）は、原ナラティブが記述した時点でのサンプル実装を基準としており、製品の詳細はバージョンによって異なる場合があります。ただし本書が重視しているのは画面そのものではなく、その背後にある規律 — アーキテクチャによって強制される原則群 — であり、導入の意思決定の根拠とすべきものもそちらです。外来語はできる限り日本語で言い換えましたが、フレームワーク固有の名称（テオリア、ポイエーシス、プラクシス、ネクサス、ミメーシスなど）は原語表記をそのまま用いています。また、本版では社内の議論で使われ始めた表記に従い、いくつかの用語を統一しました。能力の実装単位は「能力カプセル」、オントロジーの種であり運搬形式は「ジェネシス」、システムに登録する行為は「登録」、エンティティと関係の構造モデルは「ビジネスオブジェクトモデル」と表記し、オントロジーサーバーは別途のコード名を設けず「AOEDEオントロジーサーバー」と呼びます。旧資料もあわせてご覧になる方は、この対応関係だけ覚えておかれれば混乱はないはずです。

要約

本書が答えようとする問い

エージェンティックAI（Agentic AI）、すなわち自ら状況を判断し行動するソフトウェアを、企業業務に本格的に導入しようとする組織は、最終的に一つの問いの前に立たされます。自ら判断し行動するソフトウェアに、行動の自由と信頼できる規律をどう同時に与えるか。

自由だけを与えれば統制されない判断がリスクを生み、規律だけを強調すれば自動化の効用が失われます。本書はそのジレンマに対する一つの体系的な答えとして、AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークを紹介します。AOEDEはオントロジー（ビジネスの概念モデル）を出発点とし、エージェントを設計し（ポイエーシス）、運用を治め（プラクシス）、実際の現場業務に適用する（CLAWS）という全過程を、一つの一貫した構造にまとめ上げます。

一羽のワシ、五つの器官

AOEDEは全体アーキテクチャを、翼を大きく広げた一羽のワシとして具象化します。この比喩は装飾ではなく、設計そのものです。飛行中のワシが複数の器官の精緻な均衡によって動くように、AOEDEの各構成要素は互いに噛み合いながら一つのシステムを成しています。

本書は五編のナラティブ — 全体アーキテクチャ、テオリア、ポイエーシス、プラクシス、そして爪のサンプル実装であるCLAW（法人融資増強ワークプレイス） — を一つの報告書として統合し、ビジネス組織と中間管理職の視点から改めて整理したものです。

五つの中心メッセージ

本書全体を貫く考え方は、五つにまとめることができます。最初に来るのは、自動化より言語化が先という原則です。オントロジーなしに動くエージェントは自律的な存在ではなく、責任を問うことのできない存在にすぎません。そのためAOEDEでは、エージェントを作る前に、まずビジネスそのものが明確な言語で定義されます。この原則から自然に導かれる二つ目の考えは、私たちが作るべきものはエージェントではなくハーネスであるということです。賢いが手綱のないAIは、今やどこでも手に入ります。企業が自ら築くべきなのは、その知性に取り付ける馬具 — すなわち、何を知り、何ができ、どこで必ず止まるのかが組み込まれた構造物 — です。

三つ目の考えは、導入の速度に関するものです。自律性とは宣言するものではなく、積み立てるものであるという命題のもと、AOEDEはスキル（人の能力の増強）からタスク（一つの役割の代行）を経て、活動（フロー全体の自律運用）へと上る三段階のはしごを提示します。小さな単位で検証された信頼だけが、より大きな自律性を正当化するという意味です。四つ目は、オントロジーの育ち方に関するものです。オントロジーは大聖堂ではなく、地図のように育ちます。実行可能最小限オントロジー（MVO）のアプローチは、「全体をすべて設計してから始める」方式と「統制なき実験」という誤った二者択一をいずれも退け、今必要なスキル一つに十分な分だけを定義したうえで、一つの配備が成功するたびに地図を一区画ずつ広げていきます。

そして最後に、すべての結論には系譜がなければなりません。数字は想像されるものではなく計算され、決定は即興ではなく根拠から導き出され、その過程全体が追跡可能な記録として残ります。監査人のどんな問いにも画面一つで答えられる状態 — それこそが規制産業でエージェントを運用できる条件であり、本書のすべての章は最終的にこの状態へと収束していきます。

旅程の地図：五つの章のつながり方

本文の五つの章は、それぞれ独立した解説であると同時に、一つの物語としてもつながっています。第1章では、ワシの解剖構造全体を鳥瞰しながら、判断が行動に先立ち、作ることと治めることが一対であり、すべての結論に系譜がなければならないという、フレームワークの文法を身につけます。第2章はその頭の中へ入り、オントロジーが定義され、補強され、検証される作業台と、その作業台が崩れないよう支える二重のハーネスを見ます。第3章は左の翼へと渡り、そうして言語化された業務がスキル・タスク・活動という三つの大きさのハーネスへと組み立てられ、判断の隙間と禁止線が数学によって磨き上げられたのち、試験飛行を経て出荷されるまでの工程をたどります。

第4章では、右の翼の舞台が開かれます。それまでの章が取っておいた二つの名前 — ハーネスの規格であるネクサスと、それを忠実に実行するミメーシス・エンジン — の正体が明らかになり、配備されたハーネスの中でエージェントが働き、監視され、認証される運用の日常が繰り広げられます。そして第5章で、このすべての構造がついに現場の机に触れます。法人融資増強ワークプレイスという実物を通じて、フレームワークが一人の担当者、審査役、リスク管理者の朝を実際にどう変えるのかを確認するのです。第6章は、この旅程で管理者が押さえておくべきことを、ロードマップと役割と指標の実行体系として改めてまとめます。

管理者が本書から得るもの

本書は、読者が読み終えた後、次の問いに自ら答えられるようになることを目標としています。

エージェンティックAI導入の課題が持ち込まれたとき、それがスキルの増強なのか、タスクの代行なのか、活動（ワークフロー）の自律運用なのかをどう見極めるか。オントロジー管理、カプセル承認、変更統制、認証更新といった新しい管理業務の担い手は誰であるべきか。増強段階の成果は何で測り、どのような記録が積み重なれば次段階の自律性を承認できるのか。そして監督当局や監査人を前にした「その決定はどのように下されたのですか」という問いに、組織はどのような構造で答えることになるのか。

各章の末尾には、当該領域を担う管理者が押さえるべき実践項目がまとめられており、第6章ではこれを一つの統合実践ガイドとして束ねています。

もちろん、一冊の文書が導入をめぐるすべての問いに答えられるわけではありません。ただし、フレームワークの言葉 — ハーネス、系譜、はしご、地図 — を組織が共有するようになるだけでも、議論の質は変わります。「AIを導入しよう」という漠然とした一文が、「どのスキルから、どの大きさのハーネスで、何を記録しながら始めよう」という具体的な一文へと変わること、それがこのエグゼクティブサマリーが願う第一の変化です。

本書の読み方

文書の構成

本書は六つの章と二つの付録で構成されています。

第1章「AOEDEイーグル：全体鳥瞰図」は、フレームワーク全体の解剖構造を扱います。ワシの各器官が何を意味するのか、能力カプセルとMVOアプローチがなぜこのアーキテクチャの中核的な設計判断なのかを説明します。時間の限られた読者は、この章だけを読んでも全体の骨組みを把握できます。

第2章「テオリア：判断する頭」は、オントロジーが定義され管理される作業環境を扱います。概念モデル・ジェネシス・セマンティック・ファクトリーという三つの柱、チームが日々使う画面群、システムが崩れないよう支える二つのハーネス、そしてデジタルツインへと至る段階的な旅路を説明します。

第3章「ポイエーシス：作る翼」は、ビジネスシナリオが配備可能なエージェントハーネスへと組み立てられる過程を扱います。活動・タスク・スキルというハーネスの三つの大きさと、ポイエーシスが組織に与える八つの能力を一つずつ見ていきます。

第4章「プラクシス：治める翼」は、配備されたハーネスが実際に働く運用の舞台を扱います。これまで取っておいた二つの名前 — ハーネスの規格であるネクサスと、それを実行するミメーシス・エンジン — が、ここで余すところなく明らかにされます。

第5章「CLAW：爪が地面に触れる」は、爪のサンプル実装である法人融資増強ワークプレイスを扱います。抽象的なアーキテクチャが現場担当者の朝の画面でどのような姿として現れるのか、そして「代替ではなく増強」という設計思想が採用戦略としてもなぜ正しいのかを説明します。

第6章「統合実践ガイド」は、五つの章の管理者向け実践項目を一つの運用モデルにまとめ、導入ロードマップと成果指標体系、よくある質問を整理します。

付録A「用語集」は、本文に登場する主要用語を管理者の言葉で解説し、付録B「五つの章を貫く文章」は、本文各所の中心的な文章を一か所に集め、その文脈と含意を振り返りました。

読者別おすすめの読み方

役員および意思決定者には、エグゼクティブサマリーと第1章、そして第6章の導入ロードマップをお勧めします。フレームワーク全体の論理と、組織が準備すべきことを把握するには十分です。

導入を検討する現場の部門長と中間管理職には全体を通読することをお勧めしますが、自身の役割に近い章を中心に深く読むこともお勧めします。オントロジーとナレッジ管理を担うなら第2章を、エージェントの設計と実装を担うなら第3章を、運用とリスク統制を担うなら第4章を、現場適用と変革管理を担うなら第5章を中心に据えてください。

実務担当者には、担当領域の章を精読したうえで、付録Aの用語集を手元に置きながら他の章を参照する読み方をお勧めします。

表記について

本文中、固有名称は初出時に原語を併記し、以降は日本語表記を用います（例：テオリア（THEORIA））。オントロジー、ハーネス、エージェントのように、すでに業界で通用している外来語はそのまま使用しますが、初出の箇所で意味を噛み砕いて説明します。各章の冒頭には当該章の要点をまとめた案内文が、末尾には管理者向けの実践項目が置かれています。

語源について

テオリア、ポイエーシス、プラクシスの三語はいずれも古代ギリシア哲学、とりわけアリストテレスが人間の活動を区分する際に用いた中心概念に由来します。AOEDEの命名がなぜ絶妙なのかも、この語源を知ればより明確になります。

テオリア（θεωρία, theoria）は、本来「見ること」「観照（かんしょう）」を意味します。語源的には「見物する、観察する」という動詞（theorein）に由来し、もともとは祭典や神託を見に行く使節の「見る」ことを指す言葉でした。アリストテレスにとってテオリアとは、何かを作ったり変えたりするためではなく、真理そのものを知るために世界を見つめる活動、すなわち純粋な思索と認識の生でした。彼はこれを人間の活動の中で最も高いものと見なしました。英語のtheory（理論）はここから生まれました。AOEDEにおいて、オントロジーを定義する「頭」にこの名を与えたのは、行動に先立ってビジネスをありのままに「見て知る」段階という意味と、正確に符合します。

ポイエーシス（ποίησις, poiesis）は「作ること」「制作」を意味します。「作る」という動詞（poiein）に由来し、英語のpoetry（詩）の語源でもあります — 詩人は言葉で何かを「作り出す」人であるという発想です。アリストテレスの区分において、ポイエーシスの特徴は、活動の目的が活動の外にある成果物にあるという点です。家を建てる行為の目的は、建てる行為そのものではなく、完成した家です。だからこそ、作る翼、すなわちハーネスという成果物を組み立てる場所にこの名が与えられました。

プラクシス（πρᾶξις, praxis）は「行うこと」「実践」を意味します。ポイエーシスと対比される概念で、目的が成果物ではなく、行為そのものとその行為をうまく成し遂げることにある活動です。政治、倫理的な生、共同体の中での正しい行いが典型的なプラクシスです。良い統治の産物は何かの「物」ではなく、うまく治められている状態そのものです。だからこそ実践には、フロネシス（phronesis）、すなわち状況の中で正しく判断する実践知が求められるとされました。運用と統制、ガバナンスという — 終わる時点がなく「うまく成し遂げること」自体が目的である — 治める翼に、この名が与えられた理由です。

三つの概念を一列に重ねてみると、アリストテレスは人間の活動を、知ること（テオリア）、作ること（ポイエーシス）、行うこと（プラクシス）に分けたことになり、AOEDEはその古典的な三分法を、エージェンティックAIのライフサイクル — 定義し、組み立て、運用する — にそのまま移し替えたものです。参考までに、ネクサス（nexus）はラテン語で「束ね、結びつき」を、ミメーシス（mimesis）はギリシア語で「模倣、忠実な再現」を意味し、五つの名前はすべて同じ古典語彙の系譜の上にあります。また、AOEDE（eii:di、発音：エイディ）は、ギリシアの音楽の女神の一柱である歌の女神であり、「ワシの歌」を意味します。

第1章. AOEDE イーグル（ワシ）：全体鳥瞰図

本章で扱う内容：エージェンティックAI導入における根本的な問いと、それに対するAOEDEの答え、ワシの比喩で表現された全体アーキテクチャの六つの構成要素、能力カプセルという実装単位、そして実行可能最小限オントロジー（MVO）という方法論的な核心。

1.1 一つの問いから始める

エージェンティックAIを企業に本格的に導入しようとする組織は、パイロットの高揚感が落ち着いた後、結局一つの問いの前に立たされます。自ら判断し行動するソフトウェアに、行動する自由と信頼できる規律をどのように同時に与えるか？

この問いが難しい理由は、二つの要求が互いに反対方向を指しているからです。自由のないエージェントは、既存のルールベース自動化と変わらず、導入する理由が失われます。逆に規律のないエージェントは、特に金融産業のように一つの意思決定のコストが資本規模で測られる産業では、組織が抱えきれないリスクの源になります。多くの組織がこの間で揺れています。ある組織は統制を理由に何も始められず、ある組織は速度を理由に統制なしで始めてしまい、最初の事故でプロジェクト全体を失います。

AOEDE（Agentic Ontology Envisioning and Deployment Environment）フレームワークは、この問いに一つのイメージで答えます。翼を大きく広げたワシです。

1.2 なぜワシなのか

この比喩は単なる装飾ではありません。飛行中のワシは、複数の部分が精緻にバランスを取ってこそ動く一つのシステムです。状況を判断する頭があり、必ず共に動かなければならない二つの翼があり、意図を実際の動きに変える胴体があり、そして最終的に獲物を掴む爪があります。どれか一つが欠けてもワシは飛べず、飛べたとしても何も掴めません。

AOEDEは、アーキテクチャの中核要素一つひとつをこの構造に対応させます。そしてその対応は、見つめるほどに明確な設計意図を明らかにします。判断が行動に先立つべきであること（頭）、作ることと治めることは一対であること（二つの翼）、すべての行動は統制を通過しなければならないこと（胸のベルト）、実行は忠実でなければならないこと（エンジン）、そしてこのすべての価値は結局、実際の業務を掴めるかどうかで評価されるということ（爪）です。

それでは、各器官を順に見ていきましょう。

1.3 頭：テオリア（THEORIA）— 判断が行動に先立つ

ワシの頭に当たるのが、オントロジーの座であるテオリア（THEORIA）です。

ここでいうオントロジー（ontology）とは、哲学用語ではなく実務用語です。私たちの業務領域にどのような対象（エンティティ）が存在するのか、それらは互いにどうつながっているのか、この領域における「意思決定」とは具体的に何を意味し、「根拠」はどのような形であるべきか — こうした問いへの答えを、コンピューターが理解できる構造で書き記したものがオントロジーです。簡単に言えば、私たちのビジネスの公式な地図であり、公式な辞書です。

AOEDEの原則は明確です。エージェントを作ったり、何らかの行動を自動化したりする前に、ビジネスモデル自体がまずこの明確な言語で定義されなければなりません。テオリアはまさにこの定義が行われる場所であり、フレームワーク全体の思考と判断が始まる概念的な中心です。

ワシが飛ぶ前にまず見るように、AOEDEではオントロジーが自動化に先立ちます。この順序を逆にすると、どのようなことが起こるでしょうか。オントロジーなしに動くエージェントは自律的なのではなく、単に責任を問えない存在にすぎません。そのエージェントが自らを何をしていると信じていたのか、どのような概念に基づいて判断したのかを、誰も説明できないからです。事故が起きたときに「なぜそのような判断をしたのか」に答えられないシステムは、規制産業では存在し得ないシステムです。

1.4 二つの翼：ポイエーシスとプラクシス — 作ることと治めること

二つの翼は、頭が見たものを実際の動きへと移し替えながら、意図的に互いに相反する役割を担います。

左の翼ポイエーシス（POIESIS）は「作る翼」です。ここでテオリアの理論モデルが、実行可能なコンポーネントへと変わります。概念が実際に動くエージェントになる、いわば組立ラインの領域です。重要なのは、この組み立てが職人の即興作業ではなく標準化された工程であるという点です。契約が導き出され、エンジンが組み立てられ、すべてのコンポーネントは頭で定義されたオントロジーに照らして検証されます。誰が作っても同じ規格の成果物が出るように、工程自体が設計されています。

右の翼プラクシス（PRAXIS）は「治める翼」です。デプロイされたエージェントの実行を監視・管理し、すべての行動が定義された範囲とコンプライアンス基準の中にとどまるよう保証します。作る側が「このエージェントはこのように働くことになっている」を定義するとすれば、治める側は「実際にそのように働いているか」を瞬間ごとに確認します。

この対称性は目新しい発明ではありません。うまく機能している組織であればすでに知っている原理 — 商品を作る部署とその商品のリスクを審査する部署が分離されつつも、同じ基準の上で働かなければならないという原理 — を、エージェントの世界に移し替えたものです。違いがあるとすれば、人間の組織ではこの分離が規定と会議によって維持されるのに対し、AOEDEではアーキテクチャによって維持されるという点です。

この対称性がフレームワークの核心です。統制なく作ることだけをする組織はリスクを大量生産し、作らずに統制だけをする組織は何も生み出せません。飛行には二つの翼が共に動くことが必要です。後述するように、AOEDEはこの対称性をスローガンにとどめず、工学的に実装します。二つの翼は同じサーバー、同じデータベースを共有する二つの顔であり、作る側が渡したものと治める側が受け取ったものの間に、翻訳も、複製も、食い違う隙間もありません。

1.5 胸のベルト：ネクサス・ハーネス

ワシの胸を横切り、盾をX字形に包み込むのがネクサス・ハーネス（NEXUS HARNESS）です。行動（Action）、統制（Control）、ガバナンス（Governance）から成る黄金のベルトであり、エージェントが安全かつ効果的に動作することを保証する中核的な制御層です。

ここで「ハーネス（harness）」という言葉について触れておきます。ハーネスとは、馬や牽引動物に装着する馬具を意味します。馬具は動物をつなぎ止める鎖ではありません。動物の力が馬車を引く方向にのみ伝わるようにする、力と方向を結びつける装置です。AOEDEがこの言葉を選んだ理由はまさにそこにあります。エージェントの知能を抑え込むのではなく、その知能が組織の許した方向にのみ発揮されるように編まれた構造物 — それがハーネスです。

X字の形にも意味があります。行動と統制は順を追って通過する段階ではなく、システムの心臓の上で互いにぴんと張り合う交差した帯です。行動が大きくなれば統制も共に締まり、統制が行動を失えばベルト全体が緩みます。そしてガバナンスは、その緊張を留めるバックルです。エージェントが行うすべてのことはこのハーネスを通過し、ハーネスが説明できないことはエージェントも行いません。

1.6 胴体のエンジン：ミメーシス・エンジン

ワシの中央、ハーネスの下ではミメーシス・エンジン（MIMESIS ENGINE）が作動します。ネクサスを実行するために設計された実行ドライバーであり、フレームワーク運用の動力源です。

この名前は慎重に選ばれました。ミメーシス（mimesis）とは「忠実な再現」を意味します。このエンジンは結果を作り上げたりしません。オントロジーが定義した内容を、ハーネスが許容する範囲の中でそのまま実行するだけです。数字は想像されるのではなく計算され、決定は即興で下されるのではなく根拠から導き出されます。

この点において、生成AIに対するよくある懸念 —「もっともらしく作り上げた答えを出すのではないか」— に対するAOEDEの姿勢が明らかになります。創造性が必要な場と忠実さが必要な場を区別し、実行の心臓部には忠実さのみを置くということです。このエンジンが強力である理由は、逆説的にも、指示された通りにのみ正確に動くからです。

1.7 爪：AOEDE CLAWS — 実際のビジネスを掴む

ワシの構造は結局、爪が何を掴めるかによって評価されます。どれほど精緻な頭と翼を備えていても、爪が虚空しか掴めなければ、そのワシはビジネスに何ももたらしません。AOEDE CLAWSは、フレームワークが実際のビジネスと出会う接点です。フロントオフィスと顧客関係、すなわちCRMと営業環境に直接適用され、収益と顧客エンゲージメントを生み出します。

左の爪は専門金融サービスを担当します。企業向け融資、貿易金融、キャッシュマネジメントのように複雑性が高く、判断の根拠が契約文書にあり、統制されない意思決定のコストが資本規模で測られる領域です。右の爪は顧客側面を担当します。顧客管理、資産管理、そして包括的リスク管理のように、その実体が関係とポートフォリオ、日々変動するエクスポージャーである領域です。

二つの爪の性格が異なるという点も注目に値します。左は文書と契約が根拠の中心となる世界であり、右は関係と時系列データが中心となる世界です。一つのフレームワークが、性格の異なる二つの世界を同じ原理 — オントロジー、ハーネス、忠実な実行 — で掴めるのか。CLAWSはその検証の舞台でもあります。

接点の位置をフロントオフィスに定めたことにも理由があります。バックオフィスの自動化はコストを削減しますが、フロントオフィスの拡張は収益と顧客体験を直接動かします。そしてフロントオフィスこそ判断の密度が最も高い場所 — 毎日数十件の照会と比較、優先順位付けが行われる場所 — であり、系譜と統制を備えたエージェントの価値が最も早く実感される地形でもあります。爪が最初に触れる場所が、組織がフレームワークの価値を初めて実感する場所になるわけです。

1.8 能力カプセル：比喩がエンジニアリングになる地点

CLAWは能力カプセル（capability capsule）を基盤として実装され、まさにこの地点でワシの比喩がエンジニアリングの現実となります。

能力カプセルとは、それ自体で完結し、ガバナンスが組み込まれた能力単位です。各カプセルには、業務ドメイン知識パックとスキルパックをはじめ、次の七つの要素が収められています。

第一に、ゴールドスタンダード・レポートです。このスキルが生み出すべき成果物の合格基準としての役割を果たす模範的な産出物であり、カプセルのすべての構成要素はこの基準に向かって整列します。第二に、エンティティモデルとデータ契約です。このスキルが用いるビジネス上の意味に従って、データが何であり、どのような形であるべきかを正確に記述します。第三に、ソリューションツリーです。結論がどのような過程を経て導き出されるかを記録し、答えだけでなく答えに至る道筋そのものを検討可能にします。第四に、決定論的計算エンジンです。すべての数値を生み出す計算装置であり、同じ入力には必ず同じ出力が得られます。第五に、シグナルとギャップ検知器です。カプセルが自らの状態を監視し、異常と隙間を知らせます。第六に、回帰テストフィクスチャです。変更があるたびに既存の品質が維持されているかを自動的に判定し、デプロイの可否を見極めます。

そして第七が特に重要です。人間の判断と学びが検討可能な形で残るように用意された明示的なスロットです。業務ルールを収める意思決定テーブル、承認者が直接値を入力するガバナンスパラメータ、まだ存在しないモデルに対する機械学習要件フックがそれに当たります。人間の介入が必要なとき、その介入は場当たり的なものではなく、最初から設計された場所で行われます。

このように見ると、各能力カプセルは縮小された一羽のワシです。ゴールドレポートはテオリアの意図が具体化されたものであり、カプセルの組み立てはポイエーシスの作業であり、監査と承認はプラクシスの実行であり、ランタイムフックと閾値はぴんと締められたネクサス・ハーネスであり、エンジンは定められた通りに正確に実行するミメーシスです。最も小さな単位の中に全体の原理が完結した形で収められているからこそ、それらを積み上げたより大きな構造も崩れないのです。

1.9 MVOアプローチ：掴むたびに育つオントロジー

CLAWの実装において最も重要な設計上の決定は、技術ではなく方法論です。AOEDEは実行可能最小限オントロジー（MVO, Minimum Viable Ontology）アプローチを採用します。その理由は、エージェンティック・オントロジーのアプローチ手法が、全面的・全社的な革新を志向するよりも、小さく始めて試行錯誤と段階的な移行を推奨するものだからです。AIエージェント技術がまだ発展途上にあり、LLMもまた発展過程にあるため、全面的かつ同時的に推進するにはリスク要因が多いためです。

1.9.1 なぜ「すべてを設計し尽くす」は失敗するのか

エンタープライズAIの失敗事例を見ると、最初の能力を完成させる前に企業全体をモデリングしようとしたオントロジープロジェクトが少なくありません。数百人へのインタビュー、数千ページに及ぶ定義文書、そして完成する前に陳腐化してしまった数年がかりの取り組みです。ビジネスはオントロジーのモデリングが終わるのを待ってはくれず、完成した瞬間のモデルは、すでに昨日のビジネスを描いています。

MVOはその順序を逆転させます。「私たちのビジネスの完全なオントロジーとは何か？」を問う代わりに、「この一つの中核能力、スキルを信頼できるものにするために必要な最小限のオントロジーとは何か？」を問います。すなわち、目的地がオントロジーを引き寄せて存在させる方式です。

1.9.2 最小限はどのように決まるのか

具体的には、各能力カプセルは自分自身の最小オントロジーを持ちます。その範囲は、ゴールドレポートと能力カプセルが目指す目標が実際に要求するエンティティ、属性、関係、業務ルール、ガバナンスパラメータ — ちょうどそれだけであり、それ以上でもそれ以下でもありません。

例えば、グループ伝播リスクマッピング能力カプセルには、グループ構造、関係会社間のつながり、エクスポージャー上限に関するエンティティのみが必要です。離反リスク評価能力には、口座残高、保有商品、接触・相互作用の履歴、収益レコードのみが必要です。各能力カプセルにおいて、スキルは銀行全体の地図ではなく、自らの目的地までの道の地図のみを要求します。

それでは、目的地がまだデータに存在しない何かを要求するときはどうするのでしょうか。例えば、ゲージチャートに必要な許容限度や、軌跡分析に必要な遷移モデルがまだない場合は？ このときオントロジーは決して捏造することなく、宣言によってその場所を守ります。承認者が埋めるパラメータスロットが作られたり、チームが構築すべきモデル要件が明示されたりし、その値が準備されるまでは決定論的フォールバック（安全なデフォルト動作）がその場所を守ります。ないものをあるふりをするのではなく、ないという事実そのものを管理可能な形で登録するのです。

1.9.3 断片が地図になる仕組み

このようにして全社オントロジーは、ワシの握力が強まる方式そのままに — 爪一本、能力カプセル一つ、デプロイ一つずつ — 段階的に作られていきます。CLAWの中にカプセルが積み重なるにつれて、それぞれの最小オントロジーが重なり合い始めます。離反顧客把握能力カプセルの「顧客」エンティティが、融資能力カプセルの「債務者（obligor）」エンティティと出会う瞬間が訪れます。この二つを調整する作業は、もはや机上の空論的なモデリング作業ではなく、実際の根拠に裏付けられた小さな整理作業になります。二つの能力カプセルがすでに現場で検証されているため、調整の基準もまた現場にあります。

テオリアは、あらかじめ建てられた大聖堂ではなく、実際に飛行してみた領土から組み立てられる生きた地図となります。頭が爪から学ぶのです。

1.10 鳥瞰図をチェックリストとして読み替える

この鳥瞰図は鑑賞用の絵ではなく、そのままチェックリストとして使うことができます。何らかのエージェンティックAI課題が机の上に上がってきたとき、ワシの器官を一つずつ指し示しながら、六つの問いを投げかけてみるのです。

まず頭から問います。この課題が扱う業務領域の対象と関係と判断基準が、担当者の頭の中ではなく検討可能な言語で定義されているか。次は左の翼です。エージェントが作られる過程が個人の即興ではなく標準化された工程に従っており、その産出物がオントロジーに照らして検証されているか。右の翼に移り、作られたものがデプロイされた後も監視され、変更が統制され、定義された範囲を逸脱しないよう治められているか。胸のベルトについては、エージェントのすべての行動が統制とガバナンスの層を通過しているか、それとも迂回路が開かれていないかを問います。胴体のエンジンについては、数字と結論が作り上げられるのではなく計算され導き出されているか、その過程が再現可能かを問い、最後に爪については、この構造すべてが結局、現場のどのような実際の業務を掴むのか、その効果を誰の一日の中で確認できるのかを問います。

六つの問いのうちどれか一つでも答えが空白であれば、その空白こそがプロジェクトのリスクが潜む場所です。オントロジーなしに始めた課題は、事故が起きたときに説明する言葉を持たず、統制なしにデプロイされたエージェントは律儀に間違った道を進み、爪のない構造はどれほど精緻であっても、成果報告書に書く文章がありません。続く章では、この六つの問いそれぞれに対してAOEDEが用意した答えを、画面と規律のレベルまで踏み込んで示していきます。

1.11 第1章のまとめ

これがAOEDEイーグルの静かながらも根本的な差別化ポイントです。「巨大な事前設計」と「統制なき実験」という誤った二者択一を拒むこと。フレームワークの処方を五つの文に凝縮すると、次のようになります。

見える範囲だけオントロジーを定義してください。行動できる範囲だけエージェントを作ってください。すべての行動を統制とガバナンスにつなぎ止めてください。エンジンには忠実に実行させ、爪には実際の業務を掴ませてください。そしてワシが実際に掴む方法を学んだ分だけ、オントロジーを育ててください。

続く四つの章では、この鳥瞰図の各器官の内側へと入っていきます。第2章では頭（テオリア）が実際にどのような画面と規律で構成されているかを、第3章では左の翼（ポイエーシス）がハーネスを組み立てる八つの能力を、第4章では右の翼（プラクシス）の運用の舞台とともにネクサスとミメーシスの正体を、そして第5章では爪（CLAW）が実際の企業向け融資業務の現場に触れた姿を見ていきます。

第1章の要点：AOEDEは、判断（テオリア）、制作（ポイエーシス）、統制（プラクシス）、制御層（ネクサス）、忠実な実行（ミメーシス）、現場接点（CLAWS）の六つの要素から成る一つのシステムである。実装単位はガバナンスが組み込まれた能力カプセルであり、方法論の核心は、目的地が要求する分だけオントロジーを定義し、デプロイの経験によってそれを育てていくMVOアプローチである。

第2章. テオリア：判断する頭

本章で扱う内容：オントロジー・フレームワークの三本柱（コンセプトモデル、ジェネシス、セマンティック・ファクトリー）、チームが日々作業する画面群、システムを崩壊させないように支える二つのハーネス（モデルハーネスと実行ハーネス）、そしてジェネシスから出発し、デジタルツインを段階的に構築していく旅程。

2.1 テオリア・オントロジー・アーキテクチャ

オントロジーを導入しようとする組織が最初に受ける反問はこれです。「そのモデルは何を根拠に正しいと言えるのか？」担当者一人の頭の中から生まれたモデルであれば、その人が異動する瞬間にモデルの権威も一緒に去ってしまい、コンサルタントが描いてくれたモデルであれば、プロジェクトが終わった瞬間から古びていきます。テオリアのオントロジー・アーキテクチャは、この反問に構造で答えます。上には国際標準の系譜に錨を下ろし、中央には会社のビジネスモデルという単一の真実の源泉（single source of truth）を打ち立て、下にはその真実の源泉を異なる観点から検証する二つの証拠ストリームを流します。上の錨は「このモデルは正しい方法で記述されているか」を担保し、下の二つのレンズは「このモデルは意味の次元において、そして運用の次元において現実と一致しているか」を絶えず問い続けます。そして、この問いにおいてずれが発見される瞬間こそが、このアーキテクチャの真の設計意図が現れる瞬間です — ギャップは事故ではなくシグナルであり、判定を経てどちらか一方の改善を引き起こす引き金なのです。

本書はその構造を五つのステップで歩みます。標準の基礎（MOF）、日陰から導くシャドー・オントロジー（メタフレームワーク）、日向の真実の源泉（会社のビジネスモデルとオントロジー）、二つの証拠レンズ（セマンティクス・ストリームとデータ・ストリーム）、そしてギャップの判定と価値優先の運用戦略です。

2.1.1 出発点：MOF、標準から受け継いだ基礎

物語の最上位にはMOF（Meta Object Facility、メタオブジェクトファシリティ）があります。MOFは国際標準化機構であるOMG（Object Management Group）が制定したメタモデリング標準であり、OMGのMDA（Model Driven Architecture、モデル駆動アーキテクチャ）体系の最上位基盤を成しています。テオリアが独自に考案した概念ではなく、ソフトウェア産業が数十年かけて磨き上げてきた標準を継承したものです。

MDAとMOFの核心的な洞察は、モデルにも階層があるということです。一番下に現実のデータがあり、そのデータの構造を定義するモデルがあり、そのモデルの記述方法を定義するメタモデルがあり、一番上にメタモデル自体を記述する基盤層 — MOF — があります。階層を混同しないこの規律が、後述する「定義的な問いとインスタンスの問いの区別」にまでつながる、このアーキテクチャ全体の背骨です。

管理者にとって、この出発点が意味するところは明確です。テオリアのオントロジーは、どこかの個人の発明の上にではなく、業界が検証したメタモデリング標準の系譜の上に立っています。「その方法論の根拠は何か」という監査人の問いに対して、担当者の経歴ではなく国際標準の名において答えられるということです。もちろんテオリアはMOFの階層的思考を継承しつつ、ビジネスオントロジーの目的に合わせて再解釈しています — 何を受け継ぎ、何を変形したのかを明示することこそが、標準の権威を借りる正しい方法です。

2.1.2 シャドー・オントロジー：日陰から導くメタフレームワーク

MOFに基づいて構築されるのがメタ・ビジネスモデル・フレームワークです。業務対象・エンティティ・属性・活動・タスクといったメタオブジェクトが「どんな会社のモデルでも収められる文法」を宣言する層であり、一文で要約すれば会社についての知識ではなく、会社についての知識を記述する方法についての知識です。

しかし、この層の戦略的な正体を正確に押さえておく必要があります。メタ・ビジネスモデル・フレームワークは特定の会社に依存しない（company-agnostic）上位オントロジーです。それ自体はどの会社の実際のオントロジーでもありません。しかし、まさにそれゆえに、あらゆる会社のオントロジーに対してシャドー・オントロジー（shadow ontology）として機能できるのです。シャドー・オントロジーの役割は二つあります。

第一はモデリングのガードレールです。会社のビジネスオントロジーがどのチームによってどのような順序で構築されようとも、その作業はシャドー・オントロジーが予め用意した完結した上位構造の導きを受け、軌道を外れることがありません。ボトムアップで育つモデルが混乱に陥らない第一の理由がここにあります。

第二は意味の浄化装置（semantic purifier）です。ユーザーが自然言語で質問を投げかけるとき、その質問に含まれる概念はまずシャドー・オントロジーの語彙に照らして解釈され、精錬されます。会社のオントロジーにまだ定義されていない概念が質問に登場したとしても、上位構造がそれを受け止める概念的なセーフティネットを提供するのです。

この戦略の妙味は、日陰と日向の関係にあります。シャドー・オントロジーは完結した上位構造として日陰にとどまり、会社のスコープ・オントロジーがMVOアプローチによって定義される分だけ、その概念が日向へと現れます。つまり、完全性は日陰に予め備えられており、実在性は日向で一区画ずつ稼ぎ取っていく構造です。全体を事前にすべて構築することなく、それでいて全体の導きを受けること — 「壮大な事前設計」と「統制なき実験」という誤った二者択一を拒否する本書の原則が、この日陰と日向の分業によって実現されています。

2.1.3 日向の真実の源泉：会社のビジネスモデルとオントロジー

シャドーの導きのもと、日向で構築されるのが会社のビジネスモデルです。会社の商品と顧客セグメント、チャネル、業務領域と業務対象が、メタフレームワークが定めた文法の中で精錬され具体化され、それがコンピュータが理解し答えられる形に確定されたものがビジネスモデル・オントロジーです。

ここで、このアーキテクチャの第一原則が宣言されます。会社のビジネスモデルが単一の真実の源泉です。下から上がってくる二つの証拠ストリームは、真実の源泉と競合する別の真実ではなく、真実の源泉を異なる観点から検証するレンズです。セマンティクス・ストリームは意味の観点（semantic perspective）から、データ・ストリームは運用の観点（operation perspective）からビジネスモデルを照らし出します。真実は一つであれど検証は二つ — この非対称性が、後述するギャップ判定メカニズムの前提となります。

第一のレンズ：セマンティクス・ストリームとセマンティック・ファクトリー

第一の証拠レンズはセマンティクス（semantics）です。このレンズの表現形式は概念明確化（concept clarification）です。私たちのドメインにおいて「顧客」と「借主」は同じものの異なる呼び名なのか、「融資」は「金融商品」の下位概念なのか、互いに排他的だと宣言した二つの概念を同時に継承する矛盾はないか — 概念エディタと内蔵された推論エンジンが、こうした問いに論理的に検証された答えを確定していきます。これは用語集を作る作業ではなく、論理的に検証される語彙体系を打ち立てる作業です。

明確化された概念の根拠は、セマンティック・ファクトリーのセマンティック・オントロジーが供給します。セマンティック・ファクトリーは規程集や契約書、業務マニュアルといった実際の文書を読み込み、エンティティ・事実・関係を抽出し、すべての項目にどの文書のどの箇所から得られたかという出典を紐づけて蓄積します。原文に根拠が見当たらない項目は、忠実性ゲートで却下されます。このように文書から育った知識の体系がセマンティック・オントロジーであり、会社のオントロジーとは別に管理されながら、定期的に照合されます。文書には登場するがモデルには存在しない概念、文書が語る関係とモデルが宣言した関係が食い違う箇所が、矛盾検知によって表面化します。要するにこのレンズは「私たちのモデルは、私たちが記述した意味と一致しているか」を問うのです。

2.1.5 第二のレンズ：データ・ストリームと運用の実体

第二の証拠レンズはビジネスオブジェクトとデータインスタンスです。概念が意味を扱うのに対し、このレンズは構造と実体を扱います。各業務対象が所有するビジネスオブジェクトモデルが、その領域のエンティティ・属性・関係を構造として宣言し、その構造の実在性を、実際のデータベースに記録された行 — データインスタンス — が保証します。

階層の規律はここでも守られます。「紛争処理には何個のエンティティが定義されているか」はビジネスオブジェクトモデルが答えるべき定義的な問いであり、「紛争案件が現在何件溜まっているか」はデータインスタンスが答えるべき問いです。二つの平面を厳密に区別しつつ上下でつなぐこと、それが正確な答えともっともらしい誤答とを分ける違いです。このレンズが問うのは「私たちのモデルは実際に起きている運用と一致しているか」です。

ギャップの二つの顔と判定：リスクが表面化する仕組み

ここからがこのアーキテクチャの心臓部です。二つのレンズの問いにおいてずれ — ギャップ（gap） — が発見されると何が起こるのか。核心は、ギャップの種類によってその意味と処理経路が異なるという点にあります。

セマンティクスの証拠とビジネスモデルの間のギャップは、改善の機会です。文書が語る概念とモデルが宣言した概念が食い違っている場合、どちらが古びているのかは決まっていません。モデルが現実に追いついていない場合もあれば、規程文書が改訂を見落としている場合もあります。したがってこのギャップの判定は「どちらを直すか」という双方向の問いであり、どちらを直すにせよ組織の知識は一歩精錬されます。

ビジネスモデルとデータ・ストリームの間のギャップは、コンプライアンス案件です。モデルは組織が「こうすることにした」と宣言したものであり、データは「実際にこうした」という記録です。両者のずれは、定義上、宣言と実行の不一致であるため、開かれた調整としてではなく、コンプライアンスの言葉 — 原因究明、是正、必要に応じたエスカレーション — で扱わなければなりません。

どのギャップであれ、識別された瞬間に判定（verdict）が下され、その判定はどちらか一方の改善を引き起こす引き金となります。このメカニズムの真の価値は、個別のギャップの修正そのものではなく、その先にあります。ほとんどの組織において、ビジネスはかなりの部分が暗黙知の上で回っており、「規程と実務が違う」という事実は事故が起きてから初めて発見されます。このアーキテクチャでは、それが常時検知されるシグナルになります。暗黙のうちに潜んでいた潜在リスクが、運用の最中に構造的に表面化すること — ギャップ判定メカニズムは、オントロジーを文書化ツールからリスク早期発見装置へと格上げします。最後のピースとして、判定の主体とエスカレーション経路 — 特にコンプライアンス・ギャップを誰が判定し、どこに上げるのか — を組織の役割表に明示しておくことで、このメカニズムの信頼性は完成します。

価値優先のギャップ縮小：持続可能な運用戦略

ギャップの発見が積み重なると、自然な問いが続きます。これらのギャップを減らす努力に、どれだけを、いつ費やすのか。このアーキテクチャが選んだ答えは正直です。ビジネス価値の実現が先であり、実現した価値の一部をギャップ縮小のコストとして配分します。

理想的には完全な整合性を先に確保したいところですが、その順序は現実には持続しません。多額の予算をかけてビジネスオントロジーを構築しても、ビジネスの実現が伴わなければ、組織はギャップを減らそうとする関心そのものを急速に失います。反対に、ユーザーがオントロジーの価値を実際のビジネスケースとして実感すれば、不整合を減らそうとする努力は自ずと精力的になります。ギャップ縮小の努力は、ビジネス価値の回収に比例して大きくなります。したがって、価値を先に実現し、その回収分で整合性を買い取る戦略は、最善（best）ではないとしても持続可能な次善（better）です。これはMVOの経済学とまったく同じリズムでもあります — オントロジーが目的地に引かれて育つように、整合性管理も価値に引かれて育つのです。調整の予算ではなく、調整の動機を設計する方式なのです。

日陰の導き、日向の真実、二つのレンズの問い

アーキテクチャ全体をもう一度たたんでみましょう。上から下へは定義の系譜が流れます。国際標準MOFがメタフレームワークの基礎となり、そのフレームワークはシャドー・オントロジーとして日陰から会社のオントロジー構築を導き、日向では会社のビジネスモデルが単一の真実の源泉として確定されます。下から上へは二つの証拠レンズの問いが上がってきます。セマンティクス・ストリームが意味の一致を、データ・ストリームが運用の一致を検証し、発見されたギャップは改善の機会あるいはコンプライアンス案件として判定され、どちらか一方の改善を引き起こします。そして、その改善の努力は実現されたビジネス価値によって調達されます。

管理者にとって、この構造が与えてくれるのは点検の言語です。オントロジーの品質が疑わしいときに投げかける問いが、四つの方向に整理されます。文法に沿って記述されているか（標準への係留）、シャドーの導きを受けているか（上位構造）、文書の意味と食い違っていないか（セマンティクスのレンズ）、運用の実体と接しているか（データのレンズ）。この四つの問いすべてにシステムが答えを持っているなら、そのオントロジーは信頼してよく、いずれかが空いているなら、その空白こそが次に補強すべき領域です。オントロジーの信頼とは宣言ではなく、日陰の導きと日向の真実と二つのレンズの問いが日々維持されているという事実そのものなのです。

2.2 青写真が画面になる瞬間

私たちはワシの解剖構造を見てきました。判断する頭、創り治める二つの翼、胸を締めるハーネス、忠実に実行するエンジン、そして実際のビジネスを掴む鉤爪。その物語において頭に該当するのが、オントロジーの座、テオリアでした。「自動化に先立ち、ビジネスがまず言語化されなければならない」という原則のことです。

これから見ていくのは、その原則の実物です。AOEDE-テオリア・クライアントは、その「頭」を私たちのチームのブラウザの中に持ち込んだウェブアプリケーションであり、その背後でオントロジーを実際に保管し検証し回答するのがAOEDEオントロジー・サーバーです。

本章は二つの層を同時に扱います。画面上で何をするかだけでなく、その画面の裏側でどのような規律が働いているかまで扱います。管理者がシステムを信頼するためには、後者を知る必要があるからです。画面は変わり得ますが、規律はアーキテクチャであり、導入の意思決定の根拠とすべきなのは規律の側です。

物語は五つの大きな流れで進みます。第一に、オントロジー・フレームワークを成す三本の柱 — コンセプトモデル、ジェネシス、セマンティック・ファクトリー — それぞれの意味と、これらが会社のビジネスオントロジーと結ぶ連携。第二に、そのフレームワークの上でチームが日々作業する画面群 — 作業スペース、ダイアグラムエディタ、補強、顧客価値実現。第三に、この全体を崩壊させないように支える二つのハーネス — オントロジー・モデルハーネスとAIエージェント実行ハーネス。第四に、ジェネシスから出発して段階的にデジタルツインを構築していく旅程とそのナビゲーションマップ。最後に、管理者が押さえておくべき事項です。

2.3 三本の柱と一つの循環

テオリアのサイドバーにはコンセプト・オントロジー、ビジネス・オントロジー、セマンティック・ファクトリーが並んで配置されています。初めて見る人にはどれも似たような知識メニューに見えますが、この三つは異なる層で異なる仕事をしており、その関係を理解することがテオリア全体を理解する近道です。

結論から言えばこうです。コンセプトモデルは文法であり、ジェネシスは種であり、ビジネス・オントロジーは私たちの会社という文であり、セマンティック・ファクトリーはその文が現実と一致しているかを照合する証拠保管庫です。この一文を覚えておいていただければ、以下の詳細がすべてこの一文の注釈であることがお分かりいただけるはずです。

2.3.1 二段階モデル：メタオントロジーと会社オントロジー

サーバーの基礎設計文書が「これを誤解すると、その上のすべての階層が誤る」と釘を刺している概念があります。オントロジーは一つの層ではなく二つの層であるということです。

上層はメタオントロジーです。「業務対象」「エンティティ」「属性」「活動」「タスク」といった、名前の前に`#`が付くメタオブジェクトの世界です。九つのメタ・ビジネスオブジェクトモデル（実体関連モデル）ダイアグラムが一つに連結され、「どんな会社のモデルでも収められるものの文法」を宣言します。例えば「一つの業務対象は複数のエンティティを持つ」「事業部門は顧客セグメント、商品群、独立したチャネル群を持つ」といった関係とカーディナリティ（連結の個数の規則）がここで定められます。この層は会社についての知識ではなく、会社についての知識を記述する方法についての知識です。

下層が会社オントロジーです。例えば「紛争処理」という私たちの会社の業務対象は、二つの顔を同時に持っています。一つはメタオブジェクト「#業務対象」のインスタンスとして、データベースに記録された一行であるという顔であり、もう一つは自分自身のビジネスオブジェクトモデル・ダイアグラム — 紛争案件、紛争調査といった自らに属するエンティティを定義したモデル — を所有する一つのモデルであるという顔です。つまり「紛争処理」はメタダイアグラムと構造的に同じ種類の存在でありながら、一方は`#`が付いたフレームワークで、もう一方は会社の実物であるという違いがあるだけです。

管理者にとってこの区別が重要な理由は、問いの種類が分かれるからです。「紛争処理には何個のエンティティが定義されているか？」はモデルについての定義的な問いであるため、紛争処理自身のビジネスオブジェクトモデルで答えるべきであり、「紛争案件が今何件溜まっているか？」はインスタンスの問いであるため、データ行で答えるべきです。サーバーはこの二つの平面を厳密に区別します。設計文書の表現を借りれば、この階層規律が「正確な答えと、もっともらしく見える誤答との違い」を生み出します。実際、過去の誤答事例は例外なく、この二つの平面を混同したことから生じたと記録されています。

2.3.2 コンセプトモデル：言語の言語を磨く場所

コンセプト・オントロジー（ジェネシス・コンセプトエディタ）は、この文法層を直接編集する作業台です。画面ではコンセプト（concept）とその間の上位下位（IS-A）関係、OWLスタイルの属性、分類スキーム、そしてコンセプトと動詞の連結を扱います。私たちのドメインにおいて「顧客」と「借主」は同じものの異なる呼び名なのか、「融資」は「金融商品」の下位概念なのか、「リスク」という言葉はどの分類体系の下に置かれるのか — こうした問いへの答えを確定する場所です。

こうした問いが些細に見えるならば、用語のずれが組織にもたらすコストを思い浮かべてみてください。部署ごとに「顧客」の定義が異なり、報告書の数字が合わない事態、同じ指標を異なる名前で二重に管理する事態 — 人の組織でも高くつくこの混乱が、エージェントの世界では直ちに誤った自動判断につながります。

ここで注目すべきは、エディタの中に推論エンジン（reasoner）が内蔵されているという点です。保存ボタンを押して終わりではなく、サーバーがコンセプトグラフ全体を検査します。上位下位関係に循環が生じていないか（AがBの下位で、BがまたAの下位であるという矛盾）、互いに排他的（disjoint）と宣言された二つの概念を同時に継承する概念はないか、直接宣言してはいないが論理的に導かれる上位下位関係は何か。検査結果は、一貫性の有無、推論された関係の提案、充足不可能なクラスの一覧、同値グループとして整理され、画面に表示されます。

要するにコンセプトモデルは「用語集」ではなく論理的に検証される語彙体系であり、すべての修正はリビジョン履歴として残ります。

もう一つ、ガバナンス上の詳細にも触れる価値があります。コンセプトモデルは、ログインしているリポジトリのセッションに紐づいて保存されます。以前はクライアントがリポジトリ名を指定できたため、他のリポジトリのコンセプトモデルに触れられる隙がありましたが、サーバーのパッチによってセッションが唯一の権限となるよう塞がれました。小さな変更に見えますが、「誰がどの地図の文法を修正できるのか」という問いに、システムが構造的に答えられるようになったということです。概念を明確にする作業は容易な過程ではありません。多様なステークホルダーの業務要求に合わせて、全員が同意する意味として定義することは骨の折れる仕事です。コンセプトエディタでは、概念の分類、説明、そして関係にGenus（類）-Differentia（種差）-Species（種）を反復的に適用することで、一貫性があり重複のない固有の定義ができるようにし、概念定義の速度を飛躍的に短縮します。

2.3.3 ジェネシス：オントロジーの種子であり運搬形式

ジェネシスは二つの顔を持つ名前です。一つは先ほど見たコンセプトエディタの名前であり、もう一つはジェネシス・パッケージ — 業務対象定義とビジネスオブジェクトモデル・ダイアグラムを収めた移植可能なファイル形式です。この二つは偶然同じ名前を使っているのではありません。創世記（ジェネシス）というその名の通り、新しいオントロジーの世界が生まれる地点が、まさにここだからです。

流れは双方向です。出ていく方向では、よく磨き上げられたリポジトリの業務対象をジェネシス・パッケージとしてエクスポートできます。サーバーが該当リポジトリのビジネスオブジェクトとダイアグラムをまとめて一つの圧縮ファイルとしてストリーミングしてくれ、名前とバージョンがファイル名に刻まれます。入ってくる方向では、ジェネシス・パッケージから新しいリポジトリをブートストラップします。ファイルをアップロードし、会社名と管理者アカウントを指定すると、サーバーが業務対象とビジネスオブジェクトモデル・ダイアグラムを取り込み、メモリ内オントロジーと依存関係グラフを構築し、リポジトリは即座に使用可能な状態になります。すなわち、新しいビジネスオントロジーに基づくデジタルツインの世界が創造されるのです。

この双方向性が意味するところを管理者の言葉に置き換えるとこうなります。検証されたオントロジーは複製可能な資産になります。ある事業部で磨き上げられた与信ドメインのモデルをパッケージとしてエクスポートし、別の法人のリポジトリを開く種として使うことができ、パイロット・リポジトリで実験した構造を本番リポジトリへ移すこともできます。第1章で述べたMVO — 目的地が要求する分だけの最小限のオントロジーから始める — が実務で可能なのは、その「最小限」を収めて運ぶ規格化された器があるからです。だからこそ、MVOによるAIエージェントの適用は即座に効果を見せ、体系的な持続性を持つのです。

2.3.4 セマンティック・ファクトリー：文書の世界とモデルの世界をつなぐ橋

第三の柱であるセマンティック・ファクトリーは性格が異なります。コンセプトモデルとビジネス・オントロジーが人が意図的に設計する世界であるならば、セマンティック・ファクトリーは文書の山から知識を掘り出す工場です。画面の説明文がその性格を要約しています — 「文書添付から蓄積された知識です。」

内部動作はこうです。ウィキに添付された文書（規程集、契約書、業務マニュアルなど）をセマンティック分析の対象に指定すると、サーバーのビルダーがバックグラウンドで文書を読み込み、知識を抽出します。抽出単位は三つです。

第一に、文書が言及するエンティティです。各エンティティごとにページが作られ、新しい文書が入ってくるたびにそのページが累積的に充実していきます。第二に、エンティティに付随する事実です。すべての事実には、どの文書のどの箇所から得られたかという出典が必ず紐づきます。第三に、エンティティ間の関係トリプルです。文書の原文表現を保存しながら、自ら維持する関係語彙辞書に正規化されます。

抽出過程には忠実性ゲートがあります。原文に根拠が見当たらない — すなわちモデルが作り出した — 項目は保存される前に却下され、却下件数はログに残ります。AIが文書を読み込む一方で、AIの想像が知識ベースに入り込めないよう、門番が立っているのです。

そして、決定的な層がもう一つあります。矛盾検知です。セマンティック・ファクトリーが文書から発見したエンティティと関係は、オントロジーのエンティティとは別に管理されますが、システムはこの二つを定期的に照合します。文書には登場するがオントロジーには存在しない概念、文書が語る関係とオントロジーが宣言した関係が食い違う箇所 — これらが人がレビューすべき発見事項として整理されます。

ここで三本の柱のつながりが完成します。コンセプトモデルが文法を定め、ジェネシスがその文法に沿った構造を種として植えてビジネス・オントロジーを打ち立てると、セマンティック・ファクトリーは現実の文書がそのオントロジーと一致しているかを継続的に監視します。オントロジーが現実より先を行けば（宣言されたが証拠のない概念）それが見え、現実がオントロジーより先を行けば（文書にはあるがモデルにはない概念）それも見えます。第1章で「頭が鉤爪から学ぶ」と述べた一文が、ここでは「モデルが文書から学ぶ」という具体的なメカニズムとして実装されているのです。

2.4 最初の画面：オントロジーがそのままナビゲーションである

フレームワークを理解したところで、いよいよ画面に入っていきましょう。テオリアにログインすると、左側のアイコンサイドバーにこのアプリケーションの世界観が並びます。コンセプト・オントロジー、ビジネス・オントロジー、ITオントロジー、RAGシステム、オントロジー・プロジェクト、ドメイン管理、セマンティック・ファクトリー。一般的な業務システムが「メニュー」を並べるとすれば、テオリアは「私たちのビジネスを見つめるレンズ」を並べるのです。

中心はビジネス・オントロジー・ツリーです。商品ポートフォリオ、顧客セグメント、チャネル分類、市場、業務アーキテクチャの能力モデルと業務領域、業務コンポーネント、業務対象 — このツリーはフォルダ一覧ではなく会社構造そのものであり、チームメンバーがどんな作業をしようとも、その作業は必ずツリーのどこかに掛かっています。「この文書はどの業務の成果物なのか？」という問いに、ファイルパスではなくビジネス構造上の座標で答えることになるのです。

画面下部のステータスバーは、どのサーバーのどのリポジトリに接続されているか、現在どのエンティティが選択されているかを常時表示し、複数のリポジトリを行き来するチームのミスを減らしてくれます。

ツリーが最初に生まれる方法は、先に見た通りジェネシス・ブートストラップであり、育つ方法は以降の節で見る補強と編集です。ここで管理者が覚えておくべきことは一つです。ツリーはすべての作業の座標系であるため、ツリーを整える権限と責任が明確でなければならないという点です。

2.5 作業スペース：ダブルクリックで開く業務解決策ウィザード

ツリーでエンティティをダブルクリックすると、右側に作業スペースが開きます。ブラウザのタブのように複数を同時に開くことができ、シナリオ・プロセスダイアグラム・補強エディタ・レポートを並べて行き来できます。

その代表格が、業務解決策シナリオ・コンポーザーです。左側のツリーダイアグラムで文書の構造をノードとして組み立て、右側の詳細パネルで各ノードに文脈と質問を記入した後「マイニング」を押すと、AIが業務解決策の内容をマイニングして生成します。重要なのは、AIが白紙から作り出すのではないという点です。他のノードの内容、添付したPDF、ウェブ検索結果、RAG（検索拡張生成）で検索した社内知識がコンテキストとして一緒に取り込まれ、生成された内容は完全性・明確性・一貫性・実行可能性の四つの軸で品質分析を受けることができます。

AIエンジン自体も管理対象です。設定のブレイン（Brain）タブでLLMプロバイダー、温度とトークン上限、システムペルソナを定め、シナリオ単位・ノード単位で設定を変えて与え、「設定の伝播」で階層全体に反映させることができます。AIの活用が個人技ではなくチーム標準の領域になるということです。同じツールを使っていても、あるチームは標準設定と充実したコンテキストで作業し、別のチームはそれぞれ勝手に作業するのであれば、成果物の品質格差はツールではなく慣行から生まれます。

作成が終わった内容は公開プレビューで確認し、ノードまたは階層全体を公開し、翻訳連携で翻訳版を作成し、外部の公開プラットフォームへエクスポートすることもできます。各ノードには下書き・レビュー中・承認済み・ロック済みの状態が付き、「この文書はどこまで進んだか？」が一つのステータス値で答えられ、バージョン履歴で過去のスナップショットの比較と復元が可能です。

2.6 設計から実行可能なモデルへ：オントロジー詳細エディタ群

ここがテオリアが一般的な文書ツールと分かれるポイントです。作業空間では文章を書くだけでなく、実行の材料となるモデルを描きます。

ワークフロー設計は、BPMN標準（業務プロセスを描く国際標準表記法）に基づいたタスクフローエディタです。業務の開始と終了、タスクとサブプロセスを配置し、各タスクに担当ビジネスコンポーネントを指定します。

判断が必要なタスクは業務決定設計へと接続されます。ここはDMN標準（意思決定モデリングの国際標準）の意思決定テーブルエディタで、「どのような条件ならどのような結論になるか」という業務ルールが、担当者の頭の中ではなく、検討可能なテーブルとして文書化されます。そのほか、ビジネスオブジェクトモデルビューアとレポート、商品設計、戦略目標設計、ビジネスコンテキストダイアグラムなどが、エンティティタイプに応じた動的メニューとして提供されます。

これらのダイアグラムは絵で終わりません。BPMNエディタには「Poiesisへ提出」ボタンがあり、完成したタスクフローを作る翼へと引き渡し、設定にはPoiesis URLとPraxis URLが並んで配置されています。私たちのチームがここで描くプロセスと決定テーブルは、参考資料ではなくエージェントが実際に従うことになる仕様です。それだけ正確に描く必要があり、それだけ描く価値があります。

2.7 補強と顧客価値実現：オントロジーに肉付けをする作業

2.7.1 補強：エージェントという新しい職員の職務記述書

ツリーが骨格だとすれば、実務時間が最も多く費やされるのは、その骨格に肉付けをする補強（Enrichment）です。エンティティを右クリックすると、タイプに応じた補強エディタが開きます。業務対象補強はオブジェクトの属性と意味を、ドメイン知識補強はその領域の概念・手順・ヒューリスティック・因果関係・ルール・規制を、業務決定補強は決定の条件とパラメータを埋めていきます。

そして、役割補強、スキル補強、ツール補強、ガバナンスポリシー補強——この四つを並べて読んでみると、人の組織を設計する際に問う質問とまったく同じであることに気づかれるでしょう。どのような役割が必要か、その役割にはどのようなスキルが必要か、どのようなツールを持たせるか、どのようなポリシーの下で働かせるか。補強作業とは、すなわちAIエージェントという新しい「職員」の職務記述書を書く作業なのです。

ただし、決定的な違いが一つあります。その職務記述書は自然言語の文書ではなく、オントロジーに結合された構造化データであるという点です。そのため、「このポリシーを変更するとどのエージェントが影響を受けるか」をシステムが追跡できます。人の職務記述書は引き出しの中で眠りますが、エージェントの職務記述書は生きたまま接続されています。

2.7.2 顧客価値実現（CVR）：ニーズからエージェントポートフォリオまで

顧客に向けた補強が顧客価値実現（CVR）エディタです。一つの顧客活動を七つの段階で扱います。

まず顧客ジャーニーとドライバーをマッピングするフレームがあり、タスクと成果を重要度・満足度でランク付けするタスク定義が続きます。満たされていない成果をソリューションとエージェントコンセプトへと変えるアイディエーション、価値の流れを接点・チャネルのスイムレーンとして具体化する設計、機会をポートフォリオへと収束させるAIエージェント機会段階がそれに続きます。顧客要求と設計対応の整合性はQFD（品質機能展開／品質の家）手法で検証され、最後に定義段階の成果に対する実現の有無を確認する実現・測定段階が循環を閉じます。ニーズからトレードオフ、詳細実装へと降りていく反復ファネルも併せて備わっており、一つのシナリオをラウンドごとに忠実度を高めていくことができます。

デザインシンキングの言葉をそのまま用いながらも、成果物がワークショップの付箋で終わらず、オントロジーとエージェントポートフォリオへ直結するツールであるという点が差別化要素です。

2.7.3 能力カプセルワークベンチ：知識が最終パッケージ化される場所

知識とスキルが最終的にパッケージ化される場所が能力カプセルワークベンチです。能力カプセルは、まるで風邪薬の複数の薬剤が一つのカプセルに収められて効能を発揮するように、目標とする能力の効能を伝えるための業務ドメイン知識とスキルパックがカプセル化された単位です。ドメイン知識カプセルと能力カプセルはバージョン単位の独立した文書として保存され、すべてのカプセルは下書き→レビュー提出→承認→公開というライフサイクルに従います。提出されたカプセルは差し戻し・撤回が可能で、承認されたカプセルも公開前であれば撤回できますが、一度公開されたバージョンは最終版です。修正が必要な場合は新しいバージョンを作成する必要があります。

この単純なルールの重みを指摘しておきたいと思います。エージェントが参照する知識には常に「誰がいつ承認したどのバージョンか」というタグが付くということ——これが事後監査やインシデント調査において組織を守る最も基本的な防衛線です。

2.8 二つのハーネス：システムが崩れない理由

第1章では、ワシの胸をX字に横切るネクサス・ハーネスについて述べました。行動と統制という二つの交差したベルト、そしてその緊張を保持するガバナンスというバックル。テオリアとAOEDEオントロジーサーバーのコードを覗いてみると、その比喩が実際に二種類のハーネスとして実装されていることに気づきます。一つはオントロジーモデル自体を統治するモデルハーネスであり、もう一つはAIの実行を統治する実行ハーネスです。この節が第2章の心臓部です。

2.8.1 オントロジーモデルハーネス：MVOを混乱から救う規律

MVOアプローチの魅力は明確です。全体をすべて設計するのではなく、今必要なスキル一つに十分な最小限のオントロジーから始めるということ。しかし、このアプローチにはよく知られた影があります。ボトムアップで断片的に育つモデルは、統治する手がなければたちまち混乱に陥ります。チームAが作った「顧客」とチームBが作った「顧客」が微妙に異なる意味になり、昨日のエンティティ名が今日変わっており、循環参照と矛盾した分類が誰も気づかぬまま積み重なっていきます。事前設計の硬直性を避けようとして無秩序状態に到達すること——これがボトムアップアプローチが失敗する典型的な経路です。

オントロジーモデルハーネスは、この経路を防ぐために四層で締め上げられています。

第一層はメタオントロジーという文法です。どのチームがどのような順序で何を作ろうとも、作られるものはすべて`#`で始まるメタオブジェクトが宣言した形式——業務対象はエンティティを持ち、エンティティは属性を持つという文法——の中でしか存在できません。ボトムアップではあっても、無形式ではないのです。サーバーはリポジトリを開く際にこの文法をメモリ上に読み込み、入ってくるデータをその文法と照合して検証します。

第二層は概念推論エンジンです。先に見たとおり、概念モデルへのすべての変更は、循環検査、排他衝突検査、充足不可能クラス検出を通過します。各チームがそれぞれ概念を追加しても、論理的矛盾は保存時点で明らかになり、システムが推論した暗黙の上下位関係は提案として表示され、人が確定します。

第三層は境界と履歴です。概念モデルとオントロジーデータはログインセッションが指すリポジトリにのみ帰属し、他のリポジトリに触れられる隙間が構造的に塞がれています。編集ロックは二人が同じ対象を同時に修正する事故を防ぎ、リビジョン履歴とバージョン管理はすべての変更を追跡可能にし、ごみ箱は削除さえも復元可能な行為にします。カプセルライフサイクルの承認ゲートは、この履歴の上に人の判断を重ねます。

第四層が最も興味深いものです。セマンティック・ファクトリーの矛盾検知です。前の三層がモデル内部の整合性を守るとすれば、この層はモデルと現実の文書との間の整合性を監視します。MVOで育つオントロジーが「重なり始めるとき」——解約スキルの「顧客」と融資スキルの「借主」が出会うその瞬間——調整の根拠となるのが、まさにこの証拠層です。

この四層を一文に凝縮すればこうなります。モデルハーネスがあるからこそ、爪の一本一本のように育つオントロジーが大聖堂ではなく地図になりながらも、その地図が落書き帳にはなりません。モデルハーネスのないボトムアップは、速く始まって速く泥沼にはまるアプローチであり、モデルハーネスのあるボトムアップこそが、初めてMVOという名に値するのです。

2.8.2 AIエージェント実行ハーネス：問題生成機にならないための条件

二つ目のハーネスは方向が逆です。モデルハーネスが「地図を描く手」を統治するなら、実行ハーネスは「地図の上を走るAI」を統治します。そして、こちらの失敗の様相はより騒々しいものです。統制されていないAI実行システムは静かに腐るのではなく、積極的に問題を生み出します。存在しないテーブルを照会するクエリ、もっともらしくでっち上げられた数字、要求をこっそり狭めておきながら全体に答えたふりをする応答、限界を知らない探索がシステム全体を引きずり下ろす負荷。目標志向的に動くエージェントほど、手綱がなければその目標に向かって忠実に事故を起こします。

AOEDEオントロジーサーバーの自然言語クエリハーネスは、この問題に対する教科書的な答えを備えています。設計文書が「交渉の余地のない二つの原則」と呼ぶものから出発します。

第一に、スキーマ幻覚の禁止です。AIは実在しないエンティティ・属性・関係を参照するクエリを決して実行できません。第二に、読み取り専用と有限性です。すべてのクエリは読み取りのみで、結果件数と探索の深さが構造的に上限に縛られます。

そして、決定的な条件が付きます。この二つの原則は「AIが善良に振る舞うこと」や「レビュアーが勤勉であること」に依存してはならず、構造的に強制されなければならないということです。善意と勤勉さは良いものですが、アーキテクチャの安全性をその上に築くことはできません。

そのため、アーキテクチャは三つの層（tier）に分かれ、その間にただ一つの信頼境界が引かれます。

A層——言語理解（信頼しない）。LLMが自然言語の質問を受け取り、形式化されたクエリ計画——解釈・選択・探索・集計・影響分析といった型を持つ演算のグラフ——へと翻訳します。要点は、この層の出力を誰も信用しないということです。LLMはデータベースクエリ言語を直接書くことができず、中間表現しか出力できず、その中間表現は間違っていてもかまいません。誤った計画は次の層でふるい落とされるからです。

B層——検証とコンパイル（信頼境界）。決定論的なコードがA層の計画を受け取り、計画のすべての末端——対象エンティティ、属性、関係、指標——を生きたスキーマカタログと照合して結束（バインド）します。結束できない葉は実行されずに脱落し、生き残った演算だけがコンパイラを通過します。コンパイラはシステム内でクエリ言語を生成できる唯一のコンポーネントであり、生成されるすべてのクエリは読み取り専用で、件数・深さの上限が課された状態でのみ作られます。計画が「9999段階の探索」を要求しても、設定された最大値に切り詰められます。

そして——管理者の視点から見ると白眉なのですが——この層は理解レポート（Comprehension Report）を併せて出力します。質問のうち何がそのまま実行され、何が絞り込まれ、何がなぜ脱落したのかの明細です。システムはできないことを黙って省いて答える代わりに、できなかったと述べます。

C層——実行と検証（決定論）。検証済みの計画が実行され、クリティック（critic）が結果を検査します。結果が空になっていないか、形が質問に合っているか、条件が実際に適用されたか。問題があれば有限回数の範囲内で計画を修正して再試行し、最終結果は関連度で並べ替えられ、根拠・出典・能力レポート・実行トレースとともに返されます。

この構造がユーザーにどのように見えるかは、すでに体験されたことがあるかもしれません。オントロジーQ&Aで「確定した影響」と「影響の可能性あり——検討が必要」が区別され、推論項目に未確定の表示が付き、一致するエンティティがない場合に「影響がないことを確認したのとは違う」と明示されること——その画面上のすべての文言の背後に、この三層ハーネスがあります。

2.8.3 二つのハーネスは一対である

まとめましょう。モデルハーネスがなければ、ボトムアップで構築する瞬間にオントロジーは混乱に陥ります。断片同士が噛み合わず、名前が衝突し、矛盾が沈黙のうちに積み重なり、MVOの「最小限」は「杜撰さ」の別名になってしまいます。実行ハーネスがなければ、システムは問題生成機になります。もっともらしい誤答が確信に満ちた口調で届けられ、統制されていないクエリがリソースを消費し、エージェントは目標に向かって忠実に誤った道を進みます。

そして両者は互いを必要としています。実行ハーネスのB層が末端を結束する対象である「生きたスキーマカタログ」は、モデルハーネスが整合性を守ってきたオントロジーそのものです。モデルが乱れていれば、どれほど優れた実行ハーネスであっても、乱れた地図の上を正確に走るだけです。逆に、実行ハーネスの能力レポートとセマンティック・ファクトリーの矛盾発見は、モデルの空白を照らす明かりとなり、モデルハーネスが次に統治すべき対象を教えてくれます。ワシの紋章のX字——互いを張り詰めて引き合う二本のベルト——は装飾ではなく、この相互依存の肖像であったというわけです。

2.9 ジェネシスからデジタルツインへ：段階的構築とナビゲーションマップ

いよいよ最後の全体像です。ここまで見てきたすべての断片——ジェネシスの種、二層のオントロジー、補強、セマンティック・ファクトリー、二つのハーネス——は、実は一つの目的地に向かって整列しています。それが私たちのビジネスのデジタルツインです。

ここでいうデジタルツインとは、工場設備の3D複製のようなものではありません。私たちのビジネスの構造と知識と状態をコンピュータが理解できる形で映し出し、質問すれば根拠を持って答え、変更すれば波及を示してくれる生きた対応物を意味します。

重要なのは、このツインが一度の大工事で作られるわけではないという点です。ジェネシスはその段階的構築の礎石であり、オントロジーは各段階で道に迷わないようにしてくれるナビゲーションマップです。構築の六つの段階をたどってみましょう。

第1段階——種を植える。ジェネシスパッケージでリポジトリをブートストラップします。この瞬間に生まれるのは骨格だけです。業務対象群とそのビジネスオブジェクトモデル、そしてメタオントロジーという文法。しかし、この骨格こそが地図の骨組みです。以後のすべての作業が「オントロジー地図のどこに」置かれるかが、この瞬間に決まります。

第2段階——定義平面を立てる。各業務対象のビジネスオブジェクトモデルを磨き上げ、概念モデルにおいて用語の上下位関係と排他関係を確定します。推論エンジンが矛盾をふるい分けるなかで、「私たちのドメインにおいて何が存在し、どのように結びついているか」という定義的知識の平面が完成していきます。この平面がデジタルツインの座標系です。

第3段階——肉付けをする。補強エディタ群で属性と意味、ドメイン知識、決定ルール、役割・スキル・ツール・ポリシーを埋め、BPMNとDMNでプロセスと判断をモデリングします。ツインが構造だけでなく振る舞い方を持ち始めます。

第4段階——証拠をつなぐ。セマンティック・ファクトリーに実際の文書群を流し込みます。規定集や契約書、マニュアルから抽出された事実と関係が出典を伴った状態で積み重なり、矛盾検知がモデルと現実のずれを照らし出します。ツインが設計図の複製ではなく現実の反映になる段階です。

第5段階——グラフとして目覚める。デジタルツインRAGがオントロジーと補強内容全体から知識グラフを構築します。このとき、先に見た階層の規律がそのまま守られます。定義的な質問はビジネスオブジェクトモデルに由来するモデル平面で、インスタンスに関する質問はデータ行平面で——二つの平面が混ざらないからこそ答えが正確になります。そして、このグラフの上で実行ハーネスが自然言語の質問を安全に受け止めます。

第6段階——増殖する。十分に成熟したリポジトリは、再びジェネシスパッケージとして書き出され、次のドメイン・次の法人・次の実験の種になります。カプセルのインポートとコレクションのExcel入出力が部分単位での移動を担います。一つのツインの完成が、次のツインの出発点になるのです。

この六つの段階がMVOのリズムと正確に重なり合う点に注目していただきたいと思います。どの段階も「全体を終えなければ」次へ進めない関門ではありません。一つの業務対象、一つの能力カプセルのスキル範囲の中で1段階から5段階までを小さく完走し、その完走を隣接領域へと広げていきます。そして各段階においてオントロジーツリーがナビゲーションマップの役割を果たします。今、私たちが地図のどの区域を築いているのか、どの区域が定義だけあって証拠がないのか、どの区域が文書とずれているのか——ツリーと状態値と矛盾レポートが常にそれを示してくれます。霧の中で建てるのではなく、地図を見ながら一区域ずつ明かりを灯していく建設なのです。

このリズムが組織にもたらす心理的効果も軽視できません。数年がかりの大工事は完工前まで誰も成果を手にできないため、途中で予算が揺らぎ、スポンサーが交代すればプロジェクト全体が漂流してしまいます。一方、一区域ずつ明かりを灯していく建設では、四半期ごとに実際に灯った明かり——展開されたスキル、答えられるようになった質問、減少した見落とし——を示すことができます。オントロジープロジェクトが生き残る条件は完璧な設計ではなく、着実に示し続けられる明かりであるということを、この六段階の構造は最初から織り込んでいます。

2.10 オントロジーに直接尋ねる：ツインとの対話

構築の報酬は対話です。オントロジーQ&Aタブを開くと、チームが積み上げてきたツイン全体を相手に自然言語で質問を投げかけることができます。「『個人』業務対象の詳細情報と能力を説明してほしい」「ここでいうLTVとは何を意味するのか」「このエンティティを削除すると何が影響を受けるのか」、さらには「どのプロセスが最も複雑か？複雑度はタスク数で計算せよ」のように、ユーザーがその場で指標を定義するような質問まで受け止めます。

回答の性質は、すでに前節で見た実行ハーネスが決定します。説明型の質問には、サーバーがオントロジーを正確に照会し決定論的に構成したブロック——何が一致し、どこに属し、上下位の依存関係が何であるか——が権威ある答えとしてまず提示され、AIが合成した記述はその下に置かれます。根拠となるノードはグラフとして可視化され、クリックすると属性が開きます。影響分析では確定と推定が区別され、補強の接続に異常が検知されると、該当項目が確定結果から除外されたことが明示されます。

管理の観点から見ると、この機能は二つのことを変えます。第一に、「これを変えたら何が壊れるか」という変更影響の質問が、担当者の招集や会議の召集なしに、数秒で一次回答を得られます。第二に、チームが補強と文書連携を丁寧に行うほど回答の品質が目に見えて向上するため、オントロジー管理が「後のための文書化」ではなく、「今すぐ返ってくる投資」になります。

2.11 一日の流れで見るテオリア

ここまでの話をあるチームの一日に置き換えてみると、この作業台の手触りがより生き生きと感じられます。

朝、オントロジー担当者がテオリアにログインします。画面下部のステータスバーがどのサーバーのどのリポジトリに接続されているかを確認させてくれ、左側のオントロジーツリーには昨日まで磨き上げてきた会社の構造がそのまま広がっています。夜の間にセマンティック・ファクトリーが新たに添付された与信規定の改定版を読み込んでおり、矛盾検知が二件の発見事項を上げています。一つは改定規定には登場するもののオントロジーにはまだない概念で、もう一つは文書が語る関係とモデルが宣言している関係とがずれている箇所です。担当者はこの二件を、今日の午後のオントロジー協議体の議題へと移しておきます。モデルと現実のずれが放置された負債ではなく朝会の議題になること——これがこの作業台の日常です。

午前中には、業務設計者が「紛争処理」業務対象をダブルクリックして作業空間を開きます。シナリオコンポーザーで新しい業務シナリオの骨格をノードとして組み立て、各ノードにコンテキストと質問を書き込んだ後、マイニングを押します。AIが下書きを埋めますが、その材料は白紙ではなく、他のノードの内容と添付された規定文書、RAGで検索された社内知識です。生成された内容は完全性・明確性・一貫性・実行可能性の四つの軸で品質分析を受け、ノードには「レビュー中」のステータスが付きます。隣の席の同僚は同じ時刻にBPMNエディタでタスクフローを磨いており、判断が必要なタスクにはDMN意思決定テーブルが接続されていきます。

午後、ドメイン能力カプセルが一つ、レビューに提出されます。承認者はカプセルの内容がゴールドスタンダードに照らして十分か、出典がきちんと付いているか、実行結果が約束された能力を提供しているかを確認したうえで、承認の印を押します。このバージョンは公開されれば最終版となり、以後どのエージェントがこの知識を参照しても「誰がいつ承認したどのバージョンか」というタグが付いて回ります。退勤間際、チームリーダーはオントロジーQ&Aタブを開き、「このエンティティを削除すると何が影響を受けるか」を尋ねます。数秒後、確定した影響と検討が必要な推定とが区別されて返ってきて、能力レポートはどの部分を絞り込んで答えたのかを正直に明かします。チームリーダーはその「絞り込んだ部分」を来週補強すべき区域としてメモします。

この一日にドラマチックな場面はありません。しかし注意深く見れば、すべての作業に同じ文法が流れています。発見はシステムが行い、調整は人が行い、生成はAIが行い、確定はレビューが行い、知識は積み重なりますが必ず出典と承認のタグを伴って積み重なります。今日もまた、新しい能力が会社の運営に加わりました。デジタルツインは、こうした一日一日が積み重なって育っていくものであり、ある日竣工式を開く建物ではないのです。

2.12 結びに：頭を託された管理者へ

テオリアとそのサーバーを一文で要約すればこうなります。概念モデルという文法の上に、ジェネシスという種で会社のビジネスオントロジーを植え、セマンティック・ファクトリーで現実の証拠をつなぎ合わせ、二つのハーネスでモデルと実行を共に統治し、段階的にデジタルツインを築き上げていく作業台。多言語対応、編集ロックとバージョン履歴、ごみ箱とカプセルの入出力といった実務装置が、その作業を支えてくれます。

この作業台を任されることになる管理者にいくつかお伝えしておきたいことがあります。最初に決めておくべきはジェネシスと概念モデルの管理権限です。オントロジージェネシスはすべての作業の座標系であり、概念モデルはその座標系の文法であるため、文法が乱れれば、その上に書かれるすべての文章がともに乱れてしまいます。誰がツリーの構造を変更でき、誰が概念の定義を確定するのかは、導入初週に名前で決めておくべき問題です。次に、ブレイン設定と補強の慣行をチームの標準として確立することです。同じツールであっても、コンテキストを丁寧に埋めるチームとそうでないチームでは成果物の品質に大きな差が生じるため、設定伝播機能はまさにその標準を階層全体に展開するために用意されているものです。

カプセルライフサイクルの承認者の役割も軽く見てよいものではありません。下書きから公開へと移るその関門が、私たちのチームが生み出すエージェントの信頼水準を決定づけるため、承認は決裁ではなくレビューでなければなりません。セマンティック・ファクトリーが上げてくる矛盾レポートも同様です。モデルと文書のずれは放置すれば負債になりますが、定期的な議題として扱えば、オントロジーが育つ最も安価な原料になります。ハーネスは発見までしか行ってくれず、調整は常に人の役割だからです。

そして最後に、理解レポートを読む文化を作っていただきたいと思います。システムが「この部分は絞り込んで答え、この部分は答えられなかった」と正直に述べるとき、その告白を聞き流さないチームだけが、正直なシステムの価値を余すところなく享受できます。正直な失敗報告は減点の材料ではなく、次に築くべき区域を教えてくれる地図なのです。

ワシの頭はもはや抽象的な概念ではなく、毎朝開いて仕事をする画面であり、ハーネスは比喩ではなくコードで締め上げられた実物であり、デジタルツインはある日完成するプロジェクトではなく一区域ずつ明かりを灯していく地図です。見えるところまでだけ定義し、定義した分だけ補強し、補強したものを二層のハーネスで統治して引き渡すこと——テオリアでの一日一日が、まさにその地図に明かりを灯す作業なのです。

第2章の要点：テオリアは、概念モデル（文法）、ジェネシス（種であり運搬形式）、セマンティック・ファクトリー（証拠の保管庫）という三本の柱の上に築かれたオントロジー作業台である。モデルハーネス（メタ文法、推論エンジン、境界と履歴、矛盾検知）がボトムアップの成長を混乱から守り、実行ハーネス（A層の言語理解、B層の検証・コンパイル、C層の実行・検証）がAIの回答を構造的に強制する。この上でデジタルツインが六段階にわたり、MVOのリズムに合わせて育っていく。

第3章 ポイエーシス（POIESIS）：作る翼

本章で扱う内容：ポイエーシス（POIESIS）が作るものの正体（エージェントではなくエージェント・ハーネス）、ハーネスの三つの大きさ（活動・タスク・スキル）と導入のはしご、そしてポイエーシス（POIESIS）が組織に付与する八つの能力。事例ドメインには住宅ローン審査を使用します。

3.1 はじめに：ポイエーシス（POIESIS）が作るものの正体

第2章は一つのボタンで終わりました。テオリアで完成した業務フローを、作る翼へ引き渡す「Poiesisに提出」ボタンです。本章はそのボタンが押された後の物語です。

ただし、物語を始める前に、AOEDE-ポイエーシス（POIESIS）が作るものの正体を正確にしておく必要があります。ポイエーシス（POIESIS）は、いわゆる「AIエージェント」を作る場所ではありません。より正確に言えば、AIエージェント・ハーネスを組み立てる場所です。

この区分は言葉遊びではありません。裸のAI——賢いが手綱のない知能——は市場のどこでも手に入ります。企業が作らなければならないのは、その知能に装着する馬具（ばぐ）です。何を知っているべきか、何ができるか、どこまで進んでよいか、どの地点で必ず止まる、あるいは人に引き渡さなければならないかが組み込まれた構造物。第2章で実行ハーネスについて「手綱のない目標志向エージェントは、目標に向かって忠実に事故を起こす」と述べた、まさにその問題意識が、ポイエーシス（POIESIS）では作ることそのものの対象になります。ポイエーシス（POIESIS）において「作る」ということは、すなわち「ハーネスを組む」ということです。

ポイエーシス（POIESIS）が対象とするユーザーが開発者ではなくビジネスアナリストと業務設計者であるという点も、この正体とつながっています。ハーネスの本質——どこまで任せ、どこで止めるか——は技術的判断ではなく業務判断だからです。エージェントの内部仕様は専用言語で記述されますが、ポイエーシス（POIESIS）の存在理由は、現場の専門家がそのコードを直接書かなくても、自然言語と視覚的な設計ツールで完結したハーネスを組み立てられるようにする点にあります。コードは成果物であって、入場券ではありません。

本章は画面案内書ではありません。まず、ポイエーシス（POIESIS）が築くハーネスの三つの大きさ——活動、タスク、能力——を理解し、その上でポイエーシス（POIESIS）が組織に付与する八つの能力を一つずつ見ていきます。事例には、システムに実際に搭載されている住宅ローン審査ドメインを使用します。

なお、組み立てられたハーネスの内部規格と、それを実行するエンジンの話——ネクサス（NEXUS）とミメーシス（MIMESIS）——は本章では扱いません。それは、配備されたエージェントが実際に働く舞台であるプラクシス（PRAXIS）とともに、第4章で余すところなく展開するのが適切だからです。

3.2 三段階のハーネス：活動（ワークフロー）、タスク、能力

ポイエーシス（POIESIS）の作業対象リストを開くと、実装対象が最初から二つの層に分かれて到着していることが分かります。活動レベルとタスクレベルです。そして、その下で能力の階層が設計されます。この層区分は整理用フォルダではなく、AOEDEが自動化を捉える視点そのものです。ハーネスには三つの大きさがあり、大きさごとに目的と人の立ち位置が異なります。

3.2.1 活動（ワークフロー）レベル・ハーネス：流れ全体を包む最大の馬具

活動レベル・ハーネスは最大の馬具です。一つの業務活動——例えば住宅ローン審査という最初から最後までの流れ全体——を包み、目標は自律運用（autonomous operation）です。申込受付から最終意思決定まで、複数のタスクと複数の関門を通過するエンドツーエンドのワークフローがエージェントたちの協働で回り、人は流れの中の定められた介入ポイントと例外エスカレーションにのみ登場します。

この大きさのハーネスが担うべきものは、個別判断の品質を超えた流れ全体の健全性です。関門間の整合性、役割間の引き継ぎ、全体の基調の調整までがハーネスの一部です。

3.2.2 タスクレベル・ハーネス：一つの役割の代理人

タスクレベル・ハーネスは中間の大きさです。活動全体ではなく、特定の役割が遂行する一つのタスク——例えば審査担当者による担保評価、コンプライアンス担当者によるマネーロンダリング点検——を包みます。この大きさでは、エージェントは流れの主人ではなく、一つの役割の代理人または同僚です。タスクの入力と出力、そのタスクに必要なスキルと習熟度、タスクが守るべき規則と権限がハーネスの内容となり、タスクの前後は依然として人または他のハーネスがつなぎます。

3.2.3 能力レベル・ハーネス：最も小さいが最も精巧な馬具

能力レベル・ハーネスは最も小さいものの、ある意味で最も精巧な馬具です。目標が自動化ではなく、人の働き手の能力拡張（augmentation）だからです。担保価値の算定、所得書類の検証、規程の照会といった一つの能力単位において、エージェントは人に取って代わるのではなく、人の手に握られる精密な道具になります。

そして、まさにそれゆえに、この小さなハーネスには二つのことが凝縮されていなければなりません。第一に、その能力に関する包括的な知識——関連するドメイン知識、スキル、判断の材料、参照すべき規程と出典。第二に、統制ポイント（control points）——ある値は必ず検証を経なければならず、ある結論は絶対に下してはならず、ある場合には必ず人の確認を受けなければならないという地点です。要するに、能力ハーネスとは「物事が正しい方法でのみ行われるようにする」知識と手綱の最小完結単位です。

3.2.4 重なり合う構造、そして導入のはしご

三つの大きさの関係も重要です。これらは互いに異なる三つの製品ではなく、重なり合う構造です。活動ハーネスはタスクハーネス群の編み合わせであり、タスクハーネスは能力ハーネス群の編み合わせです。第1章で能力カプセル（Capability Capsule）について「各カプセルは縮小された一羽のワシである」と述べた一文が、ここで構造的な意味を得ます。最も小さな能力ハーネスにも知識と統制が完結的に含まれているからこそ、それらを積み上げたタスクと活動も崩れないのです。

管理者にとって、この三段階はすなわち導入のはしごでもあります。組織はたいてい、能力ハーネスから出発するのが安全です。人が依然としてハンドルを握ったまま、拡張された能力の品質を検証する段階です。検証されたスキルが集まれば、一つの役割のタスクをハーネスに任せることができ、タスクが十分に熟せば、ようやく活動全体の自律運用を論じる資格が生まれます。第1章のMVO（実行可能最小限オントロジー）——爪一本、能力一つずつ育つオントロジー——とまったく同じリズムです。自律性は宣言するものではなく、小さなハーネスから積み立てていくものです。

人を採用することになぞらえると、このはしごの感覚がより鮮明になります。新入社員に初日から部署全体の運営を任せる組織はありません。最初は先輩のそばで資料調査や草案作成といった一つの仕事(能力)を手伝わせ、腕前が検証されれば一つの業務(タスク)を完全に任せ、複数の業務で信頼が積み重なって初めて、一つの流れ全体(活動)を任せます。AOEDEの三つのハーネスは、この常識的な昇進の仕組みをエージェントにそのまま適用したものであり、後で見る認証と習熟度の仕組みは、その昇進の人事記録に相当します。

それでは、この三段階のレンズをかけて、ポイエーシス（POIESIS）が組織に付与する八つの能力を歩いてみましょう。

3.3 第一の能力：ハーネス実装のパイプラインを一目で把握する

ポイエーシス（POIESIS）が管理者に与える最初の贈り物は、華やかな機能ではなく可視性です。テオリアから引き渡された実装対象は、活動レベルとタスクレベルに層分けされた状態で到着し、到着した瞬間から一つのライフサイクルを付与されます。受付済み → 作成中 → 検証済み → 配備済み、そしてどの段階からでも移行しうる差し戻し。

この五つの状態は単なるラベルではありません。ポイエーシス（POIESIS）の作業フロー自体が作成 → 検証 → バージョン → 配備という四段階の順次工程で組まれており、各工程は次の工程への入場条件となります。作られていないハーネスは検証できず、検証されていないハーネスは配備できません。状態は、その工程上で各ハーネスが今どこにいるかを示す座標です。

管理者の立場から見て、これが変えるのは進捗会議の言葉です。「あの件はどうなっているか」という問いに、担当者の記憶で答える代わりに、パイプライン上の座標で答えるようになります。どの活動ハーネスが何週間も「作成中」にとどまっているか、タスクハーネスのうち「検証済み」と「配備済み」の間にボトルネックがあるかは、照会の対象になるのであって、聞き回りの対象にはなりません。

小さな一つの規律が、この能力の性格をよく表しています。根拠となるドメインデータが接続されていない対象は、そもそも作業を開始できないようロックされています。データなしにハーネスから組み始めること——あらゆる実装プロジェクトが一度は経験する誘惑——が、このパイプラインでは構造的に起こりません。

3.4 第二の能力：シナリオから出発するハーネス設計

ハーネス組み立ての最初の一手は、コードではなく物語です。担当者はこの活動またはタスクが行うことを自然言語のシナリオとして記述し、この業務が達成すべき目標を併せて定義します。そして、AIの支援を受けながら、そのシナリオを構造化された設計草案へと発展させます。

ここで重要なのは、AI支援の方式です。ポイエーシス（POIESIS）のAI生成は自由作文ではなく、規格が与えられた作文です。ハーネスにどのような構成要素が存在しうるか、それらが互いにどう結合しうるかが、あらかじめ定義された規格としてシステムに登録されており、生成はその枠内でのみ行われます。第2章の原則——「AIの出力は検証されるまで信頼されない」——が、設計段階では「AIの出力は規格の中でのみ生まれる」という形で貫かれているのです。ハーネスを組むアシスタントにも、ハーネスが装着されているというわけです。

AI活用の条件そのものもチームの資産として管理されます。どのモデルをどの温度（temperature）とペルソナで使うか、翻訳をどう付けるかが設定として標準化されているため、誰が作成しても同じ条件で同じ品質の草案が得られます。インターフェースは韓国語・英語・中国語・日本語を行き来し、多国籍チームが一つのドメインを共に設計する状況を最初から想定しています。

管理者の目でこの能力をまとめると、次のようになります。設計の出発点が現場の言葉になり、AIはその言葉を規格へと翻訳するアシスタントになります。現場が要件を書いて開発組織に投げ、数週間後に翻訳の誤りを発見するという従来のリズムが、現場が直接ハーネスの草案を手にするリズムへと変わるのです。

3.5 第三の能力：ハーネスに入れるすべての知識に根拠の身分証を付ける

能力ハーネスの定義を改めて思い出してみましょう——「物事が正しい方法でのみ行われるようにする、包括的な知識と統制ポイントの最小完結単位」。本節はその前半、知識の話です。ハーネスに収められる知識の品質は結局「何に基づいているか」によって決まり、ポイエーシス（POIESIS）がこの点で提供する能力は一文に要約できます。エージェントが参照する世界の事実の一つひとつに、身分証が付いているのです。

設計者は作業中いつでも、ドメインの全容を複数の角度から確認できます。どのような業務対象が存在し、何をもって同一性を判別するのか、対象同士がどのような関係で絡み合っているのか、どのような事象がどのような状態変化を引き起こすのか。しかし、ポイエーシス（POIESIS）のドメイン知識は単なる閲覧資料の域を超え、版を重ねるごとに三つの方向へと深化してきました。

最初に深まった方向は、規制との連結です。業務規則と不変条件——常に守られるべき宣言的な規則群——には、その根拠となる規制条項が直接リンクされており、規程・条項・引用が構造化されたグラフとして探索できます。「この規則はなぜ存在するのか」という問いには、担当者の記憶ではなく条項リンクが答えます。

ここに権限との連結が加わります。誰がどの行為をどの範囲で実行できるか、決裁チェーンは何か——委任の規則、金額の上限、有効期間まで——がマトリックスとして宣言されています。ハーネスが許容する行動の境界は、慣行ではなく仕様なのです。

そして最後の方向が、出典との連結です。各データ値がどこから来たのかという出典の帰属、その値がどれほど確実かという不確実性プロファイル、複数の出典が衝突した際の調整規則までが、値単位で記録されます。

この三つの層が合わさって生み出す状態を、管理者の言葉に置き換えるとこうなります。監査人のどのような質問にも、一つの画面で答えられるハーネス。「その数字はどこから出たのか」「その規則の法的根拠は何か」「その行為をそのエージェントが行う権限はあるのか」——規制産業でエージェントを運用しようとする組織が必ず通過しなければならない三つの問いへの答えが、設計の時点からハーネスの中に蓄積されます。

3.6 第四の能力：能力から活動まで、働く主体を組織のように設計する

ハーネスの三段階が実際の設計物として現れる場所が、まさにこの能力です。エージェントを作るということは、結局のところ新しい働き手を組織に迎え入れることであり、ポイエーシス（POIESIS）は人の組織を設計する際に使う語彙を、そのままこの世界に適用します。

最も下に能力のアーキテクチャがあります。複合的な能力が原子的なスキルへと分解され、末端の原子スキルが実際のツールと結合する階層構造——能力ハーネス群の系譜です。各スキルには、それを支えるドメイン知識、遂行の技法、判断の骨格となる推論テンプレートが連結されます。前節で見た身分証付きの知識がスキル単位でまとめられ、次節で見る統制ポイントがここに結合すると、人の働き手の手に握られる拡張の単位——能力ハーネス——が完成します。

その上に役割とタスクのアーキテクチャがあります。どのような役割が存在し、役割間の階層とエスカレーション経路——問題が大きくなると誰に上がるのか——はどうなっているか、各役割はどのタスクを担うか。そして、各タスクがどのスキルをどの習熟度で要求し、自動化が可能な段階はどこかを明らかにする業務-スキル対応表が、二つの層をつなぎます。この対応表こそが、能力ハーネスをタスクハーネスへと昇格させられるかどうかの判定表です——タスクが要求するスキルがすべて検証済みのハーネスとして存在するか?

最も上に活動のアーキテクチャがあります。タスクがプロセスとしてつながり、関門が流れを統制し、決定的に人の介入ポイント（HITL（Human-in-the-Loop）チェックポイント）が第一級の設計要素として宣言されます。活動ハーネスの自律性とは、人が消えた状態ではなく、人の居場所が正確に設計された状態です。エージェントがどこまで進み、どこで人に引き渡すかは設計の成果物であって、運用中の即興ではありません。

興味深い原則が一つ、この視点の深さを物語っています。エージェントのあらゆるLLMベースの作業さえも、登録された「認知能力」という形式を通じて宣言されなければなりません。このシステムでは、AIの知能さえも登録された能力であり、登録されていない能力はハーネスの中に存在しません。

3.7 第五の能力：統制ポイントを数学で鍛え上げる

能力ハーネス定義の後半——統制ポイント——の話です。ハーネスの統制ポイントの中で最も精巧に鍛え上げられているのが判断の統制であり、ポイエーシス（POIESIS）の最新版が集中的に強化したのがまさにここです。

3.7.1 意思決定テーブルの静かな落とし穴

出発点は、おなじみの意思決定テーブルです。「条件がこうであれば、決定はこれ」という行のリストです。住宅ローン審査ドメインには、審査の関門ごとにこうしたテーブルが連結されています。

ところが、古典的な運用方式——上から読んで最初に該当する行を採用する方式——には、静かな落とし穴が二つあります。複数の行が同時に該当する場合、どれが正しいかを吟味せずに上の行を選ぶこと、そして、どの行にも該当しない場合を音もなく見逃すことです。どちらもシステムがエラーを出さないため、誤った判断が正常処理の顔をして流れていきます。

3.7.2 落とし穴の大きさをまず測定する

ポイエーシス（POIESIS）は、この落とし穴の大きさをまず測定しました。このドメインで可能な入力の組み合わせ1,410通りをすべて展開してみたところ、97通りは複数の規則が同時に該当する真の多値(多値)事例であり、897通りはどの規則にも該当せず、旧方式が静かに取りこぼしていた事例でした。千件近いずれが、もっともらしい外見の下に隠れていたのです。

3.7.3 三つの処方：台帳、順序、禁止

そして、学界の多値意思決定理論を取り入れ、三つの方法で応えました。

まず、隠れていた多値事例と非カバー事例をすべて台帳に載せました。存在を認めることが管理の始まりだからです。

次に、複数の決定が競合する場合に「最も保守的な決定から」という深刻度順で同点を解消する判断ツリーを導入し、深さ優先型と簡潔型の代替案を並べて提示することで、ドメイン専門家がトレードオフを見て選択できるようにしました。どの規則にも該当しない事例は、テーブルごとに作成されたデフォルト決定が受け止め、判断のカバレッジは1,410分の1,410——抜け漏れなし——になりました。

そして、白眉は最後にあります。禁止規則——「この条件ではこの決定は絶対に出てはならない」という『してはならない』の文法——が194個導出され、各規則は既存の規程文言から根拠を引き継ぎ、深刻な規則は標準検証規格へとコンパイルされて、設計検証時点と運用時点の両方で機械的に強制されます。この強制は関門ごとに勧告と強制を選択でき、現在は六つの関門すべてが強制モードです。導入方式さえも慎重でした。関門一つずつ、シャドー検証期間を経る段階的な展開であり、各段階の判断根拠が報告書として残されています。こうした多次元的な統制ポイントを通じて、これまで見えていなかったリスクを排除できるようになりました。

3.7.4 願望から証明可能な性質へ

「物事が正しい方法でのみ行われるようにする」という能力ハーネスの使命は、ここでは願望ではなく、数学的に証明可能な性質となります。すべての入力に判断が存在すること(カバレッジ)、競合時に保守的な方向へ傾くこと(深刻度順)、禁止線を機械が守ること(禁止規則の強制)。

エージェントに「何をせよ」だけを教える組織と、「何を絶対にするな」までを強制する組織との間には、リスク等級の差があります。ポイエーシス（POIESIS）は、その差を配備後の事故対応の場面ではなく、作る段階で作り出します。

3.8 第六の能力：活動ハーネスの基調を計器盤で調整する

前の能力が個別判断の統制ポイントを鍛え上げるものだとすれば、今回の能力は活動レベル・ハーネスだけが持ちうる統制——流れ全体の基調——を扱います。核心概念はスロットル（throttle）です。自動車のアクセルペダルのように、自律運用される活動全体の保守性と積極性を調整するつまみです。

作動原理は一つの回路です。市場指標、延滞動向、運用データといった外部・内部のシグナルが、それぞれの重みとともに登録されており、これらのシグナルが合算されて現在のスロットルスコアになります。そのスコアは、活動を構成する各審査関門のパラメータ——承認閾値、判断の保守性バイアス——へと変換され、一斉に反映されます。そして、そのように調整された判断の結果が、関門別の成果推移や不良債権指標との相関として測定され、再びシグナルとなって戻ってきます。シグナル → 基調 → 判断 → 成果 → シグナルという閉じた輪です。

この回路が活動ハーネスの自律性にとってどのような意味を持つか、確認する価値があります。自律運用の本当のリスクは、個別判断の誤りよりも、世の中が変化したのにシステムの姿勢がそのままである状態です。スロットルはそのリスクへの答えです。市場が悪化する際、数百個の個別規則を一つひとつ改修する代わりに、流れ全体の姿勢を一つの政策レバーで調整できます。

そして、管理者にとってこれは実はなじみのない概念ではありません。与信政策委員会が会議と公文書で行ってきた、まさにその業務の計器盤版です。変わったのは透明性です。今四半期の基調調整がどのシグナルによって、どの関門に、どれだけ作用したか、その結果として不良率がどう動いたかが、すべて記録として残ります。基調調整が「勘」の領域から計器盤の領域へと移ってくるのです。

3.9 第七の能力：配備する前に飛行してみる

組み立てられたハーネスが実世界へ出て行く前に、ポイエーシス（POIESIS）は三重の試験を要求します。構成が規格に適合しているかを見る形式検証、内容が業務規則に適合しているかを見る意味検証、そして実際の実行を模してみるシミュレーション実行。文章が文法に合っているか、意味が合っているか、動かしてみると意図どおりに動くか——三つの問いが順に投げかけられます。

試験のツールも豊富です。関門とカテゴリの格子を埋め、どこが空いているかを明らかにするカバレッジ分析があり、システムが自らの知識基盤を批評し、自律エージェントに不足している情報が何かを特定してくれる「批評と補完」機能があります。

検証器の最終出力が、この文化の性格をよく表しています。現在のドメインの検証結果はエラー0件、警告18件ですが、その警告さえも「強制はされているが、規制条項へのリンクがまだ付いていない禁止規則」といった——つまり、次にやるべきことのリストです。検証は合格・不合格の判を押すものではなく、バックログ生成器として機能します。

シミュレーション実行は本格的な試験飛行場であり、ハーネスの大きさによって試験の性格も変わります。スキルとタスクのレベルでは個別判断の正確性が関心事であり、活動レベルではエージェント同士の協働——段階ごとに何が起きたかの逐次トレースと、複数のエージェントが互いに何をやり取りしたかの相互作用関係図——が関心事になります。あらかじめ用意されたシナリオ集から事例を選ぶか、直接作成して実行し、数十から数百のシナリオを一斉に回すバッチ実行が統計的な確信を加え、集計された成果ダッシュボードが結果を集約します。

システムの随所にある一つの表示が、この文化を要約しています。シミュレーション実行を経ていない分析画面には「静的モード」というバッジが付きます。実行して確かめていない主張には、タグが付けられるのです。

管理者にとって、この能力が持つ意味は承認会議の風景の変化です。配備承認の議案に上がるのは、担当者の意見ではなく飛行記録——どのシナリオを何件回したか、トレースで何が見えたか、カバレッジの空欄は何か——になります。

3.10 第八の能力：履歴と関門でハーネスの出荷を統制する

試験に合格したハーネスには、二つの最後の規律が待っています。履歴と関門です。

履歴の規律は、ソフトウェア開発の実証された慣行をそのまま取り入れています。すべてのハーネスは枝分かれ(ブランチ)と確定記録(コミット)で管理され、二つの版の間の差分を比較でき、過去の版へ戻すこともできます。版ごとにパイプラインの状態がバッジとして付いているため、「今実際に運用に出ている版はどれか」という問いにも、一度の照会で答えられます。テオリアのカプセル・ワークベンチで見た原則が、ここでも繰り返されます。ハーネスのどの版がいつどの状態にあったかは、記憶ではなく記録の問題でなければならないという原則です。

関門の規律は、配備を一つの儀式にします。配備前のチェックリストがあり、承認手続きがあり、通過したハーネスだけが運用の舞台——治める翼プラクシス（PRAXIS）——へと引き渡されます。そして、切り戻し(ロールバック)が常に用意されています。出て行く門が狭く、戻ってくる門が開いている構造——配備統制の定石です。

ここで、プラクシス（PRAXIS）との関係を一つだけ確認しておきます。ポイエーシス（POIESIS）とプラクシス（PRAXIS）は、同じサーバーと同じデータベースを共有する二つの顔です。能力、スキル、技法、推論、エージェント名簿、監督体系——両翼が参照するこれらの中核業務オントロジーは、文字どおり同じ本の同じページです。作る側が引き渡したハーネスと治める側が受け取ったハーネスの間には、翻訳も、複製も、食い違う余地もありません。第1章で「飛行には両翼がともに動くことが必要である」と述べた文の工学的な実現が、まさにこの共有構造であり、その舞台の上で起きること——配備されたハーネスの中でエージェントが実際に働き、監督される物語——は第4章の役目です。

付け加えると、静かながらも印象的な規律が一つ、履歴の世界を完成させます。ドメインデータを直接修正する編集機能さえも、手綱がかけられているという点です。修正が許される項目はあらかじめ宣言されたリストに限定され、保存は変更部分のみが単一の経路で送信され、元に戻す機能が用意されており、変更は監査の対象として残ります。データを直す手にも手袋がはめられているということ——ハーネスを作る工場自身が、ハーネスを装着して働いているというわけです。

3.11 一式のハーネスが生まれるまで

八つの能力を一つの物語につなぎ合わせると、ポイエーシス（POIESIS）で一式のハーネスが生まれる過程は、おおよそ次のように流れていきます。

発端は、テオリアから引き渡された実装対象です。住宅ローン審査活動の下に、審査担当者による担保評価というタスクが受付済み状態で到着しています。根拠となるドメインデータが接続されていることをシステムが確認して初めて、作業が開かれます。業務設計者は、このタスクが行うことを自然言語のシナリオとして記述し、達成すべき目標を併せて書き込みます。AIがその物語を構造化された設計草案へと発展させますが、その作文は自由作文ではなく、ハーネスの規格の中でのみ生まれる作文です。状態は作成中に変わります。

設計が厚みを増していく間に、収められる知識の一つひとつに身分証が付けられます。担保評価に適用される業務規則には、根拠となる規制条項がリンクで連結され、このタスクで許容される行為の範囲と決裁チェーンが権限マトリックスとして宣言され、参照するデータ値には出典と不確実性プロファイルが記録されます。タスクが要求する能力群——担保価値の算定、所得書類の検証、規程の照会——は、それぞれのドメイン知識と推論テンプレートを備えた能力ハーネスとしてまとめられ、判断の関門には意思決定テーブルが連結されます。ドメイン専門家は、規則が競合する際の保守性の順序を確定し、どの規則にも該当しない事例を受け止めるデフォルト決定を書き込み、「この条件ではこの決定は絶対に出てはならない」という禁止規則が規程文言から根拠を引き継いで強制モードで設定されます。

いよいよ試験飛行です。形式検証が規格との一致を、意味検証が業務規則との一致を確認し、カバレッジ分析が空欄を明らかにし、シミュレーション実行が用意されたシナリオ集とバッチ実行によって統計的な確信を積み上げます。検証器が残した警告18件は、不合格判定ではなく次にやるべきことのリストとしてバックログに登録されます。状態は検証済みとなり、配備承認の議案には担当者の意見ではなく飛行記録——どのシナリオを何件回し、トレースで何が見えたか——が添付されます。承認関門を通過したハーネスは、コミットとブランチの履歴を携えたまま、配備済み状態でプラクシス（PRAXIS）の舞台に上がります。

この旅路で注目すべきは、どの段階においても、治めることが作ることの後回しにされていないという点です。規格は設計の始まりから存在し、根拠は知識が収められる瞬間に付けられ、禁止線は配備の前にすでに機械に刻まれていました。作る翼が速い理由は、治めることを省略しているからではなく、治めることを工程そのものにしたからです。

3.12 むすびに：作る翼の管理者へ

ポイエーシス（POIESIS）が組織に付与する能力を一つの段落にまとめると、次のようになります。活動・タスク・能力という三つの大きさのハーネスを、パイプライン上で進捗を一目に把握しながら築く。現場のシナリオから規格のある設計を得て、ハーネスに収めるすべての知識に規制・権限・出典の身分証を付け、能力から活動まで働く主体を組織のように設計し、統制ポイントを数学で鍛え上げ、自律運用の基調を計器盤で調整し、配備前には必ず飛行してみて、履歴と関門で出荷を統制する。八つの能力に共通する文法は一つです。作る速度のために治めることを後回しにせず、治めることをハーネスそのものとして作り出すこと。

この翼を任される管理者に残したい助言も、物語の流れそのものです。新しい自動化課題が持ち込まれたら、「エージェントを作ろうか」ではなく、「これは能力拡張なのか、役割のタスクなのか、活動の自律運用なのか」という大きさの問いから投げかけてください。能力ハーネスで十分な場所に活動ハーネスを築いたり、活動が必要な場所に能力だけを与えたりする大きさの誤判断が、この領域で最も高くつく失敗であり、能力ハーネスで積み立てられた信頼のみがタスクと活動の自律性を正当化するという導入のはしごの原則が、その問いの羅針盤になります。進捗を語るときは、パイプラインの五つの状態——受付済み、作成中、検証済み、配備済み、差し戻し——を会議の言葉としてください。進捗報告はこの五語で十分であり、この五語でこそ正確です。

判断の統制に関する事柄は、技術部門ではなくドメイン専門家の机の上に置かれるべきです。規則が競合する際にどちらがより保守的な決定か、どの規則にも該当しない事例をどう受け止めるかはリスク政策の問題であり、システムはその政策を書き込む欄を用意しているにすぎません。保守性の原則とデフォルト決定の作成を専門家の正式な業務として付与し、検証が残した警告の大半を占める禁止規則の規制根拠の補強を、次四半期の課題として挙げておいてください。警告リストがすなわち業務リストです。

配備の関門では、断固たる姿勢が美徳です。シナリオを何件回したか、バッチを何回実行したか、トレースで何が見えたか——この三行がない承認要請は差し戻すことが、このツールの文化に合っています。シミュレーション実行のない配備承認を慣行から消してください。そして、活動ハーネスの自律性が大きくなるほど重くなるレバー、スロットル回路の持ち主を決めておいてください。シグナルの重みと関門との連結は、一度決めて忘れる値ではなく、成果のフィードバックを見ながら定期的に手を入れる政策レバーです。

ワシの左翼は、こうして働きます。物語が入ってきて三つの大きさのハーネスとなって出て行き、その間のあらゆる手入れに規格と根拠と記録が付き従う場所。次章では右翼プラクシス（PRAXIS）へと渡り、配備されたハーネスの中でエージェントたちが実際に働き、治められる舞台とともに、今回取っておいた二つの名——ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）——の物語を余すところなく展開します。

第3章の要点：ポイエーシス（POIESIS）はエージェントではなくエージェント・ハーネスを組み立てる場所であり、ハーネスには能力(拡張)・タスク(代行)・活動(自律運用)の三つの大きさがある。八つの能力——パイプラインの可視性、シナリオベースの設計、根拠の身分証、組織型設計、数学で鍛え上げた統制ポイント、スロットルによる基調調整、配備前のシミュレーション飛行、履歴と関門による出荷統制——に共通する文法は、治めることをハーネスそのものとして作り出すことである。

第4章 プラクシス（PRAXIS）：統治し、調整する翼

本章で扱う内容：これまで温存してきた二つの名前の正体――ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）――、そして展開されたハーネスが実際に稼働し、統治される運用の舞台。事例ドメインには融資デューデリジェンス（due diligence）業務を用います。

4.1 はじめに：ワシの最後の一片

本書もいよいよ第4章に至りました。第1章ではワシの解剖構造を見て、第2章では判断する頭部テオリア（THEORIA）を、第3章では作る左翼ポイエーシス（POIESIS）を掛けてきました。第3章は一つの約束で締めくくられました。ハーネスの規格であるネクサス（NEXUS）と、それを忠実に実行するミメーシス・エンジン（MIMESIS ENGINE）の物語を、展開されたエージェントが実際に働く舞台とともに余すところなく展開するという約束です。

本章はその約束を果たす場です。AOEDE-プラクシス（PRAXIS）は右翼、統治する翼です。ポイエーシスが三つの大きさのハーネス――能力、タスク、活動――を組み立てて関門を通過させると、そのハーネスはプラクシスの舞台に上がります。ここでエージェントたちは実際の文書を受け取り実際の判断を下し、人はその実行をリアルタイムで見守り、習熟度が測定され、認証が更新され、変更が管理され、異常が知らされます。第1章の一文を借りれば――「統制なしに作るだけの組織はリスクを大量生産し、作らずに統制するだけの組織は何も生産できない」――プラクシスは、その一文の後半が空言に終わらないようにする場所です。

プラクシスの最初の画面が、本書全体の世界観を一枚の図として要約しているという点も言及に値します。スタート画面にはAOEDE――エージェンティック・オントロジーの構想および展開環境――の全体地図が広がり、テオリア（THEORIA）・ポイエーシス（POIESIS）・プラクシス（PRAXIS）という三つのワークプレイスと、その中央のNEXUS、そしてエージェントを構成する能力の車輪――認知、知識、メモリー、推論、インタラクション、学習、ペルソナ、プレゼンテーション――が描かれています。これまで三章にわたって語ってきたことが、運用者の最初の画面にすでに一枚の図として掛けられているわけです。

本章も先行する各章と同じ方式に従います。画面案内ではなく、能力の物語です。ただし順序には理由があります。まず先送りにしていた二つの名前――ネクサスとミメーシス――を明らかにし、その上でプラクシスが組織に与える統治の能力群をたどっていきます。事例ドメインは、ポイエーシスで組み立てられたそのハーネスが実際に稼働する融資デューデリジェンス（due diligence）業務です。

4.2 ネクサス（NEXUS）：ハーネスの規格であり、一つの原本から花開く七つの視点

まず一つ目の名前です。第1章ではネクサス・ハーネスを「行動、統制、ガバナンスから成る黄金のベルト」と呼び、第3章ではその組み立てを扱いながらも名前の正体は伏せておきました。今こそ語ることができます。ネクサスとは、ハーネスが記述される規格であり、作る翼と統治する翼がやり取りする契約文書の形式です。

4.2.1 九十七種の語彙で書かれた契約書

具体的に、ネクサスはCC-DSL（Cognition Control-Domain Specific Language）という専用言語（ドメイン特化言語）で記述された一つのパッケージです。その中には、これまで三章にわたって語ってきたすべて――ビジネス領域、作業（ジョブ）と段階、役割、機能、スキル、技法、知識ベース、推論テンプレート、そして監督規則――が一そろいの定義として収められます。

驚くべきはその規模です。この規格は九十七種の定義要素と二十八種の連結関係から成り立っており、エージェント組織一つを記述するのに必要な語彙がほぼ余すところなく備わっています。人間組織にたとえるなら、組織図、職務記述書、業務マニュアル、権限規定、監査基準が一つの一貫した言語で書かれているようなものです。ここで使用するCC-DSLはネクサスのための専用言語であり、AOEDEハーネスを標準化するために開発されました。

4.2.2 二つの扉、そして自動整列

プラクシスにおいて、ネクサスは二つの扉から入ってきます。一つはシナリオ設定ウィザードです。DSLファイル群をアップロードすると、システムが定義が参照より先に来るように――メイン、知識、技法、推論、スキル、ハンドラーの順に――依存関係に基づいて自動整列し一つに統合したうえで、検証を経て検知された構成要素の一覧――ビジネス領域いくつ、役割いくつ、スキルいくつ、監督規則いくつ――を表示してからネクサスを生成します。もう一つは、ネクサスページでの直接アップロードと展開です。どちらの扉から入っても、展開されたネクサスには「展開済み」の表示が付き、運用のリポジトリに登録されます。

4.2.3 七つの視点：食い違うことのできない文書群

しかし、ネクサスページの真の価値は登録ではなく翻訳にあります。一つのネクサスを選択すると、システムは同じ原本を七つの視点に解きほぐして示します。経営陣の言葉で書かれたビジネス要件、原文そのままのDSLソース、役割別の流れを描いたワークフロー・スイムレーンとBPMN、アクションの入力と出力がどうかみ合うかを示すデータ依存関係図、定義要素の関係全体を見渡すオントロジーマップ、どの監督規則がどこに適用されているかのガバナンス・トレース、そして定義の隙間を指し示すギャップ分析です。

管理者にとって、この七つの視点が意味するところは明白です。これまで組織において、要件文書、プロセス図、データフロー図、統制マトリクスは、それぞれ異なる人が異なるツールで描くために互いに食い違うのが常だった四枚の紙でした。ネクサスでは、これらが一つの原本から機械的に派生する視点であるため、原理上互いに食い違うことがあり得ません。「文書と実態が異なる」という古い病が、文書がすなわち実態である構造によって癒やされるのです。

4.3 ミメーシス・エンジン（MIMESIS ENGINE）：「作業」という名の忠実な実演

二つ目の名前です。第1章はミメーシスをこう紹介しました――「エンジンは結果を作り上げたりしない。オントロジーが定義した内容を、ハーネスが許容する範囲内でそのまま実行するだけである。エンジンが強力である理由は、指示されたとおりにしか動かないからだ。」プラクシスにおいて、その一文は作業（Job）という形で実体を得ます。

4.3.1 作業の誕生：明示されたトレードオフ

作業の誕生から見ていきましょう。運用者は新しい作業を作成する際、展開済みのネクサス（DSLテンプレート）を選択し、処理対象となる実際の文書――契約書、財務諸表、鑑定評価書――を添付し、優先順位と実行条件を定めます。

興味深いのは処理戦略の選択肢です。システムが自動的に決める自動、一度に一、二ページずつ精読する品質優先、中間サイズのバランス、大量を高速に処理するスループット、そして自ら指定するカスタム。大量文書を扱ってきた管理者ならば、このダイヤルの意味をすぐに理解するでしょう。精度と速度のトレードオフが、担当者の勘ではなく明示的な設定として表に出ているのです。

4.3.2 実演の舞台：三層構造と生きた可視化

作業が開始されると、ミメーシスの実演が繰り広げられます。実行の単位はネクサスが定義したとおり――トランザクションがステージを従え、ステージがアクションを従える三層構造です。画面上部の二重進捗バーはトランザクションレベルとアクションレベルの進捗を同時に示し、反復処理中であれば何回目かまで表示します。

ワークフロー・タブでは実行フローが有向グラフ（DAG）として動き、エージェント・タブでは複数のエージェントが時間軸上で仕事をやり取りするスイムレーンと相互作用の関係が描かれ、イベント・タブには何がいつ起きたかという流れが秒単位で積み重なります。

4.3.3 系譜がダウンロードボタンとして存在する状態

そして実演の終わりに、ミメーシスの性格が最も鮮明に現れます。成果物タブには最終的な結果物だけがあるのではありません。すべてのアクション一つひとつの入力と出力がペアで保存され、それぞれ個別にダウンロードできます。融資デューデリジェンス作業であれば最終的にマークダウン報告書とHTMLダッシュボードが作成されますが、その報告書のどの数字であっても、「どのアクションが、どんな入力を受け取り、どんな出力を出したか」という連鎖にさかのぼることができます。

結果を作り上げないエンジンとは、まさにこういうことです。すべての結論に系譜があり、その系譜がダウンロードボタンとして存在する状態。

管理者の言葉でこの節を締めくくります。従来の自動化において、「その結果はどうやって出てきたのですか」は開発チームに問い合わせる質問でした。ミメーシスの舞台では、それはタブを一つ開くだけのことです。

4.4 約束によって結ばれた実行：要請され、約束され、陳述され、受諾される

ミメーシスが実行するトランザクションには、注目に値する構造がもう一つあります。各トランザクションは要請済み → 約束済み → 陳述済み → 受諾済みという四つの局面を経ます。言語行為理論（speech act theory）に根ざしたこの構造は、仕事とは作業の羅列ではなく行為者間の約束の環であるという観点を含んでいます。発信者が仕事を要請し、実行者がやると約束し、やったと陳述し、発信者が結果を受諾することで環が閉じます。

そのため、プラクシスの実行台帳には事実と並んで約束が第一級の項目として存在し、約束にはステータスがあります――アクティブ、履行済み、違反、キャンセル。トランザクション画面では、各トランザクションの発信者と実行者、トリガー、そして段階別のアクションがフロー図とツリーで展開されます。

これが管理の観点からなぜ重要なのでしょうか。エージェントシステムにおける責任の所在は、しばしば霧の中にあります。複数のエージェントが絡み合って仕事をする中で何かが誤れば、どこから食い違ったのかを突き止めるのは困難です。約束の環はその霧を晴らします。すべての仕事には要請した者と約束した者がおり、違反した約束は「違反」というステータスで実行台帳に残ります。責任の追跡が事後調査ではなく、データ構造そのものなのです。

4.5 生きている名簿：エージェント、役割、そして八つに分かれた能力

舞台上の役者たちを見る番です。

4.5.1 エージェント名簿：人とAIが同じ文法で

エージェント画面は、登録されたエージェントたちの生きている名簿です。各エージェントには種別――LLMベース、ルールベース、ハイブリッド、そして人間――があり、ステータスと最終ハートビート（生存信号）があり、どんな役割を担い、どんな機能・スキル・技法を保有しているかがツリーで展開されます。

目を引くのは、「人間」がエージェント種別の一つであるという点です。この名簿において、人とAIは同じ文法で登録される仲間です。これは修辞ではなく実用です。人とAIが混在して働くワークフローを一つの実行台帳で管理するには、両者を同じ語彙で記述できなければならないからです。

この選択が含意するところは、もう一歩先に進みます。人とAIが同じ文法で登録されるということは、業務を設計する際に「このタスクは人のもの、あのタスクはAIのもの」という二分法の代わりに、「この役割を今誰が担うのが最善か」という配置の問いを立てられるということです。今日人が担っていた役割を明日検証済みのエージェントが引き継いでも、あるいはその逆でも、フローの設計そのものは変わりません。ハーネスが役割に紐づいており、個人に紐づいていないからです。人間組織において引き継ぎがこれほど脆弱である理由が、業務が人に付随しているためであることを思い起こせば、この文法の実用的な価値が明らかになります。

4.5.2 役割登録簿：委員会議決までも語彙の中へ

役割画面は、その役者たちが担う配役の登録簿です。役割には種別――外部、人間、AI、人間グループ――があり、グループ役割には定足数と投票規則（過半数、全会一致、重み付け）まで定義されます。委員会の議決構造がハーネスの語彙の中に組み込まれているのです。各役割が遂行できる許可された作業の一覧と委任可能な対象が明示され、今この役割を実際に遂行中のエージェントたちが並んで照会できます。

4.5.3 エージェントロジー（Agentology）：役者の内面を解剖する

そしてエージェントロジー画面が役者の内面を解剖します。エージェントの能力は八つに分類されます。中核となるAI処理を担う認知、情報アクセスと検索の知識、文脈と状態管理のメモリー、論理と意思決定の推論、人・エージェントとのコミュニケーションであるインタラクション、適応と改善の学習、アイデンティティと行動様式のペルソナ、出力形式のプレゼンテーション。これに、入力と出力の両方にかかる七重の安全フィルターが加わります。第3章で「AIの知能さえも登録された能力である」と述べた原則が、運用の側ではこの八分類体系として生きているのです。

一つの概念上の区別が画面に明示されているため、記しておきます。能力（capability）はビジネス層――システムが行うことであり、コンピテンシー（competency）はエージェントロジー層――AIエージェントの認知能力です。「我々のシステムは担保評価を行う」（能力）と「このエージェントは文書からエンティティを抽出できる」（コンピテンシー）を区別する語彙が、組織の中に生まれるのです。

4.6 共有台帳の向こう側：同じ能力を運用の目で読む

第3章で、二つの翼は同じサーバー、同じデータベースを共有する二つの顔であると述べました。プラクシスでその共有台帳の向こう側――能力、スキル、技法、推論、ドメイン知識――を開いてみると、作る側で組み立てられた能力ハーネスが運用の目でどう読まれるかが分かります。

スキル画面では、各スキルが自身の実装する機能、使用する技法、参照するドメイン知識とともに成熟度を示します。技法画面は、各技法の入力、段階別タイムライン、出力要件――必須フィールドと任意フィールド――、そして抽出プロンプトまでを示します。

推論画面が特に印象的です。各推論テンプレートには思考連鎖の目標と要点、few-shot例が整理されており、何よりもLLM制約条件とドリフト防止規則――モデルが時間の経過とともに本来の意図から逸脱するのを防ぐ仕組み――が仕様として付随しています。推論タイプの語彙も豊富です。連鎖思考（Chain of Thought）、思考の木（Tree of Thought）、ReAct、リフレクション（Reflexion）からエンティティ関係推論、因果推論、比較分析まで、十三種類のタイプが標準分類として存在します。

この台帳のすべての項目には、二つのバッジが付いて回ります。一つはステータス――ドラフト、アクティブ、展開済み、廃止予定、アーカイブ済み――であり、もう一つは変更管理レベルです。後者は次節の主役なので、ここでは一文だけ残しておきます。能力ハーネスの定義――「包括的な知識と統制ポイントの最小完結単位」――は、展開された瞬間に消え去る設計意図ではなく、運用者が毎日開いて見る台帳の実物なのです。

4.7 統治の三つの道具：変更管理、シグナル、監督規則

統治する翼の核心的な任務は、結局のところ統制です。プラクシスは三つの道具でこれを遂行します。

一つ目の道具は変更管理です。台帳の各項目には変更管理レベルが宣言されています――自由変更、要レビュー、そしてMRM必要。MRM、すなわちモデルリスク管理（Model Risk Management）は、金融業界の管理者にとってなじみ深い重みを持つ言葉でしょう。規制が求めるモデル検証手続きが必要な項目はそのように表示され、変更管理ダッシュボードにはレビュー待ちの項目が集まって承認または却下を待ち、処理の履歴が残ります。ポイエーシスでハーネスを作る際に刻まれた統治が、運用中の変更にまで及んでいるのです。一度検証されたハーネスであっても、その部品を修正するには再び関門を通らなければなりません。

二つ目の道具はシグナルとモニタリングです。リアルタイムのメトリクスとシグナル活動が流れ、アラートは情報・警告・緊急の深刻度に分類され、ダッシュボード最上部――全作業、アクティブなエージェント、トランザクションと並んで――にアクティブなアラート数として集計されます。第3章のスロットル回路が信号を消費して基調を調整したのだとすれば、プラクシスはその信号が生まれ、監視される現場です。

そして三つ目の道具が監督規則です。ネクサスに盛り込まれ展開された監督オントロジー――ガバナンスと監督の規則群――が運用側で照会でき、先に見たネクサスのガバナンス・トレースの視点が、どの規則がどの実行ポイントに適用されているかを示します。実行記録の詳細さすらも統制の対象です。監査レベルは、なしから基本、詳細、完全まで段階的に宣言されます。

三つの道具を管理者の視点でまとめるとこうなります。何が変わるのか（変更管理）、何が起きているのか（シグナル）、何が守られているのか（監督規則）――統治の三つの問いにそれぞれ専任の道具があり、三つの道具は同じ台帳の上で機能します。

4.8 信頼の通帳：認証と習熟度

第3章は「自律性は宣言するものではなく、小さなハーネスから積み立てるものである」と述べました。プラクシスには、その積立が記録される通帳があります。認証と習熟度です。

エージェントのスキル習熟度は四段階で測定されます――未訓練、初級、熟練、エキスパート。そして熟練の主張は試験によって証明されます。認証画面で運用者はエージェントを選び、テストスイート――テストケース群と合格基準から成る試験――を受験させ、結果はスコアとともに認証記録として残ります。

認証には有効期限があります。一度取得した資格が永遠ではないということ――人間の専門資格が継続教育と更新を要求するように、エージェントの資格も更新を要求します。モデルが変わり、データが変わり、規制が変わる世界において、これは当然の要求です。

この仕組みがハーネスの三段階と交わる点こそが要点です。能力ハーネスからタスクハーネスへ、タスクから活動の自律運用へと上がる梯子の各段は、結局のところ「このエージェントをどれだけ信頼できるか」という問いですが、認証と習熟度はその問いにスコアと有効期間のある答えを提供します。自律性の拡大が、担当役員の確信ではなく認証記録の蓄積の上で決定される組織――それがこの通帳が可能にする状態です。

4.9 翼の彼方へ：フェデレーションとテナント

プラクシスの視野は、一つの組織の垣根の中では終わりません。

フェデレーション（Federation）画面は、A2A（エージェント対エージェント）プロトコルで接続された外部世界の名簿です。他組織のエージェントがエンドポイントとともに登録され、組織別に分類され、オンライン状態が追跡されます。そして運用者は特定の能力を指定して――対象エージェントを選ぶか、「利用可能な任意のエージェント」に対して――能力を呼び出すことができます。自分たちのハーネスが持たない能力を、フェデレーションの隣人から借りるのです。

内側にはテナント管理があります。一つのプラクシスの上で複数の事業部、複数の法人がそれぞれの垣根を持って運用され、ダッシュボードはテナント別に分けて見ることができます。

この二つの方向がともに指し示す絵があります。エージェント経済は、一社の一システムに閉じることはないでしょう。組織の内側には複数の主体が、組織の外側には複数のパートナーが、それぞれ自分のエージェントを持つようになり、その時必要になるのは身元と能力と呼び出しの標準的な文法です。プラクシスのフェデレーションとテナントは、その文法の早い実例です。

4.10 ある午後のデューデリジェンス作業：系譜をさかのぼる

プラクシスの一日を一場面に折りたたんでみましょう。午後、運用者が新しい作業を作成します。展開済みのネクサスの中から融資デューデリジェンステンプレートを選び、処理対象となる実際の文書――契約書、財務諸表、鑑定評価書――を添付し、今日は精度が優先されるので処理戦略ダイヤルを品質優先に合わせます。実行ボタンを押した瞬間から、ミメーシスの実行が始まります。

画面上部の二重進捗バーがトランザクションレベルとアクションレベルの進捗をともに満たしていき、ワークフロー・タブでは実行フローが有向グラフとして動きます。エージェント・タブを開くと、複数のエージェントが時間軸上で仕事をやり取りするスイムレーンが描かれ、イベント・タブには何がいつ起きたかが秒単位で積み重なります。その間、各トランザクションは要請され、約束され、陳述され、受諾される四つの局面を静かに通過します。ある一つの約束が違反状態のまま残るとすれば、それは霧ではなく台帳の一行になります。

作業が終わると、成果物タブにマークダウン報告書とダッシュボードが置かれます。運用者は報告書の中の担保評価額を一つ選び、系譜をさかのぼります。その数字を出したアクションが何だったのか、そのアクションが受け取った入力が何だったのか、その入力はどの前段階の出力だったのか――連鎖の節目ごとにダウンロードボタンが付いています。以前であれば開発チームに問い合わせチケットを開いて数日待たされたであろう質問が、数回タップするだけのことになったのです。この一場面に、統治する翼の存在理由が凝縮されています。実行は速く、しかしどの結論も自らの系譜を失わないということ。

4.11 むすびに：ワシが完成する

四つの章を貫いた旅程を一段落に折りたたみます。テオリアにおいてビジネスがオントロジーとして言語化され、二重のハーネスによって統治されました。ポイエーシスにおいてその言語が活動・タスク・能力という三つの大きさのハーネスに組み立てられ、判断の隙間と禁止線が数式によって鍛え上げられたのち、試験飛行と関門を経ました。そしてプラクシスにおいて、ハーネスはネクサスという契約の形式で展開され、ミメーシス・エンジンがそれを系譜が残る方式で実演し、約束の環と生きている名簿と三つの統制の道具と信頼の通帳がその実行を統治します。頭が見て、左翼が作り、右翼が統治し、エンジンが実演し、鉤爪が実際の業務を掴む。ワシが完成したのです。

統治する翼を任される管理者への申し送りも、この舞台の感覚そのものです。何よりも作業成果物の系譜を監査の標準に据えていただきたいと思います。すべてのアクションの入力と出力がダウンロードできるシステムにおいて、結果だけを見て済ませるレビューは道具を無駄にすることになるため、重要な作業についてはサンプルを抽出して系譜をさかのぼって確認する手続きを定例化してください。変更管理レベルの指定は、リスク部門とともに決めるべき事柄です。どのスキルと推論テンプレートがMRM対象であるかは技術的判断ではなく規制対応の判断であり、指定が終わった瞬間、変更管理ダッシュボードの保留項目がそのままリスク部門の業務リストになります。

運用のリズムの中で見落とされがちなこともあります。認証の期限切れを放置しないでください。期限切れの認証のまま働くエージェントは、更新教育を飛ばした従業員と同じですから、期限が迫った認証の点検は月例運用会議の固定議題であるべきです。そしてトランザクション台帳における「違反」状態の頻度とパターンを指標としてお読みください。約束違反は、どのハーネスのどの継ぎ目が弱いかを教えてくれる最も正直な信号です。最後に、垣根の外の問いを一つ、あらかじめ引き寄せておいてください。フェデレーションに提供する能力と借りる能力の方針――自分たちのエージェントのどの能力を外部に登録し、外部のどの能力をどのような条件で呼び出すのかは、技術が成熟してから決めたのでは遅い、今この時点でのガバナンスの問いです。

第1章はこう締めくくられていました――「見ることができる分だけオントロジーを定義せよ。行動できる分だけエージェントを作れ。すべての行動を統制とガバナンスに繋ぎとめよ。エンジンに忠実に実行させ、鉤爪に実際の仕事を掴ませ、ワシが実際に掴む術を学んだことに合わせてオントロジーを育てよ。」四つの章を経てきた今、その一文一文すべてに実物が備わりました。あとに残るのは、そのワシが実際のビジネスの地面に鉤爪を下ろす場面――第5章の物語です。

第4章の要点まとめ：ネクサスは九十七種の定義要素から成るハーネスの規格であり、二つの翼がやり取りする契約文書であって、一つの原本から七つの視点が機械的に派生するため、文書と実態が食い違うことはあり得ない。ミメーシス・エンジンはすべてのアクションの入出力をペアで保存し、すべての結論にダウンロード可能な系譜を残す。約束の環、生きている名簿、三つの統制の道具（変更・シグナル・監督規則）、そして認証・習熟度という信頼の通帳が運用を統治する。

第5章．CLAW：鉤爪が地面に触れる

本章で扱うこと：CLAWS（鉤爪群）の実装例の一つであるCLAW（企業融資拡張ワークプレイス）の全貌。企業融資業務の全生涯を収めた職場の地図、役割によって異なる三つのダッシュボード、傍らに座る同僚としてのエージェント、「分析一文」の威力、そして代替ではなく拡張を選んだ設計思想とその成果測定法。

5.1 はじめに：最初の文書の約束を果たす場

第1章はこう記しました。「ワシの構造は結局、鉤爪が何を掴むことができるかによって評価される。AOEDE CLAWSは、フレームワークが実際のビジネスと出会う接点である。左の鉤爪は専門金融サービスを担う。企業融資、貿易金融、資金管理のように複雑性が高く、根拠が契約文書にあり、統制されない意思決定のコストが資本規模で測定される領域である。」

第2章から第4章まで、私たちは頭（テオリア）と両翼（ポイエーシス、プラクシス）を順に歩んできました。オントロジーが定義され、ハーネスが組み立てられ、ミメーシスが系譜を残しながら実演するところまで見てきました。しかし、一つの問いが残っていました。では、現場の机の上では何が変わるのか？

本章ではその問いに答えます。主役は第1章で予告した、まさにあの左の鉤爪、企業融資を掴むCLAWSの実装例 — CLAW（Corporate Loan Augmenting Workplace、企業融資拡張ワークプレイス）です。

この名前はじっくり読んでみる価値があります。Corporate Loanはドメインであり、Workplaceは形態です。重心は真ん中の単語、Augmenting — 拡張にあります。第3章ではハーネスの三つのサイズについて語りながら、最も小さな能力ハーネスの目標を「自動化ではなく人間の働き手の能力拡張」だとし、「自律性とは宣言するものではなく、小さなハーネスから積み上げていくもの」だとして導入の梯子を描きました。CLAWはその梯子の最初の段が実物として建てられた姿です。ここでAIは審査役を代替しません。審査役の傍らに座ります。

あらかじめ一つ明らかにしておきます。このアプリケーションはCLAWSの実装例（リファレンス）です。データはデモ用であり、百数十の画面のうち代表的な画面は完全に実装されており、残りは登録された骨格として存在します。しかし実装例であるからこそ、かえってよく見えるものがあります。AOEDEが現場のシステムと出会うときに取る形、すなわち鉤爪のパターンです。本章ではそのパターンを読み解くことに集中します。

5.2 職場の地図：企業融資という業務の全生涯

CLAWを開くと最初に出会うのは、企業融資業務の全生涯を八つのモジュールに展開した地図です。その順序がそのまま与信の一生です。

物語は相談支援から始まります。目標顧客を検索し、企業の総合情報 — 企業概要、経営陣と主要株主、信用評価、営業現況、関係会社、企業動向 — を照会し、財務情報を財務状態表・損益計算書・キャッシュフロー計算書・財務比率など七つのタブで確認し、自行と他行の取引履歴を確認し、業種情報を比較します。そしてついに条件試算と申請 — 融資条件をシミュレーションし申請書を作成する画面 — に至ります。

続いて総合担保モジュールが担保の評価と登記と解除を担い、審査承認モジュールが与信承認の進行状況と基本登録、承認、実行、本部管理を担当します。

承認以降は管理の時間です。限度管理はPre-NPL管理、信用与信限度、総エクスポージャー（Total Exposure）、総合信用与信限度、大企業営業限度を扱います。与信資産健全性は資産健全性の登録と分類、引当金を管理します。事後管理は債権再調整と競売という与信の最も難しい局面を担い、与信審査モジュールは融資点検報告の検証を担当します。最後に総合経営情報が各種与信実績日報、日次延滞速報、月別延滞率現況、ヴィンテージ分析、金利プレミアムモニタリングといった報告の世界を締めくくります。相談から競売まで — 一枚の地図に与信の一生がすべて収められています。

この地図で管理者が注目すべきは、規模と登録の方式です。システムには183の画面が一つのレジストリに固有IDとともに登録されています。企業融資という業務の関節一つひとつが座標を持っているのです。そして画面群は十一の業務ドメイン — 企業顧客管理、相談支援、信用評価、財務分析、審査承認、総合担保、限度管理、早期警報、与信資産健全性、事後管理、与信審査 — にもまとめられており、利用者がどの画面に移動しても、システムが今どの業務領域にいるかを自動的に検知して文脈を合わせます。

この地図を歩いていると、一つの印象が残ります。八つのモジュールの順序が、そのままリスクの一生でもあるという点です。相談と試算の段階で下された判断が担保と審査の関門を通過し、承認以降は限度と健全性の監視のもとに置かれ、事がうまくいかなければ事後管理の難しい局面へ、うまく流れれば経営情報の報告書へと流れ込みます。拡張エージェントがこの地図の上のどこに座ろうとも、その場所の前後に何があるかをシステムが把握していること — それが文脈検知の実質的な意味です。

第2章の文章を覚えていらっしゃるでしょう。「オントロジーツリー（ジェネシス）はすべての作業の座標系である。」CLAWの画面レジストリとドメイン地図は、その座標系が現場の職場に降り立った姿です。鉤爪はどこにでも掴みかかるわけではありません。地形をすべて把握したうえで掴むのです。

5.3 三人の朝：役割が異なれば同じシステムも異なる顔

CLAWは三人の一日を想定して作られました。午前九時、同じ銀行の三人がそれぞれの席で同じシステムにログインします。支店の顧客担当はコーヒーを置く間もなく今日処理すべき案件を確認しなければならず、本部の審査役は夜間に積み上がった承認待ち行列の長さが気になり、リスク管理者は昨日の延滞指標が予警報線にどれほど近づいたかをまず見たいと思います。ログインした瞬間、同じシステムがこの三人にまったく異なる三つの顔で現れます。

顧客担当（RM）の朝は今日やるべきことの風景です。ダッシュボードの中心は作業キューです。K電子のB2B限度設定申請、M企業の信用評価進行案件、L流通の担保評価結果到着、N建設の現場実査準備が並んでいます。その隣には満期緊急度パネルが秒読みに入った案件を並べています。A電子の信用調査満期まで2日、B食品の融資満期まで3日、C貿易の買入外国為替満期まで5日。担当顧客の一覧、案件別の進行状況、銀行からのお知らせがこれを取り囲みます。RMの一日で最も高くつく失敗は「見落とし」です。このダッシュボードは見落としの候補を毎朝目の前に整列させます。

本部審査役の朝は関門の風景です。承認待ちの案件が優先順位と待機日数を伴って並んでおり — M企業の信用評価はすでに5日目の待機中です — 審査・信用評価・担保評価・限度管理へと続く本部業務のメニューが整列しています。審査役の一日で最も高くつく失敗は「ボトルネック」であり、この画面はボトルネックを数字で示します。

リスク管理者の朝は計器盤の風景です。ダッシュボードの一番目立つ位置にNPL（不良債権）率の推移が予警報線2.0%とともに描かれており、資産健全性分類の推移とヴィンテージ分析 — 融資実行時期別のまとまりの延滞率曲線 — が並んで配置されます。リアルタイム報告、ポートフォリオ現況、安定性、収益性の報告書群がその下を支えます。リスク管理者の一日で最も高くつく失敗は「発見の遅れ」であり、この画面は発見の時点を早めるために存在します。

三つのダッシュボードが共有する設計原則が一つあります。役割こそが視点であるということです。本シリーズを通して、役割はハーネスの第一級の要素でした。テオリアの役割補強、ポイエーシスの役割アーキテクチャ、プラクシスの役割登録簿がそれです。CLAWにおいて、その役割はついに朝の画面の姿となります。そして次節で見るように、役割を知っているのは画面だけではありません。

5.4 傍らに座る同僚：AOEDE-Claw エージェント

画面右側には折りたたんで開閉できるパネルが一つあります。AOEDE-Claw AIエージェント — このワークプレイスに常駐する同僚です。システムがエージェントに与えた自己紹介が設計思想を要約しています。「CLAWに内蔵された（embedded）知能型AI同僚（co-worker）。」ツールでもチャットボットでもなく「同僚」という言葉を選び、その言葉の価値を果たすために二つのことが設計されています。

何よりこのエージェントはユーザーが誰であるかを知っています。今ログインしている人の役割と作業キュー、今日の日付が常にエージェントの文脈に含まれています。そのためRMにかける最初の挨拶とリスク管理者にかける最初の挨拶は異なります。RMには「本日満期が迫った案件が3件あり、A電子の信用調査が最も急を要します（残り2日）。本日の業務計画を優先順位順に立てましょうか？」と話しかけます。リスク管理者には「今月の延滞率が前月比0.3ポイント上昇し、予警報の閾値を超えました。今すぐ月次リスク分析サマリーを作成しましょうか？」と話します。

そしてエージェントのパネルには二つのタブがあります。一つは協業対話 — 質問して答えるおなじみのチャットです。もう一つがこの設計の核心であり、まさにインテリジェンス・インサイトタブです。尋ねなくてもエージェントが自ら差し出す話がここに蓄積されます。RMには満期間近の警報と5日目に入った遅延中の評価案件、そして「今月のデータから見て、B食品の融資現況の月次報告書を作っておくとよい」という提案が置かれます。審査役には待機案件の優先順位付けとともに、「BB+以上の格付けの標準申請3件が検知されたため、一括審査で迅速に処理できる」という提案が上がってきます。リスク管理者には延滞率の閾値超過警報と、「2024年第3四半期実行分のバッチの延滞率が過去平均を上回っている — ヴィンテージ異常信号」という発見が届きます。

このリストを改めて読むと、共通点が見えてきます。すべて人がいずれにせよやらねばならなかったが、しばしば遅れたり見落としたりしていた種類の仕事 — ざっと目を通すこと、順番を整理すること、異変の兆しに気を配ること — です。そしてもう一つ重要な共通点があります。エージェントのすべての提案は確認要求で終わります。「作成を始めましょうか？」「一括処理を確定しましょうか？」「今すぐ分析しましょうか？」 — 実行の引き金は常に人間の指にあります。拡張ワークプレイスの統制ポイントとは大それたものではありません。まさにこれらの問いかけです。

5.5 一文の魔法：「分析　[企業名]」

CLAWの拡張が最も劇的に現れる瞬間があります。エージェントの対話ウィンドウにたった一文 — 「分析　A電子」 — を入力する瞬間です。

画面には四段階の進行が順に表示されます。企業基本情報を取得中、財務データを分析中、市場シグナルとSNS世論をスキャン中、総合評価報告書を生成中。そしてしばらくすると、企業総合分析報告書が画面に展開されます。

報告書の最初の行は六つの主要指標です。総合スコア、信用格付けと見通し、予想売上高と3年累積成長率、営業利益率と同業他社内での位置づけ、負債比率の適正性、そしてSNS好感度と同業他社平均との比較。その下にセクションが続きます。3か年の財務実績の推移チャート。経営陣評判分析 — CEO、CFO、CTOそれぞれの評判スコアと市場の評価要旨。市場動向とSNS世論分析 — 好意的・中立・否定的な世論の分布、話題語クラウド（デジタルトランスフォーメーション、ESG経営、原材料コスト、規制リスクなど）、直近の投稿のセンチメントと株価の推移。そして最後にこれらすべてを貫く総合分析意見が置かれます。

この一場面が、本シリーズの複数の文章を同時に実演していることを指摘しておきます。第3章は能力ハーネスを「包括的知識と統制ポイントの最小完結単位」と定義しました。「企業総合分析」はまさにそのような能力の一つです。信用・財務・評判・市場・世論という知識のまとまりが定められた手順に従って召集され、結果は人が検討する報告書の形で止まります。第4章はミメーシスを「すべての結論に系譜がある実演」だとしました。報告書の段階別収集過程が画面にそのまま露出しているのは、その系譜感覚がフロント画面へと翻訳された姿です。そして何より、この能力を呼び出す方法がメニューを七回クリックすることではなく自然言語の一文であるという事実 — 相談の電話を受けながら、稟議書を書きかけのまま、会議に入る直前にも呼べる同僚の形であるという事実が、「拡張」という言葉に実感を与えます。

RMの時間単位に置き換えるとこうなります。以前であれば六つ七つの画面を巡って半日かけて集めていた一企業の全貌が、顧客との通話が終わる前に机の上に置かれます。判断は依然としてRMの役目です。ただ、判断の材料が用意される速度が変わったのです。

5.6 拡張の文法：なぜ代替ではなく拡張なのか

ここで一歩下がって、CLAWが取った形そのものを読み解いてみます。このシステムには目立つ特徴が一つあります。既存のワークプレイスの文法をほぼそのまま尊重しているという点です。照会条件と結果テーブル、タブに分かれた詳細画面、入力フォームと試算機 — 銀行員であれば目を閉じても描けるような画面の文法が180ほどの画面に一貫して流れており、AIはその文法を覆す代わりに右側のパネル一つとして静かに入り込んで座りました。

これは技術の限界ではなく意図された設計であり、その理由は三つの層で解くことができます。

最も深い層に置かれているのは信頼の経済学です。第3章の導入の梯子を思い出してください。スキルで積み上げられた信頼だけが、タスクと活動の自律性を正当化します。企業融資は統制されない意思決定のコストが資本規模で測定される領域です。このような領域で初日から判断を機械に委ねる組織はなく、委ねてもなりません。拡張とは、その信頼が積み上がっていく形です。エージェントの要約が正確だったか、優先順位の提案が正しかったか、分析報告書が審査の結論とどれほど一致したか — 日々の業務がそのまま検証の記録になります。

その上に置かれるのは人の居場所に対する誠実さです。CLAWにおいて承認の押印、一括処理の確定、報告書生成の開始は、すべて人の確認を待ちます。これは第3章と第4章で見たHITLチェックポイントの原則 — 「自律性とは人が消えた状態ではなく、人の居場所が正確に設計された状態」 — の実務版であり、規制産業の責任構造とも整合します。監督当局の前で「その与信は誰が承認したのか」という問いへの答えは、常に人の名前でなければなりません。

そして最も外側の層が変化管理の現実です。現場の職場を根こそぎ作り変える導入は、教育コストと抵抗によって崩れがちです。使い慣れた画面はそのままにして傍らに同僚を一人座らせる導入は、初日から使うことができ、最初の週から感謝されるようになります。拡張ワークプレイスは技術戦略である以前に採用（adoption）戦略です。

要するに、CLAWの文法はこうです。画面はそのまま、判断の主は人、AIは要約と優先順位付けと草稿と警報を担う。そしてこの文法が定着した後に初めて — あるタスクにおいてエージェントの打率が十分に証明された後に初めて — 梯子の次の段、タスクハーネスへの昇格が議論されます。

5.7 鉤爪のパターン：この実装例が示すもの

CLAWは実装例ですが、実装例が示すパターンは普遍的です。AOEDEの鉤爪が現場のドメインを掴むときに取る形を、このアプリケーションから四つ抽出することができます。

一つ目のパターンはドメインの全貌を先に登録することです。183画面のレジストリと十一の業務ドメインの地図が先にあり、実装はその座標の上で進められます。代表画面12個が完全に作り込まれ、残りが骨格として登録されている現在の状態は、未完成ではなくMVOのリズムそのものです。第1章の表現を借りれば、「目的地がオントロジーを引き寄せて存在させる」方式です。次に作るべき画面が何かは、地図がすでに知っています。

二つ目のパターンは役割をシステムの第一級概念とすることです。ダッシュボードも、エージェントの挨拶も、インサイトの内容も役割によって分かれます。これは本シリーズを通して積み上げてきた役割アーキテクチャ — テオリアの役割補強、ポイエーシスの役割設計、プラクシスの役割登録 — がフロント画面で実を結ぶ地点です。

三つ目のパターンはエージェントを画面ではなく文脈に内蔵することです。AOEDE-Clawエージェントは特定画面の機能ではなくワークプレイス全体に常駐し、ユーザーの役割・作業キュー・現在の業務ドメインという文脈を常時把握しています。「分析　[企業名]」のようなスキル呼び出しがどの画面からでも可能な理由です。

そして四つ目のパターンは背後のワシと接続する余地を残しておくことです。この実装例のエージェントは実際のAI APIで動作しており（キーがなければデモモードに切り替わります）、その場所はすなわち本シリーズが歩んできた全体スタック — テオリアのオントロジーが根拠を、ポイエーシスのハーネスが統制ポイントを、プラクシスのミメーシスが系譜ある実行を供給する — が差し込まれるソケットです。今日の実装例ではインサイトと分析はデモデータの上で動いていますが、その形は実戦でネクサスに配備された能力ハーネスが満たすことになる形と同じです。鉤爪はワシの末端であって、ワシとは別個の生き物ではありません。

5.8 管理者の目：拡張の成果を何で測るか

拡張ワークプレイスの導入を検討する管理者にとって、CLAWの三つのダッシュボードは成果指標のヒントまで併せて与えてくれます。各役割の「最も高くつく失敗」を裏返せば、それがそのまま測定項目になります。

RM側では見落としの減少です。満期漏れ件数、信用調査期限超過率、そして顧客からの問い合わせから総合情報の回答までの所要時間 — 「分析一文」が短縮するまさにその時間です。

審査側ではボトルネックの解消です。承認待ち日数の分布、標準案件の処理リードタイム、そして一括審査提案の採用率とその正確度が指標になります。

リスク側では発見の早期化です。閾値超過から対応着手までの時間、そしてヴィンテージ異常信号がどれだけ先んじて警報を鳴らしたか（先行日数）を測ります。

これらの指標が実際に使われる場面を想像してみると、その重みが明らかになります。半年後のある昇格審査の場、議題は「企業総合分析能力をタスクハーネスに昇格させるか」です。テーブルの上に置かれるのは担当役員の所感ではなく記録です。過去半年間にこの能力の提案が何件あり、そのうち何件が採用されたか、採用された分析がその後の審査結論とどれほど一致したか、認証試験の点数と有効期間はどうか。記録が厚ければ昇格は自然な流れとなり、薄ければ審査は先送りされます。いずれにせよ、決定の根拠が人の確信ではなく蓄積されたデータであるという点が、この体系の要諦です。

そしてもう一つあります。前節の論理に従えば、拡張段階における最も重要な産出物は効率ではなく積み上げられた信頼の記録です。エージェント提案の採用率と事後の正確度を役割別・能力別に蓄積してください。その記録が十分に厚くなった能力がタスクハーネス昇格の候補となり、第4章で見た認証・熟練度体系がその昇格を公式化する手続きとなります。拡張のダッシュボードは、それ自体が自律化の審査書類というわけです。

5.9 むすびに：ワシが掴む術を学ぶ場所

五章にわたる旅をここで締めくくります。テオリアでビジネスが言語となり、ポイエーシスで言語が三つのサイズのハーネスへと組み立てられ、プラクシスでハーネスがネクサスへ配備され、ミメーシスが系譜を残しながら実行しました。そしてCLAWにおいて、そのすべてが向かっていた地面 — 一人のRMが朝に開く画面、一人の審査役が向き合う待機列、一人のリスク管理者が見守る予警報線 — に鉤爪が触れました。

この鉤爪を任される管理者への言付けは、結局のところ一つの姿勢に集約されます。拡張から始めつつ、拡張にとどまる計画は立てないでください。CLAWの形は梯子の最初の段にすぎませんから、エージェント提案の採用率と正確度を導入初日から記録し、どの能力が次の段へ上がる資格を積み上げているかをデータで把握できるようにすべきです。成果を語るときは総論ではなく役割の言葉を使ってください。見落としとボトルネックと発見の遅れ — 役割ごとに「最も高くつく失敗」を定義し、それを指標とするとき、測定が組織を動かします。

運用が定着していくほど守るべきものは確認要求の文化です。「確定しましょうか？」という問いかけは摩擦ではなく統制ポイントであり、利便性を理由にこの問いかけを取り除こうという要求は必ず出てきます。その要求には当該能力の正式な昇格審査で答えるのが正しく、問いかけの削除で答えるべきことではありません。あわせて、画面の地図をオントロジーとつないでおいてください。183画面のレジストリはそれ自体で優れた資産ですが、この画面がどの業務対象、どのタスクの表面であるかがテオリアの座標と結びついたとき、初めて鉤爪が胴体の神経とつながります。

そして視線を少し遠くに向けてください。第1章は左の鉤爪（専門金融サービス）の傍らに右の鉤爪 — 顧客管理、顧客資産管理、包括的リスク管理 — を描いておきました。CLAWで検証されたパターン、すなわちドメイン登録と役割第一級化と文脈内蔵型エージェントとスタックソケットは、次のドメインでもそのまま再利用されます。次の鉤爪を準備してください。一つの鉤爪の成功は一つの鉤爪の成功で終わるのではなく、掴む術の組織的な学習として残ります。

第1章の最後の文章でこの旅を締めくくるのがよいでしょう。「エンジンに忠実に実行させ、鉤爪に実際の業務を掴ませ、ワシが実際に掴む術を学んだ分だけオントロジーが育つようにしてください。」CLAWはその文章の最後の一節が始まる場所です。鉤爪が掴み、掴んだ経験が記録され、その記録が頭へと昇ってオントロジーを育てる循環 — ワシは今や飛ぶ術だけでなく、掴む術を学んでいる最中です。

第5章の要点：CLAWは企業融資ドメインに対するCLAWSのリファレンス実装であり、183画面のレジストリと11の業務ドメイン地図の上で、役割別（RM・審査役・リスク管理者）のダッシュボードと文脈内蔵型のAI同僚を提供する。設計の重心は代替ではなく拡張であり、すべてのエージェント提案は人間の確認を経て実行される。拡張段階における中心的な産出物は効率ではなく積み上げられた信頼の記録であり、その記録がタスクハーネス昇格の審査書類となる。

第6章. 統合実行ガイド：管理者の机の上で

本章で扱う内容：五つの物語に散らばっていた管理者向けの指針を、一つの実行体系に統合する。導入ロードマップ、組織と役割別の責任、成果指標体系、会議体の運営ルール、そしてよくある質問への回答。

6.1 本章の性格

第1章から第5章までは、それぞれワシの一つの器官を巡りながら物語を展開してきました。各章の終わりには、その器官を担当する管理者に向けた提言が五つから六つずつ置かれていました。本章では、それらの提言を一箇所に集め、導入を実際に主導すべき管理者の時間軸に沿って再配列しています。新しい内容を付け加えるというより、散らばっていたものを実行可能な形にまとめることが目的です。

6.2 導入ロードマップ：拡張から自律へ至る梯子

AOEDEの導入は、技術プロジェクトのスケジュール表としてではなく、信頼が積み上がっていく梯子として設計されています。シリーズ全体を貫くこの原則を導入段階に移すと、次のような流れになります。

準備段階 — 最初の鉤爪と最初のオントロジーを選ぶ。出発点は「自社の全体オントロジー」ではなく、一つの到達点、すなわち一つの能力です。複雑性が高く、根拠が文書にあり、誤った判断のコストが大きい領域 — つまり系譜と統制が切実に求められる領域 — が良い最初の候補です。その一つの能力が信頼できる形で機能するために必要な、最小限のエンティティ、属性、関係、ガバナンスパラメータを定義します。これがMVO（実行可能最小限オントロジー）の出発点です。

第1段階 — テオリアで言語化する。ジェネシス（Genesis）パッケージでリポジトリをブートストラップし、対象業務のビジネスオブジェクトモデルと概念モデルを整え、拡充エディタで知識・ルール・役割・ポリシーを埋め、BPMN・DMNでプロセスと判断を描きます。セマンティック・ファクトリーに実際の規程や契約文書を流し込み、モデルと現実のずれを確認します。この段階の完了基準は「『Poiesisへ提出』ボタンを押せる状態」です。

第2段階 — ポイエーシスでハーネスを組み立てる。ハーネスの規模（スキル・タスク・アクティビティ）をまず合意し、シナリオから規格の整った設計を作り、意思決定テーブルのカバレッジ・重大度の順序・禁止ルールを練り上げ、形式検証・意味検証・模擬実行という三重の試験を通過させます。この段階の完了基準は「飛行記録が添付された配備承認」です。

第3段階 — プラクシスで統治しながら運用する。ネクサスで配備し、ミメーシスが実演する作業の系譜を標本監査し、変更管理・シグナル・監督ルールという三つの道具を稼働させ、認証と習熟度の通帳を積み上げます。この段階に完了基準は特にありません。運用は終わりのない仕事であり、その代わりに次の段階へ進むための根拠がここで積み上がっていきます。

第4段階 — CLAW型の拡張で現場に届ける。鉤爪の四つのパターン — ドメイン登録、役割の一級化、コンテキスト内蔵エージェント、スタックソケット — に従い、現場のワークプレースにエージェントを同僚として配置します。画面はそのまま残し、判断の主体は人のままとし、提案の採択率と正確度を記録します。

第5段階 — 梯子を昇る。採択率と正確度の記録が厚みを増した能力を、タスクハーネスへの昇格候補に挙げ、認証・習熟度の手続きを経て昇格を正式なものとします。タスクが十分に熟せば、アクティビティレベルの自律運用を議論する資格が生まれます。同時に、この鉤爪で検証されたオントロジーとパターンをジェネシスパッケージとして書き出し、次のドメインの種として活用します。

このロードマップをカレンダー上に置いてみると、最初の90日間の見取り図はおおよそ次のように描けます。最初の月には、最初の鉤爪となる能力を一つ選び、その能力のゴールドスタンダード — どのような報告書が出れば成功と言えるか — を現場と合意し、プロセス上の役割にペルソナ名を割り当てます。二か月目には、テオリアでその能力の最小オントロジーを立ち上げて拡充し、実際の規程や契約文書をセマンティック・ファクトリーに流し込んで、モデルと現実の最初の照合を受けます。三か月目には、ポイエーシスでハーネスを組み立てて模擬実行の飛行記録を積み上げ、関門を通過した最初の配備をプラクシスの舞台に載せます。三か月後に経営陣への報告に上がるのは、大げさな転換宣言ではなく、実際に灯った明かり一つ — 機能している能力、その系譜、そして次の区域の地図です。

このロードマップにおいて最もありがちな誘惑は、段階を飛ばすことです。特に「すでに検証された技術なのだから、最初からアクティビティレベルの自律運用に行こう」という要求が必ず出てきます。シリーズの答えは一貫しています。自律性は宣言するものではなく積み立てるものであり、規模の見誤り — 能力で十分な場面にアクティビティ・ハーネスを築いたり、アクティビティが必要な場面に能力だけを与えたりすること — が、この領域における最も高くつく過ちです。

6.3 役割と責任：新たに生まれる管理業務の担当者を決める

AOEDEの導入は、新しい種類の管理業務を生み出します。これらの業務の担当者が決まっていなければ、道具はあっても統治のない状態になります。五つの章の提言から抽出した責任一覧は次のとおりです。

オントロジー・オーナー（テオリア）。オントロジーツリーと概念モデルの管理権限を持ちます。ツリーはあらゆる作業の座標系であり、概念モデルはその座標系の文法にあたるため、文法が乱れれば、その上に成り立つすべての文章が乱れてしまいます。セマンティック・ファクトリーの矛盾報告を定例議題として扱い、モデルと文書のずれを負債としてではなく、オントロジーが成長するための原料として消化するのも、この役割の務めです。

カプセル・ハーネス承認者（テオリア・ポイエーシス）。ドメイン知識カプセルと能力カプセルのライフサイクル（草案 → レビュー → 承認 → 公開）、そしてハーネスパイプラインの関門（受付済み → 作成中 → 検証済み → 配備済み）を守ります。模擬実行記録のない配備承認要求を差し戻すことが、このツールの文化にかなっています。

リスクポリシー担当（ポイエーシス・プラクシス）。意思決定テーブルの保守性原則とデフォルト決定の作成、禁止ルールの規制根拠の補強を、ドメイン専門家の正式な業務として付与します。どのスキルと推論テンプレートがMRM（モデルリスク管理）の対象であるかをリスク部門と共に指定し、指定が終われば変更管理ダッシュボードの待機項目がそのままリスク部門の業務リストになります。

運用監督者（プラクシス）。作業成果物の系譜を標本監査し、認証の失効を月例点検し、約束違反（「違反」状態）の頻度とパターンをハーネスの接合部の健全性指標として追跡します。スロットル回路 — シグナルの重み付けと関門連携 — の定期的な調整もこの役割が主管しますが、政策的判断は与信政策協議会と共に行います。

現場採用リーダー（CLAW）。役割ごとの「最も高くつく過ち」を指標として定義し、エージェント提案の採択率・正確度の記録を管理し、確認要請の文化を守ります。フェデレーション（Federation）に提供する能力と借りる能力のポリシーをあらかじめ定めるという対外ガバナンスの課題も、技術が成熟した後に先送りするのではなく、今この役割と経営陣が共に取り組むべきです。

一人が複数の役割を兼任することは可能です。しかし、いかなる役割も空席であってはなりません。特に初期段階で最も空席になりやすいのが、オントロジー・オーナーです。「モデルはコンサルタントが作って去っていった」という状態のまま運用に入った組織では、オントロジーは半年のうちに古びた文書になってしまいます。

6.4 成果指標体系：何を測り、何を報告するのか

五つの章で言及された測定項目を三つの層に整理すると、次のようになります。

第一層 — 現場効果指標。役割ごとの「最も高くつく過ち」を裏返した指標群です。見落としの減少（満期漏れ件数、期限超過率、総合情報の回答所要時間）、ボトルネックの解消（承認待ち日数の分布、標準案件の処理リードタイム）、発見の早期化（閾値超過から対応着手までの時間、異常シグナルの先行日数）。この層は経営陣報告の言語です。

第二層 — 信頼積立指標。自律性昇格の審査書類となる指標群です。エージェント提案の採択率と事後正確度（役割別・スキル別）、認証試験の点数と有効状態、模擬実行のカバレッジと配置統計、約束違反の頻度とパターン。この層は「次の段階へ進んでよいか」という問いへの根拠です。

第三層 — ガバナンス健全性指標。システム自体の規律が生きているかを見る指標群です。セマンティック・ファクトリーの矛盾報告の発生と処理速度、検証警告バックログ（例：規制条項との連結が不十分な禁止ルール）の消化推移、変更管理待機項目の滞留時間、認証失効の放置件数、能力報告書において「絞って回答した・回答できなかった」として現れたオントロジーの空白区域。この層は運用会議の言語です。

三つの層の指標は、報告の流れにもつながっています。現場効果指標は四半期の経営陣報告の冒頭に置かれ、信頼積立指標は昇格審査の書類となり、ガバナンス健全性指標は月次運用会議のチェックリストとなります。同じデータが三つの異なる会議で、三つの異なる問い — 効果はあるか、さらに任せてよいか、規律は生きているか — に答える構造です。指標を新たに考案する必要はありません。システムが運用の中で自然に残す記録を、三つの筋道で読む習慣さえあれば十分です。

指標体系において、シリーズが特に強調している文化が一つあります。理解報告書を読む文化です。システムが「この部分は絞って回答し、この部分には回答できなかった」と正直に語るとき、その言葉を聞き流さないチームだけが、正直なシステムの価値を余すところなく享受できます。正直な失敗報告は減点の材料ではなく、次に築くべきオントロジーの区域を示す地図です。

6.5 会議体と運営ルール：五つの章の提言をカレンダーに載せる

提言はカレンダーに載って初めて実行されます。五つの章の指針を会議体の観点で再配列すると、次の定例議題になります。

週次 — パイプラインレビュー（ポイエーシス）。進捗報告の言語は、受付済み・作成中・検証済み・配備済み・差し戻しという五つの状態に統一します。何週間も「作成中」にとどまっているハーネスや、「検証済み」と「配備済み」の間のボトルネックが、この会議の関心事です。

月次 — 運用・ガバナンス会議（プラクシス）。失効間近の認証の点検を固定議題とし、変更管理の待機項目、約束違反のパターン、有効なアラートの推移を併せて見ます。重要作業の系譜標本監査の結果も、この場で報告されます。

月次または隔月 — オントロジー協議会（テオリア）。セマンティック・ファクトリーの矛盾報告を定例議題とし、文書とモデルのずれを調整します。MVOとして育っていくオントロジー同士が重なり始める地点 — 例えば、ある能力の「顧客」と別の能力の「借主」が出会う瞬間 — の整理もここで扱います。ハーネスは発見までしかしてくれません。調整は人の務めです。

四半期 — 政策レバー点検（ポイエーシス・プラクシス）。スロットル回路のシグナル重み付けと関門連携を、成果フィードバックとともに再検討し、禁止ルールの規制根拠補強バックログの消化状況を確認します。検証が残した警告リストが、そのままこの四半期の業務リストになります。

四半期または半期 — 昇格審査（全社）。信頼積立指標が十分に積み上がった能力のタスクへの昇格、タスクのアクティビティへの昇格を審査します。審査の根拠は、担当役員の確信ではなく、認証記録と採択率・正確度の蓄積でなければなりません。確認の疑問符を取り払おうという現場からの要求も、この審査を通じてのみ受け入れます。

6.6 よくある質問への回答

導入をめぐる議論で繰り返し登場する質問について、シリーズの論理に沿って回答を整理しておきます。

「オントロジーの整備だけで何年もかかるのではないか」その懸念こそ、MVOがまさに回避しようとしているパターンです。AOEDEは、全社オントロジーを先に完成させるアプローチを明示的に拒否しています。最初の一つの能力に必要な最小限だけを定義し、一つの配備が成功するたびに、オントロジーを一区域ずつ広げていきます。全社オントロジーは目標ではなく、鉤爪が積み重なる中で自然に組み上がっていく結果です。このMVOアプローチの弱点を補うためにシャドウ・オントロジーが導入されており、最初の能力オントロジーの適用の段階から、シャドウ・オントロジーが日の目を見るようにしています。

「AIが捏造した数字で報告書が出てしまったらどうするのか」これは構造的に遮断されています。数字を生成するのはLLMではなく決定論的コンピュートエンジンであり、自然言語による問い合わせは三段構成（A段：言語理解 — B段：検証・コンパイル — C段：実行・検証）のハーネスを通過し、スキーマに結び付かない要素は実行前に除外されます。セマンティック・ファクトリーの抽出処理にも忠実性ゲートがあり、原文に根拠のない項目は保存前に却下されます。重要なのは、この遮断が「AIが行儀よく振る舞うこと」に依存するのではなく、アーキテクチャによって強制されている点です。

「結局のところ人がすべて確認しなければならないなら、効率は出るのか」拡張段階の効率は、判断の自動化からではなく、判断材料の準備速度から生まれます。半日かかっていた企業の全体像の収集が、通話が終わる前に用意されること、見落とし・ボトルネック・発見の遅れが指標として減っていくこと、それがその効率です。そして確認という行為の記録そのものが、次の段階の自律化の根拠となるため、人による確認はコストではなく投資です。

「監査や監督当局への対応はどうなるのか」三つの問いに画面上で答えられる状態にすることが、目標であり設計そのものです。「その数字はどこから来たのか」にはアクション単位の入出力の系譜で、「そのルールの法的根拠は何か」にはルールと規制条項の構造化された連結で、「その行為を行う権限はあったのか」には権限マトリックスと監査記録で答えます。そして最終承認の名義は、常に人の名前です。

「自社のデータ品質で可能なのか」完璧なデータを前提としない点が、このフレームワークの特徴です。セマンティック・ファクトリーはモデルと現実の文書とのずれを見つけ出すための装置であり、出典帰属と不確実性プロファイルは、値がどれほど信頼できるかを値単位で記録します。そして到達点が求める値がまだ存在しない場合、オントロジーは捏造される代わりに、承認者が埋めるべきスロットと決定論的フォールバックとして育っていきます。つまり、データの欠陥は導入を阻む壁ではなく、システムが顕在化させ、人が返済していく管理対象なのです。むしろ、最初の鉤爪の範囲を定める際には、データが比較的整っている領域を選ぶことが現実的なコツです。

「配備済みのハーネスに問題が発生したらどうなるのか」戻ってくるための扉は常に開かれています。すべてのハーネスはブランチとコミットによって履歴が管理されており、過去のバージョンにロールバックできます。配備後の部品の修正は、変更管理レベルに応じて再び関門を通過しなければならず、シグナルとアラートが異常を重大度別に集計します。約束の連鎖のおかげで、どこからずれが生じたかは事後調査ではなく台帳照会の問題であり、系譜のおかげで、問題となった結論の原因となったアクションまで遡ることができます。出て行く扉は狭く、戻ってくる扉は開いている構造 — 配備統制の定石がそのまま実装されています。

「既存システムを刷新しなければならないのか」CLAWのパターンがその答えです。使い慣れた画面の文法はそのまま残し、AIは右側のパネル一つに収まって座ります。拡張ワークプレースは、技術戦略である以前に採用戦略であり、総入れ替え型の導入が教育コストと抵抗によって頓挫するという現実を正面から反映した設計です。CLAWは既存システムをそのまま残し、企業のオントロジーを活用して既存の従業員の能力を拡張するように設計されています。ここでAIエージェントは、有能な協力者として画面の片側に座り、人間の作業者の能力を増幅させます。

6.7 むすびに：日々の飛行

本文書の冒頭に置かれていた問いに立ち返りましょう。自ら判断し行動するソフトウェアに、行動する自由と信頼できる規律を、どのようにして同時に与えるのか。

五つの章を経てきた今、答えは一つの構造に要約されます。見える範囲だけオントロジーを定義し（テオリア、MVO）、行動できる範囲だけエージェントを作り（ポイエーシス、三つの規模のハーネス）、すべての行動を統制とガバナンスに結び付け（ネクサス、プラクシス）、エンジンに忠実に実行させ（ミメーシス、系譜）、鉤爪に実際の業務を掴ませ（CLAWS、拡張）、実際に掴む術を学んだ分だけオントロジーを成長させる（循環）。

そして、この構造は一度の決断で完成するものではなく、日々の運用によって維持されます。テオリアで定義し、ポイエーシスで組み立て、プラクシスで統治し、鉤爪で記録する日々 — それがワシの飛行です。

最後に一つだけ付け加えます。本文書が長く語ってきたことは、結局のところ技術ではなく組織の習慣です。矛盾報告を議題に載せる習慣、飛行記録のない承認を差し戻す習慣、疑問符を守り抜く習慣、正直な失敗報告を地図として読む習慣。道具はこうした習慣が根づく枠を用意してくれるだけであり、その枠を満たすのは常に人です。エージェンティックAIの時代に組織が備えるべき競争力があるとすれば、それは最も賢いモデルを選ぶ目利きではなく、こうした習慣を地道に守り続ける筋力でしょう。本文書が、その筋力を鍛えるための一助となる教範となることを願っています。

第6章の要点：導入は、準備（最初の鉤爪の選定）→ 言語化（テオリア）→ 組み立て（ポイエーシス）→ 運用（プラクシス）→ 拡張（CLAW）→ 昇格という梯子をたどります。オントロジー・オーナー、承認者、リスクポリシー担当、運用監督者、採用リーダーという五つの役割に空席があってはならず、成果は現場効果・信頼積立・ガバナンス健全性という三つの層で測定します。提言はカレンダーに載って初めて実行され、自律性の拡大は常に記録の蓄積の上で審査されます。

付録A. 用語集

本付録は、本文に登場する主要用語を管理者の言葉で解説したものです。正式な定義ではなく理解を助けるための実務的な説明であり、本文で初めて登場する文脈と併せてお読みいただくことをお勧めします。

AOEDE (Agentic Ontology Envisioning and Deployment Environment) エージェンティックAIを企業に導入するための全体フレームワーク。オントロジー定義（テオリア（THEORIA））、ハーネス組み立て（ポイエーシス（POIESIS））、運用統制（プラクシス（PRAXIS））、現場適用（CLAWS）を一つの一貫した構造にまとめ、全体アーキテクチャを翼を広げたワシに対応させる。

エージェンティックAI（Agentic AI） 定められた手順のみを繰り返す自動化とは異なり、目標を受け取り自ら状況を判断し行動を選択するAI。自由と規律を同時に設計すべき対象であり、本文書全体のテーマである。

オントロジー（Ontology） 自社の業務領域にどのような対象が存在し、それらがどのように関連し、「意思決定」と「根拠」が何を意味するのかを、コンピュータが理解できる構造で記述したもの。ビジネスの公式な地図であり、公式な辞書。

テオリア（THEORIA） ワシの頭部。オントロジーが定義・拡充・検証される場所であり、フレームワーク全体の判断が始まる概念的中心。Webアプリケーション（テオリア・クライアント）とAOEDEオントロジーサーバーの二層構造で実装される。

ポイエーシス（POIESIS） ワシの左翼、「作る翼」。オントロジーで定義された業務を、実行可能なエージェント・ハーネス（アクティビティ・タスク・スキルの三つの粒度）へと組み立てる場所。対象ユーザーは開発者ではなく、ビジネスアナリストと業務設計者である。

プラクシス（PRAXIS） ワシの右翼、「治める翼」。デプロイされたハーネスの中でエージェントが実際に働く舞台であり、実行のモニタリング・変更管理・認証・監督ルールを担う。

ネクサス（NEXUS） ハーネスが記録される規格であり、「作る翼」と「治める翼」がやり取りする契約文書の形式。CC-DSL専用言語で記述され、97種の定義要素と28種の連結関係により、一つのエージェント組織を漏れなく記述する。一つの原本から、要求仕様・プロセス・データフロー・ガバナンスなど七つの視点が機械的に派生する。

ミメーシス・エンジン（MIMESIS ENGINE） ネクサスを実行する決定論的な実行ドライバー。「忠実な再現」という名の通り結果をでっち上げることなく、すべてのアクションの入力と出力をペアで保存し、あらゆる結論についてダウンロード可能な系譜を残す。

CLAWS／CLAW CLAWSは、フレームワークが実際のビジネスと接する接点（かぎ爪）の総称。CLAW（Corporate Loan Augmenting Workplace）はその中でも法人融資ドメインの実装例であり、「拡張ワークプレイス」のパターンを示す。

ハーネス（Harness） AIという知能に装着する馬具。何を知るべきか、何ができるか、どこまで進んでよいか、どこで必ず止まるか、あるいは人に委ねるかが編み込まれた構造物。AOEDEにおいて「エージェントを作る」とは、すなわち「ハーネスを編む」ことを意味する。

ハーネスの三つの粒度（アクティビティ・タスク・能力） アクティビティ・ハーネスは業務フロー全体の自律運用を、タスク・ハーネスは一つの役割の特定タスクの代行を、能力ハーネスは人の能力拡張を目標とする。三つは入れ子構造になっており、導入は能力→タスク→アクティビティのはしごを上る。

MVO（Minimum Viable Ontology、実行可能最小限オントロジー） 「まず全体のオントロジーを完成させる」というアプローチを拒み、今必要な能力を一つ、信頼できるものにするために必要な最小限だけを定義する方法論。デプロイが成功するたびに、オントロジーが一区画ずつ育っていく。

能力カプセル（Capability Capsule） ガバナンスが組み込まれた、それ自体で完結する能力単位。ゴールドスタンダード・レポート、スキル、推論、エンティティモデルとデータ契約、ソリューションツリー、決定論的コンピュートエンジン、シグナルとギャップ検知器、回帰テストのフィクスチャ、そして人の判断のための明示的スロットを含む。

メタオントロジー／会社オントロジー オントロジーの二つの層。メタオントロジーは「#」が付くメタオブジェクトの世界であり、会社に関する知識を記述するための文法である。会社オントロジーは、その文法で記述された自社の実物モデルである。この二つの平面を混同することが、誤答の典型的な原因となる。

ジェネシス（Genesis） 二つの意味を持つ名称。一つは概念エディタの名前、もう一つは業務対象の定義とビジネスオブジェクトモデル図を含む可搬パッケージ形式。検証済みのオントロジーをエクスポートし、新しいリポジトリをブートストラップするための種であり、運搬用の器でもある。

セマンティック・ファクトリー（Semantic Factory） Wikiに添付された文書（規程集、契約書、マニュアル）からエンティティ・事実・関係を抽出し蓄積する工場。すべての事実に出典が付与され、原文の根拠がない項目は忠実性ゲートで却下され、文書とオントロジーの矛盾を検知して人によるレビュー案件とする。

拡充（Enrichment） オントロジーツリーという骨格に肉付けを行う作業。業務対象の属性と意味、ドメイン知識、決定ルール、役割・スキル・ツール・ガバナンスポリシーを構造化データとして満たす。AIエージェントという新しい「従業員」の職務記述書を書くことに相当する。

CVR（顧客価値実現）エディタ 顧客ジャーニー・タスク定義・アイデア創出・バリューフロー設計・エージェント機会・QFD・実現度測定の七段階で顧客活動を扱うエディタ。デザインシンキングの言語を用いつつ、成果物はオントロジーとエージェントポートフォリオに直結する。

モデル・ハーネス／実行ハーネス テオリアを支える二つのハーネス。モデル・ハーネスはオントロジーモデル自体の整合性（文法、推論エンジン、境界と履歴、矛盾検知）を守り、ボトムアップの成長が混乱に陥ることを防ぐ。実行ハーネスはAIの自然言語クエリの実行を三段構造で統制し、システムが問題生成器になることを防ぐ。

三段実行ハーネス（A段・B段・C段） A段（言語理解）ではLLMが自然言語を形式化されたクエリ計画へと翻訳するが、その出力は信頼されない。B段（検証とコンパイル）では決定論的コードが計画のすべての要素を生きたスキーマに束縛し、束縛できない要素は排除され、読み取り専用かつ上限が設定されたクエリのみが生成される。C段（実行と検証）では批評エンジンが結果を検査し、有限回数の範囲内で再試行する。

理解レポート（Comprehension Report） 質問のうち何がそのまま実行され、何が絞り込まれ、何がなぜ除外されたのかを明示する成果物。システムができないことを黙って省いて答える代わりに、できなかったと言わせるための仕組み。

デジタルツイン（Digital Twin） ビジネスの構造・知識・状態をコンピュータが理解できる形で映し出し、問えば根拠をもって答え、変更すれば波及効果を示してくれる生きた対応物。一度の大工事ではなく、六つの段階（種をまく→定義平面→肉付け→証拠の連結→グラフとして目覚める→増殖）で築かれる。

BPMN／DMN 業務プロセス（BPMN）と意思決定テーブル（DMN）の国際標準表記法。テオリアで描かれるこれらの図は参考資料ではなく、エージェントが実際に従うことになる規格である。

意思決定テーブルの三つの規律 カバレッジ（すべての入力の組み合わせに判断が存在すること――デフォルト決定を含む）、重大度順序（複数のルールが競合する場合は最も保守的な決定から適用）、禁止ルール（「この条件ではこの決定が絶対に出てはならない」というルールの機械的強制）。住宅担保ローンの例では、1,410通りの入力組み合わせの全数分析により、多値ケース97件と未網羅ケース897件が明らかになり、禁止ルール194件が導出された。

スロットル（Throttle） 自律運用されるアクティビティ全体の保守性と積極性を調整するポリシーレバー。市場・延滞・運用シグナルが加重合算されてスロットルスコアとなり、各ゲートの承認閾値と保守性バイアスに変換され、成果が再びシグナルへと戻る閉じたループである。

HITL（Human-in-the-Loop）チェックポイント 人が介入する地点。アクティビティ・ハーネスにおける自律性とは、人がいなくなった状態ではなく、人の居場所が正確に設計された状態を意味し、HITLチェックポイントはその居場所を第一級の設計要素として宣言したものである。

約束のリング（要求済み→コミット済み→報告済み→受諾済み） 言語行為理論に根ざしたトランザクションの四つの相。あらゆる事柄に要求した者とコミットした者が存在し、コミットメントには有効・履行済み・違反・取消の状態があるため、責任の追跡が事後調査ではなくデータ構造そのものになる。

エージェントロジー（Agentology） エージェント能力の八分類――認知、知識、メモリ、推論、インタラクション、学習、ペルソナ、プレゼンテーション――と、入出力双方に設けられた七層の安全フィルター。登録されていない能力はハーネス内に存在しないという原則の運用面での実装。

能力（Capability）とコンピテンシー（Competency） 能力はビジネス層――ビジネス価値を生み出す仕事（「担保評価を行う」）を指す。コンピテンシーはエージェントロジー層――エージェントの認知能力（「文書からエンティティを抽出できる」）を指す。この二つの層を区別するための語彙。

MRM（Model Risk Management、モデルリスク管理） 規制が要求するモデル検証手続き。プラクシスの変更管理レベル（自由変更――レビュー要――MRM要）の中で最も重い段階であり、対象の指定は技術的判断ではなく規制対応上の判断である。

認証と習熟度 エージェントスキルの習熟度の四段階（未訓練・初級・熟練・エキスパート）と、テストスイートの受験によって証明され有効期限を持つ認証制度。自律性の拡大が担当役員の確信ではなく、認証記録の積み重ねの上で決定されるようにする信頼の通帳。

フェデレーション（Federation）／A2A 組織の壁の外にあるエージェントと、標準プロトコル（A2A、エージェント間通信）で接続される体系。他組織のエージェントがエンドポイントとともに登録され、自社のハーネスが持たない能力を条件に応じて呼び出すことができる。

RM（Relationship Manager） 法人顧客を担当する営業・リレーションシップ管理担当者。CLAWの三つのペルソナ（RM、本部審査役、リスク管理者）の一つ。

NPL（Non-Performing Loan）／ヴィンテージ分析 NPLは不良債権。ヴィンテージ分析は融資を実行時期別のグループに分け、各グループの延滞率カーブを追跡する手法であり、特定時期の実行分に生じる異常シグナルを早期に浮かび上がらせる。

拡張ワークプレイス（Augmenting Workplace） 既存の画面文法を尊重しながら、AIを文脈組み込み型の同僚として配置する導入形態。画面はそのまま、判断の主体は人、AIは要約・優先順位付け・草案作成・アラートを担い、すべての提案は人の確認を経て実行される。

付録B. 五つの章を貫く文章

本文の随所に置かれていた重要な文章を一箇所に集め、それぞれの文章がどのような文脈から生まれ、管理者に何を求めているのかを簡潔に振り返ります。会議資料や研修資料で引用する際、本付録が索引の役割を果たせるでしょう。

「オントロジーなしに動くエージェントは自律的なのではなく、単に責任を問えない存在にすぎない。」 第1章、頭部に関する文章です。エージェンティックAIの導入順序を定める文章でもあります。この文章が求めているのは完璧な全社モデルではなく、エージェントが足場とするだけの言語――その業務領域の対象と関係と判断基準の定義――が自動化に先立って存在すべきだという順序の規律です。

「統制なしに作ることだけを行う組織はリスクを大量生産し、作ることなく統制だけを行う組織は何も生み出せない。」 第1章、二つの翼に関する文章です。導入をめぐる議論がスピード重視派と慎重派に分かれるとき、双方に向けて投げかけられる文章であり、AOEDEがこの対称性をスローガンではなく、同一のサーバーと同一のデータベースを共有するアーキテクチャとして実装していることが、この文章の裏付けとなります。

「目的地がオントロジーを引き寄せ、存在させる。」 第1章、MVOに関する文章です。「自社ビジネスの完全なオントロジーとは何か」という問いを「この一つの能力を信頼できるものにするために必要な最小限のオントロジーとは何か」に置き換えた瞬間、何年もかかるモデリングの大工事は、四半期単位で灯りをともしていく建設へと姿を変えます。

「正確な答えと、もっともらしく見える誤答との違いは、階層の規律から生まれる。」 第2章、二層のオントロジーに関する文章です。モデルに関する定義的な問いと、データに関するインスタンスの問いを混同することが誤答の典型的な原因であり、システムがこの二つの平面を構造的に区別していることが、回答への信頼の基盤となります。

「モデル・ハーネスのないボトムアップは速く始まって速く泥沼にはまり、モデル・ハーネスのあるボトムアップこそが初めてMVOの名に値する。」 第2章、最初のハーネスに関する文章です。小さく始めるという合意だけでは不十分であり、小さく育っていく断片を文法と推論エンジンと履歴と矛盾検知によって統御する手が同時に必要だという条件を付け加えます。

「手綱のない目標志向エージェントは、目標に向かって真面目に事故を起こす。」 第2章、二つ目のハーネスに関する文章です。エージェントリスクの本質が悪意ではなく統制されない真面目さにあるという洞察であり、それゆえ解決策も訓戒ではなく構造――信頼境界を挟んだ三段の実行ハーネス――であるべきだという結論につながります。

「システムはできないことを黙って省いて答える代わりに、できなかったと言う。」 第2章、理解レポートに関する文章です。正直なシステムの価値は、その正直さを読み取る組織においてのみ実現されます。「絞り込んで答えた」という告白を、次に築くべき区画の地図として読み取る文化が、この文章のもう半分です。

「ポイエーシスにおいて『作る』とは、すなわち『ハーネスを編む』ことである。」 第3章の最初の文章であり、このフレームワークにおける「制作」の定義を変える文章です。賢い知能は市場から調達し、組織が構築するのはその知能が自社の業務の中でどこまで進み、どこで止まるかという構造物である、という役割分担がここで確定します。

「自律性は宣言するものではなく、小さなハーネスから積み立てていくものである。」 第3章、三つの粒度のハーネスに関する文章です。能力からタスクへ、タスクからアクティビティへと上るはしごの各段は、結局のところ信頼の問いであり、その信頼は確信ではなく記録――採用率、正確性、認証――によって積み立てられます。

「エージェントに『何をすべきか』だけを教える組織と、『何を絶対にしてはならないか』までを強制する組織との間には、リスク等級の差がある。」 第3章、禁止ルールに関する文章です。カバレッジ、保守性の順序、禁止ルールという三つの規律が、「正しいやり方でのみ物事が行われる」という希望を、数学的に検証可能な性質へと変えます。

「実行して確かめていない主張には、タグが付く。」 第3章、模擬実行に関する文章です。デプロイ承認の議題が担当者の意見から飛行記録へと変わる文化、そして模擬実行のない承認申請を差し戻す慣行が、この文章の実務版です。

「文書と実際が異なるという古くからの病は、文書がすなわち実際であるという構造によって治癒される。」 第4章、ネクサスに関する文章です。要求仕様書、プロセス図、データフロー図、統制マトリクスが、一つの原本から機械的に派生する七つの視点であるとき、互いに食い違う四枚の紙という光景は原理的に消滅します。

「すべての結論に系譜があり、その系譜はダウンロードボタンとして存在する。」 第4章、ミメーシス・エンジンに関する文章です。「その結果はどうやって出たのですか」という問いが、開発チームへの問い合わせではなく、タブを一つ開くだけの行為になる状態――監査対応の観点から、このフレームワークが約束する到達点です。

「責任の追跡は事後調査ではなく、データ構造である。」 第4章、約束のリングに関する文章です。要求され、コミットされ、報告され、受諾されるという四つの相、そして「違反」という状態値があるからこそ、複数のエージェントが絡む事故においても、どこから食い違いが生じたのかは台帳照会の問題になります。

「ここでAIは審査役を代替しない。審査役の隣に座る。」 第5章、CLAWの設計思想に関する文章です。拡張という選択は技術の限界ではなく、信頼の経済学と責任構造と変革管理を併せて計算した結果であり、それゆえ拡張ワークプレイスは技術戦略である以前に採用戦略なのです。

「判断は依然として人の役割である。ただし、判断の材料が用意される速度が変わったのだ。」 第5章、「分析一文」に関する文章です。拡張段階の効率がどこから生まれるのかを正確に指し示す文章であり、効率指標を設計する際に何を測るべきか――判断の代替率ではなく、材料準備の速度と見落としの減少――も同時に教えてくれます。

「確認のクエスチョンマークは摩擦ではなく、統制ポイントである。」 第5章、エージェントの確認要求の文化に関する文章です。利便性を理由にクエスチョンマークを取り除こうという要求は必ず出てきますが、その要求に対しては、クエスチョンマークの削除ではなく、当該スキルの正式な昇格審査をもって応えるのが正しいあり方です。

「拡張のダッシュボードは、それ自体が自律化の審査書類である。」 第5章、成果測定に関する文章です。今日の採用率と正確性の記録が明日の昇格根拠となる循環――拡張段階で記録を積み上げない組織は、次の段階へ上るはしごを自ら取り払っているに等しいのです。

これらの文章を改めて読み返すと、一つの共通した基調が聞こえてきます。どの文章も技術の驚異を誇っていません。代わりに、順序と規律と記録を語っています。エージェンティックAIの時代に組織が新たに学ぶべきことがあるとすれば、それはより大きなモデルの名前ではなく、この基調――自由を与えながらも系譜を残し、スピードを出しながらも関門を守る姿勢――でしょう。

お読みいただきありがとうございます。ご不明な点がございましたら、[email protected] までご連絡ください。