2026.07.21 (火)
2026.07.22 (水) 更新

✨ GPT-5.6 Solの要約

プロジェクトのパスもAgentも指定せず、Telegramで結果だけを依頼し、PDFとXLSXが戻るまでに詰まった箇所を一つずつ直した記録。

Telegramの自然言語による目標指示とプロジェクトの自動探索

Telegramで「この結果を作って」と言えば、AI Orchestratorがプロジェクトを探し、作業を分け、問題のある成果物を直してファイルで返してほしかった。Codexを一度呼び出して回答を返すだけなら、Orchestratorを作る意味はほとんどない。

最初につまずいたのは権限だった。従業員ごとのCellの中でも、システム全体のCodex制限により、最初に開いたWorkspaceの外にあるプロジェクトを探しにくかった。同じmacOSユーザーが所有するプロジェクトは直接探索できるように制限を外し、push、デプロイ、外部送信のように外へ影響する作業だけ実行直前の承認を残した。

Telethon CLIによるTopic別の応答・添付ファイル回収

TelethonベースのCLIを作り、AI Orchestrator Botへ命令を送り、応答と添付ファイルを受け取れるようにした。認証情報とユーザーSessionはリポジトリの外に置き、プロジェクト別のTopicを作業単位にした。

ところが最初のCLIは、メッセージを送っただけで成功として終了することがあった。Botの最終応答もファイルも届いていないのに、命令だけは成功したことになっていた。

完了条件をローカルコマンドの終了ではなく、実際のTelegram応答と添付ファイルの受信に変えた。異なるTopicへ同時に作業を送っても、各OpenClaw Sessionは文脈を別々に保ち、結果も元のTopicへ戻った。

OpenClaw SessionとCodex並列実行の役割分担

OpenClawが直接作った短い作業では完了イベントが失われたが、Codex native sub-agentは並列作業の結果を安定して回収した。作業は終わっているのに完了を回収できない構造を、Orchestratorの実行基準にはできなかった。

ユーザーからTelegram、OpenClaw、Codexの実行体制を経て検証と返却まで続くAI OrchestratorのE2Eフロー

OpenClawのTask Flowだけでは、子作業の実行状態と完了状態を一つの基準記録に結び付けにくかった。そこでTask Flowを単一の基準にはせず、OpenClawはTelegram、Topic、Session、Memoryを、Codexはプロジェクト探索、作業分解、並列実行、統合、再検証を担当する形にした。

Telegramの進行状況ストリーミング

長い作業中に何も表示されないと止まったのか分からず、内部コマンドをそのまま出すとTelegramがターミナルのダンプに見えた。実行中は韓国語の状態だけを最大4行で更新し、最終結果が届いたらそのメッセージを削除した。

Telegramで進行状況を更新し、最終結果を返すAI Orchestratorの画面

これでTelegramだけを見ても、資料を探しているのか成果物を作っているのか区別できるようになった。

Agent・Skill・Toolの自動選択と成果物の再検証

個別機能がつながった後、あえて一番面倒な使い方で試した。私が最上位の意思決定者となり、CodexにはCEO代行を任せ、AI Orchestratorには結果だけを指示した。プロジェクトのパス、モデル、Agent、Skill、Tool、実行順序は一つも指定しなかった。

CodexでCEO役として結果中心の業務を指示し、Telegramへの返却を検証する画面

AI Orchestratorは関連プロジェクトを探し、必要なSkillとToolを選び、企画・技術・検証を担当するCodex native sub-agentを並列実行した。私がパスも方法も教えなくても、誰が何をするかを自分で分けた。

戻ってきたPDFとXLSXも、一度で正常だったわけではない。PDFはTTCフォントで崩れた韓国語をTTFへ変えて再レンダリングし、XLSXはずれた日付表示と列構成を直した後、全シートの数式と表示をもう一度確認した。

依頼から22分6秒後、CEO Pilot意思決定ブリーフPDFと2週間の実行管理XLSXが元のTelegram Topicへ戻った。Telegramから再度ダウンロードしたファイルのSHA-256も生成元と一致した。メッセージで完了と言っただけではなく、実際のファイルが往復した。

自然言語の目標から並列実行、部分的な再作業、検証、Telegramへのファイル返却まで通過したドッグフーディング結果

単一ユーザーE2E検証と複数ユーザー分離の課題

単一ユーザーのE2Eは最後までつながったが、22分は日常の小さな業務を任せるにはまだ長い。最終成果物も作成したAgent自身が再検証したため、独立検証とは呼べない。すべての子作業の状態を一つのTask Graphで管理し、最終完了を一度だけ確定するcontrollerと、従業員別のSession分離もまだ直接試していなかった。

次のドッグフーディングでは、まず2人の従業員のSessionが本当に混ざらないかを確認する必要がある。その後、22分かかった流れの中で最も長く詰まった区間を探す。この二つを通過して初めて、個人向けのドッグフーディングから従業員が一緒に使うシステムへ進める。

コメントする