AI スキル取り逃しを 1 文字のトリガーで塞いだ話
AI コーディングエージェントの「スキル」機構は便利だが、AI が手元のスキルを per-turn の通知精度に依存して判定するため、登録済みなのに「無い」と判断されることがある。本稿はその取り逃しを 暗黙トリガー（遅延ロード） と 明示トリガー S の二段構えで塞いだ設計判断の記録。同じ問題に当たった人が手元の運用に転用できる形でまとめている。
1. きっかけになった実例
あるセッションで「この考え方を HTML で説明してほしい」という依頼が来た。本来なら自前のデザイン用スキルで生成すべき場面だったが、AI は自前で生 HTML を書き始めた。
| 観点 | 状態 |
|---|---|
| 登録済みスキル | 多数（HTML 生成用スキルを含む） |
| その turn の通知 | 関係薄い 1 件のみ |
| ユーザー意図 | HTML 生成（既存スキルの起動語そのもの） |
| AI の判断 | 「通知に出ていない」→「無い」と決めつけ → 自前で生成 |
| 結果 | house style 非準拠の HTML が生まれた。ユーザー指摘で発覚 |
本当の原因は 通知の精度 と AI の杓子定規な解釈 の 2 つ。前者はエージェント側の問題で短期では直せない。後者は運用側の規則で吸収できる。
2. 暗黙トリガー — 案 A/B 対比
グローバル設定に常時 import で常駐
@<path-to-skills-index>- 毎 turn 強制ロード（早見表全文が context へ）
- 早見表が成長するほど context を食う
- 使わない turn でも料金とトークン枠を消費
規則 5 行だけ常時。必要時に Read
「スキル」「HTML で」「リリースして」等の
依頼が来たら、毎回その場で早見表を Read- 常時ロードは規則本文だけ（約 500 文字）
- 早見表本体はトリガー時のみ Read
- 言及されない turn ではゼロロード
3. 明示トリガー S — 暗黙の保険
案 B（暗黙トリガー）は機能するが、AI の意図解釈に依存する。確実に発動させたい時の保険として、明示トリガー S を追加した。
形式と動作
| 形式 | 例 | 動作 |
|---|---|---|
S + テキスト |
S これを HTML で説明 |
早見表を 必ず Read → 続くテキストと起動語を突き合わせ最も合うスキル 1 つを特定 → 起動（args に続くテキスト全文） |
S 単独 |
S |
早見表を Read しユーザーに提示。「どれを使いますか」と聞く |
S + 改行 |
S\n依頼内容 |
S + テキストと同じ |
衝突回避ガード
S の直後が英字（SQL SSH Stack 等の単語の頭）の場合は通常テキスト扱い。半角スペース・数字・改行が続く時だけ発動するように規則化した。
| 判定対象 | 判定 |
|---|---|
S これ HTML で | 略記発動（S + 半角スペース） |
S（メッセージ全体） | 略記発動（S 単独） |
SQL を書き直したい | 通常テキスト（S + 英字） |
SSH 接続できない | 通常テキスト（S + 英字） |
Stack トレースを読んで | 通常テキスト（S + 英字） |
4. P 略記（既存）も skill 化
既存の P 略記（最新スクリーンショット参照のショートカット）は約 20 行ベタ書きされていた。これを screenshot-read スキルに外出しし、グローバル設定側はポインタだけに縮約。狙いは 常時 context の削減 と S と並べた時の対称化。
グローバル設定にベタ書き
- P 略記節が約 20 行（表 + 手順 4 ステップ + 注意書き）
- 全プロジェクトで毎 turn ロード
- 詳細手順の編集はグローバル設定の直編集
screenshot-read スキルへ
- グローバル設定の P 節は 2 行のポインタに
- 詳細はスキル本体の SKILL.md
- P 発動時にスキルとして invoke
5. P と S の対称構造
両者を並べると、プロンプト先頭 1 文字で 「コンテキストを取り込む / スキルを起動する」 という 2 つの基本動作が選べる形になった。
Picture（スクショ）
最新スクショを N 枚読んで、続くテキストの指示で応答する。
P | 最新 1 枚 |
P3 説明 | 最新 3 枚 + 指示 |
P 何が映ってる？ | 最新 1 枚 + 質問 |
Skill（スキル起動）
早見表を必ず Read し、続くテキストから該当スキルを特定して起動する。
S | 早見表を提示 |
S リリースして | release 系スキル起動 |
S HTML で説明 | HTML 生成スキル起動 |
6. 既存 lazy-load パターンとの整合
グローバル設定には既に「正典ファイルは別に置き、必要になった時だけ Read する」設計が複数あった。今回のスキル規則はその仲間として同じ形に揃えた。一貫した行動様式になり、AI が迷わない。
| 対象 | トリガー（言及語・状況） | 参照先（抽象表記） |
|---|---|---|
| ローカル開発ツール一覧 | ツール有無の判断が必要になった時 | ローカルのツール一覧ファイル |
| サーバー接続情報 | 実値（接続情報・認証）が必要な時 | 別管理の認証情報ファイル群 |
| 個人系名簿 | 会話に固有の名前や関係が出た時 | ローカル名簿の CSV |
| KB（人物・会社等） | 人物・会社・サービスの話題が出た時 | ローカル KB の CSV 群 |
| スキル（追加） | 暗黙: 「スキル」「HTML で」「リリースして」等の作業依頼語 / 明示: S 先頭略記 |
スキル早見表 |
7. トリガーから invoke までの流れ（暗黙 / 明示の 2 経路）
8. 規則の本文（雛形）
運用しているグローバル設定の該当節を、抽象化したかたちで掲載する。実環境に合わせてパスや起動語を差し替えれば、同じ構造で動かせる。
登録済みスキルのインベントリ（暗黙トリガー）
## 登録済みスキルのインベントリ（言及されたら参照）
スキルの早見表（起動語・主な引数・出力先）は別ファイルにある
（常時ロードしない）。ユーザーが「スキル」と言及した時、または
「HTML で作って／説明して」「リリースして」「CI 組んで」「npm 公開して」
等の作業依頼語を口にした時は、毎回その場で早見表を Read してから
判断すること。
per-turn の「Available skills」一覧は機械的に絞られて精度に欠ける。
通知に出ていなくても登録されているスキルは多数あるので、通知だけ
見て「無い」と判断しない。「通知に出ているもののみ invoke」という
デフォルト制約は、本規則に基づき早見表で該当スキルが確認できれば
緩和してよい。プロンプト先頭の S 略記（明示トリガー）
## プロンプト先頭の `S` 略記（スキル起動）
ユーザーのメッセージが半角大文字 S で始まる場合、形式を判定し
必ず早見表を Read してからスキル特定する。
| 形式 | 動作 |
|----------------|-------------------------------------------|
| S + テキスト | 早見表と起動語を突き合わせ → 起動 |
| S 単独 | 早見表を提示し「どれを使いますか」 |
| S + 改行 | S + テキストと同じ |
S の直後が英字（SQL / SSH / Stack 等）の場合は通常テキスト扱い。
半角スペース・数字・改行が続く時だけ発動。毎ターン独立判定。プロンプト先頭の P 略記（スキル化後・縮約版）
## プロンプト先頭の `P` 略記（スクリーンショット参照）
ユーザーのメッセージが半角大文字 P で始まる場合
（P<数字> / P + テキスト / P 単独 / P + 改行）は、
screenshot-read スキルを起動する。
詳細手順はスキル本体の SKILL.md を参照。
P で始まらないプロンプトでは何もせず通常応答する。9. 効いてくる場面 / 効かない場面
| 場面 | 規則の効果 | 結果 |
|---|---|---|
| 「HTML で説明して」（暗黙） | 作業依頼語検出 → 早見表参照 → 該当スキル発見 → invoke | 効く |
「S HTML で説明」（明示） |
先頭 S → 早見表強制 Read → 起動 | 必ず効く |
「S」単独 |
早見表参照 → 提示 | 効く |
| 「リリースして」（暗黙） | 早見表参照 → release 系発見 → invoke | 効く |
「P3 違いを説明」 |
先頭 P → screenshot-read 起動 → 最新 3 枚 Read | 効く |
「SQL を書き直したい」 |
S + 英字 → 略記非該当 → 通常応答 | 誤発動しない |
| 純粋な質問・調査 | トリガー語なし → 早見表ロードしない | 不要 |
| スキル登録漏れ | そもそも早見表に無い → 早見表メンテで対処 | 人手 |
10. 設計判断としての要点
AI の「無い」判断を信用しない
AI が「無い」と言ったら、まずユーザー側の名簿で照合できる導線を用意する。AI の自己申告だけを唯一の判定根拠にしない。
暗黙と明示の二段構え
意図検出に全部任せると取り逃す。1 文字でいいから明示の入口を別に作っておく。普段は暗黙で自然に、確実に発動させたい時だけ明示で。
既存パターンに揃える
新規ルールを足すとき、似た既存パターンが複数あったらそれらの仲間になる形を選ぶ。一貫性は将来の自分への投資。
常時ロードはコスト
「全件常駐」は確実だが線形に重くなる。「言及されたら Read」のほうがスケールする。常時ロードは規則本文だけに絞り、データ本体は遅延ロード。
対称化できるなら対称化
P と S、ベタ書きとスキル化、暗黙と明示。揃えるたびに頭の中の規則が減る。理解と説明のコストが下がる。