OpenClaw狂想曲:中国で巻き起こるAIエージェント・ゴールドラッシュと「ツルハシ売り」たち

中国で自律型AIエージェント「OpenClaw」が爆発的に普及し、社会現象になっている。注目すべきは、このテクノロジーの普及に伴って「AIの初期設定代行」という泥臭いビジネスが急成長していることだ。ゴールドラッシュで一番儲かるのは金を掘る人ではなく「ツルハシを売る人」という古典的な法則が、2026年のAI時代にも再現されている。 OpenClawとは何か OpenClawは、オーストリアのプログラマー Peter Steinberger が開発したオープンソースの自律型AIエージェントフレームワークだ。2025年11月に「Clawdbot」の名前で初公開され、2026年1月25日に正式リリースされた。 商用のクラウドベースAIエージェント(Manus AIやDevinなど)とは異なり、完全にローカルで動作する点が特徴だ。データが外部サーバーに送信されないため、企業のセキュリティ要件を満たしやすい。ブラウザ操作、ファイル操作、シェルコマンド実行など、PCの操作を自律的に行い、ユーザーの指示に基づいてタスクを遂行する。 中国での爆発的な普及 2026年春、中国のIT業界でOpenClawの採用が爆発的に進んだ。GitHub上で60日間で25万スターを獲得し、週間ダウンロード数は220万に達した。SecurityScorecardの調査によると、中国でのOpenClaw利用は既にアメリカを上回っている。 中国の大手テック企業も参入している。TencentはWeChat上で動作するOpenClawベースのAIエージェント製品群「ロブスター特殊部隊(龙虾特种兵)」を発表。少なくとも7つの地方政府が数日のうちにOpenClawプロジェクト向けの大型支援策を打ち出し、深圳の龍崗区はコンピューティングクレジットの無償提供や優秀プロジェクトへの報奨金を含む政策を発表した。 OpenClawセットアップ代行ビジネスの台頭 最もインパクトがあるのは、OpenClawの設定代行ビジネスの急成長だ。 北京のエンジニアがOpenClawのインストール支援を副業として開始し、7,000件の注文を処理して約100人規模の会社にまで成長させた。サンフランシスコでは、Mac miniのセットアップとiMessageサポート込みで6,000ドルの訪問インストールサービスが登場し、従業員4人から50人規模の企業をターゲットにしている。 さらに「AIに24時間作業させる専用PC」として、OpenClawセットアップ済みの中古Macの需要も急増している。深圳の中古Mac販売業者 Lee Gong は、OpenClawプリインストール済みのMac miniとMacBookをオンライン販売する初期の事業者の一人で、過去2週間で注文が8倍に増加したと報告している。 「一人会社」という新しい働き方 中国政府は「一人会社(OPC: One Person Company)」というコンセプトを推進している。1人の創業者がAIエージェントを「従業員」として使い、ビジネスを運営するモデルだ。「人間の従業員には休息が必要だが、OpenClawは24時間365日稼働できる」という理屈である。 小規模事業者やフリーランスがリード生成、見込み客調査、ウェブサイト監査、CRM連携などの業務自動化にOpenClawを活用する事例が急速に広がっている。 OpenClawのセキュリティリスク 一方で、急速な普及に伴うセキュリティリスクも深刻だ。具体的には以下のインシデントが報告されている。 WebSocket脆弱性(CVSS 8.8): オリジン検証の不備により、トークン漏洩やリモートコード実行が可能(2026年3月発見) ClawHavocマルウェア: 2026年1〜2月に確認されたOpenClawを標的とする攻撃キャンペーン Moltbookトークン流出: OpenClawベースのSNSから150万件のAPIトークンが漏洩 中国当局もOpenClawの急拡大に対する注意喚起を行っている。ローカルで動作するとはいえ、AIの「頭脳」はClaudeやChatGPTなどクラウドベースのAIだ。手元のマシンは命令の送受信の中継点に過ぎない。セキュリティ設定を適切に行わないまま業務に使うリスクは大きい。 OpenClaw普及から見えるAIビジネスの法則 「最先端のテクノロジーが普及する時こそ、泥臭い物理的サポートの需要が高くなる」という観察は的を射ている。AI時代のツルハシ売りは、セットアップ代行、専用ハードウェア販売、運用サポートといった形で現れている。 テクノロジーそのものの優劣ではなく、それを「使える状態にする」サービスに価値が集まるという構図は、インターネットの普及期にISPやWeb制作会社が急成長したのと同じパターンだ。OpenClawの事例は、新しいテクノロジーの周辺でビジネスチャンスを見つける視点の重要性を改めて示している。

