あけましておめでとうございます！本年もよろしくお願いします！

正月に書く2026年1発目の記事は「Gemini」×「NotebookLM」で出来るDX（業務フロー改善）！つまりAIでの業務フロー改善についてです。

AIの登場で生産性向上が叫ばれる中、業務フロー改善はより重要になってきていると思います。

なぜGeminiとNotebookLMでやるのが良いと思ったかでいうと、それぞれの得意領域である
1.NotebookLMで情報の要約、抽出を正確かつ高速に行う。
2.Geminiでその情報から、新たな創作をおこなう。
を組み合わせることで、点在するさまざまな業務フロー改善の「タネ」から自動で最適な業務フロー改善の提案をAIにさせることができるのでは？と思ったためです。

それでは、架空のWebサイト制作の業務フローをベースに、やり方を詳しく解説していきます！

1.NotebookLMに業務フローに関する情報を貯める

まずはNotebookLMに情報を貯めていきます。

具体的には、管理・分析がしやすいように情報の種類ごとにノートブックを作っていきます。

今回、そもそもの「業務フロー」と、業務フロー改善の情報となる「トラブル履歴」「コミュニケーションログ」の3つのノートブックを作成していきました。

最初にNotebookLMを開き、「ノートブックを新規作成」します。

ノートブックを新規作成すると、情報源となるファイルのアップロードポップアップが開きます。
ここで情報のカテゴリーごとにファイルをアップしていきます。

まずは「業務フロー」に関しての情報をいれていきました。
※最近「GoogleDrive」もそのままURLでアップロードできるようになったので、Google環境で仕事をしている方はとても便利です！

今回は業務フロー全体が記載されたスプレッドシートと、その各工程の詳細が描かれた業務フロー詳細をアップしました。

これで「業務フロー」のノートブックは完成です！
※今回はダミーで2ファイルのみですが、実際は情報があればあるほど良いです。

同じ要領で「トラブル履歴」には「トラブル履歴」のスプレッドシートと、トラブルをクライアントに報告する際の「経緯報告書」をアップ

「コミュニケーションログ」には、トラブルに関係しそうなSlackのやりとりのログをいくつかいれました。

特に今回のポイントは「コミュニケーションのログをそのままいれる」ことです。
こうすることで、履歴や経緯報告書だけではなく、実際のメンバー同士のやり取りから「本質的な問題点はどこか？」も踏まえ、業務改善に取り組むことができます。
まさにNotebookLMを使う利点です！

これでノートブックの準備は完了です。

2.GeminiでNotebookLMを読み込み分析＆業務フロー設計

次に、1で作成した3つのノートブックをGeminiで読み込み分析と業務フローの設計をしていきます。

まずはGeminiを開き、左にある＋ボタンでNotebookLMを選びます。

「業務フロー」「トラブル履歴」「コミュニケーションログ」の3つのノートブックをアップし、その上で以下のプロンプトで分析と業務フロー設計の指示を出しました。

これで実行すると、以下のような業務フロー改善案を出してくれました！

業務改善のプロフェッショナルとして、ご提示いただいたトラブル履歴およびコミュニケーションログの分析に基づき、現在の業務フローに潜むリスクを特定し、それを解消するための新業務フローを提案いたします。

1. 現状の業務フローにおける問題分析

分析の結果、主な問題は**「エンジニアの関与タイミングの遅れ」、「決裁権者の不在」、「抽象的な合意形成」**の3点に集約されます。

トラブルID主な問題点分析内容T-101 / T-103技術的実現可否の確認不足

ヒアリング段階でPM・ディレクターが技術仕様（API連携等）を独断で判断し、エンジニアの工数確認が形骸化していました 。

T-102 / T-104決裁権者との合意プロセスの欠落

現場担当者との合意のみで進行し、最終決裁権者（社長等）の意向が反映されないまま手戻りが発生しています 。

T-104 / T-105非言語情報のすり合わせ不足

「信頼感」「今風」といった抽象的な言葉の解釈が、ムードボード等の視覚的資料なしに進められ、感性のズレを招きました 。

T-105デザインと実装の分断

コーディング工数を考慮しないデザインが先行し、実装段階で予算・工数が大幅に超過しています 。

2. 改善後の新業務フロー

トラブルを未然に防ぎ、工数と品質を最適化するためのフローへと刷新します。特に赤字部分が重要な追加・変更箇所です。

