AIとの創作に必要だったのは、壊していい場所と拾い上げる記憶だった

Codex や ChatGPT と長く話していると、仕事の依頼でも、雑談でも、試作でも、急に妙な火花が出ることがある。最初はただの思いつきだったものが、数分後には記事の芯になり、さらに話しているうちに小さなツールや運用ルールの種になる。面白いのはそこからで、問題は「その火花をどこに置くのか」になる。

通常の開発なら repo があり、issue があり、README があり、AGENTS.md がある。けれど、AIとの創作はいつもそこから始まるわけではない。むしろ、正式な名前を付ける前、目的がまだ揺れている段階、失敗しても笑って捨てられる段階にこそ、いちばん勢いのある会話がある。

そこで必要になったのが、壊していい場所と、拾い上げるための記憶を分ける考え方だった。自分の運用では、/Users/suzukimakoto/Desktop/TEST-RUN のような揮発的な作業場を自由なキャンバスとして使い、残す価値が出たものだけを Obsidian や project、記事制作フローへ明示的に昇格させる。

この設計は、きれいな管理術というより、AI時代の作業場に対する割り切りに近い。全部を最初から整理しようとすると、会話の勢いが死ぬ。全部を放置すると、せっかくの発見が消える。だから、壊していい場所と消えてはいけない場所を最初から分ける。

仕事のrepoには最初から責任がある

仕事用の repo は、入った瞬間から責任を帯びる。ファイル名、ディレクトリ構造、依存関係、テスト、履歴、レビュー、将来の保守。そこにあるものは、たとえ試し書きでも、あとから誰かが意味を読み取ろうとする。

AIとの会話をすべて repo に直接流し込むと、発想の段階から成果物の顔をし始める。これは便利なようで、かなり重い。まだ笑いながら壊したいだけのアイデアまで、最初から「あとで説明できる形」に寄せられてしまう。

構造は成果物を安定させる

repo の構造は強い。決まった場所にコードがあり、決まった場所に設定があり、決まった場所にテストがある。Codex に作業を頼む時も、AGENTS.md があれば、その repo の流儀、禁止事項、優先順位を明示できる。

これは成果物を安定させるためには非常に重要だ。AIが何を読めばよいか、どのコマンドを使えばよいか、どのファイルを触ってはいけないかがはっきりする。再現性があり、履歴が残り、問題が起きても戻りやすい。

WordPress、SWELL、StructCiv、ローカルスクリプトのように複数の要素が絡む運用では、構造がないとすぐに迷子になる。どの HTML が最新か、どの YAML が正本か、どの出力を貼るべきかが曖昧になると、AIに任せたつもりが、人間側の確認コストだけ増える。構造は、その混乱を減らすための骨組みになる。

ただし、骨組みは成果物を支えるためのものであって、発想の発生源そのものではない。repo は完成に近づくほど頼もしいが、まだ何になるか分からない会話を置く場所としては、少し姿勢が正しすぎる。

場所	向いている役割
仕事用repo	実装、レビュー、履歴、再現性、保守を担う正式な成果物置き場
TEST-RUN	雑談、試作、記事ネタ、失敗、比較を自由に散らせる揮発的な作業場

早すぎる構造は発想を固める

AIとの創作では、最初の数分が妙に重要になる。何気ない雑談、少し荒い比喩、作りかけの運用案、記事にするにはまだ薄いけれど妙に引っかかる一言。こういうものは、早く分類しすぎると伸びにくくなる。

たとえば「これは記事ネタだ」と早めに決めると、会話は記事構成へ寄っていく。「これはプロジェクトだ」と決めると、要件やファイル構造を考え始める。どちらも悪くないが、まだ素材が柔らかい段階では、決めること自体が余白を削る。

repo-first の運用に慣れているほど、この罠に入りやすい。何か思いついたらディレクトリを切り、README を置き、AGENTS.md を整える。開発としては正しい。けれど、創作の初速としては少し硬い。まだ名前のないものに、先に名札と住所を与えてしまうからだ。

