ワークフロー on KnightLiブログ

Claude-Mem：Claude Code にセッションをまたぐ長期記憶を追加する

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem は、Claude Code 向けの永続的な記憶システムです。

解決しようとしている問題は明確です。AI コーディングアシスタントは、新しいセッションを始めるたびに、以前話したアーキテクチャ判断、踏んだ落とし穴、プロジェクトの好み、実装背景を忘れがちです。
長く続くプロジェクトでは、毎回同じ文脈を説明し直すのはかなり無駄です。

Claude-Mem の考え方は、Claude Code の会話内容を記憶として圧縮し、ローカルデータベースとベクトルストアに保存し、あとから検索ツールで取り戻すというものです。

何を解決するのか

Claude Code はコードタスクに強いですが、セッションの文脈には限界があります。

よくある課題は次の通りです。

新しいセッションが過去の作業を知らない
プロジェクトの設計判断を何度も説明する必要がある
以前調査した問題を再び踏みやすい
長期タスクに連続した記憶がない
複数の会話にまたがるプロジェクト知識を蓄積しにくい

Claude-Mem はこれらの問題を中心に設計されています。

単にチャットログを保存するのではありません。会話を検索しやすい記憶断片に圧縮します。後で必要になったとき、意味検索で関連する文脈を取り戻せます。

仕組み

README の設計を見ると、Claude-Mem は主にいくつかの部分で構成されています。

第一の部分は hooks です。

Claude Code の会話フローに接続し、適切なタイミングで会話データを捕捉します。

第二の部分はバックグラウンド worker です。

worker は原始的な会話内容を、より短く、検索しやすい記憶へ処理します。

第三の部分はローカルストレージです。

プロジェクトは構造化メタデータの保存に SQLite を使い、ベクトルインデックスには Chroma を使います。これにより、会話記録の基本情報を保ちながら、意味検索にも対応できます。

第四の部分は mem-search です。

これは Claude Code が使う検索入口です。過去の文脈が必要なとき、関連する記憶を検索できます。

全体の流れは次のように理解できます。

Claude Code のセッションで内容が生まれる
hooks が会話データを捕捉する
worker が非同期に圧縮・整理する
記憶を SQLite と Chroma に書き込む
後のセッションで mem-search によって検索する

どんな場面に向いているか

Claude-Mem は長期プロジェクト向けで、一回きりの小さなタスク向けではありません。

たとえば：

ひとつのリポジトリを何日も開発し続ける
コード構造が複雑で、背景説明が多い
プロジェクト規約、命名習慣、アーキテクチャ選択を覚えてほしい
Claude Code に頻繁にバグ修正、機能追加、文書整理を任せる
AI に「以前なぜこう変更したのか」を覚えてほしい

Claude Code に一行だけ直してもらう程度なら、長期記憶の意味は大きくありません。
しかし Claude Code を長期的な協力者として使うなら、これは役に立ちます。

インストールと起動

README では、インストール方法は直接的です。

1
2

npm install -g claude-mem
claude-mem install

起動には次を使います。

`1`	`claude-mem start`

状態確認：

`1`	`claude-mem status`

停止したい場合：

`1`	`claude-mem stop`

これらのコマンドの目的は、記憶システムを長く動くローカルサービスとして Claude Code のワークフローに接続することです。

`mem-search` の使い方

mem-search は記憶を取り戻すための重要な入口です。

普通の検索を置き換えるものではなく、Claude Code が過去の会話内容を意味で検索できるようにするものです。

たとえば Claude Code に次のようなことを検索させられます。

あるモジュールがなぜそのように設計されたのか
ある Bug を当時どう調査したのか
プロジェクトで合意した命名規則
以前議論した技術的な取捨選択
あるリファクタリングの背景

これは単純なキーワード検索とは違います。
記憶圧縮とベクトルインデックスがうまく機能すれば、正確な言い回しを覚えていなくても、意味的に近い内容を取り戻せます。

普通のプロジェクト文書との違い

プロジェクト文書は、安定した結論を記録するのに向いています。

たとえば：

アーキテクチャ説明
デプロイ手順
API 規約
データベース構造
開発ルール

Claude-Mem は、会話過程で生まれる文脈を記録するのに向いています。

たとえば：

