CONTENT
ここから
本章では、これから制作するアプリの目的と要件を整理します。
今回の課題では、単にAIを使ったアプリを作るだけではありません。利用者がスクリーンショットを撮影した後、その内容をAIが読み取り、次に行うべきことを提案する仕組みを考えます。
ただし、実際に開発できるかどうかは、使用するOSや権限、AIサービスの仕様によって変わります。最初からすべて実現できると決めつけず、技術的な制約を調査しながら開発を進めてください。
1.1 制作するアプリ
今回制作するのは、スクリーンショットの内容を解析し、利用者へ「次の行動」を提案するアプリです。
たとえば、利用者が次のような画面をスクリーンショットとして保存したとします。
- 学校からのお知らせ
- イベントの案内
- アルバイトの勤務連絡
- 病院や美容院の予約画面
- LINEやメールで届いた予定
- 商品の申込期限
- セミナーの開催情報
- 電車や飛行機の予約情報
通常、スクリーンショットを撮影しただけでは、その画像は写真フォルダに保存されるだけです。
利用者は後から画像を見直し、日時、場所、持ち物、申込期限などを自分で確認しなければなりません。保存したこと自体を忘れ、必要な行動を取れない場合もあります。
今回のアプリでは、スクリーンショットを撮影した後、次のような処理を行います。
スクリーンショットを撮影する
↓
新しいスクリーンショットを検出する
↓
画像の内容をGemini APIで解析する
↓
日時・場所・締切などを読み取る
↓
次に行うべき行動を提案する
↓
利用者が内容を確認する
最終的には、次のような提案を表示できる状態を目指します。
画像から次の予定を検出しました。
イベント名:AI活用セミナー
開催日:2026年7月28日
開始時刻:13時00分
場所:第2講義室
申込期限:2026年7月25日
提案する行動
・カレンダーへ予定を追加する
・申込期限の前日に通知する
・会場の場所を確認する
今回のアプリでは、AIが勝手に予定を確定したり、外部サービスへ申し込んだりするのではなく、利用者に行動候補を提示し、最終的な判断は利用者が行う設計を基本とします。
1.2 解決したい問題
スマートフォンでは、気になった情報や後で確認したい内容を、スクリーンショットとして簡単に保存できます。
一方で、スクリーンショットには次のような問題があります。
保存しただけで終わってしまう
スクリーンショットを撮影しても、その後に写真フォルダを見返さなければ、必要な行動にはつながりません。
「後で申し込もう」「予定を登録しよう」と考えて撮影しても、そのまま忘れてしまう可能性があります。
必要な情報を自分で探す必要がある
画像の中には、さまざまな文字や情報が含まれています。
利用者は、その中から次のような情報を自分で見つけなければなりません。
- 何についてのお知らせなのか
- いつ行われるのか
- どこで行われるのか
- 何時までに対応する必要があるのか
- 何を持っていけばよいのか
- どのURLから申し込むのか
情報量が多い画像では、必要な内容を見落とす可能性があります。
次に何をすべきか判断しなければならない
スクリーンショットに書かれている情報を理解できても、そこから必要な行動を考える作業が残ります。
たとえば、イベント案内を保存した場合、次のような判断が必要です。
- 参加するか決める
- 申込期限を確認する
- 申込ページを開く
- カレンダーへ登録する
- 前日に通知を設定する
- 必要な持ち物を準備する
今回のアプリでは、画像の内容を読み取るだけでなく、情報を具体的な行動へ変換することを目指します。
1.3 想定する利用者
アプリを設計する際は、「誰でも使えるアプリ」と考えるのではなく、最初に具体的な利用者を決めることが重要です。
想定する利用者によって、読み取る情報や提案する行動が変わるためです。
学生
学生は、次のような情報をスクリーンショットとして保存することがあります。
-
授業日程
-
課題の締切
-
学校行事
-
就職説明会
-
アルバイトのシフト
-
友人との予定 学生向けであれば、次のような行動を提案できます。
-
課題の締切をリマインダーへ追加する
-
授業予定をカレンダーへ追加する
-
必要な持ち物を一覧にする
-
申込期限の前日に通知する 社会人
社会人は、次のような情報を保存する可能性があります。
-
会議の案内
-
セミナー情報
-
出張予定
-
顧客との連絡
-
商品やサービスの申込情報 社会人向けでは、次のような提案が考えられます。
-
会議予定をカレンダーへ追加する
-
返信が必要なメッセージとして整理する
-
会場を地図で確認する
-
申込期限を通知する 日常生活で利用する人
日常生活では、次のような場面が考えられます。
- 病院や美容院の予約
- 旅行や交通機関の予約
- セールやクーポンの期限
- 家族から送られた予定
- 地域イベントのお知らせ
この場合は、予定登録や期限通知、持ち物確認などが主な行動になります。
本課題では、最初に想定利用者を一つに絞ってください。
たとえば、次のように定義します。
想定利用者:
学校やアルバイトの連絡をスクリーンショットで保存する学生
利用場面:
LINEで送られてきた予定や締切を忘れないようにする
解決したい問題:
保存したスクリーンショットを見返さず、予定や締切を忘れてしまう
利用者を具体的にすると、実装する機能を選びやすくなります。
1.4 スクリーンショットから読み取る情報
Gemini APIへスクリーンショットを送信すると、画像に含まれる文字や内容を解析できます。
ただし、画像に書かれているすべての情報を取得する必要はありません。今回のアプリで必要な項目をあらかじめ決めておきます。
基本的な抽出項目は、次のとおりです。
| 項目 | 内容 |
|---|---|
| タイトル | イベント名、予約名、授業名など |
| 日付 | 開催日、予約日、提出日など |
| 開始時刻 | イベントや予定が始まる時間 |
| 終了時刻 | イベントや予定が終わる時間 |
| 場所 | 会場、教室、店舗、住所など |
| 締切 | 申込期限、提出期限、支払期限など |
| 持ち物 | 学生証、資料、筆記用具など |
| URL | 申込ページや詳細ページ |
| 電話番号 | 問い合わせ先や予約先 |
| 注意事項 | 遅刻禁止、事前予約制など |
| 不明な情報 | 画像から確認できなかった内容 |
画像によっては、必要な情報がすべて書かれているとは限りません。
たとえば、開催日は記載されていても、終了時刻が書かれていない場合があります。その場合、AIが勝手に時刻を補ってはいけません。
{
"title": "就職説明会",
"date": "2026-07-30",
"startTime": "14:00",
"endTime": null,
"location": "第3講義室",
"deadline": "2026-07-28",
"uncertainItems": [
"終了時刻は画像から確認できません"
]
}
このように、分からない情報は空欄にするか、「確認できない」と明記する必要があります。
AIが読み取った内容は、必ず正しいとは限りません。特に次の情報は誤認識の影響が大きいため、利用者に確認させる必要があります。
- 日付
- 時刻
- 申込期限
- 場所
- 電話番号
- URL
- 金額
1.5 提案する「次の行動」
このアプリの目的は、スクリーンショットの内容を説明することだけではありません。
読み取った情報を基に、利用者が次に行うべき行動を提案します。
予定に関する提案
日付、時刻、場所が含まれている場合は、次のような行動を提案します。
- カレンダーへ予定を追加する
- 開始時刻の前に通知する
- 会場を地図で確認する
- 移動時間を確認する 締切に関する提案
申込期限や提出期限が含まれている場合は、次の行動を提案します。
- リマインダーを作成する
- 締切の前日に通知する
- 申込ページを開く
- 必要な準備を確認する 連絡に関する提案
返信や電話が必要な内容であれば、次のように提案します。
- メッセージへ返信する
- 電話をかける
- 問い合わせ先を連絡先へ保存する
- 返信内容の下書きを作る 準備に関する提案
持ち物や必要書類が記載されている場合は、次のような提案ができます。
- 持ち物リストを作成する
- 前日に準備を通知する
- 必要な書類を確認する
ただし、AIが提案した行動を、そのまま自動実行する設計には注意が必要です。
たとえば、誤った日付をカレンダーへ自動登録すると、利用者が間違った予定を信じてしまう可能性があります。
そのため、基本的な流れは次のようにします。
AIが行動を提案する
↓
利用者が読み取った情報を確認する
↓
必要に応じて内容を修正する
↓
利用者が実行ボタンを押す
↓
カレンダーやリマインダーへ登録する
AIは行動を提案しますが、最終的な判断と実行は利用者が行います。
1.6 手動アップロードを必要としない条件
今回の課題では、利用者がアプリを開き、画像を選択してアップロードする操作は行わないものとします。
理想的な動作は、次のとおりです。
-
利用者がスマートフォンでスクリーンショットを撮影する
-
アプリが新しいスクリーンショットを検出する
-
アプリが自動的に画像を取得する
-
Gemini APIへ画像を送信する
-
AIが画像を解析する
-
行動提案を通知する
ただし、この動作がすべてのOSで実現できるとは限りません。
次の条件によって、実現方法が変わります。
- AndroidかiOSか
- OSのバージョン
- アプリが前面に表示されているか
- アプリがバックグラウンドにあるか
- アプリが終了しているか
- 写真へのアクセス権限が許可されているか
- バックグラウンド処理が許可されているか
そのため、この段階では「必ず実現できる」と判断してはいけません。
後の章で、OSごとの公式仕様を確認し、次のいずれかを判断します。
- 完全に実現できる
- 条件付きで実現できる
- 一部のみ実現できる
- 技術的に実現できない 手動アップロード不要と外部送信なしは異なる
この課題で特に注意すべき点があります。
利用者が手動でアップロードしないことと、画像が外部へ送信されないことは別の話です。
Gemini APIを使用する場合、アプリは画像を解析するために、スクリーンショットを外部のサーバーへ送信します。
利用者がアップロードボタンを押していなくても、アプリが自動送信すれば、画像は端末の外へ送られています。
手動アップロードなし
= 利用者が画像を選択する操作が不要
外部送信なし
= 画像が端末外のサーバーへ送られない
Gemini APIを利用する場合は、基本的に次のようになります。
手動アップロード:不要
外部への画像送信:あり
スクリーンショットには、次のような情報が含まれる可能性があります。
- 氏名
- 住所
- 電話番号
- メールアドレス
- 個人的なメッセージ
- 学校や会社の内部情報
- 予約番号
- 医療情報
- 金融情報
- パスワード
- 認証コード
- QRコード
自動処理では、利用者が画像の内容を確認する前に外部送信される可能性があります。そのため、利便性だけでなく、プライバシー上の危険性も考えなければなりません。
本課題では、少なくとも次の対策を検討してください。
- 初回利用時に外部送信を説明する
- 利用者から明確な同意を得る
- 自動解析機能を無効にできるようにする
- 個人情報を含む画像は解析しない
- 送信前に確認画面を表示する案も比較する
- テストには架空の画像を使用する
- APIキーをアプリやGitHubへ直接保存しない
完全な自動化を優先すると、利用者が画像送信に気づきにくくなります。
一方、毎回確認を求めると安全性は高まりますが、「撮影後すぐに自動提案する」という利便性は低下します。
この課題では、利便性と安全性のどちらを優先するのか、その理由も説明することが求められます。
1.7 本課題の提出物
本課題では、完成したアプリだけでなく、開発前の調査、技術選定、実現できなかった理由も提出対象とします。
アプリが完全に完成しなかった場合でも、技術的な原因と代替案を正しく説明できれば、重要な成果として評価します。
1.使用技術の説明
次の内容を記載してください。
- 使用するフレームワーク
- 使用するプログラミング言語
- 使用するライブラリ
- 使用するSDK
- 使用するAIサービス
- 使用する開発ツール
- それぞれを採用した理由
単に技術名を並べるのではなく、アプリの要件と関連付けて説明します。
使用技術:Gemini API
採用理由:
スクリーンショット内の文字だけでなく、画像全体の意味を解析し、
日時、場所、締切、必要な行動を構造化して取得するため。
2.対応OSと権限の説明
次の内容を記載してください。
-
対応するOS
-
最低対応バージョン
-
動作確認した端末
-
必要な権限
-
権限が必要な理由
-
権限を拒否された場合の動作
-
OSによる機能差 必要になる可能性がある権限には、次のようなものがあります。
-
写真や画像へのアクセス
-
通知の表示
-
バックグラウンド処理
-
カレンダーへのアクセス
-
リマインダーへのアクセス 実際に必要な権限は、対応OSと実装方法を調査したうえで決定してください。
3.開発ロードマップ
開発の流れを番号付きで記載してください。
-
要件を整理する
-
OSごとの実現可能性を調査する
-
対応OSを決定する
-
使用技術を選定する
-
GitHubリポジトリを作成する
-
スクリーンショット検出機能を実装する
-
Gemini APIによる画像解析を実装する
-
行動提案機能を実装する
-
権限拒否時の処理を実装する
-
実機で動作確認する
ロードマップには、各工程で何を確認するのかも記載してください。
4.技術的に実現できなかった内容
実装できなかった機能がある場合は、次の内容を記載してください。
- 実装したかった機能
- 試した方法
- 発生した問題
- 実現できなかった原因
- 参照した公式資料
- 現在の実装状況
「時間が足りなかった」だけでは、技術的な原因の説明にはなりません。
OSの仕様、APIの制約、権限の制限、ライブラリの非対応など、具体的な理由を示してください。
5.代替案
実現できなかった場合は、代わりにどのような方法があるか提案してください。
たとえば、完全な自動検出ができない場合は、次のような代替案があります。
- OSの共有機能からアプリへ画像を渡す
- 通知をタップした後に解析を開始する
- アプリ起動中だけスクリーンショットを検出する
- Gemini APIではなく端末内OCRを使う
- 自動送信ではなく確認後に送信する
- Androidだけに対応する
- iOSでは機能を限定する
代替案には、元の要件と比べて何が変わるのかも記載してください。
6.GitHubリポジトリ
実装できたところまでのソースコードをGitHubへ登録し、リポジトリのURLを提出してください。
リポジトリには、少なくとも次の内容を含めます。
- ソースコード
- README
- 使用技術
- セットアップ方法
- 対応OS
- 必要な権限
- 実装済み機能
- 未実装機能
- 技術的な制約
- 代替案
- 動作確認方法
APIキー、パスワード、秘密情報などは、GitHubへ登録してはいけません。
提出物一覧
| 提出物 | 内容 |
|---|---|
| 技術選定資料 | 使用技術と採用理由 |
| OS・権限資料 | 対応OSと必要な権限 |
| 開発ロードマップ | 開発工程を番号順に整理 |
| 技術課題報告 | 実現できなかった機能と原因 |
| 代替案 | 別の実現方法とその違い |
| GitHubリポジトリ | 実装できた範囲のソースコード |
| README | 起動方法、実装状況、注意事項 |
第1章のまとめ
今回制作するのは、スクリーンショットを保存するだけで終わらせず、画像内の情報を次の行動へ変換するアプリです。
アプリの基本的な役割は、次の3つです。
- スクリーンショットの内容を読み取る
- 日時・場所・締切などを整理する
- 利用者へ次の行動を提案する
一方で、手動アップロードを不要にするためには、OS上でスクリーンショットを検出し、画像を自動取得する必要があります。この動作はOSや権限によって制限される可能性があります。
また、Gemini APIを利用する場合、スクリーンショットは解析のために外部へ送信されます。
したがって、本課題では、アプリの便利さだけでなく、次の点も考える必要があります。
- OS上で本当に実現できるか
- どの権限が必要か
- AIが間違えた場合にどうするか
- 個人情報を含む画像をどう扱うか
- 外部送信について利用者へどう説明するか
- 実現できない場合にどのような代替案があるか
次章では、スクリーンショットの撮影から行動提案を表示するまでの処理を分解し、アプリ全体の流れを設計します。