【ITニュース解説】Taming the LLM: From Generic to Gold for Go Performance Bottlenecks

近年、プログラミングの世界で大きな注目を集めている大規模言語モデル（LLM）は、あたかも魔法のようにコードを生成したり、質問に答えたりすると期待されている。しかし、実際に複雑なシステム、特に長年にわたって開発され、多くの開発者の手が加えられてきたGo言語のマイクロサービスのパフォーマンス問題を解決しようとすると、その期待はすぐに現実の壁にぶつかる。

最初に試されたのは、最も単純なアプローチだった。お気に入りのLLMに対して、「Go言語のマイクロサービスのパフォーマンスを改善するにはどうすればよいか？」と漠然と質問してみる。しかし、返ってくる答えは、「データベースクエリを最適化する」「ゴルーチンを効率的に使う」「必要に応じて結果をキャッシュする」といった、教科書に載っているような一般的すぎる内容ばかりだった。もちろんこれらは正しいアドバイスだが、何年も運用され、さまざまな技術が混在する「legacyAuthService」のような既存の複雑なシステムにおいては、具体的に何をすれば良いのかが全く分からなかった。例えば、データベースクエリの最適化と言われても、複数のORM（オブジェクトリレーショナルマッピング）ツールと生のSQL呼び出しが混在している状況では、どこから手をつければ良いのか見当もつかない。特定の行やパターンを指摘してくれるような、実践的なアドバイスが求められていた。

そこで、LLMにさらに多くの情報を提供する試みが始まった。問題が疑われる箇所のコードスニペットを直接貼り付け、LLMに解析させる方法だ。これでLLMは、冗長なマップの検索や、存在しない可能性のあるオブジェクトへのアクセス（nilポインタ）といった基本的なコードの問題点を指摘できた。これは一部役立つこともあったが、パフォーマンスの根本原因にはなかなかたどり着かなかった。次に、Go言語のプロファイリングツールであるpprofが出力する生データをLLMに渡してみた。pprofはCPUの使用状況などを詳細に分析するツールで、どの関数がどれだけのCPU時間を消費しているかを示してくれる。このデータを渡せば、LLMは「この関数が最もCPUを使っている」と特定はできたものの、「関数XをリファクタリングしてCPU使用率を下げろ」といった、やはり抽象的なアドバイスしか返してくれなかった。他にも、異なるLLMモデルを試したり、「ベテランのGo言語エンジニアとして振る舞え」といった役割指定（ペルソナプロンプト）を与えてみたりしたが、状況は大きく変わらなかった。これらの試行錯誤には、合計で数時間が費やされた。

真の突破口は、LLMを魔法の道具としてではなく、「非常に優秀だが、文字通りの意味でしか理解しないジュニアエンジニア」として扱う考え方に切り替えたときに訪れた。このアプローチは「Context-Data-Goal」サンドイッチと名付けられた。これは、情報を構造化してLLMに与える方法である。

まず、「Context（コンテキスト）」として、システムの全体像、既知の問題、使用しているGo言語のバージョンなどを明確に説明する。例えば、「Go 1.21.3がKubernetesクラスターで稼働している」「legacyAuthServiceが、中程度の負荷（秒間約500リクエスト）でCPUスパイクとレイテンシの増加を経験している」「データ競合や非効率なデータ処理が疑われる」といった具体的な情報を提供する。

次に、「Data（データ）」として、具体的な情報を段階的かつ誘導的に提供する。単にpprofのデータを丸ごと貼り付けるのではなく、「これがCPUを最も消費しているトップ10の関数を示すpprofの出力です」と前置きし、具体的な消費割合が示されたリストを提示する。その中で、最もCPUを消費している関数（例：heavyPermissionsCheckがCPUの60%を消費している）を特定し、その関数の実際のGo言語のコードと、関連する依存関数のコードスニペットをLLMに提示する。このとき、コード内の特定の行について、「このスライス（動的配列）の初期割り当ては、もっと最適化できるだろうか？」といった具体的な疑問も投げかける。

最後に、「Goal（ゴール）」として、LLMに何を期待するのかを非常に具体的に指示する。「pprofのデータとheavyPermissionsCheck関数のコードに基づき、60%のCPU使用率を引き起こしている可能性のある、この関数内または直接呼び出される関数内の具体的な行やパターンを特定せよ。特定された各領域について、CPUサイクルを削減するための具体的なリファクタリング案や代替アルゴリズムを提案せよ。ただし、大規模なアーキテクチャ変更や外部ライブラリの導入は、必要不可欠な場合を除き避けること。例えば、スライスの初期割り当ては最適化可能か？」といった具合に、明確な指示を与えるのだ。

この「Context-Data-Goal」サンドイッチによる反復的なプロンプトの組み立ては、特にClaude 3 Opusのような高性能なLLMと組み合わせることで、目覚ましい成果を生み出した。抽象的な「ゴルーチンを最適化せよ」というアドバイスではなく、「ループ内でp.HasAccess(resource)の呼び出しが繰り返されているが、もしHasAccessが複雑な処理を行うなら、その結果をループ内でメモ化（一度計算した結果を保存して再利用すること）するか、resourceが一定であればuserRolesを事前にフィルタリングすることを検討せよ」といった、非常に具体的で実践的なアドバイスが得られるようになった。これこそが、テスト可能で、実際に問題解決に繋がる「金」のようなアドバイスだった。

この方法は決して魔法ではない。瞬間的に解決策が得られるわけでもなく、システムを十分に理解し、LLMに賢い質問を投げかけ、関連性の高いデータを提供できる能力が依然として必要である。しかし、このアプローチによって、LLMは一般的なアドバイスしかできないチャットボットから、具体的なコード分析と改善提案を行う強力なエンジンへと変貌した。手作業で時間をかけて掘り下げていた分析作業を何時間も短縮できる、まさに強力なツールなのである。