大学生のリアルな技術的視点をお届けします 2026-07-01T23:28:32+09:00 https://TrueRyoB.github.io/blog/ true trueryob@proton.me © 2026 true 2026-06-26T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/26/world-model/

論文を読み始めました。

<p>自動車学校の免許合宿 延泊なしで卒業できてよかったです。長野楽しかった。</p> <hr /> <p>深層⽣成モデルと世界モデル</p> <p>鈴⽊雅⼤ 2023年3月</p> <p>問題設定</p> <ol> <li>近似推論の計算　観測変数が複雑な場合</li> <li>出力の精度の改善</li> <li>マルチモーダル環境の設計</li> </ol> <p>解法</p> <ol> <li>低次元に潜在変数の空間を圧縮し、ガウス分布に落とす。正則化項による調整で仮説通りのモデル化を発生させる。</li> <li>低解像度から高解像度に変換するdiffusion modelによる局所解決 / マルチモーダルの活用による文脈の局所化</li> <li>条件付け深層生成モデルによるエージェントの視点と行動からの世界の不変構造の学習</li> </ol> <p>感想:</p> <p>物理制約以上の示唆をDLモデルが見出すための環境作りが難しそう。恐らく、シミュレーションに閉じず、ビッグデータに頼らざるを得ない。 また、用途によってエージェントの性質を変えるべきであり、最終系が人を模したものであるべきでないことも複雑。</p> 2026-06-26T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/26/turned-light-blue/

俗にいう色変記事です。お気持ち表明を兼ねています。

