アンリアルエンジン（以下、UE）の国内ユーザーであれば誰でも参加できる、UEを用いたゲーム開発学習を目的としたコンテスト「ぷちコン」。お題に沿って制作された作品の中から、主催のヒストリアと共催のエピック ゲームズ ジャパンの担当者によって優秀作品が選定されます。
2026年2月～4月にかけて開催された「第25回UE5ぷちコン」では、「とう」をテーマに112作品の応募がありました。今回は、応募作品の中から最優秀賞に選ばれた『陶（とう）』の開発者「ぽちお」さんにインタビューを実施しました。
ろくろでの成形や色付けまで本格的な陶芸手順を体験でき、最後はなぜかランウェイでの完成品披露ウォークが楽しめるユニークな本作。その企画から実装に至るまでのこだわりや、「Claude Code」を駆使したイノベーティブな開発の裏側に迫ります。
TEXT / ハル飯田
EDIT / 浜井 智史
ぽちおさん
フリーランスSEとしてゲーム・Web・インフラ開発などを手がける傍ら、UEユーザーコミュニティによる勉強会「Unreal Engine Meetup in Shizuoka」主催としても活動する。
「第25回UE5ぷちコン」では『陶（とう）』が最優秀賞を受賞。
――まずは自己紹介として、ご経歴やゲーム制作経験などをお聞かせください。
「ぽちお」と申します。普段はノンゲーム分野で、フリーランスのシステムエンジニアやプログラマーとして活動しています。
ゲーム開発には幼少期から興味があり、初めてPCを手に入れた中学生の頃から独学でゲームを作り始めました。専門学校時代には、DirectXを用いた開発も経験しています。
その後、UEを用いた開発も手掛けるようになり、2021年の「第16回UE4ぷちコン」に初めて参加しました。その際、受賞候補作にあたる「“惜しい！でした”枠」として評価いただいたことが大きなモチベーションとなり、以降も応募を続けて今回でちょうど10回連続の参加となります。
第17回では「ささき賞」をいただき、その後もいくつか賞を頂戴してきましたが、このたび念願だった最優秀賞の栄誉に与ることができました。
「第25回UE5ぷちコン」キービジュアル（画像はヒストリア公式サイトより引用）
ぷちコンの裏では「UE5ぷちコン友の会」というDiscordサーバーを運営し、参加者同士の交流を深める活動を行っています。
そのほか、UEユーザーコミュニティ主体の勉強会イベント「Unreal Engine Meetup in Shizuoka」の主催など、ゲーム開発に関するコミュニティ活動にも取り組んでいます。
――ここからは、第25回ぷちコンで最優秀賞に選ばれた『陶』についてお伺いします。まずは簡単にゲームの紹介をお願いします。
タイトルの通り、陶芸を体験するゲームです。提示されたお題に沿って陶芸作品を制作し、大きさや形状がお題に近いほど高得点を獲得できるシステムになっています。
作品づくりの工程は、ろくろで形を整え、釉薬で色をつけた後、完成した作品をランウェイで披露するという流れです。
ランウェイパートでは、お盆に載せた作品を右手だけで支えながら歩きます。左右から煙が噴き出したり紙吹雪が舞ったりする妨害の中、お盆が傾かないようバランスを取り、作品を落とさずに歩き切ることを目指すアクション要素を取り入れました。
『陶（とう）』応募動画
ランウェイを踏破したら、完成作品の写真をゲーム内SNS「壺ッター」に投稿して楽しめるほか、実際にX（旧Twitter）で結果をシェアすることも可能です。
「壺ッター」に作品を投稿すると、実際に反響を受けられるのもユニークなところ
私はぷちコンの応募作品には外部サービスとの連携機能を組み込みたいという考えがあり、本作でもまずSNS共有機能から着手しました。「せっかくならゲーム内でも反応が見られた方が面白い」と考え、X（旧Twitter）のUIをUMG（Unreal Motion Graphics）で再現したのが「壺ッター」です。
友達に見せたら『売れるんじゃない？』って。お世辞でも嬉しい。 #陶 #ろくろゲーム #UE5ぷちコン pic.twitter.com/2Z5fgI7hBB
— toshiyuki（ぽちお） (@toshiyuki_wada) May 4, 2026
△実際に連携機能を使ってぽちおさんのXに投稿された画像
全体的なゲーム性はシンプルにまとめていますが、ランウェイで急に観客が湧き上がって踊り出すという「そんなわけないだろう」とツッコミを入れたくなるような世界観も大切にしています。
和の趣を感じる作風かと思えば、最後は突然派手やかなランウェイを歩くことに
――今回のテーマである「とう」から、どのようなプロセスで陶芸という題材に行き着いたのでしょうか。
初めはテーマを「投影」と解釈し、ペープサート（※）を用いた影絵ゲームを考案しました。「自機は影のある場所しか移動できず、ライトの位置を変えて影を伸ばすことでギミックを解く」という内容でしたが、ゲームプレイの幅が広がらずボツにしました。
※ 表と裏で絵柄が異なる紙人形を用いて、裏返しながら表情変化などを演出する人形劇
次に「塔（タワー）」を登っていくゲームも試作しましたが、うまくまとまりませんでした。3番目のアイデア出しで、ようやく現在の形に辿り着いた形です。「陶芸」の「陶」一文字だけで焼き物を意味することを知り、お題にぴったりだと考えました。
派手なゲーム性を持たせるのは難しいかもしれないという予感はありましたが、「どのような要素を足せばゲームとして成立させられるか」というチャレンジの意味も込めて、この路線で進めることに決めました。
また今回は、「Claude Code主導のゲーム開発を試す」という技術検証も兼ねたプロジェクトとなっています。
――今回、開発にClaude Codeを採用したきっかけは何だったのでしょうか？
普段の業務でもClaude Codeを利用する機会が多く、趣味の開発でも以前から活用していたため、今回も自然な流れで導入を決めました。AIに仕様書を読み込ませて開発を進めるワークフローは、すでに自分の中で確立されていたんです。
ただ、「最後までClaude Codeのみで作品を完成させる」という経験はなかったので、個人的には非常に大きな挑戦でした。
――これまでのぷちコンでも、そうした技術的なチャレンジを課してきたのですか？
毎回ではありませんが、「この技術は絶対に実践投入してみたい」「この要素を組み込んでみたい」といった縛りや挑戦を設けることが多いですね。それらの実践結果を自分のブログのネタに昇華するところまでを含めて、開発自体を楽しめるように心がけています。
ぽちおさんのブログでは、ぷちコンの各回における応募作のコンセプトや、技術的なこだわりを紹介した記事も投稿されている（画像はぽちおさんのブログ記事より引用）
――ゲームシステムや遊びを設計する上で、とくに念頭に置いたことは何ですか？
常に「ユーザーの納得度」を意識しました。たとえば、ろくろで粘土をこねるフェーズでは、破綻なく狙い通りに変形できなければストレスになりますし、釉薬につける際も思った通りに着色されなければ、ゲームとしての面白さが損なわれます。すべての挙動において、プレイヤーが「現実でもそうだよね」と納得できる手触りにすることを最重要視しました。
――確かに、ゲーム内の粘土の動きは非常にリアルでした。触れるとスッと上に伸び上がり、元の形状に戻そうとするとなかなか難しいといった感覚が丁寧に再現されています。
機械的に粘土を拡大・縮小させるだけでは面白さにつながりません。陶芸のシミュレーションとしての質を高めるため、手触りの調整にはかなりの時間を割きました。
ただ、どうしても詰め切れなかった部分もあります。本当は「両手で粘土を成形する」システムにしたかったのですが、マウス操作中心のゲームに両手の動きを落とし込むのが難しく、泣く泣く片手（1つのマウスカーソルのみ）の操作に妥協しました。
画面上に手のモデルを表示するかも悩んだのですが、片手だけだと違和感があり、かといって両手を表示させると「片方の手が動いていない」という新たな違和感が生じるため、現在の仕様に落ち着きました。
――リアルな粘土の変形を実現するために、どのようなロジックを組みましたか？
AIと壁打ちをする中で「体積保存ガウシアン変形」という技術を提案されました。3D Gaussian Splatting（3DGS）を活用し、物体の体積を維持しながら流動的な形状変化を制御する手法を指すようなのですが、初めて耳にする用語で、私自身に専門知識がなかったため、実装は全面的にClaude Codeの力に頼りました。
「粘土の質量は絶対に保つ」「底辺がろくろの幅をはみ出ないように変形する」といった要件をすべて仕様書にまとめ、Claude Codeに渡してコーディングさせています。
左クリックしながら粘土に触れると次第に幅が絞られていき、逆に右クリックで広げることができる
また、ろくろを回している最中に粘土の一か所を細くしすぎると、粘土の一部がちぎれて飛んでいってしまう仕様があるのですが、その破片を生成する仕組みもClaude Codeに実装してもらいました。
当初は粘土のバランスが崩れて遠心力に振り回され暴れ出す失敗演出を入れるつもりだったそう。実装上の都合により粘土がちぎれる演出に変更となった
――専門外の高度な技術を自力で探し当てて実装するのは困難ですから、まさにAIの強みが活きた部分ですね。
自分だけでは辿り着けない最適解を提案してくれるので、非常に心強いパートナーです。
ただ個人的な見解として、AIは「既存の情報をパッチワークのようにつなぎ合わせて構築する」能力には長けていますが、ゼロから新規のアイデアを生み出すのはまだ得意ではないと感じています。
そのため、本作の開発においてAIは主に壁打ち役として活用し、仕様を決める段階でのアイデア出しは私が行っています。スコアリングの仕組みを考案したのも、ランウェイを取り入れると決めたのも私です。「完成した器を持ってランウェイを歩く」というアイデアは、おそらくAIからは出てこないでしょうから（笑）。
――ぽちおさんご自身がプランナーとして立ち回り、実装面をAIにサポートしてもらう体制ですね。AIに渡す仕様書は、どのようなフォーマットで記述しているのでしょうか。
「GDD（ゲームデザインドキュメント）」という、AIが読みやすいマークダウン形式を採用しています。このフォーマット自体も、AIからの提案を受けて導入を決めました。
GDDの利点は、あらゆるAIモデルが読み込める汎用性の高さにあります。Claude Codeにコーディングをさせるだけでなく、ChatGPTに画面イメージを出力させたり、Geminiに「このイメージをもとにゲームのUIを構築して」と指示したりすることも可能です。
――スコアリングやランウェイといった要素も、仕様書を渡す段階で盛り込まれていたのでしょうか。
最初からすべての構想が固まっていたわけではありません。開発の途中でアイデアを思いつくたびに仕様書を書き換え、Claude Codeに実装し直してもらうというイテレーションを繰り返し、理想のシステムへと近づけていきました。
当初はスコア要素がなく、ただ粘土を成形して塗装するだけのゲームでしたが、遊びの幅を広げるために後から追加しました。ランウェイパートも同様に、ゲーム性を拡張するために付け足したものです。
実際にGDDで記述した仕様書の一部。使用する計算式などの情報がマークダウンでまとめられている。画像は各所に修正が加えられたバージョン3の仕様書で、文字数は合計約14,000字
――スコアリングの仕組みについて、具体的な算出方法をお聞きしてもよいでしょうか。
形状の判定については、完成品の断面を1か所だけ抜き出し、お題のシルエットとの一致率を算出しています。本作の陶芸システムでは必ず左右対称の形状になるため、360度どこを切っても同じ断面になります。つまり、断面をひとつ見るだけで作品全体の形状を正確に評価できるということです。
現実の陶芸では完全な左右対称にならないのが醍醐味でもありますが、そこまでリアルさを追求するとプレイヤーにとって判定が厳しすぎるため、遊びやすさを優先しました。
また、得点の算出は形状のみを参照しています。正解だけを突き詰めるのではなく、自由に色を塗る楽しさも味わってほしかったため、釉薬による着色は採点の対象外としました。
作品の評価は、形状・寸法の2種類の観点から算出される
――開発スケジュールについてもお聞かせください。Claude Codeを導入したことで、作業期間やプロセスに変化はありましたか？
開発スピードとイテレーションを回す速度は劇的に向上しました。題材が決まるまでに2種類ものプロトタイプを試作できたのは、Claude Codeを活用したからこそです。
従来のワークフローでは、企画書を書いてからプロトタイプが動くまでに何日もかかりました。そのため、仮に出来上がったプロトタイプが面白くなかったとしても、スケジュール的に別案を試す余裕がなく、そのまま進めざるを得ないケースが多々ありました。
その点、Claude Codeを使えば手早く試作できるため、「このアイデアは広げても面白くならなそうだ」と判断したら即座に次の案へ移行できます。非常にハイペースで検証を進めることができました。
――全体の作業期間はどのくらいでしたか？
締切の前日まで調整を行っていたため、トータルでは約30日かかりましたが、「ろくろでの成形」「釉薬による着色」「ランウェイ」というメインパートの基本実装自体は、わずか2日ほどで完了しました。UIの作り込みを度外視すれば、「2日賞」（※）にも応募できそうなペースでした。
※ UE5ぷちコンにおける表彰区分のひとつ。2日間で制作した作品が対象となる
ロジックを組んでゲームの根幹を確立するまでは早々に終えられたため、残りの期間はゲームとしての体裁を整える作業、すなわちUMGを用いたUI制作やアイコン素材の準備などに時間を費やすことができました。
30日と聞くと長く感じられるかもしれませんが、土日は家族と過ごす時間を大切にしているため、まとまった作業時間は確保できません。実作業時間は、平日の夜中に約2時間ずつと非常に限られていました。その短い時間を無駄にしないよう、「できている部分からどんどん進めていく」というスタイルで毎日開発に取り組んでいました。
Claude Codeで実装したプロトタイプ版。すでに粘土の変形ロジックは完成している
――Claude Codeが実装したコードに対して、不具合や改善点があればぽちおさんが手作業で修正していく流れだったのでしょうか。
「すべてをClaude Codeで作る」という技術検証がテーマでしたので、どんな些細な修正であってもAIに指示して修正させています。私自身は今回、C++のコードを一行も書いていません。
具体的なワークフローとしては、まずClaude Codeに実装内容を指示し、C++のクラスを生成させます。その後、エディター上でマテリアルを割り当てるといった作業を行えば、短時間で機能が実装できます。時間がかかったのは、Claude Codeが直接関与できないUMG周りの調整と、C++のメソッドをブループリントでつなぎ込む作業でした。
――ブループリントのつなぎ込みは、ぽちおさんご自身が担当されたのですか？
はい、そこは私が手作業で行いました。Claude Code側から「このブループリントを作成してください」とノードの名前まで厳密に指定されるので、その指示通りに呼び出していきます。ここで異なるブループリントを使ってしまうと、その後のClaude Codeの説明と辻褄が合わなくなってしまうため、仮に自分の直感と違っていたとしても、AIの指示に忠実に従うようにしました。
――その分、思考リソースをゲーム自体のブラッシュアップに割けるというわけですね。そのほかにご自身で担当された工程はありますか？
ビルド結果の検証は、「ユーザーの納得度」を確かめるために必ず自分で行っていました。実際にプレイして改善の余地がある箇所を見つけ、修正方針を文章でClaude Codeに伝えます。するとデバッグ用のコードを出力してくれるので、再度ビルドしてデバッグ結果を報告する……というサイクルを回して対処しました。
そうしてひとつの機能が完成したら、次の機能の実装へと移ります。ここまでのやり取りは、すべて1つのセッション内で完結させています。
――そのやり取りは、どのくらいの頻度で繰り返されたのでしょうか？
30日間で534回も行っていました。開発初期は実装指示を送る頻度が高いですが、終盤になるにつれて自力でUMGなどを組み込むフェーズに入るため、回数は徐々に減っていきます。最終的には実装指示ではなく、「このクラスの使い方は？」といった質問用途にシフトしていきました。
（画像は「Unreal Engine Meetup in Shizuoka」でぽちおさんが登壇した講演のスライド資料）
――Claude Codeの能力を最大限に引き出し、完成まで駆け抜けたのですね。逆に、Claude Codeをうまく活かしきれなかった、あるいは苦労した点はありますか？
最初はAIの出力に納得できない部分があっても、会話を重ねることで解決できたため、大きな難所はなかったと記憶しています。
強いて挙げるならば、受賞後に作品のブラッシュアップを行った際、スコアリングの根拠として「成形時のお題との一致率を示すヒートマップ」を実装したのですが、そのロジック構築には手間取りました。
お題と完成品の大きさが異なる場合、「形の一致度」のみを正確に比較するためには、まず両者の縮尺を揃えてから参照するロジックが必要になります。しかし、この実装意図を言葉で指示するのに非常に難航しました。私たちが当たり前のように使っている「縮尺」という漠然としたワードでは、AIが正しい意図を汲み取れず、想定外の解釈をされるケースしばしば起こり、厳密な定義に基づいた専門用語を用いて説明する必要がありました。
――人間同士なら文脈で伝わる何気ない単語でも、AIには正確に解釈されない場合があるのですね。
はい、AIに自分の思い描く正確なニュアンスを言語化して伝える方法を模索するのが大変でした。
ほかにも、完成品のサイズがお題と極端に離れている場合はスコアが下がるよう、「1つのUMGの中で、大きい方を基準（正）として比較する」という処理を実装したかったのですが、要件が複雑だったためかAIにうまく伝わりませんでした。
そこで、文字だけでなく図やイラストを描いて読み込ませてみたところ、案外すんなりと理解してもらえることが多かったです。文章では無意識のうちに省略してしまう細かな仕様も、図解であれば細部まで余さず伝達できるからだと思います。
――Claude Codeのほかに使用したツールがあれば教えてください。
アートワーク全般には主にGIMPを使用しました。また、焼き物を釉薬に浸した際に発生する水面の波紋はBlenderで制作しています。波を立てるためにはある程度の頂点数が必要だったため、適切にポリゴンを割ったメッシュを自作しました。
そのほか、ろくろやお盆のモデルもBlenderで自作しています。焼き窯やバケツは既存のアセットを活用し、ランウェイの会場も複数のアセットを組み合わせて構築しました。
――波紋のマテリアルもご自身で作成されたのですか？
マテリアルに関する基礎知識があったので、基本的には自作しています。一部Claude Codeに作成してもらったものもありますが、AIは直接マテリアルノードを組むことができないため、HLSLでカスタムノードを書いてもらっています。
（画像は「Unreal Engine Meetup in Shizuoka」でぽちおさんが登壇した講演のスライド資料）
――焼き物を釉薬に浸して色を付けるシーンでは頂点カラーが活用されていますが、理想的な実装に行き着くまで、AIとどのくらいのやり取りを交わしましたか？
これには自分でも驚いたのですが、頂点カラーの実装は一発で成功しました。釉薬での色付けには「塗る」アプローチと「浸す」アプローチがあるようで、どちらがロジック化しやすいかをClaude Codeに相談したところ、「浸す方がシンプルです」と提案され、そのまま実装を指示したら見事に機能したという流れです。
手数がかかったのは、先ほどお話ししたろくろの「体積保存ガウシアン変形」のほうですね。こちらは10回ほどやり取りを重ねて、ようやく現在の形に落ち着きました。
――ロジックの実装段階では、粘土などのモデルは仮のメッシュを使用していたのですか？
はい。最初はテスト用の動的メッシュに置き換え、マテリアルも仮のものを使用して動作検証を進めました。ロジックが固まった後で、粘土の濡れた質感や、焼き上がって白く変化する演出、釉薬が光を反射する表現などを乗せていきました。
焼き上げ後のマテリアル編集画面。こちらも頂点カラーで着色をしており、クリアコートでガラス感を生み出している
――Claude Codeに一任する部分と、ご自身で手を動かす部分の切り分けは、どのような基準で判断されたのでしょうか。
「ゲームの振る舞い」や「状態管理」といったシステムの中核を担う基底クラスは、Claude CodeにC++で記述してもらいます。そして、それを継承したブループリントの作成、パラメータの微調整、レベルデザインなど「エディター上で視覚的に操作する部分」は手作業で行うという明確なルールを設けました。
本作の例で言えば、マテリアルのロジック、釉薬の液面判定、頂点カラーの制御はC++（AI）で実装し、水面のメッシュデータや色彩の調整は私（手作業）が行っています。ランウェイに関しても、物理演算やバランス計算のロジックはClaude Codeに任せましたが、トレイの配置やカメラワークの演出などは私が調整しています。
プレイヤーが制作中の陶芸作品のActorにおける、ブループリント上に露出させた調整項目。このブループリントはレベル上に1つしか存在しておらず、ろくろの上・焼き窯の中・釉薬のバケツの上・ランウェイのトレイの上、スコア画面に登場する作品すべて1つのActorがレベル上を移動しながら、その場その場に合わせた状態で姿を変えている
――ここまで実装面のお話を伺ってきましたが、続いてビジュアル面についてお聞きします。遊びやすさを高めたり、ゲームを魅力的に見せたりするための工夫はありますか？
ステージ選択画面の構成は、見た目のかっこよさと世界観の統一を強く意識してデザインしました。巨大な回転台の上にさまざまな陶芸作品が並んでおり、台を回しながら挑戦するお題を選ぶUIになっています。画面左側には、お題の形状を示す二面図が表示されます。
この回転台は、実は成形パートで使用している「ろくろ」のモデルを巨大化させたものです。「ろくろの上で作品を選べたら面白いな」という発想から制作しました。回転スピードやカメラワークの気持ちよさにもこだわって調整しています。
ステージ選択画面。巨大なろくろを回転させながら、お題となる陶芸を選ぶ
実は、ろくろを流用しているのはステージ選択画面だけではありません。釉薬の種類を選択するシーンでも同じ仕組みを使っており、画角の外でろくろを回転させることで、画面上のバケツが左右にスライドして移動するようになっています。
釉薬の入ったバケツは真横に移動しているように見えるが、画面下ではろくろが回っているらしい
――陶芸というテーマの魅力を引き立てつつ、非常に統一感のあるUIデザインだと感じます。
UIはゲームの世界観と調和するデザインを心がけつつ、ユーザーフレンドリーな操作感になるよう設計しました。
たとえば、本格的な陶芸の作業工程を詳しく知っている方は少ないはずなので、プレイヤーが迷わないよう「現在どのフェーズにいるか」を示す進捗バーを画面上部に配置しました。さらに、画面右側にもテキストで現在の工程を明記しています。
画面右のフェーズ記載がない旧状態のゲーム画面
フェーズ記載を入れた現在のゲーム画面
ランウェイパートの操作性についても、ユーザビリティを追求しています。
開発初期の段階では、通路の両脇から吹き出す煙やフラッシュが焚かれるタイミングが分かりづらく、回避するのが難しいバランスでした。そこで、画面左側にトレイの角度や器の重心などをリアルタイムで可視化するウィンドウを配置し、さらに煙などが発生する直前に警告アイコンを出してプレイヤーに知らせる設計に変更しました。
重心表示が追加される前のランウェイ
重心表示を追加した現在のランウェイ
――ユーザー視点での「分かりづらさ」をUIで丁寧にサポートしていったのですね。その課題はどのように洗い出したのでしょうか。
家族や知人にテストプレイを頼んでフィードバックをもらうこともあるのですが、今回はスケジュールの都合もあり、自分自身で繰り返しプレイして問題点を割り出し、改善を加えていきました。
ユーザビリティを高めるための工夫をもうひとつ紹介させてください。ランウェイの開始時、マウスカーソルが画面中央からずれた位置にあると、スタートした瞬間にゲーム内のお盆が急激に傾き、理不尽に作品を落としてしまいます。これを防ぐため、開始直前に「確認ボタンを押すとスタート」というダイアログを挟みました。プレイヤーが確認ボタンをクリックすることで、自然とカーソルの初期位置が画面中央に誘導されるという仕掛けです。
こうした細かなブラッシュアップに十分な時間を割けるようになったのも、AI導入による開発スピード向上の恩恵だと思っています。
――ランウェイの操作も、マウスを左右に動かしてバランスを取るだけなので、直感的で遊びやすく感じられます。
歩くスピード自体は任意で調整できるのですが、クリック操作を伴うとプレイヤーの手に力が入りすぎてしまい、繊細なバランス操作が難しくなると考えました。そのため、純粋に「マウスを動かすだけ」で遊べるシステムにこだわっています。
煙や紙吹雪などのギミックをすべて華麗に避け続けてゴールすることも可能ですが、仮に避けられなくても、しっかりとバランスさえ立て直せばクリアできる難易度にしています。
そのほか、アート面で最も注力したと言えるのがランウェイの映像演出です。カメラの移動速度に合わせてライトをコントロールしたり、開始時にカメラが被写体にグッと寄ったりするシネマティックな演出は、実はすべてブループリントで制御しています。
――この映像をすべてブループリントで構築しているとは驚きです。シーケンサーも使用していないんですね。
シーケンサーはプロパティが多すぎて操作の学習コストが高く思えてしまい、「ブループリントのロジックで制御すれば解決できるじゃん！」というプログラマー気質の考えから、こちらを採用しています。同じプログラマーならこの感覚に共感してくれるはずだと思い、「UE5ぷちコン友の会」でもよくこの話をするのですが、なぜか誰からも同意を得られず、もっぱら笑い話にされています（笑）。
ランウェイ冒頭シーンの映像を実装したブループリント
ステージのビューポート。ライトやカメラをコントロールする為に、ステージ全体をActorとして定義している。ブループリントでライトの照度や向きを調整しつつ、スプラインに沿わせてカメラを動かしている
――以前お話ししたぷちコン参加者の方も「UE5ぷちコン友の会」のことを語られていました。皆さんとても楽しそうに活動されているのが伝わってきます。
お互いに「受賞おめでとう！」「これすごかったね！」と称え合う関係性が大きなモチベーションになっていますし、ぷちコン終了後はUEのエディター画面を見せ合いながら「ここの処理はどうやって実装したんですか？」といった開発談義も行われるんです。
C++を覚えたい人に向けた有志の勉強会が開かれたこともありますし、実は私にシーケンサーの使い方を教えるための勉強会を開いてもらったこともあります（笑）。
ともあれ、コンテストの参加者同士でこれほど密接な交流関係が築かれているコミュニティは、ゲーム領域に限らずなかなか珍しい光景ではないかと思います。
ただ、古参メンバーが固定化してしまうと、新規の方がどうしても参加をためらってしまう懸念もあるので、よりオープンで参加しやすい場にしていきたいですね。私自身とても素晴らしいコミュニティだと感じているので、参加し続けられる限りは大切に守っていきたいですし、この記事をきっかけにより多くの方に知っていただけると嬉しいです。
――今後の展望についてお聞かせください。『陶』を正式にリリースするご予定はありますか？
受賞後にもブラッシュアップを重ねているため、安定性を見れば十分リリース可能な状態には仕上がっていますが、現状は未定です。
今はぷちコンの熱が冷めやらぬうちに、以前から着手していた別プロジェクトの開発を進めているのですが、そうこうしているうちにすぐ次回のぷちコンの開催時期が近づいてくるんですよね。また忙しい日々が始まりそうです。
【告知】
Unreal Engine学習向けコンテスト
『第26回 #UE5ぷちコン』 開催決定！開催期間：7月17日(金)～8月30日(日)
テーマ発表：7月17日(金)12:00！ぜひご参加ください✨https://t.co/G3ABwElwUA pic.twitter.com/PZ7rPgJYpR
— ヒストリア広報部 (@historia_Inc) June 19, 2026
△「第26回ぷちコン」も開催決定！
――もし次回のぷちコンでもClaude Codeを導入するとしたら、今回の経験を踏まえて挑戦したいことや改善点はありますか？
仕様書をさらに精密に作り込み、ループエンジニアリングを活用して開発を自動化し、本気でぷちコンの「2日賞」を狙ってみたいですね。開発の全過程をSNSでリアルタイムに公開しながら「2日間でここまで行けるよ！」という事例紹介のように記録を残してみるのも面白そうです。
――UEの今後のアップデートや、AI技術の発展について期待している点はありますか？
やはりMCP（Model Context Protocol）の動向には強く期待しています。現状でもUEは調べれば大抵のことが実現できるほど機能が充実していますが、MCPで開発ワークフローがどこまで進化するのか、非常に注目しています。
――ありがとうございました。今後のご活躍も応援しています。
大阪生まれ大阪育ちのフリーライター。イベントやeスポーツシーンを取材したり懐ゲー回顧記事をコソコソ作ったり、時には大会にキャスターとして出演したりと、ゲーム周りで幅広く活動中。
ゲームとスポーツ観戦を趣味に、日々ゲームをクリアしては「このゲームの何が自分に刺さったんだろう」と考察してはニヤニヤしている。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁（のざわ くにひと）氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
CEDECで行われた講演のレポートをまとめました。
UNREAL FESTで行われた講演のレポートやインタビューをまとめました。
GDCで行われた講演などのレポートをまとめました。
CEDEC+KYUSHUで行われた講演のレポートやイベントレポートをまとめました。
GAME CREATORS CONFERENCEで行われた講演のレポートをまとめました。
Indie Developers Conferenceで行われた講演のレポートやインタビューをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドやレポートなどをまとめました。
東京ゲームショウで展示された作品のプレイレポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームダンジョンで展示された作品のプレイレポートをまとめました。
日本と文化が近い中国でゲームを展開するための知見を、LeonaSoftware・グラティークの高橋 玲央奈氏が解説。
インディーゲームパブリッシャーの役割や活動内容などを直接インタビューします。
