はじめに
こんにちは！ jinjer株式会社 SREチームの宇根です。
私は2023年にjinjerへ入社し、沖縄オフィスの一員としてQC（品質管理）を担当した後、2024年7月よりSREとして従事しています。
QCからSREというのは、一見すると異色のキャリアチェンジかもしれません。 ですが、jinjerには「挑戦したい」という意欲を尊重し、後押ししてくれる素晴らしい文化があり、私もそのなかで新たな一歩を踏み出すことができました。
そしてこのたび、私もZenn jinjerテックブログでの発信をスタートすることになりました！🎉
SRE として記念すべき第一弾となるこの記事では、私がいま最も注目し、挑戦を始めている 「SRE ✕ AI」 というテーマについてお話ししたいと思います。
🤔 私たちの環境と課題意識
詳しい技術スタックについてはまた別の機会で紹介できればと思いますが、私たちのチームでは、AWS上の多くのリソースをTerraformを用いてコードで管理（IaC）しています。 Terraformによってインフラの構成管理は大きく効率化されました。
しかし、現実にはコードの管理だけがSREの仕事ではありません。 私たちのチームには、日々開発メンバーからCI/CD関連のエラーに関する問い合わせが寄せられたり、緊急でのリソース変更依頼が舞い込んできたりします。こうした割り込みタスクへの対応は非常に重要ですが、その一方で、私たちが本来進めるべき信頼性向上のための設計や改善といった本質的な作業の進捗が遅れてしまうという課題を抱えていました。
加えて、SREとして向き合うべき課題はほかにも山積しています。
- 障害調査：ログの海から、原因究明につながる重要な一行を探し出すのが大変
- 定形作業：ドキュメント整備など、思考停止でできるけど地味に時間を奪われる作業（トイル）
など、守りの運用における課題は山積しています。
それに加え、私たちの環境特有の、より挑戦的な課題も存在します。その一つが、複数のプロダクトからログを集約する「ログ共通基盤」の改善です。
こちらは以前、福与さんが記事（ログ基盤の構築）で紹介しましたが、この基盤によってプロダクトを横断したログの一元管理が可能になりました。
しかしその一方で、Glueによる1時間ごとのバッチ処理では、新たなパーティションにログが出力された場合において、リアルタイムなログ検索をおこなう上でタイムラグが生じるという新たな課題が生まれていました。
私たちは、こうした 「日々の割り込み対応」と「将来のための技術的挑戦」、その両方を効率化し加速させるための強力なパートナーとして、AIの活用に大きな可能性を感じています。
🤝 AIはSREの"最高の相棒"になる
私たちは、AIがSREの仕事を奪うのではなく、むしろ SREが本来集中すべき創造的な仕事に時間を使えるようにしてくれる「最高の相棒」 だと考えています。
AIに任せられることは積極的に任せ、私たち人間は、
- より安定したシステムのアーキテクチャ設計
- 将来の負荷を見据えたパフォーマンスチューニング
- サービスの信頼性を開発全体に広める啓蒙活動
といった、より高度で本質的な業務に集中する。そのような未来を目指しています。
💡 私の具体的な取り組み（第一歩）
ここでは、まず私を含めたSREメンバーで試行錯誤を始めた、具体的な取り組みの第一歩をご紹介します。
1. 開発メンバーからのエラー問い合わせ対応の効率化
Slackで開発メンバーから「CI/CDがこのエラーで失敗します、助けてください！」といった問い合わせと共に、画面を埋め尽くすほどの長文ログが貼り付けられる、という光景は珍しくありません。
従来は、SREの担当者がそのログを一行ずつ目で追い、膨大な情報のなかから根本原因を探し出す必要がありました。これは非常に時間のかかる作業であり、さまざまある割り込み対応でも特に負担の大きいものでした。
そこで私たちは、この長文ログをそのまま生成AIに投入し、「このログの根本原因は何ですか。」と問いかける、というアプローチを始めました。
AIは、人間では見逃してしまうような些細なエラーメッセージや、関連する複数のログ行を瞬時に特定し、「〇〇の権限が不足しているようです」「△△のバージョン非互換が原因です」といった形で、原因の核心を突く回答を返してくれます。 このおかげで、根本原因を突き止めるまでのプロセスが劇的に圧縮され、開発メンバーへ素早く的確なフィードバックができるようになりました。
プロンプトと回答のサンプル
もちろん実際のログは掲載できませんが、雰囲気をお伝えするために簡単なサンプルをご紹介します。
- 実際に投入したプロンプトの例
以下のCI/CDのログについて、エラーの根本原因と解決策の案を3つ挙げてください。
(ここに "ERROR: Could not find a version that satisfies the requirement non-existent-package (from versions: none)" のようなエラーを含む、Dockerfileのビルドログが数十行貼り付けられていると想定)
- AIからの返答例
このログにおけるエラーの根本原因は、
Dockerイメージのビルド中（RUN pip install ... の箇所）に、non-existent-package という存在しない、またはtypoしたパッケージをインストールしようとしていることです。
解決策の案は以下の3つです。
1．パッケージ名が正しいか requirements.txt を再確認する。
2．...（中略）
3．...（中略）
このように、AIがエラーの核心を瞬時に特定してくれるため、調査時間を大幅に短縮できます。
2. VS Code拡張機能（Copilot, Bedrock）を活用したIaC・スクリプト作成支援
私たちのチームでは、多くのメンバーがエディタとしてVS Codeを利用しています。 ここにGitHub Copilotや、Clineなどを導入したことで、日々の作業効率が大きく向上しました。
特にTerraform（HCL）との親和性は非常に高く、「こういう仕様のS3バケットを作るコードを書いて」とコメントやプロンプトで指示するだけで、精度の高いコードを提案してくれます。これにより、これまでドキュメントを調べて書いていたようなリソース変更作業の時間が大幅に短縮されました。
もちろん、生成されたコードのレビューは必須ですが、ゼロから書くよりも圧倒的に早く、開発メンバーからの依頼にも迅速に対応できるようになりつつあります。
AI活用における注意点とコツ
もちろん、AIは万能ではありません。時には見当違いの回答をすることもありますし、生成されたコードに潜在的な問題が含まれている可能性もゼロではありません。AIからの提案はあくまで「たたき台」と捉え、最終的な判断と責任は私たち人間のエンジニアが持つ、という原則を忘れないようにしています。
その上で、AIの回答精度を上げるために私たちが試したなかで特に効果的だったのが、AWS公式ドキュメントのURLを一緒にプロンプトへ含めることです。
例えば、「特定の機能に関するTerraformコードを書いて」と依頼する際に、その機能のAWS公式ドキュメントのURLを添えるだけで、AIが参照する情報源が限定され、より正確で最新のベストプラクティスに沿ったコードを生成してくれる確率が格段に上がりました。
3. ログ共通基盤のリアルタイム検索に向けたAI活用検証
先ほど挙げたログ共通基盤のリアルタイム検索における課題に対し、私たちはAthenaのパーティション射影という機能に着目しました。理論上、これを使うことができればデータがS3に置かれた瞬間にクエリが可能になるはずです。
現在、私は「本当にリアルタイムで検索できるのか。パフォーマンスやコストは実用に耐えるのか。」という仮説を検証するため、AIにテスト用のTerraformコードや検証用スクリプトを生成させながら、効率的に実証を進めています。
この検証が成功すれば、障害調査の時間を大幅に短縮できる大きな一歩となります。
🚀 これからの展望
現在、AIの活用は限定的な内容に留まっています。とはいえこれらの取り組みで得られた手応えは非常に大きいものがあります。
今後はこの成功体験をチーム全体へ展開し、SREチームとしての生産性をさらに高めていくための活動に繋げていきたいと考えています。その先には、
- インシデントレポート（障害報告書）のドラフト作成支援
- 膨大なログデータから異常の予兆を検知する
- Terraformコードの自動レビューや改善提案
といった、さらに高度なAI活用も見据えています。
✨ さいごに
今回は、jinjerのSREとして私の「AI活用」第一歩についてご紹介しました。
私たちjinjerは、本気で 「日本一の開発組織」 を目指しています。 社内では、SREだけでなく、デザイナー、プロダクトマネージャー、そして多くの開発メンバーが、立場や職種を超えて日々議論を交わし、ユーザーにとって最高の体験を届けようと試行錯誤を繰り返しています。
私たちSREの挑戦は、そのような情熱あふれる仲間たちが、安心して「ジンジャー」の開発に集中し、失敗を恐れずに挑戦し続けられる、最高の舞台（=プラットフォーム） を作ることです。今回のAI活用も、そのための大切な一歩にほかなりません。
今後、このAI活用の取り組みがチーム全体へどのように広がっていくか、その進捗もお伝えできればと思っています。
もしこの記事を読んで、私たちの挑戦や文化に興味をお持ちになりましたら、ぜひ一度カジュアルにお話ししてみませんか。
私たちは、こうした課題に一緒に向き合い、jinjerの開発をさらに加速させてくれる仲間を探しています。以下のリンクよりお気軽にお申し込みください。
Discussion