はじめに
2025年7月に Kiro がプレビューリリースされ、2026年5月に Amazon Q Developer の新規サインアップが停止された。「kiroはQ Developerと何が違うんですか？」という質問を時々お客様から受けるので書いてみました。
一言で言うと、「超進化しました。」 です(笑)
Q Devecoperをカーナビだとするとkiroは自動運転車 です。
この記事では、LLM 活用の進化段階を整理し、各段階で人間に求められるスキルがどう変わってきたかを考察します。そして「ハーネスエンジニアリング」という新しい概念が、Kiro の設計思想とどう結びついているかを解説します。
LLM 活用の 3 段階と、人間側スキルの進化
LLM の使い方は、大きく3段階で進化してきました。
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Stage 1: チャット（対話） │
│ ───────────────────── │
│ LLM の使い方: 質問 → 回答 │
│ 人間に必要なスキル: プロンプトエンジニアリング │
│ 代表ツール: ChatGPT, Amazon Q Developer (chat) │
│ │
│ Stage 2: RAG（検索拡張生成） │
│ ───────────────────── │
│ LLM の使い方: 検索 → 文脈付与 → 回答 │
│ 人間に必要なスキル: コンテキストエンジニアリング │
│ 代表ツール: Amazon Q Developer (codebase awareness), Copilot │
│ │
│ Stage 3: エージェント（自律実行） │
│ ───────────────────── │
│ LLM の使い方: 計画 → ツール呼び出し → 実行 → 検証 │
│ 人間に必要なスキル: ハーネスエンジニアリング │
│ 代表ツール: Kiro, Claude Code, Codex │
│ │
└─────────────────────────────────────────────────────────────────┘
それぞれの段階を掘り下げてみます。
Stage 1: プロンプトエンジニアリングの時代
Amazon Q Developer の初期（旧 CodeWhisperer 時代を含む）は、本質的に「チャットの延長」でした。
- コード補完: カーソル位置のコンテキストから次の行を予測
- チャット: 「この関数の使い方を教えて」と聞けば回答が返る
- インライン生成: コメントで意図を書けばコードが生成される
この段階で人間に求められたのは 「いかに良い質問をするか」 でした。
悪いプロンプト: 「S3にファイルをアップロードして」
良いプロンプト: 「boto3を使って、マルチパートアップロードで
100MB以上のファイルをS3にアップロードする関数を書いて。
リトライは3回、プログレスバー付きで」
プロンプトエンジニアリングとは、要するに 「LLM への入力を最適化する技術」 です。一発のリクエストで最良の出力を得るために、前提条件、制約、出力形式を明示します。
限界
プロンプトが優秀でも、LLM 側には以下の制約がありました：
- モデルの知識は学習時点で固定（最新のAPIを知らない）
- プロジェクト固有のコンテキストを持たない
- 一問一答で完結し、継続的な作業ができない
Stage 2: コンテキストエンジニアリングの時代
RAG（Retrieval-Augmented Generation）の登場で、LLM に「外部知識を注入」できるようになりました。Amazon Q Developer がコードベース全体を理解して提案できるようになったのも、本質的にはこの技術です。
ここで人間に求められるスキルが変わりました。「何を聞くか」だけでなく「何を見せるか」が重要になったのです。
コンテキストエンジニアリングとは、Andrej Karpathy が提唱した概念 で「LLM に渡すコンテキストウィンドウの中身を最適に設計する技術」です。プロンプトエンジニアリングが「聞き方」のスキルだったのに対し、コンテキストエンジニアリングは 「LLM が仕事をするために必要な情報・ツール・ルールを、適切な形式で、適切なタイミングで提供するシステム設計」 です。
プロンプトエンジニアリング:
「どう聞けば良い回答が返ってくるか？」
→ コピーライティングに近い
コンテキストエンジニアリング:
「モデルが正しく動くために何を知っている必要があるか？」
→ システムアーキテクチャに近い
RAG とコンテキストエンジニアリングの関係
RAG は「検索して文脈を付与する」仕組みそのものですが、コンテキストエンジニアリングはもっと広い概念です。以下の5層で構成されます：
- システムプロンプト: モデルの振る舞いを定義するルール
- ツール定義: モデルが呼び出せる機能の仕様
- メモリ: 過去のやり取りや決定事項の保持
- 検索（RAG）: 外部知識の動的注入
- 状態: 現在の作業コンテキスト（開いているファイル、エラー状態等）
RAG は 5 層のうちの 1 層に過ぎません。コンテキストエンジニアリングは 5 層すべてを設計する総合的なスキル です。
Stage 3: ハーネスエンジニアリングの時代（= Kiro の時代）
そしてエージェントの時代です。LLM が単に回答を返すのではなく、計画を立て、ツールを使い、結果を検証し、自律的にタスクを完了します。
ここで登場したのが「ハーネスエンジニアリング」という概念です。
ハーネスとは何か
Martin Fowler のブログ（2026年4月）で体系化された定義によれば：
Agent = Model + Harness
ハーネスとは、AI エージェントからモデルそのものを除いた、残り全部のことです。具体的には：
- エージェントが読む構造化ドキュメント（ルール、規約、手順書）
- エージェントが従うべきアーキテクチャルール
- エラーを検知するフィードバックループ
- エージェントが自分の出力を検証する仕組み
ハーネスの2つの要素
ハーネスは ガイド（フィードフォワード） と センサー（フィードバック） で構成されます：
┌─────────────────────────────────────────────────────────────┐
│ │
│ ガイド（事前制御） │
│ ──────────────── │
│ エージェントが「間違える前に」正しい方向へ導く │
│ 例: コーディング規約、アーキテクチャドキュメント、手順書 │
│ │
│ センサー（事後検知） │
│ ──────────────── │
│ エージェントが「間違えた後に」自己修正させる │
│ 例: リンター、テスト、静的解析、コードレビューエージェント │
│ │
└─────────────────────────────────────────────────────────────┘
これらをさらに 計算的（deterministic） と 推論的（inferential） に分類できます：
- 計算的: リンター、型チェック、テスト → 決定論的で高速
- 推論的: AI レビュー、LLM-as-Judge → 確率的だが意味理解が可能
Kiro は「ハーネスの製品化」である
ここからが本題です。Kiro の各機能を「ハーネスエンジニアリング」の文脈で見直すと、全てが繋がります。
| Kiro の機能 | ハーネスの役割 | 分類 |
|---|---|---|
| Spec（要件→設計→タスク） | ガイド（フィードフォワード） | 推論的 |
| Steering（.kiro/steering/*.md） | ガイド（フィードフォワード） | 推論的 |
| Hooks（イベントトリガー） | センサー（フィードバック） | 計算的 / 推論的 |
| MCP（外部ツール連携） | ツールアクセス | 計算的 |
| Autopilot / Supervised | 人間のフィードバックループ | 推論的 |
Spec = 「何を作るか」のガイド
Spec は単なるタスク管理ではありません。エージェントが正しい方向に動くための事前制御（フィードフォワード） です。
従来の開発：人間が仕様を理解した上でコードを書く
Kiro の開発：仕様を構造化ドキュメントにし、エージェントに渡す
要件定義書（requirements.md）→ 設計書（design.md）→ タスク（tasks.md）という段階的な構造は、エージェントのコンテキストウィンドウに「適切な粒度で」情報を流し込む仕組みです。
Steering = 「どう作るか」のガイド
.kiro/steering/ に置くMarkdownファイルは、チームの暗黙知を明文化したものです。
# coding-standards.md
- TypeScript は strict mode で使う
- エラーハンドリングは Result 型パターンで統一
- テストは Given-When-Then で記述する
人間のエンジニアなら「うちのチームではこうする」と暗黙的に知っていることを、エージェントに対して明示的に宣言します。これがガイド（フィードフォワード）の本質です。
Hooks = センサー（自動フィードバック）
Hooks は「エージェントの出力を自動検証する仕組み」です。
{
"name": "Lint on Save",
"when": { "type": "fileEdited", "patterns": ["*.ts"] },
"then": { "type": "runCommand", "command": "npm run lint" }
}
ファイルが編集されるたびにリンターが走り、エラーがあればエージェントにフィードバックされます。これはまさにハーネスエンジニアリングにおける 計算的センサー です。
preToolUse フックで書き込み操作をレビューするのは 推論的センサー に相当します：
{
"name": "Review Write Operations",
"when": { "type": "preToolUse", "toolTypes": ["write"] },
"then": { "type": "askAgent", "prompt": "コーディング規約に従っているか確認して" }
}
Amazon Q Developer → Kiro で変わった本質
整理すると、こうなります：
| Amazon Q Developer | Kiro | |
|---|---|---|
| LLM との関係 | 会話相手 | 労働者（エージェント） |
| 人間の役割 | 質問する人、コードを書く人 | 仕事を設計する人、品質を管理する人 |
| 必要なスキル | プロンプト/コンテキスト設計 | ハーネス設計（ガイド＋センサー） |
| 制御の粒度 | 1回のリクエスト単位 | プロジェクト全体のライフサイクル |
| 知識の所在 | 人間の頭の中 | 構造化ドキュメント（Spec, Steering） |
| 品質保証 | 人間がコードレビュー | Hooks が自動検証 + 人間が最終判断 |
Q Developer では「LLM に良い質問をするスキル」が重要でした。Kiro では「LLM が良い仕事をできる環境を設計するスキル」が重要になりました。
これは「コピーライター」から「マネージャー」への転換に近いものがあります。
人間に求められるスキルの変遷まとめ
2023-2024: プロンプトエンジニアリング
「いかに上手く聞くか」
→ 文章力、質問力、LLM の癖の理解
2024-2025: コンテキストエンジニアリング
「何を見せれば正しく動くか」
→ 情報設計、検索設計、RAG パイプライン構築
2025-2026: ハーネスエンジニアリング
「どういう環境を作ればエージェントが自律的に良い仕事をするか」
→ ガイド設計、センサー設計、フィードバックループ構築
→ Spec, Steering, Hooks の設計スキル
各スキルの本質
| スキル | 一言で | 比喩 |
|---|---|---|
| プロンプトエンジニアリング | 「聞き方」の最適化 | 新人への指示出し |
| コンテキストエンジニアリング | 「情報環境」の最適化 | 社内wiki整備 |
| ハーネスエンジニアリング | 「作業環境全体」の最適化 | チーム文化・プロセス設計 |
注目すべきは、これらは 積み重ね であって、前のスキルが不要になるわけではないということです。ハーネスの中にはプロンプト設計もコンテキスト設計も含まれます。各段階のスキルが統合されて、より上位の概念になっています。
実感: Kiro を使い始めて変わったこと
実際に Kiro を数ヶ月使ってきて、自分の行動が変わりました：
Before（Q Developer 時代）
- コードを書きながら「次何を聞こう」と考える
- チャットの会話履歴を工夫して文脈を維持する
- 生成されたコードを毎回手動でレビューする
After（Kiro 時代）
- Steering にチームのルールを書き、以降は自動適用
- Spec で要件→設計→タスクの構造を作り、エージェントに渡す
- Hooks でリンター・テストを自動実行し、品質を担保
- 自分は 承認 と 判断 と 例外対応 に集中
最初は「Steering って何を書けばいいんだ？」と戸惑いましたが、本質は 「自分がコードレビューで毎回指摘していることを文書化する」 だと気づきました。暗黙知の明文化、それがハーネスの第一歩です。
ハーネスエンジニアリングの実践ポイント
1. 小さく始める
いきなり完璧なハーネスを設計しようとしないことが大事です。
Week 1: Steering に「コーディング規約」を1ファイル書く
Week 2: Hook で「保存時にlint実行」を設定する
Week 3: 初めて Spec で機能を一つ作ってみる
Week 4: うまくいかなかった部分を Steering に追記する
2. ステアリングループを回す
Martin Fowler の記事で強調されているのが ステアリングループ です：
同じ問題が複数回起きたら、ハーネスを改善して再発を防ぐ
エージェントが同じミスを繰り返したら、それは人間の「指示漏れ」です。Steering に追記するか、Hook を追加します。エージェントを叱るのではなく、環境を改善する。 この発想が重要です。
3. 計算的センサーを優先する
推論的（AI ベース）なセンサーは便利ですが、非決定論的で遅いです。まずは計算的（リンター、型チェック、テスト）なセンサーを整備しましょう。これらは高速で確実です。
優先順位:
1. TypeScript strict mode（型チェック）
2. ESLint / Prettier（コーディング規約）
3. テストスイート（振る舞い検証）
4. AI コードレビュー（意味的判断）← 最後
4. 「暗黙知の棚卸し」をする
チームの暗黙知こそがハーネスの原材料です：
- 「うちでは API のエラーレスポンスはこの形式」
- 「テストデータは fixtures ディレクトリに置く」
- 「PR は〇〇テンプレートに従う」
これらを Steering ファイルに書き出すことが、ハーネスエンジニアリングの核心です。
なぜこの変化が「世の中であまり説明されていない」のか
理由は3つあると考えています：
-
用語が新しすぎる: 「ハーネスエンジニアリング」が Martin Fowler のブログで体系化されたのは 2026年4月です。まだ浸透していません
-
プロンプトの延長だと誤解されている: Steering ファイルを「長いシステムプロンプト」だと思っている人が多いです。確かに技術的にはプロンプトに注入されますが、設計思想が根本的に違います。一回限りの質問ではなく、プロジェクトのライフサイクル全体を統治する仕組みです
-
既存のメンタルモデルに当てはまらない: 「IDE」「コード生成」「AI アシスタント」どれとも少し違います。Kiro は エージェントの作業環境をデザインするツール であり、まだこのカテゴリを表す言葉が定着していません
まとめ: Q Developer → Kiro の本質的変化
Amazon Q Developer:
人間がコードを書く。AI がそれを手助けする。
= AI はアシスタント
Kiro:
AI がコードを書く。人間がそれを統治する。
= AI はワーカー、人間はマネージャー
この転換に伴い、人間に求められるスキルは：
- プロンプト力（個々の指示の質）→ 依然重要だが十分条件ではない
- コンテキスト設計力（何を見せるか）→ Steering の設計に直結
- ハーネス設計力（作業環境全体の設計）→ Spec + Steering + Hooks の総合設計
「良い質問ができる人」から「良い作業環境を設計できる人」へ。 これが Amazon Q Developer から Kiro への移行で、開発者に求められるスキルの本質的な変化です。
Kiro は単なる IDE ではなく、ハーネスエンジニアリングの考え方を製品として具現化したものだと理解すると、Spec・Steering・Hooks という一見バラバラな機能群が、一貫した設計思想のもとに統合されていることが見えてきます。
おまけ: kiroへのコンテクストの与え方
ハーネスエンジニアリング時代になったからといって、コンテクストそのものは何らかの方法で与える必要があります。昔は、スニペットで貼ったり、ファイルで渡したりしていましたが、kiroはredmineなどのIssue管理システムにアクセスできます。そこに今までやってきたことやこれからやることが書かれていれば、それを利用することによって、エージェントは「新人」から「プロジェクトメンバー」に変わります。人間相手でもこういった情報を残す事は大切ですが、AI時代では益々大切になってきてると実感しています。
参考
- Harness engineering for coding agent users - Martin Fowler
- Harness engineering: leveraging Codex in an agent-first world - OpenAI
- Amazon Q Developer end-of-support announcement - AWS
- Context Engineering - Weaviate
- Introducing Kiro - kiro.dev