なぜある案が却下されたのか
一時的な問題をどう回避したのか
実装の背後にあった議論
まだ文書化されていないプロジェクトの好み
複数の会話で積み重なったタスク背景

両者は互いの代替ではありません。
安定した知識はプロジェクト文書へ書き、過程的な文脈は記憶システムで検索できるようにするのがよいです。

使うときの注意点

第一に、長期記憶は多ければよいわけではありません。

すべての会話を区別なく保存すると、後の検索がノイズだらけになる可能性があります。価値が高いのは、プロジェクト判断、実装背景、問題調査、長期的な好みです。

第二に、記憶はコードや文書の代わりにはなりません。

AI が見つけた古い文脈は参考にすぎません。最終判断は現在のコード、テスト結果、最新の要求に基づくべきです。

第三に、プライバシーとローカルデータに注意が必要です。

会話内容を保存する以上、どのプロジェクトに接続してよいか、どの機密情報を会話に入れるべきでないかを理解しておく必要があります。

第四に、記憶システムにはメンテナンスが必要です。

プロジェクトが進むにつれて、古い記憶は古くなる可能性があります。古い文脈が誤って使われると、後続タスクを誤導することがあります。

この種のツールが注目に値する理由

AI コーディングツールは、「一回限りの質問応答」から「長期的な協力」へ向かっています。

一回限りの質問応答では、モデルは現在の質問に答えれば十分です。
長期的な協力では、プロジェクト履歴、過去の判断、チームの好み、すでに踏んだ落とし穴を知っている必要があります。

Claude-Mem のようなツールの意味はここにあります。「文脈を覚える」ことを、一時的なチャット能力ではなく、インストールし、実行し、検索できるローカルシステムにします。

実際のエンジニアリングプロジェクトでは、単にモデルのコンテキストウィンドウを長くするより実用的です。
多くの情報は一度に文脈へ詰め込めばよいのではなく、必要なタイミングで取り戻せることが重要だからです。

誰が試すべきか

次のような場合は試す価値があります。

Claude Code を高頻度で使っている
同じプロジェクトを日をまたいで扱うことが多い
プロジェクト文脈が複雑
AI に同じ背景を何度も説明している
会話内の経験を蓄積したい

Claude Code をたまに使うだけ、またはプロジェクトが小さい場合は、まだ必要ないかもしれません。

参考

thedotmack/claude-mem

最後に

Claude-Mem の重点は「チャットログを保存すること」ではなく、Claude Code が後続タスクで有用な文脈を取り戻せるようにすることです。

AI コーディングが一回限りのタスクから長期プロジェクト協力へ移るにつれ、記憶システムはますます重要になります。
文書やテストを置き換えるものではありませんが、繰り返し説明を減らし、AI をプロジェクト履歴を理解した助手に近づけます。

Codex がコンピューターを操作し始めると、これから何が変わるのか？

Wed, 29 Apr 2026 11:28:25 +0800

今回の Codex で最も注目すべき変化は、普通のボタンが一つ増えたことではありません。Codex が「コンピューターを操作する」方向へ進み始めたことです。

これまで AI を使うとき、多くの場合はチャット欄で質問し、コピーして貼り付け、その後は人間が手動でソフトウェアを操作していました。
今、その境界が外側へ広がり始めています。AI は答えるだけでなく、あなたの目的に合わせてデスクトップアプリを操作できるようになりつつあります。

短期的には新機能の一つです。長期的には、多くの人のコンピューターの使い方を変えるかもしれません。

この機能とは何か

簡単に言えば、Codex のコンピューター操作機能は、デスクトップ環境に触れ、それを操作できるようにするものです。

できることは次のようなものです。

特定のアプリを選択して操作する
自然言語でタスクを受け取る
ブラウザ、AI ツール、ローカルファイル、その他のソフトウェアを開く
テキストを入力し、ボタンをクリックし、結果を待つ
複数の手順を一つのタスクとしてつなげる
ユーザーが一歩ずつ追わなくても、バックグラウンドで実行を続ける

役割は、単に文章を一段落書くことではありません。操作の流れそのものを代行することです。

ここが Agent と普通のチャットボットの大きな違いです。
チャットボットは主に答えを返します。Agent は「目的を受け取り、それを実行する」ものに近づきます。

なぜ重要なのか

これまで多くの自動化には、スクリプトを書く力が必要でした。

