AIチームでマイクラサーバーを作る#1AIリーダー1人 + メンバー15人でMMORPGプラグインを作る仕組み！ 🤖

こんにちは！Mojangcamです 😎

最近、知り合いと一緒にマインクラフトのMMORPGサーバーを作っています。レベル・ステータス・クラス・スキル・クエスト・ショップ・モブ・ペットまで、すべて自作のプラグインで動くサーバーです。問題は、これをほぼ1人で作らなければならないことでした。

そこでやり方を変えました。AI（Claude）1人を「開発チームリーダー」にして、その下に企画・デザイン・モジュール別の開発チーム15個をAIの予約タスクとしてつけました。私は方向性を決めて、ゲームに入ってテストして、決定を下すだけです。

このシリーズは、そうやって1週間で作った記録です。第1回では、「AIチームがどう働いているのか」という仕組みから整理していきます。

• 🧑‍💼 リーダー1人 + メンバー15人はそれぞれ何をしているのか
• 📄 指示書と報告書はどんな形なのか
• 🔀 複数のチームが同時にコードを触るとき、どうマージするのか
• 🧯 実際にチームが止まってしまった事件

📌 なぜ「AIチーム」に分けたのか 🧠

最初はAIのチャット画面1つですべてを作っていました。でも、モジュールが増えるにつれて問題が出てきました。

1. コンテキストがあふれる — 戦闘の計算式を直しているうちに、クエストのコードを忘れてしまいます。
2. 同時に進められない — 一度に1つのことしか進みません。
3. 記録が残らない — 「あのとき、なんでこう決めたんだっけ？」を探し直すのが大変です。

そこで、実際の会社のように分けました。メンバーは自分のモジュールフォルダだけを見て、リーダーは全体像とマージだけを見ます。

📌 ステップ1 - 指示書：口で言わずにファイルに書く

メンバー（予約タスク）は毎回記憶なしでゼロから始まります。だから、やることはすべてファイルに書いておきます。チームごとに orders/<팀>.md（팀＝チーム）ファイルがあり、ルールはたった3つです。

• 一番上の ## 이번 실행（今回の実行）セクションが今回やること
• 以前の指示は ## (이전 실행)（以前の実行）に名前だけ変えて下へ（消さない）
• リーダーはチームを実行するとき、言葉を付け足しません。指示はファイルにだけ

実際の指示書はこんな形です（一部省略）。

## 이번 실행 — 2026-09-30 #9 — 퀘스트 GUI 그림 연결
근거: 사용자 요청. 슬롯 배치 정본 = design/prompts-for-user_v7.md ① §3 표.
1. 배경: 창 제목 = 음수 공백 + 배경 글리프 + 흰 제목 (오르벨 메뉴와 같은 방식)
2. 아이콘 = item_model myserver:gui/quest/<id>, 설명은 전부 툴팁으로
3. 일지: 탭 0-1 메인 · 2-3 서브 · 4-5 일일 · 6-7 완료, 9-44 목록 36칸 …
9. 테스트: 슬롯 배치 단위 테스트, quest/ 밖 파일 수정 금지
시간: 11:45 전에 끝나면 오늘 테스트 빌드에 넣음

ひとつずつ見ていきましょう 💡

• 根拠（근거）：誰がなぜ依頼したのか。あとで「なんでこうしたんだっけ？」の答えになります。
• 番号リスト：メンバーがそのままチェックリストとして使います。
• テスト・範囲：「自分のフォルダの外は触らないで」のような柵を毎回書きます。
• 時間（시간）：急ぎのものは「何時までにできれば今回のビルド、無理なら次」のように書いて、焦って壊さないようにします。

口で言う代わりにファイルに書くので、同じ作業をもう一度動かしても結果がほぼ同じで、指示の履歴がそのまま残ります。これが一番大きなメリットでした。

📌 ステップ2 - 報告書：リーダーが3分以内に読めるように

メンバーは終わるときに reports/<팀>/YYYY-MM-DD_HHMM.md に報告書を残します。形式が決まっているので、リーダーがすばやく読めます。

特に①と⑦が重要です。AIは知らないことをそれっぽく決めてしまう傾向がありますが、「仮定」として別に書かせることで、あとから私がまとめて確認できました。

📌 ステップ3 - マージ：チームはブランチで、mainはリーダーだけ

モジュール13個を同時に触るので、コードの衝突が一番の心配でした。ルールはこう決めました。

• チームごとに git worktree で自分の作業フォルダ + 自分のブランチ（module/<팀>）
• メンバーは自分のモジュールフォルダの外のファイルを変更しない — コアに必要なものがあれば「コアリクエスト」として書くだけ
• mainへのマージ・ビルド・サーバーへのデプロイはリーダー1人だけ
• マージする前に、リーダーが2つのことを機械的にチェック
  • ブランチが自分のフォルダの外を触っていないか
  • 権限ノード名がルール（myserver.<모듈>.…）を守っているか

# このブランチが自分のモジュール外のフォルダを変更したか（結果が空なら合格）
git diff --name-only main...module/quest | cut -d/ -f1 | sort -u | grep -vx quest

2つ目のチェックがなぜできたのかは、第2回でお話しします。（モジュール2つが丸ごと無効になった事件がありました 😅）

ビルドが終わったらjarをサーバーの plugins/update/ フォルダに置いておき、サーバーを再起動したときに新しいバージョンが入るようにしました。

📌 AIチームが止まった事件 🧯

1. チームが静かに止まる — 「承認待ち」

しばらくの間、メンバーたちが作業を終えられずに止まっていました。エラーも通知もありませんでした。原因はファイル削除の権限リクエストでした。作業ルールに「必要なら削除権限をリクエストすること」と書いておいたら、メンバーが整理しようとして権限をリクエストし、人が承認するまで待っていたのです。

解決策はルールを変えることでした。

• メンバーはファイルを削除しない。不要なファイルは _to_delete/<팀>/ に移動するだけ
• gitから外す必要があるファイルは git rm --cached でのみ
• 人の承認がどうしても必要なら、待たずに報告書に「ブロック」と書いて終了する

AIチームで一番怖いのはエラーではなく、何も言わずに待ち続けることでした。

2. gitのロックファイル

複数の作業が同じリポジトリを触るので、index.lock や HEAD.lock が残って次の作業が止まってしまうことがよくありました。削除する代わりに、固有の名前を付けて別のフォルダに移動するルールで解決しました。

3. PCが眠るとチームも眠る

メンバーたちは私のPCに接続されたフォルダで作業しています。PCがスリープに入ると接続が切れます。リーダーが接続を確認し、つながらなければ1時間後にもう一度試すよう自分で予約するようにしました。

📌 人がやったこと vs AIがやったこと 💬

結局、私が一番多くやったことはゲームに入って見て、短く伝えることでした。この役割分担こそが、このシリーズの核心です。

📌 まとめ

今回はAIチームが働く仕組みを整理しました。

• 指示はファイルに、報告は決まった形式で
• チームは自分のブランチでだけ、マージはリーダー1人だけ
• AIチームが止まる一番よくある理由は人の承認待ち

次回は、1つのプラグインにコア + モジュール13個を入れた構造と、モジュールが丸ごと無効になった事件、ダメージが 1000029 と表示された事件を扱います。お楽しみに 🙌

この記事は、私が方向性を決めてClaudeと一緒にまとめました。このサーバーは個人プロジェクトであり、マインクラフトの公式コンテンツではなく、Mojang・Microsoftとは関係ありません。