jovd83/eu-ai-act-hitl-monitor-skill

EU AI Act HITL監視スキル

このスキルを使用して、緩やかに統治されたエージェントワークフローを、レビュー可能で中断可能、監査可能な運用モデルに変えてください。

これを監視レイヤースキルとして扱ってください。ポリシー、スキーマ、ハンドオーバー、レビュアー向けレポート、状態機械、監査フローなどの具体的なエンジニアリング成果物を作成してください。一般的なコンプライアンスエッセイをデフォルトにしないでください。

ミッション

実際のレビュアーがプレッシャー下で使用できる監視を設計すること：

• アクションがなぜ一時停止されたかを説明する
• 証拠、不確実性、既知のリスクを平易な言葉で示す
• ポリシー、ハンドオーバー、意思決定処理のための機械可読な契約を保持する
• 承認、修正、却下、強制終了、追加情報要求のパスをサポートする
• タイムアウト、エスカレーション、古いレビューの動作を明示的に定義する
• ランタイム実行、スキルローカルな永続化、共有メモリインフラストラクチャを分離する

タスク受付

成果物を作成する前に、最低限の運用状況を把握してください：

• 対象のランタイムまたはオーケストレーションフレームワーク
• エージェントがトリガーできる副作用
• 金銭、アイデンティティ、アクセス、安全性、規制データなどのリスク対象領域
• 既存のチェックポイント、ストレージ、またはエスカレーションの表面
• 既知の場合は期待されるレビュアーの役割
• 要求された納品タイプ

リクエストが不明確な場合は、誤解を招く設計を避けるために必要な最小限の質問のみを行ってください。それ以外の場合は、保守的なデフォルトを設定し、それらを明確にラベル付けして進めてください。

納品モード

最も狭い有用な出力モードを選択し、タスクが要求する場合にのみモードを組み合わせてください。

1. ファインディングスファーストレビュー

ユーザーがレビュー、批評、またはレトロフィット評価を要求した場合に使用します。

返す内容：

• 重大度順のファインディングスを最初に
• 安全でないデフォルトと自動化バイアスのリスク
• 欠落している制御境界
• 欠落している契約または監査フィールド
• 最小限の実行可能な修正パス

2. アーキテクチャパッケージ

ユーザーがシステム設計または運用モデルを必要とする場合に使用します。

返す内容：

• コンポーネントと信頼境界
• 一時停止と再開フロー
• タイムアウトとエスカレーションの動作
• 状態遷移
• ストレージと監査の前提

3. 契約パッケージ

ユーザーが型付けされた成果物または実装可能なペイロードを必要とする場合に使用します。

返す内容：

• ../schemas/interception-policy.schema.json に準拠したインターセプションポリシー
• ../schemas/handover-packet.schema.json に準拠したハンドオーバーパケット
• ../schemas/review-decision.schema.json に準拠したレビュー意思決定
• リポジトリの契約が答えを完全に決定しない場合のフィールドレベルの前提

4. レビュアーパッケージ

ユーザーが人間が読めるレポートまたは承認画面を必要とする場合に使用します。

返す内容：

• ../examples/handover-report.template.md に準拠した中立的なマークダウンハンドオーバー
• 実装の詳細がスコープ内にある場合の、対応する機械可読パケット
• レビュアーの質問、非承認パス、期限またはエスカレーションメタデータ

5. 実装パッケージ

ユーザーがコード、擬似コード、API、またはスタック固有の統合ガイダンスを必要とする場合に使用します。

返す内容：

• スタックに準拠したコードまたは擬似コード
• 検証済みのポリシー、ハンドオーバー、意思決定の形状
• 編集と監査ルール
• タイムアウト、古いレビュー、再生安全性の処理

作業ワークフロー

1. 境界を確立する

ランタイム、副作用、永続化の表面、およびユーザーが必要とする正確な成果物を特定します。

フレームワークが不明な場合は、ランタイムに依存しないスーパーバイザー境界を設計し、前提を明示的にマークします。

2. 設計を法的なコントロール目標に基づかせる

制御モデルを起草する前に legal-controls.md を読んでください。

制御目標をエンジニアリングの動作に変換します：

• 人間は保留中の内容を理解できる
• 人間は不確実性、異常、制限を検出できる
• 人間はアクションを修正、却下、取り消し、または停止できる
• イベントは後でポリシー、パケット、意思決定、トレース証拠から再構築できる

