今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
今週も盛りだくさんで長くなってしまいました。
Go言語
GoLand 2025.3は、コード品質と開発体験を強化する多数の改善を含むメジャーアップデートです。
オンザフライなリソースリーク検出、Terraformプラグインの同梱とKubernetes周りの操作性向上により、インフラとGoコードを一体的に扱いやすくしています。
AIまわりでは、Junieに加えてClaude AgentがIDE内に統合され、チャットでエージェントを切り替えながら支援を受けられるマルチエージェント環境が提供されます。
さらに今後はOpenAIやAnthropicなど自分のAPIキーを持ち込めるBYOK対応や、IDE内でAIクレジット残量や更新日を確認できるクォータ可視化も予定されています。
開発体験面では、単一ファイルをプロジェクト不要で素早く開けるようになり、golangci-lint v2のgolangci-lint fmt対応とデフォルト有効化により、フォーマットとLintを一元管理できます。
UIは新デフォルトテーマ「Islands」に刷新され、タブの視認性やコントラストが改善されました。
パフォーマンス面では、大規模プロジェクトを想定したインデックス処理の改善や低メモリ警告の削減などにより、長時間・大規模開発時の安定性とレスポンスが向上しています。
その他として、不要なelseを検出するインスペクションやgo.mod内ディレクティブブロックの折りたたみなど、小さな生産性向上も多数含まれています。
この記事は、Go 1.25 で実験的に導入され、1.26 で本格導入が期待される encoding/json/v2 の変更点を、公式テストコード v2_diff_test.go をもとに 15 項目で解説したものです。 主な内容は、JSONタグの大文字小文字をデフォルトで区別すること、omitempty が「Go の空値」ではなく「JSON の空値」を基準に省略するよう変わること、string オプションが数値専用となり複合型内の数値にも再帰的に適用されること、nil スライス・マップを null ではなく [] / {} として出力することなどです。 そのほか、固定長配列の長さ不一致をエラーにすること、[N]byte を Base64 文字列として扱うこと、HTML エスケープの廃止や無効な UTF-8・重複キーをエラー扱いにすること、null や複合型のマージ動作の整理、time.Duration の文字列表現対応、公開フィールドを持たない構造体の marshal をエラーにする変更などが紹介されており、JSON としての正しさ・一貫性・パフォーマンス向上を意図したアップデートであるとまとめています。
この記事は、Go 1.23で導入されたiter.Seqとiter.Seq2によるイテレータの基本と、エラーを伴う現実的な反復処理パターンを解説している。 従来のチャネル＋goroutineによるアダプタは複雑で非効率だとし、iter.Pull/Pull2を使って「プッシュ型」イテレータをRecvメソッド中心の「プル型」ストリームインターフェイスへ安全かつシンプルに橋渡しする方法を示し、このパターンをスタイルガイドに入れる価値があると結論づけている。
この記事では、Goで「s秒ごと」のように定期実行するワーカーを、処理中タスクをできるだけ壊さずに安全停止（graceful shutdown）させる実装パターンを解説している。 time.Ticker＋selectで素朴に書くと、タスクがintervalより長い場合にコンテキストキャンセル後も次のタスクが走りうるという落とし穴があり、ticker.C側が選ばれたときにもctx.Err()を必ず確認する実装に修正している。 さらに、タスク完了待機が無限に伸びないよう、タスクを別goroutineで実行し、doneチャネルとshutdownTimeout付きのtime.Afterを組み合わせて、一定時間だけ完了を待ってからキャンセルする仕組みを導入する方法を示している。
本記事は、本番環境でのみ発生する gRPC Federation 利用サービスでの Goroutine 急増とサービス停止問題について、原因特定と対策に至るまでの約2か月間の調査・改善の記録である。
WebAssembly プラグインを単一インスタンスかつロック付き直列実行で評価していたため、プラグイン評価部のロック待ちが集中し、Goroutine が滞留していることが Cloud Profiler や pprof による調査で判明した。 さらに調査を進める中で、ホストからの強制 GC 要求をきっかけにプラグイン内処理がハングし、その結果プラグインインスタンス全体が応答不能になることが示唆され、通信方式の見直しや GC 経路の変更、インスタンス自動復旧（タイムアウト付きフォールバック）などのワークアラウンドが導入された。 最終的な根本原因は、WebAssembly 側でネットワークソケットを扱うために利用していた wasi-go ライブラリの PollOneOff 実装で、unix.Poll に負のタイムアウト値が渡されイベント待ちから復帰できなくなるバグであり、当該ライブラリの修正適用によって問題は解消された。 記事では、初期のプロファイリング結果に既に手がかりが含まれていたことへの反省や、本番環境での pprof 常設やデバッグログのフラグ制御、プロファイル・コアの永続化基盤整備の重要性なども振り返られている。
この記事では、Goでのファイル・HTTPレスポンス・DB結果などのリソースを閉じ忘れるとメモリやFD、接続が枯渇してサービス障害につながること、そしてGoLandの新しい「リソースリーク解析」がそれをIDE上で早期検出できることを解説している。
まず、io.Closerを実装するファイル、ネットワーク接続、*http.Response、*sql.Rowsなどを閉じ忘れると、GCでは解放されない外部リソースが溜まり、徐々に性能劣化やクラッシュを引き起こすと説明する。 予防策として、deferで早めにCloseを登録すること、ループ内deferを避けること、負荷試験でリークをあぶり出すこと、golangci-lintなど静的解析ツールを使うことが推奨される。
具体例として、HTTPレスポンスボディを閉じないコードが大量リクエスト下でTCP接続を使い潰し「can’t assign requested address」になるケースと、rows.Scanエラー経路で*sql.Rowsを閉じないためにDB接続プールを枯渇させるケースを示し、どちらもdefer resp.Body.Close()やdefer rows.Close()で解決できると示している。 GoLand 2025.3 のリソースリーク解析は、io.Closerを実装する任意の型に対して制御フロー全体を追跡し、「閉じられない可能性」をリアルタイムにハイライトすることで、初心者・熟練者ともにリークを早期に防げると結論づけている。
この記事は、GoのWebフレームワーク「Gin」が標準ライブラリよりも大きく複雑で、長期的には有害だという批判的な論考です。
筆者は、HTTP自体はシンプルであり、Go標準のnet/httpは少ないコード量と小さいAPIサーフェスでその構造を素直に表現していると評価します。
一方Ginは、サーバー機能、ルーティング、テンプレート、QUIC対応など多くの関心事を1つの巨大なAPIに詰め込み、膨大な依存関係とコード量（数十万行・数十MB）をプロジェクトに持ち込むと指摘します。
さらに*gin.Contextなどの型はメソッドが過剰に多く、複雑さの割に抽象化は弱く、バイナリサイズや初期化コストの増大、不要なフォーマット・プロトコル（複数のJSONライブラリやHTTP/3など）の強制読み込みを招くと批判します。
また、人間は退屈な技術選定を雑に済ませがちで、「とりあえず検索して最初に出たGinを選ぶ」ような意思決定が依存性地獄とライブラリロックインを生むとも述べます。
筆者はGinを絶対使うなとは言わないものの、「小さく、標準に近く、置き換えやすい」ライブラリや標準ライブラリを優先し、Gin的な巨大・過剰・一体型の設計には強い警戒心を持つべきだと結論づけています。
Bill One/Contract One の認証基盤に TOTP 向けリカバリーコード機能を Go で内製実装した際の検討内容をまとめた記事です。 NIST SP 800-63B と OWASP Cheat Sheet を基に、64bit 以上のエントロピーを持つコード生成（crypto/rand による CSPRNG、36 種類×24 桁）、Argon2id＋PHC String Format でのハッシュ保存、スロットリングや ConstantTimeCompare による検証・タイミング攻撃対策などの要件と実装方針を整理しています。
この記事では、AnthropicのClaude CodeをCLIから自動制御し、タスクファイルに書いた指示をもとに実装・テストまで自律的に進めるGo製ツール「Sleepship」を紹介している。 手動でプロンプトを入力する煩雑さや夜間に作業が進まないといった課題を解消し、「寝ている間にタスクを実装しておく」開発体験を目指している。
Sleepshipはタスクファイルからの一括実行、失敗時の自動リトライ、調査→計画→実装を自動で分解して進める再帰実行機能、履歴と統計の記録、エイリアスや環境変数による設定といった機能を備える。 実装面では、Goのexec.CommandでClaude Code CLIを子プロセスとして呼び出し、エラー内容を含めたプロンプト生成により自動リトライや段階的な開発フローを成立させている。
チーム開発向けには、タスクテンプレートや.sleepship.tomlをリポジトリで共有し、共通のエイリアス・タスク構造で生産性を上げる運用方法も提案されている。 FAQでは、利用にはClaude CodeのライセンスとCLI環境が必要なことや、タスクファイルの配置・中断後の再開方法など、実務での導入を意識したポイントが整理されている。
この記事は、Go 1.26 で導入予定の新パッケージ runtime/secret と、その中核関数 secret.Do の仕組みと実用性を検証した内容である。 secret.Do は渡された関数の実行中に使われたレジスタやスタック領域を終了時に消去し、core dump などからパスワードなどの秘匿情報が読み取られにくくすることを目的としている。 Linux/amd64・arm64 のみ対応で、グローバル変数やヒープは対象外だが、スタックは systemstack と eraseSecrets により戻り先直前までゼロクリアされる。 記事では、通常のコードと secret.Do 使用コードの core を比較し、panic や runtime.Goexit、map や runtime.KeepAlive など意地悪なパターンでもスタック上の秘匿情報が漏れにくいことを確認している。 ただし外部メモリを直接書き換えるケースやヒープは守備範囲外であり、ヒープ上の秘匿情報は GC に頼るしかないため、用途を理解した上で使う必要があると結論づけている。
その他プログラミング
本講演は、PHP 8.4/8.5世代の言語機能を活かして「バグをチェックで取り締まる」のではなく、そもそもバグが入りにくい設計＝予防によって堅牢なコードを書くための指針を示す内容である。
具体的には、型宣言・列挙型・静的解析・型のモデリング・不変性・完全性・責務の配置といったトピックを通じて、引数や状態を曖昧な配列や文字列で扱うのではなく、区間やステータスなどのドメイン概念を型として表現し、DateTimeImmutable＋専用クラス＋アトリビュートなどを組み合わせて誤用をコンパイル時・実行時に早期検出するテクニックが紹介される。
また、例外やアサートの使い分け、NoDiscard的な仕組みによる戻り値の取りこぼし防止、ヘルパやDSL風APIによる「Simple & Easy」なテストコード記述などを通じて、読みやすさと安全性を両立させる設計の考え方が示されている。
Visual Studio Code
VS Code 1.107 では、GitHub Copilot を核にした「Agent HQ」が追加され、ローカル・バックグラウンド・クラウド・カスタムエージェントを統合的に管理し、Git worktree を用いた並行タスク実行や組織共有エージェント、Claude Skills 再利用など高度なエージェント機能が強化されています。 また、チャットはセッション統合、モデル管理エディタ、URL/ドメインの二段階承認、動的コンテンツ対応の fetch、ターミナル出力のリッチ表示やコマンド自動承認などにより、セキュアかつ効率的な対話体験に刷新されています。 エディタ周りではインラインチャットのコード編集特化、TypeScript のリネーム提案や次編集モデル改善、ホバー挙動の細かな制御、macOS の 3 本指スワイプによるナビゲーション、Git スタッシュ表示など開発体験を底上げする変更が多数含まれます。 さらに、最新 MCP 仕様対応や GitHub MCP Server 統合、Azure モデルの Entra ID デフォルト認証、企業向けのツール自動承認制御やエージェント利用ポリシーなど、エンタープライズと拡張シナリオへの対応も進んでいます。
VS Codeのエージェントは、プロジェクト全体を理解して複数ファイルの編集やコマンド実行まで自動で行うAIで、ローカル・バックグラウンド・クラウド・サードパーティの4種類があります。 チャットビューからセッションの作成・切り替え・委譲（ローカル→バックグラウンド→クラウドなど）ができ、セッションごとの変更差分をレビューしてローカルへ適用したり、PRブランチとしてチェックアウトできます。
MySQL
MySQL 9.4/9.5では、Community Edition向けにJSON活用・性能・運用性が強化されている。
MySQL 9.4の概要
MySQL 9.4では、複数テーブルに分散したデータを1つのJSONドキュメントとして扱えるJSON duality viewが追加され、JSONベースAPIとリレーショナルスキーマの橋渡しが容易になった。 行内容からハッシュを生成するETAG関数により、楽観ロックやキャッシュ更新判定を軽量に行え、mysqlクライアントにはクライアントコマンドを一括制御する--commandsオプションが導入されてセキュリティポリシーに沿った運用がしやすくなっている。
MySQL 9.5の概要
MySQL 9.5では、CPU数やバイナリログ有無に応じてInnoDBログ書き出しスレッド数を自動調整するようinnodb_log_writer_threadsのデフォルト挙動が変更された。 また、レプリケーション並列実行に関わるbinlog_transaction_dependency_history_sizeのデフォルト値と上限が大幅に拡大され大規模環境でのスループット向上が期待される一方、不要となった一部レプリケーション関連変数が削除され、アップグレード前に設定ファイルの見直しが必要となっている。
技術的負債
本記事は、技術的負債に伴い静かに蓄積する「クラフト」を、混在・分散・冗長・欠落の4種類に分類し、それぞれがメンテナンスコストを増大させるメカニズムと対処法を、具体的なコード例やケーススタディで示している。 また、クラフトは自然には減らないため、計画的なリファクタリングとADRによる意思決定の記録を組み合わせ、「作るフェーズ」と「整えるフェーズ」を循環させることで、スピードと品質を両立しつつ継続的に改善していく重要性を説いている。
認証・認可
本記事は、OpenID Connect Core 1.0で定義されるClaimsパラメーターの概要と、その具体的な活用方法を解説し、最後にメルカリでの利用例を紹介している。ClaimsパラメーターはAuthentication Requestで指定可能なJSONオブジェクトで、userinfo や id_token 配下に、essential や value・values を用いて必須属性や期待する値を細かく指定でき、scope だけでは表現しにくい属性条件付きの要求を実現可能とする。一方で、明示的な null 指定や各メンバーのデフォルト挙動など仕様上の要件が多く、IdP実装側ではパースや条件解釈が複雑になり得るため、まずはClaims以外のシンプルな手段で代替できないか検討した方がよい点も指摘している。メルカリでは、RFC 9470ベースのLoAに応じたStep Up認証と組み合わせ、保護リソース側が電話番号など特定の検証済み属性を求めるケースで、Claimsパラメーターにより一度のAuthorization Requestの中で属性登録・更新を誘導するユースケースを紹介している。
AI
Agentic AI Foundation（AAIF）
Linux Foundationは、オープンで中立的なエージェントAI基盤を目指す「Agentic AI Foundation（AAIF）」を設立し、AnthropicのModel Context Protocol（MCP）、Blockのgoose、OpenAIのAGENTS.mdを中核プロジェクトとして受け入れた。 MCPはAIモデルと各種ツール・データ・アプリケーションを接続する事実上の標準プロトコルとなっており、Claude、Copilot、Gemini、ChatGPTなど多数のプラットフォームが採用している。 gooseはMCPベース統合を備えたローカルファーストのエージェントフレームワークで、信頼性の高いエージェントワークフロー構築を支援する。 AGENTS.mdはリポジトリごとの開発ガイドラインをAIエージェントに共有するための単純なMarkdown標準で、数多くのOSSプロジェクトやエージェントツールに採用されている。 AAIFにはAWS、Google、Microsoft、OpenAIなどがプラチナ会員として参加し、オープン標準・オープンプロトコルを通じてベンダーロックインを避けつつ、安全で相互運用可能なエージェントAIエコシステムの構築を目指している。
OpenAIはAnthropicやBlockなどとともにLinux Foundation傘下でAgentic AI Foundation（AAIF）を設立し、エージェントAI向けのオープンで相互運用可能な標準を中立的に策定・運用する枠組みを立ち上げた。 OpenAIはコードベースごとの規約やビルド手順などをエージェントに共有するための軽量なMarkdown仕様「AGENTS.md」を財団に寄贈し、MCPやgooseといった他社プロジェクトと合わせてエコシステム全体の共通基盤とする。 これにより、ベンダー依存や標準の分断を避けつつ、安全で持続可能なエージェント基盤をオープンコミュニティ主導で発展させることを狙っている。
JetBrainsはLinux Foundation傘下のAgentic Artificial Intelligence Foundation（AAIF）に参加し、MCPやgoose、AGENTS.mdなどのオープンソースプロジェクトを通じてエージェント技術の標準化と基盤整備に貢献する方針を示している。
JunieやJetBrains AI Assistant、Claude Agentなど既存のAI機能を持つIDEを開発しつつ、今後も複数のコーディングエージェントを受け入れるオープンプラットフォームとして、人間とエージェントの協調開発を支えることを目指している。
Mistral
Mistralは次世代のコーディング向け大規模モデル「Devstral 2（123B）」と小型版「Devstral Small 2（24B）」、およびそれを活用するCLIエージェント「Mistral Vibe CLI」を発表している。
Devstral 2はSWE-bench Verifiedで72.2%と高性能で、競合よりパラメータ数が少ない一方、最大256Kコンテキストやコードベース全体をまたぐ編集・リファクタリングなど生産環境向け機能を備え、API経由で当面無料提供される。 Devstral Small 2は68.0%の性能を持つ24Bモデルで、Apache 2.0ライセンスのオープンソースとしてローカルやコンシューマGPU／CPU上でも動作可能な軽量モデルとなっている。 いずれもオンプレ展開やファインチューニングに対応し、DeepSeekやKimiなどより小型ながら同等以上の性能を目指している。
Mistral Vibe CLIはDevstralをバックエンドとするオープンソースのコマンドライン開発エージェントで、プロジェクト全体を解析し、複数ファイルにまたがる変更、Git連携、シェル実行などを自然言語で操作できるインタラクティブなチャットUIを提供する。 Zed拡張としてIDE内でも利用でき、config.tomlによるモデル・プロバイダ設定やツール権限の制御、履歴永続化と補完などを備え、自動コード修正やPRサイクル短縮を狙っている。 Devstral 2はH100級GPU 4枚以上を推奨し、Devstral Small 2は単一GPUやCPUのみ構成でも動作可能で、無料期間終了後はDevstral 2が入力/出力それぞれ100万トークンあたり0.40/2.00ドル、Small 2が0.10/0.30ドルで提供される予定である。
OpenAI
Introducing GPT-5.2
GPT‑5.2は、専門的なナレッジワークや長時間動作するエージェント向けに設計された最新の最上位モデルで、スプレッドシートやプレゼン作成、コーディング、画像理解、長文コンテキスト処理、ツール呼び出しなどでGPT‑5.1を大きく上回る性能を示します。 GDPvalやSWE‑Bench Pro、FrontierMath、ARC‑AGIなど多くのベンチマークで新たなSOTAを達成し、人間の専門家レベルのタスク遂行能力と長コンテキストでの高精度な推論を備えています。 ChatGPTでは「Instant」「Thinking」「Pro」の3バリアントとして有料プランから順次提供され、APIではgpt-5.2やgpt-5.2-chat-latestなどとして利用可能で、価格は入力100万トークンあたり1.75ドル、出力14ドルに設定されています。 また、事実性や安全性、メンタルヘルス関連の応答品質も強化されており、企業利用や科学・数学研究など高信頼が求められる用途に適したモデルとなっています。
Advancing science and math with GPT-5.2
GPT‑5.2は数学・科学分野を強化した最新モデルで、GPQA DiamondやFrontierMathといったベンチマークで最高水準の精度を達成し、抽象的な数理推論や長い思考過程での一貫した論理展開を可能にしている。 論文では、統計的学習理論における学習曲線の単調性という未解決問題に対し、GPT‑5.2 Proが直接証明案を生成し、人間研究者と外部専門家が検証することで、正規分布に基づく基本的な設定ではデータを増やすほど性能が向上することを示したケーススタディが紹介されている。 この事例から、GPT‑5.2のようなモデルは、数学や理論計算機科学のような公理的分野で、証明探索や仮説検証を大きく加速しうる一方、信頼できる科学的進歩には依然として専門家による検証と透明性を重視した協働ワークフローが不可欠であると述べられている。
論文・その他
この記事は、AIの未来を「経済的特異点」と「普通のテクノロジー」という二つのシナリオで対比し、どちらに転ぶかを見極めるための視点と戦略を提示している。 前者ではAGI級の能力が今十年で急速に普及し、仕事・資本・国家間競争が文明レベルで変容すると想定し、後者では電気やインターネット同様に導入コストや組織抵抗、規制などで普及が数十年スパンになるとする。 著者らはOpenAI・Anthropic・Googleや中国勢DeepSeekの動き、市場バブル性、電力制約、ロボティクス進展など「ニュース・フロム・ザ・フューチャー」を継続的に観察し、どのシナリオに近づいているかを更新せよと主張する。 その上で、どちらの未来でも有効な「ロバスト戦略」として、補助金前提でない採算性のあるAI活用、計算資源とエネルギー効率の追求、基盤モデルに依存しすぎないアーキテクチャ分散、セキュリティと人間の関与の徹底、そして雇用破壊ではなく価値創造に焦点を当てたAI導入を挙げ、「未来は予測するものではなく自ら設計するものだ」と結んでいる。
量子コンピューティングとAIはいずれも誤りを含むが、量子計算は「解くのは難しいが答えの検証は容易な問題」に特化しており、誤答なら再試行すればよい点が鍵とされる。 一方LLMは、人物の経歴など検証が難しい領域にまで適用され、参照元も内容を裏付けないことが多く、この「検証困難さ」が大きな問題になっている。 KarpathyはSoftware 2.0を「検証可能性」を中心に再定義し、タスクが検証しやすいほど自動化しやすく、これがLLM進歩の「ギザギザの境界」を形作っていると指摘する。 つまりSoftware 1.0が「指定できることの自動化」なら、Software 2.0は「検証できることの自動化」であり、AI開発者には「何がどう検証可能か」を設計することが今後の本質的課題として突き付けられている。
エンジニア
AIと仕事
このnoteは、AIが文章を整えてくれる時代だからこそ、「読む・書く・考える」という人間の思考プロセスがより重要になると論じている。 文章は単語・文・構造の三層が連動した「思考の外在化」であり、読み手は単語のニュアンス、文の構文、全体構造を往復しながら書き手の思考モデルを再構成していると説明する。
一方で書くことは、読み手がそのプロセスを誤らずにたどれるよう、単語選択・文の流れ・情報構造を精密に設計する高度な行為であり、箇条書きの乱用などは「その場にいた人にしかわからないログ」を生むだけだと批判する。 NotebookLMのようなAIツールは、雑な思考からでも見た目の整ったアウトプットを生成してしまうため、思考の粗さや破綻が隠れ、「これが自分の言いたかったことだ」と錯覚して深く考えるプロセスが失われる危険を指摘する。
著者は、AIは製造機ではなく「思考の増幅器」であり、入力となる思考と文章の構造が精密であるほどAIがそれを増幅してくれる一方、曖昧な入力は曖昧なまま出力されると述べる。 読む・書く・考えるは本来分離できない三位一体の活動であり、この循環を回すことでしか思考は鍛えられないため、AI時代こそ文章を「整える」能力ではなく「創る」能力が決定的な差になると結論づけている。
感想:
現状のLLMは文字情報の処理に特化されている。マルチモーダルにしても、対象を言語化しないとLLMは類推することができない。この特性のため、使い手の言語化能力と文章能力がAIを上手く使役できるかどうかの分かれ目になっているのは確かだと思う。
AIアシスタントを活用すると、ジュニアエンジニアの学習速度が上がり、「戦力化までの谷」が短く浅くなるため、採用投資としての期待値が大きく改善すると論じている記事です。
従来はジュニアは立ち上がりが遅くコスト過多と見なされてきたが、AIが探索空間を狭めることでタスク完了までの時間が短縮され、その余剰時間を学習に再投資できるようになると説明する。
その結果、離職などで投資回収前に辞めてしまうリスクが減り、早く成長したジュニアが他者のメンタリングや組織的なレバレッジを生むため、組織全体の生産性向上にもつながると主張している。
生成AIで作った長文なのに中身が薄い文章や、重要情報が抜け落ちた要約文をそのまま上司・同僚に送る「ワークスロップ」は相手の時間を奪う悪い使い方だと指摘している。 AIの回答スクショ貼り付けや長大なディープリサーチ結果、未確認の比較結果や機械要約を丸投げせず、読み手にとって必要な情報か・過不足がないかを人間が確認して編集することが、AI活用のビジネス基礎スキルだと述べている。
技術書
この記事は、著者が2025年に読んで「刺さった」技術書25冊を通じて、AI時代のエンジニアリングと学びの意味を振り返った読書感想文です。
AIやLLM、AIエージェント、プラットフォームエンジニアリング、インフラ・クラウド、設計・アーキテクチャ、技術的負債、RustやPostgreSQLなど、多様なテーマの本を取り上げつつ、「AIにコードを書かせても、責任と説明は人間が負うこと」「結合は悪ではなくバランスが重要であること」「技術選定やモダナイゼーションはトレードオフと組織文脈の問題であること」などの共通する視点を抽出しています。
著者は、AIに聞けば正解らしきものはすぐ得られる一方で、本を通じて他人の失敗や遠回り、違和感に触れ、それを自分の言葉に変えていく非効率なプロセスこそが、自分の思考や「地力」をつくると繰り返し強調します。
おわりにでは、これらの本が「それでいいのか」と問いを投げかけ、自分がなぜエンジニアを続けるのか、AI時代に本を読む意味は何かという答えの出ない問いに向き合うための手がかりになったとし、「正解がないから面白いし、本を読み続ける理由になる」と結んでいます。
感想:
何となく本がかぶっている。Beyond Vibe Codingとソフトウェアエンジニアガイドブックは私もススメです。
良いコミュニケーションのためにはまず信頼されろ
専門家が組織で声を上げないのは怠慢ではなく、話しても曲解されたり軽んじられたりし、釈明コストとリスクが大きすぎるという合理的な適応だと述べている。
分業や評価制度などの構造により専門家の言葉は「意見の一つ」として消費され、学習性無力感から沈黙を選びやすくなる一方、専門知識を「振りかざす」態度は溝と反発を深めるだけだと指摘する。
著者は解決策として、専門家側から相手の文脈に入り込んで説明する「対話」を重視し、そのための時間・労力という高コストを自ら支払うしかないと主張する。
理想的な「専門家がリスペクトされる組織」を待つのではなく、「あなたになら話したい」と思ってもらえる相手として振る舞い、自分から対話のコストを払い続けることが、専門家として生き残る唯一の道だと締めくくっている。
Discussion