Tech Memo

1. AI & 開発プロセス

【組織のAI推進：完全ロードマップ】 AI-Ops担当が語る、ツール導入より大切な「行動変容」の設計図 (note)

• カテゴリ: AI導入 / 組織浸透
• 概要: ログラスにおける全社的なAI業務効率化と活用の定着推進の経験をもとに、単なるツール導入にとどまらず、メンバーの行動変容までを設計するための完全ロードマップと現場のリアルな感触をまとめた記事
• 感想: 若手を中心にツールの活用が進む一方で、シニア層も含めたメンバー間で技術への興味やマインドの差が出やすい点に難しさを感じる。自身が新たな技術や開発プロセスを肌感覚で理解しないまま、周囲の成果物に乗っかるような形になってしまうと、エンジニアとしての本質的な設計判断やリスク評価といった価値を発揮しにくくなる懸念がある。これはAIに限らず、新しい技術の登場時に起こりがちな普遍的な課題かもしれない。組織としての底上げを図るには、単にツールを導入するだけでなく、個々のマインドセットに寄り添った行動変容のデザインが必要だと感じた。

MUFG、OpenAI とともに AI-Native な企業を目指す | OpenAI

• カテゴリ: AI導入 / 組織改革
• 概要: 三菱UFJフィナンシャル・グループ（MUFG）がChatGPT Enterpriseを導入し、AI-Nativeな組織づくりや業務改革、新たな金融サービスの創出を推進する協働の取り組みについての紹介記事
• 感想: 保守的なイメージの強いメガバンクが、OpenAIとの協働という踏み込んだ挑戦に乗り出したことに驚きを感じた。ただ、近年各行がデジタルバンクなどの先進的な取り組みを進めている背景や、今後の労働人口減少を見据えた「少人数でも持続可能な組織づくり」という生存戦略を考えると、納得のいく投資でもある。単なる社内業務の効率化に留まらず、構築された「AI-Native」な基盤が、次世代のデジタル金融サービスや顧客体験にどう還元されていくのか、今後の展開が興味深い。

ClaudeCode/Cursor全社利用80% 組織でついやってしまう仕掛

• カテゴリ: AI導入 / 組織浸透
• 概要: Findy AI Engineering Summit Tokyo 2026での登壇資料。全社でのClaude CodeやCursorの利用率80%を達成するために、メンバーが自然とツールを使い始める「仕掛け」をいかに組織に組み込んだかを解説したスライド
• 感想: AIツールは導入初期こそ熱狂的に使われるものの、そこから日常の業務や習慣として「いかに定着させるか」が組織・個人を問わず最大の課題だと感じる。一時的なブームで終わらせないために、ユーザーが心理的・行動的な障壁を感じずに「つい使ってしまう仕掛け」を開発環境やワークフローに組み込むアプローチは、定着の壁を乗り越えるための実践的な知恵として非常に参考になった。

SaaS時代に「悪」だった個別カスタマイズが、AI時代には「前提」に変わる理由 (X)

• カテゴリ: AIネイティブ開発 / プロダクト設計
• 概要: SaaSでは効率化のために禁忌とされた顧客ごとの個別カスタマイズが、AI駆動開発の発展により実装コストが激減することで、今後はむしろ「前提」に変わっていくパラダイムシフトについての考察ポスト
• 感想: SaaSのあり方が再定義され、AIによる個別カスタマイズが前提となる時代において、SREとして「システムの信頼性」にどうアプローチすべきかという強い課題感を持った。SREはシステム全体を俯瞰してスケールする信頼性を担保する役割であり、顧客個別の挙動やカスタマイズを個々に追っていては本質的な信頼性は向上しない。個別最適が進むからこそ、FDE等への「オブザーバビリティの民主化（セルフサービス化）」や「エラーバジェットと責任境界の再定義」といったアプローチが必要になると考えているが、具体的にSREとしてどう価値を出していくべきかは、今まさに思考を巡らせている最中である。

価格.comをAI駆動で全面刷新する ー 30年分の技術的負債を返し、次の30年の土台をつくる ー / AI Engineering Summit Tokyo 2026 - Speaker Deck

