AGENTS.mdのルール1行から始めるAIエージェントのチーム運営とゲームスタジオ

ある開発者は4～5カ月にわたり、小さなゲームスタジオの運営の大部分をAIエージェントに任せてきました。AIエージェントとは、目標を受け取ってタスクに分け、ツールを使ってやり遂げるソフトウェアです。大きなプロジェクト仕様を渡すと、エージェントたちはコード、キャラクターアート、音楽、品質テストにまたがって数十時間分の作業をこなします。これまでの成果として、スペードのカードゲームがAppleのApp Store審査に提出されています。この仕組みは、初日から壮大なシステムとして設計されたわけではありません。リポジトリのファイルに書いた1つのルールと、仕事を割り振る調整役のエージェント1つから育ったものです。

エージェント型システムとは何か

ここでいうエージェント型システムは三つの要素でできています。知能にあたるモデル、指示と境界線にあたるルール、そして実際に作業をこなす手段であるツールです。これらをまとめて動かす枠組みはハーネスと呼ばれます。

ChatGPT、Codex、Claude Codeはすでにエージェント型システムです。多くの人は、それらを開発した企業が書いたルールのもとで使っているにすぎません。自分でルールを書くようになると、仕事の進め方が変わります。

• プロンプトを入力し、物足りない結果を見て、またプロンプトを入れ直すという習慣は、昨年までのワークフローとみなされます。
• この夏以降に登場したフロンティアモデルは、1行ずつコードを指示するより、目標を与えたほうがうまく機能するようです。
• 目標単位で任せるには、エージェントがしてよいこと、決してしてはならないこと、チームの仕事の進め方を明記したルールが必要です。

最初のルールはごく小さくてかまいません。AGENTS.mdやCLAUDE.mdのファイルに、本番環境へ直接プッシュしないといった1行を書くだけで始められます。その後、必要になるたびにルールを1つずつ追加していきます。

実際のMacアプリを調整役主導のプロジェクトにする

その一例が、販売中のMac用メニューバーアプリです。ClaudeやOpenAIのサブスクリプションの利用枠がどれだけ残っているか、今のペースだと早めに使い切ってしまうかを表示するアプリです。一つのGitリポジトリに、Macアプリ本体、紹介ページ、販売ページ、配布パイプラインがすべて収められています。

Claude Codeのデスクトップアプリで、このリポジトリに紐づいたチャットセッションに対し、コードを書く役ではなく、オーケストレーター（作業を分担させて進捗を管理するリーダー役のエージェント）として振る舞うよう指示しました。指示の内容は次のとおりです。

• 依頼を解釈し、サブエージェントや別のスレッドに作業を振り分ける
• タスクごとに適切なモデルの階層と、モデルがどれだけ考えるかを示す推論の労力（reasoning effort）を選ぶ
• タスクがバックグラウンドで動いている間も、人間といつでも会話できる状態を保つ
• 稼働中のサブエージェント、その状態、プロジェクトのマイルストーンを、聞かれなくても報告する

Claude Codeはこの役割を引き受け、モデルの割り当て方を次のように整理しました。

ワークツリーの分離も約束しました。複数のエージェントが同じファイルを編集するときは、同じリポジトリを別々に展開したGitワークツリーでそれぞれ作業させ、マージ時に変更がぶつからないようにします。

ルールはツールのメモリではなくAGENTS.mdに

当初、Claude Codeはこの運用ルールを自分のローカルメモリに保存しました。しかし、あるツール内のメモリはそのツールでしか役に立ちません。そこでエージェントにルールをリポジトリへ移すよう指示し、AGENTS.mdに9行の「How we work」セクションを追加させ、メモリ側のコピーは削除しました。これでCodexのような他のコーディングツールも同じルールに従えます。新しいセッションで作業者なのかオーケストレーターなのかを尋ねると、モデルはリポジトリのルールを根拠に、すぐにオーケストレーターだと答えました。

▲ 並行して進む三つのタスク

三つの仕事を同時に

次にオーケストレーターに、三つの内容からなる依頼を出しました。販売中のビルドがリポジトリのリリースと一致しているかを確認すること、自動テストを実行すること、新機能のアイデアを二つか三つ出すことです。オーケストレーターは依頼を三つのバックグラウンドタスクに分け、エージェント名、モデル、労力のレベル、状態をまとめた表をリアルタイムで示しました。

発案を担当するエージェントは、自分のスレッドでプロジェクトの履歴、レート制限、設定ファイルを読み込み、その間もメインのチャットは止まりませんでした。提案されたのは、過去8週間の利用状況を示すアクティビティストリップ、5時間のリセット前にセッションの枠が尽きる時期を予測するアラート、プロジェクト別に最も重いセッションを示す内訳の三つです。人間はアクティビティストリップを選び、まずOpusに仕様を書かせ、その後、分離したワークツリーでSonnetに実装させるようオーケストレーターに指示しました。

