東京科学大学デジタル創作同好会traP

藍ノ國、紅ノ國【1-Monthon 2026 29班】

hiyoko — Sat, 05 Sep 2026 18:03:09 GMT

こんにちは。hiyokoといいます。
一か月で何かを作るイベント、1-Monthon 2026に一人で参加しました。
この記事では、制作した2Dの見下ろし型アクションゲーム『藍ノ國、紅ノ國』の軽い紹介と、こだわったしくみを紹介したいと思います。

一か月頑張った結果、優秀賞をいただくことができました。ありがとうございます！

制作したゲームについて

プレイリンク

unityroomにて絶賛公開中！
>>>ここからプレイ<<<

ゲーム概要

三柱の神々がいる世界。そこでは、藍ノ國と紅ノ國が長きにわたって戦争状態にあった。
しかし、その均衡はある時から崩れた。
主人公、レイメイは、藍ノ國の長であるタデアイから特別任務を任される。その任務中、レイメイは多くの苦難に見舞われる...

1v1で戦う見下ろし型スピードアクションゲームです。
重要なのはパリィをうまく使い、相手の攻撃をいなすこと。
迫りくる強敵を、あなたは倒すことができますか？

Unityroomではこう書かせてもらっています。なかなか端的に説明できているんじゃないでしょうか。

この一か月で様々な方向転換がありましたが、最終的に落ち着いたのは、「すべての攻撃をパリィすることができる爽快アクション」でした。

ゲームができるまで

班構成

hiyoko @hiyoko

準備

構想段階のmarkdownを残してあったのでそのままはってみましょう。

いろいろ書いてますが、この中で現実のものになったのはあんまりないですね。
このときは一人だけで開発するとはいえ、一か月あるからという余裕が感じられます。

藍と紅の世界
スプラトゥーんｘ見下ろし型ｘ激しい1v1
あらゆる敵味方の攻撃はその攻撃範囲に合わせて地面がその色に染まる
戦闘はスピーディーなかんじで、お互いに数劇の攻撃を食らうと死ぬような緊張感のある戦闘
ループもの
紅の将軍を倒すたびにループ。将軍とは遭遇するたびに戦闘前に会話をする

実際にゲームとして取り込めたのはこれくらいですかね？
テーマ「あい」「まい」に絡ませるのを何にするかを非常に悩んだ記憶がありますが、結局「藍色」に落ち着きましたね。

開発

本格的に開発が始まりました。
正直あんまりなにしたか覚えていないので、ここでは雑にコミット履歴を見てみましょう。

8/8 ~ 8/12

この人mainで作業してる（笑）
やってますね。このころは若かったな（3週間前）。

playerとakane（ハクボの古い名前）の基礎実装と、塗りシステム作ってます。
この時点で某インク塗りゲームの土台っぽいのができてますね。

8/12 ~ 8/19

Branchを作ることを覚えました。ありがとう。

最初はakane（ハクボの古い名前）の基礎実装が終わってすぐに攻撃AIを作っていたのですが、あまりにも面白くなくて断念。
面白くなさがコミットメッセージに垣間見えます。

このころはなにも絵をかいていないので、見た目がシンプルなんですよね。
ただの三角形に複雑な動きをさせようと奮闘しても、あまりモチベーションが続かないわけで。

ということでボス以外の大まかなシステム実装に逃げましたね。

8/20 ~ 8/29

8/20にしてついにグラフィックを描いて導入してますね。
仮の見た目として導入して、余裕があるときにまた書き直そうと思ってました。
もちろんできませんでしたが...

この時期もずっとボスAIからは逃げ続け、ついにopening sceneが大方出来上がっていました。

8/29 ~ 8/31

この時期は細かいグラフィック面をいじるのが面白くていろいろやってますね。
夜とか夕方とか夜明け前とかを実装したのはこのころだったように感じます。
むっちゃ実装簡単でした。上からそれっぽい色をかぶせて合成するだけなので。

8/31 ~ 9/2

ついに逃げ続けてきたボスAIに立ち向かう時が来ました。
足を震ふるわせながらブランチ（boss-ai-2）を作ります。

ふと日付を見ると、八月が終わろうとしているではありませんか。
途端に泣き崩れる俺。

視界をぼやけさせながら、爆速でboss aiに向かってキーボードをたたきます。

9/2 ~ 9/5

「やべ、もう3日しかないやん！！！もう同じブランチですべてをいじったろ！！！」
そう思った私は、あるブランチを作りました

"Everything is going to be better."

ありがとう、git。フォーエバー、git。
そう思いながら、私はあらゆる変更をこのブランチに食わせました。

楽しかったです。

ボスAIのついて詳しく書いてみる

大枠

このゲームで一番複雑なものはボスAIでしょう。
このボスAIについて、私なりに実装したものを紹介してみたいと思います。

まず、前提として、ボスには様々な条件から適切な攻撃を選択してほしいですよね。
ですが、今回私が作るゲームはそれだけでは足りません。

まず、このゲームにおけるボスには、以下の特徴があります。

playerと同じ100HP
同じ大きさ、当たり判定の同じ人間
数回の攻撃で死に至るレベルの繊細な体力

これらと大体のゲームの敵との違いは、「playerからのダメージを受け続けることができるか」ということです。
多くのボス敵は、たくさんのHPをplayerがボスの攻撃の間を縫って削っていくことが多いですが、私が作りたいゲームはそうはいきません。
だってボスがplayerの攻撃何発か食らうだけで死んでしまうのですから。

つまり、playerに対して攻撃を選択するほかに、緊急時にplayerの攻撃をよける動きを強制的にさせることが必要です。
これがめんどくさい。

通常時 : 攻撃システム
異常時 : 緊急回避システム

ということで、この二つを頑張ってなんとか実装しようぜとなったわけです。

通常時 : 攻撃システム

緊急回避システムがめんどくさいとか書きましたが、こっちも別にめんどくさかったです。

ここでの目標は、いろいろな条件から適切に攻撃を選択することです。

考えた結果、まずは大別にAIにAttackStanceというものを持たせることにしました。

この状態は、おもに攻撃の激しさ、つまり逃げの姿勢か攻めの姿勢か、塗りの姿勢かなどを持っています。
この状態をもとに、具体的な攻撃技を選んでもらうわけですね。

AttackStanceには、以下の状態を持っています。

NEUTRAL
OFFENSIVE
RETREAT
PAINT

こうみるとシンプルですね。例えばOFFENSIVEが選ばれている時は、playerに向かって突撃して剣戟を浴びせる、のような攻撃的な技が選ばれるわけです。
そして具体的に最適なAttackStanceを戦闘中に選んでもらうわけですが、実装するやり方のイメージはユーティリティベースAIと呼ばれるものです。
各行動に「今どれくらい良いか」の効用値(utility)を付けて最大のものを選ぶってかんじですね（by Claude）。
つまり、AttackStanceに対して個別にいくつかの要素の評価値を計算し、その合計和をとります。
AttackStanceの場合は、以下の要素の合計値ですね。

敵の所持Mana
playerの所持Mana
自分の周囲のインク割合
これらの評価値は、すべて0.0から1.0に縮めてあります。

これの最大値が、はれてその状況でのボスの攻撃スタンスとなるわけです。

これでやっとメンバーが出そろいました。
今度は具体的に攻撃を適切に選択してもらいます。
ここでも、評価値を計算し、その和をとってもらう形です。
このゲームでは、以下の要素の加重和です。

playerとボスの距離
直前に実行した攻撃。コンボボーナス
ボスの周囲にある自分の色領域の割合

そしてこの出てきた評価値に対して、以下の要素で乗算していきます

今現在のAttackStanceを考慮
直前の攻撃が同じだった場合はスコアを0.9倍
現在のマナが3割以下の場合は攻撃を控えたいので、0.5倍

こんな感じの評価システムを、すべての攻撃を引数として入力すれば勝手に計算してくれるようにすれば完成です。
おめでとうございます。

異常時 : 緊急回避システム

このゲームのボスは「ダッシュ」というものを頻繁に行ってきます。
playerに急接近してくる攻めのダッシュと、playerから逃げる撤退のダッシュですね。
これらの動作は、普通に登録されている攻撃と全く別の扱いをされているわけではなく、全く同じ"攻撃"としてダッシュが実装されています。
つまり、このダッシュも普通の攻撃とまったく同じように評価値を計算して、その結果最大のものであったために選択されているわけですね。

ここに先ほど言った「直前に実行した攻撃。コンボボーナス」を組み合わせれば、ダッシュした直後に近接攻撃技が繰り出されやすくなったりするわけです。

さて、ここまで実装したAIに何が足りていないかというと、playerがこちらに攻撃してくる瞬間を見て、逃げたりしてくれないということです。
大問題です。このゲームのボスのHPは全然ないので、そう易々と攻撃を与えられたくはありません。

ということで、playerの攻撃をよける動作を作りたいのですが、ここで問題が起きました。
このゲームのplayerの攻撃は、攻撃ボタンを押した瞬間に当たり判定が生成されるので、よける猶予フレームが0ということです。
なのでここはしょうがないと、「playerが攻撃しようとしてくる」ことを読み取って回避させることにしました。

「playerが攻撃しようとしてくる」ってなんやねんって感じですが、私が実装したやり方はこんな感じです。

float型emergency_dash_scoreに対して、playerが「playerが攻撃しようとしてくる」ほどこの変数に値を加算し、EMERGENCY_DASH_THRESHOLDを超えたら緊急回避のダッシュをおこなう。
emergency_dash_scoreは以下の条件で加減を行う。

playerの進行方向が、ボスに対して許容誤差60度以内であるとき、MAX_SCORE_MODIFIER * weightほど加算（適当に小さめの値）。
playerの進行方向が、ボスに対して許容誤差60度以内でないとき、その許容誤差範囲内からどれだけ角度的に離れているかで減算。

(具体的には、許容誤差範囲内からの距離0で0減算/許容誤差範囲内からの距離150度（MAX）でMAX_SCORE_MODIFIER * weight減算)

以上の動作を、playerとの距離が小さいほど大きくなるように行う。（processed_distance_scoreを乗算する）

func _evaluate_emergency_dash_score(weight: float = 1.0) -> void:

    var direct_direction = (hakubo.global_position - player.global_position).normalized()

    var player_direction = hakubo.get_player_vector()

    var diff_angle = direct_direction.angle_to(player_direction) if player_direction.length() > 0 else (-PI)

    var distance_to_player = hakubo.get_player_distance()

    var processed_distance_score = remap(_range_score(distance_to_player, 0.0, 400.0, true), 0.0, 1.0, 0.8, 1.2)  # 近いほどスコアが高くなる

    if abs(diff_angle) < deg_to_rad(60):

        emergency_dash_score = clamp((emergency_dash_score + MAX_SCORE_MODIFIER * weight) * processed_distance_score, 0.0, EMERGENCY_DASH_THRESHOLD)

    else:

        var remaped_score = remap(abs(diff_angle), deg_to_rad(60), deg_to_rad(180), 0.0, MAX_SCORE_MODIFIER) * (-1)

        emergency_dash_score = clamp((emergency_dash_score + remaped_score) * processed_distance_score, 0.0, EMERGENCY_DASH_THRESHOLD)

いかかでしたか？

ということで、おめでとうございます。これでいい感じのボスAIができました。
あとは1 monthonで発表して賞をもらうだけです（ここに強欲の壺の画像）。

余談 : 移動方向

別のボスAI実装の話で、移動方向のことについてちょっと話そうと思います。
このゲームのボス戦の戦闘場は、やった方はわかると思うのですが、きれいな円形をしています。

このマップを描いている時は特に何も考えていなかったのですが、今となってはこの円形には実装上の意味ができています。

何のことかというと、ボスがどの方向に歩いたり、ダッシュで逃げたりするかを決めるのに使用しています。

このゲームのボスは普通に歩いたり、もちろん先ほどから言っているようにダッシュをします。
しかし、普通に実装すると、どうしても壁に向かって歩き続けたり、逃げたくてplayerから遠ざかるようにダッシュしたのに、壁に阻まれでそのままお陀仏、みたいなアホAIができてしまうんですね。
これはいかんと。私はクールな激しい1v1がしたいのです。

ということで、ダッシュのシステムと、歩くシステムに対して、その適切な（壁にぶつからない）方向を計算するシステムを作ることにしました。
そしてここにきてステージが円形であることに価値が生まれるわけです。

まず、どんな方向が適切かを考えます。
AttackStanceがOFFENSIVEである場合は簡単です。攻撃をしに行きたいので、歩きもダッシュもplayerに向かっていけばよい。
じゃあほかの時は？逃げたいときは、少々複雑になります。

上の画像の場合を考えます。この時、ステージ壁に近いボスは逃げたいと思っているとします。
playerはステージ壁に対して若干左上にいるとすると、理想の逃げる方向は以下の条件を満たすものです。

playerから離れることができる方向
ステージ壁から離れることができる方向

あとは簡単ですね。この二つのそれぞれを表す単位ベクトルを合成すればよい。
playerから離れることができる方向はかんたんです。playerとボスの座標ベクトルの差で出せます。

ステージ壁から離れることができる方向は少し難しかったですね。

最初はこの円形ステージのボスから見た原点中心の方向ベクトルでいいんじゃないかと思いましたが、これだと問題があります。
ボス、player、ステージの原点中心がだいたい一直線上にある場合です。
これだとplayerから離れることができる方向とステージ壁から離れることができる方向が正反対の向きになり、打ち消しあってしまいます。
結果として逃げるまたはダッシュする方向は、どっちに行くかわからない不安定な挙動を示してしまいそうです。

ということで、ステージ壁から離れることができる方向には、原点中心の方向ベクトルに加えて、「ステージ壁の接戦方向ベクトル」を足すことにしました。
もうこれで安心ですね。

これは製作中にちゃんと機能しているか見たかったので作った視覚化機能です。（ボスから右上に伸びている赤色の扇型は、ボスの攻撃エフェクトなので関係ありません。）

青棒が "playerから離れることができる方向"
赤棒が "ステージ壁の接戦方向ベクトル"
黄棒が "原点中心の方向ベクトル"
青棒が "上記3つの合成ベクトル、つまり結果逃げることになる方向"

この写真を見ると、青い棒は短いのがわかりますか？
実は今まで喋った内容とは別に、ステージ中心と壁の距離によってもそのベクトルをどれだけ重視するかを変えています。
まあこれはおまけ程度です。

func calc_retreat_direction(invert: bool) -> float:

    if not hakubo:

        return 0.0

  

    var inv_mult = -1.0 if invert else 1.0

  

    var direct_retreat_dir = (hakubo.global_position - hakubo.get_player_position()).normalized() * inv_mult

    var circle_tangent_dir = hakubo.battle_field_center_marker.global_position.direction_to(hakubo.global_position).orthogonal().normalized()

    circle_tangent_dir = _get_similar_direction_vector_from_opposite(circle_tangent_dir, direct_retreat_dir)

    var center_direction_dir = (hakubo.battle_field_center_marker.global_position - hakubo.global_position).normalized()

  

    var battle_field_radius = 268

    var distance_to_center = (hakubo.battle_field_center_marker.global_position - hakubo.global_position).length()

    var center_bias_strength = clampf((battle_field_radius - distance_to_center) / battle_field_radius, 0.0, 1.0)

  

    var processed_direct_retreat_dir = direct_retreat_dir * remap(clampf(center_bias_strength, 0.0, 0.5), 0.0, 0.5, 0.0, 1.0)

    var processed_circle_tangent_dir = circle_tangent_dir * remap(clampf(1.0 - center_bias_strength, 0.0, 0.5), 0.0, 0.5, 0.0, 1.0)

    var processed_center_direction_dir = center_direction_dir * remap(clampf(1.0 - center_bias_strength, 0.5, 1.0), 0.5, 1.0, 0.0, 1.0)


    var retreat_direction = (processed_direct_retreat_dir + processed_circle_tangent_dir + processed_center_direction_dir).normalized()
  

    return retreat_direction.angle()

おめでとうございます。これであなたのボスAIは壁にキスをすることが趣味の変態にならずに済みました。

感想

じつはこのゲームが人生初めてちゃんと完成したゲームなのですが、結構面白いゲームが作れてとてもうれしいです。
今までは、飽きたり、何か別のことに熱中してしまったりで、未完成お蔵入りさよならバイバイがすべてでした。
今回のこの1monthonで手に入れた技術は計り知れないですね。楽しかったです～

動画投稿をしてみた結果得られたのは OO でした

Alt--er — Sat, 05 Sep 2026 13:03:48 GMT

この記事は、2026年度夏のブログリレー 20日目の記事です！
バックナンバーは上記のリンクよりご覧ください

はじめに

初めましての方は初めまして、科学大デジタル創作同好会所属の学士 4 年になりました@Alt--erです。traP では主にGame 班及びSysAd 班で活動しています。あとは動画制作もやっていたり。
今回は、昔のことにはなりますが動画制作(動画投稿)をしていたので、それを振り返ってみて思ったことを書いてみたり。なお、この記事は年始のtraP冬合宿で行ったらんぷろ(LT)の内容をもとに、文章化したものになります。

動画投稿をしてみた話

もう1年近く前のことになるのですが、実は動画投稿者の経験がありまして。半年ちょっとの期間、ニコ動とyoutubeにゲーム実況動画をアップロードしていた時期がありました。以前の記事でも触れた通り、動画編集や合成音声をもちいた製作を趣味で行っており、そのアウトプットの一環として行っていたものになります。

「『ずんだもん』の声」を思い浮かべながらこの記事を開いてください【夏のブログリレー2025】

この記事は夏のブログリレー2025 6日目のものです他の記事を見たい方はこちら↑ のリンクをクリック！ title image: akihiyo 様はじめに初めましての方は初めまして、科学大デジタル創作同好会所属の学士 3 年@Alt--erです。traP ではSysAd 班およびGame 班で主に活動しています(他にもグラフィック,サウンドに所属しています)。最近はゲームのプロジェクト進捗の日々を過ごしています。さて、今回の記事は筆者が最近ハマりだしている合成音声界隈にまつわる記事です。自分自身まだまだ知らない部分も多いですが、この記事を通して一緒にハマってくれる人を密かに求めています()。前提知識は特にないので、気軽に読んでくださればです。ずんだもんとは東北ずん子・ずんだもんPJ 公式HP東北ずん子・ずんだもんは東北企業であればイラストを無償で商用利用出来るキャラクターです。もとを辿れば、東北地方の地域振興にキャラクターを導入して盛り上げよう、という経緯から誕生したキャラクターです。ただ現在では、実況動画等に用いられ

東京科学大学デジタル創作同好会traPAlt--er

本記事は、半年間の投稿生活を振り返ってみて、色々思ったことを徒然なるままに書いていくものです。ちなみにですが、動画を伸ばす方法とかそういったものは一切書いてないので悪しからず。 ~~だって伸びてないんだもん~~

どんな動画を上げていたの?

Cities:Skylines という都市開発シミュレーションゲームの、合成音声(ずんだもんetc)実況動画を作成していました。ゲーム選択は自分の趣味でありつつ、比較的知名度の高いタイトルを選んでたり。ストーリー系実況と違い、「他の人の実況をみたらそれでおしまい」、とはならないのが良い点ですね。まあ、競合が多いという意味ではレッドオーシャン的ではあるのですが......