<h2 id="前置き">前置き</h2> <p>2026年現在 大学三年生のtrueです。</p> <p>始めてから13カ月、ようやく入水を達成しました。記念に自分が考えていることをざっくばらんに共有したいなと思っています。</p> <p>他の競技プログラマ(以下競プロer)と異なり、自分の成長曲線はかなり特殊であるため、その観点で楽しんでいただければと思っています。</p> <p>具体的には、参加してから10か月ほどずっと同じような成績で停滞していましたが、ある日を境に、突然下位黄色帯のperfしか出せなくなりました。</p> <p>適当に読み飛ばしつつ、何かしら持ち帰っていただければ幸いです。</p> <p>よろしくお願いいたします。</p> <p>尚、これは私個人の意見であり、何かしらの母集団を代表する訳ではないことをご承知おきください。</p> <h2 id="自己紹介">自己紹介</h2> <p>大学ではコンピュータサイエンスを専攻していて、情報系の研究室で、塩基の自己組織化現象の計算モデルを扱っています。</p> <p>Twitter: @aphelios_like <br /> Github: TrueRyoB</p> <p>可処分時間が多いことが、競プロにおける私の唯一の強みです。</p> <p>一方で、弱みは多い模様です。</p> <ul> <li>異常に飽き性です。</li> <li>読み飛ばしが多いです。</li> <li>納得するまで次に動けません。</li> <li>感情によって成果の質が影響されやすいです。</li> <li>大学の交友関係において、競プロに興味を持ってくれる方がいません。</li> </ul> <h3 id="なぜ競プロを始めたか">なぜ競プロを始めたか</h3> <p>そもそもなぜプログラミングを始めたかということからお話しします。</p> <p>自分の家族はかなり各地を転々とするタイプです。社会に馴染む上で自分を定義するために、周囲の人間ではなく、自分という存在を、ただの憲法で保護された有機生命体ではなく、一人の人間とさせる軸を持つ必要がありました。</p> <p>その軸に該当するのが、自己表現でした。自分は、今思えば、何にでも挑戦する素養こそありましたが、少し手をつけてみて、合わないと思えば、すぐにそこで切り捨ててしまう節がありました。その中には、例えばピアノや文字書きなどが含まれます。</p> <p>プログラミングはかなり特殊でした。まず、ある程度の参入障壁があります。そして、機能美を求められている訳ではありません。あくまで、動けば、それで利用者は満足してくれます。最後に、反復修正がとても容易です。手先が不器用でも全然問題になりません。</p> <p>このような性質から、自分は、多少の能力不足があっても、ある程度の成果を残せるであろうという観点から、プログラミングをいたく気に入りました。</p> <p>これが高校二年生くらいの話で、それから隙間時間にwebアプリやミニゲームを制作するなどしていました。</p> <p>大学二年生に差し掛かった夏のときに場面が移ります。</p> <p>自分はとても困っていました。上記の持論は、自分が親に養われている立場であるからこそ成立していたのです。具体的には、自分以外にも、世界にはコードを書ける人がほぼ無限にいて、ソフトウェアの性質として、一回作られたものは再配布が異常に簡単であるという現実に対して注意を配れていないことに気づきました。同じ課題を認識していて、解ける人など無数にいます。その中から、あえて自分のが選ばれる理由は皆無でした。そういった競争社会の制約を無視できたのは、稼ぐ必要をそもそも認識していなかったためです。</p> <p>そこで、我こそがと主張するための根拠ないし自信が欲しくなり、競技プログラミングという工程にて客観的な技術指標を得ようという成り行きになりました。</p> <h3 id="自分のレート遷移について">自分のレート遷移について</h3> <p>情報系の活躍の場は、競技プログラミング関連に限定されません。</p> <p>伸びが停滞しているとき、自分が大器晩成型だと言い聞かせてリスクを取り続けるよりは、戦略的離脱する方がよっぽど合理的に思えました。</p> <p>上位勢の思考パターンを模倣できたらとの願望のもと続けていましたが、幾ら練習を重ねても、参加当初から10カ月、成績が全く伸びなかったため、心が折れていました。</p> <p>そのため、学生選手権という重要なコンテストを潮時だと捉えて、それまでに、圧倒的な成長を示す指標がなければ引退するという覚悟のもと過ごしていました。</p> <p>そこで、最後の週で、急に、上位20%帯から3%帯へと、コンテストの成績が爆発的な変化を遂げたものなので、自分の無意識的な変化に大変驚いています。</p> <h4 id="コンテスト詳細">コンテスト詳細</h4> <p>ABC462にて初めて6完をしました。</p> <p>今までは、ずっと後一押しで5完が届かないという状態が続いていました。</p> <p>当時は、引退前最後のABCと捉えていて、焦ることもなく、ただ目の前に出てくる問題を淡々と解き続けていました。</p> <p>とても遠いと思っていた存在が、あっさり手に入ってしまい、あまり自分事のように捉えられない節があります。</p> <p>ところで、そのABCの前には、認識している中だと、以下のような特殊イベントがありました。</p> <h5 id="1-メガベンチャーでの長期インターン">1. メガベンチャーでの長期インターン</h5> <p>株式会社ユーザベースにて5月中旬から内定者インターンをしています。</p> <p>通勤時間も含めると、毎日9時間は考えっぱなしです。</p> <p>対して、大学では、完全に思考停止した生活習慣でした。</p> <p>頭を使うことが常習化したことが、何かしら競プロに作用したのかもしれません。</p> <h5 id="2-arcにて初の0完">2. ARCにて初の0完</h5> <p>ABCにて水perfを連発していたので、あまり調べもせずに、なんとかなるだろうと高を括って挑みました。</p> <p>結果、茶diffのA問題がずっと解けず、論理的思考のろもなかったかもしれないと判明して、とても悲しくなりました…</p> <p>ここで、自尊心が完全に消え失せたように思います。</p> <h5 id="3-何も精進しない期間">3. 何も精進しない期間</h5> <p>このABC前の一週間の間は、競プロ以外のことに専念しており、streakを維持することも辞めていました。</p> <p>この短期間のブランクが、もしかしたら精神状態の安定に繋がったのかもしれません。</p> <p>複数のタスクがあると、どうしても片方のことを常に意識してしまい、常にやるせなさを感じる傾向にあるので、自分自身に説明責任を果たす必要があったのだと思います。</p> <h2 id="水色コーダーに対しての見方">水色コーダーに対しての見方</h2> <p>結論から話すと、水色帯付近以上の人々はとても優秀だと思います。</p> <p>chokudai氏のブログでは”日本のIT企業において、技術力がカンストしている”と評価されています。</p> <p>自分は、あんまりこの論点に納得していません。別にAIでも同様の設計実装および説明責任を果たせるためです。</p> <p>では、一体何を以て競プロerはすごいのか、或いは競プロを通じてどんな素晴らしいことが得られるのか。一般的に思われているものと違う可能性があるので、その正体について紹介します。</p> <h3 id="得られたこと">得られたこと</h3> <h4 id="1-思考のノイズが減る">1. 思考のノイズが減る</h4> <p>問題設定に対して、忠実に取り組む必要性から、余計なことを考えないように思考傾向が矯正されたと感じています。</p> <p>「集中力」とは、ちょっとニュアンスが違う気もしています。</p> <p>メモなどの外部媒体に頼らなくても、DPの複雑な状態設計を組んだり、探索範囲の上界と下界を示すなどができるようになりました。</p> <h4 id="2-体調管理ができる">2. 体調管理ができる</h4> <p>競プロはスポーツです。</p> <p>決められたタイミングに、自身の最良を再現することが、好成績を残す上で、とても重要になります。</p> <p>強さを追求していく過程で、自己管理能力を磨く必要性が生まれてきます。</p> <p>勿論、寝不足の日とかは、実装が一生できなくて、余裕で灰perfを取ってしまいます。</p> <h4 id="3-手段ではなく目的主体になる">3. 手段ではなく目的主体になる</h4> <p>競プロerのライフサイクルとして、解きたい問題をぐっと睨んだ後に、問題設定のボトルネックに適切なアルゴリズムを起用するという工程が含まれます。</p> <p>手段ではなく、目的が先導している好例です。</p> <p>問題解決にあってはならない「手段からできる目的を狭めてしまう」という認知バイアスは排除済といった具合です。</p> <h3 id="得られなかったこと">得られなかったこと</h3> <p>以下は、自分が初学者の頃に期待していたものとその答え合わせになります。</p> <h4 id="1-アルゴリズムは問題解決における銀の弾丸">1. アルゴリズムは問題解決における銀の弾丸</h4> <p>誤りです。</p> <p>あくまで、計算量を落とすための実装の工夫に過ぎないと思っています。</p> <p>ただ、離散構造に対しての考え方の土台としては、とても役に立ちます。</p> <h4 id="2-自信">2. 自信</h4> <p>少なくとも、私にとっては、誤りです。</p> <p>当たり前の標準が上がってしまうのは、時々精神的に厳しいです。</p> <p>裏を返せば、課題感を意識できているという話でもあります。</p> <h4 id="3-直感を厳密性をもって説明-および-再現できる">3. 直感を厳密性をもって説明 および 再現できる</h4> <p>プログラムは、自然言語で書くことができません。</p> <p>自分がやりたいことを操作に置き換えられて、初めて土俵に立てます。</p> <p>そして、やりたいことが目的とずれている時、容赦なく不正解のラベルを押し付けられます。</p> <p>ここで、発想を正しく設計する動機が生まれます。</p> <p>…はずなのですが、自分はまだ理想まで程遠いです。語彙力が欠けていることや、単調性などの重要な性質の理解不足が原因に含まれます。</p> <h4 id="4-不確定な状況への耐性">4. 不確定な状況への耐性</h4> <p>状況によります。</p> <p>解法が存在するという前提があるからこそ、考え進めることができますが、そうでない場合は、中々厳しいです。</p> <p>例えば、ヒューリスティック最適化で必要になる、自分で最良の状態を定義して、制約を設定するなどの素養は、まだまだ発展途上です。</p> <h4 id="5-開発力">5. 開発力</h4> <p>念のため記しておきます。</p> <p>要件を満たす最小構成を設計するという能力を活かせるかもしれません。</p> <p>ただ、開発において重要なのは、ロジックの構築ではなく、ドメイン知識と可処分時間の投資だと思っています。作るものにもよりますが、あまり競プロで培われる能力の比重は大きくありません。</p> <h2 id="競技プログラミングで強くなるためにするべきこと">競技プログラミングで強くなるためにするべきこと</h2> <p>他の入水記事では、よく具体な取り組み内容が紹介されています。</p> <p>なので、自分は、代わりに、取り組む姿勢を一部紹介したいと思います。</p> <h4 id="1-目標を作る">1. 目標を作る</h4> <p>割と当たり前ではありますが、かなり重要です。</p> <p>競技プログラミングのような、毎週実力の一部が見え隠れする形式の成果の解釈には、注意が必要です。</p> <p>コンテスト結果に一喜一憂してしまっていては、本質的な取り組みの代わりに、自分の気分を立てるための表面上の取り繕いに走ってしまう可能性が高くなるためです。</p> <p>そもそも、自分の努力の結果が反映されるのは、大体三カ月ほど要することが知られています。(出典不明)</p> <p>自分は、目標値を固定することで、ある程度俯瞰して分散を把握することができ、まともにコンテスト結果や精進の効果を捉えられるようになりました。</p> <p>この目標とは、成果目標と努力目標に分けて考えられるはずです。</p> <p>自分は、成果目標を入黄としています。</p> <p>そして、努力目標を「簡単を落とさない」としています。</p> <p>前者の根拠は、あまりありません。コミュニティ内で上位に相当する「暖色」に分類されたかったという程度の動機です。</p> <p>後者は、師匠に教えてもらいました。この文言を解釈し直すたびに、この重要性に気づいて、驚かされてしまいます。</p> <p>補足をすると、この言葉は「未知に畏怖しない」と「出来ることを確実に積み重ねる」の二つの意味が少なくとも内包されていると思っています。</p> <h4 id="2-acまでの道筋を整理する">2. ACまでの道筋を整理する</h4> <p>初学者が最初に迎えるであろう壁は、初見で解く道筋が見つからない問題への取り組み方と思っています。</p> <p>この現象を説明してみましょう。</p> <p>基本的に、競技プログラミングのアルゴリズム部門では、以下のような手順を辿ります。</p> <ol> <li>問題文を読む</li> <li>構造を理解する</li> <li>方針を設計する</li> <li>実装する</li> </ol> <p>説明として、以下を挙げます:</p> <ul> <li>よく言われる「愚直に」とは、2と3の工程を飛ばすことを指します。これは、問題文が既に設計と同義なため、起こり得ます。</li> <li>パターンマッチングというのは、3を飛ばして、2から4に飛躍している様です。精進の恩恵の大部分はここで受けます。</li> </ul> <p>初学者が、アルゴリズムを勉強したとしても、解法にたどり着けないのは、恐らく1か2が疎かになっているためです。</p> <p>訓練なしで成長は基本ありません。それぞれの工程を認識して、それに特化した練習をすれば、適切に働きかけられます。ただ、それに気づかず、簡単な問題を解いているだけでは、いくらだっても、その抜け落ちている工程に対して、取り組めるようになる日は中々来ません。</p> <p>今の自分がどこにいるかを、レート帯という提出ありきで決まる粒度ではなく、細分化して評価してみることが重要です。</p> <p>それぞれの項目に対して、どのような精進方法が有効かの例示とその説明は、別の記事で紹介しようと思います。</p> <h4 id="3-慣習を踏襲する">3. 慣習を踏襲する</h4> <p>とても重要です。</p> <p>競プロは基本的に相対評価の世界です。そのため、他と同じようなことをしていても、抜き出ることは出来ないと、斜めに構えてしまうかもしれません。</p> <p>その結果、一見非効率に思える精進方法(例えば、低色埋めなど)を、部分的な側面でのみ批判して、手を付けることなく、証明されていない自己流で勝負してしまいます。</p> <p>論理的に考えると、初学者が訓練方法の恩恵をすべて把握できる訳もなく、また、それを通じて成長した人が、その訓練方法がどう寄与したか説明できる訳もありません。ただ、相関性があれば十分なのです。</p> <p>自身の能力を過信せずに、堅実に取り組みましょう。コツコツ続けることは、達成感を得づらいため、孤独感に襲われがちです。</p> <p>その時に意識してほしいことは、皆スタートラインが異なり、到達すべき方向に対して進んでいることこそが重要だということです。自分は、この、分からないことが分からない状態に耐え続ける期間に、これにとても助けられました。</p> <h4 id="4-自分なりの環境を探し続ける">4. 自分なりの環境を探し続ける</h4> <p>これは体調管理の延長線上にあたります。</p> <p>競技プログラミングの実力へ関与している要素は、考察の精度や実装力に閉じていません。</p> <p>そして、人が皆特別なように、一般的な慣習が貴方に適さないこともあります。</p> <p>これは先ほどの項目と相反しているようですが、短期間で検証可能という意味合いで、共存可能です。</p> <p>具体の話をすると、あまり聞かない取り組みですと、私は結果的に、以下を取り入れるようにしています。</p> <ul> <li>拡張機能で点数配分や問題ラベル および 提出結果を隠す</li> <li>数式を書く以外の用途で紙と筆記用具を封印する</li> <li>ABCはE問題から解く</li> <li>ツイッターとdiscordをコンテスト終わりまでアクセス制限する</li> <li>使用言語をC++からC#に乗り換えてタイピングの負担を軽減</li> </ul> <p>別に尖れと言っている訳ではありません。ただ、少しの工夫ないし変化が、劇的な効果をもたらす可能性を放置しない方がいいという話です。</p> <h2 id="競プロへの想いと今後の展望">競プロへの想いと今後の展望</h2> <p>実利の観点では、疑問視しています。</p> <p>それは、やはりAIの台頭が背景にあります。</p> <p>アルゴリズムや問題解決能力といったものが、特にソフトウェア界隈において、民主化されています。</p> <p>そもそも、今の世の中には未解決問題で溢れているというのに、わざわざ解法が判明している問題を作っては解いているという光景に対して、少し違和感を覚えています。教育もしくは競技としての意義は理解した上でです。</p> <p>ただ、それでも、趣味として、とても好きです。</p> <p>こんなに、罪悪感なく、達成感の実感を回し続けられるゲームは他にありません。</p> <p>コミュニティには、同世代の同じような人がわんさかいるため、居場所を感じます。</p> <p>AtCoderにおいては、今後はARCにのみrated参加しようと思っています。</p> <p>本質のみ抽出するという素養に、かなりの苦手意識を覚えており、それを集中的に改善したいからです。</p> <p>万が一、緑落ちしてしまったときには、出稼ぎでABC参加は免れませんが。</p> <p>競プロにおいては、現在、他の競プロerさんの精進のための施策を幾つか進めています。</p> <p>その内の一つは、現在の実力を可視化するwebアプリで、現在個人開発中です。技術スタックは特になく、Claude Codeに全部任せています。一緒にデザイン・アルゴリズム・運用方針を考えてくれる方を募集しています。</p> <p>生活については、取り合えず研究の真似事に注力したいと思っています。結果的に、競技プログラミングでは、根拠となる数値こそ得られませんでしたが、成功体験(AC)は無数に積ませてもらえました。</p> <p>将来的には、実際の社会問題に対して、同じように取り組み、ACの恩恵を、自分に留めず、周囲に還元できればと望んでいます。</p> <p>ここまで読んでくださり、ありがとうございました。</p> 2026-06-21T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/21/sad-girl-sex/

