個人制作発表会ガイド

2026年5月29日2026年11月1日

このガイドは、Unityの個人制作で作った作品を、PowerPointと実演を使って紹介するための手引きです。提出前の準備 → 発表 → 試遊 → 振り返りの順に進めます。制作全体の目標は制作フェーズの案内で確認してください。

まず提出前の準備とチェックリストを確認し、当日は発表の流れと試遊の流れを使います。実施日・提出先・締切・発表時間は授業の案内を優先してください。

1. 提出前の準備：作品・資料・予備動画をそろえる
2. 発表版を作り、配布する
3. 発表：作品と、自分が考えたことを伝える
4. 発表で伝えてほしいこと
5. 試遊：他の人が説明を読んで遊べるか確かめる
6. 試遊後：感想を整理して次の改善へつなげる
7. 提出前チェックリスト
8. 関連する教材

提出前の準備：作品・資料・予備動画をそろえる

発表用に次のものを用意します。発表直前まで機能を増やさず、ビルドと動作確認、資料作成、練習の時間を確保しましょう。

実行できる作品：Windows向けビルドの出力フォルダー一式をZIPにしたもの。別のWindows PCでも主要な操作を確認します。
GitHubリポジトリとReleaseのURL：講師が閲覧でき、発表するビルドに対応するソースの版が分かる状態にします。非公開の場合は、授業で指定された講師アカウントを招待し、閲覧できることを確認します。
README：作品の概要、起動・操作方法、必要な環境、完成条件と確認結果、既知の不具合、使用素材・アセットの一覧をまとめます。タイトル画面やBGMなどを一律の完成条件にせず、企画時に決めた主要な流れが動くかで確認します。
PowerPointの発表資料：5〜8枚程度を目安に、作品の目的・特徴・工夫・問題への対処・振り返りをまとめます。使用素材の一覧は付録へ載せるか、READMEの一覧へリンクします。
予備のプレイ動画：実演が止まったときに切り替えられるよう、代表的な操作を1〜3分程度のMP4にして用意します。発表用PCで映像と音声が再生できることも確認します。

スライドの具体的な構成は個人制作発表資料の作り方を使います。PowerPointの操作が必要な場合はウェブ版PowerPointの使い方を参照してください。使用技術などの詳細は付録にまとめられます。使用素材・アセットは一覧の記録項目に沿ってREADMEへ整理し、スライドの付録またはリンクで示します。

制作中のIssue・Slack・PR・コミット履歴から、発表で使う工夫や問題解決の例を選びます。すべての作業ログやエラーメモをREADMEへ転記する必要はありません。必要な記録へのリンクと代表的な学びをまとめれば十分です。

発表版を作り、配布する

ここでは、発表・試遊をWindows PCで行う場合を説明します。授業で別の環境を指定された場合は、その指定に合わせてください。ビルドは制作の早い段階で一度試し、以下は提出前の最終確認として行います。

発表するソースの版を確定する：必要な変更とビルド設定をコミットし、Pushします。チーム制作では必要なPRをmainへ統合します。ビルド対象のコミットを記録し、作業途中の変更が混ざっていないことを確認します。
Unity 6でビルドする：File → Build ProfilesでWindows向けの設定を開きます。使用するシーンがScene Listに含まれ、起動するシーンが先頭になっていることを確認し、Buildを実行します。
出力フォルダー一式を確認する：ゲーム名.exe、ゲーム名_Data、UnityPlayer.dllなど、実行に必要なファイル・フォルダーをまとめて扱います。exeだけを取り出して配布しないでください。
ZIPを別PCで試す：出力フォルダー一式をZIPにし、別のWindows PCへ渡して展開します。exeを起動し、主要な操作・終了条件・再スタートなど、決めた完成条件を確認します。
確認したコミットへタグを付ける：GitHub Desktopなどで、ビルドに使ったコミットにv1.0.0などのタグを付け、Pushします。新しいコミットが増えていても、タグは確認した版へ付けます。
GitHub Releasesへ登録する：リポジトリのReleasesから新しいReleaseを作成し、先ほどの既存タグを選びます。タイトル・確認した動作・既知の不具合を記載し、試したZIPを添付して公開します。自動生成されるSource codeのZIPと、実行用ZIPは別のものです。
配布内容を最終確認する：ReleaseのURLをREADMEと提出先へ記載します。添付した実行用ZIPをダウンロードして展開・起動し、発表版を取り違えていないことを確かめます。

不具合を直した場合は、修正したソースを確定して再ビルド・再テストし、新しい版として登録します。発表後の改善は作業ブランチで続けられます。発表時点の状態は、タグとReleaseで確認できます。

詳しい操作はGitHubを使ったUnityアプリのリリース版作成、画面項目はUnity 6のWindowsビルド設定とGitHub公式のRelease作成手順を参照してください。

補足：Macで制作している場合・MonoとIL2CPP

Unity 6でも、Windows向けのScripting BackendにはMonoとIL2CPPがあります。授業の発表のためだけに、既に動いている設定をIL2CPPへ変更する必要はありません。

Mac上でWindows向けにビルドする場合は、対応するBuild SupportとMonoの設定を確認します。Windows向けIL2CPPビルドはWindows環境で行います。Macの.appをWindowsへ渡しても実行できないため、Windows向けビルドを用意し、実際のWindows PCで確認してください。環境がそろわない場合は早めに講師へ相談します。

IL2CPPの概要／IL2CPPのビルド環境と制約

発表：作品と、自分が考えたことを伝える

発表は8〜10分を目安に、次の順で進めます。質疑応答をこの時間に含めるかは授業の案内で確認してください。スライドを読み上げるだけでなく、画面と実演を使い、何を作り、なぜその方法にしたかを伝えましょう。

