GeminiとGitHub Copilotとわたし

ワンピース（実写）の感想

2026.03.13

#日記

ワンピースの実写版、SNSなどで見かけはするし、批判も見るけどどうなんだろうと見てみたら、面白いですね。

何よりも、かなり原作リスペクトを感じるというか、日本の実写ドラマ化よりも原作に忠実というか、あのコマをそのままのカメラワークやポーズでしっかり表現してるのがかなり好感が持てました。すごい。

まだ三話くらいしか見てませんが、吹き替えもすごい良いですね。

田中真弓さん、実写に合わせて声を変えてるのがよくわかるし、もともとあんまり声を変えるタイプの声優さんじゃないのに、演じ分けがすごいなーと思いました。長年演じてきたルフィに引っ張られず、ワントーン低いルフィを演じられてるのがすごい。

ゾロもかっこいいし、俳優さんたち、ちょっと似てるというか…不思議とマッチしてくるもんですね。

本編を見る前は衣装がどうしてもコスプレ感あるなーと思ってたけど、気にならなくなっていく。バギーもいいですが、コビーがとってもいいですね。

Netflixでのみ見られると思いますが、おすすめです。

近況報告

2026.03.01

#日記

ワケあって、今年から独立することになったんですが、あまりにも急にやらなければならなくなったので、バタバタしていました。
まぁ、独立することになるのは予測できたものの、まったく先が見えない状態だったので精神的にもかなりしんどかったというのが正直なところです。

具体的な実在の名称は控えますが…
半年以上前から入社の話をしていた開発会社があったんですが、今の職場に退職する意向を伝えてから連絡が途絶え、そこから細切れに連絡は頂けるものの、採用はするが採用計画含め事業計画を通すのに苦労しており、なかなか話が進められないという状況のようです。

辞めるといった手前、今の職場からは離れることにしましたが、半端になってしまったプロジェクトを業務委託として継続させていただけることになりました。

また、別口でもお仕事が頂けて、とりあえずスタートとしては悪くはない状況にまで落ち着きました。

で、これまで作ってきた個人プロジェクトは、基本的な作りは同じものの、もう少しスケールダウンした別プロジェクトに移行することにしました。

受託だけでなく、これまでの経験も活かしながら、自ら販売する立場として頑張っていこうと思います。
個人開発自体継続はしますが、この数か月は以上のような理由からプライオリティは下げて動くことになりそうです。

いずれにしてもゲーム開発のお仕事をいただけているので、技術を蓄えながら、より良いものをリリースできたらと思います。

【Day11~15】フィールドアセット作り

2026.02.15

#Blender #Godot

パレットテクスチャでの作成を試みたんだけど、やっぱチープになりがちだな。
それとどうしてもPS2時代の3Dモデラ―なので、マテリアル数やテクスチャサイズ、ポリゴン数が気になってしまってまともに進まない。

これは本当によくない。

会社に勤めている時に、若手の3Dアーティストがポリゴン数もマテリアル数もテクスチャサイズもふんだんに使いまくって発狂しそうになった。
でも、きっとそういう自由な発想や表現を最優先にして制限を気にすることなく物を作るってのも大事なんだろうなって思う。

これまで作ったアセットはいったん破棄し、再度作り直すことにする。

Blender⇔Godotのワークフローもある程度できてきているし、何よりBlenderでのモデリングの感覚を取り戻した感じはとてもあるから、決して無駄にはならなかった。
パーツで作っていくことや、マテリアルをある程度使いまわす方法は相変わらずスタンダードな方法だし、極端に制限に囚われず、できる限りでやっていこう。

【Day10-2】Blenderワークフローを組んでいくつかモデルを作った。

2026.02.09

#Blender #Godot

どうでもいいけど毎回動画自動再生にしててこのサイト重いね。

なので任意再生にしますね。

Blenderでいくつかモデリングしつつ、木が重いと思って一生懸命作ってる様。
表現的にも悪くはないんだけど、ちょっとポリゴン数多いかもしれないね。
最適化しよう。

【Day10】蛇足：Blender側のワークフロー

2026.02.08

#Blender #Godot

Godotのインポートスクリプトでコリジョンを自動設定するために、Blender側でも扱いやすくするためのBlenderスクリプト。

Python

import bpy
from bpy.app.handlers import persistent

