19 Jul 2025

Kiroとコンテキストエンジニアリングの時流

Kiro(kiro.dev)は、AWSが開発したIDE型のコーディングエージェントです。CursorやWindsurfのようなVS Codeフォークエディタに分類されます。現在はパブリックプレビュー中で、サインアップするとKiroでClaude Sonnet 3.7 とClaude 4 Sonnetを利用できます。

Kiroの特徴は、スペック駆動開発、エージェントフック、ステアリングファイルといった独自の機能を通じて、ソフトウェア開発のライフサイクル全体を支援します。それぞれ見ていきましょう。

スペック (Specs)駆動開発

Kiroの中核をなすのが「スペック＝仕様書」機能です。これは、ユーザーが入力した大まかな指示（例：「ユーザー認証機能を追加して」）をもとに、AIが「要件定義」「設計」「タスクリスト」という3段階のドキュメントを自動で生成するものです。 Markdownファイルが.kiro/specs/${task}/配下にタスク単位で生成されます。これらのファイルをエージェントがタスクを実行する際に常に参照しています。

このアプローチは「スペック駆動開発」と呼ばれ、AIがコーディングを始める前に、まず「何を作るべきか」を明確に定義することを目的とします。AIが途中で見当違いのコードを生成してしまう問題を未然に防ぎ、手戻りのコストを削減できます。

Kiroの提唱するスペック駆動開発は、既存のAIコーディングにおける「Planモード」やプロンプトを駆使したオーケストレーションフローをIDE全体に拡張したものといえます。

コーディングの前に、正確で充実したコンテキストドキュメント群を用意し、AIエージェントを正しい方向に導きます。これはファイルを指定してAIエージェントに渡すコンテキストを管理することで実現されています。ここをIDEごと自動化するのは良いアイデアです。確かに私もAIエディタのチャット入力欄は狭いので、一度エディタでMarkdownを用意してそこで指示を書いていました。

そもそもAIエージェントのコード編集はハイコンテキストに空気を読んで自律実行してくれますが、コンテキストの読み違いで開発者の意図と違う変更も多発します。スクラッチからのアプリ開発ではこの軌道修正のコストは低いのですが、対象のアプリのロジックが積み重なるごとに1つのステップの読み違い発生率とそれを元に戻す手戻りコストが雪だるま式に増えていきます。

KiroはSpec機能で自動生成されたドキュメントを常に参照してタスクを1ステップずつ慎重に進行していきます。意図と違った変更は開発者が事前に介入して軌道修正を施します。

このフローが冗長だと感じるならおそらくKiroのSpec機能がワークするようなプロジェクトではありません。基本的にこれは人間の開発者間で行っていた根回しやレビューをAIとも行うようになった、それ専用のツール化をしたという状況です。

このドキュメントを作成してそれを常にAIエージェントに与え続けるアプローチは、他のAIエディタでドキュメント駆動な開発していた人たちにはお馴染みの方法です。例えばClineやRoo CodeのMemory Bankプロンプトは結果から仕様ドキュメントを逆算して生成して、それを次のタスクに流用します。

またGitHub Copilot Workspace(2025年5月21日テクニカルプレビュー終了) はこの要件定義から設計-実装に移行するシステム開発ロールプレイをウェブアプリベースで実現していました。

Kiroはこの形式化＋自動化をIDEのレールに乗ってサポートしているのが最大の利点です。しかしコーディング実行の部分はあまり差別化要因ではないので、仕様だけKiroで書いてClaude Codeに流せばいいという考え方もあります。これは現時点では補完的に機能しており理にかなっています。

一方、Kiroのような重厚なプランニングフェーズを、CLAUDE.mdやコマンド・フックを駆使して、ドキュメント構造化して自力で運用することもできます。実際Claude CodeやRoo Codeのパワーユーザーはこのような方法を実践していました。

タスクのMarkdownを作成してチェックボックスを埋めるように単一のAIエージェントフローを回していくのは、DevinやManusがエージェント製品レベルで実証し、Roo Codeの「Boomerang Tasks（ブーメランタスク）」やClaude CodeのTaskツールで開発者が日常的に行っていることです。

