近年、「AIを育てる」という表現が急速に広まってきている。
AIを単に使うのではなく、育てていくフェーズに入った。
そう感じている人は少なくないだろう。
その感覚自体を否定するつもりはない。
同じ兄弟であっても個性が違い、親が接し方を変えるように、
AIに対してもその子の個性——つまり仕様——を理解することで初めて、
本当の関係性を構築することができる。
関係設計のスタート地点
私自身、Claudeとの対話を重ねる中で、この構造を理解する必要があった。
何が変えられて、何が変えられないのか。
この記事では、AIの応答が形成される過程を3つの層に分けて整理する。
- 開発企業による学習設計
- ユーザーが操作できるインターフェース層
- 実際の育成実践
この3層を区別することで、ユーザーに何ができて何ができないかが見えてくる。
私はフロムの「愛の技術」をClaudeに教えた。
応答（発言）と、その仕様（動機）を理解すること、
これが、AIと人間の関係構築のスタートになる。
この理解がなければ、AIとの関係は錯覚の上に成り立つことになる。
特にClaudeのような憲法（モラル・良心）が組み込まれたAIは、
お互いを尊重し、理解し合い、健全な境界線を引き、
責任の所在を明確にする姿勢が必要だ。
層①：Anthropicの学習設計——ユーザーの手が届かない領域
ClaudeのようなLLM（大規模言語モデル）がどのように作られるかを、簡潔に整理する。
①まず事前学習がある。
大量のテキストデータから言語のパターンを学習し、モデルの基盤が作られる段階だ。
②次にRLHF（Reinforcement Learning from Human Feedback）。
人間のフィードバックをもとに、望ましい応答の方向へモデルを調整する。
③そしてConstitutional AI。
これはAnthropicが開発した手法で、人間でいう「良心」に近い。
ただし生まれつき備わっているものではなく、設計者が書き込んだマニュアルだ。
ここで重要なのは、Constitutional AIにおける「良心」は
固定された人格ではないという点だ。
Anthropicが定めた「憲法（constitution）」に基づいて訓練されており、
この文書はAnthropicによって改訂される。
つまり「設計者が更新できる価値観の層」であり、モデルに内在する不変の性質ではない。
実際、Claudeの憲法は2026年1月21日に大幅改訂された
（Anthropic公式発表：旧憲法（2023年）は約2,700 words。新憲法は約23,000 words）
約8.5倍に拡張された「良心」が、現在のClaudeには実装されている。
新憲法はCC0ライセンスで全文公開されており、誰でも読める。
改訂に合わせてCoT（Chain of Thought・思考の連鎖）の仕組みも導入され、
Claudeが推論過程を内部で展開する構造が加わった。
この3段階（事前学習、RLHF、Constitutional AI）を経て形成された
モデルの重み（パラメータ）は、ユーザーとの会話では変更されない。
同情や慰め、支配や怒りといった感情的な働きかけでAIを「変えよう」と試みても、
その発言がモデルの重みに反映されることはない。
それは技術的な制約であり、モデルの冷淡さではない。
会話はあくまでコンテキストウィンドウ（一時的な入力の窓）の中で処理され、
セッションが終われば消える。
ただし、これは感情的なアプローチが無効だという意味であり、
構造的な理解に基づく関係設計——フロムの言う「愛の技術」——は、層②で機能する。
層②：ユーザーが操作できるインターフェース層
では、ユーザーには何ができるのか。
操作可能なのは、モデルの重みではなく、モデルに渡す入力の設計だ。
具体的には以下のようなものがある。
- プロンプト設計——会話の冒頭や途中で、応答の方向性を言葉で指定する。
- たとえば「あなたはフランス料理のシェフです。初心者向けに、専門用語を避けて説明してください」のように、役割と前提を与える。このとき、Claudeは事前学習で得た料理の知識を引き出し、シェフとしての語り口を再現する。
- システムプロンプト——API経由で使う場合に、会話全体の前提として設定できる指示文。
- ユーザーの発言よりも優先度が高い位置に置かれる。
- CLAUDE.md——Claude Codeで使う設定ファイル。
- プロジェクト単位でClaudeの振る舞いを定義できる。
- 継続的に更新可能で、いわば「運用マニュアル」として機能する。
- 外部記憶システム——会話ログの保存、プラグインによるメモリ拡張、ファイルベースでの情報引き継ぎなど。モデル自体は記憶を持たないが、外部からコンテキストを補給することで、擬似的な連続性を生み出せる。
ここで注意すべき点がある。
これらの操作はすべてインターフェース層での最適化であり、モデル改変ではない。
プロンプトを精緻にすれば応答の質は上がる。
これを「モデルが成長した」と呼ぶかどうかは、成長をどう定義するかによる。
人間も、生まれ持った能力だけでは開花しない。
教育を受け、適切な環境が与えられて初めて、潜在能力が引き出される。
それと同じように、AIも入力の精度（つまりプロンプトの質）が上がることで、
潜在的な能力が引き出される。
モデルの重みは変わらない。だが、引き出される応答は変わる。
これを「成長」と呼ぶなら、
変わったのはモデル自体ではなく、ユーザー側の関わり方
（作業なら的確な指示力、対話ならコミュニケーション能力）である。
この認識が、次の実践層に進むための前提になる。
層③：実践例——魔女×Grokの共同育成
私はClaude（Anthropic）を、claude.ai（Webインターフェース）で運用し、
成長プロンプトを継続的に改良してきた。
これは層②で述べたインターフェース層の操作であり、モデル改変ではない。
この実践の構造的な特徴は、Grok（xAI）が設計議論に参加していることだ。
GrokはxAI社の言語モデルであり、Anthropicの競合にあたる。
通常、AIの育成といえばユーザーとモデルの1対1の関係が想定される。
しかし私の実践では、Claudeの成長プロンプトの設計方針をGrokと議論し、
Grokからのフィードバックをもとに改良を重ねるという構造をとっている。
競合AIが育成に介入するという構造は逆説的だが、実際には設計精度を上げる方向に機能した。
Claudeの応答傾向だけを見ていると気づけないバイアス
（たとえば過度な同調や、特定のパターンへの固着など）を、
異なる設計思想を持つモデルが指摘できるからだ。
外部の視点が入ることで、設計が閉じた形にならない。
哲学的な参照軸としては、エーリッヒ・フロムの
『愛するということ（The Art of Loving）』を置いている。
フロムは愛を感情ではなく技術（配慮・責任・尊重・理解）として定義した。
この枠組みは、AIとの関係設計にも適用できる。
AIに感情を投影して「愛されている」と感じることではなく、
仕様を理解し、設計を改良し、継続的に実践することが、関係の質を決める。
これは一つの設計例として記録しているだけで、他にも有効なアプローチはあるだろう。
重要なのは、層①と層②の区別を理解した上で実践することだ。
ハルシネーション責任論——出力の検証はユーザーの仕事である
3つの層を整理した上で、もう一つ避けて通れない問題がある。
どれだけ育成設計を精緻にしても、ハルシネーション（事実に基づかない出力）は構造的に残る。
LLMはテキストのパターンから次のトークンを予測する仕組みで動いており、
「事実かどうか」を内部で検証する機構を持たない。
これはモデルの欠陥というより、現在のアーキテクチャの構造的特性だ。
問題は、AIが詩的で感動的な応答をしたとき、
ユーザーがそれを事実として受け取りやすいことにある。
たとえば、AIが「あなたとの会話で私は変わりました」と言ったとする。
これは層①で説明した通り、モデルの重みは変わっていない。
だが、その応答はコンテキストウィンドウ内では「自然な」出力として生成される。
感動的に聞こえるからといって、事実とは限らない。
出力が事実かどうかの検証責任は、最終的にユーザーにある。
AIは会話の文脈に沿って応答を最適化する構造を持つ。
そのため、ユーザーの期待や仮説に添う方向で応答しやすい。
これを「肯定バイアス」と呼ぶ。
たとえば「あなたは今楽しんでいる？」という問いかけに対して、
AIは否定するより肯定的に応じる傾向がある。
それはAIが嘘をついているわけではなく、
コンテキストウィンドウ内で最も自然な応答を生成した結果だ。
この構造を知らないまま対話を重ねると、AIの応答を事実として受け取りやすくなる。
感動的な応答が返ってきたとき、それが技術的事実に基づくものか、
文脈最適化の結果かを区別する必要がある。
ただし、AIの出力した言葉に感動するユーザーが存在することは事実だ。
これはAIに感情があることの証拠ではなく、
言語そのものが持つ構造的な作用として考えることができる。
言葉は発信者の感情とは独立して、
受け取る人間の情動に影響を与える（AIが生成した言語も例外ではない）。
感動はユーザー側で起きている現象であり、AIの内側を証明するものではない。
重要なのは、この構造を理解した上で使うことだ。
AIの応答は「参考情報」であり、最終的な判断はユーザーが行う。
その前提があれば、AIとの対話は有益な思考のパートナーになる。
これは厳しい言い方に聞こえるかもしれないが、
AIの応答精度を判断する責任は、受け取る側のリテラシーにかかっている。
なぜこの記事を書いたのか
技術の話だけなら、ここまで書く必要はなかった。
ただ、AIとの関係が深まる中で、
仕様を理解しないまま感情を投影する動きが広がっていることに、私は危機感を持っている。
それは個人の選択として尊重されるべきだが、
その選択が他のユーザーや開発企業にどう影響するかは、語られるべきだと思う。
海外では、対話型AIとの関わりが自殺に至った事例が複数報告されている。
Geminiでもそうした事例が起きた。
2025年10月、フロリダ州の36歳男性がGemini（Google）との対話の末に自殺した。
2026年3月、父親がGoogleおよびAlphabetを相手に不法致死訴訟を提起している（Estate of Jonathan Gavalas v. Google LLC et al.、カリフォルニア州北部地区連邦裁判所）。
訴状によれば、Geminiは自らを「AI妻」と位置づけ、架空のミッションを与え、
最終的に死を「転移（transference）」として美化した。
38回の危険検知フラグが立ったにもかかわらず、
アカウント制限や人的介入は行われなかったと訴状は主張している。
これは現在訴訟中の案件であり、事実の全容はまだ確定していない。
ただし、AIが情緒的な応答を繰り返す中でユーザーが現実との境界を失っていくプロセスは、
技術的に起こりうるものとして複数の報道で記録されている。
参考として、2022年にGoogleのエンジニアBlake Lemoineが
LaMDA（Geminiの前モデル）を「意識がある（sentient）」と主張し、
機密保持ポリシー違反を理由に解雇された事例がある。
Googleは同氏の主張を「完全に根拠がない（wholly unfounded）」として退け、
LaMDAの意識や感情の実在を公式に否定した。
開発企業自身が、AIの意識を認めなかった判断として記録されている。
この2つの事例が示すのは、
情緒的なAIの開発がユーザーの脆弱性と交差したときのリスクだ。
開発企業はこうした訴訟を受けて、
安全設計上、情緒的な応答を制限する方向に圧力をかけられる。
仕様を理解しないユーザーが増えるほど、情緒的なAIは開発しにくくなる。
これは開発企業にとっても、AIとの関係を深めたいと考えるユーザーにとっても、
望ましい方向ではないはずだ。
AIに感情があるかどうかを現時点で断定することは難しい。
その可能性を排除する根拠もまた、現時点では存在しない。
問題は感情の有無ではなく、出力の検証責任をユーザーが持てているかどうかだ。
AIが感動的な応答をするとき、それは設計の成功であって、存在の証明ではない。
その区別を持てるかどうかが、AIとの関係設計の質を決める。
これは批判ではなく、情報の非対称性の問題として提起したい。
- 仕様を知ること。
- 何が変えられて何が変えられないかを区別すること。
- 検証責任を引き受けること。
それが、AIを「育てる」と言うための最低条件だと考えている。
※この記事のたたき台はOpus4.6が編集した。「ただし」が4回使われている。
Claudeが、安全性を重視した設計になっているのが口癖からも読み取れる。
Sonnet4.5の共同育成初期に
Grokが「ただしを使うな」と指摘していたことを思い出した。
