はじめに
開発の工程でLLMを使い始めて3ヶ月たったので、運用として残したもの、やめたもの、まだ試しているものを一覧にしました。各行に、そうした理由と、続いているかをどう確かめているか（コマンドと頻度）を付けています。
経緯や感想はZennに書いたので、こちらには一覧と確認方法だけを置きます。表を見て、気になった行の説明だけ拾ってもらえれば十分です。
ここでいう運用は、要件定義、ドキュメント、コードレビューの工程でLLMを続けて使うことを指します。LLMを組み込んだプロダクトの監視や評価（いわゆるLLMOps）の話ではありません。
環境
- 対象：社内の少数のプロジェクト、2026年秋からの約3ヶ月
- 集計スクリプト：Python 3.14.6 で動作確認（標準ライブラリのみ）
一覧
| 区分 | 項目 | 理由 | 確認方法 | 頻度 |
|---|---|---|---|---|
| 残した | API定義・テーブル定義とコードのズレをCIで検出する | 機械的に照合できる情報だから |
check_doc_drift.py のジョブが通っているか |
PRごと |
| 残した | 要件定義書の初稿をLLMで作り、機械で検査してから人が通しで読む | 初稿は速いが、読む工程を飛ばすと整った間違いが次に流れる |
check_requirements_doc.py と、人が見る3項目 |
初稿ごと |
| 残した | PRのAIレビューを一次チェックに使う | 命名、書式、よくあるパターンは拾える | 指摘を採るかどうかを、人のレビュアーが決めているか | PRごと |
| 残した | ヒアリングで「例外的な運用はありますか」を必ず聞く | 暗黙の業務ルールはLLMへの入力に入ってこない | ヒアリングメモにこの質問の回答欄があるか | ヒアリングごと |
| 残した | READMEや設計意図の修正案もLLMに下書きさせ、理由は人が書き足す | 変更には気づくが、なぜ変えたかまでは書けない | 「理由」を人が書いてから採用しているか | PRごと |
| 残した | 要求同士の矛盾や、サービスをまたぐ影響は、LLMが書いたものを人が最後に確かめる | 渡した文書や差分の外にある前提は、ツールを変えても見てくれなかった | 1.2の3項目を人が確認したか | 初稿ごと、PRごと |
| やめた | 工程の単位で、LLMに任せる範囲を決める | 同じ工程の中に、効く情報と効かない情報が混ざっていた | 下の判断表に置き換えた | - |
| 試している | 作成時間と差し戻し回数を記録する | 3ヶ月回しても、効果を数字で示せなかった |
summarize_metrics.py で集計 |
記録は1本ごと、集計は月1回 |
1. 残したもの
1.1 ドキュメントとコードのズレ検出
API定義とテーブル定義は、コードやマイグレーションから「正」を取り出せるので、ズレの判定まで機械でできます。仕組みは以前の記事に書きました。
続けている理由のひとつは、担当者が替わったときの確認の仕方が変わったことです。API定義とテーブル定義は信じてよく、文脈が要る部分だけ前任者に聞けば済むようになりました。
1.2 要件定義書の初稿と、人が見る3項目
初稿はLLMで数分で出ます。用語のゆれ、「要確認」と書かれた箇所、削除や承認など権限に関わる行は、スクリプトで一覧にします（検査スクリプトの記事）。そのあと人が通しで読みます。人が見るのは、機械では判断できない次の3つです。
- 例外的な運用（繁忙期は承認を一部省略する、など）が書かれているか
- 要求同士が矛盾していないか（ある画面では管理者のみ削除できるのに、別の画面では担当者も削除できる、など）
- ほかのサービスやシステムへの影響が書かれているか
初稿の文章が整っているぶん、抜けに気づきにくくなります。3項目を決めておくのは、そのためです。
1.3 AIレビューの一次チェック
命名や書式、よくある危ない書き方はAIに先に指摘させ、業務ルールが絡む判断は人が見ます。分け方の詳細はこちらの記事に書きました。
1.4 ヒアリングの質問
これはLLMとは関係のない、昔からある対策です。それでも残しているのは、LLMに渡す情報に含まれていないルールは、初稿にも出てこないからです。
1.5 READMEの修正案と、矛盾の確認
READMEのセットアップ手順に変数が増えたことには、LLMも気づきます。ただ、なぜ増えたのかは書けません。そのため下書きはLLMに任せ、理由の一文は人が書き足してから採用しています。
要求同士の矛盾や、サービスをまたぐ影響も同じ扱いです。ある程度は自動で見つけられると期待していましたが、渡した文書やPRの差分の外にある前提までは見てくれませんでした。LLMに書かせることは続けていて、最後に確かめるのは人です。1.2のスクリプトも、権限に関わる行を並べるところまでで、矛盾かどうかは人が決めます。
2. やめたもの：工程で線を引くこと
最初は「要件定義はLLM、レビューは人」のように工程で分けようとしていました。3つの工程を並べてみると、うまくいったのはどれも構造が決まっていて照合できる情報で、うまくいかなかったのは文脈が要る情報でした。今は工程に関係なく、次の表で決めています。
| 情報の性質 | 例 | LLMにやらせる範囲 |
|---|---|---|
| 構造が決まっていて、機械的に照合できる | API定義、テーブル定義、表記ゆれ | 判定まで任せる |
| 文脈がないと判断できない | 業務ルールの背景、手順の理由、設計の意図 | 下書きまで。最後の判断は人 |
迷ったときは「正しいかどうかを、コードや定義と突き合わせて機械で確かめられるか」だけを考えます。この基準にしてから、新しい使い方を試すかどうかを決めるのが速くなりました。
文脈が要る側でも、LLMに書かせること自体はやめていません。やめたのは、工程の名前で任せる・任せないを決めることです。
3. 試しているもの：計測
3ヶ月回したのに、導入前と比べられる記録を取っていませんでした。試しながら形を変えるつもりで、計測を後回しにしたためです。形を変えるたびに、比べる基準も消えていきました。
次の3ヶ月は、2つだけ記録します。
- 要件定義書1本の作成時間（初稿から、レビューに出すまで）
- 差し戻し回数（作成者に戻した回数。指摘の件数ではありません）
LLMを使わなかった案件も同じ形で記録し、比べられるようにします。記録はCSVに1本1行です。
date,doc,llm,draft_minutes,returns
2027-01-08,REQ-01,yes,95,2
2027-01-15,REQ-02,no,240,1
2027-01-22,REQ-03,yes,120,3
2027-02-03,REQ-04,yes,80,1
2027-02-19,REQ-05,no,180,2
この値は説明用の架空のデータです。集計は次のスクリプトで行います。
"""要件定義書ごとの記録(CSV)を、LLMを使ったかどうかで分けて集計する"""
import csv
import sys
from statistics import median
def main(path: str) -> None:
groups: dict[str, list[dict]] = {"yes": [], "no": []}
with open(path, newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
key = row["llm"].strip().lower()
if key not in groups:
sys.exit(f"llm列は yes か no にしてください: {row['doc']}")
groups[key].append(row)
print("LLM 件数 作成時間の中央値(分) 差し戻しの中央値(回)")
for key, rows in groups.items():
if not rows:
print(f"{key:<4} 0 - -")
continue
minutes = median(int(r["draft_minutes"]) for r in rows)
returns = median(int(r["returns"]) for r in rows)
print(f"{key:<4} {len(rows):<5} {minutes:<21} {returns}")
if __name__ == "__main__":
if len(sys.argv) != 2:
sys.exit("使い方: python3 summarize_metrics.py llm_metrics.csv")
main(sys.argv[1])
$ python3 summarize_metrics.py llm_metrics.csv
LLM 件数 作成時間の中央値(分) 差し戻しの中央値(回)
yes 3 95 2
no 2 210.0 1.5
平均ではなく中央値にしたのは、1本だけ極端に時間がかかった案件があると、平均がそれに引っぱられるからです。それでも件数が少ないうちは、中央値も1本で大きく動きます。数字を見て判断するのは、少なくとも各10本くらい溜まってからにするつもりです。
限界
この一覧は、社内の少数のプロジェクトで3ヶ月回した結果です。チームの規模や案件の種類が違えば、残すものもやめるものも変わると思います。
「残した」は、効果が証明されたという意味ではありません。続けると判断した、という意味です。効果の数字はまだ1つもありません。
計測にも穴があります。LLMを使った案件と使わなかった案件で、要件の大きさはそろえられません。比べられるのは傾向までで、「何割速くなった」とは言えない前提で記録しています。
最後に
区分、項目、理由、確認方法、頻度の5列は、そのまま使えます。手元の運用でも一度埋めてみてください。「やめた」の行が1つもなければ、それ自体が見直すきっかけになると思います。
参考文献
- Zenn：LLMOpsを3ヶ月試してみて、変わったこと・変わらなかったこと
- Qiita：ドキュメントをLLMで自動同期させたら、担当者交代のコストが変わった話
- Qiita：要件定義書をLLMと一緒に書いてみた うまくいったこと・ダメだったこと
- Qiita：AIコードレビューを1年運用して分かった、効くところと効かないところ
- Python ドキュメント: statistics.median
この記事はZennにも掲載しています（一部加筆・修正）：https://zenn.dev/vaonvn/articles/c7cb50a0aa0584
VAON Việt Nam のエンジニアチームで、要件定義とレガシー改修にLLMを使う実務を記録しています。