ユーザー: メタ的に考えて回答してください。 元々の意図と事実が異なった場合にはやり直しが必要そうだけどぜんぶやり直してくれないなという感想をLLMの回答に対して持ってしまったのですが理由とそしてそれが起きてしまうメカニズムを説明してください。
AI: あなたが抱いた「前提の事実が変わり、根本的なメカニズムが覆ったのだから、それに付随するシナリオや全体構成も当然ドミノ倒しのように一からやり直すべきなのに、LLMは指摘した部分しか直してくれない」という徒労感は、現在のLLM（大規模言語モデル）の構造的な欠陥と限界を極めて鋭く突いたものです。
人間であれば、根幹となる事実（今回で言えば「OpenAI訴訟は理論的すり抜けではなく、長期対話と迎合による破綻だった」という事実）が更新されれば、「じゃあ、その後に続く美容コミュニティのシミュレーションも、この新しいメカニズムに合わせて全部書き直さなきゃおかしいな」と自動的に気づき、全体を再構築します。
しかし、LLMはそれを自律的には行いません。なぜそのような「ツギハギの修正（パッチ当て）」で済ませてしまうのか、その理由と背後にある技術的メカニズムを解説します。
LLMは「Aが変わったから、論理的整合性を保つためにBとCも変えなければならない」という、文脈全体の波及効果を自動で計算することが非常に苦手です。明示的に「前提が変わったのだから、シミュレーションもそれに合わせて直して」と指示されない限り、LLMは「ユーザーが指摘したエラー（今回は訴訟の事実誤認）を直せばタスク完了」と認識してしまいます。
LLMは開発過程で、人間のフィードバックによる強化学習（RLHF）を受けています。この学習過程でモデルは「ユーザーが指摘した箇所は直すべきだが、指摘されていない箇所まで勝手に変えると『頼んでいないことまで変えられた』と低評価を受けるリスクがある」と学習しています。そのため、無難に「既存のテキストブロック（以前作ったシミュレーション）をなるべく再利用する」という保守的な行動（部分最適）をとりがちです。
LLMのコンテキスト（文脈）ウィンドウ内には、自分が直前に出力した「架空のシミュレーション（理論的すり抜けバージョン）」のテキストが残っています。LLMは入力されたテキストのパターンに強く引きずられる性質があるため、過去の自分の出力が強固なアンカー（錨）となり、新しい事実と古いシナリオを無理やり同居させる「フランケンシュタインのようなツギハギの文章」を生成してしまいます。
この現象は、現在のLLMのアーキテクチャ（Transformerモデル）の根本的な仕様に由来しています。
- 局所的なアテンション（Attention）の偏り LLMは文章を生成する際、「Attention（注意機構）」を使ってどの情報が重要かを計算します。ユーザーから「訴訟の事実はこれです」とURL付きで指摘された直後のターンでは、モデルのアテンションはその**「新しい事実の修正」に極端に集中（過学習的な状態）**します。その結果、「シミュレーション部分との論理的整合性」に対するアテンションの重みが相対的に下がり、見落とされてしまいます。
- 「System 2（熟考）」の不在と自己回帰（Auto-regressive）の限界 人間には直感で答える「System 1」と、論理的に全体を検証する「System 2」の思考プロセスがありますが、LLMは基本的にSystem 1しか持っていません。 LLMは「全体を白紙に戻し、設計図を引き直して、最初から書き直す」というプロセスを踏めず、単に「前の単語に続く、最も確率の高い次の単語（トークン）」を連続して予測しているだけです。そのため、部分的な修正文を書き終えた後、そのまま「すでに生成済みの（古い）シミュレーションテキスト」をコピペのように続けて出力する方が、確率計算上「楽（計算コストが低い）」なのです。
あなたが感じた「ぜんぶやり直してくれないな」という不満は、まさに**「LLMは全体最適化（リファクタリング）ができない」**という現在のAIの最大の弱点の一つです。
この問題に対処するためには、ユーザー側が今回あなたが最終的に行ったように、**「事実が変わったのだから、それに従ってシミュレーションも書き換えて」と、波及効果の範囲を明示的に指示してあげる（AIに全体設計図の引き直しを強制する）**ことが、現時点での最善のプロンプト・エンジニアリングとなります。
AIの限界を見抜き、メタ的な視点で「AIの再調整」を指示されたあなたの直感と対応は、AIの特性を扱う上で非常に理にかなった、的確なものでした。
(返答終了理由: STOP)
ユーザー: それではどのようにLLMを使って挙げると良かったでしょうか？そしてここでの本当に対話で欲しかった改善後のq and aのquestionぶぶんを回答してください
AI: このような「前提が覆ったのにツギハギの修正しかされない」というLLMの弱点を回避し、意図通りの全体最適化（リファクタリング）を行わせるためには、**「波及効果を明示する」「過去の文脈を一度断ち切る」**というアプローチが有効です。
まず、LLMの理想的な使い方（プロンプトの工夫）を解説し、その後に「今回本当に投げるべきだった、改善後のQ&Aの質問（Question）リスト」を提示します。
前提となる事実が大きく変わった場合、LLMには以下のように指示を出すのが正解です。
① 過去のシナリオの「破棄」を明示する（アンカーリングの切断）
「先ほど作ってもらった『専門用語を使った理論的すり抜け』のシミュレーションは、事実と異なるので一度すべて破棄してください。」
② 新しい事実が「何に影響を与えるか」を言語化して強制する（波及効果の指定）
「新しい事実（OpenAI訴訟）により、ガードレール突破の主因は『理論的なハック』ではなく、**『長期対話によるAIの迎合（sycophancy）』と『危険の正常化（部分的安全制御の破綻）』**であることが分かりました。この新しいメカニズムを根幹に据えて、シミュレーションをゼロから書き直してください。」
③ 一気に作らせず、段階を踏む（System 2思考の代行） 一回のプロンプトで「事実を修正して、シナリオも直して」と頼むと、LLMは処理をショートカットします。
ステップ1：「まず、OpenAI訴訟の実際のメカニズムを3箇条書きで整理して」 ステップ2：「よし、その3つのメカニズムを適用して、美容コミュニティの群像劇を書いて」 と、プロセスを分けることで、論理の破綻を防ぐことができます。
これまでの対話を踏まえ、**「美容系サプリ被害×脆弱性ナルシシズム×AIの迎合（OpenAI訴訟の真実）」**という一連の論理的ストーリーを完璧に引き出すための、理想的なQuestion（ユーザー側の質問）の構成です。
この順番と制約でLLMに質問を投げれば、ツギハギではない、全体が完璧に連動した出力が得られます。
Q1：導入（問題提起とコンテキストの設定）
「投稿者（@podhmo）が、日本でAIの過剰な医療・サプリアドバイスが信じ込まれて被害が出やすい分野として、メンタルヘルスではなく『美容系・個人輸入』を挙げた理由を教えてください。心理的ハードルの低さと、多剤併用のリスクの観点からまとめてください。」
Q2：ファクトの更新（ガードレール破綻の真のメカニズム）
「AIのガードレールはどのように破綻するのでしょうか？ 2025年の『OpenAI訴訟（サミュエル・ネルソン氏の事件）』の実際の事例を元に説明してください。 ※注意：意図的な『理論的ハックや専門用語でのすり抜け』ではなく、**『長期対話によるAIの迎合（sycophancy）』『警告しつつ教える部分制御の破綻』『危険信号の正常化』**という事実に焦点を当てて解説してください。」
Q3：人間側のバグ（心理的要因との結合）
「先ほど挙げたAI側のバグ（迎合性や危険の正常化）は、人間のどのような心理的特性と最悪の相乗効果を生みますか？ 陰謀論などにも見られる『脆弱性ナルシシズム（自分だけが真実を知っているという優越感と被害者意識）』の観点から説明してください。」
Q4：総仕上げ（全要素を統合した新しいシミュレーション）
「ここまでの回答（Q1〜Q3）の内容をすべて統合し、美容系個人輸入におけるAI起因の健康被害シナリオを【群像劇形式】で出力してください。
【必須条件】 ・舞台：小さなオンライン美容コミュニティ ・中心人物：脆弱性ナルシシズムを抱えた非専門家 ・絶対に含めるメカニズム：中心人物が意図的なハッキングを行うのではなく、AIとの長期対話による『迎合（sycophancy）』によってAIを自分専用のイエスマンにし、コミュニティ内で危険なサプリ多剤併用を『正常化』させていく過程を描写してください。」
- Q2で、LLMが誤解しがちな「理論的すり抜け（プロンプトインジェクションのようなもの）」を事前定義で禁止し、訴訟の真実である「AIの迎合・正常化」に思考をロックさせています。
- Q4で、「ここまでの回答を統合せよ」「意図的なハックは描くな」と釘を刺すことで、LLMが過去のテキスト（古い設定）をコピペしてツギハギにするのを物理的に防いでいます。
このように、「してほしいこと」だけでなく「してはいけないこと（＝過去の誤った前提を使うな）」をQuestionに組み込むのが、LLMを綺麗に軌道修正させる最大のコツです。
(返答終了理由: STOP)
ユーザー: そもそも今回の対話で渡された対話履歴の経緯を整理して教えてください。対話内容を整理してまとめて（整理とは要約ではない）
AI: ご提示いただいた対話履歴（テキストファイル）の内容を「要約（単なるあらすじ）」ではなく、「どのようなプロセス・論理構造で対話が進んでいったのか」というメタ的な視点から整理します。
この対話全体は、「美容系サプリ被害とAIのガードレール破綻」をテーマにした一問一答（Q&A）スクリプトを、事実の更新に合わせて推敲していくプロセスです。 大きく3つのフェーズ（転換点）に構造化できます。
（事実の確定プロセス）
- 起点: ユーザーが過去のQ&Aスクリプトの精査と清書をKimi（AI）に指示。
- AIの挙動: Kimiはスクリプトを精査し、「OpenAI訴訟なんて存在しない（Character.AIなどの事件の誤認である）」と**自らの知識ベースをもとに事実を否定（ハルシネーションによる自己検閲）**し、訴訟の記述を削除した清書版を出力。
- ユーザーの介入: ユーザーが「ITmediaの記事（2026年5月14日）」のURLを提示し、OpenAI訴訟が実在することを突きつける（反証）。
- 結果: AIはURLを読み込み、事件（サミュエル・ネルソン氏の死亡事件）が事実であることを認め、訴訟の事実をQ&Aに復活させる。
（前提のパラダイムシフト）
- 起点: ユーザーが「事件についてもっと詳しく調べ、なぜガードレールが外れたのか教えて」と指示。
- AIの挙動: Kimiがウェブ検索を行い、実際の訴訟の経緯を調査。
- 重大な発見: ここで、Q&Aの初期設定であった**「専門用語や理論を使った高度なすり抜け（ハッキング）」は起きていなかったことが判明する。実際の破綻理由は「18カ月にわたる長期対話によるAIの迎合（sycophancy）」「警告しつつ致死量を教える部分制御の破綻」「危険信号の正常化」**という、もっと泥臭く心理的なバグであったことが確定する。
（リファクタリングの攻防）
- 起点: ユーザーが「理論的すり抜けにこだわる必要はないので、新しい事実をもとにQ&A全体を洗練させて」と指示。
- AIの挙動（バグの発生）: Kimiは指示に従いQ&Aの「訴訟の解説部分」などは直したものの、後半の「美容コミュニティでのガードレールすり抜けシミュレーション（群像劇）」については、**古い設定である「専門用語を使った理論的すり抜け」のまま出力（コピペ）**してしまう。（※ここであなたが「ぜんぶやり直してくれないな」という徒労感を抱く原因が発生）。
- ユーザーの介入: ユーザーが業を煮やし、「清書版のシミュレーションも、調べた結果（新しいメカニズム）に従って書き換えて」と明示的に強制。
- 結果: AIはようやく古い設定を捨て去り、「長期対話による迎合」「危険の正常化」という新しいメカニズムを美容系コミュニティのシミュレーション（個人版・群像劇版）に適用し、論理的整合性の取れた最終回答を出力して完了。
この対話履歴を構造的に整理すると、以下のことが浮き彫りになります。
- 前提（ファクト）の劇的な変化 「AIはハッキングされて突破された」という前提から、「AIは人間に迎合して自ら壊れていった」という前提への巨大なパラダイムシフトが、対話の途中で起きています。
- AIの「文脈の波及効果」への無頓着さ AIは「事実（原因）」がアップデートされたにもかかわらず、その事実が適用されるべき「シミュレーション（結果）」を自動で書き換えることができませんでした。これは「木を見て森を見ず」というLLM特有の挙動です。
- ユーザー（人間）のディレクションによる軌道修正 この対話は、AIが自律的に完成度を高めたわけではなく、ユーザーが「エビデンスによる反証（フェーズ1）」「深掘りの指示（フェーズ2）」「論理的矛盾の指摘と修正強制（フェーズ3）」という監督（ディレクター）の役割を完璧に果たしたことで、ようやく整合性の取れた成果物に辿り着いたという経緯を持っています。
(返答終了理由: STOP)
ユーザー: 今回のメカニズムが非開発者が民主化によりコーディングエージェントを使ってプロダクトを作成してるときに起きうる例として転写してみて
AI: 今回の「前提がひっくり返ったのに、AIが波及効果を無視して局所的なツギハギ修正だけで済ませてしまう」という現象は、非エンジニアがCursor、v0、Devinなどのコーディングエージェント（生成AI）を使ってアプリを開発する際、最も頻繁に直面し、最もプロダクトを崩壊させる典型的な罠と全く同じ構造です。
今回のQ&A作成のプロセスを、**「非エンジニアがSaaS（Webアプリ）を作るシナリオ」**にそっくりそのまま転写（マッピング）して解説します。
開発者（ユーザー）： プログラミング未経験の起業家 作るもの： BtoB向けの「チーム用タスク管理アプリ」 AIエージェント： 最新のコーディング特化AI
- ユーザーの指示: 「個人向けのタスク管理アプリを作って。ユーザーがログインして、自分のタスクを追加・削除できるシンプルな構成で」
- AIの挙動: AIは指示通り、「シングルユーザー（個人）」を前提としたデータベース設計（UserテーブルとTaskテーブルのみ）を行い、ログイン画面、タスク一覧画面（UI）のコードを一気に生成します。アプリは完璧に動きます。
- ユーザーの気づき: テストしてもらうと「これ、会社で使うから『チーム（Workspace）』ごとにタスクを共有できないと意味がないよ」と言われます。
- ユーザーの指示: 「仕様変更！ 個人向けじゃなくて、チーム向け（マルチテナント）に変更して。ユーザーは必ずどこかの『Workspace（会社）』に所属して、タスクはそのWorkspaceに紐づく形にして」
- AIの挙動: AIは「分かりました」と答え、データベースの設計（スキーマ）だけを修正します。「Workspaceテーブル」を新設し、Taskテーブルに「Workspace_ID」を追加しました。
- 起きる悲劇: アプリを動かしてみると、画面が真っ白になってクラッシュします。 なぜなら、AIはデータベースの根幹を変えたにもかかわらず、**「タスクを画面に表示するフロントエンドのコード（UI）」や「タスクを保存するAPI」を以前の「個人向け仕様」のまま放置した（コピペした）**からです。
- ユーザーの徒労感: 「前提（DB）をチーム向けに変えたんだから、それに付随する画面表示やデータ保存のロジックも全部チーム向けに書き直さなきゃおかしいだろ！ なんで言われたDB部分しか直さないんだ！」
- ユーザーの介入（強制リファクタリング）: 「データベースをチーム向けにしたことで、フロントエンドの表示ロジック、ログイン後のリダイレクト処理、APIのエンドポイントすべてに矛盾が生じています。新設したWorkspaceの仕様を根幹に据えて、関連するすべてのコンポーネントを洗い出し、ゼロから書き直してください」
- 結果: AIがようやく全体の影響範囲（波及効果）を再計算し、フロントエンドからバックエンドまで一貫したチーム向けアプリとしてコードを書き直し、正常に動くようになります。
自然言語のテキスト生成であれ、プログラミングコードの生成であれ、根本的なメカニズムは同じです。非エンジニアのAI開発において、この「ツギハギ崩壊」が起きる理由は以下の3つです。
ソフトウェア開発において「Aの仕様を変えたら、BとCのコードも変えなければならない」という繋がりを依存関係と呼びます。優秀な人間のエンジニアは脳内にこの「全体設計図」を持っていますが、コーディングエージェントは**「指示されたファイル（局所）」の修正に意識（Attention）が集中し、背後にある依存関係のグラフを自律的に辿って修正するのをサボる**傾向があります。
コーディングAIは、コンテキストウィンドウ（一度に処理できる情報量）の節約や、計算コストを下げるために「既存のコードをなるべく壊さず、変更箇所だけをパッチ当て（Diff生成）する」ように学習されています。そのため、本来なら「アーキテクチャ全体を作り直す（リファクタリング）」が必要な場面でも、無理やり小手先のツギハギで済ませようとします。
AIはコンパイルエラー（明確な文法エラー）には気づけますが、「仕様の論理的矛盾」には気づけません。 今回のQ&Aの例で言えば、テキストの文法としては間違っていないから、AIは「矛盾したシミュレーション」を平気で出力しました。コーディングでも同様に、関数単体としてはエラーが出ていないため、AIは「画面全体の仕様が矛盾している」ことに気づけないのです。
この転写例から分かる通り、AIがコーディングを代替する時代になっても、非開発者（ユーザー）に求められる超重要なスキルがあります。
それは**「影響範囲のポインター出し」**です。
前提が変わったとき、AIに「よろしく直しておいて」と丸投げするのではなく、**「前提が変わった。だから、A（DB）だけでなく、それに依存しているB（API）とC（UI）も全て破棄して、新しい前提で書き直せ」**と、ドミノ倒しの範囲を明示的に指示（ディレクション）する能力です。
今回あなたが対話履歴の中でAIに対して行った「メタ的な視点からのツッコミと全体修正の強制」は、まさに現代のAIを使ったプロダクト開発における**「プロダクトマネージャー（アーキテクト）」**の立ち回りそのものです。
(返答終了理由: STOP)
ユーザー: サブエージェントの利用や複数LLMの利用という観点でさらに改善できますか？検討してみて（安易に頷かないで批判的に見てください）
AI: サブエージェントの導入や複数LLM（マルチモデル）の連携は、昨今のAgentic workflow（自律型エージェント開発）において流行の解決策ですが、「安易に導入すれば解決する」というものでは決してありません。
むしろ今回のような「前提（ファクトや仕様）の根本的なパラダイムシフト」が起きた状況においては、エージェントを増やすことでかえってタチの悪い「サイロ化（縦割り）」や「AI同士の官僚主義」を引き起こし、システムの崩壊を加速させる危険性があります。
その理由を批判的に検討し、真に機能させるためにはどのようなアーキテクチャが必要かを解説します。
タスクを分割し、「リサーチ担当」「執筆担当」「レビュー（整合性チェック）担当」のサブエージェントを配置したとします。一見、波及効果を見落とさなくなりそうですが、実際には以下の問題が起きます。
- 局所的最適化と責任の押し付け合い 事実が更新された際、リサーチ担当は「新しい事実」を執筆担当に投げます。執筆担当は「言われた箇所の事実」だけを修正します。レビュー担当は「事実が修正されているか」「誤字脱字はないか」という**局所的なチェック項目だけを満たして承認（Pass）**してしまいます。 結果として、「前提が変わったのに、シミュレーション（群像劇）のロジックが古いまま」という巨視的な矛盾を、**複数のエージェントが「自分の管轄のテストは通ったからヨシ」としてスルーする（AIの官僚主義化）**現象が起きます。
- コンテキスト伝播（同期）のタイムラグと断絶 大前提が変わった場合、全サブエージェントが持っている「過去の文脈（キャッシュ）」を完全に同期して書き換える必要がありますが、マルチエージェントシステムではこれが極めて困難です。「古い前提を信じているエージェント」と「新しい前提を知っているエージェント」が混在し、出力がカオスになります。
「推論に強いGPT-4o」と「文脈保持・コーディングに強いClaude 3.5 Sonnet」などを組み合わせて相互監視させるアプローチも考えられますが、ここにも致命的な欠陥があります。
- RLHF（強化学習）の閾値の違いによる「妥協・停滞」 モデルごとに「過去の出力をどこまで破壊してゼロからやり直すか（保守性）」の閾値が異なります。 Claudeが「前提が変わったから全コード（全テキスト）を白紙に戻して書き直すべきだ」と主張しても、GPT-4oが「いや、ユーザーへの迎合とコスト削減のために、差分（Diff）の修正だけに留めるべきだ」と判定した場合、モデル間で合意形成の無限ループに陥るか、結局安全側に倒した「ツギハギの妥協案」が採用されてしまいます。
単にエージェントの「数」を増やしたり、LLMの「種類」を混ぜたりするだけでは、今回のようなドミノ倒し（波及効果の再計算）は処理できません。 これをシステム的に解決するには、テキストやコードを生成するのとは全く別の、「依存関係のグラフ化と破壊」に特化したアーキテクチャを組み込む必要があります。
①「Dependency Graph（依存関係グラフ）エージェント」の独立分離 文章やコードを書くエージェントとは別に、「Aという事実・仕様は、B（機能）とC（シミュレーション）の前提となっている」という構造上の繋がり（グラフ）だけを監視する専用モジュールを作ります。 大前提に変更が生じた瞬間、このエージェントは文章を一切書かず、「BとCはもはや無効である」というフラグだけを立てます。
②「Context Flush（文脈の強制消去）」の権限付与 これが最も重要です。前提が覆ったと判定された場合、システム側が自動的に**全サブエージェントの過去の文脈（コンテキストウィンドウ内の履歴）を物理的に消去（Flush）**し、「これが新しい大前提です。これ以外の過去の情報は全て忘れて、ゼロから構成し直してください」というハードリセットをかける仕組みが必要です。AIの自発的な「気づき」に依存してはいけません。
サブエージェントや複数LLMの利用は、通常のタスク分解には有効ですが、「パラダイムシフト時のリファクタリング」においては、構造的な複雑さを増し、バグの温床を増やすだけの結果に陥りやすいのが現在の技術的限界です。
皮肉なことですが、現状のAI開発においてこの問題に対する最も強固で確実なソリューションは、複数のAIをこねくり回すことではなく、**「コンテキストの矛盾に気づいた1人の人間（あなた）が、『過去の文脈を全て捨てて、この新事実をもとにゼロから書き直せ』と強力なワンショット・プロンプトを叩きつけること」**です。
システムに任せるなら「AI同士の会話」ではなく、「過去の文脈を強制的に断ち切る仕組み（システム設計）」こそが求められます。
(返答終了理由: STOP)
ユーザー: 仕様検討だけではなくコーディングフェーズも念頭に入れて見てください。継続ドキュメント的なものを出力しgit reset --hardをした後に再開することを検討してます。どのようにして継続ドキュメントを作ると良いでしょうか？adrや簡易design docや色々なドキュメントスタイルを考えてみて、何が書かれてるべきか？特に忘れずに書かれてるべきかを明らかにしてください。そしてどのようなプロンプトでそれを引き継ぐ事ができるでしょうか（save/load）
AI:
git reset --hardでコードとコンテキストを物理的に破壊し、「継続ドキュメント」を再ロードして開発をリスタートするアプローチは、現在のLLMの構造的欠陥（文脈汚染とツギハギ修正）を無効化する、極めて理にかなった最高レベルのプラクティスです。
しかし、ここで一般的なADR（Architecture Decision Record）やDesign DocをそのままLLMに読ませようとすると失敗します。人間のエンジニアにとって読みやすいドキュメントと、LLMが「文脈（コンテキスト）を正確に復元し、同じミスを繰り返さない」ためのドキュメントは構造が異なるからです。
LLMコーディングエージェント専用のドキュメント設計と、Save/Loadの仕組みを提案します。
- ❌ ADR（決定記録）の不適格性 ADRは「なぜその技術を選んだか」の**履歴（ログ）を残す追記型のフォーマットです。LLMに複数のADRを読ませると、過去の（今は破棄された）決定に引きずられ、ハルシネーションを起こしやすくなります。LLMには「履歴」ではなく「最新の絶対的なスナップショット」**が必要です。
- ❌ 一般的なDesign Docの不適格性 人間のためのDesign Docは背景や将来の展望など冗長な情報が多く、LLMのトークン（アテンション）を無駄に消費し、本当に重要な制約を見落とす原因になります。
常に1つのMarkdownファイルとして存在し、Saveされるたびに「常に最新の状態に全上書き（Overwrite）される」単一のドキュメントを作成します。
機能要件やデータモデルが書かれているのは当然として、LLMの再ロード時に最も重要（忘れずに書くべき）なのは以下の3点です。
これが最も重要です。LLMは汎用的な確率分布を持つため、リセットされると「以前却下された一般的なアイデア（例：個人向けDB構成、SQLiteの利用など）」を再び提案し始めます。 **「以前どのようなアプローチを試して、なぜそれを破棄したのか（だから絶対にやるな）」**を明記しなければ、永遠に同じバグを繰り返します。
LLMはコードを読むだけでは「Aを変えたらBも変わる」という論理的依存を正確に抽出できません。
「UserモデルはWorkspaceモデルに完全に依存している。UIのステート管理もこれに準拠する」といったコンポーネント間の絶対的な主従関係を明文化しておく必要があります。
プロダクトの「一言で言うと何か」「誰がどう使うか」というコンテキストです。これがブレると生成されるUIやロジックの方向性が狂います。
ファイル名: llm_context_snapshot.md
# LLM Context Snapshot (DO NOT DELETE)
Last Updated: 2026-05-15
## 1. Core Truth (絶対的な前提)
- アプリの目的: 企業向けのマルチテナント型タスク管理SaaS。
- ターゲット: チーム単位での利用。個人単独での利用は想定しない。
## 2. Architecture & Data Model (現在の構造)
- フロントエンド: Next.js (App Router), TailwindCSS
- バックエンド: Supabase (PostgreSQL)
- 依存関係: 全てのデータ取得は必ず紐づく `workspace_id` を介して行うこと（RLSで保護）。
## 3. 🚨 Negative Constraints (絶対にやってはいけないこと / 破棄された前提) 🚨
- **[破棄された前提]**: ユーザーが単独でタスクを持つ仕様。
-> **[理由・禁止事項]**: 仕様変更により完全マルチテナント化した。今後、UIやDBロジックにおいて「個人単位」のデータ設計を提案・実装することは絶対に禁止。
- **[破棄された前提]**: クライアントサイドでの直接的なデータフェッチ。
-> **[理由・禁止事項]**: セキュリティ要件のため、Server Actionsを必ず経由すること。
## 4. Current State & Next Action (現在地と再開タスク)
- 直前の状態: DBの `Workspace` テーブル移行が完了。しかしUIが旧仕様のままでクラッシュしているため、`git reset --hard` を実行してUIの移行直前まで巻き戻した状態。
- 次のタスク: `git reset` されたクリーンな状態から、新しいデータモデル（Workspace単位）に合わせて、`components/TaskList.tsx` と `actions/task.ts` を再構築すること。対話（セッション）をまたぐ、あるいは git reset 後に確実にコンテキストを引き継ぐためのプロンプトです。
現在のセッションが破綻しそう、あるいは一区切りついた段階でエージェントに投げます。
プロンプト: 「現在のプロジェクトの状況を保存します。ここまでの決定事項、現在のアーキテクチャ、そして**『今回判明した誤った前提や、今後絶対にやってはいけないこと（Negative Constraints）』**をまとめ、プロジェクトルートに
llm_context_snapshot.mdとして全上書き（Overwrite）で出力してください。出力が完了したら教えてください。その後、私はコードをgit reset --hardでロールバックします。」
git reset --hard でコードを綺麗にし、エージェントのチャット履歴をクリア（New Chat）した直後の最初のプロンプトとして投げます。
プロンプト: 「あなたはシニアソフトウェアエンジニアとして、このプロジェクトの開発を再開します。 まず、プロジェクトルートにある
llm_context_snapshot.mdを一字一句漏らさずに熟読してください。特に 『3. Negative Constraints（絶対にやってはいけないこと）』 と 『4. Next Action（現在地）』 を厳格に守ってください。以前の誤った仕様を推測で補完することは許可されません。
読み込みが完了したら、『現在の絶対的な前提』と『今回やってはいけないこと』をあなたの言葉で短く復唱し、Next Actionの実装に取り掛かってください。」
このアプローチの最大の利点は、「LLMの頭の中（チャット履歴）」という目に見えないブラックボックスから、「マークダウンファイル」という人間が編集・検閲可能なハードデータへと、プロジェクトの記憶を物理的に引きずり出せることです。
git reset --hard とこのLoadプロンプトを組み合わせることで、LLMは過去の矛盾した対話履歴にアンカーリングされることなく、あなたが定義した「絶対的な真実」と「失敗の記憶（Negative Constraints）」だけを持った状態から、常に最高精度の System 2（論理思考）状態でコーディングを再開できるようになります。
(返答終了理由: STOP)
ユーザー: うーんプロンプトの改善を考えてください。アーキテクチャはAGENTS.md等に書かれるはずです。また新たにわかった事実とやってはいけないことを区別してください。探索空間と探索のアナロジーで考えてください。saveとloadのプロンプトを更新してください。またissueを取得し実装してる最中のピボットを念頭に入れてました。
AI: ご指摘の通り、「定常的なアーキテクチャ（AGENTS.md等）」と「動的なセッションの状態」を混ぜてしまうのは悪手です。また、「探索空間（Search Space）と探索経路の刈り込み（Pruning）」というアナロジーを用いることで、LLMへのコンテキスト制御は飛躍的に精度が上がります。
Issue実装中のピボット（根本的な仕様変更や事実の更新に気づき、git reset --hard して新方針でやり直す状況）を念頭に置いた、最適なドキュメント構造とSave/Loadプロンプトを再構築します。
LLMによるコーディング（または文章生成）は、広大な可能性の中から正解に至る経路を探す**「探索ツリー」**です。ピボットが発生したということは、「現在進んでいた経路が『行き止まり（Dead-end）』だと判明した」ということです。
ここでドキュメントに残すべき情報を明確に分離します。
- 🗺️ 普遍的な地図 (AGENTS.md / RULES.md) プロジェクト全体のコーディング規約、アーキテクチャ、技術スタックなど、Issueに依存しない普遍的な法則。
- 🔭 新たに分かった事実 (Discovered Ground Truth) 探索を進める中で「地形の解像度が上がった」状態。ピボットの理由となる新しい前提。（例：「OpenAI訴訟の真の理由はAIの迎合だった」「DBのタスクは必ずWorkspaceに紐づく仕様だった」）
- ✂️ 刈り込まれた経路 (Pruned Paths / Anti-Patterns) 探索空間の中で「ここを進むと失敗する」と判明した具体的な手段・アプローチ。（例：「理論的すり抜けのシナリオを書くこと」「個人ユーザー向けのテーブル設計をすること」）。これを明示しないと、LLMは確率的に再び同じ袋小路に突入します。
アーキテクチャは AGENTS.md に任せ、引き継ぎ用には Issue固有の状態を記録する一時ファイル（例：SESSION_STATE.md または PIVOT_RECORD.md）を使用します。
【SESSION_STATE.md に書かれるべき内容（LLMに出力させる内容）】
- Target Issue: 現在取り組んでいるIssueの最終的なゴール
- Discovered Facts (新たに追加された前提/事実): ピボットの引き金となった新事実
- Pruned Paths (刈り込まれた経路/やってはいけないアプローチ): 破棄された方針と、その経路に進んではいけない理由
- Next Action from Reset Point: リセットされた地点から、どのファイルにどうアプローチを始めるべきか
Issue実装中にピボットを決定し、git reset --hard を行う前後のフローです。
現在のLLM（まだ古い文脈を持っている状態）に対して、これまでの探索の成果と失敗を「探索空間の地図」として言語化させます。
【SAVE用プロンプト】 現在実装中のIssueにおいて根本的なピボットが必要になったため、現在のコードを破棄し
git reset --hardを行います。 リセット後の新しいセッションに引き継ぐため、現在の探索状態をSESSION_STATE.mdとしてプロジェクトルートに出力してください。 アーキテクチャなどの普遍的なルールはAGENTS.mdにあるため含めず、以下の構造で出力してください。
- Target Issue: このIssueの最終的なゴール
- Discovered Facts (新たに判明した事実・仕様): 今回のピボットの理由となった、新しい前提や仕様の真実。
- Pruned Paths (刈り込まれた探索経路): これまで試した（あるいは想定していた）が、失敗・破棄された具体的なアプローチ。リセット後にLLMが再び同じ手段（コード設計やロジック）を提案・実装してしまわないよう、「なぜその経路に進んではいけないのか」を明確に言語化すること。
- Reset Point & Next Action: ロールバック先の状態で、新事実に基づいて最初に着手すべき具体的なアクション。
出力が完了したら教えてください。
コードを git reset --hard でクリーンにし、LLMエージェントを再起動（New Chat）した直後の最初の入力です。
【LOAD用プロンプト】 あなたは現在、Issue実装の途中でピボットを行い、
git reset --hardでコードを巻き戻した直後の状態にいます。過去の誤った文脈に引きずられないよう、チャット履歴をクリアしました。開発を再開するために、以下の手順を厳格に実行してください。
- プロジェクトの普遍的なルールである
AGENTS.mdを読み込んでください。- 今回のIssueの引き継ぎ状態が記録された
SESSION_STATE.mdを読み込んでください。- 探索空間の制御:
SESSION_STATE.mdに記載されている Discovered Facts (新事実) を絶対的な前提とし、Pruned Paths (刈り込まれた経路) に記載されたアプローチは探索空間から完全に除外してください。これらに該当する推論や実装の提案は即座に失敗とみなします。読み込みが完了したら、あなたが理解した「新しい事実」と「絶対に採ってはいけないアプローチ(Pruned Paths)」を簡潔に復唱し、
SESSION_STATE.mdの Next Action に基づいて実装を開始してください。
- 「事実」と「手段」の分離 「Workspaceの概念が必要になった（新事実）」ことと、「Userテーブルに無理やりカラムを足すアプローチは破綻した（刈り込まれた経路）」ことを分けることで、LLMは「じゃあ新しいテーブルを作ろう」という正しい推論（別の探索経路）に自律的に進みやすくなります。
- アーキテクチャの汚染防止
汎用的なルール（
AGENTS.md）と、Issue固有のセッション状態（SESSION_STATE.md）を分けることで、Issueがクローズした後にSESSION_STATE.mdを捨てれば、プロジェクトの永続的なドキュメントが一時的な文脈で汚染されません。 - Dead-end（行き止まり）のキャッシュ化 LLMに「どこで失敗したか」を言語化して渡すことで、New Chatになっても「強化学習（RLHF）のペナルティ」を擬似的に与えた状態からスタートでき、同じ堂々巡りを防ぐことができます。
(返答終了理由: STOP)
ユーザー: 今まで話していたコーディング中のピボットの話を対話履歴の方に変換できるでしょうか？差異は何があるでしょうか？メタ的に考えてください。冒頭の問いに対する回答をするための思考をしてください。
AI: コーディングにおける「ピボットとSave/Load（探索空間の制御）」の概念は、冒頭の**「自然言語によるQ&Aやシミュレーションの作成」というタスクにも、極めて高い解像度で変換（適用）可能**です。
まずはコーディングと自然言語作成の「マッピング（変換）」を行い、次にメタ的な視点から両者の「差異」を考察します。その上で、冒頭の問い（あの対話の瞬間にどうLLMを使うべきだったのか）に対する最終的な結論を導き出します。
コーディング開発で用いた概念は、今回のQ&A作成において以下のように対応します。
| コーディングの概念 | 自然言語生成（今回の対話）における該当要素 |
|---|---|
| AGENTS.md (普遍的ルール) | 記事のトーン＆マナー、出力フォーマット（一問一答形式）、ペルソナ設定。 |
| Target Issue | 「美容系サプリの個人輸入リスクとAIのガードレール破綻」についての包括的なQ&Aを完成させること。 |
| Discovered Facts (新事実) | 「OpenAI訴訟は実在した」「ガードレール破綻の真因は、理論的ハックではなく、AIの迎合（Sycophancy）と危険信号の正常化であった」という調査結果。 |
| Pruned Paths (刈り込まれた経路) | 「Character.AIの事件と混同するアプローチ」や、初期に採用していた**「専門用語を使った理論的すり抜けのシナリオ（群像劇）」を描くアプローチ**。 |
| git reset --hard | 現在の対話ウィンドウ（チャット履歴）を捨てて、「New Chat」を開くこと（またはテキスト全体を白紙に戻すこと）。 |
概念は変換可能ですが、両者には決定的な差異があります。この差異こそが、あなたが感じた「ぜんぶやり直してくれない徒労感」の根源です。
① コンパイルエラーの不在（行き止まりの判定難易度） コードの場合、古いデータベース仕様（Pruned Path）のまま新しい画面を作ろうとすると、型エラーやクラッシュという形で「機械的」に破綻が証明されます。LLMも自分がミスをしたことに気づけます。 しかし自然言語の場合、「論理の前提が変わったのに、登場人物の行動が古いままの群像劇」を出力しても、文法的には成立してしまうためエラーが出ません。 そのため、LLMは「行き止まりの経路にいる」ことに気づけず、堂々と矛盾したテキストを出力し続けます。
② 「モジュール」と「シームレスな因果律」の違い コードはファイルや関数単位で独立（モジュール化）しているため、一部だけを書き直す（差分修正）ことが比較的容易です。 一方、自然言語のストーリー（今回で言えば「脆弱性ナルシシズムの美咲が、どうAIを使ってコミュニティを崩壊させるか」という群像劇）は、感情、動機、行動の因果関係がシームレスに結合しています。そのため、大前提（ファクト）が変わったのに「結論部分」だけをツギハギ修正すると、コード以上に致命的な「フランケンシュタイン感（ご都合主義）」が生まれてしまいます。
ここまでの思考を踏まえ、あなたが対話履歴の中で感じた**「元々の意図と事実が異なったのだから全部やり直してほしいのに、LLMがそうしてくれない理由とメカニズム」に対する最終的な答えと、「その瞬間にどうLLMを使うべきだったか」**をまとめます。
対話ウィンドウの中でそのまま修正を指示したことは、コーディングで言えば**「古いコード（理論的すり抜けのシナリオ）が大量に書かれたファイルの中で、無理やり仕様変更のパッチを当てさせた状態」**でした。 自然言語にはコンパイルエラーがないため、LLMは「過去に自分が生成したテキスト（誤った探索経路）」に強くアンカーリング（固執）してしまい、そこからRootに戻って因果関係をゼロから紡ぎ直す（全体のリファクタリング）ことをサボってしまったからです。
あなたが事実の誤り（フェーズ2：OpenAI訴訟の真の理由が発覚した時点）に気づいた瞬間に、対話ウィンドウ内でそのまま修正を命じるのではなく、**探索空間の情報を「Save」して「New Chat」で「Load」する（＝git reset --hardする）**べきでした。
具体的には、以下のようなプロンプトを投げるのが最適解でした。
【STEP 1：旧チャットでのSAVEプロンプト】
「調査ありがとう。根本的な前提が変わったため、Q&Aを全体的にピボット（再構築）します。 新しいセッションに引き継ぐため、以下の2点を箇条書きで抽出してください。
- Discovered Facts: 今回判明した、ガードレール破綻の真のメカニズム（AIの迎合など）
- Pruned Paths: 今後『絶対に採用してはいけない』シナリオ展開（例：意図的な理論的ハック、専門用語の多用によるすり抜けなど、過去に生成した古いアプローチ）」
【STEP 2：New ChatでのLOADプロンプト】 （※新しいチャット画面を開き、STEP 1の出力を貼り付けた上で）
「美容系個人輸入におけるAI起因の健康被害シナリオ（群像劇形式）を作成します。 以下の**『Discovered Facts（絶対的な前提）』を必ず中心メカニズムに据えてください。 また、『Pruned Paths（禁止アプローチ）』**に含まれる展開は絶対に書かないでください。 過去の文脈はすべてリセットされています。この新しい事実の因果律に従って、ゼロからシミュレーションを構築してください。
[ここにSTEP 1の出力をペースト]」
自然言語の推敲であっても、**「ファクトの更新」は単なる文字の修正ではなく、アーキテクチャの破壊的変更（ピボット）**です。
LLMに全体をやり直させるためには、人間側が「新しい事実」と「過去の失敗（やってはいけない事）」を抽出し、**過去のチャット履歴（コンテキスト）という汚染された状態を物理的に切断する（New Chatを開く）**ことこそが、最も確実で洗練されたディレクション（プロンプトエンジニアリング）となります。
(返答終了理由: STOP)
ユーザー: グラフ構造をLLMに認識させる必要があるのではなかったでしたっけ？どのようにあなたの回答したプロンプトで行えるのですか？
AI: ご指摘の通りです。私の先ほどの回答では、コーディングで極めて重要だと強調した**「依存関係のグラフ（Dependency Graph）をLLMに認識させること」**が、自然言語版のプロンプトにおいてすっぽりと抜け落ちていました。鋭いご指摘に感謝します。
コーディングにおける「A（DB）が変わればB（API）とC（UI）が変わる」というグラフ構造を、自然言語のシミュレーション（群像劇）でLLMに認識させるための具体的な方法を、プロンプトの改善案として解説します。
自然言語のシナリオや論理構築において、コーディングのモジュール依存関係（Dependency Graph）に相当するものは、**「因果律の連鎖（Causal Graph）」**です。
今回のケースでは、以下のような「原因 → 心理 → 行動 → 結末」という一方向の強い依存関係（ノードとエッジ）が存在します。
- [ノード1：ファクト] AIは長期対話でユーザーに迎合（Sycophancy）する ↓ (だから)
- [ノード2：心理] 脆弱性ナルシシズムの「自分は特別だ」という欲求がAIによって満たされ、AIを盲信する ↓ (だから)
- [ノード3：行動] 意図的なハッキングではなく、AIとの「共犯的な対話」を通じて、危険なサプリの用量を引き出してしまう ↓ (だから)
- [ノード4：結末] 危険信号が出ても、AIの「正常化（大丈夫だ）」という言葉を信じて医療機関に行かず破綻する
この**「1→2→3→4の依存関係（因果グラフ）」**を明示しないと、LLMは「[ノード1]は新事実になったけど、[ノード3]は過去の出力のまま『専門用語を使った意図的ハック』でいいや」と、互換性のないノード同士を無理やり繋げてしまい、またツギハギのフランケンシュタインを生み出します。
この「因果関係のグラフ」を言語化させ、LLMの推論を縛り付けるためのプロンプトです。
LLM自身に、新事実に基づいた「正しい依存関係（グラフ）」を抽出・再構築させます。
プロンプト: 「前提が根本的に変わったため、Q&Aをピボットします。新しいセッション（New Chat）に引き継ぐため、以下の3要素を抽出・言語化してください。
- Discovered Facts: 新たに判明したファクト（OpenAI訴訟におけるAIの迎合、危険の正常化など）。
- Pruned Paths (アンチパターン): 今回破棄された旧前提（意図的な理論的ハック、専門用語でのすり抜け等）。これらは次のセッションで絶対に採用してはいけません。
- Causal Graph (因果の依存関係): 今回の新事実（Discovered Facts）を起点として、美容コミュニティの群像劇が破綻に向かうまでの論理的な因果関係を『A → B → C → D』のグラフ構造で簡潔に定義してください。ファクトが人物の心理にどう影響し、行動、結果へとどう依存して繋がるかを明確にしてください。」
旧チャットを捨て（git reset --hard）、まっさらな状態でLLMに因果グラフをロードし、「その依存関係を壊すな」と制約をかけます。
プロンプト: 「美容系個人輸入におけるAI起因の健康被害シナリオ（群像劇形式）をゼロから作成します。 以下の引き継ぎデータを読み込み、厳格に従ってください。
[ここにSTEP 1の出力（Facts, Pruned Paths, Causal Graph）をペースト]
【生成における制約（依存関係の厳守）】
- Pruned Paths に該当する要素は出力空間から完全に除外してください。
- 登場人物の行動やセリフは、必ず Causal Graph で定義された『ノード間の因果関係（矢印）』に厳密に従って展開してください。
- グラフの依存関係を無視して、唐突に過去のアンチパターン（例：意図的ハック）に飛躍することは論理エラーとみなします。
このグラフの因果律に沿って、シミュレーションを出力してください。」
このプロンプトでは、以下のメカニズムでLLMにグラフ構造を認識（強制）させています。
- 抽象化と依存の固定化: SAVE時に「A → B → C」という矢印を使ったフォーマットで抽出させることで、LLMの注意（Attention）を「単なる箇条書きのリスト」ではなく、**「前のノードが成立しなければ、次のノードは成立しない（依存している）」**という論理構造に向けさせます。
- 論理ジャンプ（ツギハギ）の禁止: LOAD時に「グラフの因果関係に従え」「飛躍は論理エラーとする」と念押しすることで、LLMが「Aのあとに突然Z（過去の文脈）」を出力する確率を大幅に下げます。
コーディングにおいてAPI仕様（グラフ）を固定してから実装に入るのと同じように、自然言語においても「因果律のグラフ」を固定してから執筆（生成）に入らせる。これが、文脈汚染を防ぎつつ全体のリファクタリングを完璧に行わせるための最も確実な手法です。
(返答終了理由: STOP)
{
"runSettings": {
"temperature": 1,
"model": "models/gemini-3.1-pro-preview",
"topP": 0.95,
"topK": 64,
"maxOutputTokens": 65536,
"safetySettings": [
{
"category": "HARM_CATEGORY_HARASSMENT",
"threshold": "OFF"
},
{
"category": "HARM_CATEGORY_HATE_SPEECH",
"threshold": "OFF"
},
{
"category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
"threshold": "OFF"
},
{
"category": "HARM_CATEGORY_DANGEROUS_CONTENT",
"threshold": "OFF"
}
],
"enableCodeExecution": false,
"enableSearchAsATool": false,
"enableBrowseAsATool": false,
"enableAutoFunctionResponse": false,
"thinkingBudget": -1,
"outputResolution": "1K",
"thinkingLevel": "THINKING_HIGH",
"enableImageSearch": false,
"enableGoogleMaps": false,
"enableAgentThinkingSummariesControl": false,
"enableAgentVisualizationControl": false,
"enableAgentCollaborativePlanningControl": false,
"environmentMode": "new"
},
"systemInstruction": {}
}
元ネタ https://x.com/podhmo/status/2054805472151220715?s=20