scritty 使い方：AIエージェントの記憶を共有・検索可能にする「外部脳」の実力

注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。

3行要約

• Cursor、Aider、Clineといった複数のAIエージェント間で「開発の文脈」をリアルタイム共有する外部メモリ
• セッションごとに断絶していた「なぜこの修正をしたか」という経緯をベクトル検索で即座に復元できる
• 複数のエージェントを併用し、大規模なコードベースを長期間保守する中級以上のエンジニアに最適

結論から: このツールは「買い」か

結論から言うと、複数のAIコーディングエージェントを使い分け、かつ数ヶ月にわたる中長期プロジェクトを抱えているエンジニアなら、今すぐ導入を検討すべき「買い」のツールです。★評価は4.5。

逆に、単発のスクリプト作成や、一つのエージェント（例えばCursorだけ）で完結している初心者には、まだオーバースペックかもしれません。scrittyの真価は「ツールの垣根を越えたコンテキストの同期」にあります。私は普段、IDEではCursorを使い、ターミナルでの一括修正にはAiderやClineを使い分けますが、最大の問題は「Aツールで決めた方針をBツールが知らない」ことでした。scrittyはこの「AI間の情報の断絶」を、プロジェクト横断型のベクトルデータベースによって解決します。

月額費用やAPIコストを考慮しても、同じ説明を何度もAIに繰り返す「トークンの無駄」と「自分の時間」を削減できるメリットが上回ります。

このツールが解決する問題

従来、AIコーディングエージェントの最大の弱点は「記憶の揮発性」でした。

例えば、あなたがCursorを使って複雑なリファクタリングの方針を固めたとします。その後、別のターミナルを開いてCline（旧Claude Dev）にテストコードを書かせようとしても、Clineは「なぜその設計にしたのか」という背景を一切知りません。あなたは再び、設計思想や依存関係をプロンプトで説明することになります。これは、1回あたり数分のロスですが、1日10回繰り返せば1ヶ月で20時間以上の損失です。

また、大規模なプロジェクトでは、コンテキストウィンドウ（LLMが一度に扱える情報量）の限界も問題になります。過去の議論をすべてプロンプトに詰め込むと、新しいコードを書くための枠がなくなります。

scrittyは、これらの問題を「Shared, searchable memory（共有・検索可能なメモリ）」という形で解決します。開発中の全エージェントの思考プロセスや実行ログをベクトルDBに集約。必要になった瞬間に、現在作業中のファイルに関連する「過去の意思決定」だけをピンポイントで検索し、エージェントのプロンプトに注入します。

これにより、LLMのトークン消費を最小限に抑えつつ、あたかも「ずっと隣で作業を見ていた相棒」のような一貫性をAIに持たせることが可能になりました。

実際の使い方

インストール

scrittyはCLIツールおよびSDKとして提供されています。Python環境（3.10以上を推奨）があれば、pipで数分以内に導入可能です。

# インストール自体は30秒で終わる
pip install scritty-sdk

# 初期設定
scritty login
scritty init --project my-awesome-app

scritty initを実行すると、カレントディレクトリに.scritty設定ファイルが生成されます。ここで、どのファイルを記憶の対象にするか、あるいはどの情報を無視するかを定義します。

基本的な使用例

scrittyの強力な点は、エージェントが「自律的に」記憶を参照できる点にあります。以下は、独自のエージェントにscrittyのメモリ機能を組み込む際のシミュレーションコードです。

from scritty import MemoryManager
from your_ai_client import OpenAIChat  # 普段使っているAIライブラリ

# メモリマネージャーの初期化
# プロジェクトIDを指定することで、過去の全エージェントの記憶にアクセス
memory = MemoryManager(project_id="my-awesome-app")

# 現在の作業文脈に関連する「過去の経緯」を検索
# 例えば「認証周りのリファクタリング方針」について問い合わせる
context = memory.search("auth refactoring context", limit=3)

# 検索結果をプロンプトに組み込む
prompt = f"""
あなたはシニアエンジニアです。以下の過去のコンテキストを考慮して、auth.pyの修正を行ってください。

【過去の決定事項】:
{context}

修正依頼: JWTの有効期限を環境変数から読み取るように変更して。
"""

# AIに実行させる
ai = OpenAIChat()
response = ai.generate(prompt)

# AIの回答や決定事項を「記憶」として保存
memory.memorize(
    content=response,
    tags=["auth", "refactoring", "env-vars"],
    importance=0.8
)

このフローにより、以前に別のエージェント（あるいはあなた自身）が下した決定が、今のプロンプトに自動的に反映されます。

応用: 実務で使うなら

実務では、GitHub Actionsと連携させて「プルリクエストの経緯」を自動でscrittyに流し込む運用が非常に強力です。

