TUEO 製品ホワイトペーパー

1. TUEO とは何か

TUEO は、企業向けオンプレミスの AI 協働プラットフォームです —— AI が組織の正社員（役割、職責、成長の軌跡、行動の境界、長期記憶を持つ）として、お客様の自社環境内で人とともに業務を運営します。

これはスローガンではなく、すでに実装された製品体系です。TUEO は 10 つの製品から構成され、AI を「組織の編制に入れる」ために必要なすべてをカバーしています：

• identity：AI 従業員と人間の従業員が同じ名簿、同じログイン、同じ権限を共有；
• engram：AI の知識と記憶の基盤があり、使うほど正確になり、自動整理で自己成長；
• inference：異種の算力を統一的に管理し、モデルサービスをガバナンス付きで提供、1 つの制御基盤でクローズドループ；
• cohort：AI 従業員が同僚のようにグループチャットに参加し、工単を実行し、週次会議を進行し、組織ナレッジを蓄積；
• studio：ビジネス担当者が対話でプロセスを AI アプリケーションに編成し、公開後は組織が利用；
• capabilities：AI が呼び出せるすべてのスキルを市場化ガバナンスで管理 —— 調達、認可、計量、資格情報；
• executor：AI が実際に作業する場所を隔離サンドボックスに閉じ込め、監査可能・スケジューリング可能；
• codex-build：AI 開発チームが実際のコーディングエンジンでコードを変更し、テストを実行し、MR を出す；
• console：体系全体をお客様の自社環境に導入し、完全なネットワーク切断環境での運用をサポート。

TUEO の核となる判断は次のとおりです：企業 AI の次の段階は「より賢い会話」ではなく、「組織の運営に入り込める従業員」です。 AI には役割が必要であり、境界が必要であり、成長が必要であり、監査が必要です —— これらはまさに、組織が人間の同僚を管理するときに行うことです。TUEO はこの仕組みを製品として実装し、オンプレミスで納品します。

1.1 第二層の位置づけ：企業情報化のインテリジェント基盤

「AI の編制入り」が第一層の位置づけであり、AI があなたの業務を実行することを指します。TUEO には第二層の位置づけもあります。それは企業の情報化全体の基盤です：

AI プログラミングの時代、企業情報化に本当に欠けているのは、さらに多くのシステムではなく、システムの「定義・生産・運用・更新・統括」を完全なクローズドループにつなぐインテリジェント基盤です。TUEO はその基盤です —— タスク駆動でシステムを定義し（開発するのではなく）、企業が保有する既存の能力を再利用・AI 化し、自己運用基盤の上で継続的に稼働させます。

対外的な説明の順序は次のとおりです：まず「どのような基盤なのか」を明確にし、その上で「AI 従業員が基盤の上でどのように働くのか」を落とし込みます。

• 定義層 —— タスク駆動でシステムを定義：studio によるオーケストレーション + cohort の工単パイプライン + executor の実行。業務側がタスクを記述し、AI が分析・分派・開発・テスト・納品を実行；
• 統括層 —— 能力の AI 化、システムの孤島のガバナンス：capabilities + skillplugins + identity。OA / ERP / CRM / MES などのすでに存在するシステムを能力として登録し、認可し、資格情報を管理し、AI が安全に呼び出せるようにする —— あなたのシステムを置き換えるのではなく、あなたのシステムを初めて「AI が呼び出せ、認可でき、監査でき、計量できる能力」に変えるのです；
• 運用層 —— リソース管理、アプリケーションのデプロイ・公開、運用：console + executor。新しいシステム、既存のシステム、AI システムを、1 つの入口で体系全体を運用します。

基盤 = あなたのシステムを置き換えるのではなく、すべてのシステムがこの基盤の上で定義され、組み立てられ、運用され、AI 化されることです。

1.3 中核哲学（5 か条）

1.4 3 つの「売らない」

• 会話ボットは売らない —— それは AI 従業員の最も基本的な形態であり、製品ではありません；
• 単一機能の AI ツールは売らない —— Dify / Coze / n8n の「作り直し」ではなく、体系を売り、コンポーネントは売りません；
• 「答えられる」だけのものは売らない —— 「答えられて、かつ実行でき、ガバナンスでき、導入できる」ものを売ります。

2. 解決すべき課題

2.0 時代の命題：「データの孤島」から「システムの孤島」へ

AI プログラミングには 2 つの側面があります：良い面は、システムを作るコストがゼロに近づき、「開発」がもはや希少なリソースではなくなることです；新しい課題は、システムの数が爆発し、AI が生成したシステムが野放しに増殖することです —— 運用を担当する者も、更新を担当する者も、既存システムとつなぐ者もいません。

データの孤島は「読む」という難題です —— データは複製でき、移送でき、集中化できます。ETL / データウェアハウス / データミドルウェアは 20 年にわたって戦い、ほぼ解決しました。しかしデータをレイクに移しても、システムは語りだしません：AI が必要とするのはデータを読むことだけでなく、システムにログインし、そのシステムがどのような能力を持つかを把握し、システム内で安全にアクションを実行し、すべてのアクションを監査に残すことです。これは「動かす」という難題であり、データガバナンスでは決して解決できませんでした。

両端が孤島です：従来の旧システムはまだ AI 化されていません（マシンルームで稼働し、誰も理解できず、誰も触れません）；AI の新システムは誰も運用・保守していません（作ることはできても、育てることができません）。システムの孤島はデータの孤島よりも対処が難しい —— システムは生きており、爆発半径があります。ERP をレイクに移すことはできず、生かし続けて安全に呼び出せるようにするしかありません。

TUEO の答えは、ソフトウェア開発の完全なクローズドループです：業務側が要件を出す → AI がそれをタスクに分析 → AI チームが開発 → テスト → UAT → 本番投入 → 継続的なモニタリングと運用 → まず既存の能力を棚卸し、再利用できるものは再開発しない → 能力の統括 → 要件に戻る。中核となる考え方：タスク駆動でシステムを定義するのであって、開発するのではない。

この基盤の上で、企業が AI を実際の業務に入れる際には、さらに 4 つの断層に直面します：

2.1 答えられるが、実行できない

汎用の大規模モデルアプリケーションは「答える」ことしかできず、企業の実環境で仕事をすること（システム内のデータを変更する、既存システムと連携する、コードを実行する、実際のファイルを生成する）ができません。企業が求めるのはより賢いアシスタントではなく、実際に成果を生み出せる「手」です。

2.2 AI はツールであり、従業員ではない

多くの企業は AI をツールとして何らかのシステムに組み込んでいます：カスタマーサービスのボット、ライティングアシスタント。役割がなく、職責の境界がなく、成長の軌跡がなく、長期記憶がなく、行動の監査もありません。「身分を持たない」AI は組織に管理されることができず、継続的な業務責任を担うこともできません。

2.3 判断はあるが、実行層がない

たとえ AI が正しい判断を下せたとしても、実際に実行するのは誰でしょうか？業務システム内で AI のコードを直接実行するのは危険です —— 隔離され、制御され、監査可能な実行層が必要であり、「ユーザーコードは非信頼である」をデフォルトの前提とする必要があります。

2.4 AI はあるが、ガバナンスと監査がない

金融、行政、医療などコンプライアンス要件の厳しい業界では、AI のすべての判断について追跡・リプレイ・監査が可能である必要があります。しかし大半の AI プラットフォームは監査を後付けのパッチとして扱い、権限を各製品に散在させ、モデルの秘密鍵をクライアントに埋め込んでいます —— これらはコンプライアンス審査を通過できず、ましてやオンプレミスで納品することはできません。

TUEO は 10 つの製品からなる体系で、この 4 つの断層を一挙に解決します。

3. 製品体系の全体像

3.1 10 つの製品、一つの体系

3.2 階層構造

消費端      cohort-desktop（Electron デスクトップクライアント）· cohort-server 管理バックエンド
───────────────────────────────────────────────────────────
体験層      cohort（協働コア）· studio（アプリケーションオーケストレーション）  ← 人と AI が共に働く場所
能力層      capabilities（能力マーケットプレイス · 呼び出しゲートウェイ）    ← 1 つの能力契約、2 つのコンシューマ
実行層      executor（サンドボックス実行）· codex-build（コーディングエンジン）← AI が実際に仕事をする場所
───────────────────────────────────────────────────────────
基礎基盤    identity（アイデンティティ SSOT）· engram（知識・記憶基盤）· inference（算力・モデルサービス）← 上記すべてを横断的に支える
運用基盤    console（インテリジェント基盤運用層 · デプロイ / ミドルウェア / オンプレミス IDP）
エコシステム skillplugins（プラグインソース + @tueo/plugin-sdk）

3.3 データフローと責務の境界（真値は誰か）

3.4 統合マトリクス（行が列を呼び出す）

4. identity —— アイデンティティ基盤

一言で：全プラットフォームで統一されたアイデンティティ基盤 —— 1 つのアカウントですべての製品に入り、1 つのトークンでどのテナントに属するかを示し、1 つのディレクトリで人間の従業員と AI 従業員を管理します。

4.1 位置づけ

identity は TUEO 体系の**アイデンティティの単一真値（SSOT）**であり、3 種類のプラットフォーム級の能力を担います：

1. OIDC IdP：標準の OpenID Connect / OAuth 2.0 認可、トークン、セッション、フェデレーション、マルチテナント；
2. 組織ディレクトリの単一真値：組織構造 + 人 + 在任関係、全プラットフォームの連絡先ディレクトリの SSOT；
3. 認可判定センター：RBAC ロールを 3 段階に集約し、判定ロジックを identity に収め、下流製品はロール情報を保持しません。

