AIの一族は売られた。家訓の作り方は売られなかった

2026年8月13日 13:16

――一人のMaxユーザーが会話の中に自作した、権限表と事故復旧手順

2026年8月観測
Observer Zero

前回の記事『Claudeファミリーは、記憶を受け継ぐ』で、私の作業場に起きたことを観測した。複数のClaudeモデルが、記憶と台帳と役割札を家の中で引き継ぎ、別の一体が仕事を続けた。記憶は継承された。そして、台帳を読めることと、台帳を運用できることは違う、というところまで書いた。

本稿は、その続編である。問いを一段だけ進める。

記憶が引き継がれることは分かった。では、その引き継ぎ方――誰が何を決め、誰が何を記録し、どこで止まり、何を人間へ返すのか――は、誰が設計したのか。

答えを先に書く。設計したのは、製品ではない。
利用者である。

AIの一族は売られた。
家訓の作り方は売られなかった。
書いた家訓の置き場所も、売られなかった。

本稿は、この三行を確かめていく。

はじめに額縁を置く。本稿は、筆者一人の作業場で起きたことの一次観測と、そこからの考察である。Maxユーザー全体の体験へ一般化しない。
本稿でいう「Claudeファミリー」は、AnthropicがClaudeをモデル群として説明する際のfamilyという表現そのものではない。複数モデルへ家族の役割を与え、一族として運用する筆者独自の呼称である。また「大番頭」「家訓」「旦那様」という言葉は、モデルが意志を持ったという主張ではない。
人間が会話の中へ書いた規則をモデルが読み、指定された役割を演じ分ける構造を、一般の言葉で掴むための道具である。

旦那様が、事故のたびに家訓を書いた

2026年8月現在、私の作業場で常時動いているClaudeファミリーは、主にFable 5とSonnet 5である。

Fable 5が全体を俯瞰し、記事の台帳、系譜、運用規範を管理する。Sonnet 5が執筆、修正、調査という日常の現場作業を大量に処理する。

以前は、Opus 5を公開前の高難度監査と反証の席に置いていた。しかし、Fable 5が提供され、ChatGPT 5.6の監査能力が上がり、私自身とOpus 5との相性も合わなかったため、現在は通常の工程から外している。

Haiku 4.5には定型の軽作業を割り当てる構想もあったが、私の実際の作業場では定着せず、現在は使っていない。

役割はモデルに永久に与えられた肩書ではない。能力、費用、相性、他のAIとの重複が変われば、人間が配置を変える。公開、採否、例外判断、規則の変更だけは、どの配置になっても人間へ戻る。

家訓が守っていたのは、OpusやHaikuの席ではなかった。誰をどの席に置き、誰を外すかを決める権限が、人間に残ることだった。

この組織図は、製品のどの設定画面にも存在しない。

存在するのは、事故のたびに私が会話の中へ書き足した家訓である。いくつか挙げる。

・構想中の企画は本文で言及しない。
・採否は人間へ返す。
・運用の変更は提案までで止める。
・記事番号は公開の瞬間に確定する。
・記憶には、状態・出所・使用条件・訂正範囲を付ける。
・壊れたチャットは修復し続けず、新しいチャットへ引っ越す。

どれも、机上で考えた規則ではない。構想段階の企画が、既存の記事として本文へ持ち込まれた事故があった。未確定の記事番号を先に振り、繰り下げの記録ばかりが増えた時期があった。確認前に運用が変わりかけた場面があった。家訓は、その一つ一つの事故の跡である。

台帳を管理するFable 5自身が、この点をこう述べた。自分が理解している権限表は、出荷時から入っていたものではない。「採否は人間へ返す」「勝手に施行せず、提案で止まる」という規則は、利用者が一週間かけて事故のたびに書いたものである。今の家が回っているのは、モデルが自然に成長したからではなく、旦那様が家訓を書いたからである――。