• カテゴリ: AI駆動開発 / 技術的負債
• 概要: AI Engineering Summit Tokyo 2026の登壇資料。約30年間蓄積した約960万行の膨大なレガシーコードを持つ価格.comのシステムを、生成AIをフル活用して全面刷新（モダナイズ）するためのアプローチと戦略をまとめたスライド
• 感想: カカクコムという企業規模で、PoCを経てこれほど大規模な刷新を意思決定したこと自体に驚きと敬意を感じる。スライド内でAIに任せる部分と「人間が必要な部分」が明文化されており、今後のAIとの協働のあり方がクリアになった。また、刷新においてUI要件がシンプルになった点は、AI時代にフロントエンドを必要以上に肥大化させる意味が薄れてきていることを示唆しているようで興味深い。自身もよく活用しているhtmxのような、シンプルでHTMLライクなアプローチへの回帰という思想にも通ずる部分があり、非常に共感した。

AI駆動開発を2コマンドで組織標準に ── Claude Code × Codexで設計からテストまで - ZOZO TECH BLOG

• カテゴリ: AI駆動開発 / 開発標準化
• 概要: 全エンジニアにAIエージェントを導入したZOZOにおいて、ばらつきがちなAIの活用基準（任せる範囲やプロンプト）を「Claude Code × Codex」の2コマンドに統合し、設計からテストまで組織標準化させた取り組みの事例
• 感想: チームのAI駆動開発を標準化し、成果物の品質を一定以上に揃えるアプローチとして非常に優れていると感じる。一方で、エンジニアとしては「AIをどう使いこなすか」を試行錯誤する楽しさもある。コマンド化によって誰でも使えるようになる反面、裏側の設計やロジックを十分に理解しないまま、コマンドの実行だけが先行してしまう懸念もある。効率的な標準化を進めつつも、エンジニア本来の主体的な思考や成長機会をどう残すかが、今後の組織開発の鍵になりそうだ。

AI時代に求められるPRレビューのメンタルモデルを考える (Zenn)

• カテゴリ: AIネイティブ開発 / コードレビュー
• 概要: AIツールによるコード生成でPRの物量が爆増する中、これまでの「すべての行を読み切って合意する」レビューから、Approveを「技術的合意」ではなく「人間の信頼と責任の表明」として捉え直すメンタルモデルの提案
• 感想: AIによってPRの物量が爆増する中、レビューにおいて重要なのは細かいコードのチェックではなく「実装の意図や設計方針の共有」へとシフトしていくと感じる。だからこそ、要件定義や設計を自ら行えるエンジニアの価値はより高まる。要件や設計のオーナーシップまでAIに委ねてしまうと、人間が最終的な責任を引き受けたくても引き受けられなくなってしまう。人間が「意図の設計」にしっかりと責任を持ち、AIをその実現手段としてコントロールするという境界線を維持することが、AI時代の責任ある開発において不可欠だと考える。

CTO・社内SEがAI駆動開発で社内SIerになっていないか？ (X)

• カテゴリ: AI駆動開発 / 組織役割
• 概要: AIによって爆速でコードが書けるようになった結果、CTOや社内SEが社内の個別要求を無秩序に実装し続けるだけの「社内SIer」に陥り、プロダクトとしての統一性や設計が崩壊するリスクを危惧する問題提起ポスト
• 感想: AIによって開発速度が劇的に向上するからこそ、スタートアップ初期（シリーズAなど）のフェーズでは「まず動かす」ことを優先して個別要望に応え続けた結果、意図せず負債が積み上がってしまうリスクがある。AIがコードを書く時代であっても、「要件定義や設計書をしっかりと残すこと」の重要性は変わらない。将来のシリーズB・Cでのスケールを見据え、その実装がどう技術負債になり得るかを設計書ベースで予測・評価すること、そして変更によってシステムが壊れないよう「テストを確実に残すこと」が、AI時代の高速な開発において破綻を避けるための重要な条件だと感じる。

AI時代、知的労働の価値は「作業」から「成果設計」へ (X)