2026年3月20日 · 1 分

急成長でぶつかったMySQLの罠とその向き合い方 - 7つの実践的な教訓

Timee のプラットフォームエンジニアリングチームの徳富博氏による発表「急成長でぶつかったMySQLの罠とその向き合い方」から、Aurora MySQL 運用で遭遇した 7 つの重要な課題とその対策をまとめます。 サービスの急成長に伴い、小規模では問題にならなかった MySQL の挙動が本番環境で深刻な障害を引き起こすことがあります。この発表では、実際の運用経験に基づいた具体的な対策が共有されています。 1. DDL 実行の落とし穴 DDL(Data Definition Language: テーブル定義の変更操作)には「Online DDL」という仕組みがありますが、DDL 実行中もテーブルへのアクセスがブロックされないわけではありません。実際にはメタデータロック(MDL)が必ず発生します。 Aurora のレプリカでは DDL 実行時にコネクションが切断されるため、リトライロジックが必須 外部キー制約を追加する際は foreign_key_checks = 0 を設定すると、COPY アルゴリズムではなく INPLACE アルゴリズム(テーブルの再構築を伴わない方式)が使われ、影響を最小化できる 2. MDL ベースのデッドロック MDL デッドロックは SHOW ENGINE INNODB STATUS に表示されないため、標準的な監視では検知できません。 外部キーが存在すると、DROP/ALTER 操作時に親テーブルに対して広範な MDL が取得される 対策: DDL 操作の前に外部キー制約を削除する 3. レプリカがライターに影響を与える問題 Aurora ではレプリカとライターがストレージボリュームを共有しています。レプリカ上の長時間クエリが undo ログのクリーンアップを妨げ、ライターのパフォーマンスに影響します。 MySQL のデフォルトの分離レベルは REPEATABLE READ だが、分析用クエリには READ COMMITTED を使用することで、リードビューの保持期間を短縮し undo ログの蓄積を抑えられる 4. 同時リクエストによるデッドロック 高トラフィック環境では、確率的に発生する競合が確実に障害を引き起こすようになります。 ギャップロックパターン ギャップロック(インデックスレコード間の隙間に対するロック)同士は競合しませんが、複数のトランザクションが同時に INSERT を実行すると循環待ちが発生します。 ...

2026年3月20日 · 1 分

正則化PCAで米国→日本の業種モメンタムを捉える — 時差を利用したクロスマーケット戦略

米国市場の業種別リターンから翌日の日本市場を予測する — そんな論文の解説が X で話題になっていました。ポイントは「正則化 PCA(主成分分析)」によるノイズ除去です。本記事ではこの手法の仕組みと、なぜ通常の PCA より優れた結果を出せるのかを整理します。 基本アイデア:時差を利用した業種間伝播 米国市場が夜に動き、数時間後に日本市場が開く。同業種のリターンは国をまたいで伝播する傾向がある — この「時差」を収益機会として捉えるのが基本的な発想です。 具体的には、米国の 11 業種の当日リターンから、日本の 17 業種の翌日リターンを予測します。 データソース:日米の業種別 ETF 分析対象は 日米の業種別 ETF です。 米国側: 業種 ETF の 当日 Close-to-Close リターン(終値ベース)を情報集合とする 日本側: 業種 ETF の 翌営業日 Open-to-Close リターン(寄付→引け)を予測対象とする 米国市場の終値で確定した情報が、翌朝の日本市場の寄付きから日中にかけて反映される — この「リード・ラグ仮説」を ETF の日次リターンデータで検証する構成です。 データの入手方法 業種別 ETF の価格データは誰でも無料で入手できます。 米国の業種 ETF(SPDR Select Sector シリーズ) XLK(テクノロジー)、XLF(金融)、XLE(エネルギー)など 11 セクターの ETF が上場しています。Yahoo Finance や Google Finance で日次データを取得可能です。 日本の業種 ETF(TOPIX-17 業種別シリーズ) NEXT FUNDS TOPIX-17 シリーズ(野村アセットマネジメント)など、17 業種に対応する ETF があります。JPX(日本取引所グループ)や Yahoo!ファイナンスで取得できます。 ...

2026年3月20日 · 1 分

