🌈

ほぼ週間Go言語 2025年12月8日

に公開

今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。

Go言語

https://groups.google.com/g/golang-announce/c/8FJoBkPddm4/m/kYpVlPw1CQAJ?utm_medium=email&utm_source=footer

CVE-2025-61727で報告された、crypto/x509での脆弱性に対する対策です。


https://mackerel.io/ja/blog/entry/tech/auto-instrument-with-golang-ebpf

この記事は、Goアプリケーションに対してコードを書き換えずにOpenTelemetryのトレースを取得する「ゼロコード計装」を、LinuxカーネルのeBPFを用いて実現する方法と仕組みを解説した技術記事である。​

まずゼロコード計装の概要として、本来はアプリ側にOpenTelemetryの初期化やHTTPハンドラのラップなどのコードを組み込む必要があるところを、専用バイナリを実行するだけで計装できる点を説明し、その基盤としてLinuxカーネルの拡張基盤であるeBPFを紹介している。 eBPFプログラムを関数呼び出しなどのイベントにアタッチすることで、アプリを書き換えずに振る舞いを観測できることがポイントとされる。​

実装編では、Cで書いたeBPFプログラムをbpf2goでコンパイルしGo側から操作する構成をとり、関数開始・終了時にイベントをBPF Mapへ書き出し、Goの監視アプリがそれを読み取って実行時間などを表示する流れを示している。 さらに、Goではuretprobeがスタック書き換えと相性が悪くクラッシュを招くため、ELFバイナリ解析とディスアセンブルでRET命令位置を特定し、uprobeだけで開始・終了両方にフックするテクニックが紹介される。​

Go固有の難しさとして、M:NスレッドモデルによりスレッドIDではGoroutineを識別できない問題に対し、Arm64環境でR28レジスタに載るGoroutine構造体ポインタからGoroutine IDを取得し、BPF Mapのキーとして開始・終了イベントをひも付ける手法が説明される。 また、bpf_ktime_get_nsが返す単調増加クロックとOpenTelemetryが要求するUNIX時間とのずれを、Go側でCLOCK_MONOTONICを参照して補正し、正しい開始・終了時刻をトレースに設定する方法も扱う。​

後半では、HTTPサーバのAPM分析に必要なhttp.route・http.method・http.status_codeを、eBPFからnet/http.Requestやhttp.responseの内部構造をたどって取得する具体的な手順を解説している。 Goのstring内部表現(ポインタ+長さ)に合わせたコピー用マクロや、reflectなどで調べた構造体フィールドのオフセットを使ってルートパス・メソッド・ステータスコードを抜き出し、それらを属性としてMackerelにトレース送信するまでを通して実装している。 最後に、こうした技術要素を組み合わせることで、任意のGoアプリをeBPF経由でゼロコード計装し、OpenTelemetryトレースを送信できることと、OBIなどeBPFベース計装の動向に触れて締めくくっている。


https://zenn.dev/makocchan/articles/otel_sql_agent

この記事は、GoアプリケーションでGORMとsqlcommenterを使って、OpenTelemetryでSQLクエリの処理まで一気通貫で計装する方法を紹介しています。アプリからDBへのアクセスにはGORMを用い、go-gorm/opentelemetryプラグインで処理のトレースを取得し、sqlcommenterでSQLにトレース情報をコメントとして埋め込みます。Google CloudのCloud SQLとQuery Insightsを活用することで、アプリケーションとDBの処理を1つのトレースとして紐づけて可視化できるようになります。この方法により、ボトルネックの特定や改善策の提案が容易になり、無料で導入できる点もメリットです。


Building an AI-Powered App Entirely in Go: From Simple Prompt to Smart Pipeline | by Naveen Vandanapu | Nov, 2025 | Medium

https://medium.com/@vnaveen9296/building-an-ai-powered-app-entirely-in-go-from-simple-prompt-to-smart-pipeline-0d9be75d3d00

