本記事は「 Surgical precision with AST-based code editing in Kiro 」を翻訳したものです。 TL;DR: ここ数週間、私たちは新しい AST ベースのコードナビゲーション・編集エンジンをテストしてきました。このエンジンは、Kiro で最も頻繁なクエリタイプである機能リクエストの例を含むベンチマーク SWE-PolyBench において、トークン使用量を 20% 削減します。また、正確で耐障害性の高い、プロダクショングレードのコード変換を可能にします。脆弱な正規表現やファイル全体のダンプはもう不要です！ エージェントが 1 つの関数を見つけるために何千行も読み込み、わずかなフォーマットの違いのせいで更新に失敗することは AI コーディングアシスタントを使っているすべての開発者が経験したことがあるでしょう。現在のアプローチはファイル全体を読み込み、完全一致の文字列マッチングを行いますが、トークンを大量に消費し、簡単に壊れてしまいます。私たちはより良いものを構築しました。 本日、Kiro のコードベースでの作業に外科的精度を与える AST ベースのコードナビゲーション・編集システムを紹介します。任意の行範囲を探索したり脆弱な文字列マッチングを行う代わりに、このツールはコードを構造で捉えます。関数、クラス、インポートなどを対象とし、意味的な理解に基づいた型付き操作を適用します。 ＊AST（抽象構文木） : コードから言語の意味に関係ある情報のみを取り出し、木構造で表現したものです。 テキストベースのコードツールの問題点 これまで、Kiro IDE はコードの確認に readFile 、編集に strReplace という 2 つのテキストベースのツールに依存していました。シンプルではありますが、このアプローチには 2 つの根本的な問題があります。 1. 高いトークンコストとレイテンシ 特定の関数を探す際、エージェントはファイルの大部分、多くの場合ファイル全体を読み込む必要があります。これは、タスクに関係のないコンテキストに何千ものトークンが費やされることを意味します。 2. 脆弱な文字列マッチング 編集には完全一致の文字列マッチングが必要です。エージェントの期待と実際のコードの間にある空白、フォーマット、コメントのわずかな違いが、編集の失敗や意図しない複数マッチを引き起こします。その後、エージェントはミスを修正するために追加のイテレーションが必要になります。 これらの問題は複合的に作用します。エージェントがミスをし、診断のためにファイルを再度読み込み、別の編集を試み、このサイクルが繰り返されます。各イテレーションがより多くのトークンを消費し、レイテンシを増加させます。 AST ベースエンジンの仕組み このエンジンは、テキストベースの操作を AST パースに置き換えます。コードを文字列として扱う代わりに、関数、クラス、メソッド、インポート、およびそれらの関係性といった構造化されたエンティティとしてコードを理解します。 コード読み取り: ターゲットを絞った情報抽出 ファイルの内容全体をダンプする代わりに、エンジンのコード読み取りツールは必要なものだけを返します: シグネチャ : 実装の詳細を含まない関数やクラスの定義 構造 : 高レベルのコード構成と関係性 検索結果 : 条件に一致する特定の定義 Java クラスを調べる 2 つのアプローチを比較してみましょう: 従来のアプローチ （1,309 トークン）: Read entire AsyncRpcResult.java file including: - License header - All imports - Complete implementation of 25+ methods - Full method bodies with all logic AST ベースのアプローチ （545 トークン）: Class signatures in AsyncRpcResult.java: class: AsyncRpcResult (Line 41) method: AsyncRpcResult(Invocation invocation) (Line 53) method: getValue() (Line 70) method: getException() (Line 82) method: thenApplyWithContext(Function<Result, Result> fn) (Line 139) [additional signatures...] この例では、エンジンはナビゲーションと意思決定に必要な本質的な構造情報を提供しながら、トークンを 58% 削減しています。 コード書き込み: セマンティック編集 エンジンのコード書き込みツールは、セレクタを使用してコード要素を正確にターゲットします: ClassName.methodName で特定のメソッドをターゲット function:functionName で関数をターゲット field:fieldName でクラスフィールドをターゲット end でファイルの末尾に追加 4 つの型付き操作をサポートしています: insert_node : 特定の場所に新しいコードを追加 replace_node : 関数やクラス全体を置換 delete_node : コード要素をクリーンに削除 replace_in_node : コードブロック内で外科的な編集を実行 ベンチマークからの実例として、TypeScript ファイルに新しい関数を追加するケースを紹介します: 従来のアプローチ （361 トークン）: { "oldStr": "/**\n * Get a cached parsed configuration...\n */\nfunction getCachedParsedConfiguration(tsConfigPath: string): ParsedConfiguration {\n if (tsConfigCache.has(tsConfigPath)) {\n return tsConfigCache.get(tsConfigPath)!;\n }\n \n const parsedConfig = readConfiguration(tsConfigPath);\n tsConfigCache.set(tsConfigPath, parsedConfig);\n return parsedConfig;\n}", "newStr": "/**\n * Get a cached parsed configuration...\n */\nfunction getCachedParsedConfiguration(tsConfigPath: string): ParsedConfiguration {\n if (tsConfigCache.has(tsConfigPath)) {\n return tsConfigCache.get(tsConfigPath)!;\n }\n \n const parsedConfig = readConfiguration(tsConfigPath);\n tsConfigCache.set(tsConfigPath, parsedConfig);\n return parsedConfig;\n}\n\n/**\n * Clear the tsconfig cache...\n */\nexport function clearTsConfigCache(): void {\n tsConfigCache.clear();\n}" } AST ベースのアプローチ （96 トークン）: { "path": "packages/compiler-cli/ngcc/src/ngcc_options.ts", "selector": "end", "replacement": "/**\n * Clear the tsconfig cache...\n */\nexport function clearTsConfigCache(): void {\n tsConfigCache.clear();\n}", "operation": "insert_node" } この例では、完全一致の文字列マッチングに必要な周辺コンテキストの記述を省略することで、エンジンはトークンを 73% 削減しています。 実際の効果 私たちは AST ベースエンジンを従来のツールと比較して、2 つのベンチマークで評価しました。 PolyBench50 の結果 PolyBench50（ SWE-PolyBench のサブセット）で AST の読み取り・書き込み操作を実行したところ、一貫した改善が見られました: 指標 従来 AST ベースエンジン 改善率 タスクあたりの LLM 呼び出し数 40.88 26.86 34.30% 出力トークン 270,957 189,806 29.95% 入力トークン 680,684 541,346 20.47% 機能リクエストのデモンストレーション 現実的な機能リクエストで両方のアプローチをテストしました:「AWS Resource Explorer にサードパーティ統合を追加」（Slack/Teams 通知、Jira チケット、SIEM エクスポート、AWS Config 統合）。 指標 従来 AST ベースエンジン 改善率 実行時間 9 分 20 秒 4 分 44 秒 49.30% LLM 呼び出し数 29 22 24.10% 入力トークン 1,350 1,192 11.70% 出力トークン 761 654 14% ツールエラー 2 0 – AST がプロダクション開発に重要な理由 AST ベースのコード操作の利点は、トークン効率にとどまりません: 耐障害性 : フォーマットの変更が編集を壊しません。スペース 2 つでも 4 つでも、タブでもスペースでも、構造的な編集は成功します。 精度 : ファイル内の他の類似コードを気にすることなく、変更したい箇所を正確にターゲットできます。 保守性 : 今日機能する操作は、周囲のコードが進化しても明日も機能します。 理解力 : AST パースはエージェントにコード構造の真の理解を提供し、どこでどのように変更を行うかについてよりスマートな判断を可能にします。 これは特に機能リクエストにおいて重要です。機能リクエストは Kiro で最も頻繁なクエリタイプであり、Vibe モードのトラフィックの 45%、Spec モードのトラフィックの 67.6% を占めています。これらのリクエストはコードベース全体にわたる複数のファイル変更を伴うことが多く、脆弱な文字列マッチングの複合的な影響が大きな摩擦を生み出します。これらの初期結果に私たちは興奮しており、現在プロダクションで利用可能です。

