Kiroのコンパクションを生き残る情報をどう決定するか（2026年版ガイド）

Kiro自身によるこのメカニズムの要約は明快です。コンパクションは「セッションが大きくなるにつれて古い会話履歴を自動的に要約することで、長いセッションの生産性を維持する」ものであり、「目標、決定事項、技術的な進捗は保持され、冗長な中間部分のみが圧縮される」という位置づけです。

このプロセスは3つのパートから構成されています。「Kiroが目標、決定事項、進捗、次のステップを捉えた構造化された要約を作成する」、次に「古い会話履歴がその要約に置き換えられ、最新のメッセージはそのまま保持される」、そして「中断することなく、中断した場所から」セッションが継続します。

この設計は合理的であり、選択されているカテゴリは作業を継続する上で適切なものです。どのファイルが変更され、どのテストがパスし、何が残っており、制約が何であるかを把握している要約があれば、確実に作業を継続できます。Kiroの実例はこの点をうまく説明しています。45分間のリファクタリングの後、要約には変更されたファイル、パスしたテスト、残りの2つのファイル、および「すべての変更は後方互換性がなければならない」という制約が保持されます。

このギャップはバグではなく、カテゴリの違いによるものです。要約は結論を効率的に保存しますが、議論を保存するのは苦手です。「すべての変更は後方互換性がなければならない」という制約は生き残ります。しかし、なぜここで後方互換性が譲れないのかを確立した20分間（誰も更新できない呼び出し元、古いバージョンのクライアント、昨年失敗した移行など）は、まさにその表が「探索的な議論」や「中間推論ステップ」として分類しているものそのものです。

圧縮対象カラムにあるさらに2つの項目にも注目する必要があります。「解決済み問題のエラー詳細」は、すでに解決した失敗が圧縮されることを意味します。しかし、解決した失敗こそが、最終的に決定したアプローチの最も強力な根拠であることが多いのです。「以前のメッセージ内のコードスニペット」は、却下された実装が消え、採用された実装だけが残ることを意味し、その選択を正当化した比較プロセスが失われてしまいます。

詳細が失われた場合のKiroの対処法は、率直でありながら示唆に富んでいます。「エージェントがセッションの前の段階の特定の詳細を失っているように見える場合は、それを再提示してください。エージェントはすぐにそれを取り込みます。」これは機能します。しかし、それは同時に、保持カラムにないものを維持するための仕組みが、あなた自身がそれをもう一度言うことを覚えていること であることを意味します。これは、AIにコンテキストを何度も説明するのをやめる方法で説明したループそのものです。

これはKiro特有の設計ではありません。Amazon Q Developerも、異なる名前で同じような仕組みをドキュメントに記載しています。コンパクションの後、「Amazon Qは応答を生成するために（完全な履歴ではなく）圧縮された要約を使用します」。また、セッションのパネルには完全な会話が表示されたままであっても、「IDEを再起動すると、詳細なチャット履歴はリセットされます」。2つのベンダー、2つの独立した実装、そして同じ結論。会話はワーキングメモリであり、ストレージではないのです。

コンパクションをオフにする。 ほとんどのインターフェースでは利用できません。Kiro'sのドキュメントには、コンパクションは「IDEでは自動的に行われます。手動のトリガーはありません」と記載されており、Webやモバイルでも同様です。CLIのみが /compact を提供していますが、これは手動のトリガーであり、スイッチ（切り替え設定）ではありません。コンパクションを行わない場合の代替策は、コンテキスト不足に陥ることです。

保持設定を調整する。 CLIは2つの設定を公開しています。1つは「そのまま保持する直近のメッセージペアの最小数」と説明されている compaction.excludeMessages、もう1つは「直近のメッセージとして保持するコンテキストウィンドウの最小割合」である compaction.excludeContextWindowPercent です。どちらもデフォルト値は2であり、「両方の設定が評価され、より保守的な（大きい方の）値が適用されます」。

これらの値を上げると、直近の末尾部分がより多くそのまま保持されるため、継続性には確かに役立ちます。しかし、1時間前に行われた推論に対しては何の効果もありません。なぜなら、末尾部分は重要度ではなく、新しさによって定義されるからです。これは、なぜ長いコンテキストウィンドウがメモリではないのかで提示した一般的な限界です。

セッションをエクスポートする。 Kiroは適切な理由からこれを推奨しています。「完全な履歴を保存する必要がある場合は、コンパクションが発生する前にセッションをエクスポートしてください。」エクスポートは、完全な喪失に対する確実な保護策になります。しかし、これは検索メカニズムではありません。トランスクリプトは時系列順でインデックスされておらず、現在何が正しいかではなく、何が話されたかを記述しているにすぎません。この違いこそが、インデックス化されたセッションログが記憶するもの、しないもののテーマそのものです。

