こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。
普段はWebアプリやスマホアプリの案件などを担当しています。あと、趣味でAIを勉強しています。
Codexにサブエージェント機能が追加されたのでさっそく試してみようと思います。
Claude羨ましいなあ、私もAIチームを束ねてYesを連打するだけの仕事がしたいなあと指をくわえて待っていたのでこれは朗報です。
https://developers.openai.com/codex/subagents
ここからが本題
1. 今回作るもの
今回はサブエージェントを使って簡単なWebアプリを同時並行で開発してみます。
社内の新人向けのワーキングでこんなテーマがあったので、これをシミュレーションするプログラムを作りましょう。
あなたはエレベータの制御ロジックを開発するシステムエンジニアです。
エレベータの動作を制御するアルゴリズムを作成してください。
⇒このロジックによってエレベータは自律的に動作します
アルゴリズムは可能な限り利用する人が快適にエレベータを利用できることを目指します。
不足する情報があれば、常識的な範囲で追加して貰って構いません。
以下、前提とします。
・エレベータは2台です
・各エレベーターの最大搭乗人数は10人です(各エレベーターは自分の搭乗人数をセンターで把握できるものとします)
・建物は3階建てです
・2台のエレベータはそれぞれ自分自身について以下の情報を認識することが可能です
・何階にいるか？（何階と何階の途中か？）
・止まっているか？動いているか？どちらの方向に動いているか？動こうとしているか？
・ドアがどんな状態か
・2台のエレベータはそれぞれもう1台のエレベータの状態を認識することが可能です(相手の状態に合わせて自分がどちらに向かうべきかを選択する)
・何階にいるか？（何階と何階の途中か？）
・止まっているか？動いているか？どちらの方向に動いているか？動こうとしているか？
・ドアがどんな状態か
・エレベータは各フロアのエレベータを呼ぶボタンの状態を知ることができます(各階で待機している客がどちらの方向に行きたいか)
・エレベータは自分のエレベータ内のボタンの状態を知ることができます(乗客がどのボタンを押したか)
・エレベータは以下の情報は一切わかりません
・各フロアで待っている人の有無、人数
・もう1台のエレベータに乗っている人の有無、人数
・エレベータはそれぞれ、もう1台のエレベータに対して動作を指示することはできません
解けますか？私は解けません。新人じゃなくて良かった。
2. Codex用のAGENTS.mdを作成する
上記の内容を伝え、Canvasにmd形式でファイルを出力してもらいます。
3. Codexにサブエージェントを活用した開発を指示する
VSCodeを開き、AGENTS.mdを参照させます。
ついでに今回はサブエージェントを使用することを強制します。
4. 腕を組んで笑顔で見守る
まずは親エージェントが土台の構築をして、それからサブエージェントのそれぞれに仕事を振るようです。
今回はUI実装とロジック実装の2つのエージェントを使って開発するようです。
サブエージェントである「Feynman」「Mencius」が立ち上がりました。
各エージェントはそれぞれGPT-5.4-Miniが選択されました。
ちなみに、命名は以下になっていますが、センスが気になります。
- Feynman = ロジック担当っぽい名前(物理学者の Richard Feynman に由来？)
- Mencius = UI/人間寄り担当っぽい名前(国思想家の 孟子(Mencius) に由来？)
サブエージェントは以下で確認でき、「Open」を押下するとそれぞれのサブエージェントの仕事を覗くことが出来ます。
サブエージェントを覗くと、ワーカーとしての指示(プロンプト)を確認することが出来ます。
ロジック側の進捗を確認します。
UI側の進捗を確認します。
親エージェント(統合役)を確認します。
サブエージェントでUIの実装が完了したことを親が把握しました。
サブエージェントでロジックの実装が完了したことを親が把握しました。
UIとロジックを繋げる統合作業に着手するようです。
統合およびテストが完了したようです。
5. 動作確認をする
今回はViteで実装してくれたので、ローカルでの動作確認が簡単です。
ターミナルで「npm run dev」と叩き、ブラウザ上で確認します。
できあがったもの。
ご丁寧に以下の機能が付いています。
・実行速度の調整
・シナリオの選択(早朝ピークや平常時、ランダムなど)
・ロジック2つの比較アニメーション
・ロジック2つの各種スコア
ロジックは2つ実装したようです。
・左：呼ばれたらとにかくその階に移動することが優先(決まった進行方向はない)
・右：エレベータの移動方向を保つことが優先
通常シナリオ(Normal)で動かしてみます。
アニメーションを確認する。
左のアルゴリズムはエレベーターBが1→2階に移動したのちに、2→1階に移動しています。(1階のボタンが押されたため)
右のアルゴリズムはエレベーターAとBの両方が上下移動の方向を保っています。
スコアの変化を確認する。
スコアの計算式は以下になっています。
finalScore =
1000
- 4.0 * max(0, avgWait - 15)
- 8.0 * max(0, p95Wait - 30)
- 12.0 * max(0, maxWait - 45)
- 300.0 * (leftBehindRate ^ 2)
- 2.0 * max(0, avgRide - 20)
- 1.0 * reversalsPerTrip * 100
20.0 * imbalance
10.0 * log(1 + completedTrips)
- 15秒以下の平均待ちは十分良い
- 30秒を超える p95 はかなり悪い
- 45秒を超える最大待ちは強く悪い
- 乗り残し率は強く罰する
- 完了輸送数は評価するが、主役にはしない
※画質がガビガビで申し訳ございません
1分間くらい動かしたときの断面がこちら。
消費電力という大きな問題を完全に無視すると、「呼ばれたらすぐ行く」(左)が今回のスコアとしては優秀だと評価されています。
(瞬間的にアルゴリズムBが優位になる時間もありました)
AとBの「呼ばれたらすぐ行く」「進行方向をなるべく維持する」はさすがに頭が悪すぎるので、アルゴリズムCとして以下を追加してみました。
今のエレベーターの位置、進行方向、混み具合、すでに乗っている人の行き先などを見て、どの階をどの順番で取りに行くのがよさそうかを決めています。
これは前提である「2台のエレベータはそれぞれもう1台のエレベータの状態を認識することが可能です」を上手く活用しています。
- 早く行けるか：呼び出し階までの予想到着時間が短いほど高評価。
- 今の流れに合っているか：エレベーターの進行方向と同じ向きの呼び出しなら高評価。逆向きは減点。
- そのエレベーターが混みすぎていないか：乗車率が高いほど減点して、もう1台に仕事を回しやすくする。
- 担当エリアが偏りすぎないか：2台の受け持ちが片寄らないように、ゾーン（低層側/高層側）のバランスを加味。
結果がこちら。(AとCの比較)
Cの圧勝です。
さいごに
SIerとして仕事をしているとコレ系の課題によく直面すると思いますが、お客様と一緒に画面を見ながらすぐ評価できるのは良いですね。良い時代になったものです。
先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。AI使って仕事したいSIのかたは是非ご検討ください。
(ClaudeCode派が多く、Codex派の私は少し肩身が狭いです)
↓ のスターを押していただけると嬉しいです。励みになります。
最後まで読んでいただき、ありがとうございました。
エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。
執筆：英 良治 (@hanabusa.ryoji)
（Shodoで執筆されました）