本記事は、「Goだけで本番運用可能なAIアプリは作れるか?」という問いから始まり、GenkitとGoを用いてウェルカムメッセージ生成アプリを5段階で進化させていくプロセスを紹介している。 初期版では、文字列入力から文字列出力のシンプルなフローを定義し、LLMに対して明示的なプロンプトとレスポンス処理を行う構成を採用している。 次に、言語・長さ・トーンなどを含む構造化入力を導入し、ユーザーがフォームから細かく条件を指定できるようにしてUXを向上させている。

三段階目では、LLMにJSONでの構造化出力をさせ、メッセージ本文だけでなくメタデータや属性情報を型付きで受け取ることで、LLMを型安全なAPIのように扱う手法を示している。 さらに本番向けとして、生成結果を別のLLMフローでモデレーションし、不適切な内容があればサニタイズ版と元テキスト、理由を併せて返す安全フローを構築している。 最終段階では、自然文の要望からパラメータを抽出し、生成・モデレーションフローへと連結する「スマートフロー」を実装し、ユーザーはただ説明を書くことで安全なメッセージを得られるようになっている。

技術的には、GinとGenkitによる型安全なフローオーケストレーションに加え、Gorilla CSRFをラップしてCSRF対策を行い、環境変数で設定可能なIP単位レートリミットをgolang.org/x/time/rateで実装している。 フロントエンドはTemplとDatastar、Tailwindのみで構成され、SSEを使ってJavaScriptなしでリアクティブUIを実現している。 デプロイはDockerとCloud Runを利用し、Gemini 2.0 FlashやOllamaをモデルプロバイダとして差し替え可能な構成で、実際のコードとデモはGitHubリポジトリとライブ環境として公開されている。 全体を通して、GoとGenkit、少数の周辺ツールを組み合わせることで、観測可能でテストしやすく、安全性に配慮したAIパイプラインを段階的に育てていくアプローチが強調されている。


https://zenn.dev/iyusuke/articles/b06400ce2b66c9

一般的にPython+LangChain/LangGraphが主流だが、既存システムがGo統一であること、goroutineや単一バイナリ、interface抽象などGoの特性がエージェント基盤と相性が良いことからGo採用を継続している。

当初は/api/ai/chat1本のエンドポイントにプロンプト構築・Tool登録・LLM呼び出し・SSEストリーミングを詰め込んだ一枚岩構成だったが、OpenAI SDKへの強い依存やToolとインフラの密結合、SSE前提設計、テストの書きにくさなどの問題が顕在化した。
これを解決するため、Model・Memory・Tool・Agent・StreamingといったAI固有の概念をpkg/ai配下に抽象として集約し、OpenAI依存コードはpkg/ai/openai、DBやToolRegistry実装はinfra層、アプリ固有Toolはapplication層へ分離している。

AgentはReActパターンを実装するReactAgentとしてModel/Memory/ToolRegistry/StreamWriterにのみ依存させ、HTTPやSSE/WS/gRPCの詳細はPresentation層の実装に閉じ込めた。
Application層ではUsecaseがModelFactory・Memory・Tool群を組み合わせてAgentを組み立て、Handlerは認証やバリデーション、SSEWriter生成に専念する構造としたことで、モデル切り替えやメモリ実装変更、ストリーミング方式変更、Agent単体テストが容易になったとしている。

https://zenn.dev/iyusuke/articles/11d3a6815cecef

本記事では、Goとクリーンアーキテクチャを用いてAIエージェント基盤を再設計し、エージェント・スレッド・メッセージを中心としたスレッド型チャットと、その永続化・実行フローをどのように整理したかが解説されている。

まず、Agents / Threads / Messagesという3つのドメインモデルを定義し、Repositoryインターフェースを介してPostgreSQLに保存する構成とすることで、会話履歴をmessage_indexで順序管理しつつ、将来の編集や最適化に備えたDB設計を行っている。 また、Memoryインターフェースの実装をInMemoryからPostgreSQL版に差し替え、メッセージの可視性フラグを導入することで、ユーザー向けUIと開発者向けログで表示範囲を柔軟に切り替えられるようにしている。

