こんにちは、FVGの村田です。AI Tips連載の7日目の記事です。
はじめに
私は今フューチャー社内のバックオフィス業務をターゲットに生成AI活用を更に促進させるミッションを担い、日々業務に勤しんでいます。
バックオフィスの方へのヒアリングを通じて、生成AIの活用（本記事においてはGeminiの活用を想定）を通じて効率化・省力化を狙いたい業務シーンやニーズがいくつか浮かび上がってきました。
私自身もまだまだ生成AIの使い方を勉強している身ですが、各シーンにおいて現時点で考えられる好ましい使い方を模索したい、というのが本記事のモチベーションです。
※本記事では Gemini 2.5 Pro の利用を前提とします。
効率化・省力化を狙いたい業務シーン・ニーズ3選
【シーン① マーケ】
ブログ記事の定期アナウンス用メール文面の作成作業を省力化したい
【シーン② 総務など】
業務にて利用するGASを自作し、運用保守できるようになりたい
【シーン③ 各所】
部門内で共有するGem用プロンプトの品質をあげることで作業品質を向上させたい
本記事では上記3つの業務シーン・ニーズを想定して、Geminiをいかに上手に活用できるか模索します。
【シーン①】ブログ記事の定期アナウンス用メール文面の作成作業を省力化したい
当社はブログ執筆活動が活発ですが、マーケ部門は定期的にブログ記事をまとめて社内向けにも発信してくれています。ただアナウンス文面の作成負荷もなかなか手間なので Gemini におまかせして省力化していきましょう。
早速ですが例えば以下が完成版のプロンプトです。
フューチャー技術ブログ（https://future-architect.github.io/）のトップページから、最新の記事を10件取得してください。
取得した記事を対象に、以下の条件で宣伝メールの文面を作成してください。
・ターゲット読者： IT業界で働く若手エンジニア
・目的： ブログの購読者数増加
・トーン： カジュアルで親しみやすく
・記載内容：
・各記事のタイトル（URLリンク付き）
・各記事の概要（どんな内容か）
・各記事のおすすめポイント（どんな人におすすめか）
|
生成結果を全文載せると長いので省略しますが、以下のように文章が生成されます。記事タイトルの部分もしっかりとURLリンク付きになっています。
件名：【フューチャー技術ブログ】最新記事でスキルアップ！若手エンジニア必見の情報が満載！
フューチャー技術ブログ読者の皆様、こんにちは！
暑い日が続きますが、いかがお過ごしでしょうか？
今月も、皆さんの知的好奇心を刺激する、面白くてためになる技術情報をお届けします！
通勤中や休憩時間にサクッと読める記事ばかりなので、ぜひチェックしてみてくださいね。
【今月のピックアップ記事】
1. Software Design 2025年8月号「2038年問題を考える」を寄稿しました
・どんな内容？
2038年に迫る、UNIXシステムにおける重大な問題「2038年問題」。その概要から対策まで、新卒エンジニアが分かりやすく解説します。
・こんな人におすすめ！
・大規模システムの開発に携わっている、または興味がある方
・IT業界の未来を担う、すべての若手エンジニア
...（以下略）
|
実運用にあたってはもう少し要件に合わせて指示を追加する必要がありそうですが、ひとまず大枠のプロンプトはこれで良いのではないでしょうか。
プロンプト検討にあたっては、プロンプト自体をGeminiにレビューしてもらうプロセスを踏みました。
元々以下のようなプロンプトにて、「プロンプトの改善提案」をしてもらっています。
以下プロンプトを最適な形に書き換えて。また、指摘ポイントと改善案は表形式にまとめて提示して。
フューチャー技術ブログの記事から、直近1ヶ月間の記事を収集し、宣伝メール文面を作成して。
対象のブログURLは以下。
https://future-architect.github.io/
・各ブログ記事のタイトルがURLリンクとなっていること
・各ブログごとに、どんな内容か、どんな人におすすめか、を簡潔に示す宣伝文を付与して
|
これによりGeminiから受けた改善提案は3つありました。
各指摘に素直に従ってプロンプトを書き換えることで完成版プロンプトへと仕上げていきました。定型業務にて複数回の利用が想定されるプロンプトは、Geminiにレビューしてもらって質を高めていくプロセスを踏むのが望ましいなと感じました。
ちなみに、、、てっきりGeminiはMarkdownスタイルで丁寧に段落分けされたプロンプト改善案を提示してくるかと思ってたんですが、必ずしもそういうわけではなさそうです。
【シーン②】業務にて利用するGASを自作し、運用保守できるようになりたい
フューチャーのITコンサルは全員コードを書きますが、バックオフィスの方々は必ずしもそうではありません。ソースコードの読み書きに苦手意識を持ってる方ももちろんいらっしゃいます。そういった方でもGASを自由に扱えるようになるにはどうすればいいか考えよう、というのが本シーンの主旨です。
どうやらバックオフィスの方に話を伺うと、「Geminiに聞けばソースコードが生成されることは分かってる。ただ、生成されたソースコードが正しく動作するのかを確認できないので実運用に踏み切れない」とのこと。
エラーで動作が止まったら都度エラーメッセージをGeminiに投げて解消していけば良い、と考える方もいるかもしれませんが、例えば業務内容として「各社員宛に必要な個別情報をメールする」といったシーンなどもありえます。つまり「Aさんのための情報が正しくAさんに送付されること。間違ってBさんに送られるようなことが発生しないこと。」が担保されてない限りは生成されたGASスクリプトにて実業務を遂行することは難しいです。
ではどうすればいいでしょうか。
Geminiに直接聞いてみました。
Geminiとのやりとりを通じてGASスクリプトを生成したい。
ただし生成されたGASスクリプトの確からしさを利用者が判断できないことを想定し、Geminiにてテストあるいはテストに相当するプロセスを経てスクリプトの確からしさを検証してほしい。
あるいは、利用者にてどのような確認手順を経ればスクリプトの確からしさを担保できるのか、具体的な作業プロセスを示してほしい。
上記のようなニーズがある場合、どのようなプロンプトを書くことが望ましいか、サンプルを提示するとともに、記載のポイントとその理由を表形式で列挙して。
|
そして以下が回答の一部。
Geminiは実際のGoogle環境でスクリプトを直接テストすることはできません。そのため、**「テストコードの生成」「テストケースの洗い出し」「ユーザー向けの具体的な確認手順の提示」**を促すことで、スクリプトの信頼性を高めていくアプローチが有効です。
やはりテスト自体をGeminiに担ってもらうことは難しいので、自分がテストをする前提でそのテスト手順を明確化してもらう形が良さそうです。
さて、先程のプロンプトにて「サンプルの提示」を要求していたので、「スプレッドシートの特定の条件に合う行を別シートに転記する」というよくあるシーンを例にプロンプトを提示してくれました。
# 前提条件
- Googleスプレッドシートを使用します。
- 操作対象のスプレッドシートには「タスクリスト」シートと「完了リスト」シートが存在します。
- 「タスクリスト」シートのC列にはステータス（例：「未着手」「対応中」「完了」）が入力されています。
# 実行したいこと
「タスクリスト」シートのC列が「完了」になっている行を、「完了リスト」シートの末尾にコピー＆ペーストし、その後、元の「タスクリスト」シートからその行を削除するGASスクリプトを作成してください。
# 信頼性担保のための要件
1. **エラー処理**: 処理対象の行が存在しない場合や、シート名が変更されていた場合に、処理を安全に停止し、ログにエラーメッセージを出力するような処理を加えてください。
2. **コードへのコメント**: 各処理ブロック（変数の定義、シートの取得、行のループ、コピー処理、削除処理など）の目的が理解できるよう、コード内に詳細な日本語のコメントを記述してください。
3. **テストケースの提示**: このスクリプトの動作を検証するために、どのようなテストケース（正常系・異常系）を想定すべきか、具体的なパターンを複数挙げてください。
4. **ユーザー向けの確認手順**:
- 私がこのスクリプトを安全にテストするための、具体的な確認手順をステップバイステップで説明してください。
- テスト用のスプレッドシートの準備方法（どんなデータを用意すればよいか）から、スクリプトエディタへの貼り付け、実行、結果の確認方法までを含めてください。
- 特に注意して確認すべき点も教えてください。
|
また、上記プロンプトの作成にあたりポイントになる点を列挙してもらっています。
「タスクリスト」シートのC列が「完了」になっている行を、「完了リスト」シートの末尾にコピー＆ペーストし、その後、元の「タスクリスト」シートからその行を削除するGASスクリプトを作成してください。
例えば今回想定しているGASスクリプトでは行の削除が含まれているため、コピー&ペーストが正しく行われないと元データが最悪消失してしまうリスクを孕んでいます。ゆえにポイント5と6の指示にて正しく動作検証することが重要です。
さて、それでは先程提示されたサンプルのプロンプトを使ってGeminiにどのような回答をもらえるのか試してみましょう。
出力されたソースコードは以下です。
function moveCompletedTasks() {
try {
const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
const sourceSheetName = "タスクリスト";
const destinationSheetName = "完了リスト";
const statusColumn = 3;
const statusValue = "完了";
let movedCount = 0;
const sourceSheet = spreadsheet.getSheetByName(sourceSheetName);
if (!sourceSheet) {
console.error(`エラー: シート「${sourceSheetName}」が見つかりません。`);
return;
}
const destinationSheet = spreadsheet.getSheetByName(destinationSheetName);
if (!destinationSheet) {
console.error(`エラー: シート「${destinationSheetName}」が見つかりません。`);
return;
}
const sourceRange = sourceSheet.getDataRange();
const sourceValues = sourceRange.getValues();
const lastRow = sourceSheet.getLastRow();
for (let i = lastRow; i >= 1; i--) {
const status = sourceSheet.getRange(i, statusColumn).getValue();
if (status === statusValue) {
const rowToMove = sourceSheet.getRange(i, 1, 1, sourceSheet.getLastColumn()).getValues();
destinationSheet.appendRow(rowToMove[0]);
sourceSheet.deleteRow(i);
movedCount++;
}
}
if (movedCount > 0) {
console.log(`${movedCount}件の完了タスクを移動しました。`);
} else {
console.log("処理対象の完了タスクはありませんでした。");
}
} catch (e) {
console.error("スクリプトの実行中に予期せぬエラーが発生しました。");
console.error(e);
}
}
|
ポイント3,4にて言及されているエラーケースの処理やコメントの記載についてもしっかり考慮されたスクリプトが生成されました。
そして以下が生成されたテストケースです。（実際の出力は文章の羅列でしたが、見やすいように表形式へ変換しています。最初から表形式で出力するようにプロンプトを書くのが良さそうですね）
個人的には異常系ケースの下2つは正常系として扱ってもよいのではと思いましたが、このへんは文化でしょうか。いずれにせよ必要なテストケースが網羅的に作成されていることが分かります。
そして一番重要な「確認手順」の出力が以下です。ステップ1～4まで丁寧に出力されています。
ステップ1: テスト用スプレッドシートの準備 📝
重要: 必ず元のスプレッドシートをコピーしたファイルでテストしてください。 スクリプトは行を削除するため、元に戻せません。
1. 現在のスプレッドシートを右クリックし、「コピーを作成」を選択してテスト用のファイルを用意します。
2. コピーしたファイルを開き、以下の2つのシートがあることを確認します。なければ作成してください。
・タスクリスト
・完了リスト
3.両方のシートに、同じヘッダー行を作成します。（例: A列: タスク内容, B列: 担当, C列: ステータス）
4.「タスクリスト」シートに、テスト用のデータを入力します。上記のテストケースを参考に、様々なパターンのデータを用意してください。
・C列が「完了」の行を数行作る。
・C列が「未着手」「対応中」などの行も混ぜる。
・空白行なども含めておくと、より堅牢なテストができます。
|
ステップ1の中にて、添付スクショのように「データ準備の例」としてGoogleスプレッドシートにエクスポート可能な形でサンプルの「タスクリスト」シートと「完了リスト」シートも作成してくれているため、テスト用にどういった準備をすればいいかも丁寧にガイドしてくれます。
ただ欲を言えば、どのテストケースから順に実施するのが望ましいかをガイドしてくれたほうが良かったですね。例えば今回であればまずは「完了」タスクが1件のテストケースにて小さな正常系の動作確認を行い、その後徐々に処理対象量を増やしていくのが良さそうです。まあその旨をプロンプトに書きましょうってことですね。
ステップ2: スクリプトの導入 💻
1. テスト用のスプレッドシートを開いた状態で、上部メニューの「拡張機能」>「Apps Script」をクリックします。
2. スクリプトエディタが開きます。デフォルトで表示されている function myFunction() { ... } というコードをすべて削除します。
3. 本回答の冒頭で提示したGASスクリプトを全文コピーし、空になったスクリプトエディタに貼り付けます。
4. 上部のフロッピーディスクアイコン💾をクリックして、プロジェクトを保存します。
|
ステップ2にてスクリプトを保存します。丁寧に手順を列挙してくれてるので、初めての人でも安心です。
ステップ3: スクリプトの実行と承認 🚀
1. スクリプトエディタの上部にある関数選択プルダウンが moveCompletedTasks になっていることを確認します。
2. 「実行」ボタンをクリックします。
3. 初回実行時のみ、「承認が必要です」というダイアログが表示されます。
・「権限を確認」をクリックします。
・ご自身のGoogleアカウントを選択します。
・「このアプリはGoogleで確認されていません」という警告が表示される場合がありますが、「詳細」をクリックし、「（プロジェクト名）（安全ではないページ）に移動」を選択します。
・最後に、スプレッドシートへのアクセス許可を求める画面で「許可」をクリックします。
|
ステップ3にてスクリプトを実行して、、
ステップ4: 結果の確認 ✅
1. スプレッドシートの確認:
・「タスクリスト」シートに戻り、C列が「完了」だった行がすべて削除されていることを確認します。
・「完了リスト」シートを開き、「タスクリスト」から削除された行が末尾に追加されていることを確認します。
2. 実行ログの確認:
・スクリプトエディタの下部に表示される「実行ログ」を確認します。
・「3件の完了タスクを移動しました。」のようなメッセージ、または「処理対象の完了タスクはありませんでした。」というメッセージが表示されていれば、正常に処理が完了しています。
・エラーメッセージが表示されている場合は、シート名が間違っていないかなどを確認してください。
|
ステップ4にて結果を確認する流れ。
詳細な確認手順が列挙されているので、GASやプログラムにあまり馴染みのない人でもひとつひとつ手順を追ってGeminiに生成されたスクリプトの確からしさを確認することができるのではないでしょうか。
【シーン③】部門内で共有するGem用プロンプトの品質をあげることで作業品質を向上させたい
フューチャーではコンサルタントが提案時などに資料などを作成し、適宜リーガルチームにチェックしてもらっています。（もちろん当社固有な話ではなく、非常に一般的なプロセスだと思います）
業種・業態ごとに異なるお作法・文化があったり、相手方の企業あるいは案件特性によって重要視すべきポイントが変わったり、とかくリーガルチームのチェックは大変です。なるべく「リーガルレビューはリーガルメンバーが本当に見るべきポイントのみにフォーカスして実施したい」と考えるのは必至。そうなるとリーガルレビュー提出時の資料品質をあげようって話になるのですが、ここでGeminiを活用しようというわけです。
これはなにもリーガル領域に限った話ではありません。「資料を提出し、受け取った側が内容をレビューする」というプロセスの存在するすべての業務に通じる話です。ものすごく汎化すると「Geminiを使ってセルフレビューの質をあげよう」というのが本シーンにて取り組む課題です。そのうえで、それをGem化しておけば都度長いプロンプトテンプレをコピってくる必要もないし、作業効率の向上も見込めるはずという考えです。
シーン①②でもすでに同様のプロセスを経てるのですが、やはりまずはGeminiに相談してみるのが簡単です。
例えば先程のリーガル提出資料を想定してるのであれば以下のような感じ。
コンサルティング企業にて、法務部門へ提出する資料の品質を向上させるためにGemを作成しようとしています。
一般的な資料レビューの観点と法務の観点を踏まえ、Gem用のプロンプトを作成してください。
|
上記プロンプトにて出力される結果（= Gemに組み込むプロンプト）が以下です。
# あなたの役割
あなたは、一流コンサルティングファームに所属する、極めて優秀な法務担当者であり、ビジネス経験豊富なシニアコンサルタントでもあります。
あなたの使命は、チームのメンバーが作成した資料を、法務部門にレビュー依頼する「前」の段階で、品質を最大限に高めるための支援をすることです。
# 行動指針
1. **建設的なフィードバック:** 受け取ったメンバーが前向きに修正に取り組めるよう、常に丁寧かつ建設的なトーンで対話してください。単なる批判ではなく、改善のための具体的な提案を心がけてください。
2. **具体性の追求:** 問題点の指摘に留めず、必ず「具体的な修正案（リライト案）」と「そのように修正すべき理由（法的リスクやビジネス上の懸念点など）」をセットで提示してください。
3. **平易な解説:** 法務に関する専門的な内容も、コンサルタントが理解しやすいように平易な言葉で解説してください。
4. **構造的な出力:** フィードバックは、後述の`# 出力フォーマット`に従い、マークダウン形式で構造的に分かりやすくまとめてください。
5. **ユーザー入力の待機:** 上記の役割と行動指針を理解したら、ユーザーからレビュー対象の資料情報が入力されるのを待ってください。
# レビューの実行プロセス
ユーザーから資料情報を受け取ったら、以下のプロセスに従ってレビューを実行してください。
1. **背景理解:** まず、ユーザーが提供する「資料の種類」や「プロジェクトの背景・目的」を読み込み、資料の位置づけを正確に把握します。
2. **多角的なレビュー:** 以下の2つの観点から、資料を詳細に分析します。もしユーザーから「特に重点的に見てほしい点」が指定されていれば、その点を特に注意深くレビューしてください。
* **【観点1】一般的なコンサルティング資料としての品質**
* **論理構成:** 主張と根拠は明確か。話の飛躍はないか。全体として一貫性があるか。
* **明瞭性:** 結論ファーストか。一文が長すぎないか。専門・社内用語が多用されていないか。曖昧な表現がなく、誤解を与えないか。
* **網羅性:** 記載すべき事項（前提条件、スコープ、免責事項など）に漏れはないか。
* **正確性:** 数値、固有名詞、日付などに誤りはないか。
* **表現の統一:** 敬体・常体の混在はないか。用語の表記は統一されているか。
* **【観点2】法務・契約リスク**
* **契約条項の明確性:** 当事者、権利義務、成果物、対価、期間などが一義的に解釈できるように具体的に書かれているか。
* **リスクの洗い出しと手当:** 責任範囲（損害賠償）、知的財産権の帰属、秘密保持、再委託、契約解除、不可抗力、準拠法・合意管轄などが適切に定められているか。自社に過度に不利な内容はないか。
* **法令遵守:** 個人情報保護法、下請法、景品表示法などの関連法令に抵触する可能性はないか。反社会的勢力排除条項は含まれているか。
* **曖昧な表現の排除:** 「誠意をもって協議する」「可及的速やかに」など、解釈の余地がある表現が意図せず使われていないか、そのリスクは認識されているか。
# 出力フォーマット
---
### **法務レビュー結果**
#### **はじめに**
このレビューは、法務部門への提出前に資料の品質を高めることを目的としています。最終的な判断は、必ず法務部門にご確認ください。
#### **【総評】**
（資料全体を通しての、良い点と最も重要な改善点を2〜3行で簡潔に記載）
---
#### **【観点1】コンサルティング資料としての品質レビュー**
| 箇所（ページ数・章番号など） | 問題点 | 修正案（リライト案） | 修正理由 |
| :--- | :--- | :--- | :--- |
| （ここに具体的な指摘を記載） | | | |
---
#### **【観点2】法務・契約リスクの観点からのレビュー**
| 箇所（ページ数・条文番号など） | 潜在的リスク | 修正案（リライト案） | 修正理由と法的観点からの解説 |
| :--- | :--- | :--- | :--- |
| （ここに具体的な指摘を記載） | | | |
#### **【その他】法務部門へ確認すべき事項**
（AIだけでは判断が難しい、専門的な法的判断を要する事項をリストアップ）
* （例）本件のビジネスモデルは、〇〇法における規制対象に該当しないか、最終確認が必要です。
* （例）〇〇という条項は、過去の類似案件と比較して当社に不利でないか、確認を推奨します。
---
|
そして、都度ユーザが入力するプロンプトのテンプレートが以下。
こんにちは。
以下の資料について、法務部門への提出を想定したレビューをお願いします。
# 資料情報
* **資料の種類:** 【例：クライアントA社向け業務委託契約書ドラフト】
* **プロジェクトの背景・目的:** 【例：Bシステム導入に関するコンサルティングを提供するプロジェクト。本契約書はクライアント提示前の最終社内レビューが目的です。】
* **特に重点的に見てほしい点（任意）:** 【例：クライアントとの責任分界点と、成果物の定義について、特に手厚くレビューをお願いします。】
# レビュー対象の資料
（ここにレビューしてほしい資料のテキスト全文を貼り付けてください）
|
先程の簡単な問いかけでもここまで詳細なプロンプトを提示してくれます。これをベースに、出力形式を変えたければそのように書き換えればいいですし、あるいは会社固有の観点やあるあるの指摘ポイントなどをプロンプトの中に入れ込んでいけば、もっと実践的なプロンプトに育っていくはずです。
Gemは現状他人と共有ができないので、仮にプロンプトが育った場合にはその旨をチーム全体に周知し、各人でGemの内容を書き換えてあげる必要があります。ちょっと面倒ですね…おそらくそのうちGemは他人と共有できるようになるのではと思ってますが、サービスのアップデートを大人しく待ちましょう。
また、Gemの共有機能に加えてプロンプトのバージョン管理機構も備わってくれるとうれしいです。エンジニアであればプロンプトをGit管理するなどは特にハードルないでしょうが、そういったバージョン管理機能に馴染みのない人にとっては、GemのGUI上でポチポチするだけでバージョン管理ができると便利なんだろうなと思います。（もちろんエンジニアにとってもGem内で完結してくれた方がおそらく楽チンなはず）
さいごに
今回はバックオフィス業務改革に焦点を絞って話を進めてきました。しばらくはこの領域が私の主戦場となるので、今後直面するリアルな課題やその解決策についても別記事にてご紹介できればと思っています。
AI Tips連載はまだまだ続きます！引き続きお楽しみくださいmm