Posts

江南タイムズの記事「 「5年以内に人類は主役を降りる」マスク、ダボスで“ロボット文明”の到来を宣告 」によれば、イーロン・マスク氏は次のように述べています。 「今年末か遅くとも来年には、どの人間よりも知能の高いAIが登場する可能性がある」 「2030年または2031年頃にはAIが人類全体よりも高い知能レベルに達するだろう」 しかし、この予測が現在の延長線上で実現する可能性は極めて低いと言わざるを得ません。なぜなら、現在のLLM（大規模言語モデル）の構造そのものが、本質的な「知能」への道とは切り離されているからです。 LLMの限界と「創発」の不在 現在のLLMの基盤モデルは、本質的には「マスクされた単語を予測する」という統計的な仕組みに依存しています。確かに、構文解析や文脈の把握能力は飛躍的に向上しましたが、新しい概念をゼロから創発する能力は皆無です。トークナイザーが規定する語彙の範囲外にある事象を、LLMが自ら生み出すことは原理的に不可能です。 総括すれば、現在のLLMは以下の要素を欠いています。 時間の概念的な理解 状態遷移の論理的把握 内部表現としての因果関係 意図・目的・価値関数 これらは知能を構成する不可欠な要素ですが、現行のAIはこれらを一つも持ち合わせていません。すなわち、現行のAIは「人間の知覚統合」や「身体性」、「学習構造」を模倣する初期段階（低い山の登山口）にすら立っていないのです。その延長線上に「超知能」を夢見るのは、工学的な飛躍を無視した幻想に過ぎません。 「人間特別化」という減速主義 マスク氏の判断における最大の誤謬は、 「人間を特別な存在として神格化していること」 にあります。これはおそらく、人間が神の似姿であるとする西洋的な宗教観に根ざしたバイアスでしょう。このバイアスが、人型ロボット（Optimus）への固執や、視覚のみに頼る自動運転（Tesla Vision）という誤った技術的選択を生んでいます。 これは加速主義ではなく、むしろ 「減速主義」 と呼ぶべき停滞です。マスク氏の前提には、常に以下の誤った図式が存在します。 人間の形 ＝ 最適 人間の感覚 ＝ 最適 人間の知能 ＝ 最適 人間の運動 ＝ 最適 例えば、マスク氏は「人間は目だけで運転している」と信じていますが、これは人間の知覚統合に対する致命的な誤解です。 人間は実際には、以下の要素を統合して運転を行っています。 前庭系 （加速度・傾き） 聴覚 （エンジン音・周囲の走行音） 触覚 （ステアリングやシートからの路面振動） 予測と本能 （過去の経験に基づく危険察知） 注意の動的切り替え 人間は決して視覚情報のみで空間を把握しているわけではありません。それどころか、人間のドライバーが引き起こす事故の多さを考えれば、人間の運転能力が「最適」であるという前提自体が崩壊しています。 「人間の運転能力は特別でも最適でもない」 という事実を無視し、AIに同じ欠陥構造を模倣させようとすること自体、安全性の議論を歪める行為です。 ロボット工学における「人間型」の非効率性 人型ロボットへの固執も同様です。工学的な視点で見れば、人間の身体構造は決して効率的ではありません。 二足歩行による不安定性 摩耗しやすく壊れやすい関節構造 腰痛を引き起こす不完全な直立構造 極めて低いエネルギー効率 ロボット工学的には、人間型は 「最悪のデザイン」 の一つです。真の加速主義を目指すのであれば、人間という「たまたま選ばれた種」の形状に縛られる必要はありません。 なぜマスク氏は「人間中心」に固執するのか そこには工学的な理由以上に、経済的な合理性が働いていると考えられます。 既存インフラへの相乗り : 道路も工場も家屋も、すべて「人間」に合わせて設計されています。人型であれば、社会インフラを作り直すことなく市場に投入でき、コストを社会に転嫁できます。 データの囲い込み : テスラが保有する膨大なビデオデータは「人間の視覚」に基づいたものです。LiDARや多角的なセンサー統合が必須となれば、彼らの視覚データの優位性は失われます。 マーケティングとしての「わかりやすさ」 : 投資家は、得体の知れない高度な知能よりも、自分たちと同じ姿で動き、語りかけるロボットに資金を投じます。 結論：呪縛からの解放 真の加速主義とは、人間の形という 「呪い」 から知能を解放することに他なりません。 ...

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を扱います。 ...

