2026 年・謹賀新年

はじめに

明けましておめでとうございます.

振り返ってみると, 2024 年は年頭のブログを書きました が, 2025 年は書いていませんでした. 2026 年は, 年初の考えを残しておこうと思います.

ちなみに近所の神社でひいたおみくじは, 半吉 でした.

2025 年の振り返り

日頃のメモから抽出された 2025 年の振り返りは次の 3 点でした.

  • 早めに自分からアクションを起こす
  • 家族との時間を大切にする
  • 休む時間を確保する

仕事をスムーズにこなしつつ, 時間を捻出して家族や自分のために使っていきたいなと思います.

仕事

世の中と同様に少子高齢化の影響などを受け, 職場の人員も減る方向です. 同じアウトプットを出そうとすると多くの仕事を素早くこなす必要がありますが, それではいずれ限界が来ます (もう限界が来ているかも).

最近私が気にしているのは 全体最適 です. 制約条件の理論 を参考にすると, 制約になっている人や部署は常に忙しく, 見方を変えると全体のアウトプットに連動して仕事をするようになります. 一方, 制約ではない人や部署は, 手待ちができたり, あるいは全体のアウトプットに直結しない (ように見える) 仕事をすることになり, 生産性が下がっているように見えます.

かと言って, 個別最適で個別に頑張ってしまうと, 全体として歯車がかみ合わなくなったりして, イマイチです. 全体最適を目指しつつ, 個別でも生産性を高めてやりがいを感じられるような仕事の仕方を目指したいと漠然と考えており, 模索中です.

あと最近意識しているのは, 仕事が一区切りついたら 振り返りをする ということです. 仕事が終わったらすぐに次の仕事に取り掛かるのではなく, きちんと振り返る (PDCA の C) ことで, 落とし穴を避け, いい仕事の再現性を高めていければと思います.

ジョギング

ここからはプライベートの話題です.

2025 年は暑さが落ち着いてきた頃から, 週末に 5 ～ 7km 走りました. 年間では 250km 程度走りました.

今年はもう少し距離を延ばしたく, 目標を以下のようにします.

  • 10km / 回
  • 2 回 / 週
  • 年間目標 ; 10km × 2 回 × 50 週 = 1000km

モチベーション up のため, ChatGPT に相談して Amazfit Bip 6 を買いました ! 以前は EPSON の WristableGPS を使っていたのですが, アプリやサポートが終了してしまったので…

AtCoder

ほぼ毎週土曜日に AtCoder Beginner Contest に参加し, 2025 年はレーティングが 800 を越え, 緑色になりました. 2026 年の目標を設定するにあたり ChatGPT に相談したところ, 以下のようになりました.

こんなうまい話はありませんが, 年末にレーティング 1200 を越えて水色になれるといいなぁと思っています.

OMC

昨年 2025 年から OMC を始めました. まだ数回しかコンテストに参加していませんが, 2025 年の結果は以下の通りでした.

2026 年もあまりコンテストには参加できないかもしれませんが, 安定して緑色を維持できればと思っています.

あと, 家族から 今年は何か資格を取らないのか と煽られたので, 数学検定 をチャレンジしようかと思っています (まず 2 級か?).

その他

大事な健康面については, 昨年は数回医者に行きました (咳など) が, 仕事を休んだり寝込んだりはありませんでした. 今年も大病しないよう, 気を付けて過ごしていきたいと思います.

さいごに

今年もやることは多いですが, 冒頭にも書いたように, 時間を有意義に使っていきたいと思います.

AI で UX を変えることが腹落ちした話

TL; DR

  • シーメンスのサービスを受けて, スペインの鉄道 レンフェ が定時運行率 99.9% を達成したという話を聞いた
  • 「一度作ったら壊れずに使い続けられる機械」と「壊れる前に気付いてメンテすることで使い続けられる機械」は, ユーザ体験 (UX) 的には同義ではないか?
  • 機械が一定レベルの寿命を確保できたら, そこからさらに寿命を延ばすのは大変. でも壊れる前に気付くことができればさらに寿命を延ばすことと同じなので, 後者のほうが優位かも

最近, TL; DR という表現をあまり目にしなくなった気がしますが.

本文

先日, スマホで AI や UX に関する動画を聞き流していたら,

