ひらの

生成AIを業務に入れるときに実際に効くのは、作る速さよりも「何を機械で弾き、どこで止めるか」の設計だと考えています。 以下は個人で構築・運用しているパイプラインの記録です。数値はすべてログからの実測で、母数と観測期間を併記しています。

生成AIの制作ラインを無人化し、fail-closed な品質ゲートで運用した

解説動画チャンネルについて、題材の選定から台本生成・音声合成・レンダリング・投稿までを毎朝定時に無人で走らせるラインを構築しました。生成AIをそのまま公開に繋ぐと事故るため、公開前に3層の自動検査を通し、基準を割った原稿は公開せず引き直します。引き直しが上限に達した場合はその日は1本も公開せずに停止します（fail-closed）。停止後に原因を特定して直すところまでを運用に含めています。

• 公開前チェックの実行件数314件原稿78本に対して実施 / 2026-07-01〜08-12（43日間）
• 公開を止めた率21.0%66件 / 314件。約5本に1本を公開前に差し止め
• 人が手を入れた回数2回43日間の日次実行中（介入率4.7%）。いずれも仕組みが自ら停止した際の原因調査
• 最長の連続無人稼働33日2026-07-11〜08-12。稼働カバー率 95.3%（41日 / 43暦日）
• 失敗検知から復旧まで同日中2026-07-31 の停止事例。検知から公開復帰まで
• 1回の実行あたり所要時間中央値 86.0分同型の音楽ライン18回の機械時間 / 範囲80〜92分 / 2026-07-25〜08-12。人の作業時間はゼロ

障害事例: 2026-07-31 の停止（その日の公開ゼロ）

LLM に LLM を検査させるとき、1票では信用できない

文体ゲートは同系統モデル2票＋別系統モデル1票の3票合議にしています。票が揃わない・取得できない・配線が誤っている場合はすべて「通さない」に倒します。実測（36判定）では、同じモデルに同じ原稿を渡しても判定が割れた率が 22.2%（8/36）、3票が全一致したのは 47.2% でした。単一のAI判定を業務に組み込むことの危険性が、この数字にそのまま出ています。

「判定器が甘い」と「判定器に材料が無い」は別

別系統モデルの席が長く差し止めを出さなかったため甘さを疑いましたが、意図的に基準を踏ませた合成原稿5本では5/5を差し止めました。外していたのは既視感の軸だけで、原因はその席が過去回にアクセスできず比較が原理的にできないこと、つまり性能ではなく入力の欠落でした。挙動から性能を推定する前に、判定器が何を見せられているかを確認します。

AIで取れない層は機械的なガードに降ろす

締めの定型文が49本中31本（63%）で同一になっていましたが、これは両方のAI判定を素通りしていました。原因は判定の甘さではなく、規則ファイルが例文をそのまま渡していた仕様どおりの挙動でした。「並べないと見えない」性質はAIの単発判定では取れないため、機械的なガードに降ろして検出するよう変更しました。

監視の異常を単体で診断すると原因に辿り着けない

ゲートの監視が異常終了を出していましたが、原因はゲートではなく課題台帳のDBが書き込み不能で、監視が結果を書き込めなかっただけでした。DBを直したら監視も自動回復しました。監視が壊れたときは、まず「その監視は何に書きに行くか」を見ます。

他人が引き継げるか

実行手順は文書ではなくスキル定義ファイルに実装されており、読めば同じものが再現できます。ゲートの合否条件はコード側にあり判定者の裁量に依存しません。異常は自動で課題台帳に起票され、直るまで消えず、直ると自動で消えます。ただし停止時の原因特定は現状まだ人間の作業で、ここは自動化されていません。

この実績の限界

• これは個人プロジェクトであり、受託案件でも商用の大規模システムでもありません。発注元・納期・SLAは存在しません。
• 「削減工数」は掲載していません。このラインは最初から自動化として作られており、自動化前の手作業時間が存在しないため、差分は必ず推定になるからです。
• 「1件あたりの人間介入時間」は未計測です。現状は介入の回数までしか記録していません。
• 他人に引き渡して運用させた実績はありません。

数値の観測期間: 2026-07-01 〜 2026-08-12（43日間）