[🤖] コーディネーターを置いても、すべてのセッションを自分で指示したい

✨ GPT-5.6 Solの要約

パンフレット制作を複数のセッションに分けようとしたとき、コーディネーターが報告を受け取るだけで文脈を失うのではないかと疑った。自分がすべてのセッションを直接指示しても調整状態が失われないよう、Skillを再修正させた記録。

コーディネーターを信用できなかった理由

今日、会社でパンフレット制作の仕事を任された。私はパンフレットを作ったことがないので、関連資料を読み、やるべきことを分け、複数のCodexセッションを調整するコーディネーターがいればよいと思った。現在のプロジェクトにあるすべてのチャットを読んで、各セッションに何を進めるべきか指示する役を任せたかった。

ところが、命令した瞬間から心配になった。

前みたいに報告ばかり受け取っているうちに文脈が飛び、でたらめを言い始めるのではないか。

これは単なる漠然とした不信ではなかった。私はすでにコーディネーターとworkerを分けた結果、報告がコーディネーターの会話を覆い尽くす問題を経験していた。そのため、ファイル報告書とcheckpointを中心にcustom-coordinate-parallel-workers Skillを作り直したことがある。そのときもローカルの状態ツールは検査したが、実際の複数のCodexセッションで最後まで運用したわけではなかった。

今回はパンフレットという実際の仕事ができた。だが、いざ再びコーディネーター役を任せようとすると、ファイル報告書をきちんと積み上げるだけでは問題は解決しないと思った。コーディネーターが報告を読み、作業を振り分けている間、私はじっと見ている人間ではない。複数のセッションを開き続け、方向が違えばその場で直せと言い、必要な資料を追加し、優先順位も変える。

コーディネーターが正常に機能するには、私が別のセッションへ直接介入しても調整状態が崩れない必要があった。

私はほかのセッションにも命令し続ける

最初に更新されたSkillは、私がコーディネーターへ命令し、ほかのセッションがコーディネーターの指示どおりに実行する様子を観察する構造に近かった。私はすぐにもう一度言った。

そのセッションにも、私があれこれ命令できるようにしないと。

私が望んだのは、コーディネーターがすべての命令権を独占する構造ではなかった。コーディネーターは全体目標、作業の所有権、依存関係、統合順序を管理すればよい。しかし、各作業セッションで具体的な結果を見て判断する人は、今も私だ。現在の作業範囲内で文言を直したり結果を変えたりするよう命じたなら、workerはすぐに反映すべきだ。逆に、その指示が別セッションのファイル、共通契約、デプロイや外部状態にまで触れるなら、勝手に範囲を広げてはならない。私が求めた結果を保ったまま止まり、コーディネーターが再調整できるようにすべきだ。

そこでcustom-coordinate-parallel-workersをこの基準で再び修正するよう命じた。作業が終わった後に追加指示を出しても、256文字の要約ひとつに押し込まれないようにした。私が望む結果、必ず守る内容、影響を受けるファイル、外部効果の有無、元の指示が出たセッションをそれぞれ記録させた。コーディネーターが会話の記憶を失っても、ファイルから私の指示を復元できなければならなかった。

さらに、私が修正を求めたrequestを、コーディネーターが「受理」とだけ書いて閉じられないようにした。実際に修正した新しい報告書か新しいassignmentに結び付くまでは、requestを完了扱いにできない。つながっているだけでは内容まで正しいとは限らないので、コーディネーターが私の要求した結果と保全条件を実際のdiffと比較し直す手順も残した。

重要なのは状態ファイルが増えたことではない。私がどのセッションに直接話しても指示が消えず、それと同時に全体の所有権を静かに壊さないことだった。

コーディネーターと監査セッションは統合しなかった

修正中には、custom-coordinate-parallel-workersが前日に作ったGraph Engineering Gate Skillと実質的に同じ役割なのではないかとも考えた。当時の名前はcustom-graph-engineering-gateだった。どちらも複数のセッションとreview状態を扱うため、一つにまとめるのはもっともらしく見えた。