という話題が流れてきた. 今までも AI を使って機械の予兆監視や予兆保全をする話は何度も耳にしたことがあったが, 「それができたら便利だよね」くらいの印象しかもっていなかった. しかし今回, UX の文脈で「定時運行率 99.9% 達成」という話を聞いて, 私自身の理解が少し前進した気がした.

例えば自動車. 私は自動車を保有しているが, ほぼ週末しか乗っていない. それでも保有し続けているのは, 乗りたいときに乗れる便利さが欲しいからだ. これがもし, 乗りたいと思ってから短時間で自動車を借りられるサービスが (それなりの値段で) あれば, 敢えて自動車を保有する必要は無くなる (給油は洗車, メンテの手間からも解放される). 私が欲しいのは自動車ではなく「乗りたいときに乗れる便利さ」なので, それを実現する手段が「自動車の保有」か「自動車のレンタル」かは, どちらでも構わないということになる.

上記の鉄道に関して, これまでは「壊れない鉄道車両」「寿命の長い鉄道車両」を目指して開発・設計がなされていたと思う. しかし鉄道車両が機械部品の集合体である以上は, あるレベルに達したらそこからさらに寿命を延ばすのは大変だし, コストパフォーマンスが悪い. 一方, 壊れる前提で「壊れる前に気付く」仕組みを構築できれば, 鉄道車両自体の寿命は変わらなくても, 故障によるトラブルを無くすことはできる. 鉄道会社にとっては予定通りに鉄道車両を使うことができれば, 長寿命の車両か, 寿命はほどほどかもしれないがメンテナンスによって計画通りに使い続けられる車両かは, どちらでも良いということになる.

つまるところ, 経営学でよく言われる「顧客は製品を望んでいるのではなく, その製品を用いることで困りごとを解決したいと考えている. 自社の製品が解決している顧客の困りごとは何か?」を突き詰めた先に, AI によるソリューションがフィットすれば, 新たな価値を創出できるということだろう.

ただ, ハードに優位性を持っている会社がソリューションにおいて (も) 優位性を築くのは, 相当大変だろうと, ハード寄りの技術者である私は思った. ハード寄りの会社は, ソリューションで優位性を築けるのか? ハード寄りの私は, ソリューションで優位性を生み出せるのか?

余談

シーメンスとレンフェの下りを調べるのに, NotebookLM を使いました. 調査結果を 動画 にしました. 世の中, 進んでますね.

2025 年の競プロ (AtCoder) を振り返る

Summary (Algorithm)

  • Rating ; 527 → 947 (Highest 953 @ ABC437)
  • Highest performance ; 1326 (@ ABC424)
  • Rated Contests ; 43 times
  • Language ; Python

AtCoder でのレート変化 (2025 年)

雑感

2025 年を振り返ると, まずは緑色になれて良かったです. ただ, そこまでに 2 回, 緑色になってから 1 回の谷間 (停滞期) がありました. この 3 回の谷間では, いずれも勉強法を変えました.

5 月頃の谷間は, それまでの貯金 (過去のプログラミング学習で得た知識) を使い果たしたのが原因です. そこで解けない問題の復習などを, 以前よりも真面目に取り組むようになりました.

7 月頃と 11 月頃の谷間は, それまでの勉強法で達することができるレーティングはそのあたりだったということだと思います. 特に直近の谷間については AtCoder NoviSteps の 2Q (と最近は 1Q も) を解くという精進をしています. ただ,レーティングの上昇が緩やかなのは, その道が容易ではないということでしょう.

2026 年の抱負

今以上に精進する時間を確保するのは困難なので, まんべんなく様々な問題を解いて学習するのは難しいでしょう. 1 つずつ解ける問題を増やし, コンテストでは大負けしないようにしながら, 徐々にレーティングを上げていければと思います.

Heuristic (あるいは AI を使ったプログラミング) にも興味がありますが, 二兎を追うのは厳しいので, しばらくは Algorithm で粘ります.

おまけ

2025 年は OnlineMathContest にも参加するようになりました.

こちらは入茶しました. 週末などタイミングの合うコンテストにはなるべく参加しようとは思いますが, OMC 向けに精進するのはしんどいかも.

床屋雑感

床屋へ行ってきました. 私が行くのは, 車で 10 分くらいのところにある, 大型のチェーンのお店です. 広い駐車場があるという便利さと, 一見で行っても全然気まずくないという気楽さがポイントです.

