取扱説明書を、
AIが実行できる形で置く。

Rob Hallamさんは、SNS運用サービスSuperXにエージェント向けのSkillsライブラリを追加した。公開リポジトリには、分析、返信候補、投稿案、見込み客探索などの目的ごとに、CLIやAPIの手順と停止点が並ぶ。認証状態を最初に確かめ、公開のような不可逆な操作は人の確認を挟む。これは「機能があります」という紹介より一段具体的な、AIが仕事を始めるための取扱説明書だ。

shinshin86さんのローカルTTS検証環境にも、似た入口がある。利用者はGoogle Colabで音声エンジンを選び、必要な設定だけ入れたセルをコピーできる。公開リポジトリには、OpenAI互換の音声API、各エンジンの動作状況・言語・利用条件、CodexやClaude CodeからColabを扱うための構成が記されている。「動作確認済みが50種類に達した」という件数は本人の説明で、全品質を独立再現したものではない。

説明書を、製品の外側に置かない

二つをつなぐと、説明書はサポート資料ではなく、製品の入口になる。人向けページは「何ができるか」を伝える。エージェント向け手順は、いつ選ぶか、必要な入力は何か、どの順で動くか、成功をどう確かめるか、どこで止まるかを渡す。同じ製品でも、読む人と実行するAIでは必要な文書の形が違う。

たとえばAIキャラクターの声を比べたい場面。担当者が長いREADMEをAIへ渡すのではなく、「同じ五文を二つのTTSで生成し、所要時間と利用条件を表にし、音声ファイルを並べたら止まる」という手順を選ばせる。環境の起動と記録はAIが進め、声の採用は人が聞いて決める。説明が実行へつながり、権利や好みの判断だけが人へ戻ってくる。

小さく試すなら、一つの仕事を六欄にする

まず、繰り返し頼んでいる仕事を一つ選ぶ。「使う場面」「必要な入力」「実行手順」「期待する出力」「検証方法」「人へ戻す条件」の六欄だけを書く。AIに一度実行させ、迷った箇所と危険だった箇所を追記する。機能一覧を増やす前に、一つの仕事が最後まで安全につながるかを見る。

あなたの製品の説明は、
AIが読めるだけでなく、正しく動いて、必要な場所で止まれるだろうか。