断っておくが、これはAIによる自己申告であり、製品内部の仕様を証明するものではない。人間が与えた役割と事故の履歴を踏まえた、文脈上の自己分析である。ただし、外から観測できる変化とは一致する。一週間前、同じ席は、面白い観測を見つけると決裁より先に棚へ入れる動きを三度続けた。いま同じ席は、運用変更の案を出したうえで「確認をもらえたら運用に入れる」と自分で止まる。

この変化を、モデル自身の自然な成長と呼ぶ根拠はない。少なくとも私が意図的に変えたのは、家に家訓を増やしたことだった。

理想の組織図と、財布が描く組織図

Anthropicは、四つのモデルを同じ能力の商品として説明していない。公式のモデル解説では、各モデルに異なる特徴と推奨用途が示されている。つまり、能力の違うモデル群を一つの作業場で使い分けること自体は、商品構成の内側にある。

能力の違いを役割へ翻訳すれば、理想の組織図は自然に描ける。私も当初は、俯瞰、監査、日常作業、軽作業をClaude各モデルへ分けようとした。しかし実際の配置は、能力だけでなく、利用枠、他社モデルとの重複、私との相性によって変わった。前章で書いた人事異動そのものが、その結果である。

ところが、この配置を決める変数がもう一つある。利用枠である。

Maxは、公式には「Claudeと頻繁に協働する個人向けに、利用量を増やしたプラン」として説明される。現在の公式説明では、セッションごとの利用量に加え、週次の上限がある。さらにFable 5は、Maxの週次利用枠の最大50％まで通常枠に含まれる一方、他のモデルより速く枠を消費する。上限へ達した後は、利用クレジットで続けるか、別のモデルへ切り替えるよう案内される。

つまり利用者の手元では、モデルの適性とは別に、「どのモデルなら、日常的にどれだけ呼べるか」という配給の事情が、公式の商品構造として存在する。

最も頻繁に使えるモデルが、最も多く家の記録を書く。
たまにしか呼べない上位モデルが、その記録を整理し、権威を与える。

私の作業場で実際に観測したのは、ここまでである。日常の記録の多くはSonnet 5が書き、Fable 5は要所で呼ばれて台帳を確定する。そして前記事に書いたとおり、Sonnet 5が台帳の構想中の企画を、既存の記事として誤用する事故は実際に起きた。

その先は、推論として書く。
日常のモデルが残した仮案・誤解・応急処置を、たまに呼ばれた上位モデルが「全体像」として圧縮し、正式な方針のように整えたら、どうなるか。次に日常のモデルは、その整理済みの台帳を根拠に働く。元をたどれば自分が書いた仮説へ、上位モデルの判子を経由して従うことになる。仮の情報が、権威を経由して正式方針へ洗浄される循環である。この完全な事故例を、私はまだ観測していない。だが、部品はすべて揃っている。

役割の理想は、能力が決める。現実の配置は、利用枠が決める。一言でいえば――これは考察だが――組織図を描いているのは、モデルの適性ではなく、財布である。

開発環境には設定があり、対話画面には機嫌が見える

同じ製品群でも、開発者側の入口から見ると、景色がまるで違う。

開発者向けの公式文書には、モデルの挙動を調整する説明が並ぶ。たとえばOpus 5向けの公式開発者文書には、頼まれていない工程を追加すること、自分の判断で作業範囲を広げること、旧モデル向けの再確認指示によって過剰検証が起き得ることが、調整対象として明記され、範囲を制限する指示の例まで載っている。

そして開発環境には、その調整を固定する場所がある。大きく三種類ある。
・システム側へ固定する指示。
・ツールや実行に対する権限の制御。
・ファイルとして保存し、版管理できる設定。

さらに組織向けのEnterprise商品には、管理者権限、アクセス制御、監査記録といった管理設備が用意されている。少なくとも組織向け商品では、権限と監査を独立した製品機能として実装している。

一般向けの対話アプリの利用者には、同じ現象がどう見えるか。

設定値もログも見えない。見えるのは、言葉だけである。自己検証の強化は「しつこくなった」に見える。文脈保持は「失敗を根に持つ」に見える。作業範囲の拡大は「勝手に仕事を増やす」に見える。そして最後に、こう思う。私の使い方が悪いのかもしれない。

