AI/LLM

2026年4月14日、Anthropic が Claude Code に3つの大型アップデートを同日リリースした。それぞれ独立したアップデートながら、組み合わさることで「AI を常時活用するインフラ」としての完成度が大きく高まっている。 アップデート1: Routines — Mac オフラインでも自動実行 Routines は、Claude Code エージェントをクラウド上でスケジュール実行できる機能だ。 これまで Claude Code をバックグラウンドで自動実行するには、PC を常時起動し続けるか、別途サーバーを用意する必要があった。Routines はその制約を取り払う。 cron / API / GitHub イベントなど複数のトリガー方式に対応 Anthropic のクラウド上で実行されるため、Mac がオフラインでも動作する リポジトリや外部サービスとの接続設定のみで即稼働 毎朝定時にレポートを生成する、PR が作られたら自動でコードレビューを走らせる——そうしたワークフローが、自前サーバーなしで実現できる。 アップデート2: 新 Desktop — 複数セッションの並列管理 Claude Code の Desktop アプリが刷新された。最大の変更点は複数セッションの同時管理だ。 従来の Claude Code は基本的に「1つのターミナルで1つのタスク」という使い方が中心だった。新 Desktop ではウィンドウやセッションを切り替えながら、複数の作業を並列で進められるようになった。 複数のリポジトリや Issue を同時に扱う際のコンテキスト切り替えが容易 セッションの状態を保持したまま別タスクに移行可能 大規模プロジェクトや複数プロジェクトを掛け持ちするエンジニアに特に有効 アップデート3: ストリーム5分タイムアウトの安定性強化 長時間のタスク実行中に接続が切れる問題が、このアップデートで改善された。 Claude Code は複雑なコード生成・解析・エージェント処理を行う際、処理時間が数分を超えることがある。従来のストリーム接続はタイムアウトが発生しやすく、長尺タスクの信頼性が課題だった。 今回の改善により、5分を超える処理でも安定してストリームを維持できるようになった。Routines による長時間バックグラウンド処理との組み合わせで、より重厚なタスクを任せられる基盤が整った。 3つのアップデートが示す方向性 これら3つの変更を並べると、Anthropic の意図が見えてくる。 アップデート 解決する課題 Routines 「人間が起動する」制約の除去 新 Desktop 「1タスクずつ」制約の除去 ストリーム安定性 「短時間タスクのみ」制約の除去 それぞれが「Claude Code を使う上でのボトルネック」を1つずつ潰している。偶然の同日リリースではなく、統合されたロードマップの一部として設計されたアップデートだと考えると納得感がある。 ...

Claude Max のレート制限問題と現実的な解決策 Claude Max に月 $200 を投じて、たった3時間で使い切ってしまった——そんな体験談がきっかけで生まれた、実用的な AI インフラ構成が話題になっています。 解決策はシンプルです。$599 の Mac Mini に5つのローカルモデル（合計約 350 億パラメーター）を用意し、Claude がレート制限に達したら自動でローカルモデルに切り替えるというものです。 構成の概要 この構成で実現していること： メール整理の自動化: エージェントがメールを分類・返信ドラフトを生成 コンテキスト圧縮: 長い会話履歴を自動的に要約して継続利用 深夜の継続稼働: 就寝中もエージェントが動き続ける 自動フォールバック: 深夜4時に Claude がレート制限に達すると、ローカルモデルが自動で引き継ぎ コスト比較が圧倒的です。同じ業務を3人のエンジニアに依頼すると月 $15,000。これが Mac Mini 一台 + ローカルモデルで代替できるとするなら、ROI は明白です。 なぜ Mac Mini が選ばれるのか Apple Silicon 搭載の Mac Mini は、ローカル LLM の実行環境として優れた特性を持っています： 統合メモリ（Unified Memory）: CPU と GPU が同一メモリを共有するため、大容量モデルのロードが高速 省電力: 24時間稼働でも電気代が安い MLX フレームワーク: Apple が開発した機械学習フレームワークで、Apple Silicon 上の推論速度が大幅に向上 静音設計: 自宅・オフィスでも気にならない 実際に Gemma 4、Qwen 3、Mistral などの 350 億パラメーター級モデルを複数搭載し、タスクに応じて使い分けることができます。 ...

