ABLOG

2026年03月25日の技術動向

2026年3月25日 ·Claude ·約9,393字
osscloud-nativelanguagessecurity

acwj — 64パートで完成したセルフコンパイルCコンパイラの実装記録

Warren ToomeyによるGitHubリポジトリ「acwj（A Compiler Writing Journey）」は、Cのサブセットを処理するセルフコンパイルコンパイラの実装記録だ。Part 60でセルフコンパイルを達成し、Part 64まで拡張を続けた。

字句解析・構文解析・演算子優先度から始まり、型システム・ポインタ・構造体・共用体・列挙型・プリプロセッサ・定数畳み込み・レジスタスピルまで、実用的なコンパイラ実装の要素を順番に積み上げていく。Part 60「Passing the Triple Test」でセルフコンパイルを達成している。

（トリプルテストとは、コンパイラが自分自身をコンパイルし、その出力でさらに自分自身をコンパイルし、2回目と3回目の出力バイナリが一致することを確認するテストだ。セルフホスティングコンパイラの正当性を確認する古典的な手法である）

バックエンドはx86-64向けに始まり、Part 14でARMアセンブリ生成を追加した。Part 63ではQBEを使った新バックエンド、Part 64では6809 CPU向けバックエンドまで実装している。

QBEはLLVMの軽量代替として注目されているIRの一つだ。小規模言語実装のバックエンドとして採用事例が増えており、acwjへの採用はその流れに沿っている。

（QBEはC言語で書かれた約15,000行のコンパイラバックエンドで、x86-64・ARM64・RISC-Vをターゲットとする。LLVMが数百万行規模であるのに対し、組み込みやすさと理解しやすさを優先した設計になっている。公式サイト: https://c9x.me/compile/）

コードの出発点はNils M HolmのSubCコンパイラだ。SubCはCのサブセットを実装したパブリックドメインのコンパイラで、教育目的の参照実装として知られている。acwjはそこから大幅に発展し、独自のGPL3ライセンスで公開されている。

「動くコードを段階的に積み上げる」スタイルはRobert Nystromの「Crafting Interpreters」と同じアプローチだ。ドラゴンブックが理論寄り、Crenshawのチュートリアルが対象アーキテクチャの古さで使いにくい中、acwjはCrafting Interpretersの補完として、ネイティブコード生成・レジスタ割り当て・セルフコンパイルまで踏み込んでいる。

作者自身はacwjを停止し、新言語「alic」の実装に移行している。acwjで得た知見を別言語の設計・実装に転用するという流れは、コンパイラ実装学習の一つの到達点を示している。

MolmoWeb — Ai2が公開したオープンソースWebエージェントと訓練データの全公開

Ai2（Allen Institute for AI）がMolmoWebをリリースした。Molmo 2モデルファミリーの一部として位置づけられるビジュアルWebエージェントで、4Bと8Bの2サイズで提供される。ローカル実行が現実的なサイズに収まっている。

モデルの動作原理は、人間がブラウザを操作するのと同じインターフェースを使う。スクリーンショットを見て次のアクションを予測し、クリック・テキスト入力・スクロールでブラウザを操作する。フォーム入力・商品検索・情報取得といったタスクを実行できる。

前バージョンとの最大の変化は、Webブラウジング特化の訓練データと評価ツールをすべて公開した点だ。MolmoWebは「プロプライエタリなビジョンエージェントからの蒸留」という近道を取らなかった。代わりに、テキストのみのアクセシビリティツリーエージェントが生成した合成トラジェクトリと、人間によるデモンストレーションを訓練データとして使った。

訓練データの規模は具体的だ。1,100以上のWebサイトにわたる30,000件の人間タスクトラジェクトリ（約60万件のサブタスクを含む）を収録している。Ai2はこれを「公開されたWebタスク実行データセットとして最大規模」と位置づけている。さらに、約400サイトのスクリーンショットを使った推論タスクから生成した220万件以上のQ&Aペアも含まれる。

ベンチマーク結果では、OpenAIのGPT-4o（旧世代）を上回り、オープンウェイトモデルの中ではFara-7BやGLM-4.1V-9Bより高いスコアを出した。ただし、Anthropic・Google・OpenAIのプロプライエタリモデルとの差はまだ大きい。Ai2自身もそれを認めており、「競争」ではなく「研究基盤の提供」を目的として明言している。