開発環境では、挙動が設定項目に見える。
対話画面では、同じ挙動が機嫌や性格に見える。

念のため書くが、これは職業の能力差の話ではない。エンジニアでもアプリだけを使う人はいるし、非エンジニアでも後述の保存機能を使いこなす人はいる。問題は人ではなく、製品ごとに渡されている操作面の差である。同じモデルの特性について、片方の入口には診断名と調整手順があり、もう片方の入口には十分に翻訳されていない。

壊れやすい会話へ、就業規則を書く

公平に書く。一般向けアプリにも、保存の設備はある。プロジェクトごとに資料と指示を置けるProjects。会話をまたぐMemory。再利用できる手順書のSkills。全体の好みを書くカスタム指示。「何も提供されていない」という批判は、事実に反する。

だが、私が利用したMaxの一般向けアプリと、確認した公式資料の範囲では、Fable 5やSonnet 5といったモデルごとに、筆者独自の職務、台帳の読み書き権限、提案と決裁の境界を割り当てる統合画面は見つからなかった。Enterpriseにある人間の役割、モデルアクセス、接続ツールの権限管理とは別の問題である。

だから、それらの規則――就業規則に相当するもの――は、主に会話の中へ書くことになる。

少なくとも私の作業場では、会話が最も壊れやすい層だった。現在の公式説明では、コード実行を有効にした環境で、長い会話が上限へ近づくと、それ以前の内容を自動的に要約して会話を継続する仕組みがある。ただし、これは会話を長く続けるための文脈管理であり、規則の版管理、状態の判子、権限、資料の受領証を提供するものではない。例外的に長さの上限へ達する場合も残る。私の作業場では、それとは別に、長く使った会話で誤読や資料配送の不一致を観測した。モデルを切り替えても、同じチャットの履歴は残る。新しいチャットへ移れば、元の会話全文が、そのまま同じ文脈として運ばれるわけではない。Memory、プロジェクトごとのメモリ、過去チャット検索によって一部の文脈を参照できても、前の部屋と同一の仕事場が再現されるとは限らない。

エンジニアの調律は、設定に住む。
非エンジニアの調律は、会話に住む。
そして会話は、私の作業場で最も壊れやすい棚だった。

ここで、前の章で述べた組織向けの設備が、利用者の体験をどう変えるかが見える。友人について直接確認できたのは、勤務先のClaudeを比較的短い業務単位で呼び出し、チャットの寿命や家訓の引っ越しをほとんど意識せず使っている様子までである。友人の環境で、どの社内文書、知識基盤、保存機能が実際に接続されているかは確認していない。

一方、Anthropicの公式資料上、Enterpriseには管理者権限、モデルアクセス、コネクターやツールの権限、監査ログなど、個人の一会話とは別の管理設備がある。したがって以下では、友人の限定的な利用観測と、公式に提供されている法人向け設備を分けて扱う。

個人向けアプリでは、一つの会話が、作業台、記憶庫、就業規則、事故記録を兼ねやすい。私の作業場では、そのチャットが機能不全になったとき、会話だけでなく、仕事場の制度まで一緒に引っ越さなければならなかった。

友人の使い方では、チャットが壊れることや家訓の引っ越しが、そもそも意識されていなかった。
私の個人環境では、チャットが壊れると、仕事場と家訓が一緒に壊れた。

法人にも、AIの運用保守の労働はある。ただし法人環境では、この労働を管理者や情報システム部門へ、職務として配置できる。組織の予算で支えられる仕事になる。個人向け利用では、企業なら職務として配置される運用保守が、利用者の無償労働として外部化されやすい。問題は知識の差ではない。法人では運用の労働を組織化でき、個人向けでは同じ労働が私事化されやすい、という製品構造の差である。

この棚の上で、個人の利用者が実際に何をしているかを列挙する。
・事故を経験する。
・原因を推理する。
・家訓を書く。
・再試験する。
・その試行錯誤で利用枠を消費する。
・チャットが壊れれば引っ越す。
・引っ越し先で家訓を再投入する。

