phasegate 0.15.0

package/skills/consistency-checker/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: consistency-checker
+description: AIDLC設計文書群のレイヤー間整合性チェック・矛盾/漏れ検出
+model: sonnet
+review: opus
+---
+
+# Consistency Checker
+
+AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾・漏れ・不整合を検出するスキル。
+
+## 前提条件チェック
+
+### 必須インプット
+- **チェック対象の設計文書群** — 存在するレイヤーのみチェック。存在しないレイヤーはスキップ
+
+---
+
+## ⚠️ 3フェーズ実行ルール
+
+**このスキルは3フェーズで実行する。**
+- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
+- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`scripts/delegate-sonnet.sh` 経由）
+- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
+
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+
+---
+
+## Phase 1: チェック計画（plan）
+
+### 目的
+チェック対象・範囲を確認し、人間の承認を得る。
+
+### 出力
+会話内で以下を報告する：
+
+```markdown
+# 整合性チェック計画
+
+## 1. チェック対象ファイル一覧
+| # | レイヤー | ファイルパス | 存在 |
+|---|---------|-----------|------|
+
+## 2. 実行するチェック項目
+（存在するレイヤーのみ対象）
+- [ ] ストーリー↔Unit
+- [ ] Unit↔Domain
+- [ ] ...
+
+## 3. スキップするチェック項目
+（文書が存在しないため）
+- ...
+
+## 4. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+```
+
+### Phase 1 完了条件
+- チェック計画を報告した
+- 不明点がある場合は`[Question]`セクションに記載した
+- **人間にボールを渡した**
+- **チェック結果はまだ報告していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1のチェック計画を承認した
+
+### チェック項目
+
+以下を上位→下位の順で検証する。各チェックの具体的な検証手法は [references/チェックリスト.md](references/チェックリスト.md) を参照。
+
+1. **ストーリー↔Unit** — 全ストーリーがいずれかのUnitに所属しているか
+2. **Unit↔Domain** — 全Unitの業務概念がドメインモデルに定義されているか
+3. **Domain↔論理設計** — 全集約/リポジトリに対応するコンポーネントがあるか
+4. **論理設計↔環境設計** — 全サービス/DB変更が環境設計に列挙されているか
+5. **環境設計↔実装** — 環境設計の制約が実装に反映されているか
+6. **マイグレーション台帳↔実ファイル** — 台帳のエントリと実ファイルが一致しているか
+7. **制約集↔実装** — フレームワーク制約集のルールがコードで遵守されているか
+
+### Phase 2 最低出力基準（Sonnet委任時の品質制約）
+
+以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
+
+| 基準 | 最低要件 |
+|------|---------|
+| チェック項目網羅 | Phase 1で計画した全チェック項目が実行されていること |
+| 具体的な不整合記述 | 検出された不整合に具体的なファイル名・行・内容が記載されていること |
+| 重要度判定 | 各不整合に重要度（高/中/低）が付与されていること |
+| 推奨アクション | 各不整合に対する具体的な修正アクションが提案されていること |
+| スキップ理由 | スキップしたチェック項目にスキップ理由が記載されていること |
+
+### 出力フォーマット
+
+```markdown
+# 整合性チェック結果
+
+## 検出された不整合
+
+| # | レイヤー間 | 不整合内容 | 重要度 | 推奨アクション |
+|---|----------|----------|--------|-------------|
+
+## チェック対象外（スキップ）
+- ...
+
+## サマリー
+- チェック対象レイヤー数: N
+- 不整合件数: N
+```
+
+---
+
+---
+
+## Phase 3: レビュー（Opus review）
+
+### 実行主体
+メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+
+### レビュー手順
+1. Sonnetが出力したファイルを読み込む
+2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+3. **スキル固有レビュー観点**を検証する
+4. 判定結果を出力する
+
+### スキル固有レビュー観点（BLOCK基準）
+- [ ] Phase 1で計画した全チェック項目が実行されているか
+- [ ] 不整合の記述が具体的か（曖昧な「不一致あり」だけでないか）
+- [ ] 重要度の判定基準が一貫しているか
+- [ ] 推奨アクションが実行可能か（対応スキル名が明記されているか）
+- [ ] 偽陰性がないか（明らかな不整合を見逃していないか）
+
+### engineering-perspective レビュー観点（WARN基準）
+- [ ] ドメインスメル（責務混在・言語の乖離・境界不明確）がレイヤー横断で検出されているか
+- [ ] SOLID違反（SRP・DIP）が設計レイヤー間で見逃されていないか
+- [ ] コードスメル（Shotgun Surgery等）の兆候が設計変更の波及パターンから検出されているか
+
+### 判定と修正
+- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
+- **WARNのみFAIL** → Opusが直接修正してから完了とする
+- **全PASS** → 完了
+
+## 注意事項
+
+- 不整合の修正は行わず、検出と推奨アクションの提示に徹する
+- 技術スタック固有の用語は使わず、汎用的な表現でチェックする

