🐈

ほぼ週間Go言語 2025/10/06

に公開

今週もプログラミング雑記からGo言語に関する話題と、その他特に気になった話題をより抜きでお送りします。

Go言語

Goのビルドシステム歴史。だいぶ扱いやすくなったけど、まだ結構はまりポイントはあるんだよね。

https://zenn.dev/spiqua/articles/3e0cd6ca18c7b4

へー面白い。ランタイムの内部動作とか無駄に気になりますよね?

https://zenn.dev/su8/articles/1f81fd189acaf2

助かります。来年は行ってみたいのだけど、東京の宿泊費が高すぎるのよね。。。

ライブラリやツール

https://github.com/njayp/ophis

Cobraを使って書かれたCLIツールをMCPサーバー化するライブラリ。

https://github.com/kritihq/kriti-images

Goで構築された高性能画像変換サービス。リアルタイム画像処理のためのURLベースのAPIを提供。Cloudflare ImagesやImageKitのオープンソース代替ソリューション。

https://zenn.dev/baleenstudio/articles/78f1c692b18804

Go 1.25環境でuber-goのmockgenがインストールできない問題は、依存パッケージのバージョンが古いことが原因です。mockgenを0.6.0以上にアップデートすることで解決できます。

その他

システム思考

https://syu-m-5151.hatenablog.com/entry/2025/10/01/203633

この記事は、システムを作るエンジニアがまず理解すべき「システム思考」の重要性を説く内容です。物事を単なる部品の集合や線形な因果関係で捉えるのではなく、生態系のような複雑な相互作用や非線形性、関係性、反直感性などを意識することが求められます。日々のバグ対応や設計にも、氷山モデルなどを用いて構造やメンタルモデルの深い部分まで掘り下げる習慣が有効であり、持続可能なシステム実現のために実践的なシステム思考を身につけるべきだと強調されています。

https://syu-m-5151.hatenablog.com/entry/2025/10/01/203924

システム思考を日々の開発に取り入れる実践ガイド。技術選定や設計において自分の思考・前提への気づきを重視し、違和感や素朴な疑問を問いとして掘り下げることが、チーム全体の改善や本質的課題の発見につながると述べられる。PR説明文やレビューなどフィードバックループの働き方を具体例で説明し、個人の「問い編集力」やモデル・会話を共有することで、AI時代でもエンジニアの価値は、単純な実装作業ではなく、文脈知識やクリエイティビティに宿ると強調する。調和や学習を重視し、小さな習慣からシステム思考を実践しようと結ぶ。

https://www.calvadoshof.com/Special/1-419acrobat.pdf

あと、システムの世界観を得るための手助けとして、アーサー・ケストラーのホロンの考え方が役に立つ。上はその考え方をWEBアプリケーションのシステムを例としてあげているもの。

ホロン革命 新装版—部分と全体のダイナミクス | アーサー ケストラー, Arthur Koestler, 田中 三彦, 吉岡 佳子 |本 | 通販 | Amazon

この本自体は非常に難解なので、とりあえずシステム開発をする人間は先の資料ぐらいの理解で役に立つと思います。

エージェンティックコーディング

https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/

この記事は、Markdownをプログラミング言語のように使い、AIコーディングエージェント(GitHub Copilotなど)と連携して仕様駆動開発を行う手法について解説しています。README.mdやmain.mdにアプリ仕様や設計、ドキュメントをMarkdownで記述し、AIによりGoコードへと自動生成させることで、ドキュメントと実装の同期・透明性を高めることができます。編集やバグ修正もmain.mdを更新するだけで済み、仕様に忠実な開発サイクルを効率的に回すことが可能です。また、LintなどもAIに指示でき、保守性も向上します。


Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code – Codemanship's Blog

https://codemanship.wordpress.com/2025/09/30/comprehension-debt-the-ticking-time-bomb-of-llm-generated-code/

LLM(大規模言語モデル)生成コードは、開発者が修正や変更を行う際に理解するまで多大な時間がかかる「理解負債」を生み出している。高速なコード生成の裏で、コードの品質を保つための見直しや再作業が必要となり、初期の効率化効果は相殺される場合も多い。読まれないままリポジトリへ追加されたコードが増加し、今後変更が必要となったときにはAIでも対応できない問題が発生し、最終的に人間が多くの負債を背負って手作業で対応せざるを得ないケースが増えている。この理解負債は急速に累積しており、今後のソフトウェア保守に大きなリスクとなる。

結局プロはバイブコーディングをしてはいけないということにつきると思う。プロはバイブコーディングではなくエージェンティックコーディングを行っていくこと。仮にLLMが作成したコードであっても、それへの責任はLLMコードを書かせた人間側にあることを自覚することだろう。

株式会社BALEEN STUDIO

Discussion