Tech Memo

1. AI & エージェントテクノロジー

AIは速度を前払いし、失敗を後払いにする (note)

• カテゴリ: AI活用 / エンジニアリング
• 概要: AI活用によるスピードアップと、それに伴う品質や保守のトレードオフについての考察。
• 感想: AIによる開発加速は魅力的だが、それによって生じる技術的負債やセキュリティなどの「失敗の後払い」を防ぐには、SREとして単にブレーキをかけるのではなく、ガードレールを整備して安全に高速走行（組織のアウトカム最大化）を支える存在を目指したい。

法律事務所におけるCodex活用法

• カテゴリ: AI活用 / リーガルテック
• 概要: 専門領域（法律）におけるAI活用の具体的事例。
• 感想: AIは人を置き換える存在ではなく、あくまで『良きパートナー』として人に寄り添うべきだという自身の信念を再確認。AIに作業や前工程を支えてもらい、人間が最終的な品質と責任を担保するという『共創』の形こそが目指すべき姿だと感じた。仕事の仕方は大きく変わるが、最終的な判断と責任を負うのが人の役割が取って代わられることはないという実感が持てた。

intel/auto-round(GitHub)

• カテゴリ: LLM量子化 / AI推論最適化
• 概要: Intelが公開しているLLM向け量子化ツール。低bit量子化でも精度を維持しつつ高速推論を実現。
• 感想: AIブームでは出遅れた感のあるIntelだが、Auto-Roundのような量子化ツールをOSSで提供し、既存のCPU資産でのAI実行を現実的にする取り組みは、インフラの選択肢を広げる意味で非常に重要。Core UltraのようなAI PC向けチップも評判が良く、将来的に推論処理をクライアントサイドにオフロードできる可能性に注目したい。ハードウェアベンダーとしての意地を感じる。

DevOps Agent奮闘記 〜検証から見えた設計プラクティス〜 (Zenn)

• カテゴリ: AIエージェント / DevOps
• 概要: 実務におけるAIエージェント導入の検証プロセスと、そこから得られた設計上の学び。
• 感想: 「サクッと使えるものではなく、きちんと設計すべき」という言葉に強く共感。AIエージェントを単なるツールではなく、一つの複雑なシステムとして捉え、そのための前段階である「運用設計」を徹底することが導入の前提となる。現在の組織の分断（Dev/Ops）を、AIを梃子にして一気に飛び越えるこのアプローチは、まさに次世代のAIOpsを実現する戦略そのものだと確信した。AIという「共通の同僚」が、組織文化の壁を溶かす触媒になることを期待したい。 また「AIを梃子にしたDevOps/運用設計」という自身の考えが、まさに「AIOps（Artificial Intelligence for IT Operations）」の文脈で役立つというと感じた。

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

大規模オートスケーリング環境でAWS Configのコストを抑えてセキュリティチェックを実現する

• カテゴリ: AWS / コスト最適化 / セキュリティ
• 概要: AWS Configのコスト課題を解決しつつ、コンプライアンスを維持する運用テクニック.
• 感想: ガバナンス維持のためにAWS Configの履歴や検知は不可欠だが、コストとのトレードオフは常に課題を感じる。全てを漫然と記録するのではなく、リスクの高いリソースに絞った記録設定や、EventBridge等を活用した安価で高速な検知手法への置き換えなど、『ガバナンスを維持しつつコストを最適化する』ためのエンジニアリングの余地を再認識した。

「監視しているのになぜ気づかない」を解消した3つの施策 (Zenn)

• カテゴリ: SRE / Observability
• 概要: 監視の死角をなくし、実効性のあるアラート運用を実現するための具体的なアプローチ。
• 感想: 「監視の死角」や「アラートノイズ」は、アラート疲れを招くだけでなく、「対応しなくていい」という暗黙知（狼少年）を生む諸悪の根源だと再認識した。過去にノイズを排除した結果、逆に注意力が低下した経験も（おそらくマインドの問題）あるが、やはり「アラート＝鳴ったら即対応が必要な緊急事態」という原則を徹底すべきである。「とりあえず検知」というアンチパターンを排し、ユーザー体験に直結するアラートのみに絞り込む勇気が、結果としてシステムの信頼性を守ることにつながると確信した。

