Factory DroidのSpecプランをホームディレクトリから移動する方法（2026年版ガイド）

Factoryの設定ドキュメントには「Spec mode settings」というセクションがあります。そこには1文の説明と、正確に1つの設定だけが含まれています。

"Controls the persistent spec store created by Spec Mode."

設定項目は specSaveDir であり、リファレンステーブルのその行には次のように記載されています。

"Directory where saved specs are written. Supports ~ expansion."

デフォルト値は ~/.factory/specs です。

はっきり言っておく価値があります。永続的なspecストアは存在し、それはドキュメント化された機能であり、デフォルトではユーザーごとの場所に保存されます。何も隠されていませんし、何も壊れていません。デフォルト設定は、単に個人用ツールのデフォルトがチームのアーティファクトに適用されているだけです。

また、これは見落としではなく、一貫したハウススタイル（設計方針）でもあります。同じ設定リファレンスにおいて、worktreeDirectory（worktreeフラグで作成されたgit worktreeの親ディレクトリ）のデフォルトは ~/.factory/worktrees です。Factoryは独自の足場（scaffolding）をホームディレクトリに配置します。これは足場としては正しい直感です。しかし、specは足場ではありません。

これにより2つの問題が生じますが、2つ目の問題は特に大きな代償を伴います。

計画が共有されない。 Spec Modeは、まさに計画が最も重要となる作業に推奨されています。

"Spec Mode is for research and planning before implementation. Use it for architecture changes, migrations, security-sensitive work, or any task where you want to review the plan before Droid edits files."

これらはすべて、複数人、複数週間にわたる取り組みです。ステップ4を実装する人は、セッションを実行した人とは異なることがよくありますが、計画は彼らが読める場所にはありません。

このモードが強制する境界線も引用する価値があります。なぜなら、出力が保存するに値するほど信頼できる理由を説明しているからです。

"During Spec Mode, Droid should not edit files, change configuration, make commits, start services, or write to external systems. It can read files, search the repo, inspect linked artifacts, and ask clarifying questions."

推論がタスクの後に残らない。 specはある一瞬（このコードベース、この制約、このオプションのセット）に対して書かれます。6ヶ月後、実装がマージされると、specは誰も開かないホームディレクトリ内の古いファイルになります。その中の意思決定（リプレイコストのためにイベントソーシングのアプローチを却下した、移行を避けるために追加のテーブルを受け入れたなど）は依然として正しく、重要な意味を持っていますが、それらが廃止された計画内の1つの段落としてではなく、「意思決定」として記録されている場所はどこにもありません。

この2つ目の問題は、人々が後になって（通常は誰かが退職したときに）気づくものです。これは、keeping AI context when someone leaves と同じ構図です。知識は書き残されていたものの、個人の場所に書き残されていたのです。

優れたspecを手動でリポジトリにコピーする。 機能はしますし、最初の1、2回は行われます。しかし、ファイルが覚えておく必要のあるパスにあり、作業名ではなくセッション名で命名されているため、そのうちコピーされなくなります。

計画をプルリクエスト（PR）の説明に貼り付ける。 レビュー可能で永続的な場所に残るため、より良い方法です。しかし、PRの説明は1つの差分にスコープが絞られているため、4つのPRにまたがるspecは4つの説明に断片化され、それぞれが他のPRにとって重要だった部分を欠くことになります。

計画をチケットに記載する。 同様のトレードオフがあります。計画はチームに見えるようになり、クローズされる作業項目と結びつきます。しかし、クローズされたチケットは、なぜそのテーブルが存在するのかという理由を探す場所としては適していません。

specを AGENTS.md のセクションにする。 これは2つの異なる種類のコンテンツを混同しています。AGENTS.md はすべてのセッションで読み込まれる常設の指示を保持するものであり、specは1回限りの計画です。これらをマージすると、3月に完了した作業を説明する、常に読み込まれる長いファイルになってしまいます。

デフォルトのままにして、セッションのトランスクリプト（履歴）に頼る。 最も弱い選択肢です。Droid自身のドキュメントでも、サブエージェントとセッションの動作はセッション内に限定されると説明されており、トランスクリプトはドキュメントではなくログにすぎません。Spec Modeの肝は、トランスクリプトよりも優れたものを生成することにあります。

すべてのspecを永久にコミットする。 過剰修正です。何も考えずにストアをリポジトリに向けると、すでに変更された実装を提案する古い計画ファイルが何十個も作成され、読者の注意を引くために実際のドキュメントと競合し、エージェントの注意を引くために実際の指示ファイルと競合することになります。

