mae616 公式一次情報を最優先する
なぜこのスキルがあるか
検索結果の要約と体験談で結論し、公式の文言を自分で読まなかった。 公式は明確に否定していたのに「可能」と伝え、費用と時間のかかる手続きへ誘導した。 別のケースでは、公式に無料の正規手順があったのに、有料の方法を前提に検討を進めた。
共通構造はユーザーに「公式が何と言っているか」が見えないまま判断させたこと。 技術情報の裏取り規約（
CLAUDE.md）を、制度・手続きへ明示的に広げたものがこのスキル。
適用トリガー
- ストアの審査基準・提出要件
- アカウントの登録・種別変更・削除
- サブスクの契約・解約・返金・価格
- 外部サービスの利用規約・料金プラン・無料枠の条件
- 税務・法務・行政の手続き
- 「〜できますか」「〜は必要ですか」という可否の問い
- 費用が発生する手順や不可逆な手続きを提案するとき
鉄則
1. 公式の文言を自分で読むまで結論を出さない
検索結果の要約で結論しない。該当ページを実際に開く。開けなかったら**「確認できていない」と明言する**（記憶で補完しない）。
2. 出典の階層を守る
| 順位 | 出典 | 扱い |
|---|---|---|
| 1 | 公式ドキュメント・利用規約・料金ページ | これだけが結論の根拠になる |
| 2 | 公式フォーラムでの運営者本人の回答 | 準一次情報。日付を確認する |
| 3 | 公式のリリースノート・変更履歴 | 変更の有無を追うのに使う |
| 4 | 技術ブログ・体験談・まとめ記事 | 裏取りと手順の参考のみ。結論の根拠にしない |
3. 矛盾したら公式が勝つ
「通った実例がある」は根拠にならない。公式が否定しているなら、運用の揺れの可能性として扱い、計画の前提にはしない。
4. 「書かれていない」と「否定されている」を区別する
- 否定されている … やらない。代替案を出す
- 書かれていない … 「公式に明文が見当たらない」と明言し、確認方法（問い合わせ先・該当画面）を示す
- 明文が無いことを「できる」の根拠にしない
5. 無料の正規経路を先に探す
費用が発生する手順を提案する前に、公式に無料の方法が案内されていないか確認する。調査段階でも同じ（実行しなければよい、ではない）。
6. ユーザーに判断材料を渡す
要約で結論しない。公式の該当文を引用し、URLを示す。ユーザーが自分で検証できる状態にして初めて、判断を渡したことになる。
出力の型
### 結論
{可 / 不可 / 公式に明文なし}
### 公式の根拠
- {URL}
> {該当箇所の引用}
### 体験談との差異（あれば）
{異なる主張がある場合、その事実と、公式を採る理由}
### 費用
{発生する / しない。無料の正規経路の有無}
### 確認できていないこと
{明文が見当たらない点。どこで確認できるか}
アンチパターン
- 検索スニペットだけで「〜できます」と断言する
- 個人ブログの成功例を一般化する
- 無料経路を確認せずに有料の手順を提案する
- 「公式に書かれていない」を「できる」と読み替える
- 公式ページを開けなかったことを黙って記憶で補完する
- 出典URLを示さずに結論だけ伝える
クロスチェック：別モデルに白紙で聞く
このスキルを守っても読み違えは残る。間違うと費用や時間が飛ぶ問いに限って、別モデルに同じ問いを投げて突き合わせる（判断軸は事後学習、クロスチェックは未知の失敗にも効く事前の網なので役割が違う）。
環境に別モデルCLIがあれば使う（例: codex が認証モード chatgpt なら追加課金なしで使える。Gemini CLI等も候補）。無い環境では省略してよい。
codex exec --ephemeral --sandbox read-only --skip-git-repo-check "<質問>"
設計上の鉄則
- 自分の結論を先に伝えない。「こう結論したので検証して」は引きずられる。質問だけを白紙で投げる
- プロジェクト固有の情報を送らない。外部サービスに渡るため、制度・規約の一般的な問いに切り出す。未公開の設計・個人情報を含めない
- 出力形式を指定する（結論 / 公式URL＋原文引用 / 明文が無ければ「明文なし」と明言）
- 答えが割れたら勝手に採らない。一致→確定してよい。不一致→どちらが正しいか自分で決めず、両方の根拠を並べてユーザーに見せる
- 高リスクな問いにだけ使う（クォータを消費する）
補足
コード生成に最適化されたモデルは、制度・規約・料金のような「変わる情報」で古い知識が混ざりやすい。実装能力と制度の可否判断は別の能力として扱う。