7.8.3 プロジェクト：納品キット
LLM プロジェクトの最後に大事なのは、「動く」だけではありません。
それ以上に大事なのは、
他の人が目的を理解し、結果を再現し、評価を確認し、続きから進められるか？
このページがある理由
多くのプロジェクトは、モデルが弱いから失敗するのではなく、最後の引き継ぎが弱いから失敗します。良いプロジェクトには、デモだけでなく証拠が必要です。
最終パッケージには何が必要か
最低限、良い LLM プロジェクトには次のものが必要です。
README.md- 再現可能な実行コマンド
- 入力と出力の例
- 評価記録
- 失敗ケース分析
- スクリーンショットやグラフ
- 次のステップの計画
これがあると、プロジェクトは自立して見えます。
レビューしやすいフォルダ構成
project/
├── README.md
├── examples/
│ ├── input-01.json
│ └── output-01.json
├── reports/
│ ├── evaluation.md
│ └── failure_cases.md
├── screenshots/
│ ├── run-01.png
│ └── before-after.png
└── src/
└── ...
この構成は意図的にシンプルです。
README.mdは物語を伝えるexamples/はタスクを証明するreports/は評価を証明するscreenshots/は実行できることを証明する
再利用できる README テンプレート
次のひな形をコピーして、自分のプロジェクト内容で埋めてください。
# プロジェクト名
## 1. 目的
このプロジェクトは何を解決するのか？
## 2. タスク範囲
何が範囲内で、何が範囲外か？
## 3. ベースライン
まず何と比較したのか？
## 4. データ
データはどこから来たのか？ サンプル数はどれくらいか？
## 5. 評価
どの指標や手動チェックを使ったのか？
## 6. 結果
何が改善し、何がまだ課題か？
## 7. 失敗ケース
実際の失敗を 1 つ示し、原因を説明する。
## 8. 実行方法
どうすれば結果を再現できるか？
## 9. 次のステップ
次に何を改善するのか？
使いやすい評価記録テンプレート
固定テストセットがあるなら、結果は次のような表にまとめると便利です。
| ケース ID | 入力 | ベースライン | 新しい方法 | 合格? | メモ |
|---|---|---|---|---|---|
| 001 | 返金依頼 | 汎用回答 | ドメイン対応回答 | はい | ポリシーをカバー |
| 002 | 住所変更 | 曖昧 | 明確なルール回答 | はい | 構造が良い |
| 003 | 請求書の質問 | 重要点を落とす | 正しい回答 | いいえ | データ追加が必要 |
これで、後からバージョン比較がしやすくなります。
本当に役立つ失敗メモのテンプレート
「モデルが悪い」とだけ書かないでください。
次のように書きます。
# Failure Case: JSON field missing
- Phenomenon: The output sometimes adds extra text before the JSON object.
- Clues: This happens more often on long prompts.
- Suspected cause: The prompt does not strongly constrain the output format.
- Investigation: Compare prompt versions and inspect the raw outputs.
- Fix action: Add a strict schema reminder and a short example.
- Regression check: Run the same fixed test cases again.
この 1 つのメモは、10 枚のスクリーンショットより価値があることもあります。
良い引き継ぎとは何か
引き継ぎでは、他の人がすぐに次の 3 つに答えられるべきです。
- このプロジェクトは何を解決するのか？
- どうやって再現するのか？
- なぜこの方法はベースラインより良いのか？
この 3 つにすぐ答えられるなら、ポートフォリオやチームレビューに出せる状態です。
最終チェックリスト
プロジェクトを閉じる前に、次を確認します。
- README が目的と範囲を説明しているか
- 実行コマンドが動くか
- ベースラインと新しい方法の両方を示しているか
- 評価セットが固定されているか
- 失敗ケースが少なくとも 1 つあるか
- スクリーンショットやグラフがあるか
- 次の計画が書かれているか
まとめ
良い LLM プロジェクトは、動くだけのスクリプトではありません。
理解できて、再現できて、評価できて、さらに拡張できるパッケージであるべきです。
ここまでできれば、もう単に技術を学んでいるだけではありません。 他の人が本当に使えるものを作っています。