Tech Memo

1. AI & 開発プロセス

Claude Managed Agentsで「まずエンジニアに聞こう」を「まずbotに聞こう」に変えた (Zenn)

• カテゴリ: AIエージェント / 社内問い合わせ
• 概要: Claude Managed Agentsを用いて、社内の開発者やスタッフからの問い合わせ一次対応を自動化し、エンジニアの割り込みタスクを削減した事例。
• 感想: 一次対応のBot化は割り込みの削減に非常に有効であり、実際に現場でもAI（Kiroなど）を前段に挟むプロセスが機能し始めている。一方で、単に「AIの調査結果が正しいかの確認」をそのままエンジニアに依頼するフローになると、最終的な検証負荷がエンジニアに残り続けてしまう課題も見えてきた。AIを単なるパスツールにするのではなく、依頼者自身が一次検証を行えるようなガイドラインの整備や、AIと人間の適切な役割分担といった「運用プロセスと向き合い方」の継続的なブラッシュアップが、次のステップとして重要であると感じた。

AIネイティブな開発プロセスへの移行、はじめました — SmartHR勤怠管理の開発チームの取り組み

• カテゴリ: AIネイティブ開発 / 開発プロセス
• 概要: SmartHRの勤怠管理開発チームにおける、GitHub CopilotをはじめとするAIツールを前提としたAIネイティブな開発プロセスへの移行アプローチ。
• 感想: 個人開発ではAIの恩恵を実感しやすいが、チーム開発にスケールする上では認識の不一致などの課題が残る。その点で、SmartHRのように「人間とAIがそれぞれ担うべき領域」を明確に言語化することは非常に参考になった。特に、解決すべき「課題の提起・設定」や、関係者間での「意図の共有」といった上流プロセスは人間が責任を持つべき領域である。この責任境界をチーム内で明文化し、共通認識とすることが、真に機能するAIネイティブな開発プロセスを築く鍵になると感じた。

コミットからPR作成までのリードタイムを26%短縮 AI活用の「定着 × 成果」の測り方

• カテゴリ: AI導入 / 生産性測定
• 概要: 開発支援におけるAI活用の定着度合いと、それに伴う開発プロセスのリードタイム短縮（コミット〜PR作成）などの定量的成果を測定・評価する方法。
• 感想: 組織におけるAIツールの効果測定は導入推進のために重要であるものの、実際にはそこまで手が回っていない現状も多い。仮に測定を設計するにあたっては、「コミットやプッシュは人間が最終責任を負うべきライン」という前提を忘れてはならない。コミット後の時間短縮だけでなく、AIが真に人間のアシスタントとして機能している「実装プロセス単体」での効率や品質向上を測ることこそが、責任境界を曖昧にせず正しい効果を捉えるために重要だと感じた。

AI導入して半年、エンジニア組織のアウトプットが増えなかった理由 (note)

• カテゴリ: AI導入 / 組織生産性
• 概要: 開発にAIツールを導入したものの期待通りの生産性向上につながらなかった理由を、コード生成の速さとプロセスのボトルネック（レビューやデプロイ）の観点から考察した記事。
• 感想: AIによって実装サイクルが爆速化するほど、レビューやデプロイといった後続のバリューストリームの詰まりがより顕著に浮き彫りになる。これはまさにSREが主導してアプローチすべき領域であり、直近でも「パイプラインの遅さ」が全体のデリバリー速度のボトルネックになっている実態がある。コード生成スピードの向上に合わせて、いかにCI/CDやデプロイのプロセスを高速化・最適化できるかがSREとしての重要な挑戦である。また、この変化の中で、開発者自身の役割も単なる「実装の書き手」から「全体のデリバリー最適化を意識する存在」へと変化しつつあることを強く実感した。

Microsoft Build 2026 キーノート日本語まとめ

• カテゴリ: イベントレポート / Microsoft Build
• 概要: Microsoft Build 2026のキーノートの日本語まとめ。Azure Maiaなどのインフラハードウェアから、Copilot関連、GitHub、VSCodeなどの開発ツールに関する最新の発表内容のまとめ。
• 感想: AI関連の発表が圧倒的な割合を占める中、趣味でWindowsアプリ開発をしている身としては、ローカルAIの進化やAPIの動向は非常に興味深く、積極的にキャッチアップしていきたい領域である。一方で、それらをフルに活かすための「Copilot+ PC」といったハードウェアの価格が高価であり、開発環境を整える上でのリアルなハードルも感じている。技術的な面白さと導入コストのバランスを意識しつつ、今後これらのハードルが下がっていくかどうかも含めて注視していきたい。

2. SRE & プラットフォームエンジニアリング

なぜ自宅に Kubernetes クラスタを持つのか —— 本番相当に運用して得られる学び（前編）