アプリケーション層では、AgentRunUsecaseなどのユースケースを定義し、ToolRegistry・Memory・ModelFactoryを組み立ててエージェントを実行するロジックを集約し、HTTPハンドラはGinを用いた薄い層として認証やJSONバインディング、SSEレスポンスに専念させている。 モデル依存はpkg/ai/openai配下に閉じ込め、ModelFactoryインターフェースを介してOpenAIクライアントを隠蔽することで、将来のマルチプロバイダ対応やローカルLLMへの差し替えを容易にしている。

実装上のハマりどころとして、ユーザーメッセージが二重保存される問題や、ストリーミング中のassistantメッセージが保存されない問題が挙げられ、メッセージ保存の責務をエージェント側に集約することや、SSEで受け取ったトークンを集約して最終回答として一括保存する工夫で解決している。 結果として、従来の「ハンドラにロジック直書き」構成と比べて、モデル差し替えやツール追加、RAGや複数モデル対応、MCP連携といった拡張を、既存のGoバックエンドと同じ抽象化レイヤーの中で長期運用しやすくなったと述べている。


https://qiita.com/someone7140/items/8187fdc9a004d0ba942d

この記事は、GoのORMライブラリGORMのコードジェネレータGenを使い、Upsert時に主キー衝突が起きたとき主キー以外のカラムを一括更新する方法を紹介しています。 使用環境はgorm.io/gen v0.3.27とPostgreSQLで、主キー付きモデルを定義し、clause.OnConflict{UpdateAll: true} を指定して Create を実行することで、主キーを衝突キーとして他の全カラムを更新する実装サンプルを示しています。


その他プログラミング

.NET

https://blog.jetbrains.com/dotnet/2025/12/02/dotinsights-december-2025/

JetBrainsの「dotInsights」2025年12月号では、.NET 10やC# 14に関する最新情報、移行時に注意すべき重大な変更点、また新しいリフレクションAPIやC# 14のnullable関連機能などが紹介されています。また、.NETアプリのローカライズ方法や、ReSharperとRider 2025.3の最新版のリリース情報、F# Advent Calendarなど開発者向けの楽しい話題も取り上げられています。JetBrains RiderやReSharperは.NET 10、C# 14にいち早く対応し、生産性向上やパフォーマンス改善が進んでいます。


Python

https://pythoninsider.blogspot.com/2025/12/python-3141-is-now-available.html

Python 3.14.1は3.14系の最初のメンテナンスリリースで、3.14.0から約558件のバグ修正やビルド改善、ドキュメント更新が含まれます。 主な新機能として、フリースレッド版Pythonの正式サポート、アノテーション評価の遅延、テンプレート文字列リテラル、標準ライブラリでの複数インタプリタやZstandard圧縮サポート、改善されたエラーメッセージ、HMAC実装の追加、非同期タスクのインスペクション用CLIやpdbのリモートアタッチ対応などがあります。 また、Sigstoreによる検証への移行、macOS/Windows向け公式バイナリへの実験的JIT同梱、Android向け公式バイナリ提供、Windowsでは新しい「Python install manager」導入などビルド・配布形態にも変更があります。


https://pythoninsider.blogspot.com/2025/12/python-31310-is-now-available-too-you.html

Python 3.13系の10番目のメンテナンスリリースであるPython 3.13.10が公開されたことを告知する記事です。 このリリースでは3.13.9以降の約300件のバグ修正やビルド改善、ドキュメント更新が含まれており、ダウンロードページやオンラインドキュメント、リリーススケジュールPEP 719など関連リソースへのリンクが案内されています。また、バグ報告先のGitHubリポジトリやPython開発・コミュニティへの寄付のお願いが記載され、最後に多くのボランティアへの謝意とPython Software Foundationを通じた支援の呼びかけで締めくくられています。


https://gihyo.jp/article/2025/12/django-6-0

Django開発チームは2025年12月3日に、WebアプリケーションフレームワークDjango 6.0をリリースしました。

このバージョンでは、コンテンツセキュリティポリシー(CSP)のサポートが追加され、XSSなどの攻撃からWebアプリケーションを保護する仕組みを組み込みツールで適用・監視できるようになりました。また、Djangoテンプレート言語が**部分テンプレート(Template Partials)**に対応し、コンポーネントを分割せずにモジュール化されたテンプレート作成が可能になりました。

