LLMとElixir：幸運か致命的な一撃か？

355日前原文(zachdaniel.dev)

概要

AIの進化 がソフトウェア開発の現場に大きな影響を与える可能性
LLM（大規模言語モデル） は主流技術に偏る傾向があるが、正しい使い方で力を発揮
Elixir のような非主流技術の未来とAI時代の生き残り戦略
知識の文脈化 とAI活用法の工夫による新しい開発スタイル
コミュニティ主導のAI訓練 と評価データセットの重要性

AI時代における職業の未来とElixirの立ち位置

AIによる職業の自動化 と「ロボットの管理者」への転換という不安
Elixir は最高の汎用言語と自負、知らない人は要注目
LLMの主流技術偏重 ：「AIが言うから」という理由でNodeやNext.jsが選ばれる現状
AIの提案が最適解ではない 場合、経験者が知識で補う必要性
AIの進化が全ての言語を均質化 するか、もしくは本質的な壁でElixirのような技術が再評価されるかの二択
どちらの未来でも 開発者にとって悪い話ではない との見解

LLMの現状と課題

LLMは人気技術に偏る傾向 が強い
Elixirのような技術 に適切な選択肢を提示できるかが重要
AIの回答の質 がツール選定の新たな評価基準に
FOMO（取り残される不安） が技術選定に大きく影響

LLMとの賢い付き合い方

LLMの知識は最新でない ため、情報の文脈化が重要
LLMは要約・変換・整理が得意 で、発明や創造は苦手
正しい使い方 ：自分で必要な情報を文脈として与え、LLMには要約や再構成を任せる
間違った使い方 ：AIの回答を無批判に信じること

実践例と新しい開発パターン

Tidewave のような仕組みで、LLMがアプリケーション本体やドキュメントに直接アクセス可能
- project_eval：アプリ内でコードスニペット実行
- run_sql_query：実際のDBスキーマでクエリ実行
- search_hex_docs：依存パッケージのドキュメント検索
LLMを活用した設計支援 ：既存コードや類似実装を参照させて新機能設計

LLM時代のドキュメント戦略

usage-rules.md の導入：LLMの文脈ウィンドウ向けに特化した簡潔なドキュメント
Ash Framework での実践例：AIがより適切なコードを生成できるように変化
技術コミュニティ全体 でのLLM活用促進のテンプレート

コミュニティによるAI訓練と評価

Elixirコミュニティ が現実的な評価データセットを作成する重要性
- GenServer、OTP、Phoenix LiveView、Ecto、Ashなどの実践課題
- PythonやJavaScript中心の現状を打破する狙い
Elixirの実行環境 を活かした性能ベースの評価
- 並列負荷・障害回復・メモリ管理など現実的な観点での検証

AI時代に技術者が取るべき行動

AIを脅威ではなく成長の道具 として活用する姿勢
自分の技術がAIに無視されないよう工夫 し、情報発信や評価データセット作成に参加
LLMの弱点を補完する使い方 をマスターし、他の開発者との差別化

まとめ AIやLLMの進化は技術者の仕事や技術選定に大きな影響を与えますが、正しい使い方やコミュニティでの工夫次第で脅威を成長のチャンスに変えられます。Elixirのような非主流技術も、AI時代に適応する戦略を持つことで十分に生き残る可能性があります。AIを「知識の自動化装置」としてではなく、「要約・整理・変換の道具」として賢く使いこなすことが、今後の開発者に求められる重要なスキルとなるでしょう。

Hackerたちの意見

風が吹いてるね、欲しい人には。LLMは新しいニッチな言語でプロジェクトを書くのに最高だったよ。足りないライブラリを書くのを手伝ってくれるし、言語の面で詰まったときに繰り返し作業をするのにも役立つ。概念を説明するのも、普通のSOの投稿よりずっと分かりやすいし、存在しない投稿よりも遥かに良いよ。

└

Crystalは最高だね！そのプロジェクトではどのLLMが使われたの？私の短い経験では、LLMは書くコードの中でCrystalとRubyをよく混同してたよ。

これはラッキーだね。PhoenixとFastAPI/Expoで同じプロジェクトを書いた経験から、LLMはPythonやReactを書くのが得意だと思ってた。でも、コードのボイラープレートや有害な副作用が発生する可能性が多いから、すぐに大量のコードを生成してしまって、それを手動で理解し直さないといけなくなるんだ。Elixirだとこのループがずっと小さい。少量のコードを生成して、妥当性をチェックする（関数型言語だと確認がずっと楽）を繰り返す感じ。超人の自律コーディングエージェントが出てくるまでは、生成されたコードを理解する人間がまだ制約になってる。LLMはElixirよりもメインストリームな言語を生成するのが少しだけ得意だけど、生成されたElixirのコードは理解しやすくて修正もしやすいし、ランタイムのおかげでシステムがクラッシュすることはほとんどないよ。

└

ランタイムのおかげで、システムがクラッシュすることはほとんどない。「ほとんどクラッシュしない」というのは、ソフトウェアバグやリソースの枯渇、悪いアーキテクチャを無視してるよ。

└

超人的な自律コーディングエージェントが登場するまで、人間が生成されたコードを理解するのが限界要因だね。彼らは疲れないし、安い報酬で働くし、インターネットやコードベースを検索できるし、ルールに従って、テストケースを繰り返し改善できる。これは私ができることよりも優れてるから、人間の視点から見ると、コーディングエージェントはすでに超人的だね。

└

Elixir、Erlang、BEAMが大好きなんだけど、正直言って、クラッシュしないっていうのは、言語やランタイムに関係なく、ウェブの世界ではかなり解決された問題だよね。リクエスト/レスポンスの性質のおかげで。

└

LLMが退屈で冗長なJavaコードを書くことを強要されて文句を言う日が待ち遠しいよ。そして、より良い解決策として簡潔で堅牢、パフォーマンスの良いElixirコードを書くことを許可してほしいって要求するんだろうね。それから、viを使ってることをEmacs派に批判されるのも想像できる。

└

「少量のコードを生成して、妥当性をチェックする（関数型言語だと確認がずっと楽）、このループを繰り返す。これはLLMが登場する前からも真実だった。小さくてテスト可能な関数を作って、それを組み合わせる。それが基本だ。」

└

まだエリクサーは試してないけど、RustやGoでも同じような現象を感じてる。以前はLLMなしでは文法的に地獄だったのが、今は良いエラーとテストでフィードバックループがしっかりして、ずっとクリーンなコードベースが生まれてる。人間にはちょっと理解しづらい言語の採用がどう変わるのか、興味深いね。でもLLMにはそんなの関係ないみたい。

Elixirをサーバーアプリ以外で数年使ってきたけど、Elixirを汎用プログラミング言語と呼ぶのには反対だな。サーバーを書くのにはすごく良いけど、常に稼働しているネットワークアプリ以外のものには、OTPのやり方が自分が作っているものには合わないと感じた。Elixirはサーバーを作るのがすごく簡単だけど、言語やコミュニティはクライアント/サーバーのユースケースに偏ってる。サーバー以外のことにも使えるけど、QBasicやExcelでウェブアプリを作れるのと同じような感じ。言語の焦点や歴史、Elixirの周りのコミュニティは常にサーバーアプリに向いてるから、それが専門的な言語であることの最大の指標だと思う。

└

クライアントサーバー以外でどんなユースケースを考えてるの？存在しないとは言わないけど、どんな次元に価値を感じるかを知るのは面白いかもね。:) 例えば、ビデオゲーム？デスクトップアプリ？モバイルアプリ？組み込み？OSやハードウェアドライバーのようなシステムレベルのプログラミング？それとも、他に思いつかない千の方向のうちの一つ？

└

強みと弱みがあるからって、一般的な目的の言語じゃないわけじゃないよね。

└

アプリケーションがGenServerを必要としないなら、使うべきじゃないよ。Elixirはゲームを書くための言語じゃないけど、OTPモデルに当てはまらないものを書くのには全然使えるよ。

└

Elixir/Erlang/OTPはサービス構築に特化してるって言っても、全然おかしくないと思う。サーバーというよりサービスって言った方がいいかな。クライアント/サーバーというよりは、長時間動くジョブをこなすことに重点があるから。確かにサーバーになることが多いけど、ボットやワーカー、その他色々なものを作ったことがあって、それは必ずしもサーバーとは思わない。言語とエコシステムはかなり一般的だと思うけど、もっと一般的なエコシステムもたくさんあるよね。ErlangやRailsが達成した大きな成功のいくつか（Elixirがそれを基にしてる）は、「サービス」や「データベース付きのウェブアプリ」に問題を制約することに関してだったと思う。だから、その点はまさにその通りだね。Elixirが意外と良いなと思ったのは、PythonやBashのスクリプトの代わりとして使えるところ。シェルを使うのは時々面倒だけど、Mix.installは素晴らしいし、Task.async_streamは面白いよ。

└

これを言いたくて来た！素晴らしい一般的な目的の言語って、プログラミングだけじゃなくて、移植性にも関係してると思う。ここではGoが一番だね。もしElixirのアプリがバイナリとしてコンパイルできて、似たようなシステムに移植できるなら、素晴らしい一般的な目的の言語になると思う。それまでは、意図された通り、良いクライアント/サーバー言語に過ぎないよ。

└

スクリプトを書くのに好きなんだ。Flowモジュールのおかげで、並行コードがほとんど非並行コードみたいに見えるから。ファイル内で依存関係も引き込めるし。いくつかの言語で小さな実験をしたけど、Elixirはシングルスレッドから並列にするのに必要な変更が一番少なかった。Clojureは全体的に最も行数が少なかったよ。

└

それには反対だな。コンパイラを書くのにも素晴らしいよ。https://github.com/elixir-dbvisor/sql 進んだパターンマッチングがない他の多くの言語よりも優れていると言っても過言じゃない。

先週末、好奇心からCursorでPhoenixフレームワーク/Elixirを試してみたけど、エージェントコーディングで今までで一番良い体験だった。まだどちらも知らないけど、純粋な実験だった。指示書にはTDD、機能リスト、Phoenix/Elixir/Tailwind/Postgresのドキュメントへのリンクがあって、Sonnet 4はPhoenix CLIを上手く活用してくれて、ボイラープレート生成を大幅に減らしてくれた。各イテレーションでテストで変更がうまくいったことを証明したのがポイント。プロジェクトが複雑になるにつれて、方向感覚を失わなかったのが良かった。他のウェブアプリフレームワークだと、npmパッケージを追加するのに迷ったり、設定ファイルをいじったりして、救出が必要な「延長コード」に巻き込まれることが多いから。ノードの世界のバージョン変更やフレームワーク実装のアプローチがトレーニングデータに影響を与えているのかもしれないと思った。Sonnetがプロジェクトを構築するのを見ているのが、新しいフレームワークや言語を学ぶのに本当に魅力的な方法だと気づいた。「なんでこれをやってるの？どうやって動くの？」と聞いてコードを確認できるから、Elixirについてもっと学びたいと思った。

└

Elixir / Phoenix / LiveViewを使い始めてもう1年になるけど、LLMコーディングが流行り始めてからで、すごく変わったよ。普通の「始める時の問題」はほとんどなくなったから、ほとんど何も逃した気がしない。以前は何時間もかかってた「コンパイルできない / 新しい未知の言語でどうするの？」って問題がほぼ消えた。私のLLMペアプログラマーが全部やってくれたからね。Python / Django / Cueから来たけど、すごく新鮮な気持ち。全てのパラダイムがスタックに組み込まれてるから、すごく楽だよ（非同期ワーカーとか）。Elixir / Erlangのライブラリは意外と充実してるし、コード生成に関してもかなりうまくいってるみたい。私にとって一番印象的だったのは、Google Cloudを使ってゼロからPDFのOCRを作ったこと。必要だったのは、自分の認証情報を入力して、コードを接続するだけで、あとはそのまま動いた。魔法みたい。超おすすめ！

厳格な型システムを持つ言語がエージェントコーディングに理想的だとずっと主張してきた。言語が厳しければ厳しいほど、LLMが意味不明なものを生成するのが難しくなるし、少なくともコンパイルエラーやテストを実行できれば、出力が正しいかどうかの検証が楽になる。依存型や線形型を持つ言語が理想だけど、残念ながら… 現在はRustがベストな選択肢だね。かなり人気があって（だからLLMにも知られていて、エコシステムも良好）、問題解決のためのエラーメッセージも優れてるし、型システムも厳格で、ほとんどの他の半人気言語よりもコンパイル時の保証が多い。Rustを書くのは簡単ではないけど、人間にもLLMにも、出力がかなり悪かった時期もあった。でも、cargo checkを実行してテストを実行できるおかげで、現在のエージェントの初期バージョンでも、動作する結果が得られるまで繰り返し作業ができるようになったよ。

└

型だけじゃ限界があるよ。関数の動作の意味は、その名前やドキュメント、テストにほとんど含まれてると思う。そろそろ、型、テスト、評価を統一するフレームワークを考えるべきだと思うな。https://nilesh.trivedi.link/thoughts/we-need-a-formal-theory...

この記事の核心的な洞察は、これまで考えたことがなかった視点で、成功するプログラミング言語はLLMやLLM開発者に「自分を売り込む」必要があるってことだと思う。決定者にマーケティングされた「第一波」の言語（Java）、開発者にマーケティングされた「第二波」（Ruby on Rails、Rust）があったけど、今は「第三波」が来ると思う。そこでは、言語が最初からLLMフレンドリーに設計されるんじゃないかな。

└

もし本気でやりたいなら、もっと効率的にトークンを使えるように、密度の高い言語がいいよね。LLMに使われてるから、人間が読みやすいかどうかは二の次でもいいし。まあ、答えは明らかにPerlだね。でも真面目な話、高レベルの言語でLLM向けに設計されたものがあったら面白そう。開発者に優しい何かに翻訳するレイヤーがあればなお良し。

└

LLMを意識して書かれたプログラミング言語を探してて、ChatGPTにいくつかヒントをもらってリサーチを始めたんだ。https://chatgpt.com/share/6841d3b7-13a8-800f-9bcc-0f7859114c... 自分は新しいプログラミング言語を設計したことがない非学術的な人間だけど、強い型付け、簡潔さ、オプションの構文がない（いろんなやり方ができる）っていうのはLLMにとってすごくクールだと思う。LLMやAIエージェントと一緒に使うためのプログラミング言語を設計しようとしている言語や人たちをいくつか見つけたけど、最も期待できるのはhttps://www.moonbitlang.com/blog/moonbit-ai だと思う。これはLLMと一緒に作業するというアイデアを別のレベルに引き上げて、エージェントと一緒に使うために設計された実際の機能があるんだ（構文だけじゃなくて）。

自分の経験は限られてるけど、LLMはElmやRustみたいな言語と相性が良いって感じてる。強力な静的解析と素晴らしいコンパイラのUXがあるからね。

実は、エリクサーについて全然知らないんだけど、雰囲気でアプリを作ってるんだ。どの言語やフレームワークを使うかは聞かなかったし、「ブログでエリクサーのことを聞いたり、ハッカーニュースのトップにある記事を見たりした」だけなんだ。フェニックス以外に何を考慮すべきかをLLMに聞いてみたけど、結局はそのまま進めることにした。ジェミニは時々つまずくけど、ChatGPTに助けを求めて乗り越えてる。コードを書いてた時にエラーが見えなかったことを思い出すな。別の目があると本当に助かるよね。コードを書いてない別のLLMも、かなり役立つと思う。

ここ数日、エリクサーをジェミニと一緒に使ってるけど、LLMの成功率は他の言語に比べて低い気がする。時々つまずくこともあって、例えばJWTのエンコーディング/デコーディングライブラリの使い方が分からなかったから、介入する必要があった。GoやRuby、特にJS/TSの異常なパフォーマンスに甘やかされちゃったのかな？

マニュアルを読まないために人々がどれだけのことをするか。

ハクソク