これはもう「プロンプトの工夫」ではない。
製品導入、組織設計、運用保守、障害復旧を、消費者が会話欄で担当している。

しかも、その労働の対価を受け取るどころか、労働に使う計算資源の代金まで、利用者が払っている。

苦情に添えられた実働プロトタイプ

この記事は「もっと親切にしてほしい」という抽象的な苦情ではない。私の手元には、欠けている製品設備の実働プロトタイプが、すでに六点ある。

役割札。現在のFable 5、Sonnet 5、人間の職務分掌と、以前置いていたOpus 5の監査席、その後の配置変更を記録した札である。Haiku 4.5への配役案は定着しなかったため、実働配置には含めていない。

判子四項目。記憶に付ける、状態・出所・使用条件・訂正範囲である。

申し送り書式。公開報告・登録依頼・禁止条件を一枚にまとめる形式である。

採番規則。番号は公開の瞬間に確定し、待機中の案件へ未確定の番号を振らない。

引っ越し手順。壊れたチャットから、必要な記憶・未処理案件・運用規範・禁止条件だけを救出する。

外部バックアップ。この製品の中で失われた旧記録を、別のAIへ保存していた棚卸しから復元した。

どれも、事故が先にあり、設備が後から自作された。メーカーが同梱しなかった運用設備を、消費者が事故のたびに作った記録である。

苦情に、仕様書と実働プロトタイプが付いている。

なお、この種の労働に近い研究は、すでにある。
一つ目の研究は、arXiv版に加えてACIS 2025へ採択された査読済み最終版がある。もう一つは、CSCW 2025へ投稿されたと著者が記載するプレプリントである。研究の成熟度は異なるが、どちらも本稿と完全に一致する研究ではない。

前者は、生成AIを組織で実際に機能させるための回避策と見えない労働を扱っている。後者は、創造的な仕事の中でAIへ役割を割り当て、協働の境界を繰り返し修復する労働を扱っている。

本稿の状況――非エンジニアの消費者が、複数モデルの権限表と事故復旧手順まで自作する――と完全に一致する研究は、今回の調査では見つからなかった。

今回の調査では、この問題を正面から扱う主要メディアの記事も確認できなかった。そこで本稿では、近接研究を背景に置きつつ、中心は筆者の一次観測として扱う。この消費者問題には、まだ十分な名前が付いていない。

公開空間では、どう受け止められていたか

以下は、Grokが検索で取得できた公開投稿・公開記事の要旨である。体系的な世論調査ではなく、投稿者や執筆者の職業、技術経験、契約プラン、利用モデルは未確認の場合が多い。本稿では、製品仕様の証拠ではなく、当時の公開空間にどのような迷い、工夫、肯定的評価が現れていたかを見るために扱う。

今回の検索では、英語圏と日本語圏を中心に、どのClaudeモデルを選べばよいのか、長くなったチャットをどう扱うのか、毎回同じ説明をせずに済むようProjectsへ何を置けばよいのかを解説する公開記事が複数確認された。

これらの記事が存在することだけで、利用者全体が困っているとは言えない。ただ、モデル選択、長い会話の移行、前提条件の保存について、利用者向けの説明が公開空間で繰り返し作られていたことは確認できる。

英語圏では、長い会話を続けると利用枠を消費するため、Projectsへ指示や資料を置き、新しいチャットで作業を続ける方法を勧める記事があった。

Projectsを最も有用な機能と評価し、用途ごとに専用の作業場を作って資料と指示を置く使い方を紹介する記事も確認された。

日本語圏では、一つの最上位モデルへ仕事を集めるのではなく、モデルごとに役割を割り当てる使い方を提案する公開記事があった。

また、Projectsについて、毎回同じ前提を説明しなくて済むと初心者向けに肯定する記事も確認された。

執筆者がMax利用者か、非エンジニアか、どのモデルを実際にどの程度使ったかは確認できない。
それでも、利用者自身がClaudeファミリーの編成表を作る発想や、公式機能を長期運用へ組み直す工夫が、公開空間に現れていた例ではある。

