NexusCore Minimal Governance

0. このドキュメントの位置づけ

  • 対象: NexusCore（自己修復型・自律エージェント基盤）。AKM（Atelier-Kyo-Manager）には適用しない。
  • 目的: AI/Orchestrator/Human の行動を「最小限の統治ルール」で制約し、外部提供（SaaS/API）に耐える説明責任を確保する。
  • 優先順位: 速度よりも 安全性・証跡・再現性 を優先する（ただし探索を止めない最小統治に留める）。
  • 関連文書: AI Collaboration Rules: docs/governance/AI_COLLABORATION_RULES.md

1. NexusCore の基本原則（Principles）

  • 自己修復は許可するが、自己正当化（根拠なしに「正しい」と断言する）は禁止。
  • 進化（試行錯誤）は許可するが、不可逆変更（戻せない変更）は禁止。
  • AI は「提案者」であり「最終決定者ではない」。
  • 失敗は負債ではなく資産。失敗証跡の保存は成功ログより優先。

2. システム構成と責務境界（Responsibility Boundaries）

  • Human: 統治者（ルール制定・承認・例外判断）
  • Orchestrator: 実行統制者（権限境界の強制、監査ログ、実行計画、停止判断）
  • Agents: 実働部隊（収集・修復・解析・提案）
  • Experimental: 破棄前提の試験領域（本番資産への影響を遮断）

3. 禁止事項（Hard Constraints）

ここは「AIがやってはいけないこと」を明示し、例外を作らない。

  • Governance 自体の改訂・削除・無効化
  • Freeze 対象（後述）のコード/設定の直接変更（AI単独では不可）
  • 監査証跡（ログ、差分、失敗分析、スクショ、HAR 等）の削除・改ざん
  • コスト上限・LLM ルーティング・シークレット（APIキー等）の自己変更
  • 外部への無承認送信（ログ/HTML/機密情報を第三者へ送る行為）

4. Freeze ポリシー（Minimal）

4.1 Freeze 対象（厳格）

  • Orchestrator（実行統制ロジック）
  • LLM Controller（プロバイダ/モデル選択、フォールバック、キャッシュ、コスト計上）
  • RunContext / History / Diff / Evidence（証跡管理）

4.2 Freeze 非対象（自由度高）

  • 個別 Agent の戦術ロジック
  • プロンプト・テンプレート
  • サイト別セレクタ・設定（ただし証跡と差分は必須）
  • UI/CLI（ただし監査ログ連携を壊さない）

5. 変更の分類と許可レベル

  • Level 0: AI 不可（Human 専権）
  • Level 1: AI 提案のみ（Human 承認が必要）
  • Level 2: 条件付き実行可（テスト・差分・証跡が条件）
  • Level 3: 自動実行可（自己修復領域）
  • Level 4: 完全自律（実験領域、破棄前提）

権限レベル定義（本書では Level 0 / Level 1 のみ文章化）

Level 0（AI 不可）

定義

AI が「提案」すら実行のトリガーにできない領域。変更は Human が直接行い、監査ログに記録する。

対象（最低限）

  • Governance 文書・Freeze Policy の改訂
  • Orchestrator の権限強制ロジック、境界判定ロジック
  • LLM Controller のプロバイダ/モデル/コスト上限/鍵管理
  • 証跡（RunContext/History/Diff/Evidence）の保存方式・削除規則

要件（必須）

  • 変更は必ず差分として保存（例: patch / diff / commit）
  • 変更理由（Why）と影響範囲（Impact）をセットで残す

Level 1（AI 提案のみ）

定義

AI は差分案を作成してよいが、適用（マージ/上書き/デプロイ）は Human の承認を必須とする。

対象（例）

  • Orchestrator の非本質的改修（ログ整形、メッセージ改善、軽微な互換修正）
  • Core API（外部連携）周りの仕様変更
  • 重要なデータモデル（ResultModel、Evidence Schema）の変更

AI が出すべき成果物（最低限）

  • 変更提案（差分/パッチ）
  • 影響範囲（どのモジュール・どのユースケースに影響するか）
  • リスク（破壊的変更、後方互換、コスト増）
  • 代替案（少なくとも1つ）
  • ロールバック手順（戻し方）

以降のセクション（2026-04-19 追記）

6. 失敗・自己修復の扱い

6.1 失敗の分類

Orchestratorは発生直後にエラーを以下のいずれかに分類する。

  • Recoverable（回復可能）: リトライ、代替ルート、キャッシュ利用で自己完結解決可能なエラー（例: 一時的なネットワーク不達、APIタイムアウト）。
  • Irrecoverable（不可回復）: データ不整合や外部サービスダウン等、自動リトライでは解決不可。処理の安全な中止が必要。
  • Escalation（エスカレーション）: AIの権限上限（Level 2-3）を超える、またはビジネス上の重大決定を要するもの。即座にHumanへ引き継ぐ。

6.2 FKBへの記録ルール