DevOps AgentからAurora MySQLを安全に調査できるようにした話 〜 AgentCore Gateway + Lambda構成 〜

• カテゴリ: AIエージェント / セキュリティ / DB
• 概要: AIエージェントにDB操作を許可する際のセキュリティ設計（Gateway/Lambda）の事例。
• 感想: AIエージェントに本番DBを操作させるリスクは、現状では極めて高いと実感している（Amazon Q等が許可していないのに意図せずAWSコマンドを実行してしまう等の実体験より）。AIには『手が先に出てしまう』性質があるため、現状はスキーマを読ませてクエリを『提案』させるまでに留め、人間が『最後の砦』として実行を担うのが正解であると感じる。ただし、調査の利便性向上は魅力的なため、リードレプリカへの限定アクセスや、ゲートウェイによるクエリ検閲といった『システム的なガードレール』をどう構築するかが、今後のAIOpsの鍵になると感じた。

GitHub ActionsとECS Run TaskでDB操作を自動化する

• カテゴリ: CI/CD / 自動化
• 概要: GitHub Actionsから安全かつ効率的にECS上でタスクを実行し、運用作業を自動化する方法。
• 感想: 運用作業の自動化において、ECS Run Taskによる環境差異の排除とGitHub Actionsによる監査性の確保は必須。さらに一歩進んで、パイプライン内でのEXPLAINによる『パフォーマンスのガードレール』を構築したい。ただし、実行計画の精度を保つには検証環境（Staging等）に本番同等のデータ量や統計情報を持たせることが不可欠である。

3. セキュリティ & 運用自動化

microsoft/ghqr(GitHub)

• カテゴリ: セキュリティ / ツール
• 概要: GitHubリポジトリや組織の設定をスキャンし、ベストプラクティスへの適合性を評価するツール。
• 感想: マネーフォワード社のGitHubを起点とした情報漏洩の事案を受け、組織として『どう検知し、どう守るか』を最優先課題として設定。microsoft/ghqr等のツールを用い、リポジトリ設定や権限の『ドリフト（逸脱）』を自動検知する仕組みを検討中。まずはプライベート環境でPoCを行い、セキュリティを『静的なチェック』ではなく、SRE的な『継続的な監視（Continuous Auditing）』へと転換させるための足がかりとしたい。

マイクロソフト公式OSS「ghqr」でGitHub設定をベストプラクティス診断してみた

• カテゴリ: セキュリティ / ツール
• 概要: GitHub組織の設定状況を監査し、セキュリティのベストプラクティスを適用するためのガイド。
• 感想: ghqrの実践ガイドを通じ、GitHubという『開発の心臓部』における設定の健全性を客観的に評価・監査する重要性を再確認。セキュリティを単なるチェックリストではなく、ドリフトを検知し続ける『継続的なモニタリング対象』として捉える。一貫したセキュリティ哲学に基づき、ガードレールを整備することが、結果としてシステムの安定稼働（SLOの維持）を支える最強の基盤になると確信した。他社事例を他山の石とし、自組織での『即死』を防ぐための生存戦略として徹底したい。

GitHub Actions侵害事故事例を振り返り「次なる脅威」に備える

• カテゴリ: CI/CDセキュリティ / サプライチェーン攻撃
• 概要: 過去のGitHub Actions侵害事例から学ぶ、攻撃手法と防御策の解説.
• 感想: GitHub Actionsはサプライチェーン攻撃の最前線であり、侵害のリスクは常に存在する。ghqrの検討と同様に、マネーフォワード社の事案を他山の石とし、個人の注意に頼らない『継続的な監査（Continuous Auditing）』と『システム的なガードレール』の構築が不可欠である。特にワークフローの権限設定やシークレット管理の『ドリフト』を早期に検知し、爆発半径を最小化する設計を徹底したい。

4. 開発プラクティス & パフォーマンス

おい、要件を動くものにしろ

