AIでUIを検討
初期のUIコンセプト資料に、Codexの画像生成を活用。画面案を具体化して、設計を考える材料にする。
Newsletter Carte企画と設計の
記録
必要な範囲を決め、 共有できる仕様にする。
依頼・納品・実績をまとめる要望を、画面の役割、入力条件、保存方法へ具体化し、本番導入した配信管理ツール。決定ログ・仕様書・制作過程の画面・GAS実装を通して、担当した設計を紹介します。
設計の過程を読む課題の整理 → 構成の設計 → 技術の選択画像・データ構造・説明用デモで読み解く
01 / 課題から仕様・成果物へ要望を整理し、
要望を整理し、
確かめられる形に。
要望・設計上の問い
配信物と実績が分散し、何を配信してどう反応があったかを追いにくい。制作自体は別の環境で行う。
要件・仕様に変える
制作進行管理を対象外にし、依頼・納品の記録と実績確認に絞る。曖昧な依頼は対象者・目的・内容の入力条件へ変える。
設計判断を読む成果物で確かめる
目的・対象外・画面の役割を整理した仕様書、判断の理由を残した決定ログ、試作画面、GASの実装ソース。
実画面を見る
この事例の担当範囲
業務改善ツールの企画・仕様設計・AIを活用した制作から、本番導入まで取り組みました。仕様資料、画面、Apps Scriptによる保存処理を紹介します。
使う人：配信を依頼する人 / 制作物を受け渡す人 / 実績を振り返る人02 / 体験と処理の流れ画面の操作と、
画面の操作と、
裏側の処理をつなぐ。
画面の見どころ / 01
原稿・画像・確認を、ひとつの画面で。
- 01案件ごとに、原稿と素材を整理。
- 02配信時の見え方と確認状況を並べる。
操作に対応する内部処理を読む
利用者の操作内部の処理
- 01
案件を記録する
対象者・目的・依頼内容を登録する。
内部の処理配信記録を軸に、依頼情報と案件の版数を保持。
- 02
納品物を保存する
画像やHTMLを案件に添付する。
内部の処理属性はAssets、本文はAssetChunksへ分割保存。
- 03
内容を確認する
一覧から案件を開き、配信物を見る。
内部の処理開いた案件の本文だけを取得。切り替え時に前案件の保存済み本文を解放。
- 04
実績と振り返る
配信結果を登録し、内容と並べて読む。
内部の処理結果を案件IDに結びつける。共有更新は入力を妨げない状態で確認。
03 / AI・APIの役割AIで検討し、
AIで検討し、
APIで業務をつなぐ。
制作でのAI活用と、Google Workspace連携
画面の発想にAIを。 共有の処理にApps Scriptを。
- 01ブラウザの画面
案件を開く・保存する
- 02Apps Script
サーバー側の関数を呼ぶ
- 03Sheets / Mail
共有保存・選択宛先への通知
AI・APIの役割と、確認できる範囲
UIコンセプトの検討に画像生成を使い、画面とGoogle Workspaceの処理をつなぐ。制作時のAI活用と、アプリ内の連携をそれぞれ形にしています。
画面とサーバーの連携
google.script.runで自作のApps Script関数を呼び出し、共有データの読み書きや添付の復元を行う。
業務情報の取り込み
配信実績は文面の貼付やCSVから解析。SpreadsheetAppで保存し、MailAppで宛先を選んだ通知を扱う。
UIコンセプト資料と実装ソースに基づく紹介。AIは制作過程での活用です。配信サービスとのAPI自動同期は将来の拡張項目です。
04 / データのつながり体験を支える、
体験を支える、
データの関係。
- 配信・素材の画面案件を開く
- Apps Script必要な本文を取得
- Google Sheets属性と本文を分けて保存
一覧は軽く、開いた案件だけ詳しく。
資料から整理した構成図データ項目と関連を詳しく見る
項目を選ぶと、そのデータにつながる関係を確認できます。
主要なデータの関係
外部キー キー・保存先Assetsrecord_id接続先：DeliveryRecordsAssets保存キーで復元接続先：AssetChunksNewsletterResultsrecord_id接続先：DeliveryRecordsNotesrecord_id接続先：DeliveryRecords
8シートのうち中心となる6つを抜粋。Sheets上のキーによる関連であり、DBの外部キー制約ではありません。
05 / 設計判断と制約その設計には、
その設計には、
理由と制約がある。
画面の先まで考える
Drive SDKを利用できない環境でも、台帳から添付を再表示できる。
01本文も、Sheetsに保存する。
- しくみ
- 添付の属性と本文を分け、本文を45,000文字ずつ保存する。復元時は保存キーから必要な行を取得する。
- この構成でできること
- Drive SDKを利用できない環境でも、台帳から添付を再表示できる。
- 制約・考慮点
- 1ファイル3MiBまで。Base64化によるデータ増加やシート走査があり、大容量ファイル保管の一般解にはならない。
参照：AssetStorageService.gs / Schema.gs
02一覧では本文を読み込まない。
- しくみ
- 一覧では属性だけを取得。案件を開いた時点で本文を復元し、前案件の保存済み本文を解放する。
- この構成でできること
- 表示に必要なものだけを読み込む。切替後に届いた古い案件の応答も、今の表示へ適用しない。
- 制約・考慮点
- 前の案件へ戻ると再取得が必要。未保存の添付は解放しないため、常に1案件分だけのメモリになるわけではない。
参照：WorkspaceBridge.gs / prototype/app.js
03共有更新を、入力操作から切り離す。
- しくみ
- 15秒ごとにリビジョンを確認。入力中、モーダル表示中、保存中、非表示タブなどでは更新確認を見送る。
- この構成でできること
- 他者の変更を取り込みながら、入力や確認の流れを守る。
- 制約・考慮点
- 即時共同編集ではない。入力が続く間は、他者の更新が画面に届くまで時間がかかる。
参照：prototype/gas-bridge.js
04競合の検知と、解決を分けて考える。
- しくみ
- サーバーはロック内でリビジョンを照合し、不一致をCONFLICTとして拒否する。
- この構成でできること
- 同時保存を検出する境界を、サーバー側にも置ける。
- 制約・考慮点
- 現行の一部経路は最新リビジョンだけを取得して再送する。最新内容との差分比較はないため、競合後の再読込・差分確認に改善余地がある。
参照：WorkspaceBridge.gs / gas-bridge.js:saveNow
06 / 場面ごとの動きこんなとき、
こんなとき、
どう動く？
案件を開くと、どのデータを読み込む？
必要な画像・HTMLだけを読み込む工夫を、3つの場面で紹介します。実際のファイルを読み込むデモではありません。
下の状況を選ぶと、図や説明が切り替わります。
この例の結果
一覧では、案件名とファイル名だけを読み込みます。
大きな画像・HTMLの中身は、案件を開いてから取得します。一覧を出すたびに、すべての添付を読み込まずに済む構成です。
しくみと、実運用で確認したいこと
- 案件名・ファイル名この例の注目点
- Aの画像・HTMLこの例では未実施
- Bの画像・HTMLこの例では未実施
- 案件名・ファイル名
- A・Bとも保持
- 画面で使う添付
- A・Bとも未取得
- 保存先の添付
- A・Bとも保存済み
実運用で確認したいこと一覧表示だけで添付本文を取得しないこと。
07 / 担当と次の検証担当したことと、
担当したことと、
今後の改善。
この作品で取り組んだこと
01
要望の範囲を決める
制作管理まで広げず、依頼・納品・実績を残す範囲に絞る。なぜ外したかを、決定ログと仕様に残す。
02
仕様を説明できる形にする
対象者・目的・依頼内容、画面の役割、保存の制約を具体化。画面案と実装を対応づけて説明する。
03
確認条件まで整理する
同時更新、添付の読込、入力中の共有更新を確認項目へ。コードで分かることと、実環境で試すことを分ける。
掲載資料と確認できる範囲
要件・仕様の資料
決定ログに目的を絞った理由、仕様書に対象外・入力条件・表示原則を確認。制作過程の画面案とGAS・8シートの定義も残っています。
確認に使えるコード
添付の遅延読込・解放・分割復元を扱うテスト用ハーネスを掲載資料に含みます。
導入状況と掲載画面
本番導入済みです。掲載画像には制作過程の画面案を含み、数値はサンプルです。要件と実装の対応を伝える資料として紹介しています。