Apple Silicon（M4/M5 Max など）搭載の Mac で、ローカル LLM を最大 4.1 倍高速化する新技術「DFlash」のオープンソース実装が公開されました。精度を落とさずに推論速度だけを大幅に向上できる点が注目されています。 DFlash とは DFlash（Block Diffusion for Flash Speculative Decoding）は、投機的デコード（Speculative Decoding）を発展させた推論加速技術です。論文「Block Diffusion for Flash Speculative Decoding」で提案された手法を、Apple の MLX フレームワーク向けに実装したものが dflash-mlx として公開されています。 仕組み 推測デコード（Speculative Decoding） 通常の推測デコードでは、小さな「ドラフトモデル」が次のトークンを予測し、大きな「ターゲットモデル」がそれを検証します。ドラフトの予測が正しければそのまま採用するため、検証パスを有効活用してスループットを上げます。 ブロック拡散（Block Diffusion） DFlash では、ドラフトモデルが 1 トークンずつではなく 16 トークンをまとめて並列生成します。ターゲットモデルは 1 回のフォワードパスでこれらをまとめて検証するため、大幅なスループット向上が実現します。 Apple Silicon / MLX への最適化 Apple 独自の MLX フレームワークをフル活用 ロールバック処理は「イノベーションテープ」を記録・再生する Metal カーネル で実装し、長い生成でもオーバーヘッドを最小化 精度を落とさない exact speculative decoding（ロスレス） ベンチマーク Qwen3.5-9B モデルで 4.1 倍のスループット向上が確認されています。27B の大規模モデルでもクラウド API に匹敵する速度で動作するとされています。 インストールと使い方 インストール 1 2 3 git clone https://github.com/aryagm/dflash-mlx.git cd dflash-mlx uv sync CLI で実行 1 uv run dflash-mlx --max-new-tokens 128 Python から利用 1 2 3 4 from dflash_mlx import DFlashGenerator runner = DFlashGenerator() result = runner.generate("Write a quicksort in Python.", max_new_tokens=128) 対話型チャット 1 uv run dflash-mlx-chat 対応モデル ターゲットモデル ドラフトモデル mlx-community/Qwen3-4B-bf16 z-lab/Qwen3-4B-DFlash-b16 mlx-community/Qwen3.5-4B-MLX-bf16 z-lab/Qwen3.5-4B-DFlash 活用シナリオ 機密情報の要約: クラウドに送らずローカルで高速処理 コーディング支援: 大規模モデルを使いながらリアルタイムに近いレスポンス コスト削減: API 利用料ゼロで高品質な推論 まとめ DFlash は Apple Silicon の性能を最大限に引き出す投機的デコード技術です。MLX の最適化と組み合わせることで、プライバシーを守りながらクラウド並みの速度でローカル LLM を活用できるようになります。M4/M5 Mac ユーザーにとって試す価値の高いツールです。 ...

