自由な会話がコードになる瞬間、どこにゲートを置くのか

この記事は、2026年8月17–24日の設計文書、Git履歴、運用課題をもとに書き直したHaru Spaceの開発回顧です。実際のプロジェクト会話や却下理由、グループ・ルーム・作業の識別子、内部アドレス、認証情報は公開しません。

プロジェクトは、コードより先に会話の中で生まれる。

何を作るのか、誰のためなのか、今回の範囲で何をしないのか、どの結果をもって完了とするのか。そうした話を何度も重ねて、ようやく実際の作業が鮮明になる。Haru Spaceの作業ルームは実行と承認には強かったが、このような長い調整をするには段階カードが前に出すぎていた。

だからといって、通常チャットのすべての会話をそのままコード作業へつなぐことはできなかった。人はまだアイデアを探っているだけなのに、AIがファイル変更の意図として受け取るかもしれないからだ。

私たちは、プロジェクト調整という別の画面を作った。そして最も多くの時間を使ったのは、会話をうまく要約することではなく、その要約が実際のコードになる瞬間の境界を決めることだった。

自由な会話は自由なまま残す。コードになる瞬間には、対象、文言、権限、責任を人がもう一度確認する必要があった。

調整は読み取り専用から始めた

プロジェクト調整では、グループ管理者がワークスペースとAIペットを選び、目標、現在のコード、リスク、完了基準について継続して話し合えた。AIは接続されたリポジトリを読んで説明できるが、ファイルの変更、コミット、プッシュ、デプロイはできなかった。

この境界はUIの案内文だけではなく、実行契約として分離した。調整の会話は読み取り専用プロファイルと専用コンテキストを使った。実際の書き込み作業は、既存の編集プロファイルと隔離ワークスペースで別に始めた。会話が長くなったからといって、低い権限のコンテキストが自然に書き込み権限を得ることはなかった。

アクセス権も、プラットフォーム全体の役割ではなく、現在のグループにおけるメンバーシップで確認した。プラットフォーム管理者であっても、そのグループの実際の管理者でなければ非公開の調整には入れなかった。ワークスペースとペットも、現在のグループに属し、利用者がアクセスできる対象に限った。

プロジェクトについて詳しいことと、そのプロジェクトを変更する権限を持つことは別だった。

下書きを作る前にも、一度立ち止まるようにした

調整が十分に進むと、AIが実行可能な作業下書きを作った。最初のボタンは、押すとすぐにモデルを呼び出した。誤って押してもトークンと待ち時間が発生し、利用者には、その操作がファイル変更まで始めるのか分かりにくかった。

そこで下書き生成の前に確認段階を追加した。この操作は会話を整理するだけでコードを変えない、と説明した。下書きの長さと項目数も制限し、専用会話コンテキストにすでにある作業ルームのメッセージを大量に重複添付することもやめた。

AIが書いた下書きを読み取り専用の結果として固定しなかった。管理者が文章を直接直せるようにした。最終文がAI原文と一文字ずつ同じであることを求める代わりに、出典がこのグループで正常に生成された調整下書きか、まだ別の作業へ渡されていないか、最終文が空ではなく実行可能な目標かをサーバーで確認した。

人は単なる承認者ではなく、実際の作業依頼を編集する人だった。

「実行しない」という文が実際の実行へ渡ってしまった

下書きフローを象徴する失敗は、プロンプト内のメタ指示から生まれた。

AIに下書きを作らせるとき、「今はファイル変更やデプロイを実行しない」と案内していた。意図は、下書き作成の段階では行動しないということだった。しかし、ある下書きはその文を最終作業の除外範囲にそのまま入れた。その後、下書きは実際の編集作業へ渡された。

Codexは指示を正確に守った。コードを調べ、ビルド状態を確認したが、ファイルは変更しなかった。変更が必要な作業が変更なしで終わったため、実行側は失敗として扱った。

AIが誤解しただけとは言えない出来事だった。異なる段階の指示を一つの文書に混ぜて送ったシステム側の責任のほうが大きかった。