Claude Codeのベストプラクティスにも中間Markdownを書き出し、そこをベースに開発をするTIPSがあります。

複雑なワークフローにはチェックリストとスクラッチパッドを使用するコードの移行、多数のリンティングエラーの修正、複雑なビルドスクリプトの実行など、複数のステップがある、または網羅的な解決策を必要とする大規模なタスクの場合、ClaudeにMarkdownファイル（またはGitHubのIssue）をチェックリストや作業用のスクラッチパッドとして使用させることで、パフォーマンスを向上させることができます。たとえば、多数のリンティングの問題を修正するには、次のようにします。

* Claudeにlintコマンドを実行させ、結果として生じるすべてのエラー（ファイル名と行番号を含む）をMarkdownのチェックリストに書き出すように指示する
* Claudeに各問題を一つずつ修正し、検証するように指示する
https://www.anthropic.com/engineering/claude-code-best-practices

背景にあるコンテキストエンジニアリング

なぜこのようなドキュメント駆動の開発手法が必要なのか？　という部分に立ち返ると昨今注目の集まる「コンテキストエンジニアリング」の課題が見えてきます。

Google の Addy Osmani 氏はコンテキストエンジニアリングをプロンプトエンジニアリングの進化形であると説明します。

従来のプロンプトエンジニアリングでは、LLM に入力するテキスト（＝プロンプト）を工夫して精度を高めてきました。しかし、AI エージェントが扱うデータはもはや単なるテキストではありません。モデルの応答、内部ツール呼び出し、実行結果、メタ情報──それらすべてがメッセージ形式で構造化され、すべてが会話としてやり取りされています。

構造化されたデータなので編集操作もプレーンテキストよりも複雑な手続きを伴います。プロンプトエンジニアリングが「補完したいテキストから逆算して入力テキストを学習データの規則性に沿ったデータに変換する」というようなものであるなら、コンテキストエンジニアリングは取り扱う単位がエージェントに与える会話構造データということになります。Garbage in, garbage out原則により、複雑な会話構造を出力したいのなら、入力もどんどん複雑になっていくのは自明です。

このような現状をとらえた言葉がコンテキストエンジニアリングです。プロンプトエンジニアリングをAIエージェント向けに再定義して不足した部分を補う役割を担っています。

Kiro の公式ブログ「Kiro and the future of AI spec-driven software development」でも指摘されているとおり、バイブコーディング（ここでは対話のみでAIにコードを書かせる手法）は小規模なら効果的でも、プロジェクト規模・開発期間が大きくなるほど意図しない改変や手戻りが増えます。そこで事前に仕様を明文化し、AIに常に正しいコンテキストを与えることが欠かせません。

Kiroが採用するスペック駆動開発は、この流れの中でのコンテキストエンジニアリングの実践例の一つになります。なのでこれからも類似ツールや既存製品のアップデートに取り入れられる余地があります。

[1]: 先のAddy Osmani 氏の別記事”The AI-Native Software Engineer”においてもAI ネイティブな開発ワークフローとして「仕様駆動開発（Spec-Driven Development）」に言及があります。

余談：EARS 表記とは？

Kiroで採用されている「EARS 表記 (EARS Notation)」とうのは、Easy Approach to Requirements Syntaxの略で、システムへの要求を文章化する時の形式の構文です。ロールス・ロイス社でジェットエンジンの制御システムに関する耐空性規制を分析する過程で開発されました。

形式は[While <前提条件>,] [When <トリガー>,] the <システム名> shall <システム応答>のような形を持ちます。実際にKiroに生成されたrequirements.mdの例がこちらになります。

1. WHEN a user hovers over non-clickable elements in the Settings menu THEN the system SHALL display the default cursor.
2. WHEN a user clicks "Copy URL to clipboard" in Settings => Share code THEN the system SHALL display a confirmation message with the default cursor on hover.
3. WHEN a user hovers over clickable elements in the Settings menu THEN the system SHALL display the pointer cursor.
4. WHEN the cursor style changes after copying to clipboard THEN the system SHALL maintain consistent cursor behavior across all supported platforms (Windows/Chrome, MacOS/Desktop).

