Claude Code も Codex も Gemini もつなぐ、LLM API 変換プロキシ「llmglot」を開発した

2026年6月28日

AI 開発の現場では、モデルそのものよりも API 仕様の違いに悩まされることが増えている。

Claude Code は Anthropic Messages API を利用する。OpenAI 系ツールは Chat Completions API や Responses API を利用する。Gemini は独自 API を持ち、ローカル LLM 環境では Ollama や LM Studio がOpenAI 互換 API を提供する。

利用したいモデルは存在するにもかかわらず、API 仕様が違うために接続できない。SDK を書き換え、変換レイヤーを実装し、環境ごとに設定を分ける必要がある。

こうした問題を解決するのが llmglot である。

GitHub: https://github.com/Himeyama/llmglot

llmglot とは

llmglot は、複数の LLM API を相互変換するプロキシサーバーである。

Anthropic Messages API、OpenAI Responses API、OpenAI Chat Completions API、Gemini API などを受け取り、上流の API へ適切に変換して転送する。

つまり、クライアントが要求するAPI仕様と、実際に利用したいモデルのAPI仕様が一致していなくても利用できる。

対応範囲

クライアント側としては、

Claude Code
Anthropic SDK
OpenAI SDK
Responses API クライアント
Gemini SDK

などに対応している。

接続先としては、

Ollama
LM Studio
OpenAI
Gemini
OpenRouter
Azure OpenAI
vLLM

などが利用できる。

例えば、

Claude Code → Ollama
OpenAI SDK → Gemini
Responses API → Chat Completions API

といった接続が可能になる。

Claude Code とローカル LLM を接続する

llmglot の用途の一つが、Claude Code とローカル LLM の接続である。

例えば Ollama を利用している場合、

CHAT_BASE_URL=http://localhost:11434/v1 llmglot

として起動する。

その後、Claude Code の接続先を llmglot へ変更するだけで、Claude Code からローカル LLM を利用できる。

高価なAPIを利用せずにコードエージェントを試せる点は非常に魅力的である。

(補足: Ollama は Messages API に対応しているので実はプロキシは不要である)

Responses API にも対応

近年は Responses API を利用するツールが増えている。

llmglot は /v1/responses エンドポイントを実装しており、HTTP だけでなく WebSocket にも対応している。

そのため、Codex CLI のような Responses API ベースのクライアントとも接続しやすい。

ログ機能が便利

llmglot にはログ表示機能が搭載されている。

確認できる情報は、

モデル名
プロバイダー
入力トークン数
出力トークン数
キャッシュ利用量
推定コスト
生成速度

などである。

複数の LLM を利用する環境では、利用状況を一元管理できるメリットは大きい。

LiteLLM との違い

ここで気になるのが LiteLLM との違いである。

どちらも LLM の間に入るソフトウェアだが、目指している方向は大きく異なる。

LiteLLMの考え方

LiteLLM は多数の LLM プロバイダーを OpenAI 形式に統一する。

つまり、

アプリ
    ↓
LiteLLM
    ↓
各LLMプロバイダー

という構成である。

アプリケーション開発者が統一 API を利用するための仕組みと言える。

llmglot の考え方

一方 llmglot は、

Claude Code
Codex CLI
Gemini SDK
       ↓
     llmglot
       ↓
各 LLM プロバイダー

という構成になる。

クライアント側の API 仕様を変換することが目的である。

Claude Code で比較する

Claude Code は Anthropic Messages API を利用する。

LiteLLM は基本的に OpenAI 互換 API を中心としているため、そのままClaude Code を接続することは難しい。

一方 llmglot は Anthropic Messages API を直接受け付ける。

そのため、

Claude Code
    ↓
llmglot
    ↓
Ollama

という構成が実現できる。

これは llmglot の非常に大きな特徴である。

どちらを選ぶべきか

LiteLLM が向いているのは、

AI アプリケーションを開発する人
OpenAI SDK を統一インターフェースとして利用したい人
負荷分散やフォールバックを行いたい人

である。

一方、llmglot が向いているのは、

Claude Code を別のモデルで動かしたい人
ローカル LLM を既存クライアントから利用したい人
Responses API を別の API へ変換したい人
SDK を書き換えたくない人

である。

まとめ

