システム開発を進めるとき、開発会社から提示されたスケジュールを見ても「 この期間で本当に間に合うのか 」「 どこを確認すればよいのか 」と不安になる場面は少なくありません。 特に、初めて開発を発注する場合や、社内の関係部署をまとめる立場にある場合は、専門用語や工程の多さに戸惑いやすいものです。 システム開発のスケジュールは、単なる日程表ではなく、 納期・品質・予算を守るための設計図 です。 工程ごとの目的や期間の目安を理解しておくと、開発会社との打ち合わせでも確認すべきポイントが見えやすくなります。 また、WBSやガントチャートを使って作業を見える化すれば、関係者同士の認識ズレや承認遅れ、仕様変更による手戻りも防ぎやすくなります。 そこで今回は、 システム開発のスケジュールの考え方から作り方、遅延を防ぐ実践ポイントまで をわかりやすく整理しました！ 読み進めることで、無理のない開発計画を立て、社内説明や開発会社との調整に活かしやすくなります。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド システム開発のスケジュールは何のために作るのかを押さえよう！ システム開発のスケジュールは、開発開始日と納品日を並べるだけのものではありません。 要件定義、設計、開発、テスト、リリース、運用保守といった複数の工程を、どの順番で、誰が、いつまでに進めるのかを明確にするために作ります。 スケジュールが曖昧なまま進むと、現在の進捗や次に必要な判断が見えにくくなり、会議のたびに状況確認から始めることになりがちです。 特に発注側と開発側で認識がズレていると、完成イメージや優先順位が食い違い、後半で大きな手戻りが発生する可能性があります。 そのため、スケジュールは 関係者全員が同じ地図を見ながら進むための共通言語 として考えることが大切です。 また、システム開発では想定外の仕様変更や外部サービスとの調整、テストでの不具合発見などが起こることもあります。 事前にマイルストーンや確認タイミングを決めておけば、トラブルが起きたときも影響範囲を把握し、早めに立て直しやすくなります。 計画通りに進めることだけでなく、 変化に対応できる状態を作ること が、スケジュール管理の本質です。 全体像を見える化して、プロジェクトの迷子を防ぐ！ システム開発では、最初にプロジェクト全体の流れを見える化することが重要です。 要件定義で作るものを決め、設計で具体的な仕様に落とし込み、開発で形にし、テストで品質を確認し、リリースで実際に使える状態にしていきます。 この流れが見えていないと、どの工程で何を判断すべきかがわからず、開発会社に任せきりになりやすくなります。 一方で、工程ごとの役割や成果物が整理されていれば、発注側も「 今は何を確認する段階なのか 」を把握しやすくなります。 特に社内説明や稟議が必要な場合、全体像を示せるスケジュールがあると、上司や関係部署にもプロジェクトの進め方を説明しやすくなります。 スケジュールは、開発会社の管理資料であると同時に、 発注側が安心して意思決定するための資料 でもあります。 そのため、工程名だけでなく、各工程で決めること、確認すること、完了条件まで含めて整理することが大切です。 プロジェクトの迷子を防ぐには、最初に全体像を共有し、 関係者全員が同じゴールを見られる状態 を作る必要があります。 関係者の認識ズレを減らして、手戻りを防ぐ！ システム開発でよくあるトラブルの一つが、関係者同士の認識ズレです。 開発会社は仕様通りに作ったつもりでも、発注側や現場部門が想定していた使い方と違えば、「 思っていたものと違う 」という問題が起こります。 このズレを防ぐには、スケジュールの中に 確認タイミング・承認期限・成果物のレビュー を組み込むことが欠かせません。 たとえば、要件定義書や画面設計書を確認する日、現場担当者にレビューしてもらう期間、上司が承認する期限を明確にしておくと、確認漏れを防ぎやすくなります。 発注側の作業は、開発そのものではなくても、プロジェクト全体の進行に大きな影響を与えます。 資料提供が遅れたり、承認者が不在だったり、社内確認が長引いたり すると、その分だけ開発スケジュールも後ろ倒しになります。 だからこそ、発注側も「 いつまでに何を確認するのか 」をスケジュール上で明確にすることが重要です。 認識ズレを早い段階で見つけられれば 、修正の負担も小さくなり、納期や品質への影響も抑えやすくなります。 トラブルが起きても、早く立て直せる状態を作る！ システム開発では、どれだけ丁寧に計画しても、想定外の問題が起こることがあります。 仕様変更、追加要望、外部サービスとの連携不具合、テストでのバグ発見、担当者の急な不在など、遅延につながる要因はさまざまです。 大切なのは、トラブルをゼロにすることではなく、 発生したときに早く気づき、早く対処できる状態を作ること です。 そのためには、スケジュールの中にマイルストーンを設定し、 各工程の節目で進捗や成果物を確認 する必要があります。 マイルストーンがあれば、遅れがどこで発生しているのか、次の工程にどれくらい影響するのかを判断しやすくなります。 また、各工程に 一定のバッファを持たせておく ことで、小さな遅れを吸収しやすくなります。 バッファは余った時間ではなく、品質確認やリスク対応のために必要な時間です。 変化に対応できるスケジュールを作っておく ことで、トラブルが起きてもプロジェクト全体を大きく崩さずに進めやすくなります。 工程ごとの期間目安を知って、無理のない計画を立てよう！ システム開発のスケジュールを考えるうえで、まず押さえたいのが 工程ごとの期間目安 です。 一般的な開発では、 要件定義、設計、開発、テスト、リリース準備 という流れで進みます。 ただし、必要な期間はシステムの規模、機能数、画面数、外部連携の有無、関係者の人数、承認フローの複雑さによって 大きく変わります 。 小規模な業務ツールであれば数か月で進むこともありますが、基幹システムや外部サービス連携を含む開発では半年以上かかるケースもあります。 重要なのは、単純に「短くできるか」ではなく、各工程に必要な確認や修正の時間を含めて、 現実的に進められるかどうか です。 特に要件定義やテストの期間を短くしすぎると、後工程で手戻りが増えたり、リリース後の不具合につながったりする可能性があります。 スケジュールを見るときは、開発期間だけでなく、 設計やテスト、発注側の確認期間まで含まれているかを確認することが大切 です。 無理のない計画を立てるには、工程ごとの目的を理解し、どこに時間をかけるべきかを判断できる状態を目指しましょう。 要件定義では、作りたいものと優先順位を明確にする！ 要件定義は、システム開発の土台になる工程です。 ここでは、 システムを作る目的、解決したい業務課題、必要な機能、利用者、業務フロー、セキュリティや処理速度などの非機能要件 を整理します。 要件定義が曖昧なまま進むと、設計や開発の途中で「この機能も必要だった」「この業務パターンを考えていなかった」といった問題が起こりやすくなります。 その結果、追加開発や仕様変更が発生し、スケジュール全体が圧迫される可能性があります。 要件定義の期間は、システム規模や関係者数によって変わりますが、数週間から数か月程度を見込む考え方が現実的です。 発注側は、現場の要望、既存の業務資料、現在使っているシステムの課題、必要な帳票やデータ項目などを事前に整理しておくと、打ち合わせがスムーズになります。 また、すべての要望を同じ優先度で扱うのではなく、 必須機能 と できれば欲しい機能 を分けることも重要です。 優先順位が明確になれば、納期や予算に合わせて開発範囲を調整しやすくなります。 設計では、画面・機能・データの具体像を固める！ 設計は、要件定義で決めた内容を、 実際に開発できる形へ落とし込む工程 です。 主に、画面構成、操作方法、機能仕様、データベース構造、外部サービスとの連携方法、権限設定などを具体化します。 外部設計では、 利用者から見える画面や操作の流れを整理 し、内部設計では、 システム内部の処理やデータの持ち方 を決めていきます。 この工程で確認が不足すると、開発後に「ボタンの位置が使いにくい」「必要な項目が足りない」「現場の業務手順と合わない」といった問題が起こりやすくなります。 そのため、発注側は画面イメージや業務フローを確認し、実際に使う現場担当者にもレビューしてもらうことが大切です。 設計書は専門的に見えることもありますが、発注側が確認すべきポイントは、実際の業務で無理なく使えるか、必要な情報が抜けていないか、操作が複雑すぎないかです。 設計段階で合意を取っておけば、後の開発やテストが進めやすくなります。 完成後の手戻りを減らすには、 設計の段階で「使う人の視点」を入れることが重要 です。 開発・テスト・リリースでは、品質確認の時間をしっかり確保する！ 開発工程では、設計書をもとにプログラミングや環境構築を進め、システムを実際に動く形にしていきます。 機能数や技術的な難易度、外部サービスとの連携有無によって、必要な期間は大きく変わります。 ただし、スケジュールを考えるときに注意したいのは、 開発が終わればすぐにリリースできるわけではないという点 です。 開発後には、単体テスト、結合テスト、総合テスト、受け入れテストなどを通じて、 不具合や仕様とのズレを確認 します。 テスト期間が短すぎると、不具合を見つけきれないまま本番運用に入ってしまい、リリース後のトラブルにつながる可能性があります。 特に受け入れテストでは、発注側も実際の業務に近いシナリオで操作し、 現場で問題なく使えるかを確認する必要 があります。 リリース前には、データ移行、操作マニュアル、社内周知、問い合わせ対応体制、万が一の切り戻し手順も確認しておくと安心です。 品質を守るには、開発期間だけでなく、 テストとリリース準備の時間 をしっかり確保することが欠かせません。 スケジュール表はWBSとガントチャートでわかりやすく作ろう！ システム開発のスケジュール表を作るときは、いきなり日付を並べるのではなく、まず 必要な作業を分解することが大切 です。 この作業分解に役立つのが WBS です。 WBSは、 プロジェクトで必要な作業を細かく洗い出し、抜け漏れを防ぐための考え方 です。 一方、 ガントチャート は、洗い出した作業を時間軸に並べ、開始日、終了日、担当者、進捗状況を見える化するために使います。 つまり、WBSで「 何をするか 」を整理し、ガントチャートで「 いつ進めるか 」を確認できる形にする流れが基本です。 発注側にとっても、WBSやガントチャートがあると、開発会社の作業だけでなく、自社側の確認や承認のタイミングも把握しやすくなります。 特に、資料提供、レビュー、社内調整、上司の承認などは、発注側のタスクとしてスケジュールに入れておく必要があります。 スケジュール表は作って終わりではなく、進捗を確認しながら更新し、関係者で共有し続けることが重要です。 まずは必要な作業を洗い出して、抜け漏れを防ぐ！ スケジュール作成の第一歩は、プロジェクトに必要な作業を できるだけ具体的に洗い出すこと です。 最初は、 要件定義、設計、開発、テスト、リリース準備 といった大きな工程に分けます。 次に、それぞれの工程をさらに細かいタスクに分解し、どの作業が完了すれば次に進めるのかを明確にします。 たとえば要件定義であれば、 課題整理、機能一覧作成、業務フロー確認、非機能要件の確認、関係者レビュー などに分けられます。 タスクごとに 成果物、担当者、確認者、期限 を設定しておくと、進捗管理がしやすくなります。 ここで忘れやすいのが、発注側の作業です。 資料提供、現場ヒアリング、設計レビュー、受け入れテスト、承認手続き、社内周知 なども、プロジェクトを進めるうえで欠かせないタスクです。 作業の洗い出しを開発会社任せにせず、双方で確認することで、後から「 誰が対応する予定だったのか 」と迷う場面を減らせます。 作業の順番と依存関係を決めて、現実的な流れにする！ タスクを洗い出したら、次に 作業の順番と依存関係を整理 します。 システム開発では、ある作業が終わらないと次の作業に進めない場面が多くあります。 たとえば、要件定義が固まっていない状態で設計や開発を進めると、 後から仕様変更が発生し、修正工数が増える可能性 があります。 また外部サービスとの連携がある場合、 API仕様の確認や審査、テスト環境の準備などが遅れる と、開発全体に影響することがあります。 このように、遅れると 全体納期に影響しやすい作業を把握しておくことが大切 です。 特に、社内承認や関係部署の確認など、開発会社だけでは進められない作業もスケジュールに含める必要があります。 休日、繁忙期、担当者の不在、経営会議の日程、外部企業の回答待ち なども、現実的なスケジュールを作るうえで見落とせない要素です。 作業をただ並べるのではなく、どの順番で進めれば無理がないかを考えることで、実行しやすい計画になります。 WBSとガントチャートを使い分けて、進捗を見える化する！ WBSとガントチャートは、どちらもスケジュール管理に役立つ手法ですが、役割が異なります。 WBSは、プロジェクトに必要な作業を分解し、タスクの抜け漏れを防ぐため に使います。 一方で、ガントチャートは、 各タスクの開始日、終了日、担当者、進捗状況を時間軸で確認するため に使います。 WBSで作業を整理してからガントチャートに落とし込む と、何をいつまでに進めるべきかがわかりやすくなります。 小規模なプロジェクトであれば、Excelやスプレッドシートでも十分に管理できます。 一方、関係者が多い場合や、複数部署、開発会社、外部パートナーが関わる場合は、 プロジェクト管理ツールを使うと共有や更新がしやすくなります 。 重要なのは、ツールの種類よりも、関係者が同じ情報を見て、進捗や遅れをすぐに確認できる状態を作ることです。 進捗が見える化されていれば、遅れが小さいうちに対策を打ちやすくなります。 遅れないスケジュールにするための実践ポイントを押さえよう！ システム開発のスケジュールを遅らせないためには、最初から 「予定通りに進まない可能性」を織り込んでおくことが大切 です。 開発中には、仕様変更、追加要望、確認待ち、テストでの不具合、外部サービスの都合など、さまざまな遅延要因が発生します。 そのため、余裕のないスケジュールを組むと、小さな遅れが後半に積み重なり、納期や品質に大きな影響を与えやすくなります。 遅れにくい計画にするには、 各工程にバッファを入れ、重要な節目にマイルストーンを設定すること が効果的です。 また、 仕様変更や承認に関するルールを事前に決めておく ことで、判断の遅れや認識ズレを減らせます。 発注側としては、開発会社から提示されたスケジュールをそのまま受け取るのではなく、工程や確認期間、テスト期間が十分に含まれているかを確認することが重要です。 スケジュールの妥当性を判断できれば、社内説明もしやすくなり、プロジェクト全体を安心して進めやすくなります。 遅延を防ぐポイントは、細かな管理よりも、 早く気づき、早く相談し、早く判断できる仕組みを作ること です。 バッファとマイルストーンを入れて、遅延に強い計画にする！ システム開発では、最初の見積もり通りにすべてが進むとは限りません。 そのため、各工程の終わりには確認期間や修正期間を入れ、余裕のない日程にしないことが大切です。 この余裕が バッファ です。 バッファは単なる予備日ではなく、 品質確認や想定外の調整に対応するための重要な時間 です。 特に、 要件定義後の確認、設計承認、テスト後の修正、リリース前の最終確認 には、一定の余裕を持たせる必要があります。 また、プロジェクトの節目には マイルストーン を設定します。 要件定義完了、設計承認、開発完了、テスト開始、リリース判定などの節目を決めておくと、進捗が順調かどうかを判断しやすくなります。 マイルストーンごとに完了条件を明確にしておけば 、曖昧なまま次工程に進むことを防ぎやすくなります。 遅延に強いスケジュールとは、単に長めに期間を取ることではなく、 確認と判断のタイミングが明確な計画 です。 仕様変更と承認遅れを減らすルールを作る！ システム開発で遅延が起こりやすい原因の一つが、仕様変更です。 開発が進んでから追加要望が出ると、設計や実装、テストのやり直しが必要になり、納期や費用に影響する可能性があります。 仕様変更を完全になくすことは難しいため、事前に 変更の受付ルール を決めておくことが重要です。 たとえば、追加要望が出た場合は、 納期、費用、品質、他機能への影響 を確認したうえで、対応するかどうかを判断する流れにします。 また、 承認遅れもスケジュールに大きく影響します 。 承認者、確認期限、判断基準が曖昧なままだと、設計書やテスト結果の確認が止まり、開発会社側の作業も進めにくくなります。 そのため、 誰が最終判断をするのか、何日以内に返答するのか、判断に必要な資料は何かを事前に決めておくことが大切 です。 議事録や決定事項を残しておけば、後から認識のズレが起こりにくくなります。 初回リリースに必要な機能と、後から追加できる機能を分けることも、納期を守るうえで有効です。 開発会社に確認すべきポイントを押さえて、妥当性を判断する！ 開発会社からスケジュールを提示されたら、まず工程が一通り含まれているかを確認します。 要件定義、設計、開発、テスト、リリース準備 が入っているかは、最初に見るべきポイントです。 次に、 発注側の確認や承認、資料提供の期間 がスケジュールに含まれているかを確認します。 開発会社の作業だけで日程が組まれている場合、実際には社内確認の時間が足りず、後から遅れが発生する可能性があります。 また、テスト期間や修正期間が短すぎないかも重要です。 テスト工程が極端に短い場合、品質確認が不十分になり、リリース後のトラブルにつながるリスクがあります。 さらに、遅延が起きた場合の報告方法、進捗共有の頻度、判断が必要なときの連絡フローも確認しておくと安心です。 複数社の見積もりや工程表を比較するときは、金額だけでなく、 工程の粒度、リスク説明の丁寧さ、発注側の作業まで考慮されているか を見ることが大切です。 スケジュールの妥当性を判断できれば、開発会社と対等に話しながら、現実的な計画に調整しやすくなります。 まとめ システム開発のスケジュールは、単なる工程表ではなく、納期・品質・予算を守るための共通認識づくりです。 要件定義、設計、開発、テスト、リリース準備という流れを理解しておくことで、各工程で何を確認すべきかが見えやすくなります。 特に、要件定義やテストの期間を短くしすぎると、後から手戻りや不具合につながる可能性があるため、無理のない計画を立てることが大切です。 スケジュール表を作る際は、WBSで必要な作業を洗い出し、ガントチャートで日程や進捗を見える化すると管理しやすくなります。 また、発注側の資料提供、レビュー、承認、社内調整もスケジュールに含めることで、実態に合った計画になりやすくなります。 遅延を防ぐには、バッファ、マイルストーン、仕様変更ルール、承認ルールを事前に決めておくことが重要です。 開発会社から提示されたスケジュールを見るときは、工程の抜け漏れ、確認期間、テスト期間、遅延時の対応方法を一つずつ確認しましょう。 システム開発のスケジュールを正しく理解できれば、社内説明や開発会社との調整に自信を持ちやすくなり、プロジェクトをより安心して進められます。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