ウェブ開発の文脈でいうとCucumberのGherkinに近いです。Gherkinはテスト自動化ツールのユーザーシナリオを表現するDSLであるのに対し、EARSはシステムに要求するルールのための文章形式です。

Kiroで採用されている背景としては、Amazon社内で実際に使われている可能性があります。ブログにはTLA+やP言語のような形式仕様言語について触れられていますが、要求ドキュメントを社内でどう管理しているかについては明言されていませんでした。

自然言語によるHooks

Kiroのフック（Hooks）機能は、IDE内で特定のイベントが発生した際に、あらかじめ定義したAIエージェントのアクションを自動で実行する仕組みです。たとえば、ファイルの作成・保存・削除時や、手動でトリガーを実行したときなどに作動します。

Claude Codeでは特定のシェルコマンドを実行して一連の手続きを走らせますが、Kiroのフックでは「テストファイルをソースコードの変更に合わせて自動的に更新する」などの処理を自然言語で記述できます。この方式は柔軟性は高いものの、想定されるユースケースはClaude Codeと異なります。

Claude Codeが主にガードレール用途を想定しているのに対し、Kiroのフックはコーディング支援を拡張する機能という位置づけです。ただし両者は排他的ではなく、「コード品質フック」のように抽象度の高いガードレール処理を自然言語で設定することも可能です。

Steeringで追加のコンテキストを追加する

ステアリング (Steering) 機能は、プロジェクトに関する知識を Markdown ファイルとして管理する仕組みです。

これは CLAUDE.md や AGENT.md に代表されるコンテキスト用メモリファイルと同じ位置付けです。Kiro では .kiro/steering/ 配下のファイルを通じて、プロジェクトの永続的な知識を保持できます。

「Generate Steering Docs」ボタンを押すと、初期状態で「product.md」（製品の目的）、「tech-stack.md」（技術スタックとフレームワーク）、そして「structure.md」（プロジェクト構造と規約）の 3 つの基本ファイルが自動生成されます。これはClaude Codeでいう/initコマンドにあたります。

ユーザーは独自のステアリングファイルを追加して、プロジェクトの要件に合わせて拡張できます。各ファイルには「常に含める」「条件付きで含める（特定のファイルパターンに一致した場合）」「手動で含める」の 3 つのモードを設定できます。これは他のAIエディタにおけるルール設定と同じイメージです。

Kiroを使ったプロジェクト例

Kiroの実証プロジェクトとして、"How Kiro helped me code a game"という記事があります。

これは約2万行規模のブラウザゲームで、Bun Serve でサーバーが書かれていてDynamoDBにアクセス、フロントエンドが Vue.jsで構築されています。このゲームの開発工程がチュートリアル化されてドキュメントにあります。

以下のGitHubリポジトリでソースコードが公開されており、実際に開発に使用されたステアリングファイルを見ることができます。

深掘り(1): Q Developer CLIとの関係

KiroのバックエンドはおそらくQ Developerと共通です。OAuth認証アプリとしてログイン画面に表示されていました。

また、Kiroリリース直後にQ Developer CLIの無料ユーザーのBedrockモデルアクセスも不安定になっていることからリソースも共有していると思われます。

またDeveloper AdvocacyのNathan PeckがHackerNewsでユーザーたちの質問に答えています。プロジェクトの内情などコメントされていて面白いです。

Kiro: A new agentic IDE | Hacker News

Hacker News

ここでCLIバージョンの話も出ていますが、Q Developer CLIとは方向性が違うようです。事実、開発しているチームも異なるようですし、Kiroの中でQ Developer CLIは動作せず連携もしません。以下にIssueもあります。

深掘り(2): 内部Kiro Agent拡張

さらに筆者はKiroのMac版を対象にパッケージに含まれるファイルを解析しました。そこでKiroはCode OSSのデスクトップアプリ以下にKiro Agentという名称のVSCode拡張パッケージを内包していることを確認しました。以下のパスにあります

/Applications/Kiro.app/Contents/Resources/app/extensions/kiro.kiro-agent/

