複数のAI作業を一画面で管理する「司令室」を考えました。最初の案は一覧・編集・絞り込み・結果記録が中心で、欲しかった「画面から指示し、結果を承認する仕組み」よりタスク管理へ寄っていました。そこで実装を止め、見える化・半自動・直接連携の3段階に分けました。
欲しかった司令室はタスク一覧ではなかった
最初に考えたのは、依頼内容、担当、状態、期限、成果物、確認待ちをまとめる画面でした。ただ、必要だったのは一覧だけではありません。将来は画面からCodexへ指示を送り、進行を確認し、結果を承認または差し戻せる状態を想定していました。
軽いタスク管理と、認証を伴う実行システムを同じものとして扱うと、必要な機能と安全対策が曖昧になります。見た目の参考画面に合わせる前に、司令室がどこまで操作するのかを決める必要がありました。
タスク管理に寄りすぎた案を止めた
相談の初期には、一覧、編集、絞り込み、結果記録などの案が中心になりました。どれも必要な機能ですが、「アプリから指示する」という運用への説明が不足していました。そこで、見える化と直接操作は別の機能だと整理し直しました。
状態を表示するだけなら軽く作れます。一方、AIへ命令し、結果を受け取り、承認後に反映するには、認証、権限、実行環境、料金管理まで必要です。店長は、必要性を確認していない段階で直接連携を作らず、実装を急がないと判断しました。
実装を3段階へ分けた
- 第1段階・見える化
タスク、Codexへ渡す指示文、状態、結果を記録します。実際の指示は人がCodexへ貼ります。 - 第2段階・半自動
アプリで指示文や修正依頼を作り、Codexの結果を貼ると状態が更新されます。人の「確認OK」「修正」「保留」も記録します。 - 第3段階・直接連携
アプリからCodexへ依頼し、テスト結果を受け取り、人の承認後に反映します。認証と権限設計が必要なため今回は未実装です。
第2段階を将来の目標にしつつ、まず第1段階から始める方針にしました。段階を分けたことで、見える化の検証と、外部連携の安全設計を混同せずに進められます。
まず見える化から始め、人の承認を残した
第1段階で使う作業状態は、未着手、依頼済み、作業中、確認待ち、修正依頼、完了、エラーの7種類に整理しました。作業種別も8種類に分け、同じ画面の中で成果物や確認方法が異なる仕事を見分けられるようにします。
店長は、採用、修正、保留、公開など、業務への影響が大きい判断を人に残す方針を明確にしました。「運営者確認待ち」を独立した状態にし、確認すべき仕事を絞っても、判断そのものは自動化しません。
参考画面の演出より、一覧、検索、状態、確認待ち、結果リンクを先に扱います。画面が完成したように見えても、未実装の連携や認証まで完成扱いにしないためです。
未実装のまま確認すべきこと
今回決めたのは、アプリの役割、3段階の開発方針、7つの状態、8つの作業種別、Codexへ一度で渡すための依頼案です。コード作成、起動、テストは行っていません。
直接連携の方法、認証、料金、保存先、進行の自動反映は未確認です。次は第1段階の画面で、本当に確認待ちとエラーを見つけやすくなるかを確かめます。未実装の機能を完成したように扱わず、必要性が確認できてから次の段階へ進みます。