複数のエージェントセッションを別々のタブで開く方法と比べてみましょう。全体の進捗を一か所で見渡せず、モデルと労力のレベルを毎回人間が手で選ばなければなりません。発案にはOpusの中程度の労力で十分でしたが、アーキテクチャのロードマップにはより高い労力のほうがよさそうです。オーケストレーターがタスクを並行ではなく一つずつ処理するようになったら、AGENTS.mdの指示を調整して直します。

発想をゲームスタジオへ広げる

同じ発想を会社の規模に当てはめると、それぞれ独自のフォルダを持つ部門の集まりになります。

• スペードやクリベッジなど、ゲームごとの部門
• マーケティング部門とプロデューサー部門
• どのゲームでも再利用できる、UI、セッション管理、ロビー、ゲームの中核ロジックの共有キット

スタジオには専用のダッシュボードもあります。一つは、リーダー、作業者、共有ルール、部門からなる組織を円形の図で描くものです。キャラクターツールは、肖像画、音声演技のプロファイル、セリフの修正を管理します。オーディオツールは音楽と効果音を整理し、サンプリングレートとビットレートをそろえます。ある検索では205件の音楽が表示され、サウンドライブラリには949件の効果音が収められています。リリース用のダッシュボードは、App Storeの審査要件、スクリーンショット、法的な表記、マーケティング素材を追跡します。

時間のかかる評価はLab部門が担当します。ローカルのハードウェアで動きますが、外部のテストベンチと通信できます。指針となる原則は分散化です。長時間の作業は、1台のノートパソコンを一日中起動させておくことに頼らず、ホスティング環境で動かすべきだという考え方です。

プロデューサーとアーキテクト

スタジオ全体を支えるのは二つの役割です。

プロデューサーは、人間からの指示を受ける主な窓口です。目標を計画に分解し、作業者を割り当て、次の4段階のサイクルで成果を見守ります。

1. 解釈と計画
2. 人員配置と着手
3. 観察と復旧
4. 評価と統合

スタジオのかんばんボードでは、プロデューサーがスペードのゲームに関する14件の進行中リクエストを含め、デザイン、エンジニアリング、マーケティングにまたがる依頼を並行してさばき、作業を進めながらフォローアップを登録していきます。

アーキテクトは内部の調整役です。すべての部門の健全性を確認し、失敗を繰り返したり手戻りが重なったりする部門があれば、その部門のルールに是正の指針を書き込みます。新しいゲームの開始や、マーケティング動画、SNS投稿への進出などで事業が広がれば、アーキテクトは境界を明確にした新しい部門を作ります。不要になった部門は畳み、組織を身軽に保ちます。

10の共有ルール

すべての部門は10の共有ルールを受け継ぎます。人間の意図、オーナーシップ、リーダーと作業者、実際の着手、品質、復旧、永続的な作業、ホストと納品、学習、全体の範囲です。これらのルールによって、各部門は同じ方法でファイルを書き、同じ取り決めでやり取りし、同じ品質基準を満たします。

この構造全体は、スペードのゲームを作るという一つの目標から始まりました。最初にデザインのフォルダができ、次にスペードのコードのフォルダ、続いて独立したキャラクターライブラリができました。クリベッジとパチーシが素材やユーティリティを共有し始めると、フォルダは現在の複数部門からなるスタジオへと成長しました。

▲ 部門ごとに分かれたAIゲームスタジオ

人間が主導権を握り続ける部分

このシステムは完全に自律しているわけでも、完璧なわけでもありません。人間はクリエイティブディレクターとしてゲームに自分の好みを反映させ、機能やユーザー体験に関する決定を下します。むしろよくある落とし穴は逆の方向にあるのかもしれません。AIに任せられるのは単一ファイルの小さなコード片だけだと思い込み、会社の運営業務をどれほど任せられるかを見落としてしまうことです。

1つのルールと1つのオーケストレーターから始める

複数の部門を持つスタジオを最初から設計する必要はありません。複雑さは、実際のプロジェクトで実際にぶつかった摩擦から生まれるべきです。妥当な始め方は次のとおりです。

1. 既存のリポジトリにAGENTS.mdまたはCLAUDE.mdのファイルを追加し、禁止事項を1つ書きます。
2. メインのチャットに、自分でコードを書くのではなくオーケストレーターとして動くよう指示し、タスクごとにモデルの階層と労力を選ばせます。簡単な確認やテストにはHaikuか低い労力のSonnet、アーキテクチャや発案には高い労力のOpusを使います。
3. 同じファイルを触るサブエージェントには、別々のワークツリーで作業させます。
4. モデル、労力、完了状況を示す表の形で状況を報告させます。
5. 運用ルールは、ツール固有のメモリではなく、リポジトリ内でバージョン管理された文書に残します。
6. エージェントが行き詰まったり同じ間違いを繰り返したりするたびに、その教訓を新しいルールにします。

プロジェクトが増えてきたら共有コードを独自のモジュールに切り出し、指示の窓口となるプロデューサーと、システムの健全性を担うアーキテクトの追加を検討します。リポジトリに書いた1つのルールは控えめな出発点ですが、このスタジオが育った出発点もまさにそれでした。