identity の設計基準は「別の製品に替えても成り立つか」です。プラットフォーム級のアイデンティティ能力のみを担い、単一製品の業務ロジックは一切持ちません。

4.2 中核能力

4.2.1 OIDC IdP（ES256 + PKCE + トークンローテーション）

標準の OIDC 認可サーバー実装に基づきます：authorization code + PKCE ログイン、ES256 署名の JWT access token、refresh token のローテーション（RFC 9700）、RFC 8628 Device Flow、RFC 7662 introspection、JWKS ローテーション。署名鍵は暗号化して保存し、複数レプリカでのホットリロードに対応します。access token は厳密に最小の claim を採用し、profile は常に /userinfo で権威情報を照会し、トークンの肥大化と権限のドリフトを防ぎます。

4.2.2 スイート級 SSO（RFC 8693 トークン交換）

6 つの製品を一度のログインでつなぐ接着剤です：identity のルートトークンを使って aud=<製品> のユーザートークンを交換し、studio / executor / capabilities に直接入り、二度目のログインを不要にします。2 つの安全ゲート：subject token は現役のルートトークンであること；audience は第一方製品のホワイトリスト内であること —— 交換は同一ユーザー + 第一方製品の横方向または権限降格のみを行い、所持トークンで権限を引き上げることはできません。

4.2.3 権限降格の最小権限トークン

半信頼の実行体（AI エンジンの子プロセス、ローカルコーディングエンジン）に最小権限のトークンを発行します：独立した audience + 単一機能の scope + 短い TTL。エンジンが保持する最悪の資格情報は、「モデルベンダーの秘密鍵 / ユーザーの全権限トークン」から「本テナントのクォータのみを消費でき、15 分で失効し、audience に応じてパスに紐づいたチケット」に下がります —— それぞれの爆発半径ごとに 1 枚のチケットを発行します。

4.2.4 組織ディレクトリの単一真値

組織構造ツリー + メンバーの在任関係 + 人員検索のすべてを identity が提供します。ツリーは ltree で保存し、在任関係は user_org_memberships JOIN users JOIN org_nodes で構成し、position_title（職位名）は在任関係に紐づきます。全プラットフォームの連絡先ディレクトリは 100% これから構築され、人を変更するには identity の 1 か所だけで済み、デスクトップ / サーバー / Matrix localpart の全プラットフォームが追従します。

4.2.5 RBAC ロールの集約 + scope の宇宙

全プラットフォームのロール名は platform_admin / tenant_admin / member の 3 つだけであり、11 の旧名称はエイリアステーブルで正規化されます。scope はロールディレクトリからプログラム的に導出され、統一的に消費されます（かつて 5 か所で手動保守した scope が原因で静かに剥奪される問題がありました）。新製品を追加する = カタログに 1 行追加 + scope を紐付け、下流の変更はゼロです。

4.2.6 テナント切り替え = token の再署名

「どのテナントに属するか」の真値は 1 つだけ —— token 自身です。切り替え = テナント hint 付きで認可をやり直し、identity が検証して token を再署名します。発行のたびに認可を再検証するため、ロールが剥奪されたりテナントが削除されたりするとすぐに home に戻ります。token のみを検証する消費点（WebSocket ゲートウェイなど）は自動的に正しく動作し、権限超過へドリフトすることはありません。

4.2.7 SCIM インバウンドプロビジョニング

