aisuite（andrewyng/aisuite）は、複数のLLMプロバイダを1本のインタフェースで呼び出せるPython/JS向けOSSだ。OpenAI用・Anthropic用・ローカルLLM用と、プロバイダごとに違うSDKを書き分ける手間が地味に積み上がる開発現場で、この「呼び出し方の差」を統一インタフェースに閉じ込めるLLM API 統一の発想で作られている。開発者はAndrew Ng（DeepLearning.AI創業者としても知られる）個人。GitHubスターは16,014（2026年8月5日時点）、ライセンスはMIT。

OpenWorkerの動作概念図。ユーザーの質問→OpenWorker（任意のモデル：クラウド・オープンウェイト・完全ローカル）→Slack/GitHub/Notion等のツール→チャットで結果を返す、という一連の流れを示す
aisuiteのAgents API層を土台に構築されたデスクトップAIコワーカー「OpenWorker」の動作概念図。「Any model：cloud・open-weight・fully local」の部分がまさにaisuiteの守備範囲にあたる（出典: andrewyng/openworker 公式README）
30秒でわかる aisuite（2026年8月時点）
  • ・正体：Andrew Ng個人が公開する、複数LLMプロバイダを統一APIで呼べるPython/JS向けクライアントSDK。GitHubスター16,014・フォーク1,689、ライセンスはMIT。
  • ・何ができる：OpenAI・Anthropic・Ollama等をプロバイダ名を切り替えるだけで呼び分けられるChat Completions層と、ツール呼び出し・MCP対応を持つAgents API層の2段構成。
  • ・何を代替できる：プロバイダごとに別々のSDKを書き分ける手間。ただしサーバー型ルーティングサービス（OpenRouter等）とは層が違うため置き換えではなく別のレイヤー。
  • ・実測：検証環境でpip install aisuiteは正常終了。ただし本記事の検証環境には有料APIキー・ローカルOllamaのいずれも用意できなかったため、実際のチャット応答の取得は未実施（詳細は本文で明記）。
  • ・注意：2024年11月のリリース開始から約1年9ヶ月経った現在もv0.1.3のpre-1.0。本番導入前にAPIの破壊的変更リスクを織り込む必要がある。

この記事ではクライアント側SDKとしてのaisuiteをDevOps/自動化ツールの文脈で解説します。自動化・運用ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

aisuiteとは：複数LLMプロバイダを統一APIで呼べるクライアント側SDK

aisuiteが解決するのは、「同じ処理を複数のLLMプロバイダで動かしたいのに、プロバイダごとにSDKの作法が違う」という開発者の日常的な摩擦だ。OpenAIのSDK・AnthropicのSDK・Ollamaのクライアントは、それぞれ微妙にメソッド名やレスポンス形式が異なる。プロバイダを切り替えるたびにコードの書き方を変える必要があると、A/Bテストやフォールバック構成、コスト最適化のためのモデル切り替えといった、複数プロバイダを併用する場面すべてでコストがかさむ。

aisuiteは、この差分を「OpenAIのChat Completions APIの形式」に統一することで吸収する。呼び出し側はai.Client()を作り、model引数に<provider>:<model-name>という形式の文字列を渡すだけで、内部的に対応するプロバイダのSDKへ処理を振り分ける。プロバイダを切り替えるコード変更は、実質的にこの文字列を書き換えるだけで済む設計だ。

flowchart LR A["client.chat.completions.create(
model='ollama:llama3.1', messages=[...])"] --> B{"モデル文字列を解析
<provider>:<model-name>"} B -- "provider名を省略" --> C["エラー
プロバイダを解決できない"] B -- "provider名あり" --> D["対応プロバイダのSDKへ委譲"] D --> E["OpenAI / Anthropic / Ollama など"]

ここで重要なのが、aisuiteは「サーバーを立ててリクエストを転送するルーティングサービス」ではなく「アプリのプロセス内で直接プロバイダを呼ぶクライアントライブラリ」だという点だ。呼び出しはあなたのアプリのコード内で完結し、途中に別のサーバーを経由しない。この「層の違い」は、後述するLiteLLMやOpenRouterとの比較で改めて整理する。

実測で確認したプロジェクトの規模

記事化にあたり、2026年8月5日時点の実データをGitHub APIで確認した。

・⭐ GitHubスター：16,014（フォーク1,689）
・📦 GitHub Releases：5本、最新版はv0.1.3（2026年7月20日公開）
・👥 コントリビュータ：約52人以上（GitHub APIのLinkヘッダから下限を確認）
・🛠️ 主要言語・構成：Pythonパッケージaisuiteを中心に、JS版aisuite-jsディレクトリも同居
・🏢 開発元：Andrew Ng個人（andrewyng）。企業スポンサーの明記はREADMEに無し
・🕒 最終コミット：2026年7月25日（pushed_at）で開発は現役

