AI活用概論

要約・リライト・企画構築を分けて設計する

この節で学ぶこと

この節では、Google Opalで文章系のAIミニアプリを作るときに、「要約」「リライト」「企画構築」をひとつの指示でまとめて実行せず、工程ごとに分けて設計する方法を学びます。

Google Opalは、自然言語で作りたい内容を入力すると、編集可能なワークフローとAIミニアプリを作れるツールです。Google公式でも、自然言語でワークフローを作り、ホスティングなしで共有・公開できると説明されています。

この節だけを読んでも進められるように、最初に言葉の定義から確認します。

言葉意味
要約長い文章から大事な部分だけを短くまとめること
リライト文章の意味を大きく変えずに、読みやすさ・文体・表現を整えること
企画構築誰に、何を、どのように伝えるかを考え、記事・投稿・提案などの形に組み立てること
工程作業を進めるための段階。例:要約する、表現を整える、企画案にする
ワークフロー工程を順番に並べた流れのこと
AIミニアプリひとつの目的に特化した小さなAIアプリ
出力形式AIが返す結果の形。例:表、箇条書き、Markdown、提案書構成など

今回のポイントは、とてもシンプルです。

AIに一度で全部やらせない。
作業を分ける。
順番を決める。
最後に確認する。

これだけで、AIの出力はかなり安定します。

今回作成するもの。リンク先で試せます。

https://opal.google/app/1KSAVYgqD1Gyk_KRQQnv4eYnsO10ikh83

なぜ分ける必要があるのか

初心者がよく使う指示に、次のようなものがあります。

この議事録を要約して、読みやすく直して、提案書の企画案も作ってください。

一見、便利そうです。

しかし、この指示には3つの作業が混ざっています。

混ざっている作業本来やること
要約議事録の重要点を短く整理する
リライト読みやすい表現に直す
企画構築提案書や記事に使える形へ組み立てる

この3つを同時にやらせると、AIはどこを重視すればよいか迷いやすくなります。

その結果、次のような問題が起きます。

起きやすい問題原因
要約が浅くなる企画案作成まで同時に求めているため
重要情報が抜ける最初に整理する工程が弱いため
文章がそれっぽいだけになる根拠や材料の確認が足りないため
提案内容が飛躍する議事録にない内容を補ってしまうため
顧客向け文章と社内向けメモが混ざる出力先が整理されていないため

つまり、AIに頼む内容が多すぎると、逆に精度が落ちます。

基本の考え方

要約・リライト・企画構築は、次の順番で分けます。

flowchart TB
    A[元資料を入力する] --> B[要約する]
    B --> C[論点を整理する]
    C --> D[用途に合わせてリライトする]
    D --> E[企画案を作る]
    E --> F[確認事項を出す]
    F --> G[人間が最終確認する]

それぞれの役割は、次の通りです。

工程目的出力例
要約何が書かれているかを把握する重要ポイント、決定事項、未決定事項
論点整理何を考えるべきかを整理する課題、原因、確認事項
リライト読む人に合わせて整える社内向けメモ、顧客向け文章
企画構築次の成果物に変換する記事案、提案書構成、SNS案
確認間違い・飛躍・未確認を見つける要確認リスト

この順番にすると、AIの作業が見えやすくなります。

今回作るミニアプリ

今回作るのは、次のAIミニアプリです。

要約・リライト・企画構築アシスタント

このミニアプリでは、議事録やメモを入力すると、以下を順番に出力します。

1. 要約
2. 決定事項
3. 未決定事項
4. 課題と原因
5. 社内向けメモ
6. 顧客向け文章
7. 提案書構成案
8. 次回確認事項

Opalは、自然言語の指示を視覚的なワークフローに変換し、各ステップのプロンプトを編集できるとGoogle Developers Blogで紹介されています。

そのため、この節では「1つの巨大なプロンプト」ではなく、「工程ごとに分けたミニアプリ」として設計します。

Google Opalで作る完成プロンプト

Google Opalを開き、新しいミニアプリを作成します。

最初に、以下の指示を入力してください。

要約・リライト・企画構築アシスタントを作ってください。

目的:
議事録やメモを入力すると、要約、論点整理、リライト、企画構築を工程ごとに分けて行うAIミニアプリにします。

入力:
・元資料
・資料の種類
・想定読者
・作りたい成果物
・文章の文体
・注意したい表現

処理:
1. 元資料の内容を確認する
2. 重要ポイントを要約する
3. 決定事項と未決定事項を分ける
4. 課題と原因を整理する
5. 社内向けメモにリライトする
6. 顧客向け文章にリライトする
7. 作りたい成果物に合わせて企画案を作る
8. 提案書構成案または記事構成案を作る
9. 元資料にない内容、未確認の内容、追加確認が必要な内容を一覧化する

出力形式:
Markdown形式