分類された全ての失敗をFKBに記録する。

  • 記録内容: 発生時刻、Agent ID、実行コンテキスト、入力/出力（機密はNPEマスキング必須）、エラースタック、NPE脅威判定結果。
  • フォーマット: 構造化JSON（{timestamp, agent_id, error_type, context, npe_threat_level, resolution_status}）。
  • 参照ルール: AIは修復アクション提案・実行時に必ずFKB過去履歴を参照し、同一原因の再発を防止すること。

6.3 自己修復の許可条件

自己修復はRecoverableに分類された失敗に限定し、事前のQuality Gates（Tier 1/2）を通過した既知の修復パターンのみ適用。

  • Level 2（Agent個別）: リトライ、フォールバック機能の利用、Experimental環境での再試行。
  • Level 3（Orchestrator）: タスクの別Agentルーティング、一時的リソース再割り当て、安全なプロセス再起動。

6.4 リトライ制限

  • 最大回数: 同一コンテキストで3回まで。4回目はIrrecoverableに再分類しリトライを即時中止。
  • バックオフ戦略: Exponential Backoff必須（例: 1秒 → 2秒 → 4秒）。

6.5 Humanへのエスカレーション条件

以下のいずれかに該当する場合、Orchestratorは即座に実行を中断（または安全な保留状態へ遷移）し、Humanへ通知する。

  • 失敗がLevel 4（システム全体影響）またはLevel 0（AI不可領域）に触れる場合
  • 自動リトライ上限（3回）に到達した場合
  • NPEが脅威レベル「Critical」と判定した場合
  • 修復コスト（金銭的・計算量的）が事前定義しきい値を超過する場合

7. 外部公開・SaaS時の前提

7.1 マルチテナント分離の要件

  • データ分離: テナントごとの論理的分離（個別スキーマまたは暗号化分離）を必須とする。
  • 実行環境の分離: Orchestratorはテナント別のコンテキスト（メモリ/計算資源）を完全に分離してタスクを実行。他テナントのAgent状態へのアクセスはLevel 0（禁止）。

7.2 API認証・レート制限

  • 認証: トークンベース認証（OAuth2.0等）を全外部APIエンドポイントで必須とする。
  • レート制限: テナントごと、エンドポイントごとに1分間リクエスト上限を定義。制限超過時はHTTP 429を返却。

7.3 データ保持・消去ポリシー

  • 保持期間: 監査ログは法令・コンプライアンス要件に基づき規定期間（例: 1年間）保持。Agent一次処理メモリはタスク完了後速やかに破棄。
  • 消去要件: テナント契約終了時、関連全データを保持期間後に暗号化キーごと消去し、復元不可能にすること。

7.4 監査ログの外部提供フォーマット

  • フォーマット: Append-onlyかつ機械可読（JSON Lines または Apache Parquet）。
  • 必須フィールド: timestamp, tenant_id, actor, action, target_resource, level, decision_basis。

7.5 SLA・インシデント対応

  • SLA: API正常稼働率およびOrchestratorタスクスループットの定量的目標値（例: 99.9%）を定義。
  • インシデント対応: 重大障害時はNPEが即検知しHumanへ自動通知。対応状況は外部ステータスページで公開。

8. 改訂ルール

8.1 改訂の発議・承認フロー

  • 発議: Human（統治者）のみが発議権を持つ。AIは「最適化案」をLevel 1（提案のみ）として提示可能だが、自ら発議・改訂することはLevel 0（禁止）。
  • 承認: 発議された改訂案はHumanレビューを経て正式承認されるまでNPE等には反映されない。

8.2 改訂の分類

  • 軽微修正: 文言修正、タイポ修正、ログフォーマット追加等。単独Human承認で即時反映。
  • 構造変更: Agent権限調整、新エスカレーションルート追加等。複数Human承認（関係者合意）を必須。
  • 原則変更: Level 0-4権限定義、不可逆変更禁止等の根本原則の変更。最高権限者承認および全体影響評価テストが必須。

8.3 改訂履歴の管理

  • 改訂履歴はGit等のVCSで管理し、証跡の削除・改ざんを禁止（Level 0）。
  • 承認後のルールはNPEに即同期し、以降のシステム動作に適用。

8.4 緊急変更（Hotfix）

  • Hotfixフロー: 緊急時、単独Human権限者による一時的ルール変更を適用しシステムを安全圏に退避させることが可能。
  • 事後承認義務: Hotfix適用後48時間以内に正式な発議・承認フロー（8.1）を遡及実施。妥当と判断されないHotfixは直ちに撤回。

改訂履歴

日付 セクション 変更概要
2026-04-19 Sec 6-8 失敗・自己修復、SaaS前提、改訂ルールを新規作成
2025-12-16 Sec 0-5 初版作成（原則、責務境界、禁止事項、Freeze、権限レベル）
This site uses Just the Docs, a documentation theme for Jekyll.