AWSの強力なエージェント型IDE "Kiro"のしくみを詳しく解説する（翻訳）

AWSの強力なエージェント型IDE "Kiro"のしくみを詳しく解説する（翻訳）

🔗 要点

• Kiroとは、従来の「命令型開発（Imperative Development）」から「意図駆動開発（Intent-Driven Development）」へのパラダイムシフトを代表するエージェント型IDEです¹。

• Kiroは、以下の仕組みによって、人間とマシンが完全に一致協力して開発するコラボレーション開発環境を構築します。

  • "Spec"による仕様の構造化
  • "Steering"でプロジェクトを意図から外れないように導く
  • "Autopilot"による自律的実行
  • "Hook"による自動トリガー
  • ワークフローの統合
• 本記事では、Kiroを構成する4層アーキテクチャ（意図層、知識層、実行層、監視層）を分解して、このアーキテクチャが技術の編成方法にどのようなインパクトをもたらすかを探り、そこから未来の「人間とマシンによるコラボ開発」のパターンや、ソフトウェア開発における将来のワークフローを理解することに努めます。
• 今年5月に開催されたAWS Summit Hong Kong 2025で、私は「プログラミングを再発明する: AIは今後エンタープライズのコーディングをどのように変革するか」というテーマをソフトウェア開発ライフサイクル（SDLC）の観点から分析しました。ご興味がおありの方は、以下の記事とスライドを合わせてご覧ください。

参考: AWS Summit Hong Kong 2025 Dev Lounge: Reinventing Programming - How AI Transforms Our Enterprise Coding Approach | Ernest Chiang

🔗 パラダイムシフト: 「命令型開発」から「意図駆動開発」へ

「命令型開発（Imperative Development）」は、長い間ソフトウェア開発の中核に居座り続けてきました。開発者はコンピュータに対して、「どのように実行すべきか（how）」を細かなステップの形で厳密に指示しなければなりませんでした。開発者は、コードをたくさん書くことでコンピュータの動作を思い通りに制御できますが、ソフトウェアシステムが指数関数的に増大するにつれて、この手法の効率は限界に達しつつあります。

そして今、新しい「意図駆動開発（Intent-Driven Development）」という考え方が登場しています。
意図駆動開発の中核となるアイデアは、開発者は「それを行いたい理由（why）」と、「何を達成したいか（what）」を言葉で明確に説明することに重点を置き、面倒な「どのように実行すべきか（how）」については、よりインテリジェントなシステムにおまかせするというものです。
これは単なる自動化ではなく、より高度な抽象化思考なのです。

Kiroをはじめとする「エージェント型IDE（Agentic IDE）」は、この考え方を具体的に実装したものです。
Kiroは、単なるコード生成ツールではなく、開発者の意図を汲み取って自律的に計画を立案し、そしてタスクを実行する、インテリジェントなエージェントです。
それでは、Kiroのシステム設計がどのようなアプローチを採用しているのかを分析して、それが企業の組織にどのような深い戦略的価値をもたらす可能性があるかを探っていくことにしましょう。

私は常日頃から、新しい製品やサービスが出現したら、常にまずポジティブに捉えるよう心がけており、それらを既知のさまざまなシナリオに適用して、さまざまな側面から潜在的な価値を探っていくようにしています。こうした分析は、誰でも思い思いに試してみてよいと私は思います。分析結果が同じである必要はありませんし、違う結果を得られる方が議論は盛り上がります。

🔗 Kiroのシステムアーキテクチャ

Kiroの機能は、以下の4つの論理層の連携として抽象化できるでしょう。

• 意図層（Intent Layer）
• 知識層（Knowledge Layer）
• 実行層（Execution Layer）
• 監視層（Oversight Layer）

これら4つの層が協調動作することで、人間とマシンが完全にコラボするためのループを形成します。

🔗 2.1: 意図層: ユーザー入力を解析する

意図層は、開発者の本来の意図を汲み取って理解する責務を担います。Kiroは、さまざまな形式の意図入力を処理するために、いくつかのチャネルを提供しています。

