今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
Go言語は1.26からは標準となる予定のGree Tea GCが要注目です。この際にGoのメモリ管理について深掘りしておくと良いかもしれません。あとは、sqlmockを使わずに実DBをテストに用いる仕組みは実用的だと思いました。例外処理のテストなどmockを使わないと実現できないものもありますが、多くの場合は実DBを使った方が良いと私も考えています。
あと、GitHub Universeがあったので、その話題を入れておきました。また、エンジニアとしての方向性に感じる記事も引き続き取り扱っていきます。
Go言語
概要:
Go 1.25で新しい実験的ガベージコレクタ「Green Tea」が導入されました。ビルド時にGOEXPERIMENT=greenteagcを設定することで利用でき、多くのワークロードでGC時間が10%短縮、最大40%短縮される場合もあります。Green Teaは既にGoogleで実運用されており、Go 1.26でデフォルトとなる予定です。
従来のGCはオブジェクト単位でグラフ探索を行う「mark-sweep」アルゴリズムが中心でしたが、Green Teaは「ページ単位」で処理することで、メモリキャッシュの効率向上とCPUストールの軽減を図ります。これにより、現代のマルチコアCPUやベクタ命令（AVX-512など）にも最適化されています。
さらにGreen Teaは並列処理やベクタ命令を活用し、ページごとにローカルメタデータを管理することで高速化を実現。不規則なヒープ構造にも対応でき、場合によっては従来方式より効率が落ちるケースもありますが、ほとんどのワークロードで性能向上が見込まれます。
Go 1.25で試すことができ、Go 1.26では更なる最適化とフィードバックをもとに改善が加えられる予定です。
概要:
SQLBoilerがメンテナンスモードに入り、RemitAidでは移行先としてsqlcを選定。sqlcは生SQLを活かした型安全なコード生成が可能で、既存コードとの共存や段階的な移行も容易。学習コストが低く、保守性向上のためリポジトリ単位でSQLファイルを分割。今後は新規API開発から導入し、既存実装も段階的にsqlcへ移行予定。
感想:
自分達もSQLBoilerからの移行先を探しているので、参考にしたい。ただ、sqlcを試していて、ちょっと複雑なクエリーを書くと対応できないことがあり、どうしたものかと。SQLBoilerでそれが書けていたわけでもないのですが。
概要:
GoでAPIの応答が10秒に激増した原因は、大量の一時オブジェクト生成によるGC負荷だった。sync.Poolでバッファを再利用し、メモリ割当削減とGC効率改善で180msに短縮。Goのパフォーマンスには、測定・GCへの配慮・再利用が重要と学んだ。
概要:
この記事は、VS CodeとDocker（Dev Containers）を活用して、Go開発の再現性やチームでの共有効率を高める最新の環境構築法を解説しています。開発コンテナ導入で環境構築の手間を減らし、Goバージョンやツールの管理、設定管理（viper）、構造化ロギング（zerolog）、標準テストやテストコード、用途別Docker環境（開発・テスト・本番）など、モダンなアプリ開発課題を実践的にカバーしています。サンプルアプリでは責務分離設計や依存関係管理、柔軟な環境切替などを紹介し、環境構築から本番運用までの手順と要点がコンパクトにまとまっています。
概要:
Goのサービス開発でよく見られる「main.goに全てのロジックを詰め込む」や「ハンドラーとビジネスロジック、データベース処理が混在する構成」は、テストの難しさや再利用性の低さなどの問題に発展しがちです。Hexagonal Architecture（ポート＆アダプター）を採用することで、ビジネスロジックを中心に据え、HTTPやDBなど外部要素を疎結合で扱えるようになり、MongoDBからPostgreSQLへの交換やテスト、CLIやgRPC対応などが容易になります。小規模アプリでは過剰かもしれませんが、サービス規模が大きくなるほど効果を発揮し、Goのクリーンでモジュール化された設計が実現できます。
概要:
この記事では、Go言語による「DBアクセスを伴う単体テスト」の考え方・実践方法を紹介しています。モック（go-sqlmock等）は高速かつ依存を排除できる一方、リファクタリング耐性に乏しくテスト保守性が低下しやすい課題があります。そこで、実DBをスキーマ分割して並行テストを行う方法を提案し、「mysqltest」ライブラリを公開。各テストケースごとに独立したスキーマ・ユーザーをセットアップし、自動クリーンアップする仕組みにより、依存を排除しつつ並列実行＆高速化（5倍以上）を実現しています。大規模DDLが必要な場合は従来型モックも選択肢となり、用途ごとに使い分ける重要性も述べています。
感想:
Mockは便利なのですが、実際のRDBMSを使わないとわからない事もあったり、テストを変更したいのにひたすらMockを修正しているみたいなことにもなりがちなので、こういう試みは面白いですね。
v2.6.0がリリース。
AI
GitHub Copilot
GitHub CopilotがVisual Studio Code Insiders向けにアップグレードされました。主な新機能は、OpenAI Codex統合（Copilot Pro+契約者向け）、エージェントセッション管理画面、特定タスク専用のサブエージェント、そしてステップごとの実装計画を作成し要件を検証できる「Plan Mode」の追加です。新機能はGitHub Universe 2025で発表され、Insiders版で体験可能です。
Copilotコーディングエージェントのタスク管理画面が刷新され、進捗確認やタスク操作、ログ閲覧などが1つのビューで可能になりました。リアルタイムの指示やフィードバック送信も容易になり、タスク間の切り替えや独自エージェント選択にも対応。作業はGitHub上やモバイルなど様々な場所から開始・継続でき、VS Codeなどでの編集にも対応しています。今機能はCopilotエージェント利用者全員に提供されます。
GitHub Copilotコードレビューが新たに公開プレビューとして提供開始。LLMとESLintやCodeQLなどのツールを組み合わせ、AIによる全体像を踏まえた賢いレビューが可能に。プロジェクト全体の文脈把握、セキュリティや品質の高精度検出、Copilotによる自動修正提案とプルリク反映、柔軟なワークフロー設定・複数エディタ対応を実現。Copilot Proユーザーは自動、Business／Enterpriseはオプトインで利用可。
GitHub Copilotの利用状況を可視化する「Copilot usage metrics dashboard」とAPIが、GitHub Enterprise向けにパブリックプレビュー公開されました。企業内のCopilot採用・活用度やIDE別利用状況、ユーザーごとのアクティブ数、追加・削除コード行数、使用言語・モデルパターンなどの詳細データを管理者が把握できます。ダッシュボードから集計表示やAPI・NDJSONで詳細分析が可能で、機能はAIコントロール画面で有効化できます。
Copilot coding agentが、Actions Runner Controller（ARC）で管理するセルフホスト型GitHub Actionsランナーをサポートしました。これにより、Copilotの開発環境を自らのインフラ上に構築でき、社内パッケージなどインターネット非公開リソースへのアクセスも可能です。設定はARCの導入後、copilot-setup-steps.ymlのruns-on:ターゲットをスケールセット名に変更するだけです。詳しくは公式ドキュメントを参照してください。
GitHub Copilot coding agentがJetBrains IDEからタスク委任できるようになりました。Copilotにタスクを依頼すると、クラウド環境で非同期に処理を行い、ドラフトのプルリクエストを作成しレビューを依頼します。IDEのCopilot Chatから進捗を追跡でき、複数プランで利用可能です。管理者の設定後、チャットで「Delegate to Coding Agent」ボタンを使いタスクを委任、進捗はジョブカードや通知で確認できます。フィードバックも受付中です。
LangChain
LangChainとLangGraphが1.0正式版として公開され、AIエージェント開発がより安定・信頼性の高いものとなった。LangChainは抽象化インターフェース「create_agent」やミドルウェア機構を導入し、柔軟な制御や開発が可能に。LangGraphは永続状態管理を実装し、長時間運用や途中再開に対応。開発から運用まで一貫したエコシステムが構築され、後方互換性も維持される。さらに、標準コンテンツブロックやヒューマン・イン・ザ・ループ対応など、開発者にとって有用な新機能も多数追加された。
本
その他
クラウドとAIは規模の経済。資本の大きさが勝負を決める。
その他
AIと仕事
概要:
このZennの書籍「ソフトウェアエンジニアはいかにしてAIを真に愛するに至ったか - コードを書く人から設計意図を定義する人へ -」は、ソフトウェアエンジニアリングの未来とAIとの付き合い方について考察しています。
主な章構成は以下のとおりです。
- AIエージェントの構造的限界
- 自動化の逆説（AF447事故からの教訓）
- ソフトウェアエンジニアリングの普遍的本質
- EU AI Actが示す人間中心の価値観
- 生物進化から学ぶ共生の原理
- AIエージェントとの共生の未来
- AI時代に変化するエンジニアの役割
- 「設計意図を定義する人」への成長戦略
内容は、AIの技術的制約や人間中心のアプローチ、自動化の危険性、進化論的視点からの共生、エンジニアの役割変化といったテーマを横断的に論じています。特に、コードを書く作業から、設計意図そのものを定義できる人材への成長戦略がまとめられている点が特徴です。ソフトウェアエンジニアとしてAIとどう向き合い、どのように価値創造に関わっていくかを示唆する内容です。
感想:
とにかく一度通読することをお勧めする。
概要:
Andrej Karpathy氏の2025年最新インタビュー記事の要約は以下の通りです。
- AGI実現はあと10年程度必要と予測。現状のAIは生物的知能とは異なる「幽霊」であり、進化による「動物」とは本質的に異なる仕組み。
- LLM（大規模言語モデル）には構造的な認知欠陥が多く、複雑な作業や継続学習にはまだ不十分。また、強化学習も非効率で欠陥が多い手法と指摘。
- AGIは経済を急激に変えず、GDP成長率2％の延長線で緩やかに統合されると予測。爆発的変化よりも、歴史の中で続いてきた緩やかな技術進化の一部となる。
- AI時代の教育と人間拡張の重要性についても語り、自身が設立したEureka等の教育事業を通じ、人間がAIと共存し学び続ける未来を構想。
- 将来のAI社会は、単一の超知能ではなく複雑な自律エージェントの生態系に。人類は徐々にシステム全体の制御を失うが、「悪意」というより構造的な複雑化によるもの。
- 技術の産業化や社会実装は困難で、製品化には長い“ナインの行進”が必要。厳選されたデモより、現実運用には多くのギャップと課題がある。
全体として、「AI/AGIに過度な期待やディストピア的恐怖を持つよりも、現実的な技術進化と社会変化への漸進的適応が重要」とまとめられています。
感想:
正直、技術が嫌いな人はあまり向いていないのでは。30年以上業界の片隅に居続けてきたけど、この業界は「好きこそものの上手なれ」です。コンピューターが好きでないと続けていくのはしんどいと思う。技術のキャッチアップができなくて業界から去って行った人を何人も見ている。
概要:
働き始めると本を読む時間が減り、エンジニアは「考える力」と「語彙力」が弱まる傾向にある。日々、情報収集や学習に追われて効率的に問題を解決するが、「なぜその方法にしたか」といった本質的な思考や説明が不足しがちである。読書は自分の思考のバグをデバッグする行為であり、他人の表現や視点に触れることで自らのアウトプット力も鍛えられる。特に語彙力や説明力は、エンジニアのコミュニケーションや設計思想の伝達に直結し、読書によってそのストックを増やせる。ジャンルごとに思考や共感力、抽象化力など異なる力が養われ、長期的に読書が思考力・言語力の「筋力」となり、技術以外にも人への理解が深まる。コードはすぐ古くなるが思考力は一生使える―読書はエンジニアの根幹をアップデートする投資であると筆者は説く。
感想:
実装技術は揮発する技術、概念的な技術は揮発しない技術。あと、人間は言葉で考えるので、とにかく読んで書くことで語彙力や、言語での思考力を向上させていくことが大事。LLMを使うにしても、LLMには言語を使って指示を与えないといけないわけだし。
Discussion