LangGraphとAzure OpenAIでBicep自動生成チャットを作った
はじめまして、日本マイクロソフトのサマーインターンシップに参加している坪井星汰です！
インターンでは、Customer Success Unit (CSU) と呼ばれる部署で、お客様の技術課題を解消する Cloud Solution Architect (CSA) の皆さんと一緒に働いています。自分はCSAの中でもインフラ領域を担当するチームに所属しています。CSA には歴戦のエンジニアの方が多く、これまでのお仕事の内容を伺うだけでも時間があっという間に過ぎてしまいますし、自分の質問にも丁寧に教えていただけるので最高の環境で成長できていると実感しています。
本記事は、Microsoft Global Hackathon 2025 に CSA の方とチームを組んで参加した際の開発内容についてまとめたものです。開発したアプリは、Azure のインフラコード (Bicep) を自動生成するチャットアプリケーションです。技術的な詳細はまた別に記事にまとめて出したいと思いますので、お楽しみに！
追記: 本アプリの技術的な詳細をまとめた記事も作成しましたのでご興味がある方はご覧ください。
LangGraph × Azure OpenAIで構築するBicepコード生成アプリの技術解説
Azure インフラ エンジニアの悩み
皆さん、普段クラウドは使っていますか？
自分は大学やインターンでクラウドサービスを触る機会が増えてきて、アプリ開発や検証環境の構築をするたびに「クラウドって便利だな」と感じています。特に、必要なリソースをすぐに作れて、しかもグローバル規模でサービスを展開できるのは本当にすごいことだと思います。Microsoftでのインターンを通してその思いはさらに強くなりました。
ただ、クラウドを便利に使いこなそうとすると「インフラのコード化（Infrastructure-as-Code; IaC）」が避けて通れません。IaC を使うことで、インフラの構成をコードとして管理できるため、再現性やバージョン管理が容易になり、手動での設定ミスを減らすことができます。
当然 Azure でも、IaC を実現するためのツールが用意されています。マルチクラウド対応している Terraform はもちろんですが、Azure 独自のテンプレート言語である Bicep もあります。ステート管理が不要だったり、公式ツールなので最新の API に追従されやすいという点から、Bicep を好んで使う Azure エンジニアも多いです。
実際、Microsoftの Azure Infra CSA チームの方がどのように Bicep を使っているか聞いたところ、Bicep を使って Azure の検証環境を素早く構築したり、顧客向けの提案書に添付するサンプルコードを作成したりしているそうです。
しかし、ゼロから Bicep コードを書き始めるのは意外と手間がかかります。それはおそらく次のような理由のためです。
- そもそも自分が作ろうとしている Azure 環境の要件（用途、スケール、可用性、セキュリティ要件など）を固めるのが難しい
- 要件をコード化する時に "本質でない" パラメータの設定が必要になる
- Bicep の文法やベストプラクティスを知らないと、うまく書けない
自分自身、Bicep初心者としてAzureのIaCを書こうとしたのですが、結構難しくて手間がかかるなあという印象でした。簡単な検証環境を作るくらいだったらポータルからやった方が早いかもって思ったりします。
おや、ちょっと待ってください。こういう時こそ AI の出番ですよね！最近の LLM (Large Language Model) は非常に高性能なので Bicep のコードも生成してくれるはずです！
LLM による Bicep コード生成の課題
しかし、現実はそう甘くはありません。実際に Bicep コードの生成を LLM に丸投げすると、すぐに次のような課題に直面します。
- プロンプトに細かい要件一覧を書かないと、思ったようなコードが生成されない
- 文法やパラメータ指定がおかしい、lint に通らないコードが生成される
- 結局、人間が手動で修正・作成することになる
自分でも GitHub Copilot や ChatGPT を使って Bicep を生成して遊んでみたりしたのですが、思ったものが生成されず結局自分で書いた方が良かったなーってなりがちでした。また、業務の一環で、Azure Infra CSA の方を対象に AI 活用状況のアンケート調査を行ったのですが、やはり皆さんも同じような感想を持っているようでした。
そこで、今回は
- インフラ環境の要件整理
- lint に通る Bicep コードの出力
を自動で行ってくれるようなアプリケーションを作ることにしました。
Microsoft Global Hackathon への参加
今回のアプリケーションは、Microsoft Global Hackathon 2025 に参加して作成した作品です。これは Microsoft が社内向けに開催しているハッカソンで、全世界の FTE/インターンが参加対象です。
当初、ハッカソンに参加するつもりはなく、上記アンケートの結果を踏まえた Infra エンジニア向けのサポートアプリを個人的に開発しようと計画していました。ですが、自分がそもそもインフラ関連の経験や実績がなく出力された Bicep が優れているのかが分からないこと、テストしてみようとしてもユースケースが分からないこと、あとはプロンプトエンジニアリングをあまりやってこなかったのでそこら辺の知識が不足していることなどの問題があり、開発が思うように進みませんでした。
その時にちょうど Infra CSA の方にハッカソンの存在を教えてもらい、チームを組んで参加することにしました！今振り返っても、自分一人じゃなかなかうまくいかなかった部分が多かったので、チームで開発する方向にしてよかったなと思います。
アプリの概要
改めて、今回作成したアプリケーション (Azure Bicep Generator) の概要を説明します。
作成したのは、会話を通じて要件を整理し、そのまま Bicep コードを自動生成してくれるチャットアプリケーションです。ユーザーは「Web アプリを作りたい」「冗長構成にしたい」「XX のサービスの挙動を確認したい」など、自然言語で答えるだけで、裏側で LangGraph が会話を状態管理しながら以下の流れを自動で進めます。
主な機能は以下の通りです。
-
要件ヒアリング
- 一問一答形式で、用途・スケール・可用性など必要な前提を少しずつ質問。
- 一問一答形式で、用途・スケール・可用性など必要な前提を少しずつ質問。
-
要件サマリ生成
- 全ての会話履歴をまとめて構造化し、次のフェーズで使えるように整理。
- 全ての会話履歴をまとめて構造化し、次のフェーズで使えるように整理。
-
Bicepコード生成
- Azure OpenAIを使ってコードを生成。
-
lint検証と自動再生成
- CLIの
bicep lintを実行し、エラーや警告があればその抜粋を再度LLMに渡し、自動で再生成。このとき、MicrosoftのDocsを参照してエラーを直す - 最大リトライ回数まで繰り返し。
- CLIの
-
完成コード提示
- 問題がなければユーザーにBicepを返し、その場で編集・再利用可能。
- 問題がなければユーザーにBicepを返し、その場で編集・再利用可能。
開発の工夫
1 週間という限られたハッカソン期間の中でアプリケーションを開発するために、たくさんの工夫と試行錯誤を行いました。
まず、何を作るか決めるところです。
Azure Updates のポッドキャスト生成サービスなど、いくつか候補がありました。しかし、アンケート結果からも、インフラ要件定義の自動化、高品質な Bicep の出力には需要がありそうなことがわかっていたので、最終的にはこれで進めることにしました。事前にアンケートを取っていたことが功を奏して、スピーディーな意思決定につながったんじゃないかと思います。
ただ、「どんな UI/UX ならうれしいのか？」というユーザー目線に立ったアプリ設計・要件定義は、特にこれまでの Bicep コード作成経験の数がモノを言う部分です。あまりこれまでに Bicep と触れ合ってきていない自分としては良くわからない部分が多かったので、社員さんのお力を借りることができて本当に助かりました。
具体的には、「技術検証の時にどんな質問をお客さまとするか」を考えてもらって、そのユースケース集を作ってもらったり、その際に意識していることを落とし込んだプロンプトの提案をしていただきました。結局はドメイン知識が重要なんだな、というのを痛感しました！
アプリケーションをチャット形式にすることについても悩みました。実は、もともとはもう少しシンプルで、要件を選択して、それに対応する Bicep コードを一括で生成する仕組みを考えていました。
ただ実際に CSA の方々に話を伺うと、インフラの要件定義って一度に全部を決められるわけではなく、会話の中で少しずつ明らかになっていくものだと分かりました。例えば「Web アプリを作りたい」という要望から始まっても、「じゃあ冗長化は必要ですか？」「データベースはMySQLにしますか？」といった追加質問を経て、ようやく具体的な構成が固まります。
この「やりとりを重ねながら要件を深掘りしていくプロセス」をアプリに取り込むなら、やっぱりチャット形式の方が自然だろうと考えました。実際、要件定義の流れを模倣する形で LLM が状態管理しながら質問と生成を進めてくれる仕組みは、エンジニアにとっても使いやすいと感じています。
次に、何を使って作るかです。
自分は Web 開発の経験はあったのですが、AI チャットアプリの開発は未経験でした。また、LLM の状態管理も初めてだったので、フレームワークの選定が難しかったです。チームメンバーも同様の状況だったため、まずは簡単に LLM の状態管理ができるフレームワークの技術選定を行いました。
そこで、貴重な作業時間のうち、最初の一日をフレームワークの調査や技術検証に費やして、実現可能性が高いものを選べるようにしました。最終的に、LLM の状態管理が簡単に実装できる LangGraph を使うことにしましたが、ドキュメントやサンプルコードも豊富だったので、手探り状態の自分たちにはぴったりだったと思います。
ここまで決まれば後はひたすら形になるまでコードを書き続けるのみです！短期間で仕上げるために、GitHub Copilot にもたくさん働いてもらいました。今回コードを書いていたメンバーは自分を含め 2 人だったのですが、Copilot のおかげで少なくとも 4 人体制くらいの生産性があったんじゃないかと思います。
まとめると、今回 1 週間という短い期間でアプリケーションを開発できたのは、以下のような工夫があったからだと思います。
- 事前にアンケートを取って、ユーザーのニーズを把握しておいた
- ドメイン知識がある社員さんに協力してもらい、ユーザー目線の要件定義を行った
- LLM の状態管理が簡単にできるフレームワークの選定を最初に行い、実現可能性の高いものを選んだ
- GitHub Copilot を活用して、少人数での開発を可能にした
今後に向けて
実は、時間がなかったので実装をあきらめた機能がたくさんあります。記事執筆時点で、インターンの残り期間が３日しかないので難しいとは思いますが、以下の機能を実装したいと思っていました。
- Bicep からアーキテクチャ図の自動生成: Diagram as Code と呼ばれる分野ですね。Azure のアーキテクチャ図をコードから自動的に生成するツールをざっと調べた限り、完璧な機能としてリリースされているものはなく、需要もありそうでした。
- Azure リソースのデプロイ: 生成した Bicep コードをそのまま Azure にデプロイできると便利ですよね。アプリケーション内でデプロイまで完結できるようにしたいです。lint 検証を通ったコードでも、デプロイしてみないと分からないエラー（例：グローバルにユニークな名前が求められるリソースの名前衝突）があるので、デプロイエラーも含めてコードを再生成するようなワークフローにできれば、より高品質なコードが生成できるようになると思います。
- Web アプリ化: 今回のアプリケーションはローカルで動するアプリとして作成しましたが、Web アプリとして公開できればより多くの人に使ってもらえると思います。
何はともあれ、一週間という限られた時間の中では結構良いアプリができたなという感想です。まだまだ改善事項はありますが、LangGraph を使った状態遷移やその API 化など結構勉強になった内容は多かったです。近日中に技術に関する記事と LLM のステートを制御するフレームワークの比較を行いたいと思います！
ここまで読んでくださりありがとうございました。改めて共同開発してくださった、チームのみなさんありがとうございます！
Discussion