たとえば、複数のソフトウェアをまたぐ作業をしたいとします。

Web ページを開く
情報を探す
内容をコピーする
別の AI ツールに渡す
ファイルを保存する
ローカルディレクトリを開いて結果を確認する

従来の方法でこれを自動化するなら、ブラウザスクリプト、API、ローカルプログラム、場合によってはウィンドウ操作まで扱う必要があります。

しかし、多くの一般ユーザーはそうしたものを書けません。
書ける人でも、一時的な作業のために専用スクリプトを書く価値があるとは限りません。

コンピューター操作機能の意味はここにあります。
「スクリプト的な能力」を自然言語の方向へ一歩押し出します。

どこをクリックするかを細かく教える必要はありません。
欲しい結果を伝え、あとは Agent に試してもらう形に近づきます。

どんなワークフローが変わるのか

最初に変わるのは、極めて厳密で高リスクな仕事ではなく、面倒で、細かく、繰り返しが多く、それでも専用プログラムを書くほどではない作業だと思います。

1. ソフトウェア間の情報移動

典型的なのは、複数のソフトウェア間で情報を移動する作業です。

これまでは、ブラウザ、文書、チャット画面、ローカルフォルダを何度も行き来していたかもしれません。
今後は、こうした作業を Agent に任せられるようになります。

ある種類の情報を探す
文書にまとめる
指定フォルダに保存する
結果を開いて確認できる状態にする

この作業は難しくありませんが、注意力を消耗します。
Agent の価値は、こうした細かい操作を吸収することです。

2. 複数の AI ツールの連携

今では、一つの AI ツールだけで完結しない作業も増えています。

たとえば：

あるツールでコードを書く
あるツールで資料を調べる
あるツールで画像を生成する
あるツールで文書を整理する

これまでは、それらの間を人間がコピー&ペーストでつないでいました。
これからは、Agent が中間層になれます。ツールを開き、文脈を渡し、出力を待ち、結果を整理します。

これにより、「複数の AI ツールの協調」は手作業から半自動の流れに変わります。

3. オフィスソフトの自動化

表計算、プレゼン、文書、メールには共通点があります。機能は強力ですが、操作は細かいものが多いということです。

Agent がこれらを安定して操作できるようになれば、オフィス自動化のハードルはかなり下がります。

メニューの場所を覚えたり、複雑なショートカットを覚えたりする必要は薄れます。
必要なのは、目的をはっきり伝えることです。

この表を月報にまとめる
この文書から 1 ページの要約を作る
これらの資料を構造の分かりやすい説明にまとめる

面倒なボタン操作は、少しずつ自然言語の後ろに隠れていくでしょう。

一般ユーザーにとっての意味

一般ユーザーにとって、この種の機能は「モデルが少し賢くなった」ことよりも直接的な影響を持つかもしれません。

下がるのは知識のハードルだけではなく、操作のハードルだからです。

多くの人は、やりたいことを説明できないわけではありません。
どこをクリックすればよいか、ソフトウェアの機能をどう組み合わせればよいかが分からないのです。

Agent がそこを引き受けられるなら、コンピューターの使い方は次のようになります。

1
2
3

私が目的を説明する
Agent がソフトウェアを操作する
私が結果を確認する

これは単なるチャットより、実際の生産性に近い形です。

ソフトウェアの形にも影響する

この種の Agent 能力が成熟していけば、ソフトウェアそのものも影響を受けます。

これまでソフトウェア設計は、主に人間のクリックに向けられていました。
これからは、Agent による操作も意識する必要が出てきます。

つまり：

UI 要素はより明確である必要がある
操作結果のフィードバックは安定している必要がある
ローカル権限はより細かく管理される必要がある
ソフトウェアは Agent が呼び出しやすいインターフェースを用意するかもしれない
ユーザーは「AI がうまく操作できるか」を気にするようになる

長期的には、アプリ間の境界は薄くなるかもしれません。
ユーザーが気にするのは「どのアプリを開くか」ではなく、「どのタスクを完了したいか」になります。

まだ過度に楽観する段階ではない

もちろん、今すぐ完全に任せる段階ではありません。

この能力には、まだ明確な制限があります。

安定性はまだ見ていく必要がある
複雑なタスクは途中で失敗する可能性がある
権限の境界は慎重に扱う必要がある
アカウント、支払い、ファイル削除のような操作は簡単に任せるべきではない
利用枠の消費も無視できない

