0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Moonshot AI の Kimi K3 API を自作プロダクトに組み込んで実際に動かした

0
Posted at

Moonshot AI の中の人から突然、日本語に機械翻訳したメールが届きました。私が Qiita に公開している記事を読んだとのことで、Kimi K3 を試してみてほしいという内容でした。

それまで Moonshot AI と直接の接点はありませんでしたが、英語で何度かメールをやり取りしているうちに、Kimi K3 の API を試すためのバウチャーコードを提供してもらいました。API クレジットの提供は受けましたが、記事を書く約束はしておらず、内容の指定も受けていません。

せっかく API を使えるので、チャット画面で試して終わるのではなく、自分で公開しているプロダクトへ実際に組み込み、API の動作まで確認することにしました。

Kimi API は OpenAI API 形式との互換性を公式に掲げており、主な生成 API として Chat Completions を提供しています[1]。今回確認したかったのは、既存の OpenAI 互換 API 対応をどこまでそのまま利用できるのか、そして Kimi 固有の実装が必要になるのはどこからか、という点です。

自分のプロダクトに Kimi K3 を組み込む

今回確認したプロダクトは次の 5 つです。

プロダクト 既存設計で Kimi K3 を利用できたか 今回の対応
ai-digest できた openai-compatible の設定を利用
sizu-writer できた openai-compatible の設定を利用
reply-writer できた 既存設定で Kimi K3 用パラメーターを指定
automaticruby できなかった FilterKimi を追加
web-digest できなかった Kimi を第 4 の AI プロバイダーとして追加

結果は二つに分かれました。

API の接続先とモデルを設定として外出しし、通信方式を openai-compatible として扱っていたプロダクトは、Kimi 専用コードを追加せずに利用できました。一方、利用するサービスをプラグインやプロバイダーとして明示する構造では、Kimi を新しい実装単位として追加する必要がありました。

いくつかは既定の設計で対応済みだった

ai-digest

ai-digest は、生成 API の通信方式を anthropic-compatibleopenai-compatible に分けています。Kimi K3 は既存の openai-compatible をそのまま利用できます。

SUMMARIZER_BACKEND=openai-compatible
SUMMARIZER_API_KEY=<Kimi API key>
SUMMARIZER_BASE_URL=https://api.moonshot.ai/v1
SUMMARIZER_MODEL=kimi-k3

Kimi 専用バックエンドは追加していません。既存のプロンプト、build_report のツール呼び出しスキーマ、応答検証を変えず、接続先とモデルだけを Kimi K3 にしています。

この構造では、ベンダー名ではなく通信方式を境界にしていたことが、そのまま Kimi K3 対応になりました。

sizu-writer

sizu-writer も、接続する API を設定で指定する構造です。

GENERATION_BACKEND=openai-compatible
GENERATION_API_TOKEN=<Kimi API key>
GENERATION_BASE_URL=https://api.moonshot.ai/v1
GENERATION_MODEL=kimi-k3
GENERATION_RESPONSE_MODE=prompt-json
GENERATION_TEMPERATURE=

ここでも Kimi 固有の Python コードは追加していません。

GENERATION_BASE_URL/chat/completions の直前までを指定し、実際のリソースパスは OpenAI 互換クライアント側に任せます。Kimi K3 の応答に reasoning_content が含まれても、それを表示、保存、ログ出力する処理は追加していません。

reply-writer

reply-writer も同じ openai-compatible の経路を利用できます。ただし、出力トークン数を渡すパラメーターは明示的に切り替えています。

GENERATION_BACKEND=openai-compatible
GENERATION_API_TOKEN=<Kimi API key>
GENERATION_BASE_URL=https://api.moonshot.ai/v1
GENERATION_MODEL=kimi-k3
GENERATION_RESPONSE_MODE=prompt-json
GENERATION_TEMPERATURE=
GENERATION_OUTPUT_TOKEN_PARAMETER=max_completion_tokens

reply-writer では GENERATION_OUTPUT_TOKEN_PARAMETER=max_completion_tokens を指定し、既存の設定項目でその差を吸収しています。

ここでも「Kimi だから」というホスト名やモデル名の条件分岐は追加していません。

Kimi 用の実装を追加した

automaticruby に FilterKimi を追加した

automaticruby は、外部サービスとの接続をプラグインとして明示する構造です。OpenAI、Claude、Gemini、さくらの AI Engine はそれぞれ別のフィルターとして存在します。

そこで Kimi も FilterKimi として追加しました[2]

Recipe からは次のように指定します。

- module: FilterKimi
  config:
    token: YOUR_KIMI_API_KEY
    model: kimi-k3
    prompt: |
      以下の記事群について、個別記事の要約を羅列するのではなく、
      全体を一つのダイジェストとして日本語で要約してください。
    retry: 2
    interval: 2

送信先は Kimi API の Chat Completions です。

POST https://api.moonshot.ai/v1/chat/completions
Authorization: Bearer <Kimi API key>
Content-Type: application/json

