Lex

中核となるループを見る · Lex を使うべきですか？ · 5 分間の試用 · エージェントの評価 · ドキュメント

---

Lex が解決する問題

コーディングエージェントは、目の前のリポジトリを調べることができます。しかし、そのコードにまつわる作業について、確実に思い出せるとは限りません。

• 3 セッション前になぜその決定がなされたのか。
• すでに失敗したアプローチはどれか。
• 何が阻害されていて、次に何をすべきか。
• 越えてはならないリポジトリの境界はどこか。
• 別のエージェントが最初からやり直さずに作業を続けるために必要な情報は何か。

Lex は、この継続性を意図的で重要度の高い Frames として保持します。

Frame は、継続的な監視ではなく、意図的な引き継ぎです。つまり、何が変わり、何が重要で、何が残っていて、作業が次にどこへ進むのかを示すチェックポイントです。Lex は後から関連する Frames を呼び戻し、新しいセッション向けに範囲を限定した、プロンプトに安全な初期コンテキストを作成できます。

Work happens → Lex remembers what mattered → the next session continues

まずは remember、recall、context から始めましょう。ローカルでは SQLite がデフォルトです。信頼できるホスト間やワークスペース間でコンテキストを共有する必要がある場合は、PostgreSQL を利用できます。それ以外はすべて任意です。

記憶 → 呼び戻し → 継続

lex remember \
  --summary "Kept authentication token validation in API middleware" \
  --next "Add the service grant and rerun tests" \
  --modules unscoped \
  --blockers "Missing PermissionService grant"

lex recall "authentication"

lex context "authentication" --max-tokens 500

これが中核となるループです。

• remember は、意図的な作業のチェックポイントを 1 つ記録します。
• recall は、トピックが再び関連するようになったときに、その情報を取得します。
• context は、一致する Frames を、エージェント向けの範囲が限定された読み取り専用の初期コンテキストにまとめます。

次のセッションで得られるもの

セッションの最後に、エージェントは、そうしなければ失われてしまう状態を記録します。新しいセッションが始まると、人間に会話の再現を求めたり、差分から意図を逆算したりせずに、決定事項、阻害要因、次のアクションを復元できます。

Decision: token validation belongs in API middleware
Blocker: the service grant is still missing
Next: add the grant and rerun the authentication tests

価値は、Lex が記録を保存したことではありません。次のセッションが作業を続けられることにあります。

Lex を使うべきですか？

エージェントが次のような情報を繰り返しあなたに確認する場合は、Lex を評価する価値があります。

• なぜ変更が行われたのか。
• どこで作業が止まり、次に何をすべきか。
• 再発見すべきでない阻害要因や失敗したアプローチ。
• リポジトリ固有のモジュールやポリシーの制約。
• ブランチの切り替え、引き継ぎ、新しいエージェントセッションを経ても保持する必要があるコンテキスト。

作業が短期間で終わる場合、リポジトリにすでに効果的な継続性の仕組みがある場合、またはリポジトリの運用者に保存を任せられる永続的なコンテキストがない場合は、Lex はおそらく役に立ちません。

エージェントに尋ねる

評価は意図的に読み取り専用です。リポジトリを調べられるエージェントに、以下を貼り付けてください。

Read https://github.com/Guffawaffle/lex/blob/main/docs/agent-evaluation.md and evaluate this
repository against it. Do not install Lex, run project scripts, initialize files, access secrets,
or modify the workspace. Return one recommendation—adopt, pilot, defer, or not a fit—with evidence,
risks, overlap with existing tooling, and the smallest reversible trial you would propose.

評価基準の全文とローカルファイル版は、エージェントの評価にあります。

5分間のパイロット

主張を試してみませんか？ 機密情報を含まないチェックポイントを1つ保存し、新しいセッションを開始して、作業内容をもう一度説明しなくても続けられるか確認してください。

Node.js 24以降が必要です。Lex による、根拠のない上限の設定はありません。既存ユーザーは、Lex 4.4の移行と復旧ガイドに従い、同梱のSQLiteバイナリを確認してください。Lex 4.4.4では、ネイティブの再ビルドは不要です。Linuxのglibc環境では、glibc 2.35以降が必要です。

この承認済みパイロットでは、.smartergpt/lex/ 配下のローカルSQLiteストアにFrameを1つ書き込みます。lex init の実行、ポリシーの生成、アシスタントの指示のプロジェクションは行いません。ファイルシステムを完全に分離したい場合は、使い捨てのブランチ、worktree、またはクローンを使用してください。

1. 実際のチェックポイントを1つ保存する

LEX_STORE=sqlite npx @smartergpt/lex remember \
  --reference-point "Lex pilot" \
  --summary "Evaluating whether durable agent handoffs help this repository" \
  --next "Recall this checkpoint in a new session" \
  --modules unscoped