ステップ業務内容主な担当者成果物【重要】改善ポイント（トラブル回避策）
1案件ヒアリングPM / エンジニアヒアリングシート

エンジニアを同席させ、システム連携等の技術要件をその場で深掘りする 。

2市場・競合調査ディレクター調査報告書ターゲットの期待値を明確化する。3サイトマップ作成ディレクターサイトマップ

構成案の段階でエンジニアがCMS制限等を厳密にチェックする 。

4ワイヤーフレーム(WF)デザイナー / DWF

決裁権者の承認を必須とする。現場担当者を通じた「代理承認」は禁止する 。

5要件定義書承認PM / エンジニア要件定義書

エンジニアによる「予算・工数内での実現可否」の記名サインを必須化する 。

6デザインコンセプト立案デザイナームードボード

抽象的な言葉を避け、画像・配色等による視覚的な合意をクライアントと形成する 。

7プロトタイプ制作デザイナーラフデザイン

全ページ制作前に、メインビジュアルのラフ（2〜3案）を提示し方向性をFixさせる 。

8トップページデザインデザイナーデザインカンプ

デザイン確定前にエンジニアが実装工数を確認し、過剰な演出を抑制する 。

9下層ページ展開デザイナーデザインデータ

一貫性の担保 。

10デザインレビュー全員修正指示書

当初の目的（要件定義）との乖離がないか再確認する 。

11実装指示・引継ぎPM / エンジニア仕様書

指示詳細の「実装担当による不備チェック」を厳格化する 。

3. 業務効率を最大化するための運用ルール

フローの再構築に加え、以下の運用ルールを徹底することで再発を防止します。

• 「決裁権者チェック」の義務化:

  • WF承認（工程04）およびデザインコンセプト（工程06）の際、決裁権者の直接の合意が得られない限り、次工程に進まないことを契約条件に含める 。

• 「エンジニア・ゲート」の設置:

  • 営業・企画サイドだけで「できるはず」と判断せず、技術的な懸念がある場合は必ずエンジニアの工数見積もりを経由させる仕組み（ゲート）を設ける。

• 「言語の視覚化」プロセスの徹底:

  • 「今風」「信頼感」といった主観的な形容詞は使用禁止とし、必ず参考サイトやムードボードを提示して、認識の解像度を高める 。

この新フローを導入することで、T-104で発生した20時間の修正工数や、T-101の25時間の再設計工数といった「無駄な稼働」を大幅に削減することが可能です 。

そして、疑問点や「違和感」があれば、ノートブックを再度参照させ妥協なき改善をさせます。
今回は「ホントにエンジニアをヒアリングに同席させることで解決する？」が違和感を感じ以下の指示をしました。

すると、再度ノートブックをGeminiが参照した上で、以下のような改善提案を出してくれました。

ご指摘の通り、単に「エンジニアを会議に同席させる」だけでは、かえって議論が停滞したり、エンジニアの工数を圧迫したりするリスクがあります。

コミュニケーションログ（Slack）を再分析すると、エンジニア（伊藤さん）は**「04.ワイヤーフレームの段階で呼んでくれれば止めた」と発言しており 、「技術的なフィードバックをすべきタイミング」**を明確に求めていることが分かります。一方で、ディレクター（田中さん）はクライアントにいい顔をしたい「楽観主義」の傾向があり 、PM（鈴木さん）はリスクを察知しつつも田中さんに押し切られる傾向があります 。

これらを踏まえ、エンジニアの性格（論理的・リスク回避的）と立ち位置を活かし、**「無理な同席」ではなく「強制的な技術審査（チェックゲート）」**を組み込んだ、Wordにそのまま貼れる形式の改善案を作成しました。
・・・以下、改善案の詳細・・・

点在している情報から、違和感に該当する部分を適切に分析し、改善案を出してくれています。

これで業務フローの改善は完了です！

3.最後に

いかがでしたでしょうか？今回は情報を構造化し、要約・分析が得意なNotebookLMの特性と、そこから創造するのが得意なGeminiの特性を掛け合わせた業務フロー改善方法を紹介しました。

以前は自身でRAGを構築したり、ファインチューニングしたりと手間がかかっていたことも、最近ではツール間連携でいろいろ実現できるようになってきました。

まずは、それぞれのツール特性を理解し、やりたい事、課題に合わせて組み合わせを考える。
その上でどうしても難しいものに関しては開発を考える。

という手順でやるのがいいのでは？と思っています。

改めて本年もよろしくお願いいたします！それではまた次回！