新しいモデルが出るたびに、ちょっとした高揚感がある。「これで前より賢い文章が書ける」「レビューの精度も上がるはずだ」。実際、乗り換えた直後は体感の品質が上がることも多い。
ただ、45歳になって現役のエンジニアリングマネージャーを続けている私は、この高揚感に一つだけブレーキをかけている。
「賢いモデルだから品質が保たれる」という状態は、実は結構危ういという話だ。
モデルの賢さに品質を預けると起きること
私は個人の発信活動として、AIに記事の下書きを書かせ、そのまま自動で公開まで持っていく仕組みを運用している。この手の仕組みを作った人なら分かると思うが、最初につまずくのはだいたいここだ。
「今使っているモデルなら大丈夫」という前提で品質基準を作ってしまう。
たとえば、「このモデルは事実確認が丁寧だから、ファクトチェックの工程は軽くていい」「このモデルは表記ゆれをほぼ起こさないから、統一チェックは省略していい」。運用を始めた頃の私も、似たような判断をしていた。
でも、これは前提が崩れた瞬間にすべて崩れる設計だ。
- 使っていたモデルが提供終了になる
- 契約プランが変わって、別のモデルに切り替わる
- 同じモデルでもアップデートで挙動が変わる
- そもそも「賢い」の中身は、こちらが把握しきれていない特性の集合体でしかない
今日賢いモデルが、来月も同じように賢い保証はどこにもない。モデルを主語にした品質保証は、主語がいつ入れ替わるか分からない前提の上に建っている家のようなものだ。
これはEMのレビュー設計とまったく同じ構造をしている
ここで、EMとしての経験が接続してくる。
チームの品質保証を設計するとき、一番脆いパターンは何かというと「あの人がレビューすれば大丈夫」というものだ。エース級のレビュアーが一人いて、その人が見た変更だけは安心できる、という状態。
これは短期的には機能する。でも構造としては脆弱だ。
- そのレビュアーが休めば、品質ラインが下がる
- そのレビュアーが異動・退職すれば、品質ラインは根こそぎ消える
- そのレビュアーの調子や機嫌によって、見る観点にムラが出る
- 新しく入ったメンバーは、その暗黙知に一生追いつけないかもしれない
EMの仕事の一つは、「誰がレビューしても、一定の品質ラインを割らない仕組み」を作ることだと私は考えている。属人的な安心感を、仕組みに変換する仕事だ。
具体的には、レビュー観点をチェックリスト化する。CIに機械的なチェック（Lintやテストカバレッジ、禁止パターンの検出など）を入れて、人間の目視より先に機械で弾けるものは弾く。人間のレビューは、機械では判断できない領域——設計の妥当性や、チーム文脈との整合性——に集中させる。
この構造を、そのまま「人」を「AIモデル」に置き換えると、AI運用の話になる。
「あのモデルが書けば大丈夫」は、「あの人がレビューすれば大丈夫」と同じ脆さを持っている。
実際にやっていること: 機械ゲート＋チェックリストの多層防御
私が運用しているAI記事生成の仕組みでは、品質保証をモデルの賢さではなく、次のような多層構造に置いている。
1層目: 投稿前の非LLMバリデータ
AIが下書きを生成した後、その出力を人間が読む前に、まず決定論的なプログラム（LLMを使わない、普通のコード）がチェックする。文字数の下限・上限、禁止語の混入、必須要素の欠落、明らかなフォーマット崩れなど、ルールとして書き下せるものはすべてここで機械的に判定する。ここでエラーが出た場合、公開は自動的に止まる。モデルが何であっても、このゲートを通らなければ次に進めない。
擬似コード的に書くとこんな感じだ。
draft = ai_generate(topic)
result = validate(draft) # LLMを使わない純粋なルールチェック
if result.has_error:
stop_pipeline()
notify_human()
2層目: 公開前チェックリスト
機械チェックを通過した原稿でも、人間(または人間役のレビュー担当)が公開前に確認する項目をリスト化してある。個人情報が混ざっていないか、タイトルと本文の主張が一致しているか、事実として怪しい記述がないか。これはモデルの賢さに頼らず、「誰がこのチェックリストを実行しても同じ観点を見る」ことを目的にしている。
3層目: 公開後の再監査
公開して終わりにせず、実際に世に出た成果物を定期的に見返す工程を入れてある。想定外の劣化パターンが出ていないかを、後追いで拾うための保険だ。
この3層は、それぞれ役割が違う。1層目は「止めるべきものを機械的に止める」、2層目は「機械では判定しきれない観点を人間の目で補う」、3層目は「見逃しを後から回収する」。どの層も、特定のモデルの賢さを前提にしていない。
モデルを入れ替えても、品質ラインが動かない状態のメリット
この構造を作ってから気づいたのは、モデルの乗り換えに対する心理的な負担がほぼゼロになったということだ。
新しいモデルが出て、性能が良さそうだと感じたら、単純に生成部分を差し替えるだけでいい。品質を保証しているのはモデルではなく、その後段に積んである機械ゲートとチェックリストだからだ。逆に、何らかの理由で今のモデルが使えなくなり、性能で劣るモデルに戻さざるを得なくなったとしても、出力の最低品質ラインは変わらない。
これは、賢いモデルが出るたびに一喜一憂して、そのモデルの調子に運用全体を委ねている状態とは、精神的な安定度がまったく違う。
個人で長く発信や開発を続けていく上で、「特定の一点への依存度が低いこと」は地味だが効いてくる。EMとして、優秀な一人に依存しないチーム設計を大事にしてきたのと同じ理由で、優秀な一つのモデルに依存しないAI運用を大事にしている。
締め: EMの経験が、そのままAI運用に効いた
「賢いAIが出た」というニュースに飛びつくこと自体は悪くない。実際、私も新しいモデルの話は毎回楽しみにしている。
ただ、そのニュースに一喜一憂する運用と、どのモデルが来ても一定品質を保てる運用は、まったく別のレイヤーの話だ。前者は瞬間最大風速を追いかける遊びで、後者は長く事業や発信を続けるための土台になる。
チームの品質を、特定の優秀な個人に依存させず仕組みで守る。この考え方を何年もかけてEMとして磨いてきたことが、まさかAI運用の設計にそのまま転用できるとは、この仕組みを組むまで思っていなかった。
賢いAIを探す前に、賢くないAIでも一定の品質が出る仕組みを先に作っておく。遠回りに見えて、これが一番効く投資だと今は思っている。
*私は現役EMとして、1on1やチーム運営の仕組み化について書いています。1on1管理のNotionテンプレート（無料Lite版）を公開中です → 試してみる。X: @anikuma_tech*
コメント