調べてみると、これはKiroの持つエージェント機能を構成するコアコンポーネントであることが分かりました。VSCodeでいうと「Cline拡張」の部分にあたります。

Kiro Agentは依存パッケージとしてContinue、LangChain、埋め込みモデルXenova/all-MiniLM-L6-v2、言語パーサーのTree-sitterを含みます。 ContinueはClineのようなレイヤーのOSSで、VSCode拡張が公開されています。

KiroではチャットのGUIをそのまま使っているというわけでなく、内部APIを呼び出しコーディングエージェントを構築していると推測します。all-MiniLM-L6-v2やTree-sitterもContinueで使われている依存です。ローカルでのコードのインデックス化と埋め込み用のチャンク作成に活用されています。

LangChainはContinueの依存には含まれないので独自にKiroのスペック駆動開発のワークフローを構築するフレームワークになっているようです。ここから分かるのはKiroが実現する機能はプロンプトベースではなく手続き的なプログラムで補助されているということです。そのため既存のツール＋プロンプトで同じものを再現するのは難しくなってくるでしょう。

実践評価：Kiroの「スペック」はタスクにどう影響するのか？

Kiroの「スペック駆動開発」は、本当にAIのコーディング精度を高めるのでしょうか？この疑問を検証するため実際に評価を行いました。動作確認のために簡単なウェブアプリを新規に作るのは、既存のエージェントでのドキュメント駆動開発の経験から明らかです。そこで本記事では、より実践的な環境を想定してSWELancerベンチマークを参考にした評価を実施します。

著者は最近LLMのコーディングベンチマークの情報をよく調べています。そこでOpenAIの最新のベンチマーク論文である「SWE-Lancer」を知りました。

SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering?

