# Kimi K3の実務利用：実際に使ってみた体験とClaude Codeとの比較

> 速度、トークン使用量、キャッシュ、マルチエージェント環境との互換性：著者自身の経験と公開された独立ベンチマーク。

Source: https://ailoot.ai/blog/ja/kimi-k3-hands-on-review/
Canonical: https://ailoot.ai/blog/ja/kimi-k3-hands-on-review/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-163
Revision: sha256-444df96188044142afc4cdba4b2a4b5e2b143ed4d7c7ea2dc66d2d8f5ff702a9


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

7月25日のKimi K3レビューでは、実際に試すことが提案された。設定に1日かけて、見返りがあるか確かめようというものだ。私も自分で試した。ベンチマークでは、このモデルはフロントエンド作業で首位に立ち、ターミナルのタスクではClaudeを上回る。私のタスクでは作業速度が半分になり、トークン消費も目に見えて増え、複数エージェントでの作業にも支障が出た。

</div>

<div class="aside" data-semantic="ailoot-docs-link" role="note" aria-label="Ailoot documentation">

[Ailootのドキュメント](https://ailoot.ai/docs/)では、モデルの接続方法とAPIの利用方法を説明しています。

</div>

## 著者の実験はどうなったか

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

7月25日、私はKimi K3のレビューを公開し、締めくくりに、切り替える価値があるか確かめるため、調整に1日費やしてみようと提案した。その後、チャンネルにモデルを試していると書き、うれしい驚きを感じたと伝えた。最初の数時間は本当にそうだった。その後、複数エージェントを使った長時間の作業が続き、状況は変わった。

</div>

Kimi K3は2026年7月16日に公開された。パラメーター数は2.8兆、コンテキストウィンドウは100万トークンで、オープンウェイトを採用し、ブラインドのフロントエンド比較で首位に立った。アーキテクチャ、ベンチマーク、価格の詳細は[Kimi K3とClaude Codeの完全レビュー](https://ailoot.ai/blog/ja/kimi-k3-vs-claude-code/)にまとめたので、ここでは繰り返さない。

そのレビューの最後に、こう書いた。リスクは設定に1日費やすこと、見返りは2週目以降に請求額が下がることだ。私は自分のタスクで実験した。

最初の数時間は確かにわくわくする。モデルは意欲的にタスクに取り組み、筋の通ったフロントエンド作業を生成し、大きなファイルにもためらわない。だから私はチャンネルに、うれしい驚きを感じたと投稿した。問題が表面化したのは、長時間のセッション、複数エージェント、編集の反復、そして夜のターミナル作業だった。

結局、私は元に戻した。決断に至った経緯を、誰でも確認できるよう数値と一次情報へのリンクを添えて説明する。

## ベンチマークでKimi K3がClaudeを上回るのはなぜ？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

特定分野のベンチマークでは、Kimi K3は確かにClaudeを上回る。ターミナルのタスク、長期にわたるエンジニアリング作業、ブラインドのフロントエンド比較がそうだ。しかし、35件すべてのベンチマークを集計すると結果は異なる。Claude Fable 5が22勝、Kimi K3が12勝、引き分けが1件だ。どちらの見方も正しいが、前者のほうが引用されることが多い。

</div>

Kimi K3がClaude Fable 5を上回るベンチマークを以下に示す。

| ベンチマーク       | Kimi K3 | Claude Fable 5 | 差 |
|--------------------|---------|----------------|----|
| Terminal-Bench 2.1 | 88.3    | 84.6           | +3.7 |
| SWE-Marathon       | 42.0    | 35.0           | +7.0 |
| BrowseComp         | 91.2    | 88.0           | +3.2 |
| Program Bench      | 77.8    | 76.8           | +1.0 |

llm-statsがベンチマークを集計しており、すべての行でClaude Fable 5と比較している。

数値は実際のものだ。同じ集計に含まれる35件すべてのベンチマークでは、Claude Fable 5が22勝、Kimi K3が12勝、引き分けが1件だ。

さらに興味深いのは、Kimi K3が劣る分野だ。コーディングベンチマークでの差は小さく、4〜5ポイントだ。知識と推論では差が開く。HLEではClaudeがほぼ10ポイント先行する。長いタスクが行き詰まるのは、まさにこの部分だ。まず理解し、その後で初めて書ける。

Moonshotはリリース告知のメインセクションで、次のように述べている。

<figure>
<blockquote>
<p>全体では最も強力なクローズドモデルであるClaude Fable 5とGPT 5.6 Solにまだ及ばないものの、Kimi K3はベンチマーク一式全体で最先端の水準を示しました。</p>
</blockquote>
<figcaption>— Moonshot AI、https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

## 実際の作業でKimi K3が2倍遅く感じるのはなぜ？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Kimi K3はClaudeの2倍速く最初のトークンを返すが、その後のストリームは2倍遅く進む。短いチャットでは速く感じるが、作業タスクでは応答全体が届くまでに目に見えて時間がかかる。独立ベンチマークでは、毎秒34.7トークンで、Claude Opus 4.8の61.3トークンに対している。

</div>

| 指標                    | Kimi K3       | Claude Opus 4.8 |
|-------------------------|---------------|-----------------|
| 出力速度                | 34.7 tokens/s | 61.3 tokens/s   |
| 最初のトークンまでの時間 | 4.19 s        | 9.50 s          |
| 知能指数                | 57            | 56              |
| 100万トークンあたりの平均価格 | $2.31    | $3.85           |

数値は、Kimi K3とClaude Opus 4.8を比較したベンチマークに基づく。完全な速度計測があるClaudeのバージョンがこれだからだ。

Kimi K3は早く応答を始めるため、短いチャットでは主観的に速く感じる。実作業では別の点が重要になる。応答全体がどれだけゆっくり届くかだ。ここではほぼ半分の速度で、長い応答ではその差が数分に積み重なる。

Kimi Codeは毎秒180〜260トークンをうたっており、私の34.7と比べると説得力のある数字に見える。これは前世代の高速版、K2.7 Code HighSpeedの速度を指している。Kimi K3にはそのようなビルドはなく、独立ベンチマークが測定しているのもKimi K3そのものだ。

7回目のエラーでセッションが止まり、反復呼び出しでトークンを浪費するなら、それはコンテキストエンジニアリングの失敗だ。ここではモデル選択は二次的な問題にすぎない。完全なセットアップは3つの柱に支えられている。**AIクローン + セカンドブレイン + コンテキストエンジニアリング**。これはAIが幻覚を起こさないために欠かせない3つの柱だ。

## 推論をオフにできないなら、トークンはどこへ消えるのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Kimi K3の推論は完全にオフにすることができない。API経由でモデルを直接呼び出すと、デフォルトで最大の努力レベルが設定され、些細なリクエストも含め、あらゆるリクエストについて推論する。

</div>

努力レベルを下げることはでき、ドキュメントにはlow、high、maximumの3段階が記載されている。ただし、推論を完全にオフにはできない。Kimi K3では推論とその履歴の保存が常に有効だと明記されている。APIを直接呼び出す場合、デフォルトは最大レベルで、多くのラッパープログラムは変更しない。



各ターンで、100万トークンあたり$15の出力トークンが数千個追加される。さらにMoonshotは、推論履歴を含むアシスタントのメッセージ全体を返すよう求めており、それらの出力トークンは次のターンで再び入力トークンになる。

つまり、同じ推論に対して2回支払う。最初にモデルが書いたとき、次にそれをモデルに送り返したときだ。

全体指標では、Kimi K3の出力トークン数は前世代のK2.6より21%少ない。自社の前バージョンと比べれば、モデルは効率的になった。それでも同じタスクではClaudeのほうが少ない。

プロンプト「hi」は86トークンとして課金される。内部では約85トークンの非表示システムプロンプトが使われており、リクエストごとにその分も支払う。

利用量の計算方法や残高の確認先については、[Claude ProとMaxで使えるトークン数](https://ailoot.ai/blog/ja/claude-pro-max-usage-limits/)の別レビューで説明している。計算方法は同じで、価格だけが変わる。

## モデルが推論にはまり込むとどうなるか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

私の場合、Kimi K3は何度かループに入った。推論ブロックが同じ文章のかたまりを繰り返し始め、音節の断片へと崩れていく一方で、下位のエージェントは動かないままだった。私だけではない。Moonshot自身の既知の問題一覧にも、こうしたループの報告が複数ある。

</div>

実際にはこう見える。モデルは考え始めるが、思考を発展させず、同じ単語、次に音節の断片という具合に、テキストが延々と繰り返しに陥る。トークンカウンターが回り続ける一方で、タスクは止まる。

7月28日のMoonshot既知の問題に関する報告では、Kimi K3が同じファイルを6回連続で読み、前回の読み込み以降ファイルが変更されていないため「no-op call」として7回拒否された後、何事もなかったかのようにターンを終了したと説明している。Kimi CLIのissue trackerでは、報告者が読み取り、置換、テスト、分析という同種の停止を4種類挙げ、次の一文にまとめている。

<figure>
<blockquote>
<p>ファイルを何度読んでも、また読み続けてしまいます。置換に成功した後も、実行を続けてしまいます。こうしたデッドループで大量のトークンを消費しました。</p>
</blockquote>
<figcaption>— 開発者、Kimi CLI issue tracker、</figcaption>
</figure>

Moonshotは原因を明確に述べている。モデルは推論履歴を保持するモードで学習されており、過去の推論をすべて受け取る必要がある。履歴が不完全な状態で届くと、モデルは答えを再構築しようとして同じツール呼び出しを行い、再びループを始める。

サードパーティ製リクエストルーターでの分析の著者も同じ診断を示している。Kimiは推論履歴が不完全なリクエストを拒否するほど厳格だ。外部ラッパーはこの厳格さを把握していないため、履歴を切り詰めてしまう。

## Kimi K3でマルチエージェント環境が崩れるのはなぜ？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Claude CodeをMoonshot APIに接続すると、一部の機能が壊れる。WebFetchはまったくサポートされず、ツールの遅延読み込みではリクエストが400エラーになり、そうしたエラーが数回続くとセッションはプレーンテキストにも応答しなくなる。問題はClaude CodeとMoonshot APIの接続部分で起きる。

</div>

[Moonshotの公式ドキュメント](https://platform.kimi.ai/docs/guide/claude-code-kimi)には、同社のAPIはまだWebFetchをサポートしていないと明記されている。つまり、通常はページを取得するためオンラインに接続するClaude Codeも、Kimi K3ではそれができない。回避策は、内容を手作業で貼り付けるか、サードパーティのツールを接続することだ。

Claude Codeはツールをオンデマンドで読み込み、履歴に`tool_reference`型のサービスブロックを置く。Kimiはこの型を受け付けず、400を返す。フィールド名も理由も示さず、黙って失敗する。

```
{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}
```

比較のため、AnthropicのネイティブAPIで同じエラーがどう見えるかを示す。こちらは少なくともフィールド名と受け付ける型を列挙する。

```
messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'
```

この違いは重要だ。最初のメッセージからは原因を診断できない。クライアントにも、その背後にいる人にも、どのブロックが拒否されたのか分からない。報告者たちが問題にしているのはまさにこの点だ。プロバイダー切り替えツールの開発者は、Kimiではツールの遅延読み込みをデフォルトで無効にするか、Moonshot APIをこれらのブロックを受け付けないものとして指定することをすでに提案している。

その結果は、7月17日に立てられ、今も回答がない別の報告に記されている。報告者は1回のセッションでこのエラーに7回遭遇した。最初の6回はセッションが持ちこたえたが、7回目で完全に停止した。その後はプレーンテキストの「continue」と入力しただけでもクラッシュした。報告者は、コンテキスト上限にはまったく近づいていなかったと別途記しているため、「履歴が長すぎた」という説明は成り立たない。

Moonshot APIが受け付けるブロック型と拒否するブロック型を以下にまとめる。

| Claude Codeの動作          | Kimi K3での動作                         |
|----------------------------|------------------------------------------|
| 標準ツール呼び出し         | はい                                     |
| Web検索                    | はい                                     |
| WebFetchによるページ取得   | いいえ、APIがサポートしていない         |
| ツールの遅延読み込み       | いいえ、400エラーとセッション喪失のリスク |

ここでの「互換性」は、リクエスト形式だけを指す。それ以外はすべて異なる。受け付けられるブロック型、履歴に必要な内容、そして利用可能なツールの種類も違う。

## Kimi K3では何が引き継がれないのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

モデルを切り替えてもエンジンが変わるだけで、その周囲にあるラッパー全体、つまりClaude Code自体、ツール、サブエージェントはClaude向けのままだ。指示ファイル、スキル、サブエージェントはClaudeの振る舞いに合わせて書かれている。Moonshotは、互換性が実証されたラッパーを使い、セッション中にモデルを切り替えないよう明示的に勧めている。

</div>

リリース告知の制限事項のセクションには、次のとおり記されている。

<figure>
<blockquote>
<p>K3は推論履歴を保持するモードで学習されました。エージェントラッパーが必要とされる推論履歴全体を返さない場合、または別のモデルで開始したセッションをK3に切り替えた場合、生成品質が極めて不安定になることがあります。Kimi Codeのように互換性が実証されたラッパーを使い、セッションの途中でK3に切り替えることは避けるようお勧めします。</p>
</blockquote>
<figcaption>— Moonshot AI、limitations section、https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

モデルの開発元は、こう言っている。自社のクライアントを使ってほしい。他社のクライアントの振る舞いは保証しない。

同じセクションの2つ目の点では、私がモデルの頑固さだと思っていたことについて、さらに説明している。

<figure>
<blockquote>
<p>K3は、長く複雑なタスクを重視して学習されました。そのため、作業中に小さな矛盾やユーザーの意図が曖昧な点に直面すると、ユーザーに代わって予想外の判断を下すことがあります。</p>
</blockquote>
<figcaption>— Moonshot AI、limitations section、https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

私のCLAUDE.mdは反対の習慣に合わせて書かれていた。質問し、計画を示し、確認を待つというものだ。指示は今もそこにあるが、今は気質の異なるモデルがそれを読んでいる。

複数のエージェントで1つのルールファイルを使いたい場合は、[Claude Code、Codex、Cursor向けの共通指示ファイル](https://ailoot.ai/blog/ja/agents-md-claude-md-one-instruction-file/)で別途説明している。

## Kimi K3の実際の費用はいくらか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

トークン単価では、Kimi K3はClaudeのほぼ半額だ。だが、エージェントのワークフローではキャッシュのため単純な計算は崩れる。システムプロンプトやツール一覧を少しでも変えるとキャッシュが完全にリセットされ、入力トークンの価格が100万あたり30セントから$3に戻る。Claude Codeはこうした変更を日常的に、しかも頻繁に行う。

</div>

まず、Kimi K3に有利な価格を示す。

| 項目                       | Kimi K3 | Claude Opus 5 |
|----------------------------|---------|---------------|
| 100万あたりの入力          | $3.00   | $5.00         |
| キャッシュ利用時、100万あたりの入力 | $0.30 | $0.50 |
| 100万あたりの出力          | $15.00  | $25.00        |

Kimiの価格は[コンテキストキャッシュのドキュメント](https://platform.kimi.ai/docs/guide/use-context-caching-feature-of-kimi-api)に基づく。右列は2026年7月30日時点のClaude Opus 5の価格だ。

Kimiのキャッシュは自動で、無効化できず、リクエスト冒頭のハッシュによって識別される。システムプロンプトやツール一覧を編集すると、メッセージキャッシュが完全にクリアされる。

通常の作業日にClaude Codeが行うことを見てみよう。

1. タスクの進行に応じて外部ツールを接続したり切断したりする。
2. 必要に応じてツールをオンデマンドで読み込む。
3. 異なるツールセットでサブエージェントを起動する。
4. 指示ファイルをシステムプロンプトに追加する。
5. コンテキストを圧縮するときに履歴を再構築する。

この一覧の各項目によってリクエストの冒頭がリセットされ、キャッシュも消える。入力トークンは100万あたり30セントではなく、再び$3になる。10倍の価格だ。さらに、出力トークン100万あたり$15で推論が続き、同じトークンが次のターンで入力として戻ってくる。そのため、表示価格の低いモデルでも、予想外の請求額になり得る。

[OpenCodeの集計データ](https://opencode.ai/data/moonshot/kimi-k3)によると、約280,000件の実稼働セッション全体で、Kimi K3の平均セッション費用は$1.86、平均トークン量は3.1 millionだ。この数値は入力トークンの93%がキャッシュに当たることを前提としている。リクエストの冒頭を変えれば、この数値は当てはまらなくなる。

Kimiのプランは$19、$39、$99、$199だ。利用枠は会員全体で共有するプールから割り当てられ、未使用分を繰り越さずに毎週リセットされ、ローリング方式の5時間枠を使う。プランレビューでは、推論が常時有効なKimi K3を4つのターミナルで動かすと、5時間枠はすぐに使い切られると説明している。

$99プランのコーディング利用枠はAnthropicの$200プランに匹敵し、これは私自身の見解とは相容れない。Kimiはトークン単価では安いが、夜の請求額にはもうその安さが見えない。

## Kimi K3が客観的に得意なのはどこか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Kimi K3は、明確に定義された大きな仕事を1つこなす場面に強い。フロントエンド作業、大規模なコードのリファクタリング、長いファイルの処理、大規模なリポジトリの分析だ。ブラインドのフロントエンド比較で首位に立ったのは妥当で、こうしたタスクを任せるのも理にかなっている。以下に、長所を5つ挙げる。

</div>

1.  **フロントエンド。** 現役の開発者によるブラインド比較で首位。整ったレイアウトを、なかなかのセンスで作る。
2.  **処理量。** コンテキストウィンドウは100万トークンで、長いファイルにもひるまない。大規模なリポジトリを分析し、全体像を描くのは得意なタスクだ。
3.  **初回応答。** 最初のトークンまでの時間はClaudeの半分。短い会話では、その差がはっきりと心地よく感じられる。
4.  **トークン単価。** Claude Opus 5の価格の約60%。リクエストの冒頭が変わらなければ、大量の反復作業で実際に節約できる。
5.  **オープンウェイト。** 1つのプロバイダーに縛られない。

最後の点には注意点がある。この規模のモデルを自宅で動かすのは現実的ではない。圧縮しても、ウェイトの容量はテラバイト単位になる。ここでのオープン性は、単一プロバイダーに依存しないことを意味する。

## 一晩でこれらを自分で試す方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Kimi K3は、普段のタスクで試す必要がある。短いチャットでは差が表れない。測るのは2つ。かかった時間と、その夜の費用だ。以下に順番どおり7つの手順を示す。モデル自体の問題と、その周囲にあるラッパーの問題を混同しないためだ。

</div>

1.  **説明に従ってアクセスを設定する。** 3つの環境変数と、階層ごとのモデル置換については[Kimi K3とClaude Codeのレビュー](https://ailoot.ai/blog/ja/kimi-k3-vs-claude-code/)で説明した。`/status`コマンドで設定を確認する。Kimiはモデル選択メニューに表示されない。エイリアス一覧が組み込み式で、変更する必要はないためだ。
2.  **古いキーを削除する。** 以前に`ANTHROPIC_API_KEY`を設定していた場合は削除する。`ANTHROPIC_AUTH_TOKEN`と併用すると競合し、理由もなく認証エラーになる。
3.  **ツールの遅延読み込みをすぐにオフにする。** 最初の実行前に行う。最初のセッションが停止してからでは遅い。
4.  **タスクの途中でモデルを切り替えない。** Kimi K3で始めたら、最後までKimi K3で進める。逆の場合も同じだ。これはMoonshotの直接的な要件で、上で引用した。
5.  **自分の実タスクを使う。** 昨日取り組んだ、混乱や未完了の作業がそのまま残るものを選ぶ。スネークゲームでは違いが見えない。差は長時間使って初めて現れる。
6.  **2つの数値を記録する。** 何分かかったか、そしてその夜にいくら使ったか。Claudeで過ごす普段の夜と比べる。
7.  **待ち時間は別に記録する。** エージェントが停止したり、同じファイルをループで読んだり、エラーを返したりする時間も、コストの一部だ。

夜の請求額が予想より高ければ、ほとんどの場合はキャッシュが原因だ。その夜にリクエストの冒頭が何回リセットされたか数えてみよう。トークン単価はあまり関係ない。

## 最終的に残した構成

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

重要なポイント

Kimi K3はClaude Codeを完全には置き換えず、私は無理にそうしなかった。長いタスクやマルチエージェント環境では、Claude Codeをメインエンジンとして使い続けた。Kimi K3は、反復的なレイアウト作業が多く、ひとまとまりで任せられるタスク向けの第2エンジンとして併用している。分け目は、タスクに含まれる切り替えの回数だ。

</div>

チャンネルで一緒にモデルを試した読者も、独自に同じ構成にたどり着いた。Kimi K3にはリポジトリを調べてセカンドオピニオンを出させ、メインの作業は使い慣れたエージェントに任せる。この構成ならラッパーを移行する必要も、すでに動いているものを壊す必要もない。

こう言い換えられる。完結したタスク1つならKimi K3へ。ツールやサブエージェントを使う長い連鎖ならClaude Codeへ。タスク内でツールを切り替える回数が多いほど、Kimi K3のコストは上がり、セッションが壊れる可能性も高まる。

2つのエージェントに役割を割り当て、混同しない方法については、[2つのエージェントを使う3つの方法](https://ailoot.ai/blog/ja/claude-code-codex-together/)で別途説明している。

ベンチマークが答えるのは「実験室の条件ではどちらが強いか」という問いだ。その夜の請求額と完了した作業の一覧が答えるのは「あなたにとってどちらが強いか」という問いだ。答えが異なるなら、後者を信じよう。マーケティング部門ではなく、自分で計算した結果だからだ。

すべてを見たうえで、私は自分なりに結論を出した。新しいモデルについて何と言われようと、リーダーはやはりリーダーだ。Claude Codeは引き続き私のメインエンジンだ。

<div class="section" role="doc-bibliography" aria-label="Sources">

### 出典

- [Kimi K3、公式リリース告知と制限事項のセクション](https://www.kimi.com/blog/kimi-k3) - Moonshot AI
- [Claude Code経由で利用するためのKimiドキュメント](https://platform.kimi.ai/docs/guide/claude-code-kimi) - 環境変数、WebFetch非対応
- [コンテキストキャッシュに関するKimiドキュメント](https://platform.kimi.ai/docs/guide/use-context-caching-feature-of-kimi-api) - キャッシュの仕組みと価格
- [K3の実稼働エージェントセッションに関する統計](https://opencode.ai/data/moonshot/kimi-k3) - OpenCode

</div>

完全なバイブコーディング構成：**AIクローン + セカンドブレイン + コンテキストエンジニアリング**。



<div class="aside" data-semantic="ailoot-link" role="note" aria-label="Ailoot">

[Ailoot](https://ailoot.ai/)でAIを使った作業を続けられます。

</div>

## Kimi K3の実務利用：実際に使ってみた体験とClaude Codeとの比較：よくある質問

### 最初のトークンが速ければ、Kimiの開発タスク全体も速いですか？

いいえ。最初の応答までの遅延と、その後の生成速度は別の計測値です。出だしだけでなく、ツール操作、再試行、確認を含むタスク完了までの時間を測ってください。

### Kimiが自分の作業に合うか、どう試しますか？

現在の環境と同じ開始ファイルと合格条件で、代表的なタスクを1つ実行します。総時間、トークン利用量、成果を記録し、長いセッションで頼る前に、マルチエージェントの流れも別にテストしてください。


## Ailoot · 企業とそのプロジェクト群

Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。

企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。

Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。