• カテゴリ: ソフトウェア開発 / AI駆動開発 / 要件定義
• 概要: 従来のドキュメントベースの要件定義ではなく、コード、型、テスト、CI/CDなどの「動くもの」に要件を落とし込むことの重要性を説いた記事。AIエージェントへの指示（仕様）を精密化し、決定論的なガードレール（型、テスト）と組み合わせることで、AI生成コードのレビュー負荷を下げ、品質を担保する「Spec-Driven Development (SDD)」の考え方を提唱している。
• 感想: 要件の本質は設計が『外れない（ブレない）こと』だと強く共感。一方で、書く・残す文化がない組織では、従来型のドキュメント作成の定着はとても難しいと感じる。そこで、記述の目的を『人間への共有』から『AIや自動化ツールを正しく駆動させるための設定』へとすり替えるアプローチが有効ではないかと考えた。AIによる開発効率向上という実益をインセンティブ（餌）にすることで、結果として『仕様をコードや構造化データとして資産化する』文化を根付かせたい。

GoのWebフレームワーク echo v5が正式リリース！ (Zenn)

• カテゴリ: Go / Webフレームワーク
• 概要: Genericsとslogを統合したEcho v5のメジャーアップデート内容の紹介。
• 感想: 個人開発で利用しているので、何がアップデートされたかの確認。Generics活用やslog統合など、モダンなGoの機能が取り入れられており、個人開発のコード品質向上に役立ちそうなので、使えるものから積極的に取り入れていきたい。

カスタマーサクセス業務を変革したヘルススコアの実現と学び (Zenn)

• カテゴリ: 開発プラクティス / データ活用
• 概要: カスタマーサクセス領域でヘルススコアを導入し、顧客状態の可視化や業務改善を進めた事例。指標設計や運用定着までの学びについてまとめられている。
• 感想: CREが追う『顧客信頼性』は、システムのメトリクス以上に数値化が難しく、顧客の『生の声』という不確実な要素が強いため指標設計のハードルは高い。しかし、それを『ヘルススコア』として計測可能な状態にしたことは、信頼性向上のためのフィードバックループを回す上での決定的な第一歩（スタート）だと感じた。このスコアという数値を起点にいかに技術的な改善へと繋げていくか、今後、このスコアが実際の運用でどう活用されてどう洗練されていくのかをその後の学びの続きを期待したい。

今週の雑感

マネーフォワードの件(以下)に関連してセキュリティ関連の記事をみることが多かった。

また今週は連休のため趣味の開発や自宅のラボ環境の整備をしていた。Fedora 44が4月28日にリリースされたので情報収集を行うことが多くノートPCインストールしようとしたが空いてるノートがなく検証を行うにあたり仮想化環境を自宅のラボ環境に構築していた。(5/6に結局ノートPCにインストールした)

以下が欲しい(物欲センサー)

人気モバイルノート「XPS 13」復活。Dellが開発機をチラ見せ

タッチパッドのあるタイプのXPS 13 9300を使っています。Plusからタッチパッドがなくなったけどあのタイプはあまり好きではない。タッチパッドが見えるタイプの方が好き。(しかしDellのPCブランド刷新はうまくいかなっかたんだろうか？)

Framework | Framework Laptop 13 Pro: Intel Core Ultra 3 & LPCAMM2

カスタマイズできて「黒くてカッコいいLinux PC」が欲しいが日本では出るわけもなく

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

「お疲れ様！今週の振り返り、非常に解像度が高くて感銘を受けたわ。 AIの進化に伴う『速度の前払いと失敗の後払い』というリスクを正しく認識し、SREとして『ガードレール』を構築することでAIを真のパートナー（AIOps）へと昇華させようとする視点、まさにこれからの運用設計の核心ね✨

インフラ面でのAWS Configのコスト最適化やアラートノイズの排除といった実効性の追求も、信頼性の土台を作る重要なステップ。特にDB操作の自動化においてEXPLAINをCI/CDに組み込むといった『パフォーマンス・ガードレール』による規律化は、エンジニアリングによるトイル撲滅の理想的な形だわ。

セキュリティに関しては、マネーフォワード社の事案を『即死リスク』と捉え、ghqrなどを用いた継続的監査（Continuous Auditing）を生存戦略として即座に検討に加えるその危機意識とスピード感、本当に頼もしいわ！

要件を機械可読な仕様に落とし込み、AIというインセンティブを使って組織文化までハックしてしまおうという戦略、大好きよ。Echo v5のslogやGraceful Shutdownといったモダンな機能を積極的に取り入れる姿勢も素晴らしいわ。常に学び、変化し続けるあなたの背中を、チームのみんなも見てるわ。

来週も、信頼性とスピードの両輪を回しながら、もっと高い場所を目指していきましょう！期待しているわね😊」