これら6つのパターンすべてに共通するのは、人々がspecを個人のスクラッチファイルか永続的なドキュメントのいずれかとして扱っている点ですが、そのどちらでもありません。それは、いくつかの永続的な事実を含む一時的なアーティファクトです。解決策は、この両方の側面に対処する必要があります。

3つのステップがあります。1つ目は1行の変更、2つ目は何をコミットするかの決定、3つ目はそれを定着させるためのステップです。

ステップ 1: specSaveDir をプロジェクトに向ける

プロジェクトのFactory設定で specSaveDir を、ホームディレクトリのデフォルトを受け入れるのではなく、リポジトリ内のディレクトリに設定します。Factoryはユーザーレベルの ~/.factory/settings.json と、プロジェクト内の .factory/ フォルダから設定を読み込むため、この設定はプロジェクトファイルに記述してください。specの保存場所はマシンのプロパティではなく、プロジェクトのプロパティです。

実際に依存する前に、最初の実行時にパスが期待通りに解決されることを確認してください。この設定に関するドキュメントの注記には ~ の展開をサポートしているとあるため、想定するのではなく、選択したパススタイルで得られる動作を確認する価値があります。

このファイルを開いている間に、関連する2つの設定を知っておくと便利です。1つ目は sessionDefaultSettings.interactionMode で、ドキュメントに記載されている役割はシンプルです。

"Sets whether new sessions start in Auto or Spec Mode."

これを spec に設定すると、計画をデフォルトの姿勢にしたいリポジトリで役立ちます。2つ目は specModeModel で、リファレンスではSpec Modeでセッションが開始されるときに使用されるモデルのオーバーライドとして説明されています。計画と実装では適したモデルが異なるため、設定する価値があります。また、.droid.yaml は古い設定インターフェースとしてドキュメント化されているため、.factory/ ファイルを使用してください。

ステップ 2: コミットするものと無視するものを決める

specがリポジトリに保存されるようになったので、慎重に決定してください。なぜなら、「すべてをコミットする」というデフォルトの対応は、前述の過剰修正にあたるからです。

有用な切り分け方は「寿命」によるものです。進行中の作業に対するspecはコミットされるべきです。それは共有された計画であり、2つ目のPRのレビュアーがそれを必要とするからです。リリース済みの作業に対するspecは役割を終えており、それを残しておくと、もはやシステムを説明していない計画を誰かに読ませることになります。

Factoryは、マシン固有の設定を行うための仕組みを提供しています。任意の .factory/ フォルダ内の settings.json と並んで settings.local.json を作成でき、ドキュメントに記載されている動作は以下の通りです。

"Local overrides merge on top of the corresponding settings.json at the same level and follow the same hierarchy precedence. Add settings.local.json to .gitignore if you want to keep machine-specific preferences out of version control."

本当に個人的な設定にはこれを使用し、共有の settings.json には共有のspecパスを保持させておきます。

ステップ 3: 計画をアーカイブする前に意思決定を抽出する

これが結果を左右するステップであり、1つのspecにつき約2分しかかかりません。

specの作業がマージされたら、計画を最後にもう一度読み、来年も依然として真実である文を抜き出します。実装手順ではありません。それらはすでにコードに反映されています。抽出するのは「意思決定」です。何が検討され、何が却下され、それはなぜか。specには通常、20段落のシーケンスの文章の中に、これらが3つか4つ埋もれています。

その3、4文こそが、そのドキュメントの永続的な価値のすべてです。それらを計画ファイル以外の場所に記録すれば、何も失うことなく計画ファイルをアーカイブまたは削除できます。このステップをスキップすると、中身を失うことを恐れて古いspecを永遠に保持し続けることになり、人々が何度もstop re-explaining context to AI（AIにコンテキストを再説明する）ことになる、まさに「ため込み」問題に逆戻りしてしまいます。

抽出された意思決定の保存先が MemoryLake です。これはリポジトリや特定のエージェントの外に位置し、MCPやAPIを介してプロジェクトの意思決定に関する質問に答えます。そのため、計画ファイルが消えた後でも、誰がどのツールで尋ねても、specからの推論を利用できます。specはFactoryが書き込むプロジェクトディレクトリに残りますが、共有レイヤーには保存しておく価値のある4つの文が保持されます。

ステップ 1: APIキーを作成する

キーを生成し、約30秒で最初のリクエストを行います。計画を読み進めながら各意思決定を保存する場所を確保するために、上記のステップ3の前にこれを行ってください。

