kiro-gateway は Kiro の認証を OpenAI/Anthropic 互換エンドポイントに変換する

Kiro のクライアント側に閉じている認証を外に出す

Kiro IDE と kiro-cli は、AWS IAM Identity Center 経由の SSO で得たトークンを ~/.aws/sso/cache/ 配下の JSON に保存して使う。このトークンは Kiro 自身のクライアントからしか使えない形になっており、Claude Code や Cline、Continue といった別のツールから同じモデルを呼びたい場合、通常は別の認証経路を用意する必要がある。kiro-gateway はその間に入り、Kiro 側の認証情報を読み取って、OpenAI 互換と Anthropic 互換の HTTP エンドポイントとして公開する。対象読者は、すでに Kiro の無料ティアか社給アカウントを持っていて、エディタや CLI を乗り換えずにモデルだけ共有したい開発者だ。README は Claude Code、OpenCode、OpenClaw、Codex app、Cursor、Cline、Roo Code、Kilo Code、Obsidian、OpenAI SDK、LangChain、Continue を対応先として列挙している。逆に、Kiro を一度も使ったことがない人にとっては、このゲートウェイ単体では何も始まらない。認証の出所が Kiro 側にあることが前提のツールである。

リクエストはどこで Kiro の API 形式に変換されるのか

構成は FastAPI アプリケーション 1 プロセスで、main.py から起動する。クライアントは OpenAI 互換のパスか Anthropic 互換の /v1/messages に対してリクエストを送り、ゲートウェイはそれを Kiro API（Amazon Q Developer / AWS CodeWhisperer 系）の呼び出しに変換する。README の機能表によれば、変換の過程でストリーミング（SSE）、ツール呼び出し（function calling）、画像入力、Web 検索、拡張思考、会話履歴の全体引き渡しが扱われる。ここで実装上の特徴として挙げられているのがモデル名の正規化だ。claude-sonnet-4-5、claude-sonnet-4.5、claude-sonnet-4-5-20250929 のような表記揺れをゲートウェイ側で吸収する。クライアントごとにモデル名の書き方が違う問題を、設定ファイルを各ツールで書き分けるのではなくサーバー側の 1 箇所に寄せている。トークンは有効期限前に自動更新される。README の記述から確認できる範囲では、リクエストの再試行は 403、429、5xx に対して行われる。

起動手順と認証の 3 つの渡し方

導入は Python 3.10 以上を前提とし、git clone のあと pip install -r requirements.txt、cp .env.example .env を編集して python main.py を実行する。ポート 8000 が埋まっている場合は python main.py --port 9000 のように変更できる。Docker でのデプロイも用意されている。認証情報の渡し方は README に 3 通り示されている。1 つ目は JSON ファイル方式で、KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token.json" のようにパスを指定する。Kiro IDE の個人アカウントと、SSO を使う法人アカウントの両方で使える。2 つ目は環境変数方式で、REFRESH_TOKEN を直接 .env に書き、必要に応じて PROFILE_ARN と KIRO_REGION を添える。3 つ目は kiro-cli や AWS SSO を使う場合で、KIRO_CREDS_FILE に SSO キャッシュの JSON を指す。この場合は PROFILE_ARN が不要だと README は明記している。どの方式でも PROXY_API_KEY を設定する。これは Kiro 側の資格情報ではなく、自分のゲートウェイを守るためのパスワードで、クライアントからは api_key として渡す。JSON のフォーマットは accessToken、refreshToken、expiresAt、profileArn、region、任意の clientIdHash というフィールド構成が例示されている。~/.aws/sso/cache/ にハッシュ名のファイルが併存する場合、kiro-auth-token.json を指定すればもう一方は自動で読み込まれると README は説明している。

マルチアカウントのフェイルオーバーと、その前提にある想定

機能表には Intelligent failover between multiple accounts とあり、複数アカウントの切り替えが謳われている。ただし README の本文で詳しく説明されているのは単一アカウントの設定方法までで、複数アカウントをどう登録し、どの条件で切り替わるのかという選定ロジックは、少なくとも提示された範囲の記述からは読み取れない。アカウントシステムの詳細は別節（Account System）に譲るという構成になっているため、評価するならそちらを読む必要がある。もう一点、VPN や制限されたネットワーク向けに HTTP/SOCKS5 プロキシの指定が用意されている。これは Kiro API への到達性が組織のネットワークポリシーで制限されている場合の逃げ道として機能する。ここから読み取れるのは、このツールが想定している利用者が、Kiro の資格情報を自分で管理できる個人か、それを許された開発者だという点だ。共有サーバーに 1 つのアカウントを載せてチーム全体に配る使い方を README は想定していない。