# 🛡️ ハンドラ関数の定義
@persistent
def auto_setup_collision_viz(scene):
    """
    シーンの更新を監視して、-col配下のメッシュを自動でワイヤー表示にする 🕵️
    """
    # シーン内の全オブジェクトをループして条件チェック
    for obj in bpy.data.objects:
        # 親がEmptyであり、かつ名前に "-col" が含まれているか確認 📦
        if obj.parent and obj.parent.type == 'EMPTY' and obj.parent.name.endswith("-col"):
            
            # メッシュオブジェクトのみ対象 💎
            if obj.type == 'MESH':
                # 既に設定済みならスキップして負荷を軽減 ⚡
                if obj.display_type != 'WIRE' or not obj.show_in_front:
                    obj.display_type = 'WIRE'
                    obj.show_in_front = True
                    print(f"✨ [Auto] {obj.name} をコリジョン表示に切り替えました 🔧")

# 📋 ハンドラの登録解除（二重登録を防ぐ）
def register():
    if auto_setup_collision_viz not in bpy.app.handlers.depsgraph_update_post:
        bpy.app.handlers.depsgraph_update_post.append(auto_setup_collision_viz)
        print("🚀 コリジョン監視ハンドラを登録しました！")

def unregister():
    if auto_setup_collision_viz in bpy.app.handlers.depsgraph_update_post:
        bpy.app.handlers.depsgraph_update_post.remove(auto_setup_collision_viz)
        print("🛑 コリジョン監視ハンドラを解除しました。")

# 🚀 実行
if __name__ == "__main__":
    register()

import bpy
from bpy.app.handlers import persistent

# 🛡️ ハンドラ関数の定義
@persistent
def auto_setup_collision_viz(scene):
    """
    シーンの更新を監視して、-col配下のメッシュを自動でワイヤー表示にする 🕵️
    """
    # シーン内の全オブジェクトをループして条件チェック
    for obj in bpy.data.objects:
        # 親がEmptyであり、かつ名前に "-col" が含まれているか確認 📦
        if obj.parent and obj.parent.type == 'EMPTY' and obj.parent.name.endswith("-col"):
            
            # メッシュオブジェクトのみ対象 💎
            if obj.type == 'MESH':
                # 既に設定済みならスキップして負荷を軽減 ⚡
                if obj.display_type != 'WIRE' or not obj.show_in_front:
                    obj.display_type = 'WIRE'
                    obj.show_in_front = True
                    print(f"✨ [Auto] {obj.name} をコリジョン表示に切り替えました 🔧")

# 📋 ハンドラの登録解除（二重登録を防ぐ）
def register():
    if auto_setup_collision_viz not in bpy.app.handlers.depsgraph_update_post:
        bpy.app.handlers.depsgraph_update_post.append(auto_setup_collision_viz)
        print("🚀 コリジョン監視ハンドラを登録しました！")

def unregister():
    if auto_setup_collision_viz in bpy.app.handlers.depsgraph_update_post:
        bpy.app.handlers.depsgraph_update_post.remove(auto_setup_collision_viz)
        print("🛑 コリジョン監視ハンドラを解除しました。")

# 🚀 実行
if __name__ == "__main__":
    register()

基本的にはBlenderでは描画を変えるだけで特に何をするわけでもない。
これで編集中に何がコリジョンで何が描画されるのか見た目で判断できるので制作の邪魔にならない。

使い方と注意点

登録方法: Blenderの「Text Editor」にこのコードを貼り付け、「Run Script」を一回だけ押す。
動作:
- メッシュを -col という名前のEmptyの子にした瞬間にワイヤー表示になる。
- 逆に、普通のEmptyの名前を後から -col に変更しても、即座に中身がワイヤー化される。
保存: このスクリプトが含まれた .blend ファイルを保存し、次回開いた時にも自動で有効にしたい場合、テキストエディタのメニューから Text > Register（登録） にチェックを入れる。

次にGodotのインポートスクリプト。

GDScript

# 🛠️ カスタム・ブレンダー・インポーター
# 表示オブジェクトを維持しつつ、コリジョンを自動構成します
@tool
extends EditorScenePostImport

func _post_import(scene: Node) -> Object:
	_iterate_nodes(scene, scene)
	return scene