そのため現時点で最も向いている使い方は、コンピューター全体を完全に任せることではありません。
低リスクで、確認可能で、手順が多い作業を任せることです。

たとえば：

資料を整理する
下書きを生成する
ツール間で内容を移動する
ファイルを開いて確認する
人間が最後に確認できる半自動フローを実行する

最後に

今回の Codex 更新で本当に重要なのは、AI が「質問に答える」段階から「環境を操作する」段階へ進んだことです。

短期的には、これはコンピューター操作機能です。
長期的には、個人用コンピューターとの関わり方の転換点になるかもしれません。

これから私たちは、ボタンを覚えたり、メニューを探したり、ウィンドウを切り替えたりする時間を減らしていくかもしれません。
その代わりに、目的を伝え、Agent に実行させ、最後に人間が判断する場面が増えていくでしょう。

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

Wed, 29 Apr 2026 11:08:00 +0800

Codex skills を整理するとき、多くの人がつまずきやすい問題は主に二つあります。

~/.codex/skills と プロジェクト/.codex/skills は何が違うのか
skill はディレクトリにあるのに、なぜ現在のセッションに表示されないことがあるのか

この文章では結論から整理します。

両者の違い

まず短く覚えるなら、こうです。

~/.codex/skills は自分用のグローバルなスキルライブラリ
プロジェクト/.codex/skills はそのリポジトリ用のローカルなスキルライブラリ

`~/.codex/skills`

ここに置くのに向いているもの：

自分が複数プロジェクトで繰り返し使う skill
特定のリポジトリに依存しない汎用的な手順
明らかに個人の作業習慣に属するワークフロー

たとえば：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

このタイプの skill の特徴は、現在のプロジェクトを離れても使えることです。

`プロジェクト/.codex/skills`

ここに置くのに向いているもの：

このリポジトリでだけ成立する手順
現在のプロジェクトのディレクトリ構成、スクリプト、テンプレートに強く結びついたルール
チームで共有したい skill

たとえば：

このリポジトリ固有の公開フロー
このプロジェクト内でしか使えない生成テンプレート
プロジェクト固有のスクリプトに強く依存する自動化手順

このタイプの skill の特徴は、このリポジトリを離れると意味が薄くなることです。

グローバルに置くか、プロジェクトに置くか

判断基準はシンプルです。

個人の作業習慣に関係するなら ~/.codex/skills
リポジトリのルールに関係するなら プロジェクト/.codex/skills
複数プロジェクトで再利用できるなら、まずはグローバル
複数人で共有し、リポジトリと一緒に育てたいなら、プロジェクト側

今回のリポジトリの状態

現在見えている状態では：

ローカル環境には ~/.codex/skills がある
現在のリポジトリには .codex/skills がない

つまり、今は主にグローバル skills に依存しています。

言い換えると、post-rewrite、post-translate、git-commit-push のような手順は、このリポジトリに明示的に含まれているものではなく、あなた個人のワークフローに近いものです。

ディスク上にあるのに、現在のセッションに表示されない理由

ここでは二つの状態を分けて考える必要があります。

ディスク上に存在する：skill ファイルがローカルのディレクトリにある
セッションに公開されている：現在のセッションがそれを利用可能な skill として登録している

この二つは同じではありません。

そのため、次のようなことが起きます。

~/.codex/skills にはすでに skill がある
しかし / の後に出る一覧には表示されない

これは通常、skill が壊れているという意味ではありません。より多い原因は、現在のセッションがそれを再インデックスしていないことです。

現在のセッションに skill を表示させるには

実用上の手順は次の通りです。

1. 正しいディレクトリに置く

グローバル：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

プロジェクト単位：

`1`	`プロジェクト/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` の先頭を認識できる形にする

最低限、次のような front matter が必要です。

---
name: your-skill-name
description: この skill が何をするものか
---

3. 新規作成または編集後は、新しいセッションを開く

skill が表示されない原因は、ファイルの問題ではなく、現在のセッション開始時に利用可能な skill 一覧がすでに確定していたことかもしれません。

そのため、セッション中に skill を作成しても、ディスク上には存在する一方で、そのセッションでは認識されない場合があります。

いちばん確実な流れは次の通りです。

