自分用のSkillを配ろうとしたら、書いていなかったルールが3行増えた

自分用と配布用は、同じファイルではなかった

このシリーズでは、AIに本の解釈を先回りさせないための仕組み「Reading Project Starter」を設計した話と、それをどこで動かすか迷った話を書いた。

自分では動いているので、そのまま配ればいいと思っていた。

ところが公開用に見直したら、自分用には一行も要らなかったルールが3行増えた。 増やしてから、なぜ自分用に書かなかったのかが分かった。

まず配布物を置いておく。使い方はその下。増えた3行の話は最後に書く。

ダウンロード

reading-project-starter-v1.0.zip（27KB）

バージョン：v1.0（2026年8月16日時点）
ライセンス：MIT。改変も再配布も自由。ただし無保証
中身：14ファイル。これまでの記事で「12ファイル」と書いていたのは自分用の構成で、配布版は assets/icon.svg を足して14になった

更新する予定は今のところない。もし直したら、また記事にする。

reading-project-starter/
├─ SKILL.md
├─ LICENSE
├─ agents/openai.yaml
├─ assets/
│  ├─ icon.svg
│  └─ templates/     5ファイル（出力の雛形）
├─ references/       3ファイル（探索方針・レビュー隔離方針・出力仕様）
└─ scripts/          2ファイル（雛形展開・検証）

何をするものか

一冊の本につき、ChatGPTのProjectを一つ作る。そのProjectに置く材料を、このSkillが最初にまとめて生成する。

出てくるのは5つのMarkdownファイル。

ファイル	中身
`01_book-context.md`	書誌情報と本の背景
`02_author-context.md`	著者・解説者の最低限の背景
`03_reviews.md`	書評・第三者評価（封印される）
`04_my-reading.md`	自分の疑問・違和感・考えの変化（ほぼ空で出てくる）
`project-instructions.md`	AIがこのProjectでどう振る舞うかのルール

要約は作らない。本の「正解」も出さない。詳しくは設計の記事に書いた。

使い方

1. インストールする

2026年8月11日に私が試した環境では、ダウンロードしたzipをChatGPTのSkills画面から追加できた。デスクトップ側とWeb・モバイル側では別々に追加する必要があり、自動同期されなかった。

これは私の環境で起きた実験結果であり、すべての環境で同じように動くことを保証する説明ではない。

一方、2026年8月17日時点の公式案内では、standalone Skillの対象はChatGPTデスクトップアプリ、Codex CLI、IDE拡張とされている。Web・モバイルを含め、他の人がインストールできる形で配布する場合はPluginが推奨されている。

今回配布するzipは、Pluginではなくstandalone Skillである。私が実際に試したものを、そのまま配布する。

2. Workから起動する

通常のChatではなくWorkを使う。 ここが今回いちばんの注意点で、理由は別の記事にまるごと一本使って書いた。要約すると、通常Chatからも呼べたが、今回の比較では成果物がWorkの約3分の1だった。

Workで、こう投げる。

@Reading Project Starter
DXの思考法　西山圭太、冨山和彦

必要なのは書名と、関係者を最低1名だけ。 それ以外は聞かれない。「なぜこの本を読むのか」のような設定質問をしない設計にしてある。

役割が分からなければ、雑に名前だけ並べて構わない。出版社の公式情報を見て、著と解説の違いは向こうが直す。

3. 生成されたフォルダをProjectに入れる

<書名>-reading-project というフォルダに5ファイルが出てくる。ChatGPTで本用のProjectを新規作成し、情報源にこの4ファイルをアップロードする。

project-instructions.md の中身を、Projectのインストラクション欄に貼る。ここを忘れるとレビュー封印が効かない。

4. あとは自分で本を読む

読みながら思いついたことがあれば、その都度Project内に新しいチャットを作る。1本の長いチャットに全部入れない。

読み終わったら、Project全体を横断してまとめるチャットを作る。散らばった自分の思考をそこで整理する。

04_my-reading.md はほぼ空で生成される。そこは自分で埋める場所である。

動作環境

ChatGPTのPersonal Skillが使えること
Workが使えること
スクリプトはPython。ただし手元で実行する必要はなく、Workの中で動く

ここから先は、配布用に直した話

使い方は以上。ここから下は読まなくても使える。

増えた3行

公開用に見直して、SKILL.md に Privacy and data handling という節を足した。中身は3つ。

--reader-note に書いた文章はそのままファイルに残るので、パスワードやAPIキーや個人を特定できる情報を入れないこと
Web調査は検索語を外部に送る。未公開の原稿、社内資料、非公開のプロジェクトなどを扱うなら、明示的な許可なくそれを検索に使わないこと
検証用のベースラインJSONには、スキーマ情報と書誌情報とハッシュ値しか保存しない。絶対パスは保存しない

差分はこれだけ。他は一文字も変えていない。

なぜ自分用には書かなかったのか

書き終えてから、この3行に共通点があることに気づいた。

全部、自分一人で使っている限りは「気をつければいい」で済む話である。

自分のreader-noteに自分のパスワードを書く人はいない。自分の会社の資料を検索に投げるかどうかは、自分の判断でその場で決められる。ベースラインJSONに自分のPCの絶対パスが入っていても、自分しか見ない。

だから書かなかった。書く必要がなかった。

ところが他人の手に渡ると、書いていないルールは存在しないルールになる。

reader-noteは「読む前の自分の考え」を入れる欄なので、思ったことをそのまま打つ。そこに勤務先の話が混ざる可能性は普通にある。読もうとしている本が業務上の非公開資料である可能性もある。生成されたファイルを誰かに見せたとき、絶対パスからユーザー名が読める可能性もある。

どれも、自分がやらないというだけの理由で、仕様には書かれていなかった。

「気をつければいい」は仕様ではない

これは今回の副産物で、たぶんSkillに限らない話だと思う。

自分用のツールには、明文化されていないルールが必ず入っている。 使っている本人の頭の中にあって、ファイルには書かれていない。動いているので、書かれていないことに気づけない。

配ろうとした瞬間に、それが可視化される。「これ、書いてないな」と思った箇所が3つあった。逆に言えば、配らなければ永遠に気づかなかった。

ちなみにこのサイト自体、記事を書くために作った仕組みを何度も記事にしている。作ったものを一度外に出す形にしてみると、作ったときには見えなかったものが出てくる、というのは、たぶん同じことが起きている。

使ってみた人へ

そういうわけで配ってみます。

最初の記事に書いたとおり、似たような方法を実践している人はたくさんいると思う。それでも、自分が本を読みながら感じた違和感から形にしたものなので、そのまま置いておく。

使ってみて何か起きたら知りたい。特に、自分では気づいていない「気をつければいい」がまだ残っているはずなので。

そして肝心の『DXの思考法』は、まだ読み終わっていない。