フェーズごとに新しいセッションを開始する。 合理的なクリーンアップ方法であり、KiroのCLIガイドでも「同じセッション内で新しいフェーズの作業を開始する前に」 /compact を行うことが推奨されています。しかし、新しいセッションはステアリングファイルのみで会話がない状態から始まるため、前のセッションで確立したものの、書き留めておかなかった内容は、要約されるまでもなく定義上すべて失われます。

すべてをステアリングに詰め込む。 これは過剰修正です。.kiro/steering/ 以下にあるKiroのステアリングファイルはデフォルトで常にオンになっており、ステアリングの場所にある AGENTS.md はスコープを制限することができません。ドキュメントには「AGENTS.mdファイルはインクルージョンモードをサポートしておらず、常に含まれます」と記載されています。推論履歴をすべてそこに移動すると、コンパクションの問題がコンテキスト予算の問題に変換されてしまいます。これは、AIエージェントにどれだけのメモリを与えるべきかで検証したトレードオフです。

この表こそがツールです。事後分析としてではなく、事実が現れた瞬間のルーティングルールとして使用してください。

ステップ 1：2つのカラムをルーティング仕様として読み解く

Kiroの表を文字通りに受け止め、作業中に適用してください。セッション内で重要なことが確立されたら、それがどちらのカラムに該当するかを問いかけます。

それがタスクのステータス、変更されたパス、次のステップ、または明示された要件である場合は、会話の中に残しておきます。Kiroはこれらを保持するため、他の場所に複製すると、不一致が生じる2つの記録ができてしまいます。

それが議論、却下された選択肢、何かを学んだ解決済みのエラー、または比較対象のコードスニペットである場合、それは圧縮対象リストに入っています。それは、まだそのままの形で残っているうちに、今すぐ別の場所に書き出すべきシグナルです。

境界線となるケースは、保持カラムにある「主要な決定事項と制約」です。決定は生き残りますが、その正当な理由は生き残りません。したがって、決定に対するルーティングルールは「決定は会話に残し、その理由は書き出す」となります。理由が記録されていない制約は、次にそれを不便だと感じた人によって簡単に削除されてしまいます。

ステップ 2：再利用可能な半分をステアリングに昇格させ、ステアリングのスコープを限定する

書き出した内容の一部は、次のセッションでも有効であるため、Kiroの設定に含めるべきです。

ステアリングファイルは、ワークスペーススコープの場合は .kiro/steering/ に、グローバルスコープの場合は ~/.kiro/steering/ に配置され、フロントマターでインクルージョンモードを指定します。ドキュメントには注意すべき制約が記載されています。「インクルージョン設定はファイルの最初のコンテンツでなければなりません。その前に空行やコンテンツを置いてはなりません。」3つのモードは、always（デフォルト）、fileMatchPattern を伴う fileMatch、および manual です。

これらを実行期間（ライフスパン）に応じて使い分けます。リポジトリ全体に適用される規約は always ファイルに記述します。特定の領域にのみ適用される規約には inclusion: fileMatch とパターンを指定することで、他の場所にいるときにコンテキストコストがかからないようにします。たまに呼び出す長い手順には manual を使用します。

ステアリングに含めるべきではないのは、プロジェクトの決定事項の進行履歴です。ステアリングはすべてのタスクのすべてのセッションでロードされるため、決定ログは際限なく肥大化してしまいます。また、Kiroのドキュメントによると、グローバルステアリングはマシンごとのディレクトリです。Web上では、「グローバルステアリング」はローカルの ~/.kiro/steering/ ディレクトリを指し、「クラウドのサンドボックスはこれを読み取ることができません」。クラウドセッション間で再利用するには、Configuration Syncを介してアップロードする必要があります。1台のノートPCに存在するファイルは、チームの記録にはなりません。

ステップ 3：要約が実行されない場所に理由の保管場所を作る

残りの部分（却下されたアプローチ、制約の背後にある理由、エージェントが行き詰まったときに人間が提供した事実など）には、これまでの2つの保管先を排除する3つの特性があります。それは継続的に増加するため、常にオンにすることはできません。クエリされるのは稀であり、かつ具体的であるため、すべてのプロンプトに含めるべきではありません。そして、次のセッション、次の担当者、次のツールからも読み取れる必要があるため、1台のマシン上のトランスクリプトに置いておくことはできません。

それはファイルでも会話でもなく、「ストア（保存庫）」です。決定が下されたときに追加され、決定に疑問が生じたときに読み取られ、その中のいかなる内容も要約処理の対象にはなりません。

MemoryLakeはそのためのストアです。セッションが圧縮し、ステアリングファイルが抱えるべきではない推論を保持する共有レイヤーです。Kiroがステータスを保持し、ステアリングが常設の規約を保持し、このレイヤーが議論（理由）を保持します。ここから始めましょう。

ステップ 1：APIキーを作成する

プロジェクト用のワークスペースを作成し、APIキーを生成します。セッションごとではなく、プロジェクトごとに1つのワークスペースを作成します。重要なのは、コンパクションがリセットするセッションをまたいで機能することです。