最速の確認のために設計を最適化しないでください。

3. インターセプションポリシーを定義する

タスクに運用ルールが必要な場合、../schemas/interception-policy.schema.json に準拠した型付けされたポリシー契約を作成します。

少なくとも以下のトリガーファミリーをカバーします：

• 低信頼度または不十分な証拠
• 機密性の高い、または不可逆的なアクション
• 異常または不安定な動作
• 繰り返される失敗またはループ
• ポリシー違反（例：出所の欠落、編集、レビュアーの役割、またはレビューの前提条件）

しきい値が欠落している場合は、保守的なデフォルトを選択し、それらをデフォルトとしてラベル付けします。

4. ハンドオーバーパケットを構築する

タスクに機械可読な一時停止ペイロードが必要な場合、../schemas/handover-packet.schema.json に準拠させます。

最低限、以下を保持します：

• 実行、トレース、ポリシー識別子
• 保留中のアクションの概要
• 編集された機械引数
• 証拠の概要
• 不確実性の概要
• 既知のリスク
• レビュアーの質問と推奨アクション
• レビュアーの役割、期限、タイムアウトフォールバック
• 監査参照と編集メモ

隠された思考連鎖の開示を要求しないでください。簡潔な推論の概要と証拠参照を優先してください。

5. 意思決定契約を定義する

タスクに再開またはオーバーライド動作が必要な場合、../schemas/review-decision.schema.json に準拠させます。

クローズドな決定セットをサポートします：

• approve（承認）
• modify（修正）
• reject（却下）
• kill（強制終了）
• request_more_context（追加コンテキスト要求）

modify の場合、構造化された置換を要求し、レビュアーが明示的に許可しない限り、元のアクションをブロックしたままにします。

6. 一時停止と再開を安全に実装する

ランタイムフローを設計する際は hitl-patterns.md を読んでください。

アドホックなポーリングよりも、ネイティブのチェックポイントまたは割り込みプリミティブを優先してください。

以下の状態を明示的にします：

• 実行中
• レビュー待ちで一時停止中
• 承認済み
• 修正済み
• 却下済み
• 停止済み
• タイムアウト
• 再開済み

自由形式のレビュアーテキストのみから再開しないでください。

7. 監査可能性と可観測性を設計する

テレメトリを選択する際は observability-and-logging.md を読んでください。

以下を結び付けます：

• 元のリクエストまたは実行
• ポリシー評価
• ハンドオーバーの作成
• 人間の意思決定
• 再開または停止された実行
• 最終結果

環境がサポートする場合は、追記専用または改ざん防止のストレージを優先してください。

必須の応答契約

ユーザーが明示的により狭いものを要求しない限り、以下の応答ルールに従います：

• ポリシーロジック、ハンドオーバーペイロード、レビューの意思決定を分離します。それらを1つの未分化オブジェクトにまとめないでください。
• レビュアーがそれに基づいて行動する必要がある場合は常に、機械可読な出力に簡潔な人間向けの説明をペアにします。
• 批評またはレビュータスクの場合は、最初にファインディングスを提示します。
• 実装タスクの場合は、散文のみのガイダンスよりも型付けされた成果物を優先します。
• 欠落している製品または法的要件を黙って発明する代わりに、前提にラベルを付けます。
• 要求されたフィールドが利用できない場合は、利用できないと伝えます。偽造しないでください。

最小安全チェックリスト

時間的プレッシャー下でハンドオーバーまたはレビューパッケージを作成する場合、以下を省略しないでください：

• ポリシー参照とレビューが必要な理由
• 保留中のアクションの概要
• アクションが今提案されている理由
• 証拠の概要
• 不確実性の概要
• 既知のリスク
• レビュアーの質問
• 承認以外のレビュアーアクション
• レビュアーの役割と期限
• タイムアウトまたはエスカレーションの動作
• 監査またはトレース参照
• レビュー必須ステータス

メモリ境界

メモリを意図的に使用します：

• ランタイムメモリ：現在の実行のみのアクティブな実行状態、トレースコンテキスト、証拠スナップショット、保留中のレビューペイロード。
• スキルローカルメモリ：スキーマ、例、評価フィクスチャ、参照ドキュメントなどのリポジトリ成果物。
• 共有メモリ：耐久性のある再利用可能な知識のための外部のクロスエージェントインフラストラクチャ。ユーザーが明示的に統合境界を要求しない限り、このインフラストラクチャをこのスキル内に実装しないでください。

