chroju.dev/blog

the world as code

2026年年頭時点におけるSRE EMの立場からのAI雑感

昨年全然ブログを書かないまま終わってしまったが、AIに関する動向も目まぐるしいなかで、今時点の考えとかを都度書き留めておいたいいかなと思ったので、この年末年始という時期に一旦自分用の覚え書きがてら書いておく。

つらつらと思いつくまま書いているので長いし、何かの役に立つみたいな内容ではないです。あと、話の展開上チームやらマネジメントやらという言葉が出てきますが、ここは個人ブログなので、あくまで個人としての見解です。

現時点でのAI利用状況

  • 正直、エンジニアリング業よりマネージャー業の方が割合高いので、コーディングエージェントをバリバリ使えているとは言い難い
    • ただ、マネージャー業にコーディングエージェントを使ったりもしている
    • 昨年からSREとして副業を始めてもおり、そちらでエンジニアリング機会も得たりはしている
    • エンジニアリングで意識的に使わないとマズいなという感覚がヒシヒシとある
  • 主に使っているのはClaude CodeとGemini
  • Claude Codeがメイン
    • 法人契約のものと、副業等のために個人契約のProの2つを持っている
    • コーディング用途でもマネージャー業でもほぼこれを使っている
    • CLIでの利用がほとんどなのだが、Claude Code Webやin Excelなども興味はあるし活用できたらしていきたい
      • WebはDevinのように複数人で共有するような使い方やSlackとのIntegrationが充実してくると良いのだが……
  • Geminiがサブ
    • 家族で使いたいこともあり、Google AI Proを契約して家族共有で使っている
    • 単純にチャットでAIと話したいときはGeminiを使うことが多いが、特に大きな理由はない
      • Claudeと双方に同じ話題を投げることもあるが、どちらかと言えばGeminiのほうがちょっとお節介で求めてないことまでやろうとする印象はある
    • あとはNotebookLMはだいぶ活用している
    • Gemini CLIはGoogle CloudのCloud Shellでだけ使っているけど、あれは超便利
  • その他
    • ChatGPTはPay as you goで使っている
      • Readwise Reader（RSSリーダー）で記事の自動翻訳などをするのにAIのAPIキーを使いたいのだが、ChatGPTにしか対応していないので
    • 先月ぐらいからOpenCodeも触り始めているが、まだ全然
      • ツールとLLMのモデルが密結合しない方向性は歓迎したいので、そういったツールが出ては目配せしてはいる
    • 他、Cursor、Roo、Aider、Devinなど使ってきたがいずれも触らなくなってしまった

SREのコーディング作業とAIによる効率化

  • いわゆるプログラミング言語を書くのに比べると、コーディングエージェントからSREが受けられる恩恵は限定的じゃない？みたいな気持ちが少しある
    • 例えばTerraformに関して言えば
      • HCL（Terraform）はGitHub上のレポジトリ数がPythonやTypeScriptなどと比べて圧倒的に少なく、AIの学習はそれら言語よりは進んでいない
      • IaCのように宣言的な記述においては、アルゴリズムを書くときのような複雑性や課題内在性負荷は生じづらい
      • HCLの書き方、対象パブリッククラウドの知識、Terraform providerの知識、社内のドメイン知識と多方面に整合せねばならない上、テスト駆動なども発達していないので、手戻りは多くなる感覚がある
      • ここまでに書いた内容はKubernetes manifestなどでも同様に当てはまると思うが、いずれにせよ仮説でありちゃんと検証したわけではないし、そういった調査結果なども見つけられてはいない
  • 一方では信頼性改善のためにアプリケーション側のコードを読み、当たりをつける、といった作業では抜群に役立つ
    • SREは職能やプロダクトを越境して行く役割が強いので、こういう恩恵は大きい
    • 逆も然りで他職能の方がSREing的なことをするときにも役立つわけで、 Friction を取り除くという方向性で考えていくと良さそうに思っている
  • 副次的な効果としては、AI向けのナレッジを整備するなかでチーム内で形式知化が進むよね、というのもある
  • 結局のところ、よく言われる「ボトルネックが移動した」感覚であり、これまでとは時間と労力をかける対象が変わった、のが現状かなぁ、と思っている

