SRE NEXT 2026に参加した

今年もスタッフをやっていました。去年と違って役割的なものはなかったので当日は廊下をフラフラしたりセッションを見たりサイン会を突発でやったりスポンサーブースにとつったりをしていました。その中で気づいたことをつらつらと書いていきます。

SREのAI活用

観測範囲で使っていない人はいなかったが使っている領域は結構様々だったなと思います。コーディング部分だけを任せている人やクラウド操作の補助というケースが多い中で全てをAIでやっているという人もいました。信頼性を高めるよりもまずは機能開発重視でやっているらしく本番で検証というスタンスの場合はアプリもインフラもどっちの実装もAIにやらせた上で運用もAIにしてしまうことが可能な世界なようです。超アーリーフェーズであればそもそもユーザーが1人とかであるのでこういうパターンもありなんだなと気づきました。

アイディアを持った人がシステムをまるっと数日で作れる世界で且つ運用もそれなりに出てきるとなると競合が一瞬で生まれてくることも増えるだろうしそういうところに勝っていく必要があるんだなと改めて感じました。

未知の未知

これも若干話したこと。既知の未知とか既知の既知の課題はAIに聞けば一瞬で解いて枯れるので未知の未知、仮説を立てて進めていくための能力が必要だよねという話をした。仮説を立てる->実験する->新しい知見を生み出す みたいなサイクルを回していく必要がある。エンジニアの価値はコードを書くことではなく、まだ誰も答えを知らない問いを発見し、検証するになっていく。大変ですね...

SREの採用

SREが持つスキルはAIに依って委譲がしやすいので採用は減るのかなと思っていたのですがそんなことはなさそうだと感じました。

o11yを設計時点で取り込んで障害対応もAIで自動化されていく世界になって1社あたりのSREは少人数化するのかなと思っていたのですが採用の話とかを聞いていてもそうではないようでした。ビジネス的に正しく動いていないことに気づくのに必要なo11yの実装、信頼性を上げるためのシステムリアーキテクチャ、SLI/SLOを組織で実践していくためのコミュニケーション。そういったSREが必要だよねみたいな話をしていました。同時に元々SREってそういう人たちなんじゃないんだっけ？ともなりました。トイルの改善やインフラ仕事というのはもうAIで代替していってより難易度というか調整が必要なタスクをやれるようになったという背景があるじゃないかなと思っていたりします。

作らない・閉じる大事さ

AIで早く作るは簡単になったがじゃあ運用誰やるんだという話ですね。DBのマイグレーションやらEKSのアップデート。LLMのEoL対応などAIにそのまま投げれるわけではないものがある以上誰かしらが運用の面倒を見る必要があります。大量に作られていくとそれだけ運用の手間がかかっていきます。何かを作らないという判断や作ったけど運用に手を回せないなら閉じるという判断が必要だよねという内容ですね。

地域コミュニティ

Tamachi.sreとして地域のSREコミュニティ事情について話す会というのを企画しました。広島、京都、福岡のそれぞれのコミュニティの主催の方とtamachi.sre、SRE NEXTから登壇をしてもらいました。SRE NEXTではRoad to SRE NEXTというのをやっていて地域でコミュニティができると嬉しいよねという話をしていたりしてどんどんと広まっていって嬉しい限りでした。

blog.sre-next.dev

終わりに

コミュニティからしか得られない何かを改めて感じた2日間でした。いいですね。

自作プログラミング言語を始めた

github.com

いつかやってみたいと思っていた自作プログラミング言語を先月くらいから始めてみました。rw という言語で作者の名前から取っています。コードを書いてるのはほとんどがCodexでレビューにClaude Codeや壁打ちにはGeminiとChatGPTでやっている。

Python みたいに書けて、ネイティブバイナリになって、しかも非同期が言語の一級市民という私が欲しいと思っていたものが入った欲張りな言語という感じです。fiber ランタイムとかLLVM IR 生成みたいなところをざっくり解説していきます。