func _iterate_nodes(node: Node, root: Node):
	if node == null:
		return

	# 🔍 名前が "-col" で終わるノードを検索
	if node is Node3D and node.name.ends_with("-col"):
		_process_custom_collision(node, root)
		# 変換後はこの枝の走査を終える（内部で再構築されるため）
		return 

	for child in node.get_children():
		_iterate_nodes(child, root)

func _process_custom_collision(source_node: Node3D, root: Node):
	var parent = source_node.get_parent()
	if not parent:
		return

	# 📦 1. 新しい StaticBody3D を作成（ここが表示と物理の親になる）
	var static_body = StaticBody3D.new()
	static_body.name = source_node.name.replace("-col", "")
	static_body.transform = source_node.transform
	
	parent.add_child(static_body)
	static_body.owner = root
	
	print("✨ [CustomImport] 物理・表示統合ノードを生成: ", static_body.name)

	# 🔄 2. 子ノード（メッシュ等）の処理
	for child in source_node.get_children():
		# 物理形状 (CollisionShape3D) の生成
		if child is MeshInstance3D:
			var mesh = child.get_mesh()
			if mesh:
				# コリジョン形状の作成
				var col_shape = CollisionShape3D.new()
				col_shape.shape = mesh.create_convex_shape()
				col_shape.transform = child.transform
				col_shape.name = "Collision_" + child.name
				
				static_body.add_child(col_shape)
				col_shape.owner = root
				
				child.get_parent().remove_child(child)
				
				print("  ✅ 物理と表示をセットしました: ", child.name)

	# 🗑️ 3. 役割を終えた元の Empty のみを削除
	source_node.queue_free()

# 🛠️ カスタム・ブレンダー・インポーター
# 表示オブジェクトを維持しつつ、コリジョンを自動構成します
@tool
extends EditorScenePostImport

func _post_import(scene: Node) -> Object:
	_iterate_nodes(scene, scene)
	return scene

func _iterate_nodes(node: Node, root: Node):
	if node == null:
		return

	# 🔍 名前が "-col" で終わるノードを検索
	if node is Node3D and node.name.ends_with("-col"):
		_process_custom_collision(node, root)
		# 変換後はこの枝の走査を終える（内部で再構築されるため）
		return 

	for child in node.get_children():
		_iterate_nodes(child, root)

func _process_custom_collision(source_node: Node3D, root: Node):
	var parent = source_node.get_parent()
	if not parent:
		return

	# 📦 1. 新しい StaticBody3D を作成（ここが表示と物理の親になる）
	var static_body = StaticBody3D.new()
	static_body.name = source_node.name.replace("-col", "")
	static_body.transform = source_node.transform
	
	parent.add_child(static_body)
	static_body.owner = root
	
	print("✨ [CustomImport] 物理・表示統合ノードを生成: ", static_body.name)

	# 🔄 2. 子ノード（メッシュ等）の処理
	for child in source_node.get_children():
		# 物理形状 (CollisionShape3D) の生成
		if child is MeshInstance3D:
			var mesh = child.get_mesh()
			if mesh:
				# コリジョン形状の作成
				var col_shape = CollisionShape3D.new()
				col_shape.shape = mesh.create_convex_shape()
				col_shape.transform = child.transform
				col_shape.name = "Collision_" + child.name
				
				static_body.add_child(col_shape)
				col_shape.owner = root
				
				child.get_parent().remove_child(child)
				
				print("  ✅ 物理と表示をセットしました: ", child.name)

	# 🗑️ 3. 役割を終えた元の Empty のみを削除
	source_node.queue_free()

GodotにはEmptyを自動的にコリジョン形状として扱う機能があるはずなんだけど、だいぶ前から完全に死んでるっぽいので、特定のEmptyの子をすべてコリジョン形状として扱うスクリプトとした。

注意

コリジョン形状をメッシュそのままを使うので、複雑な形状は重くなる。
StaticBody3Dしか扱わないようにしてるので、RigidBody3DやArea3Dなどの他の型は別途工夫する必要がある。

個人的にはほぼ地形にしか使わないつもりなので、一旦これで進める。

読み込み中...

コラム第一回です。雑記に近いですが、自分なりの考えをアウトプットしますので、よかったらお読みください。

さて、2016年はVR元年なんて言われた日から、もう10年が経過した2026年。AIの浸透期に入ったと言えますね。

