今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
Go言語
GoによるAPI開発に使っているツールセットと環境を、用途別に紹介した記事です。主要な構成は、Go言語・PostgreSQL・ent ORM、ローカル開発はDocker／Docker Compose・Make・air、ObservabilityはOpenTelemetry・zap、API定義はprotobuf/gRPC/gRPC-Gatewayをbufで管理、品質管理はgofumpt・golangci-lint、DI・テスト補助はwire・go-cmp・mockを利用。エディタはVS Code＋Go拡張＋Copilot＋Prettier SQLで整備。さらにMCP/SerenaによりCopilot Chatからリポジトリ全体の操作も可能で、実例として参考になるカタログ形式。
Go言語のバッファ無しチャネルは、送信と受信が同時に揃わないと進行できず、単一ゴルーチンのみのコードで送信後に受信する構造だとデッドロックが発生します。回避するには送信・受信を別ゴルーチンで行い、順番にも注意が必要です。バッファ付きチャネルなら順番に関係なく成立しますのでこの落とし穴を理解することが重要です。
Testcontainersは、Dockerコンテナを利用してリアルな依存サービス（例：データベース、Elasticsearchなど）をテスト時に立ち上げるためのオープンソースライブラリです。従来、外部環境の不具合や停止によってテストが失敗しがちでしたが、Testcontainersを使うことでテストコード内で必要な依存サービスをその場でコンテナ化し、本番に近い環境下で結合テストや機能テストが可能になります。そのメリットとしては、外部環境に依存しない安定したテスト、モックを減らして実際の動作検証ができる点、CI環境でも手軽にテスト環境を構築できる点が挙げられます。逆に課題としては、コンテナの起動によるテスト実行の重さや、起動画像や初期化に時間がかかりコストが増加する懸念があります。対策としては、テストジョブを分離したりタイムアウト設定を活用することが重要です。本番環境との差異も認識し、どこまでTestcontainersで再現するか判断したうえで導入を進めることが推奨されています。テストの品質向上のために積極的な活用がおすすめです。
Goの公式言語仕様書「The Go Programming Language Specification」を精読する意義と、その際に役立つ英語用語集を紹介した記事です。仕様書を読むことで細かな挙動やコンパイラ視点の理解が深まり、デバッグ力や特殊な動作に対処する力が身につきます。ただし、初心者の文法学習用というより発展的な知識の獲得に適しています。本文では仕様書内の章構成とGo特有の用語、よく登場する英単語も解説されており、例や検証を通じて理解を深める方法も提案しています。
go-keysetは、Goで型安全なKeyset Pagination（カーソルベースページング）を実現するためのツールキットであり、ORM非依存でGORMやdatabase/sql、Raw SQLにも対応しています。従来のOFFSET方式のページネーションはデータ量の増大や同時更新で問題が生じやすいですが、Keyset Paginationはソートキー（idやcreated_atなど）を基準に前回取得した最終レコード以降のデータを効率的に取得できます。本ライブラリはWHERE句やORDER句の自動生成、双方向ページング、カーソルのエンコードなど煩雑になりがちな処理を部品化し、base64urlで安全にカーソルを扱えるのが特徴です。GORM専用、Raw SQL向け両方のインターフェースが提供され、複合キーページングや表示順の統一にも対応。今後はentやsqlcのサポート、署名付きカーソル導入も予定されており、大量データや無限スクロールのGoアプリ構築において「安心でシンプル」な実装を目指しています。
この記事では、Goのgo.modは依存関係を列挙するだけでなく、プロジェクト構造自体を宣言する役割があると解説されています。依存の追加・削除時はgo mod tidyで全体の再整合を行い、不要な依存は削除しgo.sumも更新します。tidy実行前には単一モジュールであることを確認し、下位フォルダのgo.modは排除することが重要です。replaceは主に応急処置として短期的な差し替えに使い、恒常的な運用は避けるべきです。replaceを使う際は期限や撤去条件を明記し、コミットしない運用が推奨されています。安定したモジュール管理のためには、必要に応じて再整合と一時的なreplace対応を心がけることが重要です。
Go言語で作成するWindows用exeファイルに、アイコン・ライセンス情報・バージョン（gitタグ由来）などを埋め込む手法を解説。JSONでリソース指定し、josephspurrier/goversioninfoを活用。バージョン取得にはgitコマンド連携も可能。
その他プログラミング
Git
Git 2.52では「git last-modified」という新コマンドが追加され、ディレクトリ内の各ファイルが最後に変更されたコミットを高速に特定できるようになりました。さらに、リポジトリのメンテナンスを効率化する「geometric」戦略がgit maintenanceに導入され、大規模リポジトリでもスムーズな運用が可能です。その他、git refsやgit repoの新機能、今後のGit 3.0でのデフォルトブランチ名やSHA-256対応、Rustサポートの追加、Bloomフィルターによるパス指定処理の高速化など、多数の機能強化と最適化が行われています。
Git for Windows v2.52.0.windows.1では、「git svn」のサポートが終了しました。主な更新内容は、Git v2.52.0、PCRE2 v10.47、cURL v8.17.0の採用、インストーラーをInnoSetup v6.6.0でビルドすることで、よりモダンな外観となりました。バグ修正として、git help git-bash コマンドの不具合が解消されています。このリリースには各アーキテクチャ用のバイナリも含まれています。
開発プロセス
2025年のDORAレポートをもとに、AIを導入したことで個人の作業スピードは向上しても、チームや組織全体のデリバリー性能には大きな変化がない――むしろ混乱や問題を招くケースもある、という現象が明らかになっています。その原因は個々のスキルではなく、組織全体の「システム」、すなわち構造やプロセス、文化にあり、AIを最大限に活かせるかどうかはそれらの整備度合いに左右されると指摘されます。
レポートは「フロー」と「摩擦」に着目し、AIはシステムの良い面・悪い面を増幅する「鏡」として機能し、システムが未成熟だとボトルネックが一気に顕在化すると説明します。2024年調査ではAI導入組織ほど「スループット」が低下し「不安定性」が増したという異変も報告されており、対策としてはValue Stream Management（VSM）やプラットフォームエンジニアリングの実践が推奨されます。これはフローの滞留箇所を可視化・改善し、組織全体の流れを整える手法です。
また、AI導入により個人の生産性やコード品質は向上しても、「摩擦」や「燃え尽き症候群」にはあまり影響がなく、摩擦を減らすことが組織パフォーマンス向上に不可欠だと述べられています。摩擦の原因としては、頻繁な割り込み、複雑な承認フロー、情報の所在不明、使いにくいツール、組織設計の歪みなどが挙げられます。
改善のためには、ストリームアラインドなチーム編成（バリューストリームごとに専属チームを持ち、継続的にフローの改善を行う）が有効とされています。摩擦軽減に役立つ「AIケイパビリティ」としては、AI活用方針の明確な伝達、小さいバッチサイズでの作業が提案されており、個人効率より全体最適とユーザー価値の向上を優先するべきだとする内容です。
総じて、AI導入で組織の成果を最大化するには、「個人の高速化」ではなく、「システム全体のフローを整え、摩擦を減らす」ことが重要。AI活用を単なるツール導入ではなく、組織変革の契機として捉え、継続的な体制改善とともにユーザー価値追求を忘れないことが鍵となります。
アジャイルは単なる開発手法ではなく、事実を偽らず正しく共有し、共通の目的にコミットし、論理的に推論・自己修正できる人材で構成されたチームでのみ成立する哲学的な方式です。誠実性・好奇心・論理思考・成長力が不可欠であり、これらが欠けると混乱や停滞につながります。アジャイルは「誰でもできる優しい方式」ではなく、特定の能力セットを持つ人材による高速な学習と適応を前提とした知的に均質な集団のための運用手法であると述べています。
感想:
バカはアジャイルチームに入れられないという身も蓋もないご意見。まぁでもそれもわかる。それなので、現状のLLMベースのAIエージェントはアジャイルに向かないし、それ故に仕様駆動開発みたいな話が出てくる。
エージェンティックコーディング・仕様駆動開発
仕様駆動開発（SDD）は、AIやエージェントを活用する開発現場で「Vibe Coding」から脱却し、明確な仕様（Spec）を中心に据える手法です。Specは自然言語かつ構造化され、要件定義・設計・検証・フィードバックまで一元管理する“単一の情報源（SSoT）”として設計されます。SDDのメリットは、設計レビューの負荷軽減や並列開発の促進、チーム認識のズレ削減があります。一方、実装・検証の自動化や反復サイクルが本質であるものの、Specの巨大化や設計検証の難しさなど現実的な課題も多く、ツールや運用、組織構成の成熟が求められます。例としてOSSツール「cc-sdd」やKiroによるProperty-based testsの導入でSpecの正確性検証も進められております。SDDの導入にはDevOps基盤とモジュール設計が不可欠で、明確な境界・安定した領域での小規模導入が推奨されます。SDDは品質とスピードの両立を目指す現代的ソフトウェア開発手法です。
感想:
よく纏まっていて参考になります。
AI
Googleが発表したGemini 3は、同社史上最も知的なAIモデルとして、あらゆるアイデアの実現をサポートします。Gemini 1・2で培ったマルチモーダル処理や高度な推論力に加え、Gemini 3では文脈や意図の把握力がさらに向上。AI検索、Geminiアプリ、開発者向けAI Studio・Vertex AI、そして新たなエージェント開発基盤「Google Antigravity」など多様なサービスに本日より展開されます。
Gemini 3 Proは、PhDレベルの推論能力や数学・科学的分野で最先端のベンチマークスコアを達成。マルチモーダル理解でも他モデルを圧倒し、さらに「Deep Think」モードでは複雑な課題対応力が大幅強化されています。日常生活でも開発でも学習・構築・計画の支援機能が強化され、開発者向けにはエージェントによる自動化・効率化も期待できます。
また、セキュリティ評価や安全性にも徹底配慮され、今後も継続的な改良と新モデル展開が予定されています。Gemini 3は新しいAI時代の幕開けとして、高度な知能とエージェント機能でユーザーの多様なニーズに応えます。
Google Antigravityは、AIが主導する次世代ソフトウェア開発環境を目指し、Googleが新たに公開したエージェント指向の開発プラットフォームです。Gemini 3をはじめとする最先端AIモデルを搭載し、従来型IDEの枠を超えて、エージェントが計画から実装、検証までを自律的かつ非同期に遂行する「agent-first」な体験を提供します。
Antigravityでは「信頼」「自律性」「フィードバック」「自己改善」という4つの柱を根幹に据え、それぞれの役割を明確に設計しています。信頼性の面では、各タスクごとに成果物（アーティファクト）や検証結果をユーザーへ提示し、エージェントの作業内容を分かりやすい形で可視化します。自律性では、エージェントがエディタ、ターミナル、ブラウザなど複数の作業環境を横断しながら独立して作業できるほか、従来の埋め込み型IDEとは逆転し、「マネージャ」画面でエージェントの進行管理や複数並行作業が行えます。フィードバックも重視しており、成果物すべてに対してGoogleドキュメント風のコメントやスクリーンショットへの指摘ができ、こうしたフィードバックはエージェントの処理に自動反映されます。自己改善機能では、エージェントが過去の経験やフィードバックから知見を蓄積し、同様のタスクに活用します。
現在Antigravityは個人利用向けに無料で提供されており、MacOS、Linux、Windowsに対応。Gemini 3だけでなく、Claude Sonnet 4.5やGPT-OSSモデルも利用可能で、タスク量に応じた制限がありますが、多くのユーザーで問題なく使えます。AIと開発体験の進化を感じたいエンジニアにとって、次世代の開発プラットフォームと言えるでしょう。
エンジニア
図にする
「解法を図解する技術」は、Kaggleコンペなどで自分の解法を分かりやすく伝えるための図解手法をまとめたスライドです。まず、テキストで解法を項目ごとに分割し、その構成を考えることで、情報の流れや重要度を整理します。図解には「ブロック図」「図形」「アイコン」「画像」などを使い分け、見やすさや伝わりやすさを意識します。さらに、詳細化と簡略化を使い分けて、必要な部分だけを強調します。デザイン面では「近接」「整列」「反復」「コントラスト」「カラー」の五原則を意識することで、情報のまとまりや違いを視覚的に表現できます。これらの技術により、discussionやSNS投稿時に反応が得やすく、印象的な解法まとめが可能になります。また、ノンデザイナーズ・デザインブックなどの良書も参考にすると効果的です。
問題解決の方法
本記事は、筆者がSREとして大規模メール配信システムの障害に直面した実体験から、「問題解決」と「知識のつなげ方・断ち方」について深く考察しています。
はじめに、解決不能に見えた障害を突破できたきっかけは、Webサービスやネットワークといった一見別分野の知見（バックプレッシャーやバッチ処理概念等）を応用したことでした。「異なる分野の知識をつなげる」ことで新しい解決策が生まれ、複雑な問題を乗り越えることができた体験が紹介されます。
筆者はこの経験を元に、問題解決のプロセスを8段階に整理し解説します。各段階は「問いの明確化」「問題分解」「関係者の望み理解」「知識収集」「組合せの試行」「無意識への委託」「アイデアの出現待ち」「他者視点での検証と実践」です。これらは単なる直線的な流れではなく何度も螺旋的に往復しながら洗練されます。また、プロセスは人ごとに最適化すべきもので、個々人の解決様式があることも強調されています。
しかし一方で、知識を「つなげすぎて」しまう失敗例（過度な複雑さ、文脈にそぐわないパターンの適用）についても述べられています。真に価値ある解決策を生み出すには、「不要なつながり・思い込みを意識的に断つ」＝"アンラーン"の技術が不可欠であり、それは一種の訓練や姿勢であると説かれます。
現代AIの時代についても議論されており、AIは知識の「点」としては有用だが線や構造（知識と知識のつながりや文脈）までは与えてくれないこと、書籍等と組み合わせ自ら問い・分解・検証・断捨離の往復運動を意識する重要性を説いています。
総じて、問題解決には分野横断的な知識の「つなげる力」と同時に断つ能力・アンラーンの意識が不可欠であり、AI時代も主体的な問い直しや選択・検証こそが真に活きた思考となると結ばれています。
感想:
相変わらず長いなｗ
問題解決への思考方法。あと広い分野の知識を積み上げることによって得られる広い視野を持つことの重要性。
Discussion