Ai

なにげに、シリーズになってしまっていますが。前回のところから考えると、Metaの激震の一つは、MetaのAI研究の象徴であった ヤン・ルカン（Yann LeCun）の辞任 であるのは言うまでもありません。ルカンといえば、福島先生のネオコグニトロン(1980年)に着想を得て、そこにバックプロパゲーションによる学習を組み込み、LeNet(1989年)という形で、CNNを切り拓いたのは言うまでもありません。 ルカン氏は、ザッカーバーグが現在「物量(GPU)とデータ」のごり押しで、次世代モデルを作ろうとしているのに対し、一貫して「今のLLMの槍から(次の単語の予測)」では猫程度の知能にも到達できないと、批判してきた人物です。 Metaの現状 : ネオコグニトロンから続く「構造による理解」を軽視、ひたすら計算資源を燃やす方向にシフト。 ルカンの新天地 : 5000億円という、Metaの135兆円にくらっべれば、コンパクトな資金で、構造的・因果的な「世界モデル」を実現しようとしている。 僕なりの考えはすでに、"AI の推論アーキテクチャと「System 2」の誤解" に示しています。System 2 は、これらの技術進展の延長線上にあるものではなく、全く別の枠組みです。先人がなぜ System 1（直感的・高速）と System 2（論理的・低速）を明確に切り分けたのかを再考すべきです。System 1 をどれほど高度化しても、それは本質的な System 2 にはなり得ません。 そして、その道標の実験の一つが、Zennで既に公開した、"Mojoで実装する「多世界解釈」並列バックトラック：N-Queen問題を例に“です。 大雑把に言えば、現在、未解決の問題というのは、いくつかあり、 フレーム問題 時相倫理 自我 などが、知られています。 Transformerの二乗の呪いは、SSMなどで解決できるかもしれません。しかし、ルカン氏の疑問は、おそらく、そんなところにはないのは明らかです。二乗の呪いというのは、TransfomerのAttention機構のオーダーがコンテキスト長の二乗になる現象です。これは、Attention機構自体に潜んでいます。そして、その解決として、期待されているのが、状態空間モデルを活用した、MambaなどのSSMです。 しかし、それは、ルカン氏の疑問のそもそも、つまり、次の語の予測では頭打ちではないのかという問題の答えにはなっていません。どう考えても、System 2の理想とは程遠い。 LeCunの主張 graph TD subgraph lecun [LeCunの主張] pattern[✖LLMは「テキストの統計的パターン」を学んでいるだけ] notworld[✖物理世界の理解がない] canot[✖常識推論ができない] world[☑必要なのは「世界モデル」] phi[☑物理法則、因果関係、時間の概念を理解するAI] end 先の提起で言えば、フレーム問題、時相論理とは、物理法則、因果関係、時間の概念をそのまま、言い表しています。 この辺の事情は、"【激震】ヤン・ルカンがMetaを去った。5000億円で「世界モデル」研究所を設立“がよく纏めています。 この図を思い浮かべてほしいのです。 graph TD subgraph Layer3 [Layer 3: Orchestration] RAG[RAG] ReAct[ReAct] MCP[MCP] Agents[Agents] end subgraph Layer2 [Layer 2: Inference Strategy] CoT[CoT] ToT[ToT] Planning[Planning/Search] end subgraph Layer1 [Layer 1: Architecture] Transformer[Transformer] SSM[SSM] RWKV[RWKV] MoE[MoE] end Layer1 --> Layer2 Layer2 --> Layer3 CoT、ToT、GoTに関しては、"CoT・ToT・GoTとは？今でも使える理由と使い分け"、あたりがよく纏まっていると思います。とはいえ、先の図の通り、それだけでは、先の図のLayer 2にすぎません。System 1やSystem 2の別はそれよりも、さらに、上の階層にあります。 ...

