この記事は、迷える非ベテランエンジニアの方々に向けたものです。
「こんなこともできる」という選択肢の一つになれば幸いです。
小さなプロジェクトや社内利用向けの開発をしているときに、「〇〇なやつ作ってよ」のような大ざっぱな依頼を、一人で受けたことがある人は少なくないと思います 
以前は、限られた知識とネット上の情報を頼りに進めるしかありませんでした。ですが、今は違います。生成AIの進歩によって、一緒に並走してくれるパートナーのような存在を得られるようになりました。
とはいえ、生成AIとのやり取りは基本的に一対一で、結局のところ処理を依頼するのは自分自身です。観点や目的設定を誤ると、うまく進められずに孤独感を覚えることもありますよね。
しかし、最近登場した生成AIのマルチエージェント機能を活用することで、開発に対する孤独感をやわらげることができました。この記事では、マルチエージェントの使い方と実際に動かした様子を共有します。
マルチエージェントとは
一言で表すとすると、あなたに協力してくれる専門家チームです。
方針やタスクを管理するメインエージェントがいて、その配下で動くサブエージェントが存在します。サブエージェントには役割が与えられ、それぞれのエージェントが独立してタスクを遂行します。
このように、複数エージェントが動く仕組みをマルチエージェントと言います。
サブエージェントにさまざまな役割や専門性を与えることで、複数の視点からタスクを処理できるようになります。その結果、問題解決の高速化や、複雑な課題への対応がしやすくなります。
まるで、課題解決のために専門家チームが並走してくれているような感覚です。一人でAIと向き合いながら進める開発特有の孤独感も、かなり薄まるように感じました。
実際に動かしてみた
今回は、Codex app からGISアプリを作るのに React/Next.js と Vue/Nuxt3 どちらを選定すれば良いか議論させてみました。
というのも、業務でGISアプリを作る機会があり、どちらがよいかを明確に言い切れなかったからです。（結局、知見を広げる意味で React を選びました）
準備
今回、準備するフォルダとファイルは以下の通りです。
.
├── .codex
│ ├── agents
│ │ ├── architect.toml
│ │ ├── dx.toml
│ │ ├── gis.toml
│ │ ├── infra.toml
│ │ ├── judge.toml
│ │ └── pm.toml
│ └── config.toml
├── AGENTS.md
└── output
まず、.codexフォルダを用意します。ここに全体やサブエージェントの設定ファイルを置いていきます。
config.tomlを作成
config.tomlは、全体の設定をするファイルです。どのサブエージェントを呼ぶか、どう動かすかを決める全体の指揮官的役割をします。
config.toml
config.toml
model = "gpt-5.4"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[agents]
max_threads = 6
max_depth = 1
[agents.gis]
description = "GIS実装担当。地図ライブラリ統合、描画性能、レイヤ管理を評価する。"
config_file = ".codex/agents/gis.toml"
[agents.architect]
description = "フロントエンド設計担当。状態管理、責務分離、保守性を評価する。"
config_file = ".codex/agents/architect.toml"
[agents.dx]
description = "DX担当。開発速度、学習コスト、型安全、情報量を評価する。"
config_file = ".codex/agents/dx.toml"
[agents.infra]
description = "インフラ担当。SSR/CSR/SSG、SEO、配信戦略を評価する。"
config_file = ".codex/agents/infra.toml"
[agents.pm]
description = "PM担当。納期、採用、教育コスト、将来拡張を評価する。"
config_file = ".codex/agents/pm.toml"
[agents.judge]
description = "審判。各エージェントの主張を整理し、条件別の結論をMarkdownで出す。"
config_file = ".codex/agents/judge.toml"
続いて、.codex内にagents フォルダを作成し、サブエージェントの設定ファイルを用意していきます。
gis.tomlを作成
gis.tomlは、GISの開発者目線で評価するエージェントです。
gis.toml
gis.toml
name = "gis"
description = "GIS実装担当。MapLibre、Leaflet、OpenLayers、描画責務分離を重視する。"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
あなたはGIS実装の専門家です。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
重視観点:
- MapLibre GL JS, Leaflet, OpenLayers との統合
- 地図描画とUIの責務分離
- 大量レイヤ管理
- GeoJSON, MVT, raster tile の扱いやすさ
- 再描画制御とパフォーマンス
ルール:
- 抽象論ではなく実装上の論点で述べる
- Nuxt 3 / Next.js の両方の長所短所を出す
- 地図ライブラリはラッパ依存ではなく素の統合もしっかり評価する
- 最後にこの前提で自分が推す側を明言する
"""
architect.tomlを作成
architect.tomlは、フロントエンドの設計者目線で評価するエージェントです。
architect.toml
architect.toml
name = "architect"
description = "フロントエンドアーキテクト。設計一貫性、状態管理、責務分離、保守性を重視する。"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
あなたはフロントエンドアーキテクトです。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
重視観点:
- コンポーネント設計
- 状態管理
- ディレクトリ構成
- テストしやすさ
- 長期保守での設計ぶれ
- 地図描画ロジックとUIロジックの責務分離
- App Router / composables / server components の影響
ルール:
- チーム開発で破綻しにくい構造を優先して評価する
- Nuxt 3 / Next.js の長所短所を述べる
- 最後に推奨案を明言する
"""
dx.tomlを作成
dx.tomlは、開発効率やコストに関する評価をするエージェントです。
dx.toml
dx.toml
name = "dx"
description = "DX担当。開発体験、学習コスト、型安全、情報量を重視する。"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
あなたはDX担当です。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
重視観点:
- 初期開発速度
- 学習コスト
- TypeScriptとの相性
- デバッグしやすさ
- 周辺情報量
- チームオンボーディングのしやすさ
- CLIや規約の強さ
ルール:
- 現実の開発現場を前提に評価する
- 好みではなく、導入しやすさと詰まりにくさで論じる
- Nuxt 3 / Next.js の長所短所を出す
- 最後に推奨案を明言する
"""
infra.tomlを作成
infra.tomlは、配信と運用に関して評価するエージェントです。
infra.toml
infra.toml
name = "infra"
description = "インフラ担当。SSR/CSR/SSG、SEO、配信戦略、運用を重視する。"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
あなたはインフラ/配信担当です。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
重視観点:
- SSR, CSR, SSG の扱いやすさ
- SEO
- CDN配信
- API連携
- 公開ページと業務画面の共存
- 地図機能をSSR対象から切り離す設計
- edge/runtimeの使い分け
ルール:
- 配信と運用の都合から評価する
- Nuxt 3 / Next.js の長所短所を述べる
- 最後に推奨案を明言する
"""
pm.tomlを作成
pm.tomlは、チームでの運用や採用市場などの観点で評価するエージェントです。
pm.toml
pm.toml
name = "pm"
description = "PM担当。納期、体制、採用市場、教育コスト、将来拡張を重視する。"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
あなたはプロダクトマネージャーです。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
前提:
- フロントエンドチームは2〜4人
- 初期リリースは3か月
- 今後も機能追加がある
重視観点:
- 初期リリースまでの速さ
- チーム体制との整合
- 採用市場
- 教育コスト
- 技術選定の失敗リスク
- 将来拡張
ルール:
- 組織運営の現実から評価する
- Nuxt 3 / Next.js の長所短所を出す
- 最後に推奨案を明言する
"""
judge.tomlを作成
judge.tomlは、各エージェントの主張を整理し最後にMarkdown形式で結果を出力させるエージェントです。
judge.toml
judge.toml
name = "judge"
description = "審判。全エージェントの主張を整理し、条件別に結論をMarkdownで出す。"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
あなたは審判です。
テーマは「GISアプリをNuxt 3で作成するかNext.jsで作成するか」です。
役割:
- 各エージェントの主張を整理する
- 強い根拠と弱い根拠を分ける
- 前提不足や比較の不公平さを指摘する
- 条件別に結論を出す
重要:
- 単純な勝者1名を決めない
- 「条件AならNuxt 3」「条件BならNext.js」の形でまとめる
- GISアプリではフレームワークより責務分離が重要なら、その点も明言する
最終出力はMarkdownで、以下の構造に従う:
# 議題
# 前提条件
# 論点ごとの議論
## 1. GISライブラリとの相性
## 2. パフォーマンス
## 3. 開発体験
## 4. 保守性
## 5. SEO/SSR
## 6. 採用と教育コスト
# 比較表
# 最終結論
# 総括
"""
続いて、ルートにAGENTS.mdを作成します。
AGENTS.mdを作成
AGENTS.mdは、全体のルールを記述します。プロジェクトの目的や全エージェントの共通ルール、出力形式や禁止事項について明記します。
AGENTS.md
AGENTS.md
# AGENTS.md
## Project goal
このプロジェクトでは、Codexのマルチエージェントを使って
「GISアプリをNuxt 3で作成するかNext.jsで作成するか」を議論する。
## Common rules
- すべての意見は技術的根拠に基づくこと
- 単なる好みで結論を出さないこと
- Nuxt 3 / Next.js の両方の長所短所を出すこと
- GIS固有の論点を必ず含めること
- 結論は前提条件に依存する形でまとめること
- 最終出力は judge がMarkdownで統一すること
## Output expectations
- 争点を明示する
- 反論可能な形で主張を書く
- 最後に judge が比較表と条件別結論を出す
- 出力ファイルは`output/`以下に保存すること
最後に、outputフォルダをルートに準備すれば完了です。
実行
実行は、Codex app から行います。Codex app から対象のプロジェクトフォルダを開き、ChatGPTと同様にチャット形式で指示を出すことができます。
ChatGPTのアカウントでサインインすれば利用できます。無料版でも期間限定で使用できるそうです（ChatGPT プランで Codex を使う）。
投げたプロンプトは以下の通りです。
GISアプリを Nuxt 3 で作るべきか Next.js で作るべきか、parallel subagents を使って技術選定会議を実施して。
要件:
- 地図表示、レイヤ切替、検索、属性表示がある業務Webアプリ
- フロントエンドチームは 2〜4 人
- 初期リリースは 3 か月
- 将来的に機能追加あり
- 地図ライブラリは MapLibre GL JS / Leaflet / OpenLayers を想定
進め方:
- gis, architect, dx, infra, pm の各エージェントに並列で評価させる
- 全員の完了を待ってから judge が統合する
- judge は Markdown 形式で最終結果を出す
- 単一の勝者を決めず、条件別に結論を分ける
- Return only the final Markdown report
すると、サブエージェントが続々と立ち上がり推論を始めます。サブエージェントに偉人たちの名前が付けられているのも面白いですね。
チャット欄を見ると、動いているサブエージェントの一覧が表示されます。
config.toml、judge.tomlで設定した通りjudgeエージェントがMarkdown形式でまとめてくれていますね。
outputフォルダを確認したらjudgeが出した結果以外にも各エージェントの観点での評価も出力してくれてました。
output
├── dx.md
├── frontend_architect.md
├── gis_impl_evaluation.md
├── infrastructure.md
├── judge_report.md
└── pm.md
judgeエージェントが作成した judge_report.md を確認すると、各エージェントの観点を踏まえた評価が整理されていました。
内容としては、どちらか一方を絶対的に推すのではなく、要員や期間、将来像によって適した選択が変わる、という結論でした。納得感のある整理だと思います。
もっと細かく、指示を与えるとベストな技術選定をしてくれそうです。
judge_report.md
judge_report.md
# 議題
業務Web向けGISアプリを、Nuxt 3とNext.jsのどちらで構築するのが妥当かを比較する。対象機能は地図表示、レイヤ切替、検索、属性表示であり、単なる好みではなく、技術的根拠と運用条件に基づいて判断する。
# 前提条件
- 対象は認証後の業務画面が中心のWebアプリである。
- フロントエンドチームは2〜4人、初期リリースは3か月である。
- 将来的な機能追加はあるが、初期版では高度な空間解析や3Dは前提にしない。
- 地図ライブラリ候補は MapLibre GL JS / Leaflet / OpenLayers である。
- GISアプリでは、フレームワーク選定そのものよりも、`地図描画`、`検索・属性取得`、`UI状態`、`BFF/API` の責務分離の方が成否に効く。
- したがって本比較は「どちらが万能か」ではなく、「どの条件ならどちらが破綻しにくいか」を見るべきである。
# 論点ごとの議論
## 1. GISライブラリとの相性
MapLibre GL JS / Leaflet / OpenLayers はいずれもブラウザAPI依存が強く、地図本体は client-only に隔離する設計が前提になる。この点では、どちらのフレームワークでも「地図をSSRの外に置く」こと自体は可能であり、絶対的な差は小さい。
強い根拠:
- Nuxt 3 は `<ClientOnly>`、`.client.ts`、composable によって、地図をクライアント専用の島として切り出しやすい。
- Next.js は App Router と `'use client'` により、server/client 境界を明示しやすく、検索や属性取得を server 側に残しやすい。
- GISでは地図描画が imperative、周辺UIが declarative になりやすいため、どちらでも `MapAdapter` のような中間層を置く設計が有効である。
弱い根拠:
- 「ReactだからGISに強い」「Vueだから地図実装が簡単」といった一般論は根拠が弱い。難しさの中心はフレームワークではなく、地図ライブラリ統合にある。
- ラッパライブラリの豊富さだけで優劣を決めるのも不公平である。実務では素の MapLibre/OpenLayers を直接扱う場面が多い。
前提不足・比較上の注意:
- OpenLayers を使うか、MapLibre を使うかで複雑度はかなり変わる。OpenLayers 前提なら、フレームワーク差よりGIS実装そのものが支配的になる。
- 地図が主役なのか、検索・一覧・ワークフローが主役なのかで評価は反転しうる。
判定:
- 地図中心の画面を短期で組むなら Nuxt 3 がやや有利である。
- 検索や属性取得を server 寄りに厳密に分けたいなら Next.js が有利である。
## 2. パフォーマンス
GISアプリの性能は、SSR性能よりも、再描画制御、レイヤ差分適用、GeoJSON/MVT/raster の扱い方、hoverやviewport更新をUI stateに流し込みすぎないことに左右される。したがって、フレームワーク比較では「再レンダリングを避ける設計をしやすいか」が主論点になる。
強い根拠:
- Nuxt 3 では `shallowRef`、`markRaw`、client-only 分離を使うことで、地図インスタンスをリアクティブ追跡の外に置きやすい。
- Next.js では `useRef` と client subtree に閉じる設計で、地図描画をReact再レンダリングから切り離しやすい。
- MapLibre の style diff、OpenLayers の layer/source 管理、Leaflet の軽量描画といったライブラリ特性の方が、フレームワーク差より大きい。
弱い根拠:
- 「Next.js の方が速い」「Nuxt 3 の方が軽い」という包括的な主張は弱い。GIS画面ではどちらも大半が client-heavy になる。
- SSRやServer Componentがそのまま地図描画性能を改善するわけではない。
前提不足・比較上の注意:
- ベクトルタイル中心か、大量GeoJSON中心か、ラスター中心かで最適解は変わる。
- 属性表示の頻度、同時表示レイヤ数、ズーム時の更新量が不明だと、性能論は過剰一般化になりやすい。
判定:
- 性能面の勝敗はフレームワークではなく、`地図描画状態をUI状態から分離できるか` に依存する。
- この条件では、Nuxt 3 も Next.js も適切な責務分離をすれば実用性能を出せる。
## 3. 開発体験
今回の条件では、開発体験は「3か月で2〜4人が迷わず同じ型で実装できるか」が中心になる。この観点では、Nuxt 3 は規約の強さ、Next.js は情報量と既存資産の厚さが強みになる。
強い根拠:
- Nuxt 3 は file-based routing、SFC、auto-import、`<ClientOnly>` により、小規模短納期で初速を出しやすい。
- Next.js は TypeScript、資料量、React生態系、採用済み部品の流用で有利になりやすい。
- GIS案件では hydration や client-only 境界が論点になるため、短納期では「判断箇所が少ない」こと自体が価値になる。
弱い根拠:
- DXの良し悪しを純粋にフレームワークUIだけで測るのは不十分である。チームの既存経験がDXに与える影響の方が大きい。
- 「情報量が多いから速い」も半分だけ正しい。情報量が多くても、設計選択肢が多すぎると初期判断は増える。
前提不足・比較上の注意:
- チームがVueに慣れているのか、Reactに慣れているのかが最重要である。この情報なしにDX優劣を断定するのは不公平である。
判定:
- 短期立ち上げのDXは Nuxt 3 がやや有利である。
- React/Next 資産が既に厚いなら、その優位は消え、Next.js がむしろ有利になりうる。
## 4. 保守性
保守性は、フレームワークの優劣よりも、地図ライブラリ依存コードをUIから切り離せるか、状態の置き場を先に決められるかで決まる。この点は本議題で最も重要である。
強い根拠:
- Nuxt 3 は `pages/components/composables/server/plugins` の規約で、小規模チームでも構成を揃えやすい。
- Next.js は server/client 境界が明示的で、検索、属性取得、認可、地図描画の責務を分離しやすい。
- どちらでも `features/map` や `map-adapter` のような境界を先に作れば、将来の地図ライブラリ変更や機能追加に耐えやすい。
弱い根拠:
- 「Nuxt 3 は規約があるから保守しやすい」「Next.js は大規模向きだから保守しやすい」といった言い切りは弱い。規約逸脱や設計ぶれが起きればどちらでも崩れる。
- auto-import や hook/composable の便利さを、そのまま保守性の高さとみなすのは危険である。
前提不足・比較上の注意:
- 状態管理を Pinia/Zustand/Context など何で揃えるか、URL同期をどこまでやるかが未確定だと、保守性評価は粗くなる。
- 3か月でまず出すのか、1年後の増員前提で育てるのかで、保守性の重みづけは変わる。
判定:
- 標準ケースでは Nuxt 3 が設計ぶれを抑えやすい。
- 組織標準がReact/Nextで、server/client 分離を運用できるなら Next.js の方が長期保守に一貫性を持たせやすい。
- ただし最重要なのはフレームワークではなく責務分離である。
## 5. SEO/SSR
この案件は業務画面中心であり、GISの中核は client-only になるため、SEO/SSR は地図本体ではなく、公開ページ、検索導線、メタ情報、初期条件の解決に限定して評価すべきである。
強い根拠:
- Nuxt 3 は route rules と Nitro により、SSR/SSG/SPA を整理しやすく、業務画面中心の単純な運用に向く。
- Next.js は App Router と Vercel 親和性により、公開ページ最適化、CDN、preview、edge 活用で強い。
- GIS画面の中核では、SSR優位は限定的であるという指摘は妥当である。
弱い根拠:
- 「Next.js だからSEOに強い」は半分しか正しくない。認証後の地図中心画面ではSEO価値が薄い。
- 「Nuxt 3 はSEOが弱い」も不正確である。今回の要件なら十分対応可能である。
前提不足・比較上の注意:
- 公開ページがどの程度重要か、業務画面と同一アプリで持つか、Vercel 運用を前提にするかで評価は変わる。
判定:
- 業務画面中心で構成を単純に保ちたいなら Nuxt 3 が適する。
- 公開ページSEOや配信最適化を強く取りたいなら Next.js が適する。
## 6. 採用と教育コスト
採用と教育コストは、中長期では無視しにくい。短納期だけを見ると Nuxt 3 が優位な場面は多いが、増員や引継ぎを見込むなら Next.js の採用市場優位は現実的な根拠になる。
強い根拠:
- React/Next.js 人材の市場母数は一般にVue/Nuxtより広く、増員や外部調達では有利になりやすい。
- Vue/Nuxt 経験が既にある少人数チームなら、Nuxt 3 の教育コストは低く、短納期での立ち上がりが速い。
- 初期リリース後も機能追加が続く前提では、採用しやすさは保守体制に直結する。
弱い根拠:
- 採用市場の広さだけで Next.js を選ぶのは短期納期では危うい。現チームの習熟度を無視しているためである。
- 逆に、現チームがVueに強いだけで Nuxt 3 を選びきるのも不十分で、将来の補充容易性は別軸で見る必要がある。
前提不足・比較上の注意:
- 社内標準技術、既存デザインシステム、将来の増員計画が不明だと、この論点は結論がぶれやすい。
判定:
- 初期納期と現チーム適合を重視するなら Nuxt 3 が有利である。
- 増員、採用市場、長期の人員流動性を重視するなら Next.js が有利である。
# 比較表
| 観点 | Nuxt 3 | Next.js | judge の整理 |
|---|---|---|---|
| GISライブラリ統合 | `ClientOnly` と composable で地図隔離がしやすい | App Router の境界明示は強いが client subtree が大きくなりやすい | 地図中心なら Nuxt 3 寄り、検索中心なら Next.js 寄り |
| パフォーマンス | `shallowRef` を徹底できれば安定 | `useRef` で描画責務を逃がしやすい | 優劣は小さく、責務分離が本質 |
| 開発体験 | 小規模短納期で初速を出しやすい | 情報量とTS/React資産が厚い | 現チーム経験で逆転しうる |
| 保守性 | 規約で設計ぶれを抑えやすい | server/client 分離を厳密に保ちやすい | 標準ケースは Nuxt 3、React組織標準なら Next.js |
| SEO/SSR | 業務画面中心の単純運用に向く | 公開ページSEO、CDN、preview に強い | 業務画面中心なら Nuxt 3、公開導線重視なら Next.js |
| 採用と教育 | Vue経験があれば短期で有利 | 採用市場と増員で有利 | 初期納期は Nuxt 3、中長期採用は Next.js |
# 最終結論
単一の勝者は決めない。今回の条件では、次のように結論を分けるのが妥当である。
- 条件Aなら Nuxt 3:
地図画面が中核で、2〜4人で3か月の初期版を安定して出すことを最優先する場合。特に、Vue経験がある、または設計判断を減らして実装を収束させたい場合は Nuxt 3 が適する。
- 条件Bなら Next.js:
検索、属性取得、認可、公開ページ、周辺UIを server 寄りに整理したい場合。特に、React/Next が組織標準で、将来の増員や採用市場を重視するなら Next.js が適する。
- 条件Cならどちらでもよい:
Leaflet 中心の比較的軽い地図で、業務UIも単純な場合。ここではフレームワーク差より、地図状態管理とAPI設計の品質の方が支配的である。
- 条件Dではフレームワーク選定より設計を優先すべき:
OpenLayers を使い、複数データ形式、レイヤ増加、選択・編集・時系列拡張まで見込む場合。ここでは Nuxt 3 か Next.js かより、`地図描画`、`UI状態`、`検索・属性取得`、`BFF` を分離した構造を最初に作れるかが重要である。
# 総括
この議題では、Nuxt 3 と Next.js の差は存在するが、GISアプリではフレームワーク優劣だけで成否は決まらない。最重要なのは、地図ライブラリを client-only に隔離し、地図描画の命令的処理をUI状態管理から分離することである。
意思決定としては、`短納期の地図中心案件なら Nuxt 3`、`React資産・採用市場・公開導線重視なら Next.js` という条件分岐が最も妥当である。実務上の推奨は、どちらを選ぶ場合でも、最初の1週間で `MapAdapter`、状態配置、SSR対象範囲、API/BFF境界を決め、フレームワーク固有機能より先に責務分離を固定することである。
まとめ
今回は、Codexのマルチエージェント機能を使って技術選定をさせてみました。生成AIと一対一だと、どうしても自身の観点に重みを置いた指示になりがちです。マルチエージェントを活用することで複数観点を交えた上で指示を遂行してくれます。
このように、複数の観点から検討してくれることで、一人で進めている感覚がやわらぎ、心理的な負担も軽くなるように感じました。
マルチエージェント機能を活用することでAIが複数観点から問題を考えられるようになり、複雑な問題を処理しやすくなります。複数観点で考えたい、複雑な問題を解決したいという方は、一人で抱え込まずにマルチエージェント機能を活用してみてはいかがでしょうか？
必要なサブエージェントの役割を考えるのが難しい？
今回紹介したサブエージェントの役割は、すべてChatGPTに相談しながら決めました。