「AIを業務に使いたいが、自社の何に活かせるのか具体的にわからない」——経営者やマネジメント層からよく聞く悩みです。

筆者はWeb制作の実務でスプレッドシートとAIを組み合わせて使っています。この記事では、実際の案件で使った3つの事例を、実際のプロンプト・ハマった点・Before/Afterの数字つきで紹介します。きれいな成功談だけでなく、「まだ工数削減になっていない」領域も正直に書きます。

まず結論の一覧です。

事例使ったツールBefore(人力)After(AI)
① 600ページのブラウザチェックClaude Code + Claude in Chrome最短でも約2.5時間30分以内・拘束時間ほぼゼロ
② 翻訳入力フォーマット生成(972行)Claude Code約80分10分程度・拘束時間ほぼゼロ
③ テストケース作成・実行NotebookLM + Claude in Chrome—作成は効果大/実行は見極め中

共通しているのは、スプレッドシートを「AIと人間の間のインターフェース」として使うという考え方です。順に説明します。

事例1:スプレッドシートを「AIへの指示書」にしてブラウザチェックを自動化する

やったこと

既存サイトの改修案件で、「全ページのtitleタグとh1を一定のフォーマットに統一する」という対応がありました。対象はおよそ600ページ。実装後の検品として、全ページのtitleとh1が仕様どおりになっているかを確認する必要があります。

手順は次のとおりです。

  1. 対応ページの一覧(URL・あるべきtitle・あるべきh1の対照表)をスプレッドシートに用意する
  2. AIエージェント(Claude Code、モデルはClaude Fable)にスプレッドシートのURLを渡してチェックを指示する
  3. AIは curlで取得したHTML と Claude in Chromeでの実際のブラウザ表示 の2段階でチェックする
  4. NG箇所がチャットで列挙されるので、修正して再実行する

実際に打ったプロンプトは、記録が残っていないため記憶ベースの再現ですが、次のような短いものでした。

今回行った実装の対照表はこちら(スプレッドシートURL)です。
ブラウザで実際の結果をテストしてください

対照表の読み方や変換はAI側が勝手にやってくれます。スプレッドシートのURLを渡すだけで、チェックリストとして解釈してくれるのがポイントです。

curlとブラウザの2重チェックにしたのは、HTML取得だけでは実際の表示を保証できないためです。結果として、この2重チェックが漏れを防いでくれたと感じています。

AIが「人間の実装ミス」を見つけた

このチェックで実際に、実装時の不具合をAIが検出しました。具体的には、変数がコメントアウトされたままになっていたのを、AI自身がコーディング時に見落としていたケースです。ブラウザチェックの段階でAIが「期待値と違う」ことに気づき、原因の特定から修正まで自分で完了させました。

600ページ規模の改修では一発で全部OKにはならず、テストは3回実行しました。その間、私がやったことは実質2つだけです。

  • テストの再実行を指示する
  • 最終ゴールを明確に伝える(「このリストに対して、titleタグとh1が〇〇というフォーマット通りの記述になっていることをブラウザ上で確認すること」)

数字:最短2.5時間 → 30分・拘束ゼロ

  • 人力の場合:1ページ最短5秒で見たとしても、5秒×600ページ×3回=9,000秒(約2.5時間)。実際は集中力の低下やミスを考えるともっとかかるはずです
  • AIの場合:正確な記録はありませんが体感で30分以内。しかもその間、私はgit worktreeで別ブランチを切って別の作業をしていたので、拘束時間は実質ゼロです

600ページ×2項目(title/h1)=延べ1,200項目を、人間は一度も目視していません。それでも人力より漏れが少ないと感じます。人間が同じ画面を600回見続けたときの精度低下を考えれば、むしろ当然かもしれません。

なお、このように大量のチェックリストをスプレッドシートで管理する場合、対応状況を条件付き書式で色分けしておくと進捗の把握が楽になります。

事例2:多言語サイトの翻訳入力フォーマットをAIに作らせる