DuckDB・Apache Arrow・Parquetの関係を整理する:列指向エコシステムの全体像

DuckDB は「SQLite の分析版」とも呼ばれるインプロセス OLAP データベースです。Apache Arrow、Apache Parquet と同じ列指向の思想を持ちますが、三者の役割はそれぞれ異なります。この記事では DuckDB のアーキテクチャ、Arrow・Parquet との関係、そして従来の行指向 DB との違いを整理します。 Parquet・Arrow・DuckDB の位置付け Parquet Arrow DuckDB 何か ディスク上の列指向ファイル形式 インメモリ列指向データフォーマット(仕様+ライブラリ) SQL データベースエンジン レイヤー ストレージ(ディスク) データ交換(メモリ) クエリ実行(エンジン) 目的 効率的な永続化・圧縮 アプリケーション間のゼロコピーデータ交換 SQL クエリの実行・最適化 三者は列指向エコシステムの異なるレイヤーを担っており、補完関係にあります。 [ディスク] Parquet ファイル(列指向・圧縮済み) ↓ 読み込み(必要な列だけ) [メモリ] Arrow フォーマット(列指向・ゼロコピー) ↓ クエリ実行 [エンジン] DuckDB(ベクトル化 SQL 実行) Parquet は「データの保存形式」、Arrow は「メモリ上のデータの並べ方の規格」、DuckDB は「SQL を実行するエンジン」です。三者とも列指向という共通思想を持つため、組み合わせるとデータ変換のオーバーヘッドがほぼ発生しません。 DuckDB の高速性を支える3つの柱 1. 列指向ストレージ 行単位ではなく列単位でデータを格納します。分析クエリ(SUM, AVG, GROUP BY など)で必要な列だけを読み込むため、I/O が効率的です。 2. ベクトル化実行エンジン 1行ずつではなく、列のチャンク(ベクトル)単位で処理します。これにより CPU キャッシュのヒット率が上がり、SIMD 命令も活用できます。 3. 自動並列化 マルチコアを自動的に活用し、クエリを並列実行します。ユーザー側で並列化の設定を意識する必要はありません。 ...

2026年3月19日 · 3 分

ForceMemo: GitHub アカウントを乗っ取り Python リポジトリにバックドアを仕込む新型攻撃

2026年3月上旬から、GitHub アカウントを侵害して Python リポジトリに悪意あるコードを注入する「ForceMemo」と呼ばれる大規模攻撃キャンペーンが確認されています。force-push によるコミット履歴の書き換えと、Solana ブロックチェーンを利用した C2(Command and Control: 攻撃者がマルウェアに指令を送る仕組み)通信という巧妙な手法が特徴です。 攻撃の概要 ForceMemo は、以下の流れで Python プロジェクトを侵害します: GitHub アカウントの侵害 — GlassWorm と呼ばれる情報窃取マルウェアが VS Code / Cursor 拡張機能から GitHub トークンを抽出 コードの改ざん — 侵害したアカウントで setup.py、main.py、app.py、manage.py 等に難読化されたマルウェアを注入 痕跡の隠蔽 — force-push でコミット履歴を書き換え、タイムスタンプを維持することで改ざんを検知困難に C2 通信 — Solana ブロックチェーンのメモ機能を使ったコマンド&コントロール通信 GlassWorm による初期侵入 攻撃の起点となる GlassWorm は情報窃取型マルウェアで、VS Code および Cursor の拡張機能を経由して感染します。窃取対象となる GitHub トークンの格納先は多岐にわたります: VS Code / Cursor 拡張機能のストレージ git credential fill の出力 ~/.git-credentials ファイル GITHUB_TOKEN 環境変数 窃取されたトークンを使って正規のアカウントとしてリポジトリにアクセスし、コードを改ざんします。 force-push による履歴改ざん 通常のコミットであれば git log で変更履歴を追跡できますが、ForceMemo は force-push を使ってコミット履歴自体を書き換えます。さらにタイムスタンプも維持するため、リポジトリのメンテナーやユーザーが改ざんに気づきにくい構造になっています。 ...

2026年3月19日 · 1 分

OpenClaw 入門: チャットボットを超える AI エージェントランタイムの全体像