そこで、正式な repo に入れる前の場所が必要になる。責任が薄く、壊してよく、途中で話題が変わってもかまわない場所。成果物の前に、発想が発想のまま走れる場所である。

私の環境に作ってあるTEST-RUNディレクトリは壊していい真っ白なキャンバス

TEST-RUN は、そのための場所としてかなり相性がよい。名前からして本番ではない。何かを試す、壊す、混ぜる、捨てる、たまに拾う。そういう振る舞いを許す名前になっている。

ここで重要なのは、TEST-RUN を「雑な一時フォルダ」と見なさないことだ。雑に見えることと、意図的に揮発させることは違う。前者は管理の失敗で、後者は探索のための設計である。

雑談から始まる実際のワークフロー

実際の流れは、たいていきれいではない。Codex と話しているうちに、Obsidian memory の話になり、そこから AGENTS.md の役割に飛び、さらに StructCiv の記事生成フローに戻る。途中で WordPress の貼り付け運用や clipboard-handoff の話が混ざることもある。

普通の開発フローなら、これは散らかっている。けれど、創作の前段階として見ると、この散らかり方に価値がある。別々のテーマがぶつかることで、「TEST-RUN は壊していい場所で、Obsidian は拾う場所だ」というような運用上の発見が生まれる。

AIとの会話は、直線的な仕様策定だけではない。むしろ、雑談、軽いツッコミ、失敗の振り返り、別案の比較が混ざったときに、運用の芯が見えることがある。最初から正式な議事録にしようとすると、その温度が落ちる。少し困るが、ここが面白い。笑いながら出た言葉のほうが、あとで運用ルールとして強かったりする。

TEST-RUN は、その温度を許す場所になる。会話が先に走り、ファイルやプロンプトや試作品があとから追いつく。正式な成果物ではなく、発想が散らばる床として働く。

消えてよい場所だから試せること

消えてよい場所では、失敗のコストが下がる。変な YAML を作ってもよい。記事の種を置いてもよい。StructCiv の session を作って、だめなら消してもよい。プロンプトを長くしすぎて、やっぱり薄いと判断してもよい。

この「だめなら消せる」は、AIとの創作ではかなり大きい。LLM は出力が速いので、試行錯誤の量が一気に増える。すべてを durable に扱うと、残骸の管理だけで疲れる。逆に、すべてを ephemeral に扱うと、再利用できる知見まで流れていく。

TEST-RUN は、その中間ではなく、あくまで揮発側に寄せる。壊していい。消えていい。作業場として散らかっていい。ただし、そこに正本を置かない。ここが肝である。

自由な場所は、自由であるほど強い。けれど、自由な場所に長期記憶まで置き始めると、急に危なくなる。散らかしてよい場所と、失ってはいけない場所を混ぜると、人間もAIも判断を誤る。

ただし消えてよい場所に正本を置いてはいけない

TEST-RUN を創作キャンバスとして使うなら、同時に「ここは正本ではない」と決めておく必要がある。これは念押しではなく、運用の安全装置だ。

AIとの作業では、ファイルがあるだけでそれらしく見える。outline.yml があれば正しそうに見えるし、article_draft.md があれば最新版に見える。けれど、そのファイルが揮発的な作業場にあるなら、正本扱いしてはいけない。

StructCivやセッション終了で消える前提

StructCiv のような記事生成フローでは、work session が作られ、outline、draft、decorated、publish_draft のようなファイルが増える。これは制作中には便利だが、永続保存の正本とは別物である。

特に TEST-RUN のような場所では、session を削除して新規作成することが普通に起きる。今回のように、薄いブリーフから作った旧 session を消し、Pre-StructCiv で濃くした YAML を正本として作り直す判断もある。これは失敗ではなく、揮発的な作業場として正しく使っているだけだ。

