【ソースは俺】LLMと開発する時の３原則
最近、LLM（大規模言語モデル）を使ってアプリケーションを作るのが、すっかり日常の一部になってきましたよね！🚀
今回は、私が大切にしている「俺的３原則」をシェアしたいと思います。名前の通り、個人的な体験をもとにした 「ソースは俺」 の原則となっています。
参考程度に見ていただければ嬉しいです。
３原則
- 第1原則：変わってはいけないものから作る
- 第2原則：メタデータを積極的に活用する
- 第3原則：構造を意識して指示を出す
では、ひとつずつ詳しく見ていきましょう。
第１原則：変わってはいけないものから作る
まず最初に作るべきは、「変わってはいけないもの」や「変えるのが大変なもの」です🔒
例えば、一般的なWebアプリケーションを考えてみましょう。フロントエンド↔︎バックエンド↔︎データベース、という構造の場合、データベースは「変わってはいけないもの」の代表格です。データベース構造を後から変えようとすると、めちゃくちゃ大変ですよね。一方で、フロントエンドは表示を担うので、比較的柔軟に変えられます。
この考え方はソフトウェアアーキテクチャにも通じるもので、例えばDDDやクリーンアーキテクチャの文脈では「ドメイン＝変わってはいけないもの」とされることが多いです。上に挙げた「データベース＝変わっていはいけないもの」は１つの例です。アーキテクチャに合わせて、変わってはいけないものが何になるかは変わります。
なので、まずは「変わってはいけないもの」を決めて、そこから作り始めるのがポイントです！
これが第1原則。
第２原則：メタデータを積極的に活用する
LLMを活用するときは、「メタデータ」を投げるようにしましょう🗒️
LLMは大量の情報を処理するのが苦手です。情報が多すぎると、前半の文脈が無視されやすくなり、期待した結果が得られないことがよくあります。これはLLMの構造上どうしても避けられない問題です。そこで役立つのが、短い文字数でたくさんの情報を詰め込んだメタデータです。
例えばこんなメタデータが使いやすいです：
- DDL（データ定義言語）：データベースの構造を伝える情報
- OpenAPI：APIの仕様をまとめたもの
必ずしも、広く知られているOpenAPIのような綺麗なメタデータである必要はないと思っています。フォルダ構造やコマンド仕様をMarkdownにまとめるだけでも十分有効なはずです！
要するに、短くても内容が濃く、全体像がわかる情報をLLMに渡すようにするのがコツです。
これが第2原則。
第３原則：構造を意識して指示を出す
ソフトウェアまたはアプリケーションの構造をしっかり理解して、その構造に合わせた指示を出しましょう🏢
体験談から話します。
私はSpringでAPIを作成していました。よくあるレイヤードアーキテクチャ（Controller→Service→Repository）を採用しており、開発のアプローチとしては、以下の2つの方法が考えられました：
- 各層を独立して開発する（例：Repository → Service → Controllerの順に作る）
- 各APIごとに層を横断して開発する（例：Hoge APIに必要なRepository、Service、Controllerをまとめて作る。その後Fuga APIに必要な〜）
実際にどちらも試しましたが、圧倒的に「2」の方が効果的でした。APIごとのデータのやりとりがスムーズになり、エラーも減ります。これも、LLMが「理解しやすい指示」を出せている結果だと思います。
結局は、自分がアプリの構造をしっかり理解して、それに合った指示を出すのが大切ですね！LLMを使っていると思考停止になりがちですが、構造を理解してどんな指示が適切か考えながら指示を出しましょう。トライアンドエラーになってもいいので、LLMの出力を見ながら考えることが必要です！
これが第3原則。
まとめ
以上が、私の「俺的３原則」です！
LLMが文章を出力するプロセスは基本的にブラックボックスであり、指示の出し方は試行錯誤が必要ですが、この原則が少しでも参考になれば幸いです。
Discussion