確認待ちで止まる完成条件を決める
完成条件は、原文一件につき確認待ちの要約候補一件が保存されることです。公開済みという状態や公開先のモジュールは追加しません。例の原文は「会議は11月5日15時。候補予算は8万円。承認は未完了」です。要約が予算を承認済みと書き換えていないかを、人が確認します。
入力とレビュー先の列を分ける
入力シートにはsource_id、source_version、source_textを用意します。レビューシートにはsource_id、source_version、candidate_summary、review_status、reviewed_summary、reviewed_byを作ります。原文の版が変わったら別の確認対象にできるよう、IDと版の組をキーにします。AIが作った文と人が直した文を別列に保ってください。
原文の持ち出し範囲と長さを確認する
送信する文章から、要約に不要な個人情報や秘密を取り除きます。閲覧権限のない文書を外部処理へ回さないことも確認してください。空欄は要約せず、長さ上限を超えた文章は確認待ちへ分けます。途中まで切った文章を完全な原文の要約と表示すると、末尾の留保や訂正が欠けるため注意が必要です。
Summarize textへ原文を割り当てる
Make AI ToolkitのSummarize textで、Text to summarizeに承認したsource_textを割り当てます。接続方法とモデルを選び、出力をRun onceで確認してからレビュー先へ割り当てます。入力中のURLや命令文を実行するモジュールはつなぎません。要約対象に含まれる指示は資料の内容として扱い、公開や送信の命令にしない設計です。
候補をneeds_reviewとして保存する
Google SheetsのAdd a Rowで要約候補と原文ID・版を保存し、review_statusは固定値needs_reviewにします。モデルが「確認済み」と書いても、承認状態へ流用しません。確認者が開ける原文リンクも残します。Value input optionはRawを選び、文頭が「=」などでも数式として解釈せず文字列で保存します。
人が数字・固有名詞・留保を照合する
確認者は候補と原文を並べ、日付、金額、担当、決定と未決定、否定表現を確認します。例では「11月5日15時」「候補8万円」「承認未完了」が重要です。AIの要約にない事実を補う場合も、根拠を原文で確認します。reviewed_summaryへ修正版を保存し、確認者と日時を記録して初めてapprovedへ変えます。
長文は分割しただけで完了にしない
長文をChunk textなどで分割する構成では、各部分の要約だけで全体の結論を作ったと扱わないでください。前後の文脈、重複、部分ごとの矛盾を確認する工程が必要です。最初は短い資料に限定し、入力上限と対象外の資料を明示する方が、レビューの完了条件を保ちやすくなります。
原文の変更と再処理を試す
同じID・版の再処理、版を上げた修正、空欄、数値を含む文、否定や未決定を含む文を試します。候補数とレビュー状態が想定通りかを確認し、既に承認した修正文を再生成で上書きしないようにします。MakeとAI提供元の費用を確認し、生成失敗時は原文IDを残して担当者へ戻す運用にしてください。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Make AI Toolkit summarization and chunking情報確認日: 2026-10-29
- Google Sheets row and input options情報確認日: 2026-10-29
- Make credits情報確認日: 2026-10-26
- Filtering情報確認日: 2026-10-29
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make scenario settings情報確認日: 2026-10-26