コンセプト

• 見た目は Python — インデント構文、def、elif、and/or/not、true/false
• 中身はネイティブ — LLVM をバックエンドに使い、macOS arm64 / Linux x86_64 のネイティブ実行ファイルを吐く
• async がファースト — spawn / await と Future[T] が組み込みの一級市民

コンパイラ本体は Python（rwc/、llvmlite 使用）、ランタイムは C(と一部アセンブリ)で書かれています。言語処理系自体は読んだり授業で聞いたくらいのど素人なので先人とかも多かったりして情報には事欠かない気がしたのでこんな感じになっています。

Hello world

Hello, world はこうです。

  def main() -> int:
      print("hello")
      return 0

再帰のフィボナッチも、見慣れた形で書けます。

  def fib(n: int) -> int:
      if n < 2:
          return n
      else:
          return fib(n - 1) + fib(n - 2)

  def main() -> int:
      print(fib(20))
      return 0

実行はこんな流れです。

  rwc run examples/fib.rw        # コンパイルして即実行
  rwc build examples/fib.rw -o fib   # ネイティブバイナリを生成
  rwc emit-ir examples/fib.rw    # 生成された LLVM IR を覗く
  rwc emit-ast examples/fib.rw   # AST を覗く

emit-ir / emit-ast で内部を覗けるので結構学びがあったりします。

非同期処理

rw の推しは、非同期処理が後付けライブラリではなく 言語そのものに組み込んでる点です。

  def add(a: int, b: int) -> int:
      return a + b

  def main() -> int:
      fu: Future[int] = spawn add(3, 4)   # 非同期タスクを起動
      r: int = await fu                   # 結果を待つ
      print(r)
      return 0

spawn 関数(引数) で Future[T] が返り、await で結果を取り出す。これはPythonのasyncioというよりかは内部的にも書き方的にもGoのgoroutineとかに挙動は近いかなという感じです。

  def square(n: int) -> int:
      return n * n

  def main() -> int:
      f1: Future[int] = spawn square(1)
      f2: Future[int] = spawn square(2)
      f3: Future[int] = spawn square(3)
      total: int = await f1 + await f2 + await f3
      print(total)
      return 0

みんな大好きTCPサーバもこんな感じでかけます。高スループットな I/O を、ブロッキングっぽい素直なコードで書くことができます。

  def handle_client(fd: int) -> int:
      while true:
          b: Bytes = read(fd, 4096)
          if len(b) == 0:
              close(fd)
              return 0
          write(fd, b)
      return 0

  def main() -> int:
      listen_fd: int = tcp_listen(8080)
      while true:
          client: int = tcp_accept(listen_fd)
          spawn handle_client(client)   # 接続ごとに軽量タスク
      return 0

まだ足りない機能

実装したい機能はたくさんあります。まずGCがないのでロングランには向いてないです。TCPサーバとか動かす前にやっておかないとOOMで死にますw

あとは以下もないです。欲しいがPythonの書き方があまり好みではないのでどうすると良いのかみたいなのを考えていたりします。

• クロージャ / ラムダ（ネスト関数も不可）
• デフォルト引数 / 可変長引数 / キーワード引数
• メソッド・ドット記法（obj.method() — struct がないので原理的に不可）
• 複数戻り値・タプル展開（x, y = f()）
• f-string / 文字列補間、デコレータ、with 文
• import
• エラーハンドリング
• タイマー
• UDP

今やっているのはrw の現在の I/O ランタイムをio_uringにしようかなとかそういうのをやっています。絶対に順番が違う気がするがやはり興味があるところからやっていかないと続かない気がするのでそんな感じです...

東京楽しすぎる話

