logbook://zem

Claude Code を LiteLLM 経由し、さくらの AI Engine へ接続する検証手順

2026-03-08T11:14:00Z

概要

さくらの AI Engine で Claude Code を動かすための手順です。あらかじめ、LiteLLM の接続先をさくらの AI Engine とした設定ファイルも準備し、LiteLLM の Docker コンテナを起動。それから、Claude Code が実行時に参照する環境変数 ANTHROPIC_BASE_URL 等を LiteLLM に変更し、Claude Code での操作を確認します。ただし、LLM の問い合わせ先を切り替えるたあとは、Claude Code の検索機能など、Claude に依存する機能は使えなくなります^[1]。

背景

Claude Code を使いたいものの、「さくらの AI Engine上に問い合わせができないか？」という漠然とした気持ちからの調査を開始でした。既に OpenCode でさくらの AI Engine に接続できるのは確認済みでしたが、同じように Claude Code でも使えるのではという思いはありました。

そして、Claude Code の公式ドキュメント^[2] を読んでいると、「LLM gateway設定」^[3]ページの存在に気づきました。LiteLLM には OpenAI 互換エンドポイント^[4] があるため、LiteLLM を通し、さくらの AI Engine に接続できる可能性を考えました。

さくらの AI Engine と Claude Code を接続する方法としては、先行事例としてダーシノさんによる「さくらのAI Engine × Claude CodeではじめるAgentic Coding」記事があります。この記事では Claude Code Router　^[5] を使っていましたので、別の方法で接続できないか試したいため、検証を進めました。

前提

検証は macOS 上で行いましたが、おそらく Linux でも動作するものと思います。 LiteLLM は Docker コンテナとして動かすため、あらかじめ Docker Desktop のインストールが必要です（Linux 環境上であれば Docker Engine が入っていれば動作すると思います）。

手順

設定ファイルをいくつか準備する必要があるため、まず litellm-sakura という名前^[6]のディレクトリを作成し、移動します。

$ mkdir litellm-sakura
$ cd litellm-sakura

それから、LiteLLM 実行時に参照する設定ファイル config.yaml ^[7]を準備します。ファイル内容は以下のようにします。設定ファイルサンプルを参考にしながらモデル名や、API エンドポイントを記載していきます。 model_list: 以下は1つでも動作しますが、複数のモデルを用途に応じて切り替えられるようにしています。 apikey には、さくらのAI Engine アクセストークンを入れますが、直接記述するのは様々な懸念があるため、環境変数 SAKURA_API_KEY を参照するようにしています。

model_list:
  - model_name: Qwen3-Coder-480B-A35B-Instruct-FP8
    litellm_params:
      model: openai/Qwen3-Coder-480B-A35B-Instruct-FP8
      api_base: https://api.ai.sakura.ad.jp/v1
      api_key: os.environ/SAKURA_API_KEY
  - model_name: Qwen3-Coder-30B-A3B-Instruct
    litellm_params:
      model: openai/Qwen3-Coder-30B-A3B-Instruct
      api_base: https://api.ai.sakura.ad.jp/v1
      api_key: os.environ/SAKURA_API_KEY
  - model_name: gpt-oss-120b
    litellm_params:
      model: openai/gpt-oss-120b
      api_base: https://api.ai.sakura.ad.jp/v1
      api_key: os.environ/SAKURA_API_KEY
  - model_name: Qwen3-0.6B
    litellm_params:
      model: openai/Qwen3-0.6B
      api_base: https://api.ai.sakura.ad.jp/v1
      api_key: os.environ/SAKURA_API_KEY
litellm_settings:
  drop_params: true

ファイルの準備が調ったら、次は Docker で LiteLLM を起動します。

その前に、さくらの AI Engine のアクセストークンを環境変数 SAKURA_API_KEY に入れておきます。 read コマンドを使う場合は、次の様にコマンドを実行したあと、アクセストークンを入力してエンターキーを押します。

$ read -s SAKURA_API_KEY

入力後は echo $SAKURA_API_KEY を実行し、適切にアクセストークンが表示されるか確認しておきます。