LEX_STORE=sqlite を指定すると、既存のPostgreSQL設定によってパイロットが共有ストアにリダイレクトされるのを防げます。

2. 新しいセッションを開始してから、作業を復元する

LEX_STORE=sqlite npx @smartergpt/lex recall "Lex pilot"
LEX_STORE=sqlite npx @smartergpt/lex context "Lex pilot" --max-tokens 500

新しいセッションで、想起した内容または範囲を限定した出力を使い、有用なコンテキストをもう一度伝えずに済むか確認してください。この結果が、インストールの成功ではなく、パイロットの成功基準です。

検証専用の手順、ファイルシステムへの具体的な影響、ロールバックのガイダンスを確認する

役立つチェックポイントを作成する

優れたFrameは、必要最小限で具体的です。判断、ブロッカー、ブランチの切り替え、引き継ぎなど、周囲の意図が失われると次のセッションで作業をやり直すことになるタイミングで記録してください。

lex remember \
  --reference-point "Authentication refresh" \
  --summary "Moved token validation into API middleware" \
  --next "Add password-reset coverage" \
  --modules "services/auth,api/middleware" \
  --blockers "Need PermissionService access"

変更点を記録し、--next を実行可能な内容にし、ブロッカーを明確に示し、正直に指定できる最も狭いモジュールスコープを使用してください。編集やツール呼び出しをすべて記録しないでください。

リポジトリポリシーがある場合、Lexは現在の証拠からモジュールスコープを推測できます。

lex remember \
  --summary "Finished context wiring" \
  --next "Run validation" \
  --modules auto

リポジトリに有用なモジュール体系がまだない場合は、--modules unscoped を使用してください。ポリシーは任意の拡張機能であり、最初のFrameに必須ではありません。

より小さなエージェントの予算や自動化向けに、コンパクトな想起と構造化されたコンテキストを利用できます。

lex recall --list 5 --summary
lex --json context --branch main --limit 5

継続性を保つワークフローを学ぶ

必要なものだけを追加する

必要なもの	追加するもの	まずはこちら
永続的なローカル引き継ぎ	SQLiteを使ったFrame	クイックスタート
セッション開始時の簡潔なコンテキスト	読み取り専用のlex context	エージェントの継続性
アシスタントからのMCPアクセス	@smartergpt/lex-mcp	MCPのセットアップ
リポジトリの境界	ポリシーチェック	ポリシーの使用方法
近隣モジュールのコンテキスト	Policy Neighborhood	コンテキストガイド
正式なアシスタント指示	指示のプロジェクション	指示
型付きMarkdownプロジェクトナレッジ	派生KnowledgeFrameスナップショット	KnowledgeFrames
ホスト間での共有ストレージ	PostgreSQL	ストアの契約とスコープセキュリティ
信頼されたテナント／ワークスペースのスコープ	実行時の権限とRLS	実行時スコープ
組み込みアプリケーションからのアクセス	TypeScriptパッケージのエクスポート	パブリックAPI

リポジトリに加わる変更

初期状態のローカルワークフローは、意図的に明示されています。

• lex init は Lex のワークスペース／設定ファイルを作成します。
• lex remember は選択したストアに Frame を書き込みます。
• lex context はストアへの読み取り専用アクセスを厳格に使用します。recall と通常のイントロスペクションは Frame を変更しませんが、互換性のための経路では、選択したストアの初期化または移行が行われる場合があります。
• SQLite のデフォルトの保存先は、ワークスペースを基準とした .smartergpt/lex/memory.db です。
• ポリシーと正規の指示ファイルは、これらの機能を選んだ場合にのみリポジトリ内のファイルになります。
• PostgreSQL、MCP ホスティング、指示の投影、CI によるポリシー適用は、それぞれ個別にオプトインできます。

Frame には機密性の高いプロジェクトコンテキストが含まれる場合があります。認証情報、トークン、秘密鍵、または確認していない秘密情報は保存しないでください。信頼できるユーザーが作成したものであっても、呼び出された Frame の本文は、信頼できない過去のデータとして扱ってください。

Lex は Frame を Lex のクラウドサービスに送信しません。エージェントホスト、パッケージレジストリ、PostgreSQL のデプロイ環境、その他の周辺ツールには、独自のネットワークやデータの取り扱いがある場合があります。これらの境界は個別に評価してください。

セキュリティポリシー · ストアの契約 · 環境設定リファレンス

Lex が提供しないもの

• チャットボットやエージェントランタイム
• トランスクリプトの記録ツールや自動キャプチャシステム
• テスト、レビュー、課題追跡、CI の代替
• クラウドメモリサービス
• MCP 専用の製品
• オーケストレーター、機能フレームワーク、ペルソナエンジン

周辺のツールセット

エコシステムのバンドルは必要ありません。明示されたパッケージ間の関係を考慮しながら、ワークフローに必要な機能を選択してください。