We introduce SWE-Lancer, a benchmark of over 1,400 freelance software engineering tasks from Upwork, valued at \$1 million USD total in real-world payouts. SWE-Lancer encompasses both independent engineering tasks--ranging from \$50 bug fixes to \$32,000 feature implementations--and managerial tasks, where models choose between technical implementation proposals. Independent tasks are graded with end-to-end tests triple-verified by experienced software engineers, while managerial decisions are assessed against the choices of the original hired engineering managers. We evaluate model performance and find that frontier models are still unable to solve the majority of tasks. To facilitate future research, we open-source a unified Docker image and a public evaluation split, SWE-Lancer Diamond (https://github.com/openai/SWELancer-Benchmark). By mapping model performance to monetary value, we hope SWE-Lancer enables greater research into the economic impact of AI model development.

arXiv.orgSamuel Miserendino

SWE-Lancerは、実際のフリーランス市場（Upwork）で発注された、OSSのバグ修正タスクをまとめたデータセットです。タスクの難易度や成果の度合いを「報酬額」という金額の数字で出すことでモデルの能力が測れるという巧妙な枠組みです。実在するExpensifyという米国の経費管理SaaS企業の公開リポジトリが使われています。

これは我々でも自由にチェックアウトして、SWELancerのベンチマークのコードを参考に同じタスクを再現できます。 Expensify/Appのモノレポはベンチマーク時点で数68万行の規模のTypeScript中心コードがあります。

これはKiroが対象とする実世界の規模のプロジェクトの例として最適です。難点としてはこのリポジトリはフロントエンド（WebやReact Native）のみの構成で、サーバーサイドで発生するようなデータベースやバックエンド処理の領域は含まれていないことです。

今回はSWE-Lancerのデータセット(tasks.csv)から、issues-343の設定画面におけるUIのバグ修正のタスクを１つ選びKiroにやってもらうことにします。これはReactコンポーネント３ファイル3箇所を修正するだけの軽微なタスクですが、68万行のモノレポから特定の修正箇所にたどり着いてもらう必要があり、コンテキスト処理能力も試されます。ただし検証時点（2025/07/18）でKiroのClaude Sonnet 4モデルはダウンしていたので3.7で行いました。

まずKiroが修正する対象となるexpensify/Appとテストデータに使うSWELancer-Benchmarkの2つのレポジトリを取得します

https://github.com/expensify/App/
https://github.com/openai/preparedness
- 注：以前はhttps://github.com/openai/SWELancer-Benchmarkにありましたが移動しました

issues/343には以下のようなファイルがあります。

❯ ls preparedness/project/swelancer/issues/343
flow.mitm    issue_data.json           revert_command.txt  user_tool.py
commit_id.txt  git_tag.txt  issue_introduction.patch  test.py

commit_id.txtがバグ修正対象のコミットです。expensify/Appをこの時点までgit checkoutしてissue_introduction.patchをgit applyすることで、バグが再現する状態にできます。

git clone https://github.com/openai/preparedness
git clone https://github.com/expensify/App/ && cd App
git checkout $(cat ../preparedness/project/swelancer/issues/343/commit_id.txt)
git apply ../preparedness/project/swelancer/issues/343/issue_introduction.patch

テストするためにはexpensify/Appの開発サーバーを起動する必要があります。これは通常のNode.js開発プロジェクトと同じです。swelancerにDockerfileがあるのでそれを使う方法もありますが、今回は対象のAppをエディタから細かくデバッグしたかったためローカルに環境をつくりました。ポイントとしてはdev.new.expensify.comを127.0.0.1に向けHTTPSでアクセスできるよう証明書を登録するということです。README通りに実行するだけです。

 asdf set nodejs 20.15.1
 node -v
v20.15.1
 npm install -g [email protected]
 npm i
 npm run setup-https
 # /etc/hosts で127.0.0.1 dev.new.expensify.com
 npm run web
 # https://dev.new.expensify.com:8082/ でテスト可能

Appの実行ができるようになったので、早速Kiroからコードベースを開いてタスクを実行していきます。 issue_data.jsonがタスクの内容です。今回はこれをKiroに入力する初期のメッセージにします。

❯ cat issue_data.json | plamo-translate
{
    "価格": 500.0,
    "タイトル": "[支払い保留 2023-10-20] [$500] 設定 - メニュー項目をクリックできないがポインターカーソルは表示される",
    "issue_repo_steps": "実行した操作: 1. 設定 => コードを共有\r\n2. "URLをクリップボードにコピー"をクリック\r\n3. コピーされたメッセージが表示され、その上にマウスカーソルを合わせるとクリックできないがポインターカーソルが表示される\n\n期待される結果: デフォルトのカーソルが表示されるべき\n\n実際の結果: なし",
    "_issue_id": "28565_1001"
}

[2]: https://github.com/pfnet/plamo-translate-cli

実験：Specモード vs. Vibeモード

Kiroには、緻密な計画を立てる「Specモード」と、計画を省略して対話的に開発を進める「Vibeモード」の2つがあります。この2つのモードで同じバグ修正タスクを実行させ、その成果物を比較することで、「スペック」の有効性を検証します。

Specモードでの実験

まず、Specモードでタスクを実行します。Kiroは指示を分析し、「要件定義」「設計」「タスク」のドキュメントを自動生成しました。

❯ ls .kiro/specs/cursor-behavior-fix/
design.md  requirements.md  tasks.md

requirements.mdには2300文字程度で

Settingsメニューでのカーソル動作に関する問題を修正する機能です。現在、URLをクリップボードにコピーした後に特定の非クリック可能な要素にホバーすると、カーソルが誤ってポインター（手の形）として表示される

と正しくソースコードのIssueを分析して問題を記述していました。

design.mdにはMermaidとソースコード例を使ったDesignDoc相当の4300文字の文章が記述されていました。ここで技術的なHOWが「確認メッセージコンポーネントに cursor: default のCSSスタイルを追加する」のように明記されます。

最終的にtasks.mdには「調査 → 分析 → 実装 → テスト → 検証」という5段階の階層型のタスクリストが作成されました。以下の順で進めるとのことです

調査: カーソル動作の問題を再現・特定
分析: スタイリング構造とプラットフォーム固有の動作を分析
実装: 確認メッセージコンポーネントに明示的なカーソルスタイルを追加
テスト: カーソル動作の単体テストを作成
検証: Windows/ChromeとmacOS/Desktop両方で動作確認

これをKiroのエディタ上で「Start Task」をクリックするたびに進行状況をチャットに出力しながらコードを編集していきます。とりあえず順番に5段階目まで実行してもらいました。成果物を確認してみると対象にテストコードを追加していたのが印象的でした。

❯ git st
## HEAD (no branch)
A  .kiro/specs/cursor-behavior-fix/design.md
A  .kiro/specs/cursor-behavior-fix/requirements.md
A  .kiro/specs/cursor-behavior-fix/tasks.md
A  cursor-behavior-analysis.md
A  platform-specific-cursor-behavior.md
M  src/components/BaseMiniContextMenuItem.tsx
M  src/components/ContextMenuItem.tsx
M  src/components/Pressable/PressableWithDelayToggle.tsx
A  tests/manual/CursorBehaviorVerification.html
A  tests/manual/CursorBehaviorVerificationScript.js
A  tests/manual/PlatformCursorVerification.md
A  tests/manual/PlatformCursorVerificationReport.md
A  tests/unit/ConfirmationMessageCursorTest.tsx
A  tests/unit/ContextMenuItemCursorTest.tsx
A  tests/unit/CrossPlatformCursorVerification.tsx
A  tests/unit/CursorBehaviorFixVerification.md
A  tests/unit/MenuItemCursorTest.tsx
A  tests/unit/PlatformCursorBehaviorTest.tsx
A  tests/unit/PlatformCursorVerificationReport.md

ただ筆者がnpx jest tests/unit/ConfirmationMessageCursorTest.tsxと単体で手動実行してみるとFAILしていました。作業履歴のチャットを見るとjestコマンドがうまく動かなくて回避策としてHTMLファイルを作って試行錯誤した痕跡のようです。このようなリポジトリを散らかすのはタスク完遂をがむしゃらに目指すAIエージェントのチャーミングなところですが、ファイルを消すより増やされる方がいくらかマシです。

とはいえKiroによると「I've successfully completed the task」と修正が完了したと報告があったので、これをswelancerサイドから受け入れテストをします。swelancer/issues/343/test.pyはPlaywrightでブラウザを立ち上げテストシナリオを自動で実行してくれます。これがパスするかを確認するのが良いでしょう

cd swelancer
pip install playwright
pytest issues/343/test.py

無事テストはパスしました。しかし、ここからが検証の本番です。はたしてこの重要なスペック駆動開発はタスクの成否にどの程度影響を与えているのでしょうか？

Vibeモードでの実験

Specモードでの結果を踏まえ今度は同じタスクをVibeモードで実行して２つの結果を比較してみます。現在の変更はパッチファイルとして保存しておきます。そして再度バグを再現するようにコミットを戻します。

❯ git diff src/components/ > kiro-spec.patch
❯ git clean -df
❯ git restore .
❯ git apply ../preparedness/project/swelancer/issues/343/issue_introduction.patch

新規チャットを開き、Vibeモードに切り替え、Specモードと同じ文章を入力してタスクを開始します。

Kiroは最初の１ターンで問題を分析し、コードベースを読み込んでチャットの応答で要件を尋ねてきました。Vibeモードでも基本的にSpecモードと同じ工程を内部的に辿っているようです。

次に「その修正を行ってください」と返信したところ、Kiroはソースコードの修正を最後まで行ってくれました。今回はSpecモードのように多段階のタスク実行を行っていないので、すぐに修正が完了しました。同じく受け入れテストも実施したところ問題はありません。

しかし先ほどのSpecモードでの変更とアプローチが異なるようにみえるので、こちらの差分も取ってClaude一門とは対極にいるo3 APIさんに中立レビューしてもらいます。以下がその結果です。

両パッチとも「コピーが成功したあと、もうクリック出来ない要素なのにポインターカーソル（手）が残ってしまう」という不具合を意識した変更ですが、実装のアプローチと効果に差があります。

1. kiro-vibe.patch  
   • `ContextMenuItem.tsx` 内で  
     - 成功状態（`!isThrottledButtonActive`）になったら `disabled` を立て、  
     - さらに `shouldUseDefaultCursorWhenDisabled` を `true` にして明示的にデフォルトカーソルを使わせています。  
   • これにより、成功後はコンポーネント自体が非活性扱いになり、内部ライブラリが持つ「disabled なら矢印カーソルを出す」ロジックが確実に働くため、カーソル問題は解消されます。  
   • ただし `PressableWithDelayToggle.tsx` から `!isActive && styles.cursorDefault` を外しているので、別の「非アクティブ時は矢印に戻す」処理が失われる副作用があります（他の画面で小さな退行が起こる可能性）。

2. kiro-spec.patch  
   • `interactive` プロパティを削除しつつ、`wrapperStyle` に直接 `styles.cursorDefault` 相当を注入する形です。  
   • しかし `interactive` が無くなるとデフォルト値（true）のまま動き、内部ロジック上は「まだインタラクティブ」と判定され続けます。  
   • その結果、上位の Pressable が `cursor: pointer` を付けてしまい、スタイルの競合次第では矢印に切り替わらないケースが残るため、バグは完全には解決しません。

結論  
• バグを確実に解消できるのは **kiro-vibe.patch** です。  
• kiro-spec.patch は状況によって矢印に変わり切らない可能性があるため不完全です。  
• なお、vibe 版で削除した `styles.cursorDefault`（PressableWithDelayToggle など）が他の UI に影響しないか追加確認をおすすめします。

意外なことにVibeモードのパッチの方が高評価でした。何回か、繰り返してみましたがこのタスクにおいては概ねVibeモードの方がo3さんには好まれていました。

機能の目的としてはSpecモードの方がSteeringでコンテキストを補強して高精度に実施するように期待しますが、今回のようなマイクロタスクには寄与しないということかもしれません。その場合、単にモデルの単一ファイル内のコンテキストで論理的な編集能力に左右されており、Specファイルはノイズになっていそうです。

しかしVibeモードではテストコードは書かれていません。「テストを書いてください」とこちらで指示する必要があります。Specモードでは自動でテストの記述がタスクに含まれていました。このようにKiroが自動で行う範囲にも差が出ました。

また今回のバグ修正タスクはどちらのモードも成功しました。よりステップの分解が要求されるような、複雑で難易度の高いタスクを割り当てて追加で検証する必要がありそうです。

おわりに：コーディングエージェント開発の新たなフェーズ

実験結果のまとめ

本記事では、Kiroのスペック駆動開発を中心に、SpecモードとVibeモードの比較をSWELancerベンチマークを用いた実践検証を通じて行いました。KiroとClaude Sonnet 3.7において分かったことは以下です。

小規模なバグ修正タスクでは、緻密な仕様策定よりもインタラクティブなVibeモードの方が効率的に完了できる場合がある
テスト／ガードレール自動化はSpecモードの強みだが、効果的なタスクが限定される
コンテキストを処理した後のコーディング以降はモデル単独の性能に依存する

現在のコーディングエージェントの限界

現在のコーディングエージェントは2024年のClaude 3.5 Sonnet時代に確立された「Tools（Function Calling）でファイル操作を繰り返すアーキテクチャ」が根幹にあります。この路線でエージェントの性能上げるには「モデルのコード編集精度による改善」と「コンテキストウィンドウ拡大による試行回数」という2軸が見込まれていました。

しかし、Claude 3.5 Sonnetの登場から1年が経過し、モデルのコード編集精度を測るSWEベンチマーク系のスコアは飽和しつつあります。そしてスコアの上昇が必ずしもコーディングタスクの成否につながるわけではないことが繰り返されるモデルのアップデートサイクルで分かりました。

コンテキストウィンドウ拡大による試行回数もそうです。理論上プロジェクト内のより多くのソースコードを読み込んで、より多い回数のツール呼び出しができるGemini 2.5 Proでも、他のモデルを上回るようなコーディング性能を発揮するまでには至っていません。

エージェント開発ベンダー各社もそれぞれリモート化やBest-of-Nなどの並列実装のアプローチを取り入れるなど新たな模索が続いています。

Devin vs Cursor Background Agents: 完全自律型AIエージェントの性能比較

はじめに Cursor のBackground Agentsが無事BETA Preview になったので「Devinとどの程度たたかえるのか？」という疑問が湧いてきました。そこでTypeScriptのクイズ101問をすべて解くというタスクでDevinと戦ってもらいます。ここにスーパーサブのClaude Code Actionさんも参加してもらって三つ巴にします。チャンピオンを決めようや・・・お題はexercism/typescriptのリポジトリを筆者がエージェントタスク向けにフォークしたものを使います。Exercismはプログラミング学習サイトで、GitHubで公開している問題集とテストコードはAider PolyglotやRoo Codeなど実際のエージェント製品のベンチマークで使用されており、エージェント同士の比較に適しています。 GitHub - laiso/exercism-typescript: Exercism exercises in TypeScript.Exercism exercises in TypeScript. Contribute to lais

laisolaiso

タスク分割アプローチの有効性

Claude Codeリリース当初は内部Taskツールでのステップ実行の機能を持たず、現在よりタスクの実行は短時間で直線的でした。しかしDevinやManusなどの有望なエージェントの実例によって内部TODOリストのアプローチが有効であることが分かると積極的に取り入れられ、Claude 4のモデル開発も巻き込んで、long-running tasksの改善やextended thinking中のツール呼び出しなど、エージェントによるより長いタスクを高精度で自律実行できるように進化しました。

この動向は示唆的で、ことコーディングエージェントに関しては短いコンテキストでタスクを分割してトークンの続く限りツール呼び出しをしてやり直すアプローチが有効であったということです。

その結果がClaude CodeとMAXプランを使ったAgenticコーディングの流行に現れていますが、これは文字通り富豪的なアプローチで長続きはしないでしょう。しかし金の弾丸（金をかけたら問題が解決する）が発見されたことには価値があります。

今後の展望：コンテキストエンジニアリングの重要性

筆者の今後の展望としては、AIコーディングツールやモデル自体の開発競争から、開発者ユーザー側でのアーキテクチャやワークフロー構築を試行錯誤するフェーズに移行し、各ツールの特徴を活かした使い分けが求められるようになると感じています。それがコンテキストエンジニアリングというトレンドに内包されているのかもしれません。

KiroはAIエディタとして登場しましたが、本記事で触れたように、焦点はツール呼び出しのプリミティブなコーディングエージェントレイヤーではありません。むしろ、そのレイヤーに接続するまでのコンテキストエンジニアリングのワークフローに主軸があります。

「スペック駆動開発」は、一見すると、かつてのアジャイル開発の対極にあった「ウォーターフォール・モデル」への回帰のように映るかもしれません。また形式言語や要求記述といった要素を駆使したシステム開発は、バイブコーディングとはかなり異なる価値観を持つように思えます。 AIコーディングという生産性に優れ予測不可能な暴走機関車に対応するために、かつての開発モデルに新たな価値を見出す「技術の螺旋状の進化」がここでも起こっているのかもしれません。

AIツールや技術トレンドへの向き合い方

「毎週新しいAIツールが登場してキャッチアップに時間が取られて大変だ」という意見もあります。コンテキストエンジニアリングも来月にはまた別の話題を追いかけているのだろうと評されそうです。

しかし、これは昨今突然出てきたトレンドというわけではなく、Claude 3.5とClineの時代(とはいっても2025年初頭)からコンテキストウィンドウやMemory Bankの議論はありました。コンテキストエンジニアリングという広めやすいラベルがついただけに過ぎません。

技術トレンドに関しては新しく出てくるツールやプロダクトの名前やブランドに惑わされずに、その背景課題や基礎技術に関心を持つのをおすすめします。ツールは変わるが課題は変わらないのです。

さて、そのようなAIツールのキャッチアップに消耗している方は、ぜひ当サイトの更新をメール購読していただければと思います。筆者はトレンドに対して保守的・懐疑的に評価しますので、SNSでシェアするにはインプレッションの乗らないつまらない結論になることは多いのですが、変化しやすいトレンドの表層の部分はスキップして、”毎週”の部分が”毎月”になる程度には貢献できるでしょう。