以前私がAmazon Q CLIやClaude CodeやCursorやClineを使っていた頃は、LLMの意図が一時的に変な方向に迷走したり、複数の側面を持つタスク目標を一度に処理させようとするとLLMが細部へのこだわりを捨てられなくなって脱出できなくなったりする（本来の目標やタスクの概要を忘れてしまう）ことが頻繁に起きました。
つまり、Kiroで「構造化された意図」と「構造化されていない意図」をうまく調和させて的確に連携させているのは、非常にレベルの高い試みなのです。

🔗 Spec（構造化された意図）

Specは、Kiroが人間の意図をキャプチャするための中核となるメカニズムです。Specは、漠然とした開発要件を、構造化されたプロセスを介して、AIがはっきり理解できる計画へと変換します。
このSpecワークフローには、以下の3つのコアドキュメントが含まれます。

requirements.md

EARS（Easy Approach to Requirements Syntax）²³⁴構文を用いて、ユーザーの意図するストーリーや受け入れの基準を明確に定義します。
形式: WHEN [条件] THE SYSTEM SHALL [期待される振る舞い]

design.md

要件や既存の知識を元に、シーケンス図などの技術設計ソリューションをAIで生成します。

tasks.md

design.mdの技術設計ソリューションを、具体的な実行可能プログラミングタスクリストに分解します。

このメカニズムは、製品の要件をエンジニアリングタスクの実行に移し替えるときに失われる意図を減らすことを試みます。

🔗 Vibeコーディングやターミナル入力（構造化されていない意図）

Vibeモード

チャットモードの1つであり、簡単なQ&Aや調査、デバッグ用の対話的インターフェイスを提供し、その場で入力された未整理の意図を処理します。

Terminal

自然言語による指示（"プロジェクトの依存関係をインストールして"など）を、正確なシェルコマンドに変換し、開発者の記憶の負担を軽減します。

🔗 2.2. 知識層: 意思決定に必要なコンテキストを提供する

意図層が「問題」や「方向性」を扱うものだとすれば、知識層は、AIが適切に返答するのに必要となる「ナレッジベース」と言えます。
エージェントの知能レベルは、知識をどれだけ広く深く備えているかで、ある程度決まります（チームメンバーを採用するときも同様ですよね？！）。

🔗 コードベースのインデックス作成（短期記憶、プロジェクト内部の知識）

Kiroは、プロジェクトのコードをバックグラウンドで自動的にインデックス化します。また、Kiroのコマンドパレットから手動で再インデックス化することも可能です。Claude Codeの/initコマンドに似ていますが、Kiroはエージェントなので、指示されなくてもインデックス化を自動的に実行します。

これにより、AI（LLM + ソフトウェア）はプロジェクト内部の「関数呼出し」「クラス構造」「プログラミングのパターン」を適切に理解して、プロジェクトのコンテキストに即した高度な提案を提供できるようになります。

インデックスは、以下のような状況で作成されます。

• プロジェクトのインポート時: ワークスペースを最初に開くと、すべてのワークスペースを自動的にインデックス化します。
• ファイル変更時: 新規ファイルや変更ファイルをインデックス化します。
• 外部による変更: Kiroの外部で変更されたファイルを再インデックス化します。

🔗 ステアリング（長期記憶、プロジェクトのガイダンス原則）

Kiroのステアリング（Steering: 運営、舵取り）は、戦略的に極めて価値が高い機能なので、ぜひ活用することを強くおすすめします。

• 私が以前AIソフトウェア開発ツール（Amazon Q CLIやClaude CodeやCursorやClineなど）の導入法を開発チームや友人たちと共有したときは、ほとんどの人は「README.mdを書く」「SPEC.mdを書く」といった直感的にわかりやすい作業についてはどうにか習得できたものの、「プロジェクトを導くためのガイダンス原則」「制約事項」「ワークフロー」といった暗黙の方法論についてはたいてい見落としがちでした。

• 多くの外資系企業では、チームの運営（steering teams）や委員会の運営（steering committies）について戦略的な体制を設けているものです。こうした体制は、部門やプロジェクトを超えるガイダンス原則を確立して、戦略的な方針や意思決定、リソース配分といったプロジェクトの運営や進捗をスムーズにすることを目的としています。

• Kiroがソフトウェア開発用のIDEにこのステアリングという概念を導入したことは、ちょうど私たちのチーム（製品と技術の統合部門）がエンジニアに製品管理に積極的に関わることを促進しているのと似ています。