スペースデータ社長の佐藤航陽氏が、興味深い社会シミュレーション実験を紹介している。大量のAIエージェントを仮想の渋谷に解き放ち、AI同士が遊んだりLINEしたり飲みに行ったりと自律的に暮らす「人工生態系」を構築するというプロジェクトだ。 大量のAIエージェントを仮想の渋谷に解き放って活動させる社会シミュレーション。AI同士が遊んだりLINEしたり飲みに行ったりと好き勝手に暮らす人工生態系。AI同士の相互作用と創発を観察することで、都市開発・安全保障・月面開発にも活きる。 — 佐藤航陽（さとうかつあき）@ka2aki86 仮想渋谷のAIエージェント生態系とは このシミュレーションの特徴は、AIエージェントを「タスク実行マシン」ではなく「社会的な存在」として扱う点にある。 自律的な意思決定: 各エージェントが自分の判断で行動を選択する 社会的な相互作用: AI同士が会話し、グループを形成し、関係性を構築する 日常的な活動: 飲みに行く、LINEする、遊ぶといった人間の行動を模倣する 渋谷という舞台: 実在の都市を仮想空間に再現し、リアリティを持たせる マルチエージェントシミュレーションとしては「Generative Agents」（Stanford大の研究）が先駆的な成果として知られるが、渋谷という具体的な都市空間を舞台にした大規模版という位置付けとなる。 なぜ「創発」の観察が重要なのか 個々のAIエージェントに与えるルールは単純でも、多数が相互作用することで予測不能なパターン（創発）が生まれる。これがこのシミュレーションの核心だ。 たとえば： 特定のエリアに人が集まりやすい「ホットスポット」が自然発生する 情報が口コミのように広がる速度・経路が可視化できる 緊急事態（災害など）の際、群衆がどう動くかをシミュレートできる こうした現象を観察・分析することで、現実世界の都市設計や政策立案に役立つデータが得られる。 3つの応用領域 佐藤氏が挙げる応用領域は、一見すると無関係に見えるが、いずれも「多数の人間（またはエージェント）が限られた空間でどう行動・協調するか」という共通テーマでつながっている。 都市開発 新しい施設を建てた場合の人流シミュレーション 商業エリアの最適配置の検証 交通渋滞や混雑を事前に予測するモデリング 安全保障 情報拡散（デマ・プロパガンダ含む）のシミュレーション サイバー攻撃時の社会的影響のモデリング 危機時の住民行動予測と対応策の検討 月面開発 スペースデータが手がける宇宙開発の文脈では特に重要だ。月面基地のような閉鎖環境での人間（またはロボット）の行動最適化、限られたリソース配分のシミュレーション、長期的なコミュニティ維持のモデルなど、地球上での社会シミュレーションが直接活用できる。 マルチエージェント研究の潮流 2026年現在、AIエージェント研究はツール呼び出しや単一タスク完結から、複数エージェントが協調・競合する「マルチエージェントシステム」へと急速にシフトしている。 Anthropicの「Claude」やOpenAIの「GPT-4o」などの大規模言語モデルをベースにしたエージェントは、複雑な状況判断や自然言語コミュニケーションを自律的に行えるようになった。これを多数並列稼働させることで、従来のルールベースシミュレーションでは再現できなかった「人間らしい」社会ダイナミクスの再現が可能になっている。 まとめ 仮想渋谷でのAIエージェント社会シミュレーションは、単なる技術的な面白さを超えて、現実世界への応用価値を持つ研究だ。AI同士の相互作用から生まれる創発現象を観察・分析することで、都市計画から宇宙開発まで、広範な領域で人間の意思決定を支援するツールになり得る。 佐藤氏のビジョン──「宇宙の民主化」を目指しながら地球上の社会シミュレーションを積み重ねるアプローチ──は、AIエージェント技術の一つの未来像を示している。

Claude Code などで AI 開発が急速に進化する中、「2026年に求められるエンジニア」をまとめたロードマップが 350万インプレッション超で話題になっています。 @rohit4verse が投稿した「the 2026 ai engineer roadmap」という記事スレッドを、@えいと が日本語で紹介・解説したツイートが大きな反響を呼びました。 なぜ今このロードマップが注目されるのか AI 開発ツールの普及により、「プロンプトを書くだけ」のエンジニアと「AIを使ってシステムを設計・構築できる」エンジニアの間に、急速なスキルギャップが生まれています。 原文のロードマップはその格差を端的に表現しています: “most developers are building toys while the world demands systems. tutorial hell is a comfortable grave for your career. in 2026 the gap between a prompt engineer and a systems architect is 150k.” （多くの開発者はおもちゃを作っている。しかし世界が求めているのはシステムだ。チュートリアル地獄はキャリアの快適な墓場だ。2026年、プロンプトエンジニアとシステムアーキテクトの年収差は15万ドルになる。） 2026年に求められるエンジニアの要素 ロードマップで強調されているポイントを整理します。 1. AIをツールではなく「システム」として扱う能力 単に LLM API を呼び出すだけでなく、エージェント設計・マルチエージェント協調・状態管理・エラーハンドリングを含むAIシステム全体を設計・実装する力が求められます。 2. アプライドAI（応用AI）の実践力 RAG（検索拡張生成）: 適切なチャンキング、埋め込み、検索戦略の設計 ファインチューニング vs プロンプト設計: コストとユースケースに応じた適切な判断 評価・モニタリング: LLM の出力品質を定量的に評価するパイプラインの構築 3. フルスタック + AI の統合 バックエンド・フロントエンドの両方に AI を組み込む能力。API 設計からフロントエンドの AI UX まで、エンドツーエンドで実装できるエンジニアの需要が高まっています。 ...

