القائمة
こんなときに使う: 繰り返し発生する業務問い合わせ（監査、アンケート、コンプライアンス調査）に対して、 過去の回答実績とエビデンスを活用して回答するためのテンプレートスキル。 再利用可能な7ステップワークフローとスキャフォールディングファイルを提供する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
モダン C#（12+）で record、パターンマッチング、合成、Result 型エラーハンドリングを使った 慣用的で高性能なコードを書く。こんなときに使う: 新規 C# コードの作成、API 設計、 または C# 12+ イディオムへのリファクタリング。
こんなときに使う: WPFアプリケーションに社員番号入力ダイアログを追加し、 DPAPIで暗号化された設定として社員IDを安全に保存したいとき。
こんなときに使う: PDFテキスト抽出、Optical Character Recognition (OCR)、結合/分割、フォーム処理をuvベースの再現可能コマンドで実行したいときに使う。
こんなときに使う: Migrate Access SQL to Oracle, generate .NET C# code. Use when converting Access queries to Oracle.
こんなときに使う: .NETドメイン層で汎用的な重み付きフィールドマッチングとスコアリングを実装。
こんなときに使う: dotnet-tools.json によるローカル .NET ツールの管理。開発環境と CI/CD パイプライン全体で バージョン固定された一貫したツール環境を構築。リポジトリ単位の CLI ツール管理時に使用。
| name | evidence-response |
| description | こんなときに使う: 繰り返し発生する業務問い合わせ（監査、アンケート、コンプライアンス調査）に対して、 過去の回答実績とエビデンスを活用して回答するためのテンプレートスキル。 再利用可能な7ステップワークフローとスキャフォールディングファイルを提供する。 |
| metadata | {"author":"RyoMurakami1983","tags":["business","evidence","questionnaire","audit","compliance","template","knowledge-management"],"invocable":true,"version":"1.0.0","last_reviewed":"2026-03-09","freshness_check_interval_days":365,"language":["en","ja"],"model_recommendation":"Claude（GitHub Copilot経由） — 長文コンテキストの知識検索と構造化推論に最適化"} |
| values_alignment | ["基礎と型の追求: 7ステップワークフローが型。一度習得すれば、どの業務領域でも応用可能","余白の設計: テンプレートは構造を提供し、ドメイン知識は意図的に空白。使う人が埋める","温故知新: 過去の回答実績を使って新しい質問に対応する。このスキルの核心","成長の複利: 回答するたびにナレッジベースが充実し、複利的に価値が増大する","継続は力: 鮮度管理プロトコルにより、放置されず毎年メンテナンスされる仕組み"] |
| trigger | ["繰り返し発生する外部アンケートや調査を受領した","監査準備でエビデンスに基づく回答が必要になった","顧客・規制当局・認証機関からのコンプライアンス問い合わせを受けた","新しい業務領域でエビデンスベース回答システムを構築する必要がある"] |
業務領域でエビデンスに基づく回答システムを構築するためのテンプレートスキル。組織が繰り返し構造化された問い合わせ — 監査、アンケート、コンプライアンス調査 — を受ける場合に、過去の実績とエビデンスを活用して正確に回答するための再利用可能なワークフローパターンとスキャフォールディングファイルを提供する。
使わない場合：
| 現在の状況 | アクション | 開始箇所 |
|---|---|---|
| エビデンス回答を初めて構築する | テンプレートをコピーし、タクソノミーを定義 | セットアップチェックリスト |
| 既存ドメインで新しい問い合わせを受領 | 7ステップワークフローを実行 | ステップ1 |
| 類似の質問に過去に回答済み | まず回答履歴インデックスを検索 | ステップ4 |
| 年次レビュー日が到来 | 鮮度管理プロトコルを実行 | 鮮度管理 |
| 新しいドメインを追加 | テンプレートから新しいインスタンスを作成 | スキャフォールディングファイル |
| 繰り返しパターンのない一回限りの問い合わせ | ❌ このスキルを使わない | — |
空手の「型」のように、このスキルは一度身につけたら様々な場面に応用できるワークフローパターンを提供する。具体的な業務知識（技の細部）は使う人がドメインに合わせて埋める。型があることで：
| 年数 | ナレッジベースの状態 | 回答にかかる工数 |
|---|---|---|
| 1年目 | 初期構築中。過去実績が少なく、調査工数が大きい | 高い |
| 3年目 | 主要な質問パターンに前例がある。類似回答を参照できる | 中程度 |
| 5年目以降 | 豊富なアーカイブ。ほぼ全ての質問に前例がある | 低い（確認作業中心） |
回答するたびにナレッジベースが充実し、次の回答が楽になる — これが「成長の複利」。
| 原則 | 価値観 | 重要な理由 |
|---|---|---|
| 記憶よりエビデンス | 温故知新 | 過去に文書化された回答は、記憶に頼るよりも信頼性が高い |
| 構造化された分類 | 基礎と型 | 分類が再現可能な一貫した回答を可能にする |
| 意図的な空白 | 余白の設計 | テンプレートは構造を提供し、ドメイン知識はユーザーが埋める |
| 知識の蓄積 | 成長の複利 | 各回答が次の回答をより速く正確にする |
| 年次の鮮度管理 | 継続は力 | 定期レビューが知識の陳腐化を防ぐ |
| 依存関係 | 目的 |
|---|---|
| Git | ナレッジベースと回答履歴のバージョン管理 |
| GitHub Copilot（Claude推奨） | 長文コンテキストの知識検索と構造化推論 |
knowledge-base-template.md | ドメイン知識の構造（references/ に同梱） |
response-index-template.md | 回答履歴アーカイブ（references/ に同梱） |
| ファイル | 目的 |
|---|---|
knowledge-base-template.md | ドメイン知識 — コピーして要件を記入 |
response-index-template.md | 回答アーカイブ — コピーして全回答を記録 |
.github/skills/<your-domain>/references/ にコピー新しい問い合わせを受領したときに使用する。理由: 分類が下流の一貫した対応を可能にする。
ドメインのタクソノミーに基づいて問い合わせを分類する。繰り返し発生するタイプを特定してタクソノミーを定義：
| 項目 | 説明 | 例 |
|---|---|---|
| タイプID | 短い大文字識別子 | AUDIT, SURVEY, CERT-CHECK |
| 名称 | 説明的な名前 | 外部システム監査 |
| 送信元 | 典型的な送信者 | 認証機関 |
| 複雑度 | 低 / 中 / 高 | 回答工数に基づく |
# 理由: 全ての問い合わせが正確に1つのタイプに分類される必要がある
新しい問い合わせ受領
├─ 正式な監査か？ → AUDIT
├─ アンケート・調査票か？ → SURVEY
├─ 証明書の要求か？ → CERT-CHECK
├─ コンプライアンス問い合わせか？ → COMPLIANCE
└─ どれにも当てはまらない？ → タクソノミー拡張を検討
価値観: 基礎と型 — 分類は基礎。これなしでは回答がアドホックになる。
問い合わせに複数の質問が含まれるときに使用する。理由: マッピングにより漏れを防ぎ、共有エビデンスを発見できる。
問い合わせを個々の質問に分解する。各質問を要件フレームワーク — ISO（国際標準化機構）規格、IATF（国際自動車産業特別委員会）条項、社内手順など — にマッピングする。
<!-- 理由: 質問ごとの状態追跡が最終回答のギャップを防ぐ -->
| Q# | 要約 | 要件参照 | エビデンス | 状態 |
|----|------|---------|----------|------|
| Q1 | 「手順を説明してください」 | ISO 9001 §7.1.5 | 手順書 Rev.N | ✅ 最新 |
| Q2 | 「トレーサビリティの証拠を提示」 | IATF 16949 §7.1.5.3 | 記録 FY2025 | ⚠️ 更新必要 |
knowledge-base.md を使ってマッピングする。マッピングできない質問は調査対象としてフラグ。
価値観: 温故知新 — ナレッジベースは蓄積された知恵。
質問が要件にマッピングされたときに使用する。理由: エビデンス引用付きドラフトが意見ベースの回答を防ぐ。
マッピングされた各質問に対して、ナレッジベースの内容を使って回答を作成する。
<!-- 理由: 一貫した構造が全回答の品質レビューを可能にする -->
**質問**: [原文の質問テキスト]
**分類**: [タイプID] — [要件参照]
**回答**:
[特定の文書とバージョンを参照したエビデンスベースの回答]
**エビデンス**: [文書名, バージョン, 日付]
**確信度**: 高 / 中 / 低
価値観: 基礎と型 — 一貫した回答構造が品質レビューを可能にする。
回答をドラフトするときに使用する。理由: 過去の回答は検証済みの表現を提供し、矛盾を防ぐ。
回答履歴インデックスで類似質問への過去の回答を検索する。
検索戦略 — この順序でチェック：
<!-- 理由: 過去回答とのリンクが一貫性の検証を可能にする -->
**過去参照**: [年]-[月] | [送信者] | [タイプ]
**元ファイル**: [フォルダパスとファイル名]
**関連性**: [この過去回答が現在の質問に該当する理由]
価値観: 温故知新 — 過去の回答は最も価値ある資産。
回答ドラフトを最終化するときに使用する。理由: 古いエビデンスは信頼性を損ない、コンプライアンス問題を引き起こす可能性がある。
参照する全エビデンス文書が最新であることを確認する。
<!-- 理由: 鮮度確認が古いエビデンスの送付を防ぐ -->
| 文書 | 期待バージョン | 実際バージョン | 状態 |
|------|--------------|--------------|------|
| 手順書 A | Rev.5 (KB) | Rev.5 (確認済) | ✅ 最新 |
| トレーサビリティ記録 | FY2025 (KB) | FY2024 (実際) | ❌ 古い |
| 証明書 | 2025-01 | 2025-01 | ✅ 最新 |
不合格時のアクション：
| チェック | アクション |
|---|---|
| バージョン不一致 | ナレッジベースを最新バージョンに更新 |
| 鮮度期間超過 | レビュー対象としてフラグ、回答にギャップを注記 |
| 規格が廃止 | 後継規格を確認 |
| 手順が変更 | 文書管理者に確認 |
価値観: 継続は力 — エビデンスの鮮度は譲れない。
外部共有用の回答を準備するときに使用する。理由: 機密情報の保護が法的・業務リスクを防ぐ。
外部に回答を共有する前に、組織の機密情報ルールを適用する。マスキングルールはナレッジベースに定義。
<!-- 理由: 一貫したマスキングが偶発的な情報漏洩を防ぐ -->
| カテゴリ | ルール | マスク前 | マスク後 |
|---------|--------|---------|---------|
| 顧客固有の用語 | 汎用化 | 「顧客Xのフォーマット」 | 「お客様のフォーマット」 |
| 社内帳票 | 伏字化 | 「帳票 K-1234」 | 「社内帳票」 |
| 担当者名 | 名前削除 | 「田中がレビュー」 | 「権限のある担当者がレビュー」 |
| 独自手法 | 要約 | 「当社のXYZ工程...」 | 「確立された工程...」 |
公的規格への参照 — ISO、IATF、JIS（日本産業規格）等 — や、外部共有が承認された一般的な手順説明はマスクしない。
価値観: 余白の設計 — 機密情報ルールが意図的な境界を作る。
全ての回答がドラフト・マスキング済みのときに使用する。理由: 最終品質ゲートが受領者へのエラー到達を防ぐ。
提出前の最終品質チェックを実行する。
<!-- 理由: チェックリストが最終回答での一般的な漏れを防ぐ -->
## 最終レビュー
- [ ] 全ての質問に回答がある（空欄なし）
- [ ] エビデンス文書がバージョンと日付付きで引用
- [ ] 該当する場合、過去回答の参照を記載
- [ ] 機密情報マスキングが一貫して適用
- [ ] 回答のトーンが問い合わせの公式度に合致
- [ ] スコープ外の主張なし（フラグ付き項目はエスカレーション）
- [ ] 回答履歴インデックスにこの新エントリを追加済み
スコープ外プロトコル — 質問がドメイン外の場合：
価値観: 基礎と型 — 品質ゲートがエラーの伝播を防ぐ。
トリガー条件（いずれか1つでレビューを開始）：
年次レビューチェックリスト：
metadata.created 日付を更新価値観: 継続は力 — 年次メンテナンスがナレッジの陳腐化を防ぐ。
.github/skills/ に配置 — git-ops-folder-init でディレクトリベースの追跡を設定| 落とし穴 | 影響 | 修正 |
|---|---|---|
| ナレッジベースを更新したが回答履歴を更新しない | 回答が古いエントリを参照 | ✅ 両方を同時に更新 |
| ナレッジベースだけを検索対象にする | 回答履歴の関連する回答を見逃す | ✅ ナレッジベースと回答履歴の両方を検索 |
| 1つの回答に複数の分類タイプを混在 | 形式の不一致がレビュアーを混乱させる | ✅ タイプごとに1回答、必要なら分割 |
| 過度にマスキング | 回答が無意味になる | ✅ 機密情報ルールが要求する範囲のみマスク |
| 「明らかな」回答の鮮度チェックをスキップ | 古いエビデンスが検知されず残存 | ✅ 毎回、全文書を確認 |
| ❌ やってはいけない | ✅ 代わりにやること | 理由 |
|---|---|---|
| 鮮度を確認せずに過去回答をコピペ | 再利用前にエビデンスのバージョンを確認 | 古いエビデンスは信頼性を損なう |
| 「簡単な」回答は回答履歴をスキップ | どんなに短くても全回答を記録 | 複利効果は完全性に依存 |
| スコープ外の質問に回答 | フラグ、エスカレーション、ギャップを文書化 | 捏造された回答は責任問題を生む |
| ナレッジを誰かの頭の中にだけ保管 | knowledge-base.md にリンク付きで文書化 | 暗黙知は人事異動で消える |
| 一回限りの問い合わせにタイプを作成 | 繰り返しパターン（3回以上）のみタイプ追加 | 過剰分類はノイズを増やす |
| 年次の鮮度管理レビューを無視 | スケジュールしてチェックリストを完了 | 陳腐化は誤回答を送るまで気づかない |
IATF 16949 内部試験所アンケート回答スキルが、校正品質管理にこのテンプレートを適用した例を示す：
自分のドメイン固有の実装を作成する際の参考として活用できる。
Q: 何件の回答があればこのテンプレートが有用になるか？ A: 1件の記録でも参照としての価値がある。10件以上で複利効果が明確になる。
Q: 監査以外の問い合わせにも使えるか？ A: はい。繰り返し発生する構造化された問い合わせ — 顧客調査、規制アンケート、内部監査 — 全て適用可能。
Q: マッピングすべき正式な規格がないドメインの場合は？ A: 社内手順やポリシーを要件フレームワークとして使用する。外部規格は必須ではない。
Q: 複数言語の問い合わせをどう扱うか？ A: 回答履歴インデックスに原文の言語を記録する。ナレッジベースは主要な業務言語で維持。
Q: ファイルをバージョン管理すべきか？
A: はい。git-ops-folder-init でディレクトリベースのgit追跡を設定する。変更履歴とロールバック機能が得られる。
knowledge-base-template.md → ドメイン知識 + エビデンス管理台帳 + マスキングルールresponse-index-template.md → 回答アーカイブ + タクソノミー + 統計