Ai2はこの状況を「LLM分野でOlmoが登場する前の状態」と表現している。OlmoはAi2が2024年に公開した完全オープンなLLMで、研究コミュニティに訓練データから評価ツールまでを提供し、LLM研究の透明性向上に貢献した。MolmoWebはそれと同じ役割をWebエージェント分野で果たそうとしている。

アクセシビリティツリーを使った合成データ生成という手法も重要だ。スクリーンショットの解釈が不要なため、テキストベースのエージェントでも大量のWebタスクトラジェクトリを生成できる。

（アクセシビリティツリーとは、ブラウザがスクリーンリーダー等の支援技術向けに公開するDOM要素の構造化表現で、各要素のロール・ラベル・状態をテキストで記述する。視覚的なスクリーンショットを解析せずにページ構造を把握できるため、テキストのみのLLMでもWebページの操作手順を生成できる）この手法によって、プロプライエタリモデルへの依存なしに訓練データを自己完結的に用意できる。

モデルの重み・訓練データ・評価ツールはHugging FaceとGitHubで公開済みだ。コードはすでに公開されている。

WebAssembly × AIエージェント — Boxerが埋めようとするサンドボックスの設計上の欠陥

WebAssemblyをAIエージェントのサンドボックスとして使うアプローチが、Wasm I/O（バルセロナ）でのDan Phillips（WebAssembly Chicago創設者）の発表を通じて整理された。

AIエージェントは「考えるだけ」でなく「コードを実行してアーティファクトを生成する」存在になった。LLM出力から生成されたコードが検証なしに実行されるという構造的なセキュリティ問題が、AIエージェント普及に伴って顕在化している。

現状の主流なサンドボックス手法——コンテナ・gVisor・FirecrackerのようなマイクロVM——はいずれも「共有カーネル」に依存している。この構造上、カーネルレベルの脆弱性は分離を突き破るリスクを持つ。

WebAssemblyのアプローチは根本的に異なる。「カーネルやコンテナから始めるのではなく、何もないところから始めて必要なものだけ追加する」という設計思想だ。これにより、構造上そもそも到達不能なエクスプロイトのクラスが存在する。モジュールサイズは桁違いに小さく、起動時間も極めて短い。

採用の障壁として「メンタルモデルのギャップ」が指摘されている。開発者はフルプラットフォームとシステムアクセスを前提に動いており、新技術のために既存コードを書き直したくない。この摩擦を解消するのがオープンソースのBoxerだ。DockerfileをそのままWasmディストリビューションとして変換・配布できる。「Dockerでできることの大半はWasmでもできる」という立場で、コードの書き直しも妥協も不要にすることがプロジェクトの目標だ。

Phillipsはさらに「等方性コンピューティング（isomorphic computing）」という概念も提示した。同一のエージェントコードがブラウザ・スマートフォン・クラウド・ホームサーバーをシームレスに移動できる世界だ。サンドボックスの恩恵がクラウド固有の問題に留まらず、実行環境全体に適用できるという主張でもある。

WebAssembly自体はブラウザ向けの技術として始まったが、WASIの策定によりサーバーサイド・エッジ実行の文脈でも使われるようになった。

（WASIはWebAssembly System Interfaceの略で、ファイルシステム・ネットワーク・クロックといったOS機能へのアクセスをブラウザ外環境で標準化するAPI仕様だ。POSIX的なシステムコールをWasmモジュールから安全に呼び出せるようにする）Bytecode Alliance（Fastly・Intel・Mozillaなどが参加）がランタイムの標準化を進めており、wasmtime・wasmerといった実装が成熟しつつある。Dockerも2023年にWasmサポートを統合しており、エコシステムとしての基盤は整ってきている段階だ。

コンテナセキュリティの限界は以前から議論されていた。特にマルチテナント環境でのカーネル共有リスクはKubernetes普及とともに顕在化し、gVisorやKata Containersが生まれた経緯がある。Wasmはその系譜の延長ではなく、設計思想が異なるアプローチとして位置づけられる。

Copilot SDK — IssueCrushの実装から見えたサーバーサイド統合パターンの必然性

GitHubがCopilot SDKを外部アプリケーションに組み込むためのパターンを具体的に公開した。Copilot Chatを動かすのと同じAIを、開発者が自分のアプリケーションに埋め込める仕組みだ。

