2026年になって一週間ほど過ぎた。
この一週間でもめまぐるしく情勢が変わっていて今年はいろいろ、再定義をする年になるんだろうと感じている。
例えば、Verilogのポート宣言であるoutputのことである。
モジュールでoutput宣言しているけど、内部でも再使用するということは多々起きる。
この時にoutput宣言した信号名はあくまでoutputのみとして使用し、内部での再使用を不可とするかどうかといった点に悩んでいる。
実情はoutputに宣言されて内部で使用しても問題ないのだが、定義上どうするかといったところだ。
言語仕様上は各言語に従うとして、禁則事項ではなく、推奨事項を設定しておきたいわけだ。
内部でも使用するならinout定義にするという方向づけでも良いと思うけど、そうするとoutputで宣言した信号名の外部から見た定義が変わってしまう。
内部で内部信号と外部信号でわけると、可読性が若干下がるというのはあるけど、機能性を考えると内部信号と外部信号の定義はきっちり分けたほうがいいのかな？
IRISという記述言語を作り始めた。
Immutable RTL Implementation Standardの略で「不変的なRTLの標準実装」って意味合いで自分用ハードウェア記述言語である。
Verilog HDLやSystemVerilogの抽象度や言語仕様の曖昧性が大きく、記述による合成事故が多発しているので事故防止のために作り始めた。
一番多くおこしている事故は代入のところだ。
"<="と"="で動作が変わるのである。
仕様がブロッキングとノンブロッキングだからそうだと言われてしまえばそのままだけど、例えばalways文の中に両方を記載できてしまう点である。
そうするとシーケンシャル方向とパラレル方向、これだとちょっとイメージが湧きにくいので、言い換えると順次処理と並行処理が混ざってしまうのだ。
このことを利用して巧みに回路を作ってみたこともあるけど、一見可読性がよいようにいいソースコードに見えるけど、理解容易性が著しく低いのだ。
合成ツールでも取り扱いが違うところもあるようなのでそこも事故の元だな。
私的にはフリップフロップとワイヤー（ゲートも含め）でハードウェア記述が表現できればいいと思っている。
ハードウェア記述言語としてVerlyがあるけど、これはこれでウォッチする。
)
あけましておめでとうございます。
2026年最初のウィークリーレポート、今年は環境を整える年にしようと思っている。
2025年12月31日は東京ビックサイトで開催されたコミック・マーケット107（C107）にサークル参加してきた。
いろんな方とお話できて楽しい一日を過ごすことができた。
C106の夏コミは落選だったので丸一年ぶりの参加になる。
昨年はコミケではなく久々に技術書典に参加してたので冬コミでは準新刊と当日の新刊を含め、3冊の新刊での参加になった。
技術島にいて、周りは現物出展が見込まれていたので技術本だけの自サークルは見劣りするのが予測されたので持込数は少なめで計画した。
結果的には新刊は印刷所から会場へ直送して、自宅からキャリーバッグで出かけて、キャリーバッグで帰宅するぐらいの荷物で済んだ。
残りは軽く、BOOTHで通販分に当てている。
技術島は南ホールにあり、南ホールはそんなに人が押し寄せるようなジャンルでもなかったので通路が広く感じられた。
シャッターが解放されているところは風が吹き込んでいて寒い感じだったけど、それ以外は比較的暖かい感じで過ごしやすい感じ。
ただ、南棟はノーチェックだったので食事と自動販売機が少ないように思えた。
コンビニも近くに無いなと思っていたら南棟3Fのローソンとフードスクエアーはすっかり忘れていて帰りに気がついたのでつぎの開催中の過ごし方に行き着いたのだ。
おそらく、南３・４ホールの企業ブースを回っていれば気がついたんだろうと思う。
技術島はだいたい、午後から訪れる人が多いので午後に待ち構えておけばいい。
とか言いつつ、ボッチ参加だけどいつものように適当にサークルスペースから離脱していた。
今回は珍しく猛烈に腹が減って我慢できなかったので西棟屋外展示場まで行ってキッチンカーの串焼きを食った。
南ホールから西棟屋外展示場の串焼きへの導線がわからなかったので、西ホールのアトリウムに行って、西３・４へエスカレータへ上がり、西４ホールから南棟へ抜ける道を回って、屋外展示場の端まで行ったので飯を求めて15分ぐらい彷徨ってしまった。
西棟屋外展示場から南ホールに戻るルートも連絡通路方面に進んでしまい遠回りしたような気がする。
新刊の内容は3冊ともAIを使ったFPGA本で、SystemVerilogを生成させるのが中心の内容だった。
訪れた方の割合はつぎの通りである。
実際にVerilogHDLやVHDLを書いている人はうまくできないとか、作っても不具合があったらどこに不具合があるか見つけられなかったなどのお話を聞いた。
話を聞いてみると、「SPIの回路をVerilogHDLで作成して」と入力して生成させるタイプですべての方が直接コードを作成するスタイルを取っていた。
私のアプローチは「SPIの仕様を理解して」→「理解したSPIの回路をVerilogHDLにして」→「ｘｘに矛盾はない？」といった感じの2,3段階の生成をするタイプでその過程を新刊にまとめている。
FPGA向けとしているがアプローチ自体は普通にアプリケーションにも使用でき、アプリケーションに適用した場合はかなりの精度の良いソースコードを生成することができる。
ひとりだけ、ソフトウェアエンジニアだけどFPGAすらまったく知らない人とお話していたときに「本の内容自体はFPGA向けの話で…」ということでAIを使ったコード生成のアプローチを話ししたら「それ、ソフトウェアでもそのまま使えて、精度が高くなりますよね？」と気がついた方がいた。
そんな感じの内容である。
)
2025年最後のウィークリーレポートです。
Autonomous Logic Executor for Complex Task Operations
ollamaとMCPサーバーを利用するCLIベースのエージェント環境を作成した。
最初のLLMはollamaに接続する。
その後の作業は専門性に応じてMCPサーバーに割り振る、いたって誰でも作るエージェント環境である。
https://github.com/aquaxis/alecto
作成した意図はオンプレでないと入力できない作業のために使用する。
モデルによってはClaude CodeやGemini CLIなどとは精度が劣るかもしれないけど、本当に直近の内容でなければollamaで使用できるモデルで解決できることがわかっているのでその辺りを認識して使用すれば問題ない。
直近の内容に関してはMCPサーバー経由でWeb検索するぐらいの機能に留めていればデータ流出も防ぐことが可能である。
以下のスペックでそこそこ動作しているのを確認済みである。
| 項目 | スペック |
|---|---|
| CPU | 12th Gen Intel(R) Core(TM) i9-12900K |
| Main Memory | 128GiB |
| GPU | Geforce RTX 4080 16GB |
コミケのブースで本を立てかけるブックスタンドをダイソーの資材で作成した。
合計770円(税込み)。
まずは正面に見える本を立てかける用のワイヤーネット、44mm × 29.5mmのサイズにした。
上記のワイヤーネットを支えるワイヤーネット、29.5mm × 29.5mmを使う。
ワイヤーネットを連結するためのジョイント、6個あればいいので8個入を購入した。
本を置くための棚、ディスプレイラック2を2つ使用する。
ディスプレイラック2に取り付けるミニフック、4個あればいいので5個入を購入した。
まずはワイヤーラックをジョイントで繋げる。
斜め具合はジョイントの取り付け位置で変更できる。
ミニフックをディスプレイラック2を正面から見た上端に取り付ける。
若干、はみ出るけど気にしない。
こんな感じだね。
ワイカーネットにディプレイラック2を備え付ける。
いい感じだね。
B5版の本を置くとこんな感じ。
本の下側が奥になると前側に倒れるのでディプレイラック2のワイヤーネット側には何か置いておくといいね。
あとで気がついたけど、ディスプレイラック2の下部が積み上げられるように足の部分に段があってこれがいい具合に…
ワイヤーネットに引っかかる感じになった。
さて、お片付けするとディスプレイラックは重ね置きができる。
ワイヤーネットもジョイントを外せばコンパクトになる。
持ち運びも設置も簡単なものができた。
)
冬コミの仕込みも終わり、今年の残す大きな仕事は12/31を迎えるだけになった。
Anthropic社がAgent Skillをオープンスタンダードとして公開した。
Agent Skillって何かというと、平たく言うとつぎの構成からエージェントが決まったタスクを実行しやすくしたするための仕組みである。
結局のところ、こういう環境に落ち着くんだよなぁと思いつつ、この辺りが拡充してくるとプロンプターは重要じゃなくなって、単にノーコードなモノを作りやすくなるツール群が誕生するんだろうなぁと感じている。
来年はこの辺りのツールや仕組みの整備が流行るのかな？
ollama＋なにかでローカルの自律エージェント環境を構築できないか模索している。
単にCLIベースの環境を作るのであればそんなに難しいことはないんだけど、自律エージェントとなると、なんかこうしっくりくるものがない。
例えば、「sample.mdファイルを読み、内容の仕様を理解して、仕様に合ったソースコードの環境を作成する」とsample.mdを用意してプロンプトを入力したとする。
sample.mdのファイルをリードして、表示するところまでは動かすことは難しくない。
そこから先が難しい。
エージェントは単にreadコマンドを実行して、sample.mdを表示しているだけでsample.mdを再び、読み込んでなにかしようとするのに繋げることができない。
こういうのをうまく処理できるエージェントはないだろうか？
いわゆる再帰的機能だね。
nanocoderやollama-codeで試したけど、うまく再起してくれないだよね。
私が設定ファイルの組み立て方が下手なんだろうな。
)
先週、ローカルエージェント環境を構築している。
ローカルエージェント環境を構築し始めているけど、まずはフリー環境を構築できることを目指している。
一昔前はフリー環境を探すのにオープンソースというキーワードで探すと検索しやすかったが最近はオープンソースでもサブスク(ここでは有償という意味合いで使用する)であることも少なくない。
サブスクがある場合、大抵のオープンソースはフリーとサブスクの組み合わせになっていることが多いがどの範囲がフリーとサブスクの境界になっているのかが判断しづらいオープンソースもある。
どんなサービスであれ、最初はフリーで試せて、気に入ればサブスクでと形であってほしい。
そう思いつつ、ローカルエージェント環境を作り始めた。
まずは目先の目標を決めた。
とりあえず、私的な好みを含めて良さげな環境を探し始めた。
エージェントはそこそこ名前が売れているものでも50近く存在する。
どれを使うか好みでいいと思うけどね。
これまでに検討していたエージェント候補はつぎのとおりだ。
つぎのようなの有名でフリーだでメンテナーが会社なので候補としない。
なぜ、いろいろ使ってるのにローカルエージェント環境を未だに作ろうとしてるのかというとどれも自分のスタイルにスポッと当てはまるものがないからだ。
nanocoderとか良さげだな思っていたがMCPサーバーがうまく連携できないのでなんかやりたいことがうまく進まなくなる傾向にあるというか、そんな感じの傾向だ。
もしかしたら、選択しているモデルが悪いのかもしれないのでそういう観点でも検討しながら構築を進める。
)
