15ヶ月間のOSS Azureエミュレーター開発：AIありとなしの両方で

15ヶ月前、Topazの開発を始めたとき（2025年4月中旬に最初のコミットをプッシュしました）、この記事を書く時点でソフトウェアエンジニアリングの状況がどのように変わっているか全く予想していませんでした。この旅全体を要約し、AIがTopaz（私がオープンに構築しているローカルAzureエミュレーター）の設計、開発、テスト方法をどのように変えたかを説明したいと思います。

2025年4月 — ウォームアップ

Topazに取り組み始めたのは挑戦としてでした。当時、私はAWSベースのプロジェクトに深く関わっており、モックを自分で書くのではなく、LocalStackを発見してすぐに気に入りました。AWSインフラのローカルエミュレーションにより、最小限の労力で、そして最も重要なことに、インフラチームの関与なしに、変更を迅速にテストできました。私は自問しました：「なぜAzureにも同様のプラットフォームがないのか？」もちろん、Azurite、Service Bus Emulator、Cosmos DB Emulatorはありましたが、それらは同じではありませんでした。単一のバイナリはなく、統一されたインターフェースもありません——それはLocalStackで15分で達成できるものとは程遠いものでした（今もそうです）。

そこで私はAzure用の独自エミュレーターの開発を始め、Table Storageのエミュレーション、シンプルなAzure Resource Managerのモック、Azure Key Vaultの基本など、最も基本的な機能から始めました。有望なスタートでしたが、すぐに、機能に集中する前に克服すべき特定の課題があることが明らかになりました。

テンプレートとAMQP地獄

エミュレーターの構築は2つの層からなることがわかりました：標準的なCRUD操作（Azureサービス間でほぼ同一）のエミュレーションと、データプレーンとエッジケースの模倣（単純な「HTTP POSTリクエストを受信し、リソースを作成して応答を返す」よりもはるかに洗練されたもの）。これらは全く異なるアプローチとマインドセットを必要としますが、共通点が1つあります——時間を消費することです。そこで、メインIDEであるRiderでテンプレートのセットを構築し、基礎部分の構築を加速することにしました。Topaz CLIコマンドとARMエンドポイントは、単純なコピー/ペースト/置換メソッドで作成できました。簡単な改良の後、標準的なリクエストを処理するために使用できました。これはエミュレーターのアーキテクチャのおかげです：ルーターが一致するエンドポイントを見つけて呼び出し、HTTPコンテキスト全体を提供します。各エンドポイントは同じインターフェースを実装し、その唯一の目的は関連情報を抽出してコントロールプレーンに渡すことです。コントロールプレーンはリソースプロバイダーと通信し、重い処理を行います——すべてのAzure固有のロジックを実行します。 正しいアプローチにより、必要なコードを数分で生成できました。ただし、1つの注意点がありました——API応答の生成です。バイナリの肥大化を避けるためにAzureパッケージをTopazに統合したくなかったので、各応答モデルを手動で実装する必要がありました。ここで初めてLLMが活躍しました——モデルに応答スキーマを取得させ、私のためにモデルを実装するように指示できました。それでもフィールドを幻覚することが多く、ほとんど推論はありませんでした（CopilotとClaudeモデルの初期の話です）が、並行して作業できることは信じられないほどの利点でした。

しかし、使用したどのモデルも解決できない課題がもう1つありました——TopazでのAMQP実装です。初期バージョンは、AMQPプロトコル仕様とAMQPNetLiteの例に基づいて100%手動で行われましたが、これらは正直言って理想からほど遠いものでした。Event Hubの実装はまずまずでしたが、Service Busインターフェースはバグだらけで多くの詳細が欠落していました。LLMで修正しようとする試みはすべて完全な失敗でした——モデルはひどく幻覚を起こし、存在しないメソッドを提案したり、プロトコル仕様を壊したりしました。これは将来に延期し、サポートするサービスと機能のカタログを拡大することに集中することにしました（例：Azure Resource Managerデプロイメントのサポート追加）。

努力の加速（2026年1月〜4月）

数週間、Topazは私からの注目をあまり受けていませんでした。主に他のプロジェクトやイニシアチブに関わっていたためです。しかし、AzureDay 2026で講演できなかった同僚の代わりを務めることになり、追加の概念実証を行いたいと思いました。CFPでTopazに関する講演を提案したので、たとえ会議のためだけでも意味のある改善を行うのは理にかなっていました。そこで、新しい機能の初期バージョンが追加されました：RBACサポートとEntra IDエミュレーションです。 この期間、私はまだLLMの使用に躊躇していました。主に、仕事をこなしルールに従うための品質が欠けていたからです。しかし、ゲームを変え始めたものがありました——アイデアを迅速に分析し挑戦することが可能になったのです。ボイラープレートコードの準備もより簡単で、より迅速で、より洗練されました。退屈なこと（新しいサービスのセットアップ、テストケースの作成、ドキュメントの生成）をモデルに任せることができたので、再び難しいことに集中する時間を得ました。

加速（2026年5月〜現在）

ここ数ヶ月、どのモデル、どの設定、どのアプローチが自分に最も適しているかについて多くの考えを巡らせました。さまざまなモデル、異なる思考努力、大小のコンテキストウィンドウをテストしました。面白いこと？1ヶ月半以上、低思考努力のClaude Sonnet 4.6を非常に良い結果で使用しています。小さなモデル（Haikuなど）はアーキテクチャを把握できず、慣習を「感じる」ことができません。大きなモデルはほとんどのタスクに過剰です。Sonnet 4.6の中/高思考努力は単に考え過ぎます。私のスイートスポットは、「考える代わりにただやる有能なモデル」です。

