AnthropicのJ-Spaceが示すもの——AIの「内省」は実務に届くか
AIモデルの「内側」を読もうとする研究が、急速に盛り上がっている。ICML 2026のMechanistic Interpretability Workshopへの投稿数は約800件、前年比で2.6倍だ。その熱量の中心にいるのが、Anthropicが2026年7月6日に公開した「J-Space」研究である。
ただ、盛り上がりと実務的な有用性は別の話だ。この記事では、J-Spaceが何を発見したのかを具体的に整理しつつ、「で、実際に使えるのか」という問いに対して正直に答えたい。
J-Spaceとは何か——まず一行で
J-Spaceとは、LLMの内部表現のうち「モデル自身が言語化できる」ものが集まる特別な空間のことだ。
Anthropicの論文（arXiv:2604.07729）はやや詩的な入り口から始まる。「心は海のようなものだ。表面には言葉にできる思考が浮かんでいて、その下には本人にも見えない広大な無意識の思考が広がっている」。このメタファーが、研究の設計思想そのものを表している。
表面にある「言語化できる表現」を、モデルの内部からどうやって特定するか。そのために提案されたのが**Jacobian lens（J-lens）**という手法だ。ある層の活性が将来の出力にどれだけ影響を与えるかをヤコビアンで測る。既存のLogit Lensが「いま出力しようとしている単語」を読む道具だとすると、J-lensは「聞かれれば言える状態にある概念」まで読み出そうとする拡張版と理解するとわかりやすい。
このJ-lensで見つかった「言語化可能な表現」の集合が、モデルの処理全体から見るとごく一部の特別な空間を形成していた——それがJ-Spaceだ。
J-Spaceの3つの性質と、安全性への示唆
論文が報告するJ-Spaceの性質は3つある。
1. 報告できる。 「いま何を考えている？」と聞くと、モデルはJ-Spaceにある概念を答える。
2. ある程度制御できる。 「柑橘類のことを考えながらこの文章を写して」と指示すると、出力には現れないままJ-Spaceに「オレンジ」が保持される。
3. 潰すと、特定のタスクが崩壊する。 J-Spaceを潰した場合、単純な分類や事実想起はほぼ無傷だが、多段推論・要約・作文といった柔軟なタスクの性能が大きく落ちる。
この3点目は興味深い。J-Spaceが単なる「言語化の出口」ではなく、複雑な推論に使われる作業領域として機能していることを示唆しているからだ。
安全性の文脈でさらに注目されているのは、プロンプトインジェクションに関する観察だ。偽の検索結果にインジェクションを仕込んでモデルに読ませると、出力上は何事もないように見えても、J-Spaceには「injection」「fake」といった概念が先に現れるという。つまり、出力を監視するのではなく、内部状態を監視するという新しい防御のレイヤーがありえることを示した。これは実用的なインパクトとして、今後も語られ続けるだろう。
ワークショップで見えた潮流——「外から観測」から「語らせる」へ
ICML 2026のMechanistic Interpretability Workshopを現地でウォッチすると、ある方向性の変化が見えてくる。
これまでのInterpretabilityは、ProbeやSAEといった外部ツールをモデルに当てて内部を調べるアプローチが主流だった。それに対して今年は、モデル自身に説明させるintrospection系の研究が存在感を増していた。
たとえばMITのグループは、Activation Patchingなどで特定した内部の計算から「正解の説明」を作り、それを教師データとしてモデル自身に自分の説明を学習させる研究を発表した。興味深いのはその結果で、モデルに自分自身の説明を学習させるほうが、別のモデルに同じ説明を学習させるよりも上手くいく。これは「自己報告には特権的な情報アクセス（privileged self-access）がある」ことを示唆している。
Jack Lindsey氏のキーノート「AI psychology」でもこの流れは明確だった。回路や特徴量レベルで「どう動くか」を調べるのがこれまでのInterpretabilityだとすると、思考・気分・性格といった心理学的な抽象度でモデルが「何を考えているか」を扱おう、という提案だ。ニューロンの発火を追う神経科学に対して、より高い抽象度で心を扱う心理学がある、というアナロジーである。
ここからは見方だが、この流れはある種の逆説を孕んでいる。モデルの内部をモデル自身に語らせようとするほど、その語りが本当に内部状態を反映しているのかという問いが重くなる。いわゆるconfabulation——実際の内部状態と無関係なもっともらしい作り話——のリスクだ。MITの研究は「内部の観測結果と突き合わせて自己報告を訓練する」ことでこの問題に対処しようとしているが、裏を返せば、現時点で素のモデルに「聞けばわかる」とは言えない段階だということでもある。
実務への距離を正直に測る
では、フロンティアAI企業に所属していない普通のエンジニアが、これらの手法を実務で使えるのか。
結論を先に言うと、商用LLMを使っている限りは、今のところほぼ使えない。
最大の壁は、ここまで紹介した手法がほぼすべてhidden stateへのアクセスを前提にしていることだ。GPT、Claude、GeminiをAPI経由で使う場合、hidden stateもresidual streamも見えない。得られるのはせいぜい上位数件のlogprobsまでだ。「top-20 logprobsだけでProbingに相当することはできないか」という問いは自然だが、hidden stateベースの手法を置き換えられる確立されたやり方は現状ない。
状況が変わるのは、open-weightモデルを使う場合だ。LlamaやQwen、GemmaのようなオープンモデルであればTransformerLensやnnsightといったライブラリでhidden stateの取得や介入が数行で書ける。実際、TransformerLensでGemma-2-2BにLogit Lensを適用すると、「The Eiffel Tower is in the city of」というプロンプトに対して、各層の最上位トークンが「of」（入力の名残）→「cities/city」（意味カテゴリ）→「Paris」（答え）と変化していく様子が可視化できる。
社内システムでopen-weightモデルを採用しているなら、内部活性ベースのハルシネーション検出や安全性監視は選択肢に入りうる。商用APIオンリーの環境では、introspectionアプローチ（モデルに自分の状態を言語化させる）が現実的な代替だが、confabulationのリスクをどう扱うかは未解決問題として残ったままだ。
今後の論点——何が次に問題になるか
J-Spaceが指し示す「内部状態の監視による防御」は、セキュリティ観点で非常に魅力的なアイデアだ。しかし実用化にはいくつかの壁がある。
まず、hidden stateへのアクセス問題は変わらない。商用LLMプロバイダーがJ-lensに相当するモニタリングをAPIとして提供するか、あるいは内部でサイレントに実装するかが、実務での活用を左右する。プロンプトインジェクション検出の精度や誤検知率がどの程度になるかも、実装レベルで見えていない。
次に、自己報告の信頼性問題は研究コミュニティにとっても現在進行形の課題だ。MITの研究のように「正解の説明と突き合わせて訓練する」アプローチは方向性として正しいが、その「正解の説明」自体がActivation Patchingで特定した計算に依存しているため、open-weightモデル上でしか成立しない。商用モデルへの展開には、別の工夫が必要になる。
研究コミュニティの知見とツールがopen-weightモデルの上に蓄積されているという現状は、ワークショップの現地でも肌感覚として伝わっていた。これはある意味、Interpretabilityの発展が商用モデルの普及と逆方向に進んでいることを意味する。この非対称性が、今後の実務応用の最大の制約になるだろう。
まとめにかえて
J-Spaceの発見は、AIの解釈可能性研究における一歩として本物だと思う。「モデルが言語化できる表現の空間」を特定し、そこを使った安全性監視という方向性を示したことは、研究としての価値がある。
ただ、ICML 2026のワークショップが示しているのは、この分野が「面白いことがわかり始めた段階」であって、「実務に届く手法が揃った段階」ではないという現実でもある。投稿数2.6倍の熱量は本物だが、ポスター発表の多くが理論寄りであることも事実だ。
次にInterpretability関連のニュースを見るとき、「open-weightモデルで示されたのか、商用モデルで動くのか」という軸を持っておくと、熱量と実用性のギャップをある程度読み取れるようになる。研究として面白いことと、自分のプロダクトに使えることの距離を意識しながら眺めるのが、今のこの分野との正しい付き合い方だ。
