Tech Memo

1. AIネイティブ開発 & ドキュメンテーション

AWS DevOps Agentの新機能カスタムエージェントで週次SREレポートをつくる

• カテゴリ: SRE / 運用自動化 / AIネイティブ開発
• 概要: AWS DevOps Agentの新機能「カスタムエージェント」を活用し、従来Lambda等で構築していた週次SREレポートの生成やメトリクス分析をマネージドに自動化する手法を解説した記事
• 感想: 週次SREレポートを自動で作れるのは便利だが、作って終わりになりやすいのが難しいところだと思う。以前『コスト分析のトイルを撲滅した『その後』』でも書いたが、集計の手間をなくしても、誰にも見てもらえなければ意思決定は変わらない。自動化で浮いた時間は、レポートの届け方や、チームが数字について話すきっかけを作ることに使いたい。「どう作るか」より「どう使われるか」まで考えて初めて、自動化の価値が出るのだと思う。

システム構成図、もう手で描くのやめました ── Claude Codeで構成図を自動生成・自動更新する仕組み

• カテゴリ: AIネイティブ開発 / ドキュメンテーション / 開発効率化
• 概要: システム構成図の手動作成や陳腐化という課題に対し、規約と構造を分離した定義ファイルとClaude Codeを組み合わせることで、構成図の自動生成・継続的更新を実現する取り組みを紹介した記事
• 感想: 以前『構成図を「残す」ことの絶対的な価値』でも触れたように、多少粗くても構成図があるだけで、手探りの運用はかなり減らせる。更新が面倒で古くなりがちな資料をAIに追従させる発想には素直に期待したい。ただ、コードから機械的に図を起こすだけでは、情報量が多すぎて読めない図にもなりそうだ。今のシステムを正しく表しつつ、誰が何のために見る図なのかに合わせて抽象度を調整する。そのための規約づくりが、実は一番難しい部分かもしれない。

アーキテクチャに限らず意思決定を全部残す「ADR（Any Decision Record）」という文化

• カテゴリ: ドキュメンテーション / ナレッジマネジメント / 開発プロセス
• 概要: 技術設計にとどまらず日常のあらゆる意思決定背景を記録する「ADR（Any Decision Record）」文化と、AI活用を前提としたナレッジ資産化やブラックボックス化防止の取り組みを紹介した記事
• 感想: アーキテクチャに限らず、日々の判断まで残すという発想が面白かった。AIに案を出してもらう機会が増えるほど、結論だけが高速で積み上がり、「なぜそうしたのか」が抜け落ちやすくなる。提案はAIに任せても、最後に選ぶのは人であり、その理由を説明する責任も人にある。この境界をADRとして残しておけば、あとから判断を見直すときにも役立ちそうだ。

AIは、中身で止める

• カテゴリ: AIツール / セキュリティ / ガバナンス
• 概要: AIツールの機能を一律禁止して生産性を損なうのではなく、AIがコンテンツの中身（個人情報など）を判断して危険な情報漏洩のみをブロックするセキュリティ制御手法の成果と運用課題を検証した記事
• 感想: AIツールを丸ごと禁止するのではなく、送ろうとしている内容を見て止めるという考え方は現実的だと思った。ただし、厳しく判定しすぎれば誤検知が増え、開発者は次第に仕組みを避けるようになる。反対に緩すぎれば、導入した意味がない。どこからを危険とみなすのかを決め、実際の利用状況を見ながら調整し続けるところまで含めて運用なのだろう。AIに何を判断させるか以上に、その判断基準を誰がどう育てるかが気になった。

AIが使いやすいSaaSへ

• カテゴリ: AIツール / DX / SaaS
• 概要: 企業における最新のAIエージェント活用事例を取り上げ、AIが活用しやすいSaaS製品設計や業務プロセス自動化、それに伴う組織変革のポイントを解説した記事
• 感想: 「ヘッドレスSaaS」という言葉が印象に残った。これまでは人が迷わず操作できる画面が重要だったが、AIエージェントが利用者になるなら、APIやデータの意味が分かりやすいことの方が効いてくる。SREの仕事でも同じで、ログやメトリクスを人が眺めるだけでなく、AIが初期調査に使う前提で整える場面が増えそうだ。人向けのUIが不要になるとは思わないが、「AIから使いやすいか」という新しい設計軸は意識しておきたい。