どこか『サッド・ガール・セックス』に通じるものがあります。

<h2 id="競技プログラミング">競技プログラミング</h2> <p>AHC（AtCoder Heuristic Contest）と呼ばれる競技は、「人がソフトウェア開発に介在する価値」を担保している最後の砦のようなものだと、自分は解釈していました。しかし今回のコンテストで、その前提が正面から否定されてしまったように感じます。</p> <p>ここで、ソフトウェアエンジニアとして、自分の立場がどう変わるのかを考えてみました。</p> <p>最大のリスクは、とりあえず「雇用枠の減少によって飢えること」だと仮置きしてみます。すると本質的な問題は、AIに置き換えられることそのものではなく、「置き換えられてから、社会制度が整って生活が担保されるまでのタイムラグ」をどう生き延びるか、という点にあると気づきました。</p> <p>この前提だと、そのタイムラグが0に限りなく近いほど、より良い訳です。</p> <p>であれば、ただ手をこまねいて待つ筋合いはありません。自分はこの「一見、逆境に立たされている」という当事者としての立場すらも、周囲のステークホルダーを巻き込み、次の一手を動かすための武器として活用していきたいと考えています。</p> 2026-06-20T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/20/coward/

欠点にばかり注目してしまいます。

<p>毎日ペヤング生活。常識的に考えれば、自殺行為に近い食生活であり、周囲から止められて然るべきだと思う。</p> <p>ただ、いざ自分がその立場になってみると、不思議と心地よさすら感じてしまっている。</p> <hr /> <h2 id="自動車学校">自動車学校</h2> <p>「操作」と「状態」を分離して考えるとは何かを、ようやく根本から理解できた気がする。</p> <p>要領の良さとは、理想状態における自分の立ち位置をどれだけ鮮明に描けるかに大きく依存しているのだと思う。結局のところ、その解像度が高いほど逆算がしやすくなる。</p> <p>では、その解像度を後天的に高めるにはどうすればよいのか。その方法論を探ることが今後の課題である。</p> <h2 id="競技プログラミング">競技プログラミング</h2> <p>入水した。</p> <p>これを機に、もう ABC には出ないでおこうと思う。</p> <p>憧れていた中位勢の一部を見ていて感じたのは、思考法そのものよりも、思考に対する態度への違和感だった。あるべき検討を避け、妥協や弁明によって現状を正当化しているように見える場面が少なくなかった。</p> <p>私は「朱に交われば赤くなる」をとても警戒している。</p> 2026-06-19T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/19/sudden-dusk/

