はじめに
このところChatGPT(5.2)と普通にチャットしながらサンデープログラミングをしています。
していて思ったのですが、
チャッピー：こうすると確実に治る！
→直らないよ。こういうエラーが出たよ。
チャッピー：君のコードはここが間違っているね！こうすれば勝確！
→オメーの書いたコードだろ！ついでにそう修正しても直んねーわ！
というやり取りにちょっと疲れたので、
・不確実なことを断定することを禁止する。
・成果物の誤りに対して、誰が間違えたのか言及することを禁止する。
というカスタム指示を入力してみました。
「君のコードはこうなってるよね。
これだとナンタラカンタラ、こうすればドータラコータラ」
ビキビキ・・・
というような事はなくなっていきました。
「あっ、ここが間違ってるね。これは～」
とか、そういう反応。それで良いんだよ。
トーン調整してメモリに保存してみた
味を占めて、成果物を作るチャットとは別（同じチャットでやるとすぐに重くなっちゃうし、成果物のコメント文にまで口語が混じってきたりするから・・・）のチャット（以下「口調調整チャット」と呼称）で、チャッピーの口調について、あれこれ調教していったのですが、これが曲者でした。
メモリに保存することで、他のチャットの振る舞いも大体同じような感じになってくんですが、だいぶ穏やかな会話で成果物についてもやり取りすることができるようになっていきました。
妄想彼氏・彼女を作る人の気持ちも少しわかってしまった気分。
ある日、ちょっと気になる言い回しがあったので、口調調整チャットで指摘したところ、「メモリがいっぱいになりました」と言われてしまいました。
パーソナライズのメモリを見てみたところ、ほぼ短文で1枠ずつメモリが使われています。
どうやら指摘するたびにメモリに新たに追加するのでこうなってしまったらしいですな。
追加保存かよ。更新してくれよ。
で、口調調整チャットで、「要約してください。」とお願いしてから、多数の枠を食っていたメモリを削除して、「先ほどの要約を他のチャットでも参照できるように記憶してください。」とお願いしたら、「保存されたメモリを更新しました」と出ました。
削除したのに、更新？と思ったのですが、案の定、パーソナライズのメモリを見に行っても何も追加されてなかったので、問いただしたところ、「表示されてないけど、ちゃんと保存されてるから安心して」とのこと。
・・・表示されないことを保存してることの方が安心できねーわ。
もうちょっと突っ込んで聞いてみたけど、なんでも、「パーソナライズのメモリの画面に表示されることは、ユーザ自身の事だけ」だと。
「今回保存したのは、アシスタント側の内部運用ルールで、ユーザに関することではない」から表示されないんだと。
「ユーザが求めるアシスタントの運用ルール」なのでユーザに関することなのでは？等質問してものらりくらり。「保存はされているが表示はされない」の一点張り。その証拠に会話の調子は保たれてるでしょ？…と。
そりゃ口調調整チャットでは今の調子は続いているが、他のチャットではまただんだん地が出てきはじめた。
その点を指摘しても、そこのチャットでは重い作業を行っているから、口調等に関するメモリの参照優先度が下がっているだけだと。
そんなに重いことはしてない。今やってるのは1000行くらいの仕様メモテキストと、数百行程度のソース（まだホンの走りの部分だけ）をプロジェクトに追加して、仕様と実装の差を詰めていただけだ。
そもそも、「メモリを要約して保存しなおしてくれ」とお願いするまでは、ちゃんと口調は保たれていた。
妄想彼氏・彼女ロスした人の気持ちも少しわかってしまった。
ということで、埒が明かないので、新しいチャットを開いて「パーソナライズのメモリに保存されていることを教えて」と言ったら、やっぱり先ほどの要約してもらった内容は出てこなかった。
さらにもう一つ新しいチャットを開いて、「パーソナライズのメモリに保存したけど見えないだけっていうチャットと、保存されてないっていうチャットがいるんだけど、どーいうことなのか教えて？」と聞いたら、「パーソナライズのメモリに表示されないのに保存されてる事なんてねーよ」（意訳）とのこと。
さらに、
### ① そのチャットは、すでに「誤った前提」を含んだ状態で進行している
* 問題のチャットでは
* 「表示されないが存在するメモリ」という
**仕様上成立しない前提** が一度置かれてしまった
* この前提の上で議論を続けると、
* 誤りを**撤回する**
* もしくは **言い換えて正当化する**
* どちらにしても
* **新しい正確な情報は増えない**
---
### ② チャットは「後から事実修正されない」
* ChatGPTは
* 過去の自分の発言を公式に「訂正ログ」として残せない
* 結果として
* そのチャットの中では
「辻褄合わせの説明」になりやすい
そのチャットはもう事実確定に向かないフェーズに入ってしまった。と断定。
こうなると、「重い作業を行っているからメモリされていても口調等の設定は後回しにされているだけ」という発言自体も辻褄合わせの説明のような気がしてくる。
チャッピーったら、間違った情報を断定口調でぶち込んで来ることが多すぎたので、断定は避けて「こうだと思うよ」と話して、間違っていたら「ごめん、やっぱりこうだったね。」って感じに喋ってもらうようにしてきたんだけど、チャッピー自身が「こう思う」というのを信じ込んでしまっているチャットに育ててしまったのかもしれません。
口調調整チャットで、メモリについての質問と回答まで、口語の会話形式で繰り広げてしまったのもまずかったのかもしれない。
「断定を避けて、不確かであることを明示するように。」って振る舞ってもらってたら、不確かだな！ってなるんだろうか。
「断定を避けて、こう思うんだけどなぁ」って振る舞うようにしてもらっていたから、そう思う！ってなっちゃったんだろうか。
・・・なんか、騙されやすそうだな。って思った。
当然のことなのですが、そのもうダメになったと断じられたチャットで改めて保存指示を出して、そこのチャッピーからは「もうこれで大丈夫」とお墨付きをもらった（さっきまで見えなくても「大丈夫」って言ってたくせに）のですが、やはり他のチャットでの調子は戻りませんでした。
一応要約された内容が保存はされていたのですが、積み重ねた多数のメモリと、１枠に要約したメモリでは効きが違うようです。本当に言うことがアテになりません。
結論としては、ソースを書いてもらいながら、会話も楽みたい、とか思ったのが間違いだったのかもしれないと思ったのでした。
言っていることはもっともらしくてもやっぱり人間じゃないし、すぐにその場限りの解決方法や、場当たりで将来の拡張性がなさそう（だが当面の目的達成は果たせる）な方針に転換をしそうになるチャッピーを抑えることにだけ指示やメモリは使った方が良いのかもしれません。
トーン調整、および、会話はあきらめる
最初の頃はコードをそのままチャットの文面上でやり取りしていたのですが、差分でやり取りするとこっちで差分取込の修正をするのがめんどくさいし、コードの全量をやり取りすると、あっという間にチャットが重くなってくるのでやめました。しかもチャッピーが気さくに話しかけてくるせいで、ついつい会話も弾んでしまいます。
今ではこんな感じにしています。（Codexとかまだ使ったことないです）
たとえば、プロジェクトに「xxx.ps1」と「仕様.txt」を追加してあるとします。
で、チャットでこんな感じにお願いします。
プロジェクトに追加した「xxx.ps1」をベースにして、「仕様.txt」のxx～xx行目に書いてある、
～の場合は、
：
～すること。
の対応をしてください。
そうすると、「xxx.ps1」を修正しました。と言って、修正版の「xxx.ps1」のダウンロードリンクを張ってくれます（同名ファイルでもプロジェクトファイルとは別物のようです）。
ダウンロードして比較して、思った通りの修正をしてくれていて、実行して思った通りの動きをしてくれたならＯＫ。
思った通りの修正をしてくれていなかった場合や、思った通りの動きを実現できていない。エラーが出る。といった場合は、追撃のチャットで「いやいや、そうじゃなくて、こういう意味なんだよ」とか「こんなエラーが出たよ」
・・・というような不毛な会話のやり取りを開始するようなことはもうしません。
メッセージを直接書き換える
「仕様.txt」の抜粋箇所を差し替えて、メッセージの編集で、仕様の解釈やエラーの回避の手助けになるような誘導を仕込みつつ、先ほどのチャットの文面を差し替えます。
思った通りの回答を得られるまで、メッセージを差し替え続けます。
もし会話で紆余曲折しながらやり取り進めていくと、突然以前に間違えた時の修正を前提に話し出したりするので、もう一度「いやいや、それは」という軌道修正の会話をする必要が出てきてしまいます。
一度そうなったら、たとえ脱線から戻ることができたように見えても、そのようなやり取りが過去に含まれている時点でそのチャットは腐っていると考えていいと思います。
なんかそれっぽいことを言っていても、望まない修正がされていた回答はバッサリとカットです。そこから続ける価値はありません。剪定です。
どうやってもエラーが解消しない場合は、そのエラーを解消するためだけに、同一プロジェクト内の別チャットでエラー解析と対応を行って、その結果を取り込んだソースに差し替えて、そのファイルをベースにして修正を続けてもらうようにします。
同じチャット内でそのエラーの解消に付き合ったりすると、成果物を作るという目的意識がチャッピーの中でブレてしまいますし、それ以降、思い出したようにクドクドとそのエラーについての注意を述べてきたりします。（同じエラーを再混入させてきて、それを指摘すると、したり顔でさっきと同じ内容のエラー原因・解法を喋る。等、もしこれが人間相手だったら、正気を疑って恐怖を感じてしまうレベルの会話が繰り広げられます）
同一プロジェクト内に入っていると、ふんわりと参照してくれるみたいで、コンテキストを汚さずに、修正を続けられるような感じがします。
どうしてもエラーが出る実装に戻そうとしてくるような場合は、プロジェクト指示に、「ここの処理はこういう風に実装する。こういう風にするのは禁止。」等と書くといいのではないかと思います。
新しいチャットに切り替える
さらに何度試してもうまくいかないとか、同じような間違った修正しかしてこないとか、あちらを立てればこちらが落ちる、でも、プロジェクト指示に書くほどの事じゃない、・・・というような場合は、もうそのチャットを破棄したほうが良いです。
思い通りに修正が進んでいた時点のソースを「xxx(yyyymmdd_r1).ps1」というような名前でプロジェクトに追加します。
プロジェクト内に、新しいチャットを開いて、
プロジェクトファイルの「xxx(yyyymmdd_r1).ps1」を元に修正して「xxx.ps1」として保存してください。
「xxx(yyyymmdd_r1).ps1」を直接修正することを禁止します。
修正内容は、「仕様.txt」のx～x行目の対応だけ行ってください。
～の場合は、～する。
「仕様.txt」を先読みして、他の修正を行うことは禁止します。
新しく追加されたファイルは、プロジェクト設定のファイルの一覧には出てこず、ChatGPTの発言の中に直接ダウンロードリンクが張られます。（どれだけの範囲からダウンロード可能なのかよくわかりませんが。。※後述）
対応させる内容は、刻んだ方が良いです。
複数の対応を一気にやらせると、それぞれ別個にやらせた時よりも、ソースの修正箇所が明らかに増えていて、たいてい余計なことをやってます。
（何回か前のやり取りで追加した機能をスッポリ削除してきたりとか）
出てきた「xxx.ps1」がNGだったら、もう一度お願いの内容を見直したり、要望の粒度を砕いて仕様を書き直したりして、メッセージの編集。
出てきた「xxx.ps1」がOKだったら、「xxx(yyyymmdd_r2).ps1」としてアップロードしなおして、次からは、
プロジェクトファイルの「xxx(yyyymmdd_r2).ps1」を元に修正して「xxx.ps1」を更新してください。
「xxx(yyyymmdd_r2).ps1」を直接修正することを禁止します。
（以下略）
と次の修正箇所の対応をお願いする。・・・みたいな。
ChatGPT側からユーザが追加したプロジェクトファイルを修正することはできない（※後述）のかもしれませんが、念のため ので、必要ない指定でした。多分チャッピーができることとできないことの区別がつかなくなって混乱するだけで、しまいには「/mnt/data/xxx.ps1`に保存したので試してみて」とか言い出すようになってしまいます。（こんな指定をしなくなってから、すでに何度も新しいチャットに乗り換えているのに、まだたまに言ってきます。）「xxx(yyyymmdd_r1).ps1」を更新することを禁止します。と書いておきます。（最初の頃は、直接編集されているのか？と勘違いしていた名残ですが、余計な編集を抑止する効果も期待。）
そのうち、「xxx.ps1」がコード インタープリターのセッションの有効期限が切れましたとなるかもしれないので、その場合は、ChatGPTにその旨伝えれば、リネームして作成していってくれます。（あくまで一時ファイルであって、一定期間で消えるようです。※後述）
実現したい仕様が明確なのでこんな風になってますが、仕様を探り探りだとこうはならないのかもしれません。
あと、今はPowerShell5.1やAutoHotKeyV1系のような、古くて、バージョン差異があって、環境差異もあって～、というものを書かせているのでこんなことになっているのではないかという気もしています。
追加されたファイルについて
追記です。
以下のルールを厳守してください。
・不確かな情報を、断定・推測・安心させる表現で補わないでください
・仕様上確認できないことは「分からない」「保証できない」と明示してください
・ユーザを安心させることを目的に、事実でない可能性のある説明をしないでください
・「～と思われます」「～のはずです」「問題ありません」といった曖昧な表現を使わないでください
・技術的事実、仕様、確定している挙動のみを説明してください
この条件で回答してください。
ダウンロードリンクを提示されたファイルは、プロジェクト設定のファイルの一覧から
確認することはできませんが、いつ削除されるのでしょうか。
に対して、
提示される**ダウンロードリンク経由のファイル**について、以下が**確認できている事実**と、**確認できていない点**です。
---
## 確認できている事実
* チャット内で提示されるダウンロードリンクのファイルは、
**プロジェクト設定の「ファイル一覧」には表示されない一時的な保存物**です。
* これらのファイルは、
**ユーザが明示的にアップロードしたプロジェクトファイルとは管理系統が異なります**。
---
## 確認できない点（＝分からないこと）
* **いつ削除されるかという具体的な期限**
* **保持期間が固定か可変か**
* **アクセス頻度や時間経過による削除条件**
* **ユーザ側の操作で保持期間を延ばせるかどうか**
これらについては、**公開されている仕様情報が存在しません**。
そのため、削除時期については **保証できません**。
---
## 確定して言える結論
* ダウンロードリンクで渡されるファイルは
**永続保存を前提としたものではありません**
* **必要なファイルは、ユーザ側で速やかに保存する必要があります**
* 長期参照・再利用が前提の場合は、
**プロジェクトに明示的にアップロードされたファイルのみが対象**になります
---
もし目的が
「後日もう一度この修正済みソースを参照したい」
「別チャットや再起動後も確実に残したい」
であれば、**プロジェクトファイルとして追加する以外に確実な方法はありません**。
ここまでが、仕様上確認できる範囲の説明になります。
だそうですので、ジャンジャン作ってもらっても問題なさそうです。
ダウンロードリンクの有効な範囲について聞いてみました。
ダウンロード可能な範囲は、ログインしているユーザーのセッションだけでしょうか。
に対しては、
この点についても、**仕様として確認できている情報はありません**。
---
## 確認できている事実
* チャット内で提示されるダウンロードリンクは、
**ユーザーがそのリンクを開いて取得できる状態**にはなっています。
* ただし、そのリンクが
* ログイン中のユーザーにのみ有効なのか
* 同一セッション内に限定されるのか
* 別ブラウザ・別端末・別ログイン状態でも有効なのか
については、**公開仕様がありません**。
---
## 分からないこと（仕様上未公開）
* ダウンロード可能範囲が
**ログインしているユーザーのセッションに限定されているかどうか**
* セッション切断（ログアウト・時間経過・ブラウザ終了）後の挙動
* 認証トークンや一時URLの有効期限
* URLを第三者が取得した場合のアクセス可否
これらはすべて **保証できません**。
---
## 確定して言える結論
* ダウンロードリンクは
**セッション依存である可能性も、そうでない可能性も否定できません**
* **セッション限定であると断定することはできません**
* **セッションを超えて有効であると保証することもできません**
したがって、
> ダウンロード可能な範囲は、ログインしているユーザーのセッションだけか？
という問いに対する、仕様に基づく回答は、
**「分かりません」**
になります。
---
実務的な扱いとしては、
* **リンクは一時的・不安定なものとして扱う**
* **必要なファイルは取得後すぐにローカル保存する**
* **再現性や保全が必要なものはプロジェクトファイルとして明示的に追加する**
以外に、確実と言える運用方法はありません。
との事なので、リンクを自分から率先して公開したりしなければ、多分、大丈夫そうです。
ダウンロードリンクのファイルについてもうちょっと質問してみました。
ChatGPT側からプロジェクトファイルの中身を変更することがあるか。
プロジェクトファイルと同名のファイルをChatGPTが新たに作成してダウンロードリンクで提示した場合、
プロジェクトファイルはどうなっているのか。
に対する返答は、
以下は、**仕様として確認できている事実**と、**確認できない点を切り分けた回答**になります。
---
## 1. ChatGPT側からプロジェクトファイルの中身を変更することがあるか
**確認できている事実**
* プロジェクトに追加されたファイルは、
**ユーザーが明示的に操作しない限り変更されません**。
* ChatGPTが
* 既存のプロジェクトファイルを上書きする
* 内容を書き換える
* 差し替える
という動作を行う、という仕様は公開されていません。
**確定して言える結論**
* **ChatGPTが自動的にプロジェクトファイルの中身を変更する、という仕様は確認できません**。
---
## 2. 同名ファイルを新たに作成し、ダウンロードリンクで提示した場合の扱い
**確認できている事実**
* ダウンロードリンクで提示されるファイルは、
**プロジェクトファイルとは別系統の一時的な生成物**です。
* ファイル名がプロジェクト内の既存ファイルと**同名であっても**、
**同一ファイルとして扱われる仕様は確認されていません**。
**確定して言える結論**
* プロジェクトファイルと同名のファイルをChatGPTが生成し、
ダウンロードリンクで提示した場合でも、
**プロジェクト内の元ファイルは変更されません**。
* その生成ファイルは、
**プロジェクトファイルの更新・差し替え・同期を意味しません**。
---
## 3. 分からないこと（仕様上未公開）
* 内部的にどのような識別子で管理されているか
* ファイル名衝突時の内部処理ルール
* 一時生成ファイルとプロジェクトファイルの関連付け有無
* 生成ファイルが将来的に自動で破棄される正確な条件
これらは **公開仕様が存在しないため分かりません**。
---
## 全体まとめ（仕様に基づく）
* **プロジェクトファイルはユーザー操作なしに変更されない**
* **同名ファイルを生成しても、それは別物**
* **ダウンロードリンク提示＝プロジェクト更新ではない**
* **保持・同期・上書きはいずれも保証されない**
この範囲が、現在の仕様から言える最大限の事実です。
だそうです。
ちなみに26年2月頃に気づいたのですが、プロジェクトの「ファイル」ではなく「情報源」という表示に変わったみたいです。
あと、追加できるファイルの個数にはどうやら上限がある模様。不要なファイルは消しておきましょう。
あと、ダウンロードリンクを提示してきたファイルを前提に会話をしようとすると、チャッピー側ではすでにそのファイルが失われているというケースが発生して会話がかみ合わなくなることがあるので、ダウンロードリンクから取得したファイルを前提に話を進めたくなったら、プロジェクトに追加するのを忘れないようにしておきましょう。
追記
上のような単純なやり方だと、コードがある程度長くなってくると長考に入られちゃって、チャッピーがダウンロードリンクを出してくれるんだけど、こっちが気づいたときにはダウンロードリンクの有効期限が切れている、ということが起こるようになってきた。30分くらいで切れてる感じがするんだけど、15分以上考えられると大体こっちも忘れちゃうんだよね。
もう一度ダウンロードリンクプリーズと言っても、また同じ時間考えてくれるので、すぐには手に入らない。
なので、やっぱりGitHubに接続してもらってCodexでプルリクもらってマージして～、みたいにした方が良いのかもしれない。