AIを入れたのに最初は時短にならない理由

AI開発ツールを使えば、コードもブログもすぐ完成すると思っていました。

実際、CodexやClaude Codeへ依頼すると、たたき台は速く出ます。しかし、使い始めた直後は、そのまま使えるかを確認する仕事が増えました。

ブログでは事実確認、コードでは差分確認、型チェック、ビルド、公開後の確認が必要です。指示より広い範囲を変更されたら、戻して伝え直すこともあります。

最初は、AIを使う前より確認項目が増えたように感じました。

先に結論

AIが時短になるのは、初回からではなく、同じ種類の作業を繰り返し、指示と確認の型ができてからです。

最初に増えるのは、主に次の時間です。

• 出力内容の確認
• 事実の出典確認
• コードレビュー
• 意図を伝え直す時間
• 変更しすぎた箇所を戻す時間
• どこまでAIへ任せるか決める時間

これらを含めず、AIが出力するまでの秒数だけを見ても、実際の時短は測れません。

ブログ生成では、自然な誤情報を見抜く時間が増えた

確認作業の重さが最も分かりやすかったのが、運営サイトの記事に誤情報が混ざった事例です。

受講期限について説明する記事に、**「1,100円で6か月延長できる」**という制度がある前提の文章が入っていました。

金額も期間も具体的で、1か月あたり約183円という計算も合っていました。文章としても自然です。しかし、その制度は公式情報で確認できませんでした。

確認のために保存した公式FAQは102件です。そこで確認できたのは、無料で2年間延長できる別の制度でした。

結果として、「1,100円」という文字だけを削除したのではなく、3つの選択肢を比較していたページを、確認できた2つの選択肢へ構成から直しました。

この経緯は、AIを使って情報整理したら実在しない制度が混ざった記事に、確認した件数と修正内容を残しています。

AIが最初の文章を作る時間は短くても、前提が正しいかを確認し、間違っていれば周辺まで直す時間が必要でした。

文章レビューだけでは足りなかった

この誤情報は、誤字脱字の確認では見つけられません。

• 日本語は自然だった
• 計算は合っていた
• 比較表の辻褄も合っていた
• 数字の一部は別制度で実在していた

問題だったのは、説明の前提です。

そのため、AI生成のブログを確認するときは、文章の読みやすさとは別に、料金、制度、期限、契約条件を一次情報へ戻って確認する工程を置くようになりました。

「AIに出典を書かせる」だけではなく、リンク先に本当に同じ条件が書かれているかを人間が見ます。

コード生成では、buildが通ったあとにも確認が残る

コードも同じでした。

AIが出したコードは、構文として正しく、ビルドも通ることがあります。それでも、変更範囲が意図どおりとは限りません。

うにラボでは、ABC関連記事だけを別サイトへ移す際、Next.jsのリダイレクト条件を広くしすぎて、残すはずのブログ一覧や無関係の記事まで転送したことがあります。

この問題では、移行対象URLが正しく転送されることだけでなく、移行しないURLが残っていることまで確認する必要がありました。詳しくは、ブログ全体をリダイレクトしてしまった失敗に実際の条件と修正方法を書いています。

この失敗をAIが起こしたと断定できる記録はありません。ただし、AIにコードを生成させる場合でも、同じ確認が必要です。差分が小さく見えても、対象外のURLや既存機能への影響は人間が確かめなければなりません。

細かな修正が増えると、Gitとデプロイの運用も重くなった

AIを使うと、文言修正やコード修正を細かく繰り返しやすくなります。

以前は、GitHub上で差分を確認するためにdevへpushしていました。しかしdevはAWS Amplifyの検証環境につながっていたため、レビューのたびにビルドとデプロイが走っていました。

そこで、役割を次のように分けました。

• featureブランチ：開発とコードレビュー
• devブランチ：検証環境
• mainブランチ：本番環境

変更後は、npx tsc --noEmitとnpm run buildを通し、featureブランチで差分を確認し、ブラウザ確認が必要な段階だけdevへ反映します。

Amplifyの自動デプロイを減らすためにGit運用を変えた記事で書いたように、AIの出力速度を活かすには、周辺のレビュー手順も整える必要がありました。

それでもAIを使い続けた理由

確認が増えてもAIを使い続けたのは、同じ種類の作業を繰り返すほど、次回へ残せるものが増えたからです。

• 記事の事実確認で見る一次情報の順番
• コード変更後に実行する確認コマンド
• Gitの差分で見る項目
• リダイレクトで確認する対象URLと対象外URL
• 公開後に確認する画面やレスポンス

最初は毎回考えていたことを、指示や手順として残せます。

また、人間の役割も変わりました。白紙から全部作るより、AIが用意した案に対して、採用するか、どこが危険か、何を確認するかを判断する時間が中心になります。

時短を感じるのは、作業の型ができてから

現在、AIを使った初回作業と、同じ手順を再利用した後の作業時間を比較できる記録はありません。

そのため、「何回目から何分短くなった」とは書けません。

ただ、リポジトリに残っている変更からは、次の状態になったことを確認できます。

• 記事の重要な数字は一次情報へ戻る
• 型チェックとビルドを確認する
• 変更対象と対象外を両方確認する
• review用ブランチとdeploy用ブランチを分ける
• 公開後の画面まで確認する

この型があると、次の依頼では確認方法をゼロから決めずに済みます。

まとめ

AIを入れた直後に時間が増えるのは、出力を受け取ったあとに何を確認すべきか、まだ決まっていないからです。

ブログなら一次情報、コードなら差分・テスト・公開後の挙動まで確認します。最初はこの設計に時間がかかります。

それでも、使えた指示と確認手順を残すと、同じ種類の作業では再利用できます。

AIの時短は、最初の1回の速さではなく、作業の型を次回へ持ち越せるようになってから表れると考えています。