無料ティアのモデル一覧は固定ではない

README の冒頭には警告が置かれている。モデルの可用性は Kiro のティア（無料か有料か）に依存し、ゲートウェイは IDE や CLI で利用可能なモデルへのアクセスを提供するだけだという。つまりゲートウェイ側がモデルを追加しているわけではなく、上流の一覧をそのまま透過させる。具体的な変更として、Claude Opus 4.5 は 2026 年 1 月 17 日に無料ティアから外れたと書かれている。無料ティアで一般的に利用できるものとして挙げられているのは Claude Sonnet 4.5、Claude Haiku 4.5、Claude Sonnet 4、そして GLM-5、DeepSeek-V3.2、MiniMax M2.5、MiniMax M2.1、Qwen3-Coder-Next といったオープンな MoE モデル群だ。ここは採用判断で最も見落とされやすい。ゲートウェイのバージョンを固定しても、上流のモデル一覧は自分の与り知らないところで変わる。特定のモデル名に依存したワークフローを組むと、ある日そのモデルが無料ティアから消える。README がモデル一覧に Important と付けて警告しているのは、この性質を先に伝えるためだと読める。

LiteLLM との設計差はどこにあるか

同じ「複数の LLM を 1 つの API に束ねる」目的では LiteLLM が比較対象になる。両者は抽象化の方向が逆だ。LiteLLM は多数のプロバイダの API キーを設定ファイルに並べ、呼び出し側のモデル名からプロバイダを選ぶ汎用ルーターとして設計されている。kiro-gateway が扱う上流は Kiro API 系に限られ、その代わりに認証の取得、トークンの自動更新、モデル名の表記揺れ吸収、SSO キャッシュファイルの自動検出といった、Kiro 固有の面倒を引き受ける。汎用性を捨てて特定の上流に最適化した作りだと言える。したがって、複数の商用 API を 1 つの設定でまとめて予算管理したいなら LiteLLM のほうが素直に収まる。逆に、すでに Kiro の SSO が手元にあり、そこへの到達だけを OpenAI 互換に変換したいなら、プロバイダ抽象化の層を丸ごと持ち込む理由は薄い。どちらが優れているという話ではなく、抽象化する対象が違う。

AGPL-3.0 とメンテナンス負荷をどう見るか

ライセンスは AGPL-3.0。ネットワーク越しに利用させるソフトウェアにもソース提供の義務が及ぶ条項を含むライセンスで、社内ツールとして動かすだけなら影響は限定的だが、これを組み込んだサービスを外部に公開する形にするなら、ライセンス条件の確認が先に必要になる。ここは法務判断の領域なので、具体的な適合性は自分で確認してほしい。メンテナンス面では、直近のリリースが v2.1（Proxy & Enterprise）、v2.2（Containers & Recovery）、v2.3（Codex app & Errors）と短期間に並んでおり、開発は活発に見える。ただしこの活発さは同時に、追従コストが小さくないことを意味する。上流の Kiro API は Amazon 側の都合で変わり、無料ティアのモデル一覧も動く。ゲートウェイの更新を止めれば、いずれ認証更新かモデル解決のどちらかで壊れる。固定できるのはゲートウェイのバージョンだけで、上流は固定できない。この非対称性を運用前提として受け入れられるかが、採用の分かれ目になる。

編集部の結論

すでに Kiro IDE か kiro-cli でログイン済みで、Claude Code や Cline など既存クライアントの設定を変えずに同じ認証を使い回したい人に向く。逆に、複数人で共有する社内ゲートウェイや、Kiro のアカウント規約上プロキシ経由の利用が想定されていない環境には向かない。導入前に確認すべきは 3 点で、自分の Kiro ティアで実際に使えるモデル一覧、KIRO_CREDS_FILE が指す JSON に refreshToken と expiresAt が入っているか、そして AGPL-3.0 の下でこのコードを社内配布物に組み込むのかどうか。

公式情報源

1. Issues
2. jwadow/kiro-gateway on GitHub
3. License: AGPL-3.0
4. README
5. Releases