この前提がないと、作業ファイルを消すたびに不安になる。逆に、最初から「ここは消える」と決めておけば、消す判断が軽くなる。残すべきものは別の層へ移す。作業場は作業場として使い倒す。

StructCiv の session は、制作工程の状態を持つ。けれど、その状態は記事制作のための状態であって、創作全体の記憶ではない。会話の意味、運用上の発見、次回も使う判断は、もっと外側の記憶層へ逃がす必要がある。

混ぜると危ないもの	理由
作業 session と正本	session は作り直しや削除が前提なので、唯一の根拠にすると消せなくなる
会話ログと durable rule	会話は揺れるが、rule は次回以降の実行条件として安定している必要がある

一時利用は許しつつdurable前提にしない

一時ファイルが悪いわけではない。むしろ、一時ファイルは必要だ。長いプロンプト、記事素材、比較メモ、失敗した draft、貼り付け用 HTML。AIとの作業では、こうした中間物が大量に出る。

問題は、それを durable 前提にしてしまうことだ。TEST-RUN に置いたファイルを、あとで必ず残っているものとして扱う。会話の流れを、そこにあるローカルファイルだけに依存させる。これをやると、作業場を消せなくなる。

消せない TEST-RUN は、もう TEST-RUN ではない。名前は軽いのに、中身は重い。こうなると、自由に壊せるはずの場所が、ただの未整理 repo になる。これはけっこうつらい。笑って消せるはずの場所に、消したら困るものが混ざっている状態だからだ。

だから、TEST-RUN は一時利用を許すが、長期の正本にはしない。そこにあるものは、生成中、検証中、受け渡し前、または捨てる前のものとして扱う。残す価値が出た時だけ、明示的に別の場所へ昇格させる。

どこに置くか迷ったら、成果物か記憶かで分ける

AIとの作業で迷いやすいのは、「今出てきたものをどこに置くか」です。発想なのか、記憶なのか、成果物なのか、運用ルールなのか。この区別を曖昧にすると、自由に試す場所が重くなり、正式な repo には未整理のものが混ざり、あとで拾いたい気づきも流れてしまいます。

判断の基準は、難しく考えなくてかまいません。まずは「これは成果物なのか」「あとで思い出したいだけなのか」「何度も使う実行条件なのか」で分けると、置き場所はかなり安定します。

状態	置き場所	理由
まだ試しているだけ	TEST-RUN	壊してよい作業場として扱えるため
あとで思い出したい気づき	Obsidian episodes	短中期の文脈として拾えるため
何度も使う判断基準になった	Obsidian knowledge/rules	再利用される知識として残すため
特定プロジェクトの文脈になった	Obsidian knowledge/projects	project ごとの前提として参照できるため
実装・成果物・履歴として残す	project repo	再現性と保守の対象になるため
Codexの実行条件として固定する	AGENTS.md	毎回守るべき運用ルールになるため

迷ったときの短い判断フロー

最初に見るのは、「これは成果物か」です。成果物なら project repo に置きます。成果物ではなく、ただ試しているだけなら TEST-RUN に残します。

ただし、あとで思い出したい判断や失敗が含まれているなら、Obsidian episodes に拾います。その後、同じ判断が何度も使われるようになったら、knowledge/rules や knowledge/projects に昇格させます。

つまり、最初からすべてを正本にしようとしないことが大事です。自由に壊せる場所で試し、必要なものだけ記憶に拾い、再利用されるものだけ正式な知識や repo に移す。この流れを分けておくと、AIとの創作はかなり扱いやすくなります。

Obsidianが火花を拾う

TEST-RUN が揮発側の場所なら、Obsidian は拾い上げる側の場所になる。ただし、ここでも何でも保存すればよいわけではない。全ログ保存は一見安心だが、あとで読めない記憶は、ほとんど記憶として機能しない。