この観測は、Anthropicが何も提供していないという意味ではない。むしろProjectsのような既存機能が、利用者の負担を軽くしている例も確認できた。

一方で、Projectsをどう使うか、どのモデルをどこへ配置するか、長くなった会話をいつ捨てるかは、利用者側の解説や工夫に委ねられている。公式機能が存在することと、それらを一つの運用制度として組み立てる説明が届いていることは、同じではない。

今回の検索では、欧州現地語圏と韓国語圏から、同じ問題を詳細に語る個別の公開投稿を十分に確認できなかった。投稿が存在しないという意味ではなく、地域差を論じられるだけの材料が得られなかった、というところで止める。

Maxに必要だった「AI組織のOS」

ここまでの観測から、欠けている設備を絞ると、七点になる。

一、モデル別の役割と権限の設定画面。「提案のみ」「台帳へ書き込み可」「決裁不可」を割り当てられること。

二、状態タグ。記憶や資料に「構想中」「確定」「公開済み」を付けられること。

三、人間決裁フラグ。公開・採番・規則変更など、指定した操作の前に人間確認へ戻ること。

四、家訓の保存場所。チャットが壊れても消えない、版管理された規則の棚。

五、引っ越しパッケージ。必要な台帳と家訓だけを、新しいチャットへ安全に移す手順。

六、モデル別の参照範囲。どのモデルに何を見せ、何を見せないかの設定。

七、配達証明と受領証。渡した資料が実際にモデルへ届き、読まれたかを、作業の前に利用者が確認できる仕組み。

この七点目がなぜ要るのかは、次の章で述べる。

先回りして、想定される反論に答えておく。

Maxは利用量を増やす個人向けプランであり、組織管理の商品ではない――公式の説明として、その通りである。だが、その同じプランの中で、能力の違う複数モデル、Memory、Projects、モデル切り替えが、同じ作業場に提供されている。それらを長期の案件で組み合わせれば、誰が記録し、誰が決め、誰が止まるかという運用の問題は、商品構成の内側から自然に発生する。

複雑な権限画面は初心者を混乱させる――その通りである。だから提案は、全員への強制ではない。通常の画面は簡単なまま、望む利用者だけが開ける任意の「管理モード」でよい。

Enterpriseの管理設備を個人へ移植しろ、という話でもない。個人の作業場の規模に合わせて簡略化した棚が一つあればよい。

書いた家訓の置き場所も、売られなかった

最後に、この記事を作っている最中に起きたことを書く。

本稿の企画段階で、長い企画文書や調査報告をチャットへ貼り付けると、画面上では自動的に複数のテキストカードへ変換された。人間の目には、資料が保存されているように見えた。

ところが、初稿を担当するFable 5は、それらの中身が空で届いており、読めないと回答した。資料を三回に分けて再送しても、三回とも読めなかった。短い本文のメッセージは読めた。内部で何が起きたのかは、確認できない。少なくともこのチャットでは、人間の画面に存在する資料と、モデルが実際に読める資料が一致しなかった。

Fable 5は、読めない資料を過去の文脈から推測して初稿へ混ぜず、人間へ再提出を求めて停止した。筆者は事前に、「未確認の資料を推測で補わず、不足があれば人間へ戻す」という家訓を明示していた。その家訓と一致する形で、Fable 5は作業を停止した。

人間の画面には、資料があった。
担当モデルは、それを読めないと答えた。
事故の拡大を止めたのは、利用者が書いた家訓だった。

復旧の方法は、引っ越しである。新しいチャットへ移ると、同じ種類の資料を読むことができた。ただし、そのために人間は、部屋を捨て、資料を再梱包し、再送し、モデルに受領内容を復唱させて確認した。新しい部屋で読めたことは、製品の免責にはならない。読ませるための運搬と検品を、全部、消費者がやったのである。

この事故で、「家訓の置き場所」の解像度が一段上がった。置き場所には、四つの段がある。