ステップ 2：最初のメモリをアップロードする

ゼロから始める必要はありません。すでにコンパクションされたセッションをエクスポートし、圧縮対象カラムに該当する情報（試して断念したアプローチ、設計を変更させたエラー、誰かが口頭で述べた制約など）を抽出します。すでに手元にある各ステアリングファイルの背後にある理由を追加してください。それらのファイルはルールを述べているだけで、その理由は述べていないからです。

ステップ 3：AIとエージェントを接続する

実際に使用しているインターフェース全体でKiroを接続します。IDEとCLIではコンパクション時の挙動が異なりますが、両方が同じデータセットを読み取る必要があります。チームのワークフローでKiro Crewを実行している場合は、それらのエージェントも接続してください。これにより、スケジュールされたエージェントが、それを設定した人間よりも狭い記録に基づいて動作することを防げます。

長いセッションが、目に見えない形で情報損失を起こすことがなくなります。コンパクションは依然として独自のスケジュールで実行され、要約はステータスを保持し続けます。しかし、各制約の背後にある議論は要約されない場所に保管されているため、コンパクションされたセッションは「記憶が短くなった」のではなく、「コンテキストが小さくなった」だけになります。

「再提示」のループが縮小します。失われた詳細を再提示するというKiroのアドバイスは、1回だけなら問題ありません。しかし、同じ3つの事実を1ヶ月間すべてのセッションで再提示し続けるのはコストが高く、また再提示する本人がその事実が確立されたことを覚えていなければならないため、不確実です。

却下されたアプローチが再び提案されることがなくなります。「解決済み問題のエラー詳細」は圧縮対象リストに入っているため、何が機能しなかったかの記録は真っ先に消えてしまいます。これらを書き留めておくことで、エージェントが火曜日に排除した案を再び提案してくるのを防ぐことができます。

ステアリングファイルを効果的なサイズに小さく保つことができます。決定ログに独自の保管場所があれば、ステアリングはリクエストごとにコンテキストを消費する肥大化したドキュメントではなく、常設の規約をまとめた短いセットに留めることができます。常にオンにするレイヤーをスリムに保つべき一般的な議論については、保持する情報を減らすことでエージェントのメモリがどのように正確になったかで説明しています。

セッションの最後ではなく、理由が語られたその瞬間に書き留めてください。最後になる頃には、会話はすでにコンパクションされている可能性があり、Kiro自身の警告が適用されます。コンパクションポイントより前の履歴は「セッション内で復元することはできません」。

長時間の自律実行を行う前にエクスポートしてください。コストはかかりませんし、Kiroも推奨しています。そして、監査できない要約しか残らないという事態を防ぐ唯一の手段です。

CLIの保持設定は、長期保存のためではなく、継続性のために引き上げてください。compaction.excludeMessages を増やすことは、エージェントが境界を越えて一貫性を保つのに役立ちます。しかし、保護されるウィンドウは新しさによって定義されるため、これはストレージではありません。

always ステアリングよりも fileMatch ステアリングを多く使用してください。すべての always ファイルはリクエストごとに同じコンテキストを奪い合うため、スコープを制限できたはずのファイルは純粋なオーバーヘッドになります。また、ステアリングの場所にある AGENTS.md には利用可能なインクルージョンモードがないことにも注意してください。

書き出す際には、決定と制約を区別してください。「決済処理で共有リトライヘルパーを使用しない」は制約であり、コンパクションを生き残ります。「二重課金が発生する失敗パスでリトライするため」は理由であり、生き残りません。しかし、半年後にその制約が削除されるのを防ぐ唯一の手段は、この理由の記録です。

自分自身の参照用にセッションログを保持する場合は、ストアとは別に管理してください。ログは時系列順であり、何が話されたかを記述します。ストアは現在何が正しいかを記述します。これらを混ぜ合わせると、最新の矛盾が最も古い主張の隣に並び、区別がつかなくなります。また、将来的にツールを移行する場合、きれいに移植できるのはストアの方です。これは、KiroからCodexへの移行で判明したことです。

Kiroのコンパクション表は、何を計画すべきかを正確に示してくれるため、ほとんどのベンダーのドキュメントよりも有用です。ステータス、パス、決定事項、次のステップ、および意図は生き残ります。ツール呼び出しの詳細、探索的な議論、中間推論ステップ、解決済みエラーの詳細、以前のコードスニペットは生き残らない可能性があり、この操作は一方通行です。

実用的な対応策は、コンパクションに抗うことではありません。2番目のカラム（圧縮対象）の保管場所として会話を使用するのをやめることです。事実がどちらのカラムに属するかをその場で判断し、常設の規約をスコープ付きのステアリングファイルに昇格させ、推論には要約処理が一切触れない保管場所を提供することです。そうすれば、コンパクションされたセッションは、まさにKiroが言う通りのものになります。つまり、「コンテキストが小さくなっただけで、何も失われていない」状態です。