القائمة
技術選定や競合分析を行う際に自律的にギャップ分析を行うメタスキルです。 複数の軸で類似概念を調査し、現行システムとのギャップを洗い出し、 なぜそのギャップが生じているのかを自問して戦略を立案します。 Trigger: 技術選定, 競合分析, 改善提案, ギャップ分析
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/HikaruEgashira/agent-skills --skill gap-analysisيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
codex CLI をツール実行エンジンとして使い、codex 側にのみ接続済みの能力 (Apps Connectors, MCP servers, computer use, web search) を `codex exec` 経由で 外部エージェント (Claude Code / opencode 等) から利用する。 Trigger: codex as tool, Google Drive アクセス, Apps Connector 利用, codex exec, ツール借用
agentops のオフライン記憶整理 (consolidation) 機能。会話 transcript は読まず、 既存の memory entry を「精緻化のみ」する。新しい記憶が獲得されたセッションでだけ Stop hook から自動発火する (fingerprint trigger gate)。手動実行は /dream。 Trigger: dreaming, memory consolidation, 記憶整理, refine memory, dream, memory dedup, /dream
AI 生成(vibecoding)成果物に潜む「それっぽい虚偽」を、固定された検査カタログ(検査ID・手順・ 合格基準つき)で系統的に検出する監査規格。主張面を列挙し、各主張面に対応する検査を 機械的に適用し、カバレッジマトリクスに全セルの実施状態を記録する。 内部整合(テスト全パス・schema valid・CI green)は証拠として認めない。 Trigger: 虚偽検出, ハリボテ検出, vibecoding 監査, 本物か確認, それっぽい嘘, fabrication audit, AI生成コード 検証, 捏造チェック.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | gap-analysis |
| description | 技術選定や競合分析を行う際に自律的にギャップ分析を行うメタスキルです。 複数の軸で類似概念を調査し、現行システムとのギャップを洗い出し、 なぜそのギャップが生じているのかを自問して戦略を立案します。 Trigger: 技術選定, 競合分析, 改善提案, ギャップ分析 |
| user-invocable | false |
表面的な比較ではなく、ギャップの根本原因を理解し、付け焼き刃ではない本質的な改善戦略を立案する。
単一の軸ではなく、複数の観点から対象を捉える。
状況: 認証基盤のギャップ分析 分析軸を網羅的に洗い出す： - 機能軸: 認証方式、MFA対応、SSO連携 - 品質軸: 可用性、レイテンシ、スケーラビリティ - 運用軸: 監視、ログ、障害対応 - セキュリティ軸: 暗号化、監査、コンプライアンス - コスト軸: 初期費用、運用費用、スケール時コスト ## 分析軸| 軸 | 観点 | 重要度 |
|---|---|---|
| 機能 | 何ができるか | 高 |
| 品質 | どれだけ信頼できるか | 高 |
| 運用 | どれだけ管理しやすいか | 中 |
| セキュリティ | どれだけ安全か | 高 |
| コスト | どれだけ費用対効果があるか | 中 |
各軸において、業界標準や先行事例を調査する。
状況: 現行のEC2ベース認証基盤とマネージドサービスの比較 この機能に関連する類似概念は何か： - Amazon Cognito: AWSマネージド認証 - Auth0: SaaS型認証プラットフォーム - Keycloak: OSS認証サーバー - Firebase Auth: Googleマネージド認証それぞれがどのようにこの問題を解決しているか調査する。
| 概念 | アプローチ | 強み | 弱み |
|---|---|---|---|
| Cognito | AWSマネージド | AWS統合、スケーラビリティ | カスタマイズ制限 |
| Auth0 | SaaS | 機能豊富、SDK充実 | コスト高、ベンダーロック |
| Keycloak | OSS自前運用 | 柔軟性、コスト | 運用負荷 |
| Firebase Auth | Googleマネージド | 導入容易 | AWS連携が弱い |
業界標準: OAuth 2.0 / OIDC、SAML 2.0 先行事例: Netflix（自前基盤）、Spotify（Auth0採用）
現行システムと類似概念との差分を特定する。
状況: 現行EC2認証基盤とCognitoのギャップ ## ギャップマトリクス| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| カスタム認証フロー | ◎ 完全自由 | △ 制限あり | +柔軟性 |
| 既存DB統合 | ◎ 直接接続 | △ Lambda必要 | +シンプル |
| 監査ログ形式 | ◎ 自社標準 | △ CloudTrail形式 | +統一性 |
| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| 可用性 | △ 99.9% | ◎ 99.99% | -0.09% |
| MFA対応 | △ TOTP のみ | ◎ 多方式 | -3方式 |
| スケーラビリティ | △ 手動 | ◎ 自動 | -自動化 |
なぜそのギャップが生じているのかを掘り下げる。
状況: MFA対応のギャップがある 問題: MFA方式がTOTPのみ ↓ なぜ？ 他の方式を実装していないから ↓ なぜ？ 開発リソースを他に優先したから ↓ なぜ？ ビジネス要件としてTOTPで十分だったから ↓ 根本原因 **要件定義時のスコープ決定**: 当時のユーザー規模ではTOTPで十分と判断したこれはギャップではなく、当時の合理的判断の結果である。
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜTOTPのみ？ | 他を実装していないから |
| 中層 | なぜ実装していない？ | リソースを他に優先したから |
| 深層 | なぜ優先しなかった？ | 当時の要件で十分だったから |
| 根本 | スコープ決定 | 当時の規模に最適化した設計 |
結論: 規模拡大に伴い「埋めるべきギャップ」に変化
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜ99.9%止まり？ | 単一AZ構成だから |
| 中層 | なぜ単一AZ？ | コスト最適化のため |
| 深層 | なぜコスト優先？ | スタートアップ期の制約 |
| 根本 | リソース制約 | 成長段階に応じた投資判断 |
結論: 事業成長に伴いマルチAZ化を検討すべき
根本原因に基づき、付け焼き刃ではない戦略を策定する。
状況: ギャップ分析結果から戦略を立案 ギャップの分類: 1. 意図的トレードオフ → 受容、ただし再評価 2. 成長による陳腐化 → 対応検討 3. リソース制約 → 優先順位付け戦略の選択肢:
現行の強みを維持しながら、マネージドサービスの利点を取り込む。
| ギャップ | 根本原因 | 戦略 | 対応 |
|---|---|---|---|
| MFA方式 | スコープ決定 | 転嫁 | Cognito MFAを部分導入 |
| 可用性 | リソース制約 | 軽減 | マルチAZ化を実施 |
| カスタム認証 | 意図的設計 | 受容 | 現行維持、強みとして活用 |
優先度: 高
優先度: 中
優先度: 低
なぜこの戦略か？
# [対象] ギャップ分析
## 1. 分析軸
| 軸 | 観点 | 重要度 |
|----|------|--------|
| | | |
## 2. 類似概念調査
| 概念 | アプローチ | 強み | 弱み |
|------|-----------|------|------|
| | | | |
## 3. ギャップマトリクス
### 優れている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
### 劣っている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
## 4. 根本原因分析
### ギャップ: [名前]
| 層 | 問い | 回答 |
|----|------|------|
| 表層 | | |
| 中層 | | |
| 深層 | | |
| 根本 | | |
**結論**: [埋めるべき/受け入れる]
## 5. 戦略立案
### 方針: [一言で]
### ギャップ別対応
| ギャップ | 根本原因 | 戦略 | 対応 |
|----------|---------|------|------|
| | | 回避/軽減/転嫁/受容 | |
### アクション
- 優先度 高:
- 優先度 中:
- 優先度 低:
### 戦略の根拠
**なぜこの戦略か？**
-
ギャップを特定したら、以下を必ず自問する：
| 振る舞い | 問題 | 代わりに |
|---|---|---|
| 全ギャップを埋めようとする | 差別化喪失、リソース浪費 | 優先順位を付ける |
| 表面的な機能追加 | 根本解決にならない | なぜなぜ分析で原因特定 |
| 競合の模倣 | 二番煎じ | 独自の強みを伸ばす |
| ギャップを隠す | 信頼喪失 | 透明に説明し代替案提示 |
ギャップ分析に基づく重要な意思決定は ./docs/adr に記録する。
# ADR-XXXX: [ギャップ]への対応方針
## ステータス
採用
## コンテキスト
ギャップ分析により、[対象]において[ギャップ]が特定された。
## 根本原因
[なぜなぜ分析の結果]
## 決定
[戦略: 回避/軽減/転嫁/受容]を選択する。
## 理由
- [根本原因に基づく理由]
- [トレードオフの考慮]
## 結果
- 期待される効果:
- 受け入れるリスク: