ハクソク

世界を動かす技術を、日本語で。

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

2025年6月5日原文(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やハードウェアドライバーのようなシステムレベルのプログラミング？それとも、他に思いつかない千の方向のうちの一つ？

└

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

Hacker Newsで議論の続きを見る