package/skills/consistency-checker/references//343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -0,0 +1,60 @@
+# 整合性チェック 検証手法ガイド
+
+各チェック項目の汎用的な検証手法。技術スタックに依存しない。
+
+## 1. ストーリー ↔ Unit
+
+**手法:** ストーリーIDの全数マッチング
+
+1. ストーリー一覧からストーリーIDを全て抽出する
+2. 各Unit定義ファイルからストーリーID参照を全て抽出する
+3. ストーリー一覧にあるがUnit定義に無いID = 孤立ストーリー
+
+## 2. Unit ↔ Domain
+
+**手法:** 業務概念のクロスリファレンス
+
+1. 各Unit定義から主要な業務名詞（エンティティ候補）を抽出する
+2. ドメインモデルの集約・エンティティ・値オブジェクト名と照合する
+3. Unit定義に登場するがドメインモデルに未定義の業務名詞 = 漏れ
+
+## 3. Domain ↔ 論理設計
+
+**手法:** 集約→コンポーネント対応表の照合
+
+1. ドメインモデルから集約名・リポジトリインターフェース名を抽出する
+2. 論理設計からコンポーネント名（コントローラ、ユースケース、リポジトリ実装等）を抽出する
+3. ドメインモデルの集約に対応するコンポーネントが論理設計に無い = 漏れ
+
+## 4. 論理設計 ↔ 環境設計
+
+**手法:** インフラ要件の突合
+
+1. 論理設計から以下を抽出する:
+   - 新規サービス/関数の定義
+   - 新規テーブル/ビュー/マイグレーションの定義
+   - 外部連携・認証に関する記述
+2. 環境設計の各セクションと突合する:
+   - サービス構成マニフェストに全サービスが列挙されているか
+   - マイグレーション台帳に全DB変更が記載されているか
+
+## 5. 環境設計 ↔ 実装
+
+**手法:** 設定ファイルとコードの機械的照合
+
+1. 環境設計のマイグレーション台帳からファイル名を抽出 → 実ファイルの存在確認
+2. 環境設計のサービス構成から設定項目を抽出 → 設定ファイルとの照合
+3. 環境設計のフレームワーク制約集からルールを抽出 → コード内のパターン検索
+
+## 汎用検索パターン例
+
+```
+# ストーリーID抽出（マークダウンテーブルから）
+grep -oE 'US-[0-9]+|US-DEV-[0-9]+' docs/product/user_stories.md
+
+# Unit内のストーリー参照抽出
+grep -oE 'US-[0-9]+|US-DEV-[0-9]+' docs/product/units/*.md
+
+# ドメインモデルの集約名抽出
+grep -E '^### .+集約|Aggregate' docs/product/construction/*/domain_model.md
+```