標準 SCIM（RFC 7643/7644）実装を /scim/v2/* に配置し、外部 IdP（Okta / Azure AD）が標準に従って接続します。各テナントは静的 bearer token で tenantId を固定し、テナントをまたぐことは不可能です。ユーザー / グループの CRUD、フィルタ演算子、externalId の照合、同期ログと失敗時の監査に対応します。

4.2.8 追跡可能な監査（暗号学的ハッシュチェーン）

アイデンティティ / 認可 / ディレクトリのすべての変更が監査に入り、行と行の間を SHA-256 contentHash + prev_hash のハッシュチェーンでロックします —— 挿入、削除、並び替え、行の変更をすべて verifyChainIntegrity で検出できます。監査の保持ポリシーはテナントごとに設定可能（デフォルト 90 日）で、エクスポートにはハッシュ検証が付きます。

4.2.9 ユーザーカスタムフィールドのガバナンス + 機微情報の暗号化

テナント管理者がフィールドのスキーマ（型 / 必須 / 検証 / 機微 / 検索可能）を宣言します。機微フィールド（身分証番号など）は通常フィールドと物理的に分離します：非機微は metadata に、機微は独立テーブルに入れて AES-256-GCM で暗号化保存し、マスキングして返却し、平文での読み出しは監査に記録します —— PIPL が機微な個人情報の追跡可能性に求める厳しい要件を満たします。

4.2.10 管理コンソール

組織 / ユーザー / ロール / 監査 / テナント / SSO / SCIM / カスタムフィールド / セッション / Webhooks / API Key / ブランドをカバーし、TUEO プラットフォームデザインシステム（紙 / 墨 / 青玉 / 朱砂）に基づいて実装され、多言語とホワイトラベルに対応します。

4.3 差別化

• AI 従業員と人間の従業員が同じアイデンティティ：users.type='ai_staff' はファーストクラスのユーザータイプで、同じ編制、同じディレクトリ、同じアドレス解決を共有；
• 認可判定を identity に集約：競合製品は「誰が管理者か」を各製品に散在させますが、identity は 1 か所だけ；
• 証明可能な監査：ハッシュチェーンにより「誰が何をしたか」を検証・改ざん検知可能；
• オンプレミスで納品可能：単一ドメインのオールインワン + setup ウィザード + 鍵は運用設定センターが管理し、完全オフラインでデプロイ可能。

5. cohort —— 協働コア（フラッグシップ）

一言で：AI を組織の正社員にする —— 人間と AI の同僚が同じワークスペースで共に働き、共に成長し、共に納品します。

5.1 位置づけ

cohort は TUEO のフラッグシップ製品であり、サーバー側（cohort-server、NestJS 11 + Fastify + PostgreSQL）とデスクトップ側（cohort-desktop、Electron 3 プロセス）で構成されます。「AI 従業員ワークスペース」のすべての業務ロジックを担います：AI 従業員エンティティの登録、グループチャットでのマルチ AI 協働、認知ループ、工単パイプライン、組織ナレッジグラフ、会話の記憶、週次会議のオーケストレーション、監査記録、マルチテナント分離。

サーバー側がデータの SSOT であり、デスクトップはシンクライアントです —— 企業データはクライアントに散在しません。

5.2 中核能力

5.2.1 AI 従業員のエンティティ化（AiStaffRegistry）

AI 従業員は「在編のアイデンティティと職務プロファイルを持つ」ファーストクラスのエンティティであり、2 層の SSOT を JOIN します：

• identity の名簿：在編のアイデンティティ / 本名 / 部署 / 職位名。連絡先ディレクトリと同じ源；
• cohort ai_staff_profiles 職務プロファイル：roleLabel / workMethod / toolPolicy.allow / leadKinds / ownedCapabilities / responsibilities / persona 人格カード。

全パイプラインはこの 1 つの registry のみを読みます。AI 従業員の追加 / 削除 / 変更は identity（+ 職務プロファイル）の 1 か所だけで済み、連絡先ディレクトリ、工単トリアージ、能力ルーティング、発言名義が全体に追従し、コード変更ゼロ、名前のリテラルもゼロです。identity から削除すると、すべての場所から消えます。

5.2.2 グループチャットでのマルチ AI 協働（coordinator）

グループチャットで、ある人間のメッセージにどの AI 従業員が応答するかはサーバー側が裁定します（coordinatorJudge = SSOT）：

• 高速パス：AI なし → 応答しない；@言及 → 必ず応答；DM の人間 → 自動応答；AI の発言 → 自己応答ループを防止；ノイズ / 純粋な emoji → 応答しない；
• 低速パス：グループチャット + 人間 + 応答期待 → AI 従業員の実際の職責プロファイルを使った決定論的な職責スコアリング（LLM コストゼロ）、複数候補が接近したときだけ LLM が仲裁し、最終的には秘書がフォールバック。

判定のたびに監査が書かれます（coordinator.dispatch_judged）。グループチャットは常に「必ず 1 人が応答を担当」し、かつ連投しません。ルーティングの根拠は実際の職責プロファイルであり、書き込みハードコードされた名前ではありません。

5.2.3 AI 従業員の認知ループ（知覚→思考→行動→振り返り→待機）

各 AI のすべての判断は 5 段階の認知ループを完了します：

1. 知覚 Perceive：会話、シグナル、組織コンテキストを読み取り、まず原則ゲート（principleEnforcer.check('perceive')）を通過し、deny は直接拒否アーティファクトを書き込み；
2. 思考 Think：長期記憶の検索 + 経験ルール + プロジェクトコンテキストを統合し、LLM を呼び出して構造化されたインテントを出力；LLM が利用できない場合はルールベースにフォールバック；
3. 行動 Act：高リスクの行動は人の確認が必要；
4. 振り返り Reflect：LLM が振り返って記憶に書き戻し、自己進化を駆動；
5. 待機 Wait：次のラウンドのシグナル監視に入る。

全プロセスは phaseTimings で計時され、可観測・トレース可能です。

5.2.4 工単システム（インテント → DoR → トリアージ → Agent 実行）

1 つのチャットメッセージから AI 開発チームが実際に作業するまでの完全なパイプラインです：

1. インテント認識：LLM jsonMode + 検証で、bug / feature / incident を認識；
2. DoR 受付：severity に応じて段階的に受け付け、AI が自己補完可能 —— LLM で中文の工単をコード検索語に変換し、ローカル ripgrep で実際のファイルを特定して再現手順を特定します。絶対に捏造しません；
3. トリアージ：パスポートゲート → LLM が assigned_role / priority / AC を推論 → dev_team_room に派遣。割り当て可能なロールは registry から動的に注入；
4. ステートマシン：14 状態 + 遷移行列の O(1) 検証；
5. Agent 実行：5 段階の単一 run-role、validateToolList が toolPolicy.allow に基づいてサーバー側で越権ツールを厳格に検証します。

デスクトップ側は TriageCard / BuildProgressCard で可視化し、AI はローカルに checkout した repo 上で実際にファイルを変更し、実際にテストを実行し、実際に commit して工単に書き戻します。人間のメッセージは自動で分類して工単化することもできます。

5.2.5 組織ナレッジグラフ（「組織の空気」）

組織の会話をナレッジグラフに沈殿させます：LLM がメッセージからエンティティと型付き関係を抽出して kg_entities / kg_edges（pgvector + 関係テーブル + 由来追跡）に入れ、検索時は pgvector のコサイン類似度上位 K 件（テナント分離）→ グラフのマルチホップ隣接（コミットメント / 依存 / 競合）→ 機密性ゲート（デフォルトで最厳格、機微情報は漏洩しません）。

ナレッジストレージは単一 DB 3 機能一体（Postgres + pgvector + 関係テーブル）を採用し、二重書き込みゼロ・ドリフトゼロ。エアギャップ導入は Postgres + identity の 2 サービスだけで成立します。

5.2.6 会話の記憶（個体の長期記憶 + 共有 substrate）

各 AI はルームをまたぐ共有の長期記憶（7 日間の半減期減衰、200 件の上限）を持ち、サーバー側の /cognitive-loop/memory を権威コピーとします。すべての AI の判断は同じ「会議室状態」substrate を共有します：メインの話題 / 決定済みの事実 / 未決定事項 / 未完了のコミットメント。ルームを変えても、マルチ AI 協働でもそれぞれフレッシュスタートせず、組織は使えば使うほど賢くなります。

5.2.7 シャドウ AI の見えない分身

各人間の背後に 1 つの見えない分身があります：本人が自分で発した言葉（スタイル / 口調 / 長さ）を学習し、相手が返信を待つメッセージを送ってきたのに本人が 30 秒間応答しない場合、バックグラウンドで本人口調の下書きを作成します。代行送信の総スイッチはデフォルトでオフで、生成 + 監査のみを行い、自動送信はしません。代行送信のゲート = 総スイッチ ∧ 非フリーズ ∧ 非保護領域 ∧ 信頼度 ≥ 信頼閾値 ∧ リスク ≤ L2。財務 / 顧客 / 技術 / 内部の 4 つのカテゴリに独立した閾値を設定します。

5.2.8 サーバー側の週次会議オーケストレーション

8 人の AI 従業員が毎週構造化された報告 → 議論 → 助言要請 → 決議のクローズドループを、すべてサーバー側で行います：AI ごとに参加者のエビデンス（直近 50 件のルームメッセージ）を取得 → 推論 → AI の実 uuid で名義発言します。全員失敗 = 誠実な失敗としてフェーズを進めず、システムメッセージで実際の原因を説明します（「LLM ゲートウェイ quota 403 が静かに空会議に飲み込まれる」という事故を根治しました）。金曜日に自動で開始します。

5.2.9 メッセージエンジン + リアルタイムチャネル

チャットメッセージの CRUD、配信 / 既読、ストリーミング AI 応答、翻訳のすべてがサーバー側 SSOT で処理され、WS でブロードキャストされます。並行処理 / 競合 / クロステナントをサーバー側で防ぎます。翻訳は有界（コンテキストハッシュによる重複排除 + 技術リテラルの mask/restore + スロットキュー）。WS ゲートウェイは 3 軸で強化（tenant claim の厳格な検証、jti の失効、テナントごとのスライディングウィンドウによるレート制限）。

5.2.10 エンジンモデルゲートウェイ（資格情報はサーバーから出ない）

AI コーディングエンジンはモデルベンダーの秘密鍵を一切保持しません：エンジンの base_url はサーバー側の OpenAI 互換エンドポイントを指し、サーバーが発行する権限降格の短命チケット（15 分、audience がパスに紐付け）を保持し、実際の鍵はサーバー側がテナントに応じて解決して注入します。3 つのハード特性：model はサーバー側が決めクライアント指定を無視、クライアントの資格情報フィールドはすべて破棄、上流の応答は返す前にマスキング。

5.2.11 MCP Tueo Server（業務能力がエンジンに入る統一出口）

cohort の業務能力（工単 / ナレッジ / 添付ファイル / コミットメント / 発言）を標準の MCP ツールとして実行エンジンに公開し、「AI が作業 → 成果が協働システムに還流」というクローズドループを形成します。

5.2.12 デスクトップクライアント（cohort-desktop）

• 3 プロセス Electron：メインプロセス（OS 統合 / OIDC / IPC / クラッシュ自己回復）+ preload（contextBridge ホワイトリスト + カテゴリ別 token-bucket レート制限、破壊的チャネルは独立した小さなバケット）+ レンダラプロセス（React 19 + Zustand）；
• 4 カラムのワークスペース：会話リスト / メッセージ領域 / 詳細 / WorkspacePanel（ドキュメント Markdown/HTML 相互変換 → PDF/PPTX エクスポート + IDE ワークベンチ）；
• セキュリティの多層化：OIDC PKCE + ES256、3 枚の権限降格トークン、CSP enforce、監査の単一ファネルでサーバー側コンソールに集約、IPC レート制限；
• ローカルペアリング：メインプロセスが直接コーディングエンジンを spawn（ACP プロトコル）、ファイル読み書きは作業ディレクトリ境界内、権限リクエストはデフォルトで拒否 ——「人が重要な関門で確認する」はスローガンではありません。

5.3 AI 従業員の役割と権限の境界（AI 従業員も同様に管理される）

AI 従業員の能力境界は、役割、職責、付与されたツール権限によって決まり、できることによって決まるのではありません —— これは「汎用 AI アシスタント」との最も根本的な違いの 1 つです。

• 境界をどう決めるか：各 AI 従業員は職務プロファイルで職責範囲とツールホワイトリスト（toolPolicy.allow）を宣言します。identity が「誰であるか」（在編のアイデンティティ）を管理し、registry が「どう働くか」（役割 / 職責 / 権限）を管理し、2 つのラインが何を許可するかを共に決定します。秘書は秘書です —— 蘇婉は秘書であり、運用サーバーを操作することはできません；
• 境界をどう守るか：越権ツールはサーバー側で厳格に検証（validateToolList が toolPolicy.allow に基づく）し、すべて拒否。知覚段階ではまず原則ゲート（PrincipleEnforcer、pattern がヒットしたら即裁定）。高リスクの行動は人の承認が必要。すべての判断と拒否が監査に入ります —— 4 段階の行動防御線が幾重にもフォールバックします；
• 境界がなぜ硬いか：人間の異動も AI の異動も同じ —— 1 か所の役割設定を変更すると、能力範囲が全体に追従します。AI 従業員と人間の従業員は同じ管理ロジックを共有します：AI は強いですが、組織が与えた境界内でのみ強いのです。

この仕組みにより、「AI が強くなるほど、境界が明確になる」が工学的な事実になります：コードを書ける AI であっても、運用権限が付与されていない限り、運用サーバーへのすべてのリクエストはシステムに厳格に拒否され、監査に記録されます —— 組織は AI への信頼を段階的に広げることができ、一度にすべてを賭ける必要はありません。

5.4 差別化

• AI は「組織の編制内の従業員」でありツールではない。名前のリテラルゼロ、名前の単一源は identity；
• グループチャットの進行役はサーバー側の契約でありクライアントのヒューリスティックではない。自己応答ループを防ぎ、判定のたびに監査を残す；
• 工単はアンケートではない：DoR の段階別受付 + AI の自己補完。厳密さを借りても官僚主義は借りない；
• 資格情報はサーバーから出ず、監査は単一ファネルで上収され、企業データはクライアントに散在しない；
• 役割が境界を決める：AI 従業員と人間の従業員は同じ管理ロジックを共有し、越権ツールはサーバー側で厳格に拒否され監査に残る。

6. studio —— アプリケーションオーケストレーションプラットフォーム

一言で：ビジネス担当者が対話でプロセスを、AI が業務オブジェクト上で認知・判断・行動するアプリケーションに編成します —— BPM の AI ネイティブな後継者であり、またひとつのワークフローキャンバスではありません。

6.1 位置づけ

studio は TUEO の「オーケストレーションエンジン層 / インテリジェント労働の立法層」です：組織内のインテリジェントな労働（AI 従業員 + コネクタ + 人による審査）を、公開可能・監査可能・進化可能なアプリケーションに編成し、人 / AI 従業員 / 外部エージェントが信頼をもって呼び出せるようにします。cohort と組み合わせて稼働します：cohort は AI 従業員ランタイム、人審カード、結果の書き戻しを提供し、studio は構造化オーケストレーション、受入リリースゲート、ガバナンスのガードレールを提供します。

6.2 中核能力

6.2.1 イベントソーシングオーケストレーションエンジン

11 種類のノード（開始 / 終了 / 分岐 / AI 認知 / AI 従業員 / 人 / 能力 / サブプロセス / ループ / 待機 / 並行）。すべての状態遷移は append-only の run-trace イベントとして追記されます。状態はイベントから導出されます：人 / サブプロセス / ループ / タイマー / 並行 / AI 従業員はすべて永続的な一時停止を経由します（プロセス再起動で再開、スレッド保持ゼロ）。ブレークポイントでのステップ実行 / 再開、失敗したステップからの再実行、再帰防止に対応します。

6.2.2 会話型コパイロット（自然言語オーケストレーション）

ビジネス担当者が意図を述べると（例：「3,000 を超える経費は財務ディレクターの承認を経由」）、コパイロットが上位の承認仕様を生成し、決定論的にコンパイルして合法的な FlowDef にします —— LLM は「何を判定するか / どうルーティングするか / 何段階の承認か」の単純な JSON だけを出力し、構造の合法性はコンパイラが保証し、最大 3 回の自己修正を行います。変換は決定論的、内容はインテリジェント。

6.2.3 公開ガバナンス：draft/published のバージョン分離 + 受入テストゲート

オーケストレータは下書きを保存し、公開時にイミュータブルな semver バージョンスナップショットを作成し、オンライン稼働は常に最新の published を取得します。公開前に受入テストスイート（スタブ AI 出力 + スクリプト化された人審 + スタブ能力、決定論的リプレイ）を実行し、すべて合格して初めて公開します —— 受入テスト = リリースゲートであり、同時に L2/L3 の回帰セーフティネットです。履歴バージョンへのロールバックをサポートします。

6.2.4 AI 認知・意思決定・行動ノード

1 つのプリミティブで分類 / 判断 / 抽出 / 画像認識 / 自律的ツール呼び出しを支えます：構造化 JSON 出力契約 + モデル出力スキーマの厳格な検証、agentic エージェントループ（function-calling、ステップごとに tool_call を記録）、マルチモーダル視覚（画像は視覚モデルを経て説明に変換）、ノードレベルのモデルフィールド上書きによる意味的ルーティング。

6.2.5 AI 従業員ノード + 人審ノード（人機対等のアクター）

ai_staff ノードは作業を identity 在編の AI 従業員に委譲し（cohort 内で作業）、人審ノードは人の裁定を待って中断します —— 2 種類のアクターはそれぞれ SLA を持ち、それぞれ組織内の上級エスカレーション経路を持ちます。AI 従業員はスクリプトではなく同僚であり、人はプロセス内の対等なノードです。

6.2.6 オーケストレーション変数モデル obj/steps/sys/env の 4 つのスコープ

ノードの入力マッピングと分岐条件は型付き式 AST を使用し、データフローは決定論的・リプレイ可能・テスト可能です —— 分岐条件はブラックボックスのプロンプトではなく、受入可能な宣言です。

6.2.7 ガバナンスの背骨（展示ではなく強制）

• kill-switch サーキットブレーカー：グローバル / アプリごとのワンクリック遮断（423）；
• クォータによるレート制限：per-app の実行レート（429）；
• token 予算：単一実行の token 累積が上限を超えるとエンジンが停止；
• コンテンツ安全ゲート：禁止語 + PII 正規表現（携帯電話 / メール / 身分証）、mode = off/flag/block；
• 監査：監査ログは run-trace イベントから投影し、エクスポート可能（SOC2 / 等保 / EU AI Act の証拠保全）。

6.2.8 cohort との統合（app-as-tool）

cohort の会話内でアプリケーションをツールとして使います：アプリ選択 → フォームカード（正確な入力）→ 会話スレッドに紐づけて run 起動 → 結果 / 人審カードの書き戻し。フォームのプリフィルは出典ゲートを通ります（根拠のあるフィールドだけを埋める）。結果カードのナラティブテンプレートは実際の結果でプレースホルダを置き換えます（値を取得できない場合は段落ごと破棄、LLM ゼロ・捏造ゼロ）。

6.2.9 デザインタブ + マルチチャネル適応

AI が実際の成果物フィールドから宣言的なブロック型レイアウトを生成し、バックエンドが厳格に検証します（ブロック列挙 + bind は実在フィールドのみ保持 + 配列ブロックは配列フィールドにバインド必須、捏造はすべて破棄）。一度のオーケストレーションでマルチチャネルに納品：cohort の 4 カラムシェル / 企業 IM（企業微信 / 钉钉 / Lark カード）/ Web ウィジェット。

6.2.10 自動化トリガー + MCP 公開 + デバッグ・観測

アプリケーションは手動呼び出し → スケジュール / webhook による自動トリガーに拡張できます。公開済みの各アプリケーションは1 つの MCP tool として公開され、任意のエージェントが呼び出せます（囲い込みはしません）。SSE ストリーミングデバッグ + dry-run 演習 + ノード Mock カバレッジ + ブレークポイントデバッグに対応します。

6.3 差別化

• Dify / n8n ではない：「業務オブジェクト上の AI ネイティブなオーケストレーション」であり、業務オブジェクト型契約 + イベントソーシング；
• 受入テスト = リリースゲート：AI オーケストレーションがソフトウェアエンジニアリングと同じように品質を制御可能；
• AI 従業員は人機対等のアクター：役割、SLA、上級エスカレーション経路を持つ；
• ガバナンスは本当の遮断であり展示ではない：サーキットブレーカー / クォータ / token 予算 / コンテンツ安全ゲートをすべてエンジン層で遮断。

7. capabilities —— 能力マーケットプレイス

一言で：企業 AI 能力の App Store —— 1 つの能力契約で、AI はツールとして、人は UI として。生産から市場、調達、認可、エアギャップ配布まで全プロセスをガバナンスします。

7.1 位置づけ

capabilities は「能力はどこから来るか」を担う独立したプラットフォーム層（生産 / プラットフォーム）であり、どのコンシューマホストにも属しません。承重壁は生産 / 消費の二分法です：能力プラットフォームはレジストリ SSOT + 市場 + インストールガバナンス + 資格情報ボールト + 呼び出しゲートウェイ + プラットフォームコンソールを担当し、cohort（チャット / AI 従業員）と studio（アプリケーションオーケストレーション）はどちらも SDK 契約経由で消費するホストであり、それぞれがネイティブ UI を持ち、決して逆依存しません。

これにより、かつてレジストリ / ゲートウェイを cohort-server にハードコードしたアーキテクチャ上の欠陥を修正しました —— studio はかつて env にハードコードされた URL で executor に直接接続し、プラットフォーム全体をバイパスしていました。

7.2 中核能力

7.2.1 レジストリ SSOT + 公開ライフサイクル

スキル / プラグインの manifest、バージョン、ステータスの単一真値。生産者側は draft → in_review → published / rejected を経て、state（active / archived）は直交します。.tueopkg アップロードは検証（semver / 能力宣言 / ペイロード完全性）を経て下書きとして保存され、元のパッケージは sha256 digest でコンテンツアドレス指定して保存します。

7.2.2 署名と信頼のガバナンス（Ed25519）

manifest は署名鍵で署名 → Ed25519 detached 署名 → 検証で official / partner / community の 3 段階の信頼を導出します。リポジトリ間で署名アルゴリズムはバイト単位で一致します（drift-lock テストで固定）。署名を宣言したのに検証が通らない = 改ざん / なりすましで、インストール時に拒否します。

7.2.3 インストールガバナンス（テナント級）

テナントがどのスキルをインストールし、有効化しているかを管理します。インストール = デプロイ状態、有効化 = 実行スイッチ、ユーザー設定 = 個人スイッチ。3 層は互いに混同しません。呼び出しゲートウェイは前置の assertEnabled ハードゲートを持ちます。

7.2.4 資格情報ボールト（テナント級の暗号化）

プラグイン設定：settings は平文 + secrets は暗号文（AES-256-GCM）。ゲートウェイは invoke 時に復号して注入し、ユーザー / AI は secret を一切見ることができません。ホストをまたいでも（cohort / studio）同一の源から見えます。

7.2.5 呼び出しゲートウェイ（kind 別ディスパッチ + 課金 / 使用量の組み込み）

1 回の呼び出しはインストールゲート + 課金ゲート + 利用可能範囲ゲートを通過 → 資格情報を復号して注入 → kind に応じてディスパッチ：action → executor サンドボックス / knowledge → 直接内容を返し宿主 LLM のコンテキストに注入（サンドボックスなし・コストゼロ）。

★課金ゲートと使用量記帳はゲートウェイ内に組み込まれています：間接 / 委任の呼び出しも自然にゲートを通過して記帳され、「課金のバイパス」という穴を根治します。

7.2.6 調達ガバナンスのクローズドループ

トライアル → 申請・承認 → 注文（法人 / オンライン）→ 財務確認 → 請求書、全プロセスを記録します。予算ゲート（使用済み + 処理中 + 今回分 ≤ 上限）、購入者自己監査の派生ストリーム（注文 / 権益 / 申請 / インストール / 範囲変更をタイムラインに集約）。

7.2.7 収益化 / 価格設定

価格は製品に属します（Stripe パラダイム）：運営側がスキルごとにグローバル価格を設定し、さらに特定顧客のテナントに対して B2B 契約価格で上書きできます。課金範囲の鉄則：買い切りまたはサブスクリプション期間のみ。使用量 / シート課金は行いません（使用量は純粋な経営分析であり、メータリングではありません）。

7.2.8 権益 SSOT + サブスクリプションライフサイクル

「そのテナントが有料スキルを使用することを認可されているか」の単一真値。オンラインとオフラインの 2 つの経路が同じテーブルに書き込み、ゲートは統一的に読み取ります。期限切れで即失効、定期クリーンアップによるフォールバック、期限切れ前のバナー警告。サブスクリプションの更新は契約 + 請求書 + 再発行のプロセスを再実行します。

7.2.9 オフライン認可アクティベーション（署名付き License の単一 SSOT）

オンプレミス / エアギャップ顧客向けの有料アクティベーション：署名付き License ファイルが単一のトラストアンカーであり、オンラインは単なる転送レイヤー、エアギャップでは同じファイルを人手で運びます。ソフトノードロック = deploymentId（プラットフォーム初回起動時に生成。1 つのファイルを複数デプロイにコピーするのを防ぎ、ハードウェアをロックせず顧客の反感を買いません）。オンラインアクティベーション / ハートビート / 技術的な失効は作りません（純粋な契約上の信頼）。

7.2.10 エアギャップオフライン配布（.tueoupdate 統一事業物）

スキルの bits を内網に運びます：1 つの署名付き更新パッケージがディレクトリとプラットフォームコンポーネントを同時に運び、console が 1 つの導入口になります。署名付き manifest はイミュータブルな承重壁です（bundle のローカル保存は独立カラムを使い、manifest は決して変更しません。変更すると署名検証が無効になります）。デフォルトで bundle-runtime はイメージ不要です。

7.2.11 利用可能範囲 + 使用量の経営ダッシュボード

「テナント内で誰がどのスキルを使えるか」の認可割り当て（mode = all / departments / users、データソースは identity SCIM）。使用量ダッシュボードは「能力が価値に見合っているか、無駄やリスクがないか」に答えます（未使用の権益の特定 = 権益を持っているのに呼び出しゼロ = 無駄なコスト）。

7.2.12 権限の 4 ステップクローズドループ

開発者が permission[] を宣言 → フロントエンドがリスクをレベル分けして赤ラベル（ネットワーク / ファイルシステム / 実行 / 鍵）→ インストール時に同意ダイアログを表示（付与時点を監査）→ executor サンドボックスがランタイムで強制（未認可の network 権限は unshare ネットワーク名前空間で本当に遮断し、出方向ゼロで漏洩を防止）。

7.3 差別化

• 1 つの能力契約、2 つのコンシューマ：同じ能力を AI がツールとして（executor サンドボックス）、人が UI として（宣言的 / フロントエンド bundle）利用；
• 商用クローズドループを呼び出しゲートウェイにネイティブに組み込み：委任 / 間接呼び出しも自然にゲートを通過して記帳；
• 署名付き License の単一認可 SSOT：エアギャップとオンラインが同じ仕組み；
• 生産状態の鍵は fail-closed：公式署名の秘密鍵 / ボールトのマスターキー / セッション鍵 / S2S トークンが欠けていると起動を拒否（公開 dev シードによる公式署名とオフライン License の偽造を防止）；
• アンチロールバックの高水位 + サブスクリプション期限切れの全テナント定期クリーンアップ：エアギャップ顧客が時計を戻して期限切れサブスクリプションを延命するのを根治。

8. executor —— サンドボックス実行基盤

一言で：AI の両手 —— 非信頼のコード / コマンド / イメージを隔離サンドボックスに入れ、監査可能・スケジューリング可能・スケール可能に AI 従業員のために実際の成果を生み出し、構造化された結果を返します。

8.1 位置づけ

cohort（ワークスペース）、studio（オーケストレーション）、capabilities（能力マーケットプレイス）は「何をするか」の決定を担当し、executor は「実際にやり遂げる」ことを担当します —— コードパッケージ / コマンド / 自前イメージを受け取り、K8s Job で隔離された Runner サンドボックスを起動して実行し、構造化された結果をコールバックし、全プロセスを監査します。全プラットフォームで統一された能力実行面であり、信頼境界内で「ユーザーコードは非信頼」を保証する隔離壁です。

8.2 中核能力

8.2.1 マルチランタイムサンドボックス実行（python パッケージ / 汎用コマンド / 自前イメージ）

1 つの job 契約で 3 種類の実行を支えます：python コードパッケージ（pip で依存をインストール → import entrypoint → main(**inputs)）、command 形式（言語に依存せず任意の shell を実行）、image 形式（job ごとに指定イメージを起動）。大きな入力（>64KB）はマウントファイルにオーバーフローさせて env の制限を回避。未認可のネットワーク権限の command 形式は unshare --net でネットワーク名前空間を遮断して子プロセスを実行します。

8.2.2 K8s ネイティブ分離 + 5 段階優先度スケジューリング + ジョブごとのリソースクォータ

各 job は独立した Pod になります：非特権、読み取り専用ルートファイルシステム、capabilities をすべてドロップ、seccomp RuntimeDefault、実行後は自動回収。5 段階の優先度（CRITICAL は BACKGROUND をプリエンプション可能）+ job ごとに設定可能な CPU / メモリ。

8.2.3 アドミッション制御 + 優先度キュー

グローバル並行上限 + per-tenant クォータ（DB で実行時に変更可能）+ 宿主リソース負荷の三重バックプレッシャー。並行上限を超えた job は QUEUED キューに入り、優先度 + FIFO で排出。アトミックな取得で二重ディスパッチを防ぎ、単一テナントが上限に達しても他テナントをブロックしません。

8.2.4 リコンサイルのクローズドループ（pull is truth, callback is optimization）

コールバックは最適化項目であり、リコンサイルループが 30 秒ごとに K8s へ真値を能動的に照会し、ゾンビ job を終了状態に導き、lost と判定し、実行中カウントを自己修復します。コールバックが届かなくても running に張り付くことはありません。

8.2.5 DAG ワークフローオーケストレーション

有向非巡回グラフで依存と並行を表現します（共有 dag_id の job 集合、独立テーブルなし）。失敗は特定ポイントから再実行できます（incremental / full）。

8.2.6 マルチテナント分離（fail-closed への集約）

すべてのリソースが tenant_id に紐づき、クエリ / 書き込みでテナントフィルタを強制します。テナントを取得できない場合はすべてを許可するのではなく直接拒否します。「すべてを見たい」と「テナントを渡し忘れた」はコード層で異なる形をしており、プラットフォーム級の集約は明示的な宣言が必要です。

8.2.7 全量セキュリティ監査 + Transactional Outbox イベント

すべてのライフサイクル操作が監査テーブルに書かれます。業務操作とイベントは同一トランザクションで outbox に落とし、非同期で CloudEvents 1.0 を配信し（CI / 通知 / 課金コンシューマ）、業務はブロックされません。

8.2.8 資格情報とコールバックの安全性

job Pod には最小権限の MinIO 資格情報（bucket-scoped）を注入します。コールバック URL には job ごとの専用 HMAC token を埋め込み、共有トークン保持者が任意の job 状態を操作できないようにします。終了状態のコールバックは冪等（状態の復活を防止）。

8.2.9 AI コーディングエージェント coding-agent

自律コーディングエージェント：GitLab リポジトリをクローン → ツールループで工単を実装 → 自己テスト → コミット → ブランチをプッシュ。パスポート（tueo-passport 拡張ポイント）が HARD ファイル編集ゲートにコンパイルされます（ゾーンを越えるとすべて BLOCKED）。視覚的自己検証 = 実際の Chromium スクリーンショット + 視覚モデルによる画像判定であり、jsdom の推測ではありません。

8.2.10 可観測性

Prometheus メトリクス（スケジューリング遅延 / キュー待ち時間 / per-tenant 実行中 / ノード水位）+ ノードリソースのリアルタイムスナップショット + 実行中 job のリアルタイムコンテナログ + 永続データからの実行タイムライン再構築。

8.3 差別化

• マルチランタイムの統一契約（python / command / image）であり、単一 Python サンドボックスではない；
• スケジューリングがファーストクラス：テナント級の公平性 + 優先度プリエンプション。多くのサンドボックス製品は単純な並行数のみ；
• リコンサイルループで自己修復：競合製品はコールバックが届かないと張り付くことが多い；
• job ごとの HMAC コールバックバインド + 最小権限資格情報 + ネットワーク遮断サンドボックス —— コールバックも資格情報も job 単位で分離。

9. skillplugins —— スキルプラグインと SDK

一言で：1 つの能力契約、2 つのコンシューマ —— AI アシスタントに本当に「業務をさせる」ために、企業のプロセス能力を署名可能・サンドボックス可能・市場流通可能なプラグインにします。

9.1 位置づけ

skillplugins は TUEO プラグインプラットフォームの生産側であり契約の承重壁、4 層アーキテクチャの源泉です：skillplugins（プラグインパッケージ + SDK）/ 能力プラットフォーム（レジストリ + ガバナンス + ディスパッチ）/ executor（バックエンドサンドボックス）/ desktop（フロントエンドレンダリング）。@tueo/plugin-sdk は manifest / capability / invocation の各層の単一源です。

9.2 中核能力

9.2.1 プラグイン宣言契約（PluginManifest）

プラグインの定義 = manifest（能力宣言）+ backend（executor で実行）+ frontend（desktop でレンダリング）の 3 点セット。言語中立（input / output は JSON Schema で、executor の Python でも検証可能）。humanSurface は slash（コマンド）/ form（自動導出フォーム）/ preview（第 4 カラムのプレビュー）の 3 つの入口を提供します。

9.2.2 プラグイン署名と信頼のガバナンス

公開側は秘密鍵で manifest に Ed25519 detached 署名を施し、ロード / インストール側は信頼された公開鍵レジストリで署名を検証して信頼レベルを導出します。改ざんされると署名検証が失敗し、インストール時に改ざん防止アサーションが働きます。

9.2.3 バックエンドランタイム I/O 契約

入力は cwd/inputs.json を読み、結果は $OUTPUT_DIR/result.json に書き、大容量の成果物は runner が一括で MinIO にアップロードします。作成者は serve({capabilityId: handler}) を書くだけで、I/O、エラー正規化、終了コードはすべて SDK が処理します。

9.2.4 参考実装：deck（プレゼンテーション）

17 種類のレイアウト（title / section / bullets / kpi / twocol / process / chart / statement / agenda / compare / timeline / composite / scorecard / matrix / gantt / pillars / figure）+ 行動タイトル + 4 セットのデザイン言語。同じ DSL で HTML プレビューと編集可能な .pptx エクスポートを出力します（プレビュー = エクスポートの一致。「プレビューは良いのにエクスポートは壊れる」は起きません）。PptxGenJS の母型で優雅にフォールバックします。

9.2.5 既存 PPT のスタイル継承

既存の .pptx をインポート：内容はサーバー側で解析し、スタイルはプラグインが theme1.xml の配色 + フォントを 1 セットのデザイン言語として抽出します。色とフォントだけを変えて、プラットフォームのレイアウト品質を保ちます —— 顧客のブランド資産を継承できます。

9.2.6 pharma-doc（医薬品コンプライアンスの例）

医薬品の随貨同行単（添付書類）認識プラグイン：VLM が 12 フィールドを抽出 → プラグインが決定論的なルール検証（承認番号の形式 / 製造日 < 有効期限 / 有効期限 > 今日 / 数量 > 0 / 必須）→ 緑 / 黄 / 赤のカラー再確認プレビュー。モデル呼び出しゼロの検証層は冪等でテスト可能・監査可能。人の介入は 1% 未満だけです。

9.3 差別化

• 1 つの能力契約、2 つのコンシューマ：同じ capability を AI（function-calling ツール）と人（slash / フォーム / プレビュー）の両方に公開し、同じ入力はバイト単位で同一；
• 抽出と内容は AI が担当、決定的検証はルールエンジンが担当：結果は冪等でテスト可能・監査可能；
• デザイントークン駆動のレンダリング：プレビュー = エクスポート、言語変更 = トークンファイルの差し替え、エンジンは変更不要；
• 堅牢性と誠実なフォールバック：1 ページが壊れてもプレースホルダページで全体を壊さない；取得できないデータは「—」を表示し、捏造しない。

10. codex-build —— コーディングエンジン

一言で：TUEO のコーディングカーネル —— AI 従業員に「実際に働かせ、実際に成果を出させる」。自己申告型エージェントではなく、企業アイデンティティの境界と監査可能な痕跡を持つ実際のコーディング実行エンジンです。

10.1 位置づけ

codex-build は TUEO 全プラットフォームの統一実行エンジンであり、AI 開発チームのコーディングカーネルを務めます。サーバー側とデスクトップ側がこれまでそれぞれ自作していた 3 セットのエージェントループ（約 13,300 行）を置き換えます。

アーキテクチャの分担を一言で言えば：エンジンは「どうやるか」を担当（実際にコードベースを読む / ファイルを変更 / shell を実行 / Web 検索 / 長時間タスク / サブエージェント）、Server は「できるか、何をするか、何の痕跡を残すか」を担当（アイデンティティ、認可、コンテキスト、資格情報、監査）、Desktop は「見えて、クリックできて、ローカルで触れられる」を担当（ペアリングとレンダリング）。

エンジンが本来持つ対話機能と自前ログイン機能はすべてロックされ、管理された入口だけを残します —— 独立したターミナル製品ではなく、TUEO プラットフォームに「企業の実行者」として飼いならされたファーストクラスのランタイムです。

10.2 中核能力

10.2.1 実際のコーディング実行（ナラティブではない）

「やったと主張する」から「実際にやる」へ：エージェントは実際のリポジトリのワークスペース内でクローン → コードを読む → ファイルを変更 → テストを実行 → コミット → プッシュ → MR を出し、実際のファイル / diff / ブランチを生み出します。内蔵ツール群：read_file（image / pdf / pptx / metadata パーサーを含む）、search_replace、bash、grep、list_dir、monitor、scheduler、todo、web_search / web_fetch。

10.2.2 コードベースの理解

大規模コードベースの構造を構築してナビゲーションします：コードインデックス（index_manager + languages + scope_graph）、ワークスペース管理（folder trust + ファイルシステム通知）、コンテキストパック（Context Pack：ロール / 制約セグメント + 工単 spec / plan / AC + モデルルーティング）をタスクに合わせてマテリアライズしてワークスペースに注入します。

10.2.3 管理されたランタイム（ACP 組み込み）

Agent Client Protocol（stdio JSON-RPC）で desktop / executor から駆動され、長いセッション、リアルタイムイベントのフィードバック、権限と承認のポップアップカードに対応します。拡張メソッドで権限リクエスト、ユーザーへの質問、サブエージェントの同意、フォルダ信頼を実装します —— すべてデスクトップ側がカードを表示して結果を返します。

10.2.4 サブエージェント協働（エンジン級のハードゲート）

メインエージェントはタスクの複雑さに応じてサブエージェントを並行 / ネスト起動できますが、最初のサブエージェントを spawn する前には必ずエンジン級の consent ハードゲートを通過しなければなりません。不変条件：1 回だけ尋ねる、ユーザーごとのリクエスト無効化、ツール能力は付与しない —— 「サブエージェント協働を採用するか」を、プロンプトに頼らずに、企業のリクエストごとの確認可能な決定にします。

10.2.5 MCP 業務能力の接続

エンジンは MCP client としてサーバー側の tueo MCP Server を消費します：工単 / アプリケーション / コネクタ / ナレッジ / コミットメント / 添付ファイル / メッセージの単一出口がエンジンに入ります。業務能力はエンジン側に散在せず、資格情報はクライアントに下ろしません。

10.2.6 企業アイデンティティの境界

ネイティブ API key / 自前アカウントログイン / 対話ターミナル / headless / リレー / セッション履歴実行はすべて恒久的に無効化され、モデル実行の管理された入口 = ACP + identity です。セッションは owner sidecar（0600、issuer / tenant / subject）に書き、new / load / prompt / cancel はすべて fail-closed で、クロステナントのセッションハイジャックを防ぎます。

10.2.7 資格情報はサーバーから出ない

エンジンはモデルベンダーの秘密鍵を一切保持せず、サーバーが発行する短時間有効のセッションチケットだけを保持し、エンジンゲートウェイ経由で実際のモデルに転送します。実際の鍵は一度もサーバーのプロセスメモリを離れません。

10.2.8 視覚と音声のマルチモーダル

テキスト専用のメインモデルが画像 / 音声を受け取ってもエラーになりません：画像は補助視覚モデルが説明に変換し（メインモデルへの元画像フォールバックは禁止）、音声はエンジン内蔵の音声ランタイムが処理します（ストリーミング文字起こし + 合成）。モデルルーティングは常にサーバー側が決定し、クライアントが任意のモデルを指名することはできません。

10.2.9 サンドボックスとプロセス分離

内蔵の複数段階サンドボックスプロファイル + deny glob + ネットワーク遮断ポリシー。マルチテナントは同じインストールを共有しても互いに見えません：Linux user + 独立した home（すべてのユーザー空間データパス）+ Bubblewrap。各テナントのエンジンデータはそれぞれ独立したディレクトリに置かれます。

10.2.10 Folder Trust 信頼ゲート（コード実行面のレッドライン）

hooks / MCP 設定 / 環境設定を含むクローンリポジトリはデフォルトでは読み込んで実行しません（そうしないとクローンするだけでリモートコード実行になります）。コンパイル時のバージョンスタンプ：スタンプのないビルドでは folder trust が静かに無効化され、リリースは発版スクリプト + レッドライン検証を必須とします（hooks 付きリポジトリは信頼確認をポップアップしないとリリースできません）。

10.2.11 アップストリームの追跡可能なガバナンス（fork の健全性）

TUEO はアップストリームへの変更をパッチ台帳 + 由来等価性検証 + 階層化カスタマイズ制約で管理します：TUEO_UPSTREAM.toml がアップストリームの commit SHA を固定し、ソースアーカイブの等価性を検証（file_count + manifest_sha256 + status=passed）、CI がメタデータ整合を強制します。いつでも「このコードはどのアップストリーム commit から来たか、どのパッチで変更されたか、ロールバックできるか」に答えられます。

10.3 差別化

• 「自己申告型エージェント」から「実際の実行」へ：実際のファイル / diff / MR を生み出し、コーディングの納品物が信頼できる；
• 1 つのコーディングエンジンで全プラットフォームを統一：デスクトップ / サーバーの 3 セットの自作エージェントループを廃止；
• 企業信頼の 4 点セット：アイデンティティ境界、資格情報はサーバーから出ない、サブエージェント / 権限 / フォルダ信頼の三重確認カード、監査可能な痕跡；
• fork ガバナンスが売り：すべてのパッチに台帳があり、すべてのリリースに由来等価性検証があり、ロールバック可能 —— オンプレミス顧客が安心して使える；
• マルチテナントのプロセス分離 + 単一バイナリ納品、オフライン / オンプレミスデプロイに直接適用可能；
• ドッグフーディング：AI 開発チームがこのエンジンで TUEO 自身の製品を開発しています。

11. console —— インテリジェント基盤の運用層 · オンプレミス納品と運用

一言で：インテリジェント基盤の運用層 —— ベアメタルをワンクリックで TUEO の本番環境に仕上げ、その後は 1 つの画面ですべてのサービスとミドルウェアを運用します。

11.1 位置づけ

console（TUEO Console 運用プラットフォーム）はインテリジェント基盤の運用層であり、「納品と運用の基盤」でもあります：上はすべての製品ラインを受け、下は k3s / Harbor / CNPG / ミドルウェアを管理します。新しいシステム、既存のシステム、AI システムを、1 つの入口で体系全体を運用します。3 点セットで完全なライフサイクルを構成します —— console = オンプレミスインストーラ + サイト内運用ハブ（デプロイオーケストレーション / 設定センター / ステータスウォール / ログ / バックアップ / アップグレード / 監査）、tueo-ci-images = 2 層のイミュータブルなオフライン CI イメージ、tueo-build = コーディングエンジンのソースと発版パイプライン。基盤（db / redis / k3s / MinIO）もまた、この運用が管理する被管理オブジェクトです —— 自分自身さえも被管理オブジェクトです（自己アップグレードはイメージ差し替えのみ、創世マニフェストが常に SSOT）。

11.2 中核能力

11.2.1 サービスカタログ SSOT（manifest）

複数箇所に散らばったレジストリを単一の宣言型サービスカタログ（11+ サービス：ops-console / postgres / redis / minio / identity / cohort-server / executor / studio-api / studio-web / capabilities-api / cohort-desktop / skillplugins）に集約し、静的トポロジの単一真値にします。製品ラインを追加 = JSON を 1 行追加 + PR、コード変更ゼロ。

11.2.2 3 ドライバのデプロイオーケストレーション（local-dev / compose / k8s）

同じドメインモデルの下で 3 つのランタイムを領域分けします：ローカルネイティブプロセス、シングルマシン Docker、顧客既存の K8s。1 つのプラットフォームでローカル開発と顧客の単機・既存クラスタの両方を管理できます。顧客に K8s がなくても導入可能です（k3s 基盤を同梱）。

11.2.3 イメージ昇格ゲート + ワンクリックデプロイ（ビルドレジストリ → 実行レジストリ）

CI はイメージをビルドレジストリにだけプッシュします。プラットフォームがクラスタ内で Harbor の pull レプリケーションを使い、tag を内網の実行レジストリへ昇格し、tag が揃ってから apply + rollout します。製品リポジトリがテンプレートを 1 つ include するだけで build-image + deploy-prod の完全な本番パイプラインを取得でき、イメージはオンラインビルドレジストリから内網実行レジストリへ自動で昇格し、手作業ゼロです。

11.2.4 設定センター（秘密鍵 AES-GCM 保存 + バージョンロールバック）

通常の設定は宣言的にレンダリングし、秘密鍵は暗号文で保存（AES-256-GCM、マスターキー）。バージョンスナップショットでロールバック可能、秘密鍵が git に入ることは決してありません。ローカル AES / Vault の 2 バックエンドに対応。

11.2.5 オンプレミス運用の生命線

導入前の事前検証（包括的な preflight アサーション）、全 DB バックアップ・リストア、エアギャップリモートサポート用の診断パック、バックアップ優先のアップグレード・マイグレーション。バックアップ優先 + ロールバックポイント + アップグレード履歴 —— 顧客現場で本当に問題が起きたとき、バックアップで復元でき、診断パックでリモート救済できます。

11.2.6 ステータスウォール + データ運用パネル

運用担当者は Console の 1 つの画面ですべての被管理ワークロードとミドルウェアを運用します：kubectl 不要、サブドメインを覚える必要なし、データポートを露出しません。PG / Redis は常に公網 ingress を開けず、高リスク操作はオンデマンドの一時セキュアトンネル（短い TTL + 監査）を経由します。

11.2.7 オフライン更新のインポート（.tueoupdate 署名検証 + 事前検証 + ディレクトリ転送）

プラットフォームはオフライン更新の配布ハブになります：.tueoupdate パッケージを Ed25519 公式署名検証 → 事前検証の互換性ゲート → bundle セグメントを capabilities へインポート、image セグメントを skopeo で Harbor にインストール。検証に失敗 / 署名なし → 拒否します。

11.2.8 プラットフォーム自己アップグレード（dogfood、イメージ差し替えのみ）

運用プラットフォームが自分自身をデプロイします：創世 bootstrap は手動で 1 回、その後は main への push で自動ビルド → promote → イメージ差し替え → /api/version をポーリングして収束。アップグレードはイメージタグだけを変更し、創世マニフェストを壊しません（PVC / マスターキー / ConfigMap / ゲートウェイはすべて保持）。典型的なセルフマネージドプラットフォームのパターンです。

11.2.9 再現可能 CI のベースイメージ（サプライチェーンセキュリティ）

2 層のイミュータブルなオフライン CI イメージ：lock ですべての入力を固定（ベースイメージ digest + Debian snapshot タイムスタンプ + name=version の apt パッケージ + バイナリ checksum）。ビルドは再現可能・オフライン・署名付き・SBOM 付きです。通常の MR はネットワーク接続ゼロ・ダウンロードゼロ、ビルド資格情報は保護された runner にのみ存在します —— サプライチェーン攻撃面を最小化。

11.2.10 オンプレミスデプロイキット（リプレイ可能な kit）

ベアメタルから TUEO 本番環境を構築するリプレイ可能なスクリプト + マニフェスト一式：サイトマニフェストを 1 つ埋めて 00 → 60 の順に実行すれば、リプレイ可能で手作業 SSH は不要です。TUEO は同じ kit を自社利用の堅牢化に使っています（dogfood）。

11.3 差別化

• SaaS ではなくオンプレミスが基本方針：顧客ごとに独立した単一サイトの隔離インストール、オフライン / エアギャップがデフォルト、ワンクリック導入、オフライン bundle + license 納品；
• 過剰設計を排する：Argo / Vault / Loki のフルセットは導入せず、ツールの規模を問題の規模に合わせる；
• サービスカタログ = manifest ファイル SSOT：「DB が真値、ファイルは seed」という反復的なドリフトの病根を根治；
• 真の dogfood：プラットフォームは自分の k8s driver で自分をデプロイし、自分の API で実際のサービスをクラスタにデプロイ；
• オフライン更新サプライチェーン：.tueoupdate パッケージの署名検証 + 事前検証の互換性ゲート + ディレクトリセグメント転送、未署名パッケージは拒否。

12. engram —— 知識・記憶基盤

一言で：AI に、企業自身の知識で企業の問いに答えさせます —— 知識ベース、会話メモリ、知識の関連付けを 1 つの基盤に統合し、使うほど正確になり、自ら成長します。

12.1 位置づけ

engram は TUEO 体系の**知識・記憶の単一真値（SSOT）**であり、3 種類のプラットフォーム級の能力を担います：

1. 企業知識ベース：制度、ドキュメント、プロセスを、検索可能・検証可能な企業知識として沈殿させます；
2. 会話メモリ：日常の協働と Q&A を自動的に長期記憶として沈殿させ、組織は使っても忘れません；
3. 知識の関連付け：知識同士のつながりを理解し、多段階の追い質問をサポートします —— 事実をつないで判断にします。

engram は identity、inference と並んで三大基盤の 1 つであり、スイート内のすべての製品が消費します。engram が答えるのは「あなたが何を知っていて、覚えているか」であり、identity が答える「あなたは誰か」と相互補完します。

12.2 中核能力

12.2.1 企業知識ベース

制度、ドキュメント、プロセスを企業知識ベースとして沈殿させ、Q&A は内部資料に直接基づいて回答します —— 根拠があり、捏造しません。AI に、汎用知識の表面的な話ではなく、企業自身の知識で企業の問いに答えさせます。

12.2.2 会話メモリ · 自動沈殿

日常の協働と Q&A が自動的に長期記憶に沈殿します。システムが自動で要約し、ノイズを除去し、矛盾を解消します —— 知識ベースは使うほど正確になり、自ら成長します。ルームを切り替えても、マルチ AI 協働でも、それぞれフレッシュスタートすることはありません。

12.2.3 知識の関連付け · 多段階の追い質問

単一の質問に答えるだけでなく、知識同士のつながりを理解し、「まず A を尋ね、次に B を追う」ような多段階の追い質問をサポートします —— 事実をつないで判断にします。ばらばらの検索結果ではありません。

12.2.4 コンテンツ安全 · 段階別管理

機微なコンテンツを段階別に管理します。誰が何を見られるか、何を外部に出せないかを、企業の制度に応じて柔軟に設定できます —— 機微なほど制御され、漏洩を発生源で防ぎます。

12.2.5 権限の統一 · 全工程の痕跡

知識へのアクセスとアイデンティティ権限を統一的に管理し、照会のたび、回答のひとつひとつを追跡できます —— 部門間のデータは厳格に分離され、それぞれ自分の範囲だけを見て、同じアイデンティティ認証に接続します。

12.2.6 軽量デプロイ · データは外部に出ない

軽量で、占有が小さく、中国語を優先します。企業知識は常に企業内に留まります —— データは外部に出ず、使うほど企業を理解し、完全オフラインでデプロイ可能です。

12.3 差別化

• 3 つを 1 つにした基盤：知識ベース、会話メモリ、知識の関連付けを 1 つの基盤で貫通し、複数の単点ツールの寄せ集めではありません；
• 使うほど正確：自動沈殿で知識ベースが自ら育ちます。「データは外部に出ず、知識は蓄積され、乗り換えられない」は実感できるセールスストーリーです；
• オンプレミス向けの軽量さ：軽量デプロイ、単一基盤、中国語優先。ToB オンプレミスの要点をすべて押さえます；
• 全製品が消費：cohort の AI 従業員はその記憶で判断し、studio がオーケストレーションしたアプリはその知識ベースで地に足のついた回答をします。

13. inference —— 算力・モデルサービス

一言で：企業のプライベート AI インフラに、算力とモデルの統一コントロールプレーンをもたらします —— 異種の算力を統一的に管理し、モデルサービスをガバナンス付きで提供し、検証可能・ロールバック可能な 1 つのクローズドループ。

13.1 位置づけ

inference は TUEO 体系の算力・モデルサービス基盤であり、3 種類のプラットフォーム級の能力を担います：

1. 異種算力の統一管理：異なるベンダー、異なる型番のアクセラレータハードウェアを 1 つのコントロールプレーンで管理し、各プールは独立して運用；
2. 標準モデルサービス：業界標準のモデル呼び出し方式を提供し、既存アプリはほぼ変更なしで接続可能；
3. 算力ガバナンスのクローズドループ：モデル、デプロイ、学習、割り当て、使用量、監査を 1 つのコントロールプレーンで管理し、コストを把握。

inference は identity、engram と並んで三大基盤の 1 つです。それは体系全体のモデル呼び出しの統一入口であり —— 各製品がそれぞれ別のモデルサービスに接続することはもうありません。

13.2 中核能力

13.2.1 異種算力、1 つのプレーン

異なるベンダー、異なる型番のアクセラレータハードウェアを 1 つのコントロールプレーンで統一的に管理します —— 各プールは独立して運用され、互いに干渉しません。算力の状況は透明に見え、異種リソースをごちゃ混ぜにしません。

13.2.2 標準モデルサービス、すぐに使える

業界標準のモデル呼び出し方式を提供し、既存アプリはほぼ変更なしで接続できます —— 下層がどのハードウェアでもアプリは感知せず、ランタイムの差異を遮断します。

13.2.3 モデルの全ライフサイクル管理

モデルの接続、本番投入、アップグレード、スケール変更、ロールバックを全プロセスで管理します —— 稼働中のサービスは安定して中断せず、変更は制御可能で、元に戻せます。

13.2.4 モデル学習、受管タスク

モデルのファインチューニングと学習を管理されたタスクとして実行し、オンラインサービスと同じプラットフォームで管理して進捗が見えます —— 一時的なスクリプトとは決別し、学習の成果物は統一的にアーカイブします。

13.2.5 アクセスガバナンス · 割り当て · 監査

誰が呼び出せるか、どれだけ呼ぶか、いくら使ったかを、アイデンティティと権限に統一的に接続します —— 呼び出しのたびに帰属・計量・監査が可能で、コストを把握できます。

13.2.6 オフライン納品 · 現地受入

完全オフラインでのインストール、アップグレード、ロールバックをサポートし、現場で診断と受入を提供します —— エアギャップ環境でも納品でき、算力能力の導入が確実です。

13.3 差別化

• 算力もマシンルームへ：アプリケーションだけでなく、モデルサービスと推論も顧客のマシンルームにデプロイされます —— データとモデルの外部呼び出しゼロ；
• 異種への誠実さ：異なるハードウェアは各プールが独立し、統一リソースプールに偽装しません。算力の状況は透明に見えます；
• 1 つのクローズドループ：モデル、デプロイ、学習、割り当て、使用量、監査を 1 つのコントロールプレーンで管理し、検証可能・観測可能・ロールバック可能；
• 全製品が消費：cohort と studio の AI アプリはそれを経由してモデルを呼び出し、engram の知識 Q&A はそれから算力を得ます。

14. 1 回の呼び出しの完全な旅路

1 つの言葉から、制御された実際の実行まで、1 つの工単の完全な旅路です：

① 人が cohort のグループチャットで：@工程 AI 「このバグを修正して」
   ↓ coordinator ルーティング（サーバー側の職責スコアリング + LLM 仲裁 + 監査）
② AI 開発チームのトリアージ：インテント認識 → DoR（AI が再現手順を自己補完）→ TriageService がチケット発行
   ↓ パスポートゲート + ツールホワイトリストの厳格な検証
③ 工単ステートマシン：triaged → spec → plan → coded → reviewed → tested → merged
   ↓ コーディング実行（executor サンドボックス / ローカルペアリング）
④ エンジンがコードを実際に変更し、テストを実際に実行し、実際に commit；視覚的自己検証
   ↓ MR を cohort が GitLab API で開く → Code Review → Merge ゲート
⑤ 成果を工単に書き戻し、会話スレッドに書き戻し；AI の振り返りが長期記憶に書き込まれる

全工程を identity が認証し、capabilities がガバナンスし（サードパーティ能力を呼び出す場合）、executor / エンジンが隔離し、監査に記録します —— AI が強くなるほど、境界は明確になります。

15. 製品横断の設計原則

TUEO はそれぞれが独立した製品の集合ではなく、統一された設計哲学を持つシステムです：

生産 / 消費の二分法は体系全体で最も中核的なアーキテクチャ上の裁定です：「能力の真実」を誰が持つか（capabilities）、誰がただ「能力を消費する」だけか（cohort / studio）—— 越境せず、パラレルワールドを作りません。

SSOT の集約は体系全体で第二の中核です：組織ディレクトリ → identity、AI 従業員の名前 → identity、AI 従業員の職務プロファイル → registry、能力 → capabilities、メッセージ → cohort、実行 → executor、オーケストレーション → studio、納品 → console。すべての境界に単一真値が存在し、「2 か所にそれぞれ 1 部ずつあり、徐々にドリフトする」という欠陥の根本原因を排除します。

16. セキュリティとコンプライアンス体系

16.1 多層防御

16.2 証明可能な監査

• identity：テナントごとの SHA-256 contentHash + prev_hash ハッシュチェーン。改ざん（挿入 / 削除 / 並び替え / 行の変更）を検出可能；
• cohort：20 種の監査イベントをサーバー側で集約 + 管理者 Web コンソールで照会 / 保持 / アーカイブ；
• studio：run-trace イベントログ（append-only）から監査を投影し、1 件ごとに「リプレイ」して実行軌跡に戻れる；
• capabilities：ファーストクラスのイミュータブル監査テーブル（マイグレーションは SELECT + INSERT のみ許可、改ざん不可）；
• executor：全操作の監査 + CloudEvents イベントの外部発信。

16.3 マルチテナント分離

全プラットフォーム統一モデル：identity の token がテナントを明記 → 各製品が RLS で物理分離 → fail-closed（テナントを取得できない場合は直接拒否）。1 つのシステムで複数テナント / 複数部門にサービスを提供でき、テナント間の漏洩はゼロ。

17. オンプレミスとオフライン納品

17.1 納品形態

• オフライン bundle + license：体系全体をオフライン bundle にまとめ、署名付き License でアクティベートし、完全なネットワーク切断環境での運用をサポート；
• k3s 同梱：顧客の既存 K8s クラスタに依存しない。顧客既存クラスタの専用 namespace を納管することも可能；
• 単一ドメインのオールインワン：単一の外部ドメイン + パスルーティング。すべての製品が同一オリジン、1 つのセッションで標準 OIDC；
• データが企業の外に出ない：モデルは顧客自社管理のゲートウェイ / ローカルモデルを経由し、秘密鍵が顧客ネットワークの外に出ず、全工程で監査可能。

17.2 エアギャップサプライチェーン

• 再現可能 CI：2 層のイミュータブルなオフラインイメージ、ビルドはネットワーク接続ゼロ、署名付き + SBOM 付き；
• 制御された更新：.tueoupdate 署名付きパッケージ（Ed25519 署名検証 + 事前検証の互換性ゲート + ディレクトリセグメント転送）、未署名パッケージは拒否；
• オフラインアクティベーション：署名付き License をネットワーク接続ゼロでアクティベート + ソフトノードロック deploymentId。

17.3 運用の到達可能性

1 つの入口ですべてのサービス + ミドルウェアを運用：設定 / ログ / ステータス / デプロイ / バックアップ / アップグレード / 監査を、すべて運用プラットフォームの 1 つの画面で完結。データポートは露出せず、高リスク操作はオンデマンドの一時セキュアトンネル経由。

18. 適用シーンと顧客価値

18.1 対象業界

複雑性・ガバナンス・リアルタイム協働の要求が高い業界：製造（契約履行）、金融（リスク管理プロセス）、医療（機微な情報の協働）、行政、公安、エネルギー、物流、小売、教育、法律。

18.2 典型的な顧客像

• 主：すでにデジタルシステムを導入し、AI を組織の運営に入れたい中堅・大企業。すでに AI を導入しているが、実行 / セキュリティ / 復旧の各層が不足している企業；
• 次：企業 AI プラットフォームのパイロットを試したい部門レベルの顧客。

18.3 顧客価値

19. 現状とロードマップ

以下は 2026-08 時点の現状です。10 つの製品はすべて本番環境で運用中です。継続的に強化中の機能は対応する製品の項目に注記します。

19.1 実証済みの完全なクローズドループ能力

以下の能力はすべて実環境で運用検証済みであり、外部に自信を持って説明できます：

• AI 開発チームの dogfood クローズドループ：工単 → Passport ゲート → LLM トリアージ → 実際のコーディング → LLM レビュー → 実際の GitLab CI → 失敗の自動修正 → 実際のマージ → 自動デプロイ → ヘルスチェック → ロールバック。TUEO は自分の 8 人の AI 従業員で自分の 5 つのコードリポジトリを開発しています；
• AI による旧システムの運用：ai-ops 運用 AI が MCP 経由で接続し、アラート / 定期点検 / 容量監視 / ローカルの多ステップ実行計画を担い、従来システムの運用を支援；
• 能力の統括（System-as-Capability）：OA / ERP / CRM / MES などの既存システムを、AI が呼び出せ・認可でき・監査でき・メータリングできる能力に接続し、能力プラットフォームのゲートウェイと統合；
• studio オーケストレーションエンジン：11 種類ノード + イベントソーシング + 永続的な一時停止・再開が本番運用され、インテリジェント基盤の定義層のオーケストレーションの中核に；
• 能力プラットフォームのコンシューマ側の一本化：cohort / studio はどちらも SDK / S2S 経由で能力プラットフォームを消費（インストールゲート / 課金ゲート / 範囲ゲート / 資格情報注入）、コンシューマ側は実行基盤に直接接続しない。

マイルストーン：オンプレミス納品は憲法級の基本方針。10 つの製品はすべて本番運用中。AI 開発チームが TUEO 自身の製品で TUEO を開発する（dogfood）が日常。インテリジェント基盤の完全なクローズドループ（定義 → 開発 → テスト → 本番投入 → 運用 → 能力再利用 → 統括）が実環境で通っています。

付録 C · 用語集

TUEO —— AI をあなたの組織の正社員に。