Kiro の頭の中を片付ける ~ /memories で始める記憶の棚卸し
2026-11-04 | Author : 稲田 大陸 (いなりく)
はじめに
こんにちは ! ソリューションアーキテクトの いなりく です !
Kiro CLI の Memory を、毎日の仕事でオンにしたまま使ってきました。先日 /memories list を開いてみると、思っていたよりずっと多くの記憶がたまっていました。
新しいセッションでも私の作業の癖を覚えていて、説明を打ち直す回数は確実に減りました。ただ一覧を眺めると、同じ内容の記憶が何件も並んでいたり、特定のリポジトリでしか意味のない手順がどの作業でも検索対象になっていたりします。
この連載では 5 月に「Kiro にハーネスを付ける」で完了を誰が判定するかを、6 月に「進化し続ける Kiro の仕様駆動開発を一度立ち止まって整理する」で Specs の使い分けを、7 月に「ゴールが決まるまで笛は鳴らない」で完了するまで回す仕組みを書きました。
今回は、Kiro が覚えたことを人が見直して片付ける方法と、Memory・Steering・Skills の置き分けの基準を紹介します。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
Kiro が覚えておく場所は 4 つある
Kiro に何かを覚えておいてもらう場所は、Memory のほかに 3 つあります。違いは「誰が書くか」と「いつ読まれるか」の 2 つで整理できます。
Steering は人が書き、毎回読まれます。AGENTS.md もここに入ります。Agent Skills も人が書きますが、読まれるのは作業がその Skill の説明に合ったときです。Knowledge bases は人が選んだ資料を索引にしておき、Kiro が必要なときに検索します。
Memory だけは Kiro 自身が書きます。作業の中で役に立ちそうなことを見つけると記憶を作ったり直したりし、後のセッションで今の作業に合う記憶を探して使います。記憶は会話のコピーではなく、タイトル、説明、本文を持つ 1 件の記録です。長い会話の古い部分を要約して 1 つのセッションに収める Compaction とは別の仕組みで、Memory はセッションをまたいで残ります。
公式ドキュメントは、Memory は Steering の代わりにはならないとしたうえで、一貫して守らせたいルールは Steering に書くように案内しています。図の右上が「なし」になっているのはこのためで、Kiro が書いた記憶が毎回必ず読まれる場所はありません。毎回守らせたいことを Memory から Steering に移す矢印が、この記事の片付けの基準になります。
記憶を見る
Memory は 2026 年 10 月 9 日の Kiro CLI 2.29.0 で入った機能で、ローカルの V3 セッションで使えます。IDE と Web は対応予定です。V3 への切り替えについては、10 月に公開した「Kiro CLI V3 をデフォルトのエクスペリエンスとして順次展開します」と、公式の Migration guide をご覧ください。Kiro CLI そのものが初めての方は、「Kiro CLI の紹介」から読むのがおすすめです。
memories を開く
ローカルの V3 セッションで /memories と打つと、config と list の 2 つが出てきます。config は Kiro に記憶をどこまで任せるかを決める画面で、list はたまった記憶を見る画面です。/memories 以外のコマンドは Slash commands の一覧にまとまっています。
config で決める 2 つのこと
config で決めるのは、記憶へのアクセスレベルと、自動更新を使うかどうかの 2 つです。
Memories のアクセスレベル
アクセスレベルは 3 つあります。
|
アクセスレベル
|
Kiro がすること
|
私が使う場面
|
|---|---|---|
|
read & write
|
記憶を使い、追加・変更・削除もする |
普段の開発。片付けもこのレベルで頼む |
|
read only
|
今ある記憶を使うだけで、増やしも直しもしない |
お客様の前でのデモ、手順書の動作確認、片付けの効果を比べるとき |
|
off
|
記憶を使わず、変えもしない |
記憶なしで Kiro がどう動くかを見たいとき |
記憶を追加・変更・削除できるのは read & write のときだけです。この記事の片付けも、read & write で Kiro に頼んでいます。
read & write を選ぶと、Automatic memory updates（記憶の自動更新）をオンにするかどうかも選べます。オンにすると、Kiro が作業の中で役に立ちそうなことを見つけて、自分で記憶を作ったり直したりします。画面の説明にあるとおり、この自動更新はセッションが終わったあとにも働きます。
この 2 つは、設定が反映されるタイミングが違います。画面にも書かれているとおり、アクセスレベルの変更は次に始めたセッションから、Automatic memory updates の変更はすぐに反映されます。デモの前に read only にするなら、切り替えてから新しいセッションを始めます。
もう 1 つ、Workspace trust も関係します。信頼していないワークスペースでは、read & write にしていても Kiro は記憶を読むだけで、追加・変更・削除はしません。clone したばかりのリポジトリが、記憶を書き換えられないようにするための仕組みです。片付けは、信頼済みのワークスペースで行います。エージェントが実行するコマンドの届く範囲を OS のレベルで絞りたい場合は「Kiro のローカルサンドボックス」、組織で使うときの権限設計は Kiroweeeeeeek の「Kiro を組織で利用するためのセキュリティとガバナンス」が参考になります。
list で記憶を見る
list を選ぶと、たまった記憶の一覧が出ます。文字を打つと絞り込めます。
記憶の一覧を見る
一覧には件数、各記憶のタイトル、1 行の説明、最後に更新されてからの時間が並びます。絞り込みはタイトルの完全一致ではなく、近い言葉を含む記憶も一緒に出てきます。ctrl+p で種類 (type) とスコープ (scope) を含むプレビューが、Enter で本文まで見られます。
一覧の役割について
この記憶は、9 月に devcontainers CLI のテストを書いていて、同じラベルを付けたコンテナが黙って使い回される原因を突き止めたときに、Kiro が自分で残したものです。スコープは記憶が効く範囲で、Global ならどこで作業していても使われ、repo:github/<owner>/<repository> ならそのリポジトリで作業しているときに使われます。
一覧は確認するための画面で、記憶を直したり消したりするときはチャットで Kiro に頼みます。片付けは「一覧で見て、会話で直す」の往復で進めます。
記憶が使われる場面
新しいセッションで、この記憶に関係することを聞いてみました。最後の「過去に Finch のせいだと誤認したことがありました」は、記憶の本文にしか書かれていない経緯です。説明を打ち直さなくても、前に調べた結論から話を始められます。公式ドキュメントによると、Kiro が作業中に記憶を読むと、チャットに Memory の行が command=get と記憶のタイトル付きで表示されます。
棚卸しを Kiro に頼む
数百件を 1 件ずつ開いていくのは大変なので、まず Kiro に棚卸しを頼みます。
記憶を全部見て、次の観点で数えて。
1) スコープ別（Global / リポジトリ / ワークスペース）
2) 同じ内容の記憶が複数あるもの
3) Global だけど特定のリポジトリでしか使わないもの
4) 毎回守るべきルールなのに記憶に入っているもの
5) 長い手順で、Skill にした方がよさそうなもの私の記憶では、いちばん多かったのは特定のリポジトリに結びついた記憶でした。ビルドの癖、テストの落とし穴、リポジトリ固有の手順など、そのリポジトリで作業しているときにだけ効けばよいものです。こうした記憶はスコープが正しく付いていれば、ほかの作業の邪魔をしません。
記憶の中身と行き先
片付けが必要なのは残りの一部で、行き先は次の 4 つに分けられます。
|
記憶の中身
|
行き先
|
|---|---|
|
毎回守ってほしいルール
|
Steering に引っ越す |
|
決まった手順で、長いもの
|
Skill にする |
|
同じ内容が複数ある
|
1 件にまとめる |
|
効く範囲が広すぎる
|
スコープを絞る |
ここからは、このうち 3 つの片付け方を順に見ていきます。
片付け 2 : 効く範囲を絞る
あるリポジトリでしか使わない手順が Global で残っていると、関係のない作業でも検索の候補に入ります。プレビューでスコープを見て、 Global なのに中身が特定のリポジトリの話になっているものを探します。
この記憶は Global になっているけど、<リポジトリ> でしか使わない。<リポジトリ> の .kiro/skills/ に Skill として書き出して、記憶は消して。そのリポジトリでだけ効けばよい手順は、リポジトリの .kiro/steering/ に書くか Skill にして、記憶は消します。リポジトリの中に置けば、チームの人とも共有できます。Skill の置き場所と書き方は Agent Skills のドキュメントにまとまっています。
片付け 3 : Steering に引っ越す
毎回守ってほしいルールが、記憶に入っていることがあります。私の場合は「反映を待つときに sleep を挟まない」という記憶がそうでした。以前、AWS の設定の反映を待つために Kiro が sleep 150 を入れたコマンドを流したので止めたところ、Kiro がそれを記憶として残したものです。
「Do not use sleep in shell commands to wait for propagation」の記憶は毎回守ってほしいので、~/.kiro/steering/no-sleep-wait.md に Steering として書き出して、記憶は消して。終わったら作ったファイルの中身を見せて記憶は「今の作業に合いそうなら使う」ものなので、毎回必ず効かせたいなら、公式の案内どおり Steering に書く方が確実です。信頼済みのワークスペースで、次のように頼みました。
処理結果
Kiro は Steering ファイルを書いてから記憶を消し、作ったファイルの中身を見せました。
作成されたファイル
作られたファイルはこれです。先頭の inclusion: always は、どの作業でも毎回読み込むという指定で、Kiro が自分で付けました。 Steering の読み込み方 にはほかにも、特定のファイルを触るときだけ読む fileMatch などがあり、記憶を移すときにどれを使うか選べます。
---
inclusion: always
---
# Do not use `sleep` to wait for propagation
Never embed `sleep` (or blocking wait loops) in shell commands to wait for eventual consistency or state propagation — e.g. `sleep 150 && <retry>` while polling for AWS/eventual-consistency changes.
Instead:
- Retry the actual operation immediately.
- If it still fails, report the result and retry on the next turn.
- Let the user decide the pacing; do not hold the terminal in a blocking wait.---
inclusion: always
---
# Do not use `sleep` to wait for propagation
Never embed `sleep` (or blocking wait loops) in shell commands to wait for eventual consistency or state propagation — e.g. `sleep 150 && <retry>` while polling for AWS/eventual-consistency changes.
Instead:
- Retry the actual operation immediately.
- If it still fails, report the result and retry on the next turn.
- Let the user decide the pacing; do not hold the terminal in a blocking wait.新しい会話で聞いてみる
最後に /clear で新しい会話を始め、同じ場面を聞いてみました。
出力結果
片付けを続ける
一度片付けても記憶はまた増えるので、私は月に 1 回、次のプロンプトで棚卸しをすることにしました。
先月から増えた記憶を見て、
同じ内容のものはまとめる案、Global にしなくてよいものはスコープを絞る案、
毎回守るべきルールは Steering に移す案を出して。
実行はまだしないで、案だけ見せて。最後の「実行はまだしないで」がポイントです。消した記憶は一覧から元に戻せないので、案を見てから実行を頼みます。記憶のデータベースは ~/.kiro/memories/ にあるので、大きく片付ける前は Kiro CLI を終了してからこのフォルダをコピーしておくと、元に戻せます。私も片付け 3 の前にコピーを取りました。
棚卸しのあいだは、Automatic memory updates をオフにしておくと、棚卸しの会話そのものから新しい記憶が作られることもありません。
24 時間動く Kiro Crew は、古い記憶が自然に薄れる
同じ Kiro でも、9 月号の「Amazon 社員 3.9 万人の日常業務を支える AI エージェント Kiro Crew の使い方大公開」で紹介した Kiro Crew の メモリー は、見直しの仕組みが違います。Crew そのものについては、8 月に公開した「Kiro Crew の紹介」もあわせてご覧ください。Crew は Slack やスケジュール実行から 24 時間動き続けるので、人が月に 1 回見に行くだけでは記憶の増え方に追いつきません。そのため、古い記憶が時間とともに自動で薄れていく仕組みを持っています。
Crew のメモリーは、好み、進行中の作業、日ごとの要約、キーと値で持つ事実、過去の出来事、教わった訂正の 6 つの層に分かれています。日ごとの要約は、14 日を過ぎると 1 日の最初の 1 件と件数だけになり、61 日を過ぎると日付と件数だけになって、181 日を過ぎると会話には読み込まれなくなります。過去の出来事は、検索の点数が日数とともに下がり、23 日で半分、77 日で 1 割ほどになります。どの層にも会話に入れる文字数の上限があり、上限を超えた分は入りません。
一方で、人が片付ける手段も用意されています。ダッシュボードの Lessons の画面や kirocrew learn list、kirocrew learn remove で教わった訂正を見直せますし、kirocrew snapshot でメモリーごとバックアップを取れます (Snapshot & restore）。会話を記憶に残したくないときは、Incognito や Temporary のモードで始めます。
CLI の Memory は人が一覧を見て会話で片付け、Crew は時間とともに薄れる仕組みに任せつつ、要所を人が見直します。どちらも、毎回守ってほしいことは記憶に頼らず Steering や Lessons として明示的に書く、という点は共通しています。
おわりに
Kiro が覚えてくれるおかげで、同じ説明を打ち直す回数は減りました。そのぶん、覚えたものを月に 1 回見直して片付ける手間がかかります。毎回守ってほしいことは Steering に、手順は Skill に、そのリポジトリだけの話はそのリポジトリの中に置くと、記憶は「必要なときに思い出せばよいこと」だけになります。置きっぱなしにすると扱いにくくなるのは Spec も同じで、Kiroweeeeeeek の「Kiro における負債にならない Spec ファイルの扱い方」で紹介した切り方・更新の仕方の考え方は、記憶の片付けにもそのまま使えます。
この連載では「どこまで任せるか」を書いてきました。完了の判定、完了までの反復に続いて、今回は覚えることを Kiro に任せ、片付けの判断を人が持つ形を紹介しました。皆さんも一度 /memories list を開いて、何件たまっているか確かめてみてください。
筆者プロフィール
稲田 大陸 (いなりく / @inada_riku)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
AWS Japan で働く筋トレが趣味のソリューションアーキテクト。製造業のお客様を支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、Kiro のブログなどを執筆しています。
