あけましておめでとうございます。
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サーバーがうまく連携できないのでなんかやりたいことがうまく進まなくなる傾向にあるというか、そんな感じの傾向だ。
もしかしたら、選択しているモデルが悪いのかもしれないのでそういう観点でも検討しながら構築を進める。
)
先週は来年に向けての準備をするためにデータ整備を行っていたので目立った出来事はない。
AIエージェントを使ったコーディングを普通に使うようになった。
たとえば、AMDのFPGAを開発するのに実際に論理合成や配置配線を実行するコマンドラインで開発するのではなく、普段はVivadoというIDEを使って開発をします。と、同じぐらいAIエージェントを普段使いしている。
去年に比べて変化があったとすれば、作業より思考に多く時間を回すようになったというところだろうか。
普段はFPGAの何かを設計開発している。
ここで設計と開発という言葉の定義で分けてみると、大雑把ではあるが次のようになる。
| 観点 | 設計 | 開発 |
|---|---|---|
| 目的 | 計画・仕様定義 | 実装・検証 |
| 主な作業 | 仕様書作成・図面作成・要件整理 | コーディング・試作・検証 |
| スキル | 論理的思考 | コーディング |
AIエージェントを使用して効率が上がるのは開発の部分である。
設計の部分はAIエージェントを補助的に導入できるけど、ここは人手が介入しないと解決できないことが多い。
設計開発を0から10までのフェーズがあるとすると、たいていは次のようになる。
| フェーズ | 作業 | 作業内容 |
|---|---|---|
| 0-1 | 設計 | 仕様書作成・図面作成・要件整理 |
| 1-10 | 開発 | コーディング・試作・検証 |
AIエージェントを活用すると設計開発の大部分を占める開発フェーズである1-10の効率が上がることを意味する。
クライアントから仕様書を受け取り、単に受託開発の作業を行っているエンジニアはAIエージェントに取って代わられても仕方がない。
さらにこの設計開発を製品のアイデア出しから市場投入までのフェーズに組み込むとこんな感じになるだろう。
| フェーズ | 内容 |
|---|---|
| アイデア創出 | トレンドや競合分析からアイデア作成 |
| コンセプト開発 | アイデアの具体化、ロードマップ作成 |
| 設計開発 | プロトタイプ・フィードバック |
| 製品化 | 量産体制・デザインの最終決定 |
| 市場投入 | 販売活動 |
ここでの設計開発の効率が上がり、全フェーズの工数が短縮されるか、アイデア創出やコンセプト開発により多くの工数を投入できるようになる。
アイデア創出やコンセプト開発に近いエンジニアほど、AIエージェントに取って代わられないと思われる。
)