さらに、HTTPリクエスト/レスポンスサイクル外でコードを実行するためのTasksフレームワークが組み込まれ、メール送信などのバックグラウンドタスクをオフロードできるようになっています。メール処理ではPython 3.6以降の最新のメールAPIを採用しました。

Django 6.0がサポートするPythonバージョンは3.12、3.13、3.14です。


Excel

https://techcommunity.microsoft.com/blog/excelblog/congrats-to-the-winners-of-the-2025-mecc--mewc/4475228

2025年のMicrosoft Excel World ChampionshipとCollegiate ChallengeがラスベガスのHyperX Arenaで開催され、世界各地から選手が集結し、新たなExcel eスポーツチャンピオンが誕生した。学生チーム、個人、一般の世界大会、Financial Modeling World Cupそれぞれで優勝・入賞者が発表され、Excelコミュニティの国際的な広がりと競技としての盛り上がりが強調されている。

ExcelはeSports。


ツール

https://zenn.dev/mozumasu/articles/mozumasu-cli-beginner

この記事では、CLI(コマンドラインインターフェース)初心者が最初に知っておきたい基本的なTipsを紹介しています。主な内容として、シェルの基本操作、頻繁に使うコマンド(ls, cd, mkdir, rmなど)、パイプとリダイレクトの使い方、シェルスクリプトの作成、そして効率的なキーボードショートカットについて解説されています。特に、LinuxやmacOSのユーザー向けに、環境変数の設定やエイリアスの活用も触れており、作業の効率化に役立つ知識が詰まっています。また、トラブルシューティングやよくあるエラーへの対処法も簡単に紹介されており、CLIを初めて触る人にとって実用的な情報が多数載っています。

感想:

Macでのmanページの日本語化方法が書かれていて助かった。


UI/UX

https://tech.findy.co.jp/entry/2025/12/04/070000

この記事では、ファインディCTOが新規プロダクト「Findy AI+」のデザインシステムをコードで管理する理由について述べています。片手間ながら1人で2〜3週間かけて設計した経験から、コードによる管理が今後不可欠だと感じている点や、Figmaとコードの関係性、AI時代における開発フローの変化についても触れています。


https://tech.dentsusoken.com/entry/20251203/Figma_Makeの使いどころ

この記事では、Figma Makeという新機能の検証結果が紹介されています。Figma Makeはプロンプトを使ってUIデザインを自動生成する機能で、簡易的なプロンプトと詳細なプロンプトの両方で精度を比較しています。より具体的な情報を入力したプロンプトでは、生成されたデザインの品質が向上しました。また、使いどころとしてプロトタイピングやアイデア出しに適しているとされています。


エージェンティックコーディング・仕様駆動開発

https://www.publickey1.jp/blog/25/aiaitypescriptgithubai.html

この記事では、GitHubがAIによる開発支援が進むことで、プログラミング言語の選定に変化が生じると予測しています。特に、AIの「ハルシネーション」(誤った出力)が少ない型付け言語、例としてTypeScriptが注目されると述べています。AIがコード生成を補助する中で、バグやエラーの発生しやすい動的型付け言語よりも、静的型付け言語の採用が増える可能性があるとしています。


https://zenn.dev/loglass/articles/c356dbc3062137

この記事は、AIに「レビューと改善を3回繰り返して」と指示するだけで、文章やコードの品質を大きく向上させられる「セルフレビュー反復」という手法を紹介している。 生成フェーズとレビューフェーズを意図的に分離し、2〜3回の反復で段階的に精度を高める原理は、Self-Refine論文などで有効性が示されており、ブログやコード生成において具体的なプロンプト例と、レビュー観点を細かく指定する工夫が有用だと解説している。


https://tech.findy.co.jp/entry/2025/12/06/070000

この記事は、Claude Codeによる開発支援で実際に起きた「やらかし」事例と、その再発防止のためのCLAUDE.md運用術を紹介している。​