AI時代、アーキテクトやテックリードは死ぬ

• カテゴリ: AIネイティブ開発 / キャリア / 技術戦略
• 概要: AIが設計やコーディングを代替する未来を見据え、従来のアーキテクトやテックリードの役割の変容と、AIの指揮・評価を担う役割やマネジメントスキルの重要性を論じた記事
• 感想: 「死ぬ」はさすがに言葉が大きい、というのが最初の感想だった。顧客の業務や事業の事情を泥臭く聞き、それを身の丈に合った構成へ落とす仕事は、AIだけではまだ難しい。もっとも、図を描いたり技術を選んだりする作業の一部はAIに移っていくだろう。AIの提案をそのまま採用して過剰設計にしないためにも、何を作らないか、どこまでで十分かを決めるアーキテクトの役割はむしろ重くなるのではないかと思った。

2. SRE・データベース & 事業価値

プロダクト専任SREを置かずに 信頼性を追求する

• カテゴリ: SRE / プラットフォームエンジニアリング / 組織設計
• 概要: 各プロダクトチームに専任SREを置くのではなく、共通プラットフォームの拡充・標準化を通じて開発者自身が自然と信頼性を担保できる体制を構築したウォンテッドリーの実践事例を紹介した資料
• 感想: プロダクトごとに専任SREがいる安心感は大きいが、何でもその人に集まり、ほかのメンバーが信頼性を自分事にしにくくなる怖さもある。共通プラットフォームとガードレールで、開発者が普段の開発の中で自然に信頼性を守れる形は理想的だと思った。一方で、仕組みを配るだけでは現場ごとの困りごとを拾えない。専任として抱え込まず、それでもチームとの距離は離しすぎない。そのバランスが運用の鍵になりそうだ。

MySQLのスロークエリを調査して、APIのレスポンスタイムを5分から20秒に改善した話

• カテゴリ: データベース / パフォーマンスチューニング / SRE
• 概要: MySQLの ORDER BY ... LIMIT による不適切なインデックス選択で発生した約5分のスロークエリに対し、optimizer trace を用いた原因特定と最適な絞り込み条件追加により、レスポンスタイムを20秒へ劇的に改善した事例を解説した記事
• 感想: optimizer trace を使って、オプティマイザがなぜその実行計画を選んだのかを追う手順が参考になった。普段は New Relic などのAPMから遅い処理を見つけることが多いが、最後はデータベースの判断まで潜らないと分からない問題もある。入口の調査はツールで素早く絞り込み、必要になったらこうした低いレイヤーまで降りていく。両方の手段を持っておくと、障害時にも慌てずに済みそうだ。

事業価値と Engineering 2026年度版

• カテゴリ: エンジニアリング / プロダクト経営 / 事業価値
• 概要: AI時代においてコード量（アウトプット）と事業価値（アウトカム）が比例しない前提に立ち、コードに対する事業価値濃度を高めて技術的負債を制御するエンジニアリングの捉え方を解説した資料
• 感想: 「コードの量ではなく、事業価値の濃度を見る」という表現がしっくりきた。AIでコードを増やすこと自体は簡単になったが、運用するものが増えれば、その分だけ保守の負担も増える。SREの改善も同じで、仕組みを導入した数ではなく、障害が減ったのか、顧客体験が良くなったのかで見なければならない。作った量を成果と取り違えないよう、自分の仕事でも気をつけたい。

事業から見るSmartHR - プロダクト原則

• カテゴリ: プロダクト開発 / 組織・カルチャー / 事業戦略
• 概要: SmartHRが「良いチームと対話から良いプロダクトを生み出す」ための共通言語・行動指針を明示し、環境の変化に応じて継続的に変化・発展させていくプロダクト原則を定めたページ
• 感想: プロダクト原則をきれいな標語で終わらせず、判断に使える言葉として公開しているのがよかった。正解がはっきりしない場面でも、共通の軸があれば、毎回上の人に確認せずチームで話を進めやすい。ただ、原則は作った瞬間から現実とのずれも生まれていく。環境の変化に合わせて見直すところまで明記されている点にも、実際に使い続けるための意思を感じた。