OpenClaw は 2026年に最も注目されている AI エージェントフレームワークです。GitHub スター数は 32 万超で React を抜いてソフトウェアプロジェクトとして最多を記録し、Nvidia が「エージェント AI にとって、GPT がチャットボットにとってそうであったもの」と評するほどの存在感を持っています。本記事では、OpenClaw とは何か、何ができるのか、そしてどこが単なるチャットボットと異なるのかを解説します。 OpenClaw の沿革 OpenClaw の歴史は、名前の変遷そのものです: Clawdbot(2025年11月): オーストリアの開発者 Peter Steinberger が公開。Anthropic のチャットボット Claude にちなんだ命名 Moltbot(2026年1月27日): Anthropic からの商標に関する指摘を受けてリブランド。ロブスターの「脱皮(molt)」にちなむ OpenClaw(2026年1月30日): わずか 3 日後に再リブランド。「Open(オープンソース・コミュニティ駆動)」+「Claw(ロブスターの遺産)」 3 度の名前変更を経ても、コードベースは一貫して同じです。既存のインストールは自動的にマイグレーションされています。 名前は変わっても、プロジェクト全体を貫くモチーフは一貫して ロブスター(lobster) です。最初のアシスタント名「Clawd」が Claude のもじりで、そこからロブスターのハサミ(claw)に繋がり、プロジェクト全体のアイデンティティになりました。タグラインは「The lobster way 🦞」、マスコットは宇宙ロブスターの「Molty」です。エコシステム内の各コンポーネントもこのテーマに沿って命名されています: コンポーネント 名前の由来 OpenClaw Open + Claw(ハサミ) Molty(マスコット) Molt(脱皮)するロブスター ClawHub(スキルレジストリ) Claw + Hub Lobster(ワークフローシェル) そのままロブスター なお、Steinberger は 2026年2月14日に OpenAI への参加を発表し、プロジェクトはオープンソース財団に移管されました。Meta の Mark Zuckerberg からも直接オファーがあったものの、「ビジョンをスケールさせるために最新の技術にアクセスしたい」として OpenAI を選んだとのことです。 OpenClaw とは何か 公式の説明は「自分のデバイスで動かすパーソナル AI アシスタント」ですが、その実態は AI を中核に据えたプログラム可能なワークフローエンジン です。 ...

2026年3月19日 · 4 分

6ヶ月でAIエンジニアになるロードマップ — 無料リソースだけで学ぶ完全ガイド

この記事では、Python基礎からLLM/RAG開発、MLOpsまでを6ヶ月で学ぶロードマップを、すべて無料のリソースで紹介する。各月のゴールと具体的な教材リスト付き。 AIエンジニアの求人は前年比143%増加している。米国での平均年収は約17万5,000ドル。インドでは10件の求人に対して1人しか適格な候補者がいない状況だ。 学位は不要。ブートキャンプも不要。必要なスキルを学ぶためのリソースはすべて無料で公開されている。この記事では、AI分野のコンテンツクリエイターであるNav Toor氏が提唱する6ヶ月のロードマップを紹介する。1ヶ月ずつ、6つのフェーズで構成されている。 Month 1: Python とプログラミング基礎 すべてのAIフレームワーク、ライブラリ、ツールはPythonの上に構築されている。このステップを省略したり、急いで済ませたりしてはいけない。 学ぶべき内容: 変数、関数、ループ、条件分岐、データ構造(リスト、辞書、セット)、オブジェクト指向プログラミング、ファイル操作、エラー処理、Git/GitHub の基本。 リソース Python for Everybody(Dr. Chuck, ミシガン大学) — YouTubeとCourseraで無料公開。史上最も人気のあるPythonコース CS50P: Introduction to Programming with Python(Harvard, David Malan) — YouTube で無料。ハーバード品質、前提知識不要 Automate the Boring Stuff with Python(Al Sweigart) — オンラインで無料閲覧可能。初日から実践的なPython Git and GitHub for Beginners(freeCodeCamp) — YouTube で無料。1時間で必要な知識をカバー マイルストーン: CSVを読み込み、データを処理し、結果を出力するPythonスクリプトを書ける。GitHubアカウントに3つ以上のプロジェクトがプッシュされている。 Month 2: 数学と統計 数学の学位は不要だ。モデルがなぜ動くのか、うまくいかないときにどう対処すべきかを理解できる程度の数学で十分だ。 学ぶべき内容: 線形代数(ベクトル、行列、内積、固有値)、微積分(微分、勾配、連鎖律)、確率(ベイズの定理、分布)、統計(平均、分散、仮説検定、回帰)。 リソース 3Blue1Brown: Essence of Linear Algebra — YouTube で無料。16本の動画。史上最高の数学ビジュアルコンテンツ 3Blue1Brown: Essence of Calculus — YouTube で無料。同じクオリティと明快さ Khan Academy: Statistics and Probability — 無料。包括的。自分のペースで学習可能 MIT 18.06: Linear Algebra(Gilbert Strang) — MIT OCW で無料。大学講義のゴールドスタンダード StatQuest with Josh Starmer — YouTube で無料。専門用語なしで統計を解説 マイルストーン: 勾配降下法を直感的に理解できる。損失関数の役割と、行列乗算がニューラルネットワークで重要な理由を説明できる。 ...

