♪♪ きほん｜第2章：AIとITをつなぐ
「返信案を作る指示と、合格基準ができた。次は、ボタン一つで使えるようにしたい！」
第1章を終えた、ほんねくん。チャット画面へ毎回指示を貼る代わりに、問い合わせを入力して「返信案を作る」を押すアプリを考えます。
でも、ボタンを置くだけでAIが動くのでしょうか。
「この画面の、どこにAIがいるんだろう？」
今回は、架空の研修会社「まなびサポート」の返信支援を例に、Webアプリの役割分担を整理します。まだコードを書く必要はありません。😊
結論：画面・処理・保存・AIを分けて考える
Webアプリは、ブラウザに見える画面だけで動いているとは限りません。ブラウザが依頼を送り、サーバー側の処理が結果を返す構成がよく使われます。[1]
今回の設計では、次の4つに役割を分けます。
| 役割 | 担当すること | 返信支援での例 |
|---|---|---|
| 画面 | 入力と結果の表示 | 問い合わせ欄、生成ボタン、返信案 |
| サーバー側の処理 | 入力確認と処理の取りまとめ | 案内を読み、AIへ依頼する |
| データ保存先 | 必要な情報を保持する | 研修案内、保存するなら返信案 |
| AIサービス | 指示と資料から文章を生成 | 返信の下書きを作る |
これは今回のアプリの構成例です。すべてのWebアプリに、独立した保存先や外部AIが必要なわけではありません。
① 画面：利用者が触る場所
ブラウザ側で動く部分を、クライアント側と呼びます。利用者に見える画面や、その操作を扱う部分は、フロントエンドとも呼ばれます。
ほんねくんのアプリなら、問い合わせの入力欄、生成ボタン、返信案の表示欄です。ボタンを押したら、処理中の表示に切り替える仕事もあります。
ここで大事なのは、画面に表示されたことと、保存されたことは別だという点です。ブラウザを閉じても残したいなら、そのための保存処理を設計します。
② サーバー側：仕事を取りまとめる場所
ブラウザからの依頼を受け、必要な処理を行う側を、サーバー側、またはバックエンドと呼びます。サーバーという言葉は、役割を担うソフトウェアや、その実行環境を指す場合があります。
今回なら、入力を確認し、研修案内と第4話の指示を組み合わせてAIへ渡し、返ってきた結果を画面に届けます。
「AIの仕事は下書き。アプリ側は、その前後をつなぐんだね！」
画面でも空欄チェックはできますが、画面側のチェックだけに頼りません。サーバー側でも入力内容や利用権限を確かめる設計にします。
③ 保存先：何を残すかは、自分で決める
研修案内は、更新した内容を次の返信にも使いたい情報です。一方、問い合わせ全文や返信案を、すべて永久保存する必要があるでしょうか。
最初の試作では、「研修案内は保存する」「問い合わせと返信案は、この画面での確認に使う」と分けることもできます。保存しない設計にする場合も、外部サービス側のデータの扱いは別途確認が必要です。
保存するなら、保存先、見られる人、残す期間、削除方法を決めます。試作ではスプレッドシートを保存先にする選択肢もありますが、利用規模や必要な管理に応じて考えます。
そして、「保存しました」という表示は、保存処理の成功を確認してから出すようにします。
④ AI：アプリから依頼する相手
今回の構成では、サーバー側の処理が、外部のAIサービスへ文章生成を依頼します。その窓口となるAPIの詳しい話は、次回です。
AIへ渡すのは、問い合わせだけではありません。研修案内、守る条件、出力形式も含まれます。不要な情報まで渡さず、仕事に必要な範囲を整理します。
また、この構成で使う秘密のAPIキーを、ブラウザへ配るHTMLやJavaScriptに書かないことも設計上のポイントです。サーバー側へ置けばすべて安全というわけではなく、アプリを使える人や利用回数の管理も必要になります。
ボタンを押すと、何が起きる？
今回の返信支援は、次の順番で動く設計です。
- 画面で問い合わせを入力し、生成ボタンを押す。
- ブラウザが、サーバー側へ依頼を送る。
- サーバー側が入力と権限を確認し、必要な研修案内を読む。
- 指示・案内・問い合わせをAIサービスへ送り、返信案を受け取る。
- 結果をブラウザへ返し、返信案と確認事項を表示する。
- 担当者が確認・修正し、普段使うメールなどから送信する。
最後の送信は、この段階のアプリでは自動化しません。下書きを表示することと、顧客へ送ることを分けておきます。
待っている間と、失敗したときも設計する
依頼を送ってから結果が返るまで、時間がかかることがあります。結果を待つ間も画面が操作できるようにする方式を、非同期処理と呼びます。GASのHTMLサービスでも、画面からサーバー側の関数を非同期で呼び出せます。[2]
「何も起きない」と思って連打されないよう、処理中は生成ボタンを無効にし、状況を表示する設計にします。
エラーが返ったら、「失敗しました」と表示して再操作できるように戻します。ただし、通信が途切れたときは、裏側の処理まで止まったと断定できません。保存や送信を伴う処理では、重複して実行されない仕組みも必要です。
GASなら、サーバーを買わなくていい？
Google Apps Script（GAS）の処理は、HTMLサービスでブラウザに表示する部分などを除き、Googleのサーバー上で実行されます。[3]
つまり、今回のような構成では、自分でサーバー機器を購入しなくても、サーバー側の処理を用意できます。だからといって、画面と裏側の区別や、権限・利用制限の設計が不要になるわけではありません。
GASの実装は後の回で扱います。今日は「どこで、何をするか」を説明できれば十分です。
今日の実践：ボタンの裏側を4つに分けよう
5分ほどで、自分の商品仮説について次の4点を書き出してください。
- 画面：何を入力し、何を表示する？
- 処理：何を確認し、どの順番で動かす？
- 保存：何を、どこへ、いつまで残す？
- AI：どの情報を渡し、何を作らせる？
さらに、「処理中」「成功」「失敗」で利用者に何を見せるかを一つずつ考えます。
「ボタンを増やす前に、裏側の仕事を決める必要があるんだ！」
🍀 今日の理解
Webアプリは、画面・サーバー側の処理・保存先・AIの役割を分けて設計する。表示、保存、送信も別の処理として考える。
🔍 ほんねチェック
画面が完成しても、仕事の流れが完成したとは限りません。待ち時間、失敗、保存の成否まで含めて、利用者が迷わず使えるかを確認しましょう。
📝 会社づくりメモ⑤
- 画面とサーバー側で、それぞれ何をする？
- 保存する情報と、保存しない情報は？
- 外部AIへ渡す情報は？
- 処理中・成功・失敗を、どう伝える？
次回：APIはAIへの窓口！鍵と利用制限を知ろう
APIの依頼と応答、認証、APIキー、利用制限を整理します。
シリーズ案内：全24話。原則1日1話、休みを挟みながら進めます。
前回：第4話「良い回答は偶然？プロンプトを試して比べよう」
参考資料（2026年10月18日確認）
- [1] MDN：Client-server overview — ブラウザとサーバーの依頼・応答。
- [2] Google for Developers：HTML Service — Communicate with Server Functions — 非同期呼び出しと結果・エラーの処理。
- [3] Google for Developers：Built-in Google Services — GASの実行環境。