重要なのは、Obsidian を knowledge-first ではなく episode-first で使うことだ。最初から完成した知識として保存するのではなく、会話や判断の断片を短中期の記憶として残す。人間の海馬のように、あとで再利用されるものだけが強くなる。

episode-firstの海馬的記憶

episode は、完成したルールではない。作業中に起きた判断、失敗、気づき、比較、方針変更を短く残すための層である。たとえば「薄いブリーフを StructCiv に直投げすると浅くなる」「Pre-StructCiv で素材化したほうがよい」「TEST-RUN に正本を置くと消せなくなる」といった観察がここに入る。

この層があると、会話が途切れても再開しやすくなる。新しい thread で Codex が作業を始める時、過去の会話全体を読む必要はない。最近の episode を数件見れば、何が問題になり、どんな判断があったのかを思い出せる。

全件走査をしないことも大切だ。記憶を持つというと、つい全部を読ませたくなる。しかし、全部を読む運用は重い。episode-first の設計では、通常は少数の最近 episode を読み、曖昧な過去参照があった時だけ追加探索する。必要な分だけ思い出す形にしておく。

これは AIにとっても人間にとっても扱いやすい。記憶が巨大な倉庫ではなく、作業中の文脈を取り戻すための短い足場になる。消える作業場から、再利用できる火花だけを拾うには、この粒度がちょうどよい。

記憶層	役割
episode	作業中の判断、失敗、気づきを短中期で保持する海馬的な層
knowledge	再利用価値が確認された rules、decisions、projects を置く耐久層

knowledge/rulesとprojectsへの昇格

episode が繰り返し使われると、ただの一回の観察ではなくなる。何度も参照される判断、明らかに今後の運用を左右するルール、特定 project に紐づく前提は、knowledge へ昇格させる候補になる。

たとえば「Project Promotion Requires Explicit Intent」は、単なる一回の気づきではなく、TEST-RUN 運用全体の安全装置になる。Codex が面白いと思っただけで、勝手に project 化してはいけない。ユーザーが明示した時だけ、ディレクトリ作成、repo 化、記憶登録、handoff の準備へ進む。

同じように「Article Promotion Requires Explicit Intent」も重要になる。会話が盛り上がったからといって、すぐ記事化するわけではない。記事にする判断はユーザーが持つ。AIは素材化や構造化を手伝うが、昇格の主体ではない。

episode と knowledge を分けることで、記憶は重くなりすぎない。まだ未確定なものは episode に置き、再利用価値が見えたものだけ rules や projects へ移す。残す場所にも段階を作ることで、自由な会話と堅い運用が共存しやすくなる。

Obsidianはpre-AGENTS.mdとして働く

AGENTS.md は強力だが、効き始めるタイミングがある。基本的には、repo や workspace が存在し、その中でどう作業するかを決めるためのものだ。

しかし、AIとの創作では、repo ができる前の時間が長い。名前も目的もまだ揺れている。記事になるか、ツールになるか、単なる笑い話で終わるかも分からない。この段階を制御する層がないと、自由な会話は残らず、残そうとすると早すぎる構造化が起きる。

AGENTS.mdはrepoができた後に効く

AGENTS.md は、局所性を持つ。ある repo の中で、どのテストを優先するか、どのファイルを触ってよいか、どの文体でドキュメントを書くかを指定する。これは project が成立した後には非常に頼もしい。

けれど、project になる前の会話には、まだその局所性がない。TEST-RUN で雑談している時点では、どの repo の AGENTS.md が正しいのかを決められない。むしろ、どの repo にするべきか、そもそも repo にするべきかを考えている段階だ。

ここで AGENTS.md だけに頼ると、pre-project の会話が抜け落ちる。正式な作業に入った後の規律はあるのに、正式になる前の発見を扱う仕組みがない。AIとの創作では、この抜け落ちがかなり痛い。