僕自身、AIをバリバリ活用してる人よりは少ないかもしれませんが、一般人としては比較的AIを活用してると思っています。仕事でも結構活用する機会が増えてますね。

個人としては、

GeminiはGoogle OneのAIプラン
Claude Codeの従量課金
GitHub CopilotはGitHubの有料プラン+従量課金
Mureka（サウンド関連）

って感じで、割と使い倒してます。なので、今回は各種AIをどんな活用をしてるかを、未来の自分に向けたメモのつもりで書いていこうと思います。

Gemini 3

Geminiはコードも書けて便利ですが、あんまりコードを書かせる方向で利用することは少ないかもしれません。個人的にはチャッピーよりもGemini派です。嘘が多いと言うか時々情報が古かったり情報が混ざって混乱してる内容を、堂々と伝えてくるのでギョッとする感じですね。

計画を立てたり分析や企画の壁打ち、小さなことの知識補完みたいな使い方が多いです。

Geminiは過去のチャット履歴からうっすら長期記憶を残す設定があるので、回答にバイアスがかかります。しかし、変な思い込みも発生するので、僕はその記憶を残す設定を切ってます。

僕にとって企画を立てることにおいて、Geminiは最適だなと常々思っています。これは個人の特性もあるんでしょうが、僕はもともと「会話をしながらひらめきを得る」タイプです。机に向かってじっくり考えたり、散歩をして考えたりするよりも、言葉で発することのほうがよほどひらめきやすいのです。

つまり、会話をベースとするGemini（や他のAI に関しては、自分との相性が良いなと感じます。

Geminiの良いところは、変に思考を引き出させせる誘導と言うか、雑な対応が少ないところだなと思います。

「なるほど、〇〇に困ってるんですね、そんなときあなたはどう考えますか？」みたいな、事実と深層の思考の引き出しみたいな、カウンセリングみたいな返答が少ない印象。というのも、これを返されるなら正直AIと会話する必要はない。

壁打ちとしてちゃんと一般的な事実や知識を交えながら、僕自身の考えを強めていく動きをしてくれるのを感じるのがいいところだなと思いました。ただAIの出した答えに乗っかるって感じの使い方は正直やめておいたほうがいいと思いました。理由はシンプルに、企画として面白くないからですね。

AIの進化はすごいですが、いつまで経っても洒落やお笑いを理解できてないですね。企画もそうです。「面白さ」というのは、人間の非合理や矛盾した部分が醸し出してるところなのかもしれませんね。

Github Copilot

コードを書いてるときはかなり頼っていますが、バイブコーティングは正直どうかと思ってます。

先述したGeminiの使い方のように、そもそもAIの考え方に乗っかるとあんまり良いものができない気がしてます。

たしかに、要望や設計通りに書いてくれるんですが、細かな意図や未来（拡張）が見えていない印象です。

たとえばゲームであれば、かなり叩きまくったプロトタイプを作ると、本開発にはほぼ使い物にならないですし、プロトタイプのコードを解析させても細い意図は汲み取ってはくれません。

実行結果もログなどから読み取ってはくれますし、動画や画像も解析はしてくれます。しかし、何が良くて何が悪いのか、AIは読み取ってくれません。

たとえば、人間からすればバグも面白い仕様になるみたいなものはAIとしてはただの不具合でしかないので、バグから生まれる新たな仕様みたいなものは完全に消されます。

まあ、バグから仕様というのは少し極端で狭い例かもしれませんが、バイブコーティングはゲームのようなエンタメにはまだまだ向かないなって感じです。

一方で、特定の要素や機能を小さく作るサポートとしては超優秀です。他の機能との連携も考えながらよく実装してくれます。注意点は言葉が足らないと変に補完してコードが冗長になったり、不必要に過去のものを残されたりするので、長くその機能とAIと付き合うのであれば、定期的にしっかりと言葉にしてリファクタリングをするのが良い付き合い方かなと思いました。

ちなみに。

WordPressのテーマやプラグインを作るのは爆速でできます。バイブコーティングとしてできるかは微妙なところはありますが、既存システムの上乗せをするだけならAIはめちゃくちゃ爆速で出来上がりますね。とてもよい。

というわけで、特にオチもないですが、AIとの「今の僕の付き合い方」でした。