AIコーディングアシスタントの「コンテキスト問題」って何だろう
みなさん、お疲れ様です。Ragateの益子です。
最近、GitHub CopilotやCursor、Amazon Q Developerなど、AIコーディングアシスタントを開発に取り入れているチームが増えてきましたよね。僕も日常的に使っていて、その便利さには本当に助けられています。
ただ、こんな経験ありませんか？「うちのプロジェクトではこういうエラーハンドリングパターンを使ってるんだけど…」と毎回説明したり、セッションを閉じたら昨日教えたことを全部忘れていたり、15個のマイクロサービスに同じ変更を加えたいのに1つずつ別々に指示を出していたり。
これ、僕は「開発コンテキストのギャップ」と呼んでいます。AIは賢いんだけど、チームの暗黙知までは引き継いでくれない。毎回ゼロから説明し直すのって、正直めんどくさいんですよね。
そんな課題を正面から解決しようとしているのが、re:Invent 2025で発表されたKiro autonomous agentです。
Kiro autonomous agentって何者なのか
AWSは、Kiro autonomous agentを「フロンティア・エージェント」の1つとして位置づけています。フロンティア・エージェントには3つの特性があるとされています。まず「Autonomous（自律）」で、ゴールを与えると計画から実行まで自分で決めて完遂する。次に「Scalable（スケーラブル）」で、複数タスクを同時並行で処理し、必要に応じてサブエージェントに分散する。そして「Long-running（長時間稼働）」で、数時間から数日にわたり人の介入なしでバックグラウンドで動き続ける。
この定義を聞いて、僕は正直ワクワクしました。これまでのAIコーディングアシスタントは「人間がずっと横についている」前提でしたが、Kiroは違う。人間が別の仕事をしている間も、黙々と開発タスクをこなしてくれるわけです。中学生の頃から人工知能に興味を持ってこの業界に入った身としては、ついにこういう時代が来たかという感慨があります。
15リポジトリのライブラリアップグレード、どうやるか
公式ブログで紹介されていた例が分かりやすいので、ここでも取り上げます。シナリオは「15個のマイクロサービスで使われている重要ライブラリをアップグレードしたい」というもの。
従来の手動アプローチだと、15リポジトリを1つずつ開いて、依存関係を更新して、破壊的変更を修正して、テスト実行して、PR作成して…これを15回繰り返す。正直、数日かかりますし、途中で心が折れそうになります。僕も似たような作業を何度かやったことがありますが、単純作業の繰り返しって本当に消耗するんですよね。
Kiro autonomous agentを使うと、一度だけ自然言語でタスクを説明するだけ。エージェントが自動で全リポジトリを特定し、コードを更新し、テストを実行し、15個のテスト済みPRをレビュー用に作成してくれる。その間、開発者は別の優先タスクに集中できる。この違いは、特にマイクロサービスアーキテクチャを採用しているチームにとって大きいと思います。
技術的に面白い3つのポイント
Kiro autonomous agentの技術的な特徴で、僕が特に面白いと感じた点を3つ紹介します。
1つ目はセッション非依存の永続コンテキストです。公式ブログの言葉を借りると、「Kiro autonomous agentはセッションベースではありません。常にそこにあり、作業全体でコンテキストを維持します。」とあります。あるPRで「標準のエラーハンドリングパターンを使って」とコメントすると、そのPRを修正するだけでなく、今後のタスクでも同じパターンを自動適用します。これって、まさにチームの暗黙知をAIが学習していく姿そのものですよね。
2つ目はマルチエージェント構成です。Kiro autonomous agentは単一のAIではなく、複数の専門サブエージェント（調査・計画エージェント、コード記述エージェント、検証エージェント）をオーケストレーションする設計になっています。これは僕が最近注目しているマルチエージェントアーキテクチャのトレンドとも合致していて、複雑なタスクを分解して専門家に振り分けるという考え方は、人間のチーム開発と似ているなと感じます。
3つ目はサンドボックス実行とネットワーク制御です。各タスクが独立したサンドボックス環境で実行され、ネットワークアクセスは3段階（GitHubプロキシのみ、標準パッケージレジストリのみ、インターネット全体）で制御可能。セキュリティを担保しながら自律的に動かすというのは、エンタープライズ環境での導入を考えると非常に重要なポイントです。
GitHubとの連携でIssue駆動の開発フロー
使い方はシンプルで、任意のIssueにkiroラベルを付けるか、Issueコメント内で/kiroとメンションするだけ。これだけで、そのIssueに対応するタスクがKiro autonomous agentに割り当てられます。
僕はこの「Issue駆動」というアプローチが好きです。既存のワークフローを大きく変えずに、自然にAIエージェントを組み込める。新しいツールを導入するときって、チームの学習コストが壁になることが多いんですが、GitHubのIssueをベースにするなら、その壁はかなり低くなると思います。
開発者の役割はどう変わっていくのか
ここからは僕の見解ですが、「実装者」から「設計者・レビュワー」への比重シフトが起きると考えています。繰り返しの実装作業はエージェントに委譲し、アーキテクチャ設計や要件定義は引き続き人間が担い、コードレビューや品質担保は人間とエージェントの協業になっていく。
これは脅威ではなく、むしろ開発者にとってはチャンスだと僕は捉えています。単純作業から解放されて、より創造的な仕事に集中できるようになる。ただ、それは同時に「設計力」「レビュー力」「要件を言語化する力」がより重要になるということでもあります。
僕自身、中学生の頃に人工知能の研究を志してこの業界に入ったんですが、AIと人間がこういう形で協業する未来は、ずっと夢見ていた姿に近いなと感じています。
まとめ
Kiro autonomous agentは、単なる「高性能なコード補完ツール」ではありません。セッションを超えたチーム共有のコンテキスト保持、マルチリポジトリ・マルチタスクの並列自律実行、セキュアなサンドボックス、GitHub Issues駆動の自然なワークフロー統合。これらが組み合わさることで、開発チームの生産性を根本から変える可能性を持っています。
まだプレビュー段階ですが、ソフトウェア開発の風景を変えるポテンシャルを感じます。特にマイクロサービスアーキテクチャを採用しているチームや、大規模なコードベースを持つ企業は、早めにウォッチしておくことをおすすめします。
それでは、また次回の記事で！