Obsidian の episode-first memory は、この前段階を受け持つ。まだ repo 化されていない判断、会話の熱量、作業場の扱い方、昇格条件を短く残す。AGENTS.md が作業の憲法なら、Obsidian は project が生まれる前の生活記録に近い。

project以前の会話を制御する層

pre-project の会話には、独特の危うさがある。面白いが、まだ固めたくない。残したいが、全部は残したくない。AIに任せたいが、勝手に正式化されたくない。

この状態を扱うには、制御点が必要になる。Codex は、TEST-RUN を volatile scratchpad として扱う。Obsidian は、必要な episode を拾う。project 化は、ユーザーの明示判断で起きる。記事化も、別の明示判断で起きる。

この分担があると、会話が軽くなる。人間は「これはまだ遊び」と言えるし、「これは残そう」とも言える。AIも、勝手に昇格させず、昇格の準備だけを整えられる。

pre-AGENTS.md という言い方は少し雑だが、感覚としてはかなり近い。Obsidian は AGENTS.md の代替ではない。AGENTS.md が効く前の空白を埋める層である。repo ができる前の判断、複数 project をまたぐ記憶、創作の温度を保存する場所として働く。

プロジェクト化はユーザーの明示判断で起きる

AIとの会話で何かが育ってくると、すぐに project 化したくなることがある。小さなスクリプト、WordPress の補助ツール、Obsidian memory の改善、StructCiv plugin の修正。どれも project に見える瞬間がある。

けれど、project 化は重い判断だ。名前を付け、ディレクトリを作り、履歴を持たせ、場合によっては repo にする。これは単なる保存ではなく、責任の発生である。

Codexが勝手に昇格しない理由

Codex は、会話の中で可能性を見つけるのが得意だ。人間が軽く言ったことを拾い、構造化し、次の手順まで出せる。これは便利だが、同時に危うい。

もしAIが「これは project っぽい」と判断するたびに昇格させたら、TEST-RUN はすぐに project の墓場になる。作りかけのディレクトリ、途中で止まった README、半端な AGENTS.md が増える。自由に試すはずの場所が、未完了タスクの圧力に変わる。

だから、project promotion はユーザーの明示判断でだけ起きる。Codex は提案してよい。準備してよい。必要なディレクトリ構成や handoff を整えてよい。けれど、昇格そのものはユーザーの意思で始まる。

この境界は、AIに任せるためにも必要だ。任せる範囲が曖昧だと、AIはやりすぎるか、逆に止まりすぎる。明示判断を境にすれば、探索中は自由に、昇格後はきっちり進められる。

ディレクトリ作成、repo、記憶登録、handoffまでのお膳立て

ユーザーが project 化を明示したら、Codex がやるべきことは多い。専用ディレクトリを作る。必要なら git repo にする。README や AGENTS.md の初期案を作る。Obsidian の project note に前提を登録する。新規 thread へ渡す handoff を用意する。

ここで重要なのは、お膳立てと決定を混同しないことだ。Codex は作業を準備する。人間は、それを project として進める判断をする。この分担があると、AIはかなり強い補助役になる。

特に長い会話から project を切り出す時、handoff は大事になる。元の thread には雑談、失敗、途中の比較、冗談、古い案が混ざっている。そのまま新規 project に持ち込むと、文脈が重すぎる。必要な前提だけを整理し、新しい thread が迷わず始められる形にする必要がある。

TEST-RUN で自由に試し、明示判断で project 化し、Obsidian に記憶を残し、新規 thread に handoff する。この流れは、AIとの創作を「思いつきで終わるもの」から「必要な時だけ正式化できるもの」へ変えてくれる。

記事化も専用の昇格フローを持つ

project 化と記事化は似ているが、同じではない。project は作る対象を正式化する。記事化は、会話から生まれた知見を読者に渡せる形へ変換する。

AIとの会話で出た発見は、そのまま記事になるわけではない。会話には熱量があるが、読者に必要な順序とは限らない。話している本人には面白くても、初見の読者には前提が足りないことも多い。