要求本文には、モデル名、system メッセージ、user メッセージだけを入れます。Kimi の応答に reasoning_content が含まれる場合でも、それは処理対象にせず、正常終了時の content だけを次のパイプラインへ渡します。

OpenAI 互換であっても FilterOpenAI の設定違いにはしませんでした。Recipe を見れば、どのサービスへ文章を送信するかが分かることを優先したためです。

web-digest に Kimi を第 4 のプロバイダーとして追加した

web-digest は、Web ページから本文を抽出し、AI で要約して Chrome の Side Panel に表示する拡張機能です。原典を書いた 2026 年 8 月時点では、さくらの AI Engine のみに対応していましたが、本文抽出、長文分割、表示処理と API 接続処理は分離していました[3]

その後 OpenAI と Claude を追加し、今回はさらに Kimi を第 4 の AI プロバイダーとして追加しました[4]

主な変更範囲は次のとおりです。

  • src/engine/kimi.js の追加
  • dispatcher への Kimi の追加
  • Kimi 用 API 認証情報とモデルの保存
  • https://api.moonshot.ai/* の任意ホスト権限の追加
  • 設定画面への Kimi の追加
  • Kimi 用のエラー変換
  • Kimi 専用テストの追加

Chrome 拡張では、単に接続 URL を変えるだけでは足りません。外部オリジンへの通信権限も拡張機能の権限として宣言する必要があります。

Kimi を選択したときだけ https://api.moonshot.ai/* の権限を要求し、Sakura AI Engine、OpenAI、Claude の認証情報とモデルはそれぞれ独立して保持します。既存の Sakura AI Engine を既定値とする挙動も変更していません。

試験した内容

実装後の確認は、自動試験と実 API 動作試験を分けました。

自動試験

web-digest は次のコマンドでテスト一式を実行します。

npm test

Kimi 専用テストでは、少なくとも次を確認しています。

  • https://api.moonshot.ai/v1/chat/completions へ要求すること
  • Bearer 認証を利用すること
  • API キーが要求本文へ混入しないこと
  • systemuser のメッセージを意図した形で送ること
  • reasoning_content を要約本文として採用しないこと
  • finish_reasonstop の場合だけ正常終了として扱うこと
  • 401、429、5xx などを同じ失敗として扱わないこと
  • 入力長超過とその他の 400 系エラーを混同しないこと

automaticruby ではプラグイン単位の RSpec を追加し、次のように実行できます。

bundle exec rake spec:plugins

こちらでは、HTTPS と証明書検証、送信先、Bearer 認証、要求本文、応答反映、再試行、401 時の停止、失敗時に元の description を破壊しないことなどを確認しています。

実 API 動作試験

自動試験はネットワークへ接続せず、要求と応答を差し替えて検証しています。これとは別に、Moonshot AI から提供されたバウチャーの API クレジットを使い、実際の Kimi K3 API へ要求を送る動作試験も行いました。

今回確認したのは次の範囲です。

  1. API キーによる認証が成立すること
  2. https://api.moonshot.ai/v1 から kimi-k3 を呼び出せること
  3. 自分の実装から Chat Completions の要求を送信できること
  4. Kimi K3 から正常な応答が返ること
  5. 返された内容を既存プロダクトの処理へ渡せること

性能比較やベンチマークは今回の対象にしていません。まず「組み込めるか」「実 API で動くか」を確認しています。

Moonshot AI の Kimi K3 を使うメリット

Kimi K3 を API から直接利用できる

Kimi K3 は Moonshot AI が 2026 年 7 月に公開したモデルで、2.8 兆パラメーター、ネイティブな画像理解、最大 100 万トークンのコンテキストを特徴としています[5]

今回の用途では画像入力は使っていませんが、web-digestai-digest のように長い文書や複数の記事を扱う処理では、大きなコンテキストを利用できる余地があります。

OpenAI 互換 API を既存コードから利用できる

今回もっとも直接確認できたメリットです。

Kimi API が OpenAI API 形式と互換であるため[1]ai-digestsizu-writerreply-writer では Kimi 専用クライアントを追加せずに接続できました。

一方で、サービス名を明示すること自体が設計上の意味を持つ automaticrubyweb-digest では独立実装にしています。互換 API を使えることと、すべてのプロダクトで一つのアダプターに統合すべきことは別です。

API の入力と出力を学習に利用しない方針が明示されている

Moonshot AI は、Kimi API に送信した入力とモデルの出力を Kimi モデルの学習や改善には利用しないと説明しています[6]。API 通信には HTTPS/TLS を使用し、利用者間のデータ分離も示しています。

外部 API を使う以上、入力を Moonshot AI へ送信すること自体は避けられません。それでも、API データの利用目的が公式に明示されていることは、接続先を選ぶ際の判断材料になります。

長い入力を扱える

Kimi K3 は最大 100 万トークンのコンテキストを特徴としており[5]、長い入力を扱えること自体が API 利用時の選択肢になります。

長文を扱えることは、長い入力を毎回そのまま送るべきという意味ではありません。既存の分割や圧縮を残しつつ、必要な場面で大きなコンテキストを使える選択肢が増えた、と捉えています。