内容	時間の目安	伝えること
作品の概要	1分	誰向けに何を作ったか。目的・操作・終了条件。
制作目的と工夫	2分	取り組んだ理由、採用した方法、その効果。
困ったことと解決	1分30秒	起きた問題、調べたこと、対応と確認結果。
実演または動画	2〜3分	主要な操作を見せる。実演が止まったら予備動画へ切り替える。
制作過程の紹介	1分	代表的な履歴や記録から、段階的に作った流れを説明する。
まとめ	30秒〜1分	学んだこと、残る課題、次に改善したいこと。

制作過程は、GitHubのコミット履歴やIssue・PR、スクリーンショットから代表例を選んで示します。履歴を最初から全部たどったり、発表中に復元操作を実行したりする必要はありません。AIや参考記事を使った箇所も、自分が採用した理由と確認した結果を説明できるようにします。

中間発表を行う場合は、確認できたこと・制作中の部分・次に取り組むことを分けて伝えます。最終発表では、企画時に決めた完成条件について、できたことと残る課題を紹介します。まだ動いていない部分がある場合は、現状と試したことを伝え、範囲や仕上げ方を講師と相談しましょう。

発表時に用意するもの：PowerPoint・実行用ファイル・予備動画。制作過程を説明するときだけGitHubや記録を開きます。Unity EditorとGitHub Desktopは、説明や確認に必要な場合に使います。試遊は配布するビルドを基本にします。

発表で伝えてほしいこと

発表では、作品の出来栄えに加えて、制作中に考えたことや工夫、困ったときの対応を紹介してください。うまくいかなかった部分も、試して分かったことや次に取り組むこととして伝えて構いません。

紹介する内容	伝えるときのヒント
作品の動作	実演や動画で、主要な操作と遊び方を紹介します。
できたことと残る課題	企画時に目指したこと、動作を確認できたこと、これから取り組むことを伝えます。
制作の進め方	期間内に何から取り組み、範囲や優先順位をどう調整したかを紹介します。
工夫や問題への対応	使いやすくするための工夫や、困ったときに調べたこと・試したこと・分かったことを紹介します。
制作を通して学んだこと	選んだ方法の理由、学んだこと、次に活かしたいことを自分の言葉で伝えます。

コミット履歴やIssue・メモは、自分がどう進めたかを思い出し、説明するために使います。回数や時刻をそろえるために記録を作り直す必要はありません。実際に取り組んだことから、伝えたい例を選んでください。

試遊：他の人が説明を読んで遊べるか確かめる

試遊では、全員が他の人の作品を遊び、自分の席は無人で遊べる状態にします。作品・操作説明・必要な入力機器をそろえ、起動方法と再スタートの方法が分かるようにしてください。

席と番号を決める：参加者と作品の席に番号を付けます。最初は自分の番号より1つ先の席へ移動し、最後の番号の次は①へ戻ります。
1回8分で試す：最初の2分で操作説明・READMEを確認し、残り6分で遊びます。興味がある人はコミット履歴も参照できますが、全履歴を読む必要はありません。
次の作品へ移る：合図で一度自席へ戻り、次の人が開始できる状態へリセットします。その後、前回より1つ先の作品の席へ移動します。自分の作品は試遊対象に含めません。

全作品を試す場合は、参加人数−1回です。12人なら11回で、試遊だけで88分かかります。移動・リセット・感想記入・休憩は別に確保します。授業時間に収まらない場合は、講師が回数と組み合わせを決め、全作品を回ることを必須にしません。

図は12人で全作品を回る例です。図中の「READMEとコミット履歴を読む」は、まず操作説明を確認し、履歴は必要に応じて見る時間として使ってください。実際の人数・回数・移動先は当日の案内に合わせます。

試遊後：感想を整理して次の改善へつなげる

試遊した作品には、作品名と「良かった点」「困った操作・改善してほしい点」を残します。名前は任意です。「難しかった」だけでなく、どの場面で何が起きたかを書くと、制作者が確かめやすくなります。

記入例：作品名：Dungeon Escape／良かった点：鍵を取ったときの音で成功が分かる／困った点：2面の右端でジャンプすると足場に届きにくい。

制作者は意見を整理し、不具合・使いにくさ・追加要望を分けて、取り組むものをIssueへ登録します。すべてを採用する必要はありません。再現方法、期待する動作、確認方法を残し、次の改善へつなげましょう。

提出前チェックリスト

□ 配布するZIPを別PCで展開し、主要な操作と再スタートを確認した。
□ Releaseのタグ・ソースのコミット・実行用ZIPが同じ版に対応している。
□ GitHubとReleaseを講師が閲覧でき、提出先へURLを記載した。
□ READMEの起動・操作方法、完成条件と結果、既知の不具合が実際の作品と合っている。
□ PowerPointを作成し、発表用PCで表示を確認した。
□ 予備のMP4動画を用意し、発表用PCで映像と音声を確認した。
□ 実演・資料・動画の切り替えを含め、時間を測って1回以上練習した。
□ 試遊する人が、操作説明を読んで開始・再スタートできる。
□ 使用素材・アセットの一覧に、素材名・使用箇所・作者や配布元・URL・ライセンス・必要なクレジットを記録し、指定の表記と掲載場所を確認した。自作素材も作成者が分かる。
□ PowerPointの付録またはリンクから、使用素材の一覧を参照できる。

補足：Unity Recorderで予備動画を録る

動画はRecorderなどで作成できます。Recorderを使う場合は、Package ManagerのUnity Registryから導入し、Window → General → Recorder → Recorder Windowを開きます。