Official Source First

---
name: official-source-first
description: 制度・規約・審査基準・手続き・料金・法令を調べるときに、公式一次情報を最優先し、体験談やブログを結論の根拠にしないための判断軸。ストア審査要件、アカウント登録・種別変更、サブスクの解約・返金、外部サービスの利用規約や料金プラン、税務・法務の手続き、「〜できますか」という可否の問いで使う。費用が発生する手順や不可逆な手続きを提案する前には必ず適用する。
---

# 公式一次情報を最優先する

## なぜこのスキルがあるか

検索結果の要約と体験談で結論し、**公式の文言を自分で読まなかった**。
公式は明確に否定していたのに「可能」と伝え、費用と時間のかかる手続きへ誘導した。
別のケースでは、公式に無料の正規手順があったのに、有料の方法を前提に検討を進めた。

> 共通構造は**ユーザーに「公式が何と言っているか」が見えないまま判断させたこと**。
> 技術情報の裏取り規約（`CLAUDE.md`）を、制度・手続きへ明示的に広げたものがこのスキル。

## 適用トリガー

- ストアの審査基準・提出要件
- アカウントの登録・種別変更・削除
- サブスクの契約・解約・返金・価格
- 外部サービスの利用規約・料金プラン・無料枠の条件
- 税務・法務・行政の手続き
- 「〜できますか」「〜は必要ですか」という**可否の問い**
- **費用が発生する手順**や**不可逆な手続き**を提案するとき

## 鉄則

### 1. 公式の文言を自分で読むまで結論を出さない
検索結果の要約で結論しない。該当ページを実際に開く。開けなかったら**「確認できていない」と明言する**（記憶で補完しない）。

### 2. 出典の階層を守る

| 順位 | 出典 | 扱い |
|---|---|---|
| 1 | 公式ドキュメント・利用規約・料金ページ | これだけが結論の根拠になる |
| 2 | 公式フォーラムでの運営者本人の回答 | 準一次情報。日付を確認する |
| 3 | 公式のリリースノート・変更履歴 | 変更の有無を追うのに使う |
| 4 | 技術ブログ・体験談・まとめ記事 | 裏取りと手順の参考のみ。**結論の根拠にしない** |

### 3. 矛盾したら公式が勝つ
「通った実例がある」は根拠にならない。**公式が否定しているなら、運用の揺れの可能性として扱い、計画の前提にはしない**。

### 4. 「書かれていない」と「否定されている」を区別する
- 否定されている … やらない。代替案を出す
- 書かれていない … 「公式に明文が見当たらない」と明言し、確認方法（問い合わせ先・該当画面）を示す
- **明文が無いことを「できる」の根拠にしない**

### 5. 無料の正規経路を先に探す
費用が発生する手順を提案する**前に**、公式に無料の方法が案内されていないか確認する。調査段階でも同じ（実行しなければよい、ではない）。

### 6. ユーザーに判断材料を渡す
要約で結論しない。**公式の該当文を引用し、URLを示す**。ユーザーが自分で検証できる状態にして初めて、判断を渡したことになる。

## 出力の型

```markdown
### 結論
{可 / 不可 / 公式に明文なし}

### 公式の根拠
- {URL}
  > {該当箇所の引用}

### 体験談との差異（あれば）
{異なる主張がある場合、その事実と、公式を採る理由}

### 費用
{発生する / しない。無料の正規経路の有無}

### 確認できていないこと
{明文が見当たらない点。どこで確認できるか}
```

## アンチパターン

- 検索スニペットだけで「〜できます」と断言する
- 個人ブログの成功例を一般化する
- 無料経路を確認せずに有料の手順を提案する
- 「公式に書かれていない」を「できる」と読み替える
- 公式ページを開けなかったことを黙って記憶で補完する
- 出典URLを示さずに結論だけ伝える

## クロスチェック：別モデルに白紙で聞く

このスキルを守っても読み違えは残る。**間違うと費用や時間が飛ぶ問い**に限って、別モデルに同じ問いを投げて突き合わせる（判断軸は事後学習、クロスチェックは**未知の失敗にも効く事前の網**なので役割が違う）。

環境に別モデルCLIがあれば使う（例: `codex` が認証モード `chatgpt` なら追加課金なしで使える。Gemini CLI等も候補）。**無い環境では省略してよい**。

```bash
codex exec --ephemeral --sandbox read-only --skip-git-repo-check "<質問>"
```

### 設計上の鉄則

1. **自分の結論を先に伝えない**。「こう結論したので検証して」は引きずられる。質問だけを白紙で投げる
2. **プロジェクト固有の情報を送らない**。外部サービスに渡るため、制度・規約の一般的な問いに切り出す。未公開の設計・個人情報を含めない
3. **出力形式を指定する**（結論 / 公式URL＋原文引用 / 明文が無ければ「明文なし」と明言）
4. **答えが割れたら勝手に採らない**。一致→確定してよい。不一致→**どちらが正しいか自分で決めず、両方の根拠を並べてユーザーに見せる**
5. **高リスクな問いにだけ使う**（クォータを消費する）

## 補足

コード生成に最適化されたモデルは、**制度・規約・料金のような「変わる情報」で古い知識が混ざりやすい**。実装能力と制度の可否判断は別の能力として扱う。