筆者は、コードレビュー確認を依頼した際に「確認して対応して」と曖昧に指示した結果、対応予定のないレビューコメントへの返信が自動投稿されてしまった事例を挙げ、原因はプロンプトの書き方にあったと振り返る。 また、別タスクで作ったバックアップファイルが、Claude Codeが git add -A を実行したことで意図せずPRに含まれてしまった事例も紹介し、ステージング内容の未確認が問題だったと分析している。​

これらを受けて、曖昧な指示が来たときは作業を進めず質問すること、意図しない挙動があったときは原因と再発防止策をAI自身に検討させてCLAUDE.mdに反映すること、といった運用ルールを整備したと説明する。 最終的には「コミット前にステージングされたファイルを確認する」「意図しないファイルが含まれていないか確認する」といった具体的なチェック手順をCLAUDE.mdに明記し、AIエージェントとともに失敗から学び成長していく姿勢の重要性を強調している。


AI

DeepSeek

https://api-docs.deepseek.com/news/news251201

DeepSeek-V3.2は、エージェント向けに設計された「推論特化」モデルであり、V3.2-Expの正式な後継としてApp・Web・APIで利用可能になりました。 V3.2は日常利用向けに推論性能と出力長のバランスを取ったGPT-5クラスの性能を持ち、V3.2-SpecialeはGemini-3.0-Proと競合する最大級の推論能力を備え、IMOやICPC等の国際コンテストで金メダル水準の結果を達成しています。 V3.2では1,800以上の環境と8.5万件超の複雑な指示から合成したエージェント用データに基づき、「Thinking in Tool-Use」と呼ばれる思考統合型ツール実行が初めてサポートされ、通常モード/Thinkingモード双方でのツール利用が可能です。 APIではV3.2が従来と同じ利用パターンで提供される一方、V3.2-Specialeは2025年12月15日までの一時的な専用エンドポイント経由でAPIのみから利用でき、ツールコールは無効化されています。 また両モデルはHugging Face上でオープンソースとして公開され、詳細な技術レポートも提供されています。


OpenAI

https://www.theinformation.com/articles/openai-ceo-declares-code-red-combat-threats-chatgpt-delays-ads-effort

OpenAIのCEO、サム・アルトマン氏は、社内で「コードレッド」を宣言し、ChatGPTの強化に全社的なリソースを集中させる方針を示しました。これは、Googleなど他社のAI技術の進展に対する危機感からで、ChatGPTの競争力維持を最優先とするため、広告導入など他のイニシアティブは延期されます。社内では新たな開発チームやエンジニアが迅速に投入され、AIの安全性や性能改善が急務となっています。


https://cookbook.openai.com/examples/gpt-5/gpt-5-1-codex-max_prompting_guide

OpenAIの「GPT-5.1-Codex-Max Prompting Guide」は、高性能なエージェントコーディングモデルであるGPT-5.1-Codex-Maxの性能を最大限に引き出すためのプロンプト設定とツールの利用方法を解説しています。

このモデルは、GPT-5.1-Codexの性能を維持しつつ、思考トークンを約30%削減し、より高速かつトークン効率が向上しました。また、長時間のタスクを自律的にこなす高い知能と、コンパクション(圧縮)機能による長時間のエージェント作業のサポートが特徴です。

ガイドでは、「自律性(Autonomy)」、「ツールの適切な利用(Tool Use)」、**「コードの品質(Code Implementation)」**を重視した推奨スタータープロンプトが示されています。具体的には、既存のツールを優先し、作業計画を立て、小さな編集ではなく論理的な編集をバッチ処理し、ユーザーの指示なしに途中で計画やステータスを伝えないなど、シニアエンジニアのように振る舞うことが求められます。また、フロントエンドタスクにおいては、定型的なデザインを避け、意図的で大胆なインターフェースを目指すことなど、各作業における具体的な原則が詳しく説明されています。


Anthropic

https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone

Anthropicは、JavaScriptランタイム「Bun」を買収し、Claude Codeの開発基盤をさらに強化すると発表しました。 Claude Codeは2025年5月の一般公開から6か月で年換算売上10億ドルに到達し、NetflixやSpotifyなど大手企業に採用されています。 Bunは高速なオールインワンJSツールチェーンとしてClaude Codeのインフラを支えてきた実績があり、今後もMITライセンスのオープンソースとして継続開発され、Claude Codeの性能や安定性、機能拡張に活用されます。