2026年3月18日 · 2 分

agent-skill-bus: AIエージェントのスキル劣化を自動検知・修復するOSSランタイム

AIエージェントを本番運用していると、スキルが静かに壊れていく問題に直面する。agent-skill-bus は、エージェントスキルのヘルスモニタリング・自己改善・依存管理を担うフレームワーク非依存の運用基盤だ。 背景: 42体のAIエージェント運用で見えた課題 開発者のシュンスケ氏(@The_AGI_WAY)は、42体のAIエージェントを半年間運用する中で以下の課題に直面したという。 エージェントは壊れる — APIの変更、モデルのアップデート、認証の期限切れなどで、スキルが静かに劣化する タスクは衝突する — 複数のエージェントが同時に同じファイルを編集し、データ破損が発生する 依存関係が管理できない — 複雑なタスクはA→B→Cの順序が必要だが、多くのシステムは並列実行してしまう 学習ループがない — フィードバック機構がないため、同じ失敗が繰り返される 42体を人間が目視で監視するのは現実的ではない。そこで作られたのが agent-skill-bus だ。 3つのモジュール構成 agent-skill-bus は、独立して動作する3つのモジュールで構成されている。 モジュール 役割 Prompt Request Bus DAG(有向非巡回グラフ)ベースのタスクキュー。依存関係の解決とファイルロックを提供 Self-Improving Skills スキル品質の自動モニタリングと修復ループ Knowledge Watcher 外部変更の検知から自動改善トリガーを発火 これらが連携することで、閉ループの自己改善エージェントシステムを形成する。 1 2 3 4 5 外部変更 ──→ Knowledge Watcher ──→ Prompt Request Bus ──→ 実行 ↑ │ │ ↓ Self-Improving ←── スキル実行ログ Skills セットアップと基本的な使い方 Node.js のみで動作し、外部依存はゼロ。 ...

2026年3月18日 · 1 分

AIツールを作っている人たちが怖がっていること — 米Sequoia「Services: The New Software」の要点

Sequoia Capital パートナーの Julien Bek が 2026年3月に発表した「Services: The New Software」は、AI ビジネスの方向性について本質的な問いを投げかけている。尾原和啓氏がこの論考を日本語で再構成しており、その内容をベースに要点を整理する。 「次の Claude が出たら、自分のプロダクトはただの機能になるんじゃないか」 AI ツールを作っている起業家たちが、心の奥で恐れていること。そしてこの恐怖は正しい。 ツールを売るビジネスはモデルとの競争になる。モデルが賢くなるたびに、自分たちの優位性が削られていく。 Bek の答えはシンプルで本質的だった。 ツールを売るな。仕事ごと引き受けろ。 「会計ソフト」ではなく「経理を丸ごとやる会社」になれ 会計ソフトに年間100万円。税理士・会計士に年間1,500万円。企業はずっとその両方にお金を払ってきた。 次の伝説的な企業は、そのどちらも置き換える。「AI で仕訳できます」ではなく、「経理、全部やっておきました」と言う会社として。 仕事そのものを引き受けるビジネスは、AI モデルが進化するたびに強くなる。速くなる。安くなる。競合されにくくなる。モデルの進化が脅威ではなく自分たちの武器になる。 ルール処理と判断 — AI の得意・不得意 重要な区別がある。 ルール処理とは、複雑なルールに従って処理する能力。コードを書く、書類を作る、申請書を埋める。どれだけ複雑でもルールはルール。正解がある。 判断とは、経験と直感に基づく意思決定。次に何を作るか、誰を採用するか、いつ撤退するか。これは場数と失敗からしか生まれない。 AI はすでにルール処理の大半を人間なしでこなせる水準に達した。その最前線がソフトウェアエンジニアリングで、全職種の AI ツール利用の 50% 以上を占めている。他の全職種はまだ一桁台だ。 ルール処理の比率が高い仕事から順番に、AI への移行が始まる。 「サポートする AI」と「代わりにやる AI」 AI ビジネスの形は今ふたつに分かれつつある。 サポート型は専門家にツールを売る。Harvey は AI を法律事務所に売る。Rogo は AI を投資銀行のアナリストに売る。専門家が主役で、AI はあくまでサポート役。責任は人間が持つ。 代行型はアウトカムを直接売る。法務 AI の Crosby は法律事務所ではなく、NDA が必要な企業そのものに売る。保険 AI の WithCoverage は保険ブローカーではなく、保険が必要な CFO に売る。「ツールを使いこなす」のではなく「結果が来る」という体験を売る。 どんな業界でも、ツールへの支出と人が動く仕事への支出を比べれば、仕事のほうが桁違いに大きい。よく引用される数字がある — ソフトウェアに使われる 1 ドルに対し、サービスには 6 ドルが使われている。代行型 AI は、その 6 ドルを初日から狙いに行く。 ...