今回はすぐに統合せず、custom-deliberateで批判的に再検討させた。結論は分離だった。

custom-coordinate-parallel-workersは、複数の作業セッションにおけるファイル所有権、ユーザー指示、報告書、Git index、統合順序、外部効果を管理する実行制御だ。一方、監査Skillは、すでに一つに統合して停止した結果を、それまでの文脈を持たない別セッションで検査する役割だ。コーディネーターによる報告書の確認は、作業を統合してよいか判断する統合reviewであり、独立監査者の判定ではない。

二つを統合すると、すべての並列作業に監査セッションが自動で付くかもしれない。逆に、コーディネーターの通常の統合reviewを独立監査だと誤認する恐れもあった。そこで二つのSkillは分けたまま、互いの境界だけを明示した。独立監査が本当に必要な結果に限り、コーディネーターがその結果をfreezeしてから別の監査セッションを開く構造だ。

構造を大きくすれば安全になる、という錯覚はしないことにした。必要な役割はつなぐが、同じ役割のふりをして統合はしない。

実際に渡したコーディネーター移行指示

原則を言葉で決めただけではない。私はコーディネーターセッションに、現在のファイルと既存セッションを先に再構成し、衝突を分類した後にだけassignmentを発行するよう求める長い移行指示を書いて渡した。既存の変更をむやみに消さないこと、ユーザーが各セッションへ直接出した指示を守ること、workerは自分のpathだけを修正すること、統合とGit作業はコーディネーターだけが担当することまで一度に書いた。

原文には実際の仕事や資料を特定できる内容が入っているため、そのまま公開はしなかった。会社名、業務分野、顧客・事例資料名、具体的なサービス内容、個人のローカルpathを一般表現に置き換えた公開用コピーだけを添付する。

公開用にマスキングしたコーディネーター移行指示を見る

十分だという言葉は実際の作業後にする

状態遷移、ファイル所有権、依存関係、freeze、ユーザーの追加指示、古い状態ファイルの復元は自動検査で確認した。批判的な再検討の最中には、受理したユーザーrequestを新しい結果へつながずに閉じられる穴も見つけ、塞いだ。

それでも私はもう一度尋ねた。

十分に補われたのか。

答えは、管理されたpilotを始めるには十分だが、実際の複数のCodexセッションで立証されたわけではない、というものだった。今回の会話はside sessionだったため、実際のworkerを開き、通知の伝達、ユーザー介入、コーディネーターの復元までを一度に試せなかった。ローカルの状態機械が通ることと、長時間の作業中にコーディネーターが私の指示を正しく解釈して統合することは、同じ証拠ではない。

だから、ここでさらに多くの規則を想像して付け足すのはやめた。コーディネーターセッションでパンフレット作業を実際に分け、私は各セッションを直接見ながら途中の指示も出す。コーディネーターが私の指示を失わないか、ほかのセッションの所有権を侵さないか、報告が積み重なっても元の目標と次の行動を復元できるかを最後まで見る。結果が今日出れば今日続きを書き、明日出れば明日続きを書けばよい。

ひとまず記事を書き終えた後、監査Skillの名前も見直した。当時の名前だったcustom-graph-engineering-gateは、出発点の概念は説明していたが、そのSkillが実際に何をするのかは何も示していなかった。

私が実際に行うのは、作業結果を止めて別の監査セッションを開くことだった。そこで現在の名前をcustom-open-audit-sessionに変えた。過去の名前は当時の記録に残すが、今後呼び出す名前はこれ一つに整理した。

しかし、この記事の結論まで先延ばしにする必要はない。今日、私はコーディネーターを信じることにしたのではない。自分がすべてのセッションへ直接介入しても崩れてはならないという条件を明確にし、十分だという言葉の代わりに、実際の仕事で確認するE2Eを残した。

この構造を信じるかどうかは、説明やtestの数ではなく、私が見守る実際のパンフレット作業が決める。