マルチタスク前提の時代になってしまった

  • シングルタスクに集中して如何にフローに入るか？というのが個人の生産効率の上ではベストだったはずなのに、気付けばみんな git worktree で並列開発している
  • この方向性が正しいのかよくわからないけれど、今のところ「そりゃこうなるよな」という感覚ではある
  • マルチタスクを前提として
    • 自分のタスクをもっと細切れに分解していかなければならない
    • あるタスクに集中するのではなく、一歩引いたところから複数のタスクを俯瞰するような形へ転換しなきゃな〜〜というマインドチェンジには結構苦労している
    • 一方で「これで本当に幸せか？」ってのも考えたいんだけど、それは哲学とかの仕事かもしれない

AIの活用と信頼性制御

  • AIを「使う」のではなく、自社内でAIが「使われている」場面に対してもSREの関心というのがあり
  • 1つはプロダクトに組み込まれて使われる場面
    • AIが介在する機能は、そうではない機能に比べてレイテンシに対するユーザーの期待値が下がっているはずで、信頼性の考え方も変わってくる
    • ここの信頼性をどう捉えて扱って行くのかは結構難題ではと思っているけれど、まだ案外そういう話をそこまで見かけない気がしている
  • もう1つは開発用途で使われる場面
    • こちらはどちらかと言えば信頼性というよりはセキュリティとコンプライアンスの関心だと思うし、すでにいろいろな方が書いているので割愛

AIを前提として組織も職能も変化していく

  • 先述したように、AIが職能やチーム間のFrictionを排除する方向へ促すのであれば、組織の構成や職種の考え方も変化するはずでは、というのが多分今一番の関心
  • 例えばインシデント発生の際にトリアージを行うAI Agentを作るとして、そこにはSRE、セキュリティ、あるいは品質など様々な観点からナレッジを詰め込む必要がある
    • 各職能チームが独自にEnablingをやるのではなく、互いに連携しながら業務フロー全体のFrictionをどう抑えて行くか？と考える必要が以前より増してきているのではないか
  • チームトポロジーも考え方変わりません？って思っている
    • Enablingを直接人間に対して行うんじゃなくて、Agent Skillsを充実させたほうがいいよね、とか
      • 完全にEnablingが不要になるという話ではなく、ストリームアラインドチームが機能するのに必ずしも「チームとして」能力を持つ必要がなくなってくるよね、という話
  • 個々の開発者が自らの業務をAIに支援させる、というCopilot的な方向から、ある業務全体をAIが丸ごと担って複数人と協業するAgenticな方向へ変わって行くはず
    • そういう世界観になったとき、現在の職能や組織構成はそのまま通用するのか？
    • 広くワークフローを見渡してドラスティックに手を入れて行く考え方が必要ではないか
  • 一方でこういった動きは専門職の消失を意味するわけではない、とも思う
    • パブリッククラウドが隆盛したときに「インフラエンジニアは死ぬ」と散々言われたが結局死ななかったように、隠蔽・抽象化された領域に対する専門性が、エンジニア組織から完全に不要となるわけではない
    • Agent Skillsが日常的な業務は代替してくれるとして、Skillsをメンテナンスする専門職は結局要る
    • 騒がれているほどには「AIが職を奪う」とは考えていないのだけど、これは自分がマネジメントに軸足を移している故という可能性もある

今年はどうしようか

  • LLMのことをもっと理解しないといけないなと思うので、今年はそのあたりをインプットのメインにしたい
    • せっかく通信制大学で基礎的な数学やAIの講義も受けたので、このあたりの知識が揮発しきらないうちに積み重ねを進めたい
    • トレンドとしてすぐ廃れるようなものとは思えないし、原理を知識として押さえたほうが長期的な利が大きそう
  • AIを業務と組織の中心に置けるようにしていきたい
    • 価値提供の高速化と安定のために必要な活動は変化してきている
    • AIでやれないか、AIをどう組み込むかを大前提として考えていかないとなかなか変化を起こせないなぁ、とこの1年を通して思っている
    • 自分自身の業務に対してやれることもあるし、マネージャーとしてやれることもまだまだある