AWS

https://kiro.dev/blog/introducing-kiro-autonomous-agent/

Kiro autonomous agentは、開発者やチームのための「常駐型フロンティアエージェント」で、従来のIDE/CLIアシスタントのようなセッション依存ではなく、タスクやリポジトリをまたいで文脈と学習内容を保持し続ける点が特徴です。
個人ユーザーはKiro Pro系プランのプレビューとして利用でき、タスクごとにサンドボックス環境を自動構築し、リポジトリのクローン・要件分解・サブエージェントによる実装と検証・PR作成までを非同期に実行します。

できること

  • 複数リポにまたがるライブラリ更新やリファクタリングなどを「1つのタスク」として扱い、自動で影響リポの特定・変更・テスト・PR作成まで行う。
  • 最大10タスクを並列実行し、開発者はチャット経由で要件の追加や方針の修正などを行える。
  • GitHub issue にラベルやコマンドを付けることで、直接タスクとしてエージェントに割り当てることも可能。

学習とチーム機能

  • コードレビューでの指摘(エラーハンドリング方針や命名規則など)を継続的に学習し、以後のタスクに自動適用する。
  • チーム版では、複数人のレビュー・仕様・議論内容を共有メモリとして統合し、Jira・Slack・Confluenceなどと連携してスタック全体の変更を一貫した基準で進められる。

セキュリティと環境

  • 各タスクは隔離サンドボックスで実行され、ネットワークアクセスレベルやドメイン許可リスト、環境変数・シークレットを細かく制御できる。
  • Devfile や Dockerfile を自動検出して開発環境を構成し、存在しない場合もプロジェクト構造から必要な依存やビルド手順を推定する。

https://yamdas.hatenablog.com/entry/20251201/beyond-vibe-coding

『バイブコーディングを超えて AI時代を生き抜く開発者の未来』は、アディ・オスマニ著で、オライリー・ジャパンから2025年末に刊行される邦訳本です。原書『Beyond Vibe Coding』は同年8~9月に刊行され、AI時代の開発者に求められる新たな姿勢や技術について論じています。邦訳は原書刊行からわずか半年で出たことで、オライリー系では非常に早いペースとされています。


https://aws.amazon.com/jp/blogs/news/introducing-powers/

Kiro powers は、MCP ツール群とフレームワーク固有のノウハウを「power」という単位にまとめ、必要になったときだけ動的に読み込む仕組みで、エージェントのコンテキスト肥大とセットアップの煩雑さを解消する仕組みです。​
Stripe や Supabase など特定ドメインごとに POWER.md・MCP 設定・ワークフロー別ステアリングをバンドルし、キーワードに応じて関連 power だけを有効化するため、トークン消費を抑えつつベストプラクティスに沿ったコード生成や操作が可能になり、Kiro IDE を起点に今後は他 IDE/エージェントにも展開されることを目指しています。


JetBrains

https://blog.jetbrains.com/ai/2025/12/bring-your-own-ai-agent-to-jetbrains-ides/

JetBrainsは、IDEとAIエージェントをつなぐ共通規格「Agent Client Protocol(ACP)」のベータ対応を25.3系リリース候補で導入し、任意のACP対応エージェントをJetBrains製IDEのAIチャットから利用できるようにした。
これにより、開発者は好みのエージェントを選択してIDE内で利用でき、エージェント開発者はIDEごとの個別実装なしに統合可能となる。 今後はUX改善、ACPエージェントのレジストリ構築、リモートエージェント対応、MCPツールチェーン提供などを進め、よりオープンで拡張性の高いエージェントエコシステムを目指している。


論文・その他

https://engineering.dena.com/blog/2025/12/llm-study-1201/

本記事は、DeNAのAIエンジニアが社内向けに実施した「LLM勉強会」の内容と、そこで使用したスライド・ハンズオン用コードを一般公開したレポートです。​