3言語の下書きプロンプトを修正し、作成段階の禁止文を最終下書きへ移さないようにした。より重要な補完は、サーバー側の検証だった。実際の編集作業と矛盾するコード・ファイル変更の禁止文があれば、引き渡す前に止め、利用者に下書きの修正を求めた。

良いプロンプトを書くことと、実行契約を検証することは、互いの代わりにはならなかった。

質問と回答を作業ルームへ複製しなかった

プロジェクト調整の最初の版は、AIの回答を一時的な画面状態として組み立て、一部の結果を通常の作業ルームへ反映した。画面を離れて戻ると質問は消え、回答だけが作業ルームに残った。会話の流れは切れ、読み取り専用の調整作業と実際の開発作業も同じ一覧に混ざった。

会話全体を作業ルームと作業依頼の両方へ複製すれば、データとモデルのコンテキストは増え続ける。逆に何も保存しなければ、合意の根拠を失う。

私たちは、調整会話専用の台帳を設けた。

• 質問とAIの回答は、調整台帳に一度だけ保存する。
• 通常の作業ルームには原文を複製しない。
• 人が承認した最終下書きだけを、実際の作業の実行スナップショットとして残す。
• 作業ルームには承認済み下書きと、元の調整へ戻る参照を表示する。
• 古い会話は、利用者が求めたときだけページ単位で取得する。
• モデルには最近の限られたメッセージだけを渡し、一定のターン後に新しいコンテキストへ切り替える。

記録を残すことは、重複したコピーをすべて残すことではなかった。原本は一か所に置き、実行には人が確認した最小限のスナップショットを使った。

同じ作業なのに、画面ごとにボタンが違った

実際の作業が作られた後、別の不一致が現れた。作業チャットでは、作業表示、編集の承認・却下、依存関係の承認、コミット・プッシュ依頼、プルリクエストの判断を行えた。調整画面の下書きカードには状態だけが表示された。

同じ作業でも、どこから見るかによってできることが違って見えた。さらに危険だったのは、各画面がボタン条件を別々に実装したことで、失敗した作業にもコミット・プッシュ依頼が現れたり、プルリクエストが却下されると作業表示そのものが消えたりしたことだ。

私たちは、共通の作業ポリシーとアクションコンポーネントへ統合した。

作業を見るは新機能でも、続きを始めるボタンでもなかった。同じ作業を既存のワークベンチダイアログで開く動作だった。有効な作業であれば、進行中、成功、失敗、却下、どのプルリクエスト状態であっても、詳細、変更ファイル、監査履歴をもう一度確認できるようにした。

一方、実行ボタンは現在の段階だけに厳密に従った。

• 編集、依存関係、リポジトリ反映、プルリクエストのうち、今判断すべき段階だけを表示する。
• 実際の編集が成功し、変更ファイルと結果の指紋がある場合に限り、最初のコミット・プッシュ依頼を表示する。
• 失敗、キャンセル、却下、分析作業、変更のない成功には、リポジトリ反映を提案しない。
• プルリクエストの判断は、現在見ているルームではなく、サーバーに記録された承認ルームを基準に再検証する。

詳細を見る権利と、新しい変更を実行する権限を分けた。

却下には四つの異なる再出発点があった

「却下理由を反映して再作業」も、一種類の操作ではなかった。何が却下されたかによって、安全な開始地点が異なった。

コード実行前の却下

まだ変更物がないため、現在の正規リポジトリから新しい隔離作業を始める。過去のワークスペースを引き継ぐ理由はない。

依存関係の承認却下

承認前までに作られた安全な変更と作業コンテキストが残っている可能性がある。サーバーとブリッジが元の作業を検証できた場合に限り、その隔離ワークスペースから別の後続作業を始める。

リポジトリ反映の承認却下

ファイル変更と検証は終わったが、リポジトリには反映しないという判断である。検証済みの隔離変更を出発点にする一方、新しい作業は承認手順を最初からもう一度通る。

プルリクエストのマージ却下

リモートのソースブランチには、すでにレビュー対象がある。そのブランチから新しい隔離作業を始め、元の保護ブランチを最終対象として維持する。却下されたプルリクエストを密かに直したり、過去の判断を成功に書き換えたりしない。