それから、リファレス^[8]を参考にして、以下のコマンドを実行し LiteLLM の proxy を動かします。ここでは litellm-sakura という名前でコンテナを起動します。

$ docker run -d \
    --name litellm-sakura \
    -p 4000:4000 \
    -e SAKURA_API_KEY=$SAKURA_API_KEY \
    -v $(pwd)/config.yaml:/app/config.yaml \
    docker.litellm.ai/berriai/litellm:main-latest \
    --config /app/config.yaml

コマンド実行後、docker ps コマンドを入力し、コンテナが正常も動作しているのを確認します。

$ docker ps
CONTAINER ID   IMAGE                                           COMMAND                   CREATED         STATUS         PORTS                                         NAMES
771696c38fb0   docker.litellm.ai/berriai/litellm:main-latest   "docker/prod_entrypo…"   9 seconds ago   Up 8 seconds   0.0.0.0:4000->4000/tcp, [::]:4000->4000/tcp   litellm-sakura

もし docker ps で何も表示されなければコンテナは停止しています。 docker logs litellm-sakura を実行すると、コンテナ実行から終了までのログが画面に出ますので、内容を確認して対処します。ちなみに私は初回、設定ファイルのパス指定を間違えてしまい、ログには IsADirectoryError: [Errno 21] Is a directory: '/app/config.yaml' というエラーが出ていました。

続けて、curl コマンドで LiteLLM proxy （ローカルのport 4000で動作中）に対してリクエストを送り、さくらの AI Engineから応答があるかどうかを確認します。

$ curl http://localhost:4000/v1/messages \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer dummy" \
    -d '{
      "model": "Qwen3-Coder-30B-A3B-Instruct",
      "max_tokens": 50,
      "messages": [{"role": "user", "content": "hello"}]
    }'

実行後、次のような応答があれば正常です。

{"id":"chatcmpl-bed700d71de14efa8464ccbd53d94f5d","type":"message","role":"assistant","model":"Qwen3-Coder-30B-A3B-Instruct","stop_sequence":null,"usage":{"input_tokens":9,"output_tokens":10,"total_tokens":19},"content":[{"type":"text","text":"Hello! How can I help you today?"}],"stop_reason":"end_turn"}

（モデル名はさくらの AI Engine上のもので、「content」には応答「Hello! How can I help you today?」が正常表示）

もし応答がなければ、アクセストークンが正しいかどうか、あるいは Docker コンテナが定常に起動しているかどうか再確認します。

それから環境変数を指定します。ここでは env.sh を作ります。

export ANTHROPIC_BASE_URL="http://localhost:4000"
export ANTHROPIC_AUTH_TOKEN="sk-litellm-static-key"
export ANTHROPIC_MODEL="Qwen3-Coder-480B-A35B-Instruct-FP8"
export ANTHROPIC_SMALL_FAST_MODEL="Qwen3-0.6B"

環境変数を読み込みます。

$ source ./env.sh

コマンド実行後、次のようにして、環境変数の内容を確認できます。

$ echo $ANTHROPIC_BASE_URL
http://localhost:4000

これで準備は調いました。あとは claude を実行したら自動的にさくらの AI Engine 側のモデルを参照した状態で起動できます。

もし claude コマンド実行後、Unable to connect to API (ConnectionRefused) と出る場合は、LiteLLM proxy が停止しているか、何か設定がおかしい可能性があります。手順を見直します。

`/status` を実行すると、どのモデルを参照しているのか見えます。

モデルを切り替え得たい場合は /model gpt-oss-120b のようにモデル名を指定します。

あとは色々ためせます。ちなみに、ウェブの検索は出来ないもようでした。

Enjoy!

正確には、現時点では「使えなくなる状態だと分かった」であり、何かしら設定を追加したり別の方法によって検索可能となる可能性はあるが、未調査。 ↩︎
https://code.claude.com/docs/ja/overview ↩︎
https://code.claude.com/docs/ja/llm-gateway ↩︎
https://docs.litellm.ai/docs/providers/openai_compatible ↩︎
GitHub: https://github.com/musistudio/claudecode-router ↩︎
名前は何でも良いのですが、ここでは litellm-sakura としました。 ↩︎
config.yaml のリファレンス：QuickStart https://docs.litellm.ai/docs/proxy/configs ↩︎
https://docs.litellm.ai/docs/proxy/docker_quick_start ↩︎