対象は新規AIプロダクトを担当するPdMやエンジニアで、LLMの基礎(Next Token Prediction、Instruction Tuning、Reasoning、プロンプトエンジニアリング)から、API呼び出しや構造化出力、複数LLMの組み合わせといった実践的なハンズオンまでを、約3時間の講義+演習形式で学べる構成になっています。 後半では、プロダクト開発で重要となるデータ活用、ファインチューニングと強化学習の違い、コンテキストエンジニアリングやRAG、ReAct・Reflexionといったエージェント手法を解説し、マルチモーダル入力、Tool Calling、Embeddingによる類似度計算、Deep Researchの設計、n8nやLangSmithを用いた演習も行われました。​

勉強会にはオンライン・オフライン合わせて52名が参加し、新規AIプロダクト配属時の研修に組み込みたい、AIエンジニアの仕事理解が進んだといったポジティブなフィードバックが寄せられています。 スライドとソースコードはそれぞれ専用サイトとGitHubで公開されており、社外秘部分を除きほぼすべての内容が誰でも再現できる教材として提供されています。


https://yamdas.hatenablog.com/entry/20251201/netscape-and-microsoft

1990年代半ば、インターネットの普及に貢献したNetscapeは、Windowsに同梱されたInternet Explorerとのブラウザ戦争で敗れ、やがてAOLに買収されました。この戦いは、OSとブラウザの統合による市場支配を巡る激しい競争であり、結果としてマイクロソフトが勝利しました。

その後、インターネットの主戦場は検索エンジンへ移り、Googleが市場を支配するようになりました。Googleは2014年にDeepMindを買収し、AI分野でもリーダーシップを発揮しています。現在、OpenAIとGoogleが生成AI分野で覇権争いを繰り広げており、これはかつてのブラウザ戦争の再来とも言われています。

ブラウザ戦争から検索、そしてAIへと主戦場が移り変わる中、技術とプラットフォームの統合が市場支配の鍵となっていることがわかります。


https://wired.jp/article/wired-innovation-award-2025-takashi-ikegami/?utm_source=twitter&utm_medium=social&utm_campaign=dhtwitter&utm_content=null

WIRED Innovation Award 2025の受賞者である池上高志氏は、人工生命の研究者として、生命の本質について深く探求しています。彼は、世界は生命に満ちているが、人間が生命を無理に理解しようとすると、むしろその本質はすり抜けてしまうと語ります。池上氏の研究は、人間中心の視点を離れた、生命そのものの在り方や、人と関係なく動くシステムの未来像に焦点を当てています。彼が注目するのは、人工生命が人間とは別の存在として自然に息づき、独自の進化や意思を持つ可能性です。この視点は、AIやロボットだけでなく、すべてのシステムやモノが「生命化」する未来への示唆とも言えます。池上氏は、科学技術の発展が人間と生命の境界を曖昧にしていく中で、その本質をどう捉えるかを問いかけています。


https://www.digital.go.jp/news/1b093bba-a4c8-4001-8a92-ff3667a69198

デジタル庁は、行政向け生成AI環境「源内」で試用する国内開発LLMを公募し、行政実務の質向上と省力化を図ることを目的としています。​

人口減少などによる担い手不足を背景に、日本語や行政文書に最適化された国内開発LLMを活用し、2026年度に他府省庁展開や試験導入、評価・検証を行います。 対象は国内で開発された自然言語系LLM/SLMで、ガバメントクラウド上で機密性2情報を扱えるセキュリティ、安全性評価、2026年度中の無償提供などが条件です。 公募期間は2025年12月2日から2026年1月30日までで、評価結果を踏まえ、2027年度以降の本格提供やライセンス契約を検討するとしています。


エンジニア

https://www.oreilly.co.jp/books/9784814401215/

この本は、人気テックニュースレター著者が、MicrosoftやUberなどの大手企業での経験をもとに、ソフトウェアエンジニアのキャリアロードマップを体系的に解説しています。新人からシニア、テックリード、スタッフエンジニアまでの各ステージに必要なスキルや知識を網羅し、実用的なアドバイスを提供。日本語版限定で著者インタビューも収録されています。

