数年ぶりに雪が積もったかな？
ESP32-S3が実装された13.3インチe-Paperの小基板を調達した。
https://www.seeedstudio.com/XIAO-ePaper-Display-Board-ESP32-S3-EE02-p-6639.html
13.3インチのe-Paperは持っているので今回はコントローラのみ。
元々はラズパイPicoを繋げて制御していて、13.3インチ用にESP32で安い基板を作ろうかと思ってたらSeeedStudioがリリースしてきたので作らなくてよかったという感じだ。
安い基板を作ろうとしたのは低消費電力で動作＆スリープが効くのが欲しかったからだ。
それでラズパイPicoで動かしてたコードをESP32-S3に移植して、動作確認は完了。
SeeedStudioでe-Paperと合わせて揃えると$149.0＋$14.9＝$163.9で150円/$換算で24,585円ぐらいになる。
これなら単品で調達しても市場にある商品より安くできそうだ。
ollamaでGLM-OCRが使えるようになったので試したら、手書きの漢字でも認識率が高い。
認識後に校正かければ手書きをほぼ認識できるレベルだった。
これなら十分にローカルで使えそうだ。
)
早いものだ、2月に入ってしまった。
先週は2つのAI支援環境をアップデートした。
AIPRJの環境はエージェントを始めた頃からの環境だけど、最近流行りのskill駆動に似てるのかな。
https://github.com/aquaxis/aiprj
AIエージェントのコーディング環境に一定のルールを与えて実行する環境をアップデートした。
次の2つの環境で使用できるようにした。
https://github.com/aquaxis/layers
AIエージェントに役割分担を与えて、役割に応じて行動するように環境を起動する。
下図のように会社のチームに似た組織を構成するAIエージェントをtmuxで起動し、tmux間で役割に応じてAIエージェントが行動する。
COO（人間）
│
▼
Producer（プロデューサー）
│
▼
Director（ディレクター）
│
├─────────────────┬─────────────────┐
▼ ▼ ▼
Lead Designer Lead Programmer QA Lead
│ │ │
├───┐ ┌───┼───┬───┬───┐ ├───┐
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
D1 D2 PG1 PG2 PG3 PG4 PG5 T1 T2人が最高執行責任者となってプロデューサーへの指示をするだけである。
下記のWebページも全てこのエージェントチームで作り上げた。
COOとして指示をしたのは、「WebGLで渦巻く銀河のコーポレートサイトを作成して下さい」から始まり、こういう風にしたいなと思ったことを伝えると、プロデューサーが意図を含み取り、タスクを分解してディレクターに指示を出し、ディレクターが各タスクを管理しながらデザイナーとプログラマーとQAに仕事を分散させていた。
自分でフルスクラッチするとおおよそ、1週間（8h x 7day）ぐらいかかるかなというところを5時間で作成することが出来た。
その5時間もべったり張り付いているわけではなく、段階ごとにプロデューサーから報告が入るのでそれをチェックして動作が満足行くかチェックして修正や改善箇所を再指示してというのを繰り返しただけである。
つまり、作業時間というよりも完成までの時間であって、総所要時間（リードタイムやスパンと言い換えたほうが分かりやすいか）であって実質的な作業時間はもっと少ない。
AIを「ああだ、こうだ」とケチを付ける人もいるけど、このようにうまく活用することで大幅に工数を削減できる環境を使わないのはこれからの自身のエンジニアリングに影響してくるだろうと思われる。
)
2026年1月の最終週になりました。
今年に入ってからAI活用で10本ぐらいアプリを作った。
アプリを作ったと言っても自分用の支援アプリがほとんどだよね。
コーディングでAIを活用するとコーディング能力が下がるというレポートが出てようですがそれは同意で実際にそのような感じでいる。
ただ、コーディング能力が落ちるというは特定の言語のコーディング能力が落ちることを意味しそうで、それが根本的な問題になるかというとそうは感じない。
コーディングはあくまで作業であり、AIで作業効率が上がり、人の作業が減るというのは特に問題ない。
むしろ思考が伸びているのでモノを作るうえで必要な工程に多く時間を避けるようになった。
コーディング能力が下がる分に問題はないと思うのは私だけだろうか？
去年までの開発環境はWindows上でVSCodeとTerminalを使った環境だったけど、今年からVSCode一本に絞っている。
こういう統合ツールで開発するというのとツールを分散で開発するというのは自分自身に当てはまると5,6年のサイクルで入れ替わる。
以前はEmacs、Eclipse、Geanyなどを使ったりしたこともあった。
当分、VSCodeを使うことになるだろうと思う。
どこかで、使用しているツールのまとめをしよう。
それと、Windowsの環境も酷くなってきたので26年だし、UbuntuのLTSもリリースされるからLinuxに戻そうか検討している。
問題はClip Studio PaintとXP PenがLinuxでうまく機能してくれるかどうかなんだけど、どう試そうか？
回路図や仕様書を作成するとき、かならずDraw系ツールを使用して図を作成する。
使用するフォーマットはsvg、drawioが多い。
中でもdrawio.pngはDrawioで編集できるうえにPNGファイルをしてそのまま表示できる。
しかし、AIで.drawio.pngを出力すると失敗することが多い。
まずは.drwaioで出力してからコマンドで.drawio.pngに変換すると失敗が少ない。
wget https://github.com/jgraph/drawio-desktop/releases/download/v29.3.0/drawio-amd64-29.3.0.deb
sudo apt install -y xvfb
sudo apt install drawio-amd64-29.3.0.debxvfb-run drawio -x -f png --no-sandbox --disable-gpu -o sample.drawio.png sample.drawio
2026年も2週間が過ぎて少し落ち着いてきたかな…
前にも書いたと思うけど、AIエージェントを使うようになって作業は爆速になった。
2026年になってからもすでにいくつかアプリケーションを作成した。
作業は完全にAIに任せ、思考部分の時間が多く取れるようになった。
その代わり、たくさん思考できるようになったので忙しさの感覚が高くなったような気がする。
一昨年ぐらいまでは作業をしてる方が多かったけど、作業中は特に物事を考えてないので忙しさには直結していない。
これはAI疲れなんだろうか…
| 観点 | 思考 | 作業 |
|---|---|---|
| 本質 | 意識内での精神活動 | 目的達成のための行為 |
言語は作っただけではダメで使えるようにしなければいけない。
ツールを作っていたけど、コミットすることを忘れていた。
作業中のファイルが散乱しているので整理してからコミットしよう。
Windowsのアップデートが酷くなってきたように思える。
品質が落ちているのは言うまでもないだろう。
いきなりOneDriveのバックアップを要求してきたり、リンク付けを変更してしまったりすることが発生している。
PictureフォルダなんかはいつのまにかOneDriveへバックアップ設定になってたし（拒否したはずなんだけど…）、Explorerのリンクも元に戻せない状況になっている。
Explorerも気持ち悪いのでOne Commanderへ乗り換えた。
)
2026年になって一週間ほど過ぎた。
この一週間でもめまぐるしく情勢が変わっていて今年はいろいろ、再定義をする年になるんだろうと感じている。
例えば、Verilogのポート宣言であるoutputのことである。
モジュールでoutput宣言しているけど、内部でも再使用するということは多々起きる。
この時にoutput宣言した信号名はあくまでoutputのみとして使用し、内部での再使用を不可とするかどうかといった点に悩んでいる。
実情はoutputに宣言されて内部で使用しても問題ないのだが、定義上どうするかといったところだ。
言語仕様上は各言語に従うとして、禁則事項ではなく、推奨事項を設定しておきたいわけだ。
内部でも使用するならinout定義にするという方向づけでも良いと思うけど、そうするとoutputで宣言した信号名の外部から見た定義が変わってしまう。
内部で内部信号と外部信号でわけると、可読性が若干下がるというのはあるけど、機能性を考えると内部信号と外部信号の定義はきっちり分けたほうがいいのかな？
IRISという記述言語を作り始めた。
Immutable RTL Implementation Standardの略で「不変的なRTLの標準実装」って意味合いで自分用ハードウェア記述言語である。
Verilog HDLやSystemVerilogの抽象度や言語仕様の曖昧性が大きく、記述による合成事故が多発しているので事故防止のために作り始めた。
一番多くおこしている事故は代入のところだ。
"<="と"="で動作が変わるのである。
仕様がブロッキングとノンブロッキングだからそうだと言われてしまえばそのままだけど、例えばalways文の中に両方を記載できてしまう点である。
そうするとシーケンシャル方向とパラレル方向、これだとちょっとイメージが湧きにくいので、言い換えると順次処理と並行処理が混ざってしまうのだ。
このことを利用して巧みに回路を作ってみたこともあるけど、一見可読性がよいようにいいソースコードに見えるけど、理解容易性が著しく低いのだ。
合成ツールでも取り扱いが違うところもあるようなのでそこも事故の元だな。
私的にはフリップフロップとワイヤー（ゲートも含め）でハードウェア記述が表現できればいいと思っている。
ハードウェア記述言語としてVerlyがあるけど、これはこれでウォッチする。
)