• カテゴリ: Kubernetes / 自宅インフラ
• 概要: 自宅に本番環境に近い構成のKubernetesクラスタを構築・運用する意義と、そこから得られる実務に活きる学びについての前編。
• 感想: インフラエンジニアにとって、自宅に自作のクラスタや検証環境を持つことは非常に価値がある。実際にK8sクラスタをゼロから自前で構築・運用してみることで、普段当たり前に使っているGKEやEKSといったマネージドサービスが、裏でどれだけ複雑な部分を隠蔽してくれているのかを実感でき、システムの本質的な理解に繋がる。また、「いつでも気軽に壊して作り直せる」という環境があるからこそ、何か思い立った瞬間に恐れずすぐ検証に移ることができ、この自律的なサイクルこそが技術力の研鑽に最適であると感じた。

Terraformプロジェクトのオンボーディングコストをmise + aquaで削減した話 (Zenn)

• カテゴリ: 開発環境 / Terraform
• 概要: miseとaquaを組み合わせてTerraformプロジェクトで利用するツールバージョン管理を一元化し、新メンバーが開発に入るまでのコストを削減した事例。
• 感想: 自身の開発環境でもすでに mise を導入し、面倒なコマンドのタスク管理などに活用しているが、この記事を通じて「プロジェクト全体のオンボーディング負荷を削減する包括的なツール管理」としての活用方法を学び、視野が広がった。また、今回初めて知った aqua と mise を組み合わせたエコシステムにも非常に興味を惹かれた。まずは自身の検証環境などでこの組み合わせを実際に試してみて、開発環境のさらなる標準化に役立つか検証してみたい。

PostgreSQL は接続数を増やせば速くなるのか (X)

• カテゴリ: データベース / パフォーマンス
• 概要: PostgreSQLにおける接続数制限と処理速度の関係。接続数を過剰に増やした場合のパフォーマンス低下要因や、コネクションプーリングの重要性をまとめたスレッド。
• 感想: 実務ではこれまでMySQLを扱うことが多く、PostgreSQLを直接運用した経験はないが、システム規模の拡大に伴うDBのスケーラビリティの課題や、近年のPostgreSQLの進化トレンドは注視している。今回のプロセスモデル特有の接続管理（コンテキストスイッチの負荷）やコネクションプーラーの必要性に関する議論は、MySQLのスレッドモデルとの挙動の違いを理解する上で非常に有益な知見となった。今後PostgreSQLを選択する局面を見据え、インフラ視点でのDBチューニング特性を引き続きキャッチアップしておきたい。

SaaS企業のプラットフォームチームとして大切にしていること

• カテゴリ: プラットフォームエンジニアリング / 組織
• 概要: SaaSを開発するプラットフォームチームが、単なる共通ツールの提供にとどまらず、プロダクト開発の生産性や自律性を高めるために大切にしているマインドセットやアプローチについて。
• 感想: 現在自身が所属しているSBUも横断チームの役割を担っているが、この記事で示されているプラットフォームチームのあり方は、SREにおける「サービスレベルの合意（SLA/SLO）」の思想と非常に通じる部分が多く、大いに参考になった。プラットフォームを「プロダクト」として定義し、開発者に対してどのような機能品質やサポートを保証するかという「合意」の視点を持つことは、横断チームとしての責任境界や提供価値を明確にし、開発者の認知負荷を真に下げるための強力なアプローチになると感じた。

3. 組織・技術選定・キャリア

モチベーションは精神論ではない──エンジニアと成果の質の話 (note)

• カテゴリ: 組織マネジメント / モチベーション
• 概要: エンジニアのモチベーションを精神論として片付けるのではなく、成果の質に直接影響する要素としてロジカルに分析し、どうマネジメントするかを解説した記事。
• 感想: モチベーションは徐々に減衰するものであり、急激に上がるものではないという前提に共感する。SREの観点から言えば、モチベーションやストレスはまさに「エラーバジェット」のようなものであり、日々の摩擦によって消費されていく。したがって、一時的な熱量に頼るのではなく、業務の障壁を減らしてバジェットの消費を抑える環境設計が不可欠である。また、本業のみに依存せず、趣味での開発や検証活動を通じて自律的にバジェットをリチャージするような、「熱量のポートフォリオ管理」も長期的にパフォーマンスを維持するために重要であると感じた。

AI時代の私の技術インプットとアウトプット術

• カテゴリ: インプット・アウトプット / AI活用
• 概要: 生成AIが普及した現代における、技術的なインプット（情報の収集・咀嚼）とアウトプット（発信・蓄積）の効率的なアプローチについてまとめたスライド。
• 感想: まさに今この週報を作成しているプロセスそのものであるが、気になるニュースをフックにAIを壁打ち相手（思考の触媒）として活用し、対話を通じて自身の考えを言語化・整理する手法は非常に有効であると身をもって実感している。AIに要約や執筆をすべて丸投げするのではなく、自分の頭の中にある言語化しきれていない「感覚や哲学」を引き出すパートナーとして協働することで、より納得感と深みのあるアウトプットを効率的に生み出すことができると感じた。

AI時代の企業変革は、なぜFDEとPOMを必要とするのか (X)