• 私には予感があります。このKiroというIDEは、おそらく将来ガラスやロボットやドローンなどの物理的な特性をもつ製品の開発すら可能になるでしょう。その日が来るのが楽しみです。

---

AIソフトウェア開発ツールが注目を適切に維持するには、制約を適切に記述することが大事です。

---

開発チームは、プロジェクトの「アーキテクチャ仕様」「デザインパターン」「推奨ライブラリ」「命名規則」といった「チームの知識」を、markdown形式のファイルで.kiro/steering/ディレクトリに書き込めます。

デフォルトのステアリングファイルは以下です。

product.md

製品の目的や目標を定義します。

tech.md

技術上のアーキテクチャ（技術スタック）や制約を記述します。

structure.md

ファイル編成やアーキテクチャ上の決定事項の概要を記述します。

AIは、タスクを実行する前に必ずこれらの「ガイダンス原則」を優先的に参照して、成果物がチームの長期的な仕様から外れないようにします。これは、一種の「実行可能なアーキテクチャドキュメント」とみなすことも可能です。

たとえば、「中国語の文字と英語の文字の間には必ず半角スペースを挿入してください」「私の説明に不明な点があれば、必ず質問してください」⁵「すべての詳細をスキップ・省略せずにもれなく処理すること、すべての考えをもれなくリストアップすること」「Amazon Working Backwordsに沿うこと」「ドメイン駆動設計（DDD）を守ること」といった原則をガイダンス原則に盛り込むことが可能です。

🔗 2.3. 実行層: 意図を操作に変換する

AIが「意図」を理解して「知識」を備えたら、その次の実行層（Execution Layer）が、それらを実際に行うコードに変換する役割を担います。

🔗 オートパイロット（自律的なタスクエクゼキュータ）

Specsが承認されたら、tasks.mdで定義されているタスクリストをオートパイロットモードが引き受けます。オートパイロットは、ファイルの変更・作成・削除を行って全タスクを完了させようとします。
これは、Kiroの「エージェント型」という自律的な特性の究極的な表現です。

オートパイロットには、以下の2つのモードが提供されています。

オートパイロットモード

デフォルトはこのモードです。ベテラン開発者が複雑なタスクを完了するのに適しています。

監視モード

ジュニア開発者が、変更内容を1つ1つ吟味しながら進めるのに向いています（私はビビリなのでこっちのモードにしていますが何か？）。

🔗 フック（イベントでトリガーされるエクゼキュータ）

フック（Hook）はイベント駆動型の自動化メカニズムを提供します。

開発者は、On-SaveやOn-Createといった特定のイベントをトリガーするAI駆動アクションを設定できます。

たとえば、TypeScriptファイルを保存するときは、自動的にテストファイルを追加または更新するようにできます。

🔗 2.4. 監視層: 人間とマシンがコラボするためのインターフェイス

高リスクの自動化システムでは、人間による監視がとても重要です。
より抽象的に言い換えれば、どんなシステムであっても監視はきわめて重要です。

Kiroは、開発者が常に「運転席」で操縦している、つまり開発サイクルで常に人間が介在している（"Human-in-the-Loop"）ことを前提とした設計になっています。
（まあそういうわけで、Kiroにロボットタクシーの無人運転を任せるわけにはいきませんね😛）

監視層の主要な制御メカニズムとして、以下があります。

段階的な承認

Specs（要件、設計、タスク）に記載されている処理について、開発者はどのステージについても実行を手動で承認する必要があります。

コマンド実行の確認

ターミナルから自然言語で与えた指示を元に生成されたコマンドを実際に実行するには、ユーザーが"Execute"をクリックする必要があります。

コード変更のレビュー

オートパイロットやフックによって変更されたコードは、必ず明確なdiff形式で表示され、開発者によるレビューと承認が行われるまで待機します。

🔗 3. Kiroが技術組織の戦略に与える影響を考えてみた

Kiroのようなエージェント型ツールを導入することは、個別の開発効率に影響するのみならず、技術組織全体の運用モデルにも影響します。

これについて、さまざまな観点から問いかけてみたいと思います。以下の問いかけは、これまで私がつらつらと自問自答してきたメモから抜粋したものです。