何がゲームチェンジャーだったか知っていますか？Ponytailスキル——モデルに過剰エンジニアリングではなく最もシンプルな解決策を追求させるVS Codeエージェントカスタマイズです。それ以前は、多くのエージェント固有の指示ファイル（CLAUDE.mdなど）がありました。それらは時代遅れで、コンテキストウィンドウを膨らませ、LLMは他の指示ごとにそれらを無視するのが好きでした。Ponytailを有効にすると、Claude Sonnetはそれでも「ユーザーを満足させるために余分な努力をする」ことができますが、その頻度ははるかに低くなります。

では、今Topaz開発でLLMはどのように使われているのでしょうか？ほぼ100% AI生成の領域があります：ドキュメント、ボイラープレートコード（エンドポイントスタブ、テスト、共通ロジック）、大規模リファクタリング（主にコードベースの規模のため）、回帰テストの処理（例：パッケージアップグレード後）、デバッグ中のラバーダッキング。しかし、ユニークな機能、コアロジック、低レベルパターンはLLMで生成する価値がありません。不可能だからではなく、単にLLMがコードベースを「感じて」おらず、すべての新機能を何か汎用的なものとして扱うからです。また、私のLLMがテストを実行し、ログを確認し、答えを得る方が簡単だと理解せずに、10k LOCと20の異なるパッケージを通じて推測しようとする（その間にコンテキストを失う）ため、1つのリクエストに1000クレジットを費やす価値があるとも感じません。

TopazにおけるLLM—学んだ教訓

LLMとコーディングアシスタントをTopazに取り入れることで、さまざまなアプローチとパターンを深くテストし、自分に最も合うものを見つけることができました。詳細にまとめましょう。

純粋なエージェントアプローチではなく「計画」モードの使用

「計画」モードの使用が洗練されたソリューションの実装における万能薬だとは言いませんが、モデルが行う可能性のある奇妙な決定をすべて捉えるのに確かに役立ちます。クレジット消費の観点からは何も変わらないと思います——そうですね、モデルは計画に従いますが、計画はコンテキストから推論される必要があります。間違った決定の爆発半径が大きい大きなタスクに使用します。

推論努力は単にコンテキストウィンドウを膨らませる

LLMが考えれば考えるほど、より多くの情報を取得しようとし、より多くのオプションを考慮しようとします。モデルにすべての可能性を提示させることはほとんど期待していません。私が直面した最も重いクエリのほとんどは、LLMが考え過ぎて、決して期待されていなかった黄金の解決策を見つけようとしたことによって引き起こされました。

テストスイートによるハーネスの導入

現在、Topazでは毎日1500以上のテストが実行されています。LLMが実装したものはすべて、最小限の労力で自動検証できます。必要に応じて、モデルは自分のアプローチを自動検証することもできますが、1つ問題があります——シナリオに完全に依存します。実際に何が起こったかを注意深く追跡する必要があるより複雑なケースでは、LLMは迷子になる傾向があります。コンテキストが多すぎ、慣習が多すぎ、問題が特異すぎます。人間の介入は依然としてループの一部です。

KISS

はい、シンプルを保つという実証済みのITルールは今でも有効です。物事を一つずつ行い、シンプルさを期待し、過度に詳しく説明するのを避けます。モデルが詩を書けることは知っていますが、私が望んでいるのはそれではありません。

結論

現在利用可能なLLMはOSSプロジェクトの開発に役立つでしょうか？間違いなく。AIアシスタントに委任できて嬉しかったことがいくつかあります。Topazのようなプロジェクトを「バイブコード」することは可能でしょうか？もちろん——問題はそれだけの価値がないことです。APIスタブの生成は簡単です。エコシステム全体の設計は現在のモデルにはできません。もしかするとClaude Opusが私の考えを変えるかもしれません。もしかするとFableが私の問題を解決するかもしれません。真実は、私はそれらを必要としていないということです。

私は最初の400コミット後にLLMをTopazのコードベースに導入し、1000コミットに達した後により真剣に使い始めました。ルールとアーキテクチャは、指示ではなく、自分の設計とテストスイートによって確立しました。モデルに何をすべきか、どのようにすべきかを伝える必要はありません。コードベースから推論できるからです。実際のコード生成が行われる前に、十分にテストされ証明された同じコードベースです。

私が証明したことは他にもあります。私がテストし、現在使用しているモデルには、1つの重要な要素が欠けています——直感です。Topazには多くのバグがあり、ログを1分読めば私には明らかでした。LLMでは、常に最初にログを読むように明確に指示されているにもかかわらず、彼らは好き勝手に行動します。時にはログを読み、時には自分は賢いと証明しようとして30分間ぐるぐる回り、クレジットを消費し、何も理解していないことを証明します。

LLMの助けがなければTopazが同じ場所にいなかったと思います。私にとって、それらは有用なツールであることが証明されました——エミュレーターをより速く構築し、品質を向上させ、すべてが最新であることを確認するのに役立ちます。しかし、手頃な価格のモデルは依然として実際のエンジニアリングにはほど遠いです。彼らは自分が何をしているかを知っているように見えます。偉大なアナリストのように見えます。しかし、表面下では、彼らはただのより洗練されたコードジェネレーターであり、オーケストレーションされ、注意深く監督される必要があります。