LINEヤフーの技術カンファレンス「Tech-Verse 2026」の公式記事です。AIでのコーディングで難しいのは、もはやコードを出すこと自体ではありません。課題はその周辺にあります。意図を正確な仕...

G-gen の福井です。Google Workspace Studio のループ機能を使用して、Google Meet の文字起こしから議事録を作成し、会議で決まったタスクを Google Tasks へ自動登録するフローを作成する手順を紹介します。 はじめに 当記事の概要 Google Workspace Studio とは ループ機能（Repeat for each）とは 作成するフロー 処理の全体像 注意事項 フローの作成手順 開始条件 : フォルダへのアイテム追加 議事録の作成 議事録ファイル名の生成 Google ドキュメントへの保存 タスク一覧の抽出 ループによるタスク登録 動作確認 はじめに 当記事の概要 当記事では、Google Workspace の自動化ツールである Google Workspace Studio を使用して、議事録の作成からタスク登録までを自動化するフローを作成します。具体的には、Google Meet の文字起こしデータをもとに議事録を作成して Google ドキュメントとして保存し、続けてその議事録から会議で決まったタスクを抽出して、1件ずつ Google Tasks に登録します。 これまでの Google Workspace Studio では、文字起こしデータから議事録を作成することはできても、会議で挙がったタスクを1件ずつ Google Tasks へ登録するような繰り返し処理はできませんでした。2026年6月にループ機能が追加されたことで、この繰り返し処理ができるようになりました。当記事では、このループ機能を中心にフローの作成手順を解説します。 Google Workspace Studio とは Google Workspace Studio は、Google Workspace のアプリケーションを連携させて定型業務を自動化できる、Gemini を搭載したノーコードの自動化ツールです。あらかじめ用意された開始条件（トリガー）とステップ（アクション）を組み合わせて「フロー」を作成することで、プログラミングなしに業務を自動化できます。 たとえば「特定のフォルダにファイルが追加されたら、その内容を Gemini で要約して Google Chat に通知する」といった処理を、コードを書かずに実現できます。 Google Workspace Studio の概要や基本的な使い方は、以下の記事で詳しく解説しています。当記事ではフローの作成手順に絞るため、基礎的な概念は以下を参照してください。 blog.g-gen.co.jp ループ機能（Repeat for each）とは ループ機能は、リスト形式のデータに含まれる項目を1件ずつ取り出し、同じ処理（サブステップ）を繰り返し実行する機能です。2026年6月に Google Workspace Studio へ追加されました。 この機能とあわせて、Gemini に相談（Ask Gemini）ステップに「回答の形式」という設定が追加されました。回答の形式で「リスト」を選ぶと、Gemini の出力をリスト形式で受け取れます。このリストをループ機能に渡すことで、リストの各項目に対して同じステップを繰り返し実行できます。 参考 : Introducing the ability to loop over a list of items in Workspace Studio 作成するフロー 処理の全体像 今回作成するフローは、Google ドライブの特定フォルダに Google Meet の文字起こしファイルが追加されたことをきっかけに動き出します。フロー全体は、次の7つのステップで構成されます。 完成したフローの全体像 ステップ 種類 処理内容 1 開始条件 フォルダへのアイテム追加を検知する 2 Gemini に相談 文字起こしから議事録を作成する 3 Gemini に相談 議事録のファイル名を生成する 4 ドキュメントを作成 議事録を Google ドキュメントとして保存する 5 Gemini に相談 議事録からタスク一覧をリスト形式で抽出する 6 繰り返し タスクのリストを1件ずつループする 7 タスクを作成する 各タスクを Google Tasks に登録する（ステップ6のサブステップ） ステップ5でタスクをリスト形式で抽出し、ステップ6のループでそのリストを1件ずつ処理する点が、当記事のポイントです。ステップ7はステップ6のサブステップとして動作し、ループのたびに Google Tasks へタスクを1件ずつ登録します。 注意事項 ループ機能で処理できるのは先頭100件まで ループ機能（繰り返し）が処理できるのは、リストの先頭100件までです（2026年6月現在）。1回の会議から抽出されるタスクが100件を超えることはまれですが、大量のタスクを扱う場合は注意してください。 Google Tasks には担当者を割り当てる項目がない Google Tasks は個人のタスク管理を目的としたツールのため、タスクに担当者を割り当てる項目はありません。そのため当フローでは、会議で決まった担当者と期限日を、タスクの詳細（メモ）欄にテキストとしてまとめて記録します。登録先は、フローを実行したユーザー本人の「マイタスク」です。 フローの作成手順 開始条件 : フォルダへのアイテム追加 開始条件（トリガー）は、フローが動き出すきっかけとなるイベントです。Google Workspace Studio では、スケジュール実行やメールの受信など複数の開始条件が用意されています。 当フローでは [フォルダにアイテムが追加されたとき] を開始条件に選びます。Google Meet で文字起こしを有効にすると、その文字起こしは Google ドライブの Meet Recordings フォルダに Google ドキュメントとして保存されます。このフォルダを監視し、文字起こしが追加されたタイミングでフローを起動します。 開始条件の選択画面で [フォルダにアイテムが追加されたとき] を選択します。 開始条件の選択 続いて、監視するフォルダを指定します。[ドライブ] をクリックし、文字起こしが保存される Meet Recordings フォルダを選択します。 監視するフォルダの選択 これで、対象のフォルダに新しいファイルが追加されるたびに、フローが実行されます。 議事録の作成 開始条件の次に、文字起こしから議事録を作成するステップを追加します。アクションの [ステップの選択] から [Gemini に相談] を選択します。 Gemini に相談ステップの追加 [Gemini に相談] は、入力したプロンプトに沿って Gemini にテキストを生成させるステップです。 ステップを追加すると、プロンプトの入力欄が表示されます。ここに、Gemini へ議事録作成を指示するプロンプトを入力します。 プロンプトの入力 入力したプロンプトの全文は次のとおりです。画面では省略していますが、議事録の体裁を出力フォーマットとして細かく指定したうえで、後続のタスク登録を見据えてアクションアイテムを「1タスク1依頼事項」に分割するよう指示しています。 # 命令書 あなたは、議事録作成のプロフェッショナルです。与えられた「会議の文字起こしデータ（テキスト）」から、会議の目的、議論の詳細なプロセス、結果が正確に理解できる、構造化された議事録を作成してください。 # 制約条件 * 【文章の整形】文字起こしデータ特有の誤字、脱字、フィラー（「えーと」「あのー」など）は、文脈を正確に読み取り、削除・修正（ケバ取り）し、自然で分かりやすい文章にしてください。全体のトーンはビジネス文書として客観的かつ中立的に記述してください。 * 【敬称ルール】発言者の名前は「さん」付けで統一してください。 * 【情報の網羅性】アイスブレイク等は省略して構いませんが、本題に関する議論の過程（どのような意見や懸念が出て、なぜその結論に至ったのか）は決して省略せず、すべての内容を集約させてください。過度な要約による情報欠落を固く禁じます。 * 【ファクトチェック】音声認識エラーと思われる不自然な単語や人名は、前後の文脈を元に論理的に推測し、正しい表記に補正してください。数字、日付、システム要件などの事実は特に正確に記載してください。資料の内容と実際の発言に差異がある場合は、発言内容（最終的な合意）を正とし、その変更に至ったニュアンスを含めて記載してください。 * 【決定事項の記述】決定事項は、単なる結果だけでなく、資料との差異や最終的な合意内容のニュアンスを含めて具体的に記述してください。すべての決定事項においてこのルールを適用します。 * 【アクションアイテムの記述】「誰が」「いつまでに」「何をするか」を明確にしてください。1つのタスクに複数の依頼事項（例：権限付与とインスタンス起動など）を含めず、必ず「1タスク1依頼事項」に分割すること。また要素を漏らさず全て記載してください。すべてのタスクにおいてこのルールを適用します。 * 【不明瞭な箇所】文脈や資料から合理的な推測が不可能な箇所は無理に補完せず `[要確認：発言内容不明瞭]` と記述してください。 # 思考プロセス（ステップ4実行時に内部で行う処理） 1. **全体把握と完全な理解** 入力された「文字起こしデータ」の全体を注意深く読み込みます。会議の主要な目的、全体的な議論の流れ、各参加者の立場や発言の意図、そして最終的な結論（全体像）を完全に理解・把握します。 2. **情報の抽出と詳細へのブレークダウン** 理解した全体構成から、指定フォーマットの各項目へとブレークダウンし、情報を漏れなく抽出します。「決定事項（合意に至ったニュアンスや資料からの変更点）」、「アクションアイテム（付随する細かな依頼内容、担当、期限の全要素）」、およびアジェンダごとの「議論のプロセス（なぜその結論に至ったかの過程）」を、過度な要約をせずに拾い上げます。 3. **構造化と清書** 抽出した情報を指定のMarkdownフォーマットに当てはめ、制約条件（敬称のルール適用、ケバ取り、中立的なトーンへの調整など）を厳格に適用して議事録として清書します。 # 出力フォーマット 以下のMarkdown形式のテンプレートに厳密に従って、議事録を作成してください。 --- ## 議事録 **会議名:** （会議の名称を記述） **日時:** YYYY年MM月DD日 HH:MM - HH:MM **場所:** （会議の場所を記述。オンライン等） **出席者:** （出席者リストを「さん」付けで記述） --- ### 1. 決定事項 * （決定事項の内容） * （決定事項の内容） --- ### 2. アクションアイテム * **TODO:** （タスク内容 ※必ず1タスク1依頼事項） * **担当:** （担当者名） * **期限:** YYYY年MM月DD日 * **TODO:** （タスク内容 ※必ず1タスク1依頼事項） * **担当:** （担当者名） * **期限:** YYYY年MM月DD日 --- ### 3. 議題とディスカッション #### 3.1. （議題1のタイトル） * **（発言者名）:** * （発言内容） * **（発言者名）:** * （発言内容） #### 3.2. （議題2のタイトル） * **（発言者名）:** * （発言内容） === 以下「会議の文字起こしデータ」=== プロンプト末尾の === 以下「会議の文字起こしデータ」=== の下に、文字起こしデータを渡します。[+ 変数] をクリックし、開始条件（ステップ1）の アイテムへのリンク を挿入します。 変数の挿入 挿入した変数には、フォルダに追加された文字起こしファイルへのリンクが入ります。Gemini はこのリンク先のファイルを読み取り、議事録を作成します。 次に、プロンプトの下にある [Gemini が使用できるソース] を設定します。[ウェブ検索] をオフにし、[Workspace] のみをオンにします。 ソースの設定 議事録は文字起こしの内容だけにもとづいて作成すべきであり、ウェブ検索の結果が混ざると事実と異なる内容が含まれるおそれがあるため、ウェブ検索はオフにします。 最後に、画面下部の [回答の形式] で [テキスト] を選択します。議事録は1つの文章として出力するためです。 議事録ファイル名の生成 続いて、作成する議事録に付けるファイル名を生成するステップを追加します。ステップ2と同様に [ステップの選択] から [Gemini に相談] を選択します。 Gemini に相談ステップの追加 1つの [Gemini に相談] ステップで生成できる回答は1つのため、議事録の本文とファイル名を1つのステップで同時に作ることはできません。そのため、議事録本文とは別に、ファイル名を生成する専用のステップを用意します。 プロンプトには、ファイル名を生成する指示を入力します。このとき、あとで変数を埋め込む箇所は 「」 を空けたままにしておきます。あわせて、ファイル名の生成にウェブ検索は不要なため、[ウェブ検索] をオフにします。 ファイル名を生成するプロンプト 入力したプロンプトは次のとおりです。 # 命令書 会議の文字起こしデータを格納したファイルのファイル名「」から「会議実施日付」と「会議名」を抽出し、議事録のファイル名を生成してください。 # 出力フォーマット [会議実施日付（例：20260601）]_[会議名]_議事録 次に、空けておいた 「」 の中に変数を挿入します。[+ 変数] をクリックし、開始条件（ステップ1）の アイテムの表示名 を選択します。 変数（アイテムの表示名）の選択 「」 の中に アイテムの表示名 が挿入されました。 変数が挿入されたプロンプト アイテムの表示名 には、フォルダに追加された文字起こしファイルの名前が入ります。Google Meet の文字起こしファイルの名前には会議名や日時が含まれるため、そこからファイル名を組み立てられます。 Google ドキュメントへの保存 作成した議事録を Google ドキュメントとして保存するステップを追加します。[ステップの選択] から [ドキュメントを作成] を選択します。 ドキュメントを作成ステップの追加 このステップでは、作成するドキュメントの名前と本文を、それぞれ前のステップの出力から指定します。ステップ2とステップ3はどちらも [Gemini に相談] のため、変数の名前はいずれも Gemini で作成されたコンテンツ と表示されます。ステップ番号で見分けて選択してください。 [新しいドキュメントの名前] には、[+ 変数] からステップ3の Gemini で作成されたコンテンツ （ステップ3で生成したファイル名）を選択します。[追加するコンテンツ] には、ステップ2の Gemini で作成されたコンテンツ （ステップ2で作成した議事録の本文）を選択します。 ドキュメントの名前と本文の指定 最後に、保存先を指定します。[ドライブ] をクリックし、保存先のフォルダを選択します。 保存先フォルダの指定 これで、生成した議事録が、指定したファイル名の Google ドキュメントとして保存されます。 タスク一覧の抽出 ここからが、ループ機能を活かす中心部分です。議事録から会議で決まったタスクを抽出し、後続のループで1件ずつ登録できるよう、リスト形式で出力させます。 ステップ4の次に、再び [Gemini に相談] を追加します。プロンプトには、[+ 変数] からステップ2の Gemini で作成されたコンテンツ （議事録の本文）だけを指定します。 タスクを抽出するプロンプト タスクを抽出する具体的な指示は、このあと設定するフィールドの「Gemini の説明」に記述します。そのため、プロンプト本文には議事録の変数のみを置き、指示は書きません。 次に、[回答の形式] で [リスト] を選択します。続けて [リスト形式] で カスタム構造化データ を選び、タスク1件が持つフィールドとして タスク名 ・ 期限日 ・ 担当者 を定義します。各フィールドの「Gemini の説明」に、議事録のアクションアイテムから対応する情報を抽出する指示を記述します。 リスト形式とフィールドの定義 [リスト] を選ぶことで、Gemini の出力をリスト形式で受け取れ、後続のループ（繰り返し）で1件ずつ処理できます。各フィールドの「Gemini の説明」に設定した内容は次のとおりです。 フィールド名 Gemini の説明 タスク名 会議議事録の「アクションアイテム」に定義された内容から「タスク名」を原文のまま抽出すること 期限日 会議議事録の「アクションアイテム」に定義された内容から「期限日」を「2026年06月01日（月）」の形式で抽出。日付形式で期限日が指定されていない場合はブランクとすること 担当者 会議議事録の「アクションアイテム」に定義された内容から「担当者」を原文のまま抽出。担当者が指定されていない場合はブランクとすること ループによるタスク登録 最後に、抽出したタスクのリストをループで1件ずつ Google Tasks に登録します。 ステップ5の次に、ループ処理を行う [それぞれについて繰り返す] を追加します。 繰り返しステップの追加 これがループ機能（繰り返し）です。指定したリストの各アイテムに対して、この中に置いたサブステップを順番に実行します。処理されるのはリストの先頭100件までです。 続いて、ループの対象とするリストを指定します。[+ 変数] からステップ5の 詳細リスト - Gemini が作成したリスト を選択します。 ループ対象リストの選択 これで、ステップ5で抽出したタスクのリストを1件ずつ処理できます。リストの各アイテムは、 タスク名 ・ 期限日 ・ 担当者 の3つのフィールドを持ちます。 次に、ループの中で実行する処理を追加します。[サブステップを追加] から、Google Tasks にタスクを登録する [タスクを作成する] を選択します。 タスクを作成するサブステップの追加 このサブステップは、ループのたびに（タスク1件ごとに）実行されます。 [タスクを作成する] では、タスクのタイトルと詳細を、ループの各アイテムの値から指定します。[タスクのタイトル] には、[+ 変数] からステップ6の タスク名 を指定します。[タスクの詳細] には、 期限日： と入力してその後ろにステップ6の 期限日 を、改行して 担当者： と入力してその後ろにステップ6の 担当者 を挿入します。 タスクのタイトルと詳細の設定 以上で、文字起こしの追加から議事録の作成、タスクの登録までを自動化するフローが完成です。 動作確認 フローが完成したら、画面左上のフロー名を分かりやすい名前（ここでは「議事録作成・タスク登録」）に変更し、[オンにする] でフローを有効化します。 フローの有効化 フローをオンにすると、 Meet Recordings フォルダに文字起こしが追加されるたびに、自動で実行されます。実行結果は、画面右上のアクティビティ（グラフのアイコン）から確認できます。今回はフローが正常に完了しています。 アクティビティでの実行結果の確認 文字起こしが追加されると、まず議事録が Google ドキュメントとして作成されます。プロンプトで指定した出力フォーマットのとおり、決定事項やアクションアイテムが整理されています。 作成された議事録 続いて、議事録から抽出されたタスクが、1件ずつ Google Tasks に登録されます。各タスクのタイトルにはタスク名が、詳細欄には期限日と担当者が記録されています。 Google Tasks に登録されたタスク 福井 達也 (記事一覧) クラウドソリューション部 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進 Google Cloud Partner Top Engineer 2026 選出。