business-compliance

業務コンプライアンス

Hexagone Web アプリケーションのページまたはコンポーネントに対して、完全自律型のドメインコンプライアンス監査を実行します。このスキルは、docs/domain/ に記載された業務ルールを検出し、対象画面のエンティティと境界づけられたコンテキストを抽出して、該当するルールを照合し、ドメイン不変条件への違反を検出します。そして、必須の引用を含む構造化レポートを出力します。ファイルは一切変更しません。このスキルはレポートのみを出力します。 意味上の影響や患者の安全に及ぼす影響が、機械で判断するには大きすぎるため、業務ルール違反を自動修正することはありません。

このスキルを使用する場面

ユーザーが次のような場合に有効化します。

• 「business-compliance」に続けて URL、コンポーネント名、またはページ名を指定する
• 画面上のドメインルール、業務ルール、不変条件の監査を依頼する
• 「ビジネスロジックを確認して」「ドメインルールを監査して」「業務レビュー」と依頼する
• 画面が docs/domain/ に記載された不変条件を適用しているか検証したい

design-compliance との関係

design-compliance と business-compliance は相互補完的ですが、別々のスキルです。

	design-compliance	business-compliance
監査対象	ビジュアル／プレゼンテーション層	ドメイン／業務ロジック層
信頼できる情報源	hexagone-preset.js、CLAUDE.md、デザインルール	docs/domain/（DDD 構造の Markdown）
モード	すべての違反を自動修正	レポートのみ。修正は行わない
リスクプロファイル	低（見た目上の問題）	高（患者の安全、規制）
レビュアー	フロントエンド開発者	ドメインエキスパート、臨床 PO、コンプライアンス担当者

統合しないでください。必要に応じて、それぞれを個別に実行してください。統合された screen-compliance アグリゲーターは v1 の対象外です。

基本原則

1. 完全な自律性

• パイプライン全体を実行中に質問することなく実行します
• 引数が指定されていない場合は、レビュー対象をユーザーに尋ねてから、自律的に実行します
• ファイルは一切変更しません。 レポートはターミナルにのみ出力します

2. レポートのみ — 自動修正なし

医療ソフトウェアで業務ルール違反を自動修正することは、断じて安全ではありません。機械による「修正」は、次のような結果を招く可能性があります。

• 警告をブロックに変える（正当な医療を停止する）
• ブロックを警告に変える（ショートカットというアンチパターンを常態化させる）
• 人によるレビューを経ずに、臨床上の意味を黙って変更する

このスキルは違反を提示し、記録し、引用します。修正は人間（開発者とドメインエキスパート）が判断します。

3. スキーマ優先

このスキルでは、docs/domain/ が構造化されたルールスキーマ（reference/rule-schema.md を参照）に従っている必要があります。スキーマが守られていない場合、このスキルは監査を拒否し、移行チェックリストを出力します。入力が不正確であれば、出力される検出結果は幻覚になります。これは譲れない条件です。

4. 決定論的な照合パイプライン

画面とルールの照合は、LLM による推論の前に、決定論的なパイプラインで実行します。

1. 画面の抽出（決定論的）— ルート、Pinia ストア、API エンドポイント、TypeScript 型
2. 境界づけられたコンテキストによる事前フィルタリング（決定論的）— ルールのフロントマターにある api_prefixes を使用
3. エンティティの検索（決定論的）— 抽出した型をルールの entities: リストと照合
4. ルールの推論（LLM）— 絞り込んだルールのみを対象とする

LLM を使用するのはステップ 4 のみです。ステップ 1〜3 は機械的に実行します。

5. 具体性よりも感度を優先

医療分野では、偽陰性は致命的であり、偽陽性は煩わしいものです。このスキルは感度を優先するよう調整されています。不確かな場合、ルールを黙って除外せず、ステータス NEEDS_CLINICAL_REVIEW として報告します。

6. 引用必須

すべての検出結果には、次の内容を必ず引用する必要があります。