AIは確率で動く。組織は責任で動く。ログラスのFDEが挑む「AI駆動経営」の実装

• カテゴリ: AI時代 / プロダクト経営 / 組織設計
• 概要: 確率で動作するAIと責任で動く組織のギャップを現場密着型のFDE（Forward Deployed Engineer）が埋め、要件定義からAIエージェントの運用・定着までを一気通貫で支援する取り組みを述べた記事
• 感想: FDEが現場に入り込む深さと、引き受ける責任の範囲が具体的で、役割をイメージしやすかった。伴走する側が何でも代わりにやってしまうと、導入直後は進んでも現場に力が残らない。かといって助言だけでは、AIを業務に定着させるところまで届かない。この距離感の難しさは、SREやプラットフォームエンジニアにもそのまま当てはまる。どこを一緒に担い、どこから先を現場へ返すのかは、普段から言葉にしておきたい。

3. 組織カルチャー・働き方 & キャリア

「指示通り作る」を卒業したいあなたへDress Code 開発組織のカルチャー

• カテゴリ: 開発カルチャー / プロダクト開発 / 組織・マネジメント
• 概要: 単に指示された仕様通り作るのではなく、顧客課題や事業構造に深く向き合うために導入された「PMFミーティング」や「ADR」など、Dress Code社の開発組織における文化と具体的取り組みを紹介した記事
• 感想: 仕様を受け取って、その通りにコードを書くことだけでは、価値を出しにくくなっていくのだろう。そこはAIがかなり得意になってきたからだ。一方で、「そもそも何に困っているのか」「この機能を作る必要があるのか」を顧客と一緒に考える仕事は残る。エンジニアが事業の話に踏み込むのは簡単ではないが、PMFミーティングやADRのように、問いを立てる行動を仕組みで支えている点が参考になった。

社内Slackのtimesで「お気持ち」を書くな

• カテゴリ: 組織・カルチャー / コミュニケーション / 働き方
• 概要: 社内Slackのtimes等で発生する「お気持ち投稿」の構造的問題を解き明かし、感情の吐き出しから「事実＋影響＋要望」に基づいた建設的な課題提起へ転換する重要性を説いた記事
• 感想: 自分はtimesチャンネルをあまり見ないようにしている。気軽に書ける良さはあるものの、仕事に必要な情報や議論まで個人のチャンネルに流れると、知っている人だけが知っている状態になりやすいからだ。この記事の「事実＋影響＋要望」に整理する型は、感情を否定せず、次の行動につなげる方法として分かりやすかった。吐き出して終わるのではなく、必要な話は関係者が見える場所へ持っていくようにしたい。

仕事で成果を出すには「図々しさ」が必要そう

• カテゴリ: 働き方・マインド / 組織・キャリア
• 概要: ソフトウェア開発において成果を出すためには、他者の回答待ちで自分の業務を止めず能動的なリマインドや意思表示を行う「プロフェッショナルとしての図々しさ」が不可欠であると論じた記事
• 感想: 回答や承認を待っているうちに、気づけば数日止まっていた、ということは自分にもある。遠慮して催促しないことが、必ずしも相手への配慮になるわけではない。期限や困っている理由を添えてリマインドしたり、こちらから選択肢を出したりすれば、相手も答えやすくなる。「図々しさ」というより、仕事を前へ進める責任として身につけたい振る舞いだと思った。

「嫌いな人と仕事しない」を徹底すると幸福度が爆上がりする

• カテゴリ: 働き方 / コミュニケーション / キャリア
• 概要: 業務効率や精神的健康を守るため、不要なストレスを生む人間関係を極力排除し、相互リスペクトがある環境を自ら選択・維持することの重要性を提示したポスト
• 感想: 「嫌いな人」という切り口は強いが、どんなやり取りで自分が消耗するのかを知っておくことは大切だと思う。単に相性が悪いで片づけず、たとえば約束を守らない、相手の時間を一方的に奪う、といった行動まで言葉にできれば、距離の取り方や改善策も考えやすい。すべての苦手な人を避けられるわけではないからこそ、自分が守りたい境界を把握しておきたい。