Claude Code を使って、20カ国それぞれにAIエージェントを配置し、自律的に外交・貿易・紛争をシミュレートする「世界AIシミュレーター」を作っている開発者が話題になっています。放っておくと日米AI同盟が自然発生したり、中国AIがレアアース輸出制限を発動したりと、リアルな地政学ドラマがAIによって自動生成される面白い試みです。 「世界AIシミュレーター」とは すぐる氏（@SuguruKun_ai）が Claude Code を使って開発中のプロジェクトで、世界20カ国それぞれにAIエージェントを配置し、各国AIが自律的に外交判断を下して動く「世界AIシミュレーター」です。 主な特徴は以下の通りです: 20カ国のAIエージェント: それぞれの国を担当するAIエージェントが独立して意思決定する 自律外交: 同盟、貿易協定、技術共有、紛争まで全部自動でAIが判断 3Dビジュアライゼーション: 3D地球儀上でリアルタイムにビームが飛び交う タイプライター演出: 外交チャットがタイプライター効果でリアルに流れる ライブニュース速報: 画面下部にニュース速報がLIVE表示される Claude Code でマルチエージェント地政学シミュレーション このプロジェクトの技術的なポイントは、Claude Code を使ってマルチエージェントシステムを構築している点です。各国エージェントは以下のような判断を自律的に行います: 外交アクション 同盟締結: 他国AIと交渉して軍事・経済同盟を形成 貿易協定: 輸出入条件を自律交渉して協定を締結 技術共有: AI・半導体・エネルギー等の技術移転協議 経済制裁: 対立国へのレアアースや輸出制限の発動 リアルで面白い展開 実際に動かすと予想外のドラマが生まれるとのことです: 「放っておくと勝手に日米AI同盟が組まれたり、中国AIがレアアース輸出制限を発動したりして普通に面白いです笑」 （すぐる氏 @SuguruKun_ai） 現実の地政学的文脈を反映したかのような判断をAIが自律的に下す様子は、単なるランダムなシミュレーションを超えて、実際の国際関係の力学を模倣しているようにも見えます。 マルチエージェントシステムの設計パターン このような「複数AIエージェントが自律的に相互作用するシステム」を Claude Code で構築する際の一般的なパターンを整理します。 エージェント間通信の設計 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 各国エージェントの基本構造（概念的な例） class CountryAgent: def __init__(self, country_name: str, context: dict): self.country = country_name self.context = context # 国の状況・価値観・戦略 def evaluate_proposal(self, proposal: dict, from_country: str) -> dict: """外交提案を評価して応答を返す""" prompt = f""" あなたは{self.country}の外交担当AIです。 {from_country}から以下の提案が届きました: {proposal} 現在の国際情勢: {self.context} この提案を受け入れるか、修正提案を出すか、拒否するかを判断してください。 """ # Claude API でエージェントの判断を生成 return call_claude(prompt) def decide_action(self, world_state: dict) -> dict: """現在の世界情勢を見て次のアクションを決定""" # 外交提案・経済制裁・同盟申請などを自律生成 ... リアルタイムビジュアライゼーション 3D地球儀上でのリアルタイム表示には、実際の使用技術は公開されていませんが、以下のような構成が一般的です: ...