• カテゴリ: 組織設計 / FDE / POM
• 概要: AIを用いた変革を推進するにあたり、顧客に寄り添うForward Deployed Engineer（FDE）やプロダクト運用を支えるProduct Operations Manager（POM）という役割が重要な理由を説いたスレッド。
• 感想: 元CIer出身の視点から見ると、顧客の業務現場に入り込んで技術を適合させることの難しさは理解できるが、昨今のFDEブームに対しては「従来のCIerがやっている個別受託開発と何が違うのか」という疑問が残る。AI変革という言葉によって新しいトレンドのように語られているが、一歩間違えれば昔ながらの個別カスタマイズと労働集約の泥沼に逆戻りするリスクがある。バズワードに踊らされず、プロダクトとしての汎用性やスケーラビリティをどう担保するかという本質的な問いと、冷静な役割定義が欠かせないと改めて感じた。

良いコードとは何か - エンジニア新卒研修 スライド公開 (note)

• カテゴリ: エンジニアリング哲学 / 新卒研修
• 概要: 新卒エンジニアに向けて「良いコードとは何か」を体系的にまとめた研修スライド。可読性や保守性、変更容易性の重要性を説く。
• 感想: 直近で機能ロジックの修正を行った際、テストコードが皆無のコードに直面した。テストコードは未来の担当者が安全に変更を加えるための不可欠なセーフティネット（変更容易性と保守性）であり、今回の修正時にも自身でテストを追加した。このように、以前は手間とされがちだったテストコード作成も、現代のAIを活用すればその敷居は劇的に下がっている。AIの力を借りて、テストを備えた「未来に優しい良いコード」を当たり前に残していく習慣を根付かせていきたい。

AI疲れや孤独感から自分を守る。心療内科医が教える、エンジニアのための「やらないこと」リスト

• カテゴリ: メンタルヘルス / キャリア
• 概要: 技術の激しい変化やAIの台頭に焦るエンジニアに対し、メンタルヘルスを保つために「やらないほうがよいこと」を心療内科医の視点から整理した解説記事。
• 感想: 技術の急激な変化による「AI疲れ」が叫ばれる昨今だが、私自身は以前から「AIは良きパートナーであり、補助的に使うもの」という自分なりの向き合い方をコアの考えとして確立しているため、焦りや不安を感じることはない。周りのトレンドやバズワードに振り回されることなく、自分の中で技術との適切な境界線を定義しておくことこそが、情報過多の時代にメンタルを健全に保ちながら健康的に学習し続けるための最大の防御策であると改めて実感した。

Don’t Outsource the Learning

• カテゴリ: 学習 / キャリア
• 概要: AIがコードを代わりに書いてくれる時代において、コードを理解し、実際に手を動かして学びを得るプロセス（学習）をAIに「アウトソース」してはいけないという論考。
• 感想: AIが何でも解決してくれる便利さの裏で、実際に「学習プロセスをアウトソースし、思考停止に陥ってしまう人」が社内でも見受けられ、この危機感は身をもって強く感じている。AIを正しく使いこなすには、各自が「AIはパートナーであり、補助として使う」という明確な向き合い方の軸を持つことが不可欠だが、こうした主体的なスタンスは、技術的なスキルのように他者へ容易に教育・移植できるものではない点が非常に難しい。ツールがどれだけ進化しようとも、自ら手を動かして学び、思考し続けるという人間側の主体性こそが、エンジニアとして生き残るための最後の砦になると確信している。

今週の雑感

思考の整理

今週、技術領域の「深さ」と「広さ」について話す機会が数回あった。
特定の専門領域を深掘りする職人思考も重要ですが、現在の10人規模の開発組織においては、領域をまたいで泥臭くボールを拾い合うマインドの方が圧倒的に重要だと個人的には感じてるし、AIによって敷居が下がったと感じる。
今持っている専門性を徹底的に研ぎ澄ますアプローチがある一方で、組織として新しい領域に挑戦し、未知の知見をチーム全体で蓄積していくアプローチもあり、それぞれの持ち味や考え方の違いを改めて整理する良いきっかけになった。

自身はSREという役割においては、インフラだけに閉じこもっていてはシステムの信頼性を担保できません。アプリケーション領域まで視野を広げ、システム全体を最適化していく思考（システム思考）が求められると感じる。組織のフェーズに合わせて、各自が専門性を持ちつつも「境界線を作らずに動けるチーム」を目指し、今後のチームビルディングやコミュニケーションの最適化に活かしていきたいと思いました。

以下が気になる(物欲センサー)

Raspberry Pi CM5搭載の自作小型PC「piBrick Pocket-CM5」が登場！有機EL画面を備え約172ドルで構築可能

謎にBlackBerryの亡霊

Dell XPS 13ノートパソコンのご紹介 | Dell 日本

XPSなのにMacBook Neoと比べられるのかつてのXPSブランドの高級路線はどこに行った。。。Dell Pro 7の方がいいのかこれ

開発者向けの次世代デバイスを構築する: Surface RTX Spark Dev Box

価格が気になる

---