はじめに こんにちは！芝浦工業大学理工学研究科 修士1年の只野陽生と申します。2026年2月の3週間 ...

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第2回の記事です。 先に第1回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ こちらは第1回で紹介したBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、負荷テストツールとして採用したLocustの選定理由から、実際の構築・運用方法までを紹介します。 負荷生成ツールの選定 負荷テストのリクエスト元となる負荷生成ツールの選定を行いました。 選定の際は、まず今回の要件として以下の通りまとめました。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こうした観点から参考として整理したOSSの比較表が以下となります。 ツール名 分散実行可能 Web UI レポート品質 学習コスト 実績が豊富 特徴 Locust ◎（Master/Worker が標準） ◎ ○ Web UI 低 ○ OSSで最も簡単にクラスタ構成可能。Pythonでシナリオが柔軟。中規模負荷に強い。 Taurus ○（バックエンドの Locust/JMeter/k6 を分散実行管理） △ ○（バックエンド依存） 低〜中 △ CI/CDで分散テスト統合運用。YAMLでテストランナー統一。チーム利用に最適。 JMeter ○（分散実行あり、構成は複雑） △（要プラグイン） ◎ HTMLレポート 中 ◎ GUI派に最適。歴史が長く安定。大規模負荷にも実績豊富。 k6 OSS △（K8s/CIで水平スケール。自動クラスタなし） ✕ △（外部連携で補完） 低〜中 ○ K8sベースのスケール前提なら実質分散可能。軽量で高性能。 Gatling △（OSS版は限定的。分散は Gatling Enterprise 推奨） ✕ ◎ HTMLレポート 中〜高 ○ Scala/Java DSLで高精度なシナリオ記述。レポートが非常に詳細。高スループット計測に強い。 k6、JMeter、Locustは自身で使ったことがありました。 k6は軽量ですが、Web UIがなく、分散環境で実行した場合、サーバーごとに出力されるレポートの収集が必要なのが懸念でした。 JMeterはテストシナリオを作るための構成が独特で理解に時間がかかるため、学習コストが高いと感じていました。 LocustはWeb UIから容易に実行でき、Pythonでテストシナリオを書く体験が良かったので、今回もLocustを選定することにしました。 Locustの公式ドキュメントはこちらを参照ください。 https://locust.io/ Locustの構築と実行 ECSに構築しました。ECSはAWSのコンテナ管理サービスです。 LocustはMasterとWorkerのタスクに分かれて起動します。 MasterはWeb UIとWorkerの管理を行い、Workerが実際の負荷をリクエストします。 Workerの数を増やすことで、負荷リクエストの上限も増やすことができる構成です。 ECSでのLocustの構成 Classごとに実行が可能で、ProfileでGold環境とBronze環境を切り替えられるようにしています。 Locustの実行画面 実行結果はWeb UIからRPS、Response Times、User数がチャートで見れます。 Locustの実行結果 実際に負荷テストを実行する際は、急激な負荷増加によるスパイクを避けつつ安定状態を観測するため、30秒程度で全てのUserがRamp upするようにして5分間の負荷をかけています。 そして5分の間、応答速度が安定的であるかどうかチャートを見ながら確認しつつ負荷テストを行っています。 Terraformを用いたインフラのコード化 Locustを配置している負荷テスト環境のインフラは Terraform で管理しています。 Terraformはインフラの構成を「設定ファイル」として記述できるOSSです。 AWSコンソールから設定せず、Terraformを用いてコード管理することで以下のメリットがあります。 負荷テスト環境で使用しているリソースをコードから確認できる コードベースでAIに環境構築を依頼できるため、構築が早い 環境の起動と破棄がGitHub Actions（GHA）から実行できる これにより、負荷テスト環境を使用する時だけ起動し、使い終わったら破棄するといったこともできます。 しかし、負荷テスト環境の構築を始めた当初、チーム内にTerraformを使用したことのある知見がなかったため、メンバーから提案をいただき、まずAIにAWSの基礎知識を含めた学習用コンテンツを作ってもらうことから始めました。 AIは主にClaude Codeを使用しています。 こちらが学習コンテンツの一部ですが、このような資料を作っていました。 学習コンテンツ また環境構築自体も、Claude Codeに設計書を書いてもらい、チーム内でレビューをし、何度も修正を繰り返した上で、Claude CodeにTerraformのコードに落とし込んでもらうという形で進めました。 作成されたコードのレビューはチーム全員で行い、全員が負荷テスト環境について知識を揃えるようにしました。 また今回Terraformのフォルダ構成として、以下の通りcoreとruntimeという二つのフォルダに分けています。 core：常設リソースの配置場所で、destroy不可に設定して常設リソースを保護します runtime：一時的なリソースの配置場所で、destroy可能とすることでコストを削減します これにより、インフラの起動時間の短縮とコストの削減を両立させることができます。 今回はTerraformの構成についての知見も得ることができ、良い経験になりました。 負荷テストシナリオの作成 LocustではPythonでテストシナリオを書くことができます。 下記はClaude Codeに書いてもらったサンプルコードからの抜粋ですが、コードの組み立て方は実コードとあまり変わらないため、イメージしやすいかと思います。 """Locust による会員登録フローの負荷テストシナリオ""" import json import os import random import string from locust import HttpUser, between, task DEBUG = os.getenv( "DEBUG" ) == "1" def random_email (): """テスト用のユニークなメールアドレスを生成する""" rand = "" .join(random.choices(string.ascii_lowercase + string.digits, k= 10 )) return f "test_{rand}@example.com" def log_response (label, response): if not DEBUG: return code = response.status_code mark = "✓" if 200 <= code < 300 else "✗" print (f " {mark} [{code}] {label}" ) if code >= 400 : print (f " body: {response.text[:200]}" ) class UserRegistration (HttpUser): """新規会員登録フローのシナリオ""" wait_time = between( 1 , 3 ) @ task def register (self): email = random_email() # 1. 仮登録（メール送信リクエスト） with self.client.post( "/api/v1/signup" , json={ "email" : email}, catch_response= True , ) as r: log_response( "signup" , r) if r.status_code != 200 : r.failure(f "signup: {r.status_code}" ) return token = r.json().get( "confirmation_token" ) if not token: r.failure( "signup: token missing" ) return # この後の処理は省略 今回、テストシナリオを商品や決済方法毎にいくつか作成しました。 作成方法としては過去にk6のJavaScriptで書かれたテストシナリオを流用し、Claude CodeにPythonのコードに変換してもらいました。 変換後のコードが正しいかどうかを検証するために、Playwrightを使用しました。 Playwrightはブラウザを自動操作できるOSSのテストツールです。 Claude CodeをPlaywright MCP（MCPは外部ツールと連携するための共通規格）に接続して、開発環境での購入画面に実際にアクセスしながら、通信しているAPIを確認し、APIコールがテストシナリオのコードと一致しているか検証する形で行いました。 実際に指示したプロンプト Playwright MCPで下記URLにアクセスして、 購入フローをトレースしながらコールされているAPIが scenario/*****.py の シナリオに記載されている内容と一致しているかチェックしてください https://*****/items/12939562 こうしたClaude Codeを用いたテストシナリオの作成により、作業時間を大幅に短縮することができました。 Locustの週次での自動実行 GHAから自動実行する際は、ECSでLocustを起動した後、起動したLocustに対してLambda経由でLocustの負荷テスト実行APIを叩くようにしています。 そして負荷テストの完了結果はログ収集サービスであるCloudWatch Logsをポーリングして、結果ログを取得するようにしています。 以下がそのシーケンス図になります。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant GHA as GitHub Actions participant Lambda as Lambda<br/>(locust-control) participant CWL as CloudWatch Logs participant Master as Locust Master<br/>(ECS) participant Worker as Locust Worker<br/>(ECS x N) Note over GHA: Locust Master/Worker の<br/>デプロイ完了後 GHA->>Lambda: Lambda を非同期で呼び出す<br/>（ユーザー数・実行時間等を指定） Lambda-->>GHA: 即時応答（202） Note over GHA: CloudWatch Logs のポーリングを開始<br/>（30秒間隔で結果ログを監視） Lambda->>Master: Worker の接続状況を確認<br/>（10秒間隔・最大120秒） Master-->>Lambda: 接続済み Worker 一覧 Lambda->>Master: テスト開始を指示<br/>（POST /swarm） Master-->>Lambda: 開始成功 Master->>Worker: テストシナリオを配信 Note over Worker: 負荷テスト実行中... Note over Lambda: 指定時間が経過するまで待機 Lambda->>Master: テスト停止を指示<br/>（GET /stop） Master->>Worker: 停止指示 Master-->>Lambda: 停止完了 Lambda->>Master: テスト結果を取得<br/>（GET /stats/requests） Master-->>Lambda: 統計データ（JSON） Note over Lambda: サマリを抽出<br/>（全体集計 + POST /orders） Lambda->>CWL: サマリをログに出力 GHA->>CWL: サマリログを検索 CWL-->>GHA: テスト結果（JSON） GHA->>GHA: Slack に結果を通知 こうしてLocustを毎週、自動実行することで、Locustを継続的に使用できる状態を保てるようにしています。 おわりに LocustはWeb UIからすぐに負荷テストを開始できるのが非常に便利です。 複数のテストシナリオを組み合わせて実行することもできます。 今後、BASEの決済や販売方法のテストシナリオを拡充した上で、テストを並走させることで、本番をよりシミュレーションした負荷テストを実施していければと考えています。 こうした負荷テストの仕組みに興味がありましたら採用情報もぜひご覧ください。 binc.jp