出力項目:
# 要約・リライト・企画構築アシスタント出力

## 1. 元資料の概要
## 2. 要約
## 3. 決定事項
## 4. 未決定事項
## 5. 課題と原因
## 6. 社内向けメモ
## 7. 顧客向け文章
## 8. 企画案
## 9. 提案書または記事の構成案
## 10. 次回確認事項
## 11. 人間が最終確認すべき点

条件:
・元資料に書かれていない決定事項を作らない
・未確定の内容は「未確認」と書く
・社内向けメモと顧客向け文章を分ける
・顧客向け文章は丁寧で自然な表現にする
・提案内容は複数案で出す
・各提案のメリットと注意点を入れる
・専門用語には短い説明を添える
・そのまま提出や公開をせず、人間が確認する前提で出力する

作成したミニアプリで試すサンプル入力

ミニアプリができたら、実際にサンプル入力を入れて動かしてみます。

今回は、地域食品を販売する会社との打ち合わせを想定します。

# サンプル入力

## 元資料
地域食品を販売する会社と打ち合わせを行った。
現在のホームページは5年前に制作したもので、スマートフォンで見ると商品情報や問い合わせ先が探しにくい。
Instagramは不定期に投稿しているが、投稿内容に統一感がなく、何を伝えるアカウントなのか分かりにくい状態になっている。
EC販売も行っているが、実店舗の顧客情報とは別管理になっている。
担当者は、ホームページ、SNS、EC、店頭販売をもう少し一体的に運用したいと話していた。
ただし、社内に専任のWeb担当者はいないため、いきなり大きなシステムを導入するのは難しい。
次回までに、現状分析、ホームページ導線改善、SNS運用設計、SEO記事作成、データ確認の方向性を整理することになった。

## 資料の種類
議事録メモ

## 想定読者
社内メンバーと顧客担当者

## 作りたい成果物
顧客向けの簡易提案書構成案

## 文章の文体
丁寧でわかりやすい。専門的すぎず、相手が安心して読める表現。

## 注意したい表現
・決まっていないことを決定事項のように書かない
・大規模システム導入を前提にしない
・顧客の現状を否定しすぎない
・未確認の内容は未確認と書く

この入力を実行すると、要約、決定事項、未決定事項、課題、顧客向け文章、提案書構成案まで一気に確認できます。

期待される出力例

出力のイメージは、次のような形です。

# 要約・リライト・企画構築アシスタント出力

## 1. 元資料の概要
地域食品を販売する会社のホームページ、SNS、EC、店頭販売の運用課題について整理した議事録メモです。現在は各施策が分断されており、スマートフォンでの見やすさ、SNSの統一感、データ管理、運用体制に課題があります。

## 2. 要約
現在のホームページはスマートフォンで情報を探しにくく、Instagram投稿にも統一感がありません。ECと実店舗の顧客情報も別々に管理されており、全体の運用がつながっていない状態です。一方で、社内に専任のWeb担当者がいないため、まずは現実的に始められる改善案を整理する必要があります。

## 3. 決定事項
・次回までに現状分析の方向性を整理する
・ホームページ導線改善の方向性を整理する
・SNS運用設計の方向性を整理する
・SEO記事作成の方向性を整理する
・データ確認の方向性を整理する

## 4. 未決定事項
・ホームページを全面リニューアルするか、一部改修にするかは未確認
・SNS運用を外部委託するか、社内運用するかは未確認
・ECと実店舗の顧客情報をどの方法で連携するかは未確認
・予算、スケジュール、担当範囲は未確認

## 5. 課題と原因
### 課題1:スマートフォンで情報が探しにくい
原因:ホームページ制作から時間が経っており、現在の閲覧環境に合っていない可能性がある。

### 課題2:SNS投稿に統一感がない
原因:投稿テーマ、デザインルール、運用目的が整理されていない可能性がある。

### 課題3:ECと実店舗の顧客情報が分かれている
原因:販売チャネルごとの管理になっており、顧客情報を横断的に見る仕組みが整っていない可能性がある。

## 6. 社内向けメモ
今回の提案では、いきなり大規模なシステム導入を前提にせず、現状分析から段階的な改善提案へつなげる。特に、スマホ導線、SNS運用設計、SEO記事、データ確認を優先して整理する。

## 7. 顧客向け文章
今回のお打ち合わせでは、ホームページ、SNS、EC、店頭販売をどのように連携させていくかについて、現状の課題を共有いただきました。まずは大きなシステム導入を前提にするのではなく、現在の運用体制に合わせて、優先度の高い部分から段階的に改善していく方針が適していると考えております。

## 8. 企画案
### 企画案1:スマートフォン導線改善プラン
メリット:問い合わせや商品閲覧につながりやすくなる。
注意点:既存サイトの構造確認が必要。