Kimi K3 を使うリスク

日本からの API 利用は安定性が保証されていない

Moonshot AI の公式 FAQ では、Kimi API は主として中国本土の利用者を対象としており、海外からのアクセスはネットワーク条件の影響を受ける可能性があり、安定性を完全には保証できないと説明しています[7]

今回、日本から実 API を呼び出して正常に利用できたことは確認しました。ただし、今回の疎通成功は、日本から継続運用した場合の可用性を保証するものではありません。

常時稼働する処理や応答時間を保証するサービスへ組み込む場合は、ここを別途評価する必要があります。

入力データの送信先が Moonshot AI に変わる

Kimi API を使うと、生成対象の入力は Moonshot AI の API へ送信されます。API データを学習に利用しない方針[6]と、外部事業者へ入力を送信することは別の論点です。

今回の各プロダクトでは、送信対象がおおむね次のように変わります。

プロダクト Kimi 利用時に Moonshot AI へ送る主な内容
web-digest 開いている Web ページから抽出した本文
automaticruby フィードや記事の description
ai-digest 収集した論文やニュースの要約対象
sizu-writer 入力した文章や思いつき
reply-writer 受信メッセージと返信方針

特に reply-writer のように私的なメッセージを扱えるプロダクトでは、利用前に送信先を確認する必要があります。

API の利用量、残高、レート制限に依存する

Kimi API は Web 版の Kimi とは別の課金体系です。API 側で残高が不足すると 403、要求頻度が上限を超えると 429 が返ります[7]

今回のような少量の動作試験と、定期バッチや多数の利用者から呼ばれる運用では条件が違います。

長文を処理できることは入力トークンを増やせることでもあるため、運用時には利用量と料金を同時に見る必要があります。

OpenAI 互換でも完全に同じ挙動ではない

今回の実装でも、max_completion_tokensreasoning_contentresponse_format、thinking、tool choice など、既存の OpenAI 系 API と同一だと仮定できない部分がありました。

OpenAI 互換 API であることは接続コストを下げますが、利用するモデルとエンドポイントの仕様確認までは不要になりません。

影響範囲

Kimi K3 を選んだ場合に変わるのは、生成結果だけではありません。

観点 影響
生成結果 要約、文章生成、返信案などが Kimi K3 の出力になる
データ送信先 対象データが Moonshot AI の API へ送信される
可用性 Moonshot AI 側の API と、日本から同 API までの通信状態に依存する
費用 Kimi API の利用量と残高を消費する
運用 API キー、残高、429、モデル名や API 仕様変更を管理する必要がある

今回の実装では、Kimi を選択または設定しない既存経路には影響を与えないようにしています。

web-digest では既定の Sakura AI Engine を変更せず、OpenAI、Claude、Kimi の認証情報とモデルを別々に保持しています。automaticruby でも既存の FilterOpenAIFilterSakuraAI は変更せず、FilterKimi を新しい選択肢として追加しています。

Kimi K3 を利用可能にすることと、既存の処理を Kimi K3 へ自動的に移行することは分けています。

おわりに

今回のきっかけは、Moonshot AI の中の人から突然届いた「Qiita を読んだ」というメールでした。何度かやり取りした結果、Kimi K3 の API を試すためのバウチャーコードを提供してもらい、その API クレジットを実際の実装と動作試験に使いました。

結果として、既存の OpenAI 互換 API 対応だけで Kimi K3 を利用できたプロダクトと、Kimi を独立したプラグインやプロバイダーとして追加したプロダクトの両方がありました。

Kimi K3 の性能そのものを他モデルと比較した記事ではありません。今回確認したのは、Moonshot AI の API を自分のプロダクトへ組み込み、実際の API まで通したときに何がそのまま使え、何を追加する必要があり、採用するとどのデータと運用条件に影響するかです。

バウチャーコードを受け取って管理画面を眺めるだけでは分からなかったところまで、実装して実際に動かしたことで確認できました。いままで記事を書くことで日本人や米国人からフィードバックを得ることはありましたが、中国人とメールをやりとりできたことは良い経験になりました。

参考文献

  1. Moonshot AI, Kimi API Product Overview and Quick Start. https://www.kimi.com/en/help/kimi-api/api-overview
  2. id774, automaticruby. https://github.com/id774/automaticruby
  3. id774, 長い Web ページを構造に沿って要約する Chrome 拡張 web-digest を作った(2026-08-17). https://blog.id774.net/entry/2026/08/17/5517/
  4. id774, web-digest. https://github.com/id774/web-digest
  5. Moonshot AI, Kimi K3 Tech Blog: Open Frontier Intelligence. https://www.kimi.com/en/blog/kimi-k3
  6. Moonshot AI, Kimi API Data Security and Privacy Protection. https://www.kimi.com/en/help/kimi-api/api-data-security
  7. Moonshot AI, Kimi API FAQs and Troubleshooting. https://www.kimi.com/en/help/kimi-api/api-troubleshooting
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?