ツールの変更から仕事の進め方の刷新へ：マルチ Agent 開発実践に向けた10の原則
AI プログラミングによってデリバリーが目に見えて速くならないのは、多くの場合モデルの性能不足ではなく、人間が依然としてあらゆるステップでボトルネックになっているからだ。Kiro の10の原則は、この問題を意図、検証、コードベース、権限、そして注意力管理へと落とし込んでいる。
多くの開発者が日常的に AI コーディングアシスタントを使う中で、次のような状態に陥っている：
IDE でプロンプトを1行入力し、息を呑んで数十秒待ち、コードが出力されたのを見てそのまま「承認」をクリックする。ローカルで実行するとコンソールが一面エラーで真っ赤になり、エラーログを対話欄にコピーしてまた数十秒待つ……この繰り返しだ。
確かにツールは最新のものに変わり、タイピングや生成のスピードも上がった。しかし、一歩引いて全体のデリバリーサイクルを見てみるとどうだろうか。要件定義、システム設計、コーディング、繰り返されるデバッグから本番リリースに至るまで、デリバリー全体としては期待したほどの目覚ましい高速化がもたらされていないことが多い。開発者が依然として疲弊しやすい根本的な原因は、多くの人が依然として AI とターミナルの間に身を置き、リアルタイムの「人間ルーター」「例外伝達係」「クリック承認マシーン」として振る舞っていることにある。
2025年9月、Kiro チームは Clare Liguori 氏が主筆を務めたエンジニアリング特集『Frontier Engineering』（フロンティア・エンジニアリング）を公開し、マルチ Agent 開発実践に向けた10の探索的原則を体系的にまとめた。
著者の核心的な主張は、現在のソフトウェア開発の実践において二極化が進んでいるという点にある。一部のチームは既存のプロセスの中でコーディングツールを乗り換えたに過ぎないのに対し、最先端の探索者たちは仕事のやり方そのものを再構築しようとしている。すなわち、自ら1行ずつコードを手書きするスタイルから、Agent が自律的な閉ループで開発を推進できるエンジニアリング基盤の構築へとシフトし、大幅な、さらには非連続的なデリバリーの高速化を追求しているのである。
もしあなたがすでに AI 支援プログラミングに慣れ親しんでいるにもかかわらず、エンドツーエンドのデリバリーが依然として人的なボトルネックに阻まれていると感じているなら、本記事は Kiro の10の原則を踏まえ、このワークフローの背後にある動作メカニズム、前提条件、そしてエンジニアリングの境界線を紐解いていく。
10の原則 リーディングマップ
- Architect, not typist → 役割のリセット
- Maximize agent time → 人的ボトルネックからの脱却
- Build for agents → コードベースの刷新
- Build a fast feedback loop → 高速フィードバックの閉ループ
- Direction over execution → 役割リセットにおける方向性と仕様駆動
- Treat code as disposable → コードは書き捨て可能、境界テストが契約となる
- Hold the line on human standards → 人間の基準とレビューの分担
- Trust the boundaries → ガードレール・エンジニアリング
- Use agents for everything → 全プロセスの協調
- Constantly tune your setup → 継続的チューニングのフライホイール
役割のリセット：コードを叩くタイピストから、意図を定義するアーキテクトへ
最先端のエンジニアリング実践において、Kiro は最前線を走る開発者が手書きする本番コードの割合がすでに 1% 以下にまで低下していることを観察した。強調しておくべきは、これは著者が特定の実践の中で観察した現象であり、すべてのチームが一律に当てはめるべき目標 KPI ではないということだ。これは開発者の責務が軽くなったことを意味するのではなく、エンジニアリングの重心が大きく移行したことを意味している。
図：Kiro「Architect, not typist」原則の図版。エンジニアが重心をシステムの方向性と検証へと移す様子を示している。
従来、大半の時間はキーボードを叩き、構文の細部を調べ、低水準な API 呼び出しの不具合を調査することに費やされていた。しかし、Agent が具体的なコーディングを担うモデルにおいては、ソフトウェア開発の核心的なコストは次の2点へと転換する。第1に、「完了（Done）」の定義（要件の境界、制約、検収基準）を明確にすること。第2に、生成された成果物がシステムの意図に真に合致しているかを検証することである。
多くの開発者が Agent をうまく活用できない場合、最初の段階として「意図の曖昧さ」という罠に陥っていることが多い（注：以下の認証・認可の比較は、意図表現のメカニズムを説明するために本文で展開した例示であり、Kiro 原文の事例ではない）：
- 非効率な意図：「この API にユーザー認証を追加して。」
この指示に対し、Agent は往々にして技術選定を勝手に補完し、インターセプトする範囲やデフォルトのエラーレスポンス形式を独断で決めてしまう。その仮定が実際のビジネス要件と衝突した場合、開発者は余計な労力をかけて最初からやり直す羽目になる。 - 適切な意図：「次のエンドポイントにロールベースのアクセス制御（RBAC）を追加して：
/admin/*は Admin ロールのみ、/api/v1/user/*は User および Admin ロールからのアクセスを許可する。トークンの有効期限が切れている場合は、仕様に従ってステータスコード 401 とエラー本文TOKEN_EXPIREDを返すこと。未認証アクセス、トークン期限切れ、偽造署名に対するテストケースを提供し、すべて成功することを確認して。」
ここでは、具体的なコード実行の限界費用が大幅に低下する一方で、システムの方向性（Direction）を定義することの重要性が著しく増大している。
システムアーキテクチャ、API 契約、外部依存関係の選択、そして中核となるトレードオフ（Trade-offs）がひとたび乖離してしまうと、白紙に戻して修正するコストは依然として決して低くない。したがって、開発者はシステムの重要な骨格に注力すべきである。設計段階においては、Agent をソリューション検討の助手として活用することもできる。例えば、複数の実現可能な技術的アプローチを調査させ、比較可能なプロトタイプを作成させ、プロトタイプの実行結果や客観的な証拠を通じてチームの意思決定を支援させる、といった具合だ。
方向性が定まった後は、仕様駆動開発（spec-driven development） へと移行すべきである。すなわち、コードを生成する前に Agent と協調して仕様や要件を明確に書き起こし、曖昧さを排除しておく。そして開発を進める中で、アーキテクチャが実際の負荷に耐えられるか、既存のトレードオフを再検討する必要はないか、そしてプロダクトがユーザーに届けられる品質基準に達しているかを継続的に判断していく。
図：Kiro「Direction over execution」原則の図版。まず方向性と仕様を固め、その後に実行を拡大することを示している。
人的ボトルネックからの脱却：「60秒の待機ループ」を「30分の自己修復ループ」へ引き延ばす
開発のスループットを飛躍的に向上させるには、「Human-in-the-loop（ループ内の人間）」という密結合を打破しなければならない。
もしあなたが画面の前に座り、指示を出すたびにカーソルの点滅を見つめ、約 60 秒待った後に手動でテストを実行し、手動でエラーをフィードバックしているなら、あなた自身がパイプライン全体における最大の並行処理ボトルネックになっている。
最先端の開発者が行っているアプローチは、明確な検証基準を備えた、より長いライフサイクルを持つタスクを Agent に割り当てることだ。例えば Kiro が原則の中で挙げている典型的なタスク指示は次の通りである:
“機能を実装し、テストを作成し、テストを実行してすべて成功することを確認した上で、新規コードのテストカバレッジを 90% に到達させること。”（注：これは Kiro 公式のタスク例であり、実装と検証をパッケージ化して納品する閉ループモデルを示すためのもので、全プロジェクトに対する必須 KPI ではない）
このプロセスにおいて、Agent が最初に書いたコードに欠陥が含まれていることはごく日常茶飯事である。重要なのは、構文エラーや環境エラーの調査を人間が代行するのではなく、制御された環境の中で Agent 自身にコードを実行させ、エラー出力をキャッチして自己修正させ、期待通りの結果へと収束するまで自律的に取り組ませることだ。
2つの作業モードの違い：
- 非効率な人的ポーリング：人間が Prompt を送信 → 約 60 秒待機 → Agent がコードを生成 → 人間が手動でテストしログを確認 → 人間がエラーをコピーして差し戻す → 再び待機。人間の注意力とコンテキストスイッチのコストがスループットの上限を決定づけてしまう。
- 長時間の自己修復ループ：人間がまず目標、検証スクリプト、検収指標を定義し、その後 Agent が 30 分またはそれ以上自律的に稼働し続ける：
- 実装とテストを作成する；
- ローカルで検証を実行する；
- 失敗した場合はエラーをキャッチして修正し、前のステップに戻る；
- すべて通過したら Diff を提出し、人間の非同期レビューを待つ。
単一の Agent が 30 分あるいはそれ以上の時間にわたって自律的に閉ループを回せるようになると、開発組織のモデルも自ずとアップグレードされる。開発者は独立したタスクに向き合う複数の Agent を並行してスケジューリングしたり、長時間タスクをバックグラウンドで走らせて後からまとめて非同期レビュー（Async Review）を行ったりできるようになる。
しかし、Kiro は特集の中で注意力管理（Attention Management） の重要性を特に強調している。これは並行して動かす Agent の数を闇雲に追求することを決して意味しない。肝要なのは、明確な目標と信頼性の高い検証閉ループを備えたタスクのみを継続稼働させ、プロセス全体を通じて品質基準を厳格に維持することである。同時に開発者は、明確な注意力バジェット（注力の予算）と生活の境界線を設け、夕食時や深夜に進捗を気にして何度も確認したくなる衝動を抑える必要がある。
インラインツール
6つのフィールドで自己検証可能なタスク委任シートを作る
以下にサンプルの内容を入力してあります。実際のタスクに合わせて6つの境界を書き換えると、生成エリアに Agent へそのまま渡せるタスク委任シートがリアルタイムで整理されます。このツールは曖昧な要件を自動で明確化せず、アーキテクチャも代わりに決めません。
図：Kiro「Maximize agent time」原則の図版。短いポーリングから検証を伴う長時間タスクへのシフトを示している。
コードベースの刷新：「毎回入社し直す新入社員」を迎えるように環境を整える
人間のチームメンバーが入社する場合、通常は一度ドキュメントを通読し、一度ローカル環境をセットアップすれば、関連する業務コンテキストやエンジニアリング上の暗黙の了解は脳内に長期間保持される。
しかし、Agent はそうではない。新しいセッション（Session）のたびに、現在の業務を全く知らない新たな協調者が「初日に入社」してくるようなものなのだ。
もしコードベースが口伝や暗黙の了解だけに頼って運用されているなら、Agent は文脈の欠落した箇所で幾度となく行き詰まることになる。Agent を高効率で働かせるためには、リポジトリが Agent 向けのインフラを確立していなければならない:
図：Kiro「Build for agents」原則の図版。ドキュメント、境界、テスト、ツールが Agent を支える重要性を強調している。
1. リポジトリレベルの基礎的サポートとエンジニアリング衛生
- 完備された README とアーキテクチャドキュメント：明確なシステムの全体像、技術スタックの選定理由、ディレクトリガイドを提供し、新しいセッションがシステム全体の認識を迅速に確立できるようにする。
- 期待される振る舞いを記述したテストスイート：ビジネス上期待される振る舞いを明確に反映したテストを作成し、Agent が自己検証を行うための直接の根拠を提供する。
- 明確なモジュール境界と強い型付け：厳密なモジュール疎結合と強力な型制約によって暗黙の依存関係を削減する。曖昧な型付けは、Agent の推論に誤謬や曖昧さを生じさせる確率を著しく高める。
- 高速なビルドと高情報量のエラーメッセージ：ローカルのビルドとテストフィードバックが十分に高速であり、かつコンパイラやテストのエラーに具体的で原因特定につながる手がかりが含まれている状態を確保する。
- 大規模レガシーリポジトリへの対応戦略：歴史的経緯の重い大規模コードベースに対しては、一気呵成に解決しようとせず、モジュール単位での段階的な刷新アプローチを採り、タスクごとに Agent のコンテキストと操作スコープ（Scope）を絞り込むべきである。
2. 明文化されたエンジニアリングルールとツール連携
- ステアリングファイル（Steering Files）：チームのコーディング規約、ディレクトリの約束事、頻出ルールをルールファイルとしてまとめ、持続的に適用されるエンジニアリング規約とコーディング標準を提供する。
- オンデマンド・スキル（Skills / Procedures）：複雑な手順（データベースマイグレーション、API 公開など）をモジュール化されたステップとしてカプセル化し、特定のタスクがトリガーされた時のみ動的に読み込むことで、無関係な情報によるコンテキストの圧迫を防ぐ。
- 環境構築スクリプトと CLI/MCP ツール：スクリプトで立ち上げ可能なローカル環境を整え、CLI や MCP（Model Context Protocol）ツールを通じて Agent が自律的にログを照会したり、スキーマを取得したり、補助サービスを呼び出したりできるようにする。
3. 重要な意思決定とコンテキスト制約の永続化
タスクを進める過程で、Agent に対し設計上の意思決定を（ADR などを活用して）記録させ、中核となる処理フローに重要なコンテキストや制約条件のコメントを追記させる。これはモデルの冗長な思考プロセスをそのままコードベースに山積みにすることを求めているのではなく、必要な設計判断、背景にある前提、制限事項を永続化し、その後のセッションや他の協調者に連続性のあるエンジニアリングの記憶を提供するためである。
高速フィードバックの閉ループ：ローカル検証ツールからプロパティベーステストによる補完まで
Agent が自律的に問題を特定し修復できるための基盤は、アジャイルで、ローカル化され、自動化されたフィードバックツールチェーンを備えていることにある。
図：Kiro「Build a fast feedback loop」原則の図版。Agent が実行結果やテスト結果を迅速に確認できるようにすることを示している。
もし Agent が UI を調整するたびに人間がブラウザを開いて目視確認しなければならなかったり、インターフェースの修正をリモートのテスト環境にデプロイしなければ検証できなかったりすれば、自己修復のフィードバックループは寸断され、人間は再び煩雑なリアルタイム確認作業へと引き戻されてしまう。
最先端の実践において、高速フィードバックは通常、以下のローカル機能に依存している：
- 静的コードチェッカー（Linter）とユニットテスト（Unit Tests）：構文、コードスタイル、基本的なロジックの乖離を迅速に検出する。
- 画面をレンダリングし視覚的検証が可能なブラウザ（Browser）：Agent が自律的にフロントエンド画面を読み込み、DOM 構造やインターフェース表示の視覚的な比較検証を行う。
- ローカルの軽量な依存関係とモック（Local Mocks）：ローカル Mock やコンテナ化の手法を活用し、外部の共有環境から切り離されたマシン上でフルスタックのエンドツーエンドテスト（E2E）の実行を支える。
そして多種多様なテスト手法の中でも、プロパティベーステスト（Property-based Testing） は特に価値のある補完策となる。ただし、これは必須の導入ハードルというわけではなく、基本的なユニットテストを直接代替するものでもない。
従来の事例ベースのユニットテストは、通常、特定の入力に対して固定された出力をアサーションする。Agent が自身で書いたコードをカバーするテストを自ら作成する場合、自身の実装ロジックと同じ思考の慣性に陥りやすい。これに対し、プロパティベーステストでは、幅広い入力に対してシステムが満たさなければならない不変条件（Invariants） を宣言することが求められる（注：以下の例はメカニズムを説明するために本文で展開した例示であり、Kiro 原文の事例ではない）：
- シリアライズの不変条件：「制約を満たす任意のオブジェクトについて、serialize した後に deserialize すると、規定のセマンティクスにおいて元のオブジェクトと等価であること。」
- 資金移動の不変条件：「手数料、為替換算、端数処理の誤差を考慮しない前提において、2つの口座の残高変動量の合計は常に 0 に等しいこと。」
ランダム生成された幅広い入力サンプルを通じて境界を検証するプロパティテストの力を借りることで、Agent は通常のテストでは見落とされがちなエッジケースの異常をより容易にあぶり出し、失敗したケースに対してさらなるコード修正を行うことができる。
コードは書き捨て可能、境界テストが契約となる
従来の開発プロセスにおいて、コードを白紙に戻して書き直すことには、膨大な時間的コストと強い心理的抵抗が常に付きまとっていた。
しかし、コード生成および書き直しのコストが実質的に激減したことで、既存の実装やアーキテクチャの方向性が芳しくないと判明した際には、誤った方向を果断に切り捨てて実装を再生成することが極めて現実的になった。 これはすべてのエンジニアリングコストがゼロになったことを意味するのではなく、チームがいびつな局所的実装を取り繕うために長期的な技術的負債を抱え込む必要がなくなったことを意味している。
図：Kiro「Code is disposable」原則の図版。代替可能なのは実装であり、書き直しには依然として境界テストによる保護が必要である。
ここでは2つのレイヤーを明確に区別する必要がある：
- 使い捨て可能なレイヤー（Disposable Layer）：具体的な内部実装ロジックや局所的なプライベート関数。方向性が思わしくない場合、Agent に最初から書き直させることができる。
- 契約保護レイヤー（Contract Layer）：エンドツーエンドの統合テスト、プロパティベーステスト、負荷・性能のベースラインテスト。これらは外部の振る舞いとシステムの境界を記述しており、コードを書き直すプロセスにおいて維持されるべき検収基準となる。
このような書き直しにおいて、重点的に維持され、リファクタリングの礎とされるべきなのが境界テスト（Boundary Tests） である：
- 外部から期待される振る舞いを網羅するエンドツーエンドテスト（E2E Tests）；
- 中核となるルールや不変条件を検証するプロパティテスト（Property-based Tests）；
- 高並行処理や極限状態での挙動を検証する負荷テスト（Load Tests）。
これら3種の外郭テストこそが、システムが対外的に約束する書き直しの契約（Contract） を構成する。内部のプライベート関数や過度に密結合したユニットテストは、古いコードとともに破棄して構わない。上位の境界契約が明確かつ有効に機能している限り、Agent は明確な制約の範囲内で多様な実装ルートを探索し、システムの期待に沿うコードへと段階的に収束させることができる。アーキテクチャの設計や API の取捨選択は、依然としてコストが高く慎重な判断を要する方向性の意思決定であるが、当初の方向性に誤りがあったと事実が示した際には、それらもまた再検討される必要がある。
ガードレール・エンジニアリング：最小権限境界と多層防御の構築
Agent に十分な自律的実行スペースを与えることは、セキュリティ制御を怠ってよいことを決して意味しない。
図：Kiro「Trust the boundaries」原則の図版。最小権限とガードレールによって自律実行を制約する様子を示している。
多くのチームが Agent を導入する際、2つの極端な偏りに陥りやすい。1つは過剰防衛であり、ほぼすべての読み取り専用コマンドやローカルコマンドにまでポップアップ承認を設けてしまい、すぐに人間が深刻な「承認疲れ」に陥って判断力を失うケース。もう1つは防御の欠落であり、全体への読み書き権限や機密資格情報を無警戒に付与して、取り返しのつかない操作リスクを招くケースである。
Kiro がセキュリティ原則の中で提示した核心的な戦略は、現在のタスクに必要な最小限の範囲にファイル、ツール、ネットワーク、認証情報のアクセスを制限し、その前提のもとで Agent を無人稼働（run unattended）させるというものだ。
実践にあたっては、通常「狭い範囲から開始し、段階的に緩和する」というアプローチを採り、多層防御を構築する：
- 権限とツールの境界
避けるべきこと：デフォルトでシステム全体や全ツールの読み書き権限を付与すること。
ガードレール：必要最小限の狭いツールセットから開始し、タスクに応じて段階的に緩和し、真に必要な場合にのみ対応する機能をマウントする。 - 操作承認の関門設定
避けるべきこと：操作の軽重にかかわらず頻繁にポップアップ承認を求めること、あるいは承認を一切設けないこと。
ガードレール：読み取り専用の操作や管理されたローカルテストの自律実行は許可し、破壊的なデータ変更や外部本番環境へのリリースなど、真に取り返しのつかない影響を及ぼす高リスクなアクションにのみ承認の関門を設ける。 - クレデンシャルと本番環境の認可
避けるべきこと：高権限のクレデンシャルをグローバル環境変数に混入させること。
ガードレール：本番環境の権限およびクレデンシャルは、デフォルトで厳格に付与しない。日常的にはモックデータや制限されたサンドボックスのクレデンシャルを使用し、明確かつ慎重な承認を経た場合にのみ特定の権限を開放する。 - セキュリティとコードの防御
避けるべきこと：マージ前の人間の目視確認だけに頼ること。
ガードレール：自動静的解析（SAST）、自動推論または形式検証ツール、機密情報スキャンなどの機能を組み合わせ、多層的なセキュリティ防護ネットを構築する。
このような境界設計の目的は、システムとデータの安全性を担保した上で、管理された範囲内で Agent を滞りなく進行させ、頻繁な割り込みによるプロセスの停滞を最大限に削減することにある。
人間の基準の堅持とレビュー階層の役割分担
コードが人間によって手打ちされたか Agent によって生成されたかにかかわらず、最終的にメインブランチにマージされ本番運用される以上、エンジニアリングの責任は常に人間のエンジニアが負う。
図：Kiro「Hold the line on human standards」原則の図版。生成されたコードも同一の品質基準を満たす必要があることを強調している。
生成されるコード量が増加するにつれ、チームはスループットを追求するあまり品質基準を妥協してはならない。しかし、高頻度の出力に直面したとき、最初歩の機械的なレビューまで完全に人間の1行ごとの確認に依存していては持続が困難になる。Kiro が提案するレビューの進化プロセスには、明確な前提と役割分担が含まれている:
- 初期段階の人手による1行ずつのキャリブレーション：チームへの Agent 導入初期においては、使用するモデルの強み、コーディングの癖、典型的な失敗パターンを正確に把握するため、エンジニアは生成されたコードを1行ずつ読み込んでレビューし、基礎的なキャリブレーション判断を確立する必要がある。
- AI Reviewer による事前チェックの担当：モデルの特性を把握するにつれ、ローカルでの PR 作成前や CI パイプラインに専用の AI Reviewer を導入できるようになる。コードの正しさ、セキュリティ、保守性、テスト品質、典型的なバグパターンを自動で検査させ、最初の数往復のフィードバック作業を段階的に肩代わりさせる。
- 人間は中核アーキテクチャとシステムへの影響に集中する：人間のエンジニアは、より重要な高次元の判断に意識を集中させる：
- 全体のアーキテクチャやモジュールの責務分割は適切か？
- 変更が上流・下流の依存関係にどのような波及効果をもたらすか？
- セキュリティ境界とビジネス権限は厳密に保たれているか？
- 変更はシステムの長期的な意図に真に合致しているか？
- デプロイ後の検証とリグレッション監視：Agent の閉ループは PR の提出だけで終わらない。デプロイフェーズにまで拡張し、Agent にデプロイ監視へ参加させ、本番環境での動作を検証させ、メトリクスの悪化や異常が発生した際にはトラブルシューティングと修復プロセスの立ち上げを支援させることもできる。
全プロセスの協調：Agent は単なるコード生成ツールにとどまらない
マルチ Agent の実践におけるもう1つのよくある誤解は、Agent を「コードを書くタイプライター」と狭小に捉えてしまうことだ。Kiro の第9原則は明確に指摘している。「Agent の能力は、ソフトウェアの研究開発から運用に至る全ライフサイクルを貫くべきである」 と。
図：Kiro「Use agents for everything」原則の図版。Agent の適用範囲がコード生成にとどまらないことを示している。
ビジネスコードの実装やリファクタリングにとどまらず、Agent は以下のような領域にも広く応用できる：
- 提案書・設計ドキュメント：アーキテクチャ設計案の起草、インターフェース設計仕様書の作成、技術調査レポートの作成。
- 運用と障害調査：トラブルシューティングやインシデント対応において、エラーログの集約や呼び出しトレーシングの異常特定を行う。
- プロジェクトと運用の連携：ステータス更新の生成、スプリント総括レポート、オンコール（On-call）の引き継ぎ、日常的なエンジニアリングドキュメントの保守。
こうしたタスクは共通の協調フローに従う：コンテキストの提供（Context）→ 期待される成果物の明確化（Outcome）→ Agent による初稿作成 → 人間によるレビューと修正を経て外部に共有。
さらに一歩進めて、計画、開発、テスト、デプロイから日常の運用に至る各フェーズにおいて、さまざまなタスクを担当する Agent 同士がエンジニアリングコンテキスト、Steering ガイドルール、低水準ツール（CLI/MCP）を可能な限り共有し、開発ライフサイクル全体で一貫した協調のシナジーを形成すべきである。
継続的チューニングのフライホイールシステムの構築
フロンティア・エンジニアリングは一度設定すれば終わりというものでは決してなく、進化し続けるエンジニアリング実践である。
図：Kiro「Constantly tune your setup」原則の図版。根本原因分析を通じてルールやツールを継続的に改善することを示している。
日々の開発において、Agent が障害に直面したり、実行が脱線したり、不要な割り込みが発生したりするたびに、単にモデルの性能不足のせいにしたり、盲目的にすべての問題を環境の欠陥として片付けたりすべきではない。最先端の実践が採るアプローチは、繰り返し発生するエラーや割り込みに対して詳細な根本原因分析を行い、その根本原因がビジネス上の制約の不明確さにあるのか、ツールの欠落にあるのか、あるいは権限が厳格すぎる点にあるのかを見極め、それを Agent Setup に対する具体的な改善策へと昇華させることである：
- 似通った2つのツールの使い分けを頻繁に混同する？ → Steering ルールファイルに明確な利用シーンと肯定例・否定例の説明を追記する。
- 複雑な操作手順で何度もミスを犯す？ → その手順を独立した Skill スクリプトとして抽出し定型化する。
- 必要な環境コンテキストデータが不足している？ → 軽量な CLI ツールを作成するか、MCP Server を通じて情報取得のパイプラインを提供する。
- 安全なローカル操作なのに頻繁に処理を中断して人間の承認を求めてくる？ → 根本原因に基づき、実行環境の権限設定を慎重に調整する。
このフライホイールは次の4ステップに凝縮できる：
- Agent が長時間タスクを実行する；
- 繰り返されるエラー、不要な割り込み、その他の障害を記録する；
- 人間が根本原因分析を行い、ビジネス制約、プロセス、ツール、権限のいずれの問題かを切り分ける；
- 該当する Steering、Skill、CLI/MCP、または権限境界を更新し、次のタスクで改善が有効かどうかを検証する。
こうした根本原因分析とチューニングが蓄積されるにつれ、エンジニアリング環境による Agent へのバックアップはますます強固なものとなる。さらに重要なのは、基盤となる基底モデルは常に進化し続けているという点だ。新しいモデルがリリースされた後は、旧モデルの弱点を補うために設けていたワークアラウンド（回避策）を再評価すべきである。検証を経て不要となったルールやプロンプトのみをクリーンアップする。一方で、コードベースの周囲に蓄積された明確な契約、自動化テストスイート、制御された権限境界、MCP ツールチェーンは、そのまま再利用でき、新しいモデルがより安定して力を発揮できるよう支え続ける。
開発者の実践セルフチェックリスト
もしあなたが今日から自身の開発ワークフローの刷新を始めるなら、以下の観点に照らし合わせて段階的に進めることができる：
- 手書きの割合
従来の警告サイン：大半の定型コードやボイラープレートを依然として人手で1行ずつ記述している。
実践の方向性：システムの意図、アーキテクチャの契約、検収境界の定義に集中する。Kiro は最先端の開発者において手書きの本番コードが 1% 以下にまで低下し得ると観察している。 - インタラクションと注意力
従来の警告サイン：頻繁な人間による監視と約 60 秒のポーリングに陥り、常に作業が中断される。
実践の方向性：自己検証の閉ループを備えた長時間タスクを委譲し、非同期でレビューを行い、注意力のバジェットと業務外時間の境界を維持する。 - 検証とテスト
従来の警告サイン：人手による目視確認に依存している、あるいは局所的実装に密結合したユニットテストしか存在しない。
実践の方向性：ローカルの自動検証閉ループを頼りに、エンドツーエンドテストやプロパティテストをリファクタリングを保護する契約として位置付ける。 - コードベースのコンテキスト
従来の警告サイン：チーム内の口伝や暗黙の了解に依存し、ドキュメントや規約が欠落している。
実践の方向性：README とアーキテクチャドキュメントを完備し、Steering ルールファイル、オンデマンドの Skills、軽量な CLI/MCP ツールを蓄積する。 - リファクタリングの観念
従来の警告サイン：過去のサンクコストに縛られ、古いコードを捨てることをためらう。
実践の方向性：境界テストの保護のもと、コード書き直しコストの低下を活かして、方向性のズレた局所的実装を思い切って破棄する。 - 権限とセキュリティ
従来の警告サイン：頻繁なポップアップ承認による疲弊、または無防備な全面開放。
実践の方向性：必要最小限の権限に従い、狭い範囲から段階的に緩和し、不可逆なアクションにのみ関門を設け、本番権限はデフォルトで開放しない。 - エラーの帰属
従来の警告サイン：感情的にモデルを非難する、あるいはすべてのエラーを盲目的に環境の問題として片付ける。
実践の方向性：繰り返されるエラーや不要な割り込みに対してまず根本原因分析を行い、ルール、ツール、権限のいずれの不備であるかを確認した上で setup の改善へと反映させる。
客観的に指摘しておくべきこととして、この Agent 向けのエンジニアリングパラダイムは現在もなおアーリーアダプター（early-adopter）による実践段階にある。Kiro によれば、コードレビューの最適な組織形態は今なお模索が続けられており、Agent 向けに特化して設計されたツールチェーンやテスト体系も完全には成熟していない。タスクをいかに適切に委任するか、複雑な長期目標をいかに分解するか、そしていつ人間が介入すべきかは、現状ではエンジニア個人の経験の蓄積に依然として大きく依存している。
単純な対話型のコード補完から、Agent が駆動するエンジニアリング基盤の構築へと移行することは、スイッチを切り替えるように一瞬で完了するプロセスではない。Kiro が注意を促すように、最初の数週間は開発速度がむしろ低下し、モジュールの境界を整理し、テストやルールファイルを整備し、信頼できる自動検証環境を構築するという環境整備に数週間を投じる必要がある。
もしチームが今から段階的な探索を始めたいと考えるなら、これら10の原則に基づき、以下のようなスタート手順を組み立てることができる：
- コードベースの基礎を固める：コアモジュールの README とアーキテクチャドキュメントを整備し、モジュールの疎結合と強い型定義を明確化し、ローカルのビルドとテストフィードバックが迅速かつ信頼できる状態を確保する；
- 最初の検証閉ループを通す：境界が明確な独立モジュールを選定し、期待される振る舞いを明確に定義したテストスクリプトを作成し、自己修復検証を伴う 30 分規模のタスクの委託を試みる；
- ルールとツールを段階的に蓄積する：初期段階では人手による1行ずつのレビューを維持してモデルの挙動をキャリブレーションし、繰り返し生じる障害に対して根本原因分析を行い、チームの Steering ファイル、操作用 Skill、必要な CLI/MCP インターフェースを蓄積する；
- 全プロセスの協調へと拡張し、注意力を管理する：提案書の起草、トラブルシューティング調査、ドキュメント更新などを徐々に協調体制へと組み込み、同時に注意力バジェットを明確にして、システムの品質と個人の作業ペースの適切なコントロールを維持する。
実践用持ち帰り資料
Markdown をスクロールして確認し、コピーしてチーム向けに調整できます。
Markdown を読み込み中…