### 企画案2:SNS運用ルール整備プラン
メリット:投稿の統一感が出て、ブランドの印象が整いやすくなる。
注意点:継続運用できる投稿頻度を決める必要がある。

### 企画案3:SEO記事・商品紹介強化プラン
メリット:検索からの流入を増やす土台になる。
注意点:すぐに成果が出る施策ではないため、継続運用が必要。

## 9. 提案書構成案
# 地域食品販売におけるWeb・SNS・EC運用改善のご提案

## 1. 現状の整理
## 2. 課題
## 3. 改善方針
## 4. 優先施策
## 5. 段階的な進め方
## 6. 次回確認事項

## 10. 次回確認事項
・現在のホームページURL
・アクセス解析の有無
・問い合わせ数
・Instagramの運用担当者
・ECの管理方法
・実店舗の顧客管理方法
・希望予算
・希望スケジュール

## 11. 人間が最終確認すべき点
・会議で本当に決定した内容と一致しているか
・顧客の発言を誇張していないか
・未確認事項を断定していないか
・顧客向け文章として失礼な表現がないか

この出力を見ながら、「要約」「リライト」「企画構築」が分かれていることを確認します。

次に別パターンで試す

同じミニアプリに、別の種類のサンプルを入れてみます。

今度は、就職活動の文章作成に近い事例です。

# サンプル入力 2

## 元資料
大学のゼミで、地域商店街の来訪者アンケートを作成し、集計する活動を行った。
最初は質問数が多く、回答者が途中で離脱してしまうことがあった。
そこで、質問数を減らし、選択式の設問を増やした。
その結果、回答しやすくなり、集計もしやすくなった。
私はこの経験を通じて、相手に負担をかけない設計の大切さを学んだ。
現在は、IT企業の企画職に応募するため、自己PRや志望動機にこの経験を活かしたい。

## 資料の種類
経験メモ

## 想定読者
採用担当者

## 作りたい成果物
エントリーシートの自己PR案

## 文章の文体
誠実で自然。過度に立派に見せすぎない。

## 注意したい表現
・実績を盛らない
・リーダー経験があるとは書かない
・結果を数字で断定しない
・本人の学びが伝わるようにする

この入力では、同じミニアプリでも出力の方向が変わります。

議事録の場合は「提案書構成」でした。

経験メモの場合は「自己PR案」になります。

つまり、ミニアプリの使い方は、入力と作りたい成果物によって変えられます。

サンプル入力2で見るポイント

見るポイント確認内容
要約経験の流れが短く整理されているか
リライト採用担当者向けの自然な文章になっているか
企画構築自己PRの構成に変換されているか
安全性実績や役割を盛っていないか
本人らしさ学びや考えが残っているか

さらに自分用に改造する

サンプルで動きを確認したら、自分用に改造します。

Opalに次のように追加指示を出します。

このミニアプリを、提案書作成に特化した形に変更してください。

変更内容:
・出力項目に「提案の優先順位」を追加してください
・各提案に「実施難易度」「期待効果」「必要な確認事項」を追加してください
・顧客向け文章は、専門用語を避けた表現にしてください
・最後に、次回打ち合わせ用の質問リストを作ってください

また、就活用にする場合は、次のように変更します。

このミニアプリを、エントリーシート作成に特化した形に変更してください。

変更内容:
・社内向けメモを削除してください
・顧客向け文章を「採用担当者向け文章」に変更してください
・出力項目に「自己PR案」「志望動機案」「本人が深掘りすべき質問」を追加してください
・経歴や成果を盛っていないかをチェックしてください

精度が低いときの直し方

出力が物足りないときは、次の順番で改善します。

症状追加する指示
要約が浅い「重要度の高い順に要約してください」
企画案が弱い「企画案ごとに目的、対象者、期待効果を入れてください」
文章が硬い「中学生にも伝わる自然な表現にしてください」
未確認事項を断定する「未確認の内容は必ず未確認と明記してください」
顧客向け文章が強すぎる「相手の現状を否定せず、伴走する表現にしてください」
出力が長すぎる「各項目を3行以内でまとめてください」
出力が短すぎる「各項目に具体例を1つ入れてください」

この節のまとめ

この節では、要約・リライト・企画構築を分けて設計する方法を学びました。

重要なのは、AIに一度で全部やらせないことです。

flowchart TB
    A[元資料] --> B[要約]
    B --> C[論点整理]
    C --> D[リライト]
    D --> E[企画構築]
    E --> F[確認事項]
    F --> G[人間が最終確認]

要約は、内容を短く整理する工程です。

リライトは、読む人に合わせて表現を整える工程です。

企画構築は、次の成果物に変換する工程です。

この3つを分けると、AIの出力は安定します。

そして、どこで失敗しているのかも見つけやすくなります。

教材トップへ戻る