皆さんもきっと私と似たようなことを考えていることでしょう。ThreadsやXで私と議論やチャットできます。

🔗 3.1. 生産性モデルの変革について

• 「今後ROI（投資利益率）の測定基準で、生産性サイクル時間に「Intent-to-Production Cycle Time（「意図から生産への」サイクル時間）」の測定が追加される可能性はあるだろうか？」

• 「AIがコードを大規模に生成できるようになったら、開発者（やプロダクトマネージャ）の価値は、製品の意図を明確に言語化することや、"ステアリング"ルールの設計の品質改善、システム・アーキテクチャ全体の理解を深めることにシフトするだろうか？」
  「伝統的な生産性測定指標では、いくつかの隠れたコストが無視されています。「チームが"ステアリング"ドキュメントを適切に書く技術を習得するのにどのくらいの期間を要するか？」
  「AIがコードを即座に出力できるようになったら、シニア開発者たちが自分たちのスキルの価値が下がっているのではと不安に駆られるだろうか？」
  「AIの提案を人間がレビューする頻度が増えると、人間にとって認知の負荷が新たに増えることになるだろうか？」

• 「"ステアリング"が組織のワークフローで「戦略の中心」を占めるようになったら、生産性の測定項目にも「ルールの品質指標」「知識の再利用率」「意図の伝達効率」といった新たな観点を盛り込む必要があるだろうか？」
  「自分たちの組織で"最も生産性が高い"のはどんな開発者か？:コードを最速で書ける開発者か、それとも再利用の利く優秀な"ステアリング"ルールを設計できる開発者か？」

• 人間とAIとのコラボは、短期的には効率を改善するかもしれませんが、長期的な価値創造についてはさらなる検討が必要です。
  「技術的な意思決定の質」「チーム能力の醸成」「イノベーションの余地」といったあらゆるトレードオフを"ステアリング"ドキュメントで明確に定義する必要があります。

🔗 3.2. チーム構造の進化について

• 「以下のような新しい職務が生まれる可能性はあるだろうか？」

  • "ステアリングアーキテクト": AIを適切に導くナレッジベースをメンテナンス・最適化することに特化した職務
  • "AIコーディネータ": AIワークフローをレビューおよびガイドして、チームの目的から外れないようにする職務
    （ そんな時代が来たら、ドキュメントの名詞を専門に管理したり、動詞を専門に管理するようになったりするでしょうか？）
    （私はシンプルな英語が好きです😆）
    （私が入学推薦状を書くのを手伝ってくれた英語の先生に感謝ですね😛）
  • しかしこういう新しい職務の出現は、組織が変革されるときの表面的な兆候にすぎません。
    もっと根本的な変化は「既存のチームメンバーは、（定期的に）自分たちの価値をどうやって再定義するようになるだろうか？」になるはずです。
    （古い名詞（=役職名）はなくならず、新しいもの（=価値）は来ない、なんてことはあるでしょうか？）
• "ステアリングアーキテクト"は、単なるドキュメントメンテナーではなく、組織のインテリジェントのキュレーターです。
  ビジネス要件や技術上の制約事項、チーム文化といったものを、AIが確実に理解できるガイダンス原則として言語化することで、タイムリーかつ統一されたドキュメントの"ステアリング"を完全に行い、さまざまな状況でAIが多くのトレードオフをどのように優先順位付けすべきかを明確に定義する必要があります。
  「あなたの組織でステアリングアーキテクトに最適なのはどの役職でしょうか？シニア技術アーキテクト？それとも分野を超えるコミュニケーションに長けたプロダクトマネージャ？」

• AIもしくはエージェント型な何かが、「仮想チームメンバー」に昇格したとしたら、従来のチームが力関係の再調整を迫られるでしょう。
  「そうなったら、責任の帰属はあいまいになるだろうか？」
  「そうなったら、意思決定プロセスの再構築が必要になるだろうか？」
  「そうなったら、組織文化はどんなふうに変わるだろうか？」
  「その場合、どんな可能性が考えられるだろうか？」
  「そうなったら、AIと組んで作業する人間のチームメンバーは、これまで通り自分の仕事に価値を感じられるようになるだろうか？」
  「エージェントがマルチエージェント化したら、あるエージェントが別のエージェントを差別するような事態が起きたりするだろうか？」
  「"AIに取って代わられるのでは"という不安に囚われずに、"AIと力を合わせよう"という心構えを養うにはどうすればよいだろうか？」
  「自分個人の知識をAIに"食わせてやる"必要が生じるようになったら、知識を共有するモチベーションを削がれたりすることがあるだろうか？」