• docs/domain/ 内の正確なルールファイルと行番号（または見出しアンカー）
• 違反箇所の正確なコードファイルと行番号
• 安定した rule_id（例：ADM-001、PRESC-014）

3 つすべてが引用されていない検出結果は、レポートから除外されます。引用がなければ、検出結果もありません。

情報源の優先順位

1. docs/domain/ 内のルールファイル — ビジネスルールの唯一の正式な情報源
2. ルールスキーマ — reference/rule-schema.md（ルール構造に関するこのスキルの契約）
3. ユビキタス言語 — 存在する場合は UBIQUITOUS_LANGUAGE.md。エンティティ名の整合に使用します

このスキルはルールを作り出しません。ルールが docs/domain/ に記載されていない場合、このスキルにとってそのルールは存在しません。

入力モード

design-compliance と同じ3つの入力モードです。

URL モード

/business-compliance http://localhost:5173/hexagone-etab/vue/prescriptions/123

1. URL を使用して、ルーター設定内のルートを特定します
2. そのルートに対応するコンポーネントファイルを見つけます
3. コンポーネントツリーを再帰的に解決します

コンポーネント名モード

/business-compliance PrescriptionEditor

1. 一致するファイルを glob で検索します：**/PrescriptionEditor.vue、**/prescription-editor.vue
2. バウンデッドコンテキストを推定するために、該当する場合はルートを特定します
3. コンポーネントツリーを再帰的に解決します

ページ名モード

/business-compliance Prescriptions

1. ルーター設定でルート名またはパスが一致するものを検索します
2. 割り当てられたコンポーネントを見つけます
3. コンポーネントツリーを再帰的に解決します

引数なし

/business-compliance

監査する対象をユーザーに尋ねます。推測で決めないでください。

ワークフロー

ステップ 1：ルールスキーマの検証

ほかの作業を始める前に、docs/domain/ が必須のスキーマに準拠していることを検証します。

1. プロジェクト内で docs/domain/ を探します。存在しない場合は、次のメッセージを出して中止します。

   "docs/domain/ ディレクトリが見つかりません。business-compliance には、文書化されたドメインルールが必要です。必須の形式については reference/rule-schema.md を参照してください。"

2. docs/domain/ 内の各 .md ファイルを解析し、フロントマターを検証します。

   • 必須フィールド：bounded_context、entities、api_prefixes（空のリストでも可）、rule_id またはそれぞれに rule_id を含むルールのリスト、severity、layer
   • severity の許容値：P1、P2、P3、P4
   • layer の許容値：client、server、both

3. いずれかのファイルが検証に失敗した場合、監査を中止し、移行チェックリストを出力します。

   docs/domain/ schema violations — audit aborted
   
   | File | Missing fields | Action |
   |------|----------------|--------|
   | docs/domain/prescriptions.md | severity, layer | Add frontmatter fields |
   | ... | ... | ... |
   
   Fix the rule files before re-running. See skills/business-compliance/reference/rule-schema.md.
   

4. すべてのファイルが検証に合格した場合、正規化したルールインデックスをメモリ上に構築します。

   • (bounded_context, entity, rule_id) をキーにします
   • 各エントリに保持する情報：ルールのテキスト、severity、layer、api_prefixes、ソースファイルと行番号

ステップ 2：対象ファイルの特定

design-compliance と同じ特定方法を使用します。

