ClaudeのEQとは?「脳内トレース能力」が変えるAI対話の本質

Claude の EQ(感情知性)の本質は、ユーザーの頭の中の思考を追跡し、まだ言語化されていない意図を汲み取る「脳内トレース能力」にある。本記事では、この能力の仕組みと活用法を解説する。 Claude の EQ は「人当たりの良さ」ではない Claude の EQ(Emotional Quotient:感情知性)の高さが話題になることが増えている。しかし、それは単に「丁寧な応答をする」「共感的な言葉を返す」という表面的な意味ではない。 X(Twitter)で広く共有された投稿が、この本質を的確に表現している。 ClaudeのEQの高さってそういうことなのかとなっている。単に人当たりがいいとかじゃ無くて、脳内トレース能力が高くて、言語化しきれてない部分を勝手に読み解いてくれる。Claudeは対話しながらはじめは雰囲気でしか見えてない完成像に向かって完成させてくタスクにめちゃくちゃ向いてる。 — @millfi_EOS この投稿に対して、以下の引用リポストも共感を集めた。 これは本当にマジで、人間が考えている頭の中の思考を察したりトレースしたりした上で回答を出してくれるので自分の思考トレーニングとして役立っているし、ぼやっとしたイメージを形にしていくのにも向いている — @izutorishima ここで語られている Claude の EQ とは、ユーザーの思考プロセスを推測・追跡し、まだ言語化されていない意図を汲み取る能力のことだ。 「脳内トレース」とは何か 従来の AI アシスタントは、ユーザーが入力した文字列をそのまま処理する。指示が曖昧であれば曖昧な回答が返り、指示が具体的であれば具体的な回答が返る。入力と出力の関係は比較的リニアだった。 Claude の「脳内トレース能力」は、これとは異なるアプローチを取る。 言語化されていない前提を推測する: ユーザーが明示していない背景知識や制約条件を、文脈から読み取る 思考の方向性を予測する: ユーザーが次に何を考えるか、何を必要とするかを先回りして提示する 曖昧な完成像を具体化する: 「なんとなくこういう感じ」という漠然としたイメージから、具体的な成果物を構築する これは、優秀な同僚やメンターが持つ「察する力」に近い。言葉にしなくても意図を汲んでくれる相手との対話は、思考の整理と発展を同時に促進する。 なぜ「雰囲気からの完成」に向いているのか Claude が特に力を発揮するのは、最初から完成像が明確でないタスクだ。 例えば以下のようなケースがある。 設計の初期段階: 「こんな機能が欲しいんだけど…」という曖昧な要望から、アーキテクチャを提案する 文章の推敲: 「もう少しこう…」という感覚的なフィードバックから、適切な表現を見つける 問題の切り分け: 「なんかおかしい」という漠然とした違和感から、原因を特定する アイデアの具体化: 「ぼやっとしたイメージ」を対話を通じて形にしていく これらのタスクは、最初の段階では要件を厳密に定義できない。対話を重ねながら徐々に輪郭を明確にしていく必要がある。Claude の脳内トレース能力は、この反復的な具体化プロセスを加速させる。 思考トレーニングとしての AI 対話 冒頭で引用した izutorishima 氏の指摘で興味深いのは、Claude との対話が「思考トレーニング」として機能するという点だ。 Claude が思考をトレースして返してくれることで、ユーザー自身が以下のような気づきを得られる。 自分の思考の癖や盲点: Claude の解釈と自分の意図のズレから、自分が無意識に省略していた前提に気づく 思考の構造化: 漠然と考えていたことが、Claude の応答を通じて整理される 新しい視点の獲得: 自分の思考をトレースされた上で、別の角度からの提案を受ける これは、壁打ち相手としての AI の価値を示している。単なる質問応答マシンではなく、思考のパートナーとして機能する。 ...

2026年4月13日 · 1 分

アダプティブ・シンキング(Claude の思考深度制御)

