記事一覧

海外で発生した実際のインシデント「An AI Vibe Coding Horror Story」を元に、AI に開発を丸投げするリスクを解説します。技術的リテラシーのないまま本番環境を構築した結果、患者データが完全露出するという深刻な事態が起きました。 何が起きたのか 専門知識のない医療従事者が、AI を使って自分専用の患者管理システムをゼロから自作しました。業界で実績のある既存ソフトウェアを使わず、「自分のバイブ（感覚）」で開発を進めたのです。 元記事: An AI Vibe Coding Horror Story システムの問題点 AI が生成したこのアプリには、致命的なセキュリティ上の欠陥が多数ありました。 アーキテクチャの問題 単一 HTML ファイル構成: すべてのプログラムが 1 つの HTML ファイルに詰め込まれた簡素な構造 クライアントサイド認証: パスワードなどの認証機能がブラウザ側の処理だけで実装されていた アクセス制御なし: データベースへのアクセス制限が全くなく、誰でも中身を閲覧できる状態 データ管理の問題 蓄積されていた大量の患者データをそのまま自作アプリに移行 全データが暗号化されず、無防備な状態で公開サーバーに配置 適切なセキュリティ設定をしないままインターネット上に公開 プライバシーの問題 診察中の会話を録音し、外部の AI サービスに送信して要約させる機能を実装 患者の個人情報や音声データが、事前の同意なく海外のサーバーへ転送 被害の深刻さ わずか 30 分の調査 で、全ての患者データに対する読み書き権限が奪取されました。 患者の個人情報が完全に露出 音声データも含めた機密情報が外部に流出 現地の個人情報保護法や医療従事者の守秘義務に違反している可能性が極めて高い状況 問題の本質 不備を指摘された本人は、AI が生成した定型文で回答し、問題の深刻さを理解していませんでした。 これはバイブコーディングの本質的なリスクを示しています： AI はコードを生成できるが、セキュリティ要件の判断はできない 開発者が仕組みを理解していないと、問題が起きても原因を特定できない 「動いているように見える」と「安全に動いている」は全く別の話 開発の民主化とリテラシーのトレードオフ AI によって開発の民主化が進み、非エンジニアでもアプリケーションを作れる時代になりました。一方で、最低限の技術的リテラシーがないと重大な事故を招くリスクも同時に高まっています。 特に以下の領域では、専門知識なしの AI 開発は高リスクです： 領域 リスク 医療・健康データ 個人情報保護法・医療法違反 金融データ 金融規制・顧客情報保護 個人認証システム なりすまし・不正アクセス 本番環境のインフラ サービス停止・データ消失 まとめ バイブコーディングは強力なツールですが、「AI に生成させたコードを理解できる人間が監督する」 という原則なしには危険です。 ...

スペースデータ社長の佐藤航陽氏が、興味深い社会シミュレーション実験を紹介している。大量の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地球儀上でのリアルタイム表示には、実際の使用技術は公開されていませんが、以下のような構成が一般的です: ...

Claude Code の拡張 OSS「Claude Harness」が v4.0.0 “Hokage” をリリースした。コア全体を Go ネイティブに書き換え、フック実行速度が約 30 倍に向上。設定ファイルも harness.toml 1 本に集約され、大幅に扱いやすくなった。 Claude Code の拡張機構とは Claude Code には最初から強力な拡張機構が備わっている。 hooks — PreToolUse / PostToolUse / SessionStart などのイベントでスクリプトを差し込める permissions — settings.json の deny ルールで危険なコマンドを事前ブロックできる plugin system — plugin.json で自作プラグインを作り、チーム配布できる skills — スラッシュコマンドで自作ワークフローを走らせられる MCP — 外部ツール（DB・Slack・GitHub…）をネイティブ連携できる 「AI がやらかしそうなこと」「自律運用のワークフロー」「危ないコマンドのブロック」はほぼ全部、Claude Code の機能で実現できる。 自分で全部セッティングするのは無理ゲー 強力だからといって、簡単ではない。 自作で「AI に危ないコマンドを通させない」ワークフローを組もうとすると、以下を理解しておかなければならない。 plugin.json — プラグインマニフェスト hooks.json — PreToolUse に走らせるスクリプトを宣言 settings.json — deny ルールを人力で組み立てる .mcp.json — MCP サーバー設定 .claude-plugin/hooks.json — プラグイン経由のフックも別途 整合させる JSON が 5〜6 本。どれか 1 つを直すと別がズレる。 さらに「Plan → Work → Review の自律運用」を乗せようとすると以下も必要になる。 ...

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 モデル 複数のバリアントが公開されている。 ...

S_mart（エスマート）は、デジタルディスプレイに実物大の商品棚を再現し、在庫を持たずにサテライト店舗を展開できるリテール DX サービスだ。月額 10,000 円から利用でき、買物困難者対策や商圏拡大に活用されている。この記事では、S_mart の仕組み・活用パターン・料金体系を整理し、導入を検討する際のポイントを解説する。 S_mart とは S_mart は、デジタルディスプレイで実店舗の売場と商品棚を「実物大」で再現するリテール DX ソリューションである。再現した売場をサテライト店舗として各地に展開できる。開発元のダン:サイエンス株式会社が 2021 年 3 月の「リテールテック JAPAN 2021」でプロトタイプを発表した。現在は int mart design 株式会社が運営・提供を担っている。 コンセプトは 「ご近所デジタルディスプレイ商店」。実店舗と EC の利点を組み合わせた新しい購買体験を目指している。 解決する課題 日本では約 700 万人（農林水産省推計）の買物困難者が存在する。従来の対策には以下のような限界がある。 対策 課題 ネットスーパー 商品サイズの実感が難しい、検索型 UI で「売場を回る」体験がない 移動販売 時間・品揃えに制限がある、運行コストが高い キオスク・マイクロスーパー 1,000〜3,000 SKU に限定される、在庫リスクがある S_mart はこれらの課題に対して、品揃えに上限がなく、受注後に商品を手配するため在庫を持たないというアプローチで解決を図っている。 システム構成 S_mart は以下の 4 つのコンポーネントで構成される。 S_display（表示アプリ） エンドユーザーが操作するタッチパネル向けアプリケーション。商品を実物大で表示し、陳列棚を再現する。Web ショッピングの「検索型」ではなく「陳列・比較型」の買い物体験を提供する点が特徴である。 S_manager（管理画面） クラウド型の管理ソフトウェア。店舗担当者がいつでも・どこからでも商品や売場のレイアウトを登録・変更できる。 S_device（デバイスセット） 75 型・22 型などのタッチパネルディスプレイを含むハードウェアセット。設置場所に合わせたサイズ選択が可能。 MDB（商品データベース） ナショナルブランド食品の画像・仕様情報を提供するデータベース（有料オプション）。商品登録の手間を削減できる。 活用パターン 店内設置型 既存店舗の店内にディスプレイを設置するパターン。 品揃え拡大: 棚に並べきれない商品をデジタルで陳列 陳列労力の削減: 物理的な商品入れ替え作業が不要 詳細情報の伝達: 商品説明やアレルギー情報などをデジタルで表示 サテライト型 実店舗の周辺地区にデジタルディスプレイを設置して「出張店舗」を展開するパターン。 ...

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 やパッケージ名の捏造）が発生したターンでは推論が一切出力されていなかった」とも述べています。 ...