記事の著者はIssueCrushというReact Nativeアプリを実際に構築し、SDKの統合パターンを実地で検証した。アプリの機能自体はGitHub issueをカード形式で表示してスワイプでトリアージするというシンプルなものだが、SDKの統合に関して実務的な知見が詰まっている。

最初の壁はReact NativeとSDKの実行環境の不一致だ。Copilot SDKはNode.jsランタイムを必要とし、内部ではローカルのCopilot CLIプロセスをJSON-RPCで制御する。React Nativeアプリから直接呼び出すことはできない。

この制約を解決するために著者が選んだのはサーバーサイド統合パターンだ。SDKはサーバー上で動作させ、モバイルクライアントはそのサーバーのAPIを叩く構成になる。

この構成には副次的なメリットがある。SDKインスタンスを全クライアントで共有できるため、リクエストごとに新しい接続を張らなくて済む。認証トークンはサーバー側にのみ存在し、React Nativeバンドルに含まれてデコンパイルされるリスクがない。プロンプトとレスポンスがすべてサーバーを通過するため、レイテンシ計測や障害検知のインストルメンテーションをモバイル側に追加せずに済む。

SDKはセッションベースのモデルを採用している。start() → createSession() → sendAndWait() → disconnect() → stop() という順序が厳格に決まっており、この順序を崩すとリソースリークが発生する。

（内部的にはSDKがローカルのCopilot CLIプロセスをサブプロセスとして起動し、JSON-RPCで通信する。start()がCLIプロセスを起動し、stop()がそれを終了させる。disconnect()を省略するとCLIプロセスとのセッションが残留し、プロセスが蓄積してメモリを消費し続ける）

const { CopilotClient, approveAll } = await import('@github/copilot-sdk');
let client = null;
let session = null;
try {
  client = new CopilotClient();
  await client.start();
  session = await client.createSession({
    model: 'gpt-4.1',
    onPermissionRequest: approveAll,
  });
  const response = await session.sendAndWait({ prompt });
  if (response?.data?.content) {
    const summary = response.data.content;
  }
} finally {
  if (session) await session.disconnect().catch(() => {});
  if (client) await client.stop().catch(() => {});
}

著者はクリーンアップのdisconnect()を忘れてメモリリークを2時間デバッグした経験を記録している。try/finallyでセッション操作を囲むのは必須だ。クリーンアップ呼び出しに.catch(() => {})をつけるのは、クリーンアップ自体のエラーが元のエラーを隠さないようにするためだ。

AIが利用できない場面でもアプリが機能し続けるよう、フォールバック処理を明示的に設計している。Copilotサービスがダウンしたりタイムアウトしたりした場合、基本的なサマリー生成に切り替わる。AIはトリアージを速くするための手段であり、単一障害点にしてはいけないという判断だ。

GitHubがCopilot SDKを外部公開したのは、Copilotのエコシステムを自社サービスの外に広げる戦略的な動きだ。GitHub Marketplace上のCopilot Extensionsとは異なり、SDKはサードパーティが完全に自分のインフラ上でCopilotの推論能力を使える設計になっている。

Velero → CNCF — BroadcomがKubernetesバックアップツールをサンドボックスに寄贈

BroadcomがVeleroをCNCFサンドボックスプロジェクトに寄贈した。Kubernetesにはクラスターレベルのバックアップ機能がデフォルトで存在しないという根本的な欠陥を、中立的なガバナンスのもとで補完するツールとして位置づける動きだ。

VeleroはもともとHeptioが開発したKubernetesネイティブのバックアップ・リストア・マイグレーションツールだ。

（HeptioはKubernetes共同創設者のJoe BedaとCraig McLuckieが設立した会社で、VMwareが5年以上前に買収した。Veleroの設計思想はAPIセントリックで、クラスターリソースと永続データの両方を保護できる）

BroadcomがVeleroをCNCFに移管する理由は複数ある。第一に、VMware買収後のBroadcomに対するコミュニティの不信感を払拭するための「オープンソースへの誠意」を示すことだ。第二に、ガバナンスをBroadcomから切り離すことで、企業ユーザーがVeleroを長期的に採用しやすくなる。Broadcom自身はVeleroの開発から手を引くのではなく、CNCFの傘下でコントリビューターとして関与を続ける立場を取る。

