はじめに
背景
普段はエンジニアとして、Classi で提供している学習トレーニング機能の問題を管理するCMSの機能強化などを行っています。それが2025年度からは開発だけでなく「コンテンツチーム」にも兼任という形で所属することになりました。 目的はシンプルで、「コンテンツ制作の現場と連携を強化し、その知見をCMS開発へダイレクトに反映していくこと」です。
趣旨
この記事で伝えたいことは以下の3点です。
- CMSへの「入稿前段階（コンテンツデータ作成）」に関わることで、エンジニアの貢献ポイントが劇的に増えた。
- Vibe Coding（Claude Code等）で「使い捨てスクリプト」を量産し、AI（Gemini等）で「中身」を補完することで、開発・制作双方の工数を圧縮した。
- 「100点を目指さない（AI活用）」×「汎用化を目指さない（ワンショットスクリプト）」という割り切りが、最大の成果を生んだ。
※このエントリーで取り扱っている「コンテンツ」は、Classiの「学習トレーニング」上で生徒さんが取り組む「問題」のことを指しています。さまざまな科目、利用用途に合わせて問題群を充実させていくようにコンテンツチームが中心となって制作をおこなっています。
発見：「入稿」の前にエンジニアの仕事があった
これまでの認識と現実
チームに入るまで、私はコンテンツのフローを以下のように認識していました。
- コンテンツ制作
- CMSに入稿 （← ここからがシステム/エンジニアの領分）
- 編集・検収
- 公開
しかし、学習コンテンツの制作現場に入って作業を見てみると、景色は全く違いました。 ユーザー（制作担当）は「CMSに入稿する」ずっと手前の段階で、WordやExcelのデータ整理・整形、コピペ、フォーマット変換といった「作業」に多くの工数を使っていたのです。
エンジニアリングで解決すべき課題は、CMSの中ではなくその「手前」に山積していました。
ヤコブ・ニールセンの教え
ユーザビリティの大家、ヤコブ・ニールセンの言葉に以下のものがあります。
"Pay attention to what users do, not what they say." （ユーザーが言うことではなく、ユーザーがすることに注目せよ）
ユーザーは「入稿データ作成を省力化できるPythonスクリプトが欲しい」とは言いません。黙って手を動かして作業を進めています。 チームに入り込み、そのプロセスそのものを観察したことで、新たな貢献ポイント（入稿データの変換・整形・自動生成）を見つけることができました。
フローの劇的な変化
この発見の結果、施策を通してワークフローは以下のように変貌しました。
- Before: 工数の大部分を「整形・調整・入力」という作業が占めていました（図の赤色部分）。
- After: 「作業」工数はスクリプトとAI（図の青色部分）が肩代わりし、ほぼゼロに。人間は「クオリティアップ・検収」に全振りできるようになりました。
戦術①：Vibe Codingによる「使い捨てスクリプト」戦略
「実行」はAIではなくスクリプトで
当初はデータプラットフォームチームが、データのコンバート・整形そのものをAI（LLM）に行わせる検証をしていました。しかし、「定型処理が多いなら、確率的なAIに頼るより、ロジックが明確なプログラムで処理すべき」という結論に至りました。
この「無理にAIで処理させようとしなかった判断」は、今振り返るとファインプレーでした。結果として「ルールベースの堅実なスクリプト」を採用することになり、その「スクリプトを大量に書くコスト」をどう解決するか？という点に課題がフォーカスされたことで、後述するVibe Codingの活用が活きてきたからです。
早すぎる最適化はしない
学習用コンテンツは、教科や難易度、ユースケースごとにデータの形態がバラバラで、画一的な一括したシステム対応が困難でした。 以前の私なら、「毎回フォーマットが違うならシステム化は無理。汎用的なインポート機能ができるまで手作業でお願いします」と断っていたかもしれません。
しかし今回は、「汎用化は半年後。それまでは毎回ワンショット（使い捨て）スクリプトを書く」と割り切る戦略を取りました。
Vibe Codingがそれを可能にした
ファイルごとに異なる変換スクリプトを書くのは、本来コストが高い作業です。しかし、2025年の私たちにはVibe Codingがあります。
- Claude Code / GitHub Copilot Agent の活用： 「このExcelの構造を解析して。CMSの入稿フォーマットはこれ。変換スクリプトを書いて」と投げるだけです。
- 複雑な正規表現や構造変更のロジックを、人間が知恵を絞ってを絞って書く必要がない。
- 数分でスクリプトが完成するから、「その場限りの使い捨て」にしても痛くない。
これにより、「Web UIで大量のWordファイルを手動入稿する」代わりに、「スクリプトで一括コンバート＆API入稿」したり、「根本的に形式が違う他プロダクトのデータを強制変換」したりといった荒技が、低コストで実現できるようになりました。
戦術②：アウトプットは「70点」でいい
スクリプトとAIの合わせ技で「下書き」を作る
スクリプトで構造は作れますが、中身の「解説文」や「足りない選択肢を増やす」までは自動化できません。そこで生成AI（Gemini等）をAPIで組み合わせました。
- ワンショットスクリプト: 構造化、フォーマット変換、ID付与などの「ルール」を定型的に処理。
- 生成AI: 元データに足りない「解説」や「選択肢」を創造的に補完。
この組み合わせで出力されるのは「70〜80点」のデータです。 構造は維持しますが、定型処理で拾いきれない例外、AI生成部分には嘘や違和感が混ざります。しかし、これを「入稿完了」ではなく「人間がチェックするためのタタキ台」と定義し直しました。
極端な例では、紙媒体のPDFから生成AIをOCRのように使い無理やり構造化し、「50点」程度の精度でCMSに突っ込んだこともあります。それでも「人間がゼロから文字を拾って入力する」よりは、遥かにマシだからです。
「100点を目指さない」という合意形成
- 以前の常識: コンテンツは人間が100%の品質で作ってから入稿するもの。
- 新しい常識: システムが70%の完成度でCMSに入れておく。人間は残りの30%（ファクトチェック、校正）を埋める。
どういう形であれ、最後は人間が検収します。「ゼロから書く」より「ある程度のものを直す」ほうが圧倒的に速い。このマインドセットの変更こそが、技術導入以上に重要でした。
結果：エンジニアリングの委譲がもたらした成果
Vibe Codingがあったから成立した体制
コンテンツの「制作作業」をシステム（スクリプト＋AI）に委譲し、それを実装するエンジニアの「コーディング作業」もAI（Vibe Coding）に委譲する。
この「二重の委譲」があったからこそ、限られたエンジニアリソースで「作業」をハックすることができました。 結果として、2025年上期に全ての問題制作のリードタイムを4割削減。約3,000問のコンテンツをコンバートするプロジェクトでは、作業工数を当初の見積もりから9割削減するという成果が出ました。
これからの展開
「当たり前」になりつつあるこのフローですが、現在のインターフェースは「特定のエンジニア（私）」であり、属人化のリスクがあります。 貢献度が明確になった今、次はフェーズを変えなければなりません。 今後はワンショットスクリプト群の中から「汎用的に使えるロジック」を抽出し、CMS本体の機能として実装することで、エンジニアの手を離れても回る仕組みを目指していきます。
また、「70点で良い」はあくまでも現時点の話として、精度を上げていく取り組みを続けていく必要があります。
おわりに
この1年で、私の役割は「CMSを作る人」から「コンテンツ制作のあらゆる場面でエンジニアリングで課題を解決する人」へと変わりました。
AIによってコードを書くコストが下がった今、エンジニアの価値は「コードを書くこと」そのものではなく、「どこにコードを適用すれば最もレバレッジが効くか（＝課題発見）」にシフトしています。 その課題を見つけるためにも、ユーザー（制作担当）と距離を近くし、伴走することの重要性を改めて学んだプロジェクトでした。
