LLMのために設計された静的型付け言語「Mog」登場！仕様はわずか3200トークン、AIが自らコードを書き、即実行する世界へ

Mogの作者、Tedです。Mogについて紹介させてください。

• Mogは静的型付けのコンパイル型組み込み言語です（イメージとしては「型付きのLua」）。最大の特徴は、LLM（大規模言語モデル）に書かせることを前提に設計されている点で、仕様のすべてがわずか3,200トークンに収まります。
• AIエージェントがMogプログラムを書き、コンパイルし、プラグインやスクリプト、フックとして動的にロードして実行します。
• ホスト側は、Mogプログラムが呼び出せる関数を厳密に制御（ケイパビリティベースのパーミッション）できるため、エージェントの権限をそのまま実行コードに継承させることができます。
• ネイティブコードにコンパイルされるため低レイテンシ。インタープリタのオーバーヘッドやJIT、プロセスの起動コストもありません。
• コンパイラは安全なRustで記述されており、ツールチェーン全体のセキュリティ監査が可能です。すでに、エージェントが自身のコードで機能を拡張する用途で活躍しています。
• MITライセンスで公開しており、コントリビューションも歓迎します。

Mogを開発した動機は以下の3点です。

1. AIだけが愛せる構文

MogはAIが書くために作られた言語です。仕様が約3200トークンと非常にコンパクトなため、LLMのコンテキストに余裕で収まります。また、生成時の「自爆（バグ）」を減らすため、あえて不自由な設計にしています。例えば、演算子の優先順位がありません。(a + b) * c のように括弧が必須です。また、長年のバグの温床である暗黙の型変換も廃止しました。ジェネリクスは最小限で、メタプログラミングやマクロ、構文抽象化は一切ありません。
人間には窮屈ですが、LLMは気にしません。むしろ、AIに渡す表現力は制限されているほど安全なのです。

2. ケイパビリティベースの権限管理

AIエージェントのセキュリティにはパラドックスがあります。全アクセスを許可すればハックされるリスクがあり、サンドボックス化しすぎると何もできません。Mogは、マシンコードにコンパイルしつつも、syscallやlibc、メモリへの直接アクセスを遮断することでこれを解決します。
Mogプログラム単体では何もできません。ホストから与えられたアリーナ内でのメモリ割り当てと、ホストが提供した関数の呼び出ししか許可されません。これにより、エージェントが動的に生成したプラグインであっても、ホスト側で実行を完全に監視・制限できるのです。
（PL/プログラミング言語オタク向けのネタ：コンパイラが「協調的割り込みポーリング」のチェックを挿入することで、ホスト側から実行時間を制限できます。タイトなループで約10%のパフォーマンス低下がありますが、最適化の余地はあります）

3. 再起動なしの自己修正

例えばOpenClaw（AIエージェント）の設定を変える際、通常は再起動が必要ですが、Mogならセッションを中断せずに新しいプラグインをコンパイルして実行できます。ユーザーのフィードバックを受けて、その場で「ファイルを消す前に必ず確認する」コードを生成・ロードして即座に適応する、といった動的なレスポンスが可能です。
言語レベルでAsync（非同期）をサポートしており、LLVMのコルーチン処理を応用してQBEコンパイラ（Rustポート版）に組み込んでいます。Bunなどのイベントループともシームレスに連携できます。

今後の展望として、Pythonのような「標準ライブラリ（JSON, CSV, SQLite, HTTPなど）」を充実させる必要があります。また、エージェントを介してトークン消費量を管理しながらLLMを呼び出すllmライブラリの実装も計画中です。
AIエージェントが自律的に機能を拡張していくための、強力な基盤になることを目指しています。

これ、見た目やコンセプトは好きなんだけど、Deno経由のTypeScriptは実績のある言語だし、セキュリティモデルもしっかりしてて、型システムも良い。それに、かなり堅牢なランタイムでサンドボックス化もされてる。LLMの学習データもめちゃくちゃ豊富だしね。エージェントっていう文脈で、Mogがこれより明確に優れてる点って何なんだろう？\n\nDenoだとサブプロセスが必要でオーバーヘッドがあるのはわかるけど、エージェントのラウンドトリップや推論時間に比べたら、サブプロセスが原因の非効率なんて微々たるもんだと思うんだよね（まぁ、ローカルならラウンドトリップは無視できるかもだけど、推論は依然として遅いし）。\n\n正直、文法はこっちの方が好みだけど、理想論より実利的な観点から聞いてる。俺がDenoを使ってるのは、理想的だからっていうより、便利で実用的で効率が良いからなんだよね。