感想:

全プログラマは読め!

とくに、経験の浅いエンジニアは、第一部と第二部は端から端まで熟読しよう。特に本書の中でも強調されていますが、仕事を完遂することが大事です。決められた期限までに仕事を完遂していくことで、上司やチームの仲間から信頼を得ることが出来ます。まず、信頼を得ないと、話を聞いてもらえませんし、それによってどんどん仕事がやりにくくなってしまいます。


AIとお仕事

https://techblog.recochoku.jp/12487

AI時代に大手企業が新卒採用を停止する流れが広がっているが、業界全体で若手の育成を辞めると将来エンジニアが不足する可能性がある。新卒採用には時間がかかるため、一度辞めてしまうと若手の補充に1~2年のラグが生じ、業界全体のバランスが崩れる。そのため、新卒採用を完全にやめるのではなく、採用数を減らす程度にとどめるべきであり、業界全体で若手の育成を継続する必要があると指摘している。


https://tech-blog.tabelog.com/entry/advent-calendar-20251205

この記事は、AI活用が進む中でコードレビューの役割を「品質確認」から「ナレッジ蓄積とチーム成長の場」へと再定義しようという提案をしている。​

まず、生成AIの導入により技術的なバグやパフォーマンス問題が減り、従来型の技術的指摘が少なくなった一方で、その時間をチームの知識共有や個人のスキル向上に充てられるようになったと述べている。 これを踏まえ、AI時代のコードレビューでは「生成されたコードだけでなくプロンプトもレビューすること」と「実装意図と背景を明確化すること」の2点へのシフトが重要だと主張する。​

プロンプトレビューについては、GitHub上でAIとの対話やプロンプトを見える形にしておき、レビュアーがより良いプロンプトや対話の進め方をフィードバックすることで、AIとの対話スキル・生成コード品質・再現性の向上、そしてチームとしてのナレッジ蓄積につながると説明している。 実装意図の明確化では、AI生成コードであってもビジネスロジックや設計判断の背景をコメントや説明として残し、レビュアーは「なぜこの実装か」を積極的に問い、将来の改修時にも理解しやすい状態にすることが求められるとしている。​

また、ツール選定において「レビューのしやすさだけを基準にしない」ことも強調する。 GitHub上で対話できるツールはプロンプトレビューやナレッジ共有に向く一方、エディタ内対話ツールは大規模機能追加など細かく詰める作業に適しており、作業形態に応じてレビュー観点を変えるべきだとしている。 最後に、こうした取り組みを継続することで、チーム全体のナレッジが蓄積され、個人のスキルも高まり、コードレビューが組織の学習サイクルを回す重要な時間になっていくと結んでいる。


https://syu-m-5151.hatenablog.com/entry/2025/12/06/060208

この記事は、Rustの所有権・非同期処理・トランザクション・キャッシュなどの具体例を通じて、「類推(アナロジー)は理解の強力な足場だが、同時に誤解と判断ミスの源にもなる」という両義性を論じたエッセイです。 類推によって抽象概念への入り口を開き、学習・コミュニケーション・創造性を加速できる一方で、「本の貸し借り」「料理」「銀行振込」「辞書」といった日常的な比喩を引きずりすぎると、Rustのライフタイムや借用、非同期下のMutex・デッドロック、分散システムのトランザクションと外部API、キャッシュ無効化やレースコンディションの本質を取り違えるプロセスが丁寧に描かれます。 筆者は、表面的類似と構造的類似の混同、ベストプラクティスや他社事例の安易な当てはめが設計や組織運営を誤らせると指摘し、「類推は仮説であって証明ではない」と強調したうえで、類推のレベルを意識すること、反例探索と実測で検証すること、複数の類推を比較し言語化することを通じて「類推で入り口を作り、判断は具体で行う」態度を提案します。 最後に、間違った類推を手放す心理的な難しさにも触れつつ、「類推をやめるのではなく、疑い、修正し、必要なら断つ勇気を持て」というメッセージで締めくくられています。


株式会社BALEEN STUDIO

Discussion