刹那の静けさにて集中力がピークに達します。

<p>すれ違いで過半数を占める4人が卒業した。そして、談話室に私以外だれもいなくなった。蛙の鳴き声と空調の音とタイピング音が心地よく混ざり合っている。</p> <hr /> <h2 id="自動車学校">自動車学校</h2> <p>意外と自分は車を乗りこなせるかもしれない。強いて言うなら、停車用のブレーキ処理は、普段のとは異なる時間軸で動かさないといけないため、そこが厄介。一応ピアノを少し弾けるので、同じ要領でクリアしたいところである。</p> 2026-06-18T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/18/void/

新天地長野は壮絶です; 自我がない方が適応できるのかもしれません。

<p>エスカレーターの段差が生まれる場所で、目の前のおばあさんが後ろ向きに倒れた。慌てて赤い非常停止ボタンを何度も押したが、うんともすんとも言わない。「止めて〜」という声だけが空しく響いていた。</p> <hr /> <h2 id="自動車学校">自動車学校</h2> <p>運転において最も厄介なのは、一人称バイアスだと思っている。自分の思い通りに車が動くため、他人も自分と同じだけ状況を認識できているような錯覚に陥りやすい。</p> <p>運動神経に恵まれているタイプではないので、私は感覚ではなく論理で自分を追い込むしかないと思っている。</p> <h2 id="競プロ">競プロ</h2> <p>初めて私営バチャに参加した。1450perf程度で、思った以上に解けず驚いた。</p> <p>方針を立てるところまでは概ね筋が通っていたものの、細部に残る違和感を潰し切れるほどには頭が回っていなかった。</p> 2026-06-17T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/17/sleep/

