
♪♪ きほん|AIをアプリから呼び出す、その前に
「画面から裏側へ依頼を送って、AIに返信案を作ってもらう。流れは見えてきた!」
第5話でWebアプリの役割を整理した、ほんねくん。次に気になったのは、サーバー側のプログラムが、どうやって外部のAIを使うのかです。
「AIにも、仕事を頼むための窓口があるの?」
あります。その窓口の一つが、APIです。今回は、架空の研修会社「まなびサポート」の返信支援を例に、依頼の仕組み、APIキー、利用制限を整理します。😊
結論:窓口のルール、鍵、利用枠をセットで知る
APIは、Application Programming Interfaceの略です。プログラム同士が機能やデータを利用するための、決められた接点を指します。
APIにはさまざまな種類がありますが、ここではインターネット経由でAIサービスへ依頼するWeb APIを扱います。人がチャット画面を操作する代わりに、プログラムが決められた形式で依頼します。
押さえるのは、次の3点です。
- ルール:どこへ、何を、どんな形式で送るか。
- 鍵:どの認証方式で利用するか。今回の例ではAPIキー。
- 利用枠:一定時間にどれだけ使えるか、料金はどうなるか。
APIを使うことと、無制限に使えることは別です。

① プログラムが「依頼」を送り、「応答」を受け取る
ほんねくんのアプリでは、サーバー側がAIサービスに返信案の生成を依頼します。送る内容は、例えば次のものです。
- 利用するモデルの指定。
- 第4話で整理した、返信案を作る指示。
- 必要な研修案内と、問い合わせ本文。
- 出力の長さなど、必要な設定。
依頼する先のURLは、エンドポイントと呼ばれます。そこへ、仕様に沿った依頼、つまりリクエストを送ります。認証情報は、サービスが指定する場所に付けます。
返ってくる結果がレスポンスです。返信案だけでなく、利用量などの情報や、失敗した場合のエラーが含まれることもあります。具体的な項目や形式はAPIの仕様によります。[3]
ただし、通信が成功したことと、返信案が正しいことは別です。本文が取得できたか、必要な項目があるかをアプリで確認し、内容は人も確認します。
② APIキーは、公開するための情報ではない
APIの利用には認証が必要な場合があります。Gemini APIではAPIキーを使った認証が用意され、キーはプロジェクトに関連付けられています。[1]
ここでいうキーは、利用に関わる秘密情報です。漏れると、他人に利用枠を消費されたり、想定外の費用につながったりする可能性があります。[1]
「動かすための鍵を、配る画面に書いちゃいけないんだね」
今回の構成では、キーをブラウザへ配るHTMLやJavaScriptに埋め込みません。サーバー側で読み込み、AIへの依頼に使います。公開するGitHubのコード、記事、スクリーンショット、ログにも残さないようにします。
キーは、AIに読ませる指示文へ書くものでもありません。AIへ渡す資料と、サービスへの認証情報は分けて扱います。
なお、APIキーがあるからといって、アプリを使っている人が誰なのかまで確認できるとは限りません。AIサービスを利用する認証と、自分のアプリの利用者確認は別に設計します。
③ GASでは、キーをどこに置く?
GASの試作では、設定値を保存するスクリプトプロパティを使う方法があります。プロパティサービスは、キーと値の組で設定を扱う仕組みです。[4]
ただし、スクリプトプロパティは、プロジェクトの編集者からも秘密を守れる専用の保管庫ではありません。編集権限を持つ人が取得できる前提で、共有範囲を考えます。
「サーバー側へ置いたから、公開範囲は何でもよい」わけでもありません。誰がアプリを使えるか、何回呼び出せるか、どんな入力を受け付けるかも決めます。
今回はキーの発行や実際の接続は行いません。GASでの組み込みは、第8話の試作へつなげます。
④ 利用制限は、料金とは分けて確認する
APIには、一定時間に使える量の制限があります。Gemini APIでは、リクエスト数やトークン数などの制限があり、モデルや利用階層などによって条件が異なります。[2]
| 確認すること | 意味 | 設計への影響 |
|---|---|---|
| リクエスト数 | 一定時間の呼び出し回数 | 連打や一斉利用への対応 |
| トークン数 | 一定時間に処理できる量 | 長い資料や多数の入力への対応 |
| 利用料金 | 使用量などに応じた費用 | 予算と利用量の記録 |
無料枠でも制限があり、有料なら何でも無制限になるわけではありません。制限の数値は変わるため、実際に使うモデルとプロジェクトの現在の条件を確認します。
ほんねくんの試作なら、まずは少人数で使い、呼び出し回数と利用量を記録します。予算を知らせる通知と、利用を実際に止める仕組みも区別しておきます。
⑤ 429が出たら、連打しない
APIが使えなかったときは、エラーの種類と内容を読みます。例えば、HTTPの429は、リクエストやトークンの制限などに達した場合に返ることがあります。[2][3]
短時間の混雑や制限なら、案内された待ち時間を尊重し、回数を決めて間隔を空ける方法を考えます。一方、日単位の枠や利用条件が原因なら、数秒待つだけでは解消しません。
入力や認証の問題も、同じ依頼を繰り返すだけでは直りません。エラー本文と管理画面を確認して、原因に合った対応をします。

「とにかく再送信じゃなくて、何で止まったのかを見るんだ!」
画面には「今は作成できませんでした」など、利用者が次の操作を判断できる案内を出します。内部の詳しいエラーをそのまま見せず、キーなどの秘密情報を表示・記録しない設計にします。
今日の実践:接続前のメモを作ろう
5分ほどで、次の4項目を書いてみてください。まだAPIキーは作らなくて大丈夫です。
- 渡す情報:指示、案内、問い合わせのうち、何を送る?
- 鍵の管理:サーバー側のどこへ置き、誰が触れる?
- 利用枠:回数・トークン・料金を、どこで確認する?
- 失敗時:利用者へ何を伝え、再試行はどうする?
例えば、「案内は必要な項目に絞る」「キーをHTMLへ書かない」「利用量を記録する」「制限時は連打させない」が、ほんねくんの最初の方針です。
🍀 今日の理解
APIはプログラムから機能を利用する窓口。依頼の形式、認証情報の管理、利用制限をセットで確認する。
🔍 ほんねチェック
つながっただけで完成にしないこと。キーの保管、アプリの利用者確認、利用量、エラー時の動作までが、仕事で使うための設計です。
📝 会社づくりメモ⑥
- 利用するAPIと、その仕様の確認先は?
- 認証情報の保管先と、触れられる人は?
- 利用枠と費用を誰が確認する?
- 制限や失敗が起きたとき、どう案内する?
次回:AIとアプリの共通言語「JSON」
依頼や結果を、プログラムで扱いやすい形にする方法を見ていきます。
シリーズ案内:全24話。原則1日1話、休みを挟みながら進めます。
前回:第5話「ボタンを押した後、Webアプリの裏で何が起きる?」
参考資料(2026年10月18日確認)
- [1] Google AI for Developers:Using Gemini API keys — APIキーと秘密情報の管理。
- [2] Google AI for Developers:Rate limits — 利用枠と制限。
- [3] Google AI for Developers:API errors — 応答とエラー。
- [4] Google for Developers:Properties Service — GASの設定値の保存。