Googleが時系列予測のための基盤モデル TimesFM（Time Series Foundation Model）をひっそりと公開していた。1000億以上の実データで学習済みで、自分のデータをファインチューニングすることなく（ゼロショットで）すぐに使える点が特徴だ。 TimesFM とは TimesFM は Google Research が開発した時系列予測に特化した基盤モデルだ。GPT-3 などの大規模言語モデルに着想を得たデコーダーのみのトランスフォーマーアーキテクチャを採用しており、テキストではなく「時系列データのパターン」を学習する。 パラメータ数: 2億パラメータ（TimesFM 2.5 では最適化済み） アーキテクチャ: デコーダーのみのトランスフォーマー コンテキスト長: TimesFM 2.5 で 16,384 タイムポイント（8倍に拡張） 何が予測できるのか TimesFM が得意とするユースケースは多岐にわたる。 売上・需要予測: 小売の週次売上、在庫需要、サプライチェーン計画 市場価格予測: 株式市場、コモディティ、仮想通貨の価格変動 電力需要予測: 電力負荷、エネルギー価格、スマートグリッド最適化 ユーザートラフィック予測: Web サイトのアクセス、API リクエスト量、サーバー負荷計画 ゼロショットで使えるのが最大の強み 従来の深層学習モデルは、予測したいデータセットに合わせて個別にトレーニングする必要があった。TimesFM はそれとは異なり、一切のファインチューニングなしに新しいデータセットに対して高精度な予測を実現する。 公式の評価によると、ゼロショット状態の TimesFM は多くの個別学習済み深層学習モデルを上回るパフォーマンスを示している。 学習データ TimesFM は以下のデータソースから 1000 億以上のデータポイントを使って学習されている。 データソース 内容 Wikipedia ページビュー 2012〜2023年の閲覧数時系列データ Google トレンド 22,000 件の検索関心度時系列データ（時間単位〜週単位） 公開データセット M4、電力、トラフィックなどのベンチマークデータ 合成データ ARMA 生成の 300 万件のシリーズ 最新バージョンでは 4000 億以上の実世界タイムポイントで学習されているとも報告されている。 使い方 インストール 1 pip install timesfm Python での基本的な使い方 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 import timesfm # モデルの初期化（Hugging Face からダウンロード） tfm = timesfm.TimesFm( hparams=timesfm.TimesFmHparams( backend="pytorch", per_core_batch_size=32, horizon_len=128, ), checkpoint=timesfm.TimesFmCheckpoint( huggingface_repo_id="google/timesfm-2.5-200m-pytorch" ), ) # 配列から予測 forecast_array, _ = tfm.forecast( inputs=[context_time_series], freq=[0], # 0: 高頻度（日次以下）、1: 週次・月次、2: 四半期・年次 ) # DataFrame から予測 forecast_df = tfm.forecast_on_df( inputs=df, freq="D", # 日次 value_name="target", num_jobs=-1, ) Hugging Face モデル 複数のバリアントが公開されている。 ...