2026 年 1 月、三菱電機株式会社 電力システム製作所 電力 ICT センターで、 3 日間にわたる「AI-DLC Unicorn Gym」が開催されました。 AI 駆動開発ライフサイクル（AI-DLC）を組織的に体験する Unicorn Gym に、 33 名のエンジニアが参加。本記事では、運営を担当した電力 ICT センターの中村様が聞き手となり、実際に参加した増成様、相原様、小森様に体験を語っていただきました。 AI 駆動開発ライフサイクル（AI-DLC）とは 中村 : まず「AI-DLC って何？」と聞かれることが多いので、簡単に説明させてください。 AI-DLC（AI 駆動開発ライフサイクル）は、 AI をソフトウェア開発の中心的な協力者として位置づける新しい方法論です。「AI が実行し人間が監視する」「ダイナミックなチームコラボレーション」という 2 つの柱のもと、開始（Inception）・構築（Construction）・運用（Operation）の 3 フェーズでソフトウェア開発を進めます。 AI が要件定義から設計・実装・テストまでの成果物を迅速に生成し、人間がビジネス判断と品質の監視を行うことで、品質を維持しながら開発速度を大幅に向上させるアプローチです。詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 をご覧ください。 私たちの紹介 中村 : 改めまして、今回の座談会メンバーを紹介します。私たちは三菱電機 電力システム製作所の電力 ICT センターに所属しています。電力 ICT センターは横浜に拠点を置き、電力の安定供給を支える制御・監視システムから、クラウドを活用した次世代の電力プラットフォームまで、幅広い領域でソフトウェア開発に取り組んでいる部門です。 増成 : 私はインフラ寄りの品質管理を担当しています。アプリ開発の経験はほとんどありません。 相原 : 私は当社パッケージのグローバル開発に向けた AWS 活用やアジャイル開発を推進しています。 Kiro は公開直後から使い込んでいて — 自分では「Kiro ちゃん」と呼んでるんですが（笑）。 小森 : 私は CI/CD 環境の構築や AI エージェントツールを活用した開発の仕組みづくりを担当しています。先日、 AWS Blog で Kiro と GitLab Duo を活用した開発ワークフローの標準化について記事 を執筆しました。 エンジニアコミュニティ「YOKOHAMA UNITED」から始まった 中村 : では、今回の AI-DLC Unicorn Gym が実現した背景からお話しします。私たちの部門ではプロジェクト運営改善委員会（PMON）が中心となって「YOKOHAMA UNITED」というエンジニアコミュニティを運営しています。毎週「You 勉強会」— You は YOKOHAMA UNITED の頭文字です — を開催していて、テーマは生成 AI やクラウドなど業務に関わる技術動向が中心です。現時点でコミュニティは 600 人規模、勉強会は 110 回を超え、毎回 30〜40 名が参加するところまで成長しました。 小森 : You 勉強会がきっかけで Kiro を知った方も多いですよね。 中村 : そうなんです。 2025 年 7 月に Kiro に触れたのがきっかけでした。 Vibe Coding や Spec 駆動開発での生産性の高さに驚き、 You 勉強会で AWS の方に説明いただく機会を得ました。その事前打ち合わせで「個人の生産性向上はわかったけど、組織やチームではどう活用すればいいのか？」と質問したところ、 AI-DLC を紹介していただきました。 開催までの道のり 中村 : 最初にコミュニティのチャネルで募集をかけたときは、反応が今ひとつでした。 3 日間のワークショップは個人の裁量で参加するにはハードルが高い。そこで方針を転換して、管理職に AWS から直接 AI-DLC の説明会を開催していただきました。 増成 : 管理職の合意が得られてから再募集したら、 20 名の枠に 40 名が応募したんですよね。 中村 : そうなんです。潜在的なニーズは想像以上でした。最終的に開発環境の制約もあり、 5 チーム 33 名での開催になりました。各チームが部門内の実際の業務課題を持ち寄ってテーマを決めています。既存業務システムの改良、 SaaS 上のダッシュボード構築、 IoT プラットフォームの改善など、どれもリアルな課題です。 3 日間の進め方 中村 : ワークショップは 2026 年 1 月 14 日〜16 日の 3 日間で開催しました。初日はセミナールームにチーム毎に分かれて着席し、オープニングセッションの後、 AWS から AI-DLC の概要説明を受け、まずは共通テーマ「EC サイト構築」でハンズオンを実施しました。 相原 : 最初に全員で同じテーマをやることで、進め方のイメージが掴めましたよね。 中村 : そうですね。進め方を理解したところで、各チームの実テーマに沿って最初のステップである開始（Inception）フェーズに着手。各チームのテーブルには AWS のメンバーが 1 名専任で付き、手厚くサポートいただく形で進めました。ユーザーストーリの構築が完了したチームから順次、構築（Construction）、運用（Operation）へと進みます。 AI のアウトプットの速さは関係者を一か所に集めた上でその場で意思決定のためのアウトプットを作成することを可能にするため、通常は数週間〜数カ月かかる開発も短期間で可能にします。 チーム毎のテーマと成果 中村 : 部門内の様々なビジネスユニットの課題をチーム毎に持ち寄り、テーマを決めました。 5 チームそれぞれが 3 日間でリアルな業務課題にチャレンジしています。 チーム テーマ 成果 チーム A 既存業務システム改良 フロントエンドは React, TypeScript、データベースはPostgreSQLの構成で、既存システム処理に必要な情報の設定画面を開発 チーム B 既存業務システムのマイクロサービス化 既存システムの機能を模擬したReactベースの画面を構築。ダッシュボードを用いて、一連の業務実行可能なことを確認 チーム C IoT プラットフォーム管理画面の使いやすさ向上 AI 駆動でドキュメント分類・コンテンツ生成を行い、RAG方式のチャットボットで回答する、IT に詳しくない一般ユーザでも使いやすい管理画面を開発し、効率的なオンボーディングのデモを実施 チーム D 業務状況確認ダッシュボード開発 SAP UI5を利用しダッシュボード画面・一覧画面・詳細画面・操作ガイドを実装し、 SAP クラウド環境上へデプロイ完了 チーム E 教育プラットフォーム構築 フロントエンドは React、バックエンドは Java で構築された既存アプリに対して、オンボーディング機能を追加開発。ドキュメント管理・コンテンツ生成・チャットボット・フィードバック分析を実装し、セキュリティを確保した環境へデプロイ完了 小森 : チーム D は SAP UI5 を利用しダッシュボード画面・一覧画面・詳細画面・操作ガイドを実装し、 SAP クラウド環境上へデプロイ完了しました。2 日目時点ですでに動くものが出来上がっていました。 増成 : チーム E は短期間でこれだけのシステム構築ができたことに驚きの声が上がっていました。 中村 : どのチームも「3 日間でここまでできるのか」という手応えを感じていたのが印象的でした。 やってみてどうだった？ 中村 : では、実際に参加してみた感想を聞かせてください。増成さんはチーム A でしたね。 増成 : はい。私たちのチームでは既存システムの設定画面を開発したんですが、正直、自分が参加して意味があるのかなと思っていました。アプリ開発の経験がないので。でも終わってみたら「これは実際の開発に適用すべき」と強く感じました。短時間で大きなアウトプットが出てくるので大幅な時短ができます。ただ、適切なタイミングで適切なインプットをさせてあげる、これが難しかった。 中村 : 具体的にはどういうことですか？ 増成 : 既存ドキュメントをまとめて読ませれば、よしなにやってくれるだろうと思ったんです。そうしたら目を通すのが大変な特大ドキュメントが生成されて。本来技術的な話が出てきてはいけないフェーズなのに技術的な内容が混ざっていたり。過剰なインプットはノイズになるし、少なすぎると的外れになる。このバランスが一番の学びでした。 中村 : なるほど。 AI への情報の渡し方が鍵になると。 増成 : そうですね。あと、今回のプロセスを通じて「そういえばこういうドキュメントなかったな」という気づきがありました。現状の開発プロセスやドキュメントを見直すきっかけにもなると思います。 中村 : 相原さんはどうでしたか？事前に Kiro を使いこなしていたと聞いていますが。 相原 : はい、 Spec 駆動開発モードも使いこなし、「簡単な要件をインプットすれば Mock 画面も簡単に作れるじゃん！ Kiro ちゃんスゲー」状態の私に死角は無い…と思ってました。 中村 : 思ってた、と（笑）。 相原 : 1 日目はまだ余裕だったんです。「Kiro ちゃんは Spec 駆動以外でも要件を残せて、モブセッションにも向いてるのか、イイネ」って。ところが、チームで要件を詰め始めたら「要件ふわっとしすぎじゃね？」と。 中村 : 2 日目はどうなりましたか？ 相原 : ふわっとした要件でも Kiro ちゃんはユーザーストーリーを作ってくれるんですが、範囲が広すぎる。 AWS の方に「ユーザーストーリーが出た段階で Mock 作れますよ」と言われて作ってみたら、「あれ？これって本当に私たちが検討したい内容なんだっけ」と。要件定義に戻る。同じフェーズを何度もループする状態になりました。 小森 : 他のチームから見ても「あのチーム、2 回 Inception 回してるな」って見えてましたよ（笑）。 相原 : 3 日目の午前中まだ Inception から抜け出せてなくて、午後にようやく構築フェーズに入って「皆の衆、作業にかかれ！」と。 中村 : そこからは順調に？ 相原 : いえ、終了 30 分前に各ユニットを結合したら上手く動かなくて焦りましたが、AI-DLC の中ではちゃんと開発の過程をドキュメントに残しながら、進めているので、動かない理由もすぐリカバリーすることができ、なんとか要件をカバーするダッシュボードができました。 中村 : 最終的にはできたんですね。 相原 : はい。昔はここまでに半年かかってたので。それに、 他のチームから「手戻りですよね」と言われたとき気づいたんです。これは手戻りじゃなくて「失敗を素早く試せた」だけだと。すぐに失敗できるのって最高です 。 中村 : 小森さんのチームはどうでしたか？ 小森 : 最初にプロンプトを流し込んで Kiro からの返事が返ってきたとき、質問の多さに圧倒されました。でも「あー、確かにここって検討しないといけないよな」という検討漏れに気づけたんです。「これって必要ですか？」「必要な理由は？」とチーム内で議論が活発になって、議論するたびに開発対象への理解が深まりました。 中村 : 関係者全員で議論する場が強制的に作られる、というのは面白いですね。 小森 : そうなんです。「この機能は今は不要だから削ろう」「これは後で必要になるから優先順位を下げて残そう」といった判断も、全員がその場にいるので納得感を持って進められました。一方で、 AI がドキュメントをどんどん生成するので、気がつくと大量のドキュメントが溜まっていて。 AI 用のドキュメントと人間が後で確認するドキュメントを分けるなど、環境整備が必要だなと感じました。 中村 : 成果物としてはどこまでできましたか？ 小森 : 我々のチームでは既存の Web アプリにヘルプツールを開発して埋め込みましたが、実働ほぼ 2 日で見せられるクオリティにまで持っていけたのは強力でした。しかも我々のフレームワークを理解した上で作られていたのには驚きました。 AI-DLC を体験したことによる変化 中村 : AI-DLC を体験したことで、どんなところが変わっていくと思いますか？ 増成 : 従来の開発では生成 AI を個人で利用することが中心でした。今回、AI-DLC Unicorn Gym を体験できたことで AI を中心に据えて上流の要件定義から行うことができたので、今までプログラム製作を行ってこなかったメンバーも簡単に UI のイメージを作れることがわかりました。これによりお客様への価値提供に直接関わるメンバーが増やすことができ、そのスピード、生産性も向上できることからより大きな力を得ることができそうです。 相原 : 今まで生成 AI を使っていなかったメンバーが使うようになったのが大きいです。それに、他の人がやってるプロンプトの書き方とか便利な利用方法も学ぶことができました。AI-DLC Unicorn Gym ではモブワークでメンバー間のディスカッションが活発になり、チームのコミュニケーションも変わったと感じています。また、モブワークによる技術継承の効果もありそうだと感じています。今までのドキュメント製作者、レビュー者というある意味対立する立場から、一緒の方向を向いて進んでいく仲間としてビジネスを推進できるようになるんじゃないかな。 ⼩森 : 確かに AI-DLC で上流設計の要件定義にみんなで参画したのも大きい。要件を決めるところに入ったことで、いわゆる意思決定に参画することになり、皆が自分事になって開発に取り組むことができていました。チーム、組織のマインドセットも変えていけそうな気がします。 ハピネスドアで見えた 3 日間の感情曲線 中村 : 連日の熱い議論を見て、この熱量を可視化したいと思い、アジャイルマネジメントシステム Management 3.0 のプラクティス「ハピネスドア」を導入しました。ドアや白板に 4 段階（Very happy, happy, unhappy, sad）の絵文字付箋を貼っておき、各メンバーが自分のコメントを書いた付箋をそこに貼っていくもので、リアルタイムの満足度を可視化する手法です。 相原 : チーム毎に付箋の色を変えてたのが良かったですよね。チーム単位の温度感が一目でわかりました。 中村 : 3 日間のエンゲージメントスコア（4 点満点）は 3.3 → 3.1 → 3.6 と推移しました。 1 日目：生成 AI のアウトプットの速さに驚いた。すごい！ — Surprised!! 2 日目：AI の返しが速すぎて、人間側の判断・仕様検討が追いつかない。ちょっと気分ダウン — Tired!! 3 日目：限られた時間の中でゴールを決めて進み、各チーム成果を出せた — Very happy!! 増成 : 2 日目のスコアが下がったのは、どのチームも「AI は速いけど人間が追いつかない」という壁にぶつかったタイミングでしたね。 アンケート結果 参加者全員に実施したアンケートでは、以下の結果が得られました。 働き方の変化 : 90% 以上が「AI-DLC は働き方を変える可能性が高い」と回答 生産性改善 : 従来の手作業中心の開発と比較して、参加者の体感値として「30〜40 倍の生産性がある」と回答 他の方への推薦 : 97% が「第二回開催を他の方に勧めたい」と回答 3 日間という短い期間でしたが、参加者が AI-DLC の本質的な価値を実感できたことが数字に表れています。 これからの挑戦 中村 : 最後に、今後の話をさせてください。今回参加した 33 名を起点に、まずは各チームが自分の組織に持ち帰って共有する場を設けます。すでに次のテーマ選定にも着手していますし、三菱電機グループの部門横断 AWS ユーザーコミュニティ「 MAWS-UG 」への発信や、社内の年次イベントである「Melco AWS Day」へ登壇も決まっています。 YOKOHAMA UNITED の 600 人のコミュニティ、さらには MAWS-UG を通じてグループ全体へと広げていきたいですね。 増成 : 「AI-DLC いいぞ、いいぞ！」と啓蒙活動にも力を入れていきます！ 相原 : 早速、AI-DLC を実プロダクトの検討フェーズに適用できないかトライしてみています。絶賛 Inception フェーズにいます。失敗を素早く試せるのが AI-DLC の良さなので、またループするかもしれませんが、チャレンジしてみようと思っています。 小森 : AI-DLC をきっかけに AI エージェントツールを初めて使った方も多かったので、ここからがスタートですね。どんどん進めていきたいです。 中村 : ユニコーンを創るジムでしたから。ここから先が本番です。 座談会メンバー 中村 信夫 電力デジタルエナジーシステム開発部 品質管理課。品質管理業務を担当する傍ら、プロジェクト運営改善委員会（PMON）を立ち上げ、ツール・環境を提供。コミュニティ「YOKOHAMA UNITED」も PMON が運営。 増成 謙汰郎 電力デジタルエナジーシステム開発部 品質管理課。品質管理の一環で生成 AI を中心とした様々な技術やツール・環境を活用し、業務適用設計や技術検証を担当。 小森 裕之 電力デジタルエナジーシステム開発部 システム基盤課。電力 ICT センター内の全ビジネスユニットの開発・運用に貢献するため、 ITIL4 に準拠した専用プラットフォームの開発に携わり、 CI/CD 環境の検討・構築・導入や AI エージェントツールを活用した開発の仕組みづくりを担当。 相原 祐太 Digital Energy 事業統括センター準備室 開発推進課。当社パッケージ BLEnDer のグローバル開発に向けた AWS 活用・アジャイル開発適応・プロダクト設計/開発/推進担当。 著者プロフィール 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。2022 年から三菱電機グループを支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

この記事は、合併前の旧ブログに掲載していた記事（初出：2020年11月25日）を、現在のブログへ移管したものです。内容は初出時点のものです。こんにちは。LINE Growth Technology福岡...