1. ユーザーの入力を解析して、モード（URL、コンポーネント名、ページ名）を判別します
2. エントリーポイントのファイルを特定します。
   • URL → パスを解析し、一致するルートをルーターファイル（**/router/**/*.{js,ts}、**/router.{js,ts}）から検索して、コンポーネントを取得します
   • コンポーネント名 → **/<name>.vue、**/<name-kebab>.vue、**/<Name>/** を glob で検索します
   • ページ名 → ルート名またはパスが一致するものをルーター設定で検索します
3. コンポーネントツリーを再帰的に解決します。
   • 各 .vue ファイルを読み込みます
   • すべてのローカルインポートを抽出します（primevue/*、vue、vue-router、pinia、node_modules、@hexagone/shared は除外します）
   • 各インポートをたどり、新しいローカルコンポーネントがなくなるまで繰り返します
4. 見つかったツリーをユーザーに報告します

Step 3: 画面の成果物を抽出する

コンポーネントツリー内の各ファイルについて、ルールとの照合に必要な成果物を抽出します。

1. ルート情報：

   • ルートパス（例：/prescriptions/:id）
   • ルートから導出される API プレフィックス（例：/api/prescriptions）

2. Pinia ストア：

   • import { usePrescriptionStore } from '...'
   • ストア名は、境界づけられたコンテキストを特定する有力な手がかりです

3. API エンドポイント：

   • axios.*、fetch('...')、useFetch(...)、$api.* を検索します
   • 完全な URL と HTTP メソッドを記録します
   • エラー処理を記録します：catch (err) ブロック、4xx／5xx のハンドラー

4. TypeScript の型：

   • @/types/、@hexagone/shared/types、またはローカルの types.ts からインポートされる型
   • エンティティを表す型に注目します：Prescription、Admission、Patient、Order など

5. フォームのフィールドとバインディング：

   • v-model のバインディング
   • フォームのバリデーションルール（required、rules、schema、Zod／Yup／Valibot のスキーマ）
   • アクションボタンの :disabled、v-if、v-show（ステートマシンのシグナル）

6. アクションハンドラー：

   • ラベルが状態遷移（save、validate、discharge、sign、cancel）に一致するボタンのクリックハンドラー
   • API 経由でどのような状態変更がトリガーされるかを記録します

ファイルごとの抽出サマリーを出力します：

PrescriptionEditor.vue:
  route: /prescriptions/:id
  api_prefixes: [/api/prescriptions, /api/allergies]
  stores: [usePrescriptionStore, usePatientStore]
  types: [Prescription, AllergyCheck, Patient]
  actions: [save, validate, sign]

Step 4: ルールを画面に照合する

各ファイルから抽出した成果物について、該当するルールを照合します。

1. 境界づけられたコンテキストによるフィルター：画面内の各 api_prefix について、api_prefixes フロントマターが一致するルールを収集します
2. エンティティによるフィルター：抽出した TS 型名のいずれかを entities リストに含むルールに絞り込みます
3. ユビキタス言語の調整：UBIQUITOUS_LANGUAGE.md が存在する場合は、照合前にコード上の名前をドメイン上の名前に対応付けます（例：Rx → Prescription）

ファイルごとのルール候補リストを出力します：

PrescriptionEditor.vue: 7 applicable rules
  - PRESC-001 (P1) — Allergy check required before validation
  - PRESC-002 (P1) — Electronic signature required on save
  - PRESC-014 (P2) — Signature requires audit log entry
  - ADM-008 (P3) — Patient must have active admission
  - ...

Step 5: 静的解析 — 違反の検出

各（ファイル、該当ルール）のペアについて、次の 5 つの違反カテゴリを確認します。

カテゴリ 1：事前条件チェックの欠如

• ルールがアクションの前に満たすべき事前条件を定めている（X requires Y verified）
• 確認事項：UI はアクションをガードしていますか（:disabled、v-if、フォームバリデーション、または API の事前条件によって）？
• 必要な証拠：アクションのコード位置とガードがないこと
• 重大度はルールから引き継ぎます

カテゴリ 2：禁止された状態遷移の提示

• ルールが状態遷移を禁止している（Discharged cannot return to Active）
• 確認事項：禁止された状態遷移をトリガーできるボタン／アクションが UI に提示されていますか？
• 証拠：ボタンハンドラーと、禁止された状態変更を引き起こす API 呼び出し

カテゴリ 3：必須フィールドの欠落

• ルールがフィールドの収集または表示を必須としている（例：「臨床アクションには INS が必須」）
• 確認事項：フォームテンプレートにフィールドがあり、v-model でバインドされ、バリデーションで必須になっていますか？
• 証拠：テンプレートの検索結果とバリデーションスキーマの確認

カテゴリ 4：エンティティ間の不変条件が適用されていない

• ルールが複数のエンティティにまたがっている（例：「処方箋は有効な AllergyCheck を参照しなければならない」）
• 確認事項：画面は両方のエンティティを読み込む／参照し、エンティティ間の条件に基づいてアクションを制限していますか？
• 証拠：両方のストア／型が存在することと、エンティティ間の関係に基づく条件

カテゴリ 5：ワークフローの欠落

• ルールがワークフローのステップを定めている（例：「口頭指示には 24 時間以内の追認が必要」）
• 確認事項：リマインダーやフォローアップアクションであっても、そのステップが UI に表示されていますか？
• 証拠：ワークフローのステップに対応する UI 成果物の有無

サーバーサイドのルール処理

ルールの layer: server または layer: both の場合：

• UI がルールを完全に適用する必要はありません
• UI には、サーバーからの拒否を適切に処理することが求められます（409／422 を捕捉し、ユーザーに見えるエラーを表示する）
• 確認事項：API 呼び出し箇所に適切なエラーハンドラーが含まれていますか？
• サーバーで適用されるルールに対してエラーハンドラーがないこと自体が違反となります（カテゴリ 1 — 事前条件処理の欠如）

ステップ 6：不確実性への対応

ルールが適用されるか、違反されているかをスキルが確信を持って判断できない場合：

1. ルールを黙って無視しない
2. ステータス NEEDS_CLINICAL_REVIEW で指摘事項を出力する
3. レビュアーへの構造化された質問を含める：

   NEEDS_CLINICAL_REVIEW — PRESC-007
   Rule: Prescriptions require electronic signature.
   Screen: PrescriptionEditor.vue uses usePrescriptionStore.save() but signature step not clearly detected.
   
   Please confirm:
   (a) Rule applies, step missing → fix required
   (b) Rule applies, step present but undetected → add code annotation or test anchor
   (c) Rule does not apply → document why in commit message or rule exclusion
   

ステップ 7：評価不能なルールを記録する

分析後、候補リストに含まれていたものの評価できなかったルール（コードが複雑すぎる、動的ディスパッチ、外部ライブラリ呼び出しなど）をすべて列挙します。これにより、「違反が見つからなかった」ことと「監査されていない」ことを混同しないようにします。

Non-evaluable rules (5):
  - PRESC-022 — dynamic dispatch on action name, cannot trace
  - ADM-014 — relies on backend orchestration not visible in screen code
  - ...

ステップ 8：レポートを生成する

構造化レポートをターミナルに出力します。

## Business Compliance Report

**Target:** [component/page name or URL]
**Files analyzed:** [count]
**Rules indexed:** [count from docs/domain/]
**Rules applicable to target:** [count]
**Violations detected:** [count]
**Uncertain findings (NEEDS_CLINICAL_REVIEW):** [count]
**Non-evaluable rules:** [count]

### Rule Index Summary
| Bounded Context | Rules | Files |
|-----------------|-------|-------|
| prescriptions   | 14    | docs/domain/prescriptions.md |
| admissions      | 8     | docs/domain/admissions.md |
| ...             | ...   | ... |

### Files in Component Tree
| # | File | Applicable Rules | Violations |
|---|------|------------------|------------|
| 1 | `frontend/gap-mf/src/views/PrescriptionEditor.vue` | 7 | 2 |
| 2 | `frontend/gap-mf/src/components/AllergyBanner.vue` | 2 | 0 |
| ... | ... | ... | ... |

### Violations by Severity

#### P1 — Patient Safety ([count])
- **PRESC-001** — Allergy check required before validation
  - Rule source: `docs/domain/prescriptions.md:42`
  - Code location: `frontend/gap-mf/src/views/PrescriptionEditor.vue:118`
  - Category: Missing precondition check
  - Evidence: `validate()` handler calls `prescriptionStore.validate()` without prior check on `allergyCheckStore.verified`.
  - Suggested action (NOT applied): add `:disabled="!allergyChecked"` to the Validate button, or guard inside the handler.

#### P2 — Regulatory / Compliance ([count])
...

#### P3 — Clinical Workflow Integrity ([count])
...

#### P4 — Data Quality / Interoperability ([count])
...

### NEEDS_CLINICAL_REVIEW ([count])
- **PRESC-007** — [structured question as in Step 6]

### Non-Evaluable Rules ([count])
- **PRESC-022** — dynamic dispatch on action name, static trace impossible

### Drift Signals
- Rule files unchanged in > 6 months while referenced entities evolved: [list]
- Rules with no applicable screen in this audit: [list]

### Summary
- **Total violations:** [count] (P1: [n], P2: [n], P3: [n], P4: [n])
- **Waivable by developer alone:** [count] (P3 + P4)
- **Require clinical / compliance sign-off:** [count] (P1 + P2)
- **No files modified.** Review the report, discuss with domain experts, apply fixes manually.

違反のリファレンス

5 つの違反カテゴリ

#	カテゴリ	典型的なルールの表現	必要な証拠
1	前提条件チェックの欠落	「X には Y の確認が必要」	アクションハンドラー ＋ ガードの欠如
2	禁止された遷移が可能	「A から B への遷移は禁止」	アクションハンドラー ＋ 禁止された状態変更
3	必須フィールドの欠落	「フィールド F は必須」	テンプレート ＋ 検証スキーマ
4	エンティティ間の不変条件が未適用	「X は Y を参照する必要がある」	両方のエンティティの存在 ＋ 条件
5	ワークフローの抜け	「ステップ S は T 以内に実施する必要がある」	ステップ S の UI 要素

重大度の分類

重大度	意味	エスカレーション
P1	患者の安全 — 直接的な危害につながる経路（アレルギー、投与量、患者の取り違え、署名の回避）	マージをブロックします。臨床 PO の承認が必要です。
P2	規制／コンプライアンス — HDS、MDR、CNIL、監査ログ、トレーサビリティ	マージをブロックします。コンプライアンス担当者の承認が必要です。
P3	臨床ワークフローの整合性 — ステートマシン、孤立エンティティ、ワークフローの抜け	マージをブロックします。臨床 PO は書面による正当化を添えて免除できます。
P4	データ品質／相互運用性 — 任意フィールド、コードシステム、ラベル	警告します。ブロックはしません。開発者が免除できます。

P1 と P2 は、開発者だけでは免除できません。 このような免除が申請された場合、スキルは免除メタデータに、氏名を明記した臨床またはコンプライアンスのレビュアーを必須とする必要があります。

医療ルールの例（Hexagone のコンテキスト）

具体例については reference/rule-schema.md を参照してください。Hexagone における一般的なルールカテゴリ：

• 安全インターロック：アレルギー／禁忌／投与量の範囲／薬物間相互作用
• 本人確認：臨床行為の前に INS（Identité Nationale de Santé）を確認
• 処方の完全性：電子署名、変更監査証跡、口頭指示への追認署名
• ステートマシン：入院／退院フロー、オーダー／結果フロー、ケアパスウェイの手順
• 相互運用性：HL7/FHIR/PAM メッセージの完全性、セグメントの順序（Hexaflux ドメイン）
• 規制：書き込み時の監査ログ、緊急アクセスの正当化、データ保持
• 請求の連鎖：退院を妨げる行為コード、主病名を必須とする GHS

エッジケース

docs/domain/ が存在しない

監査を中止します。次の内容を出力します。

"docs/domain/ ディレクトリが見つかりません。このスキルでは、reference/rule-schema.md のスキーマに従ったドメインルールの文書化が必要です。実行前にディレクトリを作成し、ルールファイルを追加してください。"

docs/domain/ は存在するが、スキーマ検証に失敗する

監査を中止します。ファイルごとのスキーマ違反について、移行チェックリストを出力します（ステップ 1.3 を参照）。部分的なデータは誤った安心感につながるため、部分的な監査は試みないでください。

ルールが未知のエンティティを参照している

ルールの entities: リストに、コードベース内のどこにも見つからない名前が含まれている場合：

• ルールをインデックスに残す
• レポートのドリフトシグナルのセクションに、「ルール X はエンティティ Y を参照していますが、コードベース内で使用箇所が見つかりません」と記載する
• これは、ドキュメントが古いか、サーバー側のみのエンティティであることを示しています

画面に一致するルールがない

「適用可能なルール 0 件」と報告し、「準拠」と同じ意味ではないことを明示します。画面は、文書化されていない境界づけられたコンテキストで動作している可能性があります（それ自体が報告すべきドリフトシグナルです）。

競合するルール

インデックス内の2つのルールが同じrule_idを共有している場合、または同じエンティティについて矛盾する主張をしている場合：

• Drift Signals セクションで競合を報告します
• 解決を試みないでください。これはドメインの専門家が判断する事項です

開発サーバーが起動していない

このスキルは開発サーバーを必要としません。静的解析とドキュメント解析を行うスキルです。目視確認は対象外です。ビジネスルールはコードの動作に関するものであり、レンダリングに関するものではありません。

コンポーネントツリーが大規模（20 ファイル以上）

すべてのファイルを処理します。読みやすさを考慮して、ファイルごとにレポートを整理します。LLM の推論コンテキストを扱いやすく保つため、ツリーが10ファイルを超え、かつルールインデックスが30ルールを超える場合に限り、並列サブエージェントを使用します。

マイクロフロントエンドが混在

MF に関係なく、すべてのファイルに同じルールインデックスを適用します。レポートには、ファイルごとの MF への所属を記載します。

免除の申請

このスキルは免除を管理しません。指摘事項を免除する必要がある場合は、開発者が PR の説明またはこのスキルの対象外である専用の免除ログに記載します。このスキルは次回の実行時にも必ず同じ指摘事項を報告します。免除を記憶しておくのはスキルの役割ではありません（免除の記録は人間のプロセスに関するものです）。

重要な注意事項

• このスキルはファイルを変更しません。 レポートのみを出力します。ユーザーから「修正して」と言われた場合、ビジネスルール違反は機械的には修正できないことを説明してください。レポートには、人間が適用する必要のある推奨アクションが記載されています。
• すべての指摘事項には、rule_id + doc:line + code:line を記載します。 この3つがすべてそろっていない指摘事項はスキルのバグです。出力しないでください。
• P1 / P2 の違反には、臨床またはコンプライアンスのレビュアーによる氏名付き承認が必要です。 スキルはレポート内でこれを明示します。
• 特異度より感度を優先してください。 可能性のある指摘事項を10件挙げてチームがそのうち9件を却下するほうが、P1 を1件見落とすより適切です。
• 確信が持てない指摘事項は NEEDS_CLINICAL_REVIEW とします。 ルールを黙って除外してはいけません。
• ドリフトシグナルは最優先事項です。 エンティティが変更されているのにルールが更新されていない場合は、レポートに提示します。未知のエンティティを参照するルールも提示します。
• 評価不能なルールは最優先事項です。 「違反が見つからなかった」と「監査されていない」を混同してはいけません。評価不能なルールは必ずすべて列挙します。
• 自動修正は絶対に行いません。v2 でも自動修正は行いません。 求められた場合は、医療分野の意味的な変更には人間の判断が必要だと説明して断ってください。
• まずパイロットを実施してください。 新たに導入する場合は、対象を1つの限定されたコンテキストに絞って開始します（例：最も重要度が高く、不変条件が最も明確な処方）。対象領域を拡大する前に、そのパイロットでシグナル対ノイズ比を検証してください。