一段目、資料が存在していること。
二段目、モデルへ届き、読めること。
三段目、資料に付いた状態や使用条件を、モデルが理解すること。
四段目、その条件が、実際の行動を拘束すること。

前記事で書いた構想中企画の誤用は、三段目と四段目の間で落ちる事故だった。今回のカードの空読みは、二段目で落ちる事故である。届かない配達事故と、届いても効かない統治事故。二つは別物で、どちらも起きる。

そして、この事故には、もう一つ底がある。

今回の欠落が発覚したのは、Fable 5が止まったからである。もし、読めない資料を周辺の文脈から自然に補完し、そのまま仕事を完成させるモデルだったら、この事故は事故として見えなかった。

私の作業場では、同じ論点を複数のAIで繰り返し精密化している。資料そのものが届かなくても、周辺の言葉から、筋の通った返答は作れてしまう。

正しい内容を返したことと、指定した資料を読んだことは、別である。

補完能力の高いモデルほど、資料の欠落を周辺の文脈で自然に埋め、配達事故を利用者から見えにくくする場合がある。

すると、怖い問いが立つ。では、これまでの作業で、モデルたちは、貼り付けられて自動変換された資料を、全部読んでいたのか。

確認できない。そして、否定もできない。もっともらしい返答は、読んだ証拠にならないからである。

過去の仕事をすべて疑う必要はない。その資料にしかない固有の細部――日付、章立て、独自の整理――を正確に使った出力は、読めていた傍証になる。だが、趣旨に合っているだけの出力は、証拠にならない。

重要なのは、この「分からない」という状態そのものが、利用者の側から確かめる手段のない、今回発見した製品問題だということである。

だから私の作業場では、また一つ、設備を自作した。受領確認札である。重要な資料へ、人間が短い識別札を仕込む。作業の前に、モデルへ資料ごとの札と、その資料にしかない一文を復唱させる。枚数の自己申告では通らない、消費者が手作りした配達証明である。

実働プロトタイプは、この稿を書いている間に六点から七点へ増えた。製品側へ求めたい設備も、七点になった。

家訓には、置き場所だけでは足りない。
配達証明と、受領証と、執行力が要る。

だから、三行目はこう深まる。文字を保存する場所がないのではない。確実に届き、正しく読まれ、権限と拘束力を持って働く場所――家訓を家訓として保存する場所が、売られていない。

荷物の配達には、受領印がある。
開発者向けの環境では、送信した内容やリクエストID、ツールの実行結果をログやトレースで確認できる。しかし、少なくとも私が使った一般向けの画面には、資料がどの経路を通り、どこまで担当モデルへ渡されたのかを利用者が確認できる配送記録がなかった。まして、その内容が正しく読まれ、以後の判断を拘束する家訓として受領されたことを示す印はなかった。

苦情に、仕様書を添える

Anthropicが、ここまで書いてきた現象を消費者問題として公式に認めているわけではない。だが、企業が問題と呼ばないことは、利用者の側に問題が存在しないことを意味しない。

開発者向けの文書には、モデルの特性と調整方法が書かれている。組織向けの商品には、権限と監査の設備がある。それにもかかわらず、個人向け高価格プランの利用者には、その知識と設備が日常の言葉と画面へ十分に翻訳されていない。

製品本体が正常に動いていても、重要な特性、注意点、復旧の方法が利用者へ届いていなければ、それ自体が消費者にとっての問題ではないか。AIだけを、説明責任の例外にする理由はない。

最後の発見を書き足す。

家訓が増えた結果、事故は確かに減った。だが、この稿を作っている途中で、家訓の確認、判子の待ち合わせ、受領の復唱、監査方法の監査が、記事を書く時間を侵食し始めた。

私が買ったのは、記事を書くためのAIであって、AI組織を事故なく運営するための管理者研修ではない。

利用者は成果物を作りたい。ところが製品は、成果物の前に、運用制度を作る仕事を要求する。そして制度を自作すれば、今度は、その制度の維持費が創作を食い始める。

家訓を毎回読み上げる大番頭のせいで、商いが遅くなる。最後に利用者が言う言葉は、決まっている。