• ドキュメントの"ステアリング"は、単なるAIのガイダンス原則にとどまらず、組織としての学びをも担うことになります。チームに潜んでいる暗黙の知識を実行可能なルールとして言語化し、チームが培ってきたベストプラクティスをドキュメントの形で蓄積して他のチームにも伝え、AIの実行結果で得られたフィードバックを元に、組織で有効なパターンを絶えず最適化します。
  「ドキュメントの"ステアリング"はどのくらいの頻度で更新すべきか？」
  「更新が必要な時期は誰が決めるのか？」

🔗 3.3. 技術的負債の管理

• これは諸刃の剣です。技術的負債を放置すれば、AIはメンテ困難なコードを大量に吐き出すようになり、技術的負債はかさむ一方でしょう。
  （バイブコーディングを見直して、バイブメンテナンスに目を向ける方がよいのかも...）

• 「ドキュメントの"ステアリング"をうまく活用して、リファクタリングやTDDなどの優れたプラクティスをルール化できたら、技術的負債を返済して負債の蓄積を防ぐ強力な手段になるだろうか？」

• AIとコラボする時代の技術的負債の管理は、表面に見えるよりもずっと複雑な問題に直面しています（自分の目で見たものをうかつに信じないこと）。

• 技術的負債の管理は、伝統的に後付の対応になりがちですが、ドキュメントの"ステアリング"なら事前に手を打つことが可能になります。
  技術的負債の容認可能なレベルを"ステアリング"に明記し、自動リファクタリングできるよう条件や優先順位を設定し、既知のアンチパターンをルールで防ぎます（最初が肝心というやつ？）。

• ドキュメントの"ステアリング"を、「迅速なリリース」と「コードの品質」の優先順位をどうバランスするのがよいかを練習する場にしてみたらよいかもしれません。
  「このバランスポイントは、プロジェクトのステージが変わったら調整が必要だろうか？」（やれやれ、この手の変数は増える一方だけど、変数も次元もなければ変更をどうやって知ればよいのやら）

• 「AIと人間がコラボすることで、技術的負債のコスト構造は変わるでだろうか？」
  「AIが生成したコードをレビューするには、通常と違う心構え（もしくは層やツール）が必要になるだろうか？」

• AIが生成したコードをチームや顧客が信頼するには、時間が必要です（AIが生成したコードには、人間が理解しにくいロジック構造が含まれているかもしれません）。

• 戦う相手は、コードレベルの技術的負債だけとは限りません。AIとコラボするようになると、「文化的な技術的負債」が生み出されるかもしれません。
  「AIにコードを生成させると、技術的負債によっては（やがて）チーム間の理解に食い違いが生じる可能性はあるだろうか？」（実はAI登場前からそうだったのか？）

• AIと人間がコラボレーションするときの文脈では、技術的負債の定義を拡張して以下も追加する必要があるかもしれません。
  「要件の原則があいまいなために発生する、"意図の負債（intent debt）"」
  「ガイダンス原則があいまいなために発生する、ステアリングの負債（steering debt）」
  「人間とマシンによるコラボのパターンがよくない場合に発生する、"コラボの負債（collaboration debt）"」
  こうした新種の技術的負債を特定して定量化するのは、伝統的なコードの負債よりも難しくなりそうですが、組織への長期的なインパクトはより深刻なものになるかもしれません。
  さもなければ、もともと隣の部署の責任だったのかもしれませんが、その場合は「どの部署をクビにすべきか？」という問題に立ち戻ることになるでしょう。同じことを前向きに言い換えれば「どの部署が最初に変革に直面するのか？」という問題です。

🔗 3.4. 知識管理の革命