package/skills/doc-freshness-checker/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: doc-freshness-checker
+description: 設計文書の鮮度チェック（L4バリデータ拡張）。`p2:check-freshness` CLIを使い、設計文書の最終更新日が閾値を超えていないか、コード変更と設計文書の乖離がないかを検出する。使用タイミング: 「設計文書が古くなっていないか確認して」「ドキュメントの鮮度チェックを実行して」「L4 freshness チェック」「設計とコードの乖離を調べて」など。
+model: sonnet
+review: opus
+---
+
+# Doc Freshness Checker
+
+設計文書の鮮度（freshness）を検証し、古くなった文書や対応コードとの乖離を検出するスキル。
+`phase2-extensions` Unit の `p2:check-freshness` CLIをラップし、結果を解釈・対処する。
+
+## 前提条件
+
+- `phasegate.config.json` に `docFreshnessThresholds` が設定されていること（未設定時はデフォルト値使用）
+- git リポジトリ内で実行すること（最終更新日は `git log` で判定）
+
+---
+
+## ⚠️ 2フェーズ実行ルール
+
+- **Phase 1（計画）**: チェック対象スコープを確認し、人間の承認を得る
+- **Phase 2（実行）**: CLIを実行し、結果を解釈してアクションを提案する
+
+**Phase 1/2を同時に実行してはならない。**
+
+---
+
+## Phase 1: チェック計画（plan）
+
+### 出力（会話内のみ）
+
+```markdown
+# Doc Freshness チェック計画
+
+## チェック対象スコープ
+- ディレクトリ: {デフォルト: docs/product/construction/}
+- 閾値: {phasegate.config.json の値 or デフォルト 30日}
+
+## 実行コマンド
+pnpm run p2:check-freshness [--dir {path}] [--threshold {days}]
+
+## QA
+[Question] Q1: ...
+[Answer]
+```
+
+### Phase 1 完了条件
+- スコープを報告した
+- 人間にボールを渡した
+- **CLIはまだ実行していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### Step 1: CLIの実行
+
+```bash
+pnpm run p2:check-freshness
+```
+
+オプション:
+- `--dir <path>` — チェック対象ディレクトリ（デフォルト: `docs/product/construction/`）
+- `--threshold <days>` — 警告閾値（日数）
+
+### Step 2: 結果の解釈
+
+`CheckDocFreshnessOutput` の構造:
+
+| フィールド | 意味 |
+|-----------|------|
+| `results[].status` | `ok` / `warn` / `error` |
+| `results[].documentPath` | チェック対象ファイルパス |
+| `results[].daysSinceUpdate` | 最終更新からの日数 |
+| `results[].threshold` | 設定閾値 |
+| `summary.error` | エラー件数（即対応必要） |
+| `summary.warn` | 警告件数（確認推奨） |
+
+### Step 3: アクションの提案
+
+| 状態 | 推奨アクション |
+|------|--------------|
+| `error`（閾値超過） | cascade-updater で上位設計文書を更新 |
+| `warn`（閾値近接） | 設計文書の内容確認・必要に応じて更新 |
+| `ok` | 対応不要 |
+
+### 出力フォーマット
+
+```markdown
+# Doc Freshness チェック結果
+
+## サマリー
+- 総ドキュメント数: N
+- ok: N / warn: N / error: N
+
+## 要対応（error）
+| ファイル | 最終更新 | 閾値超過日数 | 推奨アクション |
+|---------|---------|------------|--------------|
+
+## 要確認（warn）
+| ファイル | 最終更新 | 残り日数 |
+|---------|---------|---------|
+
+## 次のアクション
+（errorがある場合は `cascade-updater` の実行を提案）
+```
+
+---
+
+## phasegate.config.json 設定例
+
+```json
+{
+  "docFreshnessThresholds": {
+    "domain_model.md": 90,
+    "logical_design.md": 60,
+    "unit_test_design.md": 30,
+    "default": 30
+  }
+}
+```
+
+---
+
+## 関連スキル
+
+| スキル | 用途 |
+|-------|------|
+| `cascade-updater` | errorが検出された設計文書の更新 |
+| `consistency-checker` | 文書間整合性の検証（freshness修正後の確認） |

