Developer’s Eye Vol.9 Firewatch

トランシーバーだけで関係性を描く、対話システムの発明

■ ゲーム概要
■ 購入先・プレイ環境（2026年7月4日時点）
■ 公式PV
■ 開発者が注目した”一点突破の面白さ”
■ その面白さを開発者視点で分解する
■ 設計思想の推測（開発者視点）
■ 制作に応用できるポイント（Unityで再現する場合の構造案も）
■ まとめ：このゲームは”作り手の教材”である
■ 参考文献（一次情報）
■ 著作権表記

■ ゲーム概要

Firewatch

開発：Campo Santo
ジャンル：一人称ミステリーアドベンチャー
プレイ時間：4〜6時間
特徴：主人公とその上司の会話が、すべてトランシーバー越しの音声だけで進む一人称ミステリー
開発エンジン：Unity（Unity 4で開発を始め、開発中にリリースされたUnity 5のベータ版に早期からアクセスして移行。SECTR、Marmoset Skyshop、Amplify Color、NGUI、Playmakerなど複数のUnity拡張を組み合わせて制作）

■ 購入先・プレイ環境（2026年7月4日時点）

販売先	リンク
Steam	store.steampowered.com/app/383870
Microsoft Store（Xbox / PC）	xbox.com/ja-JP/…/firewatch

Xbox Game Pass：対象（Premium・Ultimate に含まれる） Xbox公式ストアページ（日本版）で「Xbox Game Pass Premium、Ultimate でクラウドプレイ可能なゲームが含まれています。Xbox Game Pass Essential でストリーミングするには、ゲームの購入が必要です。」の表示を確認済みです（2026年7月6日再確認）。Essentialプランのみ購入が必要です。

■ 公式PV

「Firewatch – September 2016 Trailer」。開発元Campo Santoの公式サイト（firewatchgame.com/media/）に掲載されているトレーラーです。

■ 開発者が注目した”一点突破の面白さ”

物語を伝える手段を、トランシーバー越しの会話”だけ”に絞り込む。

Firewatchは、主人公ヘンリーと上司デライラの関係を、直接顔を合わせることのないトランシーバー越しの会話だけで描く。ディレクターのJake Rodkin氏はIBTimesの取材で、「基本的に、世界の中で何か気になるものを見つけたら、無線で上司に話しかけられる」という仕組みが、ゲーム全体の対話設計の核になっていると説明している。

■ その面白さを開発者視点で分解する

● ① Twine（テキストゲーム制作ツール）で人物像を固めてから3Dに落とし込む

Film Storiesの記事によれば、Firewatchの導入部はもともと、キャラクター設定資料の代わりとしてTwineで内部的に作られたテキストゲームだった。共同創業者のSean Vanaman氏は、ヘンリーがどんな人物かをチーム全体に理解してもらうには、資料を読ませるより実際に「プレイさせる」方が良いと考えたという。この手法はのちに製品版の導入シーケンスとしてそのまま採用されている。

● ② プレイヤーに”ヘンリーとして”選ばせる設計

同記事内でRodkin氏は、「あなたは特定の人生を歩んできた特定の人物をプレイしている」と述べている。選択肢の分岐点は、プレイヤー自身の価値観ではなく、ヘンリーというキャラクターの人物像を体現するように設計されている。妻ジュリアの転職の場面などは、プレイヤーに”ヘンリーならどうするか”を選ばせることで、キャラクターへの没入を作っている。

● ③ 予算規模に応じてUnityを選ぶという現実的な判断

MCV/DEVELOPの取材でRodkin氏は、10人程度の新設スタジオという規模と予算を踏まえ、Unityが「唯一理にかなう選択だった」と語っている。開発中にリリースされたUnity 5のベータ版に早期アクセスできたことで、レンダリングパイプラインの改善など、細部の使い勝手が大きく向上したという。

● ④ 独自ツールを内製しつつ、既存資産も活用するバランス

firewatchgame.com公式サイトの解説によれば、SECTR（シーンストリーミング）やMarmoset Skyshopなど複数のUnity拡張を活用しつつ、対話・イベント管理は自社製のツールをプログラマーが内製している。既製品と自社開発を適材適所で組み合わせる姿勢がうかがえる。

■ 設計思想の推測（開発者視点）

検証できる発言から見えてくる Campo Santo の設計思想は、次のように整理できる。

対話手段をあえて制限する：直接対面ではなく無線越しの声だけに絞ることで、想像力を働かせる余地を残す
キャラクター設定を”読ませる”のではなく”プレイさせる”：資料ではなくプロトタイプでチーム全体の理解を揃える
予算規模に見合った技術選定をする：予算と人数に対して現実的なツールを選び、その中で最大限の作り込みをする

■ 制作に応用できるポイント（Unityで再現する場合の構造案も）

● ① 対話手段を一つに絞ってみる

会話システムを設計する際、あえてチャンネルを一つ（音声のみ、テキストのみなど）に絞ることで、想像力に訴える余白が生まれる。Unityであれば、音声再生とテキストログ表示を分離しておき、映像的な演技を省いた設計を試す価値がある。

● ② キャラクター設定をプレイ可能なプロトタイプにする

小規模チームでは、キャラクター設定資料をドキュメントで共有するより、Twineなどの簡易ツールで「体験できる形」にしてチームに共有すると、認識のズレを減らせる。

● ③ チーム規模に見合ったエンジン選定をする

大手スタジオの事例をそのまま真似るのではなく、自分たちの人数・予算・スケジュールに見合った技術選定を優先する。Unityのように情報量が多く、アセットストアが充実したエンジンは、小規模チームほど恩恵が大きい。

■ まとめ：このゲームは”作り手の教材”である

Firewatch は、「対話の手段を無線越しの声だけに絞る」という制約から、逆に深い関係性を描き出したゲームだ。キャラクター設定をプレイ可能な形で固める手法、身の丈に合った技術選定など、限られたリソースの中で密度の高い体験を作るための判断の積み重ねが随所に見られる。

■ 参考文献（一次情報）

■ 著作権表記

© Campo Santo / Panic / Firewatch
本記事内の開発者コメントは上記一次情報を要約・翻訳したものであり、逐語引用は最小限（15語未満・出典1件につき1箇所まで）に留めています。