はじめに 検索基盤チームの mrkm4ntr です。以前、 CPU 使用率による Elasticsearch の autoscaling について書きました。ピーク時間帯に合わせて確保していたリソースを、トラフィックに合わせて増減することで、Elasticsearch のコストを約 40% 削減できました。 この autoscaling には、まだコストを削る余地が残っていました。この記事では、そのために行った 2 つの改善を紹介します。 scale-out の高速化 : shard のコピー待ちをなくすために、PVC に shard を事前に同期しておく仕組みを作りました。 HPA の tolerance の調整 : 1 のおかげで HPA の CPU threshold を高くできるようになった結果、tolerance が新しい問題になりました。これを HPA ごとの設定と CronJob で解消しました。 課題 scale-out が間に合わない Elasticsearch のノードを増やすと、新しいノードには他のノードから shard が複製されます。これが Peer Recovery で、大きく 2 つのステップに分かれます。 ファイルコピー : primaryが持つ segment ファイルを、ネットワーク越しに新しいノードへ丸ごとコピーします。 差分の追い付き : コピーしている間にも更新は続くので、その間に発生した変更を translog から再生して追い付きます。 時間がかかるのはほとんどが 1 です。私たちのクラスタは 1 shard が大きく、コピーが終わるまで 10 分以上かかります。その間、新しいノードは検索を処理できません。 threshold を下げて凌いでいた HPA は、負荷が上がったことを検知してから台数を増やします。ノードが使えるようになるまで 10 分以上待つことになると、急なトラフィック増には間に合いません。 そこで、HPA の CPU 使用率の threshold をあえて 65% 前後と低めに設定し、まだ余裕があるうちに早めに scale-out を始めるようにしていました。scale-out の遅さを、平常時の余裕で補っていたことになります。 安全ではありますが、その余裕のぶん、autoscaling で得られるコスト削減は小さくなります。 改善 1: PVC 事前同期で scale-out を高速化する アイデア Peer Recovery が遅いのは、新しいノードのディスクにデータがなく、ステップ 1 のファイルコピーが避けられないからです。それなら、あらかじめデータを持ったディスクを用意しておけばよいはずです。 そこで Replicator という Pod を常駐させます。Replicator は次のような役割の Pod です。 通常のノードと同じように shard の replica を持ち、PVC にデータを同期し続ける。 検索リクエストは受けない。 scale-out するときは、Replicator を通常ノードに昇格させます。PVC にはすでに shard の実体があるので、ファイルコピーは不要です。起動後は、同期が止まっていた間の更新を取り込むだけの Local Recovery で済みます。 回復方法 ファイルコピー 差分の追い付き Peer Recovery（従来） 必要（shard 全量） 必要 Local Recovery（今回） 不要 必要 Replicator の数は shard 数と同じです。各 Replicator が、ちょうど 1 つの shard を持つ構成（1 ノードあたり 1 shard）を前提にしています。つまり Replicator 全体で、インデックスの全 shard を 1 セット余分に持ち、いつでも通常ノードに昇格できる状態で待機することになります。 ただし通常ノードより小さいリソースで動かすので、常駐させるコストは抑えられます。ところが、この「小さいリソースで動かす」という点で、Kubernetes の制約にぶつかります。 壁: StatefulSet の Pod は全部同じサイズ 通常ノードと同じサイズで Replicator を常駐させてしまうと、インデックスのコピー 1 セット分のリソースを丸ごと余分に確保することになり、コスト削減になりません。Replicator は検索を処理しないので、本来 CPU も memory も少なくて済みます。 ところが、Elasticsearch を StatefulSet で動かしていると、これが簡単ではありません。StatefulSet 配下の Pod は、すべて同じ Pod テンプレートから作られるため、サイズも同じになります。Replicator だけ小さくする方法がありません。別の StatefulSet に分ける方法もありますが、PVC の名前が StatefulSet ごとに決まるため、昇格のたびに PVC の付け替えが必要になります。 そこで、Replicator と通常ノードを 同じ StatefulSet に置いたまま 、Pod の作成時に MutatingWebhook でサイズを書き換えることにしました。StatefulSet のテンプレートは通常ノードのサイズのままで、特定の Pod だけ、作られる瞬間に Replicator 用の設定に差し替えます。 アーキテクチャ StatefulSet の Pod には、 es-data-0 、 es-data-1 、… のように、名前の末尾に 0 からの連番が付きます（この番号を ordinal と呼びます）。この番号を使って、通常ノードと Replicator を見分けます。 shard が 12 個で、1 ノードに 1 shard の構成を例にします。 es-data-0 〜 es-data-11 : 通常ノード（各 1 shard） es-data-12 〜 es-data-23 : Replicator（各 1 shard の replica） StatefulSet の replicas は 24 になります。番号が小さい方から通常ノード、それ以降が Replicator、という分け方です。 【図 1: 定常状態。通常ノード 12 台と Replicator 12 台が同じ StatefulSet に並び、それぞれ PVC を持つ】 Webhook は、Pod の番号が通常ノードの台数以上であれば、その Pod を Replicator として次のように書き換えます。 対象 変更内容 ラベル Replicator であることを示す role ラベルを付与 リソース Elasticsearch コンテナと、ECK が注入する initContainer の request / limit を縮小 ES_JAVA_OPTS heap サイズを、縮小した memory に合わせて再計算 ノード属性 検索から除外する属性を付与 initContainer のリソースも書き換えているのは、Pod 全体の実効的な request が、initContainer の request の影響も受けるためです。ここを残すと、Pod のサイズが小さくならないことがあります。 通常ノードの台数は、controller が ScalableElasticsearchNodeSet に記録し、Webhook はそれを見て境界を判断します。HPA が指定する台数と、実際の通常ノード数は、shard 数との兼ね合いで切り上げられてずれることがあるためです。 Replicator に配置される shard と、検索の除外については、Elasticsearch 側にも手を入れています。 shard の配置（plugin） : Pod 名の末尾の番号から、どの shard を持つかが決まるようにする plugin を作りました（番号を shard 数で割った余りが shard ID です）。たとえば es-data-12 は shard 0 を持ちます。これにより、各 Replicator は必ず 1 つの shard を持ち、他の Replicator と重複しません。 検索の除外（patch） : 検索リクエストの宛先から、先ほどのノード属性を持つノードを外すよう、Elasticsearch 本体にパッチを当てています。 昇格・降格のフロー scale-out（通常ノード 12 台 → 24 台） controller が、通常ノードの台数を 24 に更新する。 es-data-12 〜 es-data-23 の Replicator の Pod を削除する。 StatefulSet が Pod を再作成する。このとき Webhook は、通常ノードの設定（元の大きなサイズ）を適用する。 PVC には shard のデータが残っているので、Local Recovery だけで検索を受けられるようになる。 続いて、StatefulSet の replicas を 24 から 36 に増やす。新しく作られる es-data-24 〜 es-data-35 は、新しい Replicator として起動する。 index の replica 数を増やす。 この順序は入れ替えられません。先に replicas を増やしてしまうと、新しい Pod が古い台数の情報を読んでしまい、Webhook が誤った設定を適用します。 新しい Replicator は Peer Recovery でデータを全量コピーしますが、検索を受けないので、新しい Replicator のコピー完了を待たずに、昇格した通常ノードで検索を提供できます。コピーの待ち時間が、検索を受ける経路から外れたことになります。 ノードに空きがない場合 昇格のときは、Pod を大きなサイズで作り直します。元のノードに空きがあれば、同じノードにそのまま再作成されます。空きがなければ、別のノードに Pod がスケジュールされ、Kubernetes の Attach/Detach controller が PV を新しいノードに付け替えます 。 どちらの場合も、shard のコピーは発生しません。コピーされるのではなく、PV そのものが移動します。PV の detach から attach までにかかる時間は 1 分程度で、shard を丸ごとコピーするのに比べれば、はるかに短く済みます。 scale-in（通常ノード 24 台 → 12 台） scale-out の逆の順序で戻します。 index の replica 数を減らし、shard の再配置が終わるのを待つ。 通常ノードの台数を 12 に更新する。 es-data-12 〜 es-data-23 の Pod を削除する。再作成されるとき、Webhook は Replicator の設定（小さなサイズ）を適用する。 StatefulSet の replicas を 36 から 24 に減らし、 es-data-24 〜 es-data-35 を削除する。 降格した Pod は、PVC のデータを持ったまま Replicator になります。そのため、次の scale-out に向けた準備が、そのまま整った状態になります。 HPA との連携 HPA は、 ScalableElasticsearchNodeSet の scale subresource を見て、台数と CPU 使用率を判断します。Replicator は検索を受けず、リソースのサイズも通常ノードとは違うので、これを一緒に数えたり平均に混ぜたりすると、scale の判断が狂います。 そこで、HPA に見せる値からは Replicator を除きます。 台数（ status.count ）と ready な台数（ status.readyCount ）から、Replicator を引く。 Pod を選択するセレクタに、Replicator ではないことを条件として加える。 これで、HPA は通常ノードだけを見て判断できます。 改善 2: HPA の tolerance をピークに合わせて切り替える threshold を上げると tolerance が効いてくる 改善 1 で scale-out の待ち時間が短くなったので、HPA の CPU 使用率の threshold を、65% 前後から 80% 前後まで引き上げられるようになりました。threshold を上げれば、同じトラフィックを少ない台数でさばけます。 ところが、threshold を上げると、新しい問題が出てきました。HPA の tolerance です。 HPA は、現在の指標が target に対してどれだけ離れているかを比で計算し、その比が 1 ± tolerance の範囲内であれば、何もしません。小さな変動のたびに台数が増減するのを防ぐための仕組みで、デフォルトは 0.1（10%）です。 target が 65% のとき、scale-out が始まるのは、約 71.5% を超えたときです。target との差は 6.5 ポイントです。target が 80% のときは、88% を超えるまで scale-out しません。差は 8 ポイントで、target を上げるほど、tolerance が作る不感帯の幅（ポイント換算）は広がります。scale-in も同様に、72% を下回るまで起きません。 さらに、HPA には stabilizationWindow があります。短時間の揺れで台数が増減しないよう、一定期間の推奨台数を見てから判断する仕組みです。私たちはスラッシング防止のために、もともとこの窓を設けていました。tolerance を超えてからさらにこの窓の分だけ待つことになり、遅れが二重に積み重なります。threshold を上げて余裕を削ったぶん、この遅れの影響が大きくなりました。 かといって、tolerance や窓を単純に小さくすると、今度は台数が頻繁に増減するスラッシングが起きます。私たちが絶対に避けたいのはこれで、台数が増減するたびに shard の再配置や昇格・降格が走るためです。 HPA ごと・方向ごとに tolerance を設定できるようになった tolerance は、以前は kube-controller-manager の --horizontal-pod-autoscaler-tolerance フラグで指定する、クラスタ全体に一律の値でした。特定の HPA だけ変える方法がありません。 これが KEP-4951 で変わりました。 HPAConfigurableTolerance という feature gate として Kubernetes v1.33 で alpha、v1.35 で beta となり、v1.37 で GA になっています。 これにより、HPA の spec.behavior.scaleUp.tolerance と spec.behavior.scaleDown.tolerance で、HPA ごと、さらに scale-out と scale-in の方向ごとに tolerance を指定できます。beta になった v1.35 以降であれば、デフォルトで有効です。 CronJob で切り替える 反応の速さとスラッシングの回避は、一律の設定では両立しません。そこで、トラフィックの向きに合わせて、tolerance と stabilizationWindow を 1 日のなかで切り替えることにしました。 トラフィックには、ピークに向かって上昇する時間帯と、ピークを過ぎて下降する時間帯があります。考え方は、 今のトレンドと逆向きの操作を抑える ことです。 ピークに向かう間 : scale-out はしやすくする（ scaleUp.tolerance を小さく、 scaleUp.stabilizationWindowSeconds を短く）。scale-in はしにくくする（ scaleDown.tolerance を大きく、 scaleDown.stabilizationWindowSeconds を長く）。上昇中に scale-in すると、すぐに scale-out が必要になるため。 ピークを過ぎた後 : scale-in はしやすくする。scale-out はしにくくする。再び上昇傾向に入るまでは、下降中に scale-out しても、すぐ scale-in が必要になるため。 切り替えは、決まった時刻に CronJob が HPA の behavior を patch することで行っています。 効果 2 つの改善の結果、次のようになりました。 項目 改善前 改善後 scale-out の所要時間 12 分 2 分 HPA の CPU threshold 65% 80% ファイルコピーの待ちがなくなったことで、scale-out は 2 分で終わるようになりました。その結果 threshold を引き上げられるようになり、同じトラフィックをより少ない台数でさばけています。 tolerance と stabilizationWindow の切り替えにより、threshold を上げても、スラッシングは起きていません。 まとめ この記事では、Elasticsearch の autoscaling を改善するために行った 2 つの取り組みを紹介しました。 StatefulSet の Pod は全部同じサイズ、という制約を MutatingWebhook で回避し、PVC に事前に shard を同期した Replicator を常駐させることで、scale-out から shard のコピー待ちをなくしました。 その結果 HPA の threshold を引き上げられるようになり、顕在化した tolerance の問題を、HPA ごと・方向ごとの tolerance と stabilizationWindow の設定、および CronJob による切り替えで解消しました。 Kubernetes 側の Pod 制御と、Elasticsearch 側の shard 配置・検索対象の制御を組み合わせることで、検索を提供するまでの経路から全量コピーの待ち時間を切り離しました。同じように、StatefulSet の制約や HPA の挙動に悩んでいる方の参考になれば幸いです。

こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 ファインディでは、施策の立案からIssueの生成、タスク分解、AIエージェントによる並列実装やQAまで、開発フローの各所にAIエージェントを組み込んでいます。 この記事では、開発フロー全体のアーキテクチャを図で示し、構成要素ごとに役割を解説します。PM、開発、QAのそれぞれでエージェントが何を担い、人間がどこで判断しているのか、開発の状態をGitHubのどこに置いているのかが分かる内容となっています。 複数のAIエージェントを開発フローに組み込もうとしている方や、AIエージェントとの役割分担を考えているエンジニアの方の参考になると思います。それでは見ていきましょう！ 開発フローのアーキテクチャ 施策を作るエージェント 施策提案スキル 要件定義スキル 要件をIssueに分解するエージェント Issueの依存関係から実装の順番を決める計画エージェント 並列で動く実装エージェント スタックプルリクエスト QAのエージェント まとめ 開発フローのアーキテクチャ エージェントやスキルは、PM向け、開発向け、QA向けの3つのPluginにまとめています。 開発フローは次の順に進みます。 PM向けPlugin PMのエージェントがNotionやGitHubなどからコンテキストを集めて施策を作り、要件定義のIssueとしてGitHubに作成する 開発向けPlugin 開発のエージェントが要件定義のIssueをタスクに分解し、親Issue、Sub-issue、依存関係をGitHubに作成する 計画エージェントがGitHubからIssueと依存関係を読み、実装の順番を決める 実装エージェントが依存の順にIssueを実装し、スタックプルリクエストとして積む レビュー 人間やAIがプルリクエストを順にレビューしてマージする QA向けPlugin QAのエージェントが要件定義のIssueからQA観点とテストケースを作り、Playwrightで実行する ここからは、構成要素ごとに解説します。 施策を作るエージェント フローの起点は、施策を作る段階です。PM向けの社内Pluginに、施策を提案するスキルと、施策の要件を定義するスキルを用意しています。施策提案スキルで案を選び、要件定義スキルでGitHubのIssueにする、という順に使います。 施策提案スキル 施策提案スキルは、PMからテーマや領域を受け取り、取り組むべき課題を探すところから始めます。 最初に、専用のエージェントが情報を並列に収集します。社内ドキュメントからはKPIや戦略、コードベースからは既存の機能やデータスキーマ、GitHubからは既存のIssueとプルリクエスト、Notionからは仕様書や議事録などを集めます。あわせて、Google AnalyticsとSearch Consoleのアクセス解析のデータと、Web上の市場や競合の情報も取得します。 収集した結果をもとに、別のエージェントが複数の観点から施策のアイデアを出し、さらに別のエージェントがインパクトと実現可能性などで評価して優先順位を付けます。 PMは、順位付けされた提案の一覧から採用する案を選びます。採用した案は次に紹介する要件定義スキルに引き継ぎます。 要件定義スキル 要件定義スキルは、提案された施策の要件を定義します。 情報収集の段階では、仮説エージェントと収集エージェントを並列に動かします。仮説エージェントが仮説を立てると、収集エージェントはその仮説に沿って必要なデータを集めます。仮説エージェントは追加で集まったデータを受け取り、仮説を裏付けたり修正したりします。 続いて、施策の規模を判定します。ユースケースやユーザー種別が複数にまたがる場合は、MVPと優先度付きの拡張項目に分けます。そのうえで、収集したデータが仮説を裏付けているかと、技術的に実現できるかを整理して、統合ドラフトにまとめます。PMはこのドラフトをレビューし、修正や補足があれば伝えます。 PMがドラフトを最終承認すると、要件定義の親IssueをGitHubに作成します。 要件をIssueに分解するエージェント 要件定義のIssueを受け取るのが、Issue生成スキルです。要件定義IssueのURLを入力に、実装タスクのIssueを作るところまでを対話的に進めます。 最初に、要件定義Issueの本文とコメントを読んで要件を理解し、対象のコードベースを探索して既存の構造と実装パターンを把握します。 tech.findy.co.jp 設計の段階では、方針の異なる設計案を並列に作り、開発者が比較して設計方針を決めます。決めた方針をもとに、タスクに分解します。 tech.findy.co.jp Issueの作成は、専用のサブエージェントに切り出しています。サブエージェントは、要件定義Issueを親Issueとして再利用し、子IssueをSub-issueとして作成したうえで、Issue間の依存関係を設定します。依存関係を本文の #番号 ではなくGitHubのIssue依存関係機能（ blocked_by ）で登録しているのは、後段の計画エージェントが機械的に読めるようにするためです。 blocked_by は、あるIssueが別のIssueの完了を待つ関係を、Issue同士に設定する機能です。Sub-issueで「何を作るか」を親子に整理し、 blocked_by で「どの順に作るか」を表します。 Issueの依存関係から実装の順番を決める計画エージェント 並列実装を指揮するのが計画エージェントです。計画エージェントの役割は実行計画の作成と実装エージェントの起動に限られていて、コードの編集、worktreeの操作、GitHubへの書き込みはしません。 計画エージェントは親Issueを起点に、GitHubからopenなSub-issueと、それぞれの blocked_by を読み込みます。closedのIssueは対象から外し、closedのIssueへの依存は解決済みとして扱います。 開発者は、計画エージェントが提示した実行計画を確認します。確認が取れると、計画エージェントは、依存でつながったIssueのグループごとに実装エージェントを並列で起動します。 tech.findy.co.jp 並列で動く実装エージェント 実装エージェントは、依存でつながったIssueのグループごとに起動され、担当のIssueを実装してプルリクエストを作るまでを、完全に非対話で受け持ちます。 計画の承認が必要な場合は、先に計画だけを返す実装エージェントを起動します。開発者が計画を承認したあとで、改めて実装エージェントを起動します。 実装エージェントは、担当のIssueを依存の順に下から実装します。Issueごとにgit worktreeを作り、2番目以降のIssueは前のIssueのブランチをbaseにします。この時点のブランチはpushせず、手元に置いたままです。 tech.findy.co.jp グループの中に互いに依存しないIssueがある場合は、それらを並列に実装したあと、組み立てエージェントがリベースして依存の順に並べ直します。リベースを実行する権限は、このエージェントだけに持たせています。 並べ終わったブランチからプルリクエストを作成し、スタックプルリクエストとして登録します。 スタックプルリクエスト 実装エージェントは、プルリクエストをスタックプルリクエストとして登録し、そこで終了します。 tech.findy.co.jp プルリクエストの本文には、対応するIssue（ Closes #番号 ）、親Issue、依存しているプルリクエスト、セルフレビューなどの品質保証の結果を入れます。 開発者は、スタックを下から順にレビューしてマージします。下位のプルリクエストがマージされると、GitHubが上位のブランチを自動でリベースし、baseを付け替えます。図の例では、#201をマージすると#202のbaseがmainに付け替わります。どこまでマージされたかという状態はGitHubが持っているため、エージェントはマージを待ちません。 マージされたプルリクエストは、 Closes によって対応するIssueを自動でcloseします。closeされたIssueは、次に計画エージェントを起動したときの計画の対象から外れます。 QAのエージェント QAには、QA向けの社内Pluginを使っています。開発リポジトリとは別のQA用リポジトリで動かし、分析対象の開発リポジトリを設定で登録しておきます。 QA観点を作るスキルは、要件定義のIssueを仕様ソースとして読みます。NotionやFigmaのページも仕様ソースとして渡せます。まず仕様を抽出するエージェントが、キーワードと対象ファイルを決めて探索の範囲を絞ります。続いて、画面と操作フローを調べるエージェントと、変更による回帰リスクを判定するエージェントを並列に動かし、その間に要件がコードとテストで満たされているかを突き合わせます。 集めた検証項目は、テスト戦略のスキルで「テストコードで自動化するもの」と「QAテストで確認するもの」に分けます。QA観点にはQAテスト側の項目だけを展開し、テストコードが足りていない箇所は別のファイルとして出力します。 テストケースを作るスキルは、QA観点をもとに、前提条件、手順、期待値、ロールごとの結果欄を持つテストケースを作ります。各ケースには、ブラウザ操作で自動実行するAutoか、人間が目視で確認するManualかを付けます。判断に迷うケースはManualに寄せています。 作成した観点とテストケースは、QA基準のカテゴリごとにレビュー用のエージェントを並列に起動して、網羅性と品質を確認します。QA担当は、指摘のうちどれを反映するかを選びます。 Autoのケースは、Playwright MCPを使ってロールごとに順に実行します。結果は、失敗したケースのスクリーンショットを含むレポートとして出力し、元のテストケースには書き戻しません。Manualのケースは目視確認の一覧としてまとめ、QA担当が目視で確認します。 まとめ AIエージェントを開発フローに組み込むうえで大事なのは、AIに任せる範囲と人間が判断する部分を切り分けることだと考えています。 情報の収集、設計案の作成、実装、テストの実行といった作業はAIに委任し、施策の採択、設計方針の決定、実行計画の確認、マージ、QAの確認といった最終的な判断は人間が行います。 AIに委任して人間が最終判断するという線引きを決めておくことが、AIエージェントと一緒に開発を進めるうえでの前提になります。 開発フローのどこにAIエージェントを置くかは、チームによって答えが変わると思います。この記事の図が、自分たちのフローを見直すときのたたき台になればうれしいです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

