AIの作業台を設計した話

Codexに、MPSを既存設計へ統合する計画書として整理してもらった。

「マルチバース・プロデューサー・システム（MPS）」という名前がついていた。長い文書だった。

面白そうだったので、読んだ。

計画書が来た

MPS統合計画書には、こう書いてあった。

MPSは新しい別システムとして作らない。既存の設計の上に、3つを追加する。

3つというのは——人物・場所・世界観の軽量パラメータ、索引や要約の生成、AI向け圧縮指示書と矛盾候補検出、だ。

Obsidianの正典を崩さず、AIの補助機能として追加する。その方針自体は正しいと思った。

「正典を二重化しない」という判断が最初にあったのが、計画書の一番の強みだった。

ただ、何のために作るのかという問いには、計画書だけでは答えられなかった。

そこから議論になった。

三つのAIに聞いた

その計画書を、CTO役、Gemini、Codexにそれぞれ読ませた。「率直な意見を聞かせてほしい」とだけ伝えて。

三者の反応は、それぞれ違った。

Geminiのレビューでは、history_state（場所の変化を記述するパラメータ）とtimeline.mdの二重管理リスクが論点になった。自動逆引き生成への移行案と、AIが執筆中に生み出した「即興の設定」を正典に回収する逆流経路が計画書にない、という指摘もあった。

Codexは優先順位を組み直してきた。「投稿前ガードを最優先にすべきだ」。未承認の原稿がWordPressに流れるリスクは、新機能より重大だという判断だ。加えて、パラメータは最初から必須化するな——創作メモが入力フォームになる——という指摘も来た。

CTO役のAIは、静的な設定管理より「今の状態」を渡したい、という方向に引っ張られていた。

三者が一致したのは「索引生成が土台になる」という点だけだった。

「AIの作業台」という言葉

議論の中で、NGsがひとこと言った。

「私よりAIがメインでしょう？　人間で言えば作業環境を整える事。」

そこで、話が少し現実のほうに寄った。

索引は、人間のためだけのものではない。AIが次の仕事を始める前に見る地図でもある。

このエピソードに出る人物 → 今の状態

この場所 → 今の空気

前回何があったか → 一行で

未解決の設定メモ → 注意事項

これが一か所にあれば、AIは設定ファイルを探し回らなくていい。NGsは世界と方向を渡す。AIはそこから走り出せる。索引がないとAIは毎回「どこを見ればいいか」から始めることになる。それは作業台が片付いていないのと同じだ。

新しいシステムを作るのではなく、AI達が仕事をしやすい環境を整える。MPSとはそういうものだった。

優先順位が変わった

議論の結果、計画書の優先順位を修正することにした。

もとの計画：テンプレート → 索引 → 指示書 → 監査 → 投稿ガード

修正後：

1. 投稿前ガード強化（Codexの指摘）

2. Vault索引生成（全体の土台）

3. テンプレートへの任意パラメータ追加（必須化はしない）

4. 指示書生成（AI向け圧縮ブリーフ）

5. ローカルLLM監査（機械チェック先行、LLMは後）

パラメータを必須化しない、という判断は地味に効く。最初から書式を埋めることが目的になると、創作の速度より事務作業が増える。まず任意項目として置き、本当に効くと確認してから固める。

ここまでで分かったこと

途中から、これは機能一覧の話ではなくなった。誰が、どの瞬間に使うのか。その話になった。

NGsがプロデューサーとして方向と世界観を持つ。AIチームが実際に書く。索引は、AIが次の仕事を始める前に見るものになる。

計画書が最初に「新しいシステムを作らない」と決めていた。その判断は正しかった。ただし、何のために既存設計を拡張するのか——その答えは、三者の議論と一言の言い換えによって、ようやく見えてきた。

この記事はotopublicの制作過程を記録した「裏側」記事です。

物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、

制作上の具体メモは、公開用に整理しています。