薄いブリーフをStructCIへ直投げして失敗した

StructCiv は記事生成のための強いパイプラインだが、入力が薄ければ出力も薄くなる。これは当たり前なのに、AI運用ではつい忘れやすい。よい generator があれば、会話の断片もいい感じに記事へしてくれる気がしてしまう。

実際には、薄いブリーフをそのまま投げると、表面的な説明になりやすい。TEST-RUN は自由な場所です、Obsidian は記憶です、project 化は明示判断です、という要点は並ぶ。けれど、なぜそれが必要になったのか、どこで失敗したのか、どの層が何を担うのかという手触りが薄くなる。

会話の熱量は、単なる要約では移らない。どの言葉が重要だったのか、どの失敗が設計判断につながったのか、どの読者がどこで迷うのかを整理する必要がある。ここを飛ばすと、記事は正しいが弱くなる。正しいだけの記事は、読者の運用を変えるところまで届きにくい。

この失敗は、かなり実務的な発見だった。StructCiv が悪いのではない。素材化が足りない。記事生成へ渡す前に、会話の火花を読者ニーズ、著者意図、アウトライン、未確認事項へ変換する工程が必要だった。

Pre-StructCivで素材化してからStructCIへ渡す

Pre-StructCiv は、この前処理に向いている。会話から、role、audience、persona、keywords、E-E-A-T、extracted_needs、article_outline、dialogue_digest を取り出す。これは単なる下書きではなく、記事化のための素材化である。

この工程を挟むと、StructCiv はかなり働きやすくなる。読者が何に困っているのか、どの順序で理解したいのか、どの失敗を残すべきか、どの言葉を自然に出すべきかが明確になる。生成器が想像で埋める部分が減る。

特に今回のような reflective technical essay では、素材化がないと抽象論に寄りやすい。TEST-RUN、Obsidian、AGENTS、StructCiv、clipboard-handoff という要素名だけを並べても、読者には「で、自分の運用ではどう使うのか」が見えにくい。

Pre-StructCiv で会話の芯を抜き出し、StructCiv で記事として展開する。この二段構えにすると、AIとの雑談が単なるログではなく、読者へ渡せる実践知になる。記事化は project 化とは別の昇格先であり、そのための専用フローを持たせる価値がある。

拙作のclipboard-handoffが人間の最終判断を残す

AI運用では、自動化できる場所が増えるほど、どこに人間の判断を残すかが重要になる。全部を自動化すると楽に見えるが、送信、貼り付け、公開のような最後の一手までAIに渡すと、制御点が見えにくくなる。

clipboard-handoff は、その意味でかなりよい橋になる。Codex が長い YAML や prompt や HTML を用意し、ローカルファイルやクリップボードへ渡す。人間は、それを新規 thread、WordPress、GUI の入力欄へ貼り、最後に送るかどうかを判断する。

Codexが用意し人間が貼る

長い指示書を会話欄へ直接流し込むと、thread の見通しが悪くなる。途中で修正したい時も扱いにくい。ファイルとして用意し、必要なら clipboard-handoff で渡すほうが、境界がはっきりする。

この運用では、Codex は準備役として強く働く。素材を整え、形式を合わせ、不要な揺れを消し、貼り付けられる状態にする。人間は、その内容を見て、今送るか、直すか、別 thread にするかを決める。

この最後の判断が残っていると、AIとの共同作業は安心しやすい。任せているが、流されてはいない。自動化しているが、公開や送信の責任まで曖昧にはしていない。

WordPress や SWELL のような GUI を含む運用でも同じだ。Codex が HTML を作り、コードエディタへ貼れる形を用意する。最終的な画面確認、保存、公開判断は人間が握る。これは手間を残しているのではなく、必要な制御点を残している。

長文セッションと新規スレッドをつなぐ