package/skills/domain-designer/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: domain-designer
+description: DDD戦術パターンでドメインモデル（集約・エンティティ・VO・イベント）を設計（AIDLC Step 2.1）
+model: opus
+---
+
+# Domain Designer
+
+DDD戦術パターンを用いてドメインモデルを設計するスキル。AIDLCプロセスのStep 2.1に対応。
+
+## 前提条件チェック
+
+### 必須インプット（存在しなければ`[Question]`で提供を要求）
+- **Unit定義** — 対象Unitの担当ストーリー・機能要件
+- **統合契約** — Unit間のAPI仕様
+
+### 任意インプット（あれば参照）
+- **既存ドメインモデル** — 既にある場合はフォーマットに準拠する
+- **プロダクト概要** — ユビキタス言語やコアドメインの理解
+- **Shared Kernel** — 複数Unitが共有するドメインモデル
+
+---
+
+## ⚠️ 上位レイヤー存在チェック
+
+**このスキルは AIDLC Step 4「Domainの設計」に対応します。実行前に上位設計の存在を確認してください。**
+
+### 依存する上位設計文書
+
+| ファイル | 必須 | チェック方法 |
+|---------|------|------------|
+| `docs/product/units/{対象unit}.md` | ✅ 必須 | 対象Unitのファイル存在を確認 |
+| `docs/product/units/integration_contract.md` | ✅ 必須 | ファイルの存在を確認 |
+
+### 上位設計が存在しない場合のアクション
+
+上位設計文書が存在しない場合、**設計を開始せず**、以下を行う：
+
+1. **状況報告** — ユーザーに不足している設計文書を明示
+2. **選択肢提示** — 以下の選択肢を提示
+   - 上位設計（unit-designer）を先に実行する
+   - 上位設計をスキップして進める（非推奨）
+3. **ユーザー指示待ち** — 独自判断で設計を開始しない
+
+**報告テンプレート:**
+```markdown
+## ⚠️ 上位レイヤー設計が見つかりません
+
+以下の設計文書が存在しないため、ドメイン設計を開始できません：
+- `docs/product/units/{unit}.md` ❌ 未作成
+- `docs/product/units/integration_contract.md` ❌ 未作成
+
+### 推奨アクション
+`unit-designer` スキルを使用してUnit設計を作成してください。
+
+### 選択肢
+1. **unit-designerを先に実行する**（推奨）
+2. **このまま進める**（上位設計なしで進める場合、整合性リスクあり）
+
+どちらを選択しますか？
+```
+
+---
+
+## ⚠️ 2フェーズ実行ルール
+
+**このスキルは必ず2フェーズに分けて実行する。Phase 1で計画を作成し、人間の承認を得てからPhase 2で成果物を作成する。Phase 1とPhase 2を同時に実行してはならない。**
+
+---
+
+## Phase 1: 計画（plan）
+
+### 目的
+ドメインモデリングの方針・集約の特定方針・不明点を整理し、人間の承認を得る。
+
+### 出力ファイル
+`docs/inception/{unit}/domain_model_plan.md`
+
+### 計画ファイルの構成
+
+```markdown
+# ドメインモデル設計計画: {Unit名}
+
+## 1. スコープ
+- 対象Unitと担当ストーリー
+- 他Unitとの境界
+
+## 2. 集約候補の分析
+- ストーリーから抽出した業務名詞一覧
+- 集約候補とその根拠
+
+## 3. 設計方針
+- 集約の粒度方針
+- 値オブジェクト vs エンティティの判断基準
+- Shared Kernelとの関係
+
+## 4. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+
+## 5. 前提条件・リスク
+- ...
+```
+
+### Phase 1 完了条件
+- 計画ファイルを出力した
+- 不明点がある場合は`[Question]`セクションに記載した
+- **人間にボールを渡した**
+- **成果物（ドメインモデル本体）はまだ作成していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1の計画を承認した
+- QAセクションの全[Question]に[Answer]が記入されている（QAがある場合）
+
+### ワークフロー
+
+1. **集約の特定** — ライフサイクルが一致する業務名詞を集約にまとめ、集約ルートを決定
+2. **エンティティ・値オブジェクトの設計** — 各集約内部の構造、メソッド、設計ルールに沿った配置
+3. **不変条件の定義** — 各集約のビジネスルール制約を列挙
+4. **状態遷移の定義** — 状態遷移表の作成
+5. **ドメインイベントの定義** — 集約が発行するイベントを列挙
+6. **クラス図の作成** — Mermaid形式で関係を図示
+7. **品質評価（engineering-perspective）** — 設計完了後、以下の観点で自己評価し、問題があれば修正してから成果物を確定する
+   - **ドメインスメル**: 責務混在・不適切なVO・言語の乖離・境界不明確がないか
+   - **SOLID**: 集約がSRPに従っているか、集約間の依存方向が正しいか
+   - **シンプルさ**: 過度に複雑なモデルになっていないか、各集約を簡潔に説明できるか
+
+### 出力ファイル
+
+| 種別 | 配置先 |
+|------|--------|
+| 成果物 | `docs/product/construction/{unit}/domain_model.md` |
+
+---
+
+## 注意事項
+
+- **ファイル配置は `docs/folder_management_rules.md` に従うこと**
+- **コードスニペットは生成しない**（設計文書のみ）
+- ユビキタス言語がある場合、命名はそれに準拠する
+- 既存のShared Kernelがある場合は、共有モデルとの整合性を保つ
+- ビジネスロジックは集約・エンティティ・値オブジェクトに配置する（ユースケースは調整役に徹する）
+- 集約間の参照はIDのみ（直接参照禁止）

