「95%はAIの仕事」の正体
前々回の記事で、僕は「この解説ガイドの95%以上はClaude Codeが作った」と書きました。これは嘘ではないんですが、正確でもない。
前回の記事でパイプライン構築の技術的な話を書いたあと、ふと気になったんです。「じゃあ残りの5%って何だったんだろう？」と。
そこで、このプロジェクトの全会話ログを洗い出してみました。3日間、延べ数十時間の作業記録から、僕が実際に判断・介入した瞬間を1つずつ拾い上げた結果、68件ありました。
今回は、この68件を分類しながら「AIに任せたコンテンツ制作で、人間は本当は何をしていたのか」を振り返ります。
68件の内訳
会話ログから抽出した人間の介入ポイントを、5つのカテゴリに分類しました。
| カテゴリ | 件数 | 割合 |
|---|---|---|
| 音声・ビジュアルの品質判断 | 30 | 44% |
| デザイン決定 | 13 | 19% |
| 戦略的決定 | 12 | 18% |
| エラー検出 | 7 | 10% |
| 好み・感性判断 | 6 | 9% |
最も多いのは「品質判断」で全体の44%。 つまり、人間の仕事のほぼ半分は「聞いて、見て、違和感を伝えること」でした。
カテゴリ1: 耳と目による品質判断（30件）
これが一番多かった。AIが生成したものを「聞く」「見る」して、違和感を伝えるという作業です。
音声の品質チェック
edge-ttsで生成した音声を全ページ分聴き返す作業は、ひたすら地味です。でもここで拾った問題が23件。
– 「背景」が中国語風に読まれている
– 「互換的」が「ゴカンマト」に聞こえる
– 「2.4」が「ツーポイントフォー」と英語読みになっている
– セクション間の「間」が足りない — 「0.2秒ほしい」「0.5秒でも間がほしいですね」
1ページ聴くたびに2-3個の修正点が見つかる。修正して再生成して、また聴く。このループを25ページ分繰り返しました。
ビジュアルのチェック
視覚的な判断も7件ありました。
– Mermaidダイアグラムを見て「ダサい」と判断 → HTML+CSSに切り替え
– ヘッダーの黒背景が「違う」と感じた
– 3色パレット（青・コーラル・グリーン）に統一する方針を決めた
面白いのは、これらはすべて即座の直感なんですよね。「ダサい」に理由を説明するのは難しいけど、その判断がHTML+CSSへの大きな方向転換につながっている。
カテゴリ2: デザイン決定（13件）
構造やフォーマットに関する「こうしよう」という決定。
– 音声をパート別に分ける方針: 「パート別が良いですかね」
– ポーズの長さ: 「セクション間は0.5秒、文末は0.2秒」
– 英語テック用語はカタカナ読みにする方針
– edge-tts + Florianの声を維持する判断
– MkDocs Materialテーマの採用
これらの判断には「正解」がないんですよね。たとえば音声のポーズを0.3秒にしても0.7秒にしても、どちらも「正しい」。でも0.5秒がちょうどいい、という感覚は聴いてみないとわからない。
カテゴリ3: 戦略的決定（12件）
プロジェクト全体の方向性に関わる判断。
– ターゲット設定: 「いろんな人に広く適用できつつ」→ 非エンジニア向け初級ガイドという方向性
– 二重プロジェクト化: ガイド制作とパイプライン検証を同時に進める戦略
– ファクトチェック指示: 「出典を確認したい」— これがなければ架空のデータが公開されていた
– claude.mdを「分離可能な外部ナレッジストレージ」として紹介するアイデア
特に「ファクトチェック」は重要です。AIは自分の出力を疑えない。「このデータ、出典ある？」と聞いたのは人間で、その結果、NRIの架空統計（AIが捏造した29%→55%というデータ）が公開前に発覚しました。
カテゴリ4: エラー検出（7件）
AIが作り出した誤りを発見した瞬間。件数は少ないですが、インパクトが大きい。
– 架空統計データの発見: 「出典元のソースリンクにできませんか？」→ 調べたら出典が存在しない。AIが作った架空のデータだった
– デプロイ先パスの間違い: AIが間違ったパスにデプロイしようとした
– プロジェクトの取り違え: 「それ、inouekabuですよね？」— AIが別プロジェクトのテーマと混同
– 正規表現の適用順序バグ: 修正を入れたのに「確認しましたが、まだ読まれていますね」と伝えた
– コンテンツ脱落: 音声生成の修正が意図しない副作用を起こしていた
– キャッシュ問題の特定: AIが「デプロイ完了」と言ったが、実ブラウザでは古いバージョンが表示されていた
– メタデータの音声混入: 発音辞書のキー自体が音声出力に混入するバグ
7件中5件は「AIが完了と言ったのに実際にはおかしい」というパターンです。AIは自分のアウトプットを実際に聞いたり見たりできないので、「本当に正しいか」の最終確認は人間にしかできない。
カテゴリ5: 好み・感性判断（6件）
最も言語化しにくい判断。
– 「Florianの声質が好きなんだけどな…」 — 他の選択肢を検討しつつも、声の好みで現行を維持。この好みが70語超のREADING_MAP辞書を作る動機になった
– 「ヘッダーがブラックは違ったなぁ…」 — 感覚的な違和感による即座の却下
– 「間」の感覚 — 「0.2秒」「0.5秒」という具体値は聴覚的な好みに基づく
「好み」はたった6件ですが、プロジェクトの根幹を規定しています。Florianの声を使い続ける判断がなければ、READING_MAPも、モンキーパッチも、4回失敗した中国語読み対策も、すべて不要だった。
じゃあ「5%」は何だったのか
コード量で言えば、確かに95%以上はAIが書いています。generate_audio.py（500行超）もgenerate_video.py（800行超）も、音声生成スクリプトも動画生成スクリプトも、僕が1行も手で書いていません。
でも68件の介入を見ると、人間の仕事は「コードを書くこと」ではなかったんですよね。
人間の仕事は3つに集約される
1. 感覚器官による品質保証（44%）
聞いて、見て、「これは違う」と伝える。AIは自分の出力を聴けないし、「ダサい」もわからない。
2. 方向性の決定（37%）
何を作るか、誰に向けるか、どんなトーンにするか。「正解のない判断」は人間の領域。
3. 信頼性の担保（19%）
ファクトチェック、エラー検出、最終確認。AIは自分を疑えない。
時間配分で見ると
3日間の作業を通して、僕がキーボードを叩いていた時間は1時間もないと思います。会話のための入力がほとんどで、コードを直接書いたのは5分もない。
でも「音声を聴き返す」「画面を見て確認する」「方針を考える」時間を合わせると、僕の作業時間は全体の30-40%くらいあったんじゃないでしょうか。キーボードを叩く時間と、実際に「仕事をしている」時間は全く別物なんですよね。
「95%はAIの仕事」は、コード量の話。
時間で見ると「60-70%がAI、30-40%が人間」。
でもこれは当然のことだと思っています。そもそも前々回の記事で書いた通り「0から1は自分」であり、今回作っているのはAI向けではなく人間向けのコンテンツです。人間の介入が10%で済むなんてことは、現時点ではほぼあり得ない。
とはいえ、80%のところまで持っていくのは5%くらいの労力というのは、あながち嘘ではないんですよね。残りの80%から100%への品質向上 — 発音の微調整、色の好み、「間」の感覚 — そこに人間の介入が集中しているだけです。
そして面白いのは、この割合は徐々に変わっていくだろうということ。今回のプロジェクトで得た知見 — 発音辞書の設計ルール、デプロイ順序、音声除外タグの使い方 — は、すべてclaude.mdやメモリーに記録しています。次に同じようなコンテンツを作るとき、AIはこれらの知見を最初から持っている。つまり、今回30-40%だった人間の仕事は、次回は20-30%になるかもしれない。
人間の仕事は「なくなる」のではなく、「より上流に移動していく」。 発音辞書のチューニングは自動化されても、「誰に向けて何を作るか」という判断は残り続ける。
「意図を正確に伝える」こと自体がスキル
68件を振り返って、もう1つ気づいたことがあります。
前回の記事で書いた「トランジションのタイミングを4回説明した」話。僕の頭にある「ナレーション終了 → トランジション開始 → トランジション完了 → 1.5秒待ち → 次のナレーション」という順序を、AIに正確に伝えるのに4ラウンドかかりました。
これは「AIが頭悪い」んじゃなくて、「人間の頭の中のイメージを言語化するのが難しい」んですよね。「1.5秒の間がほしい」と言ったら、AIはナレーション終了後に1.5秒の無音を追加した。でも僕が欲しかったのは「トランジション完了後の待ち」であって、「ナレーション後の無音」ではなかった。
AIとの協業で最も価値のあるスキルは、コーディングではなく「自分が何を求めているかを正確に言語化すること」かもしれません。
「やったことがなくても試す」こと自体もスキル
もう1つ、68件を振り返って感じたことがあります。
今回のプロジェクトで僕がやったことの多くは、正直「初めて」でした。FFmpegもMarpも、触ったことがなかった。動画編集だってまともにやったことがない。
多くの人は「具体的な使い方がイメージできない」「自分には技術がない」という理由で、新しいことを試すのをためらうと思います。僕だってそういうときはあります。
でもAIと一緒に作業すると、失敗の時間的コストが劇的に下がるんですよね。
たとえばFFmpegのxfadeトランジションの話。24枚のスライドそれぞれに異なる22種類のトランジションを設置して、AIがベストプラクティスから提案してくれたものを聴き比べて好みで選ぶ。これ、全部で10分くらいなんですよね。手動でフィルタチェーンを書いていたら1種類あたり数十分かかるところが、AIと一緒なら「全部見てから選ぶ」ができる。
この「失敗にかかる時間の短さ」が、実は「95%はAIの仕事」という感覚の正体なのかもしれません。
試す時間が短い → だからどんどん試せる → 試すからAIの使い方がわかってくる → さらに試す速度が上がる。
このループが回り始めると、「やったことがない」は障壁ではなくなる。むしろ「やったことがないからこそAIと一緒に試してみよう」になる。68件の介入のうち、デザイン決定13件の多くは、まさにこの「試してから判断する」プロセスから生まれたものでした。
この記事シリーズ全体を振り返って
3本の記事を通して、1つのプロジェクトを3つの角度から書いてきました。
– 記事1: 何を作ったか（成果物の紹介）
– 記事2: どう作ったか（技術検証）
– 記事3（本記事）: 誰が何をしたか（人間とAIの役割分担）
全部通して見ると、AIとの協業は「AIに仕事を任せる」というより「AIと一緒に品質を作り上げる」という感覚に近い。AIが大量のコードやテキストを生成して、人間が耳と目と直感で磨き上げる。
68件の介入のうち、44%が「聞いて、見て、違和感を伝える」だったことが、その何よりの証拠だと思います。
ぜひみなさんも、AIとの作業ログを振り返ってみてください。「自分は何をしていたのか」が見えてくると、AIとの付き合い方がもう少しクリアになるかもしれません。
この記事が参考になったら
Share