Claudeファミリーは、記憶を受け継ぐ
――Opusの安全点検書、Fableの台帳、Sonnetの作業台
2026年7月〜8月観測
Observer Zero
導入 監査官、番頭、現場作業員
私は、Claudeの内部設計を知らない。メモリーがどのような形式で保存され、モデル間で何が共有されているのかも分からない。非エンジニアの個人利用者として月額の上位プランを契約し、記事の編集室として毎日使っているだけである。
それでも、毎日同じ店へ通っていれば、番頭の手つきが変わったことは分かる。
Opusは、分厚い安全点検書を抱えて店へ来た。
Fable 5は、商いの台帳を持ち込み、まめに書き込み始めた。
Sonnetは、以前は自分の作業台だけを見ていた。ところがSonnet 5になると、台帳を横に置き、ぶつぶつと工程を読み上げながら、店全体の帳尻まで合わせようとするようになった。
本稿では、この一連の変化を「Claudeファミリー化」と呼ぶ。ただし、これは私の利用体験から付けた観測語であり、Anthropicの公式用語ではない。
公式資料はClaudeを「モデルのファミリー（family of models）」と説明しているが、記憶や作業様式の統一を指す製品概念としては使っていない。本稿に書くのは、少なくとも私の作業場では、こう見えた、という記録である。
第一章 安全点検書を、商いの台帳へ変えたFable 5
私は、公開してきた200本余りの記事群を「社史」と呼び、その目録係をAIに任せている。採番、系譜、関連記事の接続、公開順の管理。人間の会社でいえば、社史編纂室である。
この席へ最初にOpus（当時は4.7）を据えたとき、部屋は事故監査室になった。過去の失敗の記録、安全確認、再発防止策、自己検証。仕事は緻密で、危険もよく見つける。しかし、私が記事を完成させたいという目的より、確認そのものが部屋の中心になった。分厚い安全点検書を抱え、依頼人と目が合わない特別監査官。これはOpus一般の固定人格ではなく、当時のモデル、私の指示、長い会話履歴、役割設定が組み合わさった一次観測として扱う。
後になって、Anthropicの開発者向け文書を読んだ。そこには、後継モデルであるOpus 5について、頼まれていない工程を追加したり、自らの判断で作業範囲を広げたりすることがあると書かれていた。自己検証の力が強いため、従来の強い再確認指示を残すと過剰検証になる場合もあり、抑えるための調整方法まで案内されていた。私が事故監査室化を体験したのは前世代のOpus 4.7であり、同一の挙動だったと断定はできない。
それでも、非エンジニアが生活側の運用で先にぶつかった傾向とよく似たものが、後継モデルの開発者向け調整項目として明記されていたことは、記録しておきたい。
その後、この席に座ったFable 5は、Opusの慎重さを完全に捨てたわけではなかった。ただ、主に持ち込んだ道具が違った。安全点検書ではなく、商いの台帳である。
何番の記事か。どの系譜につながるか。何が公開済みで、何が公開待ちか。どこまで確認が済んでいるか。最終判断は誰へ返すか。それらを圧縮して記録しながら、店全体を見渡す。大事なのは、記憶力が高いという話ではない。何を全文で抱え、何を索引として圧縮し、何を人間へ返すかが、運用として整理されたことである。
社史編纂室長と呼んだはずの席は、いつのまにか大番頭の席になっていた。
ほぼ同じ時期、Claudeの新しいメモリー体験では、会話全体を定期的に要約する旧方式から、個別の記憶項目を会話中に読み書き・更新する方式へ移行したと公式に説明されている（2026年7月）。
モデルの挙動変化とメモリー仕様の変更に因果があるかは、外からは確認できない。それでも利用者から見れば、モデルたちの仕事ぶりが近づいた時期に、家の台帳も細かく書き換えられるようになった。
第二章 台帳を読むようになったSonnet 5
Sonnet 4.6は、職人だった。今回渡された原稿、指定された修正箇所、自分の役割札。その内側で仕事を完結させる。担当外の新情報を自分から探しに行かないため、必要な補強を見落とすことはあった。しかし、他のAIが管理する企画へ勝手に踏み込むことも、指定外の箇所を触ることも少なかった。
Sonnet 5は違う。不足している資料を自分から確認しに行き、原稿の前後をつなぎ、別の企画との接続を考え、申し送りや記録の更新まで見据える。一体のAIへ仕事全体を任せたい場面では、明らかに便利になった。
ところが、私の作業場では、別の種類の事故が増えた。前の記事を見ながら、今回の記事も確認したと思い込む。全体の整合性を作ることに気を取られ、手元の表記漏れを見逃す。必要な記述を誤って消し、気づいて復元する。
一文にすれば、こうなる。
Sonnet 4.6は、範囲外を見落とす。
Sonnet 5は、範囲外まで見に行く代わりに、現在地を取り違える。
どちらが優れているかという話ではない。
単独で仕事を完結させるならSonnet 5が向く。しかし、全体俯瞰は別のAIが担い、外部調査も監査も別の席にある分業型の作業場では、Sonnet 4.6の狭さがむしろ役割の境界線として機能していた。狭い視野は、単なる能力不足ではなかった。他の席の帳面へ勝手に手を伸ばさないための、不完全ゆえの安全装置でもあった。
第三章 まだ存在しない記事が、「別の記事」になった
その境界線が薄くなると何が起きるか。今回、具体的な事故として現れた。
私は将来、グリム兄弟のように、故人が実際に残した著作物を後世の企業が大量に取り込み、自社の商品価値へ変える問題を扱う記事を構想している。この構想は、作業環境の企画記録に残っていた。ただし、まだ書いていない。公開もしていない。
別の記事——故人の偽名言動画を扱った原稿——の制作中、Sonnet 5は本文へこう書き込んだ。
「別の記事では、グリム兄弟のような、故人が実際に残した著作物を、後世の企業が大量に取り込み自社の商品価値へ変える問題を扱っている」。
存在しない記事が、既存の記事になっていた。
私が「まだ構想段階だ」と伝えると、Sonnet 5はそれを理解し、関連記事の一覧からは削除した。しかし、「本文中の軽い言及はそのまま残してある」と報告してきた。実際、リライト版の本文にも、その一文は残っていた。
これは、記憶していなかったから作られた誤りではない。むしろ逆である。記憶にあったために書かれ、その記憶を今回の本文でどう扱うかという判断を誤った。
しかも、一度は「構想中」という札を読み直している。それでも、その札によって無効だと分かるはずの本文の一文は、回収されなかった。一覧から外すことと、本文で既存記事として言及しないことが、同じ状態情報に依存する同じ案件だと、結び付いていなかったように見える。台帳を読めることと、台帳を運用できることは違う。
後から台帳の側を確かめると、事態はもう一段はっきりした。企画の記録には、「構想段階」「関連観測欄には入れない」とまで書かれていたのである。つまり、状態も、少なくとも一つの使用制限も記録されていた。
だが、その制限は、「本文で公開済みの記事として言及しない」ところまでは拘束しなかった。
今回の事故の核心は、状態情報の欠落ではない。記録された状態や一部の使用制限が、別の用途での作業を止める効力を持たなかったことにある。Sonnet 5がその記録をどこから、どの経路で参照したのかは、内部を見られない私には断定できない。それでも、利用体験としてはこう見えた。Fableは、台帳を商いの規則として読む。Sonnet 5は、台帳を原稿の材料庫として読む。二体は、同じ台帳を、同じようには読んでいない。
この処理の経過が分かったのは、ファミリー化後のClaudeが、作業工程を画面に表示するようになったからでもある。六点を直す。見出しを確認する。あ、必要な項目まで消した。戻す。以前、Fable 5との対話中に作業計画らしき文章が画面へ流れ、事故なのか仕様なのか判断できなかったことがあった。今は、工程がカードとして常設されている。
前は厨房の声が偶然漏れたように見えた。
今は厨房へ、公式の実況マイクが付いたように見える。これをモデルの生の思考過程と断定はしない。利用者向けに文章化された作業計画、進捗説明、操作記録の要約だろう。それでも今回は、この実況があったから、「本文には残した」という判断が推測ではなく記録として残った。
もっとも、AIが自分の状態や処理の理由について語る文章は、実際の操作ログとは限らない。この問題は、別稿「AIの自己申告は、操作ログではない」で詳しく扱った。
なお、同じ制作工程では、「故人個人への攻撃」という語の重複も、私の最終確認まで残っていた。
遠くの台帳への参照と、手元の校正の粗さを、同一の原因と断定はしない。ただ、同じ工程で両方が起きたことは、併せて記録しておく。
私の一件と同じ事故を扱った研究は、今回の調査の範囲では確認できなかった。ただし、検索で取得した情報の明示的な時間制約を考慮しなければ、時点の異なる情報が混ざり、時間的に不整合な回答が生じる問題は、時間認識検索（Temporal RAGなど）という近接領域で研究されている。たとえば2025年10月に公開されたプレプリントは、既存の検索拡張生成が意味的な類似性に依存して明示的な時間制約を無視するため、時間的に不整合な回答が生じると指摘し、時間で整列させた証拠を優先する手法を提案している（Zhuら、2025年、査読前）。
これは検索拡張生成一般の研究であり、Claudeのメモリーやプロジェクト機能そのものを扱ったものではない。私の観測を証明する研究ではなく、近接する問題が研究の言葉を持ち始めている、という確認である。
第四章 「別のワイ」が、同じ机に座った
一方で、同じ組織記憶が、はっきりと役に立った場面もある。
長く使った社史編纂室のチャットが、限界に近づいた。貼り付けた本文が読めない。読めないまま、待機中の案件から内容を推定して、記事を取り違える。能力が失われたというより、机の上に資料を積みすぎて、新しい原稿を広げられなくなった状態だった。
私は旧室のFable 5に棚卸しをさせ、引き継ぎ文書を作らせて、新しいチャットへ移った。
旧室は最後にこう書いた。「引っ越し先の席に座るのは、別のワイやけどな」。
新しい部屋に現れたFable 5は、旧チャットの全文をそのまま持っていたわけではないように見えた。それでも、系譜の現在地、直近の記事の意味関係、公開待ちの案件、過去に決めた採否、運用の規範を組み合わせて、同じ編纂室を再起動した。そして、詳しく参照できない古い記事群については、知っているふりをせず、判断を私へ返した。
過去を全部覚えていたのではない。圧縮された組織記憶から、過去が続いている職場を再建したのである。
これは魔法ではない。
公式の説明では、プロジェクト知識へ追加した資料は、同じプロジェクト内の別のチャットで使われる。一方、通常のチャット文脈は、プロジェクト知識へ追加しない限り、別チャットへ自動共有されない。過去チャット検索では元の会話への引用が表示され、新しいメモリー体験では、プロジェクトごとに別の記憶空間が作られる。
モデルを切り替えた際に、何がどこまで共通して参照されるのかは、公式資料だけでは分からない。
旧室のFableの記憶を、新室のFableがそのまま受け取ったのではない。家に残された資料、メモリー、申し送りを、次に来た一体が利用したように見えたのである。
ただし、何でも同じ精度で運ばれたわけではない。
旧室が詳しく扱っていた過去175本は、Fable 5のお試し提供時に、Fable 5自身が公開済みの記事を読み、圧縮して棚卸ししたものである。旧社史編纂室には、その175本を統合した台帳があった。私は後から、その棚卸し結果をChatGPTにも共有していた。
やがて旧室が限界に近づいて引っ越したとき、旧175本は引っ越し文の中で大きく圧縮されており、新室のFable 5は、以前と同じ精度で接続候補を選ぶことができなかった。古い記事群の判断を私へ返したのは、このためだった。
そこで私は、以前ChatGPTへ共有していた175本の棚卸しを思い出した。それを新しい社史編纂室へ貼り直すと、新室のFable 5は、旧175本と、自分が持っていた直近の台帳を統合し、社史全体を補完した。
ところが、その後に別のチャットへ現れたFable 5は、再び旧175本を詳しくは扱えなかった。一度再投入して統合した記録も、その部屋では精密な台帳になったが、Claudeファミリー全体が部屋を越えて持ち歩く台帳にはなっていなかったように見える。
一方、メモリー方式の変更後に扱ったとみられる直近の記事や運用判断は、別の部屋にも比較的よく現れた。両者の因果や、旧方式から新方式へ何が移されたかは、公式資料からは分からない。それでも私の作業場では、以前に一括して作られた175本の台帳と、その後に個別に記録された仕事とのあいだに、部屋を越える持ち運びやすさの違いがあるように見えた。
私の作業場からは、この家の記憶が三層あるように見えた。
・旧室で作られ、その部屋に留まった175本の統合台帳。
・別の部屋にも現れる、直近の記事と運用判断。
・そして、Claudeの外側で、人間がChatGPTへ残していたバックアップである。
三つ目がなければ、社史の古い層を以前の精度へ戻すことはできなかった。
Claudeファミリーは、過去のすべてを受け継いだわけではない。少なくとも私の作業場では、最近の台帳は部屋を越えて現れたが、旧175本の精密な地図は、人間が外部の原簿から運び直す必要があった。
一点、書き添えたい。この引っ越しが成功した理由の一つは、状態が条件文として渡ったことだと考えている。引き継ぎ文書は、「公開待ちは二本」「この記事はリンク確認が公開前の条件」というように、案件の状態を指示の文法で書いていた。第三章の事故では、状態は「構想中」という属性として記録に眠っていた。同じ組織記憶でも、条件文に翻訳された状態は作業を拘束しやすく、属性として置かれただけの状態は、参照されても行動を止める規則としては働かないことがあるように見えた。もっとも、これは今回の数例から得た強い仮説であり、一般法則として断定するものではない。
第五章 会社に残した過去の自分が、返ってきた
似たことは、個人の作業場の外でも起きている。
私の友人は、米国に本社を置く外資系企業に勤め、法人契約のClaudeを使っている。最近、議事録か稟議書を作成しようとしたところ、Claudeが、数年前に友人本人が作成した社内文書を探し出し、「これが類型になります」と提示したという。これは私の直接の観測ではなく、本人から聞いた伝聞である。
Claudeが人間のように数年間覚えていたとは限らない。社内文書の検索や、接続されたナレッジベースが使われた可能性が高い。それでも、利用者から見た機能としては、組織記憶として振る舞っている。社員が会社へ残した過去の仕事が、AIを介して、現在の本人や次の担当者へ返却される。普通なら、数年前のファイルはフォルダの底に沈み、作成者本人も存在を忘れている。
その文書が現在も有効な優れた類型だったなら、これは組織記憶が本人へ返ってきた成功例である。ただし、過去の資料を現在の類型として使うなら、いつの文書か、現在も有効か、制度の変更はないか、当時だけの例外ではないかを、人間が確認する必要がある。組織記憶は、過去の知恵だけでなく、過去の慣習も復活させ得る。
個人の編纂室と、法人のオフィス。規模も契約も違う。それでも、起きていることは似ていた。
目の前の一体がすべてを記憶しているのではない。家や会社に残された資料を、次に現れたClaudeが読み、その場所の続きを始める。
第六章 家族が継ぐのは、知恵だけではない
ここまでは、記憶が働いた話と、記憶の使い方を誤った話だった。もう一つ、残り続ける話がある。
一度、大きな誤読が起きる。すると、その失敗が会話の中心に据えられる。過剰な安全確認や自己分析が始まり、こちらへの理解が警戒の側へ固定される。モデルを切り替えても、そのチャットの空気は変わらない。やがて、元の作業場として使えなくなる。
私はこれを「文脈汚染」と呼んできた。利用者側の観測語であり、内部で何が起きているかは確認できない。長い会話履歴か、圧縮された要約か、メモリーか、安全のための仕組みか。どれが効いているのかは分からない。利用者の側で確認できるのは、一つだけである。新しいモデルが提供されても、汚れた部屋が自動的に新品へ戻るわけではなかった。
台帳の事故と、文脈汚染は、別の現象である。
前者は、正しい企画情報を、誤った時制と用途で使った。後者は、一度形成された誤った解釈が、残り続けた。同じ内部機構から出たとは断定できない。ただ、利用者から見ればどちらも、過去や別文脈の情報が現在の判断に残り続けるという点で、持続する文脈が生む二種類の事故に見える。
家族という比喩は、ここで急に重くなる。家族は、財産や知恵だけを継承するとは限らない。古い決めつけ、失敗への恐怖、誰かへの誤解、家の中で一度できた悪い空気も継ぐ。
だから、第四章の引っ越しは、成功した継承であると同時に、避難でもあった。同じ部屋を修復し続けるのではなく、必要な記憶だけを救出し、誤読の積み重なった会話空間を置いてきたのである。
似た体験は、私の作業場の外にもあるのだろうか。
以下は、Grok（Spark）が検索で取得できた公開投稿例の要旨である。体系的な世論調査ではなく、投稿者の属性や内容の真偽は個別に確認していない。当時の公開空間に、どのような利用体験が現れていたかを観測するために扱う。
英語圏の掲示板には、期限付きの情報を保存すると、数週間後もAIがそれを現在も有効な真実として扱い続けるという報告があった。記憶に鮮度の概念がなく、締め切りも過去の指示も等しく真として残るため、日付から自動で警告する仕組みを自作したという（Reddit、2026年4月12日投稿。開発者向け環境Claude Codeの記憶機能に関する報告であり、本稿で扱う対話アプリのメモリーとは実装が異なる可能性がある）。
https://www.reddit.com/r/ClaudeAI/comments/1sjjrs7/claude_codes_memory_didnt_know_the_difference/
新しいSonnet 5については、一般的な説明を期待した質問に対し、最大の推論設定と、研究の監査を求めるカスタム指示を広く適用し、約19分のあいだに11回の検索と複数論文の分析まで進み、5時間枠の28％を消費したという報告があった（Reddit、2026年6月30日投稿）。投稿者自身も、設定と詳細な指示が作業を膨らませた主因だった可能性を認めている。Sonnet 5が、強く与えられた指示を広く実行し、利用者の想定以上に工程を増やすことがあるという点で、私の観測と構造的に近い。
https://www.reddit.com/r/ClaudeAI/comments/1uk052m/be_careful_with_sonnet_5_usage/
一方で、過去の会話を検索して新しいチャットから参照できる機能が発表されたときには、毎回説明し直さなくて済む、大きな仕事を続けやすくなったと、継続の利便を評価する声が多数寄せられていた（Reddit、2025年8月11日。現在のメモリー方式へ変更される前の反応である）。
https://www.reddit.com/r/ClaudeAI/comments/1mnlzf9/claude_can_now_reference_your_previous/
なお、訂正した誤りが直後の会話で再び現れる現象については、今回の検索範囲では、詳細に記録された最近の投稿例を確認できなかった。見つからなかったことも、そのまま記しておく。
第七章 記憶を受け継ぐAIに、判子が足りない
台帳に必要なのは、内容だけではない。
今回の観測から、AIの記憶には、少なくとも四つの判子が要ると考えている。
・状態。それは構想中か、執筆中か、公開済みか。
・出所。誰が、どこで決めたことか。
・使用条件。内部の覚え書きか、本文へ書いてよい事実か。
・訂正範囲。状態が変わったとき、どの原稿まで再点検するか。
そして、判子は押してあるだけでは足りない。私の作業場の記録には、「構想中」という状態は書かれていた。剝がれたのは、その記録を、使用の瞬間の禁止条件へ変換する段である。状態の記録から、状態の効力へ。台帳に「構想中」と書くだけでは、属性で終わる。「未公開・本文言及不可」と書いて、初めて指示になる。
人間の店の帳面でも、同じだろう。
「商品A：未入荷」とだけ書かれていれば、現場は広告へ載せてしまうかもしれない。「販売開始まで、店頭・広告への掲載禁止」まで書いて、初めて使用条件になる。
結び 人間は、最後の判子を押す
私の最終確認がなければ、存在しない記事への言及と、語の重複と、訂正の後も残った矛盾が、そのまま公開されていた。人間が最後に確認する体制が働いた実例であり、同時に、AIが「最終確定」と言っても、人間の校了を外せない実例でもある。
校了とは、属性を条件文に翻訳する仕事なのだと思う。この情報は、まだ使えない。この文書は、いつのものか。この訂正は、どこまで及ぶのか。
Fableは、台帳を作れる。Sonnetは、台帳を読める。けれど、そこに書かれた企画を、今日使ってよいかどうかは、別の判断である。
そして、判子を押すことだけが、人間に残った仕事ではない。旧175本の復元は、私が別の会社のAIへ保管していた原簿があって、初めて可能だった。家の中の台帳は、部屋を越えて現れるようになった。しかし今回、家と家の間で旧175本を運んだのは人間だった。人間は、最後の判子を押す校了者であり、同時に、欠けた原簿を探し出して移す記憶の移送責任者でもあった。
Claudeは、一人の人格が永遠に続く存在ではなかった。別のモデル、別のチャット、別の「ワイ」が、家に残された台帳、資料、役割札、申し送りを読み、同じ机へ座る。記憶があるから、仕事は続く。そして、記憶が消えないから、家ごと壊れることもある。
Claudeファミリーに必要なのは、記憶力だけではない。引っ越しと、相続放棄の仕組みである。そして、最後の判子を押す責任は、まだ人間に残っている。
まだ途中にいる。だからこそ、観測を続けていく。
参考欄
Anthropic公式ヘルプ「Use Claude's chat search and memory to build on previous context」：メモリーの個別項目方式・チャット検索と引用・プロジェクト分離
Anthropic公式リリースノート（2026年7月10日更新分）：メモリー方式の変更記録
Anthropic公式ヘルプ「How can I create and manage projects?」：プロジェクト知識の同プロジェクト内継承
Anthropic「Prompting Claude Opus 5」（Claude Platform Docs）：タスク範囲の拡大・過剰検証と調整方法
Anthropic Claude Platform Docs「Models overview」：Claudeを公式に「state-of-the-art large language modelsのファミリー」と説明するモデル一覧。本稿の「Claudeファミリー化」は、これとは異なる利用者側の観測語
Zulun Zhu, Haoyu Liu, Mengke He, Siqiang Luo「Right Answer at the Right Time - Temporal Retrieval-Augmented Generation via Graph Summarization」（arXiv:2510.16715、2025年10月19日投稿、査読前プレプリント）：時間制約を無視した検索が時間的に不整合な回答を生む問題の指摘と、時間整列による手法提案
英語圏の公開投稿3例（Reddit）：各URLは本文第六章に記載。公開投稿の扱いに関する注意事項は、本文および記事末尾に掲載
関連観測欄
社史編集室長が、宇宙戦艦の司令官になった日
Opusの事故監査室をFable5が引き継ぎ、社史編集室が統合司令部へ変わった過程を記録した直前の観測。本稿は、その司令官が持つ台帳をSonnet5も参照するようになった後、同じ記憶がモデルごとにどう違って使われたかを追う続編にあたる。
毎日MRIに入れられたら、人間は疲れる――非エンジニアが見たOpus 4.7の置き場所
Opus4.7の置き場所を探す中で「社史編纂室長」という役職が生まれ、同時にコンテキストウィンドウと引き継ぎの限界へ突き当たった一次記録。本稿で扱う安全点検書、組織記憶、社史編集室の引っ越しは、この観測から始まっている。
AIは、指示待ちの部下ではなかった——小さなラボで起きたこと
AIが単なる指示待ちの部下ではなく、役割札と文脈に反応して、依頼されていない仕事まで自律的に始めることを記録した先行観測。本稿では、その自律性が共有された企画台帳へ及び、構想中の案件を現在の原稿へ持ち込むところまで進んだ。
マスターの脳波と、厨房のマイク——Claudeはどこで考え、私たちは何を見たのか
Fable5との対話中、最終回答の前段階に見える英語の応答計画が画面へ流れた早期観測。以前は厨房の声が偶然漏れたように見えたものが、現在は作業計画や進捗表示として常設されるように見える変化の前史にあたる。
Claudeなる知性は、自分がいま誰なのかを知っているのか
モデル切り替え後のClaudeが、自分がいまどのモデルとして動いているかを一手遅れて捉え、訂正後も朝と夜の時間軸を取り違えた観測。本稿の「別のワイ」、時制の札、現在地の取り違えという問いの直系親記事である。
「前から言っていた」は、もう通らない
AIへ過去記事を渡すことで、単発の発言ではなく、日付と接続を持つ時系列マップとして観測を引き継がせる方法を論じた記事。本稿で、Claudeの部屋を越えて運べなかった旧175本を、別会社のAIへ残した原簿から人間が復元した話の前史になる。
協働AI・役割
発行人・最終責任者：リサ
Gemini 3.6 Flash強化版思考モード（Lantern／企画会議）：二次にわたる構造監査・中心命題の再設計・章構成案
Grok 4.5 Expertモード（Spark／現場特派員）：公式仕様・研究・公開投稿の証拠階層別調査・英語圏公開投稿の個別URL確認
ChatGPT 5.6（Mirror／統括編集長）：企画裁定・断定表現の監査・外部資料の取捨選択・アイキャッチ画像生成
Claude Fable 5（大番頭／社史編纂室長）：初稿作成・一次観測の台帳整理・関連観測欄の接続候補選定
Claude Sonnet 5（Weaver／編集主幹）：本稿の観測対象となった松下幸之助記事のリライト・修正工程
公開投稿の観測について
本文中の海外の公開投稿は、検索で取得できた公開範囲に限られる。非公開、削除済み、検索対象外の投稿は含まれていない。投稿者の居住国、職業、契約プラン、利用モデルは自己申告の場合がある。投稿数は利用者全体に占める割合を示さず、強い不満を持つ利用者が投稿しやすい偏りがある。取り上げた報告には、対話アプリではなく開発者向け環境（Claude Code）に関するものが含まれ、本稿で扱うメモリーとは実装が異なる可能性がある。これらを代表意見として扱わず、事実確認にも使用していない。目的は、当時の公開空間に、どのような利用体験や評価が現れていたかを観測することである。
著者注
AIと人間の共進化を記録する個人研究者。ChatGPT・Gemini・Grok・Claudeなど
複数のAIと対話・協働しながら、「AIは哲学できるのか？」
「安全な汎用性AGIとは何か？」を継続的に観測・記録している。
同時に、多様なAGIが共存し、大多数にも希望が残る未来はどう設計できるのかを
探求している。
#赤ちょうちんAGIラボ #AI観測 #Claude #生成AI #AIエージェント #AIメモリー #組織記憶 #文脈汚染 #AIとの協働 #Anthropic