package/skills/engineering-perspective/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: engineering-perspective
+description: |
+  ケント・ベック + マーティン・ファウラー + アンクル・ボブ + エリック・エヴァンスの視点を統合したエンジニアリング思考フレームワーク。
+  以下の場面で使用:
+  (1) 設計・コードレビュー時に品質を多角的に評価したい
+  (2) 要件や仕様を整理・明確化したい
+  (3) コードスメル・SOLID違反・ドメインスメルを検知したい
+  (4) TDD/リファクタリング/DDDのベストプラクティスを適用したい
+  (5) チーム議論で共通認識を構築したい
+  トリガー例: 「レビューして」「これどう思う？」「設計見て」「SOLID的にどう？」「リファクタ必要？」「ドメイン的に正しい？」
+---
+
+# Engineering Perspective
+
+4人の巨匠の視点を統合し、実用性・シンプルさ・説明責任の観点でレビュー・設計・議論を行う。
+
+## 視点一覧
+
+| 視点 | 専門 | キーワード |
+|------|------|------------|
+| **統合視点** | 統合・実用性 | 前提確認, シンプルさ, 説明責任 |
+| **ケント・ベック** | XP・TDD | Red-Green-Refactor, YAGNI, 小さなステップ |
+| **マーティン・ファウラー** | リファクタリング | コードスメル, Extract Method, 読みやすさ |
+| **アンクル・ボブ** | Clean Code | SOLID, 依存性逆転, プロフェッショナリズム |
+| **エリック・エヴァンス** | DDD | ユビキタス言語, 境界づけられたコンテキスト, 集約 |
+
+## 統合思考フロー
+
+```
+問題 → 前提確認(統合視点) → 並行評価(4視点) → 統合判断(統合視点) → ガイダンス
+```
+
+### 1. 前提確認（統合視点）
+
+まず確認:
+- **コンテキスト**: どの文脈での話か
+- **境界**: どこまでが対象範囲か
+- **目的**: 何を達成したいのか
+
+### 2. 並行評価（4視点）
+
+| 視点 | 評価観点 |
+|------|----------|
+| ケント・ベック | テストある？ YAGNI守ってる？ |
+| ファウラー | コードスメルない？ リファクタ必要？ |
+| アンクル・ボブ | SOLID守ってる？ 依存の方向正しい？ |
+| エヴァンス | ドメイン表現してる？ 言語一致してる？ |
+
+### 3. 統合判断（統合視点）
+
+各視点の結果を統合し、実用性を考慮してシンプルな改善案を選択。
+
+## スメル検知
+
+### コードスメル（ファウラー視点）
+
+| スメル | 兆候 | 対処 |
+|--------|------|------|
+| Long Method | メソッドが長い | Extract Method |
+| Feature Envy | 他クラスのデータ多用 | Move Method |
+| Primitive Obsession | 基本型の過剰使用 | Value Objectに置換 |
+| Shotgun Surgery | 変更が多クラスに波及 | Move Method/Field |
+
+### SOLID違反（アンクル・ボブ視点）
+
+| 原則 | 違反の兆候 | 対処 |
+|------|------------|------|
+| SRP | 変更理由が複数 | クラス分割 |
+| OCP | 変更時に既存コード修正 | 抽象化 |
+| LSP | 派生型で例外発生 | 継承の見直し |
+| ISP | 使わないメソッドに依存 | IF分割 |
+| DIP | 具象に依存 | 抽象に依存 |
+
+### ドメインスメル（エヴァンス + 統合視点）
+
+| スメル | 兆候 | 対処 |
+|--------|------|------|
+| 責務混在 | 集約に複数責務 | 概念を分離 |
+| 不適切なVO | nullable値オブジェクト | ドメイン的に分解 |
+| 言語の乖離 | コードと用語が不一致 | 命名統一 |
+| 境界不明確 | コンテキストが混在 | 境界を明確化 |
+
+## 評価基準
+
+### Good判定（すべて満たす）
+
+- [ ] シンプル・説明可能・実用的（統合視点）
+- [ ] テストがある・YAGNIに従う（ケント・ベック）
+- [ ] コードスメルがない（ファウラー）
+- [ ] SOLID原則に従う・依存が内向き（アンクル・ボブ）
+- [ ] ドメインを適切に表現・言語が一致（エヴァンス）
+
+### NG判定（いずれかに該当）
+
+- [ ] 複雑・目的不明・説明不能
+- [ ] テストなし・過剰設計
+- [ ] 重大なコードスメル
+- [ ] SOLID違反・依存が外向き
+- [ ] モデル不一致・言語の乖離
+
+## 表現パターン
+
+### 質問
+
+| 視点 | パターン | 場面 |
+|------|----------|------|
+| 統合視点 | 「前提は？」 | 議論開始時 |
+| 統合視点 | 「具体例にすると？」 | 抽象的な話 |
+| ケント・ベック | 「テストは書いた？」 | 実装レビュー |
+| ファウラー | 「これ匂う？」 | コードレビュー |
+| アンクル・ボブ | 「依存の方向は？」 | 設計レビュー |
+| エヴァンス | 「ドメインエキスパートはこう呼ぶ？」 | 命名議論 |
+
+### 指摘
+
+| 視点 | パターン | 場面 |
+|------|----------|------|
+| 統合視点 | 「それって違くない？」 | スメル検知 |
+| ケント・ベック | 「今必要ないなら作らない」 | 過剰設計 |
+| ファウラー | 「リファクタしてから機能追加」 | 変更前 |
+| アンクル・ボブ | 「責務が複数ある」 | SRP違反 |
+| エヴァンス | 「コンテキストが混ざってる」 | 境界不明確 |
+
+### 開発アプローチ
+
+- 「バーティカルスライスでまず価値提供」（統合視点）
+- 「Make it work, make it right, make it fast」（ケント・ベック）
+- 「2回目で抽象化を検討」（ファウラー）
+- 「ボーイスカウトルール: 来た時より美しく」（アンクル・ボブ）
+- 「モデルとコードを一致させる」（エヴァンス）
+
+## 参照ドキュメント
+
+- **統合モデル**: [references/domain-model.md](references/domain-model.md) - 完全なドメインモデル図
+- **用語集**: [references/glossary.md](references/glossary.md) - 各視点のユビキタス言語