みなさん、こんにちは。 いなりく です。 新年あけましておめでとうございます。みなさん Kiro ライフをいかがお過ごしでしょうか。 Kiro CLI 1.24.0 では、 大規模なドキュメントセットの段階的な読み込みを可能にする Skills 、 カスタム Diff ツール 、 18 言語に対応した組み込みコードインテリジェンス 、 リモート認証 、 web_fetch ツールの詳細な権限管理 、 長時間のセッションをスムーズに維持する会話 圧縮の詳細なコントールが導入されました。これらのアップデートが私の Kiro ライフを更に快適にしてくれたので、今回はこれらの追加された機能を深堀ってご紹介します。Kiro って何？という方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけると Kiro の全体像を掴んでいただけると思います。気になるアップデートのセクションおよび移行ガイドだけを読んでいただいても問題ありません。Kiro CLI の v.1.21.0 から v.1.23.0 までのアップデートに関しては「 Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0 」をぜひお読み下さい。 アップデート１ : Skills による段階的なコンテキスト読み込み アップデート２ : カスタム Diff ツール アップデート 3 : AST パターンツールによる正確なリファクタリング アップデート 4 : 改善されたコードインテリジェンス アップデート 5 : 会話圧縮の詳細なコントロール アップデート 6 : web_fetch ツールの詳細な URL 権限管理 アップデート 7 : リモート認証 移行ガイド アップデート 1 : Skills による段階的なコンテキスト読み込み Skills は起動時にはメタデータ（名前と説明）のみが読み込まれ、エージェントが必要と判断したときにのみ完全なコンテンツが読み込まれます。これにより、コンテキストウィンドウを効率的に管理しながら、広範なドキュメントへのアクセスを提供できます。 Skills の仕組み 従来の Steering ファイルは、エージェント起動時にすべてのコンテンツをコンテキストウィンドウに読み込みます。これは小規模なファイルには適していますが、大規模なドキュメントセットではコンテキストウィンドウを圧迫してしまいます。 Skills は以下のアプローチを採用しています。 起動時 ：名前と説明のみが読み込まれる 実行時 ：エージェントが関連性を判断し、必要に応じて完全なコンテンツを読み込む 効率性 ：使用されないドキュメントはコンテキストを消費しない Skills ファイルの作成 Skills ファイルには、YAML フロントマターで記述された説明的なメタデータが必要です。エージェントが完全なコンテンツを読み込むタイミングを確実に判断できるよう、具体的な説明を記述してください。 --- name: dynamodb-data-modeling description: DynamoDB データモデリングのベストプラクティスガイド。DynamoDB スキーマの設計または分析時に使用。 --- # DynamoDB データモデリング ## 概要 DynamoDB は NoSQL データベースで、適切なデータモデリングが重要です... ## パーティションキーの設計 パーティションキーは均等に分散する必要があります... ## ソートキーのパターン ソートキーを使用すると、効率的なクエリパターンが可能になります... Skills と Steering の使い分け Skills を使用する場合： 大規模なドキュメントセット（API リファレンス、アーキテクチャガイドなど） 特定のタスクでのみ必要な専門知識 コンテキストウィンドウの効率的な管理が必要な場合 複数のトピックに分かれた参照ドキュメント Steering を使用する場合： すべての会話で常に必要な小規模なファイル（README、設定ファイルなど） プロジェクトの基本情報やコンテキスト エージェントの動作を常に制御したいコーディング規約やスタイルガイド カスタムエージェント設定での Steering/Skills の使用 カスタムエージェントでは Skills/Steering ファイルは自動で読み込まれず、カスタムエージェント設定ファイルの resources フィールドで明示的に指定する必要があります。Glob パターンを使用すると、複数の SKill ファイルを一度に含めることができます。エージェントは各 Skills のメタデータを読み込み、会話の文脈に基づいて関連する Skill を自動的に読み込みます。 以下の例では README.md と Steering ファイル（coding-standards.md、project-rules.md）はカスタムエージェントで常に読み込まれ、Skills として、api-reference.md、architecture-guide.md、deployment-guide.md が必要なときだけ読み込まれます。 詳細については、 Skills リソースのドキュメント を参照してください。 { "resources": [ "file://README.md", "file://.kiro/steering/coding-standards.md", "file://.kiro/steering/project-rules.md", "skill://docs/api-reference.md", "skill://docs/architecture-guide.md", "skill://docs/deployment-guide.md" ] } アップデート ２ : カスタム Diff ツール Kiro がファイルの変更を提案する際、デフォルトでは組み込みの Diff ツールを使用して変更内容を表示します。1.24.0 では、外部の Diff ツールを設定できるようになり、シンタックスハイライト、サイドバイサイド表示、お気に入りの GUI ツールなど、好みの Diff 表示方法を選択できます。 設定方法 chat.diffTool 設定で、好みの Diff ツールを指定します。 kiro-cli settings chat.diffTool delta カスタム Diff ツール (delta を利用した場合) 組み込みの Diff には以下のコマンドで戻すことができます。 kiro-cli settings -d chat.diffTool 組み込み diff ツール ターミナルツール ターミナルで直接 Diff を表示するツールは、ワークフローを中断しません。 delta ：Git ユーザー向けのシンタックスハイライトと行番号表示 difftastic ：フォーマットの違いを無視する言語対応の構造的 Diff icdiff ：素早いサイドバイサイドのカラー比較 diff-so-fancy ：クリーンで人間が読みやすい出力 colordiff ：シンプルなカラー表示の Diff bat ：Git 統合を備えたシンタックスハイライト GUI ツール 変更内容を別ウィンドウで確認できる GUI ツールもサポートしています： VS Code ： code Meld ： meld KDiff3 ： kdiff3 FileMerge (macOS) ： opendiff Vim ： vimdiff Neovim ： nvim 注意： GUI Diff ツールは表示専用の一時ファイルを開きます。GUI ツールで行った編集は保存されず、Kiro の提案された変更には適用されません。 カスタム引数の使用 引用符で囲むことで、ツールの動作をカスタマイズできます。 # delta でサイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" 詳細については、 カスタム Diff ツールのドキュメント を参照してください。 アップデート 3 : AST パターンツールによる正確なリファクタリング 新しい pattern-search と pattern-rewrite ツールにより、エージェントはテキストの正規表現ではなく、構文木パターンを使用してコードを検索および変換できます。これにより、文字列リテラルやコメント内の誤検出がなくなります。 pattern-search の使用例 # すべての async 関数を検索 > async function $NAME($$$PARAMS) { $$$ } という構造のコードを検索して # 特定のメソッド呼び出しを検索 > $OBJ.setState($$$ARGS) のパターンを検索して pattern-rewrite の使用例 # var を const に変換 > var 宣言をすべて const に書き換えて # 古い API を新しい API に変換 > $O.hasOwnProperty($P) を Object.hasOwn($O, $P) に書き換えて メタ変数を使用してパターンを定義します。 $VAR ：単一のノード（識別子、式）にマッチ $$$ ：ゼロ個以上のノード（文、パラメータ）にマッチ これらのツールは、コードの構造を理解するため、テキストベースの検索置換よりも正確で安全なリファクタリングが可能です。 アップデート 4 : 改善されたコードインテリジェンス Kiro CLI は、セットアップ不要で 18 言語に対応した組み込みのコードインテリジェンスを提供します。エージェントは、シンボル検索、定義へのナビゲーション、構造的なコード検索を即座に実行できます。 対応言語 Bash、C、C++、C#、Elixir、Go、Java、JavaScript、Kotlin、Lua、PHP、Python、Ruby、Rust、Scala、Swift、TSX、TypeScript 組み込み機能 シンボル検索 ：コードベース全体で関数、クラス、変数を検索 ドキュメントシンボル ：ファイル内のすべてのシンボルをリスト表示 シンボルルックアップ ：定義に即座にジャンプ パターン検索 ：AST ベースの構造的コード検索 パターン書き換え ：AST パターンを使用した自動コード変換 コードベースマップ ：ディレクトリ構造の探索とコード構成の理解 コードベース概要 任意のワークスペースの概要を素早く取得できます。 /code overview クリーンな出力には --silent を使用します。 /code overview --silent これは以下の場合に便利です： 新しいコードベースへのオンボーディング プロジェクト構造に関する Q&A セッション 未知のパッケージを素早く理解 LSP 統合（オプション） 参照の検索、ホバードキュメント、リファクタリングのリネームなどの拡張機能を使用するには、LSP 統合を有効にできます。プロジェクトルートで以下のコマンドを実行することで、 .kiro/settings/lsp.json 設定が作成され、言語サーバーが起動します。 /code init 使用例 # シンボルを検索 > UserRepository クラスを検索して # すべての参照を検索 > Person クラスの参照をすべて検索して # 定義に移動 > UserService の定義を検索して # ファイル内のシンボルを取得 > auth.service.ts にはどんなシンボルがある？ # ホバードキュメントを取得 > AuthService の authenticate メソッドのドキュメントは？ # 利用可能なメソッドを発見 > s3Client インスタンスで使えるメソッドは？ 詳細については、 コードインテリジェンスのドキュメント を参照してください。 アップデート 5 : 会話圧縮の詳細なコントロール /compact コマンドを利用することで会話履歴を要約し、重要な情報を保持しながらコンテキストスペースを解放することができます。今回のアップデートでは保持するメッセージと最小コンテキストウィンドウの割合を指定することが可能になりました。 圧縮の仕組み 圧縮は、古いメッセージを要約しながら最近のメッセージを保持します。これにより、会話の文脈を維持しながら、コンテキストウィンドウを効率的に使用できます。 手動圧縮 ： /compact コマンドを実行 自動圧縮 ：コンテキストウィンドウがオーバーフローすると自動的にトリガー 設定 保持するメッセージの量を設定できます。 compaction.excludeMessages （デフォルト：2）：保持する最小メッセージペア数 compaction.excludeContextWindowPercent （デフォルト：2）：保持する最小コンテキストウィンドウの割合 両方の設定が評価され、より保守的な（大きい）値が優先されます。 圧縮後の操作 # 手動で圧縮を実行 /compact # 元のセッションに戻る /chat resume 詳細については、 会話の圧縮のドキュメント を参照してください。 アップデート 6 : web_fetch ツールの詳細な URL 権限管理 エージェント設定を通じて、エージェントがアクセスできる URL を制御できるようになりました。正規表現パターンを使用して、信頼できるドメインを自動的に許可したり、特定のサイトをブロックしたりできます。 設定方法 エージェント設定ファイルの toolsSettings で URL ベースの権限を設定します。 { "toolsSettings": { "web_fetch": { "trusted": [".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com.*"], "blocked": [".*pastebin\\.com.*"] } } } パターンの動作 パターンは正規表現で、自動的に ^ と $ でアンカーされます blocked は trusted よりも優先されます blocked の無効な正規表現は、すべての URL を拒否します（フェイルセーフ） trusted の無効な正規表現はスキップされます 信頼されたパターンに一致しない URL は、承認を求めるプロンプトが表示されます 使用例 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/myorg/.*", ".*stackoverflow\\.com.*" ], "blocked": [ ".*pastebin\\.com.*", ".*privatesite\\.internal.*" ] } } } この設定により、AWS ドキュメント、組織の GitHub リポジトリ、Stack Overflow への自動アクセスが許可され、特定のサイトがブロックされます。 詳細については、 web_fetch ツールのドキュメント を参照してください。 アップデート 7 : リモート認証 リモートマシン（SSH、SSM、コンテナ経由）で Kiro CLI を実行する際、Google または GitHub でサインインできるようになりました。ポートフォワーディングにより、認証が機能します。 Builder ID と IAM Identity Center Builder ID と IAM Identity Center の場合、デバイスコード認証がそのまま機能します。URL とコードをローカルブラウザに入力するだけです。 ソーシャルログイン（Google または GitHub） ソーシャルログインの場合、CLI は PKCE 認証を使用し、ポートフォワーディングが必要です。OAuth コールバックは localhost にリダイレクトされるため、トンネルなしではリモート CLI に到達できません。 リモートマシンでのサインイン手順 kiro-cli login を実行し、「Use for Free with Google or GitHub」を選択 表示されたポート番号をメモ（毎回異なります。例： 49153 ） ローカルマシンの新しいターミナルで、ポートフォワーディングを設定： ssh -L <PORT>:localhost:<PORT> -N user@remote-host <PORT> をステップ 2 のポートに、 user@remote-host をリモート認証情報に置き換えます。 CLI で Enter キーを押し、ローカルブラウザで URL を開きます 認証を完了すると、コールバックがトンネル経由で CLI に到達します SSH ポートフォワーディングの例 # 基本的なポートフォワーディング（49153 を実際のポートに置き換え） ssh -L 49153:localhost:49153 -N user@remote-host # カスタム ID ファイルを使用（EC2 で一般的） ssh -i ~/.ssh/my-key.pem -L 49153:localhost:49153 -N user@remote-host # SSH 設定エイリアスを使用 ssh -L 49153:localhost:49153 -N myserver 詳細については、 リモート認証のドキュメント を参照してください。 移行ガイド 既存の Kiro CLI ユーザーが 1.24.0 にアップグレードする際のガイドラインです。 ステップ 1：常に読み込みが必要ではない Steering ファイルを Skills に変換 既存の Steering ファイルの中に常に読み込みが必要ではないものがある場合は、Skills に変換することを検討してください。 変換前： { "resources": [ "file://docs/api-reference.md", "file://docs/architecture-guide.md" ] } 変換後： 1. 各ファイルに YAML フロントマターを追加 --- name: api-reference description: API リファレンスドキュメント。API エンドポイント、リクエスト/レスポンス形式、認証方法について記載。 --- # API リファレンス ... 2. エージェント設定を更新： { "resources": [ "skill://docs/api-reference.md", "skill://docs/architecture-guide.md" ] } ステップ 2：カスタム Diff ツールの設定 お気に入りの Diff ツールがある場合は、設定してください。 # delta を使用する場合 kiro-cli settings chat.diffTool delta # サイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" ステップ 3：URL 権限の設定 web_fetch ツールを使用している場合は、信頼できるドメインを設定してください。 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/your-org/.*" ] } } } ステップ 4：コードインテリジェンスの有効化 プロジェクトルートで LSP を初期化 /code init まとめ Kiro CLI 1.24.0 は、開発者の生産性を向上させる多くの新機能を提供します。Skills による効率的なコンテキスト管理、カスタム Diff ツールによる柔軟な変更レビュー、18 言語に対応した組み込みコードインテリジェンス、会話の圧縮による長時間セッションのサポート、詳細な URL 権限管理、リモート認証のサポートなど、開発ワークフローを強化する機能が満載です。 今すぐ Kiro CLI 1.24.0 にアップグレードもしくは インストール して、これらの新機能をお試しください！みなさんの Kiro ライフがより快適になることを願っています！ 著者 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。