今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
Go言語
Go言語で自動微分ライブラリを実装し、機械学習の仕組み理解とコードの簡素化を目指した記事です。「ゼロから作るDeep Learning❸」を参考に実装し、基本の使い方（変数と関数、合成関数、高階微分）や応用例（勾配降下法、機械学習フレームワーク構築）を紹介。Goには演算子オーバーロードがないため、Pythonより記述が明示的ですが、合成関数のBackward実装不要などメリットも強調しています。行列演算やFunctionの実装も解説し、課題や開発エピソードも記載しています。
従来のOCR精度の課題をLLM（Claude Vision API）で克服し、高精度なレシートOCRシステムをGo＋Modular Monolith／Clean Architecture設計で実現。Redisによる24時間キャッシュやプロンプト工夫でコスト抑制・精度向上を図り、金額誤認識もアプリ側で補正。各明細のカテゴリ自動判定や高度なテスタビリティも実装し、商品リスト・合計金額など重要情報を正確に抽出可能。Dockerで簡単デプロイが可能です。
GoとGitHub Copilot Agentを活用した開発環境・ツール構成を用途別に詳しく紹介。言語はGo、DBはPostgreSQL＋ent ORM、ローカル開発はDocker、Make、airで効率化。ObservabilityはOpenTelemetry＋zap、API定義はprotobufやgRPCをbuf管理。品質管理にgofumpt・golangci-lint、DIやテスト補助にwire・go-cmp・mock採用。VS Code拡張やMCP/Serena連携も含み、開発作業やCIを自動化しています。
The Golang Patterns That Make High-Scale Systems Shockingly Simple
この記事は、Go言語の小さくシンプルな設計パターンがいかに高負荷・大規模なシステムを安定して運用できるかを説明しています。主に、コンテキストによる制御や小さなインターフェース、ワーカープールによる並行処理の制限、チャネルによるパイプラインとバックプレッシャー、優雅なシャットダウン、シャーデッドカウンタ、構造化ログなどが重要とされています。これらのパターンを組み合わせることで、システムの振る舞いを予測可能・テスト可能にし、「運用が楽」な高スケール処理を実現します。さらに、リソースリークの防止やパフォーマンス測定に役立つ簡易実装例・ベンチマーク方法も示されています。
筆者が「Goで作る自作コーディングエージェント nebula 開発入門」を写経しながらコーディングエージェントを実装し、ツールコールやシステムプロンプト、メモリ機能などエージェント実装の基本構成・設計パターンを学べて非常に良かったという感想を述べている。 実装では元資料から一部設計を変えたり、セッション一覧表示や編集時のdiff表示機能を追加しており、Goで普段開発していてAIエージェント作りに挑戦したい人にとって、10時間程度で一通り作りきれるおすすめ教材だと評価している。
その他プログラミング
Python
Pythonは、その高い可読性と直感的な設計を特徴とし、AI・科学・教育分野で広く使われています。Cの複雑さとシェルスクリプトの限界の間を埋めるために1991年にグイド・ヴァンロッサムが開発しました。Pythonはオープンソースで、開発者フレンドリーなエラーメッセージや豊富なライブラリにより、初心者にも扱いやすい言語として発展。AI分野ではNumPyやPyTorchなどの強力なエコシステムを持ち、LLM時代でも静的型付けの強化は不要とされます。安定性と進化を両立し、多様なバックグラウンドの開発者に支持され続けています。
Git
2024年7月、AWSはCodeCommitの重要度を下げる方針を発表しましたが、利用者からの強い要望を受け、再び一般提供（GA）を再開しました。CodeCommitはAWSの深い統合やセキュリティ機能が強みで、特に規制産業などで多く利用されています。今後はGit LFS対応（2026年Q1予定）やリージョン拡大も進める方針です。現在、料金やSLAは変更なく、新規利用も可能です。AWSは今後も積極的にCodeCommitを改善・強化していくとしています。
Git 3.0では新規リポジトリのデフォルトブランチ名が「main」となり、従来の「master」との設定不要になります。これはGitHubの変更などに続くもので、長年議論されてきました。3.0では他にもSHA-256によるハッシュ化や、macOS・Windows対応のストレージフォーマット改善、Rustの正式導入などが計画されています。リリースは2026年末頃が見込まれています。
ドキュメント
Markdownは広く使われているものの、技術コンテンツに適していない側面が多いと筆者は指摘しています。Markdownは手軽で可読性が高い一方、構造化情報が不足しており、AIやIDEによる機械的消費や再利用が困難です。同じ「Markdown」でも仕様が異なり、移植性や一貫性に問題が生じます。MDXなどの拡張も本質的には、構造的な表現力への欲求から生まれたものです。
一方、reStructuredTextやAsciiDoc、DocBook、DITAといったより高度なフォーマットは、セマンティックマークアップ（意味的な構造付け）に対応しており、多様な変換や再利用、機械解釈に強みがあります。小規模なドキュメントにはMarkdownで十分ですが、大規模・構造化・多チャンネル配信が必要な場合は、より表現力のあるフォーマットを選ぶべきです。Markdownはアウトプット用としては有用ですが、ソースとして使うと将来的な拡張性や再利用性で足かせになると警告しています。
感想:
まさかのXML復活か。
設計
巨大で高密度かつ変化し続ける医療ドメインを解きほぐすため、全員が“アーキテクト”として振る舞う開発・組織体制が重要だと説く講演資料です。従来のトップダウン設計や分断されたモノリス型から脱却し、境界調整コストを下げるモジュラーモノリスへの移行、コードの可視化とatomicな変更、組織の自律性・安定性・越境力の向上などを通じ、現場の全エンジニアが隣接領域への影響や例外パターンを捉えて継続的に改善できる環境構築を目指しました。正解のないアーキテクチャ設計を、学びと現場変化に応じてソフトウェア・組織両面で螺旋階段を登るように刷新し続けることの大切さが語られています。
ソフトウェア工学
本資料「ソフトウェアエンジニアリング入門」は、ビジネス現場におけるソフトウェア開発の基本と、それを支えるエンジニアリングの実践を体系的に解説しています。ソフトウェア開発では、顧客・品質・規模・納期という4つの課題のバランスを取り、生産性と品質を高めることが重要です。要求分析、プランニング、モデリング、コーディング、テスト、デプロイ、保守運用など一連の活動について、具体的な流れやポイントを丁寧に整理。また、チーム開発・コミュニケーションや品質保証（QA）の重要性、開発現場で起こる典型的な課題や改善サイクルも取り上げています。アジャイルやDevOpsなど現代的な手法も意識しつつ、現場で直面する不確実性や変化への対応力の重要性も強調。「技術」「プロセス」「人」という三要素が有機的にかみ合うことで、高品質なソフトウェアを継続して生み出す土台となることを示しています。各活動や概念を具体例に沿って理解しやすく説明し、新人エンジニアにも現場で役立つ実践的な知識を提供する内容です。
オブザーバビリティ
ABEMAは多様な視聴スタイルやイベント性の高い番組を提供しており、予測困難な負荷や障害に常に備える必要があります。このため、プラットフォームの信頼性設計とオブザーバビリティ基盤の強化を重視してきました。クラウドアーキテクチャでは、AWS・Google Cloudなどのマルチクラウド×マルチリージョン構成を採用し、Kubernetes・Service Meshなどによるマイクロサービス化・サービス間通信の信頼性向上を実現しています。統合監視基盤にはPrometheusやGrafana、OpenTelemetryをベースにDatadogやHoneycombといったSaaS連携も導入。特にTail-based Sampling手法を実践し、膨大なトレースデータの効率的な取得とコスト削減を図っています。SDKによる計装の統一やプロトコルのW3C化など、開発者体験の向上や拡張性にも配慮しながら、AIによる異常検知の活用も進めるなど、今後もさらなる規模拡大や未知の障害への対応を目指した取り組みが続いています。
エージェンティックコーディング・仕様駆動開発
Claudeの「Skills」は、特定の業務や分野向けにAIの能力を拡張できるカスタム命令です。SKILL.mdファイルに問題やタスク、トリガー条件、成功基準を明確に記載し、実装手順や例を構造化して書きます。スキルは5つのステップ（要件把握・名前、説明・手順作成・アップロード・実運用で改善）で作成します。曖昧さを避け、具体的な内容・トリガー・用途を記述すれば、強力で再利用性の高いスキルとなります。運用後は利用状況や改善点を反映します。適切な記述により、Claudeは複数スキルの同時活用や境界管理も可能となります。
このリポジトリは、GitHub Copilotの活用を強化するために、コミュニティが集めたカスタムエージェント、プロンプト、インストラクションなどを提供しています。各種プログラミング言語や用途ごとの特化エージェントやプロンプト、コーディング標準、ベストプラクティスをまとめており、作業効率化や品質向上に役立ちます。VS CodeやCopilot Chatへの導入も容易で、貢献も歓迎されています。利用や導入方法、セキュリティ情報も整備されています。
AI
Anthropic
Anthropicが公開した「Claude Opus 4.5」は、AI技術の新たな進化を示すフラッグシップモデルです。従来型と比較して、ソフトウェア開発・コーディング・エージェント連携・デスクトップ操作など幅広い業務において高い知能と効率性を発揮します。特に、複雑な課題への対応力や曖昧な指示の解釈、マルチシステム間のバグ修正、長期間に渡る自動化タスク実行などで強みがあります。
公式ベンチマークでは、Opus 4.5は他社AIや過去モデル(Sonnet 4.5など)を上回るパフォーマンスを記録。コード生成やリファクタリング、エージェント型ワークフロー、Excel自動化、3Dビジュアライゼーション、長文ストーリーテリング分野で大きな成果をあげています。加えて、トークン使用量が最大65%削減され、価格も従来より手頃になりました。
セキュリティ面では、最新のプロンプトインジェクション対策を施し、悪意ある入力への耐性が業界最高水準だと評価されています。ユーザー企業・開発者からは「効率的で信頼性が高い」「複雑なタスクにも柔軟に対応」「初回出力品質が向上」など高い評価が多数集まりました。
開発者向けには「努力パラメータ」や「コンテキスト圧縮」「高度なツール連携」など、多様な用途に応じた制御が可能に。プラットフォームやアプリも強化され、長大なチャットの自動要約、Excel・Chromeとの連携、複数セッション並行処理などが実現しています。
このモデルは、人間の技術力を超える場面も現れ、今後の仕事や社会への影響に関する調査も進行中です。Claude Opus 4.5は高性能と安全性・コストパフォーマンスを両立させたAIであり、多くの業界に新たな可能性をもたらします。
GoogleのAIに関するポッドキャスト「Release Notes」でCEOサンダー・ピチャイがホストのローガン・キルパトリックと対談し、Gemini 3の進化やGoogleのAI戦略について語りました。ピチャイ氏は、2016年に「AIファースト」戦略へとシフトし、現在のGemini 3やNano Banana Proといった研究やプロダクトにつながる重要な投資判断について振り返りました。対談では量子コンピューティングについても触れ、今後5年ほどでAIと同様に注目を集める分野になるだろうと期待感を示しています。最新の取り組みや将来のビジョンが語られる内容となっており、GoogleのAI技術への深い取り組みと今後の方向性がわかるエピソードです。
エンジニア
AIとお仕事
この記事は、AI全盛時代における「バイブコーディング」とソフトウェアエンジニアの役割について、t-wada（和田卓人）氏が問題提起しつつ、「自分の手でコードを書くこと」の意味を掘り下げた内容です。
バイブコーディングなどAI活用によって開発生産性が上がった結果、本来は大規模・長期開発で露呈していた技術的負債やレビュー負荷、セキュリティリスクといった問題が、短期間で一気に顕在化するようになったと指摘する。しかし、それらは昔から存在していた構造的な問題であり、AIという強力な道具によって「顕在化が極端に早くなった」だけだと位置付ける。バイブコーディングはむしろ非エンジニア層にとっての革命であり、裾野が広がるほどプロフェッショナルなソフトウェアに求められる品質やインパクトは一層高くなるため、「エンジニアのためのものではない」と述べている。
AI時代の課題にも、TDDやDDD、制約理論、プロダクトマネジメントといった既存のソフトウェアエンジニアリングの知見は有効であり、「AI」と従来のプロセスをどう融合させるかが鍵だとする。現状は人間がAIをマイクロマネジメントしている段階だが、今後はより宣言的に自走させる方向に進むため、その迷走・暴走を抑えるガードレールとして「バージョン管理・テスティング・自動化」という三本柱の重要性が増すと強調する。AIとの協業は「ウォーターフォールのプロセスを15分で回し続ける」ようなもので、AIとの対話を通じて仕様を詰め、タスクを分割し、TDDでサイクルを回すのが現時点のベストプラクティスだと述べている。
設計は最初から正しくはできず、コードを書くプロセス自体が理解を深め、設計へのフィードバックを生むため、人間が自分の手で書く「オーガニック・コーディング」をあえて行う価値があると語る。研究結果なども踏まえ、AIは人や組織の能力を増幅する鏡であり、AIから引き出せる性能は人間側の能力に比例するため、「労力は外注できるが能力は外注できない」として、AIで進捗を上げるだけでなく自分の能力向上にもAIを活用すべきだとする。AIによってプログラミングスキルが不要になるどころか、理解できないものをレビューできない以上、むしろスキルの重要性は増しているという立場だ。
また「ジュニアエンジニア不要論」については、AIで代替できるからという説明は表向きにすぎず、実態は「人員を減らしたいからAIを言い訳にしているレイオフの方便だ」と批判する。10年スパンで見れば、現在のシニア層の多くは引退しており、AIに指示を出しソフトウェアを育てる役割を担う人材を育てなければ立ち行かないと指摘する。若手は新しいツールへの感度やフットワーク、アンラーニングすべきものの少なさなど強みが大きく、「AIに全賭け」ではなく「半分賭ける」くらいのスタンスで選択肢を狭めず、自分の手と頭を動かし、変化そのものを楽しむメンタルモデルが重要だと結んでいる。
AI導入による人員削減は一時的な支出削減をもたらしますが、長期的には企業の成長に不可欠な人材育成の機会や中間管理職を担う人材パイプラインの断絶を招き、逆効果となるリスクがあります。若年層の雇用減少や重要なスキル獲得の困難も懸念されており、企業はAI活用と人材育成が両立するワークフローの再構築が必要です。また、AIと人が協働しながら成長できるスキルや仕組みづくり、社会的なチェック体制も求められています。
この記事は、『Noを伝える技術』の著者・飯沼亜紀さんに、「成果につながる断り方」について聞いたインタビューである。
人はその場の楽さからつい「Yes」と言いがちだが、「No」を避け続けると長期的には悪い結果を招くため、意志と設計をもって伝える必要があると指摘する。
飯沼さんは、「No」を直接ぶつけるのではなく、「今ではない」「その方法ではない」「このプロダクトではない」「ビジョンに合っていない」といった「Not」に分解して、何が変われば「Yes」になり得るかを共有することが建設的な対話につながると説明する。
また、「No」を言えずにモヤモヤするときは判断力不足ではなく「判断基準」が曖昧なことが多く、会社の戦略やKPIといった共通の基準に立ち返ることで、個人の好みではなくチームとして妥当なYes/Noを決められると語る。
重要なのは、YesにせよNoにせよ自分の意思決定に責任を持ち、その選択を「正解に近づける努力」をする姿勢であり、この本を通じてプロダクトマネージャーでない人にも、事業やプロダクトの成果から考える思考法を身につけてほしいと締めくくっている。
Discussion