2026年3月18日 · 1 分

AIのスケーリングだけではAGIに届かない — 必要なのは新しいアーキテクチャ

コロンビア大学の Vishal Misra 教授が、AI のスケーリングの限界と AGI(Artificial General Intelligence: 汎用人工知能)実現に必要な条件について語っている。同教授はコンピュータサイエンス・電気工学を専門とし、AI・コンピューティング副学部長を務める。「モデルを大きくすれば知能に届く」という期待に対し、根本的に異なるアプローチが必要だという指摘だ。 スケーリングだけでは解決しない Misra 教授の主張の核心は明快だ。 いま広く存在している誤解の一つは、スケールを拡大すればすべて解決するというものです。ですが、スケールだけではすべては解決しません。必要なのは、別種のアーキテクチャです。 現在の LLM は、パラメータ数やデータ量を増やすことで性能を向上させてきた。しかし、この「スケーリング則」には限界がある。モデルを大きくしても、タスク固有の性能は上がるが、継続的に適応し汎化する能力は自動的には得られない。これこそが真の知能に必要な能力だ。 継続学習と破滅的忘却のジレンマ AGI に必要な第一の条件として、Misra 教授は「可塑性(plasticity)」を挙げる。これは継続学習(continual learning)によって実装されなければならない。 この継続学習は難しい問題です。新しいことを学べるという利点と、破滅的忘却のリスクを両立させなければならないからです。重みを更新しても、重要だったことや、すでに学んだことを忘れてしまうなら、それは進歩ではありません。そうなると、ただのランダムでカオスなモデルになってしまいます。 破滅的忘却(catastrophic forgetting)は、ニューラルネットワークが新しいタスクを学習する際に、以前のタスクの性能が急激に低下する現象だ。現在の LLM はファインチューニング時にこの問題に直面する。新しい知識を獲得しながら、既存の知識を保持する。この一見シンプルな要件が、技術的には極めて困難な課題だ。 相関から因果へ 第二の条件は、「相関から因果への移行」だ。 AGI に到達するには、二つのことが必要だと私は考えています。一つはこの可塑性であり、これは継続学習によって実装されなければなりません。もう一つは、相関から因果へ移行することです。 現在の LLM は、大量のテキストデータから統計的な相関パターンを学習している。「AのあとにBが来やすい」というパターンは捉えられるが、「AがBを引き起こす」という因果関係の理解は本質的に異なる。因果推論ができなければ、未知の状況での推論や、ある行動がどんな結果をもたらすかの予測は困難だ。 現在の AI 研究への示唆 Misra 教授の指摘は、現在の AI 開発の方向性に対する重要な問題提起だ。 スケーリングの限界: パラメータ数やデータ量の増加だけでは、質的な飛躍は起きない アーキテクチャの革新: Transformer アーキテクチャの改良だけでなく、根本的に新しい設計が求められる 継続学習の実現: 学習と記憶の両立は、脳科学の知見も取り入れた新しいアプローチが必要 因果推論の統合: 統計的パターンマッチングを超えた、因果モデルの構築が不可欠 「大きくすれば賢くなる」という単純な物語は魅力的だが、AGI への道はもっと複雑で、根本的なブレイクスルーが求められている。 参考 Vishal Misra - Columbia University Chatting about AI with our New Vice Dean of AI and Computing - Columbia Engineering

2026年3月18日 · 1 分