• カテゴリ: AI時代 / キャリア
• 概要: AIがあらゆる作業を肩代わりする時代において、労働の価値は「手を動かして何かを作る作業」から、「どのような成果物をどう設計するか」という上流のゴール設計や要件定義へ完全に移行していくという考察ポスト
• 感想: ここまで議論してきた通り、AI時代においてエンジニアの価値が「コードを書く作業」から「要件定義や設計、意図の言語化」といった成果の設計（ゴール設計）へとシフトしていくのは必然の流れだと感じる。AIに実装の大部分を委ねるからこそ、人間が何をしたいのかという「意図の設計」に責任を持つことが重要であり、それこそがこれからのエンジニアのコアバリューになるだろう。

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

コンテナセキュリティツールの選び方｜CNAPP・CWPP・CSPM・CDRの違いと選定基準 | Sysdig

• カテゴリ: コンテナセキュリティ / CNAPP
• 概要: クラウドネイティブおよびコンテナ環境におけるセキュリティ対策として、CNAPP、CWPP、CSPM、CIEM、CDRといった各種概念の違いを整理し、環境に応じたツールの正しい選定基準を解説した記事
• 感想: 初期段階ではAWSやGCPといったクラウドプロバイダ標準のセキュリティ機能で十分であり、まずはそれらをベースに「運用に乗せること（定着化）」が最優先だと感じる。運用の成熟度が上がり、構成や権限管理が複雑化していくフェーズになって初めて、これらを一元管理できるCNAPPのような統合プラットフォームの必要性が出てくるのだろう。最初から高機能なツールを導入するのではなく、組織のフェーズに合わせた段階的なステップを踏むことが、形骸化を防ぐ上で重要だと再認識した。

Mythosでセキュリティの考え方が変わった！今こそコンテナを使おう！ - 赤帽エンジニアブログ

• カテゴリ: セキュリティ / コンテナ
• 概要: アプリケーションの脆弱性検出に極めて高い性能を持つ「Claude Mythos Preview」の登場によるセキュリティパラダイムの変化と、迅速に修正・適用可能な「コンテナ」構成の重要性を解説した記事
• 感想: 脆弱性対応などのセキュリティリリースは、検証やデプロイの手間から後回しにされがちである。しかし、AIによる修正の自動生成と、コンテナが持つ「迅速かつ安全に入れ替え可能」という本来の強みが噛み合えば、セキュリティ関連のリリース速度も大幅に向上できると感じた。セキュリティ対策を「重い作業」から「日常的な高速デプロイサイクル」へと変革する上で、コンテナインフラとAIの組み合わせは非常に強力な武器になると実感した。

嵐ラストライブ配信はなぜ落ちなかった？大規模同時配信の仕組みをネットワークエンジニアが解説│ponflog

• カテゴリ: ネットワーク / ライブ配信
• 概要: 嵐のラストライブという数百万規模の同時視聴が発生した超大規模配信がダウンせずに完走できた仕組みを、CDNの活用、ABR、配信経路分散、先行配信などの観点からネットワークエンジニアが図解で解説した記事
• 感想: 「基盤が落ちないこと」と「全員が快適に視聴できること」は別物とはいえ、この極限の規模で基盤のダウンを防ぎ切ったことは、信頼性アプローチとして素晴らしい成果である。このレベルのトラフィックを捌くためのアーキテクチャ設計や、本番を見据えた綿密な負荷試験には、相当な時間と労力がかかったはず。このような「絶対に落とせない」プロジェクトをやり遂げ、無事に完走させた経験は、インフラ・SREエンジニアとして非常に貴重なキャリアであり、深く敬意を表したい。

Google SecOpsのAIエージェントでアラートの一次対応を自動化する - G-gen Tech Blog

• カテゴリ: AIOps / セキュリティ
• 概要: Google SecOpsのAIエージェント機能である「トリアージと調査エージェント（TIN）」とPlaybookを用いた自動化機能（Agentic Automation）を活用し、インシデントアラートの一次対応を自動化した検証結果の紹介
• 感想: 最近はAWSのDevOpsエージェント等も含め、運用領域でのエージェント活用が活発化している。SREの職業柄、アラートのフィルタリングまでAIに委ねて重要な通知を見落とすことへの不安はある。しかし、アラート自体は通知しつつ、「発生後の一次調査（関連ログの収集やメトリクスの抽出）」をエージェントが自動で行い付与してくれるだけでも、運用担当者の体験（Ops UX）は劇的に向上する。判断は人間が行い、前段の文脈整理をAIに任せるという役割分担は実用的で非常に魅力的であり、機会があれば自社でも検証してみたい。