skill を正しい場所に置く
現在のセッションを終了する
プロジェクトに入り直す
新しいセッションを開く
/ に表示されるか確認する

4. プロジェクト skill は事前に置いておく

プロジェクト/.codex/skills をより安定して認識させたいなら、リポジトリに入り、セッションを開始する前に、それらの skill をプロジェクト内に置いておくのが無難です。

最後に

短くまとめると：

~/.codex/skills は個人用のスキルライブラリ
プロジェクト/.codex/skills はリポジトリ用のローカルルールライブラリ
skill がディレクトリにあることと、現在のセッションに表示されることは別
表示させたいなら、正しいディレクトリに置き、正しい SKILL.md を書き、新しいセッションを開くのが基本

エージェントスキルを使用して、VS Code の Copilot の「コミットメッセージの生成」機能を置き換える

Mon, 06 Apr 2026 13:09:49 +0800

VS Code の GitHub Copilot の「コミットメッセージの生成」は非常に便利な機能です。クォータを使い果たした後のリセット期間は非常に長くなります。この記事は、ローカルエージェントスキルを使用してこの機能を置き換える試みです。

問題と目標

この記事の目的は、直接実装できる代替手段のセットを提供することです。つまり、git-commit-push-zh スキルエージェントを使用して、標準化された送信とプッシュを完了します。

代替: `git-commit-push-zh`

このスキルは、「現在の変更」を固定プロセスに収束します。

変更ステータスを表示します。
現在のブランチを確認します。
変更を一時的に保存します。
中国語の提出情報を生成します。
コミットを実行します。
リモートブランチにプッシュします。

対応するコマンドは次のとおりです。

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

情報提案仕様書の提出

推奨される統一形式:

`1`	`<类型>(<范围>): <中文摘要>`

タイプの例:

feat: 新機能
fix: 問題を修正
docs: ドキュメントの更新
refactor: コードのリファクタリング
chore: メンテナンスの変更

例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

一般的な障害シナリオ

nothing to commit: 現在、送信する変更はありません。プッシュを停止してください。
push が失敗しました: 最初に権限、リモートブランチのステータス、競合を確認してください。
SSH/権限の例外: 認証情報と権限を確認して、再試行してください。

付録: オリジナル `SKILL.md`

次の内容は git-commit-push-zh の元のドキュメントであり、その後の再利用とメンテナンスを容易にするためにそのまま保持されます。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

ワークフロー on KnightLiブログ

Claude-Mem：Claude Code にセッションをまたぐ長期記憶を追加する

何を解決するのか

仕組み

どんな場面に向いているか

インストールと起動

mem-search の使い方

普通のプロジェクト文書との違い

使うときの注意点

この種のツールが注目に値する理由

誰が試すべきか

参考

最後に

Codex がコンピューターを操作し始めると、これから何が変わるのか？

この機能とは何か

なぜ重要なのか

どんなワークフローが変わるのか

1. ソフトウェア間の情報移動

2. 複数の AI ツールの連携

3. オフィスソフトの自動化

一般ユーザーにとっての意味

ソフトウェアの形にも影響する

まだ過度に楽観する段階ではない

最後に

Codex の ~/.codex/skills と プロジェクト/.codex/skills の違い

両者の違い

~/.codex/skills

プロジェクト/.codex/skills

グローバルに置くか、プロジェクトに置くか

今回のリポジトリの状態

ディスク上にあるのに、現在のセッションに表示されない理由

現在のセッションに skill を表示させるには

1. 正しいディレクトリに置く

2. SKILL.md の先頭を認識できる形にする

3. 新規作成または編集後は、新しいセッションを開く

4. プロジェクト skill は事前に置いておく

最後に

エージェント スキルを使用して、VS Code の Copilot の「コミット メッセージの生成」機能を置き換える

問題と目標

代替: git-commit-push-zh

情報提案仕様書の提出

一般的な障害シナリオ

付録: オリジナル SKILL.md

`mem-search` の使い方

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

`~/.codex/skills`

`プロジェクト/.codex/skills`

2. `SKILL.md` の先頭を認識できる形にする

エージェントスキルを使用して、VS Code の Copilot の「コミットメッセージの生成」機能を置き換える

代替: `git-commit-push-zh`

付録: オリジナル `SKILL.md`