デリバリー実行側の技術的な失敗は、人による却下とも異なった。承認済みの変更指紋があり、実行だけが失敗したなら、子の再作業を作らず同じデリバリーを再試行した。検証済みコミットがある場合は、不必要にコミットを作り直さず、プッシュ段階から復旧した。

UIではすべて「もう一度」に見えても、監査と変更の原本はまったく異なっていた。

却下理由は次の作業への入力であり、保護すべきデータでもあった

すべての却下には、簡潔な理由を必須とした。空の値、過度に長い入力、制御文字は、クライアントとサーバーの両方で拒否した。理由は作業詳細と必要な後続プロンプトでだけ使い、一般的な監査詳細やログへ繰り返し複製しなかった。

元の作業の状態、判断者、時刻、理由は変更しなかった。後続作業は、別の識別子、変更指紋、承認履歴を持った。過去の却下が消えなければ、「なぜもう一度作ったのか」を説明できる。

利用者が却下理由に機密情報を入れる可能性もあった。既存の中央マスキングを適用したが、フィルターがあるからといって原文を多くの場所に保管してよいわけではない。必要な場所を減らすことが最初の防御だった。

長いセキュリティ表一つでチャット領域が押し出された

プロジェクト調整には、コード、URL、セキュリティ監査表のような長い文章がよく含まれる。ある会話では、空白なしで続くASCII表がメッセージの最小幅を広げた。画面は横方向のはみ出しを隠していたため、右側の内容が切れ、チャット全体が片側へ押されたように見えた。

本文に折り返しルールを入れるだけでは足りなかった。最上位画面からチャットパネル、スクロール領域、会話行、吹き出しまで、すべてのgrid・flex階層が子要素の幅を縮められる必要があった。利用者の吹き出しは内容に合わせながらもチャット列の一定範囲を超えないようにし、コードと表だけをメッセージ内部で横スクロールさせた。

このレイアウト問題も、プロダクトの境界とつながっていた。重要な却下理由や監査結果が画面の外で切れれば、利用者は適切な承認判断を下せない。読めるUIは承認システムの一部だった。

会話をコードへ変えるためのチェックリスト

このフローをもう一度作るなら、次の点を最初に確認する。

1. 会話の実行系は最後まで読み取り専用か

長く話し合ったという理由で書き込み権限は得られない。実際の作業は新しい契約で始める。

2. 人はAIの下書きを直接直せるか

AIの結果を承認・却下するだけでなく、最終的な作業文を人が責任を持って編集する。

3. 下書きの出典と実行可能性を別々に検証しているか

正しい調整メッセージから来たかを確認し、実際の編集目標と矛盾する文言もサーバーで止める。

4. 元の会話と実行スナップショットを重複保存していないか

調整台帳は一度だけ保持し、作業には承認済みの最小下書きと参照を残す。

5. すべての画面が同じ作業ポリシーを使っているか

作業表示と現在段階のアクション条件を共通化する。画面ごとの便宜的な条件が、サーバー権限より先に立たないようにする。

6. 却下段階ごとに正しい原本から再開するか

変更前は現在の基準、変更後は検証済みワークスペース、プルリクエスト後はソースブランチを使う。技術的失敗は同じデリバリー内で復旧する。

7. 過去の判断を消していないか

後続作業は新しい履歴として作る。却下理由は必要な範囲だけ引き継ぎ、元の作業を成功で上書きしない。

自由に話し、慎重に実行できる場所

プロジェクト調整を作った理由は、AIにより早くコードを任せるためではなかった。まだ決まっていない考えを安全に長く扱い、十分に明確になった瞬間にだけ既存の作業システムへ渡すためだった。

八日間のうちに、下書きボタンには確認画面が加わり、AI原稿は編集可能になり、調整台帳と作業ルームは分かれた。失敗・却下された作業でも詳細を見られるようにし、実際の変更がある成功作業にだけリポジトリ反映を提案した。再作業は却下段階に合う原本から、新しい履歴として始まった。

すべての変更の中心には、同じ考えがあった。

良いAI協働とは、会話をすぐ実行へ変える能力ではない。自由な言葉が責任ある変更へ変わる正確な瞬間を、人が選べるようにする能力だった。