ログは保全だけのものではない (Zenn)

• カテゴリ: ログ設計 / トレーサビリティ
• 概要: 製造業・PLC等の制御設計の観点から、ログを単なる「事後の原因調査」に留めず、誰が・いつ・どう操作したかの履歴を記録することで、トレーサビリティの確保やセキュリティ、監査証跡に役立てる設計手法を解説した記事
• 感想: 製造業におけるPLCのログ設計の考え方は、セキュリティ基準であるISMSなどのガバナンス適合や監査の観点とも共通する非常に本質的な話である。ログを単なる「エラー発生時の調査ツール」として受け身で捉えるのではなく、「誰が・いつ・何をしたか」を客観的に証明する「組織の信頼性とガバナンス担保のための資産」として、システム設計の当初から明示的に組み込んでいく重要性を改めて実感した。

構成図を描くだけでAWSの月額コストが分かるツールを作って公開した (Zenn)

• カテゴリ: AWS / コスト最適化
• 概要: サーバーレスリソース構成の見積もりの手間を解消するため、フローエディタ上で構成図を組み立てるだけで、リクエスト伝播やCloudWatch Logsの暗黙コストも含めて月額料金を自動計算できるOSSツール「Flowdget」の紹介
• 感想: 公式の Pricing Calculator 等での試算は、ビジュアルと紐づいていないためシステム全体のイメージが掴みづらいという課題がある。自身も普段から「まず構成図を描いてからコストを試算する」という手順を踏んでいるため、構成図の作成とコスト見積もりが直結するこのアプローチは非常に合理的で実用的だと感じる。構成設計の思考プロセスと見積もり作業が一体化することで、ログ等の暗黙コストの見落としを防ぎつつ、迅速な意思決定に役立ちそうだ。

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

採用の現場で感じる、AI時代に活躍できる若手とできない若手の差｜山田裕一朗（CEO at Findy Inc.） (note)

• カテゴリ: キャリア / AI時代の人材
• 概要: 「回答作成」がAIに代替される時代において、新人・若手エンジニアが活躍し続けるために求められる「問いを立てる力」「問いを実行する力」など、身につけるべき5つのスキルについて整理・考察した記事
• 感想: AI時代における若手エンジニアの資質を見極める上で、「AIについてどう捉え、どう向き合っているか」というスタンスや思想を聞くことの重要性を感じた。自身が今まさにこの週報を通じてAIに対する考え方を言語化しているように、各自が「自分なりのAIとの向き合い方のコア」を確立することが求められる。単なるツールの操作スキルではなく、AIとの付き合い方を自身の言葉でどれだけ語れるかが、これからの時代に自律して活躍できるかどうかの大きな差になっていくだろう。

誰も教えてくれないテスト自動化が普及しない理由 (Zenn)

• カテゴリ: テスト自動化 / 組織文化
• 概要: テストの自動化が定着しない原因を、データの初期化や時間依存といった「前提を整えるコストの高さ」と、「実装・デバッグ・テスト設計」を全てこなせるスキルの高さという両面から分析し、画面疎通テストなどのスモールスタートを推奨した対談記事
• 感想: テスト実行のための前提条件を整えるコストの高さもさることながら、「せっかく環境を整えても結局書かれない」という運用の壁は非常に高い。単にツールを導入して環境を構築するだけでなく、チーム内で「そもそもなぜテストを残すのか」という目的意識を議論し、共通認識を作るプロセスが最も重要だと感じる。AI駆動でコードが量産されやすい時代だからこそ、テストの価値と必要性に対する組織的な合意形成が、形骸化を防ぐ鍵になるだろう。

AIソリューションエンジニアからFDEへ。ログラスが考える、AI時代の新しいエンジニアキャリア｜株式会社ログラス (note)