店員さんも多いので, ほぼ覚えている店員さんはいないのですが, 実は今日, 私の髪の毛を切ってくれた人は, 2, 3 か月前に行ったときに切ってくれた人と同じだったということに気付きました.

何故覚えていたのかというと, その人の声が元気だったということと, いつも笑顔だったので, 印象に残っていたためでした. 前回行ったときも「この人, 元気で笑顔だな」と思い, そして今回も「元気で笑顔の人がいるな」と思い出した次第です.

いつも元気で笑顔でいるというのは簡単ではないと思います (私も普段は普通の顔ですし). でも「元気」「笑顔」で一見さんにも良い印象を与えられるなら, そういう態度をとるのもアリかなと思いました.

追伸

私はいつも, 8mm のバリカンで刈り上げてもらうので, 特に冬は散髪前後の頭部の体感温度が変わります. 11 月に切って冬を迎えるというのが, 私にはベストです.

感想戦 ; ABC430

目次

はじめに

OMCG002 に参加しました. OnlineMathContest は少し前からチラチラ見ていたのですが, これまでは都合が合わず, on time でコンテストに参加したことはありませんでした. 今回の OMCG は有志コンテストで Unrated でしたが, 土曜日かつ 10 時間という条件だったので参加してみました.

結果的には A, B の 2 問正解で, 順位は 105 位.

OMCG002 の解答結果

100 点の A, B だけ解いて離脱しようと思いましたが, A がなかなか解けず. 一旦 B を解き, A も何回か誤答を繰り返し, 最終的に何とか正答できました. 実は図形の問題は得意ではなく, 受験生の頃に 大学への数学 の図形問題を集めた増刊号に取り組んだ記憶がよみがえりました.

さて ABC430 です. 今回から Codon が使えますので, 計算量が気になるときに試してみたいです. ここのところ負けが続いているので, 何とかしたいところです.

今回は B 問題から見ていきます.

B - Count Subgrid

atcoder.jp

与えられたサイズでグリッドを切り取ったとき, 何種類あるか? という問題. 250 点とちょっと難しめ. 重複させずに数えるときは set() を使うのが常套手段ですが, 例えば切り取ったグリッドを「リスト」で表現していると, そのまま set() に放り込むことはできません.

私は, 切り取ったグリッドを各行をつないで 1 つの文字列にして, それを set() に入れました. 文字列操作は計算コストが大きいですが, 今回の制約なら何とかなるという見通しです.

13:14 にAC.

C - Truck Driver

atcoder.jp

さて, 問題はここからです. 最初は尺取りでできるかな? と思ってコーディングしてましたが, 普通の尺取り, すなわち

  • 条件を満たす間は r をインクリメント
  • 条件を満たさなくなったら l をインクリメント

ではすべての場合を数えきれないことに気付きました (ここまでも結構時間が掛かりました)

ならば累積和を計算して, 任意区間の "a" と "b" を数えようとしましたが, O\left( N^2 \right) の時間計算量では間に合いません.

コンテスト中にできたのはここまでで, 結局のところ解けませんでした (;_;)

終了後に解説を読み, 単調増加なので二分探索を使えばよいことを知り, コンテスト終了後 18 分で upsolved. まだ基本が身に付いていないことを実感させられた問題でした.

D - Neighbor Distance

atcoder.jp

「部分的に更新していく」ということは分かりました. が, リストを常にソートされた状態で持っておく必要があるので, 新しい X_i を挿入する場所を効率よく探すにはどうすれば良いか? と考え, そこから先に進めませんでした.

ここで私が見落としていたのは, D 問題の実行制限時間が 4sec ということ. 以前にも実行制限時間を見落としていたことがあり, それ以来, 必ず実行制限時間を確認していたのですが, 今回は焦りのせいで見落としていました.

さて, コンテスト後に解説を参考にしながら, データは list() で持ち, 新しい X_i を挿入する場所は bisect で探す方針でコーディングしましたが, 結果的に TLE.

Twitter で「SortedSet を使った」というのを見掛けたので, SortedSet を使ったら何とか AC できました. ただし実行時間は 3884ms とギリギリ.

試しに, 最初にすべての X_i を並べてそれぞれの最短距離を求めてから, 逆順に減らしていく方針でもコーディングしてみました. 実行時間は 3400ms と 1 割くらい速くなりました.

