週報 2026年10月25日〜2026年10月31日
今週も何か代わり映えがあるわけではなく仕事をしたり趣味のプロジェクトを回したりだけしている日々であった。
趣味の時間はバイブコーディングを色々試して自分なりにどこまでをエージェントに投げてどこまで理解を手放さずに持つべきかという肌感を養おうとしている。
先週から引き続き、あいも変わらず Discord の VC 用ボットを作っているプロジェクトをやっている。
別に VC 用ボットに並々ならぬ熱量があるというわけではないのだけど、規模のデカめのプロジェクトを全部バイブコーディングで作りながら、ベンチマークとかで改善傾向を掴んで LLM に最大限任せつつ品質は見ていくというのの練習になっていて、そのようなコーディングエージェントに色々任せたプロジェクト運用の練習として大変興味深くて続いている。
特に今回試したベンチマークを用意して改善のループを自動で回させるというのはかなり興味深い感じになっている。 自分が間に介入して全部レビューしていたのではできない速度の改善ループが回るようになっていて面白い。
エージェントが勝手にループを回して入れた改善は、1 日 1 回スライドの形にまとめられて私が概要を確認できるような仕組みまで作った。 これが結構良い感じではある。
しかし、この一週間でこのバイブコーディングで進めてきたプロジェクトがだいぶ破綻してきていることが分かってきており厳しい感じである。 ここまで完全にバイブコーディングでどういう感じにしてほしいかだけ伝えてコードの中身は一切見ずに作ってきたのだけど、中身が破綻していることが分かってきたので大幅リファクタリングして私の理解をもう少しもって置く形にしていく形にリファクタをやっている一週間だった。 まだリファクタは全然終わっておらず仕様書を書き直している段階である。
これまで「こういう風に作って」とコーディングエージェントに依頼して、その通りに作りましたと AI が言ったのでそうなっているだろうと認識したまま作業を続けさせるということを多々やってきた。 しかし実態としては AI が時々余計な気を利かせて謎の実装をしたり、うまく動かないからといってゴールを勝手にずらして全然違う実装をしていたり、指示したとおりには実装ができないがちょっと指示から変えて実装すれば実装できるというのを独自判断で入れていたりということが多々あった。 そしてそういう内部実装がおかしく壊れているのにそれについて報告してくることもなく指示された通りに辻褄を合わせるように継ぎ足しまくってその結果として大変なことになっていた。
もはや気がついた頃には手のつけようがないほど中の実装がぐちゃぐちゃに壊れた状況になっていた。 特に今回、オープンウエイトモデルのお試しも兼ねて DeepSeek V4.1 Flash とかも使ったので Claude Code の Opus 5.5 などよりも知性が劣っておりそれもあって実装が大変なことになってしまった。
そのため、コードベースについて一行一行レベルの理解まではしなくても、そもそもどういうアルゴリズムで何を行っているか自体はちゃんと現状の実装がどうなっているかは把握したほうが良い。 全部を細かく実装内容を把握はしなくても良いが、そもそも実装しているものがすり替わっていたみたいなことが起こっていないように、そこだけは最低限どのような内容のものが入っていっているか見ておく必要があるなあという感じ。
コーディングエージェントでぐるぐるループを回していけるようにして、人間が介入せずにループを回させつつ、それでいて人間の目も入れて作っているものがズレたりしていないかだけは目を光らせるという感じで、そのさじ加減が重要だなあと感じている。
何が起こっているか、どういうものが作られているかを把握しないと、そもそも作ってほしかったものからゴールをずらされて全然違うものが作られていて、違和感を覚えて AI に質問した頃には全然想定と違うものになっていたということが起こるので、想定と同じようなことをやっているかだけは確認する必要がある。 そしてそれは行レベルのコードを実際に読んだレビューをするというより、AI 自身に今の実装がどうなっているかのレポートとかを作らせてみたりして、方針がぶれていないかをそこで確認するだけでもだいぶ防げたはずなので、そのくらいの介入度でやっていこうかなあという風に今のところは思っている。
まだまだ今後もこの趣味のプロジェクトでひたすら AI エージェントに任せて大きめのものを作る作業を趣味でやりつつ今後のプログラミングでのものづくりの肌感は掴んでおきたいなあという感じ。
そして上記の VC 用ボットの開発と合わせて、上記のボットのダッシュボードをやたらカッコよくするのも先週に引き続き手をつけていた。 HTML-in-Canvas と WebGPU を使ってゴリゴリに演出を加えた Web ベースの UI を作っている。
HTML-in-CanvasとWebGPUを使ってDiscordのAIボットのダッシュボードを無駄にカッコよくするやつ、もう少しコーディングエージェントに詰めさせて演出を載せまくってもらったらこんな具合になった。さすがにうるさすぎる気もするが。。。Webブラウザでこのくらい派手なGUIが動くのは面白いわね。 pic.twitter.com/hI7Utzctb4
— 折登 樹 (@MatchaChoco010) 2026年10月26日
デモページを Origin Trial で公開もしてみたので、しばらくの間は以下のページで動くものが見れるかも。
上記ページは Chrome 専用で他のブラウザはまだ対応していないのと、GPU がちゃんとしたのがついている PC とかで見たほうが良いです。 Mac とかだと描画が崩れるという報告も受けているのですが、適当に作っているだけなので動かない環境は多々ありそう。
これも、別にカッコいい UI を作り込むのが最終目標というわけではないのだけど、コーディングエージェントが最近グラフィカルなのが得意になったのでその上達度合を測るためにテストしているというところがある。
ボイスチャットにしろダッシュボードにしろ、本気で作りたいというより「コーディングエージェントで作る」という開発体験自体を今後どのようにやっていくかというのを深掘りするのを楽しんでいる感じではある。
それにしても Web ブラウザでこのくらいの GUI が動くのは面白いわね。 HTML-in-Canvas が Origin Trial を開けて正式にいろんなブラウザで使えるようになったら面白いだろうなあ。 アクセシビリティとか視認性とかに問題をきたす Web ページも増えそうではあるけど。
ちなみに上記のダッシュボードのツイートは 500 リツイートの 3900 いいねとかで、自分がやってきた中では一番拡散されたツイートにはなった。 しかし、このツイートをいち早く引用して「広めないでくれ」とかいう人を煽るようなコメントをつけて他人の褌で相撲を取るような人がいてそっちもやたら伸びていた。 全然知らない人の謎な引用でなんやねんというか気色悪いなという感じではあるが、ツイートが拡散されるとこういうこともあるのだなあという学びではある。
検証していないプログラムは曲芸的なものにシステムを載せていたなんて、信じられないという未来が来そうというのは先週書いた[1]。
そしてその検証がセキュリティ的な面から必要という面を除いても、一般の開発でも AI に開発を任せるなら単体テストベースより形式検証ベースの方が良かったりしないかというのを疑っているので、少しずつ試していこうと思っている。
特に AI はテストを書くのがへたであると感じることが多い。 単体テストで全く意味ないものを追加しがち。 全然確認する必要がない 1+1=2 みたいなテストを書くというか……。
その単体テストだけでは本来満たしたい性質を守れないだろうというテストを足しまくる AI と、そしてテストを通しさえすればそれで OK という AI の実装スタイルとが相まって最悪なことになっている。 最低でも AI に書かせるときは個別のテストケースを書かせるのではなく PBT とかで性質をテストさせるような書き方をさせたほうが良いのではないかという気がする。 そうでないと全然条件を網羅できていないのにどうでも良いところにばかり単体テストを足していって、本来保証したいことをテストで検査していないのにテストを通せば良いという実装のせいでかなり厳しいことになる。 意味不明な直感的に書くべきところに書かずに必要ないところにいたずらにテストを足していっているので、単体テストは欠かせずに性質のテストを書かせたくなる。
そして、PBT とかの仕様を縛る形のテストを書かせる方に寄せたほうが良いし、もっと言えば形式検証に寄せられるところは寄せていった方が良いのではないかと疑っている。 単体テストを雑に書かせると無意味なテストが増殖しまくるし、AI の徹底的にやる執念を見ると形式検証とか PBT とか人間が書くと面倒だった手法をやらせた方がよくて、人間の直感で意味があったりバグを見つけやすそうなところを狙って直感に基づいて単体テストをセンスよく入れるというセンスを模倣させるより、そっちの方が AI にコードを保証させる際にはよさそうに感じられる。 そういう意味で形式検証を単体テストのベターバージョンとして入れるのがよさそう。
形式検証というとその検証している内容が本当に保証したい内容かどうか、保証したい内容自体をよく理解した上でそれを検証に落とし込まないといけないのが非常に大変な部分だったわけだが、あえてその保証したい内容を全部形式検証にすることは諦めて部分的な仕様だけでも形式検証をリッチな単体テストとして入れるというのは面白いのではないだろうか？と想像している。 まあ形式検証の証明を書くコストをコーディングエージェントで踏み倒すのがどこまでうまくいくか次第ではあるとは思うが。
そんなわけで形式検証をプログラムに入れることにだいぶ興味が出てきている。 これは個人的な興味だけじゃなく流行としてもあるんじゃないかなという気がする。 例えば以下の記事なども興味深いものだった。
特に最近のトレンドのフルでの形式検証ではない部分的に形式検証を入れるプログラミングを自分の手で書いて何となく把握しておくというのはやるとよさそう。
自分の知っている分野で、glTF の読み込みとかハッシュグリッドキャッシュを使った GI とかをこれでインデックスがはみ出ないことを検証するようなプログラムを書いてみるというのをやってみようかなあと思っている。 まだやっていないので実際に手を出すのは来週以降ではあるが。 形式検証付きプログラムを作るのは Moonbit でも良いし Rust の Kani や Creusot を使ったコードでも良いけど、自分で書いてみるのを今後試してみたい。
やはり自分で試してみないと、現状では肌感を掴めていないのでどういう風にコードに形式検証を入れるのかわからないまま AI に任せるのはちょっとよく分からない過ぎて任せるのも難しいと感じている。 それにたとえ AI にほとんどを任せたとしても、それでもどこまでを形式検証を入れてどこから入れないか、とかそういう判断を人間もする必要が出てくる場面が出てくると思う。 そういう判断をするに当たってやっぱり肌感というのは持っておいたほうが良いと思う。
AI コーディングにしても、この部分は AI に完全に任せても壊れていても影響範囲は小さいしすぐ直せるが、ここの前提条件が崩れていたら最悪だから、そこだけは説明させて 想定通りの実装になっているかを確認しよう、みたいな人間の肌感に基づいて必要なところだけを見ることをやっている。 そしてその肌感は人間自身がプログラミングした経験から得たものである。 同様に形式手法をコーディングに組み合わせるのも実際に人間が試して肌感を養っておくのは有用そうに思う。
どこをどのように形式手法に任せるか。 また、既存の形式手法は完全に形式手法を使うものだけど、部分的に漸進的に導入していくというのが今後求められている使い方になるのではないだろうか。 ちょっと高級なテスト、みたいな使い方で形式手法と呼んで良いのか怪しいが、それでもないより良いみたいな使い方。 そういう使い方はちょっと色々試してみて肌感を手に入れておくとよさそう。
そんな感じで、ここ最近は総じてどこまで AI に任せてプロジェクトを進めるか、どこまで理解を手放してどこまでは把握しておくかとか、どこが適当だとヤバそうだけどここは任せても大丈夫な領域だなというエンジニアとしての肌感というか直感を持つかとか、そういうことを考えて過ごしている。 まだ人間の既存のエンジニアとして積み重ねてきた経験に基づく文書化したりするのが難しい直感ではあり、この直感はなんだかんだまだもう少し役に立ちそうなので直感を養うためのコーディングとかは手をつけておこうかなあという感じである。
とはいえ、この直感を養うというのはエンジニアとして食っていくための自己研鑽とかではもはやないけれどもね。 もはやエンジニアとして一生食っていくことはもう考えていないので、この直感を身につければエンジニアとして食い扶持に困らなくなるだろうみたいなことは一切考えてはいない。 昔ならエンジニアとして自己研鑽するのは良い職場に就くためや転職するためだったわけだが、もはや今となってはエンジニアとして色々できるといってもそれだけでエンジニアを続けるのも簡単ではないだろうし、そういう目的での自己研鑽ではもはやないかなあ。
そういう自己研鑽が食い扶持にならないにしても自分のものづくりでプログラムを AI に書かせることはやっていくだろうし、そのときに役に立つ直感は養っておくと便利そうではある。 趣味開発を楽しんでやるために持っておくと良いだろうなあという感じである。
もはや趣味開発ではない仕事の開発は数年で縮小していくかもしれないが、それでも自分が自分で趣味で何かを作ったりあるいは AI に作らせたりはやっていくだろうから、その趣味を充実させるための自己研鑽である。