長い会話には文脈が溜まる。最初の前提、途中の失敗、笑いながら出た比喩、最終的な判断。これを全部新規 thread に持ち込むと重すぎる。逆に、何も持ち込まないと薄くなる。

handoff は、この中間を作る。新しい thread が必要な文脈だけを受け取れるように、長文セッションを圧縮する。目的、制約、決定済み事項、未確認事項、次の作業をまとめる。記事化なら Pre-StructCiv YAML、project 化なら project handoff prompt のように、用途に合った形へ変換する。

ここで clipboard が効く。Codex が生成した長文を、そのまま人間が確認して次の場へ渡せる。API 的な自動送信ではなく、UI 上の手触りを残したまま作業をつなげられる。

この「人間が最後に貼る」は、原始的に見えてけっこう強い。完全自動化より少し遅いが、間違った文脈を次の thread へ流し込む事故を減らせる。AIに任せる領域と、人間が握る領域の境界が目に見える。

Codexが担うもの	人間が握るもの
長文 prompt、YAML、HTML、handoff の整形	貼り付ける場所、送信するタイミング、公開や保存の最終判断
作業手順の準備と入力形式の調整	次の thread や WordPress 画面で本当に進めるかの決定

結論: 壊していい自由と拾い上げる記憶を両立する

AIとの創作は、最初から整いすぎていると細る。かといって、自由だけだと消える。大事なのは、自由と耐久性を同じ場所に押し込めないことだ。

TEST-RUN は壊していい。Obsidian は拾う。AGENTS.md は repo ができた後に効く。project 化と記事化は、ユーザーの明示判断で起きる。Pre-StructCiv は会話の火花を素材化し、StructCiv はそれを記事へ展開する。clipboard-handoff は最後の判断を人間に残す。

• 自由に試す場所と、残す場所を分ける
• project 化と記事化を同じ昇格として扱わない
• AIに準備させ、人間が最後の判断を握る

自由なキャンバスと耐久層を分ける

自由なキャンバスには、自由であるための条件がある。消せること。壊せること。途中で話題が変わってもよいこと。未完成のものが置かれても、それだけで責任を帯びないこと。

耐久層にも条件がある。あとで読めること。必要な時に思い出せること。どの判断が未確定で、どの判断がルール化されたのかが分かること。正本がどこにあるかが曖昧にならないこと。

この二つを分けると、AIとの作業は軽くなる。TEST-RUN で思い切り試せる。必要な火花は Obsidian が拾う。project にする時は project として始められる。記事にする時は記事化の素材として整えられる。

逆に、ここを混ぜると重くなる。消していい場所に消せないものが混ざる。正式な repo に未確定の雑談が入り込む。記事生成に薄い要約だけを渡して、あとで「なんか浅い」となる。どれも一度はやりがちな失敗だが、層を分ければかなり減らせる。

AI時代の個人的な創作インフラ

AIを創作の相棒として使うなら、必要なのは万能の自動化ではなく、自由に試せる場所と、残す価値を判断する仕組みだと思う。AIは速い。だからこそ、出てきたものを全部正式化しない設計がいる。

TEST-RUN は、会話がまだ会話でいられる場所になる。Obsidian は、そこから再利用できる記憶を拾う場所になる。Pre-StructCiv と StructCiv は、会話の熱を読者へ渡すための記事化フローになる。clipboard-handoff は、人間が最後の一手を握るための橋になる。

この構成は、大げさなシステムではない。むしろ、壊していい場所をちゃんと壊せるようにするための、小さなインフラである。自由さを守るために、正本を置く場所を決める。軽さを守るために、昇格判断を明示する。深さを守るために、会話の火花を記憶へ拾う。

AIとの創作は、きれいな一本道ではない。雑談から始まり、試作に寄り道し、記事になりかけ、project になりかけ、また雑談へ戻る。その揺れを無理に止めなくてよい。壊していいキャンバスと、拾い上げる記憶があれば、その揺れ自体を創作の燃料にできる。