NoteStack
This page is a beginner-friendly note about how a custom GPT uses settings vs chat context. It focuses on what persists, what doesn't, and how to avoid misunderstandings.
「保存されないの?」マイGPTのチャット履歴と設定の反映範囲
右側のチャットで伝えたことが「次回以降も効くのか」を、運用で迷いにくい切り分けとして整理します。
まず結論:右側は「会話の文脈」、左側は「マイGPTの仕様」
いちばん混乱しやすいところなので、最初に言い切っておきます。
右側(チャット欄)でのやり取り
そのチャット(そのスレッド)の中では文脈として使われます
でも「設定として固定される」わけではありません
新しいチャットを開いたとき、同じように効く保証はありません
左側(マイGPTの設定)
そのマイGPTの土台(ルール・前提・役割) になります
新しいチャットを開いても、毎回この前提からスタートします
「いつも守ってほしいこと」はここに置くのが安全です
体感としては、左側が「憲法」、右側が「その日の作業メモ」に近いです。
よくあるつまずき:同じ話をしたのに、次回は守られない
「前に言ったのに…」が起きるのは、だいたい次のパターンです。
つまずき例
右側で「今後はこの方針で」と伝えたが、次のチャットでは前提が戻ってしまう
右側で長い前提を説明したが、数ターン後に要点が薄まる
「覚えてる?」ように見えたり、見えなかったりして不安定に感じる
なぜ起きる?(迷いの原因)
右側のチャットは「その会話の中で役に立つ文脈」ですが、マイGPTの恒久的なルールとして保存される仕組みではない ためです。
逆に、左側に書いた内容は「毎回の前提」として使われるので、再現性が上がります。
切り分けの判断基準:どっちに書けばいい?
迷ったら、次の質問で判断するとブレにくいです。
Q1. これが守られないと困る?(再現性が必要?)
YES → 左側(設定) です。たとえば口調、必須の出力形式、禁止事項、判断基準、守るべき順番など。
Q2. これは今回だけの作業条件?
YES → 右側(チャット) で十分です。たとえば「今日はこのファイルを直す」「このログだけ見て判断する」など。
Q3. 何度も同じ説明をしている?
YES → 左側に移したほうが楽 です。繰り返しが発生している時点で、設定化の効果が出ます。
Q4. 具体例・素材(コード、ログ、URL)が中心?
この場合は、右側で扱うほうが自然です。素材は会話ごとに変わりやすく、設定に固定すると逆に邪魔になることがあります。
運用の型:右側で決めたら、左側に「要点だけ」転記する
一番安定するのは「右側で試行錯誤 → うまくいった要点を左側へ」という流れです。
おすすめの流れ
右側で会話しながら「こうしたい」を詰める
決まったルールを、短い箇条書きにする
左側の設定に貼り付けて固定する
転記するときのコツ
長文のまま貼るより、守らせたいルールだけ を抜き出す
「やること」より「判定基準」を入れる(例:必ず h2 直後は1文、など)
例を1つだけ添えるとブレにくい(例:タイトルの形式)
コピー運用の注意:既存マイGPTを複製しても「右側の会話」は一緒に移らない
「Python用マイGPTをコピーしてCSS用に調整」のような運用では、ここもハマりやすいです。
コピーで引き継がれやすいもの
左側の設定(指示文・知識・ファイル)
そのマイGPTが持つ役割・ルールのベース
コピーで引き継がれにくいもの(勘違いしやすい)
右側チャットで詰めた「会話の流れ」
その場の前提・素材・例外条件
だからこそ、右側で有用だったルールは、左側へ要点を移しておくのが効きます。
よくある質問(FAQ)
Q. 右側で「今後もこの方針で」と言えば、次回以降も確実に効きますか?
A. 確実ではありません。次回以降も守らせたいなら、左側(設定)に固定するのが安全です。
Q. 右側でのやり取りは、完全に無駄ですか?
A. 無駄ではありません。右側は「試行錯誤の場」として強いです。うまくいった内容を左側へ移すと、運用が安定します。
Q. 左側に書きすぎると、逆に扱いづらくなりませんか?
A. なります。だから「毎回守るべきルール」だけに絞るのがおすすめです。素材や作業メモは右側へ、が基本です。
Q. 左側には、どのくらいの粒度で書くと良いですか?
A. 「出力が変わるポイント」だけで十分です。口調、必須構成、禁止事項、判断基準などを短く書くと安定します。
Home
サイトのトップページ
NoteStack
気になったことを、ChatGPTと一緒に試行錯誤のログとして残しているノート集です。
「どこで切り替える?」JavaScriptとTypeScriptの違いと移行タイミング
JavaScriptからTypeScriptへ移るときの「違い」と「移行する自然なタイミング」を、迷いにくい判断軸で整理します。
TypeScript
手順
CSPログの見方:csp-received.log を安全に閲覧する(tail / less / grep)
CSP を Report-Only で運用開始できたら、次にやることはとてもシンプルです。「ログを見る」 です。
CSP
運用
Linux
CSP Report-Only を安全に運用開始する(Nginx + PHP + SELinux)
「CSPを入れたいけど、いきなり厳しくするとサイトが壊れそう」——この不安は正しいです。CSPは強力な反面、いきなり強制(enforce)すると広告・解析・外部JSなどが止まりやすい ため、まずはReport-Only(観測のみ) から始めるのが定石です。
CSP
Nginx
PHP
SELinux
セキュリティ
運用
Nginxで安全に入れられる基本セキュリティヘッダ(ほぼ壊れない)
「セキュリティヘッダを入れたいけど、サイトが壊れるのが怖い」——この不安はとても自然です。ヘッダの中には入れ方を間違えると動作に影響 するものがありますが、逆に“ほぼ壊れない”基本セット もあります。
Nginx
セキュリティ
手順
SSHのWARNING:post-quantum鍵交換ではないと言われたときの確認と対策
初心者の方でも混乱しないように「何が起きているのか」「今すぐ対応が必要なのか」「どこを見れば判断できるのか」を、手順つきでまとめます。
SSH
セキュリティ
トラブル
暗号