ソーシャルメディアの巨人、Meta Platforms（以下、Meta）は、AI 業界において長らく「オープンソースの盟主」として君臨してきた。2023 年に始まった Llama シリーズの公開は、クローズドな開発体制を敷く OpenAI や Google に対する強力なカウンターパワーとして、世界中の開発者コミュニティから熱狂的な支持を受けてきた。 しかし、2025 年から 2026 年にかけて、同社の戦略は劇的な、そして痛みを伴う転換点を迎えている。この変革の象徴となっているのが、野心的な仕様を掲げながらも内部評価で苦戦を強いられた「Llama 4」シリーズと、その反省から極秘裏に開発が進められているプロプライエタリ（独占的）な次世代モデル「Avocado（アボカド）」である。 Llama 4：MoE アーキテクチャへの挑戦と躓き シリーズの構成と技術的野心 2025 年 4 月 5 日、Meta は Llama 4 シリーズをリリースした。このシリーズは、従来の Dense なモデル構造から、計算効率を飛躍的に高める「Mixture of Experts (MoE)」アーキテクチャへと全面的に移行した初のフラッグシップモデルであった。Meta は、単一の巨大なニューラルネットワークですべての入力を処理するのではなく、特定のタスクに最適化された小規模な「専門家」ネットワークを多数配置し、入力トークンごとに最適な専門家を選択してルーティングする方式を採用した。この設計思想により、モデル全体のパラメータ数を巨大化させつつも、推論時の計算負荷を抑えることが可能となった。Llama 4 は主に、効率重視の「Scout」、汎用性の「Maverick」、そして AGI（汎用人工知能）を標榜する巨大モデル「Behemoth」の 3 モデルで構成されている。 モデル名 総パラメータ数 アクティブパラメータ数 専門家構成 主な特徴 Llama 4 Scout 109B 17B 16 experts 単一 H100 GPU での動作、10M トークンの超長文コンテキスト Llama 4 Maverick 400B 17B 128 experts コーディング・推論に特化、LMSYS Arena で上位を記録 Llama 4 Behemoth 約 2T 288B 16 experts リリース延期、GPT-4.5 超えを目指す教師モデル 内部評価と市場における「性能の乖離」 リリース直後、Meta の幹部たちは Llama 4 の性能を誇示した。VP の Ahmad Al Dahle は、Llama 4 Maverick が LMSYS Arena で 1417 の ELO レーティングを獲得し、GPT-4o や Gemini 2.0 Flash を凌駕したことを強調した。しかし、独立した開発者や研究者からの評価は、これとは対照的に厳しいものであった。 ...

この記事に掲載されている図には、技術的な観点から違和感を覚えます。 特に、System 2 の隣に SSM（State Space Model）が並べられている点が不自然です。より正確には、System 2 は現状の Transformer や SSM 単体では実装不可能であると言うべきでしょう。System 2 は、統計的なアプローチによる「もっともらしさ」の追求だけで実現できるものではありません。 graph TD subgraph Layer3 [Layer 3: Orchestration] RAG[RAG] ReAct[ReAct] MCP[MCP] Agents[Agents] end subgraph Layer2 [Layer 2: Inference Strategy] CoT[CoT] ToT[ToT] Planning[Planning/Search] end subgraph Layer1 [Layer 1: Architecture] Transformer[Transformer] SSM[SSM] RWKV[RWKV] MoE[MoE] end Layer1 --> Layer2 Layer2 --> Layer3 レイヤー 構成要素（例） 本質的な役割 Layer 1: Architecture Transformer, SSM, RWKV, MoE 統計的な計算効率と表現力。計算複雑性をどう克服し、並列性をどう担保するかという 「土台」 の議論。 Layer 2: Inference Strategy CoT, ToT, Planning/Search 統計モデルの「回し方」。モデルに思考プロセスを模倣させ、統計的な妥当性を高めるための 「手順」 の議論。 Layer 3: Orchestration RAG, ReAct, MCP, Agents 外部世界とのインタフェース。モデルが感知できない最新情報や外部ツールと連携するための 「運用の仕組み」 の議論。 元の図の作成者にとって、AI は「課題を解決するための魔法のツール」の詰め合わせに見えているのかもしれません。しかし、以下の境界線が曖昧になっているように見受けられます。 ...