お休みです...

<p>疲れが溜まりすぎていたのかもしれない。通勤の際に、最寄り駅をついに寝過ごしてしまった。信頼貯蓄をたった一カ月目で使い果たしてしまった。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>ちゃんとした議論が出来て良かった。競プロの経験が役立っているように感じた。行動と結果の軸を単純グラフとして見立てることで、複雑な相関関係を紐解けた。 一方で、自分に課されたタスクはLV手前に終わらせることができなかった。引継ぎ対応してくれたSさんに大変感謝である。 Claude Codeに対してスキルを設けることで、チームのそして自分のバリューを守らせた実装をできるようワークフローに自然に組み込みたいと思う。</p> 2026-06-16T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/16/shackled/

二つ以上を同時に意識することが困難です。

<p>久しぶりに風呂へ入ることを怖いと感じた。正確には、部屋に最後の一人として取り残された状況で、普段なら何の抵抗もなくできる行動が急にできなくなった。監視者がいなくなると、時間が止まっているかのように錯覚してしまう傾向が治らない。</p> <hr /> <h2 id="南国ソフト">南国ソフト</h2> <p>プレゼン自体は、抽象論と具体論が入り混じった整理不足の構成だった。しかし当初の目的であった「細部を詰めるための議論を生み出す」という点では成功だったと思う。</p> <p>一方で、議論を進める際の共通フレームワークが不足していた。ドメイン駆動設計のような枠組みを前提として認識を揃えられていなかったため、何を価値とみなし、どの要件を優先すべきかについて共通理解が形成されなかった。その結果、要件をどのようなUIへ落とし込むべきかの判断に苦労した。</p> <p>今回は Claude Design が良い叩き台を生成してくれたため議論を前へ進められた。しかし、より複雑な要件を扱う場合、このような解決策だけに頼ることはできないだろう。ファシリテーターとして、議論の前提や評価軸を整理し、意思決定を導けるようになりたい。</p> <p>そもそも要件からUIへの変換は、各要求の優先度や重要度を定義できれば、ある程度は論理的に導出できるはずであった。</p> 2026-06-15T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/15/ameba/

四方八方に手を伸ばした結果、千切れそうです。

<p>業務で Claude Code の利用権が支給されている。ふと、片手間に Notion MCP の恩恵を享受しようと思い、社員自己紹介ページから情報を抽出して、誰がどの音楽アーティストのファンなのかを調べさせていた。結果として、5 hour session limit を一瞬で使い切った。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>役割の認識と理解こそが、課題解決において最も重要だと気づいた。</p> <p>私は、アプリの機能を Web にも展開するプロジェクトを任されていた。本来であれば、既存アプリと Web 版との体験差をどう埋めるかに頭を使うべきだった。しかし実際には、ロジックの管理方法ばかり考えていた。しかも、それが面白そうだからという、あまりにも子供じみた理由である。</p> <p>典型的な罠を見事に踏み抜いていた。自分は元来、与えられた枠組みを疑ってしまう性質があるので、今後も事業への貢献や優先順位を忘れて、自分の担当範囲外へ首を突っ込みそうな気がする。そのときは、自覚的でありたい。まず自分の責務を果たし、その上で余力を使うべきだろう。</p> <h2 id="self-assembly">self-assembly</h2> <p>仮の研究軸はできていたものの、次に読む論文の選定に苦戦していた。しかし、読んでいる論文の引用文献を辿り、気になったものを拾っていけば自然に知見を広げられることに気づいた。</p> <p>今日は時間的な余裕がなく、目星をつけるだけで終わってしまった。それでも、次に何を読むかは見えてきた。明日が楽しみである。</p> 2026-06-14T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/14/wandering/

何もかも楽しく感じる時期に突入しています。

