Transcript
00:00:00VercelがXeroという新しいプログラミング言語をリリースしました。これの
00:00:03何が違うかというと、人間とAIエージェントが協力して
00:00:07小さなネイティブプログラムを開発できるように、ゼロから構築された点です。でも、それって皆すでにやっていることでは？
00:00:12では、何がそんなに優れているのか、本当に良いアイデアなのか、それとも数ヶ月後には
00:00:16誰も話題にしないような、ただのサイドプロジェクトに過ぎないのか？確かめてみましょう。
00:00:25XeroはRustやZigのようなシステム言語なので、いつかBunがこれで書き直されるかもしれません。
00:00:30私が知る限り、その核心にある考え方は「既存の言語は人間のために作られた」ということです。
00:00:34人間はエラーメッセージや警告、トレースを読みますが、AIは構造化されたデータがある方が
00:00:38そのため Xeroは ツールチェーン全体が それを念頭に置いて構築されており
00:00:43コンパイラが出力するものはすべてJSONとして出力できます。
00:00:46ただ、これらの点と、このウェブサイトにある明らかにAIが書いたような文章を見る限り、
00:00:51これがなぜ存在するのか、どれほど機能するのかについては、まだかなり懐疑的です。
00:00:56意見は最後に取っておくとして、まずは言語そのものを探ってみましょう。
00:00:59非常に興味深いものですからね。定番の「新しい言語の学習」プロジェクト、
00:01:03シンプルな文字列の出力から始めます。この大部分はとても理解しやすいです。
00:01:08プログラムのエントリポイントとして、パブリックなmain関数があります。この関数は
00:01:12voidを返し、内部で文字列を出力しています。しかし、その文字列の出力方法に
00:01:16最初の特徴的な機能が現れています。ここでは「world」ケーパビリティを使用しています。
00:01:21ファイル操作、出力、ネットワーク呼び出しなど、何らかのI/O操作を行う場合に、このケーパビリティが必要になります。
00:01:26あらゆるI/Oのサイドエフェクトが対象であり、これがこの言語の「明示性の原則」の一部となっています。
00:01:31関数にこのworldケーパビリティがあれば、それがI/O操作を行うという即座のサインになり、
00:01:37なければ、I/Oのサイドエフェクトがないことを意味します。
00:01:40また、worldケーパビリティによって、コンパイラはターゲットに基づいて、実行時ではなく
00:01:45コンパイル時に利用不可能なケーパビリティを拒否できます。そのため、この関数内でファイルシステムへのアクセスを試み、
00:01:50さらにWebAssemblyビルドをターゲットにしようとすると、コンパイラが最初にエラーを出します。
00:01:54したがって、後になって実行時エラーに驚かされることはありません。
00:01:57worldケーパビリティのほかに、このプログラムにはいくつかのキーワードもあります。
00:02:00ここにある「check」は、エラーを処理するためのものです。関数が失敗する可能性がある場合は
00:02:05「raises」をマークし、この「check」を使ってエラーを伝播させます。これはRustの
00:02:09クエスチョンマーク演算子に似ていますが、キーワードとして存在しています。これがXeroでの
00:02:13最初のプログラムに必要な知識のすべてです。「xero run hello.xero」で実行できます。
00:02:19なお、これがXero言語の拡張子です。ここでエンターキーを押すと、
00:02:23「hello, subscribe to Betastack」と表示されます。ぜひチャンネル登録してくださいね。
00:02:26helloプログラムはこれくらいにして、私たちは皆もうXeroのエキスパートですから、
00:02:30この言語が持つ、基本的なアプリケーションをカバーする他のプリミティブを見ていきましょう。
00:02:34ここに新しいものを用意しました。入力がテキストか、数値か、混在しているかを分類する簡単なアプリです。
00:02:39これを見ると、標準ライブラリなどの機能が使われているのが分かります。
00:02:43enum（列挙型）や、struct（構造体）によく似たshapeがあります。それから、
00:02:47if文のような期待通りの通常の言語機能があり、下にはwhile文があります。また、
00:02:52forループも使えますし、ここにあるmatchはswitch文のようなものです。
00:02:56特に予想外なものや新しいものはありません。メモリのような、より高度な概念に関しても、Xeroでは
00:03:00すべてが明示的であるべきです。書き込み可能なビューにはmutable spanがあり、読み取り可能なビューには
00:03:05通常のspanがあります。そして下の方にはowned型があります。これは本質的に、この値は
00:03:10ここで所有され、スコープ外に出たときにdrop関数を実行することを示します。drop関数は
00:03:14このshape上で自分たちで定義するため、ここにクリーンアップのロジックを記述します。別の方法として、
00:03:18「defer」キーワードを使って、その後に関数を置くこともできます。要するに、
00:03:22この関数が終了してスコープ外に出たときに、その後でこの関数を実行するという意味です。つまり、
00:03:26現在の非常に基本的なアプリケーションに必要なものは、基本的にすべて揃っています。他にもいくつかの機能は
00:03:31ありますが、プログラミングのチュートリアルにしたいわけではないので、履歴書に「Xeroの経験
00:03:353分」と遠慮なく書いてください。それでは、これらを脇に置いて、
00:03:39Xeroの本当の売り文句であると思われる部分、つまりそのツールチェーンと、AIエージェント向けに作られたという事実に焦点を当てましょう。
00:03:44AIエージェントがXeroのコードを書いて、いくつかバグを埋め込んでしまったと想像してください。彼らの主張によると、
00:03:49ほとんどの言語では、大量のテキストが返ってくるだけであり、それらのエラーメッセージは人間が読むように設計されています。
00:03:54Xeroでは、人間が読める形式も取得でき、それはこのような見た目になりますが、
00:03:58ご覧の通り、これは構造化された出力ではありません。そこで彼らは、ツールチェーンの
00:04:02あらゆる部分にJSONオプションが確実に備わっているようにしました。そのため、同じ関数をもう一度、
00:04:07今度はJSONオプションを使い、見栄えを良くするためにjqにパイプで渡して実行すると、
00:04:12綺麗に構造化された出力のエラーメッセージが返ってくるのが分かります。重要度（severity）、コード、
00:04:16メッセージなどの診断情報（diagnostics）があります。エラーが発生している場所、期待される値、
00:04:21そして実際の値があります。さらに、LLM自体に対するヘルプや、修正の安全性（fixed safety）フィールドもあり、
00:04:26これには「人間の確認が必要」といったことや、どのように修復できるかについての情報が書かれています。つまり、
00:04:31LLMが自分で修正できるように十分なコンテキストを与えようとしているのです。それをうまく示している
00:04:35もう一つのコマンドが「xero fix」です。これはplanモードとJSONを併用し、
00:04:40ターミナルで見やすくなるようにjqにパイプで渡しています。これでエンターキーを押すと、
00:04:44提供した壊れたファイルの診断を基本的に行い、このファイルを実際に修正するために
00:04:49何をする必要があるかを提示してくれます。安全レベル、モード、適用（applies）、編集（edit）など、
00:04:53ほぼLLMだけが知る必要のあるフィールドを持つ、構造化された出力が返されるのが分かります。下の方には
00:04:58セルフホストの修復ポリシー（self-host repair policy）といったものもあります。それから診断セクションがあり、これは
00:05:03先ほどの「xero check」コマンドで見たものとほぼ同じです。そして下には、そのエラーコード自体の
00:05:07修正方法も含まれています。では、これは通常どのように修正されるのでしょうか？本質的に、アイデアの一部は
00:05:12「言語が必要なときに独自のドキュメントを提供したらどうか」ということのようです。そのため、この新しい言語にLLMを向ければ、
00:05:17ドキュメントを調べたり、既存のスキルを使ったりする必要はなく、実際に必要なときに
00:05:21ツールチェーンから十分な情報を取得できることになります。そこで、それをテストするために、
00:05:25Xero言語に関する情報が一切ない、完全に新しいディレクトリにその壊れたファイルを置きました。そして今、
00:05:30Claudeにその壊れたファイルを修正するよう依頼し、それらの診断に必要なコマンドも与えます。
00:05:34ツールチェーンの実際の使用方法に関する情報がいくらか必要だからです。これで、
00:05:38Claudeが実際にこのファイルを修正できるかどうか見てみましょう。ご覧の通り、31秒後には
00:05:43ファイル内のすべてのエラーを修正することに成功しました。実は私が3つのエラーを混入させていたのですが、
00:05:47その3つすべてを見つけて修正しました。上にスクロールして、どのように行ったかを確認できます。
00:05:51私が教えたあの「xero fix」コマンドを実行しているだけです。今回は「ok: true」が返ってきたので、これで
00:05:56エラーが残っていないことが分かります。さらに上にスクロールすると、コードが変更されているのが確認できます。なぜなら
00:06:00前のステップで「xero fix」を実行し、その問題を正確に修正する方法についての情報を取得したからです。
00:06:05そして、私たちが抱えていた3つの問題すべてに対してそれを行いました。つまり、これには
00:06:10Xero言語が何であるかという事前の情報はなく、ドキュメントを取得するためにウェブ検索なども一切行わず、
00:06:14ツールチェーンが構造化出力として提供した情報だけを使用したのです。これには正直、
00:06:18少し感心しました。言語がどのように構築されているかのおかげで、LLMがデバッグできる
00:06:22全く新しい言語なのです。ただ、一つ疑問が残ります。これは本当に新しいことなのでしょうか？
00:06:28ツールチェーン内のエラーやあらゆるものが構造化出力を
00:06:31持つというセールスポイントは分かりますが、それは決して新しい概念ではなく、私たちは何十年も構造化エラーメッセージを使ってきました。
00:06:37これを見てください。Rustで構築された、ほぼ同じ分類プログラムがあり、同様のエラーが含まれていますが、
00:06:41出力をJSONにするよう要求するだけで済みます。このアイデアを中心に言語全体を構築する必要があったのかは
00:06:46あまり定かではありませんし、情報にギャップがあると考えたのなら、既存の言語を改善すればよかったのかもしれません。
00:06:51また、その壊れたRustのコードを持って行ってClaudeに修正を依頼すれば、
00:06:55簡単に修正できるはずです。たとえ構造化出力を使用していなかったとしてもです。
00:07:00LLMは通常のメッセージでも完全に問題なく処理できると感じています。あるいは、私がまだその問題に直面していないだけかもしれません。
00:07:05それに加えて、LLMはRustのような既存の膨大なコーディング言語で訓練されているという事実があるため、
00:07:10デバッグが非常に得意であり、訓練データに多くの例があります。しかし、Xeroに関しては
00:07:14全くありません。だからといって、新しい言語を追加しようとすべきではないという意味ではありません。ただ、
00:07:19複雑なアプリを構築する場合、Xeroを選ぶことはないだろうということです。ですが実を言うと、彼らも
00:07:24そのようなものとしてはマーケティングしていません。全体として、
00:07:28これは巧妙な実験であり、どちらかと言えば、その言語で訓練されていなくても、新しい言語を構築して
00:07:32LLMに必要なコンテキストを提供できることを示しています。ただ、これが本当に必要だったのかは
00:07:37あまり分かりません。だからといって、言語自体がクールではないと言っているわけではありません。先ほど言ったように、
00:07:42実際に使うのはそれほど悪くありませんし、素晴らしいサイズにコンパイルされます。ただ、私がこれを
00:07:47Rust、Zig、Goのような確立された言語よりも好んで使うことはないだろうと思います。これについては
00:07:51多くの意見があると思いますので、下のコメント欄でどう思うか教えてください。またはチャンネル登録を
00:07:55お願いします。それでは、いつものように次の動画でお会いしましょう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video