スター1万6千超という規模に対してリリースが5本のみという点は、後述する「pre-1.0のリスク」として本文後半で改めて扱う。

インストールと中身の確認：pip installと2層アーキテクチャ

実際にaisuiteをインストールし、パッケージの中身を確認した。検証環境はPython 3.11。

pip install aisuite

このコマンドは検証環境で正常に完了し、aisuite本体と依存パッケージ（httpx・docstring-parser等）がインストールされた。続けてインストールされたパッケージのメタデータを確認する。

pip show aisuite

出力にはAuthor: Andrew Ng Author-email: [email protected]と、開発元が個人であることがそのまま表示される。興味深いのはバージョン表示で、PyPIから配布されているパッケージは0.1.14だった。これはGitHub Releasesで確認できる最新タグv0.1.3（5本目のリリース）とは異なる番号である。GitHub上でタグを切った「リリース」と、PyPIへ実際に配布されているパッケージバージョンの間にズレがあるということは、開発側がリリースノートを毎回丁寧に整備する体制にはまだ至っていないことを示唆しており、これもpre-1.0段階らしい運用の粗さと言える。

aisuiteの内部構造は、公式READMEの記述をたどると大きく2つの層に分かれている。土台になるのがChat Completions層で、OpenAI形式のインタフェースに統一して各プロバイダを呼び出す部分。その上に、ツール呼び出しやMCP（Model Context Protocol）接続を扱うAgents API層が乗る構成だ。

aisuiteの2層構成を示す図。上段にOpenWorker（デスクトップAIコワーカー）、中段にAgents API層（ツール呼び出し・MCP対応）、下段にChat Completions層（統一インタフェースで複数プロバイダを呼び出す）が積み重なっている
aisuiteの2層構成と、その上に構築されたOpenWorkerの位置づけ（出典: andrewyng/aisuite・andrewyng/openworker 公式README）
読者の3つの問いへの答え
① 何ができる：複数LLMプロバイダを1つのSDKで、Chat Completions形式に統一して呼び出せる。② 何を解決する：プロバイダごとにSDKを書き分ける手間と、モデル切り替え時のコード変更コスト。③ 何を代替できる：自前で複数SDKのラッパーを書く作業。ただしサーバー型ルーティングサービスの代替にはならない（層が違う）。

クイックスタート：モデル文字列の書式と実行時の注意点

公式READMEが示すもっとも基本的な使い方は、ai.Client()を作り、chat.completions.create()にmodelとmessagesを渡す形だ。有料のAPIキーを持つプロバイダはもちろん、READMEにはOllamaプロバイダ対応も明記されているため、ローカルの無料モデルだけで試すこともできる。

import aisuite as ai

client = ai.Client()
response = client.chat.completions.create(
    model="ollama:llama3.1",
    messages=[{"role": "user", "content": "Say hello in one sentence."}]
)
print(response.choices[0].message.content)

このコード自体は公式READMEに沿った基本形だが、本記事の検証環境にはOllamaも有料のLLM APIキーも用意できなかったため、実際にこのスクリプトを実行してモデルの応答を得ることはしていない。検証できたのは前段のpip install aisuiteが正常終了することまでで、それ以上の実行結果を断定するのは避ける。手元で試す場合は、事前にollama pull llama3.1等でモデルを取得しておく必要がある。

ここで実務上ハマりやすいのが、モデル文字列の書式だ。aisuiteでは<provider>:<model-name>という形式が必須で、ollama:llama3.1のようにプロバイダ名を必ず先頭に付ける。llama3.1とだけ書いてプロバイダ名を省略すると、どのSDKに処理を委譲すればよいか解決できずエラーになる。前掲のMermaid図はこの分岐を示したものだ。プロバイダをまたいでモデルを切り替える運用をするなら、この文字列だけを設定ファイルや環境変数で外出しにしておくと、コードの変更なしにプロバイダ移行ができる。

この設計のメリットが際立つのは、A/Bテストやフォールバック構成を組むときだ。例えば「まず高性能なクラウドモデルで応答を試み、レート制限や障害が起きたらローカルのOllamaモデルにフォールバックする」といった構成を考えると、プロバイダごとに別々のSDKを呼び分けるコードを書かずに済み、model引数の文字列を差し替えるロジックだけで対応できる。逆に言えば、aisuiteが吸収してくれるのはあくまで「呼び出し方の統一」までであり、各プロバイダの料金体系・レート制限・コンテキスト長といった特性そのものが均一になるわけではない。プロバイダ間の違いを意識した設計は、依然としてアプリ側の責務として残る。

OpenWorkerとの関係：aisuiteを土台にしたデスクトップAIコワーカー