<p>夕方、気持ちよく走り始めた。</p> <p>「速く動き続ければ、害虫は物理的に身体に留まれないため刺されない」と聞いていたので意気揚々と走っていたのだが、代わりに数匹まとめて喉の奥へ吸い込んでしまい、ひたすら苦しむ結果となった。</p> <hr /> <h2 id="self-assembly">self-assembly</h2> <p>2時間ほどまとまった時間を取って論文を読み、AIにも好き勝手質問した結果、ある程度の展望が見えてきた。</p> <p>自己組織化はまだ発展途上の学問であり、理論と実証がさらに蓄積されれば、自己修復や自己再生だけでなく、より高次の自己進歩的なシステムへ応用されていく可能性がある。</p> <p>私はこうしたロマンに強く惹かれるので、その方向性が見えてきたことは素直に嬉しい。</p> <p>当面は kinetics や thermodynamics の素養を身につけることを優先しつつ、CCT の実用化に向けた検討を進めたい。</p> <p>また、教授と腰を据えて議論できるレベルまで理解を深めたい。そのため、日本に滞在している間も隙間時間を活用して英会話を継続していこうと思う。</p> <h2 id="南国ソフト">南国ソフト</h2> <p>今回は AI をかなり上手く活用できたと思う。</p> <p>頭の中にある完成像に対して、役割情報と精度を高めるための CSS カタログを与えたところ、ほぼ想定通りの UI が生成された。</p> <p>一方で、要件の整理と設計方針の議論に土日合わせて4時間ほど費やしてしまった。実装よりも前段の思考整理がボトルネックになっている。</p> <p>ただ、今回に限って言えば、初見分野であり、チームメイトに実装を全部任せてしまうため、気力次第ではあるが、もう少し細部の仕様を詰めても良かったかもしれない。</p> 2026-06-13T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/13/victory/

正しい努力は報われるという成功体験をかみしめました。

<p>同期との関わり合いは気楽である。寝ぐせすら直さないような怠慢に対して、咎めるどころか仲間意識を覚えてくれる。</p> <hr /> <h2 id="競プロ">競プロ</h2> <p>初めて黄色perfを出せた。解いている最中は特別なひらめきに頼った感覚がなかったため、これまで意識していた「自然な導出」が少しずつ身についてきたのだと思う。</p> <p>今日の結果が青perf以下であれば競プロを完全に引退するつもりだった。そのため、途中で投げ出さずに考え続けられたのは、そのプレッシャーのおかげかもしれない。</p> <p>最近はインターンで設計やレビューなど、競プロとは異なる形で頭を使う機会が増えている。問題を構造化し、制約の中で意思決定する経験が、別の形で競技にも還元されている可能性を感じた。</p> <h2 id="個人開発">個人開発</h2> <p>Claude Codeとの1on1が非常に楽しかった。</p> <p>今回初めて、問題を構造化し、ボトルネックを特定し、それを解消するための打ち手を仮説として列挙するという流れを競プロ以外の文脈で実践できた。解法を考える対象がアルゴリズムからプロダクトに変わっただけで、思考の型には共通点があるように感じる。</p> <p>かなり気分が高揚してしまったが、仮説は検証され、しばしば否定されることに価値がある。現時点では手応えよりも検証結果を重視し、淡々とリリースまで進めたい。</p> <p>研究もまた、仮説を立てて検証する営みであるならば、似たようなプロセスを辿るのだろうと想像している。</p> 2026-06-12T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/12/dislocated/

知識の欠落の自覚の無さがひどい空振りに繋がっています。

<p>朝早く起きて研究の進捗を作ろうと、早朝にアラームをかけた。決意を研ぎ澄ませるために、保険の他のアラームはすべて消した。結局起きれなかった。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>コードレビューの準備に心が折れそうになった。説明責任のために、ただエラーを併発しないかだけでなく、保守性のための慣習に沿っているかも考慮しないといけない。元々記載されているコードだけでなく、外野の意見ないしcopilotのレビューも同時に評価する。 今後置き換えられるポジションにて、必要以上に疲弊しているのが馬鹿らしく思えてくる。これをリリースしたあとにユーザの笑顔が約束されているなどの特別な報酬が確かでない限り、頑張り切れない。</p> <h2 id="南国ソフト">南国ソフト</h2> <p>仕様書レビューはダメダメだった。論理を構築するにあたって最重要事項である言質を取ることで失敗してしまっていて、最悪だ。時間の余裕の無さを経験値で測れていたら、今の能力値でも解決できたかもしれない。</p> <h2 id="self-assembly">self-assembly</h2> <p>研究テーマそのものへの興味は強い。しかし、業界内での需要や注目度を考えると、直接的な実利には結び付きにくそうだとも感じている。 一方で、Dario 氏のブログから研究の方向性についていくつか示唆を得られた。今日の収穫としてはこれが最も大きかった。</p> 2026-06-11T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/11/impressed-by-speed/

意外と社会的体裁を気にしてしまうカスみたいな自分がいることに気づきました

<p>時間を作るために、断捨離に走ろうと、まず競プロの価値について再定義しようとした。ツイッターにて、それが地頭の改善に繋がるかという投票を投げた。結果、いいねは2つついたものの、投票はされなかった。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>承認されやすいPRを作成することがタスクとして目標にあるべきである。私はそのための考慮が抜けていて、情報を初見の方が判断しやすいよう整理するために大幅なタイムロスを受けるところだった。本質的にAIに仕事を奪われたように感じた。そもそも理想が決まっていてから作業に落とすまでが頭の使う箇所で、他は労力を取るべきではない。また、忙しくしていることが給与を受け取る必要条件でもない。</p> <h2 id="研究">研究</h2> <p>とても時間がない。今はcatch upで耐える時期なので、何も面白い洞察は提供できない。取り合えず、目安となるタイムラインを作成したので、そのノルマに則って色々進めていきたい。基本的な知る←→課題を知る→仮説を立てる→検証する の循環ループにいち早くも乗りたい。</p> 2026-06-10T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/10/unfixed/

理想を信じる根拠を得ました