LLM の世界ではモデルそのものよりも API の違いが問題になる場面が増えている。

Claude Code を使いたいが Ollama を利用したい。OpenAI SDK を使いたいが Gemini を利用したい。こうした要求は今後さらに増えていくだろう。

llmglot は、その間に立って API 仕様の違いを吸収する。

Claude Code → Ollama
OpenAI SDK → Gemini
Responses API → Chat Completions API
Gemini API → OpenAI互換API

LiteLLM が「開発者向けの統一 API」であるのに対し、llmglot は「クライアント互換プロキシ」と言える。

Coreutils for Windows のまとめ

2026年6月3日

ひかり

WinGetでインストールできるMicrosoft公式Linuxコマンド群の最新動向（2026年6月更新）

2026年6月、Microsoftは Coreutils for Windows を正式に公開した。

winget install Microsoft.Coreutils

このコマンドでインストールできる Microsoft.Coreutils は、LinuxやmacOSで日常的に利用される ls、cp、rm、cat などのUNIX系コマンドを、Windows上でネイティブ実行できるようにするMicrosoft公式プロジェクトである。

本記事では、プロジェクトの概要、対応コマンド、制限事項、WSLやPowerShell との違いを整理する。

概要

Microsoft.Coreutilsは、MicrosoftがメンテナンスするWindows向けのコマンドラインツール群である。

内部的には、

uutils/coreutils
findutils
grep

をベースに構築されており、Rust で実装されている。

Microsoft はこのプロジェクトの目的を、

Linux、macOS、WSL、コンテナ、Windowsを行き来する開発者の摩擦を減らすこと

と説明。

インストール方法

WinGet から簡単に導入可能である。

winget install Microsoft.Coreutils

WinGetはWindows標準のパッケージマネージャーであり、指定したパッケージを自動的にダウンロード・インストール可能。

インストール後は通常のコマンドとして利用可能。

ls
cat file.txt
grep keyword log.txt
cp source.txt backup.txt

利用できる主なコマンド

代表的なコマンドは以下の通り。

分類	コマンド例
ファイル一覧	ls
ファイルコピー	cp
ファイル移動	mv
ファイル削除	rm
内容表示	cat
作業ディレクトリ	pwd
ディレクトリ作成	mkdir
スリープ	sleep
パイプ処理	tee
検索	grep, find

Linux利用者であれば見慣れたコマンドがそのまま利用可。

PowerShellとの衝突問題

ここが最大の注意点！

PowerShell には既に同名のエイリアスや組み込みコマンドが存在する。

例:

コマンド	問題
ls	PowerShellエイリアスと衝突
cp	Copy-Itemと衝突
cat	Get-Contentと衝突
rm	Remove-Itemと衝突
pwd	Get-Locationと衝突

そのため、

ls

を実行しても、必ずしも Coreutils 版が呼ばれるわけではない。

Microsoft は PowerShell 7.4 以降の利用を推奨している。

Windows特有の制約

Linux 互換を目指しているものの、Windowsの仕組みによる制限が存在する。

1. POSIX シグナルがない

Linuxの

kill
SIGTERM
SIGKILL

の仕組みはWindowsに存在しない。

そのため、

kill
timeout

は現時点で提供されない。

2. /dev/null が存在しない

Linux:

grep error log.txt > /dev/null

Windows:

grep error log.txt > NUL

となる。

3. ACLとPOSIX権限の違い

Windows は ACL ベースの権限管理である。

そのため、

chmod
chown
chgrp

などのコマンドは提供されない。

4. シンボリックリンク作成

読み取りは可能だが、新規作成には

Developer Mode
管理者権限

が必要である。

提供されない主なコマンド

Microsoft は一部コマンドを意図的に除外している。

Windows と衝突するもの

dir
more
paste
whoami
expand

POSIX 依存が強いもの

chmod
chown
chgrp
chroot
nohup
stty
tty
who

現時点で未実装なもの

kill
timeout
dd

WSLとの違い

よく比較されるのが WSL（Windows Subsystem for Linux）である。

項目	Microsoft.Coreutils	WSL
導入コスト	非常に低い	Linux環境構築が必要
起動速度	ネイティブ	仮想環境層あり
Linux互換性	一部	非常に高い
Bash環境	なし	あり
apt利用	不可	可能
シェルスクリプト互換性	限定的	高い