ITmediaの記事「Claude拡張機能にCVSS10.0の脆弱性　現在も未修正のため注意」によると、LayerX Securityは2026年2月9日（現地時間）、Anthropicが提供する「Claude Desktop Extensions」（以下、DXT）にゼロクリック型のリモートコード実行（RCE）の脆弱性が存在すると報告しました。 Zero-Click RCE Vulnerability in Claude Desktop Extensions Exposes 10,000+ Users というLayerXの評価は、以下の通り極めて深刻なものです。 攻撃難易度：最低 認証：不要 影響範囲：完全破壊 回避策：なし 権限：完全奪取 即時性：ネットワーク経由で即時悪用可能 これらはCVSSスコア 10.0 という、セキュリティ脆弱性評価における最悪のレベルを示しています。 1990年代、ActiveXは「便利さのために権限を渡しすぎた」ことでインターネットを危険地帯に変えました。2020年代、AIエージェントは同じ構造を、より強力かつ危険な形で再現しつつあります。今回のClaude DXTの脆弱性は、まさにその象徴と言えるでしょう。 権限管理と「承認疲弊」の歴史 歴史を振り返ると、テクノロジーの進化と共に「便利さとセキュリティのトレードオフ」が繰り返されてきたことがわかります。AIエージェントの問題は、過去の失敗の延長線上にあります。 1. ActiveX（1996〜） ブラウザにOSレベルの“ネイティブ権限”を渡す仕組みでした。「便利だから」という理由で広い権限が許可され、ユーザーは承認ダイアログに疲弊し、最終的にすべてを許可するようになりました。結果として、ActiveXはマルウェアの温床となりました。 構造：不信頼入力 → 高権限コード実行 2. ブラウザ拡張（2000年代） ブラウザ拡張機能がファイルやネットワークへアクセスできるようになりましたが、権限の粒度が粗く、ユーザーが承認画面を精読することはありませんでした。 構造：利便性のために権限境界が崩壊 3. モバイルアプリ権限（2010年代） 「このアプリは連絡先・カメラ・位置情報にアクセスします」という承認フローが定着しましたが、形骸化しました。ユーザーはアプリを使いたいがために、無意識に「許可」を押すようになり、結果として個人情報の大量漏洩を招きました。 構造：承認疲弊による“儀式化した許可” 4. AIエージェント（2020年代〜） そして現在、AIエージェントはカレンダー、メール、Webといった「不信頼な入力」を読み込み、LLMが解釈して行動に変換します。権限はブラウザ、ファイル操作、API実行と多岐にわたります。 構造：不信頼入力 → LLMによる解釈 → 高権限アクション ActiveXの再来、しかしより危険な理由 DXTは構造的に「ActiveXのAI版」と言えます。不信頼なWebページ（入力）から、高権限コードの実行につながり、ユーザーの承認プロセスが機能しない点において、両者は共通しています。 しかし、決定的な違いがあります。それは攻撃ベクトルが 「コード」ではなく「自然言語（文章）」 であるという点です。 攻撃に「技術力」が不要になった かつてのActiveX時代、攻撃を実行するには最低限の技術力が必要でした。 COMオブジェクトやOS権限モデルの理解 JavaScriptやVBScriptのコーディングスキル つまり、攻撃者は「技術者」である必要があり、攻撃のコストと敷居はそれなりに高いものでした。 一方、AI時代の攻撃（今回のDXT脆弱性など）は、その敷居を劇的に下げています。 カレンダーは外部から汚染されやすい（ICSファイルは誰でも送付可能） メールから予定が自動生成される 共有カレンダーには誰でも書き込める 攻撃者は「カレンダーの予定に文章を書く」だけでAIを乗っ取ることが可能です。コーディングも、AIの専門知識も、LLMの深い理解も必要ありません。必要なのは 「文章を書く能力」 だけです。 脆弱性の質的変化 今回の事例と、従来の脆弱性を比較すると、その性質の違いが浮き彫りになります。 ...