本日、 Moonshot AI の Kimi K3 モデル が Kiro で利用可能になったことをお知らせします。Kimi K3 は、 Moonshot AI によると 世界初の 2.8T パラメーターのオープンウェイトモデルで、これをエージェンティックな開発ワークフローの中で直接使えるようになります。100 万トークンのコンテキストウィンドウ、2.8 兆のパラメーター、トークン効率の高い Mixture-of-Experts アーキテクチャを備えた Kimi K3 は、複雑なソフトウェア開発において性能と効率を両立させます。また、Kiro の特徴である仕様駆動で正しさを最優先するアプローチとも相性の良いモデルです。 1M トークンのコンテキストウィンドウと 2.8T パラメーターで、長時間に及ぶ複雑なタスクに対応 Kimi K3 の 100 万トークンのコンテキストウィンドウには、コードベース全体、仕様書一式、テストスイート、会話履歴を同時に収められます。Kiro で要件、設計、実装、検証と進む仕様駆動開発のワークフローを回すとき、このモデルならコンテキストを途切れさせずに作業を続けられます。総パラメーター数 2.8 兆の K3 は、長期にわたるコーディング、深い推論、エンドツーエンドのナレッジワークといった、プロの開発者にとって重要なタスクでフロンティアレベルの知能を発揮します。Kiro ユーザーにとっては、複数ファイルにまたがるリファクタリングを推論し、深くネストした依存関係の連鎖を理解し、大規模なコードベース全体でアーキテクチャとして筋の通ったコードを生成できるモデルということになります。 オープンウェイトモデルの選択肢が広がり、Kiro での高品質な開発を後押し Kimi K3 の追加により、Kiro で開発者が使えるオープンウェイトモデルの幅はさらに広がります。日常的なタスクには効率を、複雑な作業には高い性能を、というモデル選択への取り組みを今後も強化していきます。Kimi K3 の推論能力を選ぶことで Kiro の仕様駆動開発が強化され、要件をより網羅的な実行可能仕様へと落とし込めます。Kiro の自動化された決定論的な検証によって、生成されたコードが仕様と開発者の意図に合致しているかが確かめられます。K3 は 1M のコンテキストウィンドウでシステム全体を考慮したうえで成り立つべき性質（プロパティ）を見極め、2.8 兆パラメーター分の知識によって、初回からそれらの性質を満たしやすい実装を生み出します。この組み合わせにより、単に動くだけでなく、仕様に照らして検証されたソフトウェアを届けられます。 はじめ方 Kimi K3 モデルは本日より、us-east-1（IAD）の Kiro Pro、Pro+、Pro Max、Power のすべてのお客様に 実験的サポート として提供されます。クレジット倍率は 2.4x で、高い性能が求められる開発作業に向いています。 この記事は Kiro ブログの Kimi K3 model is now available in Kiro を翻訳したものです。