コーディングエージェントを利用したボトムアップ型ツール開発

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackB-7

Transcript

1. GREE Tech Conference 2026 コーディングエージェントを用いた ボトムアップ型ツール開発 株式会社WFS プランナー 形山 竜一
2. 自己紹介 形山 竜一 株式会社WFS フィールドプランナー 高専から慶應義塾大学SFCに進み、HCIを研究。VR関連ECサイトのフロ ントエンド開発や、映像制作ソフトの開発を経て、2025年3月よりグリー ホールディングス株式会社に入社し、株式会社WFSに所属。 現在は『アナザーエデン 時空を超える猫』のフィールドプランナーとして ゲーム内コンテンツの企画・実装を担いながら、開発経験を活かしてAI エージェントを活用した内製ツール開発や生産フロー改善にも取り組んで いる。 2
3. 本日の流れ 01 02 アナザーエデンと私たちの仕事 長期運用による複雑な工程の固定化 例1 エリアの追加 ／ 例2 NPCの配置 03 AIツールを一箇所にまとめる仕組み 04 システム構成 05 1つの機能が足されるまで 06 問題・課題 07 今後の展望 まとめ 3
4. 01 アナザーエデンと私たちの仕事 1/7 4
5. 01 アナザーエデンと私たちの仕事 アナザーエデンと私たちの仕事 ジャンル スマートフォン向けRPG 運用 2017年リリース、来年で10周年 開発期間を含めると12年ほど ゲーム 過去・現在・未来を行き来する冒険 街やダンジョンを歩いて、話して、探検して、戦う ©WFS Developed by WRIGHT FLYER STUDIOS 5
6. 01 アナザーエデンと私たちの仕事 アナザーエデンの開発体制 プランナー コンテンツの企画と実装 シナリオ バトル 物語のプロットや本文を書く 戦闘のギミックやバランスの設計・ 実装 スクリプト フィールド イベントの演出。カメラやキャラク ターの動き、表情 エリアの設計、イベント、ダンジョ ンギミックなど ほかにも運用班・アート班などがあります 6
7. 01 アナザーエデンと私たちの仕事 フィールド班の業務 1 エリアを作る 2 エリアのイベントを作る • プレイヤーが歩き回るマップ • ダンジョン内の扉を開くギミック • 歩ける場所や動線の設計・実装 • NPCに話しかけると会話が始まる • 見た目の装飾やカメラ設定 • 宝箱やフィールド上の小ネタ • シナリオに応じた天候や環境変化 7
8. 02 長期運用による複雑な工程の固定化 2/7 8
9. 02 長期運用による複雑な工程の固定化 長期運用で、複雑な工程が固定化している 来年で10周年 長く続いている運用タイトル 独自の開発ツール Cocos2d-xベースの独自エディタ エンジニアの最優先は別 新規実装や不具合対応が最優先 複雑な作業工程がそのまま固定化 実例を2つ紹介します 例1 エリアを一つ追加するまで 例2 NPCを一人追加するまで 画像引用：https://docs.cocos2d-x.org/api-ref/cplusplus/V3.6/ 9
10. 02 長期運用による複雑な工程の固定化 エリアとは プレイヤーが歩くマップのこと 街、ダンジョン、草原、民家の中…… 要素 1 見た目の装飾 2 歩くためのライン 3 イベント発火位置用のピン 4 その他 カメラや環境効果など ©WFS Developed by WRIGHT FLYER STUDIOS 10
11. 02 長期運用による複雑な工程の固定化 エリアとは プレイヤーが歩くマップのこと 街、ダンジョン、草原、民家の中…… 要素 1 見た目の装飾 2 歩くためのライン 3 イベント発火位置用のピン 4 その他 カメラや環境効果など ©WFS Developed by WRIGHT FLYER STUDIOS 11
12. 02 長期運用による複雑な工程の固定化 エリアとは プレイヤーが歩くマップのこと 街、ダンジョン、草原、民家の中…… 要素 1 見た目の装飾 2 歩くためのライン 3 イベント発火位置用のピン 4 その他 カメラや環境効果など 交差点や道の終わりにピンを置き、ピン同士をラインでつなぐ ©WFS Developed by WRIGHT FLYER STUDIOS 12
13. 02 長期運用による複雑な工程の固定化 エリアとは プレイヤーが歩くマップのこと 街、ダンジョン、草原、民家の中…… 要素 1 見た目の装飾 2 歩くためのライン 3 イベント発火位置用のピン 4 その他 カメラや環境効果など イベント用のピンを足し、何が起きるかを Lua で書く ©WFS Developed by WRIGHT FLYER STUDIOS 13
14. 02 長期運用による複雑な工程の固定化 エリアとは プレイヤーが歩くマップのこと 街、ダンジョン、草原、民家の中…… 要素 1 見た目の装飾 2 歩くためのライン 3 イベント発火位置用のピン 4 その他 カメラや環境効果など 約1ヶ月半ごとのアップデートで 約 20 エリアを新規作成 ©WFS Developed by WRIGHT FLYER STUDIOS 14
15. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 一年前の工程 1 スプレッドシートで設計と共 有 2 CLIツールで雛形のCSVを出 力 3 ExcelでCSVを加工 4 CLIツールで不完全なJSONに 出力 15
16. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 一年前の工程 1 スプレッドシートで設計と共 有 2 CLIツールで雛形のCSVを出 力 3 ExcelでCSVを加工 4 CLIツールで不完全なJSONに 出力 ツール起動画面 出力される初期CSV 16
17. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 一年前の工程 1 スプレッドシートで設計と共 有 2 CLIツールで雛形のCSVを出 力 3 ExcelでCSVを加工 4 CLIツールで不完全なJSONに 出力 Excelでの編集 17
18. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 一年前の工程 1 スプレッドシートで設計と共 有 2 CLIツールで雛形のCSVを出 力 3 ExcelでCSVを加工 4 CLIツールで不完全なJSONに 出力 CLIツール設定画面（.txt） 18
19. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 一年前の工程 1 スプレッドシートで設計と共 有 2 CLIツールで雛形のCSVを出 力 3 ExcelでCSVを加工 4 CLIツールで不完全なJSONに 出力 出力結果：ずれや足りないピンは手で直す ©WFS Developed by WRIGHT FLYER STUDIOS 19
20. 02 長期運用による複雑な工程の固定化 一年前の工程の問題点 1 ツールの行き来 2 4〜5個のツールを行き来する。起動や頭の切 り替えが重たい 3 Excelの下準備 毎回セルのサイズ調整や、書式による色付け が必要 メンテナンスされないCLIツール 設定ファイルがテキスト形式でわかりづら く、エラーも出ない 4 数十箇所の手直し 出力したJSONの不備や、足りないピンを手で 追加 20
21. 02 長期運用による複雑な工程の固定化 例1：エリアを一つ追加する工程 現在の工程 設計から出力まで 1つのツールで完結 CLIツールのロジックは リスペクトしつつ移植 GUIの追加やアセットサイズの自動設定など 細かい使い勝手を向上 ピン・ラインの配置 20分 → 3分 道アセットを敷く 10分 → 1分 1エリアあたり 約40分削減 21
22. 02 長期運用による複雑な工程の固定化 例2：NPCの配置とイベント作成 酒場や街などにいるNPC 以前の工程の問題 1 7000を超えるエリア一覧から、過去のエリアの Luaファイルを探してコピペ 2 座標や見た目、吹き出しの種類などを、Luaスク リプトで直接編集（見た目はEnumの値で判断） 3 NPC一人に一つのLuaファイル ©WFS Developed by WRIGHT FLYER STUDIOS 22
23. 02 長期運用による複雑な工程の固定化 例2：NPCの配置とイベント作成 現在の工程 ツールからエリアのNPCを一括管理 1ファイルでNPCを複数管理 場所・吹き出し・出現条件をGUIで設定 セリフの文体チェックも 23
24. 02 長期運用による複雑な工程の固定化 例2：NPCの配置とイベント作成 現在の工程 ツールからエリアのNPCを一括管理 1ファイルでNPCを複数管理 場所・吹き出し・出現条件をGUIで設定 セリフの文体チェックも ノードエディタも作った 非エンジニアによる修正や機能追加も 24
25. 02 長期運用による複雑な工程の固定化 2つのツールに共通するルール 入稿するデータの形を今までと同じにする この間の作業だけで完結させる 入力 出力 例1 エリアの追加 エリアやNPCの 設計情報 CLI → Excel → CLI → 手直し 1つのツールで完結 JSON・Lua 入稿データ 例2 NPCの配置 過去のLuaをコピーして直接編集 ゲーム側・エンジニア側の作業に影響が出ない 画面上で設定して一括管理 品質はこれまでと同じ確認の流れで見られる 25
26. 03 AIツールを一箇所にまとめる仕組み 3/7 26
27. 03 AIツールを一箇所にまとめる仕組み AIで作ったツールの置き場所と配り方 AIを用いた個人によるツール開発が 活発に行われるようになった index.html ル1つ イ HTMLファ tool.py ただ…… Pythonファイ ル1つ 作り方・置き場所・配布方法などが 決まっていないことがある Artifact アーティファクトのまま 27
28. 03 AIツールを一箇所にまとめる仕組み ツールは1つのアプリにまとめている 30 個ほど 現在のツール数 28
29. 03 AIツールを一箇所にまとめる仕組み 1つのアプリになるまで 2025.07 〜2026.02 2026.05 2026.08 最初のツール ほぼ一人で5〜6個 AIへの指示書を追加し リポジトリを社内共有 バトル班ツールと統合 通常の数十倍の広さを持つ マップの作成ツール 二つ目の集約アプリとして バトル用も 翌月のコミット数 ツール数 4 14→27 倍 29
30. 04 システム構成 4/7 30
31. 04 システム構成 アプリの全体像 読み書き デスクトップアプリ（Tauri 2） ゲームアセット エリアのJSONやギミックのLua WebView（画面） Core（Rust） React / TypeScript / Vite Tailwind CSS Konva・three.js SQLite git同期 自動更新 同期 チーム共有ストレージ GitHubリポジトリ React Flow 更新 GitHub ツールのソースコード / Releases 指示書（mdファイル） AIエージェント Issue・PR・リリース リポジトリ内／ゲーム開発ルールはプラグ イン GitHub Copilot / Claude Code 作業はAIが代行する 31
32. 04 システム構成 非エンジニア複数でも壊れにくい仕組み 設計 1 班ごとのフォルダ フォルダに置くだけでメニューに載る。共通部分に 触らずにツールを追加できる 2 AIへの指示書 開発手順はリポジトリ内に、ゲーム固有の知識はプ ラグインにまとめて配布 3 デザインシステム UIカタログから部品を選ぶので、誰が作っても似た 見た目になる 32
33. 04 システム構成 非エンジニア複数でも壊れにくい仕組み 設計 root/ 1 班ごとのフォルダ フォルダに置くだけでメニューに載る。共通部分に 触らずにツールを追加できる CLAUDE.md Claude Code 用 AGENTS.md Codex など用 .github/ copilot-instructions.md 2 AIへの指示書 開発手順はリポジトリ内に、ゲーム固有の知識はプ ラグインにまとめて配布 GitHub Copilot 用 docs/ team_workflow.md issue → PR の手順 adding_a_tool.md ツールの追加手順 src-field/ 3 デザインシステム UIカタログから部品を選ぶので、誰が作っても似た 見た目になる CLAUDE.md 別リポジトリ marketplace/ 班ごとの指示書 ゲーム開発のルールを プラグインで配る 33
34. 04 システム構成 非エンジニア複数でも壊れにくい仕組み 設計 1 班ごとのフォルダ フォルダに置くだけでメニューに載る。共通部分に 触らずにツールを追加できる 2 AIへの指示書 開発手順はリポジトリ内に、ゲーム固有の知識はプ ラグインにまとめて配布 3 デザインシステム UIカタログから部品を選ぶので、誰が作っても似た 見た目になる 34
35. 04 システム構成 アプリの更新と配布 普段の開発でgitは使っているが、Issueやブランチ、イレギュラー時の対応までは非エンジニアには難しい 1 2 3 4 Issue・ブランチ ・PR リリース アプリ更新 共有 AIが操作する コマンド／スキルで頼め ばOK。リリースノート もAIが書く GitHub Releases から情 報を取得し、アプリ内で 案内 フィールド班では週1で リリースノート確認会 35
36. 05 1つの機能が足されるまで 5/7 36
37. 05 1つの機能が足されるまで 「NPCの向きを戻す機能」が入るまで 例 NPC Studio に、現場のメンバーがAIに頼んで足した機能 1 2 3 4 5 困る AIに頼む AIがつくる リリースする 共有する NPCが会話の後も向 きがそのままで不自 然 エンジニアではなく AIに伝える 指示書やプラグイン を読み、Issue → 班 フォルダで実装 → PR コマンドかスキルで リリース → 全員のア プリが更新 定期的な確認会で、 誰が足したかを共有 困った本人がAIに頼んで直し、次の更新で全員が使えるようになる 37
38. 06 問題・課題 6/7 38
39. 06 問題・課題 うまくいっていないこと 課題 1 課題 2 全体の工数はまだ減ったとは言えない 使ってもらうまで、作ってもらうまでが 大変 • 大きく工数を減らせる場所は、すでに着手済みであ ることが多い • ツールが知られていない、今のやり方で困っていな い → 乗り換える動機が弱いケースも • 痒いところが減っても、全体から見ればごく一部 • エンジニア経験者がいないと勧めにくい場面も • 最終的にはエンジニアさんによる全体のフロー改善 が必要 • フィールド班は活発。班によって差がある 39
40. 07 今後の展望 7/7 40
41. 07 今後の展望 振り返りと今後 良かった事 時間の使い方 作れるもの • 作ったツールを簡単に共有できる場所に なっている • オーバーヘッドの削減 • 作りやすくなることで、体 験を提供する機会を増やせ る • エンジニア工数なしでツール開発が進め られる。放置されてきた痒いところに手 が届く • より本質的なことに時間と 頭を使う • AIに触れる機会になり、リテラシー向上 にも繋がっている 41
42. まとめ 1 AIで作ったツールには、置き場所と配り方が必要 2 非エンジニアでも迷わない開発環境を配る エンジニア プランナー より大きなフローの改善に じっくり取り組める ゲームの面白さを考えることに 時間を使える 42
43. ご清聴ありがとうございました 株式会社WFS 形山 竜一