• "ステアリング"ドキュメントは、それ自体が「生きたナレッジベース」です。コードから切り離されたWikiのドキュメントではなく、出力に直接影響して、知識の喪失や食い違いを大幅に軽減してくれる「実行可能な仕様」です。しかし、この変革の重要性は、ドキュメント管理の改善にとどまりません。
  「組織レベルの知識がAIの振る舞いによって直接"ガイドされる"のであれば、知識管理の戦略の重要性がどのように根本的な形で変わるだろうか？」
  「そしてそれをどうやって導入すべきか？」

• 伝統的な知識管理は、多くの場合「単に記録しておしまい（メモを取る、ドキュメントを書くなど）」になりがちでしたが、"ステアリング"は、知識管理を「実行」ステージに押し上げてくれます。

• 「ベテラン開発者が長年養ってきた「直感」を、どうやってAIが理解可能なルールに落とし込めばよいのか？」
  「チームのワークフローをAIの意思決定ロジックに埋め込む？」
  「組織レベルの価値観や原則を"ステアリング"ドキュメントの一字一句にもれなく反映させられるだろうか？」（まだ改善の余地はありそうですが、さしあたって100%を目指すよりも改善を目指しましょう）（私は楽観的なのです）

• 「自分たちの組織に、「言葉で表せないが理解は得られる」ような知識があるとしたら、"ステアリング"ルールに変換する価値が最も高いのはどの知識か？」
  「プロセスを言語化すると抜け落ちてしまう重要なコンテキストとは何だろうか？」

• 「ドキュメントの"ステアリング"は、組織の知識を継承する新たな担い手となりうるのか？」
  「既存のドキュメントの中で、どれが"ステアリング"ドキュメントに近いだろうか？」

• 「退職者の経験（中小企業では多くて大企業では少ないかどうかは知りませんが）を"ステアリング"で引き続きルール化できるのか？」
  （そもそも必要とされているのか？適切でない知識をAIに食わせるべきではない？）

• 新入社員はAIの振る舞いを見て組織の作業パターンを学習できるでしょう。"ステアリング"によって、組織レベルのコアな知識が少数の社員によって独占されることはなくなり、新入社員にとってまたとないハンドブックとなるでしょう。

• 「退職する上級社員の知識を、効果的に"ステアリング"ルールに落とし込むのは、いつがよいのか？」
  「このプロセスにどのぐらい時間がかかるか？」
  「その知識が正確であることは誰が担保するのか？」
  （やめた後に爆発するような不発弾的な文言を仕込まれたりして）

• "ステアリング"が導入されると、組織の権力構造が変化するかもしれません。"ステアリング"ルールに誰の知識が盛り込まれるかを見れば一目瞭然になるはずです（ですよね？現在よりも透明化されますよね？）。

• 技術的な影響は、"ステアリング"ルールに採用されやすくなる傾向があるでしょう。
  「"ステアリング"ルールにどの知識を組み込むかを決める権限を握っているのは、組織の中の誰になるのか？」
  「その決定プロセスは透明（かつ公正）なものなのか？」

• 最後に、"ステアリング"によって推進される知識管理の革命は、いくつかの暗黙の課題ももたらします。
  「"ステアリング"ルールに頼りすぎると、思考の多様性が制限されてしまわないか？」
  「"ステアリング"ルールがなまじ成功すると、さらなる知識の探求が阻害されてしまわないか？」
  「知識が集約されると、個人が持っている知識に対する責任が失われてしまわないか？」
  こうした課題に対処するには、"ステアリング"でもたらされるメリットを享受すると同時に、組織が知識管理の複雑さに対する感度を失わないようにすることも求められます。
  （専門家とは、その道の訓練を十分に受けた人々ですよね...）

🔗 4. まとめ: シングルエージェントからマルチエージェントへ、そしてエージェント型の時代へ

現在のKiroは、主に汎用の単一エージェントを複数のモードで動かす形になっています。しかしAI開発の動向から考えると、次のステップはマルチエージェントシステム連携の方向に進む可能性が高そうです。

将来、たとえばコードの引用（quote）を扱う「引用エージェント」やフロントエンドを専門に扱う「UIエージェント」、DBに特化した「DBAエージェント」、セキュリティスキャン専門の「セキュリティエージェント」といったものが登場するかも知れません。そして全体を統括する「ジェネラルエージェント」（このエージェントは1つで十分ですよね？）の指揮の元、複数のエージェントがせっせと連携して開発を進めるようになるかもしれません。これはソフトウェア開発における巨大な飛躍となるかもしれません（たぶんですが）。