ITmediaの 「メモ帳」の対応で脚光を浴びるMarkdown　AI時代の“文書共有のスタンダード”になるか という記事を読みましたが、技術的背景を知る者としては、正直なところ強い危機感を覚えずにはいられませんでした。この記事は、おそらくインプレスの「技術の泉シリーズ Markdown ライティング入門」などをベースに構成されたものと推測されますが、紹介されているツールや認識が数世代前で止まってしまっています。 2026年という現在、Markdownはもはや「普及するかもしれない」技術ではなく、 エンジニアリングと文書作成の分かちがたい交差点 として確立されています。本稿では、同記事で見られた技術的な誤謬を正しつつ、現代における真のMarkdownワークフローを整理します。 1. ツール選定における「出土品」レベルの乖離 まず、Markdownエディタとして「MarkdownPad」や「MacDown」が挙げられている点に驚きを禁じ得ません。MarkdownPadは2013年にMarkdownPad2へと移行しましたが、その後、Microsoftの Visual Studio Code (VS Code) という圧倒的なデファクトスタンダードが登場したことで、その役割を終えています。 今、初心者にこれらの化石化したツールを勧めるのは、令和の時代に「インターネットをするならNetscape Navigatorがいいですよ」と教えるようなものです。 Cursorは「モデル」ではなく「フォーク」である 記事中では以下のような記述がありました。 「Cursor」はこれ（VS Code）をモデルに作られているので、元祖の方でもMarkdown記法に対応している。 技術メディアとして、ここは正確に 「Code - OSSをフォークして開発されている」 と記述すべきです。「モデルにしている」という曖昧な表現では、バイナリ互換性や拡張機能の共有性といった重要な技術的構造が伝わりません。 2. 破壊されているワークロードとAIの拒絶 最も致命的だと感じたのは、執筆環境に関する以下の助言です。 「Markdown Editor」という拡張機能があり、それをインストールするとレンダリングした状態で執筆が可能になる。ただ「Markdown Editor」上で書くと、「Cursor」の特徴であるAIのサジェスチョンが表示されないので…… この「編集画面をプレビュー画面で上書きする」スタイルは、現代のAI駆動開発（AI Native Development）とは極めて相性が悪いものです。CursorやVS Codeの真髄は、エディタがテキストの構造を理解し、AIがリアルタイムで補完や修正を提案することにあります。 標準のプレビュー機能を Side by side (左右分割) で配置すれば済む話を、わざわざAIの恩恵を殺すような拡張機能を紹介するのは、読者を「一番不便で、AIの恩恵を受けられない呪われた環境」に閉じ込める行為に他なりません。 3. 現代のMarkdownエコシステム：Mermaidと自動化 現代のMarkdownは、単なるリッチテキストの代替品ではありません。 Mermaid による図解のコード化、 Pandoc による高度な形式変換、 GitHub Actions による自動ビルドなど、高度に自動化されたエコシステムの一部です。 graph TD A[Markdown Source] -->|AI Pair Programming| B(VS Code / Cursor) B --> C{Processor} C -->|Mermaid| D[Diagrams / Flowcharts] C -->|Pandoc| E[PDF / Docx / LaTeX] C -->|Static Site Gen| F[Hugo / Astro / Zenn] D & E & F --> G[Knowledge Asset] subgraph "Legacy View (Critiqued Article)" H[MarkdownPad] --> I[Manual Preview] I --> J[Text Only Output] end 上記の図が示すように、現代的なワークフローでは「テキストを書いて終わり」ではなく、図解（As Code）やCI/CDを含めた一連のパイプラインとしてMarkdownを扱います。 ...