Bebop Style Development を公開しました

2025-12-29T12:35:00Z

Bebop Style Development

先日の投稿の通り、Tsubame は、生成 AI を使っての開発（AI-Assisted Developmentに類すると考えられる）を行いました。

私の開発スタイルは、Claude Code など自動的にコードを書かせるのではありません。ウェブブラウザ上のチャット画面での対話を通して、継続的な開発を行っています。Tsubame で試行錯誤していたプロセスを、手順としてまとめたのが、この Bebop Style Development です。

https://github.com/zembutsu/bebop-style-development

なぜ Bebop なのかというと、なんとなく生成 AI との対話の「ノリ」が、音楽っぽいような印象を受けたからです。例えると、オーケストラとの違い。はじめから終わりまで、楽譜通りに演奏する大規模な音楽というよりは、なんか良い感じに、やってみる？というアプローチを例えたものです。

おそらく、生成AIを使った何らかの開発、特にチャットを通しての場合、チャットが終わると意味が失われたり、継続することが困難という問題がありました。ですが、あらかじめ記録を「ログ」という形で残したり、ワークフローとして手順を作っておくと、別の会話ウインドウを開いたとしても、文脈を維持したまま作業を継続できています。

実際、今日もこの Bebop Style Development 方式で開発を行い、問題無く作業が進行しています。次のリンク先にあるログは、Claude に対して、自由にこの開発方式にフィードバックして欲しいと依頼した結果です。

https://gist.github.com/zembutsu/0f826b35195bc3d9e05404f131369b01

有る程度、利用者である私に忖度している書き方は感じますが、内容はさておき、開発としては機能していると考えられました。

そのため、しばらくはプライベートリポジトリで運用していましたが、一応の機能することが確認できたため、本日リポジトリをパブリックにしました。

まだ、細かな課題（定義が重すぎる、軽量版を作れないか）はいくつかありますが、徐々に運用しながら改善していきたいと考えています。

初めてのmacOSアプリ"Tsubame"を開発・リリース

2025-12-18T12:17:00Z

Tsubame とは

Tsubame（ https://github.com/zembutsu/tsubame ）は、私が初めて作った macOS アプリです^[1]。2025年11月から GitHub 上のリポジトリで開発を開始し、12月8日に macOS のバイナリリリース（Apple による Notarization 済み）に至りました。2012年にも Apple Developer Program に登録し、アプリ開発を試みていましたが挫折。積年を経て、ようやく開発に至りました。以下は、簡単なアプリの機能や、開発経緯を記録として残します。

Tsubame は2画面のウインドウ操作を瞬時に行うアプリ

Tsubame は macOS のメニューバーに常駐するタイプのアプリです。機能としては、一般的に「ウインドウマネージャー」の領域であり、アプリとしては「作業効率化」にあたります。想定している利用者は、メインディスプレイと外部ディスプレイを分けて使っている方。特に、家や会社など場所によってディスプレイの位置が異なる方です。基本機能は主に2つ。1つはアプリのウインドウを、キーショートカットで瞬時に別のディスプレイに移動する機能。もう1つは、ウインドウ位置の記憶・復元です。

アプリを違うディスプレイに移動するには、アプリを選択した状態でキーボード操作をします。デフォルトでは Ctrl-Cmd-→ で拡張画面に移動し、Ctrl-Cmd-←でメインウインドウに戻せます。移動後に微妙にポジションを調整したい場合は、Ctrl-Cmd-WASD（↑←↓→）で微調整も可能。つまり、キーボード操作をするだけ、トラックパッドやマウスを使わなくても瞬時にウインドウを移動できます。