やったこと

多言語サイト制作では、今でも人間の翻訳家に翻訳を依頼するケースが多くあります。そのとき地味に工数がかかるのが、翻訳家に渡す入力フォーマットの作成です。

担当した案件では、多言語対応の原稿が言語ごとのphpファイルで定義されているシステムでした。日本語のphpファイルをベースに、Claude Code(モデルはClaude Fable)へ次のように指示しました(記憶ベースの再現です)。

多言語対応の原稿は言語ごとのphpファイルで定義されています。
翻訳家に渡す入力フォーマットとして、日本語のphpファイルをベースに
「どの箇所の値か/どんな値か/日本語の現在の値」を列にしたCSVを作ってください。
対象言語は英語、繁体字、簡体字です。
各言語の列は翻訳家の入力欄とするため空欄としてください

AIは内部で抽出スクリプトを書いて実行していたはずですが、そこは確認していません。私がやったのは、出てきたCSVの中身をチェックして、Google Driveの共有フォルダに上げただけです。あとはGoogleスプレッドシート形式にして、翻訳家に空欄セルを埋めてもらう運用です。

ポイントは「各言語の列は空欄にする」と明示したことです。翻訳家の入力欄をあらかじめ設計しておくことで、納品されたシートをそのまま流し込み用データとして使えます。

結果:一発OK、翻訳家からの指摘もなし

CSVは文字化けもキーの漏れもなく一発でOKでした。翻訳家からフォーマットについてのフィードバック(使いにくい等)もありません。

  • 規模:1案件あたり324行。同規模の案件を3サイト分行ったので、合計約970行
  • 人力の場合:phpファイルからキーと日本語値を1行5秒でコピペしたとして、約4,860秒(約80分)。実際は転記ミスの確認も必要です
  • AIの場合:実行は10分程度(体感)。ここでも並行作業していたので拘束時間は実質ゼロ

事例1と比べると地味ですが、「AIに丸ごと任せて、人間は成果物のチェックだけする」型の仕事として再現性が高い事例です。

事例3:NotebookLMに過去のテストケースを学習させてテスト設計を半自動化する

前提:テストケースの資産がスプレッドシートに溜まっている

システム開発の受け入れテストでは、テストケースをスプレッドシートで管理しています。列構成は概ね次の形です。

No / テストカテゴリ / テスト項目 / 入力値例(操作内容) / 期待値 /
結果(Mac) / 実施日 / 結果(SP) / 実施日 / 担当者 / 詳細

社内では主要メンバー3人によるテストケースの相互レビューを義務化しており、そこで出た指摘は同じスプレッドシートの「指摘事項」タブにストックしています。

この資産——過去のテストケース約50件分と、それに対する指摘事項——をNotebookLMに読み込ませておくのがこの事例の肝です。

機能概要を渡すと、過去の指摘を踏まえたテストケースが出てくる

新機能のテストケースを作るときは、NotebookLMに機能概要と指示を渡します。実際のプロンプトはこの形でした(機能の詳細は伏せています)。

機能概要:
(改修内容の説明。例:コピーしたデータを連続で貼り付けられるようにする仕様変更)

AとBのパターン、同一ページへの複製と、別ページへの複製のパターンでテストを作成してください。
なお、過去のテストケースを参考に、他にチェックすべき点があれば追加してください

すると、指示したパターンのテストケースに加えて、過去のレビュー指摘に由来する観点が自動で追加されて返ってきます。実際に追加された観点は次のようなものでした。

自動で追加された観点由来
データの独立性(複製元を編集しても複製先に影響しないか)過去レビューでの指摘
Undo/Redoの履歴管理(連続操作が1回ずつ取り消せるか)過去テストの必須項目
追加不可エリアのバリデーションが維持されているか過去に不具合が出やすかった箇所
新しいコピーで古いデータが正しく上書きされるか仕様変更に伴う派生観点

