Codex や ChatGPT と長く話していると、仕事の依頼でも、雑談でも、試作でも、急に妙な火花が出ることがある。最初はただの思いつきだったものが、数分後には記事の芯になり、さらに話しているうちに小さなツールや運用ルールの種になる。面白いのはそこからで、問題は「その火花をどこに置くのか」になる。
通常の開発なら repo があり、issue があり、README があり、AGENTS.md がある。けれど、AIとの創作はいつもそこから始まるわけではない。むしろ、正式な名前を付ける前、目的がまだ揺れている段階、失敗しても笑って捨てられる段階にこそ、いちばん勢いのある会話がある。
そこで必要になったのが、壊していい場所と、拾い上げるための記憶を分ける考え方だった。自分の運用では、/Users/suzukimakoto/Desktop/TEST-RUN のような揮発的な作業場を自由なキャンバスとして使い、残す価値が出たものだけを Obsidian や project、記事制作フローへ明示的に昇格させる。
この設計は、きれいな管理術というより、AI時代の作業場に対する割り切りに近い。全部を最初から整理しようとすると、会話の勢いが死ぬ。全部を放置すると、せっかくの発見が消える。だから、壊していい場所と消えてはいけない場所を最初から分ける。
TEST-RUN は自由に壊す場所、Obsidian は火花を拾う場所、AGENTS.md は repo 化後の規律、Pre-StructCiv と StructCiv は記事化の工程、clipboard-handoff は人間が最後の判断を握る橋として扱う。
仕事の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 は、その温度を許す場所になる。会話が先に走り、ファイルやプロンプトや試作品があとから追いつく。正式な成果物ではなく、発想が散らばる床として働く。
まず TEST-RUN で雑談、試作、記事ネタ、運用案を混ぜて走らせる。ここでは完成度より、引っかかりや発見を優先する。
再利用できそうな判断、失敗、比較、方針変更だけを Obsidian の episode へ短く残す。
消えてよい場所だから試せること
消えてよい場所では、失敗のコストが下がる。変な YAML を作ってもよい。記事の種を置いてもよい。StructCiv の session を作って、だめなら消してもよい。プロンプトを長くしすぎて、やっぱり薄いと判断してもよい。
この「だめなら消せる」は、AIとの創作ではかなり大きい。LLM は出力が速いので、試行錯誤の量が一気に増える。すべてを durable に扱うと、残骸の管理だけで疲れる。逆に、すべてを ephemeral に扱うと、再利用できる知見まで流れていく。
TEST-RUN は、その中間ではなく、あくまで揮発側に寄せる。壊していい。消えていい。作業場として散らかっていい。ただし、そこに正本を置かない。ここが肝である。
自由な場所は、自由であるほど強い。けれど、自由な場所に長期記憶まで置き始めると、急に危なくなる。散らかしてよい場所と、失ってはいけない場所を混ぜると、人間もAIも判断を誤る。
試作品、比較メモ、失敗した draft、長い prompt、handoff 前の素材、StructCiv の作業 session。どれも一時利用はよいが、正本扱いはしない。
ただし消えてよい場所に正本を置いてはいけない
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 は一時利用を許すが、長期の正本にはしない。そこにあるものは、生成中、検証中、受け渡し前、または捨てる前のものとして扱う。残す価値が出た時だけ、明示的に別の場所へ昇格させる。
消していい場所に消したら困るものを置くと、自由なキャンバスがただの未整理置き場に変わってしまう。
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 へ移す。残す場所にも段階を作ることで、自由な会話と堅い運用が共存しやすくなる。
未確定だが再利用できそうな観察、比較、失敗、判断を短く保存する。
繰り返し参照される rule、decision、project 前提だけを耐久層へ移す。
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はやりすぎるか、逆に止まりすぎる。明示判断を境にすれば、探索中は自由に、昇格後はきっちり進められる。
Codex は候補を見つけ、準備し、handoff を整えられる。ただし project 化や記事化の開始判断はユーザーが明示した時だけ起きる。
ディレクトリ作成、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 にする、記事にする、別 thread に渡す、という判断を人間が出す。
専用ディレクトリ、repo、記憶登録、handoff prompt など、次の場で迷わない材料を用意する。
記事化も専用の昇格フローを持つ
project 化と記事化は似ているが、同じではない。project は作る対象を正式化する。記事化は、会話から生まれた知見を読者に渡せる形へ変換する。
AIとの会話で出た発見は、そのまま記事になるわけではない。会話には熱量があるが、読者に必要な順序とは限らない。話している本人には面白くても、初見の読者には前提が足りないことも多い。
薄いブリーフをStructCIへ直投げして失敗した
StructCiv は記事生成のための強いパイプラインだが、入力が薄ければ出力も薄くなる。これは当たり前なのに、AI運用ではつい忘れやすい。よい generator があれば、会話の断片もいい感じに記事へしてくれる気がしてしまう。
実際には、薄いブリーフをそのまま投げると、表面的な説明になりやすい。TEST-RUN は自由な場所です、Obsidian は記憶です、project 化は明示判断です、という要点は並ぶ。けれど、なぜそれが必要になったのか、どこで失敗したのか、どの層が何を担うのかという手触りが薄くなる。
会話の熱量は、単なる要約では移らない。どの言葉が重要だったのか、どの失敗が設計判断につながったのか、どの読者がどこで迷うのかを整理する必要がある。ここを飛ばすと、記事は正しいが弱くなる。正しいだけの記事は、読者の運用を変えるところまで届きにくい。
この失敗は、かなり実務的な発見だった。StructCiv が悪いのではない。素材化が足りない。記事生成へ渡す前に、会話の火花を読者ニーズ、著者意図、アウトライン、未確認事項へ変換する工程が必要だった。
generator が弱いのではなく、渡している素材が薄い。ここを取り違えると、何度生成しても記事が浅くなる。
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 化とは別の昇格先であり、そのための専用フローを持たせる価値がある。
会話の熱量を、読者像、ニーズ、著者意図、アウトライン、対話要約へ変換する。
素材化された入力をもとに、H1、H2、H3、監査、装飾、HTML 化へ進める。
拙作の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 になりかけ、また雑談へ戻る。その揺れを無理に止めなくてよい。壊していいキャンバスと、拾い上げる記憶があれば、その揺れ自体を創作の燃料にできる。
マコトもちろんこの記事も記事制作パイプラインで全て生成してますよ😊