また、ウインドウの記憶・復元は自動でも手動でも行えます。たとえば、外部ディスプレイとのケーブルが抜けたり、電源が節電モードで切れたりすると、拡張ディスプレイで表示していたアプリはメイン画面に移動させられます。しかし、再び拡張ディスプレイの接続が復帰してもウインドウはメインに残ったまま。通常であれば、何もないディスプレイに手動でウインドウを再配置する必要がありました。Tsubame はウインドウ位置を自動記録していますので、拡張ディスプレイとの接続が切れても、再認識したあとは自動的にウインドウを再配置します。

どうして作ったのか

そもそも、なぜ Tsubame を作ったかといえば、私自身が困った・面倒だと思っていたからです。私が困っていたのは2画面での作業時。ふだん、メイン画面と拡張画面を横に並べて使っています。おそらく私だけの環境かもしれませんが、macOS がスリープ状態から復帰したら、拡張画面で操作していたウインドウが強制的にメイン画面に戻ってしまう困りごとがずっとありました。拡張画面側のディスプレイの電源復帰に時間がかかるか、あるいはディスプレイを認識するまでに時間がかかるのでしょうか。

いずれにしろ、メイン画面のウインドウを、毎回トラックパッドで移動する必要がありました。私は常に10以上のウインドウを動かしていますので、元の自分の快適だと思う場所に戻すという手間がありました。本当毎回面倒ですし、思っていたベストポジションにウインドウを調整するのも面倒でした。

どのようにして作ったのか

当初、このアプリは単純なディスプレイ間の移動機能だけを備えていました。キーショートカットによって瞬時に移動できる。ただそれだけの、シンプルなアプリ。当時の開発コードは Window Smart Mover という名称です。Tsubame の GitHub リポジトリ内^[2]にも、開発当初の名残が今も残っています。

そして、いよいよアプリが動き意気揚々。これで全て解決したと思っていたのですが、この問題は根本的な私の悩みを解決しないのだと気づきました。

確かに、拡張ディスプレイにウインドウは瞬時に動かせるようになりました。キーボード操作だけで、本当に楽です。ですが、拡張ディスプレイに自動的にウインドウが再配置される機能こそが、私が本当に欲しかったものだと気づいたのです。そもそも、自動再配置できれば、キーボード操作で拡張ディスプレイにアプリを移動する手間すら不要になります。そして、ようやく主要機能をキーボード操作と自動復元の2つに絞っての開発がスタートしました。

ちなみに、似たようなツールとして Rectangle （https://rectangleapp.com/）や Magnet（https://magnet.crowdcafe.com/）は認識していました。ですが、どちらも私の求めている機能より多機能すぎたり学習コストが高そうだぞと。あるいはアプリは便利そうですが、ソースコードは公開されておらず、中身が見えなくて不安だという個人的な懸念もありました。

そして、たまたま Claude （ブラウザ版のチャット）を通して Xcode で開発できそうだと認識。あえて学習を通した車輪の再発明をしてみようと、勉強がてら取り組もうとしたのがスタート地点でした。その後、紆余曲折ありましたが、おおよそ1ヶ月でのリリースです。開発には Claude を使いました。Claude Code ではなく、普通にブラウザでの会話を通したのみです。何か開発用のツール導入や、生成AIサービスのAPI利用もありません。また、Vibe コーディングやspecのような定義をするような手法とも異なります。

基本的な進め方は、私がClaudeに指示したり質問したり、表示された内容を元に開発を進めました。そのため、もしかしたら、一般的な AI を使った開発手法とは異なり、AI 支援開発^[3]と呼ばれる類型なのかなと思います。思いますというおは、既存の手法を意識しておらず、Claude との会話を通してアプリの完成に至ったつもり。具体的な開発手法については、また改めて整理して書こうと思います。

なにをもって「アプリ」とするかですが、SwiftUI で作ったバイナリ形式のアプリは、初めてです。 ↩︎
https://github.com/zembutsu/tsubame/tree/main/WindowSmartMover ↩︎
AI-Assisted Development ↩︎

Close the world, Open the next.

2025-11-02T12:00:00Z

Close the world, Open the next.^[1]

私(@zembutsu)の、個人的な取り組み・記録を公開する場所。

散らばった情報のカケラを整理する場所。

PlayStation の "Serial Experiments Lain" のパッケージに掲載された文字。 ↩︎