「低レイテンシなプラグイン実行のためにネイティブコードにコンパイルするから、インタプリタのオーバーヘッドもJITも、プロセスの起動コストもない」ってあるけど、コンパイル済みコードをプロセス内で実行するなら、それって実質JITじゃないの？ それに、インタプリタよりレイテンシが高くなったりしない？ V8みたいなTiered-JITはまさにその問題を解決してるわけだし。\n\n追記：サンプルプログラムを見ると伝統的なAOT（事前コンパイル）と実行の手順を踏んでるみたいだけど、だとしたら「プロセスの起動コストなし」っていうのは嘘になっちゃわない？

「人間にコードを書かせるときは制約が重荷になるかもしれないけど、LLMは気にしないし、信頼できる表現力が低いほど良い」って言ってるけど、LLMはめちゃくちゃ気にするよ。演算子の優先順位が非標準だったり存在しなかったりする言語だと、LLMのコード作成能力が目に見えて落ちるっていう結果が出てる。LLMがどうやってプログラミングを学習してるかを考えれば、当然の話だよね。

「Mogコード生成時のエラー率を下げるために、うっかりミス（foot-guns）を最小限にするよう設計されている。だからMogには演算子の優先順位がなく、結合法則が成り立たない計算には括弧が必須（例：(a + b) * c）」とのこと。\n\nでも、LLMが学習に使ったコードのほとんどは演算子の優先順位があるものばかりだから、優先順位がないこと自体が逆に大きなミスに繋がりそうだけどな。

理由その1（AIだけが好む構文）はちょっと怪しいな。90%くらい優先順位に自信があっても、念のためいつも括弧をつけるっていう心配性なのは俺だけじゃないはず。Lisp系言語なら曖昧さなんて最初から発生しないし、俺はたくさん括弧を使うのが好きだ。コードの構造編集がやりやすくなるからね。暗黙の型変換がないのも、人間用の普通のプログラミング言語（例えばSML/NJとか）では当たり前のことだし。\n\n> Mogはジェネリクスのサポートも少なめで、メタプログラミングやマクロ、構文抽象化は一切サポートしていない。\n\nあー、それは一気につまらなくなるね。そこは認めざるを得ない。

俺にとってのそれはGleamだな。かなり小さめの言語で、型安全、コンパイル型、NULLなし（これ超重要）、FFIも優秀、コードも読みやすい。それに、BEAM（Erlang仮想マシン）が使える！\n\nエージェントもほぼ自律的に改善を回せるしね。\n\n少なくとも今のところ（そして当面の間）俺にとって一番大事なのは、出力されたコードをはっきりレビュー・読解できることだ。エージェントから人間へのループにおいて、ボトルネックになるのは俺自身。だから、明確で読みやすいコードを生成してそこを最適化するのが最優先事項なんだ。Gleamは大量のエラーを自動的に排除してくれるから、レビューでは主にビジネスロジックに集中できる（冗長なコードを指摘しなきゃいけないことも多いけど）。\n\nフルでErlangを使うっていう案もわかるけど、俺は静的型付けの方が好きだな。

誰かがまともなLisp用ハーネスを作ってくれるのをまだ待ってる。LispのREPLにエージェントを放り込めば、文字通り何でも自由自在に、しかも簡単に変更できるようになるはずなのに。

ざっと見た感じ、足りないのは「データの汚染追跡（data tainting）」かな。昔からある技術だけど、プロンプトインジェクションが問題になる今の時代には完璧にマッチしてると思う。

1つ気になった細かい点。\n\n> 文字列のスライス\n> ブラケット構文と範囲指定 s[start:end] で部分文字列を取り出せる。startとendは両方ともバイトオフセット。startを含みendは含まない。\n\n文字列が全部UTF-8であることを考えると、コードポイント単位で反復処理する良い方法がないのが気になるな。バイトオフセットを使う方がパフォーマンスは断然いいんだろうけど、こういうプログラムで文字列操作を大量にやるなら、よくある要望になりそう。\n\nそれ以外は結構クールだと思う。他の人と違って、俺は演算子の優先順位がないのは嫌いじゃない。LLMがこの言語でコードを生成するときは既存のコードをパターンマッチングするだろうし、そこには常に明示的な括弧があるはずだから、案外大きな問題にはならないんじゃないかな。

うわ、大量の.mdファイルとかをCodexへの指示に使って、自分は最先端（bleeding edge）を行ってるつもりだったよ。まだまだ学ぶことがたくさんあるな！