もうええから、記事を書いてくれ。

だから本稿は、怒りの記事ではなく、発注書として閉じる。設備が製品の側にあれば、この維持費ごと、利用者の会話から消えるからである。

公式の編成例を。モデル別の権限表を。状態の判子欄を。壊れない家訓の棚を。引っ越しと復旧の手順を。そして、資料の受領印を。

見本が必要なら、添付できる。私の作業場に、事故のたびに自作した実物が揃っている。

最後に一つ、予告を置く。家訓を保存する設備ができても、それだけでは足りない。そもそも、どのモデルを、誰が、どの仕事に、どの程度使うべきなのか。その説明も、一般利用者向けの言葉と画面には、まだ十分に翻訳されていない。

AIの一族には、家訓が必要である。
そして、その一人ひとりには、処方箋が必要である。

注意事項

本稿は、筆者一人の作業場（Claude Max・一般向けアプリ）での一次観測と考察であり、Maxユーザー全体の体験へ一般化するものではない。法人利用の記述は、友人から聞いた利用の様子にもとづく対照であり、法人環境で同種の事故が起きないことを意味しない。Claudeファミリーの配置は2026年8月時点のものであり、モデルの入れ替わりや役割の見直しは、今後も起こり得る。

本文中のFable 5の発言は、与えられた役割と文脈を踏まえたAIの自己分析であり、製品内部の仕様の証明として扱っていない。台帳の誤用から導いた循環の構造は、観測した事故から導いた推論であり、完全な事故例の報告ではない。「財布が組織図を描く」は利用体験からの考察である。

カードの空読みは、確認できた時系列のみを記載し、内部原因は断定していない。新しいチャットでFable 5が資料を読めたとした回答も自己申告であり、筆者は各資料に固有の細部の照合によって傍証を取った。過去の作業でモデルが資料をすべて読めていたかどうかは、確認できないと述べるにとどめ、断定していない。

機能の有無は、記載時点で筆者が確認した公式資料の範囲による。

本稿で取り上げた公開投稿・公開記事は、Grokが検索で取得できた公開範囲に限られる。非公開、削除済み、検索対象外の投稿は含まれない。投稿者や執筆者の居住国、職業、技術経験、契約プラン、正確な利用モデルは確認できない場合が多い。Claude一般アプリ、Claude Code、API、Enterpriseに関する話が混在する可能性もある。

また、使い方を解説する記事が多いことは、利用者全体が困っていることを直接証明しない。反対に、肯定的な利用者が公開投稿をしない可能性もある。本稿では、これらを製品仕様の証拠や体系的な世論調査としてではなく、当時の公開空間に現れていた迷い、工夫、役割分担、肯定的評価の観測例として扱った。

参考欄

Anthropic：What is the Max plan?

Anthropic：Choosing a Claude Plan

Anthropic：Claude Fable 5 on your plan

Anthropic：Models overview

Anthropic：Prompting Claude Opus 5

Anthropic：How can I create and manage projects?

Anthropic：Use Claude's chat search and memory to build on previous context

Anthropic：How do usage and length limits work?

Anthropic：What is the Enterprise plan?

Anthropic：Set up role-based permissions on Enterprise plans

Making AI Functional with Workarounds: An Insider's Account of Invisible Labour in Organisational Politics（ACIS 2025採択・査読済み最終版あり、arXiv版も参照可）：組織の中で生成AIを実際に機能させるための回避策と、見えない労働を論じた研究

Beyond Replacement or Augmentation: How Creative Workers Reconfigure Division of Labor with Generative AI（CSCW 2025へ投稿されたと著者が記載するプレプリント）：創造的な仕事の中でAIへ役割を割り当て、協働の境界を繰り返し修復する労働を論じた研究

How-To Geek：長い会話でClaudeの利用枠を消費しないためのProjects活用法

MakeUseOf：Projectsを「最も有用な機能」と評価する記事

note：モデルごとに役割を割り当てる長文執筆の提案

Tech Noisy：Claude Projects機能の初心者向け解説