引っ越して1ヶ月くらいが経った。感想は東京楽しすぎてやばい！楽しい！やばい。という感じ。住んでるのは埼玉だけど週5くらいで東京に遊びに行っている。池袋、新宿、渋谷あたりが好きで特に用事はないけど行ったりしている。東京タワーに登ったりスカイツリーに登ったり車でレインボーブリッジ渡ったり秋葉原散歩したりハチ公前集合したりして遊んでいる。やりたいことリストとかを書き出して消化しているがあと何年かかるかわからない。

今一番やりたいことはヘリにでの周遊あたり。10万くらい出せばできるらしいのでやってみたい。

skyview.airos.jp

あとは屋形船とかにも乗りたい。思ったよりこっちは安い。貸し切るとかするとやばいのかな。

yakata-fune.jp

本来の目的として出社とかテックイベントに平日参加するみたいなことがあったが全然やれていないのでそろそろ本気出してやっていく。多分。

【ポエム】EC2にsshしてデプロイ

git pushしたらテストされてきちんと正しい挙動のアプリケーションがデプロイされる。みたいな仕組みは割と当たり前だと思って生きてきた。ただ世の中にはまだEC2に入ってgit pullしてsystemcltで再起動して最新のアプリケーションコードを反映するみたいなことが必要なシステムはある。gitがあればまだ良くてzipとかをメールで共有してpatchコマンドを当てる運用なんかも存在している。

嘘だろと思うかもしれないが私はここ2~3年でそういったシステムのお手伝いを3回くらいやっている。又聞きではあるが他の人たちからも聞くので超レアな話ではなさそうだという感じである。さらにこれが10年来のシステムでメンテナンスがされてこなかったとかであればそうかとなるのだがどうやら新規構築でこういったフローのサービスに出会ったりもするから不思議である。

AIがあって簡単に運用が楽なシステムが組めるならそれでよくないかと思ったりする。実際にClaude Codeにsshしてpullするデプロイで組めないかを聞いてみるとその方法は推奨されなくてモダンな仕組みが提案されてくる。なので今このフローを組むにはモダンな提案をしてくるAIを拒否しながら実装を進めていく必要がある。これにメリットはあるのだろうか。

もちろん、すべてのシステムに立派なプラットフォームや複雑なデプロイ基盤が必要だとは思わない。小さなサービスなら、シンプルな構成でよい。ただ、シンプルであることと、手作業に依存することは違う。シンプルなCI/CD、シンプルなロールバック、シンプルな監査ログは作れる。

では、なぜそれでも手作業に依存する構成が選ばれるのか。「学習しないで知っていることでなんとかしようとする」という力が強いんじゃないかなと思っている。SSHして git pull する方法は、多くのエンジニアにとってすでに理解している操作で完結する。一方でCI/CDは、パイプライン、アーティファクト、権限、失敗時の挙動など、いくつかの概念をまたいで理解する必要がある。この差は思っている以上に大きい。

結果として、「すぐ動く既知の方法」が選ばれ、「後から整える」という意思決定がなされる。(そして多くの場合、その「後」は来ないがw)興味深いのは、AIがこの状況を変えきれていない点だ。AIはモダンな構成を提案してくるし、実装のハードルも下げてくれる。それでもなお、既知のやり方に寄せる選択がされるのは、「知らないからできない」のではなく、「学習する意思決定をしていない」からだと思う。

こう考えると、「なぜそんな運用が存在するのか」という問いに対しては、「合理的な理由がある」というより、「合理的に見える小さな選択の積み重ねの結果そうなっている」と捉える方がしっくりくるのかもしれないなとなった。

「今ある知識でなんとかするか」か「少し学習してより良い方法を選ぶか」

どちらを選んでもその場は進む。ただ、その差は時間が経つほど大きくなる。

AIがあっても、この構造自体は変わらない。むしろ良い選択肢が簡単に手に入るようになった今だからこそ、それを取りに行くかどうかの意思決定がより重要になっているのかもしれない。やはり、学習していくことは大事だなと改めて感じた。最近本を読むとかインプットへのモチベーションが減っていたけどちゃんと学んでいこう。