1. はじめに：毎年30分の定例作業
毎年4月、自治体から配布されるゴミカレンダーをTimeTreeに登録しています。対象は1年分（4月〜翌年3月）のゴミ回収スケジュール。他の予定と一緒に確認したいので、あえてTimeTreeに統一しているという背景です。
これまでの手作業での運用は以下の通りです。
- パターン化できる部分：「第2水曜日はプラスチック製容器包装の日」など法則が一定している期間は、TimeTreeの「繰り返し予定」機能で一括登録
- 例外処理：1ヶ月に5週ある月は隔週のゴミが3回発生する。正月や盆は回収なし。こうした例外が発生する箇所で繰り返し予定を区切り、新たな繰り返し予定を設定
- 所要時間：年1回、約30分弱
毎年同じ手順の繰り返しなので、「PDFを読み込んでCSVを吐き出し、カレンダーに一括登録できれば」という単純な動機で、生成AIを使った自動化を試みることにしました。
では、配布されたPDFをまずCopilotに読み込ませてみることにしました。
2. 対象PDFの構造を確認する
まず、配布されるゴミカレンダーPDFの特徴を確認してみました。
このような構造です。
- レイアウト：1年分（12ヶ月）が1ページ（A3相当）に高密度に詰め込まれている
- 情報表現方法：ゴミの種別は日付マスの背景色で示されている。日本語による注釈や文字列はない。凡例（中央上）に色の意味が書かれているが、1ページ表示では各日付マスの背景色と凡例を正確に照合しにくい
- 例外対応：一ヶ月に５週ある月などが存在すると、びん・かんごみの週が等間隔の隔週でなくなるなどが発生。その他、正月や盆などの回収なし日も存在
では、このPDFを複数のAIに読み込ませてみることにしました。
3. 試行1：Copilot → 階層構造により失敗
Copilotに上記のゴミカレンダーPDFを読み込ませました。
当時、無課金で使える生成AIとしてCopilotをよく使っていたので、まず手近なところから試してみることにしました。
結果は簡潔でした。「文字列が認識できません」という返答。
理由は、このPDFがイラストレータなどの設計ツールで作られた階層構造のPDFだからだと推測されます。見た目には1年分のカレンダーと凡例が見えているのに、テキスト情報として抽出可能な文字が含まれていないという状態。
所要時間：10分程度。別の手段を探す必要があります。
4. 試行2：Gemini → 「ぼやけて見える」という返答
Copilotが対応できないなら、もう少し画像認識の強いAIを試そうということで、Geminiに同じPDFを読み込ませました。
Geminiは階層構造を気にせず、画像として認識できます。ただし、その返答は微妙でした。
「1ページに12ヶ月分の情報が詰め込まれているので、ぼやけて見える」という表現です。確かに1ページA3相当のPDFに、3月から翌年3月までの全カレンダーが高密度に配置されています。
試してみた結果、最初の1〜2ヶ月分については比較的正確に繰り返し法則を抽出できるのですが、その後の月になるとハルシネーションが始まります。「画像に見えない色」で「存在しないゴミの日」を作り出してしまうのです。
所要時間：30分程度の試行。目視確認でこのハルシネーションに気づきました。
5. 試行3：ゴミカレサービス → 同じ挙動
「既存のサービスなら対応済みかもしれない」と考え、ゴミカレというサービスを試してみました。このサービスは、自治体のゴミカレンダーPDFをアップロードするだけで、Googleカレンダーに自動登録してくれるものです。
試してみた結果は、Geminiと同じ挙動でした。高密度レイアウトと背景色認識の困難さは変わりませんでした。
サービス調査・試用に20分程度を要しました。
6. 転機：「1ヶ月ずつ拡大したPDFなら読める可能性がある」
ここで詰まりました。複数回の試行結果から、生成AIが「1年1ページの高密度PDF」に対応できないことは明らかです。
そこでGeminiに改めて相談してみました。「このPDFを読み込むにはどうすればいいか」という問いに対して、**「1ヶ月ずつに拡大・分割したPDFなら、認識精度が上がる可能性がある」**というアドバイスをもらいました。
13ページ分の「凡例+12ヶ月分の拡大版」というPDFを手作業で作り、それをGeminiに読み込ませることにしました。
シンプルなアドバイスですが、ここから手作業が始まります。
7. 手作業での前処理：13ページPDFの作成
Geminiのアドバイスを実行するため、以下の作業を手作業で行いました。
- 配布PDFをPDF-XChange Viewerで画像エクスポート
- 元のPDFから凡例部分を確認し、どのゴミが何色かを明記
- LibreOffice Impressで新規ファイルを開く
- 凡例を拡大した状態で1ページ目を作成
- エクスポート画像から各月を範囲選択で切り出し
- 切り出した月ごとの画像を、Impressのスライドに貼り付け（全12ページ）
- 最終的に「13ページPDF（凡例+12ヶ月分）」をファイル→PDFエクスポートで生成
切り出し処理の自動化も検討しましたが、座標計算の手間を考えると手作業の方が早いと判断しました。
結果として、体感で30～45分程度の手作業になりました。単なるトリミングではなく、凡例の文字サイズを大きくしたり、各月の画像を見やすくレイアウトし直したりという調整が入っているためです。
ここまでで、Copilot試行（10分）+ Gemini試行（30分）+ ゴミカレ試用（20分）+ 前処理（30～45分）= 合計90～105分を費やしています。本来の手作業が30分程度だったことを考えると、時間的には明らかに損です。
ただ、もう引き返せません。作成したPDFをGeminiに読み込ませてみることにしました。
8. 試行4（再チャレンジ）：Gemini + 拡大PDFで月単位出力
前処理済みの13ページPDFをGeminiに読み込ませ、1ヶ月ずつ「このような形式でCSVを作ってください」というプロンプトを送りました。
画像が拡大されたおかげか、ハルシネーションは減りました。Geminiは月単位で、以下のような形式のCSVを出力できるようになります。
Subject,Start Date,All Day Event
もえるごみ,2026/04/02,True
プラスチック製容器包装,2026/04/01,True
プラスチック製容器包装,2026/04/08,True
（以下続く）
ようやく実用的な出力が得られました。所要時間は15分程度。
9. 必須フェーズ：CSVの目視確認と修正
ここからが重要なポイントです。Geminiの出力を前提として信用してはいけません。
AIが出力したCSVを確認し、以下のプロセスを実施しました。
- 出力されたCSVを確認
- 元のPDFと照合し、日付や曜日に誤りがないか目視確認
- 必要に応じてCSVを手修正（特に色の認識誤りや背景色の微妙な変化を見直す）
- GoogleカレンダーにCSV形式でインポート
- TimeTreeで読み込み、再度レイアウトと内容を確認
この目視確認と修正に、30～40分程度を要しました。
特に夏季の月は、ペットボトル回収が追加されることで色分けが複雑になるため、より注意深く確認する必要がありました。
10. 結果：技術的成功 vs 手間と成果
10.1 技術的評価
「自治体PDF → 前処理 → AI読み込み → CSV出力 → Googleカレンダー → TimeTree」というフローは完成しました。翌年以降はこのフローを再利用できます。
10.2 手間と成果
昨年までの手作業は約30分でした。今年の自動化全体にかかった時間をまとめると：
- Copilot試行：10分
- Gemini初回試行：30分
- ゴミカレ試用：20分
- PDFの前処理（13ページ化）：30～45分
- Gemini再度の読み込みと指示：15分
- 目視確認・修正：30～40分
- 合計：約2時間25分～2時間50分
個人的な満足度としては「8割失敗」です。技術的には完成形を作れましたが、手間と成果を見比べると、手作業のほうが遥かに効率的だったという結果になりました。
翌年以降は、このフローを再利用できるはずなので、時間効率が改善される可能性はあります。ただし、PDF形式の変更や新しい色の追加があれば、前処理の再構築が必要になる危険性も残っています。
11. 考察：なぜ色が情報を持つ文書はAIに難しいのか
このプロジェクトを通じて、生成AI（無料枠）の構造的な限界が見えてきました。
11.1 色が唯一の情報源となっている文書
生成AIは「テキスト」や「構造化されたデータ」を抽出するのは得意です。しかし「背景色」という視覚要素のみが情報源となる文書は、認識が不安定になります。
色の認識は、解像度・スクリーン設定・JPG圧縮時のノイズなど、細かい環境要因に影響されやすいためです。同じ「ピンク色」でも、Geminiがそれを「もえるごみ」と認識するか「びん・かん」と認識するかは、背景色の微妙なRGB値差異に左右されやすいのです。
11.2 高密度レイアウトでの精度低下
1ページに大量の情報が詰め込まれると、個別要素（日付マス）の認識精度が低下する傾向があります。
実際のPDFでは、1ページA3相当に12ヶ月分が配置されており、各日付マスは非常に小さいです。Geminiが「ぼやけて見える」と表現したのは、この高密度さが原因だと考えられます。
前処理で「1ヶ月単位への分割」を行うことで精度は向上しましたが、これは「AIが高精度で対応した」のではなく「人間が補助情報を用意した」という状態です。
11.3 前処理のコスト
自動化の前段階である「前処理」が手作業で行われると、自動化全体のコストに大きく影響します。
毎年同じ形式のPDFが配布されるはずですが、自治体側の設計変更・色追加があれば、前処理の再構築が必要になります。その時点で、単純な手作業に戻したほうが効率的という判断も十分あり得ます。
12. おわりに：自動化の「できる」と「やるべき」は別
今回のプロジェクトから得た教訓は、**「自動化は『できること』と『やるべきこと』が別である」**ということです。
技術的には、PDF → AI処理 → CSV → カレンダー統合は実現可能です。しかし実務的には、試行錯誤と前処理の時間が、シンプルな手作業を超えてしまいました。
自動化の採用判断には、技術的な可能性だけでなく、実際の運用コストの検証が必須です。特に「色が情報」という構造を持つ文書では、現状の生成AI（無料枠）での完全自動化は現実的ではありません。
ただし、このプロジェクトで構築したフロー自体は、他の高密度レイアウト文書（例えば、複数ページの料金表や家計簿の自動取込など）に応用できる可能性があります。前処理の手間をどこまで許容できるか、という判断基準さえあれば、今後も検討の余地はあります。