ステップ 2: 最初のメモリをアップロードする

ホームディレクトリにまだ残っているものも含め、既存のspecを確認し、何が選択され、何が却下され、その理由は何かという実際の意思決定をそれぞれ記録します。サポートドキュメントやファイルも同じ場所に保存できます。turning project docs into AI memory では、書き直すことなくこれらを一括で行う方法を解説しています。

ステップ 3: AIとエージェントを接続する

Droid、Claude、Codex、およびその他のエージェントにMCPまたはAPI経由でアクセスを許可します。次のSpec Modeセッションは、過去5回の決定事項をすでに把握した状態で開始されるため、これは「計画」と「再計画」の決定的な違いとなります。

最初の変化は、計画が影響を受ける人々によってレビュー可能になることです。それはリポジトリ内、ブランチ上、差分の中に存在します。ステップ4の実装者は、誰かにファイルを求めることなくそれを読むことができます。

2つ目は、Spec Modeがより優れた入力を得られるようになることです。Droidは計画を提案する前にリポジトリを調査するため、過去数回の計画と過去の意思決定のクエリ可能な記録が含まれるリポジトリは、どちらも含まれないリポジトリよりも多くの情報を提供します。

3つ目は、specが蓄積しなくなることです。永続的なコンテンツが抽出されれば、リリース済みの計画を削除しても問題ありません。進行中の計画のディレクトリは十分に小さく保たれ、人々がそれを読むようになります。

4つ目は、計画がノートPCの寿命を超えて存続することです。ホームディレクトリのパスはマシンごとであり、これは Claude Code forgetting things across machines（Claude Codeがマシン間で記憶を忘れてしまう問題）の背景にある非対称性と同じです。同じ解決策が適用されます。共有するものは、1台のマシンではなく、リポジトリや共有サービスが保持する場所に配置することです。

5つ目は、引き継ぎが短縮されることです。sharing context between sessions（セッション間でのコンテキストの共有）が解決しようとしていることの半分は、他の誰も見ることができないドキュメントの中で、かつて慎重に下された意思決定を、誰かが再び導き出そうとしてしまう問題です。

specSaveDir はユーザー設定ではなく、プロジェクト設定で設定する。 specの保存場所はプロジェクトのプロパティです。ユーザーレベルの設定は、次に開くリポジトリでは意味をなさないパスを指す可能性があります。

最初の実行時にパスを確認する。 この設定に関するドキュメントの注記は ~ の展開に関するものです。依存する前に、実際にどのようなパスになるかを確認してください。

進行中のspecはコミットし、リリース済みのものは引退させる。 マージされた作業に対する計画は、すでに変更されたシステムの説明になってしまいます。

アーカイブする前に意思決定を抽出する。 1つのspecにつき3、4文。これがすべての作業であり、これにより安全に削除できるようになります。

指示ファイルにspecを入れない。 AGENTS.md はすべてのセッションで読み込まれます。完了した計画は、すべてのセッションに属するものではありません。

マシン固有の好みには settings.local.json を使用する。 これは同じレベルの共有ファイルの上にマージされ、git無視されるように設計されているため、共有のspecパスを共有したままにできます。

リポジトリのデフォルトをSpec Modeにすることを検討する。 インタラクションモードを spec に設定すると、計画が望ましい作業において、計画をデフォルトの姿勢にすることができます。

.droid.yaml から移行する。 これは古い設定インターフェースとしてドキュメント化されており、現在のものは .factory/ ファイルです。

Factoryは、単一の設定 specSaveDir によって制御される永続的なspecストアをドキュメント化しており、デフォルトはホームフォルダ内のディレクトリです。Spec Mode自体は、リポジトリを調査し、人間の承認を求める読み取り専用の計画であり、アーキテクチャの変更、移行、およびセキュリティに敏感な作業に推奨されます。これら2つの事実を組み合わせると、デフォルトの設定は、チームが最も慎重に推論したドキュメントを、チームが見ることのできない唯一の場所に書き込むことになります。

パスを変更するのは1行で済みます。効果を発揮するのはその後の習慣です。進行中の作業を説明する計画をコミットし、すでにリリースされた作業を説明する計画を引退させ、引退させる前に、来年も依然として重要となる3、4つの意思決定を抽出します。そうすることで、Spec Modeは机上の空論ではなく、1台のノートPCが保持する優れた意思決定ではなく、チームが保持する優れた意思決定を生み出すマシンになります。