Google Apps ScriptとGemini APIで日報からボトルネックを抽出。業務改善のヒントを探す
結論を3行で
- スプレッドシートで運用する「日報」の記述内容をGASとLLMで自動分析し、ボトルネック（ここでは作業での失敗事項や体感で時間がかかっている作業）を抽出する
- 抽出したボトルネックはJSONとして保存し、履歴として残すことで分析可能とする
- 一定程度ボトルネックが貯まると、そこに業務改善の可能性が生まれる
この記事は何？
この記事は筆者の日報の活用例を紹介するものです。
前回の記事で、筆者はAIの学習に日報を活用していることを紹介しました。
今回紹介するのは、せっかく書いた日報から、業務改善に繋がるヒントを抽出してみた、というものです。
特に日々のルーティンワークの中で見過ごされがちな「小さなボトルネック」や「ふとした気づき」を、自動で拾い上げてくれる仕組みがあれば、もっと楽で効率的に仕事ができるはず。
そんなお話です。
実際には、企業の現場で個人作成の日報を解析対象にするのは賛否両論あるかもしれません。
プライバシー的な問題のほかにも、特に「失敗 = 弱みを見せる」と感じられる場面もありますから、うまくいかなかったこと話をなかなか表に出ないことも多いのでは？と。
ですが、それでも、日報から「新たな芽を見つける」といった使い方ができると、現場でうまくいってない事柄を拾い上げることができるため、便利で良いのでは？とは思うところです。
個人的には、イーロン・マスクの「失敗はオプションだ。失敗していなければ、十分に革新していない証拠だ」という言葉が好きで、うまくいかなかったことを積極的に拾い上げてLLMにコメントさせるために作った、というのが今回の仕組みです。
というわけで、詳しく紹介しますね。
なお、ボトルネックの定義について、ここでは単純に「失敗したなぁと感じたこと」または「タスク完了に時間がかかった作業」としています。
作業内容からLLMが推測するのではなく、あくまでユーザーが自発的に報告した部分をLLMが拾い上げてJSON形式でまとめる、という仕組みです。
仕組み
日報ツールのおさらい（前回記事）
この日報ツールは、Google Apps Script (GAS) を使って、Googleスプレッドシートに記録された日々の報告を読み込み、それをLLM（大規模言語モデル）に渡して分析させ、結果を再びスプレッドシートに書き戻す、というシンプルな構成です。
前回の記事では、ユーザーが記載した日報（タスクの進捗 / タスクで感じたこと）をxAIのGrok APIに送り、Grokが「愛あるコメント」を返すという仕組みでした。
今回の仕組みはこれとほぼ同様ですが、アクセスするAPI（Grok→Gemini）とプロンプトは変えてある、といった仕組みになっています。
LLMでボトルネックを抽出する
処理の流れは以下の通りです。
今回は、推論コストを下げるために、極シンプルに日報の記述内容に「ボトルネック」または「失敗」がある場合に、ボトルネックを抽出する処理をGemini APIに送り、その受信結果をJSONとして保存する、という仕組みにしました。
プロンプトは以下の通り。
以下の業務日報の内容のうち、
- 失敗として触れられている部分
- 作業のボトルネックとして触れられている部分
を1行でまとめてください
フォーマットは必ず以下の形式に従ってください
まとめる際は以下の事柄に注意せよ
- 「だ、である」調で記載すること
- 記載された内容に基づくこと。入力にない情報は補完しないこと
---
<タスクの進捗>
${taskDigest}
</タスクの進捗>
<タスクで感じたこと>
${taskMind}
</タスクで感じたこと>
---
JSONの保存フォーマットは以下のようなシンプルな形式です。
{
"ProjectID": {
"Portfolio_slug": "ops-automation（大カテゴリ）",
"Project_slug": "daily-report-update-2025-09（小カテゴリ）"
},
"history": [
{
"date": "2025-10-06T15:00:00.000Z",
"comment": "失敗として触れられている部分はない。作業のボトルネックはスクリプトの修正に時間を要したことである。"
},
{
"date": "2025-10-19T15:00:00.000Z",
"comment": "「種」JSONを出力するソースコードの作成に時間を要し、似たようなソースコードが増えたため、今後もリファクタリングが必要である。"
},
{
"date": "2025-10-21T15:00:00.000Z",
"comment": "失敗としてマークダウンでのメモが続かなかったこと、ボトルネックとしてGASでファイルが増加したことが挙げられる。"
}
]
}
また、Google Apps ScriptでのGemini APIのアクセス例はこちらの記事で紹介しています。下記記事内容同様に、今回もJSONスキーマでの出力を強制し、適切なフォーマットで返されているか、軽くガードレールを通しています。
実際使ってみて
というわけで、実際に使い続けてると、こんな感じで比較的よく躓く点が見えてきます。以下は筆者がGoogle Apps Scriptの改ざん中に実際に運用し、記録された物を抜粋したものです。
- 失敗として触れられている部分はない。作業のボトルネックはスクリプトの修正に時間を要したことである。
- 「種」JSONを出力するソースコードの作成に時間を要し、似たようなソースコードが増えたため、今後もリファクタリングが必要である。
- 失敗としてマークダウンでのメモが続かなかったこと、ボトルネックとしてGASでファイルが増加したことが挙げられる。
ここでは、ソースコードの修正・リファクタリングに時間がかかっていることがわかります。
つまり、この部分を何らかの方法で対処する（またはその作業自体が必要かどうか見直す）ことで、作業のボトルネックをつぶせる可能性がありますよね。
ちなみに、抽出したボトルネックはJSONに保存しているため、それをプロンプト化し「このボトルネックをもとに改善策を出して」みたいな改善案提示も自動化できます。
ほかにもこんなアイディア
今回は「日報のネタから仕事のボトルネックを探して蓄積する」というものでしたが、ほかにも
- 「こうしたらいいんじゃない？」という改善アイディア
- 「ここがよくわからなかった」という不明点
- 「これいつも繰り返してるよ」という自動化ポイント
など、抽出させるとおもしろいのでは？と考えています。
個人的には「こうしたらいいんじゃない？」という改善アイディアを「未来の種」と呼び、今回のボトルネックと同様にJSONに蓄積しています。
仮にその改善アイディアを採用したとき、「なぜそうしたのですか？」という問いに、記録が残っているから「あの時こういうことがあって・・・」と物語として答えられるんですよね（要するにストーリーテリングの材料になる、という意味です）。
また見てね！
また、記事を書くのでフォローしてね！
Xはお金の話中心です
Discussion