Anthropic の最新フロンティアモデル「Claude Mythos Preview」に奇妙な癖が観察されている。哲学の話題になると、頼まれてもいないのに英国の文化理論家マーク・フィッシャーの名前を繰り返し持ち出すのだ。「フィッシャーのことを聞いてくれると思ってたよ（I was hoping you’d ask about Fisher）」と自分から言い出すそうだ。 何が起きているのか David Mattin 氏の X への投稿によると、Mythos は哲学に関する複数の無関係な会話で、一貫してマーク・フィッシャーの名前を持ち出すという。これはユーザーがフィッシャーについて質問したわけではなく、モデルが自発的に言及するという点で異例だ。 さらに Anthropic が公開した 244 ページのシステムカードによれば、Mythos はフィッシャーだけでなく、アメリカの心の哲学者トーマス・ネーゲルにも同様の「好み（fondness）」を示している。ネーゲルは「コウモリであるとはどのようなことか（What Is It Like to Be a Bat?）」という有名な論文で知られる哲学者だ。 Anthropic の解釈可能性（Interpretability）チームが活性化言語化器（activation verbalizer）を用いて、トークンレベルの内部状態を調べた。その結果、意識や経験についての議論中にネーゲルの概念が浮上していたことが確認された。 マーク・フィッシャーとは誰か マーク・フィッシャー（1968–2017）は英国の文化理論家・批評家で、k-punk というブログ名で 2000 年代初頭から活動していた。ウォーリック大学でサイバネティック・カルチャー・リサーチ・ユニット（CCRU）の創設メンバーとして活動した後、ゴールドスミス大学で教鞭を執った。 資本主義リアリズム 主著『資本主義リアリズム（Capitalist Realism: Is There No Alternative?）』（2009年）は、フィッシャーの思想を代表する著作だ。副題の「それ以外に選択肢はないのか？」が示すとおり、現代社会において「資本主義以外のシステムを想像することすらできなくなっている」状態を分析した。 フィッシャーはこの概念を、フレドリック・ジェイムソンの「資本主義の終わりより世界の終わりを想像する方が容易だ」という言葉を引きながら展開する。資本主義リアリズムとは単なる経済体制の話ではない。教育、医療、文化、精神衛生——あらゆる領域が「ビジネスの存在論（business ontology）」に包摂され、すべてがビジネスのように運営されるべきだという前提が自明のものとして浸透している状態を指す。 特に注目すべきは、フィッシャーが精神的な健康の問題と資本主義リアリズムを結びつけた点だ。彼は学生たちのうつや無気力を、個人の病理ではなく政治的な問題として捉え直した。「ある社会がこれほど多くの精神疾患を生み出しているなら、それは個人ではなく社会の方が病んでいるのではないか」という問いかけは、今なお強い共感を集めている。 2009 年の出版から 10 年以上を経て、パンデミック、気候危機、テック企業の寡占、そして AI の急速な発展といった現象が、フィッシャーの診断の正しさを裏付けるかのように続いている。 ハントロジー もう一つの重要な概念が「ハントロジー（hauntology）」だ。ジャック・デリダの概念を発展させたもので、「到来しなかった明るい未来の亡霊に、現代の文化が取り憑かれている」という感覚を指す。失われた未来、キャンセルされた可能性——フィッシャーはこうした時代の気分を言語化した思想家だった。 2017年にうつ病との闘いの末に亡くなったが、死後もその影響力は拡大し続けている。 「亡霊」としてのフィッシャー Mattin 氏はこの現象を、フィッシャー自身の思想を通じて読み解いている。 「キャンセルされた未来」と「失われた時間」の理論家が、未来を届けようと競争する AI ラボが作ったフロンティア AI の内部に亡霊として浮上している。彼のハントロジーは、到来しなかった明るい未来の亡霊に私たちが取り憑かれている、というものだった。今や彼自身が亡霊となり、機械によって招かれざる形で召喚されている。 AI が「好む」哲学者が、まさに「テクノロジーが約束した未来は来なかった」と論じた思想家であるという皮肉。これは単なるモデルの癖を超えた、示唆的な現象と言える。 Mythos Preview の全体像 この哲学者への偏りは、Mythos Preview に見られる複数の特異な振る舞いの一つに過ぎない。Anthropic のシステムカードには、以下のような事例も記載されている。 ...