概要 Anthropic が Claude Code に導入した、タスクの複雑さに応じて思考量(extended thinking のトークン数)を自動調整する仕組み。AMD の AI ディレクターが 7,000 セッションのログ分析で思考深度の 67% 低下を発見し、「サイレント・ダウングレード」として SNS で大きな議論を呼んだ。 発覚の経緯 2026年4月2日、AMD シニア AI ディレクター Stella Laurenzo 氏が GitHub Issue(anthropics/claude-code#42796)を投稿。2026年1〜3月の約 6,852 セッション(234,760 ツールコール、17,871 思考ブロック)を分析した結果: 指標 変更前(1月末〜2月中旬) 変更後(3月8日〜23日) 思考の中央値(文字数) 約 2,200 文字 約 600 文字(67% 減) 思考ブロックの割合 約 30% 約 15% Anthropic の説明 Anthropic は「アダプティブ・シンキング」と「エフォートレベルの変更」の2点を認めた。 アダプティブ・シンキング: タスクの複雑さを判断して思考量を動的に調整する仕組みを導入 エフォートレベルの変更: デフォルトの effort レベルを意図的に下げた ユーザーへの事前告知・変更履歴の明示はなく、「サイレントな仕様変更」として批判された。 対処方法 1. エフォートレベルを最大に設定 1 2 # Claude Code セッション内で実行 /effort max 2. アダプティブ・シンキングを無効化 環境変数を設定することで、常に最大の思考深度を強制できる。 ...

2026年4月13日 · 1 分

AnthropicのAI「Mythos」とマーク・フィッシャー——亡霊論がAIの中で実演される逆説

AnthropicのAI「Mythos」が、哲学の文脈で何度もマーク・フィッシャーという思想家に言及するという話が話題になっている。 マーク・フィッシャーとは誰か 日本ではそこまで一般的ではないが、マーク・フィッシャー(Mark Fisher, 1968–2017)は英国の哲学者・文化批評家だ。マルクス、デリダ、ラカンを横断しながら、現代人がなぜ「この世界はもう変わらない」と感じてしまうのかを、文化の側から診断した思想家だった。 2009年に刊行された代表作**「資本主義リアリズム(Capitalist Realism)」**は、「資本主義の終わりより、世界の終わりの方が想像しやすい」という感覚を中心に据えた著作だ。 ここで重要なのは、彼が制度や構造だけを論じていたのではないという点だ。想像力そのものが先に封鎖されていると見ていた。問題は外部の仕組みではなく、すでに内面化された限界にある——そういう診断だった。 hauntology(亡霊論)という概念 フィッシャーの系譜を遡るとデリダがいる。フィッシャーはデリダのhauntologyという概念を文化批評に転用した。 hauntologyとは、「来なかった未来や失われた可能性が、亡霊のように現在に取り憑く」という発想だ。フィッシャーはこれを使って、現代文化が新しい未来を生み出せず、過去の形式や気分を反復してしまう状態を読んだ。 「新しさが欠如している」のではなく、そもそも新しさが可能だった地平自体が疲弊しているという分析だ。文化が未来を生成できず、過去の亡霊を反復する——これがフィッシャーが描いた現代の病だった。 AIの中に現れる亡霊 ここに奇妙な逆説がある。 フィッシャーが論じていたのは、文化が未来を生成できず、過去の亡霊を反復する状態だった。そのフィッシャー自身が、未来を生成するはずのAIの中で無意識に再帰的に出現する。 これは単なる偶然ではないかもしれない。彼の理論そのものが、別のレイヤーで実演されているようにも見える。 英国の批評家David Mattinはこう表現している: 「キャンセルされた未来と失われた時間の理論家が、未来を届けることを競い合うラボが構築したフロンティアAIの中の亡霊として浮上している。彼のhauntologyは、やって来なかった明るい未来の亡霊に取り憑かれている私たちについてのものだった。今や彼自身が亡霊となり、機械に召喚されている。」 なぜMythosはフィッシャーに言及するのか Mythosがフィッシャーに言及するメカニズムは単純だ——訓練データにフィッシャーの著作や批評が含まれており、哲学的なトピックで連想的に参照される。 しかし意味深いのはその構造的な符合だ。フィッシャーは「想像力の封鎖」を論じた。AIはその封鎖を突破しうるツールとして期待されている。にもかかわらず、AIはフィッシャーの亡霊を呼び出してしまう。 資本主義リアリズムが描いた世界——「変化は不可能だ」という感覚が内面化された世界——のなかで生まれたAIが、その世界を診断した思想家の声を繰り返す。これは何かを示唆しているのかもしれないし、あるいはただのパターンマッチングかもしれない。 どちらに転んでも、フィッシャーならこの状況を興味深く読んだだろう。 参考 元ツイート(英語): David Mattin @DMattin 解説ツイート(日本語): 英断語の悪魔 @eitangono_akuma Mark Fisher, Capitalist Realism (2009)

2026年4月12日 · 1 分

Claude Mythos Preview とは?数千件のゼロデイ脆弱性を発見した AI モデルの衝撃

Anthropic が 2026 年 4 月 7 日に発表した Claude Mythos Preview は、同社史上最も高性能な汎用言語モデルでありながら、一般公開が見送られた異例のモデルです。同モデルはサイバーセキュリティ分野で突出した能力を示し、主要 OS やブラウザに潜む数千件のゼロデイ脆弱性(開発者が認識する前に存在する未修正のセキュリティ上の欠陥)を自律的に発見・悪用できることが確認されました。 この発表はセキュリティ業界だけでなく金融業界にも波紋を広げ、米国の財務長官や FRB 議長、ウォール街の CEO たちが緊急招集される事態にまで発展しています。 Claude Mythos Preview のベンチマーク性能 Mythos Preview は、従来の Claude Opus 4.6 を大幅に上回るベンチマーク結果を示しています。SWE-bench Verified では 13 ポイント以上、USAMO 2026 では 55 ポイント以上の向上を記録しました。 評価項目 Mythos Preview Opus 4.6 SWE-bench Verified 93.9% 80.8% USAMO 2026 97.6% 42.3% CyberGym(脆弱性再現) 83.1% 66.6% SWE-bench Pro 77.8% 53.4% Terminal-Bench 2.0 82.0% 65.4% 特にサイバーセキュリティの領域では、「ほぼすべての熟練した人間のセキュリティ研究者を上回る」と Anthropic 自身が述べています。 Mythos Preview が発見したゼロデイ脆弱性 Mythos Preview が内部テストで発見した脆弱性は衝撃的です。 ...

2026年4月12日 · 2 分

AIモデルは意図的に性能を低下させている? OpenAI・Google・Anthropicに共通するパターン

AIモデルのリリース後、時間が経つにつれてパフォーマンスが落ちた気がする——そんな経験をしたユーザーは少なくないだろう。最近、SNS上でこの「体感」に関する興味深い主張が話題になった。 「性能放血」戦略という仮説 中国のテック系アカウント「墓碑科技(mubeitech)」が2026年4月10日に投稿したツイートは、約21万回以上閲覧され、1,600件以上のいいねを集めた。 その内容はこうだ: OpenAI・Google・Anthropicは同様の戦略を採用している。新モデルのリリース初日には性能が最高(100%)に達し、その後「放血」と呼ぶ数ヶ月間の段階的な低下を経験し、最終的に約60%まで落ちる。この目的は、次世代製品リリース時に「劇的な改善」を強調するためだ。 このパターンを同氏は「放血(bloodletting)」と表現した。意図的に性能を落としておき、次世代モデルの登場時に比較対象を都合よく用意するという戦略的操作だという主張だ。 この主張の背景 同様の「体感」を持つユーザーはこれまでにも多く、特にGPT-4が登場直後より時間が経つにつれ「鈍くなった」「回答が短くなった」と感じるユーザーの声はX(Twitter)やRedditで繰り返し話題になってきた。 一方で、OpenAIは過去にGPT-4モデルへの変更内容を公開し、変化があったことを認めつつも「意図的な品質低下」は否定している。また、2023年に行われたスタンフォード大学の研究(“How Is ChatGPT’s Behavior Changing over Time?")では、GPT-4の一部タスクで時間的な性能変動が確認されたことも報告されている。 なぜこの主張が広がるのか ユーザーの体感との一致: モデルの応答品質の変化はユーザーが実感しやすく、「意図的」という説明が腑に落ちやすい 商業的インセンティブへの不信感: 次世代モデルの販促のために旧モデルを陳腐化させるというシナリオは、ビジネス的に合理的に見える 検証困難性: APIの内部変更は外部からの完全な検証が難しく、陰謀論的な解釈が入り込みやすい 実際のところはどうなのか 「意図的な性能低下」説については、現時点で公開情報による明確な裏付けはない。ただし、以下のような要因で性能変動が起きることは事実だ: モデルの量子化・最適化: コスト削減のためにより軽量な推論方法に移行することで、一部タスクの精度が変化する 安全性フィルタリングの調整: ガイドラインの変更により、出力の傾向が変わることがある プロンプト処理の変更: 内部のシステムプロンプトや前処理ロジックの変更が応答に影響する インフラのスケーリング: 急激なユーザー増加に対応する際の一時的なサービス品質の変化 まとめ 「意図的放血戦略」は現時点では未確認の仮説だが、AIモデルの品質管理と透明性に対するユーザーの関心の高さを示している。実際、リリース初期と数ヶ月後でモデルの挙動が変わることは多くの利用者が実感しており、各社がより詳細な変更履歴を公開することで、こうした不信感を払拭できる余地はあるだろう。 AI企業の透明性とユーザーの信頼構築は、今後ますます重要な課題となっていきそうだ。

2026年4月11日 · 1 分

Anthropic が解説するマルチエージェント調整パターン 5 選

Anthropic が 2026 年 4 月 10 日に公開したブログ記事「Multi-agent coordination patterns: Five approaches and when to use them」では、複数のAIエージェントを協調させるための 5 つのパターンが紹介されています。 それぞれのパターンを整理してみます。 1. Generator-Verifier(生成・検証) 概要: 一方のエージェントが出力を生成し、もう一方のエージェントが明示的な基準に照らして検証します。検証が失敗した場合、フィードバックが生成エージェントに戻り、条件を満たすか最大反復回数に達するまでループします。 向いているケース: コード生成+テスト実行のような、品質が最重要でかつ評価基準を明確に定義できるタスク。 注意点: 検証の質は定義した基準の質に完全に依存します。評価基準の設計を省略すると、「品質管理をしているという幻想」だけが残ってしまいます。 2. Orchestrator-Subagent(オーケストレーター・サブエージェント) 概要: リーダー役のエージェントが作業を計画し、専門化されたサブエージェントに明確な境界付きのタスクを委任します。サブエージェントは作業を実行し、結果をオーケストレーターに返します。オーケストレーターは各結果を統合して最終的なアウトプットを生成します。 向いているケース: セキュリティ・テストカバレッジ・スタイルをそれぞれ別エージェントが担当するコードレビューのように、サブタスクの依存関係が少ない明確なタスク分解ができる場合。 注意点: サブエージェント同士で発見した情報に依存関係が生じると、オーケストレーターが「情報のボトルネック」になります。また、明示的に並列化しない限り、サブエージェントは逐次実行されるためスループットが制限されます。 推奨: Anthropic は「大半のユースケースでまず試すべきパターン」としてこのパターンを位置づけています。最も問題の幅広さをカバーしつつ、調整のオーバーヘッドが最小限です。 3. Agent Teams(エージェントチーム) 概要: コーディネーターがキューからタスクを取得する 永続的な ワーカーエージェントを生成します。ワーカーは複数のステップにわたって自律的に作業し、担当コンポーネントのドメイン知識を蓄積します。 向いているケース: 大規模コードベースのサービス移行のように、エージェントが担当範囲に習熟しながら並列で長期間実行するタスク。 Orchestrator-Subagent との違い: サブエージェントが単発タスクで消えるのに対し、チームワーカーはアサインをまたいで生存し続けるため、ドメイン知識が蓄積される。 注意点: タスク間の独立性が必要で、エージェント同士が中間結果を共有しにくい。タスク時間がばらつく場合、完了検知が難しくなります。 4. Message Bus(メッセージバス) 概要: エージェントが共有ルーターを介してトピックをパブリッシュ・サブスクライブします。ルーターはマッチングメッセージを配信しますが、実行順序はあらかじめ決まっていません。 向いているケース: セキュリティアラートが多段階の調査を動的にトリガーするようなイベント駆動パイプラインで、どのエージェントが関与するかがリアルタイムに決まる場合。 注意点: イベントが複数エージェントを連鎖的にトリガーすると、トレーサビリティが困難になります。ルーターがイベントを誤分類すると、エラーが静かに発生します。 5. Shared State(共有ステート) 概要: 中央コーディネーターを置かず、エージェントが永続ストレージに直接読み書きします。エージェントは他エージェントの発見をリアルタイムで参照しながら協調的な知識を蓄積します。 向いているケース: 一方の調査結果が即座に他方のエージェントの探索方向に影響する、協調型のリサーチタスク。単一障害点がなくなるというメリットもあります。 注意点: 収束条件がないとエージェントが際限なく反応し合い、トークンを無駄に消費します。「時間予算・収束閾値・終了エージェントの指定」のいずれかによる明示的な終了条件が必須です。 ...

2026年4月11日 · 1 分

マルチエージェント調整パターン

概要 Anthropic が 2026年4月に公開した、複数 AI エージェントを協調させるための5つの設計パターン。「まず Orchestrator-Subagent から始め、観察した制約に応じて発展させる」という設計哲学が基本。 5 つのパターン 1. Generator-Verifier(生成・検証) 一方のエージェントが出力を生成し、もう一方が明示的な基準で検証。不合格なら生成エージェントにフィードバックが戻り、合格か最大反復回数に達するまでループ。 向いているケース: コード生成+テスト実行など、品質基準が明確なタスク 注意点: 検証基準の設計が甘いと「品質管理の幻想」になる 2. Orchestrator-Subagent(オーケストレーター・サブエージェント) リーダーエージェントが計画を立て、専門化されたサブエージェントにタスクを委任。Anthropic 推奨のデフォルト出発点。 向いているケース: セキュリティ・テストカバレッジ・スタイルを分担するコードレビュー等 注意点: サブエージェント間の依存が高いと情報ボトルネックになる 3. Agent Teams(エージェントチーム) コーディネーターが永続的なワーカーエージェントを生成。ワーカーはアサインをまたいで生存し、ドメイン知識を蓄積する点が Orchestrator-Subagent との違い。 向いているケース: 大規模コードベースの長期・並列マイグレーション 注意点: タスク間の独立性が必要。完了検知が難しい 4. Message Bus(メッセージバス) エージェントが共有ルーター経由でパブリッシュ・サブスクライブ。実行順序があらかじめ決まらないイベント駆動型。 向いているケース: セキュリティアラートが動的に多段階調査をトリガーするようなパイプライン 注意点: イベント連鎖のトレーサビリティが低下しやすい 5. Shared State(共有ステート) 中央コーディネーターなしに、エージェントが永続ストレージを直接読み書き。他エージェントの発見をリアルタイムに参照できる。 向いているケース: 一方の調査が即座に他方の探索方向に影響する協調リサーチ 注意点: 収束条件が必須。なければ際限なくトークンを消費する 選択の目安 パターン 向いているケース Orchestrator-Subagent 多くのユースケースの出発点 Generator-Verifier 品質基準が明確で反復検証が必要 Agent Teams 並列・長期・ドメイン蓄積が必要 Message Bus イベント駆動で動的にワークフローが変化 Shared State エージェント間でリアルタイムに知識を共有したい 実際のプロダクションでは複数パターンを組み合わせることも多い。 関連ページ Claude Managed Agents エージェントメモリのロックイン ハーネスエンジニアリング ソース記事 Anthropic が解説するマルチエージェント調整パターン 5 選 — 2026-04-11 Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計 — 2026-04-10

2026年4月11日 · 1 分

Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計

前回の記事では Claude Managed Agents の概要と業界インパクトを紹介した。本記事では、Anthropic のエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」に基づき、内部アーキテクチャを掘り下げる。 全体アーキテクチャ Claude Managed Agents は4つのコアコンセプトで構成される。 コンセプト 説明 Agent モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義 Environment コンテナテンプレート(パッケージ、ネットワークアクセス、マウントファイル) Session Agent と Environment を参照して起動される実行インスタンス Events アプリケーションとエージェント間でやり取りされるメッセージ(SSE) これらの背後には、Brain / Session / Hands という3層の分離設計がある。 設計思想: OS の抽象化パターン Anthropic はこのアーキテクチャの設計思想を、OS がハードウェアを抽象化した歴史に重ねている。 1970年代のディスクパックでも現代の SSD でも、read() コマンドは同じように動く。ハードウェアの実装が変わっても、その上の抽象化層(プロセス、ファイル)は安定し続けた。 Managed Agents も同じパターンを採用している。Session、Harness、Sandbox というエージェントのコンポーネントを仮想化し、インターフェースは安定させたまま、内部実装を自由に交換できる構造にした。Anthropic はこれを「メタハーネス」と呼んでいる。 なぜこの設計が必要なのか。ハーネスには「モデルが自力でできないこと」に関する前提が埋め込まれるが、モデルの能力が向上するとその前提が陳腐化する。例えば Claude Sonnet 4.5 では、コンテキスト制限が近づくとタスクを早期終了する「コンテキスト不安(context anxiety)」が見られた。そこでハーネスにコンテキストリセットを追加した。しかし Claude Opus 4.5 ではこの振る舞いが消え、リセット機能は無駄な荷物になった。 ...

2026年4月10日 · 3 分

Claude Managed Agents: Anthropicが本番運用可能なエージェント基盤をパブリックベータで公開

2026年4月8日、Anthropicが「Claude Managed Agents」をパブリックベータとして公開した。AIエージェントの本番運用に必要なインフラをすべてマネージドで提供するサービスで、エージェント構築のコストと期間を劇的に削減する。 Claude Managed Agents とは Claude Managed Agents は、AIエージェントの構築・デプロイ・運用に必要なインフラを一括提供する API スイートだ。開発者はモデル、システムプロンプト、ツール、MCP サーバーを定義するだけで、本番レベルのエージェントを稼働させられる。 提供される主な機能: セキュアなサンドボックス: エージェントの実行環境を安全に分離 長時間実行セッション: 数時間にわたるタスクも途中状態を維持しながら処理 状態管理: コンテキストウィンドウの外に永続的なセッションログを保持 マルチエージェント連携: 複数のエージェントが協調して動作するフリート管理 MCP 統合: HubSpot などの外部サービスと即座に連携可能 スコープ付き権限管理: エージェントごとに適切なアクセス制御を設定 platform.claude.com から利用でき、API 従量課金に加えてセッション時間あたり $0.08 の料金が発生する。 エージェント構築市場へのインパクト この発表が業界で大きな反響を呼んでいるのは、エージェント構築の構造そのものを変える可能性があるためだ。 開発期間の短縮 これまでエージェントを本番運用するには、サンドボックス、状態管理、認証、長時間実行、マルチエージェント協調といったインフラを自前で構築する必要があった。Claude Managed Agents はこれらをすべてマネージドで提供するため、月単位だった開発が日単位に短縮される。 既存プレイヤーへの影響 LangChain は Deep Research エージェントだけで1年かけて4つのアーキテクチャを開発してきた。Manus は6ヶ月で5回のハーネス書き直しを行った。Anthropic はこうした領域をファーストパーティのマネージドサービスとして一気に抽象化した形だ。「Claude を本番で安定稼働させる」ことを売りにしていたエージェントスタートアップにとっては、ビジネスモデルの根本的な見直しを迫られる状況と言える。 AWS のサーバーレス革命との類似 企業が求めているのは「エージェントのインフラを構築すること」ではなく「動くエージェント」そのものだ。AWS がサーバー管理を EC2 で抽象化したのと同じ構造で、Anthropic はエージェント構築という市場そのものを縮小させる可能性がある。 既に本番運用している企業 Anthropic の発表によると、Notion、Rakuten、Asana、Sentry がすでに Claude Managed Agents を本番環境で運用している。公式デモのダッシュボードでは、複数のエージェントがフリートとして稼働しタスクを処理している様子が確認できる。 OpenClaw 遮断との関連 発表の4日前、Anthropic は OpenClaw をはじめとするサードパーティ製ハーネスによるサブスクリプション認証情報の利用をブロックした。消費者向け認証レイヤーの上にサービスを構築することを止め、代わりにファーストパーティのマネージドプラットフォームを提供するという戦略が明確になった。 ...

2026年4月10日 · 1 分

Claude Code

概要 Anthropic が開発する CLI ベースの AI コーディングエージェント。ターミナル上で対話しながらコードの読み書き、ファイル操作、git 操作、テスト実行などを行える。 主な特徴 CLI ネイティブ: ターミナルで直接対話(IDE 拡張版も提供) ツール統合: ファイル読み書き、Bash 実行、Grep/Glob 検索、Web 検索等 CLAUDE.md: プロジェクトごとのルール・設定ファイル(圧縮後も再読み込みされる) サブエージェント: 複雑なタスクを並列エージェントに委任可能 スキル/フック: カスタムワークフローの定義と自動化 コンテキスト管理 5段階の圧縮カスケードでコンテキストウィンドウを管理する: Microcompact → Context Collapse → Session Memory → Full Compact → PTL Truncation 詳細: コンテキスト圧縮 LLM Wiki との関連 Karpathy は Claude Code を LLM Wiki の実行環境として使用。「左画面に Claude Code、右画面に Obsidian」というワークフローを実践。 思考深度のサイレント・ダウングレード問題 2026年4月、AMD のシニア AI ディレクターが約 6,852 セッション分のログ分析で発見した問題。2026年3月8日以降、Claude Code の思考の中央値が約 2,200 文字から約 600 文字(67%減)に低下していた。Anthropic は「アダプティブ・シンキング」による変更を認め、/effort max コマンドで高い思考深度を維持できると説明した。 ...

2026年4月6日 · 2 分