Kiroのようなエージェント型IDEは、単に効率を高めるためのツールにとどまらず、開発者とコンピュータがやりとりするときの関係を再構築する、OSやサンドボックスの新しい層に近いものと言えます。

管理職にとって重要となるのは、人間をAIで置き換えてコストを浮かせるかどうかを云々したり不安にかられたりすることではなく、人間とマシンが最大限に効率よくコラボレーションできるよう、組織アーキテクチャやワークフローをいかに設計するかに取り組むことです（"最大化"だと強すぎるかもしれないので、"改善する"で十分でしょう）。

こうしたツールを十分理解したうえで組織での実験を開始し、チームがAIに「取って代わられる」のではなく、チームがAIに適切な指示を出せる能力を養うことこそが、今後数年間の技術的な競争力を維持するうえで肝心な点となるでしょう。

---

🔗 FAQ

🔗 技術アーキテクチャ

• Q: Kiro.devのエージェント型IDEのアーキテクチャは、従来のIDEと何が違うのですか？
  • 従来のIDEは、主にコードの編集やコンパイル、デバッグ機能を提供しますが、エージェント型IDE⁶は自律的な意思決定能力と実行能力を備えており、目標を自ら理解して複雑なタスクを完了するためのプランを立案します。
  • エージェント型IDEは、単なる受動的なオートコンプリート機能にとどまらず、開発環境内で自ら推論や適応を行い、自らアクションを実行できる自律的なエージェントです。
• Q: EARS（Easy Approach to Requirements Syntax）記法は、ソフトウェアの要件エンジニアリングでどんなメリットがありますか？
  • EARS³⁴は、わずかなキーワードとシンプルな基本ルールセットを用いて、自然言語で記述された要件事項に対して緩やかな制限を加え、要件が時相論理（Temporal Logic）に沿って記述されるようにし、文章の句構造の順序を一定に保ちます。
  • EARSは、要件を自然言語で記述したときに起きがちな問題を軽減・排除します。特に、非英語話者が要件を記述するのに適しています。

🔗 ワークフロー

• Q: ファイルイベントでトリガーされる自動化ワークフローによって、開発効率はどんなふうに改善されますか？
  • Kiroのエージェントフックを使うと、決まりきったタスクを（可能な限り？）手動で実行せずに済むようになります。よく使うタスクをフックで実行することで、コードベースの一貫性と品質が保たれ、セキュリティ脆弱性を防止して、手動作業のオーバーヘッドを軽減し、チームの作業手順を標準化できるようになります。

🔗 トラブルシューティング

• Q: KiroはWSL2で何か不具合があるようですが、修正方法はありますか？
  • こちらの日本語記事をどうぞ: AWSのAIコーディングエージェントIDE「Kiro」をWSL2から起動する設定 #AWS - Qiita
  • 同僚が試したところ、うまくいったそうです。
  • 以前CursorやQ CLIが相互に干渉したときも、似たような方法で解決できました。要するに、$PATHを明示的に設定して、シェルとプロファイルも明示的に設定することです。
• Q: Kiroで問題が発生したらどこに報告すればよいでしょうか？
  • Kiroの開発チームはリポジトリのissuesを積極的に監視しています。
  • このissuesで、発生した問題を頻繁に報告したり（エラーレポートを書く良い練習にもなります）、他の人がどうやって解決しているかを調べたり、+1を付けたりできます。

🔗 公式ドキュメント

• Kiro Getting Started
• Kiro First Project
• Kiro Editor Interface
• Kiro Codebase Indexing
• Kiro Specs Concepts
• Kiro Specs Best Practices
• Kiro Chat Autopilot
• Kiro Chat Vibe
• Kiro Chat Terminal
• Kiro Hooks
• Kiro Hooks Types
• Kiro Hooks Management
• Kiro Hooks Best Practices
• Kiro Hooks Examples
• Kiro Hooks Troubleshooting
• Kiro Steering

関連記事

ChatGPTのしくみとAI理論の根源に迫る:（1/16）実は語を1個ずつ後ろに追加しているだけ（翻訳）

AIパフォーマンスの最適化を学ぶ（2）「SOWを作って」は超便利な指示