<p>朝強い眠気を感じていたが、朝風呂の後に腹部の不快感が解消されると、実は睡眠不足という主観的評価は嘘だったと気づいた。実際には、ただ野菜の摂取量が不足していただけだった。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>責任を取れるようになりたい。不確定要素によって私が責任を果たせなくなった時、それに対して取るべき行動 (例えば、協力申請; 最悪は弁解) を取らずに、代わりに、それを果たすことをお祈りすることのみに思考を捧げてしまった。</p> <p>意識すべきは、この環境において、私はソロではなく、チームを構成する一人ということだった。それぞれのmaxを掛け合って、私一人じゃ出せないものをリリースするという個人的最大目標のstep1に該当するはずなので、意識し始めた以上、今後は絶対におろそかに出来ない。</p> <h2 id="競技プログラミング">競技プログラミング</h2> <p>Rさんに乗せられて、参加できなかったコンテストのF問題に30分挑んだ。</p> <p>問題設定の抽象化は出来たものの、結局まともな解法には至らなかった。それに、抽象化にも無限に時間がかかってしまった。DFSのような、操作を脳裏にちらつかせる問題に対して、それを取り除くので精一杯だった。</p> <p>ただ、正体を見破る考察手法をすることを努力目標としていたので、今回はほとんどACという自己評価をしている。今後は、実際に解けるように分からない状態に耐えることを意識したい。</p> 2026-06-09T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/09/lost-function/

軸を持つことがどれほど重要か振り返りました

<p>ブログのネタのために競プロの問題を解く程度の動機では、早起き出来なかった。</p> <p>原因を考えると、やるべきこと自体が不足していたというより、複数の選択肢の中で何を優先するか判断する軸が曖昧だった可能性がある。目的や方向性が十分に定義されていない状態では、個々のタスクへの動機も弱くなるのかもしれない。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>これまでは、主に自分が理解していない内容について質問することが多かった。</p> <p>その姿勢自体は、曖昧な理解を放置しない点として評価されていたようである。一方で、以前より曖昧さを許容できるようになった結果、発言頻度が減り、周囲からは消極的に見える場面もあったらしい。</p> <p>ここから、自分の中で理解を深めることに意識が向き過ぎると、外部との情報交換が不足する可能性があると認識した。</p> <p>今後は「何を知りたいか」だけでなく、「他者に対してどのような情報提供や問いかけを行うか」という観点でも行動方針を定義したい。情報収集だけでなく、情報流通の起点になることで、より効果的に周囲と協働できるかもしれない。</p> <p>また、Hさんの話で印象的だったのは、AIによって挑戦可能な領域が大きく広がったからこそ、行動の一貫性や前提知識の共有を重視している点である。技術的な実現可能性だけでなく、継続的な方向性を持つことが高い視座の形成に繋がっているように見えた。</p> <p>自分の場合は、サプライチェーン全体を見渡す視点を活用することで、各施策の寄与を見積もり、合理性を評価できる可能性がある。この点では、Impactを重視する考え方についてHさんと共通する部分がありそうだ。</p> <p>今後は、実現可能性だけでなく、システム全体への影響や価値の流れを踏まえて意思決定を行えるかを検証したい。</p> <h2 id="南国ソフト">南国ソフト</h2> <p>要件整理のために仲間へ説明するプロセスを挟んだところ、自分の理解の曖昧さや要件間の矛盾が見つかった。</p> <p>感覚としては、循環している依存関係を切り分けて構造化する作業に近い。頭の中だけで整理するよりも、説明や図示を通して外部化した方が問題点を発見しやすかった。</p> <p>また、双方が手を動かしながら整理する時間を設けたことも有効だった。議論だけでは見落としていた論点が可視化された。</p> <p>一方で、UI設計は依然として未確定である。試しにClaudeへ実装の再現を依頼したが、CSS要件を十分に共有しておらず、期待する結果は得られなかった。</p> <p>今回の反省として、実装に入る前に類似サービスや既存アプリの調査を行えば、より少ない労力で設計上の示唆を得られた可能性がある。今後は要件整理と並行して先行事例の調査も進めたい。</p> 2026-06-08T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/08/be-done-to-do/

開発フローの振り返りをしました

<p>溜まっていた課題を翌日に持ち越し、予定通り就寝して早朝に取り組むという社会人典型を実践できた。これまでは難しいと考えていたことが、徐々に習慣として定着しつつあるように感じる。</p> <p>この変化がなぜ起きているのかは説明できない。一方で、日々の小さな約束を守ることが継続の土台になっている可能性はある。</p> <hr /> <h2 id="uzabase">Uzabase</h2> <p>実装の並列化に着手する前段階で想定以上に時間を消費した。</p> <p>主な要因は、テストの扱いに対する理解不足だった。現在の業務範囲では変更の影響範囲が限定的であるにもかかわらず、必要以上に広い範囲の確認を行っていた。また、テストそのものだけでなく、mainブランチとの差分解消や競合対応といった周辺作業も工程に含まれることを十分に見積もれていなかった。</p> <p>今回の経験から、実装作業だけでなく、その前後に発生する付随タスクも含めて開発工程として捉える必要があると分かった。今後は、変更箇所と影響範囲を把握した上で適切なテストを選択し、競合が発生しやすい状況を事前に避ける進め方を意識したい。</p> <h2 id="南国ソフト">南国ソフト</h2> <p>アーキテクチャの技術スタック選定は概ね順調に進んだ。</p> <p>まずアプリケーションの特性から必要条件を整理し、その条件を満たす技術候補を調査する形で検討を進めた。技術そのものから入るのではなく、解決すべき問題や要求から逆算して選定できた点は有効だった。</p> <p>一方で、プロダクト設計に関する議論では十分に貢献できなかった。個別の機能や仕様に対する提案を行ったものの、プロダクト全体の文脈や利用者体験との接続が弱かったためである。</p> <p>後から振り返ると、User Lifespanのような利用者の行動プロセスに沿って整理すれば、より構造的に議論へ参加できた可能性がある。ただし、その場で適用できるほど習熟していなかった。</p> <p>現在は、経験によって獲得される設計上の判断をどのように形式知化できるかに関心がある。将来的には、ユーザー行動や要件整理のフレームワークをより明示的な手順へ落とし込み、設計支援や自動化につなげられないか検討したい。</p> 2026-06-07T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/07/bfs-style/