数百万回再生の動画もあり、実況が活発なタイトルです

動画投稿の経験はこれが初めてではなかったのですが、何回かエタった(シリーズ途中で予告なく動画投稿を止めること)ことがあったので、今回こそはと完結させる心意気で。年内に終わらせる、といった目標のもと 25年5月~12月の期間に投稿していました(最終回動画は大晦日の夜にアップロードでした！)。本数は 22本 (25年内に上げたもののみ)、動画時間の累計は 4時間8分 (同左)でした。(詳細データはあとで載せるかな)

完走した感想

まあ、達成感はありました。最後の方駆け足になっちゃって、若干の不完全燃焼は残っていますが。と、同時に振り返ると「すごい時間の溶かし方をしてたなぁ......」とも思ってたり。「しばらく(動画制作は)休みたい」って感想もあったかなぁ。しばらくといいつつもうnカ月も Aviutl(動画編集ソフト) 開いていませんが()。

とはいえ、ブログ記事にするくらいには、そして自分の活動の一つと胸を張って言えるくらいには面白いことができたと思います。ここからは、自分がどんな雰囲気で動画制作を進めていったのか、実際のところどれくらい再生されていたのかとか話していこうかと。

どんなことやってたの?

単純にいえば「10日に一本、10分くらいの動画を1回分として投稿する」といったところです。シンプル。
それで、この作業を大きく分けると「収録」「セリフ作り」「編集」といった3フェーズに分けられます。この辺、動画の種類や投稿者によってやり方が結構バラバラですが。

大体の所要時間ですが、収録が2_{4時間、セリフ作りが2}3時間、編集が5時間以上といった感じでした。集中したらもうちょっと速くできるでしょうけども。1本の動画、10分くらいの動画を作るのに10~15時間くらいかかったかなぁって印象です。セリフを合成音声に喋ってもらうタイプの動画だと、1分に1時間はまあ普通くらいの進捗速度でしょう。

それぞれのフェーズについて詳しく紹介

収録

その名の通り、「ゲームを遊んで録画する」といったフェーズになります。とはいっても、動画として見どころは作りたいので、遊ぶ方針自体はある程度決めていたり。今回実況していたのはシミュレーション系だったので、事前の方針決めもやり易かったかな(逆に撮れ高があるまで続けないといけないアクション系は収録も大変そうです......)

収録が終わりましたら、ゲームプレイを思い出しながら、改めて動画の構成を考えます。事前に計画した意外にも撮れ高が得られたり、もしくは事前の計画ではあまり尺が取れなさそう、といった場合があるためです。あと、やっぱり動画を撮り終わった後の方が具体的に構成を練れますからね。

クリップのイメージ

ゲーム内容とクリップのファイル名をメモでまとめていたり

大体1~2分ごとに「シーン」を区切るイメージで、各シーンについて使うクリップをフォルダー分けしたりしていました(録画ソフトの設定で5分ごとにクリップを分けるようにしています)。ある意味では整理作業とも言えるのが、収録パートですね。

セリフ作り

収録と使う素材の整理が終わったら、続いて話すセリフを作ります。合成音声での実況特有のパートですね。
この部分は、合成音声系の投稿者でも様々なやり方や派閥があるところなのですが、自分は以下の順序で進めていました。

収録で分けたシーンごとに、各キャラクターのセリフテキストを入力する(1動画120セリフが目安)
全体を見通して、回りくどい言い方がないか、誤字がないか、セリフ間の繋がりが自然かなどを確認する
音声作成ソフトにデータを入力する。1でのセリフ入力をスプレッドシート→csv変換することで、半自動的に情報を入力できる
読みのミスやイントネーションに違和感がないように「調声」する

読み変換との戦いなのだ

他のスタイルとしては、後述する編集と並列する形で動画素材を並べながらセリフを作っていく、というものもあります。自分もその方針でやっていたことがあったりなのですが、動画全体でのまとまりが取れないこと、くどい言い回しが増えちゃうといった所があったので先にセリフを作るようになりました。作業速いのは並列で進める方なんでしょうけどもねぇ。

編集

ここまで用意した収録素材とセリフ素材を、実際にまとめ動画にしていくフェーズになります。加えて、字幕づけやキャラクターの表情作り、場面切り替えといったエフェクトの導入も行います。動画作りと聞いて一番イメージが湧く場所であり、そして創作者としての技量も試される部分であります。投稿者の味が出る場所ってことですね。

シーンチェンジ演出の例レイヤー設定とか結構工夫してたりします

ゲーム実況など、定期投稿を行う際に重要なこととして、「テンプレート化」というのがあります。これは、1本の動画の大まかな流れや字幕のスタイル、画面のレイアウトなどといった要素を揃える、といったことです。このテンプレート化は、視聴者が違和感なく動画を視聴してくださるためにも重要ですし、編集効率を上げるためにも役にたつものとなります。

エイリアス機能などを活用して一気に配置できるように

先ほどのシーンチェンジもこの10レイヤーを一気に配置できるようにしてます

1つの動画作品を作る場合と異なり、定期投稿では編集効率も十二分に求められます。10日に一回の頻度だったら、忙しくないタイミングで大体3~5日で1本の動画は作れるようにしたい所です。字幕の強調や立ち絵の表情、効果音入れだったり、とにかく繰り返しの多い作業であるので、効率化や自動化も大事だったりします。

大変だったこと

学生、特に数ヶ月で時間割がガラッと変わる4Q制の弊学においては、生活環境の変化が割と多いこともあり(もちろん試験もあるので)そういった節目でも安定して投稿を続けられるようにするのが大変だったかと。実際、本当に忙しいタイミングでは投稿間隔を伸ばしたりすることもあったり。

謝罪ツイートのつもり

あと、何気に後半になってくるとネタ出しとかってちゃんと大変になってくるんですよね。これまでの動画ではじっくり扱えたことでも、カットすべき時間が長くなること、そもそもゲームが進むにつれてプレイすべき時間が伸びていく(これはゲームの性質にもよりますが)といったところとか。後述しますが、「ちゃんと終わりを決めておくこと」がかなり重要なことだったりしました。

得られたもの

もちろん編集技術も台本を作る力も、合成音声の調声技術も身につきましたが、やっぱり大きかったのは「物事を継続する力」なのかなぁと。世の中見ると、当たり前のように継続して投稿してるじゃないですか、それは動画に限らず絵描きさんや物書きさんでも。さらに、仕事ではなくあくまで趣味の範囲でという方も多いはず。

やってみたら分かりますが、何年も続けている人は本当に凄いなって。毎日投稿しているような化け物の方々はもちろん、1ヶ月に1度といった低頻度だとしても、続けることがすごい。現に自分、終わってから半年以上たってももう一度チャレンジするほどのモチベがまだ湧いておらず...... まあ、やりたい時にやるのが一番ではありますけどもね。

あと、継続する力に絡んできますが、「物事を構成する力」ってのも何気についてるんじゃないかと思ったり。特に今回、完結まで続けられたのは早い段階で「終わりを決めておいたから」だと考えてます(10本目くらい、夏頃には終わりを見据え始めていました)。ゴールを設定していたのがある意味ではモチベになってたのかもしれません。

最終回までの投稿日リスト

いわゆる広告収入的なものも僅かですが得られました。クリエイターに優しい(と思ってます)ニコニコ動画は収益化条件がないので、1300円ほどの収入を得られました。額面こそ僅か、時給換算で5円ほどですが、自分の創作物で稼いだという喜びはひとしおです。え、Youtubeですか?収益化の基準(登録者500人)に遠く及ばずで収益0だけど()。

niconicoのクリエイターサポートによる収入

youtubeはこれなので......

今回はシリーズをしっかり締めることを目標にしていたので、再生数や登録数を気にしすぎないように注意していましたが、まあ気になりますよね。これが他のチャンネルに比べて多いのか少ないのかは分かりませんが、登録者数は 200人ほど、総再生数は1.5万回ほど(youtube)でした。7月と11月ごろに一気に伸びて、気持ち良かったことを思い出したり。

youtubeのアナリティクスより

終わりに

本記事では動画投稿主としての Alt--er の側面をお伝えしました。創作の技術というよりかは、タスクを進めるための技量が身についたという感じではありますが、その面でもいい経験だったかと。かなり時間を使う活動にはなるので、気軽にはじめてほしい、とは正直言い難いですが、一つ挑戦してみても良いかもしれません。

明日は @quarantineeeeeeeeee さんの記事です！お楽しみに

四国一周旅行から学ぶ気を付けるべきこと

SAH123 — Thu, 03 Sep 2026 15:00:24 GMT

この記事は夏のブログリレー19日目の記事です

こんにちは！25Bの佐原です。

皆さんは旅行とか行きますか？僕は、お金と時間の問題で、そこまで旅行に行くことができていません。それは置いておいて、今回は、昨年の夏休みに行った四国一周旅行で起こったアクシデントから、気を付けるべきことをピックアップしていきたいと思います。

1. 貴重品を身から離すな

旅行0日目（フェリーで四国に上陸した日を1日目とするため、便宜上この表記となっています。）、僕は有明にいた。イベントに参加していたのである。終了後、乗船場へと浮足立ちながら移動していた矢先、手元からスマホがなくなっていた。

あほかではないかと思うかもしれませんが、これが現実です。