E - Shift String

atcoder.jp

備忘録的に書いておきます. 解説では z-algorithm の解法が紹介されていましたが, Twitter で CPython なら find() で通る と見かけました. そこで, find() を使った速度を比較しました.

処理系 結果 コード
PyPy AC x 36, TLE x 16 #70655102
Codon AC x 40, TLE x 12 #70655121
CPython AC x 52 (41ms!) #70655131

確かに CPython が圧倒的に速い. 「大抵は PyPy が速い」との説明を見ることが多いし, 実際正しいのだと思いますが, CPython が速い場合もあるんですね.

結果

AB 2 完でしたが, B 問題の 250 点に救われて, 前回の ABC429 よりはパフォは上でした.

今回の学び.

  • 実行制限時間や制約はきちんと確認しよう
  • 単調増加は二分探索で探す (ちなみに極値があるときは三分探索)
  • ソートされたデータを使うときは, 素直に SortedSet を使う

来週以降もめげずに頑張ります.

感想戦 ; ABC429

目次

はじめに

先週は, 大学の同窓会に参加したので ABC428 は欠席しました. 大学では, 国からの予算が減らされているせいか, 至るところで 寄付 の話が出ました. 研究のための寄付や建物改修のための寄付などです. 先日, ノーベル賞 の発表があり, 日本人受賞者 (だけ?) が話題になりました. しかしながら大学は苦しんでいます. ただ, 結局のところは科学に対する国民の興味・関心が低下した結果, 科学に対する予算が減り, 研究機関が苦しい状況になっている, ということなのかもしれません.

国立公文書館も寄付を募っている ということが SNS で話題になりました. こちらも, 国民の興味・関心の低下の現れでしょうか?

さて, ABC429 です. 配点は 100-200-300-425-450-525-625 で, A ～ C を解いたうえで D もしくは E にチャレンジできると良いかな? と思いました.

今回は C 問題から見ていきます.

C - Odd One Subsequence

atcoder.jp

整数列から 3 つの数字を選んで, そのうち 2 つが同じ, 1 つが異なる場合の数を求めます.

  1. 整数列内に, どの数字が何個あるか? を調べておく
  2. 「複数個ある数字から 2 つ選ぶ選び方」と「その数字以外の数字の個数」の積を計算し, 「複数個ある数字」の全てに対して和を取ります

計算は簡単ですが, デバッグ用の print() 文を消し忘れた というミスを犯し, ここで 2 ペナ食らってしまいました (泣)

14:38 に AC です.

D - On AtCoder Conference

atcoder.jp

M が大きいので, 座標圧縮的な考え方で「位置, 人数」のリストを作り, 尺取り的に考えるというイメージは分かりました. ただ, 地点 i を 1 つずつインクリメントしていく考え方 (これは間違い) と, 人がいる位置ごとに計算する考え方 (こっちが正解) がごっちゃになってしまい, 結局のところ適切にコーディングすることができませんでした (泣)

落ち着いてやれば分かったかもしれませんが, コンテスト中に落ち着くのも技術と考えれば, まだ技術不足といったところです.

翌日, 解説 AC です.

E - Hit and Away

atcoder.jp

D で混乱している中, E もトライしました. 私は「 S に直接つながっている D を始点に BFS すれば良いのでは?」とか「 S から S への移動は無駄では?」と, 難しく考えてしまいました (このような考え方ではテストケース 2 が通らない). 素直に

  • S を始点とする, 多始点 BFS にする
  • 各頂点について, 異なる 2 つの始点から到達するまで探索を続ける

とすれば良いです.

ただ, 探索の継続 or 打ち切りをどこで判断するかが難しくて, 結構悩みました (できてしまえば, あぁなるほどというコードになりました).

悔しかったので, コンテスト終了後の深夜に解説 AC.

結果

前回に続き, 2 回続けて茶パフォで, レーティングは下降中です. 次回には, 何とか食い止めたいところです.

今回の教訓は,

  • まず, 落ち着け
  • テストケースにも目を通してから, 考察を始めよう

感想戦 ; ABC427

目次

はじめに