aisuiteが2026年に入って改めて注目を集めている理由の1つが、Andrew Ng自身が2026年7月20日に公開したデスクトップアプリOpenWorker（andrewyng/openworker）の存在だ。OpenWorkerはaisuiteとは別のリポジトリとして公開されたプロダクトで、READMEによれば「Slack・GitHub・Notion・Google DriveなどのツールにアクセスできるAIコワーカーが、あなたのコンピュータ上で動く」というコンセプトのデスクトップアプリである。公開からわずか2週間強で、GitHubスターが12,784まで伸びた（本記事執筆時点で確認）。

前掲のOpenWorker公式図が示す通り、ユーザーが自然文で依頼を投げると、OpenWorkerが「Any model：cloud・open-weight・fully local（クラウド・オープンウェイト・完全ローカルのいずれのモデルでも）」動作し、Slack・Outlook・Googleカレンダー・Notion・GitHub・HubSpot・Google Driveといった各種ツールと連携して、結果をチャットやMarkdown・PDF・画像といった形式で返す。この「Any model」を実現している技術的な土台が、まさにaisuiteのAgents API層である。ツール呼び出しやMCP接続をプロバイダに依存せず扱えるからこそ、OpenWorkerは背後のモデルをクラウドAPIからローカルモデルまで差し替え可能な設計にできている。

なお、aisuite本体のリポジトリ内に残っているplatform/ディレクトリは、OpenWorker開発時点の旧スナップショットであり、README上でも今後削除予定と明記されている。これはOpenWorkerの一部がaisuiteリポジトリ内で先行開発されていた名残であって、aisuite本体の正式な機能ではない点は誤読しないよう注意したい。

両者の関係を整理すると、「aisuiteはライブラリ、OpenWorkerはそのライブラリを使って作られたアプリケーション」という一般的なSDKとプロダクトの関係に過ぎない。ただし今回のケースが興味深いのは、同じ開発者本人がライブラリとその上に載るキラーアプリの両方を、ごく短い間隔で連続して公開した点だ。ライブラリ単体では「複数プロバイダを統一APIで呼べる」という地味な価値しか伝わりにくいが、OpenWorkerという具体的なプロダクトが2週間強でスター1万超を集めたことで、aisuiteのAgents API層が実際にどんな用途で使われうるのかが可視化された形になる。OSSのSDKを評価する際、README単体の説明だけでなく「実際にそのSDK上で何が構築されているか」まで確認すると、技術選定の判断材料が増える一例と言えるだろう。

aisuiteのGitHubスター16,014、OpenWorkerのGitHubスター12,784（公開2週間強）、aisuiteのGitHub Releases数5本（最新v0.1.3）を並べた数値インフォグラフィック
aisuiteとOpenWorkerの実測数値（2026年8月5日時点）。OpenWorkerの★12,784は公開からの日数が短い点を織り込んで読む必要がある（出典: andrewyng/aisuite・andrewyng/openworker GitHub実測）
aisuiteの立ち位置は「ルーティングサービス」ではなく「OpenWorkerのようなプロダクトが上に構築されるクライアント側SDK」。OpenWorkerの急伸ぶりだけを見て、aisuite自体を成熟した1.0系プロダクトだと誤読しないよう注意したい。

LiteLLM・OpenRouterとの違い：サーバー型ルーティングとクライアント側SDKの層の違い

「複数LLMを統一的に扱う」というテーマでは、当サイトでもVercel、AI Gateway統合レポートAPI正式提供開始やDecolua 9router：Luaで軽量ルーティングを実装するシングルファイルフレームワークを扱ってきた。ただし、これらとaisuiteは同じ土俵で比較できるものではない。OpenRouterやVercel AI Gatewayは、リクエストをサーバー側で受け取り、内部でモデルを選んで転送する非OSSのSaaSだ。対してaisuiteは、あなたのアプリのプロセス内から直接各プロバイダのAPIを呼び出すクライアント側のSDKであり、間に別のサーバーを挟まない。

もう1つの主要な比較対象がLiteLLM（BerriAI/litellm、GitHubスター55,558）だ。LiteLLMもaisuiteと同じくクライアントSDKとして利用できるが、加えて「LiteLLM Proxy」というサーバー型の運用形態も持つ点で対応範囲が広い。ライセンス表記には注意が必要で、GitHub APIのlicenseフィールドは標準SPDXと一致しないNOASSERTIONを返す。実際にリポジトリのLICENSEファイル原文を確認したところ、大部分のコードはMITライセンスだが、enterprise/ディレクトリ配下だけは別ライセンス（本番利用に商用サブスクリプションを要求するBerriAI独自のEnterprise License）が適用される、という2階建ての構成になっていた。GitHub APIが単一のSPDXライセンスとして判定できずNOASSERTIONを返すのは、このためだと考えられる。

