週報 2026年10月18日〜2026年10月24日
今週は先週に引き続き Discord で会話できるボイスチャットのボットを趣味で開発をしていた。 ボットの調整をやりつつ、ローカルで動かすハーネスを DSH に移行してその調整が進んできた。 Hermes Agent は入れたら即ある程度良い感じに動いたけど、基本的にこの手のハーネスは自分に合わせて少しずつ調整していくのが重要だから、手に馴染むまで調整し続けていくかあという感じで。
以下の記事を読んだ。
ソフトウェアファクトリーについて。 AI が自動で走ってもらいつつ検品とかできる仕組みを作っていくべきというのはそうだなあと。
最近作っていたチャットボットは完全バイブコーディングで何も考えずに全部よしなに、っていって AI に任せておいたら、後で実装がどうなっているかの説明を聞くたびにボロボロと想定外の実装でしかもそんな実装していたは当初作りたかったものと別物になっているじゃないかみたいのも多々あり。 そういう想定レベルでズレているみたいなものを作られてしまわないように AI が作っているものを検査していく必要はありそう。
そういうバカみたいに間違ったものを作られるでなくても従来のテストとかの仕組みを使って品質をちゃんと検品できるシステムは必要で、その仕組みを作る工場を作るようなのが次の仕事だというのは納得感はある。 全部をコード一行一行把握している必要はないけど、そもそも別の間違ったものが作られていないかは確認したい。
もし間違ったものが作られていることが発覚したら作り直せばよいし、作り直しのコストは安い部分というのもある。 そのため Design Doc を事前に書いて詳細までレビューしてエンジニア間で合意を取るように AI と合意を取らなくても事後報告で実装内容を報告してもらったり確認したり、というのができるように整えていけばよいかなあと思っている。 DB のスキーマとかはあとから変更するのめっちゃ大変なので、そういうところは事前に Design Doc とかで AI と作るものを握るのも大事だろうけど、全部の箇所に Design Doc で何を作らせるかを細かく指示しなくても良いのではというのも最近は感じるところではある。
知らぬ間にコーヒーが飲めるようになったことを前回書いた[1]が、それで気になって近所のカルディでコーヒー豆とキャニスター缶とハンドミルとコーヒードリッパーなどを買ってしまった。
しかし、ハンドミルは若干大変である。 普通に粉にしてもらって買えばよかった。 豆を自分でミルで挽くことに若干憧れがあったが、ゴリゴリ回していくのは微妙に大変だということを知った。 まあ何事も経験ではある。
Kindle をセールで買ったことも前回買ったが、良い感じである。 電池の持ちがよくてサイズ感もちょうど良い。
空き時間に本を読むかという気分になったので、久々に星新一のショートショートを読んだ。 星新一は小学生の頃に図書館で借りては読んでいたので、多くの話は一度読んだことがあるはずなんだけど、そういう経緯なので読んでみると何か懐かしさも感じる。 小学生の頃は返却期間の 2 週間ごとに図書館に行って好きな本を目一杯借りて読むというのを続けていたのに、最近は読書しなくなってたからなあ。 Kindle のおかげで読書へのハードルがまた下がった気がするので、このまま再び読書を楽しめるようになると良いね。
以下の勉強会的なのがキャンセル枠があったので飛び入り参加してきた。
私は AI エージェントのサブスクが余ったときにその週のレートリミットを使い切るためだけに作っている言語処理系のプロジェクトを持っていたので、まあ多少は言語処理系にも興味がある。 色々興味深い話が聞けて良かったわね。
DropBox から最後のお知らせが来た。 いよいよ最後ということで、ようやくデータも消えるかな。
プランを解約して無料プランとかにして即中身が消えるのかと思っていたのだけど、こんだけ残させてしまったのは申し訳ないなあという感じはしている。
HTML-in-Canvas API を使ってみたが面白い。 Web ブラウザでこのくらいのものがグリグリ動くようになる。
最近趣味でLLMとボイスチャットできる仕組みを作って遊んでいるのだけど、そのログとかを確認するためのダッシュボードを、HTML-in-Canvas APIを使って無駄にカッコいいものをバイブコーディングで作ってもらった。 pic.twitter.com/gBP0uUuZzs
— 折登 樹 (@MatchaChoco010) 2026年10月23日
HTML-in-Canvasを使ったダッシュボードをもう一つ少し動きの違うやつを追加でClaude Codeに作ってもらった。これがWebブラウザで動くGUIというの、なかなかシビレるね。 pic.twitter.com/hvoMv96UDr
— 折登 樹 (@MatchaChoco010) 2026年10月23日
こうなってくると今後の Web がもっとリッチになるのかなあ。
そして上記動画のやつもそうだけど、実装は Claude Code Opus 5.5 に任せている。 直近の AI のコーディングが大幅にビジュアルに強くなったこともあり、こういうのを個人でサクッと AI に頼んで作らせることも可能になっていくと考えると、なかなか面白い時代だわ。
HTML-in-Canvas の何が良いって、3D 系でゴリゴリ動かすものを作ると文字のレンダリングが死ぬほど大変で、さらに文字の選択とか入力とかもっともっと大変なのが Web に乗っけたまま動かせることだと思う。
まだ HTML-in-Canvas は Chrome のみでしかも Origin Trial の状態だから広く一般で使えるのはもう少し先になりそうだけど。 使えるようになったら Electron とかの Chromium ベースの GUI クライアントとかもこのくらい遊びまくるのが楽になりそう。
Anthoropic がプログラミングに形式手法を入れてバグを探すとかやっていたらしい。 形式手法は今までもあったけど使いこなすには相当な知識が必要で大変だったが、今は AI に雑に使わせられるのね。
ただ、形式手法はそれが何を証明しているのか、どの性質を示そうとしているのかというのをドメイン知識のある人間がちゃんと定義が正しいことを見ていくからこそのものなので、既存のプログラミングから作るのってそれでいいのかという気はしたりする。 が、それはそれとしてその程度の雑な形式手法の検証を突っ込んでみるだけでも出てくるバグや見つかる不具合があるということはまあ役に立つのだろうなあ。
「形式手法で完璧に動作が示されたソフトウェアを作ります」というよりも「AI が動作を検証するときの道具が 1 つ増えた」という程度のもののような気がしているが。
それはそれとしてこういう検証をガンガン回していけるのはすごいことだなあ。 形式手法も使わずにプログラムを作っていた時代は人間が手で書けるわずかな工数でプログラムを作っていた時代のものである。 AI がガンガンコードを書く時代にはこういうのをやって当たり前になるのかもしれない。
構造化プログラミング以前の人間の頭で相当こねくり回して作っていた時代と今のプログラミングとの間と同じくらいの断絶が、将来から見たときの今の人間のコーディングに対する評価になるかもなあと思う。 構造化プログラミング以前とかは確かに動くけどスパゲッティ過ぎて動作を把握するのも作るのも大変そうなイメージがある。 それが構造化プログラミングで if とか for とかそういう制御構文を使うというような制御フローを使えるようになって、メモリを直接操作したりとかしながら動くプログラムを書くよりはるかにわかりやすくなっていき、結果としてその構造化プログラミング以前のプログラムは曲芸的に動いていただけなのでは？という感覚を覚えるわけだが、それと同じようなことが AI での検証をゴリゴリやるのが当たり前になった時代には今のプログラムに対して思われることかも。 人間の小さい頭の中で中途半端なテストとかだけで曲芸的に動いていたものに社会インフラとかが乗っていたなんて信じられないなあ、なんて判断を後年にはしているのではないかしら。 今までの人間がソフトウェアエンジアリングだとか言ってテストを書いたり開発手法を色々工夫してきたのも、全部曲芸の一種でありちゃんと動くことが保証できるわけでもない曲芸にいろんなシステムを載せていたなんて信じられないなあ、みたいな。