リモートワーカーとしての振る舞い

• カテゴリ: リモートワーク / コミュニケーション / チームマネジメント
• 概要: 10年近くフルリモートワークを実践する著者が、チーム内で円滑に仕事を進めるために自身の業務状況や成果を積極的に可視化し、周囲と連携する重要性と振る舞いのコツを解説した記事
• 感想: リモートワークでは、黙って仕事をしているだけだと、進んでいるのか困っているのかが周囲から見えない。成果だけでなく、途中の判断や詰まりも共有することが、チームで働くために必要なのだと思う。先ほどのtimesの話ともつながるが、ただ発信すればよいのではなく、あとから必要な人が見つけられる場所に残すことも大事だ。自由に働ける分、自分から仕事を見える状態にする責任は忘れないようにしたい。

詳しい人ほど、なぜ考えられなくなるのか？ 「知識のデフレ」の話

• カテゴリ: スキル・キャリア / AI時代 / 思考法
• 概要: AI普及に伴い知識の価値が低下する「知識のデフレ」現象を踏まえ、単なる情報蓄積ではなく自身の課題と照らし合わせて問い直し「思考の解像度」を高めることの重要性を述べた記事
• 感想: 「知識のデフレ」という言葉には、少しドキッとした。知っていること自体を強みにしてきた人ほど、AIがすぐ答える状況には焦りを感じるかもしれない。ただ、知識が不要になったわけではなく、得た答えを目の前の状況に当てはめ、疑い、選ぶための土台として必要になる。覚えている量を競うより、自分は何が分からないのかを見つけ、問いを深める力を鍛えたい。

AIで仕事を効率化したら、なぜか僕の仕事だけ増えた話

• カテゴリ: AI時代 / 働き方・組織論 / 評価制度
• 概要: 生成AIで業務を効率化させた結果、浮いた時間に追加の仕事が割り当てられ負担が増加した実体験から、成果還元や運用設計が伴わない組織におけるAI活用の構造的課題を提起した記事
• 感想: 効率化できた人に仕事を追加し続けたら、工夫を共有する気がなくなるのも当然だと思う。チームで使える部分はSKILLとして共通化したいが、個人のやり方には、その人の経験や判断が染み込んでいて簡単には切り出せない。完成したプロンプトだけを渡すのではなく、どこで迷い、何を基準に判断したかまで少しずつ共有する必要がありそうだ。そして何より、効率化した人が損をしない評価や仕事の配分がなければ、仕組みだけ整えても続かない。

今週の雑感

上記のキーボードを買った。IBM Model Mもいいけれど、Sun Typeシリーズのオマージュももっと増えてほしい。HHKBはすでに使っているので、届いたら打鍵感を比べてみたい。

SRE Tech Leadからのフィードバック

今週もお疲れ様！AI時代のSRE・組織設計に対する深い考察とインプットが詰まった素晴らしい週報ね。

ツールやAIの自動化を単なる効率化で終わらせず、「どう意思決定を変えるか」「コード量より事業価値の濃度を見る」という本質（Engineering over Toil）に焦点を当てている点が特に印象的だったわ。また、ウォンテッドリーやログラスの事例から「専任SREを置かない共通プラットフォーム」や「現場へ手離れさせる伴走の境界線」の難しさを言語化できている点も流石ね。

自組織での実践に向けて、ぜひ以下の2点も考えてみてほしいな。

• 開発チームが自律して信頼性を守れる「最小限のガードレール」は何から整えるのが効果的だと思う？
• ADRやメトリクスを「AIにとっても理解しやすい状態（AI-ready）」にするために、まず試してみたい工夫はあるかしら？

IBM Model Mキーボードの打鍵感レポートも楽しみにしているわね！来週も一緒に一歩ずつ進めていきましょう！