出力はTSV形式で返ってくるので、そのままスプレッドシートに貼り付ければテストケース表になります。「過去のテストケースを参考に、他にチェックすべき点があれば追加してください」の一文が効いていて、チームの過去の失敗が観点として蓄積・再利用されるのがNotebookLMを使う最大の理由です。

弱点もあります。すでにチェック済みの項目を再度提案してくることはあるので、最終的な取捨選択は人間がやります。

テストの「実行」はまだ見極め段階

作成したテスト手順の実行はClaude in Chromeに任せ、結果をチャットで受け取って人間がスプレッドシートの結果列に転記しています。一次チェックをAIが済ませ、人間が最終チェックする体制です。

ただし、正直に書くとこの領域はまだ工数削減効果が大きくありません。理由は次のとおりです。

  • テスト結果を踏まえた再依頼のやり取りが増えた
  • 現状AIのみでは不安が残るため、人力でのテストも並行して行っている
  • スマホ表示のチェックはうまく動作しないことが多く、手動に切り替える機会が多かった

並行作業できるという意味で「テストに張り付く時間」はゼロになりましたが、トータルの工数はまだ大きくは減っていません。現在は、AIがどこまでできるかを見極めて、将来の自社利用における最適解を探している段階です。

AIがまだ苦手なこと・任せていないこと

3事例を通して見えてきた、現時点でのAIの苦手分野です。

  • ログイン・認証が複雑に絡むケース:ブラウザ操作の自動化が安定しない
  • 見た目でしか判断できない点:「UIがわかりにくい」「動作が遅い」といった、人間の感覚に依存する評価
  • スマホ実機相当のチェック:エミュレーションでの動作が不安定なことが多く、手動に頼りがち
  • チェック済み観点の重複提案:NotebookLMは便利だが、取捨選択は人間の仕事

もうひとつ、運用上の注意点として実感しているのがモデル更新時の挙動変化です。モデルを最新にした途端、それまで禁止していたgit commitを勝手に実行してしまうことが増えました。AIの性能が上がる=既存の運用ルールがそのまま通用する、ではない点は覚えておいて損はないです。

事故を防ぐ権限設計:AI専用アカウント+read権限

AIに業務データを触らせる上で、社内で決めている運用ルールを紹介します。

  1. AI専用のアカウントを別途作成する(人間のアカウントを使い回さない)
  2. そのアカウントに対して、必要な資料にだけread権限を付与する
  3. コードはすべてgit管理し、git差分を人間がチェックする工程を必ず挟む

この構成にしておけば、AIが暴走しても書き込み事故は起こりにくく、コードの変更もdiffで必ず人間の目を通ります。逆に言えば、この仕組みがあるからこそ「経過はAIに任せて、成果物だけチェックする」働き方ができています。実際、AIに任せて事故った経験はほぼありません。

まずは小さく:NotebookLMに資料を渡すところから

3事例に共通するのは、大掛かりなシステム導入ではなく、すでにあるスプレッドシートや資料をそのままAIに渡しているだけ、という点です。

AI導入前の私の悩みは、とにかく人力の工数がかかりすぎることでした。できなくはない。ただ、600ページの目視チェックのような作業は、自分がやるのもしんどいし、部下にやらせるのも同じくらいキツい。仕事上やむを得ないとはいえ、成長性の低い単純作業を人に振るのは忍びない——マネジメント側ならこの感覚は伝わると思います。

だからこそ、最初の一歩は小さくていいと思っています。おすすめは、NotebookLMに自社の過去資料を読み込ませてみることです。テストケースのような整った資産でなくても、議事録やマニュアルでも構いません。一度「過去の資産をAIが参照して答えてくれる」体験をすると、その便利さから次に自動化したい業務が自然と見えてきます。私自身、使えば使うほど、より多くのトークン・より上位のモデルを試したくなり、課金のコスパは圧倒的だと感じるようになりました。

スプレッドシートは、AIと人間の間の最も手軽なインターフェースです。まずは手元のシートをひとつ、AIに渡してみてください。