抽象から具体に落とす写像は、想定以上に複雑でした

<p>今日は事務的な作業でいくつか問題が発生し、その対応に追われました。</p> <p>特に興味深かったのは、解決よりも保留を選ぶ方が精神的な負荷が大きかったことです。状況を整理するためには時間が必要だと理解していても、不確定要素を残したままにする判断には想像以上のエネルギーを消費しました。</p> <p>もっとも、その原因は曖昧さへの拒否感というより、孤立感にあったように思います。実際には相談できる仲間がおり、認識を共有することで必要以上に問題を大きく捉えていたことに気づきました。</p> <hr /> <h3 id="self-assembly">Self-Assembly</h3> <p>理論から応用までは比較的単純に写像できるものだと思っていましたが、実際にはそうではありませんでした。</p> <p>現在扱っている空間支配のルールに関する基礎理論は、各座標に存在する物体の有無や種類のみを考慮しており、暗黙的に二次元構造で成立することを前提としています。そのため、現実の物理的な制約を扱おうとすると、そのまま適用することはできません。</p> <p>今後の課題は、汎化可能な形状を構成する要素を明確化し、理論と物理世界の間をどのように接続するかを整理することだと感じています。</p> <p>一方で、自分自身は物理学の専門家ではありません。そのため、物理現象を一からモデル化するよりも、必要十分な理解を持った上で既存の知見や理論を部品として活用し、高次の設計や抽象化に集中するのが適切な立ち位置なのかもしれません。</p> 2026-06-06T00:00:00+09:00 https://TrueRyoB.github.io/blog/2026/06/06/hajimemashite/

個人技術日誌を始めました。先週の学びを振り返ります - TDD、ホスト移行、GNN、Kaggle。

<p>個人日誌を始めることにしました。</p> <p>学んだことを言語化する習慣をつけたいというのが理由です。頭の中で「なんとなくわかった」で止まってしまうと、後から何も残りません。書くことで輪郭をはっきりさせたいと思っています。手始めに、先週を振り返ります。</p> <hr /> <h2 id="uzabase--チーム開発でのtdd実践">Uzabase — チーム開発でのTDD実践</h2> <p>インターン2週目。チーム開発でTDD（テスト駆動開発）を実践しました。</p> <p>仕様書を書く段階が特に難しかったです。「何を実装するか」ではなく「何が満たされれば完了か」を先に定義する作業は、普段の開発とは思考の順序が逆になります。</p> <p>ただ、仕様策定を通じて要件と周辺の文脈をかなり深く理解できた結果、AIエージェント（Claude）を並列で走らせられる程度には全体像を把握できました。要件が曖昧なままAIに頼ると出力がブレるので、これは自分の理解度の指標として使えると気づきました。</p> <p>一方で、実際に作ったものをどの程度運用するか——つまりプロダクトの将来性——はまだ不確定で、何によって決まるべきかも自分の中で整理しきれていません。</p> <hr /> <h2 id="南国ソフト--ホスト移行における構造分解">南国ソフト — ホスト移行における構造分解</h2> <p>アプリのホスティング環境の一部移行に関わりました。</p> <p>ここで学んだのは、<strong>流用するものと新規作成するものを最初に分けて考える</strong>という設計の切り口です。APIやCSSなどクラウド上で複数サービスから共通利用されるリソースを「共通項」として括り、移行対象と非移行対象を整理しました。</p> <p>保守性の方針についてはまだチームとして議論できる段階にありませんが、この「共通と固有の分離」という考え方は、今後の設計でも繰り返し使えそうだと感じています。</p> <hr /> <h2 id="競プロ--gnnと金融への応用">競プロ — GNNと金融への応用</h2> <p>GNN（グラフニューラルネットワーク）のアルゴリズムが、金融業界における企業間の依存関係分析に活用されていることを知りました。</p> <p>直感的に面白いと思ったのは、<strong>この手法をuzabaseの顧客ペルソナ設定にも転用できるのではないか</strong>という点です。企業間の関係性をグラフ構造で捉え、顧客セグメントを動的に更新するようなアプローチが考えられます。まだ仮説の段階で、検証は今後の課題です。</p> <hr /> <h2 id="kaggle--アンサンブル学習と意思決定支援">Kaggle — アンサンブル学習と意思決定支援</h2> <p>Kaggleの勉強を始めました。ゲーム的なインターフェースで取り組みやすいです。</p> <p>アンサンブル学習を学んでいて、<strong>過去データが正解ラベル付きで存在する状況では、意思決定プロセスのシミュレーションが成立するのではないか</strong>と考えました。たとえば、経営会議への参加を希望する人物の過去の判断履歴をもとに信頼性を定量評価する、といった応用が思い浮かびました。</p> <p>一方で、loglossなどの評価指標の数式については、まだ直感的に理解できていません。uzabaseでも数値感覚の欠如を課題として実感しているので、ここから逃げずに向き合っていきたいと思います。</p> <hr /> <p>以上、先週の振り返りでした。</p>