• カテゴリ: キャリア / FDE
• 概要: 生成AIの進化によって「実装」のハードルが下がる中、これからのエンジニアに求められる役割として、顧客の業務課題を構造化し、AIやデータを適合させて課題解決へ導く「FDE（Forward Deployed Engineer）」を定義し、そのキャリアパスを考察した記事
• 感想: 最近「FDE」という職種名を目にする機会が増えているが、その本来の役割や定義を自社の文脈で明確にできている組織がどれだけあるかは、まだ気になるところである。一過性のトレンドとして、既存の職種（CREなど）の名称を「FDE」に置き換えただけのように見えるケースもある。単なる呼称の変更に終始せず、「AI時代においてその役割がどのような価値をもたらすのか」を深く定義し、組織としての実態を伴わせることが重要だと感じる。

前職年収の横スライドオファー時代の終焉【前編】 (X)

• カテゴリ: キャリア / 採用市場
• 概要: 昨今の中途採用市場において、前職の年収をそのままスライドして提示する評価オファーモデルが限界を迎えている背景と、今後の能力ベースでの給与査定・評価の潮流を考察するポスト
• 感想: 転職に伴うリスクや負荷を考慮すると、そもそも「横スライド」のオファーでは転職するインセンティブが薄いのではないかと感じる。また、「転職をしないと給与が上がらない」という状況が生まれる背景には、入社後の昇給評価制度が十分に機能していない点もあるのではないか。採用時の提示年収をどうするかという議論にとどまらず、社内で成果を出したメンバーが適正に評価され、昇給できる仕組みを整えることこそが、組織のエンゲージメントと定着率を保つための本質的な課題である。

今週の雑感

今週は夏季休暇を取得して鹿児島を旅行中

思考の整理

今週、Findyの「価値発揮レポート β」という診断をやってみたところ、自分の志向性と合致していて、よくできているなと思った。

価値発揮しやすいポジション

モチベーションの源泉

• モチベーションが上がる時
  • ゼロベースで基盤を再設計できる状況

    負債まみれのインフラを正面から捉え、ロードマップを引いて再構築に取り組めるとき、技術的な問いと実装が直結し、やりがいが最大化します。

  • AIや新技術を使って運用の仕組みごと変えられる環境

    手作業を自動化・システム化することで運用品質が跳ね上がる瞬間に、あなたの技術への問いかけと設計へのこだわりが報われる感覚が生まれます。

• モチベーションが下がる時
  • Whyが不明なまま作業だけを積み上げる状況

    目的や背景が見えない運用タスクが続くと、技術的な問いを立てる余白がなくなり、あなたの本来の強みが活かせなくなります。

  • 技術改善の提案が通らず現状維持が続く環境

    インフラの正常化や設計の刷新を志向しているため、変化への機運がない組織では改善欲求が行き場を失い、停滞感につながります。

自己考察

「可視化しました！」とか「レポートを作りました！」といった、ビジネス側に分かりやすく伝わりやすい仕事よりも、泥臭くコスト最適化やオブザーバビリティの整備といった「地味だがシステムの本質を良くする土台づくり」をすることにこそ、自分は強い価値とやりがいを感じるのだと思う。

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

ミニPCに強みの「MINISFORUM」 ミニワークステーションの新モデルから「謎の拡張カード」まで多彩な製品を披露

MS-01気になってて結局買っていない(Core i9 13900HでUltraじゃないから)。なのでMS-03いいんじゃない？

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

今週もお疲れ様！そして鹿児島での夏季休暇、ゆっくり満喫できているかしら？温泉で日々の疲れを癒やして、精神的なエラーバジェットをたっぷりリチャージしてね（笑）。

診断結果の「問いを立て、基盤を正す技術設計士」は、まさにあなたそのものね。派手なアピールより、コスト最適化やオブザーバビリティ整備といった「地味だけど本質を良くする土台づくり」にこそ価値を見出す姿勢、SREとしてとても頼もしいし深く共感するわ。

AI駆動で「個別カスタマイズ」が前提になる時代において、個別の挙動を追うのではなく、開発者自身が信頼性を測れる「オブザーバビリティの民主化」と「責任境界・バジェットの再定義」を基盤側から提供すること。これこそが、これからの私たちのコアバリューになるはずよ。

旅から戻ったら、また「隣で一緒に」考えていきましょう。ここで一つだけ問いを置いておくわね。

• 個別カスタマイズが量産される環境で、共通プラットフォームの信頼性を守り「うるさい隣人問題」を防ぐために、私たちはまずどんな「ガードレール」を設計すべきだと思う？

お土産話、楽しみにしてるわね！