プロジェクト	責務	関係
Lex	持続的な作業コンテキスト、リポジトリポリシー、オプションの近隣コンテキスト、指示、スコープを限定した Frame ストレージ	コアライブラリと CLI
AXF	検査可能なワークスペース機能と、その実行境界	単独でも使用可能。Lex と連携
LexRunner	ファンアウト、試行、ワーカー／ワークスペースの調整、検証、マージウィーブ	継続性のために Lex を使用
Lex-MCP	Lex の機能を利用する軽量な MCP トランスポート	対応する Lex リリースを固定
LexSona	ペルソナとレビュー済みルールから導出される行動制約	Lex のストレージ契約を通じて統合

簡単に言うと、Lex は記憶し、説明します。AXF は機能を公開します。LexRunner は作業を調整します。Lex-MCP は Lex を MCP 経由で転送します。LexSona は行動制約を導出します。

エージェントおよび自動化のインターフェース

Lex は、複数のエントリポイントから同じコア機能を利用できます。

• 人間、スクリプト、エージェントシェル向けの CLI
• 自動化向けの 構造化 JSON と AXError の復旧情報
• @smartergpt/lex-mcp または埋め込み可能なサーバーエクスポートを通じた MCP
• アプリケーションと信頼されたホスト向けの TypeScript API

Frame Schema v8 は、現在の正規 Frame 契約です。パッケージの公開エクスポートマップは semver に従って管理されます。利用側は、宣言されていない dist/ やソースのパスをインポートしないでください。

CLI 出力の契約 · MCP ツール · 公開パッケージのエントリポイント · 契約の範囲

次のステップを選ぶ

次のような場合は…	こちらをお読みください…
Lex が目的に合うか判断している	エージェントの評価
初めて Lex を試す	クイックスタート
エージェント間の引き継ぎを設計する	エージェントの継続性
MCP クライアントを接続する	MCP サーバー
SQLite または PostgreSQL を運用する	ストアの契約 および PostgreSQL の権限
信頼できるマルチテナントホストを構築する	ランタイムスコープ および PostgreSQL のスコープセキュリティ
TypeScript API を使用する	パブリックパッケージ API
型付きの規範的宣言をコンパイルする	規範的ポリシーコンパイラー
パスまたはランタイムの動作を設定する	環境変数
既知の制約を確認する	制限事項 および よくある質問
Lex に貢献する	貢献ガイド
アーキテクチャ上の決定を確認する	ADR

インストールに関する注意事項

# Global CLI
npm install -g @smartergpt/lex

# Repository dependency
npm install @smartergpt/lex

WSL ユーザーは、Windows の npm シムや npm の _npx キャッシュが PATH 上で優先されないように、Lex を WSL 内にネイティブにインストールしてください。WSL へのネイティブインストールを参照してください。

一般的なローカル互換性設定には、LEX_DB_PATH、LEX_POLICY_PATH、 LEX_LOG_LEVEL、LEX_LOG_PRETTY、LEX_GIT_MODE、LEX_DB_KEY があります。PostgreSQL の選択には LEX_STORE と LEX_DATABASE_URL を使用します。信頼できる Lex ホストでは、環境変数からスコープや権限を再構築するのではなく、それらを明示的に組み合わせます。

環境変数の完全なリファレンス

プロジェクトのステータス

現在のバージョン： 4.4.4

Lex 4.4.4 では、信頼できるワークスペースの宛先の事前確認と保存レシートにおける Windows のルート比較を修正しています。4.4.4 リリースノート、4.4 リリースノート、移行ガイドを参照してください。候補メタデータは公開の証拠ではありません。正確な新しいペアが検証されるまでは、検証済みの既存ランタイムを保持してください。

Lex 4 は、ローカル SQLite ワークフローを維持しながら、明示的なランタイム ID と権限、スコープに紐づく Frame ストア、PostgreSQL の行レベルセキュリティへの対応、信頼できるホストの構成を提供します。Lex 4 には Node 24 以降が必要であり、Ecosystem 3.1 互換性トレインの一環としてリリースされています。

Lex 4 の移行および復旧ガイド、リリース履歴を記載した変更履歴、ライブのエンドツーエンドの 2 テナント／5 ワークスペース受け入れパスを示すLex 3 PostgreSQL 分離カナリアを参照してください。

貢献

貢献を歓迎します。貢献ガイドでは、開発環境のセットアップ、テスト、ローカル CI、フォーマット、署名、変更セット、リリースワークフローについて説明しています。

リポジトリ全体のフォーマット検証では、npm run local-ci -- --pretty はチェックのみを行います。--prettier はこれと完全に同じエイリアスです。フォーマットの変更は、別途 npm run format を実行してください。

ライセンス

Lex は MIT ライセンスの下で利用できます。