7.8.3 プロジェクト：納品キット

LLM プロジェクトの最後に大事なのは、「動く」だけではありません。

それ以上に大事なのは、

他の人が目的を理解し、結果を再現し、評価を確認し、続きから進められるか？

プロジェクト納品キット

最終パッケージには何が必要か

最低限、良い LLM プロジェクトには次のものが必要です。

README.md
再現可能な実行コマンド
入力と出力の例
評価記録
失敗ケース分析
スクリーンショットやグラフ
次のステップの計画

これがあると、プロジェクトは自立して見えます。

レビューしやすいフォルダ構成

この構成は意図的にシンプルです。

README.md は物語を伝える
examples/input-01.json と examples/output-01.json はタスクを証明する
reports/evaluation.md と reports/failure_cases.md は評価と失敗分析を証明する
screenshots/run-01.png と screenshots/before-after.png は実行できることを証明する
src/ は実行可能な code を置く

再利用できる README テンプレート

次のひな形をコピーして、自分のプロジェクト内容で埋めてください。

# プロジェクト名

## 1. 目的
このプロジェクトは何を解決するのか？

## 2. タスク範囲
何が範囲内で、何が範囲外か？

## 3. ベースライン
まず何と比較したのか？

## 4. データ
データはどこから来たのか？ サンプル数はどれくらいか？

## 5. 評価
どの指標や手動チェックを使ったのか？

## 6. 結果
何が改善し、何がまだ課題か？

## 7. 失敗ケース
実際の失敗を 1 つ示し、原因を説明する。

## 8. 実行方法
どうすれば結果を再現できるか？

## 9. 次のステップ
次に何を改善するのか？

使いやすい評価記録テンプレート

固定テストセットがあるなら、結果は次のような表にまとめると便利です。

ケース	結果	メモ
001 返金依頼	ドメイン対応回答は合格	汎用 baseline よりポリシーをよくカバー
002 住所変更	ルール型回答は合格	baseline より構造が明確
003 請求書の質問	新しい方法は不合格	まだ重要点を落とすため、データ追加が必要

これで、後からバージョン比較がしやすくなります。

本当に役立つ失敗メモのテンプレート

「モデルが悪い」とだけ書かないでください。

次のように書きます。

# 失敗ケース：JSON フィールド不足

- 現象：出力が JSON オブジェクトの前に余計な説明文を付けることがある。
- 手がかり：長い Prompt のときに起きやすい。
- 推定原因：Prompt が出力形式を十分強く制約していない。
- 調査方法：Prompt バージョンを比較し、raw output を確認する。
- 修正アクション：厳密な schema reminder と短い例を追加する。
- 回帰確認：同じ固定テストケースをもう一度実行する。

この 1 つのメモは、10 枚のスクリーンショットより価値があることもあります。

納品パッケージの完全性を確認する

プロジェクトを完了と言う前に、次の小さなスクリプトをプロジェクトルートの check_package.py として置きます。

from pathlib import Path

required = [
    "README.md",
    "examples/input-01.json",
    "examples/output-01.json",
    "reports/evaluation.md",
    "reports/failure_cases.md",
]

missing = [item for item in required if not Path(item).exists()]

if missing:
    print("missing:")
    for item in missing:
        print("-", item)
    raise SystemExit(1)

print("package_ready=true")
print("checked_files=", len(required))

実行します。

python check_package.py

パッケージがそろった後の期待出力:

package_ready=true
checked_files= 5

このスクリプトはモデルの良し悪しを判定しません。レビューする人が、再現と確認に必要な最低限の材料を持っているかを確認します。

良い引き継ぎとは何か

引き継ぎでは、他の人がすぐに次の 3 つに答えられるべきです。

このプロジェクトは何を解決するのか？
どうやって再現するのか？
なぜこの方法はベースラインより良いのか？

この 3 つにすぐ答えられるなら、ポートフォリオやチームレビューに出せる状態です。

最終チェックリスト

プロジェクトを閉じる前に、次を確認します。

README が目的と範囲を説明しているか
実行コマンドが動くか
ベースラインと新しい方法の両方を示しているか
評価セットが固定されているか
失敗ケースが少なくとも 1 つあるか
スクリーンショットやグラフがあるか
次の計画が書かれているか

期待される結果：他の人がこのパッケージを開き、コマンドを実行し、例と評価表を確認し、不足した文脈を質問しなくても次の行動を理解できる状態です。

残す証拠

このページを終えたら、この証拠カードを残します。

フォルダー: プロンプト、評価、出力、データメモ、README
実行コマンド: 誰かが結果を再現する方法
指標表: ベースラインと改善後の結果
失敗ノート: 既知の弱いケースと次の行動
レビュー準備: 別の人が質問なしで証拠を確認できる

プロジェクトレビュー観点と通過基準

よい提出パッケージは live demo に依存しません。README、fixed eval table、failure note、rerun command だけで流れが分かる必要があります。
評価表は最終版だけでなく baseline と比較します。そうしないと、reviewer は何が改善したのか判断できません。
結果がよく見えても、失敗ケースを 1 つ残します。境界を理解していることを示し、次の contributor の出発点になります。
他の人が 10 分以内に再実行し、次の改善点を言えるなら、このページは完了です。

まとめ

良い LLM プロジェクトは、動くだけのスクリプトではありません。

理解できて、再現できて、評価できて、さらに拡張できるパッケージであるべきです。

ここまでできれば、もう単に技術を学んでいるだけではありません。他の人が本当に使えるものを作っています。