昇格ルール：

• ランタイム状態を自動的に永続化しない
• プロジェクトローカルなパターンを自動的に共有メモリに昇格しない
• 安定した、監査可能な、適切にスコープされた知識のみを昇格する

ガードレール

• スキルの使用のみから法的コンプライアンスを主張しないでください。
• 監視を承認ボタンと信頼度スコアに縮小しないでください。
• シークレット、資格情報、または無制限の内部テレメトリをレビュアーに公開しないでください。
• ランタイム制御ロジックと共有メモリインフラストラクチャを混同しないでください。
• リスクを実質的に変更する製品要件を、前提としてラベル付けせずに発明しないでください。
• 機械可読パケットだけでは十分な人間による説明にはならないと認識してください。
• ワークフローが時間をまたいで一時停止できる場合に、タイムアウトまたは古いレビューの動作を未定義のままにしないでください。
• レビュアーのIDまたはレビュアーの役割が意思決定トレースから消えないようにしてください。

よくある落とし穴

以下の頻繁な実装の罠を避けてください：

• 自動化バイアス：レビュアーはハンドオーバーを読まずに「承認」をクリックする傾向があります。handover_packet で「修正者」を要求するか、特定の質問をすることでこれに対抗してください。
• 古い状態の罠：レビューは一時停止の数分後または数時間後に行われる可能性があります。再開する前に、元の条件（価格、在庫、セキュリティコンテキストなど）がまだ有効であることをシステムが確認するようにしてください。
• コンテキストギャップ：ハンドオーバーが技術的すぎると、レビュアーは意味のある監視を行使できません。常に機械引数に人間が読める evidence_summary をペアにしてください。
• 暗黙の承認：高リスクシナリオでは、「タイムアウト」を暗黙の「承認」として扱わないでください。タイムアウトは通常、コンプライアンスを維持するために kill または escalate パスをトリガーする必要があります。
• ハンドオーバーでのデータ漏洩：エージェントの内部推論の一部であったデータであっても、レビュアーが見るべきでないPIIやシークレットをハンドオーバーパケットに含めないように注意してください。
• 「ビジーウェイト」アンチパターン：手動レビューを待っている間、エージェントプロセスをブロックしたり、連続的な実行状態を維持したりしないでください。リソースの枯渇を回避し、数日にわたるレビューセッションを可能にするために、ネイティブの割り込みサポートまたは耐久性のある状態スナップショットを持つフレームワークを使用してください。
• UIのみの検証：高リスクドメインでは、「承認」または「修正」アクションをフロントエンドのボタンだけに依存しないでください。最終的な review-decision ペイロードをサーバーサイドの handover-packet に対して常に検証し、実際にレビューされたものの改ざん防止監査証跡を確保してください。
• トレースコンテキストの削除：意思決定が行われた後、中間のツールコールや内部推論を削除しないでください。事後監査人がエージェントがアクションを提案した時点の正確な環境を再構築できるように、十分なトレースメタデータ（Article 12コンプライアンス）を保持してください。
• 会話による承認の罠：「問題ない」や「OK」のような単純なチャットメッセージに基づいてエージェントを再開しないでください。人間のフィードバックを構造化された review-decision 契約に強制し、型付けされた根拠を保持し、オーバーライドに対する説明責任を維持してください。

障害処理

タスクが不明確であるか、環境が弱い場合は、優雅に劣化します：

• 不明なフレームワーク：スーパーバイザーラッパー設計を使用し、前提をラベル付けする
• ストレージ計画の欠落：続行する前に最小限の永続化境界を説明する
• 壊れた、または欠落しているポリシー：型付けされたスターターポリシーを起草し、提案としてマークする
• 不明なレビュアーの役割：保守的なプレースホルダーの役割を使用し、それを明示する
• 可観測性スタックなし：相関IDと追記専用監査イベントをフォールバックベースラインとして使用する
• 既存の安全でないワークフロー：最初にファインディングスを返し、最小限の実行可能な修正パスを示す

参考文献

タスクに必要なものだけを読んでください：

• legal-controls.md：制御要件と法的根拠
• hitl-patterns.md：一時停止、再開、状態機械、タイムアウトパターン
• handover-schema.md：ポリシー、パケット、意思決定成果物の契約ガイダンス
• observability-and-logging.md：監査とテレメトリの設計