ChatGPTの回答を一回直す。「次からこうして」。また直す。「これも毎回」。気づけば設定欄には長大なルール、メモリには昔のルール、作業フォルダにも別のルール。全部が「最優先」を名乗り始める。AIの頭の中で、最優先事項の満員電車が発車した。
整理の答えは明快だ。普段の答え方はカスタム指示、会話から続く背景はメモリ、特定の仕事の進め方はプロジェクト指示、細かな作業標準はGitHubなどの管理ファイルへ分ける。ただし、ファイルに保存しただけでChatGPTが自動的に読んだことにはならない。最後は実際の回答で確認する。[1][2][3][4]
1. 四つの置き場所は、そもそも担当が違う
カスタム指示は、どの会話でも使いたい基本方針を書く場所だ。「まず質問に答える」「推測と確認済みの事実を分ける」「必要なら出典を示す」などが向いている。OpenAIの案内では、設定した指示はチャット全体に適用される。[1]
メモリは、過去の会話や利用可能な情報から、その人に関係する背景を今後の会話へ持ち込む仕組み。関心のある分野や進行中のテーマを思い出すのに役立つ。ただし、すべての会話を一字一句保存する倉庫ではない。[2]
プロジェクト指示は、ある仕事にだけ必要な方針を置く場所。たとえば記事制作では「一般読者へ平易に説明し、出典を確かめ、公開前に確認する」。旅行計画の会話まで記事編集者にする必要はない。ChatGPTのプロジェクトでは、プロジェクト指示が全体向けのカスタム指示より優先される。[3]
GitHubのルールファイルは、長く、正確で、変更履歴を残したい仕事の手順書に向く。記事の構成、対応言語、検査項目、保存先、失敗時の対処まで書ける。対応する開発支援AIにはAGENTS.mdを読む仕組みもあるが、通常のChatGPTが任意のGitHubファイルを毎回自動取得するという意味ではない。[4]
2. なぜルールを増やすほど混乱するのか
最初の指示は「短く答えて」。しかし長い話題では説明不足になり、「必要なときは詳しく」。次に長すぎる回答が出て「簡潔に」。さらに「根拠を出して」「ネタを消さないで」「専門語を使わないで」……。
どれも単独ではもっともだ。問題は例外の範囲と適用場所を書かずに、毎回の不満を永久ルールへ追加してしまうこと。「短く」と「詳しく」は敵ではなく、「単純な質問は短く、複雑な判断は必要な深さまで」という一行にできる。
メモリへ細かな検査手順を何十項目も積むのは、冷蔵庫の中に家電の取扱説明書を保管するようなものだ。保管場所は確かにある。だが、夕食を作るたびに製造番号まで読む人はいない。記憶は思い出すため、手順書は正確に実行するため。
3. 仕分けは「いつ、誰が、何に使うか」で決める
ルールを一つ取り出し、四つの質問をする。
- どの会話にも適用したい？ ならカスタム指示。「結論から」「新しい事実は確認」「不要な個人情報は持ち込まない」など。
- 会話を通して変わる背景？ ならメモリ。「最近取り組んでいる題材」「継続中の目標」など。古くなったら見直す。
- この仕事だけのルール？ ならプロジェクト指示。「12言語の記事を書く」「見出しをそろえる」など。
- 長い手順、変更履歴、検査方法が必要？ ならGitHubなどの版を管理できる文書。「各言語の品質検査」「公開前の確認」「失敗時に原稿を保全」など。
そして、今日だけの注文は今日のメッセージへ。「今回はネタ多め、個人情報を除く、全文を一つのファイルに」といった指定を永久ルールへ昇格させる前に、再利用するか考える。
例を二つ。会話の合間に短い英語表現を自然に混ぜたいなら、その基本方針はカスタム指示向き。毎日の英語テストのような細部まで全会話へ強制する必要はない。反対に、チームの仕事でどの変更を誰が承認するかは、個人の好みより案件のルールと実際の権限が優先する。「私の好み」と「この仕事の決まり」は別の引き出しだ。
4. 短いカスタム指示は「骨格」を書く
たとえば、汎用設定はこれくらいの考え方に整理できる。
日本語で最初に質問へ答える。単純な質問は簡潔に、複雑な判断は根拠・反証・比較まで整理する。変わりやすい事実は確認し、推測と実測を分ける。関連する過去の背景だけ利用する。特定のプロジェクトでは、そのプロジェクトの最新ルールを確認できる範囲で適用し、読めなかった資料を読んだふりをしない。
これは「何を大切にするか」を示す骨格だ。記事制作の詳しい検査表、12言語の表記ルール、保存手順などの筋肉や道具は別の文書に置ける。
書き換えのコツは、同じ目的の指示を一つにまとめること。「結論先」「分かりやすく」「長すぎるな」は一緒にできる。一方、「危険な個人情報を公開しない」のような重要な制約は、短縮して意味を消さない。削るのは重複であって、安全の境界ではない。
5. GitHubを正本にするなら「保存」と「読んだ」を分ける
細かな編集ルールを一つの文書へまとめ、プロジェクトの入り口に「作業前に最新版を参照」と書く。変更のたびに文章の版が残る。複数のAIや担当者が同じ手順を参照しやすくなる。
ただし、ここで小さな落とし穴。GitHubへ保存成功 → すべてのAIへ念力で配信完了、という通信方式は存在しない。対象のAIにファイルを読む権限と手段が必要で、実際に開いたかを確かめる必要がある。権限がなければ、必要な節を会話へ渡す方法もある。
保存した原稿も同じ。ファイルを作る、GitHubへ書く、書かれた内容を読み戻す、公開サイトへ反映する、読者が実際に見られる――これは別々の出来事だ。「保存できた」と「世に出た」を同じ完了印で塗らない。 ルールファイルの更新も、走っている定期タスクの設定変更を自動保証するわけではない。
6. 本当に効いたかは、二つの会話で試す
指示を整理したら、以前に困った場面を二つ選ぶ。一つは普段の質問、もう一つはそのプロジェクト特有の作業。
普段の質問では「結論を先に答え、根拠の必要なところだけ調べたか」を見る。プロジェクト作業では「最新版のルールを実際に取得したか」「専門的な手順を守ったか」「できなかった工程を正直に分けたか」を確認する。ファイル名を答えただけでは、本文を読んだ証拠にならない。
うまくいかなければ原因を分ける。ルールを読めなかった／読んだが曖昧だった／別の指示と衝突した／実行環境や権限が足りなかった。ここを区別せず「もっと強く絶対と言おう」とだけ書き足すと、最優先事項の満員電車に特急列車が一本追加される。
7. 結局、目指すのは「全部覚えたAI」より「必要なルールに戻れるAI」
メモリは背景を思い出す。カスタム指示は日常の振る舞いを整える。プロジェクト指示は仕事の方向を合わせる。GitHubの文書は細かな決まりを同じ版で管理する。今日の依頼が具体的な成果物を指定する。
これなら、改善点が一つ増えても、まず置き場所を決めればいい。全会話のカスタム指示を増築し続ける必要がない。AIの記憶力を筋トレさせるより、手順書の住所を教えて、実際に読んだか確認する。
最強の指示は「絶対」を100回書いた長文ではない。誰がいつどのルールを使うかが分かり、最後に結果を検証できる指示だ。
参考資料（4件）
[1] OpenAI Help Center, ChatGPT Custom Instructions: https://help.openai.com/en/articles/8096356-chatgpt-custom-instructions
[2] OpenAI Help Center, Memory in ChatGPT: https://help.openai.com/en/articles/8590148-memory-in-chatgpt
[3] OpenAI Help Center, Projects in ChatGPT: https://help.openai.com/en/articles/10169521-projects-in-chatgpt
[4] GitHub Docs, Adding repository custom instructions for GitHub Copilot in your IDE: https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/customize-copilot/configure-custom-instructions/add-repository-instructions-in-your-ide