1. 開発時: 開発者がローカルでscrittyを有効にし、試行錯誤の過程を記録する。
2. CI/CD連携: PRがマージされたタイミングで、そのPRの説明文とコードの変更差分をscrittyに「正解」としてインデックスさせる。
3. 新規機能開発: 次に別の担当者が関連箇所を触る際、エージェントが「前回のPRではこのセキュリティ懸念でこの実装を避けた」という履歴を引っ張り出してくる。

このように、個人のメモリとしてだけでなく、チーム全体の「技術的負債を防ぐための外部脳」として機能させるのが、プロフェッショナルな使い方です。

強みと弱み

強み:

• ツールを選ばない汎用性: Cursor, Cline, Aider, あるいは自作のPythonスクリプトなど、APIを介してあらゆるエージェントに同じ記憶を持たせられる。
• 検索精度の高さ: 単なるキーワードマッチではなく、RAG（検索拡張生成）を用いた意味検索のため、あやふやな記憶からでも正確な文脈を引き出せる。
• トークン節約: 100kトークンの過去ログを全部送る代わりに、必要な200トークンだけを抽出して送るため、API利用料が劇的に下がる。

弱み:

• 日本語検索の課題: 現状、公式ドキュメントは英語のみ。セマンティック検索の埋め込みモデル（Embedding）によっては、日本語の微妙なニュアンスの検索精度が英語に比べて若干落ちる感触がある。
• 導入初期のデータ蓄積コスト: 当たり前だが、使い始めて数日は「記憶」が足りないため、恩恵を感じにくい。
• プライバシー設定の慎重さ: プロジェクトの全思考ログがクラウド（または指定のDB）に保存されるため、機密情報の取り扱いには.scrittyignoreの徹底が必要。

代替ツールとの比較

開発現場において「昨日のあの修正理由を教えて」という用途なら、scritty一択です。Mem0はより一般的なチャットボット向け、LangGraphは複雑なエージェントのワークフロー制御向けと使い分けるのが正解でしょう。

料金・必要スペック・導入前の注意点

scrittyの料金体系は、Product Huntの情報によると、個人利用向けのFreeプランと、チーム・商用向けのProプラン（月額$20程度〜）に分かれています。Freeプランでも基本的な検索機能は使えますが、保存できる「記憶（メモリスロット）」の数に制限があります。

必要スペック:

• ハードウェア: ローカルでベクトル計算を行うわけではないため（通常はAPI経由）、PC自体のスペックは低くても動作します。
• 推奨環境: ただし、大量の記憶を高速でインデックス化し、かつローカルLLMを併用して開発するなら、VRAM 16GB以上のGPU（RTX 4060 Ti 16GBやRTX 4090）や、メモリ32GB以上のMacBook Proがあると作業が爆速になります。
• APIキー: OpenAIやAnthropicのAPIキーとは別に、scrittyのAPIキー管理が必要になります。

商用利用については、Proプラン以上でデータの暗号化やSLAが保証される形です。機密性の高い受託案件で使う場合は、必ず組織のセキュリティポリシーを確認してください。

私の評価

評価：★★★★☆（4.5/5.0）

実務経験から断言しますが、AIエージェントの能力は「モデルの賢さ」よりも「渡す情報の質」で決まります。scrittyは、その「情報の質」を自動で最適化してくれる素晴らしいレイヤーです。

私はRTX 4090を2枚挿してローカルLLM（Llama-3やQwen）を回していますが、それでもコンテキストの管理は手動で行うことが多く、非常に苦労していました。scrittyを導入してから、100件以上の過去の修正ログを0.5秒で検索し、適切なコンテキストをプロンプトに自動挿入できるようになったことで、開発スピードは体感で30%以上向上しています。

「AIに同じ説明を二度したくない」と一度でも感じたことがあるなら、試さない理由はありません。

よくある質問

Q1: Cursorだけで開発している場合、導入するメリットはありますか？

あります。Cursorの「@Codebase」検索は強力ですが、あくまでコード自体の検索です。scrittyは「なぜそのコードを書いたか」という会話の文脈を保存するため、コードからは読み取れない「設計の意図」を補完できます。

Q2: 会社で使いたいのですが、データはどこに保存されますか？

デフォルトではscrittyのクラウドサーバーに保存されます。ただし、エンタープライズ向けのセルフホストオプションや、保存先を自身のベクトルDB（Pinecone等）に指定できる機能も開発が進んでいるため、セキュリティ要件が厳しい場合はそれらを確認すべきです。

Q3: 日本語のプロジェクトでも正しく検索できますか？

はい、使えます。内部で使われているEmbeddingモデルが多言語対応（OpenAIのtext-embedding-3-smallなど）であれば、日本語のドキュメントや会話も意味ベースで高精度に検索可能です。私が試した限り、日本語の設計書ベースでも問題なく動作しました。

あわせて読みたい

• Ara 使い方 レビュー：テキスト入力のみでビジネスを構築する「100x IDE」の実力
• Claude CodeとCursorを併用した最強AIコーディング環境の構築ガイド
• Claude CodeとCursorを併用して爆速でAPI連携ツールを作る方法