はじめに

こんにちは。電子薬歴 Musubi の基盤開発チームで SRE を担当している大山です。

カケハシでは生成 AI の活用を丁寧に推進しています。具体的な体制や方針については🗒️ 薬局DXをリードするカケハシは社内で生成AIをどのように活用しているのか?をご参照ください。

Musubi SRE チームでも生成 AI を導入し、業務効率化や生産性向上に大きな効果を感じています。最初は「便利そう」という印象でしたが、今では「活用しない選択肢はない」と考えるほどインパクトがありました。本記事では、生成 AI を活用した具体的な事例を 4 点ご紹介します。

対象となる読者

SRE がどのように生成 AI を活用しているのか知りたい方
Devin や Cursor を Terraform で使うとどう嬉しいのか興味がある方
NotebookLM で AWS ドキュメントを読み合わせるとどうなるのか知りたい方

薬局DX業界 SREチームにおける生成 AI 活用事例

Musubi のインフラは大部分を Terraform で構築しています。生成 AI エージェントである Devin や Cursor を活用することで、Terraform のリファクタリングや設定値の一括修正が効率的に行えます。

1. Terraform の variable description の表記揺れを Devin で一括修正

Musubi のインフラは IaC 導入開始から 3年ほど経過しており、Terraform のエントリポイントやモジュールは設定ファイルがかなり増えていました 😢

Terraform CLI のエントリーポイントの数: 261
Terraform モジュールの数: 94

この背景に伴い、variable の description に表記揺れが多岐に渡り発生していました。これを手動で修正するのは大変な作業ですが、Devin を活用することで、数十箇所に及ぶ設定値の一括修正を行い、少ない時間で見事に修正することができました 👏👏👏

最初は「variables の表記揺れをいい感じに統一して」とざっくり依頼しただけでしたが、Devin は会話を通じて詳細を詰めてくれます。細かい指示がなくても意図を汲んで提案してくれるので、ラフな依頼でも十分に対応してくれるのが便利でした。

Devin とのラリーは対話といえど非同期なので、対話中も別の作業ができることもあり、ながら指示できるのはかなりメリットです。

⚠️ 注意点

あとこれはかなり重要なポイントですが、アプリ開発のユニットテストのように、CI で terraform plan によるリソースの diff を確認可能な機構があると、PR の品質を一定に保ってくれるのでレビュア（責務を持つ人間）のコストが削減でき、且つ Devin を導入する敷居が下がります。逆に自動テストがない・または不十分な場合、PR の品質の担保が難しいので、Devin（含め生成 AI エージェント）を導入するリポジトリに対してはまずテスト機構を整えることをお勧めします。

Devin のメリットまとめ

✅ 表記揺れの修正という、人間がやると時間がかかりそうな仕事をすぐに片付けてくれる
✅ 非同期でやり取りできるので、他の作業をしながら進められる
✅ 修正方法に少し悩むところも Devin が提案してくれるので考える手間が省ける。「いい感じにお願い」でもなんとなく伝わるのがすごい
✅ 必要なコンテキストさえ与えれば、初回の PR でも品質が 80% ~ 90% 以上のものができる

2. Terraform だと定義するリソースの数が多い API Gateway を Cursor で対話しながらサクサク作成できた

Amazon API Gateway を Terraform で構築する際、ゼロからだと初回は 10〜30 程度のリソース定義が必要です。新規の案件で API Gateway を追加するとき、従来は 1〜2 日程度かかる見積もりでしたが、Cursor を活用することで 40 分で完了しました。

Devin や Cursor 問わず、生成 AI エージェントは宣言型のコードとは親和性が高いのかなと、という印象です。

💡 Tips: Devin と Cursor の使い分け

Devin と Cursor の役割は部分的に重複するものの、自身やチームメンバーの使い方を観察していると、私は以下のように使い分けることがよいと思います。 ※あくまで一例として参考になれば幸いです

Devin の主なユースケース

ゼロからアプリやモジュールを作成
まとまった機能単位の開発（例: Webhook追加、リソース作成）
ドキュメントが少ない状態からの開発
PoCやプロトタイプの初期構築
自動でPR作成まで任せたいとき
機能仕様から設計・実装・テストまで一括対応
ゴールベースでの開発
フロントエンドやバックエンド、インフラなど含めた横断的な開発
質問を繰り返しながら設計を深める
爆速で初期構築したい場合
PR 作成まで任せたいとき

Cursor の主なユースケース

既存コードの修正・拡張
特定ファイル・関数のピンポイント編集
軽微なバグ修正やリファクタリング
GUIやIDE連携で作業内容を可視化したいとき
既存プロジェクトの部分的な改修
ペアプロ感覚での編集
影響範囲を追いながらのピンポイント修正
小規模なバグ修正やリファクタリング

3. インフラのオンボーディングで Devin Wiki を活用

Musubi SRE チームでは、よくある AWS のシステム構成図を元にオンボーディングを実施していました。ただ、長大な世界地図を見せられても解像度が低く、詳細は IaC や CI/CD のコードを元に口頭で説明することが多かったのですが、先日 Devin 2.0 で正式にリリースされた Devin Wiki を活用することで、より詳細な情報共有ができるようになりました。

詳細はお見せできませんが、こういうのが自動生成されます。（概要と見出しを抜粋）

devin_wiki

既にインフラはコード化（IaC）できる時代ですが、Devin Wiki はインフラのドキュメント化を実現したと言えます。それか IaC 自体の価値を高めたというべきか。

実態のリソースに合わせて手作業でドキュメントをメンテナンスするのは現実的なコストではありませんので、手作業でやると結局実態と乖離したものになるのが現実でした。支払えるドキュメントへのコストとしては、インフラの構成図と README を充実させるのが限界かなと。しかし、Devin Wiki を活用することで、もう少し解像度の高いインフラのドキュメント化が容易になりました。（しかも自動で生成してくれるという。）

現在日本語には対応していませんが、Web ブラウザ上で動作するので機械翻訳でも十分に使えます。

⚠️ 注意点

一定期間で最新に更新されるので、「あの Mermaid 記法で作られた図が分かり易かったのに...」と思っていても、次の更新で消えたりすることが普通にあります... orz 適切なコンテキストを与えることで更新による問題を軽減できる可能性がありますが、現状では多少ガチャ感があります。

4. AWS ドキュメントを NotebookLM のポッドキャスト形式で読み合わせ

AWS ドキュメントの URL を NotebookLM にデータソースとして読み込ませ、ポッドキャスト形式でチームで読み合わせを行いました。このときのテーマは「ECS・ECR のコンテナセキュリティ」について。これにより、短時間で要点を把握し、効率的に議論を進めることができました。

ecs_ecr_container_security_best_practice

NotebookLM は、データソースの量に関わらず数分程度（5~10min）の音声概要（ポッドキャスト形式の音声データ）で要約を作成してくれます。当然、ドキュメントすべての内容を網羅することはできませんが、要点を押さえた内容を短時間で把握できるため、議論のスタート地点として非常に有用かなと。体験としてかなり良かったです。（個人的に AWS のドキュメントはなぜか読むのがつらいので、使い方としてはフィットしているのかなと思います。）

これを社内 LT で話したとき、「輪読会でも使えそう」と話題になりました。他にも色んな使い方ができそうで考えるとワクワクしますね。