今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
AIが新米が成長の機会を奪う議論がありますが、AIは壁打ちの相手として最適なので、上手く使えば新米の技量をエンハンスしていく可能性も持っています。一方でGoogleがコピペ開発を進めてしまったように、AIが作ったコードを無批判で受け入れて言ってしまうリスクもあります。結局使う方が主体性を持って道具として使いこなせていくかなのだと思います。
では、まとめに移りましょう。
Go言語
Go 1.25.4 and Go 1.24.10 are released
セキュリティアップデート。
Go and enhance your calm: demolishing an HTTP/2 interop problem
概要:
Cloudflareは、社内のGo製HTTP/2クライアントが頻繁なPING送信により「ENHANCE_YOUR_CALM」エラーで接続を切断される問題に直面しました。原因はレスポンスBody未読のままCloseしていたことで、不要なRST_STREAMとPINGフレームが多発していました。解決策として、Bodyを必ず全て読む（io.Copy(io.Discard, resp.Body)）ことで、エラーと無駄なフレーム送信を防げることが判明しました。GoでHTTP/2を使う際はBodyを確実に読み取る実装が推奨されます
感想:
Go言語でのHTTP/2運用時に発生する「ENHANCE_YOUR_CALM」問題について、原因究明から解決方法まで詳しく解説されていて非常に参考になりました。特にBodyを正しく読み切る重要性や、実際のトラブルシューティングの流れが具体的で、同様の課題に直面するエンジニアにとって大変有益な内容だと感じました。Go開発者としても、今後意識したいポイントです。
概要:
Go言語はクラウドの発展とともに標準的な選択肢となりました。その理由は、シンプルで信頼性が高く、I/O処理や並行処理に強く、運用において「退屈さ（サプライズのなさ）」が重要だったからです。小さなバイナリ、高速なビルド、容易なクロスコンパイル、堅牢な標準ライブラリなどが特徴です。コンテナ技術や各種クラウド基盤の基盤技術で数多く採用され、開発・運用効率や人材確保にも寄与しました。クリティカルな用途での「安定した平凡さ」がGoの勝因です。
感想:
Go言語がクラウドの主役となった背景や理由が非常に納得できました。特に、シンプルさや並行処理の強み、運用現場での「いい意味での退屈さ」が技術選択に大きく影響している点が印象的です。実際に現場でもGoの堅実さや扱いやすさを感じていて、クラウド時代に最適な技術だと改めて実感しました。開発・運用両面での信頼性の高さが、今後もGoの支持につながると思います。
概要:
このMedium記事「Inside Go’s Memory Model: What Every Senior Dev Should Know」は、Go言語のメモリモデルに関する高度な技術解説です。主な内容は以下の通りです:
- happens-before規則：Goのメモリ操作の可視性を規定し、異なるゴルーチン間でデータ競合が起こる理由と、正しい同期の必要性を解説。
- 同期ポイント：チャネル送受信、MutexのLock/Unlock、WaitGroup、Once、アトミック操作など、Goが保証する同期方法を紹介。
- スタック・ヒープとエスケープ解析：変数がどこに割り当てられるかと、その決定がパフォーマンスやGCコストに与える影響を説明。
- ガベージコレクタの仕組み：Goのマーク＆スイープGCの特徴、stop-the-world時間の短縮、GCチューニング方法を解説。
- ゴルーチンとメモリ所有：各ゴルーチンは独自のスタックを持つが、ヒープは共有されるため同期が不可欠。
- sync/atomicによる低レベル同期：アトミック操作は高速かつメモリセーフだが、通常の読み書きと混合すると未定義動作になることに注意。
- メモリリオーダリング：Goランタイムやコンパイラによる最適化と、happens-beforeを守る重要性。
- デバッグ・検証ツール：pprofやMemStatsなどの組み込みツール活用方法を案内。
- ありがちな落とし穴：同期のない構造体共有やグローバル状態のタイミング依存など、上級者でも犯しやすい失敗例を列挙。
- シニア開発者の視点：Goのメモリ内部を深く理解し、スケールする堅牢な並行システムを設計する姿勢の重要性を強調。
まとめとして、Goのメモリモデルは単なる仕様ではなく、「安全性とパフォーマンスが両立する並行設計の約束」であり、これを理解することで安定したプロダクションコードが書けるようになると結論付けています。
感想:
Go言語のメモリモデルについて、実践と理論の両面から非常に分かりやすくまとめられた素晴らしい記事でした。happens-before規則や同期ポイント、GCの動作原理など、普段意識しづらい内部動作まで踏み込んだ内容で、現場で即役立つ知識が多かったです。特に、シニア開発者として並行処理の安全性や性能を担保するための考え方に共感しました。Goで堅牢かつスケーラブルなシステム設計を目指すなら必読の内容だと思います。
概要:
2025年のGoエコシステムは極めて成熟し、注目すべき6つのライブラリがソフトウェア開発を大きく変革しています。Fiber v3はExpress.js風の高速API開発を可能にし、HTTP/3や豊富なミドルウェアが特徴です。Ent ORMは型安全でスキーマ進化が容易なグラフベースORMを提供します。Temporal Go SDKはクラウド分散処理の信頼性を大きく高め、耐障害性を簡単に実現します。GQLGen v2はGraphQLサーバー開発においてコード生成とホットリロード、連携機能が強化されました。GoFlowは宣言的な並行処理を実現し、大規模データパイプラインやAI活用に最適です。Bun ORMはSQLらしさと高速性を兼ね備え、GORMに取って代わる存在になっています。これらに加えZapやCobraなどにも注目が集まっています。Go言語は表現力と生産性を備えた、現代的な競争力ある言語へと進化しているのが2025年の特徴です。
Go言語におけるログ出力のベストプラクティスについて解説しています。パフォーマンスを損なわず、開発と運用の両面で有用なログを残すには、「ログレベルの活用」「レベルチェックによる遅延評価」「バッファ付き・非同期書き込み」「構造化ログ」「ループやホットパスでの過剰なログ抑制」「本番環境でのサンプリング」などが重要です。更に、ログのボリューム管理やベンチマークでの負荷測定も推奨されています。これらの実践で高速かつ実用的なロギングを実現できます。
Go言語が高性能な並行処理を実現できる秘密は、ランタイムシステムにあり、主に「スケジューラ」「ガーベジコレクタ」「メモリアロケータ」「スタック管理」の4つで効率的な動作を支えています。スケジューラは軽量なゴルーチンを効率的に分散・管理し、ガーベジコレクタは自動で不要メモリを掃除します。メモリアロケータは倉庫管理のように高速配分を行い、スタック管理は必要に応じて動的拡張します。これらの仕組みが、シンプルなコードで高速かつ安定した現代的なアプリケーション開発を可能にしています。
概要:
このGitHubページ「go-gorm/cli」は、GORMプロジェクト向けの型安全なコード生成CLIツールを紹介しています。主な特徴は、Goジェネリクスによる型安全なインターフェース駆動のクエリAPI生成や、モデル構造体から自動生成されるフィールドヘルパー（絞込・更新・並び替え・関連操作）です。SQLテンプレートコメント付きインターフェースで、タイプセーフなメソッドを生成でき、GORM本体とのシームレスな統合や柔軟な設定（出力パス、フィールドマッピング等）が可能です。モデルや関連（has one、has many、belongs to、many2many）ごとの操作も型安全に行えます。またクイックスタート手順や設定例、SQLテンプレートDSL例も記載されています。
Go言語で既存ファイルを安全に更新するには、一時ファイルに全内容を書き込んでからrenameで置き換えるのが基本です。直接上書きすると途中で失敗した場合や他プロセスとの競合が起きるため危険です。また、os.CreateTempを使う際は最終配置先と同じディレクトリで一時ファイルを作る必要があります。systemdのPrivateTmp運用時は/tmpの扱いに注意し、同時実行時は最後にrenameしたものが反映されます。
その他
LangChain
概要:
LangChain v1.0は2025年10月22日にリリースされ、エージェント構築機能が大幅強化されました。主な新機能は「create_agent」によるエージェントAPIの刷新、柔軟な拡張を実現するミドルウェア標準搭載、テキスト・画像・ツール呼び出し等を統一的に扱うコンテンツブロック、出力フォーマット指定による構造化出力、LCELによるチェイン記述の簡潔化など。旧機能はlangchain-classicに分離され必要なモジュールのみ選択可能となりました。また、Python3.9のサポートは終了し3.10以降が必要です。統合と分離によりエージェントフレームワークとして大幅に完成度が向上、後発フレームワークに匹敵する内容となっています。既存利用者はコード例を参考に移行すべきです。
感想:
大分使いやすくなっている。前に書いた物を書き直したい。
AIとお仕事
概要:
このスライドは、AIがコードを書いてくれる時代における「新米エンジニアが何をすべきか」をテーマにしたプレゼン資料です。主なポイントは以下の通りです。
- AIによるコーディングが当たり前になることで、新米エンジニアが「手を動かして学ぶ」従来の成長ルートが変化する可能性を提起。
- 顧客が求めるのは「価値」であり、技術そのものではなく「役に立つもの」をAIを活用して効果的に生み出すべきと強調。
- AIを役割分担してチーム化し、人間がそれを指揮・橋渡しする役割になる構図を提示。
- 人間には「説明責任」や「遂行責任」が発生し、成果物の価値やプロセスの説明能力が重要となる。
- 新米エンジニアは「AIが書いたコードを説明できる知識」、「コーディング以外の工程への理解・貢献」、「説明力」を磨くことがキャリア形成につながると提案。
- IPA試験区分などの専門性（ITストラテジスト、システムアーキテクトなど）も参考に、多様なスキルを学ぶことを推奨。
まとめ：AI時代のエンジニアは、単なるコーディングスキルだけでなく、「価値を説明する力」や「プロジェクトの全体像を把握する力」が求められ、キャリアの方向性も「Individual Contributor（IC）」と「Engineering Manager（EM）」で分岐する可能性がある、という内容です。
感想:
結局やることは変わらないと思うが、実装技術よりもより概念的な技術、設計力、開発プロセスに対する理解、ドメイン知識、それらを身につけていくためのメタ学習といったものが重要になっていくし、先ほどの国語力にもつながるが、説明能力、AIが出力したものへの理解力がより重要になると思う。
AIを効率的に活用するには「指示力」よりも、何をAIに提示するかという「文脈設計力」が重要だと述べています。LLM（大規模言語モデル）は確率的に応答し、会話が長くなると不要な情報がコンテキストを圧迫し応答品質が低下します。プロンプトの工夫だけでは解決できず、コンテキストから不要な情報を「引き算」する設計が必要です。エンジニア自身の基礎理解と目的意識が、AIの効果的な利用に不可欠だと強調しています。
ツール
この記事は、システム構成図やシーケンス図を作成する際に「どのツールを選べばいいか悩む」エンジニア向けに、draw.io・PlantUML・Mermaid・FigJamなどの人気ツールを比較し、実際の使い分け事例とメリット・デメリットを網羅的に解説しています。
主な内容は以下の通りです。
- draw.io：無料かつ高機能で汎用性が高く、システム構成図やER図作成に多用される万能ツール。GUI操作が直感的だが、Git管理がしづらい・起動が重いという弱点もあり。
- PlantUML：テキストで図を記述するコードベース派に人気。Git管理やAI連携が得意だが、配置調整が難しい・Javaベースで慣れが必要。
- Mermaid：MarkdownやZennに埋め込めるテキストベース。AIとの親和性が高くコスパも良い。複雑な図は苦手だが、GitHubとの連携やAI生成ワークフローに強い。
- その他のツール（FigJam/Miro/Visio/Excalidrawなど）：共同編集やデザイン性、ホワイトボード用途・業務環境などニーズ別に解説。
-
用途別のおすすめ：
- シーケンス図にはPlantUMLやMermaid
- ER図や構成図にはdraw.io推奨
- Swagger、icepanel.ioなど特化型ツールも紹介
- 現実的な業務環境：PowerPointやExcelなど、企業事情・非エンジニア説明用途としてOffice系の汎用性も根強い。
- 使い分けパターン：ツール選定基準や、読者、用途、環境制約に合わせた柔軟な併用事例を紹介。
- 結論：銀の弾丸はない。使い勝手・同僚環境・AIとの相性・用途ごとに最適なツールを選択するのが重要。
- AI・LLM時代を見据え、draw.ioとMermaidの二刀流を推奨。AIが扱いやすい軽量フォーマットへの慣れが今後の武器になるとしている。
図表作成・ドキュメント生成の現場のリアルと、AI活用時代へ向けた現状分析・今後の選定基準がまとまった記事です。
感想:
VISIO最強！
チーム開発
概要:
この記事は、エンジニアリングチームの戦略的成長を実現するための行動指針について解説しています。
主なポイントは以下の通りです。
-
スケーリングで直面する3つの課題
- チームやツール間の一貫性の欠如
- 可視性・メトリクス・リスク把握の不足
- 組織拡大による複雑性の急増
-
スケールに応じた組織変化
- 小規模はフルスタック担当で柔軟
- 中規模は専門分化とサイロ化
- 大規模になると自律性・部門単位でのサイロ化・調整の困難化
-
プラットフォーム思考の重要性
- ツールの棚卸し・重複排除
- 組織全体に最適化したプラットフォームを選択
- AI主導のワークフローを一元管理
- DORAメトリクスなど組織的指標の重視
- データ戦略の優先・運用管理自動化
-
継続的な評価と適応が必要
- スケーリングに終わりはない
- 技術的課題だけでなく組織的な“複雑さ”へ体系的に向き合うことが持続的成長の鍵
まとめ：個別ツール管理ではなく、プラットフォーム基盤への転換が、AI時代のエンジニアリング組織の成長に不可欠であると説いています。
感想:
個人の最適化とチームの最適化はアプローチが異なる。チームの最適化をしようとすれば、作業の標準化、ツールの標準化、メトリクスの計測とそれに基づくカイゼンと、よりソフトウェア工学的なアプローチが必要になっていく。個人の技芸を誰もができる「仕事」にしていく必要が生じていく。当然それを気に入らない人はいる。
設計
概要:
この記事は、アーキテクトチームやテックリードが「設計や実装パターンを絞る」理由や背景、そして技術選定におけるジレンマについて述べています。
主なポイントは以下の通りです。
- 設計／実装パターンの統制は、プロジェクト全体の最適化（品質・保守性・認知負荷削減）を目指すため。一方、開発者側は局所最適（その場の効率や新技術の採用）を重視しがちで、双方の視点が異なり衝突や不満が生じることがある。
- 統制のメリット（品質担保や保守性向上）やデメリット（モチベーション低下、開発速度低下など）があり、状況やフェーズによってバランスを取る必要がある。
- ガイドラインは整備しても読まれにくく、現場の実態に即した実効性あるルールが大事。また、AIレビューや静的解析などツールの活用も重要。
- チーム規模や技術レベルで統制の必要度は変化し、「ダンバー数」など人数に応じて設計方針を変えるのが妥当。
- レビュー時は指摘の理由や判断基準を明確化・伝達し、納得感を大切にすることが信頼関係につながる。
- 統制はプロジェクト、部門、全社視点で考え、特定領域は標準化のメリットを重視するが、現場適用性や新陳代謝も考慮する。
まとめとして、アーキテクトは「開発速度」と「引き継ぎコスト」の間で最適解を探るバランス調整役を担い、それぞれの立場や規模に応じた議論・技術選定が重要と述べています。
感想:
属人性が強いとスケールせず、引継ぎも難しい。統制がきつすぎるとモチベーションが低下し、「かたちだけ」が横行する。そしてAIの登場ときて、個人的には統制のルールに関してはAGENTS.mdに書けるぐらいの内容が良いのではないかと思うようになりました。AIと人間がルールを共有するのも大事なっていくと思いますし。
Discussion