はじめに
KiroのIDEでAIと一緒に開発していると、プロジェクトで共通するルールは Steering でルール化できますが、開発者ごとに個別に記録しておきたいことはありませんか？
「このライブラリは自分はこう書く」「このバグは自分が前にハマって、原因はこれだった」といった、チーム共有ではなく個人の作業文脈に属する知見です。
KiroにMemory機能が追加されました。
Kiroが作業を通じて学んだコンテキストを保持し、次のセッションでも活かせるようになっています。
この記事では、Kiro IDEでのMemory機能の使い方を中心に、概要・確認方法・アクセス制御、そして既存のSteering機能との使い分けを紹介します。
（CLIでも同じMemoryが使えますが、本記事はIDEを主役に解説します。）
Memory機能とは
Memoryは、チャットのセッションをまたいで有用なコンテキストを引き継ぐための仕組みです。
通常、AIとの会話はセッションが終わるとコンテキストが消えます。
しかしMemoryに蓄積された内容は、次回以降のセッションでKiroが必要に応じて思い出して使ってくれます。
公式ドキュメントによれば、Memoryはリポジトリ固有のコマンドや規約、こちらの訂正、デバッグで得た知見、すでに却下した approach、作業スタイルの好みなどを覚えられるとされています。
各Memoryは過去会話の丸ごとコピーではなく、「タイトル・要約・内容」を持つ1件のレコードとして保存されます。
Memoryは「How Kiro works」で言うエージェントハーネス（コンテキストを組み立ててエージェントを動かす仕組み）の一部で、次の2つの役割を担います。
- 作業の中から「何を覚えておく価値があるか」を見極める
- 目の前のタスクに「関連するMemoryを見つけ出す」
どう動くのか（覚える／思い出す）
Memoryは、Kiroがもともと使っているコンテキストに「覚える」と「思い出す（過去に覚えたことを呼び出して使う）」を足すイメージです。
- 今のタスクから始める：こちらの依頼・現在の会話・Steeringがコンテキストとして入る
- 作業から覚える：ハーネスが有用なコンテキストを見つけてMemoryを作成・更新する
- 関連するときに思い出す：後のセッションで、作業に合うMemoryを取り出して使う
たとえば、あるセッションでデバッグ中に「このプロジェクトは .env に API キーを設定しておかないとビルドが失敗する」と発覚したとします。
Kiroがこれをメモリに保存しておけば（覚えるのはキーの値そのものではなく、「.env に API キーの設定が必要」という手順のほうです）、次のセッションでは原因を再発見せず、先に .env の設定を確認してからビルドを走らせる、といった動きができます。
保存できる情報の種類
IDEのMemoryビューでは、各Memoryに**型（type）**が付きます。
多くは次の2種類で、IDEが名前を付けられないものは Other と表示されます。
Preference（好み）
コーディングスタイルや作業フローに関する個人的な指示です。
「インデントはタブを使う」「コメントは日本語で書く」「コミット前に必ずlintを実行して」といった内容が対象になります。
Fact（知識・事実）
プロジェクト固有の重要な知識や、調査に時間がかかった発見です。
「このリポジトリのAPIはREST風だが実際はGraphQLを使っている」「ビルドエラーの原因はenv変数Xの欠如だった」といった内容が対象になります。
スコープ：どこに効くか
各Memoryには**ロケーション（location）**があり、どこで適用されるかを表します。
Global（グローバル）
どのプロジェクトでも共通で参照されます。
個人の作業スタイルや好みを保存するのに適しています。
リポジトリ単位
特定のリポジトリに紐づいて保存されます。
ロケーションにはリポジトリ名が表示されます。
プロジェクト固有の知識や発見を保存するのに適しています。
保存と更新のされ方
Memoryへの保存には2つの流れがあります。
自動で学習
デフォルト（後述の Use and learn）では、Kiroが「後のセッションでも役立つ」と判断した情報を自動で作成・更新します。
明示的な依頼
チャットで「これをMemoryに覚えておいて」と伝えれば保存されます。
「このMemoryを直して（内容を更新して）」もチャットで対応できます。
ただしチャット経由の変更は、信頼済みワークスペースで Use and learn か Use but don't learn のときだけ有効です（アクセス制御は後述）。
覚えている内容を確認する（Memoryビュー）
IDEでは、保存されたMemoryを一覧で確認し、削除できます。
内容を直したいときはビューからは編集できず、チャットでKiroに頼む形になります。
アクティビティバーの Memories アイコンを選ぶとMemoryビューが開き、Globalと、今開いているリポジトリにスコープされたMemoryが並びます。
- 各行には、タイトル・作成からの経過時間・1行要約・型（Preference / Fact / Other）・ロケーションが表示されます。
-
Search memories... にキーワードを入れるとタイトル・要約で絞り込めます。All memories から TYPE や LOCATION でのフィルタも可能で、フッターに
3 of 12 memoriesのように件数が出ます。 - 行を選ぶとエディタタブで開き、要約・内容に加えて Refresh と Delete のボタンが使えます。
- 削除は行の右クリック →Delete、またはタブ内の Delete から。削除前に確認が入ります。
削除は読み取り専用（Use only）でも可能です。
一方、内容の修正をKiroに依頼する場合は、信頼済みワークスペースで Use and learn か Use but don't learn である必要があります。
チャット上での見え方
Kiroがメモリを使うと、チャットに折りたたみ可能なエントリとしてまとまって表示されます。
- Memory accessed（参照） / Memory created（作成） / Memory updated（更新）
- それぞれ関係したMemoryのタイトルが並び、タイトルにホバーすると型と要約が見えます。タイトルを選べばそのMemoryを開けます。
以下、イメージです。
Memory accessed (1)
Memory accessed aws-profile
アクセス制御（歯車マークの設定）
IDEでは設定（歯車マーク）からMemoryのアクセスレベルを選びます。
- アクティビティバーの Memories アイコンを開く
- Memory settings（歯車）を選ぶと、Kiro Agent: Memory の設定が開く
- 次の4段階から選ぶ
| アクセスレベル | 動作 |
|---|---|
| Use and learn | 参照も変更も可能で、自動での作成・更新も行う（デフォルト） |
| Use but don't learn | 参照・変更は可能だが、自動での作成・更新はしない（依頼すれば変更する） |
| Use only | 既存のMemoryを参照のみ。依頼しても作成・更新・削除はしない（読み取り専用） |
| Off | MemoryをまったくAIが使わない |
CLIでは、3段階（read & write / read only / off）のようです。
IDEでは「自動学習だけ止めて、参照と手動変更は残す」中間の Use but don't learn が選べるのが特徴です。
ワークスペースの信頼について
Use and learn や Use but don't learn でも、信頼していないワークスペースではチャットからの追加・変更・削除はできません（参照は可能）。
セキュリティ面でも考慮された設計になっています。
Steering機能との比較
KiroにはMemoryと似た目的を持つSteeringという機能もあります。
両者の違いを整理します。
| Memory | Steering | |
|---|---|---|
| 管理者 | Kiro（AI）が自動で保存、またはチャットで依頼 | ユーザーが手動で編集またはチャットで依頼 |
| 主な対象 | 個人の好みや作業中の発見 | チーム共通のルール・規約・設計方針 |
| 保存場所 | Kiro内部ストレージ（IDEのMemoryビューで確認） |
.kiro/steering/*.md（ファイル） |
| Gitでの共有 | できない | できる（リポジトリに含めれば全員が参照） |
| 自動保存 | あり（Use and learn時） | なし（常に明示的な操作が必要） |
| 適用タイミング | 次回セッション以降 | 設定に応じて常時・条件付き・手動 |
Steeringはファイルとして存在するため、Gitで管理してチーム全員が同じルールを共有できます。
一方でMemoryは個人の作業文脈を蓄積するもので、チームには共有されません。
「一貫して必ず守らせたいルール」はSteeringに書く、というのが公式の勧めです。
実際の使い分けイメージ
作業中に気づいたこと（個人の発見）
→ KiroがMemoryへ自動保存、または「覚えておいて」と依頼
個人のコーディングスタイル
→ Memoryに保存
チームで決めた設計方針・コーディング規約
→ Steeringファイルとして作成し、Gitで管理
プロジェクト固有のセットアップ手順（チーム共有が必要）
→ Steeringに記載
CLIでも使える
今回はIDEを中心に紹介しましたが、同じMemoryはKiro CLIでも使えます。
CLIのV3セッションでは /memories コマンドでアクセスモード（read & write / read only / off）を切り替えられます。
Classic（V2）セッションでは利用できません。
考え方はIDEと共通で、UIが /memories コマンド中心になる点が違いです。
補足：セッションタイプによる挙動の違い（要注意）
ひとつ実際に試して気づいた点を補足しておきます。
セッションタイプが Quick Spec モードのときは、Memoryへの記録が行われませんでした。
一方、default で新しいセッションを起動した場合は、問題なくMemoryに記録できました。
これはバグの可能性があります（未確認）。
現時点では公式ドキュメントにセッションタイプ別のMemory挙動についての記述は見当たらないため、仕様かバグかの断定はできていません。
当面の回避策としては、Memoryに覚えさせたい作業は default セッションで行うのが無難です。
Quick Specモードで作業していて「覚えておいて」が効かない場合は、このセッションタイプの違いを疑ってみてください。
なお、この挙動は公式に Issue として報告しました。
まとめ
Memory機能の追加により、KiroはAIとの対話を個人レベルで蓄積・継続できるようになりました。
- Memory：個人の作業文脈・発見・好みをセッション間で保持（IDEのMemoryビューで確認・削除、歯車の設定で学習レベルを制御）
- Steering：チームのルール・規約をプロジェクト単位で共有
この2つを組み合わせることで、「個人の知見はMemory、チームの合意はSteering」という形でKiroをプロジェクト運用に活かせます。
AIツールをただ使うのではなく、プロジェクトに馴染ませていく土台として活用できそうです。