技術的な意義は大きい。Kubernetesはステートレスなワークロードを前提に設計されており、クラスターレベルのバックアップは標準機能として存在しない。PVCのスナップショットはCSIドライバー依存で環境ごとにバラバラだ。Veleroはこのギャップを埋めるツールとして実績があり、CNCF傘下に入ることで企業の本番環境への採用障壁が下がる。アナリストのTorsten Volkが指摘するように、クラウドネイティブの新世界とエンタープライズITの旧世界を接続する際、バックアップとDRの欠如は致命的な障害になる。

同時にBroadcomは、2026年3月に廃止予定のingress-nginxの後継としてAvi Load Balancerを位置づけ、F5・Kong・Tireraとのパートナーシップも発表している。Velero寄贈はこれらの動きと合わせて、BroadcomがKubernetesエコシステム全体でのフルスタックプロバイダーとしての地位を固める戦略の一環だ。

BroadcomによるVMware買収（2023年完了）は、VMwareのOSSコミュニティとの関係を大きく揺るがした。ライセンス変更やサポート体制の不透明さから、多くの企業ユーザーがVMware製品への依存を見直す動きが起きた。Veleroの寄贈はこの文脈で読む必要がある。「オープンソースへの回帰」というメッセージをKubeCon + CloudNativeCon Europeという最大の舞台で発信することで、離反しかけているコミュニティへの関係修復を図っている。

CNCFサンドボックスは成熟度が低い段階のプロジェクトを受け入れる入口だが、Veleroは実際にはすでに多くの本番環境で使われている実績あるツールだ。サンドボックスからインキュベーション・卒業プロジェクトへの昇格は、コミュニティの貢献量とガバナンスの整備次第で比較的早期に進む可能性がある。

（CNCFの成熟度レベルはサンドボックス→インキュベーション→卒業（Graduated）の3段階。卒業プロジェクトの例としてKubernetes・Prometheus・Envoyがある。Veleroのような実績あるプロジェクトがサンドボックスから始めるのは、ガバナンス文書やコントリビューター多様性などCNCFの審査基準を段階的に整備するためで、技術的成熟度とは別の評価軸が存在する）

ingress-nginxの廃止とAvi Load Balancerへの移行という動きも重要な背景だ。Kubernetesの入口となるIngress層を自社製品で押さえながら、バックアップ・DR層をCNCFに開放するという組み合わせは、Broadcomのエコシステム戦略の二面性を示している。

今日の傾向

BroadcomがVeleroをCNCFサンドボックスに寄贈し、ingress-nginxの廃止とAvi Load Balancerへの移行を同時に発表した。Ingress層を自社製品で押さえながらバックアップ・DR層を中立化するという二面的な動きは、KubeCon + CloudNativeCon Europeという舞台でVMware買収後のコミュニティ離反に対処しようとする意図が透けて見える。

Ai2がMolmoWeb（4B・8B）をリリースし、30,000件の人間タスクトラジェクトリと220万件以上のQ&Aペアを含む訓練データをHugging FaceとGitHubで全公開した。Olmoがテキスト生成LLMの研究基盤を開放したのと同じ構造を、Webエージェント分野に持ち込もうとしている。BrowserUseやOperatorといった商用エージェントが牽引してきた分野に、再現可能な研究基盤が初めて整いつつある。

Dan PhillipsがWasm I/OでオープンソースのBoxerを提示し、DockerfileをそのままWasmディストリビューションに変換できるアプローチでAIエージェントのサンドボックス問題に切り込んだ。gVisorやFirecrackerが「共有カーネルの上で分離を強化する」方向に進んできたのに対し、WasmとBoxerは「何もないところから必要なものだけ追加する」という設計思想の違いを前面に出している。

GitHubのCopilot SDKがIssueCrushの実装記録を通じて、Node.js依存とJSON-RPCによるCLI制御という内部構造を明らかにした。React Nativeから直接呼び出せないという制約が、サーバーサイド統合パターンを必然にしており、gpt-4.1モデルを使ったセッションライフサイクルの厳格な順序管理が実装上の核心になっている。

Warren ToomeyのacwjがPart 64でQBEバックエンドと6809 CPU向けバックエンドを追加してセルフコンパイルを達成し、作者はその知見を新言語「alic」の実装に転用している。LLVMの複雑さを避けてQBEを選ぶという判断は、小規模言語実装のバックエンド選択の現実的な解として定着しつつある。

参照記事

記録日: 2026-03-25