DanLevy.net

llm://接続文字列の出番です

llm:// URLでモデルとプロバイダーの設定を簡素化する

更新: この記事をきっかけに、llm:// URIスキームのInternet-Draftと、それを支えるllm-strings npmパッケージが生まれました。実装はGitHubにもあります。

データベースに接続するだけなのに、雑多な環境変数の寄せ集めをやりくりしていた、あの嫌な時代を覚えていますか？

繊細な設定の塔でした。DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、DB_NAME……いや、DB_USERNAMEだったか？ DB_PASSとDB_PWDのどっちだ？ 今回はPG_*プレフィックスが必要なのか？ そもそもタイムアウト設定はどこに書くんだ？

HOSTを大文字にし忘れただけで本番ビルドを崩壊させる、トランプの家のような脆い仕組みです。

そこへ誰かが、「URLを使えばいいじゃないか¹」という素晴らしいアイデアを思いつきました。

Terminal window
postgres://user:pass@host:5432/dbname

たった1本の文字列。必要なものが全部入っている。どこでも一貫してパースできる。ポータブル。言ってしまえば……美しい？

では、なぜ私たちはLLMを1999年のように扱っているのでしょう？

環境変数の爆発

今の私の.envファイルは、捨てられたAPIキーの墓場です。OPENAI_API_KEY、ANTHROPIC_API_KEY、MISTRAL_API_KEY、GROQ_API_KEY。Azureの話は始めないでください。「こんにちは」と言うだけで、エンドポイント、デプロイ名、APIバージョン、そしてキーが必要です。

見た目が悪いだけではありません。摩擦そのものです。モデルを入れ替えたり、新しいプロバイダーを試したりするたびに、初期化コードを書き換え、プロバイダー固有のパラメータ名をドキュメントで探し、環境設定にさらに3行追加しなければなりません。

だったら、DB URLのアイデアを……盗んで借りてくればいいのでは？

LLM接続文字列の登場

モデルとのインターフェース全体を、たった1行で設定するところを想像してください。

Terminal window
llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

LLM接続文字列の構造

LLM接続文字列の各部分

スキームはllm://です。ホストはプロバイダーのAPIベースURL。パスはモデル名です。そしてクエリパラメータで、通常ならコードを散らかすことになる実行時オプションをすべて扱います。

認証が必要？ それなら追加すればいい。

postgres://と同じように、認証情報をそのまま埋め込めます。

Terminal window
llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

注：認証情報をURLに入れたまま公開ログへ貼り付ければ、セキュリティリスクになる。とはいえ、最近のログサービスはこうしたパターンのマスキングにはかなり強い。それに正直なところ、あなたは.envファイルをそれほど丁寧に扱っているだろうか？ 検証し、サニタイズし、注意して使おう。

レジリエンス？ もちろん入れよう。

多くのデータベースライブラリは、複数のホストを指定してラウンドロビン方式のフェイルオーバーに対応しています。AIエージェントだけが同じ信頼性を持てない理由はありません。

Terminal window
llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

llms://のsはタイプミスではありません。複数形です。primary.gptが応答しなくなれば、クライアントは自動的にbackup.gptへ再試行します。複雑なルーターのロジックは不要です。

認証情報からエンドポイント、ハイパーパラメータまで、すべてが1本の文字列に収まる。

代替フォーマット

私はllm://に固執しているわけではありません。重要なのは個別のスキームではなく、標準そのものです。

標準の構造は保ったまま、簡潔さのためにプロバイダー固有のスキームを使う世界も想像できます。

Terminal window
ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

正確な構文がどうであれ、中心的なメリットは明白です。

  1. ポータビリティ： ローカルスクリプトからクラウドワーカーまで、設定全体をコピー＆ペーストできる。
  2. CLIフレンドリー： スクリプトに引数を1つ渡せばいい。my-agent --model "llm://..."のほうが、my-agent --model gpt-4 --temp 0.7 --key $KEY --host ...よりずっとましです。
  3. 言語非依存： どのプログラミング言語にも堅牢なURLパーサーがあります。検証、パース、サニタイズが最初から手に入る。
データベースの世界がこれに気づくまで、何十年もかかった。
朗報なのは、AIの時間感覚なら、たった半バイブ年ほど前の話だということだ。

結論

新たに複雑な設定標準を作る必要も、YAMLベースのマニフェストファイルを増やす必要もありません。必要なのは、インターネットの他の部分でこの30年間ずっと機能してきた道具を使うことだけです。

車輪の再発明はやめて、LLM接続をデータベース接続と同じように扱い始めましょう。あなたの.envファイルも、あなたの正気も、きっと感謝してくれます。

散らかった環境変数の引き出し

Loading comments...