WSL は「Linux 環境そのもの」だが、Coreutils は「Windows 上で Linux 風コマンドを使うためのツール集」である。

Makefile のすすめ

2026年5月29日

ひかり

背景と課題意識

日々の業務で Python スクリプトを用いてデータ変換の自動化を行うと、次のような課題に直面することが多い。

元データの一部だけが更新されたのに全体を実行し直して時間を浪費する。
どの手順がどのファイルに依存しているかが曖昧で、実行順序や抜け漏れの管理が難しい。
スクリプトの変更がどの成果物に影響するか掴みにくい。

Makefile は「依存関係」と「差分だけの再実行（インクリメンタルビルド）」を標準機能として備え、これらの課題を小さな記述で解決できる道具である。

Make の基本

ターゲット: 生成物（例: output/report.csv）
依存関係: 生成に必要なファイル（例: data/clean/*.csv やスクリプト）
レシピ: 生成に使うコマンド（例: python scripts/aggregate.py ...）

Make は「依存関係がターゲットより新しいときにだけレシピを実行」する。これにより、元データや Python スクリプトを更新した場合に、必要な箇所のみが自動的に再実行される。

最小構成の Makefile 例

以下は raw データをクリーニングし、集計レポートを作る一連の処理を差分実行する例である。

# Makefile
SHELL := bash
.SHELLFLAGS := -eu -o pipefail -c
.DELETE_ON_ERROR:
.ONESHELL:
.DEFAULT_GOAL := all

RAW_DIR := data/raw
CLEAN_DIR := data/clean
OUT_DIR := output

RAW := $(wildcard $(RAW_DIR)/*.csv)
CLEAN := $(patsubst $(RAW_DIR)/%.csv,$(CLEAN_DIR)/%.csv,$(RAW))
REPORT := $(OUT_DIR)/report.csv

# ディレクトリは順序限定依存（存在しなければ作るが、更新判定には使わない）
$(CLEAN_DIR) $(OUT_DIR):
	mkdir -p $@

# 集計レポートはクリーン済み CSV と集計スクリプトに依存
$(REPORT): $(CLEAN) scripts/aggregate.py | $(OUT_DIR)
	python scripts/aggregate.py -i $(CLEAN_DIR) -o $@

# 各 raw CSV から対応する clean CSV を生成
$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv scripts/clean.py | $(CLEAN_DIR)
	python scripts/clean.py -i $< -o $@

.PHONY: all clean status

all: $(REPORT)

clean:
	rm -rf $(CLEAN_DIR) $(OUT_DIR)

# 何が再ビルド対象かを確認するヘルパ
status:
	@echo "RAW   : $(RAW)"
	@echo "CLEAN : $(CLEAN)"
	@echo "REPORT: $(REPORT)"
	@echo
	@echo "Dry-run (what would run):"
	@$(MAKE) -n all

この構成により次が実現できる。

元データ data/raw/foo.csv を更新すると、対応する data/clean/foo.csv だけが再生成される。
scripts/clean.py を更新すると、クリーン工程だけが必要分再実行される。
scripts/aggregate.py を更新すると、集計レポートだけが再実行される。

動作イメージ

# 初回（すべて生成）
make -j

# 一部の raw が更新（そのファイルのクリーンとレポートのみ再実行）
touch data/raw/a.csv
make -j

# クリーニングスクリプトが更新（全クリーンとレポートを再実行）
touch scripts/clean.py
make -j

# 集計スクリプトが更新（レポートのみ再実行）
touch scripts/aggregate.py
make

「何が走るか」を事前確認するには make -n が有効である。

スクリプト依存の設計指針

各ルールには、それを直接呼び出す Python スクリプトを依存関係として明示することが重要である。
複数のモジュールに分割している場合、対象ルールが import するモジュールまで依存に含めると変更が正しく伝播する。簡便策としては対象ディレクトリの Python ファイル一式を変数化して依存に加える。

例（簡便策）:

PY_SRCS := $(wildcard scripts/**/*.py) $(wildcard scripts/*.py)

$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv $(PY_SRCS) | $(CLEAN_DIR)
	python scripts/clean.py -i $< -o $@

並列実行と高速化

make -j により独立したファイル変換を並列化できる。データ点数が多いほど効果が高い。
中間生成物を細かく分割するほど差分実行が効きやすく、全体の再計算を回避できる。
I/O がボトルネックの場合は圧縮形式やファイル分割、ローカル SSD などと併用する。

実運用のコツ

ディレクトリ作成は順序限定依存（| dir）で扱い、無駄な再ビルドを避ける。
失敗時に不完全な生成物を残さないために .DELETE_ON_ERROR を有効化する。
よく使う入口を .DEFAULT_GOAL := all で標準化し、make 一発で動かせるようにする。
デバッグには make -n（実行せず表示）、make --trace（どの判定で動くか表示）、make -d（詳細ログ）を使う。
クリーンアップは .PHONY: clean とし、生成物だけを削除するよう注意する。

仮想環境と依存パッケージ（任意）

Python の実行環境も Make で管理できる。

VENV := .venv
PY := $(VENV)/bin/python

$(VENV)/bin/python: requirements.txt
	python3 -m venv $(VENV)
	$(VENV)/bin/pip install -r requirements.txt
	touch $@

# 以降のレシピで $(PY) を使う
$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv scripts/clean.py | $(CLEAN_DIR) $(VENV)/bin/python
	$(PY) scripts/clean.py -i $< -o $@

$(REPORT): $(CLEAN) scripts/aggregate.py | $(OUT_DIR) $(VENV)/bin/python
	$(PY) scripts/aggregate.py -i $(CLEAN_DIR) -o $@

requirements.txt を更新すると必要な範囲でのみ再セットアップされる。

まとめ

Makefile は「依存関係の明示」と「差分だけの再実行」を自動化し、データ変換パイプラインの信頼性と開発速度を大きく向上させる道具である。
元データ、スクリプト、生成物を正しく結び、処理を細かく分割することで、更新の影響範囲だけが素早く再計算される。
最小の記述で再現性・並列化・可観測性が手に入り、日々の自動化作業が一段と快適になるのである。

Anthropic API で Claude のモデル一覧を取得する

2026年5月22日

ひかり

Anthropic API の /v1/models エンドポイントを使うと、利用可能な Claude モデルの一覧とその仕様をプログラムから取得できる。

Cloudflare Workers で独自ドメインをさくらサーバーのサブパスに割り当てた

2026年4月20日

ひかり

背景

さくらのレンタルサーバー「ライトプラン」は、36ヶ月一括払いで 月額121円 という破格の安さだ。(12ヶ月一括の場合は月165円) 静的ファイルのホスティングや CGI 用途としては十分で、個人用途のストレージとして気軽に使える。

ただし、割り当てられるドメインは ユーザー名.sakura.ne.jp のサブドメインになるため、独自ドメインで特定のパスに紐づけたい場合は一工夫が必要になる。

やりたいこと

https://app.example.com にアクセスすると、 https://sakurauser.sakura.ne.jp/app/ のコンテンツが URL を変えずに 表示されるようにする。

なぜ単純な DNS 設定ではできないのか

DNS の CNAME レコードはホスト名しか指定できず、 /app/ のような パスを含む URL は指定できない。

リダイレクト (301) でも実現できるが、ブラウザのアドレスバーの URL が sakurauser.sakura.ne.jp/flower/ に変わってしまう。

Cloudflare Workers を使った透過プロキシなら、 URL を app.example.com のまま維持できる。

前提条件

Cloudflare に独自ドメイン (例: example.com) を登録済みであること
Cloudflare の無料プランで OK (10万リクエスト/日まで無料)

手順

1. Worker を作成する

Cloudflare ダッシュボード → Workers & Pages → Create
Start with Hello World! を選択
Worker 名を入力 (例: storage-proxy)
Deploy をクリック

2. コードを編集する

Deploy 後、Edit code をクリックし、以下のコードに全て置き換える。

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const target = new URL("https://sakurauser.sakura.ne.jp");
    target.pathname = "/app" + url.pathname;
    target.search = url.search;

    const newRequest = new Request(target.toString(), {
      method: request.method,
      headers: request.headers,
      body: request.body,
    });

    const response = await fetch(newRequest);

    const newHeaders = new Headers(response.headers);
    newHeaders.delete("content-security-policy");
    newHeaders.delete("x-frame-options");

    return new Response(response.body, {
      status: response.status,
      headers: newHeaders,
    });
  }
};

まとめ

さくらのレンタルサーバーライトプランは 月額121円 と格安で、静的ファイルの置き場として十分使える
ただし独自ドメインをサブパスに割り当てる DNS 設定は標準機能では不可能
Cloudflare Workers を透過プロキシとして挟むことで、URL を変えずにコンテンツを配信できる
Workers のコードは数十行で済み、Cloudflare 無料プランの範囲内で動作する

AWS S3 から Cloudflare Pages へ移行しました

2026年4月19日

ひかり

このブログを AWS S3 から Cloudflare Pages へ移行した。これまでは S3 で静的ホスティングを行い、CloudFront を通じて配信していたが、管理の簡素化とパフォーマンス向上のために Cloudflare Pages を採用することにした。

CSS ではなぜ「8 の倍数」が余白の基準になるのか

2026年4月12日

ひかり

現代の UI デザインでは「余白は 8 の倍数で設定する」というルールがよく用いられる。これは単なる慣習ではなく、画面密度・タイポグラフィ・スケールの数学的整合性に裏付けられた経験則である。

新機能 Amazon S3 Files で S3 バケットを EC2 にマウントする

2026年4月8日

ひかり

Amazon S3 Files は、S3 バケットを NFS ファイルシステムとして EC2 などのコンピュートリソースに直接マウントできるサービスである。データは S3 に保持されたまま、通常のファイル操作 (ls、cp、cat など) で読み書きできる。

mitmproxy で AI コーディングツールの通信を見てみる

2026年4月5日

ひかり

mitmproxy を中間プロキシとして設定することで、AI コーディングツールが裏側で行っている API 通信をリアルタイムで確認できる。

Amazon Cognito でパスキー (WebAuthn) を設定してみた

2026年4月5日

ひかり

AWS SAM で構築したファイルストレージ API のユーザー認証に Amazon Cognito を使っている。先日、パスキー (WebAuthn) によるログインを追加したので、設定内容をまとめる。

llmglot とは​

対応範囲​

Claude Code とローカル LLM を接続する​

Responses API にも対応​

ログ機能が便利​

LiteLLM との違い

LiteLLMの考え方​

llmglot の考え方​

Claude Code で比較する​

どちらを選ぶべきか​

まとめ​

WinGetでインストールできるMicrosoft公式Linuxコマンド群の最新動向（2026年6月更新）​

概要

インストール方法

利用できる主なコマンド

PowerShellとの衝突問題

Windows特有の制約

1. POSIX シグナルがない​

2. /dev/null が存在しない​

3. ACLとPOSIX権限の違い​

4. シンボリックリンク作成​

提供されない主なコマンド

Windows と衝突するもの​

POSIX 依存が強いもの​

現時点で未実装なもの​

WSLとの違い

背景と課題意識​

Make の基本​

最小構成の Makefile 例​

動作イメージ​

スクリプト依存の設計指針​

並列実行と高速化​

実運用のコツ​

仮想環境と依存パッケージ（任意）​

まとめ​

背景​

やりたいこと​

なぜ単純な DNS 設定ではできないのか​

前提条件​

手順​

1. Worker を作成する​

2. コードを編集する​

まとめ​

llmglot とは

対応範囲

Claude Code とローカル LLM を接続する

Responses API にも対応

ログ機能が便利

LiteLLMの考え方

llmglot の考え方

Claude Code で比較する

どちらを選ぶべきか

まとめ

WinGetでインストールできるMicrosoft公式Linuxコマンド群の最新動向（2026年6月更新）

1. POSIX シグナルがない

2. /dev/null が存在しない

3. ACLとPOSIX権限の違い

4. シンボリックリンク作成

Windows と衝突するもの

POSIX 依存が強いもの

現時点で未実装なもの

背景と課題意識

Make の基本

最小構成の Makefile 例

動作イメージ

スクリプト依存の設計指針

並列実行と高速化

実運用のコツ

仮想環境と依存パッケージ（任意）

まとめ

背景

やりたいこと

なぜ単純な DNS 設定ではできないのか

前提条件

手順

1. Worker を作成する

2. コードを編集する

まとめ