サーバー型ルーティング（OpenRouter・Vercel AI Gateway）とクライアント側SDK（aisuite）を対比した図。左は非OSSのSaaSでサーバー側転送・自社サーバーを経由しない構成は組めない。右はMITのクライアント側SDKでアプリのプロセス内から直接プロバイダを呼びコードを手元に置ける
サーバー型ルーティングサービスとクライアント側SDKの構造上の違い
項目 aisuite LiteLLM OpenRouter Vercel AI Gateway
形態 クライアント側SDK クライアント側SDK＋Proxyサーバー運用 サーバー型SaaS サーバー型SaaS（Vercel製）
ライセンス MIT 本体MIT／enterprise/のみ別ライセンス（要商用契約） 非OSS 非OSS
GitHubスター 16,014 55,558 ― ―
Agents API・MCP対応 あり（OpenWorkerの技術基盤） Proxy経由の機能追加は別途 ― ―
該当する既存記事 本記事 ― Vercel、AI Gateway統合レポートAPI正式提供開始で言及 同上

比較表からも分かる通り、star数だけを見るとLiteLLMの規模が圧倒的だが、これは「クライアントSDK単体」と「クライアントSDK＋サーバー運用の両対応」という守備範囲の違いも影響している。「複数プロバイダを統一APIで呼びたいだけ」ならaisuiteのようなシンプルな構成、「社内でプロキシサーバーとして一元運用したい」ならLiteLLM Proxyのような選択肢、「自前でインフラを持たずルーティングだけSaaSに任せたい」ならOpenRouterやVercel AI Gateway、という住み分けで考えると選びやすい。

導入前に確認したいこと：pre-1.0のリスクとライセンスの読み方

aisuiteをプロダクションのコードベースに組み込む前に、確認しておきたい点を整理する。

・pre-1.0であること：2024年11月のリリース開始から約1年9ヶ月が経過した2026年8月時点でも、最新版はv0.1.3（通算5リリース）にとどまる。GitHubスター16,014という知名度の高さと、リリースの少なさは必ずしも矛盾しないが、「スターが多い＝APIが安定している」と読み替えるのは早計だ。将来のマイナーバージョンアップで、Chat Completions層やAgents API層のインタフェースが破壊的に変わる可能性は織り込んでおきたい
・開発体制：GitHubのandrewyng個人アカウントでの公開であり、企業によるスポンサーシップの明記はREADMEに見当たらない。コントリビュータは約52人以上いることをGitHub API経由で確認できたが、正確な合計人数やコミット内訳の集計までは今回の検証範囲外としている
・バス係数の考え方：Andrew Ng本人の知名度がスター数を牽引している可能性が高い。個人発のOSSに共通する留意点として、中核メンバーの継続的な関与に依存する度合いが企業バックのOSSより大きくなりがちな点は意識しておくべきだろう
・PyPI版とGitHub Releasesのバージョンずれ：前述の通り、pip show aisuiteで確認できるパッケージバージョン（0.1.14）と、GitHub Releasesの最新タグ（v0.1.3）は一致しない。どちらのバージョン番号を基準に管理するかは、依存関係を固定する際にチーム内で認識を揃えておいた方がよい

ライセンスまわりの注意
aisuite自体はMITで、LICENSEファイルの原文とも一致している。ただし比較対象として挙げたLiteLLMは「本体はMIT、`enterprise/`ディレクトリのみ別ライセンス」という2階建て構成になっている。競合ツールを比較する際は、GitHub APIが返す単一のライセンス表記を鵜呑みにせず、実際のLICENSEファイルを開いて確認する習慣が安全である。
まとめ
aisuiteは、複数LLMプロバイダをChat Completions形式の統一APIで呼べるクライアント側SDKであり、その上にツール呼び出し・MCP対応を持つAgents API層を備える。この2段構成の上に、Andrew Ng自身が公開したデスクトップAIコワーカー「OpenWorker」（公開2週間強で★12,784）が実際に構築されている。サーバー型ルーティングサービス（OpenRouter・Vercel AI Gateway）とは層が異なり、LiteLLMとはクライアントSDK同士で機能範囲が重なる部分がある。GitHubスター16,014という知名度に対し、まだv0.1.3のpre-1.0段階である点は、本番導入前に必ず確認しておきたい。

参照ソース

・andrewyng/aisuite（公式リポジトリ・README） — アーキテクチャ・Chat Completions/Agents API仕様・インストール手順を取得
・andrewyng/openworker（公式リポジトリ・README） — aisuiteとの関係・構成図（how-it-works.png）・機能一覧を取得
・aisuite GitHub Releases — リリース数・最新版v0.1.3の公開日を取得
・BerriAI/litellm（公式リポジトリ） — 比較表のスター数・LICENSE/enterprise LICENSE.md原文を取得