同行していた先輩を連れて探し回ったり、実家の妹にスマホの位置を探してもらったり(https://myaccount.google.com/intro/find-your-phone) したところ、近隣施設で保管されていました。

もしも見つかっていなかった場合、これからの数日間、スマートフォンなしで旅行をする羽目になっていたので、非常に危ないですね。あり得ないことなので、皆さんはポシェットなどを活用して、小物の管理に気を配ってください。

友達と食べた骨付鳥。友達とは、到着から道後までの2日間行動を共にした。

2. ホテルを当日に取るな

四国一周旅しようと思い立った時、まずすることとは何でしょうか。

四国上陸と離陸のチケットを確定させるか、1日目の予定を詰めるかになると思います。僕は前者でした。

そして、めんどくさかったので、それ以外の行程は前日に立てることにしました。このことが問題となるのは、高知観光のため一泊追加することにした日でした。（実は、旅行中慢性的な将来への漠然とした不安に駆られていたので、気づかないうちに問題になっていたのかもしれません。）

僕は、高知のカプセルホテルで朝を迎えた。そのまま、寝ぼけまなこをこすりながらgoogleマップを開いた。適当なカプセルホテルを適当に選び予約を押す。すぐに、予約確定メールと支払い速報メールがinboxに入り通知音が鳴る。僕は、手続きの完了を確信し、高橋一生似の主人に見送られながら高知観光へ向かった。

国民休暇県らしいです。確かに穏やかな気候だった。

異変はホテルで起こった。観光を終え、ホテルへ向かうと僕の名前が全く見当たらないのである。何かの間違いだと、今朝したはずの予約を確認すると、間違えていたのは僕の方だった。

あほですね。googleマップでは、空室がない場合、指定した日以外の空室状況が表示されることがあります。当日予約する人のほうが少ないので、至極当然な処理だと思います。ちゃんと予約するときは、日付まで確認しておくのと、キャンセルポリシーについても気にするとよいと思います。（その日は結局、近くにあったビジネスホテルに泊まることにしました。）

チンアナゴ。外に出た直後大雨に打たれた。

3. 厳しいスケジュールを立てるな

こんぴらさん（金刀比羅宮やその周辺の山）はご存じでしょうか？

金刀比羅宮（ことひらぐう）は、香川県仲多度郡琴平町の象頭山中腹に鎮座する単立神社である。(from: Wikipedia)

四国のみならず、周辺地域でも有名な神社なので、ぜひとも拝みにいきたいところです。

そうぼんやりと思う徳島にいる佐原。しかし、残された日数は2日しかありません。さらに、最終日はノリで聖地巡礼をすることに確定してしまいました。（この話は後述する。ちゃんと宿予約してえらい。）

かずら橋（祖谷）はご存じでしょうか？

かずら橋（かずらばし）は、サルナシ（しらくちかずら）などの葛類を使って架けられた原始的な吊橋。（from: Wikipedia）

四国山地によって形成された渓谷に架けられていて、非常に神秘的なので、ぜひとも渡っておきたいところです。

そうぼんやりと思う徳島・阿南にいる佐原。

この結果、夏の日差しの下、息つく暇なく山を上り下りすることに。どうしてこうなったのでしょうか。（つづく）

あり得ない角度で生えてる家。

4. 下調べをしろ

2-3をご覧の皆さんこんにちは、答え合わせの時間です。

上で述べてきた問題は、すべてこの一言に集約されます。

ホテルを適当に予約しているのも、スケジュールがカツカツになったのも、最終日に突然聖地巡礼が生えたのも、0日目にフェリー乗り場が有明ではなく竹芝にあると勘違いしたのも、骨付きどり屋が電話予約できない日だったのも（遅いからかあまり待たずに入れた）、当初泊まろうとしていた宇和島周辺に空室のある宿が高級ホテルしかなく、無理やり道後から高知まで1日で移動したのも、桂浜で突然の大雨に見舞われたのも、阿南駅前にあまり飲食店がなく、近くのマックスバリュで寿司を買って部屋で食べたのも、サンライズ瀬戸のシャワーカードを手に入れることができなかったのも、全部下調べ不足が原因です。

大体調べていれば出てくるような事柄を、調べずに旅に出たことによって、このようなことになってしまいました。

特に、途中駅での乗り換え時に見かけたポスターから、一時期アニメを一気見したとある作品の聖地だということに気づいたという出来事から、すべてが察せられます。あまりにも予習不足で呆れます。

ですが、一人旅は修学旅行ではありません(互いに素）。学習することがすべてでしょうか？とはいえ、限度があるので、最低限は調べておきましょう。

親の橋より見た橋。

5. 現金を持っていけ

番外編です。

今回は公共交通機関で一周を行いました。バスの営業所といった施設では、クレジットカードを使用できます。しかし、クレジットカードを使えないバスへ整理券で乗る場合や、現金専用券売機しかない場合は、ただのプラスチックと化します。また、交通系ICに関しても、利用できない区間や、地域限定のICカードのみ使用できる区間が存在します。おとなしく十分な現金（小銭）を用意しておきましょう。

一面岩が広がる。携帯の電波もあまりつながらない。

6. 金を用意しておけ

番外編2です。

四国旅行の旅費は総額121,181円となりました。大半が交通費か宿泊費ですね。（フェリーとかサンライズ瀬戸がでかすぎる）

もしも、旅行の途中でクレジットカード（またはデビットカード）が停止されるとどうなるでしょうか？さっきはただのプラスチックとか言いましたが、止められてしまえば宿無し旅行が始まるので気を付けましょう。

これらの旅費を世界陸上でのバイトですべてまかなえたのは、また別のお話。（ただの観戦含めて、世界陸上に全日程で参加してたことになります）

徳島城跡で食べたそうめん。

まとめ

振り返って見出しだけ見ると、やる気のない旅行まとめサイトのチェックリストみたいになりましたね。とりあえず大切なのは、思い出を作ることだと思うので、この内容を参考にたくさん思い出を作ってください。

人生初のシロノアール

明日の投稿者は@Alt--erです!

マジカルミライ2026 in Tokyo レポート

fumo-fumo-C — Wed, 02 Sep 2026 23:39:30 GMT

始めまして、こんにちは、FUMO2Cです。初めてTrap Blogを書きます。

今日は9月3日、ひっくり返せば３９みくになる「逆ミクの日」ということで、2026年度夏のブログリレー18日目の今日の記事は、8月28日～30日まで開催されたマジカルミライ2026 in Tokyoにお友達と行ってきたので、その感想を綴っていこうと思います。

マジカルミライ

引用：初音ミク「マジカルミライ 2025」アフターレポート© Crypton Future Media, INC. / © TOKYO MX

マジカルミライとは「本気"マジ"なライブと初音ミクの文化"カル"チャーと未来"ミライ"」であり、初音ミクと※その仲間たちによるパフォーマンスを直接楽しめるバーチャルライブと彼らピアプロキャラクターズが生み出してきた文化を楽しめる企画展で構成されています。

※リン、レン、ルカ、KAITO、MEIKOはミクの仲間以上の存在だと思ってるよん。

In Tokyoは8月28日～30日の3日間構成で、ライブは昼公演と夜公演の二回づつ開催されます。私は28日の夜公演と30日の昼公演に参加しました。
また、私は去年やっと上京して初めてマジミラに行ったにわか民なので、お手やわらかに…

旅のお供はこちら！

マジカルミライ2024初音ミクことサンパレスミクちゃんのねんどろいどです。
またの名を私の一推しなのに大学受験~~とか言う忌々しい日本の教育制度~~によって行けなかったミクちゃんですね。まぁ田舎民の辛いとこ。

企画展

公式の展示

等身大フィギュア

企画展会場に入場し一番最初に目に入ってくるのは、ある意味企画展のお目玉的存在、マジミラデザインのミクさんの等身大フィギュアです。バーチャルシンガー初音ミクの造形が物理的に現実の空間に出現し、その迫力と美しさがたまらん！！

今年のミクちゃんは、ソナーレちゃんとかって呼ばれてます。今年のイベントテーマが「湖のソナーレ」で、それが発表された際、全員が「ソナーレってなんや？？？」となり「それーな」ってことでそう呼ばれています。

メインビジュアルのデザインはイラストレーターの緜さんによるもので、等身大フィギュアはDesign COCOが製作しており非常にお美しい…

記念撮影。カメラという道具は不便で、(比較的カメラに近い位置で)二つの場所に同時にピントを合わせられない…

今年のミクの立体化について思うこと…←押すと読めます

履修申告の前に知っておきたい！「ウェルネス実習」のあれこれ―体験談を添えて―【夏のブログリレー2026】

phi_isct — Tue, 01 Sep 2026 23:00:53 GMT

はじめに

この記事は夏のブログリレー17日目の記事です。

こんにちは！ゲーム班とCTF班に所属する、26Bのphiと申します。私は学士1年の前期、1Qと2Qに「ウェルネス実習」を履修しました。しかし、私は履修申告の前に、成績評価の方法や授業の進み方、そして評判などの十分な情報を集めることができませんでした。そこで、この記事では「ウェルネス実習」の履修を考えている方に向けての情報提供として、私なりに「ウェルネス実習」を解説してみようと思います！

（ちなみに、「情報提供」というのは、裏を返せば「ネタバレ」ということにもなりますので、ご承知おきください。。。（小声））

そもそも「ウェルネス実習」とは

いわゆる「体育の授業」です。自分の興味や関心に合わせて自由に選べる、選択科目の1つです。しかし、選択科目の中では、特に多くの1年生が履修する科目の1つでもあります。

履修方法

ウェルネス実習は、1つのクオーターあたりの単位数が0.5であるため、1単位を取得するには、以下のいずれかの方法で履修する必要があります。

連続する2つのクォーター（前期：1Qと2Q または後期：3Qと4Q）で週1回受講し、1単位を取得する（推奨）。
2Qと3Q、または連続しない2つのクォーター（例えば、1Qと3Q）でそれぞれ週1回受講し、1単位を取得する。
同じクォーターで異なる時限の2つの「ウェルネス実習」を受講（週2回）し、1単位を取得する。

2026年度1Qにおいては、多くの1年生が履修する時間帯は、月曜5-6限と木曜5-6限でした。「ウェルネス実習」の成績は、系所属点に用いることができます。なお、学生の多様なスケジュールや興味関心に対応するため、「ウェルネス実習」には参加できる時間帯や種目がたくさんあり、履修申告の仕組みが複雑になっています。詳細は、ウェルネス科目のホームページを熟読してください。

http://www.wn.ila.titech.ac.jp/

余談ですが、このウェルネス科目のホームページのタイトルが「Wellcome」になっているのがシャレがきいてて好きですw

授業を受ける際の服装

高校時代までの「体育着」のような指定された服装はありません。各自で運動着や運動に適した私服を持ってきます。高校時代に運動部に所属していた人は、高校時代の部活Tシャツやユニフォームなどを引き続き着ている人が多いようです。また、生協の購買部で購入できる𝑺𝑪𝑰𝑬𝑵𝑪𝑬 𝑻𝑶𝑲𝒀𝑶のTシャツを着ている人もいます。授業前後の着替えには、トレーニングセンター（体育館）の地下にある更衣室とシャワーを利用することができます（~~ちゃんと男子の更衣室もあるよ！~~）。バドミントンやトレーニングなどの屋内の種目を選択する場合、屋内用のシューズが必要になりますので前もってご準備ください。

気温について

2Q・3Qの「ウェルネス実習」は暑い中行われるので注意してください。ただし、種目「トレーニング」については、エアコンが設置されたトレーニングルームで行うため、暑さの心配は要らないようです。

種目分けについて

1Qと3Q、2Qと4Qで種目分けの方法が異なるので、それぞれに分けてまとめてみました。

1Qと3Q（ガイダンスあり）

1Q・3Qの「ウェルネス実習」においては、第1回の授業で種目分けが行われます。まず、履修したい時間帯の第1回の授業が行われる場所（トレーニングセンター1F体育館？）に集合し、そこで種目分けを行います。種目ごとに、教務Webシステム上で履修申告する科目名が異なるため、履修申告は決定した種目に基づいて行います。私がウェルネス実習を履修した2026年度1Qの木5-6限では、以下の4つの種目が開講されていました。

サッカー
ソフトテニス
バドミントン
トレーニング

各種目には定員があるため、人気の種目ではじゃんけんによって人数を絞る場合があります。私のときは、ソフトテニスと、特にバドミントンが人気でじゃんけんを行いましたので、これらの種目を履修する予定の方はご注意ください（トレーニングとサッカーは、たぶん定員に収まりました）。

2Qと4Q（ガイダンスなし）

2Qと4Qの初回の授業では、全体でのガイダンスや履修者全員を対象とした種目分けは行われません。「ウェルネス実習」は、同じ種目を1・2Q、または3・4Qと続けて履修することを想定した授業計画となっているため、1Qや3Qから続けて履修する学生は、同じ種目を優先的に選択できます。したがって、2Qや4Qの授業でも続けて同じ種目を選択する人が多いと考えられます。私が2Qの授業で見た限り、続けて同じ種目を選択した人は8割程度いました。なお、他の種目に変更する人も一定数いました。一方で、2Qから履修を始める学生は残りの定員の中で種目を選ばなければならないため、人気の種目を中心に、抽選倍率が1Qと比べて非常に高くなりました。2Qや4Qから履修を始めることを検討している方はご注意ください。

私の体験談: バドミントン

私が履修した科目は、1Qの「ウェルネス実習 A6」および2Qの「ウェルネス実習 B6」で、種目はバドミントン、担当はmrym先生でした。種目分けのあと、授業の進め方と成績評価についての説明がありました。この授業では、8人ずつ8つのグループに分かれて練習を行いました。授業のねらいは、1Qでは個人技能の向上、2Qではダブルスの技能向上でした。

以下、ネタバレ注意

1Qの第2回の授業からは、グループの中でペアを組んでの練習がスタートします。プッシュ、ドロップ、ドライブなどの打法を扱います。
（ここだけの話、私は第2回の授業があった日に、湘南新宿ラインに携帯を忘れて平塚まで取りに行く羽目になり、授業をトんでしまいました...w そのため減点されただけでなく、グループでの顔合わせのチャンスも逃してしまいました。皆さんはくれぐれも気をつけてください...。）

また、1Qの第2回以降の毎授業では、グループの中で半面シングルスの試合を行い、順位をつけて、その結果を踏まえて次回の授業でグループを組み替えていました。具体的には、グループ1～4の人たちの中で勝率が高かった人から順にグループ1、2、3、4に割り振られ、グループ5～8の中で勝率が高かった順にグループ5、6、7、8に割り振られました。そして、この試合結果が "多少" 成績に反映されたようです。私はこのことを知らずに履修申告したので、かなり心配しました。私ははじめグループ5にいて、5→8→7→8→8と移動しました（泣）。1Qではバドミントンの経験の有無は特に考慮されなかったので、経験者はもちろん勝てます。試合を重ねていくと、新しい知り合いや友達ができたりして楽しいです。

続く2Qの授業では、1Qの戦績を踏まえて、得意な人と苦手な人がバランスよく入るようにグループを分け、そのグループの中で（ランダムに）ダブルスを組んで、グループ対抗の試合（団体戦）を行います。ダブルスパートナーと一緒に戦うので、1Q以上に試合を楽しむことができました。最終的には、団体戦の結果に基づいて4グループずつ1位から4位までの順位が付きます。2Qから履修を始める人（10人強）は、最初の授業でバドミントンの実力がどれくらいあるか確認され、それに基づいていずれかのグループに入れられました。第1回と第2回の授業ではグループ内で練習を行いました。第3回から第6回までの各回の授業では、団体戦を1回ずつ行いました。そして、第7回の授業でも団体戦を1回行いましたが、これは第3回から第6回までの結果を踏まえた「決勝戦」または「ビリ決定戦」であり、ここで下の図のように4グループずつ順位が確定します。（なお、第3回から第6回までの勝ち数が同じで三つ巴になった3チームがあったため、そこの順位は獲得セット数で決めたようです。）

2Qの成績評価については、グループワークを中心にどれぐらいチームがまとまったか、技能点、グループの順位（"多少"）の3つを基準に行われました。

私の成績ですが、2回目の授業をトび、1Qで下位チームに居座り続けたにもかかわらず、83点でした。詳しくは後述しますが、成績を気にせず楽しむのが大事です。

成績や系所属点について

一般に、「ウェルネス実習」は毎回出席していれば高い成績を取りやすいといわれています。~~私は1回トびましたけど~~
「ウェルネス実習」では出席点が比較的大きな割合を占めており、通常の欠席は減点対象となりますので、~~電車内に携帯を忘れないように~~気をつけてください。

以下は万が一の場合に備えた、系所属点の仕組みに関わる小難しいお話です。

「ウェルネス実習」は、「広域教養科目」に分類され、系所属点の算出においては「選択単位群」として扱われます。2026年度の学修案内で、「系への所属と学修課程について」（p23-24）を参照すると、以下のことが書かれています。

（Ａ）必修単位群及び（Ｂ）選択単位群の授業科目については，「成績×単位数」として得点を算出する。総得点の算出においては，「（Ａ）必修単位群の授業科目の成績上位 17 単位」（以下「必修上位 17 単位」という。）の得点合計値と，「必修上位 17 単位以外の必修単位群の授業科目の成績，（Ｂ）選択単位群の授業科目の成績及び（Ｃ）その他（TOEFL 等）の成績の上位 14 単位」（以下，「選択等上位 14 単位」という。）の得点合計値を足した値を総得点とする。（最大 3,100 点）総得点＝必修上位 17 単位の得点合計値 + 選択等上位 14 単位の得点合計値
(https://www.titech.ac.jp/guide/guide_2026/gakubu1/)

この規則によれば、「必修上位17単位」以外の単位（「ウェルネス実習」を含む）の成績は、上位14単位の分のみが系所属点に用いられることがわかります。したがって、万が一「ウェルネス実習」の成績が振るわなかった場合でも、必修科目や他の選択科目、英語の外部試験（を100点満点に換算したもの）でより高い点数を確保することができれば、系所属点に用いる「選択等上位14単位」から追い出すことができます。

また、学修案内の同じページ（p24）には以下のようなことも書かれています。

「ウェルネス実習」と「生涯ウェルネス実習」の 2 科目を履修した場合は，そのうち成績上位１科目のみを用いることができます。
(https://www.titech.ac.jp/guide/guide_2026/gakubu1/)

すなわち、1Q・2Qに「ウェルネス実習」を履修して万が一成績が振るわなかった場合、3・4Qで「生涯ウェルネス実習」を履修してより高い成績を取ることができれば、系所属点を上書きすることが可能です。

これら2点を逆に考えれば、「ウェルネス実習」を使って他の選択科目を系所属点の要素から追い出すこともできます。

系所属点に関わるこれらの仕組みを知っておけば、成績に関して過度に不安を感じることなく、楽しく体を動かしたり、仲間との交流を深めたりすることができます。もっと早く知っておけばよかった！！

まとめ

以上、「ウェルネス実習」についてご紹介しました！「ウェルネス実習」は仲間と一緒にスポーツができる貴重な機会になります。新しい友達ができるかも！？また、しっかりと出席してしっかりと取り組めば、種目にもよりますが、比較的成績も取りやすい科目です。まだまだ知りたい情報があったら、友達や先輩に聞いてみて、情報収集してみてください！

明日の投稿者は@Fumo²Cさんです！お楽しみに！

Arpa's Trick

Oxojo — Mon, 31 Aug 2026 23:13:00 GMT

夏のブログリレー 16 日目の記事です。

問題を解いていてこれを使う機会があったのですが、日本語での解説がほとんどなかったので、書いていこうと思います。

Post Image は近代五種です。内容とは全く関係ないです。

Repovive Starter Round 2 - F. のネタバレを含みます。

導入

次の問題を考えます。

長さ $N$ の配列 ${a_{i}}_{1 \leq i \leq N}$ があり、最初すべての $i$ に対し $a_{i} = 0$ です。
以下のようなクエリが $Q$ 回与えられるので、すべて処理したあとの $a$ を求めてください。

$i$ 回目のクエリでは、 $l_{i}, r_{i}, v_{i}$ が与えられる。 $\forall p \in [l_{i}, r_{i}]$ について、 $a_{p} := v_{i}$ とする。

この問題を、 $lo g$ がつかない計算量で解いてください。

安直にやるなら Lazy Segment Tree を用いると一発ですが、log がついてしまいます。およそ線形時間で求まるようにしたいですね。

Disjoint Union Set であそぼ

これを Disjoint Union Set でやりましょう、という少し不思議な提案をしてみます。

準備 : クエリ先読み

問題を見るに Offline なので、クエリを先読みしてよいです。そうすると、クエリを全部読んで逆から処理していけば、すでに塗られているところを無視することで線形時間で解けそうです。実際に既知の要素を完全に無視できるのならば、すべての配列の要素はそれぞれ 1 回タッチするだけですから高速です。

赤線部分が実際にタッチしているマス

問題はこれをどう無視するかということですね。

やってみよう

12 マスあって、まず 2~7 番目のマスを青で塗り、次に 4~6 番目のマスを赤で塗るという場合を考えてみましょう。先ほどのように、クエリを逆順に見るので、まず 4~6 番目のマスを赤で塗り、2~7 番目のマスを青で塗るという順番で処理していきます。

$next [i] := i$ 以降にあるまだ塗っていないマスのうち、最も左にあるもの

としてみましょう。最初はどのマスも塗っていないので、 $next [i] = i$ です。

$i$ マス目を塗ったとき、一個右のマスはまだ塗っていないマスなので $next [i] = i + 1$ という風に変化させます。

でもこの数字、塗ってるマス指してるところあるじゃん！これでちゃんと青塗れるの？

というわけでこちらをご用意いたしました。

int find(int p) {
    if (next[p] == p) return p;
    else return next[p] = find(next[p]);
}

これで、 $i$ マス目を塗ったときに、 $next [i] := find (i + 1)$ と更新してあげます。
たとえば、最初は 4 マス目を塗ったので、 $next [4] := find (4 + 1) = 5$ です。

では、次に 2~7 マス目を青で塗ってみましょう。

$next [3]$ を更新するときどうなるかというと、

$find (4)$ を見る。 $next [4] = 5 \neq = 4$ になっている。
$find (5)$ を見る。 $next [5] = 6 \neq = 5$ になっている。
$find (6)$ を見る。 $next [6] = 7 \neq = 6$ になっている。
$find (7)$ を見る。 $next [7] = 7$ になっている。 $7$ を返して $find (7)$ 終了。
$next [6] = find (7) = 7$ に更新して、 $7$ を返して $find (6)$ 終了。
$next [5] = find (6) = 7$ に更新して、 $7$ を返して $find (5)$ 終了。
$next [4] = find (5) = 7$ に更新して、 $7$ を返して $find (4)$ 終了。
$next [3] = find (4) = 7$ に更新する。

という風になります。すると、最初に塗った 4~6 マス目に行くマスがなくなるので、これ以上タッチしなくなります。結果として、3 マス目は次に 7 マス目を指すようになります。

あとは、残った 7 マス目を青く塗って、 $next [7] = 8$ に更新します。

以上のように、DSU と同様に辿ってマージをすることができるというわけです。

ただ、マージの仕方が重要な問題です。DSU では、マージの計算量を落とすために、Path Compression と Union by Size (or Rank) を行うのがよくある手法ですが、今回のケースでは Union by Size は行うことができません。というのも、自身より右にある頂点に向かって結合するという向きが重要な役割を果たすので、単にサイズなどを基準にして swap などを行うことはできないのです。

Path Compression しかできないと、マージには $O (lo g N)$ かかってしまうのでは？と思われるかもしれませんが、大丈夫です。

Important Fact:
Union Find を構成する木が Line Graph である場合、union by size/rank の処理を行わず、単に Path compression を行うだけでも、結合は $O (α (N))$ で実行できる。

証明は省略しますが、Line Graph のもつ特殊な性質を用いることで示すことができます。よって、 $O (N + Q α (N))$ で解くことができました。

Arpa's Trick

長さ $N$ の配列 ${a_{i}}_{0 \leq i < N}$ に対して、

\forall i \in [0, n - 1], b_{i} := min {j ∣ j > i, a [j] < a [i]}

を $O (N)$ で求めてください。 ${j ∣ j > i, a [j] < a [i]}$ が empty である場合は $b_{i} := N$ としてください。

例えば、 $a = {5, 8, 2, 1, 6, 3, 9, 7}$ に対し、 $b = {2, 2, 3, 8, 5, 8, 7, 8}$ です。

$O (N^{2})$ なら超簡単ですね。

for (int i = n - 1; i >= 0; i--) {
    b[i] = i + 1;
    while (b[i] != n && a[i] <= a[b[i]]) {
        b[i]++;
    }
}

1 行変えてみました！

for (int i = n - 1; i >= 0; i--) {
    b[i] = i + 1;
    while (b[i] != n && a[i] <= a[b[i]]) {
       b[i] = b[b[i]];
    }
}

なんと！　 $O (N)$ になるんですね～　何？

b[i]++ を b[i] = b[b[i]] に変えただけですが、ここがいわゆる Path Compression に相当する操作になります。

つまり、ここでやっていることは、本質的には先ほどの色塗りの問題と変わりません。まず $i \to i + 1$ という辺を張って、それに沿ってマージしていくというだけです。こちらも形が Line Graph なので、Path Compression のみを行ってもマージは $O (α (N))$ です。

このように DSU 的な操作を行うことで、線形時間でこの問題を解くテクニックは、考えた人の Handle Name から Arpa's Trick と呼ばれています。

問題

ここからネタバレです。

Repovive Starter Round 2 - F. Pair Increment Ranges

こちらの問題を解いていきたいと思います。

とりあえず問題をまずは日本語に書き直していきます。

2 本の配列 $a_{1}, a_{2}, \dots, a_{n}$ と $b_{1}, b_{2}, \dots, b_{n}$ があります。
ある閉区間 $[l, r]$ が beautiful であるとは、配列 $a$ に対し、ある index $l < i \leq r$ を選んで、 $a_{i - 1}$ から $1$ 引いて $a_{i}$ に $1$ 足すという操作を $0$ 回以上行うことで、 $\forall i \in [l, r], a_{i} = b_{i}$ を満たすことを言います。
beautiful な閉区間の個数を求めてください。 $t$ 個のテストケースが与えられるので、それぞれに対して答えてください。

Constraint :

$1 \leq t \leq 1 0^{4}$
$1 \leq n \leq 2 \cdot 1 0^{5}$
$0 \leq a_{i}, b_{i} \leq 1 0^{9}$
$\sum n \leq 2 \cdot 1 0^{5}$

$[l, r]$ が beautiful である条件は

$\sum_{i = l}^{r} a_{i} = \sum_{i = l}^{r} b_{i}$
$\forall p \in [l, r], \sum_{i = l}^{p} a_{i} \geq \sum_{i = l}^{p} b_{i}$

の 2 つが成立することです。 $d_{x} := \sum_{i = 0}^{x} a_{i} - \sum_{i = 0}^{x} b_{i}$ とすると、以上の条件は

$d_{r} = d_{l - 1}$
$\forall p \in [l, r], d_{p} \geq d_{l - 1}$

に書き換えられます。

$l - 1$ を固定して考えます。日本語で説明すれば、自分より右にいて、自分と同じ値で、かつ自分より小さい値が間にないものがカウント対象の要素です。と考えたら、とりあえず末尾から考えていけばよいということが分かります。

$dp [i]$ を $i$ 番目が左端であるような beautiful な閉区間の個数とします。求める答えは $\sum dp [i]$ です。上の条件を満たすような最小の $r > i$ があったとしたら、 $dp [i] = dp [r] + 1$ と更新すればよいです。なければ、ないので $0$ です。じゃあその $r$ をどうやって探すのかというのが問題です。

$x = y ⟺ x \leq y \land x \geq y$ というのは皆さんもおなじみかと思いますが、これを言い換えると、 $x = y ⟺ x \leq y \land \neg (x < y)$ となります。ということは、次の配列を考えてみるといいのかもしれません。

$nex t_{<} [i] = min {j ∣ j > i, d_{j} < d_{i}}$
$nex t_{\leq} [i] = min {j ∣ j > i, d_{j} \leq d_{i}}$

どちらも、集合が empty な場合は $n + 1$ を代わりに入れます。

$next_{<} [i] = next_{\leq} [i]$ の場合、その場所を $p$ とすると $d_{p} \leq d_{i} \land d_{p} < d_{i}$ であるので $d_{p} \neq = d_{i}$ です (1)。逆に、 $next_{<} [i] \neq = next_{\leq} [i]$ の場合、 $p := next_{\leq} [i]$ とすると $d_{p} \leq d_{i} \land \neg (d_{p} < d_{i})$ ですので、 $d_{p} = d_{i}$ であり、間に自身より小さい値は存在しません (2)。よって先述の $r$ が求められたというわけです。

では、 $next_{<} [i], next_{\leq} [i]$ をどう求めるかという話ですが、この集合の中身は Arpa's Trick の説明で書いたものとほぼ同じです。そのため、条件に注意しながら Arpa's Trick を使えば高速に求めることができます。

#include 
using namespace std;
typedef long long ll;

void solve();
int main() {
    int t; cin >> t;
    while (t--) solve();
}
void solve() {
    int n; cin >> n;
    vector a(n), b(n);
    for (int i = 0; i < n; i++) {
        cin >> a[i];
    }
    for (int i = 0; i < n; i++) {
        cin >> b[i];
    }
    vector d(n + 1, 0);
    for (int i = 0; i < n; i++) {
        d[i + 1] = d[i] + (a[i] - b[i]);
    }
    const ll inf = numeric_limits::max() / 4;
    d.push_back(-inf);
    vector dp(n + 2, 0);
    vector next0(n + 1, 0), next1(n + 1, 0);
    ll ans = 0;
    for (int i = n; i >= 0; i--) {
        next0[i] = i + 1;
        while (next0[i] != n + 1 && d[i] < d[next0[i]]) {
            next0[i] = next0[next0[i]];
        }
        next1[i] = i + 1;
        while (next1[i] != n + 1 && d[i] <= d[next1[i]]) {
            next1[i] = next1[next1[i]];
        }
        if (next0[i] == next1[i]) dp[i] = 0;
        else dp[i] = dp[next0[i]] + 1;
        ans += dp[i];
    }
    cout << ans << endl;
}

おわり

明日のブログリレーは @phi_isct さんです。

参考にした資料

https://cp-algorithms.com/data_structures/disjoint_set_union.html
https://codeforces.com/blog/entry/143633
https://repovive.com/contests/10/problems/F
Harold N.G., Robert E.T., (1983) A linear-time algorithm for a special case of disjoint set union, https://doi.org/10.1016/0022-0000(85)90014-5

【競プロ】ざっくり Trace Monoid

alyth_sol — Mon, 31 Aug 2026 12:00:07 GMT

この記事は traP 2026 夏のブログリレー 15 日目の記事です。明日の記事は @Oxojo さんの予定です。

この記事には ARC194E Swap 0^X and 1^Y のネタバレが存在します。

文字列に連結演算を入れた構造は、モノイドの公理以外の関係式を持たないことから free monoid と呼ばれています。ここに一部の文字間での可換性を課した構造は free partially commutative monoid あるいは trace monoid と呼ばれ、並列計算におけるジョブ同士の関係を表現できることからコンピュータサイエンス方面でも研究されているらしいです。

「一部の文字ペアについて、その 2 文字での隣接 swap が禁止されている。このとき隣接 swap を繰り返して文字列 $S$ から文字列 $T$ に変換できるか？」という問題の判定法を提示することを目標とし、trace monoid の性質をざっくりと紹介していきます。

この記事は Trace monoid (en-Wikipedia) を参考にして作成されました。有名な本・記事とは異なる表記をしている可能性があることに注意してください。

定義

以下において "swap" は文字列上で隣接した文字を入れ替える操作を指します。
$Σ$ をアルファベットとします。種類数を $σ = ∣Σ∣$ と書くことにします。
$Σ^{*}$ を文字列全体の集合とします。特に空文字列を含みます。
dependency relation $D \subset Σ \times Σ$
- 対称的かつ反射的である必要があります。
- swap が禁止されたペアの集合です。同じ文字同士は swap 禁止とします。
independency relation $I := Σ \times Σ ∖ D$
- $D$ の性質から、 $I$ は対称的かつ非反射的になります。
- swap が可能なペアの集合です。
trace $\equiv$
- 文字列 $x$ から swap を何回か行って文字列 $y$ に変換できるときに $x \equiv y$ と書きます。
- 正確には $x ab y \sim x ba y (x, y \in Σ^{*}, (a, b) \in I)$ で定義される二項関係 $\sim$ の反射推移閉包で定まる同値関係です。
trace monoid $M := Σ^{*} / \equiv$
- この記事では使わないので、分からなくても大丈夫です。
- $[x] [y] := [x y]$ は well-defined なので商集合にも連結演算が入ります。

簡約律 (Cancellation Property)

文字列に対し、文字 $a$ として一番右に現れる位置を最右 $a$ と呼ぶことにします。
文字 $a$ を含む文字列 $x$ について、最右 $a$ を削除して得られる文字列を $x \div a$ と書きます^[1]。

右簡約律 $x \equiv y ⟹ x \div a \equiv y \div a$ が成立することを示します。

(証明)
$x$ から $y$ に変換する過程を $x = w_{0} \to \dots \to w_{n} = y$ と置く。また、文字列 $w_{i}$ を最右 $a$ で分割して $w_{i} = p_{i} a q_{i}$ と置く。過程 $w_{i} \to w_{i + 1}$ について

操作に最右 $a$ が関わらないときは $p_{i} \equiv p_{i + 1}$ かつ $q_{i} \equiv q_{i + 1}$
関わるときは $p_{i} q_{i} = p_{i + 1} q_{i + 1}$

であるから $p_{i} q_{i} \equiv p_{i + 1} q_{i + 1}$ が成立する。 $x \div a = p_{0} q_{0} \equiv p_{n} q_{n} = y \div a$ より示された。

左簡約律 (最左削除) も同様にして示せます。系として、文字列 $a, b$ に対し $a x b \equiv a y b ⟺ x \equiv y$ が成立します。

射影による trace 判定 (Projection Lemma)

文字集合 $S \subset Σ$ に対し、文字列 $x$ から $S$ に含まれる文字だけを残してできる文字列を $π_{S} (x)$ と書きます。これは $S$ への射影と呼ばれます。

任意の swap 禁止ペア $(a, b) \in D$ について、swap の前後で ${a, b}$ への射影が不変量になることは簡単に分かります。逆に変換可能かどうかは、禁止ペアへの射影が全て一致しているかを見ればよいというのが、以下の Projection Lemma^[2] です。

^{\forall} (a, b) \in D, π_{{a, b}} (x) = π_{{a, b}} (y) ⟺ x \equiv y

証明 1

$⟹$ を文字列長に関する数学的帰納法で示します。

(証明1)
仮定より $π_{{c, c}} (x) = π_{{c, c}} (y)$ であるから、文字 $c$ が現れる回数は $x, y$ で等しく、特に $∣ x ∣ = ∣ y ∣$ である。

文字列長 $0$ のとき明らかに成立する。 $∣ x ∣ \geq 1$ のときを考える。

文字列 $x$ の末尾文字を $a$ と置く。仮定から $y$ の最右 $a$ を末尾まで swap させることが可能であると分かるので $y \equiv (y \div a) a$ である。

文字列長 $∣ x ∣ - 1$ の Projection Lemma を仮定すると、 $(x \div a, y \div a)$ に適用することにより $x = (x \div a) a \equiv (y \div a) a \equiv y$ が得られて、文字列長 $∣ x ∣$ の Projection Lemma が示される。以上の議論に数学的帰納法を用いればよい。

文字列長の和を $N = ∣ x ∣ + ∣ y ∣$ と置きます。射影ごとに文字列を走査するナイーブな方法で $O (∣ D ∣ \cdot N)$ で計算できます。文字ごとの出現位置リストから計算したり、一回の走査で並行して射影を構築したりすることで $O (σ N)$ になります。

後者の方法について、射影を Rolling Hash で表現させると面白い気がします。モノイドが載るデータ構造を利用して部分文字列を調べたり、文字列の累乗が計算できるので例えば $w^{p} x^{q} \equiv y^{r} z^{s}$ かどうか判定したりすることができます。ここにお好みの Rolling Hash に関する典型を追加してください。おまけに空間計算量が落ちます。

証明 2

他の証明も載せます。アルファベット $Σ$ に全順序が定まっているとき、文字列 $x$ から変換可能な辞書順最小の文字列 $f (x)$ を構築できます。これを標準形 (すなわち同値類の代表元) とすることで trace 判定ができます。

射影は元の文字列のインデックスに関する情報を持たないため dependency graph (en-Wikipedia) というものを経由して Projection Lemma を証明します。

(証明2)
文字列 $x$ に対し、 $V = {1, \dots, ∣ x ∣}, E = {(i, j) : i < j \land (x_{i}, x_{j}) \in D}$ としてグラフ $G = (V, E)$ を定義する。このグラフは DAG である。

$G$ のトポロジカル順序を受け取り、その順番で文字を並べてできる文字列を返す写像は単射である。また、この写像の像は $x$ から変換可能な文字列全体の集合である。よって、文字 $x_{i}$ を重みとする辞書順最小のトポロジカル順序により生成される文字列が求める文字列 $f (x)$ である。

$(V, E, ϕ : V \to Σ)$ が次の条件を満たすとき dependency graph と呼ぶ。

グラフ $(V, E)$ は DAG である。
$(ϕ (i), ϕ (j)) \in D$ ならば頂点 $i, j$ 間にいずれかの向きの辺が張られている。

また、dependency graph $(V, E, ϕ), (V^{'}, E^{'}, ϕ^{'})$ の同型性は次のような全単射 $g : V \to V^{'}$ が存在するかで定義される。

グラフ $(V, E), (V^{'}, E^{'})$ は $g$ によって同型である。
任意の頂点 $i \in V$ に対して $ϕ (i) = ϕ^{'} (g (i))$

Projection Lemma の仮定を満たすとき、作られる dependency graph は同型を除いて一意であり、関数 $f$ の値を求めるアルゴリズムは dependency graph の同型性に関して不変なので $f (x) = f (y)$ が導ける。

グラフの辺は定義通り張る必要はなく、射影において隣接する頂点に張ればよいです。計算量は $O (σ N)$ です。

ARC194E

ARC194E Swap 0^X and 1^Y / 公式解説

正整数 $X, Y$ および長さ $N$ の 01 文字列 $S, T$ が与えられる。 $S$ の部分文字列 $0^{X} 1^{Y}$ を $1^{Y} 0^{X}$ に置き換えたり、その逆ができるとき、 $S$ を $T$ に一致させることは可能か判定せよ。

公式解説の前半の言い換えは同様に行います。
$0^{X}, 1^{Y}$ の塊を表す文字 $A, B$ を導入してアルファベット $Σ = {0, 1, A, B}$ とします。現れる $0^{X}, 1^{Y}$ の塊を貪欲に $A, B$ に置き換えるようにして 01 文字列を $Σ$ 文字列に変換したのち、 ${0, A}, {1, B}, {A, B}$ でのみ swap 可能としてもよいです。あとは $S \equiv T$ かどうかの判定をするだけです。

公式解説の後半はアルファベットに $A < 1 < 0 < B$ あるいは $A < 0 < 1 < B$ という順序を入れ、射影から辞書順最小の文字列が一意に定まることを ad-hoc に証明しています。 ${0, 1}$ は swap 禁止ペアなのでどちらの順序を選んでもよいです。

この性質が一般の場合で成り立つという話でした。以上。

あとがき

Gemini に上の問題を投げたら面白そうな話題を返してくれたので、少し勉強して記事にしてみました。よく見返したら Projection Lemma の証明に簡約律を使っていないことに気付いたのですが、消すのも勿体ないので残すことにしました。

trace monoid には面白い話が残っていそうなので、誰か書いてください、頼みました……

この記事は traP 2026 夏のブログリレー 15 日目の記事です。ぜひリンクから他の記事も閲覧してみてください。明日の記事は @Oxojo さんの予定です。

参考にした Wikipedia の記事では文字 $a$ を含まない文字列についても定義されていたが、ここでは未定義とする。 ↩︎
Mathematics Stack Exchange の回答において Projection Lemma と呼ばれているが、一般的に何と呼ばれるかは調べていない。 ↩︎

春ハッカソン参加記「以線伝心」

yasako — Mon, 31 Aug 2026 06:00:02 GMT

今回の春ハッカソンでは、「以線伝心」というゲームを作りました。投票の結果、アイディア賞をいただきました！

春ハッカソンでは、「Web」「ゲーム」「映像作品」のいずれかを作ることが多いです。私たちの班では、Web技術で協力ゲームを作ることにしました。

作ったゲームのルールは、次のような感じです。

ルール

最大9人が部屋に参加可能
漢字を推測する人が一人選ばれる
残りの人が一画ずつ順番に直線を引き、お題として示された漢字を表現する
条件
- 最大9画しか描けない
- 直線しか描けない
- 確定後は線を描き直せない

実際に遊んでいる様子

お題：「陵」

線を書いている様子（書き途中の線は点線）

推測している様子（お題は表示されない）

プレイ画面

メンバー紹介

@yasako 25B リーダー、フロントエンド
@akimo 24B バックエンド
@y_33550336 25B バックエンド
@cuptea 26B フロントエンド、デザイン
@yadorigi 26B フロントエンド、デザイン
@soy4040 23B バックエンド

開発の様子

今年の春ハッカソンは昨年とは違い、メンバー発表が本番の一週間前でした。

準備期間

準備期間は、対面で1回、Discordで3~4回ほど集まって、何を作るのか相談しました。全員が集まれたのは、初回の対面での話し合いのみでしたが、来れなかった人も話し合いの議事録を読んで内容を把握してもらいました。

話したときのメモの様子を載せます。

アイディアをみんなで出している様子

作るものが決まった（この時点では、まだ協力ゲームではなく対戦形式）

細かい仕様を検討している様子

ゲームとして成立するのかをFigmaで試している様子（右側に書いてあるのは上から「組」「阻」「読」「書」）

本番

本番の様子を、フロントとバックエンドそれぞれで振り返ります。

デザイン・フロントエンド

初日は主にデザインや仕様の確定、ゲームの状態管理部分の実装をやっていました。

@cuptea @yadorig がデザインを作っている間、@yasako はゲームの進行度合いの管理部分を実装をしていました。デザインが確定したところで、@cuptea @yadorig にそれぞれのページを順番に作っていってもらいました。

バックエンドができるまでの間、決まった動作しかしないモックサーバーをAIに書かせ、フロントエンドの動作確認をしていました。

バックエンド

必要なエンドポイントやゲーム中に発生するイベントは前もって整理しておいたので、それらに対応する空のメソッドだけ最初に用意して @soy4040 @y_33550336 の2人に実装していってもらいました。事前に決めていたのは「サーバーがどう振る舞うべきか」という部分だけで、具体的な実装は各自で考えながら進めてもらうという形です。@akimo はPRのレビューをしたりお菓子を食べたりしていました。

感想

@yasako (リーダー、フロントエンド)

フロントエンドを担当しました。昨年度の春・1-Monthon・冬に続き四回目のハッカソンで、Web班のリーダーは二回目です。今回のハッカソンでは初めてWebゲームにチャレンジしました。遊んでて面白いゲームを作れてとても満足してます。

フロントエンドの二人には、デザインをしてコンポーネントを作り、コンポーネントを組み合わせて画面を作っていき、サーバーから取得したデータを流し込む、という開発の流れを体験してもらいました。「ごめん、それについて説明し忘れてた！」と言ってばかりだったと思うのですが、僕の分かりやすいとは言えない説明を頑張って聞いてくれてありがとうございます！途中僕が寝落ちしてしまったときもうまく進めてくれててありがたかったです。

短い準備期間の中でいろんなアイディアを出してくれたみんなのおかげで、遊びがいのあるゲームを作ることができました！ありがとう！！！

（ブログの完成が遅くなってしまいすみません...！）

@y_33550336(バックエンド)

バックエンドを担当しました！去年の春ハッカソンでは理解していることが少なく、少し悔しい思いをしました。そのため、一年間頑張って様々なプロジェクトに参加するなどしていろいろなことを学んできました。まだまだ初心者でよく分からないことも多いのですが、何か新しいことに挑戦してみたいと思い、WebSocketを用いた開発をやってみたいと提案したところ、班のみなさんにも快く賛同していただきやってみようということになりました！
準備期間では、技術選定やテーブル設計などの細かい部分はまだ慣れておらず、ほとんどの部分をakimoさんにお任せしてしまいましたが、分からないところは質問してなんとか自分もできるところは頑張れたと思います。
ハッカソン当日では、データベースやいくつかのエンドポイントを担当したのですが、思ったより分からないところが多くて他のバックエンドの方に迷惑をかけてしまったことも多かったかもしれません…ですが、たくさんのサポートをしていただきながら最後までなんとかやりきることができました！
去年よりも分かることやできることが増えたということを実感できたことがとてもうれしく、頑張った成果が表れてよかったです！
良いメンバーに恵まれて、みんなで考えた案でアイデア賞もとることができてとても充実したハッカソンとなりました！

@cuptea (フロントエンド、デザイン)

フロントエンドとデザインを担当しました。高校では高々2人で共同制作していた程度で、この春ハッカソンが人生初めてのハッカソンでした！
使うフレームワークがVue.jsだったり作るものがブラウザゲームだったりと、今まで食わず嫌いで触れてこなかった分野にチャレンジでき、今後のハッカソンに出場するモチベーションが沸きました。
チーム制作初心者の僕でも楽しんで2日間を過ごせたのは、リーダーのやさこさんを始めとしたメンバーの皆さんのおかげです。本当にありがとうございました！

@soy4040 (バックエンド)

23Bにもかかわらず春ハッカソン初参加 & ほぼ初のチームでの開発でした。
最初は何をすればいいか全く見当がついていなかったのですが、やさこさん、あきもさん、わいごさんなどなどに助けられながら楽しく開発を進めることができました。
26Bのお二人もバリバリフロントエンドを書いていたようで、本当にすごいと思いました…！
終始楽しいハッカソンでした！チームメンバーへの感謝でいっぱいです。

@akimo (バックエンド)

バックエンド、APIの設計や後方腕組みを担当しました。僕が頑張ったのは主に事前準備で、開発期間中は実装を他の2人がやってくれているのを頼りになるな〜と思いながら眺めていました。昨年の春ハッカソンでは事前準備が足りないと感じていたので、その反省を活かして設計を煮詰めてから本番を迎えられたのは良かったです。

一方で、自分を過信して動作確認を全く行っていなかったのは今回のハッカソンの反省点ですね。実際に動かしてみると大量のバグが見つかり、結局試遊会の時間に動かすことはできませんでした。ハッカソンだからと手を抜いていましたが、仕様は自動テストで保証すべきであるという当たり前のことを痛感させられました……。

ともあれ、ゲームのサーバーを書く機会はあまりないので設計などを考えるのは楽しかったです。たくさん面白いアイデアを出してくれたチームメイトに感謝。今回は参加するか迷っていたけど、参加して良かった〜！

@yadorigi (フロントエンド、デザイン)

大学入学までほとんどプログラミングやweb開発には触れてこず、今回のハッカソンが初めての制作でした。web開発どころかプログラムの書き方や制作で使った様々なツールの使い方すらおぼつかない状態での参加となってしまい、自分が貢献できた部分はほんの少しですが、それでも自分が考えたデザインのページが表示されたり自分でコードを書いて作った画面が動いていたりするのを見る度に、自分のつくったものがゲームに貢献できていると感じられて、制作の楽しさや達成感を感じることができました！また、技術的な学びやチームでの開発の進め方の知見も多く得られて、参加して良かったと思える充実したハッカソンでした。

熱心に制作を進めてくださり初心者の私にも優しく接してくださったチームメンバーの皆さん、そして台風という変則的な状況の中でハッカソンを最後まで進行してくださった運営の方々には、本当に感謝してもしきれません。短い開発期間の中でここまで作品を形にできた、そしてアイディア賞までいただくことができたことを心から嬉しく思います！ありがとうございました！

Made in traPを実現した設計技術

hijoushiki — Sun, 30 Aug 2026 15:13:55 GMT

こんにちは、hijoushikiです。先日traPのゲーム班内で開催された、新入生向けミニゲーム開発イベント「Made in traP」にて、リードプログラマとして全体の設計や実装を担当しました。この記事では、Made in traPを実現した技術的背景について紹介します。

【総勢41名】『Made in traP』を作りました

９年越しの悲願、実現...!! どうも、YMACです　Game班の班長をしています 2026年4月から7月にかけてを新入生向けミニゲーム開発イベント「Made in traP」を開催・そして完成しました！！！！ Made in traPとは？要するにメイドインワリオ的な感じで、連続で出現するミニゲームをクリアしていくゲームです！一定ゲームをクリアするとレベルアップしてミニゲームが難しくなっていき、４回ミスるまでエンドレスに続いていきます ↑こんなミニゲームもあるよミニゲームは主に26B（今年の新入生）に制作してもらっています！春ハッカソン後の初めての個人制作ということで、なかなかハードなものではあったと思いますがみんなしっかりと動く作品を作ってくれてお兄さん嬉しいよ遊べます ↓基本WASD＋スペース＋マウス（たま〜にキーボード）で操作できます！ https://unityroom.com/games/made-in-trap ミニゲーム突破数がランキングになってます、目指せハイスコア...!! CREDITS 総勢、４

東京科学大学デジタル創作同好会traPYMAC

要求仕様

Made in traPを実現するためには、最低限以下の問題を全てクリアする必要がありました。

ゲーム本体からミニゲームが呼び出せなければならない

Made in traPのキモは、ミニゲームを次々にプレイできることです。つまり、ゲーム本体から何かしらの手法でミニゲームを呼び出し、ミニゲームを動作させ、制限時間が過ぎればミニゲームを片付けてゲーム本体に復帰する必要があります。

簡単に思い付く方法は、ゲーム本体のSceneから SceneManager.LoadScene("MiniGameSceneName") を使用してミニゲームのSceneに遷移することでしょう。しかしその場合、ミニゲームのSceneに遷移したらゲーム本体のSceneは破棄されてしまいます。進行中のゲームの状態はどう保存するか？ミニゲームの制御はどうやるか？どうやってミニゲームのSceneからゲーム本体のSceneに復帰するか？Loadに必要なミニゲームのSceneの名前はどう取得するか？そもそも、この手法ではSceneの切り替わりの関係で、原作のようにゲーム本体とミニゲームを滑らかに繋ぐことができないため、美しくありません。

普段の開発とほとんど同じようにコードが書けなければならない

Made in traPの目的は、新入生をその後の本格的なゲーム開発に繋げることです。そのため、コードの書き方や制限など、Made in traP特有の都合にミニゲーム側が過度に振り回されることはあってはなりません。

ただ、最低限ミニゲーム側とゲーム本体側は互いにやり取りできる必要があります。例えばミニゲームの成功/失敗の通知などです。その場合、using MadeInTrap.SDK.API として、MiniGameAPI.SendResult(bool isSuccess) というような形で、ゲーム本体にミニゲーム結果を簡単に送れるようにしなければなりません。

ゲーム本体とは独立したプロジェクトでミニゲームが作れなければならない

ミニゲームを作る時、ゲーム本体のUnityプロジェクトをCloneし、そのプロジェクト上でミニゲームを制作する形は美しくありません。ゲーム本体を意図せず変更してしまうかもしれませんし、ゲーム本体のGit履歴もミニゲームを作る上では不要です。新しくゲームを作るのですから、新しいプロジェクトでミニゲームを作れるようにするべきです。

ミニゲーム単体で再生できなければならない

ゲーム本体とは別のプロジェクトでミニゲームを作れるようにするのなら、ミニゲームはゲーム本体から呼び出して再生するだけでなく、それ単体でも再生できる必要があります。テストプレイのためにいちいちゲーム本体を通すのは開発体験が悪すぎます。

ミニゲームが提出できなければならない

ゲーム本体とは別のプロジェクトでミニゲームを作れるようにするのなら、ミニゲームをゲーム本体に提出する手段が必要になります。ミニゲームを .unitypackage として出力するのが順当でしょうが、単にそうするだけでは参照切れが発生するかもしれません。

提出するミニゲームがレギュレーションに従っているか判別できなければならない

使用可能なライブラリや、変更してはいけないPrefab、使ってはいけない文字、提出の形式など、ミニゲーム側が最低限守らなければいけないルールがあります。それが実際に守られているかを事前に判別する方法が無ければ、ミニゲーム制作者はミスに気付けず、運営側がゲームを個別に検証して修正する手間も膨大になります。

アーキテクチャ設計

アーキテクチャの説明をしてから、ミニゲームを制作して動かすまでの一連の技術を解説します。

まず、全体のアーキテクチャを以下のように設計しました．

技術スタックは以下の通りです。

UniTask
R3
VContainer
LitMotion

ポイントは、システム全体をHost, SDK, MiniGameの3つのサブシステムに分割していることです。

Host: ミニゲームを呼び出すゲーム本体
SDK: HostとMiniGameを繋ぐ部分。MiniGameには、ミニゲームの結果をHostに通知するAPIなど、ミニゲーム開発に必要な機能を提供し、Hostには、MiniGameの生成や結果の取得など、MiniGameへ干渉する窓口となる
MiniGame: ミニゲーム

特に注目したいのが依存関係です。HostとMiniGameが互いに依存せず、どちらもSDKに依存しています。これにより、HostはMiniGameの内容を知る必要がなく、MiniGameもHostの実装を知る必要がありません。よって、HostとMiniGameが切り離し可能になり、SDKをPackage Managerで配布することによって、Hostとは独立したプロジェクトでMiniGameが作れるようになっています。この話はまた後ほど詳しく解説します。

Host

Hostは、ミニゲームを呼び出すMade in traPというゲーム本体部分です。Hostは以下の5つのレイヤーに分かれています。

Model: MVRPパターンにおけるModelに相当する部分
View: MVRPパターンにおけるViewに相当する部分。唯一 MonoBehaviour の継承を許可している
Director: ModelとViewの仲介役となり、両者をオーケストレーションする
Infrastructure: 技術的関心 (ここでは主にSDK) を集約する
CompositionRoot: VContainerを用いて依存の解決とEntryPointの起動を行う

これは私がUnity開発で個人的に使っているアーキテクチャです。複雑そうに見えますがやっていることはシンプルで、Pure C#でModelを書き、MonoBehaviour を継承したViewでそれを表示し、Directorで両者を仲介しているだけです。SDKなどの技術的関心はModelからInfrastructureに切り出し、CompositionRootでVContainerを使ってDIをしています。

とりあえず、InfrastructureがSDKを叩いてMiniGameの生成や結果の取得などを行っているということを押さえておけばOKです。その他の部分は今回の本質とは外れてしまうので，またいつかの機会に解説します．

SDK

SDKは、HostとMiniGameを繋ぐ部分です。MiniGameには、ミニゲームの結果をHostに通知するAPIなど、ミニゲーム開発に必要な機能を提供し、Hostには、MiniGameの生成や結果の取得など、MiniGameへ干渉する窓口となります。

SDKはAPIとInternalの2つのモジュールに分かれています。

API: MiniGameが結果の通知をする際などに叩くAPI
Internal: APIの内部実装や、Hostとの接続部分

APIは、using MadeInTrap.SDK.API として、MiniGameAPI から利用できます。APIには例えば以下のようなものがあります。

API	説明
`MiniGameAPI.MiniGameStarted`	ミニゲームのプレイが開始されたときに発火します
`MiniGameAPI.MiniGameEnded`	ミニゲームのプレイが終了したときに発火します
`MiniGameAPI.RemainingTime`	現在のミニゲームの残り時間を取得します
`MiniGameAPI.CurrentLevel`	現在のレベルを取得します
`MiniGameAPI.SendResult(bool isSuccess)`	ミニゲームの結果をHostに通知します

MiniGame

MiniGameは、ミニゲームのことです。SDKを利用してHostで動作するミニゲームを作ります。

例えば、UIのボタンを押したらクリアとなるシンプルなミニゲームの場合、このように記述します。

using UnityEngine;
using MadeInTrap.SDK.API;
using UnityEngine.UI;

namespace MadeInTrap.MiniGame.TestMiniGame_0
{
    public class GameManager : MonoBehaviour
    {
        [SerializeField] Button clearButton;

        void OnEnable()
        {
            clearButton.onClick.AddListener(Clear);
        }

        void OnDisable()
        {
            clearButton.onClick.RemoveListener(Clear);
        }

        void Clear()
        {
            MiniGameAPI.SendResult(true);
        }
    }
}

普通にゲームを作る場合とほとんど同じなのが分かると思います。ボタンが押されたら、APIを叩いて成功を通知するだけです。このように、最低限APIを利用するだけで、普段の開発とほとんど同じようにミニゲームを作ることができます。

ミニゲームの制作

ミニゲームの制作について詳しく見ていきます。ミニゲームは，個人がそれぞれのUnityプロジェクトで制作し，そのSceneをフォルダごとunitypackageにエクスポートして提出するようにしました．

SDKの配布

ミニゲームを作るにはまず、ミニゲームが叩くAPIや、ミニゲームのSceneのテンプレート、配布素材などが詰まったSDKを取得する必要があります。アーキテクチャ図のSDKの部分です。今回はこれをPackageManagerでGit URLからインストールするようにしました。こうすると、SDK開発側にとってもミニゲーム開発側にとっても、パッケージの管理や更新がとても楽になります。

口で言うのは簡単ですが、SDKを配布できるように作るのは結構難しいです。SDK単体で配布するためにはSDKがHostやMiniGameといった他のサブシステムに一切依存していない必要があります。なので設計段階から依存関係を適切に制御している必要があります。実はSDKを配布できるようにする作業に取り掛かったのは色々あってミニゲーム開発開始の1日前になってしまったのですが、最初から設計をちゃんと考えていたため、ほぼ何もすることなく一発でPackageへの切り出しに成功して感動しました。

制作

ミニゲームの制作は用意されているSceneテンプレートを用いて行います。といっても特別色々なセッティングがされているわけではありません。Made in traPのミニゲームとして動かすために必要な MiniGameController というPrefabと、Canvasが予め置かれている以外はデフォルトの新規シーンと変わりません。

MiniGameController は、ミニゲームに外部から干渉する際の窓口です。ミニゲームのセットアップ、開始、終了などのメソッドを公開しており、これを外から叩くことでミニゲームを制御できるようにしてあります。Prefabには、スクリプトの MiniGameController の他に、後述する単体テストや提出チェックのためのスクリプト、ミニゲーム中に表示するタイマーのUIと効果音のAudioSourceなどが含まれています。

Canvasは、どうせミニゲームを作るときに使うだろうということで最初から置いています。ただそれだけではなく、ミニゲームのSceneに存在する全てのCanvasのRender Modeが必ず Screen-Space Camera になるように最初からセットしておくためでもあります。これは後述するミニゲームの生成時に必要になってきます。

単体テスト

ミニゲームは普段通りSceneを再生することで、Hostを使わず単体テストできます。一見当たり前のように聞こえますが、再生時にタイマーのUIやAPIもちゃんと一緒に動作させる必要があるので一筋縄にはいきません。特に、ミニゲームの時間やレベルといった状態は本番再生時はHost側が保持しているので、単体テスト時にはHostの代わりとなるモックに切り替えられるようにする必要がありません。

この部分について詳しく説明します。 MiniGameAPI には、ミニゲームの残り時間 float RemainingTime や、ミニゲーム結果を通知する SendResult(bool) などのAPIがあります。これが叩かれると、MiniGameAPI はミニゲームの実行元を保持している MiniGameAPIRuntimeConnection を叩いて実行元を取得し、それに対して値の取得や結果の通知を行います。

本番再生時は、Hostの MiniGameRunner が実行元となり、MiniGameController を叩くなどして実際にミニゲームを動かしています。しかし、単体テスト時にはこれは存在しないため、APIの宛先や MiniGameController の叩き役がいなくなってしまいます。

そこで、単体テスト時に動作するモックとして UnitTestMiniGameRunner を用意しました。どちらとも IMiniGameAPIRuntime を実装し、本番再生時には MiniGameRunner を、単体テスト時には UnitTestMiniGameRunner を MiniGameAPIRuntimeConnection に登録することで、本番再生か単体テストかを気にすることなく同じようにミニゲームを動作させています。

提出準備

ミニゲームが完成したら提出の準備に入ります。提出は、アセットを全て1つのフォルダに収め、それをunitypackageとしてエクスポートすることで行います。なので、まずフォルダにSceneやスクリプト、スプライトなどを全て収めます。

次に、提出するフォルダの直下に MiniGameInfoSO というミニゲームの情報を記述するScriptableObjectを作成します。ここにSceneの名前や制作者名などの情報を記述します。Hostではこれを収集することでミニゲームの情報を管理します。

提出チェック

提出するにしても、MiniGameInfoSO が無かったり、必要なPrefabが適切に配置されていなかったり、フォルダ外のアセットを参照していたりしたら、Hostで正しく動作させることはできません。そのため、これらレギュレーションに違反していないかを検証する提出チェックを事前に走らせます。

MiniGameController Prefabに MiniGameSubmissionCheckTarget というスクリプトがアタッチされています。これに MiniGameInfoSO を割り当てることでそのフォルダを提出フォルダと認識し、チェックが走ります。

この機能が今回のMVPだと思っていて、この機能は元々追加する予定が無かったのを、私が「これあった方が良くね？」と思って独断で実装したものです。すると案の定本番では、Prefabの値が変更されている、使ってはいけない文字コードを使っている、使ってはいけない入力APIを使用している、といったレギュレーション違反が多発し、それらを事前にブロックすることができました。もしこれが無かったら、提出された全てのミニゲームをひとつひとつ検証して修正する必要があり、我々は発狂していたことでしょう…

エクスポート

提出チェックが通ればフォルダをunitypackageにエクスポートして提出します。

Hostの動作

次に、Hostが提出されたミニゲームを登録し、実際にゲーム上で再生するまでの流れを見ていきます。

ミニゲームの登録

提出されたミニゲームのunitypackageをインポートします。提出チェックに通っていれば、参照切れも発生せず問題なくミニゲームをインポート可能です。

インポートしたミニゲームのSceneを、Build ProfilesのScene Listに登録します。これをしないとSceneをLoadできませんからね。加えて、MiniGameInfoSO に MiniGameInfo のAddressableのラベルを付与します。これにより、Addressables.LoadAssetsAsync(config.MiniGameInfoLabel, null); でラベルを付与した全ての MiniGameInfoSO を取得することで存在するミニゲームの情報を全て取得することができます。

ミニゲームの生成

Hostからミニゲームを生成します。これには、MiniGameRunner が SceneManager.LoadSceneAsync("sceneName", LoadSceneMode.Additive) でミニゲームのSceneをAdditiveにロードし、SceneManager.SetActiveScene(scene) でアクティブSceneに切り替えています。つまり、Hostのシーンに重ねてミニゲームのシーンをロードしているということです。

ミニゲームの生成方法には3つの選択肢がありました。ミニゲームのSceneに直接遷移する方法、Additiveにロードする方法、ミニゲーム自体をPrefabとして提出してもらい、それを生成する方法です。

直接遷移する方法では、普通にやると遷移によりHostの状態が失われるため、状態の保存が問題になります。また、ミニゲームを表示するときのアニメーションがどうしても制限されてしまいます。

Prefabでやる方法はかなり不自然に感じます。提出や管理が難しいのもさることながら、ミニゲーム側で動的に生成されたゲームオブジェクトをどう管理するかが問題になります。

Additiveに読み込めば、Hostの状態は保存され、ミニゲームのカメラ映像をテクスチャに描画することで表示アニメーションもスムーズに行えます。また、動的に生成されるゲームオブジェクトは現在のアクティブシーン上に生成されるという仕様があるので、ミニゲーム中はミニゲームのSceneをアクティブにすることで、ゲームオブジェクトを確実にミニゲーム側で生成させることができます。そうすればScene破棄時に一緒に消えてくれるのでゴミは残りません。

ミニゲームの表示

単にAdditiveに読み込んだだけでは、HostのSceneとミニゲームのSceneが混ざり合ってしまいます。ミニゲームの映像を映した画面をフェードさせたりもしたいので、何らかの方法でミニゲームをHostのカメラに映らないようにし、ミニゲームのカメラ映像をテクスチャに描画してHostのUIに表示させるということが必要になります。

Hostのカメラからミニゲームを除外するには、ミニゲームのSceneに存在する全てのゲームオブジェクトのLayerを MiniGame に書き換え、HostのカメラのCulling Maskで MiniGame Layerを除外しています。Layerの書き換えは MiniGameController が行っています。

ミニゲームのSceneのカメラは camera.targetTexture = renderTexture; によって映像の描画先をテクスチャに変更し、そのテクスチャをHostのRawImageに表示させています。これによりミニゲームのカメラ映像をHostに表示することができ、RawImageをフェードさせたりすることで表示アニメーションもスムーズに実装できます。

ここで重要になるのが、ミニゲームのSceneに存在する全てのCanvasのRender Modeを Screen-Space Camera にすることです。これにより、Canvas上のUIもカメラの描画対象になり、他のゲームオブジェクトのようにテクスチャに描画することができます。Screen-Space Overlay の場合、Canvasはカメラを経由せず画面そのものに直接描画されます。そうなると、RawImageのフェードアニメーションが適用されず、表示が不自然になってしまいます。

入力のフォワーディング

次に問題になるのが、ミニゲーム側に入力をどう渡すかです。キー入力の場合、ミニゲーム側でInputSystemの設定をしていればキー入力がそのまま効きます。

問題なのはマウス入力です。マウス入力はそのままでは全く効きません。なぜなら、画面に映っているのはミニゲームのSceneのカメラ映像を投影したRawImageであり、そこに実際にミニゲームのオブジェクトが存在するわけではないからです。よって、RawImageに対するマウス入力を何らかの方法でミニゲーム側に送り、そこでイベントを手動発火させるという荒業が必要になってきます。

まず、RawImageにアタッチされた MiniGameScreenView が、マウスクリックやホバーといったマウス入力を受け取ります。その際、RectTransformUtility.ScreenPointToLocalPointInRectangle() を用いてRawImage内のマウス座標をUV座標に変換します。

次に、マウス入力の情報から MiniGamePointerInput を生成します。これは入力の内容やUVといった情報を保持することでマウス入力を表す構造体です。そしてこれを様々なクラスを経由して MiniGameController まで運びます。

入力を受け取った MiniGameController は、入力を元にミニゲームのSceneのEventSystemを直叩きし、eventSystem.RaycastAll(eventData, raycastResults); でミニゲーム内のオブジェクトをRaycastします。

最後に、Raycastしたオブジェクトに対して ExecuteEvents.Execute() などを叩くことで、マウスイベントを手動発火します。これにより、RawImageに対するマウス入力をミニゲームのSceneに手動で展開することができます。

ただし、この手動発火したマウスイベントをミニゲームのスクリプトで受け取るには、IPointerClickHandler といったEventSystemインターフェースを利用して実装する必要があります。逆に、それ以外の方法でマウスイベントを扱うことはできません。例えば、Mouse.current.position ではHostウィンドウのマウス座標をそのまま取得してしまい、ミニゲームのScene用に手動で補正された座標を使用できません。

感想

私が普段考えているような設計は、Unityで実際にゲームを作るうえではどうしても過剰になりやすく、私の設計力をフルで活かせる場面は今までありませんでした。しかし今回、設計をちゃんと考えたからこそこのゲームを完成させることができたと思う場面が何度もあり、作っていてとても楽しかったです。こんな素晴らしい機会をくれたYMAC君を始めとするゲーム班の皆様に圧倒的感謝！

「1-Monthonの進捗は？」「なぜか別のMMORPGができました」ーClustyle開発記

sorane_yaduki — Sun, 30 Aug 2026 10:08:11 GMT

この記事は夏のブログリレー2026、14日目の記事です。

はじめに

どうも、雑食ゲーマーで(ほぼ)全創作をやっている、多声類の夜月そらねです。

気づいたら、MMORPGの運営やってました。

…というわけで、流石に何か書き残そうかなぁ、と、筆を執りました。ではでは、早速、ゲーム概要から。

ゲーム概要

Clustyle(クラスタイル)という、ブラウザで遊べるMMORPG。

プレイヤーは、素材を集めて武器や装備を作ったり、売ったり、それを使って戦ったりできる、というゲームです。

自由度の高さと、プレイヤー間の商売の多さが特徴でしょうか。

武器一つ作るにも、パーツを組み合わせて作ります。

例えば、片手剣なら柄+鍔+刃、大剣なら柄+刃+鍔+プレート…というように、武器によって異なります。

そして、パーツのステータスを左右する、８段階の品質とランダムなボーナス！

属性を考えながら組み合わせ、相棒ともいえる武器を作れます。

属性に関しても、相性だけでなく、親和性や属性技能があり…

いろいろ語りたくはありますが、長くなるのでこのくらいにしておきます。

とりあえず、やってみてくれたら嬉しいな…

Clustyle

開発環境

Cloudflare、GitHub、そしてChatGPTを使っています。ChatGPTはPlusで、最初にシステム面などを用意させていたときはWork、それ以外は基本的にChatを使ってます。

ゲームを作る環境とは思えないね。

月曜日

「面白そう」

夜、とある「ポチゲー」と言われるジャンルのゲームにハマっていた私は、ふと思いました。

「作れたら面白そう」

突発的な思いつきでしたが、ここがスタート地点になりました。

その日は「どんなのを作りたいか」だけ空想して、就寝。

火曜日

「まずは勉強から」

調べて発覚、小規模でやるだけなら、サーバー代はかなり安く済む。ここで、目の色が変わります。お金の問題は何とかなりそう。

あれ？行く手を塞ぐものがいなくなった？

ダメですよ。

行動力だけはあるやつのストッパー外しちゃ。

実装はAI任せにするつもりでしたが、流石に責任がある程度生じる以上「知らん」じゃダメだろと思い、サーバーの勉強。１日バイトがあったのですが、昼休みにお昼ごはん食べる場所探しながら、お昼食べながら、戻りながら、ChatGPTと壁打ちして勉強しました。

帰宅中もずっとやり、夜寝る前になってようやく一通り知識を詰め込めました。

バイトの空き時間に、ゲームのイメージを固めつつあったので、壁打ちで仕様を固め始めたところで就寝。

水曜日

「カタカタカタカタカタカタ…」

朝から飛行機で祖父母の家へ。飛行機内では作業進まず。昼前に到着し、ひたすら夜まで仕様を詰めていく。

最終的に、PDF17ページほどの仕様書にまとめ、ワクワクしながら就寝。

木曜日

「えぇ、できちゃうの？」

朝になって、昨日まとめた仕様書を全部読み、謎テンションで変な仕様になってしまっているような場所がないかチェック。特に問題なく、実装へ。

サーバーを準備したり、環境構築したりして、昼前に終了。

並行して、企画書プラスで必要な仮データを用意。まとめて生成AIに渡し、実装してもらう。

形になっていてビビる

触ってみて、挙動がおかしいところ、UIが不親切なところを列挙して渡し、修正させるというのを夕方まで繰り返す。そして、高校の時の友人数名に招待コードを渡し、試してもらう。フィードバックと修正を繰り返す。

金曜日

「終わりという名のスタートライン(オープンβ)が見えてきた」

朝起きて、来てたバグ報告だけ軽く直し、ここでオープンβを考える。

何をするべきか考え、オープンβ用に要素を一気に拡張しようと、クローズドβの3エリアから、12エリアまで拡張。さらに武器種を3種から9種に増やし、武器パーツも一気に増やす。敵も相応に増やし、敵の名前、属性、特徴、ゲーム上の役割を考え、ChatGPTにステータスを仮組みさせる。調整し、ボス枠を設定し、ドロップ設定…

と、一番地道な作業。

夜になって、ハッカソンのミーティング。みんな進んだのかな〜、と思って焦りつつ、

「えーと…成果ね…ブラウザで遊べるMMORPGのクローズドβテストまでできた」

って言ったらちょっとウケた。

誰も進んでなかった。

土曜日

「カタカタカタカタポチポチポチポチ(スマホ併用)」

朝からずっと昨日に引き続き、データ考案。

夕方からいとこがほぼ全員集合。夜まで大宴会。

作業進まず　仕様語らず

日曜日

「楽しかったから…まぁいっか」

今日こそオープンβ！と思っていたら、昼前に電話。

「◯◯ちゃん(私のこと)と遊びたいから、遊びに行ってもいい？」

かわいいいとこからの電話。もちろんOK、そして作業は片手間でチマチマ進めることを決意。

夜になって、オープンβ用の要素追加が実装完了。

要素追加したよー、と伝え、就寝。

実をいうと、要素もチェックしてたので、この時点でオープンβ開始できはしたが、「これから寝るタイミングで…？」ということで、明日の朝へ。

月曜日

「ついにこの時が」

朝からオープンβへ！

並行して、ポチゲーポータルへの登録も進める。Xを始めるところから。DMってこれか…？と思いつつ、連絡を取り、ポチゲーポータルに追加！それが夕方くらい。

狭い交友関係ながら紹介して、Discordも盛り上がり始める。

それと同時に届く、莫大なバグ報告。ひたすら対応。そして就寝。

火曜日

「サプライズ！」「！？！？！？」

朝起きてサーバーの状況を見てみると、無料枠じゃアヤシイラインに…念のため、サーバーを有料にアップグレードする。

バグに対処しつつ、夕方空港へ。そして開発者コミュニティで、私が大いに影響を受けたとあるポチゲーの管理人さんが「お、Clustyle出てきた、やってみるか」。

めっちゃ緊張しながら、手続きを済ませ、搭乗ゲート前で待っていると、何やら、Discordが騒がしい。

慌ててそのポチゲーを開いてみると、メンテ告知などをする欄で、まさかのClustyleの紹介が！

管理人さんが、「新しいポチゲーできてるぞー！突撃ー！」というわけで、

同接36人！！

同接がMAX12人程度から、急に３倍…！

飛行機に乗ってからも気が気じゃなかったが、飛行機を降りて確認してみると、やばいバグとかは出てなさそうで一安心。家に帰って、いくつかバグ修正して就寝。

水曜日〜金曜日

「１日100歩も歩いてない」

朝起きて、朝ごはん食べて、バグ修正して、お昼食べてバグ修正して、お風呂入ってバグ修正して、晩ごはん食べてバグ修正、やっと時間ができてアプデターイム！

金曜日頃には、夕方くらいにはアプデに回れるように。

日付感覚なんてないし、今が昼だったか夕方だったかすらわからなくなってくる。ちゃんと寝てはいる。

１日のサイクルではなく、アプデやバグ修正に基づいた、一直線の時間軸に、今私は生きている。

楽しい。

同接も順調に増え、18人くらいまで膨らむことも。基本常に10以上、Discordはいつもにぎやかで、安定してきたな〜、という感じ。

土曜日

「正式リリースって、休み前にやりたいよね」

朝からテスト環境と本番環境の分離やロールバックの準備などを進める。

夕方になってから、正式リリースにふさわしい要素追加(新リージョン追加)をするべく、仕様書を書き始める。

ChatGPTに実装させてる間に仕様書がさらに３つ(うち２つ大型アプデ)増える…このままでは正式リリースできないと悟り、

日付が変わる前に正式リリースするために、スプラをやるという奇行に走る。

次々と仕様書を書いていくには、私の想像力は少し高すぎた。

そして日付変更とほぼ同時に正式リリース！

…というわけで、これが昨日までの流れです。

これを書いている、2026/8/30現在、登録ユーザー数が249人、過去24時間でのアクティブユーザー数は87人、直近５分のアクティブユーザー数が16人です。

感想

完走してない感想ですが、書き残しておきます。

廃人、怖い

夜中も朝も、もちろん昼も、少なくとも1時間に１回くらいはDiscord鯖で話してたやつがいるんですよ…なぜかβテストの段階で、全装備最高品質で揃えてたり。バランス調整するときは、そういう人を基準にしないようにしつつ、外れ値な人がいても大きく狂わないようにしましょう。

ヘルプは読まれない

読む人もいますよ？でも、ほとんどの人は読みません。「ヘルプ読めばわかるじゃん」は通用しないと思いましょう。

必ずしも遊び方を決めなくていい

Clustyleの場合ですが、私は世界を作ってます。

プレイヤーが勇者として偉業を達成し、語り継がれるための世界ではありません。

どこかに存在する、とある１つの世界です。

強敵に挑む必要性なんて作ってません。

最高品質の武器を作る必要もありません。

ただ、プレイヤーが、

「行ってみたい場所があるけど、今のままじゃ自信ないから、強い武器を作ろう！」

「いろんな人に素材売りまくって富豪目指そうかな」

「強い装備じゃないけど、この装備を全部最高品質で揃えるわ」

と、やりたいことをやっていきます。

もちろんゲームによります。ですが、必ずしも遊び方を決めない、ルートを提供しない、という考え方もあることは知っておくと良いかもしれません。

設計思想は話そう

早いうちから、設計思想は固めておきましょう。そして、ユーザーに話しておいてもいいかと思います。

Clustyleの場合は、「レベルを上げた上級者がほかの人の完全上位互換になってしまう」というのを避けようとしています。さらに、「いろんなことに手を出せるようにしたい」「専門化の価値を残したい」などというところから、「技能のレベルが上がると、他の技能が少し上がりにくくなる。その影響は、技能レベルが上がるほど加速度的に大きくなる」というものになっています。

設計思想がないと、設計がブレます。

最初に決めましょう。

また、同時に、「このゲームはプレイヤーに何を楽しさとして提供するのか」も考えておきましょう。MMOに限らず、これを決めないと、だらだらと要素が増えていって、まとまりのないものになってしまいます。

アプデするなら、「この要素は、提供したい楽しさを増幅させてくれる、もしくは共存できるさらなる楽しさを追加できるか」を考えると、ゲームがブレにくくなります。

おわりに

とはいえ、これを書いている現在、まだ正式リリースから24時間も経っていません。

あくまでこれから。

これが参考に…なるかなぁ？なったら嬉しいな。

最後にもう一つ…

みんな遊んでね！

最後までお読みいただき、ありがとうございました！

明日(15日目)は、@Alyth_solさんの記事が投稿予定です！

中高生のためのプログラミング教室を開催しました!(2026年夏)

mirin — Sun, 30 Aug 2026 06:00:37 GMT

8/21に中高生のためのプログラミング教室を開催いたしました。

今回も例年通り対面形式で開催し、TA1人に対して2人の生徒がつく形で教室を進行しました。

本教室では、JavaScriptを用いてブラウザ上で動くシューティングゲームを作成しました。

司会による全体の説明ののち、各グループに分かれてプログラミングを始めました。

以下は、当日に使用した資料の一部です。
プログラミングとは何かといった概念的な話から始まり、図形の描画やキーボード操作を受け付ける方法など基本的なことを学んだ後、それらを活かして実際のゲームを作るという流れになっています。

お昼休みにはドミノ・ピザさんのピザをいただきました。生徒やスタッフへの昼食・飲み物の提供は、ご協賛いただいている株式会社サポーターズ様の支援により実現しています。

昼食後には@nopoさんによるAIエージェントハーネスの比較、@Suimaさんによるプログラミング言語ごとの特性の紹介といったテーマでLT(ライトニングトーク)が行われました。難しい内容でありながらもみなさん熱心に傾聴していました。

LTのあとは，各自プログラミングに戻りゲーム作りを進めていました。プログラミングの時間にも歓談を交えながら、楽しく取り組んでいただきました。そして，最後には全員で記念撮影と締めの挨拶を行いました。

事後アンケートでは参加者の全員から、「とても良かった」という高評価をいただき、また「みなさんがたくさん教えてくれて楽しかったです。プログラミングのこともPCのことも詳しくなりました。ありがとうございました。」や「今まではpythonしかやっていなかったので、ジャバスクリプトも使い作品を作りたいと思いました。」など、プログラミングを楽しんでいただけたことがうかがえる感想コメントを多数いただくことができました。

最後に、本教室にご協賛いただいた株式会社サポーターズ様、TA・遊撃・裏方として活動を支えてくださった部員の方々、そして本教室に参加してくださった生徒の皆様、本当にありがとうございました。

今回ご協賛いただいた株式会社サポーターズ様(画像クリックでページに移動します)

【26年度8月版】Unity MCPであそんでみよう with Codex

Alt--er — Sat, 29 Aug 2026 08:00:12 GMT

この記事は、2026年度夏のブログリレー 13日目の記事です！
バックナンバーは上記のリンクよりご覧ください

おことわり

この記事は、 2026年8月 現在の情報で記述されております。また、致命的な記事内容の誤りなどがない限り更新する予定はありません。
同分野の情報や仕様は変化しやすく、少し前の情報でも有効でない/矛盾が生ずることがあり得ます。それを心得た上でお読みくだされば幸いです。
また、個人の見解も多く含まれる記事となっております(ブログなので当然といえばなのですが、特に注目度が高い話題ではあるので改めて注意喚起いたします)。あくまで「素人が試しに使ってみた」くらいの温度感で読んでくださると幸いです。

はじめに

初めましての方は初めまして、科学大デジタル創作同好会所属の学士 4 年になりました@Alt--erです。traP では主にGame 班及びSysAd 班で活動しています。あとは動画制作もやっていたり。
さて、これまであまり技術的な話をしてこなかった(それでいいのか?)自分ですが、今回は久しぶりにそれっぽい記事ってことで。UnityのMCPをCodex経由で触ってみたので、その所感を書いていこうかなと

開発にAIをつかうということ

Codex や Claude Code に代表されるように、LLM技術を応用したコーディング支援エージェントは日々発展しています。僕が大学に入学した頃は、まだ "ChatGPT" の言葉がようやく広がりはじめた頃というのに、今やエージェントによる支援が当たり前とも言えるくらいに利用されています。個人開発ならまだしも、もし生業として開発を行うのであれば、エージェント利用による生産性向上は必至です。

ゲーム開発界隈も、特にプログラマに関していえば同じでしょう。ただ、web系開発とは異なり Unity などゲームエンジンを用いることが標準的なゲーム開発では、単にコーディングを行うだけでなく演出の描画やオブジェクトの配置などといったエディタの操作が必要となります。実際、コーディングエージェントが広がりだしたタイミングでは、スクリプトこそエージェントに書いてもらうものの、ゲームオブジェクトの作成やコンポーネントのアタッチ、UIの配置調整といった部分は人手による作業が中心となっていました。むしろ、アタッチ忘れとかでぬるぽとか出がちなのでエディタの作業を自動化したいって思ってたり。

MCP技術の登場

「これができたら良いのに～」が数ヶ月で叶っちゃうことがあるのが、この業界の凄いところ(そしてちょっと恐ろしいところ)です。Anthropic社により開発された MCP 規格を介することで、コーディングに限らず様々なソフトウェアが(MCPインタフェースを提供していれば)エージェントによる操作を受け付けるようになりました。コードを書くだけでなく、アプリケーションも使えるようになったのですね。

What is the Model Context Protocol (MCP)? - Model Context Protocol

Model Context Protocol

Unityは多くの開発者に用いられているかツール。MCPもすぐに提供されている...... かと思ったら、公式からの提供は2026年代に入ってからと思ったより遅め(それ以前にもユーザ作成による非公式MCPは存在していましたが)。提供開始当初は有料でしたが、26年7月ごろに無料提供されるようになりました。解説記事では(公式が有料だったため)非公式MCPを用いているものも多いですが、初心者であれば公式ツールが一番使いやすいかと思うので今回はこちらで。

Unity MCP | Assistant | 2.0.0-pre.1

2.0.0-pre.1

なお、規約上一部の制限はありますが(ゲーム開発の上では基本的に問題にならない事象かと)、非公式サードパーティのMCPを用いることも可能です。もしかしたら性能差とかあるのかもしれませんが、今回は割愛します(性能比較できるほどの経験や知見がないため)。

Codex と繋いでみる

今回用いた MCP は、あくまでソフトウェアとのインタフェース。いうなれば、エージェントがソフトウェアを道具として使えるようにするための仕組みです。道具を使う主体となるエージェントには Codex を用いることにしました(ChatGPTのコーディング特化版といえばよいでしょうか)。構成図は以下のイメージ。

なお、MCPを使うためには使うPCに ChatGPT のアプリを入れておく必要がありますので事前にインストール/ダウンロードを。また、Codexを使えるプランへの契約(Plus以上)を済ませておきましょう。アプリを起動しておいて、裏にウィンドウが出ている状態にしておくとこの後がスムーズ。

続いて、Unity側からの設定を行います。まずは Unity AI のパッケージをダウンロード。こちらは、(エディタバージョンが最新に近ければ)画面左上　AI のボタンからダウンロードできます(普通のパッケージみたいに、URLを入力したり...... といった必要はありません！)。ダウンロード終了を待ちましょう。

ダウンロードが終了したら、程なくして以下のような画面が出てくるかと。

こちらの画面が「(現在裏で開いている)Codexと自分のMCPを繋いでいいか?」を尋ねる画面となっています。身元不明のエージェントになんて触らせたくないですからね。まあ、今回は Codex くんと分かりきってるので、左側細い字の Allow をクリックしましょう。

これでエラーが出なければ、接続完了です。なお、接続を確認したい場合は "Project Settings"→"Unity MCP Server" と追っていくことで見える画面から確認できます。今回なら codex-mcp-client が出ていれば大丈夫かな(複数あってもOK)。

なお今回は何も設定していませんが、既存のプロジェクトに入れる場合は権限周りの設定もしておくことをおすすめします。特に既存プロジェクトに導入する場合、エージェントはできるだけ安全に使うようにしておきたい。設定内容の説明は割愛いたしますが、先ほど述べた "Unity MCP Server" の設定からこの項目も設定できますので知っておくと幸せになれるでしょう。

動かしてみる

例えばこんなことができます

画面中央にカプセルを配置して

カプセルを、WASDで動く主人公のオブジェクトにして動作を確認できるように床も作って

これまで歩いた距離を示すUIを、Canvasを作って配置してテキストにはTMProを使って

これほどの内容でしたら、特にエラーを出すことも長考することもなくすんなりと実装してくれます。WASD移動とか、慣れているものではありますが地味に調整やコンポーネント付けが面倒なものをやってくれるのが嬉しい。

これとは別のプロジェクトですが、こんなものを作ったりもできました。

FPSゲーム
WASDで移動できる
マウス操作でカメラワークができる
弾を撃てるあたったら爆発する
自動で動く敵が現れる敵も同様に攻撃してくる
カメラワークに応じて画面上HUDが動いたり、HUDサイズを変えれたりする
その他、ゲーム中に衝突判定のあるオブジェクトを配置している

著者によるコードやエディタへの手入れは行わず、全てCodexへ指示を出し実装してもらいました(いわゆる vibe codingってやつっす)。
所感としては、1回めの実装では意図と違ってたり画面レイアウトが崩れたり、といったことがあるものの指示出しを繰り返すことでまともな見た目になっていく。エラーを出した状態で「できました！」と言ってくることはほとんどない。ただ、繰り返し指示を出しても粗がある部分は直らないがち。ライブラリ類は事前に入れておいた方がいい(レガシーな方法で実装することも多い)。といったところでしょうか。特に「エラーをほとんど出さない」というのは、エディタを触られる以上多少のアタッチ忘れとかは生じうるかなぁ...... と思ってたので意外な結果でした。だってコード書かせた時はたまにエラーのままで渡してくるもん..... あいつ。

まあ、結論としてはありきたりかもですが、やはりモック製作(ゲームを作る際に動く「イメージ」となるもの)では活きるものの、人力でブラッシュアップすべき部分も多くある、といったところでしょうか。とはいえ、特にチームでのゲーム開発ではイメージの共有が至上課題。動くイメージ/ラフを作れれば、それだけでも意思疎通や考慮すべき点の洗い出しに一助してくれることでしょう。

終わりに

今回は、Unity公式のMCPで遊んでみた記事になります。正直、プログラマの中ではAI技術周りにかなり遅れをとってた自覚があったので、この記事執筆を機に環境構築や用語の整理、技術の持つ可能性への思案等ができ良かったです。(さらにもとを辿ると、「AIを使った開発をしたいが、やり方がわからない！」といったグラフィッカーの質問を拾ったことが始まりでした。彼には圧倒的感謝です！)

この記事に書いてあることも、来年見れば「何をやってるんだ?」って程度のものかもしれません。それでも、変化と成長激しいこの業界/時代で、プログラマ/エンジニアとしてのリテラシーを持って生きていければと思います。

明日は @sorane_yaduki さんの記事です！お楽しみに

参考文献

Unity MCP + CodexでAIにUnityを操作させてキャラクターを踊らせてみた - Qiita

Unityの AI Assistant v2.0.0-pre.1 から、 Unity MCP（Model Context Protocol）が使えるようになりました。 MCPを使うと、AIからUnity Editorを操作できるようになります。今回は Codex C…

Qiitakumi0708

【初心者向け】Windows版Codex appからUnityを無料で操作する手順（CoplayDev/unity-mcp）

Zennふくろう

(上記記事ではサードパーティ製MCPを用いているため、導入手順が若干異なります)

Unity公式MCPをCodexで使う前に：Prefab・Console・Scene操作の安全設計と評価方法

ZennGameDev Tool Lab

0-1 行列をビット演算で高速化する

ryoku — Thu, 27 Aug 2026 15:25:00 GMT

この記事は夏のブログリレー12日目の記事です

概要

bitset を使ったワードサイズ倍の高速化は、ほかの方法では計算量を改善しにくい問題で有用です。 $N \times N$ サイズの $0$ - $1$ 行列 $A$ をサイズ $N$ の bitset $N$ 個により保持しているとしましょう。 $j$ を固定して $A_{i, j}$ に関する何らかの情報を得るためには、自明な実装ではワードサイズ倍の高速化を行えません。
しかし、転置を行うことにより単一のビット列の場合に帰着して、高速化を行うことができるようになります。この記事では、転置を高速に行うアルゴリズムおよび、転置を必要とせず、より高速に行える場合を紹介します。

以下では簡単のため正方行列のみを扱いますが、そうでない行列にも容易に適用可能です。

記法

添字は $0$ -indexed とします。
$N \times N$ の $0$ - $1$ 行列 $A$ の第 $i$ 行を $A_{i}$ とし、 $N$ ビットのビット列として扱います。

ビット列 $x$ の第 $j$ ビットを $x_{j}$ と書きます。ビット列に対する $\land, \lor, \oplus, \neg$ は、それぞれ各ビットごとの AND、OR、XOR、NOT を表します。
word size を $w$ とおいて $w = Θ (lo g N)$ と仮定します。

説明を簡単にするため $N$ を $2$ 冪と仮定し、 $l = lo g_{2} N$ とします。
多重集合の和を $⊎$ で表します。

1. 高速な転置

問題

$N \times N$ の $0$ - $1$ 行列 $A$ が与えられる。
各行は長さ $N$ のビット列として保持されているものとする。
この行列の転置 $A^{T}$ を求めよ。

解法

転置では、 $(r, c)$ にあるビットを $(c, r)$ に移せばよいです。
行番号と列番号を $2$ 進数で見ると、これはそれぞれのビットを入れ替えることに対応します。

次のアルゴリズムが正当です。

$i = l - 1, \dots, 0$ について次を行う。
- 整数の組 $(r, c)$ であって、 $r$ の $i$ ビット目が $0$ であり、 $c$ の $i$ ビット目が $1$ であるもの全てに対して次を行う。
  - $(r, c)$ と $(r + 2^{i}, c - 2^{i})$ にあるビットを交換する。

アルゴリズムの正当性

最初、 $(r, c)$ にあったビットの動きを観察しましょう。
$r, c$ を $2$ 進数に展開して、 $r_{l - 1} r_{l - 2} \dots r_{0}$ および $c_{l - 1} c_{l - 2} \dots c_{0}$ とします。

$i = k$ の場合、ビットは次のように動きます。

[1] $r_{k} = c_{k}$ のとき

変わりません。

[2] $r_{k} = 0, c_{k} = 1$ のとき

このとき、 $r_{k} = 1, c_{k} = 0$ になります。また、 $r_{k} = 0, c_{k} = 1$ なので、 $r + 2^{k}, c - 2^{k}$ では繰り上げ、繰り下げが起こらず、 $r_{k}, c_{k}$ 以外は変わりません。

[3] $r_{k} = 1, c_{k} = 0$ のとき

[2] で述べた交換のもう一方の要素となるため、 $r_{k} = 0, c_{k} = 1$ になります。

以上から最終的に $r_{i}, c_{i}$ は全て swap されて転置されます。

具体例

$N = 8$ の場合の転置の過程を示しておきます。

クリックして開く

関数アートの現在地

konryu — Thu, 27 Aug 2026 08:00:43 GMT

この記事は夏のブログリレー11日目の記事です

はじめに

こんにちは、konryuです。関数アートを始めて6年が経とうとしているので、改めて関数アートを俯瞰してみようと思いました。関数アートについて知らない人に、関数アートとは何か、私が現在（2026年8月）知っている限りの全体像をこの記事で知ってもらおうと思っています！

「関数アート」とは？

皆さんは「関数アート」という言葉を聞いたことがあるでしょうか？　最近はzboyさんの「きゅうくらりん」関数アートなどによって知名度が上がっていますが、まだまだ知らない人も多いと思います。

数式だけで「きゅうくらりん」描いてみた【関数アート】KYUUKURARIN but in Desmos

これはグラフを描くための教育用ソフト「desmos」を使って作られています。本来は数学の学習に用いるツールですが、私はグラフを使って絵や動画を作っています。いよわさんの「きゅうくらりん」をグラフで作りました。解説付きです。＜引用＞↓偉大なる本家様：「きゅうくらりん / いよわ feat.可不（Kyu-kurari…

YouTube

簡単に言えば関数アートとは「数式を用いて絵を描くこと」です。

学校での数学でも $y = x$ や $y = x^{2}$ などのグラフや円の方程式 $x^{2} + y^{2} = 1$ などを習いますよね。他に図形に関するものと言えば不等式が作る領域、ベクトルと媒介変数表示などがあります。

関数アートではこれらの直線や円、さらに高度な数式などを組み合わせながらさまざまな図形を作り、絵を描きます。

ところで、関数アートはDesmosという、数式をグラフにして表示できるサイトで主に描かれています。このDesmosが関数アート界隈で圧倒的なシェアを占めているために、Desmosを使って作られた作品（絵に限らない）は関数アートと呼ばれがちです。しかし実は、Desmosは静止画しか作れないわけではないんですね。

静止画だけでなく動画、それにとどまらずプログラミング、ゲーム、音楽まで再現できてしまうので、この意味で関数アートの定義はかなり曖昧になっています。「形態を問わず、制作手法として主に数式を用いている作品」が関数アートだと個人的には思っています。

では具体的に、どんな関数アートがあるのでしょう？　まず絵の描き方が主に大きく2つに分かれるので、まずはそれを見ていきましょう。

① 媒介変数表示を使う

媒介変数表示とは、 $x = f (t), y = g (t)$ といったように、2つの変数( $x$ と $y$ )の関係を別の変数( $t$ )を用いて表すこと、ですね。関数アートではもっと単純に「動く点の軌跡を描画する」ととらえると分かりやすいです。

点を動かせば線が引かれるというのはペンみたいですね。Desmosでは媒介変数表示で描かれた図形を塗りつぶすこともできるので、実際に絵を描くのに使えます。

この媒介変数表示は関数アートの中では最も手軽で、表現力が高いです。その理由は普通のお絵描きソフトでも使われるベジェ曲線が扱えることにあります。

ベジェ曲線を扱う

そもそもベジェ曲線とは、制御点と呼ばれる点から作られる曲線です。点を置くだけでいい感じの曲線が作れるので、表現力はとても高く、ベクター画像を扱うようなロゴやアイコンの制作ソフトやフォントのデータなどに応用されています。

このベジェ曲線、実は数学的な背景がある曲線で、関数アートにそのまま持ち込めます。これでお絵描きソフト同様の表現力を手に入れることができるわけですね。zboyさんの「きゅうくらりん」関数アートもこのベジェ曲線を使って描かれています。

3次ベジェ曲線で描いたハート。青い点が制御点で、制御点からベジェ曲線を描き、塗りつぶしている。

これら媒介変数表示を使う関数アートはその手軽さ、表現力の高さから、関数アート界隈でも人気です。ただ、ペンのたとえから分かる通り、ペンで描けるような図形しか描けないという弱点（？）があります。また、規則的なパターンがある図形なども、フリーハンドに近い状態でそのまま書かなくてはいけません。せっかく数式を使っているのにもったいない気がします。

そのような図形は方程式を使って描くことができます。多くの人が「数式を使って描く」「関数アート」と聞いて想像するのはこっちかもしれません。

② 関数・方程式を使う

数式をしっかり使いながら図形を描く方法です。関数アートっぽさがあって私は好きです。「はじめに」で載せたようなグラフなどを使って絵を描くのですが、 $y = f (x)$ の形の関数は表現力が低いので使わずに方程式を使って描くことが多いです。

そんなぁ。「関数」アートなのに、、

それはさておき、不等式を使うと図形を塗りつぶすことも可能です。

さらに、これらの式に対して様々な関数を加えることで図形同士を結合、共通部分を抜き出す、重なった部分だけ消すなど色々な操作をすることができます。以下に式を載せるので、気になる人は見てみてください。

方程式で描かれた2つの領域

また、1つの方程式に対しても少し変えるだけで色々な操作ができます。以下に一例を挙げます。気になる人はぜひ見てみてください。

元の方程式で描かれた領域

こちらはベジェ曲線が使える媒介変数表示に図形単体の表現力は劣るものの、図形に対する操作の自由度がとても高く、違うベクトルで表現力が高いです。あと描いてて楽しいです。

下の絵は1時間半程度で描いた関数アートで、方程式を使って描いています。雲の複雑な図形をペンで描くのは難しい（私の画力だと不可能）ですが、方程式を使うと簡単に描けます。

ここまで紹介した手法を使うと様々な図形が描けます。次は色を塗りたくなりますね。Desmosでは色を定義できる色関数というものがあり、デフォルトで用意されている色のほかにも色が扱えます。色関数rgbなどを使って定義した色を変数に入れると、Desmos上でその色が塗りつぶす色として指定できるようになります。

普通にべた塗りするだけなら簡単にできるのですが、これまでの手法ではグラデーションを扱うのが大変でした。そこに約1年前、Desmosに画期的なアップデートが起きました。

座標を含んだ色関数を使う

約1年前、3DのDesmosで色関数に座標を含められるようになり、場所によって色が変化する、つまりグラデーションの実現が簡単にできるようになりました。

Have you noticed a change of colors? 🍂

You can now define colors in the 3D calculator that depend directly on coordinates. 📝Learn more in the Desmos Help Center: https://t.co/JjQfutKPtv #desmosart #colors #iteachmath pic.twitter.com/x1g9GbYRc0
— Desmos (@Desmos) October 28, 2025

また、任意の絵は座標(x,y)から色を表すベクトル(r,g,b)の関数だとみなすことができるので、方程式の手法と組み合わせると、xy平面に本当にどんな絵を描くこともできるようになりました。ただ、3Dを使う、数式が複雑になるなど、難点が多く、まだ界隈全体に浸透はしていない印象があります。ただ、一部でその圧倒的な表現力を使った作品もあり、今後が楽しみな分野です。

T=1
n=[0...64]/64
Y=y+.006sin6τT
p=(x,Y,1)/(max(|x|,|Y|))
c=hsv(0,join([0...32],[32...0])/32,n)
c:.3/|(p.x,p.y,mod(p.z+4T,4))-(0,1,2)|>n#関数アート https://t.co/tGc5ApQURD pic.twitter.com/Ca2Brbuzd1
— てねうら (@teneshinuran) July 5, 2025

以上でDesmosで絵を描く方法を説明しました。他にもDesmosでできることはあるのですが、詳しく書くと長くなるので以下ではざっくり説明します。

Desmosで動画を作る

Desmosは変数を定義でき、しかもこの変数を時間によって動かすことができます。つまり、媒介変数表示や方程式を変数によって変化させることでアニメーションが作れるんですね。一般的にアニメーションに使われるイージングも数式で表せるものばかりなので、関数アートに簡単に持ち込むことができます。この関数アートは私の描いたもので、1つ1つの円を方程式で描き、これを変数Tによって変化させてアニメーションを作っています。

Desmosでプログラミングをする

Desmosにはアクションと呼ばれる構文があり、a->bと書くことでaにbを代入する操作を表せます。これを実行するには式の左にある矢印ボタンを自分でクリックします。ただ、「ticker」という機能を使って指定した秒数ごとに自動的にアクションを実行することができます。代入しかできませんが、Desmosは関数の自由度が高いのでこれで大体のロジックが書けるようになります。主に次で紹介する技術と組み合わせてインタラクティブにしている作品が多いです。

Desmosでゲームをつくる（グラフを操作できるようにする）

Desmosでは、点がドラッグ可能だったり、グラフをクリックしたときに任意のアクションを実行できたりします。

これを使うとユーザーの操作をグラフに反映させられるので、ゲームだったり簡単なツールだったりが関数アートとして作れるわけですね。実際にテトリスを再現した例もあります。（作者：FG_1024氏、Shou氏）

グラフ計算機desmosで”あのゲーム”を作ってしまう猛者現る！【関数アート】

制作者:FG_1024さん (twitter : https://x.com/FG_1024?s=20)Shouさんこの関数アートは関数アートdiscordサーバーにて公開されました↓のリンクからサーバーに参加できますhttps://discord.com/invite/FMRFNfJ7ZC使用BGM : hon…

YouTube

Desmosで音を鳴らす

Desmosにはtone関数と呼ばれる構文が3年前に追加され、tone(周波数, 音量)で指定した周波数、音量の正弦波を鳴らすことができるようになりました。

なんで、、？

グラフ計算機に必要な機能とはあまり思えませんが、関数アートを作るうえでは革命的で、音楽を作品に組み込めるようになりました！ありがとう！　また正弦波しか出せないのですが、任意の波形はフーリエ変換を用いて正弦波の組み合わせとして表現できる（らしい）ので理論上問題はなく、すべての音色をつくることができます。関数アートとしてはすでにある音楽の再現がよく見かけますが、オリジナルなものもあり、国際アートコンテストでは、入賞作品のうちtone関数を使って音楽や効果音を入れた作品が毎年一定の割合を占めるようになりました。

国際数学アートコンテスト13～14歳部門入賞作品（制作者：Ryker VanderHorn）

Twilight Gaze

Desmos

関数アートを取り巻く環境と文化

ここまで関数アートに使う技術を紹介してきました。最後に、ここまで関数アートを発達させたコミュニティーやその文化について軽く書こうと思います。主に私の知っている日本国内での話です。

Desmodder

有志によるDesmosの非公式の拡張機能です。関数アートの作成に特化した機能が追加され、関数名の自動補完・GPUを使った方程式のレンダリング・動画出力など、数々の便利機能が使えて、関数アートにおいてほぼ必須級の機能になっています。便利！

DesModder for Desmos - Chrome ウェブストア

Supercharge your Desmos graph creation and sharing experience with many convenient features

Chrome ウェブストア

国際数学アートコンテスト

これはDesmos公式が年に一度開催している、関数アートの世界大会です。関数アート技術の最前線を見ることができます。日本人だとzboy氏とてきちょく氏が4年連続で入賞していてやばい。

Desmos | Art Contest

Art Contest

また、日本国内でも「関数グラフアート全国コンテスト」「全国小学生関数アートコンテスト」などが開催されていて、こちらは中高生、小学生を主な対象としているようです。

ゆっくりと学ぶDesmosと関数アートの話

てきちょく氏が作成している関数アート入門のための動画シリーズで、現時点で日本でほぼ唯一の、関数アートの技術が体系的に説明されているコンテンツです。めっちゃ分かりやすい。最近では100話を超え、レイトレーシングをDesmosで実装するといったかなり高度な内容が展開されています。関数アートを始めたい方はまず見てみるといいと思います。

関数アートサーバ / Unofficial Desmos

関数アートサーバは日本の、Unofficial Desmosは世界全体の関数アートのdiscordサーバーで、どちらも関数アートの作品が日々飛び交っています。今関数アートサーバは800人ちょい、Unofficial Desmosは5700人近くが参加しているようです。他にもredditのr/Desmosがでかいコミュニティーとしてあるらしいのですが、詳しくないので挙げるだけにしておきます、、

#MathInReality

現実世界にある図形を関数アートにする遊びです。twitterや関数アートサーバ上で時折見られます。

電車のドアの模様の関数アート by konryu #MathInReality

数式ゴルフ

目的の図形をどれだけ短い式で描けるかを競う遊びです。名前はコードゴルフに由来すると思われます。ときに $0^{0^{x}}$ や $x^{\infty}$ など、奇抜な（そして数学的に怪しい）関数を使いながら文字数を短縮していくのは、見ているだけで面白いです。てきちょく氏の運営する関数アートサーバで盛り上がりを見せている分野の一つで、不定期で大会なども開催されています。

【関数アートサーバ 2周年記念 #数式ゴルフ大会】

📈📈結果発表～～！📈📈

今回は提出された式を他の数式ゴルフ勢がより短くしていく協力体制が見受けられました！

派生とともにすべての作品は以下のツリーから見れます！ 👀 https://t.co/s63Gg7MGW2 pic.twitter.com/YJYHrBsMHq
— 【彳▼亍 ▼てきちょく】 (@TETH_Main) October 28, 2023

おわりに

関数アートに使われる技術から関数アート周辺の環境まで、現時点での私から見た関数アートの全てをざっくりとまとめてみました。得意分野の違う色々な人・分野が集まっているのに共通の言語で話せる・扱えるという感覚が関数アートの良いところの一つだと思っています。

ひとくちに「関数アート」といっても様々な分野があることと、またその魅力も一緒に伝わっていたら嬉しいです。ここまで読んでくださりありがとうございました！

明日の投稿者は@ryokuです！

世界のナベアツと Aho–Corasick オートマトン

hayatroid — Wed, 26 Aug 2026 14:00:31 GMT

この記事は夏のブログリレー 10 日目の記事です。

こんにちは、23B の @hayatroid です。院試対策でオートマトンの勉強をしたので、同じく講義などでオートマトンの勉強をした人間を競プロに誘いです。

TL;DR

kuretchi さんのオートマトン上の DP に KMP オートマトンと Aho–Corasick オートマトンを impl です。そして次の問題を AC です。

ナベアツとはオートマトンである

ナベアツ^[1]は、 $3$ の倍数と $3$ がつくときアホになる。数を読んでアホになるかどうかを決めるのだから、ナベアツはオートマトンといえる。

ナベアツ数を認識するオートマトン

非負整数がナベアツ数であるとは、 $3$ の倍数であるか $3$ がつくことをいう^[2]。

$3$ の倍数を認識するオートマトンと $3$ がつく数を認識するオートマトンは、それぞれ次のとおりである。

$3$ の倍数	$3$ がつく

ナベアツ数を認識するオートマトンは、この $2$ つの union で表せる。

たとえば $10125$ は、 $3$ がつかないが $3$ の倍数であるため、ナベアツ数である。

$3$ の倍数 ( $10125$ を読む)	$3$ がつく ( $10125$ を読む)

たとえば $38347$ は、 $3$ の倍数でないが $3$ がつくため、ナベアツ数である。

$3$ の倍数 ( $38347$ を読む)	$3$ がつく ( $38347$ を読む)

これらのオートマトンを実装すれば、次の問題が解ける。

No.220 世界のなんとか2

yukicoder No.220 世界のなんとか2 では、 $1$ 以上 $1 0^{P}$ 以下のナベアツ数を数え上げる必要がある。 $P$ は最大 $19$ である。

先の図のオートマトンを実装し、この問題を解く。

まず、決定性有限オートマトン^[3]の $5$ つ組をそのまま trait にする。

trait Dfa {
    type State;
    type Alphabet;
    fn init(&self) -> Self::State;
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State;
    fn accept(&self, q: &Self::State) -> bool;
}

先の図の左、 $3$ の倍数を認識するオートマトンを MultipleOf(3) として実装する。

struct MultipleOf(u64);
impl Dfa for MultipleOf {
    type State = u64;
    type Alphabet = u8;
    fn init(&self) -> Self::State {
        0
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        (q * 10 + (c - b'0') as u64) % self.0
    }
    fn accept(&self, q: &Self::State) -> bool {
        *q == 0
    }
}

先の図の右、 $3$ がつく数を認識するオートマトンを Seen(b'3') として実装する。

struct Seen(u8);
impl Dfa for Seen {
    type State = bool;
    type Alphabet = u8;
    fn init(&self) -> Self::State {
        false
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        *q || *c == self.0
    }
    fn accept(&self, q: &Self::State) -> bool {
        *q
    }
}

オートマトンの union もまたオートマトンである。 $2$ つのオートマトンを並べて走らせ、どちらかが受理すれば受理するオートマトンを Or として実装する。

struct Or(A, B);
impl> Dfa for Or {
    type State = (A::State, B::State);
    type Alphabet = A::Alphabet;
    fn init(&self) -> Self::State {
        (self.0.init(), self.1.init())
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        (self.0.next(&q.0, c), self.1.next(&q.1, c))
    }
    fn accept(&self, q: &Self::State) -> bool {
        self.0.accept(&q.0) || self.1.accept(&q.1)
    }
}

オートマトン $A$ に $Σ^{n}$ のすべての文字列を読ませ、 $A$ が受理する文字列を数える関数を $count (A, Σ, n)$ として実装する。たとえば $Σ$ を $10$ 進の数字とすれば、 $count (A, Σ, n)$ は $n$ 桁の数字列のうち $A$ が受理するものを数える。先頭の $0$ を気にしないことにすれば、これは $1 0^{n}$ 未満の非負整数のうち $A$ が受理するものの個数とみなせる。

fn count(dfa: A, sigma: S, len: usize) -> u64
where
    A: Dfa,
    A::State: Eq + Hash,
    S: Iterator + Clone,
{
    let mut dp = HashMap::new();
    dp.insert(dfa.init(), 1);
    for _ in 0..len {
        let mut ndp = HashMap::new();
        for (q, v) in dp {
            for c in sigma.clone() {
                *ndp.entry(dfa.next(&q, &c)).or_insert(0) += v;
            }
        }
        dp = ndp;
    }
    dp.iter()
        .filter_map(|(q, v)| dfa.accept(q).then_some(v))
        .sum()
}

あとはオートマトンを組み立てて長さ $P$ で数え上げるのみである。 $1 0^{P}$ はナベアツ数でなく、 $0$ はナベアツ数なので、 $1$ を引けば答えになる。

fn main() {
    input!(p: usize);
    let dfa = Or(MultipleOf(3), Seen(b'3'));
    println!("{}", count(dfa, b'0'..=b'9', p) - 1);
}

以上を提出すると AC が得られる。

No.260 世界のなんとか3

実は先の問題はナベアツ方程式^[4]で解けてしまう。それでも問題をオートマトンで解くことの真髄は、条件が増えてもオートマトンを足すだけで済むことにある。

yukicoder No.260 世界のなんとか3 では、 $A$ 以上 $B$ 以下の整数のうち、ナベアツ数であって $8$ の倍数でないものを $1 0^{9} + 7$ で割った余りで数え上げる必要がある。 $A, B$ は最大 $1 0^{10000}$ である。

これは、先の問題で用意したオートマトンに加えて、次の $4$ つのオートマトンを足せば解ける。

$B$ 以下を認識するオートマトン Le
$A$ 未満を認識するオートマトン Lt
オートマトンの intersection And
オートマトンの complement Not

たとえば $B = 31415$ のとき、 $B$ 以下を認識するオートマトンは次のとおりである。読んだ数字列が $31415$ の接頭辞より小さいか、等しいか、大きいかを状態に持つ。

$31415$ 以下

上図のオートマトンを Le(b"31415") として実装する。

struct Le<'a>(&'a [u8]);
impl Dfa for Le<'_> {
    type State = (Ordering, usize);
    type Alphabet = u8;
    fn init(&self) -> Self::State {
        (Ordering::Equal, 0)
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        (q.0.then(c.cmp(&self.0[q.1])), q.1 + 1)
    }
    fn accept(&self, q: &Self::State) -> bool {
        q.0.is_le()
    }
}

Lt, And, Not もこれまで同様のノリで実装する。count は $1 0^{9} + 7$ で割った余りを取るよう書き換える。

あとはオートマトンを組み立てて、 $B$ 以下の数え上げから $A$ 未満の数え上げを引くのみである。

fn main() {
    input!(a: Bytes, b: Bytes);
    let nabeatsu = || And(Or(MultipleOf(3), Seen(b'3')), Not(MultipleOf(8)));
    let dfa_le_b = And(Le(&b), nabeatsu());
    let dfa_lt_a = And(Lt(&a), nabeatsu());
    let le_b = count(dfa_le_b, b'0'..=b'9', b.len());
    let lt_a = count(dfa_lt_a, b'0'..=b'9', a.len());
    println!("{}", (le_b + MOD - lt_a) % MOD);
}

以上を提出すると AC が得られる。

ナベアツが本気を出してきたらどうしよう

今度のナベアツは、 $3$ の倍数と $w$ がつくときアホになるという。

$w$ がつく数を認識するオートマトン

$w$ がつく数を認識するオートマトンは、読んだ数字列の末尾と $w$ の先頭が一致する長さのうち、最も長いものを状態に持てばよい。読んだ数字が $w$ の次の文字と一致しなかったら、その次に長いものへ戻り、そこから続きを読む。この戻る辺を failure link という^[5]。 $w$ を一列に並べて failure link を足したものを KMP オートマトンという^[5:1]。

たとえば $w = 33$ のとき、 $w$ がつく数を認識するオートマトンは次のとおりである。破線が failure link である。読む数字の辺が無いときは、破線を $1$ 本たどって読む。それでも読めなければ、また破線を $1$ 本たどって読む。 $0$ まで戻っても読めなければ、 $0$ に留まる。

$33$ がつく

たとえば $344333$ は、 $3$ の倍数でないが $33$ がつくため、ナベアツ数である。

$33$ がつく ( $344333$ を読む)

このオートマトンを実装すれば、次の問題が解ける。

No.2867 NOT FOUND 404 Again

yukicoder No.2867 NOT FOUND 404 Again では、 $N$ 以下の正の整数のうち $404$ がつかないものを $998244353$ で割った余りで数え上げる必要がある。 $N$ は最大 $1 0^{1000000}$ である。

これは、先の問題のオートマトンに加えて、 $w$ がつく数を認識するオートマトン Contains を足せば解ける。

先の図のオートマトンを Contains::new(b"33") として実装する。

状態 $q$ において、数字 $c$ を読んだ次の状態を next[q][c]、破線を $1$ 本たどった先を fail[q] とする。 $c$ の辺が無いときは、破線をたどって読んだ先を next[q][c] とする。next と fail は、 $q$ の小さいほうから埋められる。

struct Contains {
    next: Vec<[usize; 10]>,
    accept: Vec<bool>,
}
impl Contains {
    fn new(w: &[u8]) -> Self {
        // 1. w を一列に並べる
        let n = w.len();
        let mut next = vec![[0; 10]; n + 1];
        let mut accept = vec![false; n + 1];
        for q in 0..n {
            next[q][(w[q] - b'0') as usize] = q + 1;
        }
        accept[n] = true;
        // 2. failure link を張る
        let mut fail = vec![0; n + 1];
        for q in 1..=n {
            for c in 0..10 {
                if next[q][c] != 0 {
                    fail[next[q][c]] = next[fail[q]][c];
                } else {
                    next[q][c] = next[fail[q]][c];
                }
            }
        }
        // 3. 受理状態に留まるようにする
        next[n] = [n; 10];
        Contains { next, accept }
    }
}
impl Dfa for Contains {
    type State = usize;
    type Alphabet = u8;
    fn init(&self) -> Self::State {
        0
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        self.next[*q][(c - b'0') as usize]
    }
    fn accept(&self, q: &Self::State) -> bool {
        self.accept[*q]
    }
}

count は $998244353$ で割った余りを取るよう書き換える。

あとはオートマトンを組み立てて長さ $∣ N ∣$ で数え上げるのみである。 $0$ は $404$ がつかないので、 $1$ を引けば答えになる。

fn main() {
    input!(n: Bytes);
    let dfa = And(Not(Contains::new(b"404")), Le(&n));
    println!("{}", (count(dfa, b'0'..=b'9', n.len()) + MOD - 1) % MOD);
}

以上を提出すると AC が得られる。

Re: ナベアツが本気を出してきたらどうしよう

今度のナベアツは、 $3$ の倍数と $W$ のどれかがつくときアホになるという。

$W$ のどれかがつく数を認識するオートマトン

$W$ のどれかがつく数を認識するオートマトンは、KMP オートマトンの一列を $W$ の trie^[6] に差し替え、同じように failure link を足したものである。これを Aho–Corasick オートマトン という^[7]。

たとえば $W = {33, 313}$ のとき、 $W$ のどれかがつく数を認識するオートマトンは次のとおりである。破線が failure link である。受理状態に添えた集合が、そこで見つかる語である。見つかる語は、破線を $1$ 本たどった先で見つかる語を含む。その先の語も、また破線を $1$ 本たどった先の語を含む。

$33$ または $313$ がつく

たとえば $31131335533$ は、 $3$ の倍数でないが $313$ も $33$ もつくため、ナベアツ数である。

$33$ または $313$ がつく ( $31131335533$ を読む)

このオートマトンを実装すれば、次の問題が解ける。

No.1269 I hate Fibonacci Number

yukicoder No.1269 I hate Fibonacci Number では、 $1 0^{N}$ 未満の正の整数のうち、 $L$ 以上 $R$ 以下のフィボナッチ数がどれもつかないものを $1 0^{9} + 7$ で割った余りで数え上げる必要がある。 $N$ は最大 $5000$ 、 $R$ は最大 $1 0^{18}$ である。

これは、先の問題のオートマトンに加えて、 $W$ のどれかがつく数を認識するオートマトン ContainsAny を足せば解ける。

先の図のオートマトンを ContainsAny::new(&[b"33".to_vec(), b"313".to_vec()]) として実装する。

状態 $q$ において、数字 $c$ を読んだ次の状態を next[q][c]、破線を $1$ 本たどった先を fail[q] とする。 $c$ の辺が無いときは、破線をたどって読んだ先を next[q][c] とする。next と fail は、根からの深さが小さいほうから埋められ、幅優先探索をすればよい。実装は OI Wiki の AC 自动机を参考にした。

struct ContainsAny {
    next: Vec<[usize; 10]>,
    accept: Vec<bool>,
}
impl ContainsAny {
    fn new(ws: &[Vec<u8>]) -> Self {
        // 1. ws の trie をつくる
        let mut next = vec![[0; 10]];
        let mut accept = vec![false];
        for w in ws {
            let mut q = 0;
            for c in w {
                let c = (c - b'0') as usize;
                if next[q][c] == 0 {
                    next[q][c] = next.len();
                    next.push([0; 10]);
                    accept.push(false);
                }
                q = next[q][c];
            }
            accept[q] = true;
        }
        // 2. failure link を張る
        let mut fail = vec![0; next.len()];
        let mut bfs = VecDeque::new();
        for c in 0..10 {
            if next[0][c] != 0 {
                bfs.push_back(next[0][c]);
            }
        }
        while let Some(q) = bfs.pop_front() {
            for c in 0..10 {
                if next[q][c] != 0 {
                    fail[next[q][c]] = next[fail[q]][c];
                    bfs.push_back(next[q][c]);
                } else {
                    next[q][c] = next[fail[q]][c];
                }
            }
            accept[q] |= accept[fail[q]];
        }
        // 3. 受理状態に留まるようにする
        for q in 0..accept.len() {
            if accept[q] {
                next[q] = [q; 10];
            }
        }
        ContainsAny { next, accept }
    }
}
impl Dfa for ContainsAny {
    type State = usize;
    type Alphabet = u8;
    fn init(&self) -> Self::State {
        0
    }
    fn next(&self, q: &Self::State, c: &Self::Alphabet) -> Self::State {
        self.next[*q][(c - b'0') as usize]
    }
    fn accept(&self, q: &Self::State) -> bool {
        self.accept[*q]
    }
}

count は $1 0^{9} + 7$ で割った余りを取るよう書き換える。

あとはフィボナッチ数を列挙し、オートマトンを組み立てて長さ $N$ で数え上げるのみである。 $0$ はフィボナッチ数がつかないので、 $1$ を引けば答えになる。

fn main() {
    input!(n: usize, l: u64, r: u64);
    let mut ws = vec![];
    let (mut x, mut y) = (1, 1);
    while x < l {
        (x, y) = (y, x + y);
    }
    while x <= r {
        ws.push(x.to_string().into_bytes());
        (x, y) = (y, x + y);
    }
    let dfa = Not(ContainsAny::new(&ws));
    println!("{}", (count(dfa, b'0'..=b'9', n) + MOD - 1) % MOD);
}

以上を提出すると AC が得られる。

〆

Rust の trait によって、オートマトンの具体を知ることなく、抽象に依存したオートマトンが合成できたり (Or)、抽象に依存した数え上げが定義できたり (count) するのが面白ポイントです。

以上、オートマトン er を競プロに誘い記事と見せかけた、競プロ er を Rust に誘い記事でした^[8]。

https://ja.wikipedia.org/wiki/桂三度 ↩︎
https://x.com/Yuk3u/status/2076621350224179441 ↩︎
https://ja.wikipedia.org/wiki/決定性有限オートマトン ↩︎
https://dreamscience.iml.menhera.org/wiki/ナベアツ方程式 ↩︎
https://qiita.com/hdbn/items/b3909ce29a46c5d0cb8c ↩︎ ↩︎
https://oi-wiki.org/string/trie/ ↩︎
https://oi-wiki.org/string/ac-automaton/ ↩︎
本記事の内容は他言語でも同等に書けるので、優劣のお話ではありません。「Rust 競プロは巷で言われるほど悪くないのでいかがでしょうか」というお誘いです。 ↩︎

東京科学大学デジタル創作同好会traP

藍ノ國、紅ノ國 【1-Monthon 2026 29班】

制作したゲームについて

プレイリンク

ゲーム概要

ゲームができるまで

班構成

準備

開発

8/8 ~ 8/12

8/12 ~ 8/19

8/20 ~ 8/29

8/29 ~ 8/31

8/31 ~ 9/2

9/2 ~ 9/5

"Everything is going to be better."

ボスAIのついて詳しく書いてみる

大枠

通常時 : 攻撃システム

異常時 : 緊急回避システム

余談 : 移動方向

感想

動画投稿をしてみた結果 得られたのは OO でした

はじめに

動画投稿をしてみた話

どんな動画を上げていたの?

完走した感想

どんなことやってたの?

収録

セリフ作り

編集

大変だったこと

得られたもの

終わりに

四国一周旅行から学ぶ気を付けるべきこと

1. 貴重品を身から離すな

2. ホテルを当日に取るな

3. 厳しいスケジュールを立てるな

4. 下調べをしろ

5. 現金を持っていけ

6. 金を用意しておけ

まとめ

マジカルミライ2026 in Tokyo レポート

マジカルミライ

企画展

公式の展示

等身大フィギュア

履修申告の前に知っておきたい！「ウェルネス実習」のあれこれ―体験談を添えて―【夏のブログリレー2026】

はじめに

そもそも「ウェルネス実習」とは

履修方法

授業を受ける際の服装

気温について

種目分けについて

1Qと3Q（ガイダンスあり）

2Qと4Q（ガイダンスなし）

私の体験談: バドミントン

成績や系所属点について

まとめ

Arpa's Trick

導入

Disjoint Union Set であそぼ

準備 : クエリ先読み

やってみよう

Arpa's Trick

問題

Repovive Starter Round 2 - F. Pair Increment Ranges

おわり

参考にした資料

【競プロ】ざっくり Trace Monoid

定義

簡約律 (Cancellation Property)

射影による trace 判定 (Projection Lemma)

証明 1

証明 2

ARC194E

あとがき

春ハッカソン参加記「以線伝心」

実際に遊んでいる様子

プレイ画面

藍ノ國、紅ノ國【1-Monthon 2026 29班】

動画投稿をしてみた結果得られたのは OO でした