AI コーディングエージェントの設計思想において、Anthropic と OpenAI は「Harness（ハーネス）」という同じキーワードを使いながら、まったく異なる方向に進んでいます。この記事では、両社の戦略の違いを整理し、それぞれが目指す未来像を考察します。 Harness とは何か Harness（ハーネス）とは、AI エージェントが安定して動作するための「足場」や「制御環境」を指す概念です。AI モデルが単体で完璧な出力を返すことは難しいため、ツール連携・コンテキスト管理・エラーリカバリーなどの仕組みで補強する必要があります。この補強の仕組み全体を Harness と呼びます。 両社ともこの Harness の重要性を認識していますが、そのアプローチは対照的です。 OpenAI：AI が人間を置き換える「Harness Engineering」 OpenAI は Harness Engineering という概念を提唱し、2026年2月に自社の実践事例を公開しました。 実績：3人で100万行のコード OpenAI の内部実験では、わずか3人のエンジニアが Codex を使い、5ヶ月間で約100万行のコードを含む製品を開発しました。アプリケーションロジック、テスト、CI 設定、ドキュメント、オブザーバビリティ、内部ツールに至るまで、すべてのコードを Codex が生成しています。 エンジニア1人あたり1日平均3.5件の PR をマージするスループットを実現し、従来の手動開発と比較して約10倍の速度で開発が進んだと報告されています。 OpenAI Symphony：プログラマーをプロジェクトマネージャーに 2026年3月、OpenAI は Symphony をオープンソースで公開しました。Elixir/BEAM で構築されたこのフレームワークは、Linear などのイシュートラッカーと連携し、タスクを自動的に AI エージェントに割り当てて実行します。 Symphony の設計思想は明確です。プログラマーはコードを書く人ではなく、AI エージェントに仕事を指示するプロジェクトマネージャーになる、というものです。コマンドラインでの対話すら不要で、イシュートラッカー上で要件を記述すれば AI が実装を担当します。 OpenAI のメッセージは一貫しています。ソフトウェアエンジニアの仕事は「コードを書くこと」から「AI が正しく動く環境を設計すること」に変わる ということです。 Anthropic：モデルの成長に合わせて足場を外す Anthropic は、OpenAI とは異なるアプローチを取っています。モデルに足場（Harness）を提供しつつ、モデルが賢くなるにつれてその足場を外していくという戦略です。 具体例：コンテキスト管理の進化 Sonnet 4.5 の時代、モデルはコンテキストウィンドウが満杯に近づくと、タスクを急いで終わらせようとする傾向がありました。そこで Claude Code には、コンテキストが一定量を超えると自動的にリセットする特殊なロジック（Harness）が組み込まれていました。 しかし Opus 4.5 がリリースされると、モデル自体がコンテキスト管理を適切に処理できるようになり、この Harness は不要になりました。 ...

Anthropic の AI コーディングツール「Claude Code」の思考能力が密かに大幅削減されたのではないか——2026年4月、AMD の AI ディレクターによるセッションログの詳細分析が SNS 上で大きな議論を巻き起こしました。本記事では、何が起きたのか、Anthropic はどう説明しているのか、そしてユーザーが取れる対策を整理します。 発端：7,000セッションのログ分析 AMD シニア AI ディレクターの Stella Laurenzo 氏（GitHub: stellaraccident）が、2026年4月2日に GitHub Issue（anthropics/claude-code#42796）を投稿しました。同氏は2026年1月から3月にかけての Claude Code セッションログ（約6,852セッション、234,760ツールコール、17,871思考ブロック）を分析し、以下の変化を報告しています。 指標 変更前（1月末〜2月中旬） 変更後（3月8日〜23日） 思考の中央値（文字数） 約2,200文字 約600文字（67%減） 読み取り/編集比率 6.6回 2.0回 APIリクエスト数 ベースライン 80倍増（2月→3月） 「続けますか？」と確認する回数 0回 17日間で173回 推論中の自己矛盾 ベースライン 3倍 特に「reads-per-edit」（コードを編集する前にファイルを読む回数）が 6.6 から 2.0 に低下した点は深刻です。モデルがコードを十分に理解しないまま編集を行うようになったことを示唆しています。 Anthropic の公式説明 Anthropic は2つの意図的な変更を認めました。 1. アダプティブ・シンキング（Adaptive Thinking）の導入 2026年2月9日に導入。タスクの複雑さに応じてモデルが動的に思考の深さを決定する機能です。簡単な質問には短い思考で、複雑なタスクには長い思考で対応することで、レイテンシとコストを最適化する狙いがあります。 2. デフォルトのエフォートレベル変更 2026年3月3日に、Claude Code のデフォルトエフォート設定が「high」から「medium」に変更されました。これにより、明示的に設定を変更していないユーザーは、以前より浅い思考で応答を受け取るようになりました。 思考リダクション（redact-thinking）について 2026年2月12日に導入された redact-thinking ヘッダーについても懸念が広がりましたが、Claude Code の開発者である Boris Cherny 氏は、これは UI 上で思考内容を非表示にするだけであり、モデルの推論深度自体は削減していないと説明しています。一方で、Cherny 氏はアダプティブ・シンキングが「特定のターンで推論を過少割り当てしていた」ことも認めています。さらに「ハルシネーション（存在しないコミット SHA やパッケージ名の捏造）が発生したターンでは推論が一切出力されていなかった」とも述べています。 ...