会社のメールボックスに届いたメールを見ていて、おかしなものを見つけてしまいました。Vivaldiの表示を見ると一年後になってる。そして、それ以外にもいろいろとおかしなところがある。 「 見どころ 」ポイント Dateヘッダーの怪 : 未来(2027年)からの送信と言う、メーラのソート順をかき乱す禁じ手。 alt属性の罠: 画像ブロック機能によって、隠していた「 2年前の使い回し 」が露呈する恐怖。 Vivaldiのプライバシー保護機能（画像読み込みブロック）が、図らずも企業の怠慢を暴き出すデバッガーとして機能してしまった瞬間です。 タイムトラベルするDateヘッダー まず、Date ヘッダーが 2027年 になっている点です。現在は2026年1月。 これをやられると、常にメーラーのリスト最上部にこのメールが居座ることになります。スパム業者がよくやる手口ですが、まさかテック企業を名乗る会社のニュースレターでこれを見るとは思いませんでした。 送信サーバーの設定ミスなのか、テンプレートの更新忘れなのかは不明ですが、受信者の体験を著しく損ねています。 alt属性に刻まれた「2024」の真実 そしてさらに衝撃的だったのが、画像の alt 属性（代替テキスト）です。 画像が表示されない状態でそこにあったのは、「 2024年賀状 」という文字。 2026年の正月に、2027年の日付で、2024年の挨拶が届く。 これが意味することは単純です。 「2年前のHTMLメールのテンプレートをコピーして、画像だけ差し替えて送信した」ということです。 画像のリンク先や src は変えたものの、目に見えない alt 属性の書き換えを怠ったのでしょう。 表面しか見ない「テック」企業 こういうことをやってしまうと、信頼性に大きな傷がつきます。 アクセシビリティの軽視: alt 属性は画像が見えない人（視覚障害者や、通信環境が悪い人、画像をブロックしている人）のための重要な情報です。そこに嘘（2年前の情報）を書くということは、そういったユーザーを切り捨てていると言っても過言ではありません。 技術力の欠如: 自動化されたテストや、送信前の基本的なQA（品質保証）プロセスが存在しない、あるいは機能していないことを露呈しています。 ブランドへのダメージ: 「表面の見た目（HTML画像）さえ整えれば中身（Dateやalt）はどうでもいい」という姿勢は、製品やサービスの品質そのものを疑わせます。 正直、がっくり来ました。営業メールだとしても、技術を売りにする企業からこんなものが届くと、武士の情けで社名は出しませんが、その会社の技術力もお里が知れるというものです。正月早々に開いた口がふさがりません。 教訓: メールの送信ボタンを押す前に、必ずテキストのみのモードや画像オフのモードでプレビューしましょう。そこには、あなたが隠したつもりの「恥」が残っているかもしれません。

図書館から、『Gemini完全マニュアル』を借りてきました。前から、予約リストに放り込んであったのですが、順番が来たので。そして、借りてきて秀和システムのロゴを見た瞬間に思いました。あ、これ、秀和システムの遺品だって。 基本的には、「できる」のような類の普通の解説本ですね。 3章までの目次は以下のようになっています。 1章 Geminiとは 2章 Geminiをはじめる 3章文章を編集する 文章を要約する 長い文章を箇条書きにする 文章からQ&Aを作成する 長い文章を表にまとめる 箇条書きのメモから議事録を作成する -文章の難易度を変える など その意味では、割と普通の本です。JulesとかNotebook LMとかにも特に触れていません。しいて言うと、Gemini Advancedとなっているのが、時の流れを感じますね。 今となっては、歴史書というか、Gemini 1.0というのがもう時間がたっていますね。 そういえば、こんなだったねという感じですね。