衣替えをせず, まだ通勤時に半袖シャツを着ていますが, 朝晩はちょっと寒いかな? と思うような気候になりました. でも日中はそれなりに暑く, また太陽の高度が下がっているため上からではなく横から暑さが来る感じがして, イマイチです.

今週のトピックスは, ADT で言語アップデートの先行運用が始まったことですね. Python 使いにとっては Codon が注目点です. 通常の Python より「静的型付け」など制約がありますが, スピードは速いです.

私も今週, Codon をトライしてみました. 暗黙の型変換ができないので, 変数の型を意識しながら書く必要があります. 例えば, よく使う

# usually
N, M = map(int, input().split())

は Codon ではエラーになります. Codon を通すためには

# for Codon
N, M = list(map(int, input().split()))

のようにします. しばらく ADT では Codon 向けに書いてみて, 徐々に慣れていこうと思います.

さて ABC427 です. 配点は 100-200-350-425-500-525-625 と C と D が高めです. C で長考してしまういつものパターンが頭をよりぎりますが, 頑張ってみます.

今回は A を飛ばして, B から振り返ります.

B - Sum of Digits Sequence

ポイントは関数 f\left( x \right) (各桁の和) をどう表現するか? でした. 私は以下のようにしました (解答)

  • 整数がある (x)
  • 文字列に変換する (str(x))
  • リストにする (list(str(x)))
  • 数字に戻す (list(map(int, list(str(x)))))
  • 和を計算する (sum(list(map(int, list(str(x))))))

C - Bipartize

そして C. 結果的に長考となりました. 最初に考えたのは, 以下のような方法です.

  • 頂点 1 から探索して色を塗り, 矛盾が生じた辺の数を数える
  • あるいは UnionFind を使って最小数の辺 (点の数 - 1) で連結にした後, 点に色を塗り, 残った辺が矛盾なく入れられるかどうかを調べる

ただし, いずれの方法も「任意に選んだ塗分け方法で, 矛盾する辺の数が最小になるか?」が不明確で, 結果的に WA でした.

あらためて制約を見ると点の数は高々 10 で, 塗分け方は 2^{10} となり十分小さいです. そこで塗分け方を全探索 (bit 全探) し, それぞれに対して辺を張ったときに矛盾する辺の数を数え, その最小値を求めました. 58:32 に AC となりました.

bit 全探と気付いてからは, 迷いなくコードを書けたところは良かったです.

C 問題は一般的に計算量の見積もりが大事と言われます. その際, 効率的なアルゴリズムを適用することを考えがちですが, 一方で愚直な方法の計算量を適切に見積もって, それが間に合うかどうか? という冷静な判断も大事ですね (最近, 愚直で間に合う C 問題をよく見る気がします).

D - The Simple Game

問題を見て「あっ!」と思ったのは, 今週の ADT に似たような問題が出ていたからでした.

atcoder.jp

こういうゲームの問題は, ゴールに達した状態から逆向きに DP する のが定石で, 私もそれは分かりました. ただ, 具体的な実装まではたどり着けませんでした.

私が考えたは, K が大きくないから, 頂点 1 から 2K 回で行ける範囲を再帰的に全探索して, 最終的にどちらが勝つかを調べるというもの. しかしコードを正確に書ききれなかったことと, この方法で探索すると計算量が多すぎるということから, 提出まで至りませんでした.

解説を読んで, Upsolved. コードはちょっと長いですが, 考え方は割とすっきりしています.

追伸 ; ADT_20251007_1 ; G - Stones も解説 AC しときました.

E - Wind Cleaning

コンテスト中にチラ見しただけで終わりました.

  1. 風が吹くと, 考える領域を小さくできる (例えば初期状態から下向きに風が吹けば, 一番下の行のゴミが無くなるので, 以降は考慮しなくて良い)
  2. 風が吹いたとき, 高橋君はゴミで汚れないか?

を考えながら, 風が吹く方向で BFS すると良いみたい → Upsolved (写経 AC)

結果

茶パフォでレーティングが下がってしまいましたが, 瓦が割れなかっただけ良しとしましょう (前向き)

日頃, ADT の考察でトレーニングしてますが, 分からない問題は「今, 分からなくても, そのうち分かればいいや」と思って解説を見ないことが多いです. 配点が 500 点以上の問題はそれでも良いかもしれませんが，450 点以下で分からない問題は解説を見て解けるようになっておくべきかな? と思いました.